管理規(guī)范及流程

1、bug管理規(guī)范及流程1、概述本文檔定義bug的整個生命周期，規(guī)范bug的解決方案及管理流程。Bug在流轉的過程中有章可循。 規(guī)范bug嚴重等級與bug解決優(yōu)先級，使開發(fā)人員與測試人員能根據此文檔準確判斷bug的嚴重程度并加以解決；2、關鍵角色及職責角色職責測試工程師1. 根據規(guī)范提交bug；2. 及時驗證bug是否已解決；3. 及時關注開發(fā)拒絕bug，和相關人員溝通討論解決方式；測試經理1. 審核測試工程師提交的bug；2. 定期review bug，報告現(xiàn)狀，并給出解決意見；開發(fā)工程師1. 以優(yōu)先級為依據分析解決bug開發(fā)主管1. 定期 review bug，對bug多的模塊加強c

2、ode review和單元測試；2. 分析bug解決進度，對產品質量及進度進行風險評估；產品1、當開發(fā)和測試存在意見分歧時，進行需求確認2、從產品角度劃分bug修改的優(yōu)先級；   3、Bug生命周期4、Bug書寫規(guī)范4.1 BUG標題1) 以一個簡短的句子描述某個模塊存在的問題；或者某個操作導致了什么問題；2) 描述問題時要簡練、直接切入主題，但是要抓住要點；3) 偶現(xiàn)bug在主題前標注出現(xiàn)的次數；4) 有些模塊功能比較多，可以在主題描述前標注上具體得操作；示例：【偶現(xiàn)3次】【賬號切換】登錄非本機手機號，切換回本機號碼登錄后，收不到消息【偶現(xiàn)2次】添加載

3、體庫時程序停止運行4.2重現(xiàn)步驟說明區(qū)域包括：步驟、預計結果、實際結果、測試環(huán)境、bug出現(xiàn)時間、截圖、日志1)   用數字編號，一步步的描述問題的重現(xiàn)步驟；2)   不同的操作步驟產生不同的問題，需分別報bug；盡量做到一個bug匯報一個問題；3)   偶現(xiàn)問題必須明確bug出現(xiàn)的時間、提供截圖以及日志；5、Bug解決方案當天提交的新建狀態(tài)bug，對應的開發(fā)人員需在2天內全部審核一遍，將bug分成以下3類：拒絕、進行中、延期、反饋（給產品）；開發(fā)已修復的bug：將bug狀態(tài)置為已解決；同時添加說明驗證版本號、錯誤原因、解決辦法；示例

4、：驗證版本：V1.0.1.1101（1101表示在11月1號可以驗證）問題原因：未作條件判斷解決方法：進行合理邊界判斷開發(fā)認為不是bug：將bug狀態(tài)置為已拒絕；指派給bug提出者；同時注明拒絕理由；示例：參考XXX設計，測試人員理解錯誤；bug缺乏必要的信息，無法重現(xiàn)：將bug狀態(tài)置為已拒絕（無法重現(xiàn)）；指派給bug提出者；同時注明拒絕理由；示例：缺少必須日志；開發(fā)已修復，測試驗證通過的bug：將bug狀態(tài)置為關閉，并注明通過版本號；示例：V1.0.1.1103驗證通過開發(fā)已修復，測試驗證不通過的bug：將bug狀態(tài)置為打回（激活），并根據實際情況注明反饋理由；示例：  

5、   V1.0.1.1103版本驗證此問題仍然存在；     步驟：XXX     出現(xiàn)時間：XXX     測試環(huán)境：XXX     截圖、日志；測試、開發(fā)有爭議的bug：指派給對應產品經理，進行討論確認修改方案；由產品經理編輯bug狀態(tài)為激活/不予處理/轉為需求，并注明理由。示例：     測試認為ip地址設置錯誤，應該提示用戶，而不應該程序出現(xiàn)停止運行；無法修復的bug：

6、將bug狀態(tài)修改為公認(外部原因/不予解決)，并注明公認理由；無法重現(xiàn)的bug：主要依賴日志分析問題原因，然后進行對應的修改；開發(fā)修改后，測試追溯3個版本、或者使用測試工具反復測試，如沒有重現(xiàn)則先關閉；并注明關閉版本號；示例：     V1.0.1.1103暫未復現(xiàn)，先關閉；需延期的bug：將bug狀態(tài)修改為低，計劃完成日期修改為計劃解決bug的日期；并注明延期理由；示例：     需求變更，改動量很大，影響版本發(fā)布時間；產品確認需要修改的bug：將bug狀態(tài)修改為打回，指派給對應的開發(fā)人員，并注明修改內容；產品確

7、認不需要修改的bug：將bug狀態(tài)修改為已解決，并注明不需要修改原因；不是本端的bug：由bug所在端（本端）人員給出分析說明，轉給對應端和開發(fā)人員，并口頭通知；6、Bug跟蹤類別bug：測試人員判定為bug的問題；優(yōu)化：功能已實現(xiàn)，需要做性能優(yōu)化的問題；建議：測試對于產品的一些改進建議；需求：需要產品重新梳理的需求問題；7、Bug狀態(tài)新建：測試人員新提交的bug、優(yōu)化或者建議的問題狀態(tài)；進行中：開發(fā)人員已確認是bug，需要修改的問題狀態(tài)；已解決：開發(fā)人員已修復的問題狀態(tài)；已關閉：測試驗證，確定已解決的問題狀態(tài)；已拒絕：開發(fā)認為不是bug，拒絕給測試的問題狀態(tài)；反饋：反饋給產品確認的問題狀態(tài)；

8、公認：確認是bug，但是無法解決的問題狀態(tài)；打回：測試驗證已解決bug，仍然沒有修復的問題狀態(tài)； 8、Bug嚴重程度致命：不能執(zhí)行正常的功能操作，或者因產品原因導致系統(tǒng)死機，需馬上修復的問題示例：       程序無法啟動，或者登錄；       程序崩潰、停止運行，系統(tǒng)死機，無法進行下一步的操作嚴重：部分功能存在嚴重缺陷，尚可繼續(xù)測試，不影響產品穩(wěn)定性；示例：      偶現(xiàn)的程序崩潰、停止運行  

9、60;   功能未實現(xiàn)      數據不同步      功能錯誤，無法進行后續(xù)操作一般：次要功能或者界面存在的一些錯誤，不影響正常測試；示例：      界面UI顯示和效果圖不一致；      提示語不正確；      錯別字；      查詢結果顯示錯誤建議：測試對于產品的一些

10、改進建議；9、Bug優(yōu)先級4低：對產品的影響比較小，在時間不允許的情況下可以暫時不修改；3中：必須修改，不一定馬上修改，需討論確定在某個特定的里程碑前修改完；2高：必須在版本發(fā)布之前修改完；1緊急：影響測試，需立即或者下一個版本修復；10、其他注意事項1)   開發(fā)人員沒有關閉bug的權限，所有問題均需經過測試驗證無誤后才可關閉；2)   開發(fā)、測試雙方有爭議的bug，必須經過產品的確認才可進行下一步的操作；3)   測試需及時驗證已修復bug；4)   產品人員可以根據產品的階段性需求重新分配bug解決的優(yōu)先級；5)   重新指派bug后，需要口頭或者QQ告知對方；6)   bug的優(yōu)先級劃分比較重要；11、禪道bug提交流程參考：附件：禪道bug管理規(guī)范V1.0禪道系統(tǒng)bug嚴重程度（即bug等級）1=致命bug，2=嚴重bug，3=一般bug，4=建議。致命bug： 不能完全滿足應用要求導致應用閃退和應用停止運行嚴重bug： 嚴重地影響應用需求或基本功能的實現(xiàn)，使應用不穩(wěn)定、或破壞數據、或產生錯誤結果，或部分功能無法執(zhí)行。一般bug： 使操作者不方便或遇