每當我們完成一個版本測試時，總會在測試報告中添加一些分析bug的名額 ，主要用于分析在測試過程中存在的問題 。但是在分析的過程中你就可能遇到如下的問題 ：
- 我應該分析那些名額呢 ？每一個具體的名額該如何分析 ？它能說明什麼問題 ？
你若想要答案 ，不妨從以下三個問題入手 ，能回答了以下的三個問題，答案就呼之欲出了 。
- 為什麼要進行bug分析 ？ 它對我們工作有什麼幫助 ？
- bug分析具體要分析什麼 ？ 即它有那些名額 ？
- 該如何進行bug分析 ，它們能說明什麼問題 ？
1.為什麼要進行bug分析 ？
通過bug分析，對我們測試工作有兩個好處：
- 通過bug分析 ，能發現在測試過程中存在的一些問題，這些問題主要産品品質和測試效率上的問題 。
- 通過長時間bug的分析 ，建立bug分析資料庫 ，進而在批量資料下找到規律，進而為後續版本測試提供一些可靠建議 。
bug分析發現問題
在測試過程中，最常見的一個bug分析名額就是 ，時間和bug數量的折線圖 。通過這個名額我們就可以看出bug是否收斂，進而判斷出項目是否已經穩定，進而決定能進行上線了 。那如果這個折線圖一直是上下抖動 ，說明目前産品品質還不穩定 ，需要再繼續測試 。
當然，通過一個名額是不能說明整個測試過程的問題的，需要将一些有效的名額都結合起來分析，才有可能得出比較可靠的結論 。
bug分析建立資料庫
偶然隻去分析一個版本，不足以去發現一些規律性的問題 ，而且也不容易積累經驗 。是以 ，我們将每一個版本的資料都要搜集起來，進行縱向比較，就會發現一些固定的影響因素 ，即長期潛在的問題 。如若它是相對固定的問題 ，你再拿着這些問題也同樣預測到後續版本也會出現這樣的問題 。 通常情況下，一旦此類型的問題被解決，改善效果就會很明顯 。最後就可以拿着這個名額去監控目前測試狀态是否健康 ，與預期的曲線相符合，說明測試狀态健康 ，反之就不健康 。
2.bug要分析什麼 ？ 具體它有那些名額 ？
在上面我們隻列出了一個名額 ？ 那麼一個疊代測試中，我們到底要分析哪些名額呢 ？第一是對産品品質評估的名額，即産品品質在測試過程中是否健康 ？ 是否已經達到上線标準 ，都需要通過這些名額檢視 。第二就是對工作效率的評估的名額 ，主要包括測試效率和開發效率 ，寫開發效率是因為它會影響到測試 。評估它們是否對測試進度産生影響 ，進而影響整個上線工期 。
- bug趨勢圖 ：就是上面的那個截圖 ，主要是檢視随着時間的推移，bug數量的變化 。通過此圖我們主要關注産品品質是否穩定，是否具備了上線條件 。
- bug修複情況 ：在最後一輪測試是否出現二級及以上bug ；必修bug是否已修複 。通過這兩個問題主要關注重點問題是否已被修複 ，不會導緻影響産品品質。
- bug修複和關閉的及時性 ：即bug修複的快慢速度 ，bug被關閉的快慢速度 。 這兩個及時性主要關注的是測試過程中流程執行的是否正常 ，是否因速度慢導緻品質或進度産生偏差。
- 用例執行和非用例測試産出bug比 ： 即通過用例發現的bug數和非用例發現的bug數的比率值 ，這個值一把是維持在一個固定的範圍值内 ，太高或太低都說明用例寫的有問題 或者 其它測試方法使用的有問題 。
- bug有效率 ：就是送出已修複的bug占總bug數的比率 ，通過這個比率我們來判斷測試人員的業務水準
- bug激活率 ： 就是通過回歸測試重新激活的bug占總bug的比率 ，通過這個比率我們來判斷開發人員的開發效率 。
3.該如何分析bug ？
具體名額知道了 ，在實際的版本測試中該如何進行分析呢 ？
bug趨勢圖分析 ：
該名額主要關注的是中間的波動和最後的收斂情況 。
曲線上升可能産生的原因有：合入或修改了新功能 ，使用了新方法 ，功能未完成一輪測試 ，随着業務的熟悉測試出前期遺漏的bug ；若曲線下降很可能是測試方法已經失效 ，功能已經完成一輪測試 。
最後的曲線一定要收斂才行 ，否則說明産品品質不穩定，不具備上線條件，考慮進行延期測試。
bug修複情況：
在探索式測試裡曾有這樣的說法 ，在最後回歸測試期間 ，要謹慎的測試(即不能随意的測試) 。如若這樣測試，還是在最後一輪測試中發現了一二級bug，那隻能說明前面的測試沒有做好 ，同時該bug也可能影響産品上線品質，因為它是最後期發現重要的bug的，不修改不行，修改的話又可能引入新的bug 。這也是為什麼我們要關注這個名額：'在最後一輪測試是否出現二級及以上bug' .
當然 ，我們也要關注主要bug是否在本次上線前已經修複 ，因為它影響産品品質 ，是以重點bug也要進行關注 。
bug修複和關閉的及時性：
一般bug被提出後1~2天能是應該被修複的 ，如若該時間拉長了 ，它不僅僅是延長了我們的修複時間，更主要的是它很有可能産生新bug而影響産品品質的穩定性 。
bug回歸的及時性也同樣如此 ，如若回歸的太晚 ，就可能會導緻回歸出新bug而導緻的産品後期不穩定。
用例執行和非用例測試産出bug比
此名額已經在‘如何進行測試用例的分析’一文有詳細說明，這裡不在贅述 。
bug有效率和bug激活率
bug有效率主要關注測試人員送出效率，如果這個值很低 ，說明測試人員對業務了解上有問題 ，或者了解能力比較差，亦或者是業務準備時間上不足 。同時如果這個值很低說明我們的測試效率也低 ，拉長整個改的生命周期 。
bug激活率主要關注的是開發人員修複效率 ，如果這個值很低 ，說明開發人員修複bug邏輯上有問題 ，或者技術水準存在問題 ，或者是态度可能有問題 。同時這個值很低也會影響測試和開發的配合效率，拉長整個改的生命周期 。