2.2 Bug的處理流程概述：
測試人員或開發人員發現bug后，判斷屬于哪個模塊的問題，填寫bug報告后，通過Email通知項目組長或直接通知開發者。
項目組長根據具體情況，重新reassigned分配給bug所屬的開發者。
開發者收到E-Mail信息后，判斷是否為自己的修改范圍。
A. 若不是，重新reassigned分配給項目組長或應該分配的開發者；
B. 若是，進行處理，resolved并給出解決方法。（可創建補丁附件及補充說明）；
測試人員查詢開發者已修改的bug，進行重新測試。（可創建test case附件）
A. 經驗證無誤后，修改狀態為VERIFIED。待整個產品發布后，修改為CLOSED。
B. 還有問題，REOPENED，狀態重新變為“New"，并發郵件通知。
如果這個BUG一周內一直沒被處理過。Bugzilla會一直用E-Mail騷擾它的屬主，直到采取行動為止。
2.3 一個Bug的生存周期圖示：
2.4 測試人員報告Bug的流程：
請先進行查詢，確認要提交的bug報告不會在原有紀錄中存在，若已經存在，不要提交，若有什么建議，可在原有紀錄中增加注釋，告知其屬主，讓bug的屬主看到這個后自己去修改。
若Bug不存在，創建一份有效的bug報告后進行提交。
具體操作：點擊【新建】，選擇產品后，填寫一個Bug報告的表格。填表注意：【指派給】為空則默認為設定的owner，也可手工制定。【抄送】可為多人，需用逗號隔開。【描述】中要詳細說明下列情況：
A. 發現問題的步驟；
B. 執行上述步驟后出現的情況；
C. 期望應出現的正確結果。
【平臺】、【操作系統】、【優先級】、【嚴重級】，可以根據具體情況自行選擇。
【依賴】是指與這個新Bug有關聯的Bug號碼。
【Blocks】不太清楚J
填寫完畢之后，點擊【Commit】提交，發送郵件通知給相關人員。
2.5 Bug的不同處理狀態解釋：
Bug的屬主(owner)確認并接受這個Bug，然后給出解決方法，并填寫【附加說明】，還可以【建立新的附件】（如：更改提交單）等等。
開發人員可以調整的Bug狀態如下：
A. FIXED => 描述的問題已經修改；
B. INVALID => 描述的問題不是一個bug (輸入錯誤后，通過此項來取消)；
C. WONTFIX => 描述的問題將永遠不會被修復；
D. LATER => 描述的問題將不會在產品的這個版本中解決；
E. DUPLICATE => 描述的問題是一個存在的bug的復件；
F. WORKSFORME => 所有要重新產生這個bug的企圖是無效的。如果有更多的信息出現，請重新分配這個bug，而現在只把它歸檔。
測試人員收到Bug的修改通知之后，還可以做如下的調整：
A. Leave asRESOLVED FIXED => 保持FIXED狀態不變；
B. Reopen bug => 這個bug還有問題，重新打開；
C. Mark bug asVERIFIED => 這個bug確實被正確修改了；
D. Mark bug asCLOSED => 產品已經發布，將這個bug關閉。
2.6 關于權限的說明：
組內成員對bug具有查詢的權利，但不能進行修改。
Bug的owner和reporter具有修改的權利。
具有特殊權限的用戶具有修改的權利。
另：有關Bugzilla的安裝請訪問下面的連接：
http://www.csdn.net/Develop/read_article.asp?id=24088
http://www.csdn.net/Develop/read_article.asp?id=24091
http://www.csdn.net/Develop/read_article.asp?id=24092
