背景
毋庸置疑，質量是決定產品能否成功、企業能否持續發展的關鍵因素之一。對於“質量時代”下的網際網路企業，如何在快速迭代的節奏中兼顧質量，真正落地“人人重視質量、人人創造質量、人人享受質量”，這是對QA的要求，也是整個產品技術團隊面臨的重要挑戰。
質量運營，是將運營的思路注入到質量評估與改進工作中，它著眼於產品的全生命週期，以質量為中心，以資料為驅動，通過建設持續迭代的質量保障體系，最終提升交付質量。本文將聚焦研發過程中的提測階段，以改進提測質量為例，從方案制定、策略應用、效果評估等幾個方面，介紹質量運營在智慧支付業務中的初步應用。
挑戰
美團點評智慧支付承擔了整個公司所有線下交易，當前日交易量已經突破1000萬單，是公司繼外賣和摩拜之後，又一個千萬級日訂單的業務。業務高速增長、團隊快速擴張的情況下，質量問題極易被放大化，如果不能及時得到處理，後續解決成本會越來越高。
存在的痛點
剛參與智慧支付業務測試時遇到的幾個問題，如下：
- 缺陷嚴重級別高，提測打回時常發生
如：核心功能未實現或實現與需求不符。 - 缺陷數量多，定位、修復、迴歸耗時長
如：越在上游引入的缺陷，修復的成本就越高，潛在的風險也越大。 - 各類低階缺陷，團隊彼此間的信任度降低
如：文案錯誤、變數引用錯誤等編碼大意導致的低階缺陷。
解決的難點
在嘗試去改善時發現難以推動的幾個問題，如下：
- 對暴露出的質量問題，如何更直觀的在認知上達成一致？
如：收到過很多類似的問題反饋：“xx的缺陷太多了，質量意識差”、“xx專案存在很大問題，需要儘快改進”，即使是基於事實得出的判斷，這種偏主觀的表達方式，對問題達成一致的認知帶來很大的困難。 - 對已公認的質量問題，如何更快速的進行分析和定位？
如：缺陷發生在測試階段，但缺陷的引入可能是在需求階段、設計階段、開發階段；某個時間段內的異常質量資料，可能是A專案或B專案，可能是C團隊或D團隊。問題型別細分、資料鑽取能力等等，在問題的快速分析和定位中至關重要。 - 對已定位的質量問題，如何找到可以落地的改進措施？
如：專案總結中常常會見到類似這樣的描述：“加強自測”、“嚴格遵守專案流程”、“文件需要寫的更詳細些”，這種偏“形容詞”的改進措施，很難實際操作，這也是整個質量改進過程中最大的一個難點。
思路
質量改進是一個持續迭代的過程，不可急於求成。按照質量運營的方法，基本思路為：分析痛點，找到抓手，持續運營，形成閉環。
基於提測階段的質量問題特徵，從痛點和難點中尋找突破點。大致思路為：
- 目標應達成一致：質量改進的目標是QA的KPI，並應該與關鍵干係人在願景、目標上達成一致。
- 問題的客觀呈現：提取核心度量指標，通過有效資料和典型案例說話。
- 資料的靈活鑽取：儘可能全的提供各種維度的資料，並分層級展示。
- 改進措施可落地：對措施的多方Review、流程標準化到工具化的演進。
解決方案
解決方案的重中之重，是務必遵循PDCA來實現運轉方式的閉環。具體如下：
確定問題與方向
通過痛點描述可知，缺陷是反映智慧支付業務當前提測質量的最顯著特徵。提測質量的進一步分析，可通過缺陷的數量、缺陷的嚴重程度、缺陷的生成原因三個方向來展開。
缺陷數量
| 缺陷數量 | 具體說明 |
|---|---|
| 缺陷總數 | 指定統計規則下缺陷的數量，僅包含專案過程中提交的缺陷 |
缺陷的嚴重程度
| 嚴重級別 | 具體說明 | 使用範圍 |
|---|---|---|
| 致命-Blocker | 影響核心功能的缺陷 | 缺陷導致核心業務流程不可用，或產生較大影響 |
| 嚴重-Critical | 造成較大影響的功能性缺陷 | 缺陷導致核心業務流程受影響，或導致非核心業務流程不可用 |
| 一般-Major | 影響較小的功能性缺陷 | 缺陷導致非核心業務流程受影響，或導致使用者體驗類的問題 |
| 提示-Minor | 非功能性缺陷 | 如：不影響正常功能的UI錯誤、無重大歧義的提示錯誤等 |
| 建議-Trivial | 優化建議 | 非嚴格意義上的缺陷，一些可優化的點 |
缺陷的生成原因
| 生成原因 | 具體說明 |
|---|---|
| 實現與文件不符 | RD實現與需求文件描述不一致 |
| 需求缺陷 | 需求文件中缺少相應描述；需求變更 |
| 技術方案考慮不足 | 前後端介面定義不一致；對邊界、異常場景考慮不全等 |
| 環境問題 | 被測服務不穩定；伺服器或測試裝置配置等引起的問題 |
| 第三方依賴 | 依賴的外部系統引入的問題，如使用者中心等 |
| 相容性 | 不同裝置上出現的功能或展示異常類的問題 |
| 效能問題 | 服務端效能：響應時間過長、CPU過高、GC頻繁、沒有分頁、沒有快取等； 客戶端功耗：包大小、冷啟動時間、流量、記憶體洩漏OOM、載入時間、耗電量 |
| 安全問題 | XSS注入，SQL隱碼攻擊等 |
| Bugfix引入 | 由於修改Bug引入的缺陷 |
| 不是缺陷 | 無效Bug；不能復現 |
度量指標及標準
針對缺陷的三個分析方向，提取出可度量的指標、定義合理的標準值，並與整個團隊達成一致。
指標提取策略
- 典型性
- 找最想要解決的問題。不追求全面，只針對Top問題提取指標，如：生成原因裡最應該避免的是哪些。
- 找最能反映問題的指標。如：缺陷數量有眾多度量指標（新增數量、人均數量等等），為排除工作量影響，我們選擇用千行程式碼缺陷率這個指標。
- 有效性
- 除非對絕對數量有明確要求，否則儘量使用百分比作為度量指標。
- 指標資料的計算方式，要求簡單易懂，並務必得到相關人的認可。
標準制定策略
- 基於公司統一要求
如：Sonar千行程式碼嚴重問題數，統一標準為低於0.1。 - 基於公司各業務現狀
如：缺陷相關指標按照公司各業務部門排行，取Top5的值作為標準線。 - 基於自身業務階段持續調整
如：隨著智慧支付業務質量的持續改進，定義更嚴格的質量標準。
最終定義的指標與標準
| 度量指標 | 指標說明 | 標準值 |
|---|---|---|
| 千行程式碼缺陷率 | （缺陷總數/程式碼行數）* 1000 | 移動端：< 0.45 前端：< 0.2 後端：< 0.15 |
| Sonar千行程式碼嚴重問題數 | （Sonar嚴重問題數/程式碼行數）* 1000 | Blocker：0 總數：< 0.1 |
| 嚴重缺陷佔比 | 嚴重缺陷總數/缺陷總數 | < 3.5% |
| 需求缺陷佔比 | 需求缺陷總數/缺陷總數 | < 10% |
| 實現與文件不符缺陷佔比 | 實現與文件不符缺陷總數/缺陷總數 | < 10% |
獲取資料並展示
基於Metrics（美團點評工程質量中心提供的度量平臺），能夠快速的獲取資料並展示。但要注意，部分指標的計算需要對Metrics提供的資料進行二次處理，以保證資料的精準性。如：在計算千行程式碼缺陷率時，需要排除掉開發自測缺陷等。
對於資料的展示形式，除了利用Metrics提供的各種圖表外，最為關鍵的是要實現資料與問題（相關缺陷）的可關聯，以便進行下一步分析。如下圖所示（通過超連結方式進行關聯）：
制定計劃並改進
改進措施的制定和實施是整個質量改進過程中的重中之重。基於經驗，給出三個策略。
自上而下與自下而上相結合
- 自上而下：通過有效資料、典型案例，建設可信任的結果評估體系；以此為基礎，利用每一個問題資料，在Leader層強化質量意識，借鑑向上管理的思路，實現質量改進的向下驅動。
- 自下而上：通過案例覆盤、資料鑽取，對問題進行明確定位，讓問題方基於工具即可將問題下沉到具體專案或具體角色，進而推進可落地的過程改進，並持續利用結果評估體系衡量改進效果，實現質量改進的向上閉環。
多維度的資料聚合與分析相結合
- 周維度資料聚合：對週資料中的異常進行分析，並排除掉因週期偏短導致的資料噪點，重在對問題進行風險預警。
- 月維度資料聚合：對月資料中的異常進行分析，並結合資料的變化趨勢，重在對問題進行確認和改進。周維度和月維度相結合，構成了質量管理中的問題發現與改進週期。
- 季度維度資料聚合：對季度資料的分析，重在得出對質量目標的完成度並給出質量評分，並對過程中的問題進行回顧和總結，構成了質量管理中的考核週期。
流程的標準化與工具化相結合
- 在改進提測質量的初期階段，對於流程的優化經常出現在各個專案總結的改進措施中，但大多是通過意識、模板或者口頭提醒來實現，這無疑增加了流程的接入成本、執行難度，進而降低了流程的約束力。
- 借鑑在製造業中常見的一種解決思路——“防呆措施”，在流程標準化之後，應儘可能將其工具化，提升流程的生命力。
- 防呆措施的目的之一是防止不符合流程的產出物交付到下游。
- 將防呆措施應用到提測流程，即應實現各項准入標準的自動化檢查，類似如下提測時校驗：
回顧與反饋
主要從時間維度、專案維度兩方面開展。
- 時間維度
各類週會、雙週會、季度總結，對質量資料進行Review。 - 專案維度
重在專案覆盤。覆盤可以看成PDCA環和環之間的連線，有了它，PDCA才能環環相扣、周而復始。
迭代與推廣
若改善有效，則進行推廣。若改善無效，則分析原因，修改計劃，重新啟動另一輪PDCA。
- 指標與標準的持續迭代
如：過程中對Sonar千行嚴重問題數的標準由0.1提升到0。 - 度量模型與方法工具的推廣
如：質量報表、Sonar在PR時觸發檢查不通過不允許Merge、提測准入自動化等等在其他業務的推廣。
效果
對於效果的評估，主要從三方面進行說明。
- 質量資料的關注度
- 質量指標的達成度
- 過程質量改進對迭代效率的提升效果
質量資料關注度
主要體現在團隊各方對質量報表的使用率。以下三張圖分別為：智慧支付QA、智慧支付RD、智慧支付RD Leader對質量報表的使用率走勢。
質量指標達成度
對質量指標的達成情況進行說明，其中：初始值為16年Q4的情況。
| 度量指標 | 初始值 | 標準值 | 目標完成度 |
|---|---|---|---|
| 千行程式碼缺陷率 | 移動端：0.7 前端：0.25 後端：0.3 |
移動端：< 0.45 前端：< 0.2 後端：< 0.15 |
整體達標，但存在個別方向缺陷率較高 |
| Sonar千行程式碼嚴重問題數 | Blocker > 0 總數：0.2 |
Blocker：0 總數：< 0.1 |
達標 |
| 嚴重缺陷佔比 | 14%左右 | < 3.5% | 達標 |
| 需求缺陷佔比 | 18%左右 | < 10% | 達標 |
| 實現與文件不符缺陷佔比 | < 10% | < 10% | 達標，但有升高趨勢，接近標準值 |
近幾個Q的變化趨勢，如下：
迭代效率提升效果
以客戶端方向為例（之前過程質量存在較嚴重的問題），說明過程質量改進對迭代效率的提升效果。
總結
經過一段時間的摸索和實踐，我們在提測質量上有了較明顯的提升，過程中積累的方法、流程和工具也在推廣使用。但提測質量只是全生命週期質量運營的一小部分，對於高速發展的智慧支付業務，不僅要求整個質量保證體系的迭代優化，更要求全體成員不斷提升質量思維、持續追求極致質量，進而形成一種質量文化，真正實現“人人重視質量、人人創造質量、人人享受質量”。
作者介紹
勳偉，美團點評高階測試開發工程師，金融服務平臺智慧支付業務測試負責人，2015年加入美團點評。
如果你想學習網際網路金融的技術體系，親歷網際網路金融業務的爆發式增長，如果你想和我們一起，保證業務產品的高質量，歡迎加入美團金融工程質量組。有興趣的同學可以傳送簡歷到：fanxunwei#meituan.com。
