1 概述
本文檔定義bug的整個生命周期，規範bug的解決方案及管理流程。Bug在流轉的過程中有章可循。 規範bug嚴重等級與bug解決優先級，使開發人員與測試人員能根據此文檔準确判斷bug的嚴重程度并加以解決；
2 關鍵角色及職責
3 Bug生命周期
4 Bug書寫規範
4.1 主題
1) 以一個簡短的句子描述某個子產品存在的問題；或者某個操作導緻了什麼問題；
2) 描述問題時要簡練、直接切入主題，但是要抓住要點；
3) 偶現bug在主題前标注出現的次數；
4) 有些子產品功能比較多，可以在主題描述前标注上具體得操作；
示例：
【偶現3次】【賬号切換】登入非本機手機号，切換回本機号碼登入後，收不到消息
【偶現2次】添加載體庫時程式停止運作
4.2描述
說明區域包括：步驟、預計結果、實際結果、測試環境、bug出現時間、截圖、日志
1) 用數字編号，一步步的描述問題的重制步驟；
2) 不同的操作步驟産生不同的問題，需分别報bug；盡量做到一個bug彙報一個問題；
3) 偶現問題必須明确bug出現的時間、提供截圖以及日志；
5 Bug解決方案
當天送出的建立狀态bug，對應的開發人員需在2天内全部稽核一遍，将bug分成以下3類：拒絕、進行中、延期、回報（給産品）；
開發已修複的bug：将bug狀态置為已解決；同時添加說明驗證版本号、錯誤原因、解決辦法；
示例：
驗證版本：V1.0.1.1101（1101表示在11月1号可以驗證）
問題原因：未作條件判斷
解決方法：進行合理邊界判斷
開發認為不是bug：将bug狀态置為已拒絕；指派給bug提出者；同時注明拒絕理由；
示例：
參考XXX設計，測試人員了解錯誤；
bug缺乏必要的資訊：将bug狀态置為已拒絕；指派給bug提出者；同時注明拒絕理由；
示例：
缺少必須日志；
開發已修複，測試驗證通過的bug：将bug狀态置為已解決，并注明通過版本号；
示例：
V1.0.1.1103驗證通過
開發已修複，測試驗證不通過的bug：将bug狀态置為打回，并根據實際情況注明回報理由；
示例：
V1.0.1.1103版本驗證此問題仍然存在；
步驟：XXX
出現時間：XXX
測試環境：XXX
截圖、日志；
測試、開發有争議的bug：将跟蹤類别置為需求，狀态置為回報；指派給對應産品，進行讨論确認修改方案；并注明回報理由；
示例：
測試認為ip位址設定錯誤，應該提示使用者，而不應該程式出現停止運作；
無法修複的bug：将bug狀态修改為公認，并注明公認理由；
無法重制的bug：主要依賴日志分析問題原因，然後進行對應的修改；開發修改後，測試追溯3個版本、或者使用測試工具反複測試，如沒有重制則先關閉；并注明關閉版本号；
示例：
V1.0.1.1103暫未複現，先關閉；
需延期的bug：将bug狀态修改為低，計劃完成日期修改為計劃解決bug的日期；并注明延期理由；
示例：
需求變更，改動量很大，影響版本釋出時間；
産品确認需要修改的bug：将bug狀态修改為打回，指派給對應的開發人員，并注明修改内容；
産品确認不需要修改的bug：将bug狀态修改為已解決，并注明不需要修改原因；
不是本端的bug：由bug所在端（本端）人員給出分析說明，轉給對應端和開發人員，并口頭通知；
6 Bug跟蹤類别
bug：測試人員判定為bug的問題；
優化：功能已實作，需要做性能優化的問題；
建議：測試對于産品的一些改進建議；
需求：需要産品重新梳理的需求問題；
7 Bug狀态
建立：測試人員新送出的bug、優化或者建議的問題狀态；
進行中：開發人員已确認是bug，需要修改的問題狀态；
已解決：開發人員已修複的問題狀态；
已關閉：測試驗證，确定已解決的問題狀态；
已拒絕：開發認為不是bug，拒絕給測試的問題狀态；
回報：回報給産品确認的問題狀态；
公認：确認是bug，但是無法解決的問題狀态；
打回：測試驗證已解決bug，仍然沒有修複的問題狀态；
8 Bug嚴重程度
緻命：不能執行正常的功能操作，或者因産品原因導緻系統當機，需馬上修複的問題
示例：
程式無法啟動，或者登入；
程式崩潰、停止運作，系統當機，無法進行下一步的操作
嚴重：部分功能存在嚴重缺陷，尚可繼續測試，不影響産品穩定性；
示例：
偶現的程式崩潰、停止運作
功能未實作
資料不同步
功能錯誤，無法進行後續操作
一般：次要功能或者界面存在的一些錯誤，不影響正常測試；
示例：
界面UI顯示和效果圖不一緻；
提示語不正确；
錯别字；
查詢結果顯示錯誤
建議：測試對于産品的一些改進建議；
9 Bug優先級
低：對産品的影響比較小，在時間不允許的情況下可以暫時不修改；
中：必須修改，不一定馬上修改，需讨論确定在某個特定的裡程碑前修改完；
高：必須在版本釋出之前修改完；
緊急：影響測試，需立即或者下一個版本修複；
10 其他注意事項
1) 開發人員沒有關閉bug的權限，所有問題均需經過測試驗證無誤後才可關閉；
2) 開發、測試雙方有争議的bug，必須經過産品的确認才可進行下一步的操作；
3) 測試需及時驗證已修複bug；
4) 産品人員可以根據産品的階段性需求重新配置設定bug解決的優先級；
5) 重新指派bug後，需要口頭或者QQ告知對方；
6) bug的優先級劃分比較重要；