軟件
質量的量化評估，最重要的一點是經驗。同時科能需要大量統計工作作為鋪墊。
下面我主要從bug統計來說一下我的經驗。
1。測試項目數和摘出bug數預測 一般來說我們可以根據軟件代碼行數來粗略估計一個產品可能包含的bug數目和需要的測試項目。
現在有些公司流行每千行bug數的標準來制定
測試計劃，這個標準是通過以往測試經驗總結出來的，
一般來說，同類的產品，尤其是同一個
開發流程的產品，這些數值不應該相差太多，
如果相差一個數量級以上，我們幾乎可以說，要么是QA出問題了，要么是開發出問題了。
2。測試bug分級 使用
bugzilla或者Jira之類的
缺陷管理系統何以很容易的實現bug分級，一般至少有
Fatal, Major, Minor, cosmatic這幾種，還有一種特殊的叫做blocker，意思是這個bug
會影響測試進度。產品發布前，可以根據實際情況，定一個界限級別，比如要求
新出Major為0，并且所有已有的Major全部close。
3。測試bug收斂 量化評估必不可少的是bug收斂，這個要通過統計每日新出bug并跟蹤已有bug
制作收斂曲線來實現。收斂曲線的形狀發散表明目前產品極其不穩定，收斂曲線
開始收斂表示目前產品趨于穩定，完全收斂之后可以認為是發布的時機。
4。測試bug分布 bug分布是決定下面測試重點的一個重要的參考數據。首先還是需要統計，
找出所有已有的不同級別的bug在各個模塊的分布，假如ABC三個模塊，
A模塊占了bug的60%，C模塊占了bug的8%那么，我們可以得出這樣的結論，
軟件的不穩定瓶頸在于A模塊，是一個薄弱點，需要開發人員集中力量對應。
但是C模塊也是一個可疑模塊，因為出現bug率太低，如果不是開發的太好
就是
測試方法不當。
5。測試bug的周期 一個bug的生命歷程是一個完整的輪回，從他出生(open)開始，到調查(Accept)
到修復(Fix)，再到確認(Verify)是最簡單的路線，這個周期越短，說明項目進展越順利
反之則意味著項目進度目前有很大的阻礙。
6。降級bug數 降級bug的多少對于軟件質量評估也是一個重要參考標準，降級bug也就是由于修正一個bug
又作了一個新bug，降級bug數目過多意味著現在的產品在越修越壞。
一個新的QA團隊，在2，3，4，5，6步驟可能會有所迷惑，不知道閾值應該怎樣選
但如果每次都堅持這樣做，很多次之后2，3，4，5，6會給這個團隊大量的經驗積累，
完全可以做到看著統計圖估計出一個產品處于什么狀態，需要加強哪些方面等等。
