Bug的生命週期中有很多個狀態，下面我就為大家比較細緻的羅列出一個Bug從它被建立到關閉的過程：

1.首先當測試人員接到一個專案或產品準備測試的時候，測試人員會根據測試用例一步步的來執行用例進行簡單的功能測試。當測出一個Bug的時候，就是這個Bug被開始建立的狀態(也就是被新建New)；

2.當一個Bug出現，測試人員會將這個Bug遞交給開發人員，讓開發人員進行修復，這個時候Bug的生命週期就進入到了被指派的狀態(Assigned)；

3.當開發人員將這個Bug接到手之後會認證它到底是不是一個Bug，此時Bug就進入到被開啟的狀態(Open)，這個時候也表示開發人員可能正在修復此缺陷；

4.當此Bug已經被開發人員修復成功之後，Bug就會進入到另一個狀態就是已被修復的( Fixed)，這個時候開發人員又將此Bug交還給了測試經理然後再由測試經理分配給負責它的測試人員；

5.Bug再次回到測試人員的手裡(測試嘛，專職的活就是找Bug和測Bug...)這個時候他還會將這個Bug再測一遍，那此時Bug就進入到了待被測試的狀態(Pending Reset)；

6.測試人員正在測試這個已經被開發人員修復過一次的Bug，Bug的狀態又進入到了再測試的狀態(Reset)；

7.經過測試人員的第二輪測試確認此Bug已被修復，這時Bug就進入到了接近尾聲要被關閉的狀態了(Closed)；

8.那如果測試人員經過第二次測試發現缺陷依舊存在，那就會重新把Bug遞交給開發人員讓開發人員繼續修復。此時Bug進入到重新被開啟的狀態(Reopen)；

9.當將這個Bug再次傳遞給開發人員的時候(他也會納悶兒，我這個Bug明明已經修復好了啊，怎麼又給我讓我修復呢，我拒絕！或者說開發人員認為這並不是個Bug時)，開發人員可以拒絕接受此Bug，此時Bug又進入到正在被拒絕中的狀態(Pending Reject)；

10.經過開發團隊開會討論或者與產品經理交流溝通後發現這確實不是個Bug，或者說這與產品說明書上寫的保持一致，那專案經理就會把此Bug設為已被拒絕的狀態(Rejected)；

11.有的時候一些比較特殊或者要考慮到很多因素的Bug，又或者說是比較小的但不影響正常功能實現的Bug就會被開發人員設定為延期的(Postponed)。

注：如果是比較全面的劃分，Bug生命週期就是以上的11個！

Bug等級由高到低依次分為：致命Bug、嚴重Bug、一般嚴重Bug、低階Bug和建議性的Bug。

致命的Bug：不能完全滿足系統要求，系統停止執行，系統的重要部件無法執行，系統崩潰或者掛起等導致系統不能正常執行。

嚴重的Bug：嚴重地影響系統要求或基本功能的實現，且沒有更正辦法（重新安裝或重新啟動該軟體不屬於更正辦法）。使系統不穩定、或破壞資料、或產生錯誤結果，或部分功能無法執行，而且是常規操作中經常發生或非常規操作中不可避免的主要問題，系統無法滿足主要的業務需求，效能、功能或可用性嚴重降低。

一般嚴重的Bug：系統可以滿足業務需求，系統性能或響應時間變慢、產生錯誤的中間結果但不影響最終結果等影響有限的問題。

低階的Bug：使操作者不方便或操作麻煩，但它不影響執行工作功能或重要功能。介面拼寫錯誤或使用者使用不方便等小問題或需要完善的問題。

建議性的Bug：希望提出的建議以及建議進行但不強制進行的修改。不會給釋出的準確性或可用性帶來任何嚴重影響。