文/秋之川

【目錄】

第二十六章 軟件缺陷數據能夠告訴你什么？

今天，老大把我喊到辦公室叮囑我，“提測之后每天都要關注項目里的 bug，知道吧？”

我說，“我知道，我每天肯定會及時跟進 Open Bug 的修復進度和 Fixed Bug 的驗證進度的。”

他說，“不僅僅是這兩類的進度，從 bug 數據里能獲取到的項目信息還有很多，我跟你說說，你自己記一下，然后再好好想想。”

1. 根據每個需求模塊待修復缺陷和待驗證缺陷的數量變化，可以大致了解每個需求的測試進展；
2. 根據缺陷的分布模塊，可以分析出問題多發的模塊，以此來調整測試策略；
3. 根據每個人的有效缺陷數量，來觀察工作量的飽和度；
4. 根據截止到某個時間點的待修復缺陷數量，來判斷截止當下的產品質量；
5. 根據回歸性缺陷的數量和被多次激活的缺陷數量，來判斷開發的代碼質量，從而調整測試策略；
6. 如果 Fixed/已修復 的缺陷數量過高，就說明測試工程師沒有及時地做驗證，那就需要關注一下某個測試工程師的工作狀態了，或者看下測試流程是不是有問題。
7. 如果 Deferred/已推遲的缺陷數量過高，就需要檢查一下當前項目的計劃，是否在人力儲備和相關資源儲備上有不足之處，導致無法在當下解決。
8. 如果 OnHold/已掛起的缺陷數量過高，就需要安排相關的技術攻堅人員，去預研一下能否解決一些技術限制難題。
9. 如果 Designed/設計的缺陷數量過高，就說明需求評審做的不夠好，或者需求文檔還不夠細，導致很多開發和測試在認知上不一致的問題；
10. 如果 CannotDuplicate/不能復現、NeedMoreInfo/需要更多信息和 NotABug/不是缺陷的數量過高，就說明缺陷報告的質量不高，需要對測試工程師做一些注意事項和執行層面的培訓；

除了缺陷的不同狀態之外，我們還需要關注缺陷在某些狀態上的停留時長，比如：

1. 高優先級和嚴重的 Open/待修復的缺陷，如果停留時間超過2天，就需要過問一下 fix 進度了，是不是有技術難點需要支援，還是別的原因，導致 fix 延遲。
2. Fixed/已修復的缺陷如果停留時間過長，就需要過問一下，一直不能驗證的原因是什么，有什么 block issue 嗎？還是任務安排有問題。

最后，我們還需要明確缺陷狀態的變更規則和責任人，比如：

1. 任何類型的缺陷都只能被測試工程師關閉。
2. 變更缺陷的優先級和嚴重級別需要經過產品經理或項目經理的確認，并由測試工程師修改。
3. 將缺陷改為 OnHold 狀態，需要開發負責人或開發經理才能決定。

《告訴你如何從執行測試到管理測試》帶你邁出第（26）步！，點擊這里可查看完整地圖

作者簡介：14 年測試 + 11 年項目管理 + 11 年團隊管理 = 一個測試老兵

【目錄】