BUG處理流程圖

流程描述：

一、 測試人員發現bug提交給開發。

二、 開發人員判斷是不是bug。

三、 若是是bug，進行修改，修改完成後更改bug狀態爲已解決。

四、 若是不是bug，退回給測試人員並描述退回緣由，或爲設計如此，或爲外部緣由，或者不能重現。

五、 開發人員修改完成的bug，由測試人員進行驗證，確認修改正確，關閉bug。

六、 驗證未經過的bug從新激活，開發人員繼續修改，直至驗證經過，關閉bug。

七、 測試人員須要對開發人員退回的bug進行確認。

八、 確認不是bug關閉。

九、 如與開發人員意見不一致，認爲是bug，需提交項目負責人仲裁。

十、項目負責人確認是bug由開發人員修改，不是bug由測試人員關閉。

注：除提交項目負責人仲裁環節外，其餘環節均可以在禪道上完成。

2、 各角色應關注的狀態

1. 開發人員：激活、從新打開

激活：開發人員要對處於激活狀態的bug進行處理，處理後將其狀態置成「已解決」、「設計如此」、「沒法重現」、「外部緣由」、「重複bug」或「延期處理」。

從新打開：從新打開的bug是已解決的bug通過測試人員驗證，未修改正確，須要繼續修改。

1. 測試人員：已解決、沒法重現、設計如此、外部緣由、延期處理

已解決：測試人員發現狀態爲「已解決」的BUG，要及時驗證，若是確實已解決，要將其置爲「關閉」。不然「從新打開」

沒法重現：測試人員發現狀態爲「沒法重現」的BUG，要及時修改，把步驟描述清楚，並將其狀態置爲「從新打開」。

設計如此：測試人員發現狀態爲「設計如此」和「外部緣由」的BUG，要及時通知項目經理，由項目經理來決定是否修改；對「延期處理」的問題要進行按期跟蹤，如發現問題沒有按註釋進行修改要及時通知開發人員或彙報給相關負責人。

1. 項目經理：設計如此、外部緣由、延期處理

設計如此：由於這些BUG都是測試人員和開發人員有爭議的BUG，所以項目經理必須及時關注這些BUG，及時給出合理的定奪，若是不需修改把狀態置成「關閉」，若是須要馬上解決置成「從新打開」，不然置成「之後解決」。同時，項目經理也要關注「延期處理」的BUG，以避免其被漏掉或遺忘從而影響到項目上線。

3、 缺陷嚴重級別及類型定義

u 致命錯誤包括：

1． 形成系統崩潰、死機

2． 形成程序非法退出、死循環、通信中斷或異常

u 嚴重錯誤包括：

1. 功能不符

2. 數據流錯誤

3. 程序接口錯誤

4. 密碼明文顯示

u 通常錯誤包括：

1. 界面錯誤

2. 打印內容、格式錯誤

3. 輸入限制未放在前臺進行控制

4. 刪除操做未給出提示

5. 輔助說明描述不清楚

6. 顯示格式不規範

7. 長時間操做未給用戶進度提示

u 建議（非缺陷）

1． 修改後可得到更好的用戶體驗

4、 缺陷優先級定義

一、 高：致使測試暫停，沒法進行；必須當即解決，優先級高於開發工做。

二、 中：致使部分功能沒法測試；須要優先解決，解決週期2天。

三、 低：不影響測試的進行；可在方便時解決，解決週期3-5天。

5、 必須注意的問題

1. 開發人員不能直接關閉bug，關閉bug必須由測試人員完成。

2. 在進行問題處理的時候必需要添加註釋，描述不是問題的緣由、之後解決的計劃版本時間等等。

3. 你們在處理本身的問題時，即便這個問題不是本身的程序引發，也最好不要把問題置之不理，由於這個問題是在你這塊表現出來的，到底哪裏出問題應該比較清楚，跟其餘相關人溝通相對比較容易，這樣能夠下降溝通成本，勁量作到「首位責任制」或「問題到此爲止」

項目線上Bug處理流程