狀態
描述備註
active
測試人員發現bug並提交，待修改狀態。
bug初始狀態
resolved
開發人員修改完bug，bug變更為已解決狀態。
bug中間態
closed
測試人員回歸通過，變更為已通過狀態。
bug完成態
postpone
經確認不需要在本次發布範圍之內修改，變更為推遲修改狀態/掛起狀態。
bug中間態
rejected
開發人員確認不是bug，變更為非bug狀態。
bug中間態
obsolete
重複和非bug的，經過測試人員確認後，變更為廢棄狀態。
bug完成態
bug提報原則
bug提報格式
經辦人epic link
sprint
bug狀態
bug優先順序
release to
bug資訊填寫規範
測試資料：提供測試資料，以便開發人員可以重現問題。
截圖/日誌：有截圖提供截圖，有日誌提供日誌，截圖和日誌可以幫助開發人員花較少的時間來定位問題。
問題分析：測試人員通過抓包、日誌、檢查資料庫等工具和手段來初步定位出問題，主要目的是幫助開發人員快速定位出問題。（實際情況下，測試人員一方面要培養自己定位問題的能力，另一方面也要合理安排自己的測試進度，避免出現死磕乙個問題，而影響整體測試進度的情況。）
報告人：bug提出人
經辦人：開發物件
bug優先順序（嚴重等級）：
bug優先順序（嚴重等級）
描述緊急程度
致命p1
阻塞測試、引起系統崩潰、其他功能不可用和造成資料丟失等缺陷；
緊急，需要立即解決
嚴重p2
主要功能未實現、未達標、不可用，可能還會引起其他部分功能失效；
緊急，盡快解決
一般p3
一般的缺陷，不影響主要功能和流程的實現；
一般提示p4
優化建議，最好修改，但不是必須的，不影響上線發布。
不緊急bug狀態：
bug狀態
描述active
測試人員發現bug並提交，待修改狀態。
resolved
開發人員修改完bug，bug變更為已解決狀態，可驗證。
closed
測試人員回歸通過，變更為已通過狀態。
obsoleted
重複和非bug的，經過測試人員確認後，變更為廢棄狀態。
sprint：當前的迭代資訊。
epic：專案有epic時，關聯相應的epic，方便統計。
release to：沒有epic時，關聯story，方便統計。
bug的解決時效根據優先順序來跟蹤。
bug的狀態需要及時更新。
原則上，有未解決的bug不能發版，需要經過專案經理、開發測試leader和產品一起評估後，才能決定是否將bug掛起。
掛起的bug要在迭代結束後確認好解決版本，並修改相應資訊。
bug管理規範
1 2 3 4級bug判定標準如下 1 緊急 致命錯誤，例如主程式不能正常執行，基本業務功能未實現，交易資料不準確或不一致，從而使得後續流程無法正常進行 作業系統崩潰 宕機 頻繁造成資料庫死鎖或資料丟失 造成交易資料不準確 收銀對賬不一致 使用者無法註冊 登陸 正常操作，從而無法進行無法正常使用 在...
缺陷管理規範 bug 型別
bug型別劃分 bug型別 內容說明 備註 功能缺陷 1.程式功能無法實現 2.程式功能實現錯誤 介面缺陷 1.操作介面錯誤 2.列印內容，格式錯誤 3.刪除操作未給出提示 4.長時間操作未給出提示 5.介面不規範 系統缺陷 1.由於程式引起的司機，非法退出 2.程式死迴圈 3.程式錯誤，不能執行正...
bug規範初稿
一 背景 bug是開發和測試質量的重要指標，從bug數量 嚴重性等可以看出rd的開發質量，從發現問題的階段可以看出qa的測試意識和測試質量，從問題分類 問題 等可以看出產品開發 測試質量的一些固有模式，幫助rd和qa提公升開發和測試質量。總之窺一斑而見全豹，因此統計和分析bug十分有必要。各端都將b...