軟件錯誤跟蹤處理流程

　　大型本地化軟件測試需要進行充分的測試準備，需要科學的測試流程管理。為了跟蹤和控制測試質量，便于管理測試發現的Bug，需要為每一個測試項目配置一個專用缺陷跟蹤數據庫，以便報告、查詢、分類、跟蹤、處理和驗證錯誤。

　　為了保證發現和報告的錯誤質量，需要首先由經驗豐富的測試人員，在缺陷跟蹤數據庫中對新發現的錯誤進行確認，如果確實屬于錯誤，再由錯誤修復工程師進行修復處理。

　　1、軟件錯誤的狀態

　　新錯誤(New)：測試中新報告的軟件缺陷。 更多新信息(New More Info)：錯誤修復工程師認為報告的錯誤信息不完整，要求錯誤報告者添加更準確的錯誤信息。 打開 (Open)：錯誤被確認并分配給相關錯誤修復工程師處理。 拒絕(Declined)：拒絕修改缺陷。包括兩種情況： 拒絕-不是錯誤(Declined-Not Bug)：報告的錯誤不術語錯誤。 拒絕-重復(Declined-Duplicated)：以前已經報告過這個錯誤，需要指出已經報告過的錯誤標識編號。 修正(Fixed)：錯誤修復工程師已完成修正，等待測試人員驗證。 重新打開(Reopen)：沒有正確修復的錯誤，需要進一步修復。 延期(Deferred)：不在當前版本修復的錯誤，以后的版本修復。包括兩種情況： 延期-下個版本(Deferred –Next Build)：本項目的下一個新版本修復。 延期-下個主要版本(Deferred –Next Main Release)：本項目不修復，本軟件下一個項目的版本修復。 關閉(Closed)：錯誤已被修復。

　　2、Bug管理的一般流程

　　測試人員提交新的錯誤入庫，錯誤狀態為New。

　　高級測試人員驗證錯誤，如果是重復報告的錯誤，則設置為Declined- Duplicated狀態，并指出與哪個已經報個錯誤重復(注明標識編號ID#)。否則，如果確認是錯誤，分配給相應的修復工程師，設置狀態為Open。如果不是錯誤，則拒絕，設置為Declined-Not Bug狀態。

　　錯誤修復工程師查詢狀態為Open的錯誤，如果因為錯誤的信息不完全，沒法重現錯誤，則設置狀態為New More Info;如果不是錯誤，則設置狀態為Declined-Not Bug;如果是錯誤則修復，設置狀態為Fixed。對于當前版本不能解決，準備本項目的下一個新版本處理的錯誤，要留下處理注釋，設置錯誤為Deferred –Next Build狀態。如果只能在軟件的下個新項目才能解決，要留下處理注釋，設置錯誤為Deferred –Next Main Release狀態。

　　對于不能解決和延期解決的錯誤，不能由軟件修復工程師自己決定，一般要通過某種會議(評審會)通過才能認可。

　　測試人員查詢狀態為Fixed的錯誤，然后驗證錯誤是否已修復，如果已經修復，設置錯誤的狀態為Closed，如沒有解決置狀態為Reopen。

　　下面以一個錯誤的處理過程為例，給出一般的處理流程圖。

　　3、軟件錯誤流程管理要點

　　為了保證錯誤的正確性，需要有豐富測試經驗的測試人員驗證和確認發現的錯誤是否是真正的錯誤，測試步驟是否準確、簡潔、可以重復。 軟件錯誤的確認并不總是輕而易舉的事情。由于對軟件設計具體要求的不了解，對測試報告的個別軟件錯誤，可能無法確認是否屬于真正的軟件錯誤，本地化服務商需要與軟件供應商交流并確認。 每次對錯誤的處理都要保留處理信息，包括處理者姓名，時間，處理方法，處理步驟，錯誤狀態，處理注釋等。 對錯誤的拒絕不能由程序員單方面決定，應該由項目經理，測試經理和設計經理共同決定。 對錯誤延期處理不能由本地戶服務商決定，應該由軟件供應商決定。 錯誤修復后必須由報告錯誤的測試人員驗證后，確認已經修復，才能關閉錯誤。

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