通常表現為:主流程無法跑通，系統無法執行，崩潰或嚴重資源不足，應用模組無法啟動或異常退出，主要功能模組無法使用。

比如：1.記憶體洩漏；2.嚴重的數值計算錯誤；3.系統容易崩潰；4.功能設計與需求嚴重不符；5.系統無法登陸；6.迴圈報錯，無法正常退出。

嚴重（二級bug）

通常表現為：影響系統功能或操作，主要功能存在嚴重缺陷，但不會影響到系統穩定性。

比如：1. 功能未實現；2.功能存在報錯；3.數值輕微的計算錯誤。

一般（三級bug）

通常表現為：介面、效能缺陷。

比如：1.邊界條件下錯誤；2.容錯性不好；3.大資料下容易無響應；4.大資料操作時，沒有提供進度條。

提示（四級bug）

通常表現為：易用性及建議性問題

比如：1.介面顏色搭配不好；2.文字排列不整齊；3.出現錯別字，但是不影響功能；4.介面格式不規範。

缺陷管理流程說明

　　1、測試人員填寫bug並提交給開發組長，Bug的狀態為New；

　　2、開發組長次日工作前對bug確認是否有效。有效的bug，狀態變化為open，並分配給開發人員；bug無效或者延期修改的，將bug狀態變化為Rejected，同時也在comment中註明原因。

　　3、開發人員上班的第一件事情是檢視自己有幾個bug需要修改。

　　4、開發人員修改bug，修改完成並進行單元測試後，將bug的狀態變為fixed，在comment中說明修改方法；

　　5、測試人員每天檢視自己提交的bug的狀態變化，應該成為每個測試人員的例行行為；

　　6、當bug的狀態變為fixed時，測試人員開啟該bug，開始對該bug進行迴歸測試；

　　7、如果該bug迴歸測試通過，則狀態變為closed。否則bug的狀態變為reopen（必須說明reopen、closed狀態變化原因或者操作過程）；

　　8、如果迴歸測試通過，可是修改的同時又引入新的bug，則重新提交bug，狀態為new。如果需要的時候註明相關聯的bug號；

　　9、只有當所有的bug狀態為closed，才可釋出版本。

　　注：每當bug狀態改變後，必須給出相應的註釋和說明，以便檢視bug生命週期的變化情況。

new-open(rejected)-fixed(reopen)-closed