一篇文章講清楚如何對軟件缺陷進行管理(4)

模糊提交

測試環境

缺少必要的測試工具和設備。在一個比較大型的網站中，系統在正常負載情況下的性能非常重要，如果測試人員沒有一種有效的測試工具或者必要的硬件設備，那么就很難去模擬、再現系統負載的環境。

缺少必要的系統配置。如果是Java開發的程序，我們可能會在多種操作系統上去驗證它的正確性和穩定性。

缺少必要的測試用例。好的測試模型可以減少更多的BUG，也可以發現更多潛在的BUG。好的測試用例不僅僅是一系列測試方法的組合，它更大的用處在于和歷史積累BUG記錄的對比分析。

4、Bug的種類

需求階段的BUG——來源：

模糊不清的需求

忽略的需求

沖突的需求

分析、設計階段的BUG——來源：

忽略設計

混亂的設計 ：這樣的情況發生在兩種設計性質完全相反的情況中，如果在實際的系統中，某塊地址規定不允許被多線程訪問，而方案卻被設計成以多線程方式進行，則會在此層面上產生BUG，嚴重的會造成整個系統的崩潰。

模糊的設計：模糊BUG產生的原因在于設計人員對需求沒有清晰的認識，或者需求本身就是含糊不清的。

實現階段的BUG——來源：

遺漏的功能

內存溢出：屬于一種比較嚴重的軟件BUG類型。例如，軟件執行了某些強行向操作系統保護地址寫入數據的指令，導致整個環境的徹底崩潰；再如：數值除零導致堆棧溢出

其他實現：表現為出現的錯誤難以定位其類型，比如在產品化階段，測試人員或者最終用戶提出的部分提高程序運行效率的建議，當然開發人員并不完全處理這些問題，但是這些建議將成為一種特殊的BUG類型，被保留在項目數據庫中。

配置階段的BUG

配置階段的BUG是最危險的，往往體現在軟件交付或者最后的系統測試中。

配置階段的BUG出現的原因是復雜的，比較典型的是舊的代碼覆蓋了新的代碼；或者測試服務器上的代碼和實現人員本機最新代碼版本不一致。這些情況造成了錯誤代碼被修改后，經過一個時間段再次回歸測試時又會出現同樣的問題。

配置階段的BUG解決方案也很簡單，項目組可以指定專人（集成員）進行配置和集成管理，集成員保證正確集成整個系統，并將最新的代碼發布到測試服務器或者客戶服務器上。這個階段由QA（質量保證）部門負責監管和控制，規定集成的時間間隔和最佳集成時間，統一維護一份項目組集成人員和集成時間列表。

原文轉自：http://www.uml.org.cn/Test/201611161.asp