發布后bug的數量和嚴重性，是評估軟件質量、測試工作質量的重要依據。
鄭州軟件開發！
我們首先需要對遺漏bug的原因進行分類分析。遺漏bug的原因分為兩個方面：一是引起bug的根本原因，二是bug遺漏的原因。我們分別說明一下這兩個方面的分類。
首先是bug的根本原因（Root Cause），這指的是在軟件開發過程中，是哪個過程引起了bug，通常的分類有：
需求分析
設計（還可以細分為數據庫設計、頁面設計等等）
編碼
部署（例如數據庫升級）
其他
這里沒有“測試”，原因是測試這個過程一般是不會引起bug，如果有的測試人員引起了bug，那一般是測試人員參與了其他的過程。
總之，這樣的分類方法是按照開發過程為標準，我們還可以根據實際情況添加一些別的分類。
第二種原因是“遺漏”的原因，這指的是為什么在發布前，測試人員沒有把bug找出來，這和缺陷的根本原因是完全不同的。其實遺漏的原因我們可以歸結于：測試沒有覆蓋相應的用例。我們分類的依據是：為什么沒有覆蓋。基本的分類有：
測試遺漏
測試用例未設計
測試用例被裁減
測試環境不同
其他
下面我們說明一下這幾個分類的不同。測試遺漏指的是測試用例已經設計好了，也確定要執行，但是測試人員因為粗心等原因，沒有執行用例，這是一個比較嚴重的失誤。測試用例未設計指測試人員根本沒有考慮到，應該這樣測試，通常是因為經驗不足，或者對系統不了解等技術問題；測試用例被裁減指測試用例已經設計好，但是由于時間、人手等資源不足，不得不選擇放棄執行一部分用例，這樣選擇必然會面臨一定的風險，這在日常的測試中比較普遍。測試環境指在測試環境中沒問題，但是在生產環境里有，原因是測試環境沒有完全模擬生產環境。
按照這些分類進行統計，只是第一步，我們還可以把數量比較多的類型再進行細分，從而發現bug的深層原因，指導我們的過程改進。在這個基礎上，我們還需要分析每個bug的詳細原因，豐富我們的知識庫。
