從軟件測試角度度量項目質量的7個維度

　　首先由于我自己是做測試的，因此這篇文章頁主要是從測試的角度出發，對幾個測試相關的維度進行分析，說明它們是如何影響項目質量的。這7個維度是根據以往做項目的經驗再加上網上一些前輩的總結提煉出來的，并非來自于教科書，所以僅供參考。這7個維度也只是從 功能測試 出發，對于性能測試、安全性測試、用戶體驗測試等并沒有過多的涉及，至于從這些方面如何去度量，以后再做討論。

　　首先，我們要明確幾個概念，就是“嚴重Bug”和“缺陷修復率”。這7個維度，有很多都和這兩個概念有關。“嚴重Bug”指的是在項目中，優先級為A和B的Bug。由于我們公司用的JIRA不像bugzilla/' target='_blank'>Bugzilla那樣，對Bug分為“嚴重程度”和“優先級”兩個維度，因此我們在報Bug時根據情況綜合這兩點的影響，統一以“優先級”來衡量Bug級別。A級Bug是指程序無法正常運行或者是測試無法正常進行；B級是指各個主要功能模塊出現用戶不可接受的錯誤。C級和D級大多也是一些功能方面的問題，還有一些用戶體驗易用性的問題，用戶可以接受少量這種類型的Bug。

　　好，下面開始討論這7個維度，我會說明計算方法，以及它們的戰略意義。

　　1、嚴重bug數 / 測試用例數

　　這個維度代表了一個項目的嚴重bug數量是否正常，讓測試用例參與計算，是為了平衡規模不同的項目的數據。

　　2、第三輪系統測試出現的嚴重bug數 / 嚴重bug總數

　　由于需求變更和項目并行比較常見，又不可避免，因此目前我們的測試流程盡可能的控制不超過四輪系統測試，四輪的目標分別是：發現bug、驗證bug并響應變更、繼續驗證Bug、穩定回歸。如果在第三輪系統測試時，還出現大量嚴重bug，那說明可能是之前的測試做的不到位，或者有新的變更，再或者開發修改缺陷帶來的成本太高，肯定是不正常的，也會對第四輪的回歸帶來巨大風險。因此這個數字應該要控制在一個很低的水平。

　　3、被重開的嚴重bug / 嚴重bug總數

　　重開指開發修復缺陷后，測試驗證不通過，或者是已經關閉的Bug又復發。這個維度也應該被控制在一個很低的水平，如果偏高，說明開發修復bug的效率偏低，代碼不穩定，發布后出現bug的幾率可能會增加。

　　4、第二輪、第三輪測試用例平均通過率

　　因為第二輪和第三輪的目標就是修復bug，所以如果第三輪結束的時候，嚴重bug全部被修復，并且第三輪沒有出現新的嚴重bug，那么可以說項目的質量是非常穩定的。這里判定第二輪、第三輪用例通過與否的標準，就是看這兩輪測試結束時，如果有嚴重bug沒有關閉，那相關的測試用例就是failed。此外，C、D級bug如果沒有關閉，除非有確定的用例與之對應，否則不會影響用例的通過率。

　　5、測試工作量（人月） / 測試用例數

　　這個維度代表投入的測試資源是否充足，這里的工作量，指的是從測試設計到測試執行的所有人月數。如果數字過低，說明測試資源緊張，無法保證測試質量；如果過高，說明有可能測試效率低，測試負責人需要進行解釋。

　　6、嚴重bug平均關閉時間（天）

　　bug 關閉時間，指bug從創建開始，到close為止，經過的時間，要精確到小數點后1位。只有狀態是closed的bug，才會計算關閉時間。平均關閉時間的計算方法也很簡單，把所有closed嚴重bug求平均值即可。這個維度代表項目組解決bug的效率，如果時間太長，說明項目組對bug重視不夠，或者開發組資源不足。

　　7、已修復Bug / Bug總數

　　這個維度代表測試人員所報Bug的總體修復率，如果修復率過低說明在測試過程中對于項目的控制出現了問題，可能是在測試過程中產品變更過于頻繁，對變更的控制不合理，或者測試組對于項目的理解有偏差，項目經理和測試負責人需要給出解釋。

　　其實要度量項目的質量，還有很多維度要考慮，比如需求文檔、設計方案、代碼等等，不過我們還是先在測試的范疇進行討論，歡迎大家對這些維度提改進建議，或者提出新的維度。

原文轉自：http://www.kjueaiud.com/ceshi/ruanjianzhiliangbaozheng/rjdl/2016/1214/208391.html