缺陷管理規(guī)程

缺陷管理規(guī)程PAGE南方電力集團(tuán)科技發(fā)展有限公司第9頁共9頁密級(jí)：內(nèi)部公開文檔編號(hào)：版本號(hào)：V0.1缺陷管理規(guī)程編制：生效日期：2010年12月14日審核：批準(zhǔn)：日期版本號(hào)修訂說明修訂人審核人批準(zhǔn)人2010-12-14V0.1初稿劉會(huì)林

目錄1. 目的 42. 角色與職責(zé) 43. 入口準(zhǔn)則 44. 輸入 45. 主要步驟 45.1. 定義缺陷 45.1.1缺陷屬性 55.1.2缺陷類型 55.1.3缺陷嚴(yán)重程度 55.1.4缺陷優(yōu)先級(jí) 65.1.5缺陷狀態(tài) 65.1.6缺陷發(fā)現(xiàn)的階段 65.1.7缺陷引入的活動(dòng) 65.2. 缺陷管理流程 75.3. 缺陷報(bào)告 85.4. 遺留缺陷跟蹤 85.5. 缺陷分析 96. 輸出 97. 出口準(zhǔn)則 98. 引用文檔 99. 使用模板 9

目的缺陷管理的最終目標(biāo)是最大限度地減少缺陷的出現(xiàn)率，從而提高軟件產(chǎn)品的質(zhì)量。細(xì)分為：1）從缺陷發(fā)生到結(jié)束的全生命周期進(jìn)行跟蹤管理，盡可能發(fā)現(xiàn)所有的缺陷，確保每個(gè)被發(fā)現(xiàn)的缺陷都能夠被解決；2）收集缺陷數(shù)據(jù)并根據(jù)缺陷趨勢圖識(shí)別測試過程的階段；可以通過缺陷趨勢圖來確定測試過程是否結(jié)束；3）在已收集到的缺陷數(shù)據(jù)的基礎(chǔ)上進(jìn)行統(tǒng)計(jì)分析?？偨Y(jié)缺陷出現(xiàn)的原因、類型和規(guī)律，采取相應(yīng)措施避免該類型缺陷再次出現(xiàn)，并在開發(fā)過程的早期階段予以確定，起到缺陷預(yù)防的作用，并作為組織的過程財(cái)富。本規(guī)程規(guī)定了缺陷管理流程以及缺陷統(tǒng)計(jì)分析要求，項(xiàng)目組必須嚴(yán)格遵循本規(guī)程要求保證在較短的時(shí)間內(nèi)高效率地解決所有缺陷，縮短軟件開發(fā)測試進(jìn)程，提高軟件質(zhì)量，減少開發(fā)和維護(hù)成本。角色與職責(zé)角色職責(zé)項(xiàng)目經(jīng)理評(píng)審缺陷QA提交、評(píng)審缺陷測試工程師提交，驗(yàn)證缺陷項(xiàng)目組成員修改缺陷CM工程師在缺陷管理中受控已解決的配置項(xiàng)入口準(zhǔn)則缺陷發(fā)生時(shí)輸入無主要步驟定義缺陷是對(duì)軟件產(chǎn)品預(yù)期屬性的偏離現(xiàn)象。它包括檢測缺陷和殘留缺陷。每一個(gè)軟件組織都知道必須妥善處理軟件中的缺陷。這是關(guān)系到軟件組織生存、發(fā)展的質(zhì)量根本。5.1.1缺陷屬性屬性名稱描述缺陷標(biāo)識(shí)缺陷標(biāo)識(shí)是標(biāo)記某個(gè)缺陷的一組符號(hào)。每個(gè)缺陷必須有一個(gè)唯一的標(biāo)識(shí)。缺陷類型缺陷類型是根據(jù)缺陷的自然屬性劃分的缺陷種類。缺陷嚴(yán)重程度缺陷嚴(yán)重程度是指因缺陷引起的故障對(duì)軟件產(chǎn)品的影響程度。缺陷優(yōu)先級(jí)缺陷的優(yōu)先級(jí)指缺陷必須被修復(fù)的緊急程度。缺陷狀態(tài)缺陷狀態(tài)指缺陷通過一個(gè)跟蹤修復(fù)過程的進(jìn)展情況。缺陷發(fā)現(xiàn)的階段缺陷來源指缺陷引起的故障或事件第一次被檢測到的階段。缺陷引入的活動(dòng)缺陷來源指引起缺陷的起因。5.1.2缺陷類型缺陷類型編號(hào)缺陷類型描述10功能影響了重要的特性、用戶界面、產(chǎn)品接口、硬件結(jié)構(gòu)接口和全局?jǐn)?shù)據(jù)結(jié)構(gòu)。并且設(shè)計(jì)文檔需要正式的變更。如邏輯，指針，循環(huán)，遞歸，功能等缺陷。20邏輯需要修改少量代碼，如初始化或控制塊。如聲明、重復(fù)命名，范圍、限定等缺陷。30接口與其他組件、模塊或設(shè)備驅(qū)動(dòng)程序、調(diào)用參數(shù)、控制塊或參數(shù)列表相互影響的缺陷。40標(biāo)準(zhǔn)編碼/文檔的標(biāo)準(zhǔn)問題，例如縮進(jìn)、對(duì)齊方式、布局、組件應(yīng)用、編碼和拼寫錯(cuò)誤等50性能處理速度慢、因文件的大小而導(dǎo)致系統(tǒng)崩潰等60語法不符合所用程序設(shè)計(jì)語言的語法規(guī)則70設(shè)計(jì)缺陷設(shè)計(jì)錯(cuò)誤。5.1.3缺陷嚴(yán)重程度#缺陷嚴(yán)重等級(jí)描述1致命缺陷不能執(zhí)行正常工作功能或重要功能?；蛘呶＜叭松戆踩?嚴(yán)重缺陷嚴(yán)重地影響系統(tǒng)要求或基本功能的實(shí)現(xiàn)，且沒有辦法更正。（重新安裝或重新啟動(dòng)該軟件不屬于更正辦法）3一般缺陷比較嚴(yán)重地影響系統(tǒng)要求或基本功能的實(shí)現(xiàn)，但存在合理的更正辦法。（重新安裝或重新啟動(dòng)該軟件不屬于更正辦法）4輕微缺陷使操作者不方便或遇到麻煩，但它不影響執(zhí)行工作功能或重要功能。5建議其它錯(cuò)誤。5.1.4缺陷優(yōu)先級(jí)#缺陷優(yōu)先級(jí)描述1立即解決缺陷必須被立即解決。2高優(yōu)先級(jí)在立即解決之后,要解決的,不用排隊(duì),如果發(fā)現(xiàn)要立即解決的3正常排隊(duì)缺陷需要正常排隊(duì)等待修復(fù)或列入軟件發(fā)布清單。4低優(yōu)先級(jí)缺陷可以在方便時(shí)被糾正。5.1.5缺陷狀態(tài)缺陷狀態(tài)描述Submitted已提交的缺陷Open確認(rèn)“提交的缺陷”，等待處理Rejected拒絕“提交的缺陷”，不需要修復(fù)或不是缺陷Resolved缺陷被修復(fù)Configed缺陷涉及到的代碼被受控Reopen缺陷未通過驗(yàn)證Verify缺陷驗(yàn)證通過Closed確認(rèn)被修復(fù)的缺陷，將其關(guān)閉5.1.6缺陷發(fā)現(xiàn)的階段缺陷起源描述需求階段在需求階段發(fā)現(xiàn)的缺陷設(shè)計(jì)階段在設(shè)計(jì)階段發(fā)現(xiàn)的缺陷編碼階段在編碼階段發(fā)現(xiàn)的缺陷測試階段在測試階段發(fā)現(xiàn)的缺陷發(fā)布階段在發(fā)布階段發(fā)現(xiàn)的缺陷發(fā)布后在產(chǎn)品發(fā)布給客戶之后5.1.7缺陷引入的活動(dòng)缺陷來源描述需求由于需求的問題引起的缺陷構(gòu)架由于構(gòu)架的問題引起的缺陷設(shè)計(jì)由于設(shè)計(jì)的問題引起的缺陷編碼由于編碼的問題引起的缺陷測試由于測試的問題引起的缺陷集成由于集成的問題引起的缺陷缺陷管理流程 對(duì)于缺陷管理（注1），從發(fā)現(xiàn)缺陷到最終解決的流程圖如下：圖4-2缺陷管理流程圖【注1】可以手工管理，也可以采用自動(dòng)化的bug管理工具進(jìn)行管理。例如bugzilla等開源的bug管理工具。（1）缺陷的提交發(fā)現(xiàn)的缺陷均提交給項(xiàng)目內(nèi)指定人員（可以是項(xiàng)目經(jīng)理或者開發(fā)經(jīng)理），缺陷的狀態(tài)為：NEW,由指定人員進(jìn)行評(píng)審、分配。提交缺陷必須填寫：缺陷的描述、優(yōu)先級(jí)、嚴(yán)重性、缺陷的狀態(tài)、解決人、發(fā)現(xiàn)缺陷的階段，缺陷引入的階段等信息。這些信息由提交缺陷的人負(fù)責(zé)填寫。（2）缺陷的分配項(xiàng)目組內(nèi)對(duì)缺陷評(píng)審，決定缺陷計(jì)劃解決的版本、時(shí)間和負(fù)責(zé)人員。分配缺陷后的狀態(tài)可能為：Open&Rejected缺陷分配必須修改：缺陷的狀態(tài)、解決人、計(jì)劃關(guān)閉的版本和評(píng)審信息。這些信息由缺陷的解決人（一般是項(xiàng)目經(jīng)理、開發(fā)經(jīng)理或者是模塊負(fù)責(zé)人）負(fù)責(zé)填寫。（3）缺陷的解決缺陷由指定的開發(fā)人員解決后，經(jīng)過單元測試或代碼走查，填寫缺陷修改完成時(shí)間和缺陷處理結(jié)果描述。解決后的缺陷的狀態(tài)為：Resolved解決缺陷必須修改：缺陷的狀態(tài)、解決人、涉及到的代碼等信息。這些信息由解決缺陷的人（對(duì)應(yīng)的開發(fā)人員）負(fù)責(zé)填寫。（4）缺陷的代碼受控CM工程師篩選Resolved后的缺陷，將缺陷涉及到的代碼統(tǒng)一受控。受控后缺陷的狀態(tài)為：Configed受控缺陷必須修改：缺陷的狀態(tài)、解決人、涉及到的代碼等信息。這些信息由CM工程師負(fù)責(zé)填寫。（5）缺陷的驗(yàn)證測試工程師篩選狀態(tài)為Configed的缺陷，出產(chǎn)品包進(jìn)行驗(yàn)證測試。驗(yàn)證通過后狀態(tài)為：Verify否則為：Reopen缺陷的驗(yàn)證必須修改：缺陷的狀態(tài)、解決人、解決的版本等信息。這些信息由測試工程師負(fù)責(zé)填寫。（6）缺陷的關(guān)閉經(jīng)過驗(yàn)證后的缺陷由測試專員關(guān)閉，狀態(tài)為Closed。缺陷驗(yàn)證后的關(guān)閉必須修改：缺陷的狀態(tài)、實(shí)際關(guān)閉缺陷的版本、解決的版本等信息。這些信息由測試專員負(fù)責(zé)填寫。缺陷報(bào)告階段性的測試完成后，測試工程師將該階段發(fā)現(xiàn)的缺陷進(jìn)行統(tǒng)計(jì)分析，可以作為測試報(bào)告的一部分，包括：缺陷的數(shù)量、缺陷類型分類、缺陷分類百分比等。遺留缺陷跟蹤跟蹤遺留缺陷對(duì)于讓步發(fā)布的產(chǎn)品，需要跟蹤產(chǎn)品發(fā)布后的運(yùn)行情況。對(duì)遺留的缺陷跟蹤記錄并分析其影響范圍，直到遺留缺陷形成解決結(jié)果。產(chǎn)品發(fā)布后發(fā)現(xiàn)的缺陷產(chǎn)品發(fā)布后的缺陷來源有：客戶服務(wù)部門客戶服務(wù)人員、咨詢實(shí)施部項(xiàng)目實(shí)施工程師、客戶、開發(fā)和測試人員。該類缺陷的發(fā)現(xiàn)后需要提交給項(xiàng)目組，納入缺陷管理，該類缺陷的發(fā)現(xiàn)階段標(biāo)識(shí)為“發(fā)布后”，便于分析原因。缺陷分析通