測試人員查詢開發(fā)者已修改的bug,進(jìn)行重新測試。(可創(chuàng)建test case附件)
A. 經(jīng)驗證無誤后,修改狀態(tài)為VERIFIED。待整個產(chǎn)品發(fā)布后,修改為CLOSED。
B. 還有問題,REOPENED,狀態(tài)重新變?yōu)?ldquo;New",并發(fā)郵件通知。
如果這個BUG一周內(nèi)一直沒被處理過。Bugzilla會一直用E-Mail騷擾它的屬主,直到采取行動為止。
2.3 一個Bug的生存周期圖示:
2.4 測試人員報告Bug的流程:
請先進(jìn)行查詢,確認(rèn)要提交的bug報告不會在原有紀(jì)錄中存在,若已經(jīng)存在,不要提交,若有什么建議,可在原有紀(jì)錄中增加注釋,告知其屬主,讓bug的屬主看到這個后自己去修改。
若Bug不存在,創(chuàng)建一份有效的bug報告后進(jìn)行提交。
具體操作:點擊【新建】,選擇產(chǎn)品后,填寫一個Bug報告的表格。填表注意:【指派給】為空則默認(rèn)為設(shè)定的owner, 也可手工制定!境汀靠蔀槎嗳,需用逗號隔開!久枋觥恐幸敿(xì)說明下列情況:
A. 發(fā)現(xiàn)問題的步驟;
B. 執(zhí)行上述步驟后出現(xiàn)的情況;
C. 期望應(yīng)出現(xiàn)的正確結(jié)果。
【平臺】、【操作系統(tǒng)】、【優(yōu)先級】、【嚴(yán)重級】,可以根據(jù)具體情況自行選擇。
【依賴】是指與這個新Bug有關(guān)聯(lián)的Bug號碼。
【Blocks】不太清楚J
填寫完畢之后,點擊【Commit】提交,發(fā)送郵件通知給相關(guān)人員。
2.5 Bug的不同處理狀態(tài)解釋:
Bug的屬主(owner)確認(rèn)并接受這個Bug,然后給出解決方法,并填寫【附加說明】,還可以【建立新的附件】(如:更改提交單)等等。
開發(fā)人員可以調(diào)整的Bug狀態(tài)如下:
A. FIXED => 描述的問題已經(jīng)修改;
B. INVALID => 描述的問題不是一個bug (輸入錯誤后,通過此項來取消);
C. WONTFIX => 描述的問題將永遠(yuǎn)不會被修復(fù);
D. LATER => 描述的問題將不會在產(chǎn)品的這個版本中解決;
E. DUPLICATE => 描述的問題是一個存在的bug的復(fù)件;
F. WORKSFORME => 所有要重新產(chǎn)生這個bug的企圖是無效的。如果有更多的信息出現(xiàn),請重新分配這個bug,而現(xiàn)在只把它歸檔。
測試人員收到Bug的修改通知之后,還可以做如下的調(diào)整:
A. Leave as RESOLVED FIXED => 保持FIXED狀態(tài)不變;
B. Reopen bug => 這個bug還有問題,重新打開;
C. Mark bug as VERIFIED => 這個bug確實被正確修改了;
D. Mark bug as CLOSED => 產(chǎn)品已經(jīng)發(fā)布,將這個bug關(guān)閉。
2.6 關(guān)于權(quán)限的說明:
組內(nèi)成員對bug具有查詢的權(quán)利,但不能進(jìn)行修改。
Bug的owner 和 reporter 具有修改的權(quán)利。
具有特殊權(quán)限的用戶具有修改的權(quán)利。