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

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

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

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

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

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

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

　　因爲需求變動和 項目並行比較常見，又不可避免，所以目前咱們的測試流程儘量的控制不超過四輪系統測試，四輪的目標分別是：發現bug、驗證bug並響應變動、繼續驗證 Bug、穩定迴歸。若是在第三輪系統測試時，還出現大量嚴重bug，那說明多是以前的測試作的不到位，或者有新的變動，再或者開發修改缺陷帶來的成本太 高，確定是不正常的，也會對第四輪的迴歸帶來巨大風險。所以這個數字應該要控制在一個很低的水平。

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

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

　　四、第二輪、第三輪測試用例平均經過率

　　由於第二輪和第三輪的目標就是修復bug，因此若是第三輪結束的時候，嚴重bug所有被修復，而且第三輪沒有出現新的嚴重bug，那麼能夠說項 目的質量是很是穩定的。這裏斷定第二輪、第三輪用例經過與否的標準，就是看這兩輪測試結束時，若是有嚴重bug沒有關閉，那相關的測試用例就是 failed。此外，C、D級bug若是沒有關閉，除非有肯定的用例與之對應，不然不會影響用例的經過率。

　　五、測試工做量（人月） / 測試用例數

　　這個維度表明投入的測試資源是否充足，這裏的工做量，指的是從測試設計到測試執行的全部人月數。若是數字太低，說明測試資源緊張，沒法保證測試質量；若是太高，說明有可能測試效率低，測試負責人須要進行解釋。

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

　　bug 關閉時間，指bug從建立開始，到close爲止，通過的時間，要精確到小數點後1位。只有狀態是closed的bug，纔會計算關閉時間。平均關閉時間 的計算方法也很簡單，把全部closed嚴重bug求平均值便可。這個維度表明項目組解決bug的效率，若是時間太長，說明項目組對bug重視不夠，或者 開發組資源不足。

　　七、已修復Bug / Bug總數

　　這個維度表明測試人員所報Bug的整體修復率，若是修復率太低說明在測試過程當中對於項目的控制出現了問題，多是在測試過程當中產品變動過於頻繁，對變動的控制不合理，或者測試組對於項目的理解有誤差，項目經理和測試負責人須要給出解釋。

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

轉載請註明：http://www.spasvo.com/news/html/2013129100733.html