軟體測試的主要目的在於發現軟體存在的錯誤(bug)，對於如何處理測試中發現的錯誤，
將直接影響到測試的效果。只有正確、迅速、準確地處理這些錯誤，才能消除軟體錯誤，保證
要發布的軟體符合需求設計的目標。在實際軟體測試過程中，對於每個bug都要經過測試、確
認、修復、驗證等的管理過程，這是軟體測試的重要環節。
錯誤跟蹤管理系統
為了正確跟蹤每個軟體錯誤的處理過程，通常將軟體測試發現的每個錯誤作為一條條記錄
輸入制定的錯誤跟蹤管理系統。
目前已有的缺陷跟蹤管理軟體包括compuware公司的trackrecord軟體（商業軟體）、
mozilla公司的buzilla軟體（免費軟體），以及國內的微創公司的bms軟體，這些軟體在功能
上各有特點，可以根據實際情況選用。當然，也可以自己開發缺陷跟蹤軟體，例如基於notes
或是clearquese開發缺陷跟蹤管理軟體。
作為乙個缺陷跟蹤管理系統，需要正確設計每個錯誤的包含資訊的字段內容和記錄錯誤的
處理資訊的全部內容。字段內容可能包括測試軟體名稱，測試版本號，測試人名稱，測試事
件，測試軟體和硬體配置環境，發現軟體錯誤的型別，錯誤的嚴重等級，詳細步驟，必要的附
圖，測試注釋。處理資訊包括處理者姓名，處理時間，處理步驟，錯誤記錄的當前狀態。
正確的資料庫許可權管理是錯誤跟蹤管理系統的重要考慮要素，一般要保證對於新增的錯誤
不能從資料庫中刪除。
軟體錯誤的狀態
新資訊(new)：測試中新報告的軟體缺陷；
開啟 (open)：被確認並分配給相關開發人員處理；
修正(fixed)：開發人員已完成修正，等待測試人員驗證；
拒絕(declined):拒絕修改缺陷；
延期(deferred): 不在當前版本修復的錯誤，下一版修復
關閉(closed)：錯誤已被修復；
bug管理的一般流程
測試人員提交新的bug入庫，錯誤狀態為new。
高階測試人員驗證錯誤，如果確認是錯誤，分配給相應的開發人員，設定狀態為open。如
果不是錯誤，則拒絕，設定為declined狀態。
開發人員查詢狀態為open的bug，如果不是錯誤，則置狀態為declined；如果是bug則修復
並置狀態為fixed。不能解決的bug，要留下文字說明及保持bug為open狀態。
對於不能解決和延期解決的bug，不能由開發人員自己決定，一般要通過某種會議（評審
會）通過才能認可。
測試人員查詢狀態為fixed的bug，然後驗證bug是否已解決，如解決置bug的狀態為
closed，如沒有解決置狀態為reopen。
軟體錯誤流程管理要點
為了保證錯誤的正確性，需要有豐富測試經驗的測試人員驗證發現的錯誤是否是真正的錯
誤，書寫的測試步驟是否準確，可以重複。
每次對錯誤的處理都要保留處理資訊，包括處理姓名，時間，處理方法，處理意見，bug
狀態。拒絕或延期錯誤不能由程式設計師單方面決定，應該由專案經理，測試經理和設計經理共同決
定。錯誤修復後必須由報告錯誤的測試人員驗證後，確認已經修復，才能關閉錯誤。
加強測試人員與程式設計師的交流，對於某些不能重複的錯誤，可以請測試人員補充詳細的測
試步驟和方法，以及必要的測試用例。
Bug管理的一般流程
軟體bug的狀態 新資訊 new 測試中新報告的軟體缺陷 開啟 open 被確認並分配給相關開發人員處理 修正 fixed 開發人員已修正，等待測試人員驗證 拒絕 declined 拒絕修改缺陷 延期 deferred 不在當前版本修復的錯誤，下一版修復 關閉 closed 錯誤已被修復 bug管理...
Bug管理的一般流程
軟體測試的主要目的在於發現軟體存在的錯誤 bug 對於如何處理測試中發現的錯誤，將直接影響到測試的效果。只有正確 迅速 準確地處理這些錯誤，才能消除軟體錯誤，保證 要發布的軟體符合需求設計的目標。在實際軟體測試過程中，對於每個bug都要經過測試 確 認 修復 驗證等的管理過程，這是軟體測試的重要環節...
Bug管理的一般流程
測試人員提交新的bug入庫，錯誤狀態為new。高階測試人員驗證錯誤，如果確認是錯誤，分配給相應的開發人員，設定狀態為open。如果不是錯誤，則拒絕，設定為declined 拒絕 狀態。開發人員查詢狀態為open的bug，如果不是錯誤，則置狀態為declined 如果是bug則修復並置狀態為fixed...