缺陷的集中性原則（Pareto原則）表明80%的錯誤集中在20%的程序模塊中，實際經驗也證明了這一點，通常情況下， 缺陷並不是平均而是集中分佈的，大多數的缺陷只是存在測試對象的極小部分。如果在一個模塊發現了很多缺陷，那麼通常在這個模塊中可以發現更多的缺陷。因此，測試過程中要注意缺陷集中現象，對發現缺陷較多的模塊 ，應進行反覆的深入的測試
軟件缺陷作為測試人員基本的測試產出，其價值僅僅體現在暴露影響當前產品質量的問題數量、嚴重程度？除此之外，我們還能夠通過缺陷挖掘哪些有價值的信息呢？
本文主要通過介紹缺陷分析的幾種度量方式，分享如何挖掘軟件缺陷數據的潛在價值的方法，推進測試策略的持續優化，進一步保障產品質量。
缺陷度量維度
模塊缺陷分佈統計（模塊缺陷密度）
- 缺陷所屬模塊分佈統計
- 各模塊缺陷的嚴重程度分佈統計
缺陷類型分佈統計
- 缺陷類型的分佈統計
- 缺陷引發原因的分類統計
缺陷解決/發現趨勢統計（Gompertz分析）
- 缺陷狀態（新建、關閉）的持續統計
缺陷發現方法分佈統計
- 缺陷發現方法的分佈統計
- 各測試方法所發現缺陷的嚴重程度分佈統計
接下來就其中幾種常用的分析維度做詳細的介紹，具體如下。
模塊缺陷分佈統計（模塊缺陷密度）
通過對各功能模塊的缺陷數量分佈進行統計，同時考慮缺陷嚴重程度分佈、缺陷類型分佈。客觀得出哪些模塊的缺陷佔比較高，參考Pareto原則及時調整測試策略。如下圖，C模塊缺陷數據和嚴重缺陷數量佔比都是最高的，結合需求優先級，調整C模塊的測試策略（人力投入、測試深度、測試廣度）。
模塊缺陷分佈圖
缺陷解決/發現趨勢統計（Gompertz分析）
首先我們先繪製缺陷趨勢分析圖 ，我們可以選擇以天為統計分析粒度，也可以選擇以周為統計分析粒度，這裡我們選擇以周為統計粒度進行說明，如下圖，繪製出累計發現缺陷數量與累計解決缺陷數量的趨勢圖。
xx項目曲線趨勢統計圖
- 累計發現缺陷數量：測試活動開始至今，測試團隊發現的缺陷總數。
- 累計解決缺陷數量：測試活動開始至今，經測試確認已經被修復了的缺陷總數。
缺陷趨勢曲線中的“凹凸性”
我們知道具備凹函數特性的曲線，是呈現遞增的變化趨勢。具備凸函數特性的曲線，呈現遞減的變化趨勢。凹函數與凸函數中間的連接點稱之為”拐點“，如下圖。
缺陷收斂的兩個必要條件
下面我們從缺陷的收斂角度來分析一下，解讀的缺陷曲線收斂程度背後的信息（需要注意的是，單獨就“測試發現缺陷趨勢”也可以從不同角度反映測試情況，這裡暫不說明）。判斷缺陷趨勢必要條件如下（兩者同時具備）：
- “累計發現的缺陷趨勢”為凸函數（遞減趨勢）。
- “累計發現的缺陷趨勢”和“累計解決的缺陷趨勢”兩條曲線逐漸靠近並且趨於一點。
如上圖“xx項目曲線趨勢統計圖”為缺陷收斂，曲線收斂說明當前繼續測試難以發現更多問題，並且缺陷也逐漸被修復完成，一般情況缺陷收斂可以作為當前測試階段的準出條件。
場景一：累計發現的缺陷趨勢為凹函數
如上圖，累計發現的缺陷趨勢曲線為凹函數，即使累計發現的缺陷曲線和累計解決的缺陷曲線逐漸趨於一點，但也不滿足曲線收斂的必要條件，此時繼續開展測試還能發現產品軟件較多的缺陷。
如果在測試策略不變（人力投入、測試深度、測試廣度不發生改變）的情況下，較長時間“累計發現的缺陷”趨勢未出現拐點，說明版本質量較差。基於此情況，我們可以考慮從如下幾個方面調整測試策略：
- 對缺陷進行分析，明確缺陷較多的模塊，結合缺陷的集中性原則考慮，根據需求優先級視情況調整各模塊的測試投入。
- 重視缺陷不斷修復帶來的代碼改動可能引入新問題的風險，加強相關模塊的迴歸測試，同時要求加強研發自測。
- 明確缺陷解決優先級(參考缺陷嚴重程度)，與研發進行確認缺陷解決順序。
場景二：累計發現的缺陷趨勢曲線與累計解決的缺陷趨勢曲線未出現靠近趨勢
如上圖，累計發現的缺陷趨勢為凸函數但兩條曲線未出現靠近趨勢，基於此情況可以從如下方面調整測試策略：
- 嚴格控制代碼改動，按照需求優先級、缺陷嚴重程度確定缺陷修復順序，如用戶感知度較低的輕微、中等缺陷建議暫不修復。
- 要求研發做好涉及改動的功能自測，避免出現因修復缺陷而引入新問題的現象。
缺陷類型分佈統計
這裡主要介紹一下缺陷引發原因類型分佈統計，通過整體缺陷引發原因進行追溯分析，可幫助團隊找出影響產品質量的主要因素，優化開發、測試策略，更好的保障後續產品版本質量。
- 需求文檔：需求分析文檔不清晰、不明確等原因引起。
- 需求分析：需求分析不充分等原因引起。
- 系統設計：軟件系統架構或設計等原因引起。
- 信息對等：信息不對等，開發成員間溝通不及時引起。
- 研發自測：未按要求進行代碼自測（致使出現明顯嚴重缺陷）原因引起。
- 程序編碼：軟件開發階段中編程錯誤引起。
- 修復引入：由於修改缺陷而引入的新缺陷（引發的缺陷與原變更相關）原因引起。
- 系統集成：依賴第三方服務、系統模塊異常等外部問題因素所引起。
- 測試漏測：由於測試分析、設計、覆蓋不充分等原因引發線上缺陷。
- 安裝部署：安裝部署時，系統環境檢查不充分、系統配置或安裝不當等所引起。
- 用戶體驗：用戶使用成本、學習成本高等交互體驗原因引起。
- 數據異常：由於數據異常或者數據覆蓋不充分等數據原因引起。
缺陷發現方法分佈統計
確定哪種缺陷發現方式有效，進而選擇合適的方法降低缺陷，需要從缺陷數量、缺陷嚴重程度、缺陷修復成本等角度考慮，調整相關測試策略（人力投入、測試深度、測試廣度）。
- 需求分析：通過需求分析、評審等方式發現問題。
- 功能測試：通過（手工）功能測試方式發現問題。
- 性能測試：通過性能測試、壓力測試、穩定性測試方式發現問題。
- 交互測試：通過用戶交互體驗測試、用戶行為分析方式發現問題。
- 數據測試：通過數據驅動測試方式發現問題。
- 質量運營：通過線上質量自動化運營方式發現問題。
若對你有所幫助，歡迎大家評論、留言。
閱讀更多 測試開發技術棧 的文章
