軟件缺陷管理制度(共8頁)

1、精選優(yōu)質(zhì)文檔-傾情為你奉上軟件缺陷管理規(guī)定1 目的缺陷是產(chǎn)品與規(guī)定要求不相符的部分。軟件缺陷是開發(fā)、評審、測試和使用的過程中，發(fā)現(xiàn)的軟件產(chǎn)品與用戶需求，設(shè)計要求不符的部分，這些部分造成使用不方便或在某種程度上不能滿足用戶的要求。軟件缺陷的同義詞有：bug，issue，defect，問題等，這里通稱為缺陷。缺陷會存在于軟件產(chǎn)品的整個生命周期中：可以是軟件代碼的問題、系統(tǒng)文檔（開發(fā)文檔和測試文檔等）存在的問題，或者是用戶的幫助文檔和使用指南方面的問題等。本文規(guī)定了軟件缺陷登記跟蹤處理的完整過程規(guī)范。2 范圍適用于軟件的整個生命周期。不限于測試過程發(fā)現(xiàn)的缺陷。評審，用戶使用等過程中發(fā)現(xiàn)的缺陷都是應當

2、按照本流程進行登記跟蹤管理。3 職責3.1 測試工程師：在這里主要是指發(fā)現(xiàn)和報告缺陷的測試人員。在一般流程中，他需要對這個缺陷后續(xù)相關(guān)的狀態(tài)負責：包括相關(guān)人員對這個缺陷相關(guān)信息的詢問回答，以及驗證測試。3.2 開發(fā)工程師：這里主要指對這個缺陷進行研究和修改的開發(fā)人員。同時，他需要對修改后的缺陷在提交測試人員正式測試驗證之前需要進行驗證測試。3.3 其他參與人：主要有項目負責人、測試經(jīng)理、用戶等組成。他們對缺陷進行優(yōu)先級劃分，負責人進行確認并調(diào)解爭議。3.4 配置管理員：負責缺陷庫的創(chuàng)建和權(quán)限管理，并監(jiān)督指導缺陷庫的定制。4 缺陷管理流程缺陷管理流程圖，下圖描述缺陷管理的工作程序，缺陷的生命周期

3、狀態(tài)。4.1 登記缺陷發(fā)現(xiàn)后，由測試人員登記到缺陷庫。具體項目也可以允許用戶向缺陷庫提交缺陷。缺陷登記后，提交前可以反復編輯，補充缺陷記錄的信息。測試人員必須保證登記的缺陷信息可以被處置負責人員理解，具體要求參見 5.10登記后的缺陷狀態(tài)是“新”。4.2 提交測試人員確認缺陷已經(jīng)表述清楚，可以提交缺陷。提交后的缺陷狀態(tài)是“已提交”缺陷提交前必須分配一個具體的開發(fā)人員負責，如果測試人員不確定誰負責，可以把缺陷分配給測試經(jīng)理或項目負責人，再由他們重新分配負責人。4.3 處置開發(fā)人員確認缺陷是自己負責后，開始著手處理，并修改缺陷的狀態(tài)為“打開”，表示缺陷正在處理中。已經(jīng)打開的缺陷也可以修改負責人。4

4、.4 解決問題解決后，填寫解決處置記錄，寫明造成缺陷的原因和解決方案，改變?nèi)毕轄顟B(tài)為“已解決”。處置記錄必須符合 5.12 規(guī)定的要求。如果開發(fā)人員發(fā)現(xiàn)如下情況，可以把缺陷狀態(tài)置成“否決”條件處置意見處置記錄缺陷不可再現(xiàn)不可再現(xiàn)無與先前登記的缺陷重復重復問題先前登記缺陷的編號不是缺陷，是測試人員理解錯誤不是問題說明需求和設(shè)計中對應的內(nèi)容，以證明軟件行文符合預期要求。缺陷輕微，且修改困難，或修改易導致更大的潛在問題不處理說明缺陷和需求不相抵觸，且輕微說明處理的困難和風險如果按照開發(fā)計劃，缺陷發(fā)生的功能不屬于當前開發(fā)階段必須的完成的推遲處理引用開發(fā)計劃，寫明何時處理。需要項目負責人確認4.5 驗證

5、測試人員對“已解決”狀態(tài)的缺陷進行重新測試，測試步驟應當按照登記的可重現(xiàn)步驟進行。4.6 關(guān)閉測試人員確認缺陷已經(jīng)解決后，關(guān)閉缺陷。對于否決的缺陷，測試人員需要和項目負責人討論，項目負責人同意的可以關(guān)閉，項目負責人不同意的需要“重新打開”。4.7 再打開驗證測試不通過的缺陷，應當重新打開，狀態(tài)變?yōu)椤爸匦麓蜷_”。關(guān)閉了的缺陷再次出現(xiàn)時(通常因為解決缺陷的方法導致相同位置出現(xiàn)不同形式的缺陷時)，測試人員重新打開缺陷，開發(fā)人員需要繼續(xù)解決。項目負責人應當關(guān)注“重新打開”的缺陷。5 缺陷記錄缺陷記錄應當包含但不限于如下屬性。5.1 編號缺陷的唯一標示，可以方便對特定缺陷記錄的引用。5.2 所屬項目5.

6、3 軟件發(fā)布版本即缺陷是在什么發(fā)布版本中發(fā)現(xiàn)。對于文檔缺陷，這里使用文檔在配置庫里的版本號。5.4 所屬功能5.5 負責人負責處置解決缺陷的負責人，對于程序缺陷，負責人應當具體開發(fā)人員；對于文檔缺陷，負責人應當是具體文檔的作者。缺陷登記者不明確責任人時，可以指定項目負責人為責任人，由他重新分配負責人。5.6 狀態(tài)即缺陷通過一個跟蹤修復過程的進展情況新新登記的缺陷，這個時候缺陷記錄內(nèi)容可以不完整，可以繼續(xù)補充已經(jīng)提交缺陷信息完整，并分配責任人，打開負責人開始處理已解決問題已經(jīng)解決，負責人必須填寫完整的處置記錄，內(nèi)容包含對原因的分析和解決方法。參見5.11否決責任人呢不同意缺陷，或不處理缺陷參見4

7、.4 和 5.11關(guān)閉驗證測試通過后重新打開沒有通過驗證測試，或不同意被否決。已經(jīng)關(guān)閉的缺陷再次出現(xiàn)的。5.7 嚴重程度標志缺陷對整個軟件產(chǎn)品功能的影響程度?？梢杂脭?shù)字表示，分為1到5檔，可以用說明文字表示，具體項目可以根據(jù)自己的情況定義缺陷的嚴重程度標準，下表是一個常用的標準嚴重程度標示含義1 致命導致軟件無法使用問題，例如整個程序崩潰，導致無法使用，測試無法繼續(xù)進行。下面的問題應定義為嚴重度1級：l 問題會自發(fā)的影響整個系統(tǒng)。l 用戶使用正常的操作步驟，就會影響整個系統(tǒng)提供的服務(wù)。l 具有操作先后順序的功能，一開始的步驟出現(xiàn)故障，導致后續(xù)步驟無法使用2 嚴重某個功能未實現(xiàn)或?qū)е乱粋€特性不能

8、運行并且沒有替代方案。3 一般錯誤導致了一個特性不能運行但可有一個替代方案功能特征設(shè)計不符合系統(tǒng)的需求，不影響系統(tǒng)的業(yè)務(wù)，并且有相應的補救方法。4 輕微錯誤是表面化或微小的（提示信息不太準確友好、不準確、誤導、錯別字、界面布局或罕見故障等），對功能幾乎沒有影響，產(chǎn)品及屬性仍可使用。5建議建設(shè)性的意見或建議。需求文檔沒有規(guī)定的特性，如果實現(xiàn)會對系統(tǒng)功能或者易用性有所提高。5.8 優(yōu)先級優(yōu)先級和嚴重程度有一定關(guān)系，但是不同于嚴重程度。嚴重程度表示對軟件系統(tǒng)功能的影響程度，而優(yōu)先級表明哪些缺陷應當盡早處理，反映了處置缺陷的時間安排。優(yōu)先級一般由測試人員建議，項目負責人確定。1緊急如果障礙相關(guān)開發(fā)人員

9、的進一步開發(fā)活動，應立即進行修復工作；如果阻止與此密切相關(guān)功能的進一步測試，應立即修復。一般嚴重程度是1的需要立刻處理。2必須的必須修改，發(fā)版前必須修正。3應該的必須修改，不一定馬上修改，但需確定在某個特定里版本發(fā)布前須修正4可選的如果時間允許應該修改5不需要允許不修改測試人員和項目負責人負責督促缺陷的修改進度。測試人員、測試經(jīng)理負責定期生成測試報告，統(tǒng)計該階段缺陷的登記和處置情況。5.9 缺陷來源來源說明需求需求描述不充分需求有歧義業(yè)務(wù)規(guī)則不完整流程環(huán)節(jié)描述不完整不合理的流程設(shè)計不正確的流程不恰當?shù)慕巧徽_的前后條件（輸入，輸出）功能描述不完整，不匹配補充規(guī)范描述不完整不一致的表述開發(fā)異常

10、處理不充分或不恰當結(jié)構(gòu)不當邏輯判斷不當對攻擊性的使用處理不足，例如無效數(shù)據(jù)，非法字符。變量定義和使用不當，例如作用域不當多余的循環(huán)和分支測試流程錯誤功能沒有完全測試補充規(guī)范（有效，格式等）沒有完全測試缺少工具和資源的使用規(guī)范使用了錯誤的環(huán)境（比如數(shù)據(jù)庫）其他文檔需求，設(shè)計，測試用例，測試計劃以外其他文檔建構(gòu)建構(gòu)過程導致的5.10 缺陷描述缺陷描述的要求為分類準確、敘述簡潔、步驟清楚、有實例、可再現(xiàn)、復雜問題有據(jù)可查（截圖或其它形式的附件）。具體要求為：ü 單一：盡量一個報告只針對一個軟件缺陷 ü 簡潔：每個步驟的描述應盡可能簡潔明了。只解釋事實、演示和描述軟件缺陷必要的細節(jié) ü 再現(xiàn)：必須描述重現(xiàn)的步驟和條件，比如具體輸入?yún)?shù)值，以便進行回歸驗證。如果能截圖就應當提供截圖。截圖文件不建議用BMP格式。ü 不能使用籠統(tǒng)的抽象詞句：比如“有錯誤”之類ü 問題描述一般格式：ü 可重現(xiàn)的步驟: 包括發(fā)生錯誤時的輸入值ü 期望結(jié)果ü 實際結(jié)果ü 其它信息，可依實際情況增加5.11 處理意見處置意見是缺陷負責人對缺陷處置結(jié)果的簡短描述。如果缺陷已經(jīng)修正解決，處置意見是“已修正”，對于否決的缺陷，處置意見參考4.4