1.NEW
測試人員將Bug提交給任務分發人員（研發模塊負責人），此時Bug狀態為NEW，開始Bug的生命周期，如果測試人員知道具體負責的研發人員，也可以直接指定，在Assign To項目中輸入具體負責的研發人員Email
2.ASSI
任務分發人員將Bug分發給指定研發人員時，將Bug置為ASSI狀態，解決Bug的工作開始
3.Ressigned
研發人員接收到Bug，經過分析，不屬于自己負責的范圍，如果知道誰應該負責，可以在Assigned To項目旁點擊edit，直接輸入被指定人的Email，將Bug轉移給其他研發人員，研發人員接收到Bug，經過分析，不屬于自己負責的范圍，如果不知道誰應該負責，將Bug退回給任務分發人員（Bugzllia沒有該狀態，列在此處，只為研發人員處理不屬于自己負責范圍的Bug提供參考）
4.RESO DUPL
研發人員接收分配給自己的Bug后，在當前項目的Bug List中查看該Bug是否與之前的Bug重復，若重復，將新Bug置為RESO DUPL狀態，并在Commnet中注明與哪個Bug重復（部分研發人員將舊Bug置為RESO DUPL是錯誤的）
5.RESO INVA
研發人員對于沒有重復的Bug進行修復，經過分析，如果Bug是因為在錯誤的環境下產生或由于錯誤操作導致或由于測試人員錯誤理解而產生，屬于無效Bug，將Bug置為RESO INVA狀態，并在Commnet中注明置為無效的原因
6.RESO LATE
研發人員對于沒有重復的有效Bug進行修復，經過分析，如果當前版本無法修復，但在以后項目中或條件成熟時會修復，將Bug置為RESO LATE狀態，并在Commnet中注明置為LATE的原因（部分研發人員將此類Bug誤置為RESO INVA是錯誤的）
7.RESO WONT
研發人員對于沒有重復的有效Bug進行修復，經過分析，不在產品需求范圍內，而且在可預見的未來內也不會提供該功能，將Bug置為RESO WONT狀態，并在Commnet中注明置為WONT的原因
8.RESO WORK
研發人員對于沒有重復的有效Bug進行修復，按照Bug的步驟，多次驗證，卻無法重現該Bug，需要測試人員再次發現該Bug時告知自己，以便查找原因時，將Bug置為RESO WORK狀態
9.RESO FIXE
研發人員對于沒有重復的有效Bug進行修復，發現了產生Bug的原因，經過修改代碼，能夠消除該Bug，將Bug置為RESO FIXE狀態，并在Commnet中注明問題的原因、修復的方法和將在哪個版本中修復，以便測試人員準確及時驗證（部分研發人員只注明修復了Bug，但沒有說明版本，或說明版本錯誤）
10.VERI FIXE
測試人員在處理RESO FIXE時，在指定的版本及以后的版本中進行驗證，如果發現該Bug已經不存在，將Bug置為VERI FIXE狀態，并在Commnet中注明驗證通過的版本
11.REOP
測試人員在處理RESO FIXE時，在指定的版本及以后的版本中進行驗證，如果發現該Bug仍存在，將Bug置為REOP狀態，并在Commnet中注明重現該Bug的版本，補充必要的信息，需要研發人員繼續查找原因，進一步修復Bug，測試人員在測試過程中，發現狀態為VERI FIXE的Bug重現了，將Bug置為REOP狀態，并在Commnet中注明重現該Bug的版本，補充必要的信息，需要研發人員繼續查找原因，進一步修復Bug，測試人員在測試過程中，發現狀態為CLOS的Bug重現了，操作同上
12.CLOS
測試人員在回歸測試時，再次驗證VERI FIXE狀態的Bug，如果該Bug仍未重現，將該Bug置為CLOS狀態，并在Commnet中注明后驗證的版本，至此Bug的生命周期結束，如果該項目后續版本中再出現該Bug時，需要REOP，以上的操作只在同一個項目中進行處理，不同項目的Bug不存在重復問題。測試人員在提交Bug時，如果希望其他人也了解Bug的進展，可以在CC項中輸入他們的Email，bug已經提交后，如果希望其他人也了解Bug的進展，可以在CC List項中點擊edit，添加他們的Email
