质量运营在智能支付业务测试中的初步实践
背景
毋庸置疑，質量是決定產品能否成功、企業能否持續發展的關鍵因素之一。對于“質量時代”下的互聯網企業，如何在快速迭代的節奏中兼顧質量，真正落地“人人重視質量、人人創造質量、人人享受質量”，這是對QA的要求，也是整個產品技術團隊面臨的重要挑戰。
質量運營，是將運營的思路注入到質量評估與改進工作中，它著眼于產品的全生命周期，以質量為中心，以數據為驅動，通過建設持續迭代的質量保障體系，最終提升交付質量。本文將聚焦研發過程中的提測階段，以改進提測質量為例，從方案制定、策略應用、效果評估等幾個方面，介紹質量運營在智能支付業務中的初步應用。
挑戰
美團點評智能支付承擔了整個公司所有線下交易，當前日交易量已經突破1000萬單，是公司繼外賣和摩拜之后，又一個千萬級日訂單的業務。業務高速增長、團隊快速擴張的情況下，質量問題極易被放大化，如果不能及時得到處理，后續解決成本會越來越高。
存在的痛點
剛參與智能支付業務測試時遇到的幾個問題，如下：
解決的難點
在嘗試去改善時發現難以推動的幾個問題，如下：
思路
質量改進是一個持續迭代的過程，不可急于求成。按照質量運營的方法，基本思路為：分析痛點，找到抓手，持續運營，形成閉環。
基于提測階段的質量問題特征，從痛點和難點中尋找突破點。大致思路為：
解決方案
解決方案的重中之重，是務必遵循PDCA來實現運轉方式的閉環。具體如下：
確定問題與方向
通過痛點描述可知，缺陷是反映智能支付業務當前提測質量的最顯著特征。提測質量的進一步分析，可通過缺陷的數量、缺陷的嚴重程度、缺陷的生成原因三個方向來展開。
缺陷數量
| 缺陷總數 | 指定統計規則下缺陷的數量，僅包含項目過程中提交的缺陷 |
缺陷的嚴重程度
| 致命-Blocker | 影響核心功能的缺陷 | 缺陷導致核心業務流程不可用，或產生較大影響 |
| 嚴重-Critical | 造成較大影響的功能性缺陷 | 缺陷導致核心業務流程受影響，或導致非核心業務流程不可用 |
| 一般-Major | 影響較小的功能性缺陷 | 缺陷導致非核心業務流程受影響，或導致用戶體驗類的問題 |
| 提示-Minor | 非功能性缺陷 | 如：不影響正常功能的UI錯誤、無重大歧義的提示錯誤等 |
| 建議-Trivial | 優化建議 | 非嚴格意義上的缺陷，一些可優化的點 |
缺陷的生成原因
| 實現與文檔不符 | RD實現與需求文檔描述不一致 |
| 需求缺陷 | 需求文檔中缺少相應描述；需求變更 |
| 技術方案考慮不足 | 前后端接口定義不一致；對邊界、異常場景考慮不全等 |
| 環境問題 | 被測服務不穩定；服務器或測試設備配置等引起的問題 |
| 第三方依賴 | 依賴的外部系統引入的問題，如用戶中心等 |
| 兼容性 | 不同設備上出現的功能或展示異常類的問題 |
| 性能問題 | 服務端性能：響應時間過長、CPU過高、GC頻繁、沒有分頁、沒有緩存等； 客戶端功耗：包大小、冷啟動時間、流量、內存泄漏OOM、加載時間、耗電量 |
| 安全問題 | XSS注入，SQL注入等 |
| Bugfix引入 | 由于修改Bug引入的缺陷 |
| 不是缺陷 | 無效Bug；不能復現 |
度量指標及標準
針對缺陷的三個分析方向，提取出可度量的指標、定義合理的標準值，并與整個團隊達成一致。
指標提取策略
- 找最想要解決的問題。不追求全面，只針對Top問題提取指標，如：生成原因里最應該避免的是哪些。
- 找最能反映問題的指標。如：缺陷數量有眾多度量指標（新增數量、人均數量等等），為排除工作量影響，我們選擇用千行代碼缺陷率這個指標。
- 除非對絕對數量有明確要求，否則盡量使用百分比作為度量指標。
- 指標數據的計算方式，要求簡單易懂，并務必得到相關人的認可。
標準制定策略
最終定義的指標與標準
| 千行代碼缺陷率 | （缺陷總數/代碼行數）* 1000 | 移動端：< 0.45 前端：< 0.2 后端：< 0.15 |
| Sonar千行代碼嚴重問題數 | （Sonar嚴重問題數/代碼行數）* 1000 | Blocker：0 總數：< 0.1 |
| 嚴重缺陷占比 | 嚴重缺陷總數/缺陷總數 | < 3.5% |
| 需求缺陷占比 | 需求缺陷總數/缺陷總數 | < 10% |
| 實現與文檔不符缺陷占比 | 實現與文檔不符缺陷總數/缺陷總數 | < 10% |
獲取數據并展示
基于Metrics（美團點評工程質量中心提供的度量平臺），能夠快速的獲取數據并展示。但要注意，部分指標的計算需要對Metrics提供的數據進行二次處理，以保證數據的精準性。如：在計算千行代碼缺陷率時，需要排除掉開發自測缺陷等。
對于數據的展示形式，除了利用Metrics提供的各種圖表外，最為關鍵的是要實現數據與問題（相關缺陷）的可關聯，以便進行下一步分析。如下圖所示（通過超鏈接方式進行關聯）：
制定計劃并改進
改進措施的制定和實施是整個質量改進過程中的重中之重?；诮涷?#xff0c;給出三個策略。
自上而下與自下而上相結合
- 自上而下：通過有效數據、典型案例，建設可信任的結果評估體系；以此為基礎，利用每一個問題數據，在Leader層強化質量意識，借鑒向上管理的思路，實現質量改進的向下驅動。
- 自下而上：通過案例復盤、數據鉆取，對問題進行明確定位，讓問題方基于工具即可將問題下沉到具體項目或具體角色，進而推進可落地的過程改進，并持續利用結果評估體系衡量改進效果，實現質量改進的向上閉環。
多維度的數據聚合與分析相結合
- 周維度數據聚合：對周數據中的異常進行分析，并排除掉因周期偏短導致的數據噪點，重在對問題進行風險預警。
- 月維度數據聚合：對月數據中的異常進行分析，并結合數據的變化趨勢，重在對問題進行確認和改進。周維度和月維度相結合，構成了質量管理中的問題發現與改進周期。
- 季度維度數據聚合：對季度數據的分析，重在得出對質量目標的完成度并給出質量評分，并對過程中的問題進行回顧和總結，構成了質量管理中的考核周期。
流程的標準化與工具化相結合
- 在改進提測質量的初期階段，對于流程的優化經常出現在各個項目總結的改進措施中，但大多是通過意識、模板或者口頭提醒來實現，這無疑增加了流程的接入成本、執行難度，進而降低了流程的約束力。
- 借鑒在制造業中常見的一種解決思路——“防呆措施”，在流程標準化之后，應盡可能將其工具化，提升流程的生命力。
- 防呆措施的目的之一是防止不符合流程的產出物交付到下游。
- 將防呆措施應用到提測流程，即應實現各項準入標準的自動化檢查，類似如下提測時校驗：
回顧與反饋
主要從時間維度、項目維度兩方面開展。
迭代與推廣
若改善有效，則進行推廣。若改善無效，則分析原因，修改計劃，重新啟動另一輪PDCA。
效果
對于效果的評估，主要從三方面進行說明。
質量數據關注度
主要體現在團隊各方對質量報表的使用率。以下三張圖分別為：智能支付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。
總結
以上是生活随笔為你收集整理的质量运营在智能支付业务测试中的初步实践的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Android单元测试研究与实践
- 下一篇： 从逻辑回归到神经网络