分五個等級，即p1~p5，p1的優先級別最高，之後逐級遞減。
問題優先順序
描述p1
應立即修復的問題
p2在產品發布之前必須修復的問題
p3如果時間允許應該修復的問題
p4可以在發布版本中存在的問題
p5建議
bug嚴重程度
描述響應時間
blocker
阻礙開發或測試工作，影響測試進度的問題
立即修復
critical
宕機的問題
立即修復
major
較大的功能缺陷
立即修復
normal
普通的功能缺陷
提交到下一版本前必須修復
minor
較輕的功能缺陷
有時間修復
trivial
介面及外觀問題
有時間修復
enhancement
建議以後版本中修復
新建狀態（ new）
bug建立後的初始狀態。
已分配狀態（open）
經過確認有效的問題後分配給開發人員的狀態。
拒絕狀態（rejected）
驗證不是有效的問題
解決狀態（fixed）
開發人員處理此問題後的狀態
結束狀態（closed）
經測試部門對修改後的軟體問題進行驗證並確認修改正確後的狀態。
重新開啟狀態（reopened）
對開發部門修改後軟體問題，經過驗證，如果仍然存在，則將其狀態改為「重新開啟」狀態。對於「關閉/延遲修改」狀態的軟體問題，如果時機成熟，需要重新開發，則將其狀態改為「重新開啟」狀態。
bug報告模板
id
bug的唯一標誌
標題簡明扼要地對bug進行概要描述
產品名稱
軟體產品的名稱
功能模組名
產品子系統
產品版本
測試環境
開發人員
測試人員
建立時間
bug狀態
前提條件
問題**，引起問題的前提條件
bug嚴重程度
問題優先順序
操作步驟
實際結果
期望結果
出現頻率
文字注釋和附圖
風險管理計畫中的BUG應對方案
bug就像軟體的影子一樣，其生命週期和軟體的生命週期同步持續進行。產品是想bug的，研發是寫bug的，測試是找bug的。在軟體開發這場戰役中，幾乎所有的專案人員都在不停的與bug做鬥爭，直到被打敗。在風險管理中，軟體產品的風險被認為是不可避免的，只能設定相對完全的應對方案來降低風險度。就是說，bug...
微軟Bug管理
一 團隊組織 1 常見問題 2 微軟團隊模型 各角色的職責 角色 職責 專案經理 編寫功能規範，協調各角色關係 產品經理 客戶聯絡的橋梁，進行需求分析 使用者教育 讓產品容易使用 發布經理 保證產品順利發布 二 專案管理 1 常見問題 2 微軟專案管理 多里程碑式流程 如何完成乙個里程碑 專家會診機...
bug管理規範
1 2 3 4級bug判定標準如下 1 緊急 致命錯誤，例如主程式不能正常執行，基本業務功能未實現，交易資料不準確或不一致，從而使得後續流程無法正常進行 作業系統崩潰 宕機 頻繁造成資料庫死鎖或資料丟失 造成交易資料不準確 收銀對賬不一致 使用者無法註冊 登陸 正常操作，從而無法進行無法正常使用 在...