一位關注我公眾號很久的同學後臺留言，問了我一些關於質量度量的問題，和他溝透過程中交換了彼此的一些觀點，也讓我對質量度量有了一些新的理解。這篇文章聊聊在質量度量中，幾個很有意思的指標，以及常見的誤區。
什麼是缺陷收斂率
說到缺陷收斂率，就不得不先聊聊缺陷逃逸率。
我在前面的文章《聊聊缺陷逃逸率》中對缺陷逃逸率是如此描述的：缺陷逃逸率指的是軟體產品線上釋出後，發生線上上環境的缺陷數量與該版本迭代生命週期內總缺陷數量的比率，缺陷逃逸率也稱之為線上BUG逃逸率或者“測試逃逸”。
關於線上缺陷逃逸率，有這樣一個計算公式：線上缺陷逃逸率=線上缺陷數/版本週期總缺陷數×100%。這個指標一般除了衡量線上的產品交付質量以外，還可以用來評估測試團隊的質量控制水平。
既然是質量控制，那對應的就是要控制線上缺陷的數量，或者儘可能降低線上缺陷對業務和系統穩定性的影響。在這樣的背景下，就有了缺陷收斂率這樣一個質量度量指標。
缺陷收斂率的作用
所謂缺陷收斂率，反映的是缺陷在軟體產品研發過程中的變化趨勢和修復的時效性問題。
一般來說，軟體系統會在測試階段的前中期(單元測試&整合測試)暴露出大量缺陷，到系統測試和迴歸測試階段，缺陷數量會有明顯的下降和收斂趨勢。
為什麼會出現這樣一個指標呢？正常來說每輪測試發現的bug，應該在下一輪測試開始之前都儘量修復，且bug的reopen數量應該有大幅度的降低，這樣才能從某種角度證明，測試活動是有效的。
單純以bug數量衡量軟體產品質量，是不夠全面的，但是bug數量的多寡確實在很大程度上體現了產品的功能正確性。
如果在多輪的測試和bug修復後，依然存在很多bug，那隻能說質量控制的結果是失敗的。與之對應的，無論是測試活動，還是研發規範，或者說編碼質量，肯定存在很大的風險。
而缺陷收斂率的作用，則是用來度量這一過程的工作結果，是否符合預期。
同時這一指標還可以提醒研發測試同學，避免潛在的風險向下遊傳遞，放大影響範圍和修復成本。再進一步來說，透過缺陷收斂率這一指標，來控制和降低產品驗收以及線上釋出的風險。
如何度量缺陷收斂率
既然缺陷逃逸率可以度量，那麼缺陷收斂率同樣可以度量。下圖是一張缺陷收斂折線圖：
（網圖侵刪，僅供示意參考）
一般來說，從提測到線上釋出，再到下一版本線上釋出之前，這一階段可以視為一個完整的缺陷統計度量區間。如果只是簡單的進行統計，那麼僅需要統計如上圖所示的三個指標即可。
如果需要更詳細的指標，則可以對這一完整的統計度量區間進行劃分。例如：單元測試階段，整合測試階段，系統測試階段，驗收灰度階段，線上運營階段。
單純的統計資料和度量其實比較簡單，一般來說如果在某個統計階段內，累計發現缺陷和累積解決缺陷的曲線接近一致，則說明缺陷收斂率資料較為良好。反之，則說明該階段的質量存在一定的風險。
理論上，累積發現缺陷和累積解決缺陷的曲線應該在完整的統計區間末期接近重合。但在實際工作場景中，這種情況很少見，畢竟影響質量的因素太多了，且總會存在不可控的因素，或者黑天鵝因素。
如何根據缺陷收斂率度量評估質量呢？我的思路是選擇某個版本作為對比基線，然後統計後續版本不同階段和統計區間的資料，進行同比和環比的對比。
當然，所有的質量度量和改進措施，在實際應用實踐中應該“量力而為”，因為質量本身就是有成本的。應該在有限的資源條件下提高質量，這也是質量保障和改進應該追求的目標。
之前看過一些分析文章和部分測試團隊的質量度量實踐案例，他們為了線上質量和系統穩定性，專門針對線上環境制定了度量指標，典型的如線上問題留存率(線上發現的缺陷留存時長，用來評估修復時效和對線上質量的重視程度)。
對此我只能感嘆，指標和資料真的被玩出花兒了。
最後，聊聊缺陷逃逸和缺陷收斂的關係。
缺陷逃逸率是階段性的質量結果，缺陷收斂是對質量進行控制和改進的目標，缺陷收斂率是評估質量控制和改進結果的度量指標。聽起來很拗口，簡單來說就是因為有逃逸，所以要進行收斂，並對收斂的結果進行評估。
其實無論是質量度量還是什麼，都只是解決問題達成目標的手段和工具。有度量指標，從度量結果開始分析如何改進，然後對改進過程和結果繼續進行度量分析改進，套娃般的迴圈往復。
度量指標真要玩起來，能定特別多的指標，但最為重要的是結合團隊痛點，真實的去最佳化改進，不斷提升產品交付質量。否則質量度量，最後只會成為KPI和向上管理的畫餅工具。