一個缺陷的生命周期簡單的可以分為三步:
1、測試人員登記一個缺陷。
2、開發人員閱讀缺陷,并作出處理結果。
3、測試人員進行驗證,決定關閉或者打開。
在這3個過程中,開發人員和測試人員更多的時候是靠文字溝通的。因為在實際工作中,一個項目所產生的缺陷往往不會很少(這是由軟件開發的特性所決定的,跟開發人員沒有必然的聯系),所以不可能對于每一個bug都面對面的溝通,所以說,測試人員和開發人員之間給對方提供充足的信息是測試開發高效進行的保證。
一、 測試人員登記缺陷:
QC中需要測試人員填寫的描述缺陷的字段主要有:摘要、嚴重程度、分配給、描述信息。
1、 摘要:部分最好簡單一些,簡明扼要的描述哪個地方出現了什么問題。比如:“無法登陸Sohu郵件系統”。
2、 描述:這個字段詳細解釋發生了什么問題及如何發生的。需要填寫的內容則包括:前置條件、測試數據、操作步驟、結果。比如說:“使用帳戶A和正確的密碼****,登陸郵件時提示密碼錯誤”。附加信息:把出錯時的詳細的問題表現,提供給開發人員更多的信息,很方便的找出問題所在。
總之,測試人員提交缺陷時,要根據開發人員的需求,提供更多、更有效的信息,提高開發人員定位bug的效率。
二、 開發人員處理缺陷。
開發人員處理缺陷的流程:
1. 閱讀缺陷:開發人員在接到測試人員報告的bug后,第一件要做的事情是仔細閱讀摘要和描述部分,確認自己理解了bug所描述的情況后,再決定是否做修改。還有一種情況測試人員的描述的有歧義或者根本不清楚,這時候開發人員可以在注釋中說明此情況(請注意此時不必修改bug的狀態),接著處理下面bug。把所有不清楚的bug列出來,當面跟測試人員溝通。
2. 重現缺陷:測試人員提出的bug都是在測試環境下發現的。而開發人員本地都有自己的一套測試環境,對于每個缺陷,開發人員都必須首先本地的測試環境中重現。如果無法重現,最有可能的問題是代碼不同步。如果可以重現,那么需要做的事情就是定位并修改了。
3. 處理缺陷:有三種結果 “已修復”、“不是問題”、“下一版本修復”。對于決定修改的bug,開發人員需要在本地測試通過后并保證本地編譯通過后修改bug的狀態為“已修復”;對于一些不影響用戶使用的bug,經過與PD、測試人員溝通后可以把狀態修改為“下一版本修復”;對于測試人員錯誤提交的bug,將其狀態修改為“不是問題”。這類bug是不會統計到項目的bug數中的。
原文轉自:http://www.anti-gravitydesign.com