背景說明
爲了減少開發、測試在Bug上花費不必要的溝通成本，同時爲迭代總結會提供報告依據，督促開發提升質量意識，制定以下規範內容。
相關職責
|
角色 |
職責 |
|
測試人員 |
1. 根據規範提交bug； 2. 及時驗證bug是否已解決； 3. 及時關注開發拒絕bug，和相關人員溝通討論解決方式； |
|
測試負責人 |
1. 審覈測試工程師提交的bug； 2. 定期review bug，報告現狀，並給出解決意見； |
|
開發人員 |
1. 以優先級爲依據分析解決bug |
|
開發負責人 |
1. 定期 review bug，對bug多的模塊加強code review和單元測試； 2. 分析bug解決進度，對產品質量及進度進行風險評估； |
|
產品 |
1、當開發和測試存在意見分歧時，進行需求確認 2、從產品角度劃分bug修改的優先級； |
測試負責人定期發送測試統計報告（每週或每迭代一次，需要包含BUG數量、BUG趨勢圖、提測質次數等）。
提交規範
爲了開發同學能迅速定位並儘快修復問題，測試同學需要儘量提供全面、精準的Bug描述信息。測試人員應初步定位BUG，能給開發提供修改建議。提交BUG時用清晰的語言寫明以下內容。
BUG提交地址目前已經統一到禪道系統。
|
角色 |
職責 |
|
標題 |
1. BUG簡潔描述。 2. 如果沒有指明模塊選項，標題需要帶上模塊名。 3. 能讓開發一眼就能明白問題現象和可能原因。 |
|
重要等級 |
1. 參考重要等級說明，此項是分析項目質量的重要依據，爲必填項。 |
|
優先級 |
1. 根據允許的修復時長來排優先級，此項爲必填項。 |
|
復現步驟 |
1. 此處寫明操作步驟，可以結合視頻、截圖來提高描述清晰度。 2. 如果在特定賬戶、請求數據下才能復現，需要寫明使用的賬戶，請求數據。 |
|
結果 |
|
|
預期 |
寫明正確的結果。避免測試、開發理解有偏差。 |
BUG嚴重程度
致命：導致系統無法正常工作的bug。系統崩潰、數據丟失、數據毀壞、非法退出、內存溢出，500錯誤等。
嚴重：對系統功能影響較大的bug。比如錯誤結果、遺漏功能、數據丟失等。
一般：表現爲實現不符合需求/設計，但對系統而言影響一般的bug。
輕微：小問題、UI錯誤，文案提示，不影響功能，代碼規範。
優先級與修復時長
緊急（P1）：致命類BUG，需要立即修復，修復時長<4小時。
高（P2）：嚴重類BUG，當天修復。
中（P3）：非主流程類的重要問題，產品發佈前修復。
低（P4）：針對輕微類型BUG，可選修復。
解決方案說明
已解決：當開發人員修復問題後，本着對問題負責的態度，儘可能用清晰的語言描述問題原因，解決方案，對肯能引起類似BUG的地方，以註釋的方式，提醒相關測試人員。
不予解決：測試建議性需求或者體驗性需求，都應該作爲這個狀態處理；並建議測試人員與產品等需求方進行溝通。
延期解決：延期解決的問題，並不是最終的狀態，需要持續關注，最後開發負責人或產品進行排期處理。
無法重現：當開發人員遇到不能復現的bug時，首先跟測試人員進行溝通，溝通後仍不能復現的情況，儘可能描述相關過程，然後將該bug置爲無法重現。
BUG定位
https://blog.csdn.net/kaka1121/article/details/51538979?locationNum=2&fps=1