◎ Desription 中要詳細說明下列情況：
1 ） 發現問題的步驟
2 ） 執行上述步驟后出現的情況
3 ） 期望應出現的正確結果
◎關鍵字：單擊“關鍵字”三個字，會顯示管理員已經設定的關鍵字，選擇其一，便于以查詢。注意：此處不可以隨意添加，必須使用已經存在的關鍵字才好。另外，如果管理員沒有創建關鍵字的話，那么此項缺省。
◎依賴：直接輸入與當前 bug 有依賴關系的 bug 的編號。簡單地說，比如說這里輸入“ 3 ”，那么是說當前提交的 bug 有依賴關系，不是由于 3 導致了當前 bug ，是當前 bug 導致了 bug3 。
確認無誤后，“ commit”!
提交之后，系統會提示： bug 已經提交。在此頁面的下半部分，會再次顯示剛才提交的 bug 的詳細信息，你可以在這里進行修改，重新 commit， 也可以在此增加新的附件或是附加說明來進一步說明 bug 。
4、對于 Bug 的不同處理情況
4.1 Bug 的屬主 (owner) 處理問題，提出解決意見及方法。
給出解決方法并填寫附加說明（ Additional Comments ），還可創建附件（如：更改提交單）。
填表提示：
FIXED 描述的問題已經修改， 該 bug 已經修復并檢查過，源文件已經檢入 CVS 庫。
INVALID 描述的問題不是一個 bug ( 輸入錯誤后，通過此項來取消 )
WONTFIX 描述的問題將永遠不會被修復。
LATER 描述的問題將不會在產品的這個版本中解決。
DUPLICATE 描述的問題是一個存在的 bug 的復件。
WORKSFORME 所有要重新產生這個 bug 的企圖是無效的。如果有更多的信息出現，請重新分配這個 bug ，而現在只把它歸檔。
4.2 項目組長或開發者重新指定 Bug 的屬主。
① bug 不屬于自己的范圍，可置為 Assigned ， 等待測試人員重新指定。
② bug 不屬于自己的范圍，但知道誰應該負責，在 Reassign bug to 的輸入框中 直接輸入被指定人的 Email 。
③操作結果：此時 bug 狀態又變為 New ，此 bug 的 owner 變為被指定的人。
4.3 測試人員確認開發人員報告的 Bug 是否存在 .
查詢狀態為“ Unconfirmed" 的 Bug，
測試人員對開發人員提交的 Bug 進行確認，確認 Bug 存在。
具體操作：選中“ Confirm bug(change status to New)" 后，進行 commit.
操作結果：狀態變為“ New".
4.4 測試人員驗證已修改的 Bug
① 測試人員查詢開發者已修改的 bug ，即 Status 為 "Resolved"， Resolution 為 "Fixed". 進行重新測試。（可創建 test case 附件）
② 經驗證無誤后，修改 Resolution 為 VERIFIED 。待整個產品發布后，修改為 CLOSED 。
若測試之后發現還有問題， REOPENED ，狀態重新變為“ New" ，并發郵件通知。
5、查詢
登錄 Bugzilla 缺陷跟蹤系統后，點擊查詢，可以按照指定的一個或者多個查詢條件進行查詢。
◎摘要 (Summary) ： 下拉列表框選擇查詢規約。在其后的輸入框中輸入包含的信息，此信息的指定與提交bug時的注釋信息相一致。
◎ 產品 (Product) ：選擇所要查找的 bugs 所在的產品。
◎ 模塊 (Component) ：選擇 bugs 所在的模塊。
◎ 版本 (Version) ：選擇 bugs 版本。
◎注釋 (Comments) ：可在下拉列表框中選擇將要輸入的包含信息的規約，其后指定包含的信息。此信息的指定根據提交 bugs 時所填寫的描述信息。
◎ URL ： 指定關于 bugs 所在的 URL 。
◎關鍵字 (Keywords) ：指定包含或不包含該關鍵字的 bugs 。每個 bug 可以被指定關鍵字， bugs 報告人或者管理員可以編輯關鍵字。
◎ 狀態 (Status) ：選擇 bugs 狀態。
◎ 處理 (Resolution) ：選擇 bugs 處理的結果。
◎ 嚴重性 (Severity) ：選擇 bugs 的嚴重級別。
◎ 優先級 (Priority) ：選擇 bugs 的優先級別。
◎ 硬件 (Platform) ：選擇存在 bugs 程序運行的平臺。 ◎操作系統
