大型本地化軟件測試需要進行充分的測試準備,需要科學的測試流程管理。為了跟蹤和控制測試質量,便于管理測試發(fā)現(xiàn)的Bug,需要為每一個測試項目配置一個專用缺陷跟蹤數(shù)據(jù)庫,以便報告、查詢、分類、跟蹤、處理和驗證錯誤。
為了保證發(fā)現(xiàn)和報告的錯誤質量,需要首先由經(jīng)驗豐富的測試人員,在缺陷跟蹤數(shù)據(jù)庫中對新發(fā)現(xiàn)的錯誤進行確認,如果確實屬于錯誤,再由錯誤修復工程師進行修復處理。
1、軟件錯誤的狀態(tài)
新錯誤(New):測試中新報告的軟件缺陷。 更多新信息(New More Info):錯誤修復工程師認為報告的錯誤信息不完整,要求錯誤報告者添加更準確的錯誤信息。 打開 (Open):錯誤被確認并分配給相關錯誤修復工程師處理。 拒絕(Declined):拒絕修改缺陷。包括兩種情況: 拒絕-不是錯誤(Declined-Not Bug):報告的錯誤不術語錯誤。 拒絕-重復(Declined-Duplicated):以前已經(jīng)報告過這個錯誤,需要指出已經(jīng)報告過的錯誤標識編號。 修正(Fixed):錯誤修復工程師已完成修正,等待測試人員驗證。 重新打開(Reopen):沒有正確修復的錯誤,需要進一步修復。 延期(Deferred):不在當前版本修復的錯誤,以后的版本修復。包括兩種情況: 延期-下個版本(Deferred –Next Build):本項目的下一個新版本修復。 延期-下個主要版本(Deferred –Next Main Release):本項目不修復,本軟件下一個項目的版本修復。 關閉(Closed):錯誤已被修復。
2、Bug管理的一般流程
測試人員提交新的錯誤入庫,錯誤狀態(tài)為New。
高級測試人員驗證錯誤,如果是重復報告的錯誤,則設置為Declined-Duplicated狀態(tài),并指出與哪個已經(jīng)報個錯誤重復(注明標識編號ID#)。否則,如果確認是錯誤,分配給相應的修復工程師,設置狀態(tài)為Open。如果不是錯誤,則拒絕,設置為Declined-Not Bug狀態(tài)。
錯誤修復工程師查詢狀態(tài)為Open的錯誤,如果因為錯誤的信息不完全,沒法重現(xiàn)錯誤,則設置狀態(tài)為New More Info;如果不是錯誤,則設置狀態(tài)為Declined-Not Bug;如果是錯誤則修復,設置狀態(tài)為Fixed。對于當前版本不能解決,準備本項目的下一個新版本處理的錯誤,要留下處理注釋,設置錯誤為Deferred –Next Build狀態(tài)。如果只能在軟件的下個新項目才能解決,要留下處理注釋,設置錯誤為Deferred –Next Main Release狀態(tài)。
對于不能解決和延期解決的錯誤,不能由軟件修復工程師自己決定,一般要通過某種會議(評審會)通過才能認可。
測試人員查詢狀態(tài)為Fixed的錯誤,然后驗證錯誤是否已修復,如果已經(jīng)修復,設置錯誤的狀態(tài)為Closed,如沒有解決置狀態(tài)為Reopen。
下面以一個錯誤的處理過程為例,給出一般的處理流程圖。
為了保證錯誤的正確性,需要有豐富測試經(jīng)驗的測試人員驗證和確認發(fā)現(xiàn)的錯誤是否是真正的錯誤,測試步驟是否準確、簡潔、可以重復。 軟件錯誤的確認并不總是輕而易舉的事情。由于對軟件設計具體要求的不了解,對測試報告的個別軟件錯誤,可能無法確認是否屬于真正的軟件錯誤,本地化服務商需要與軟件供應商交流并確認。 每次對錯誤的處理都要保留處理信息,包括處理者姓名,時間,處理方法,處理步驟,錯誤狀態(tài),處理注釋等。 對錯誤的拒絕不能由程序員單方面決定,應該由項目經(jīng)理,測試經(jīng)理和設計經(jīng)理共同決定。 對錯誤延期處理不能由本地戶服務商決定,應該由軟件供應商決定。 錯誤修復后必須由報告錯誤的測試人員驗證后,確認已經(jīng)修復,才能關閉錯誤。
[1]
聯(lián)系客服