測(cè)試人員查詢開發(fā)者已修改的bug，進(jìn)行重新測(cè)試。(可創(chuàng)建test case附件)

　　A. 經(jīng)驗(yàn)證無誤后，修改狀態(tài)為VERIFIED。待整個(gè)產(chǎn)品發(fā)布后，修改為CLOSED。

　　B. 還有問題，REOPENED，狀態(tài)重新變?yōu)?ldquo;New"，并發(fā)郵件通知。

　　如果這個(gè)BUG一周內(nèi)一直沒被處理過。Bugzilla會(huì)一直用E-Mail騷擾它的屬主，直到采取行動(dòng)為止。

　　2.3 一個(gè)Bug的生存周期圖示：

　　2.4 測(cè)試人員報(bào)告Bug的流程：

　　請(qǐng)先進(jìn)行查詢，確認(rèn)要提交的bug報(bào)告不會(huì)在原有紀(jì)錄中存在，若已經(jīng)存在，不要提交，若有什么建議，可在原有紀(jì)錄中增加注釋，告知其屬主，讓bug的屬主看到這個(gè)后自己去修改。

　　若Bug不存在，創(chuàng)建一份有效的bug報(bào)告后進(jìn)行提交。

　　具體操作：點(diǎn)擊【新建】，選擇產(chǎn)品后，填寫一個(gè)Bug報(bào)告的表格。填表注意：【指派給】為空則默認(rèn)為設(shè)定的owner， 也可手工制定。【抄送】可為多人，需用逗號(hào)隔開。【描述】中要詳細(xì)說明下列情況：

　　A. 發(fā)現(xiàn)問題的步驟;

　　B. 執(zhí)行上述步驟后出現(xiàn)的情況;

　　C. 期望應(yīng)出現(xiàn)的正確結(jié)果。

　　【平臺(tái)】、【操作系統(tǒng)】、【優(yōu)先級(jí)】、【嚴(yán)重級(jí)】，可以根據(jù)具體情況自行選擇。

　　【依賴】是指與這個(gè)新Bug有關(guān)聯(lián)的Bug號(hào)碼。

　　【Blocks】不太清楚J

　　填寫完畢之后，點(diǎn)擊【Commit】提交，發(fā)送郵件通知給相關(guān)人員。

　　2.5 Bug的不同處理狀態(tài)解釋：

　　Bug的屬主(owner)確認(rèn)并接受這個(gè)Bug，然后給出解決方法，并填寫【附加說明】，還可以【建立新的附件】(如：更改提交單)等等。

　　開發(fā)人員可以調(diào)整的Bug狀態(tài)如下：

　　A. FIXED => 描述的問題已經(jīng)修改;

　　B. INVALID => 描述的問題不是一個(gè)bug (輸入錯(cuò)誤后，通過此項(xiàng)來取消);

　　C. WONTFIX => 描述的問題將永遠(yuǎn)不會(huì)被修復(fù);

　　D. LATER => 描述的問題將不會(huì)在產(chǎn)品的這個(gè)版本中解決;

　　E. DUPLICATE => 描述的問題是一個(gè)存在的bug的復(fù)件;

　　F. WORKSFORME => 所有要重新產(chǎn)生這個(gè)bug的企圖是無效的。如果有更多的信息出現(xiàn)，請(qǐng)重新分配這個(gè)bug，而現(xiàn)在只把它歸檔。

　　測(cè)試人員收到Bug的修改通知之后，還可以做如下的調(diào)整：

　　A. Leave as RESOLVED FIXED => 保持FIXED狀態(tài)不變;

　　B. Reopen bug => 這個(gè)bug還有問題，重新打開;

　　C. Mark bug as VERIFIED => 這個(gè)bug確實(shí)被正確修改了;

　　D. Mark bug as CLOSED => 產(chǎn)品已經(jīng)發(fā)布，將這個(gè)bug關(guān)閉。

　　2.6 關(guān)于權(quán)限的說明：

　　組內(nèi)成員對(duì)bug具有查詢的權(quán)利，但不能進(jìn)行修改。

　　Bug的owner 和 reporter 具有修改的權(quán)利。

　　具有特殊權(quán)限的用戶具有修改的權(quán)利。