今天和大家一起聊一聊缺陷分級的重要性以及分級標準，良好的缺陷等級標準可以給我們帶來哪些好處呢？

1. 明確的缺陷分級標準可以在項目不同角色間對齊問題的嚴重程度，開發在解決問題時也會優先解決問題等級高的缺陷。

2. 我們通常使用千行代碼缺陷量來衡量開發質量，但千行代碼缺陷率統計并不方便，通常我們可以通缺陷量和嚴重問題占比來簡化開發質量度量。

3. 我們可以通過單位時間內（例如1月內）測試人員發現缺陷的數量和質量來評估測試人員的能力和工作飽和度。

   

既然缺陷等級這么重要，那么我們應該如何對缺陷分級呢？通常我們對缺陷進行5個等級劃分：

致命

這一等級問題包含程序異常崩潰，死循環和死鎖，軟件整體或部分核心功能不可用等。

這一級別問題出現時系統處于不可用狀態，應立即進行修復或回滾操作。

嚴重

系統不穩定，一般功能未實現或不正確，接口錯誤，數據庫慢查詢或消息隊列堆積等性能問題。

這一級別問題出現時系統處于不穩定狀態，系統服務異常但未完全宕機，若不及時處理則會造成更惡略的后果。

一般

兼容性問題以及數據異?；虿僮鳑]有達到預期效果，參數未充分校驗等。

這一級別問題通常不會對系統造成致命影響，但會影響用戶使用或需要手動修復后系統才能正常運行。

輕微

界面展示錯誤或提示不友好，一些概率性復現問題等。

這一級別問題通常會和產品一起評估是否需要修復以及修復方案。

建議

外觀和體驗性問題

這一級別問題可以同UI、UE一起評估，確定是否修復以及修復方案。

通常致命和嚴重缺陷未修復軟件系統不能發布，一般問題應在發布前全部修復完畢。輕微和建議性問題需要確認是否修或，明確修復的問題若未在發布前修復完畢需要給出明確的修復時間點或轉為線上問題，或轉為需求。