缺陷管理规范及流程
?
?
缺陷管理規(guī)范及流程
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
修訂歷史紀錄
| 日期 | 版本 | 說明 | 作者 |
| 2018-8-1 | 1.0 | 創(chuàng)建 | *** |
| ? | ? | ? | ? |
| ? | ? | ? | ? |
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
目錄
1.概述????4
2.適用范圍????4
3.缺陷書寫規(guī)范????4
3.1新建缺陷必填項????4
3.2重現(xiàn)步驟模塊示例????4
3.3對主要必填項的解釋????5
缺陷標題????5
重現(xiàn)步驟????5
3.4對其它必填項的解釋：????5
3.4.1開發(fā)人員負責定義????5
3.4.2測試人員負責定義????6
4.缺陷生命周期????6
4.1測試人員提交缺陷????6
4.2開發(fā)人員解決缺陷????6
4.3測試人員驗證缺陷????6
?
?
?
?
?
?
?
?
?
?
?
?
?
1.概述
本文檔定義缺陷書定規(guī)范及缺陷生命周期，以便測試及開發(fā)人員能夠更好的配合工作, 提高工作效率
2.適用范圍
適用人員：測試人員，開發(fā)人員，產品經(jīng)理
適用工具：禪道
3.關鍵角色及責任
| 序號 | 角色 | 責任 |
| 01 | 測試工程師 | 1.提交缺陷，驗證缺陷 |
| 02 | 測試組長 | 1.審核測試人員提交的缺陷 2.定期對缺陷進行分析，報告現(xiàn)狀，在測試報告中給出意見 3.分析測試中的風險 |
| 03 | 開發(fā)工程師 | 1.分析缺陷，解決缺陷 |
| 04 | 開發(fā)組長 | 1.分配缺陷,并提出處理意見 2.定期對缺陷進行分析，對bug多的模塊代碼走查 3.跟蹤缺陷修復進 |
| 05 | 產品經(jīng)理 | 1.提出需求變更 2.Bug仲裁 |
?
?
3.缺陷書寫規(guī)范
3.1新建缺陷必填項
如上圖，紅色高亮部分為提交缺陷時的必填項
3.2重現(xiàn)步驟模塊示例
重現(xiàn)步驟格式說明：新建缺陷時重現(xiàn)步驟欄必須包含前置條件，步驟，結果，期望，具體格式見上圖
3.3對主要必填項的解釋
缺陷標題
簡短一句話描述問題所在，如：領取優(yōu)惠券失敗，頁面報400錯誤
重現(xiàn)步驟
[前置條件]
描述缺陷的必要條件，或者描述在寫[步驟]之前需要的前提，如：
優(yōu)惠券已生成成功，批次號：YX0726101306538
優(yōu)惠券領取鏈接：https://pro.uselect.com.cn/activity/html/coupon.html?batchNum=YX0726101306538
[步驟]
用數(shù)字編號，一步步描述重現(xiàn)問題的所有操作步驟，一個步驟對應一個結果，如：
[結果]
以上步驟所對應的實際結果，必要時可以在備注欄貼上截圖，如：
領取失敗，頁面報400錯誤，見截圖：編號001
一個缺陷只描述一個問題
[期望]
清淅地描述期望的結果，必要時可以在備注欄貼截圖，如見截圖，編號：002，期望結果必須有文字描述
3.4對其它必填項的解釋：
3.4.1開發(fā)人員負責項
開發(fā)人員在處理缺陷時，根據(jù)缺陷實際情況填寫如下內容：
缺陷類型：如，代碼錯誤，配置相關，功能優(yōu)化，用戶體驗 ，測試人員提交缺陷時可以選擇缺陷類型，最終缺陷類型由開發(fā)人員在確認或解決缺陷時負責
?
優(yōu)先級：優(yōu)先級從1到4，級別分別為緊急，高，中，低
緊急：立即修復
高：下次發(fā)版前必須修復
中：下次里程碑前必須修復
低：時間允許可以修復，或經(jīng)項目負責人確認后可以在維護階段修復，對于延期處理的缺陷（功能）可以將優(yōu)先級暫時設為低，在下次項目周期時再調整優(yōu)先級，如目前優(yōu)惠券購買價格功能漏項的缺陷
解決方案：如，已解決，設計如此，無法重現(xiàn)
解決日期：上傳代碼時間
3.4.2測試人員負責項
測試人員在新建缺陷時，參照如下定義新建缺陷：
嚴重程序：嚴重程度編號從1到4，分別為致命，嚴重，一般，優(yōu)化
致命：系統(tǒng)崩潰，死機，無法登錄進入下一步操作
嚴重：主要功能模塊未實現(xiàn)，其它功能模塊可以下一步操作
一般：次要功能不能正常使用，提示信息錯誤
優(yōu)化：界面優(yōu)化，報錯時未給出友好提示，文字排列不整齊
所屬項目，模塊，操作系統(tǒng)，瀏覽器
備注：截圖及簡單易讀的文字
4.缺陷生命周期
缺陷狀態(tài)：激活，已確認，已修復，已關閉
4.1測試人員提交缺陷
測試人員根據(jù)規(guī)范提交缺陷,測試主管定期審核缺陷并提出意見
4.2開發(fā)人員解決缺陷
缺陷確認期限：2天
開發(fā)人員依據(jù)缺陷優(yōu)先級分析解決缺陷,開發(fā)主管跟蹤缺陷解決進度，對缺陷多的模塊加強代碼審核
確認缺陷:當天新建的缺陷狀態(tài)為[激活]，對應的開發(fā)人員需在2天內全部審核一遍，將缺陷狀態(tài)置為[已確認]直接解決，
修復缺陷:解決方案，版本，解決日期必填
**必須上傳代碼到測試服務器以后才能修改缺陷狀態(tài)
寫備注：開發(fā)人員在提交代碼后必要時應在備注欄寫明該代碼預計會影響哪些功能，以便測試人員做回歸測試
開發(fā)認為不是缺陷：將缺陷狀態(tài)置為已拒絕；指派給缺陷提出者；同時注明拒絕理由
缺陷缺乏必要的信息：將缺陷狀態(tài)置為已拒絕；指派給缺陷提出者；同時注明拒絕理由
4.3測試人員驗證缺陷
缺陷驗證期限：2天
驗證缺陷:已解決的缺陷 ，測試人員需在2天內驗證
驗證通過：關閉缺陷，同時在備注欄寫明驗證通過
驗證未通過：缺陷狀態(tài)改為激活并指派給對應開發(fā)，同時必須在備注欄寫明原因
若在驗證該 缺陷時，發(fā)現(xiàn)新的缺陷,應重新提交缺陷, 若驗證此缺陷的前提必須是該新提交的缺陷解決以后，應在備注欄寫明原因，如：驗證前提：待缺陷-XXX 驗證通過
5.缺陷仲裁
6.需求變更
轉載于:https://www.cnblogs.com/applewang-123/p/9441814.html
總結
- 上一篇： 爆强！瑞星老用户可获取免费正版Vista
- 下一篇： Juniper