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

精品文檔精心整理精品文檔可編輯的精品文檔BUG管理規(guī)范及流程目錄1 前言 32 術(shù)語定義 33 總則 44 研發(fā)階段缺陷管理 44.1 缺陷表單說明 44.2 流程 65 維護(hù)階段問題反饋及處理 75.1 問題表單 75.2 流程 86 附件 96.1 缺陷管理工具選擇 96.2 問題記錄表 10

前言本文檔用于描述“XX軟件股份有限公司”軟件生命周期中，產(chǎn)生的問題及缺陷的收集處理方法和參考規(guī)范。術(shù)語定義術(shù)語英文定義備注缺陷影響客戶正常使用的任何問題缺陷分類按照缺陷的嚴(yán)重程度分為：重大缺陷、待確認(rèn)缺陷、一般缺陷。重大缺陷：指在軟件開發(fā)過程中的針對軟件產(chǎn)品和開發(fā)過程的問題，這些問題已經(jīng)影響用戶的正常使用。待確認(rèn)的缺陷：指該缺陷需要測試人員進(jìn)行重現(xiàn)和確認(rèn)是否為缺陷。一般缺陷：指在軟件開發(fā)過程中的針對軟件產(chǎn)品和開發(fā)過程的問題，這些問題已經(jīng)影響或者可能影響軟件產(chǎn)品的質(zhì)量問題問題指系統(tǒng)上線后，用戶反饋的所有有關(guān)軟件系統(tǒng)的問題，包括：需求和缺陷問題級別按照問題需要處理的緊迫程度分為：非常重要、重要、一般?？梢詮挠脩舻臐M意度和修改的影響范圍兩個方面來定義。非常重要：優(yōu)先級高，要求能在一周之內(nèi)予以解決或者給出解決辦法。重要：優(yōu)先級一般，要求能在兩周之內(nèi)予以解決。一般：優(yōu)先低，要求能在一個月之內(nèi)解決需求分類按照需求特性分為：待討論需求、特殊需求及一般需求。待討論需求：指該需求需要經(jīng)過產(chǎn)品組人員進(jìn)行討論。特殊需求：指該需求的特殊性，一般是工作量較大或是原需求上改動較大的需求。新需求：目前產(chǎn)品功能無法滿足的需求點，該需求具有一定的通用性，可以完善產(chǎn)品問題確認(rèn)確認(rèn)指問題流轉(zhuǎn)各環(huán)節(jié)對問題的處理意見。確認(rèn)結(jié)果可分為：支持：經(jīng)過分析該需求有開發(fā)價值或確認(rèn)修改該缺陷。不支持：經(jīng)過分析該問題無開發(fā)價值或?qū)崿F(xiàn)困難。取消：由于某種原因該問題撤銷，不需要繼續(xù)處理。問題狀態(tài)指問題所處的處理狀態(tài)。分為：待處理、處理中、驗證中、確認(rèn)通過、關(guān)閉等。總則該規(guī)范作為軟件缺陷管理的參考規(guī)范，不作為強(qiáng)制性規(guī)范軟件項目生命過程中缺陷的管理分為兩個階段：未發(fā)布版本前研發(fā)階段的缺陷管理；發(fā)版后項目維護(hù)過程中用戶反饋問題的管理。研發(fā)階段的缺陷管理目標(biāo)是測試過程中發(fā)現(xiàn)的缺陷的管理和跟蹤，確保已發(fā)現(xiàn)缺陷都獲得修復(fù)，同時通過缺陷反映產(chǎn)品質(zhì)量狀況；維護(hù)階段問題反饋處理是產(chǎn)品或者項目已經(jīng)上線使用，在使用過程中用戶或者技服人員反饋缺陷及問題的管理辦法，因為問題的收集環(huán)境比較復(fù)雜，填寫問題的人員比較多，收集的方式應(yīng)該便捷（如郵件、瀏覽器等）填寫和提交比較簡單，同時有專人對反饋的問題進(jìn)行一輪過濾篩選。缺陷管理的字段除必填字段外，項目可根據(jù)需要自行增減這里定義的流程為推薦的最佳處理流程也可根據(jù)具體項目情況進(jìn)行細(xì)節(jié)調(diào)整研發(fā)階段缺陷管理缺陷表單說明可追蹤信息缺陷ID唯一的缺陷ID，可以根據(jù)該ID追蹤缺陷缺陷基本信息缺陷狀態(tài)缺陷的狀態(tài)，新建、打開、正修改、待驗證、待確認(rèn)、關(guān)閉、遺留缺陷摘要缺陷一句話描述嚴(yán)重級別A:致命問題(引起軟件整體運行崩潰或破壞軟件敏感數(shù)據(jù)的致命問題)；B:嚴(yán)重問題(功能測試出錯，導(dǎo)致功能無法使用的問題)；C:一般問題(影響軟件正常完成任務(wù)但仍能產(chǎn)生正確結(jié)果的問題，或者該功能測試出錯，但可以通過其它方式實現(xiàn)該功能)；D:輕微問題/描述性問題(引起操作不舒服但并不影響軟件完成任務(wù)的問題，或者軟件中說明不確切或含義模糊或未準(zhǔn)確使用專業(yè)術(shù)語，容易導(dǎo)致誤解的問題)；E:改進(jìn)建議(不影響軟件完成任務(wù)或功能可以實現(xiàn)，但操作或顯示方面需要改進(jìn)的問題)。F待分類問題（不確定用戶是否需要該功能或該功能應(yīng)用場景不清楚）優(yōu)先級別描述缺陷的緊急程度，高中低缺陷提交人缺陷提交人的名字（郵件地址）缺陷提交日期缺陷提交的時間缺陷所屬產(chǎn)品缺陷所屬產(chǎn)品、或者產(chǎn)品系列缺陷所屬子項目所屬子項目缺陷所屬模塊缺陷所屬的模塊，最好能較精確的定位至模塊產(chǎn)品版本號產(chǎn)品版本號；如CI3.2；CI關(guān)聯(lián)交易2.0；CI_儀表盤1.0期望解決版本CI對外版本號缺陷處理結(jié)果描述對處理結(jié)果的描述，如果對代碼進(jìn)行了修改，要求在此處體現(xiàn)出修改缺陷修正人最終處理缺陷的處理人獲得解決版本解決該缺陷的版本號，由驗證人員填寫。缺陷解決日期缺陷來源錯誤產(chǎn)生原因：編碼錯誤、設(shè)計缺陷、業(yè)務(wù)需求缺陷、編譯配置問題、低級缺陷缺陷類別錯誤的類別：功能錯誤、數(shù)據(jù)錯誤、界面問題、安裝配置其他缺陷提出人提出缺陷的人名缺陷的詳細(xì)描述對缺陷的詳細(xì)描述；之所以把這項單獨列出來，是因為對缺陷描述的詳細(xì)程度直接影響開發(fā)人員對缺陷的修改，描述應(yīng)該盡可能詳細(xì)；操作步驟及缺陷的表現(xiàn)測試環(huán)境說明對測試環(huán)境的描述操作系統(tǒng)、瀏覽器、中間件、數(shù)據(jù)庫必要的附件對于某些文字很難表達(dá)清楚的缺陷，使用圖片等附件是必要的其他：缺陷的歷史流轉(zhuǎn)記錄及缺陷所有的操作；缺陷關(guān)聯(lián)的條目；從創(chuàng)建到關(guān)閉花費時間必填字段缺陷摘要、嚴(yán)重級別、優(yōu)先級別、缺陷所屬產(chǎn)品、缺陷所屬模塊、產(chǎn)品版本號、缺陷處理結(jié)果描述、缺陷來源、缺陷類別、缺陷的詳細(xì)描述選項字段缺陷狀態(tài)：新建、退回、打開、正修改、待驗證、關(guān)閉、遺留、待討論嚴(yán)重級別：致命、嚴(yán)重、一般、建議優(yōu)先級別：高中低缺陷所屬產(chǎn)品：缺陷所屬項目：缺陷所屬模塊：產(chǎn)品版本號：缺陷來源：編碼錯誤、設(shè)計缺陷、業(yè)務(wù)需求缺陷、編譯配置問題、低級缺陷缺陷類別：功能錯誤、數(shù)據(jù)錯誤、界面問題、安裝配置自動生成字段：缺陷ID、缺陷提交人、缺陷提交日期、缺陷解決日期缺陷處理人填寫的字段：缺陷處理結(jié)果描述；驗證通過填寫的字段：獲得解決版本；其余字段由缺陷提交人填寫。流程缺陷提交人提交缺陷（缺陷提交人可以是項目組任何成員）可能根據(jù)項目情況選擇是否需要“缺陷分發(fā)人”（一位或多位），如提交缺陷的人員無法判定該缺陷應(yīng)該提交給哪位研發(fā)人員處理時；特別關(guān)注、需要保證提交缺陷的質(zhì)量時；需要項目經(jīng)理或者主要負(fù)責(zé)人對缺陷進(jìn)行處理時。也可以提交人直接將缺陷提交給最終的缺陷修改人員如果缺陷被退回，再次確認(rèn)是否為缺陷或者是否描述清晰，如果不是缺陷關(guān)閉缺陷，如果描述不清修改描述并重新提交打開缺陷缺陷分發(fā)人對缺陷進(jìn)行判斷，如果是缺陷分配給對應(yīng)缺陷修正人員，如果不是缺陷或者描述不清，將缺陷退回提交人缺陷修正人判定是否為缺陷，如果是缺陷轉(zhuǎn)為“正修改”狀態(tài)；如果不是缺陷或者描述不清，將缺陷退回提交人新版本研發(fā)開始后，研發(fā)經(jīng)理檢查遺留問題，需要在此版本中解決的缺陷，將缺陷打開制定給修正人修正缺陷修正缺陷，將缺陷置為“待驗證”如果缺陷修正人對缺陷是否要修改有爭議，或者需要協(xié)調(diào)修改或者修改有不明確的因素，將缺陷置為“待討論”研發(fā)經(jīng)理處理“待討論”缺陷，如果認(rèn)為需要修正轉(zhuǎn)給修正人員進(jìn)行修正，如果認(rèn)為不用修正直接關(guān)閉缺陷，如果可以遺留到下個版本在進(jìn)行解決置為“遺留”狀態(tài)缺陷驗證測試人員對“待驗證”的缺陷進(jìn)行回歸測試，如果驗證通過關(guān)閉缺陷，如果驗證不通過將缺陷置為“打開”，繼續(xù)進(jìn)行缺陷修正維護(hù)階段問題反饋及處理問題表單字段字段說明*編號問題統(tǒng)一編號*功能模塊功能模塊或者功能分類*問題描述問題的詳細(xì)描述*性質(zhì)問題性質(zhì)決定問題的下一步處理流程，分為：缺陷、重大缺陷、需求、待討論需求、特殊需求（研發(fā)產(chǎn)品負(fù)責(zé)人填寫）*版本所用版本號*項目名稱提交此問題的具體項目名稱*提出人提出人姓名*提出時間出題具體時間年月日*期望解決時間期望的解決時間預(yù)計解決時間預(yù)計解決時間（研發(fā)負(fù)責(zé)人填寫）問題歸類問題分類，可以分為：宕機(jī)、效率問題、美觀性問題、易用性問題、數(shù)據(jù)正確性*問題級別問題嚴(yán)重級別，分為：非常重要、重要、一般問題解決方法具體解決辦法（研發(fā)負(fù)責(zé)人填寫）*研發(fā)人員確認(rèn)情況支持、不支持（研發(fā)產(chǎn)品負(fù)責(zé)人填寫）研發(fā)負(fù)責(zé)人研發(fā)負(fù)責(zé)人姓名*研發(fā)完成情況完成、未完成（研發(fā)負(fù)責(zé)人填寫）研發(fā)完成時間（研發(fā)負(fù)責(zé)人填寫）*測試確認(rèn)情況可重現(xiàn)、不能重現(xiàn)、不存在、已解決、未解決（測試負(fù)責(zé)人填寫）測試確認(rèn)時間（測試負(fù)責(zé)人填寫）*完成版本測試通過的版本號（測試負(fù)責(zé)人填寫）實施確認(rèn)情況已確認(rèn)、未確認(rèn)（實施人員填寫）實施確認(rèn)時間開始時間產(chǎn)品維護(hù)小組填寫開始時間結(jié)束時間問題最終通過時間狀態(tài)不支持關(guān)閉、支持待解決、支持正解決、解決關(guān)閉、取消關(guān)閉備注附件必填字段：打星號的為必填字段。缺陷狀態(tài)區(qū)分：不支持關(guān)閉、支持待解決、支持正解決、解決關(guān)閉、取消關(guān)閉流程問題提交項目實施人員記錄用戶反饋問題，包括缺陷和需求，提交給產(chǎn)品維護(hù)小組成員如果產(chǎn)品線比較大，可以分為多個小組分別負(fù)責(zé)不同業(yè)務(wù)產(chǎn)品維護(hù)小組成員對提交的問題進(jìn)行確認(rèn)、過濾，對于不用研發(fā)處理的問題（如由于實施問題、用戶理解和操作方式問題）要過濾掉，對于重復(fù)提交的問題進(jìn)行合并，并將處理結(jié)果反饋給提交人對于確認(rèn)過的問題，梳理后提交到“問題一覽表”，或者通過缺陷管理工具提交到研發(fā)部門（要填寫的字段有“編號”“功能模塊”“問題描述”“版本”、“項目名稱”、“提出人”、“提出時間”、“期望解決時間”、“問題歸類”、“問題級別”、“開始時間”），如果有需要可同時抄送給產(chǎn)品相關(guān)干系人問題分類研發(fā)產(chǎn)品負(fù)責(zé)人對提交過來的問題進(jìn)行分類，填寫“問題性質(zhì)”、“研發(fā)人員確認(rèn)情況”字段，如果確認(rèn)支持填寫對應(yīng)的“研發(fā)負(fù)責(zé)人”如果確認(rèn)需求不予支持，填寫不支持，并通知產(chǎn)品維護(hù)小組如果是一般缺陷、一般需求指派給確定的研發(fā)人員進(jìn)行修正，并填寫“預(yù)計解決時間”，轉(zhuǎn)給相應(yīng)研發(fā)人員如果是重大缺陷，將嚴(yán)重缺陷抄送給產(chǎn)品相關(guān)干系人（包括研發(fā)部門經(jīng)理、測試負(fù)責(zé)人等），把問題級別定為“非常重要”，并指定研發(fā)人員和預(yù)計解決時間如果認(rèn)為缺陷不明確或者需要測試人員驗證，將性質(zhì)填為“需測試驗證缺陷”，轉(zhuǎn)給測試負(fù)責(zé)人如果屬于重大需求，有較大開發(fā)量，需要進(jìn)行需求分析設(shè)計，將問題性質(zhì)定義為“特殊需要”如果是屬于需求但描述不清、理解可能有偏差或者有爭議，問題性質(zhì)定為“待討論需求”問題處理對于確認(rèn)不支持的直接取消對于一般缺陷、一般需求和嚴(yán)重缺陷，負(fù)責(zé)修正的研發(fā)人員盡量在“預(yù)計時間”內(nèi)完成修改，并填寫“研發(fā)完成情況”、“研發(fā)完成時間”對于需測試驗證缺陷，測試人員了解并重現(xiàn)缺陷，如果缺陷確實存在，提交缺陷并將缺陷根據(jù)嚴(yán)重程度修改為“一般缺陷”或“嚴(yán)重缺陷”，然后按一般缺陷和嚴(yán)重缺陷處理流程處理；如果不是缺陷與提交人缺陷取消；如果無法重現(xiàn)也要聯(lián)系提交人分析問題，如果不能解決提交疑難雜癥小組解決對于待討論需求，研發(fā)產(chǎn)品負(fù)責(zé)人聯(lián)系缺陷提交人和產(chǎn)品維護(hù)小組人員進(jìn)行討論確認(rèn)，討論清晰后根據(jù)問題性質(zhì)轉(zhuǎn)為“一般需求”“特殊需求”，然后按“一般需求”和“特殊需求”流程處理對于特殊需求，研發(fā)人員要對此需求進(jìn)行需求分析并編寫需求規(guī)格說明書，評審?fù)ㄟ^后進(jìn)行開發(fā)問題驗證、確認(rèn)問題修正完成后，提交測試人員進(jìn)行測試其中特殊需求及嚴(yán)重缺陷要安排測試設(shè)計及評審，并進(jìn)行詳細(xì)測試測試人員驗證完成填寫“測試確認(rèn)情況”、“測試確認(rèn)時間”，如果驗證通過填寫“完成版本”；如果驗證沒通過退回研發(fā)人員重新修正問題提交人看到測試確認(rèn)通過，并且有“完成版本”，獲取完成的程序版本進(jìn)行此問題的確認(rèn)，確認(rèn)重點為是否為預(yù)期的效果，在本項目中應(yīng)用是否正常，并填寫“實施確認(rèn)情況”“實施確認(rèn)時間”；如果確認(rèn)通過“實施確認(rèn)時間”即為問題“結(jié)束時間”狀態(tài)變?yōu)椤敖鉀Q關(guān)閉”；如果驗證沒通過退回研發(fā)人員重新修正附件低級及嚴(yán)重缺陷定義標(biāo)準(zhǔn)低級缺陷新推出的研發(fā)中心“月度考核指標(biāo)”中有一項指標(biāo)為“低級缺陷個數(shù)”，根據(jù)考核需要，測試部各項目測試人員在今后提交缺陷時，將提供對低級缺陷的標(biāo)識建議，是否定為低級缺陷可以在由項目經(jīng)理核實。目前各項目的缺陷管理，只使用以下兩種工具：TrackRecord或rpims系統(tǒng)，這兩個缺陷管理工具中都已加入了“低級缺陷”的缺陷類型。測試人員在提交缺陷時需要一個基本的低級缺陷界定的依據(jù)，經(jīng)初步討論，我們給出低級缺陷的定義為：關(guān)鍵界面及重要的提示信息中有明顯的錯別字。提示信息文不對題，或者張冠李戴。界面中的文字、按鈕格式不復(fù)合公司規(guī)范。簡單的異常值測試出現(xiàn)錯誤（如邊界值等）。開發(fā)人員在程序中直接調(diào)用其他開發(fā)人員編寫的模塊，對該模塊中無用的功能未做屏蔽，造成部分功能使用異常。基本業(yè)務(wù)流程性錯誤，最基本的業(yè)務(wù)流程不能走通，致使測試不能往下進(jìn)行。重復(fù)多次出現(xiàn)的錯誤，一個錯誤重復(fù)三次以上。由于版本管理不善，未更新部分代碼引起的bug或者測試程序根本就沒有給對。正式提交到測試部的測試版本，如果發(fā)現(xiàn)如下錯誤將視為低級缺陷處理。嚴(yán)重缺陷嚴(yán)重缺陷指引起軟件整體運行崩潰或破壞軟件敏感數(shù)據(jù)的致命問題，以及核心功能無法使用，可能會給用戶帶來重大損失的程序缺陷，具體定義如下：系統(tǒng)核心業(yè)務(wù)、重要功能未實現(xiàn)或不能正確執(zhí)行數(shù)據(jù)丟失,數(shù)據(jù)計算錯誤,數(shù)據(jù)錯亂等用戶敏感的數(shù)據(jù)錯誤系統(tǒng)性能差，響應(yīng)時間用戶無法接收系統(tǒng)崩潰和非正常死機(jī)，造成用戶不能使用缺陷管理工具選擇目前可提供的缺陷管理工具及其優(yōu)缺點對比工具優(yōu)點缺點TrackRecord可靈活定制流程字段及界面可自定義缺陷管理流程簡便易掌握查詢速度快具備一定的統(tǒng)計分析能力版本陳舊，有部分缺陷需要專職維護(hù)人員無法實現(xiàn)一個數(shù)據(jù)庫中不同項目采用不同管理流程的要求C/S沒有提供瀏覽器方式訪問無法統(tǒng)計缺陷的修復(fù)效率等rpims操作簡便、易與使用B/S結(jié)構(gòu)統(tǒng)計分析能力較好流程不能定制缺陷字段不能靈活增刪數(shù)據(jù)量大、登錄人數(shù)多時系統(tǒng)響應(yīng)速度有待提升無缺陷流轉(zhuǎn)的歷史記錄StarTeam流程可定制字段及界面可自定義可以對缺陷按版本進(jìn)行管理維護(hù)工作量大同時作配置管理工具，效率有一定影響界面操作比較復(fù)雜一次展現(xiàn)缺陷條數(shù)少EXCEL字段可根據(jù)需要隨時增加沒有流程控制文檔的準(zhǔn)確性和時效性不好保證文檔維護(hù)工作量大無統(tǒng)計分析能力問題記錄表精品文檔精心整理精品文檔可編輯的精品文檔報銷規(guī)定及流程1）各項費用的開支憑原始發(fā)票由財務(wù)主管填制《單據(jù)報銷粘存單》,經(jīng)辦