《精選文檔BUG管理規(guī)范與流程.doc》由會員分享，可在線閱讀，更多相關(guān)《精選文檔BUG管理規(guī)范與流程.doc（10頁珍藏版）》請在匯文網(wǎng)上搜索。

1、精選文檔BUG管理規(guī)范與流程BUG管理流程與規(guī)范目 錄1概述51.1編寫目的51.2適用范圍52關(guān)鍵角色及應(yīng)負責任53BUG流程圖64活動描述65BUG書寫規(guī)范85.1測試人員BUG提交85.1.1主題85.1.2步驟85.1.3實際結(jié)果85.1.4預(yù)期結(jié)果85.1.5備注95.2開發(fā)人員解決BUG96BUG嚴重等級106.1致命106.2嚴重106.3一般116.4優(yōu)化117BUG優(yōu)先級127.1緊急127.2高127.3中127.4低128BUG解決方案128.1設(shè)計如此128.2重復(fù)bug128.3已解決128.4無法重現(xiàn)128.5延期處理128.6新增/變更需求129BUG狀態(tài)129.

2、1激活129.2已解決139.3關(guān)閉1310其他要求1311相關(guān)文件1312附件13 1 概述1.1 編寫目的本文檔定義bug的整個生命周期，規(guī)范bug的管理流程。Bug在流轉(zhuǎn)的過程中有章可循。規(guī)范bug嚴重等級與bug解決優(yōu)先級，使開發(fā)人員與測試人員能根據(jù)此文檔準確判斷bug的嚴重程度并加以解決。1.2 適用范圍本文檔適用測試人員、開發(fā)人員。2 關(guān)鍵角色及應(yīng)負責任序號角色應(yīng)負責任01測試工程師1) 提交bug，用bug級別反映bug的嚴重程度，2) 驗證bug是否已被解決02測試負責人1) 審核測試人員提交的bug ；2) 定位測試工程師提交的bug優(yōu)先級3) 定期對bug庫進行分析，描繪出

3、曲線圖等，報告現(xiàn)狀、預(yù)測趨勢，在測試總結(jié)報告中給出意見。4) 分析項目測試過程中存在的風險03開發(fā)工程師1) 分析bug，寫出問題原因，修改bug，2) 實行bug優(yōu)先原則，嚴重程度5個以上的，停止新功能的開發(fā)。04開發(fā)負責人1) 每天對bug進行分配，標注處理意見2) 定期對bug庫分析，對bug多的模塊，進行代碼走查。3) 分析bug修復(fù)進度，對項目的質(zhì)量、進行風險評估。4) 跟蹤被需求確認可延期處理的bug05系統(tǒng)工程師1) 解釋需求，給出處理意見，2) 將bug庫中的建議整理成為需求文檔3) 當開發(fā)和測試存在意見分歧時，進行需求確認。3 Bug流程圖Bug狀態(tài)：激活，已修復(fù)，已關(guān)閉解決

4、方案：設(shè)計如此，重復(fù)Bug，已解決，無法重現(xiàn)，延期處理，新增/變更需求4 活動描述序號活動名稱參與角色活動描述輸入、輸出信息處理時限01提交bug測試工程師詳細書寫B(tài)ug，指派給對應(yīng)的測試負責人輸入信息：無輸出信息：在禪道上提交bug-02Bug確認與分配測試負責人根據(jù)判定是否是Bug，給出意見輸入信息：測試人員提交的bug，測試用例，軟件需求輸出信息：確定bug優(yōu)先級，指派給開發(fā)負責人。0.5個工作日03分析確認并指派Bug開發(fā)負責人根據(jù)判定是否是Bug，給出意見輸入信息：測試負責人指派的bug，軟件需求，程序源代碼等輸出信息：分析Bug，指派給對應(yīng)的開發(fā)工程師，不是bug或應(yīng)該需求變更時，

5、指派給相關(guān)人員0.5個工作日04修復(fù)Bug開發(fā)工程師修改Bug，給出解決方案，修復(fù)再次激活的bug。輸入信息：開發(fā)負責人確認指派的bug，軟件需求輸出信息：Bug的解決方案，產(chǎn)生bug的原因，指派給對應(yīng)的測試工程師0.5個工作日05驗證Bug測試工程師驗證Bug，給出驗證結(jié)果輸入信息：開發(fā)工程師指派的已修復(fù)的Bug，需求確認轉(zhuǎn)為變更或新增需求的bug輸出信息：如果Bug未修改，激活并指派給對應(yīng)的開發(fā)工程師；如果Bug已修改或系統(tǒng)工程師確認轉(zhuǎn)為需求的bug，關(guān)閉bug，0.5個工作日06確認bug延期測試主管分析bug，確認bug是否能延期處理輸入信息：開發(fā)或系統(tǒng)工程師指派的延期bug輸出信息：

6、確認是否能延期處理，對應(yīng)延期的bug在開發(fā)修復(fù)的版本進行激活視實際情況而定07Bug仲裁系統(tǒng)工程師根據(jù)判定是否是Bug，給出處理意見輸入信息：測試主管指派的延期bug或需要系統(tǒng)工程師確認的bug，開發(fā)主管指派的新增/變更需求的bug。輸出信息：給出明確處理結(jié)果，屬于新增/變更需求的bug需要在需求文檔中記錄相關(guān)需求。0.5個工作日5 BUG書寫規(guī)范5.1 測試人員BUG提交5.1.1 主題用一個簡短的句子描述問題，不要寫成一大段以進入問題模塊路徑開頭，方便項目經(jīng)理分派任務(wù)，以及開發(fā)人員定位問題描述問題時要詳細、簡練、抓住要點，直接切入正題，不要羅嗦不要夸大或縮小問題的嚴重程度5.1.2 步驟用

7、數(shù)字編號，一步步的描述重現(xiàn)問題的所有操作步驟提供明確的再現(xiàn)問題的步驟，避免問題被以“不能重現(xiàn)”關(guān)掉設(shè)置區(qū)域需要詳細描述，如：各設(shè)置項值為默認、*值更改為“”，其他設(shè)置項值為默認；盡量用動詞作為開頭，描述每個步驟。如：打開、點擊、設(shè)置、選擇、插入、雙擊等不要在一個步驟中描述不相關(guān)的多個操作。如果是相關(guān)的一系列操作，可以使用“”來連接描述。按照你寫的步驟去執(zhí)行，看問題能否重現(xiàn)不要在步驟中使用含糊不清的縮寫詞描述5.1.3 實際結(jié)果實際只描述一個問題同樣的操作步驟產(chǎn)生多種現(xiàn)象，要在一個缺陷報告中加以描述不同的操作步驟產(chǎn)生不同的問題，分別報bug如果有截圖，請列出所附的圖片信息5.1.4 預(yù)期結(jié)果不要

8、加入實際結(jié)果的描述信息描述要清晰，不要使用含糊不清的縮寫詞描述如果有截圖，請列出所附的圖片信息5.1.5 備注避免寫成大段落，要寫得簡單、易讀問題的特征出現(xiàn)問題后的解決方法對終端客戶的影響情況如果有必要，列出產(chǎn)生問題的配置環(huán)境5.2 開發(fā)人員解決BUG1.BUG的原因。2.BUG的修改方法3.BUG可以在哪個版本上進行驗證。4.測試人員驗證bug時，需要寫明：驗證了什么，在什么版本驗證，是否通過，如果不通過需寫明原因。如果在驗證當前bug時有新現(xiàn)象產(chǎn)生阻礙了驗證此bug，則該bug不能關(guān)閉，寫明沒有驗證的原因，并為新現(xiàn)象提bug。舉例1：現(xiàn)象：修改后：6 BUG嚴重等級6.1 致命不能執(zhí)行正常

9、工作功能或重要功能，因軟件原因?qū)е孪到y(tǒng)死機等，須馬上修正致命錯誤。通常有如下情況：1.內(nèi)存泄漏2.由于執(zhí)行程序引發(fā)數(shù)據(jù)庫發(fā)生死鎖3.用戶數(shù)據(jù)丟失或破壞4.系統(tǒng)崩潰5.死機6.程序無法啟動或異常退出7.因錯誤操作導(dǎo)致的程序中斷8.功能設(shè)計與需求嚴重不符6.2 嚴重影響系統(tǒng)功能或操作，應(yīng)用模塊錯誤使業(yè)務(wù)中止無法進行后續(xù)操作，主要功能存在嚴重缺陷，但不會影響到系統(tǒng)穩(wěn)定性。具體基本上可分為：1.功能未實現(xiàn)2.功能錯誤3.業(yè)務(wù)中止，無法進行后續(xù)操作4.數(shù)據(jù)庫的表、業(yè)務(wù)規(guī)則、缺省值未加完整性等約束條件5.數(shù)據(jù)庫表結(jié)構(gòu)錯誤，字段長度不夠，缺少表、存儲6.語音或數(shù)據(jù)通訊錯誤7.數(shù)值計算錯誤8.前臺提示存儲報錯

10、9.系統(tǒng)所提供的功能或服務(wù)受明顯的影響6.3 一般影響系統(tǒng)正常運行的缺陷，主要功能出現(xiàn)錯誤，影響到產(chǎn)品的使用。例如：次要功能不能正常實現(xiàn)； 查詢錯誤，數(shù)據(jù)錯誤顯示；簡單的輸入限制未放在前臺進行控制具體基本上可分為：1.操作界面錯誤（包括數(shù)據(jù)窗口內(nèi)列名定義、含義是否一致）2.報表打印內(nèi)容、格式錯誤、取值錯誤3.頁面查詢結(jié)果錯誤，自動讀值項取值錯誤4.邊界條件下錯誤5.提示信息錯誤（包括未給出信息、信息提示錯誤等）6.簡單的輸入限制未放在前臺進行控制7.長時間操作無進度提示8.光標跳轉(zhuǎn)設(shè)置不好，鼠標（光標）定位錯誤6.4 優(yōu)化使操作者不合理或者不方便或操作遇到麻煩，但它不影響執(zhí)行工作功能或重要功能

11、，次要功能，對產(chǎn)品使用影響不大。例如：程序在一些顯示上不美觀，不符合用戶習慣，或是一些文字的錯誤。具體基本上可分為：1.界面格式等不規(guī)范2.輔助說明描述不清楚3.操作時未給用戶提示4.可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標志5.個別不影響產(chǎn)品理解的錯別字6.文字排列不整齊等一些小問題7.提示窗口文字未采用行業(yè)術(shù)語7 BUG優(yōu)先級7.1 緊急阻止與此密切相關(guān)功能的進一步測試,需要立即修復(fù)7.2 高必須修改，發(fā)版前必須修正7.3 中必須修改，不一定馬上修改，但需確定在某個特定里程碑結(jié)束前須修正7.4 低對系統(tǒng)的影響較小，如果時間允許應(yīng)該修改8 BUG解決方案8.1 設(shè)計如此設(shè)計如此，測試人員理解錯誤

12、，無需改動，即無效的bug8.2 重復(fù)bug以前已經(jīng)有同樣的bug。8.3 已解決Bug已經(jīng)被修改正確，待測試進行驗證8.4 無法重現(xiàn)根據(jù)測試寫的重現(xiàn)步驟，無法重現(xiàn)bug。8.5 延期處理確實是bug，但現(xiàn)在不解決，以后處理。8.6 新增/變更需求分析確實是存在問題，但需求沒有描述清晰，應(yīng)指派給需求確認，進行需求的新增或變更。9 BUG狀態(tài)9.1 激活1.新創(chuàng)建的bug；2.已關(guān)閉的bug重新出現(xiàn)需要再次激活 ；3.已解決但驗證未通過的bug。9.2 已解決開發(fā)已經(jīng)修改完成的bug。9.3 關(guān)閉已驗證通過的bug或系統(tǒng)工程師確認轉(zhuǎn)為需求的bug。10 其他要求Bug的描述與Bug的流向嚴格遵守流程規(guī)范。11 相關(guān)文件文件編號文件名稱12 附件文件編號文件名稱保存時間保管部門附件10 / 10