BUG管理規(guī)范與流程

BUG管理流程與規(guī)范TOC\o"1-5"\h\z\o"CurrentDocument"概述3\o"CurrentDocument"編寫目的3\o"CurrentDocument"適用范圍4\o"CurrentDocument"關鍵角色及應負責任4\o"CurrentDocument"BUG流程圖5\o"CurrentDocument"活動描述5\o"CurrentDocument"BUG書寫規(guī)范7\o"CurrentDocument"測試人員BUG提交7主題7步驟7實際結果7預期結果7備注7\o"CurrentDocument"開發(fā)人員解決BUG8\o"CurrentDocument"BUG嚴重等級9\o"CurrentDocument"致命9\o"CurrentDocument"嚴重9\o"CurrentDocument"一般10\o"CurrentDocument"優(yōu)化10\o"CurrentDocument"BUG優(yōu)先級10\o"CurrentDocument"緊急10\o"CurrentDocument"高10\o"CurrentDocument"中11\o"CurrentDocument"低11\o"CurrentDocument"BUG解決方案11\o"CurrentDocument"設計如此11\o"CurrentDocument"重復BUG11\o"CurrentDocument"已解決11\o"CurrentDocument"無法重現(xiàn)11\o"CurrentDocument"延期處理11\o"CurrentDocument"新增/變更需求11\o"CurrentDocument"BUG狀態(tài)11\o"CurrentDocument"激活11\o"CurrentDocument"已解決11\o"CurrentDocument"關閉11\o"CurrentDocument"其他要求11\o"CurrentDocument"相關文件12\o"CurrentDocument"附件12概述編寫目的本文檔定義bug的整個生命周期，規(guī)范bug的管理流程。Bug在流轉的過程中有章可循。規(guī)范bug嚴重等級與bug解決優(yōu)先級，使開發(fā)人員與測試人員能根據(jù)此文檔準確判斷

bug的嚴重程度并加以解決。適用范圍本文檔適用測試人員、開發(fā)人員。2關鍵角色及應負責任序號角色應負責任01測試工程師1）提交bug,用bug級別反映bug的嚴重程度，2）驗證bug是否已被解決02測試負責人1）審核測試人員提交的bug;2）定位測試工程師提交的bug優(yōu)先級3）定期對bug庫進行分析，描繪出曲線圖等，報告現(xiàn)狀、預測趨勢，在測試總結報告中給出意見。4）分析項目測試過程中存在的風險03開發(fā)工程師1）分析bug,寫出問題原因，修改bug,2）實行bug優(yōu)先原則，嚴重程度5個以上的，停止新功能的開發(fā)。04開發(fā)負責人1）每天對bug進行分配，標注處理意見2）定期對bug庫分析，對bug多的模塊，進行代碼走查。3）分析bug修復進度，對項目的質量、進行風險評估。4）跟蹤被需求確認可延期處理的bug05系統(tǒng)工程師1）解釋需求，給出處理意見，2）將bug庫中的建議整理成為需求文檔3）當開發(fā)和測試存在意見分歧時，進行需求確認。3Bug流程圖Bug管理流程樨出bug 修房階段 驗證階段 艱睞階段師程工試測管主試測Bug驗證 ］是否修復 關閉bug3Bug流程圖Bug管理流程樨出bug 修房階段 驗證階段 艱睞階段師程工試測管主試測Bug驗證 ］是否修復 關閉bugbug,明產生原因師程工發(fā)開JL是否延期

修復是否是bug修復bug確認用百派bug管主發(fā)開師程工統(tǒng)系仲裁是否是bug分析是否J 是否在該卜是bug 版本修復確認bug為延期修復,

但bug狀態(tài)為已解決，

不能關閉，在修復完

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

分析Bug,指派給對應的開發(fā)工程師，不是bug或應該需求變更時，指派給相關人員04修復Bug開發(fā)工程師修改Bug,給出解決方案，修復再次激活的bug。輸入信息：開發(fā)負責人確認指派的bug,軟件需求輸出信息：Bug的解決方案，產生bug的原因，指派給對應的測試工程師0.5個工作日05驗證Bug測試工程師驗證Bug,給出驗證結果輸入信息：開發(fā)工程師指派的已修復的Bug,需求確認轉為變更或新增需求的bug輸出信息：如果Bug未修改，激活并指派給對應的開發(fā)工程師；如果Bug已修改或系統(tǒng)工程師確認轉為需求的bug,關閉bug,0.5個工作日06確認bug延期測試主管分析bug,確認bug是否能延期處理輸入信息：開發(fā)或系統(tǒng)工程師指派的延期bug輸出信息：確認是否能延期處理，對應延期的bug在開發(fā)修復的版本進行激活視實際情況而定07Bug仲裁系統(tǒng)工程師根據(jù)<<軟件需求>>判定是否是Bug,給出處理意見輸入信息：測試主管指派的延期bug或需要系統(tǒng)工程師確認的bug,開發(fā)主管指派的新增/變更需求的bug。輸出信息：給出明確處理結果，屬0.5個工作日于新增/變更需求的bug需要在需求文檔中記錄相關需求。5BUG書寫規(guī)范測試人員BUG提交主題?用一個簡短的句子描述問題，不要寫成一大段?以進入問題模塊路徑開頭，方便項目經理分派任務，以及開發(fā)人員定位問題?描述問題時要詳細、簡練、抓住要點，直接切入正題，不要羅嗦?不要夸大或縮小問題的嚴重程度步驟?用數(shù)字編號，一步步的描述重現(xiàn)問題的所有操作步驟?提供明確的再現(xiàn)問題的步驟，避免問題被以“不能重現(xiàn)”關掉?設置區(qū)域需要詳細描述，如：各設置項值為默認、**值更改為“”，其他設置項值為默認;?盡量用動詞作為開頭，描述每個步驟。如：打開、點擊、設置、選擇、插入、雙擊等?不要在一個步驟中描述不相關的多個操作。如果是相關的一系列操作，可以使用“一”來連接描述。?按照你寫的步驟去執(zhí)行，看問題能否重現(xiàn)?不要在步驟中使用含糊不清的縮寫詞描述實際結果?實際只描述一個問題?同樣的操作步驟產生多種現(xiàn)象，要在一個缺陷報告中加以描述?不同的操作步驟產生不同的問題，分別報bug?如果有截圖，請列出所附的圖片信息預期結果?不要加入實際結果的描述信息?描述要清晰，不要使用含糊不清的縮寫詞描述?如果有截圖，請列出所附的圖片信息備注?避免寫成大段落，要寫得簡單、易讀?問題的特征?出現(xiàn)問題后的解決方法?對終端客戶的影響情況?如果有必要，列出產生問題的配置環(huán)境開發(fā)人員解決BUG1.BUG的原因。2.BUG的修改方法3.BUG可以在哪個版本上進行驗證。4.測試人員驗證bug時，需要寫明：驗證了什么，在什么版本驗證，是否通過，如果不通過需寫明原因。如果在驗證當前bug時有新現(xiàn)象產生阻礙了驗證此bug,則該bug不能關閉，寫明沒有驗證的原因，并為新現(xiàn)象提bug。舉例1：BUG慨7s還教歷史中，還款期數(shù)排列豳序同通歪艮步理陟獴K用戶進入財務管理-正常還款確認在引爆中選擇一條里據(jù)查看該單據(jù)的還款期掇第果1K還款期麴不是按照正常的排列靦序顯示期望12、還款順序按照正常順序顯示,提時間上瞪定或者是金額上的約定來顯示該還款期數(shù)）現(xiàn)象:□證款日即irSC5T?/中，土灣問白喻.11亦*TB-LT21QXCITOKD2S4QIE2ODescuZ2RKtH-LT3EECC174ED2三如］esco33出MrXHT30000mzB2510W1TO丈一m期片中-車主利宅瑕更新RVJ180五BEHEEEET]4IZEE-EEEK-E-"'12&ID■a2CKJE31DDW細KF9-1T&時鉞節(jié)TWIFEE斑詠肝254033H14-OT-1S&GECEEE7IQI^EEEEEH=￡T?E4￡i□修改后:BUG#575還款歷史中，還款期數(shù)排席混亂沒有按般正序或逆序排列重現(xiàn)步孽茜獴1、用戶進入財務管理-正常還款確認一“在為廉中選捺一條單據(jù)3查看該單據(jù)的還款期勉―士還款期非列順序混亂沒有按照正序或逆序排列陪果］還款歷史卬，還款懶排列順序混亂沒有按照正序或逆序排列mi還款順序按照正常順序顯示.（是時間上的約定或者是金領上的約定來顯示該還款期數(shù)）BUG嚴重等級致命不能執(zhí)行正常工作功能或重要功能，因軟件原因導致系統(tǒng)死機等，須馬上修正致命錯誤。通常有如下情況：.內存泄漏.由于執(zhí)行程序引發(fā)數(shù)據(jù)庫發(fā)生死鎖.用戶數(shù)據(jù)丟失或破壞.系統(tǒng)崩潰.死機.程序無法啟動或異常退出.因錯誤操作導致的程序中斷.功能設計與需求嚴重不符嚴重影響系統(tǒng)功能或操作，應用模塊錯誤使業(yè)務中止無法進行后續(xù)操作，主要功能存在嚴重缺陷，但不會影響到系統(tǒng)穩(wěn)定性。具體基本上可分為：.功能未實現(xiàn).功能錯誤.業(yè)務中止，無法進行后續(xù)操作.數(shù)據(jù)庫的表、業(yè)務規(guī)則、缺省值未加完整性等約束條件.數(shù)據(jù)庫表結構錯誤，字段長度不夠，缺少表、存儲.語音或數(shù)據(jù)通訊錯誤.數(shù)值計算錯誤.前臺提示存儲報錯.系統(tǒng)所提供的功能或服務受明顯的影響一般影響系統(tǒng)正常運行的缺陷，主要功能出現(xiàn)錯誤，影響到產品的使用。例如：次要功能不能正常實現(xiàn)；查詢錯誤，數(shù)據(jù)錯誤顯示；簡單的輸入限制未放在前臺進行控制具體基本上可分為：.操作界面錯誤（包括數(shù)據(jù)窗口內列名定義、含義是否一致）.報表打印內容、格式錯誤、取值錯誤.頁面查詢結果錯誤，自動讀值項取值錯誤.邊界條件下錯誤.提示信息錯誤（包括未給出信息、信息提示錯誤等）.簡單的輸入限制未放在前臺進行控制.長時間操作無進度提示.光標跳轉設置不好，鼠標（光標）定位錯誤優(yōu)化使操作者不合理或者不方便或操作遇到麻煩，但它不影響執(zhí)行工作功能或重要功能,次要功能，對產品使用影響不大。例如：程序在一些顯示上不美觀，不符合用戶習慣，或是一些文字的錯誤。具體基本上可分為：.界面格式等不規(guī)范.輔助說明描述不清楚.操作時未給用戶提示.可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標志.個別不影響產品理解的錯別字.文字排列不整齊等一些小問題.提示窗口文字未采用行業(yè)術語BUG優(yōu)先級緊急阻止與此密切相關功能的進一步測試，需要立即修復高必須修改，發(fā)版前必須修正中必須修改，不一定馬上修改，但需確定在某個特定里程碑結束前須修正低對系統(tǒng)的影響較小，如果時間允許應該修改BUG解決方案設計如此設計如此，測試人員理解錯誤，無需改動，即無效的bug重復bug以前已經有同樣的