軟件質(zhì)量的量化評估，最重要的一點是經(jīng)驗。同時科能需要大量統(tǒng)計工作作為鋪墊。

　　下面我主要從bug統(tǒng)計來說一下我的經(jīng)驗。

　　1 測試項目數(shù)和摘出bug數(shù)預測

　　一般來說我們可以根據(jù)軟件代碼行數(shù)來粗略估計一個產(chǎn)品可能包含的bug數(shù)目和需要的測試項目。現(xiàn)在有些公司流行每千行bug數(shù)的標準來制定測試計劃，這個標準是通過以往測試經(jīng)驗總結(jié)出來的，

　　一般來說，同類的產(chǎn)品，尤其是同一個開發(fā)流程的產(chǎn)品，這些數(shù)值不應該相差太多，如果相差一個數(shù)量級以上，我們幾乎可以說，要么是QA出問題了，要么是開發(fā)出問題了。

　　2 測試bug分級

　　使用bugzilla或者Jira之類的缺陷管理系統(tǒng)何以很容易的實現(xiàn)bug分級，一般至少有Fatal, Major, Minor, cosmatic這幾種，還有一種特殊的叫做blocker，意思是這個bug會影響測試進度。產(chǎn)品發(fā)布前，可以根據(jù)實際情況，定一個界限級別，比如要求新出Major為0，并且所有已有的Major全部close。

　　3 測試bug收斂

　　量化評估必不可少的是bug收斂，這個要通過統(tǒng)計每日新出bug并跟蹤已有bug制作收斂曲線來實現(xiàn)。收斂曲線的形狀發(fā)散表明目前產(chǎn)品極其不穩(wěn)定，收斂曲線開始收斂表示目前產(chǎn)品趨于穩(wěn)定，完全收斂之后可以認為是發(fā)布的時機。

　　4 測試bug分布

　　bug分布是決定下面測試重點的一個重要的參考數(shù)據(jù)。首先還是需要統(tǒng)計，找出所有已有的不同級別的bug在各個模塊的分布，假如ABC三個模塊，A模塊占了bug的60%，C模塊占了bug的8%那么，我們可以得出這樣的結(jié)論，軟件的不穩(wěn)定瓶頸在于A模塊，是一個薄弱點，需要開發(fā)人員集中力量對應。但是C模塊也是一個可疑模塊，因為出現(xiàn)bug率太低，如果不是開發(fā)的太好就是測試方法不當。

　　5 測試bug的周期

　　一個bug的生命歷程是一個完整的輪回，從他出生(open)開始，到調(diào)查(Accept)到修復(Fix)，再到確認(Verify)是最簡單的路線，這個周期越短，說明項目進展越順利反之則意味著項目進度目前有很大的阻礙。

　　6 降級bug數(shù)

　　降級bug的多少對于軟件質(zhì)量評估也是一個重要參考標準，降級bug也就是由于修正一個bug又作了一個新bug，降級bug數(shù)目過多意味著現(xiàn)在的產(chǎn)品在越修越壞。一個新的QA團隊，在2，3，4，5，6步驟可能會有所迷惑，不知道閾值應該怎樣選但如果每次都堅持這樣做，很多次之后2，3，4，5，6會給這個團隊大量的經(jīng)驗積累，完全可以做到看著統(tǒng)計圖估計出一個產(chǎn)品處于什么狀態(tài)，需要加強哪些方面等等。