一、划分一個bug的等級
bug等級主要分為致命、嚴重、一般、輕微或者建議四個等級；
1.致命錯誤：系統無法執行、崩潰或嚴重資源不足、應用模塊無法啟動或異常退出、無法測試、造成系統不穩定、價值較高功能異常（比如與金錢相關的功能）
具體基本上可分為：
（1）嚴重花屏
（2）內存泄漏
（3）安全問題
（4）用戶權限問題
（5）網頁無法正常打開
（6）嚴重的數值計算錯誤
（7）功能設計與需求嚴重不符
（8）系統崩潰/死機/凍結/死循環
（9）模塊無法啟動、調用或異常退出
（10）數據庫數據丟失或破壞、數據庫連接錯誤、發生死鎖
（11）重要的一級菜單功能不能使用、無法登錄、無法正常退出，程序重啟、自動退出， 關聯程序間調用沖突
2.嚴重錯誤：影響系統功能或操作，主要功能存在嚴重缺陷，但不會影響到系統穩定性
具體基本上可分為：
（1）功能未實現
（2）系統刷新錯誤
（3）數值計算錯誤
（4）語音或數據通訊錯誤
（5）功能錯誤、主要功能喪失、基本模塊缺失
（6）系統所提供的功能或服務受明顯的影響（接口錯誤）
3.一般錯誤：界面、性能缺陷
具體基本上可分為：
（1）操作界面錯誤（包括數據窗口內列名定義、含義是否一致）
（2）邊界條件下錯誤
（3）提示信息錯誤（包括未給出信息、信息提示錯誤等）
（4）長時間操作無進度提示（如導出功能）
（5）系統未優化（性能問題）
（6）光標跳轉設置不好，鼠標（光標）定位錯誤
（7）涉及系統以及用戶隱私數據沒有處理或者隱藏（如密碼沒有隱藏化）
（8）代碼在頁面顯示出來
4、輕微錯誤（建議性問題）：易用性
具體基本上可分為：
（1）界面格式等不規范
（2）頁面顯示重疊
（3）輔助說明描述不清楚
（4）功能描述不清楚
（5）操作時未給用戶提示（如修改成功、刪除成功、添加成功、加載中等）
（6）可輸入區域和只讀區域沒有明顯的區分標志（一般只讀區域顏色設置較暗）
（7）個別不影響產品理解的錯別字
（8）文字排列不整齊等一些小問題
（9）輸入框沒有限制字符數、符號等約束條件（如電話號碼字段只能輸入純數字、姓名限制字符數為3-4位、身份證號碼嚴格標准化約束）
二、bug狀態
1.待處理：測試人員或者用戶發現並待確認的問題
2.已確認：經測試人員及開發人員討論后確認是BUG，並提交到缺陷管理系統（如禪道）
3.已解決：開發人員修復BUG，待測試人員驗證
4.已驗證：測試人員驗證問題通過
5.再激活：經測試，BUG未修復成功
6.重復出現：上一個版本修復的BUG，這個版本又出現
7.設計如此：與開發人員和產品溝通后，確認不是BUG，或者建議，但是開發人員不采納
8.暫不處理：當前版本不修改，后續版本再考慮（與開發人員確定修改日期）
三、處理bug流程
四、bug權重分配
1.一些測試leader對TE工作評估的主要依據，發現的bug數，如果僅僅是bug數並不科學，因為根據bug等級的划分，有些bug甚至沒有經確認或者重復，甚至有可能出現濫竽充數的現象也說不定。
2.如果按照bug等級划分來分配權重的話，明顯更加科學；
| BUG等級 | 權重 |
| 致命 | 2 |
| 嚴重 | 1 |
| 一般 | 0.5 |
| 輕微/建議 | 0.25 |
例如，我發現了2個致命的bug，4個提示的bug，3個建議的bug，最后的成績=2*2+4*0.5+3*0.25
3.個人覺得，一些致命的bug或者是嚴重的bug（比如：一些影響到測試工作的bug等），相對比較容易發現，這些都是不具思考性的錯誤，為什么？因為發現這些問題，不用問，必須改的bug？難道不是這樣嗎？在測試日常中最難處理反而是一些建議性問題，往往更具有思考性，比如說用戶需求沒有說明，但是我覺得做了更能體現出用戶體驗的易用性，然而需求文檔上沒有，那就不是必須要做的，開發可以選擇不做，這樣開發和測試就有了爭議了，那就捅到產品那里去吧。。。對於一些建議性問題往往是花費更多的時間的。
| BUG等級 | 權重 |
| 致命 | 0.25 |
| 嚴重 | 0.5 |
| 一般 | 1 |
| 輕微/建議 | 2 |
注意：如果產品比較成熟的話第三種比較合適，如果產品還停留在開發基本功能的情況下第二種相對比較符合。