缺陷管理規(guī)程

1、缺陷管理規(guī)程文檔版本號：文檔編號：江通服_TST_05文檔密級：內(nèi)部公開歸屬部門/項目：研發(fā)部編寫人：朱佳佳生效日期：2018-05-10版權(quán)信息本文件涉及之信息，屬江西省通信產(chǎn)業(yè)服務(wù)有限公司所有。未經(jīng)江西省通信產(chǎn)業(yè)服務(wù)有限公司允許，文件中的任何部分都不能以任何形式向第三方散發(fā)。文檔修訂記錄版本 號修訂日期修訂人修訂說 明修訂 狀態(tài)審核日期審核人批準(zhǔn)人2018-05-02朱佳佳新增缺 陷管理 規(guī)程A2018-05-02熊晴汝李偉2018-05-10朱佳佳評審并 發(fā)布止 式版本M2018-05-10熊晴汝李偉修訂狀態(tài)：A-增加，M-修改，D-刪除日期格式：YYYY-MM-DD1.目的缺陷管理的最

2、終目標(biāo)是最大限度地減少缺陷的出現(xiàn)率，從而提高軟件產(chǎn)品的質(zhì)量。 細(xì)分為：1）從缺陷發(fā)生到結(jié)束的全生命周期進(jìn)行跟蹤管理，盡可能發(fā)現(xiàn)所有的缺陷，確保每個被發(fā)現(xiàn)的缺陷都能夠被解決；2）收集缺陷數(shù)據(jù)并根據(jù)缺陷趨勢圖識別測試過程的階段；可以通過缺陷趨勢圖來確定測試過程是否結(jié)束；3） 在已收集到的缺陷數(shù)據(jù)的基礎(chǔ)上進(jìn)行統(tǒng)計分析?？偨Y(jié)缺陷出現(xiàn)的原因、 類型和規(guī)律，采取相應(yīng)措施避免該類型缺陷再次出現(xiàn)，并在開發(fā)過程的早期階段予以確定，起到缺陷預(yù)防的作用，并作為組織的過程財富。本規(guī)程規(guī)定了缺陷管理流程以及缺陷統(tǒng)計分析要求，項目組必須嚴(yán)格遵循本規(guī)程要求保證在較短的時間內(nèi)高效率地解決所有缺陷，縮短軟件開發(fā)測試進(jìn)程，提高軟

3、件質(zhì)量，減少開發(fā)和維護(hù)成本。2 .角色與職責(zé)角色職責(zé)項目經(jīng)理評審缺陷測試工程師提交，驗證缺陷軟件工程師修改缺陷CM工程師在缺陷管理中受控已解決的缺陷代碼3 .入口準(zhǔn)則缺陷發(fā)生時4 .輸入5.主要步驟1.1. 定義缺陷是對軟件產(chǎn)品預(yù)期屬性的偏離現(xiàn)象，它包括檢測缺陷和殘留缺陷。每一個軟件組織都知道必須妥善處理軟件中的缺陷。這是關(guān)系到軟件組織生存、發(fā)展的質(zhì)量根本。缺陷屬性屬性名稱描述缺陷標(biāo)識缺陷標(biāo)識是標(biāo)記某個缺陷的一組符號。每個缺陷必須有一個唯 一的標(biāo)識。缺陷類型缺陷類型是根據(jù)缺陷的自然屬性劃分的缺陷種類。缺陷嚴(yán)重程度缺陷嚴(yán)重程度是指因缺陷引起的故障對軟件產(chǎn)品的影響程度。缺陷優(yōu)先級缺陷的優(yōu)先級指缺陷

4、必須被修復(fù)的緊急程度。缺陷狀態(tài)缺陷狀態(tài)指缺陷通過一個跟蹤修復(fù)過程的進(jìn)展情況。缺陷發(fā)現(xiàn)的階段:指缺陷引起的故障或事件第一次被檢測到的階段。缺陷引入的階段指引入缺陷的階段。缺陷類型缺陷類型編號缺陷類型描述10功能影響了重要的特性、用戶界面、產(chǎn)品接口、硬件 結(jié)構(gòu)接口和全局?jǐn)?shù)據(jù)結(jié)構(gòu)。并且設(shè)計文檔需要正 式的變更。如邏輯，指針，循環(huán)，遞歸，功能等 缺陷。20邏輯需要修改少量代碼，如初始化或控制塊。 如聲明、 重復(fù)命名，范圍、限定等缺陷。30接口與其他組件、模塊或設(shè)備驅(qū)動程序、調(diào)用參數(shù)、 控制塊或參數(shù)列表相互影響的缺陷。40標(biāo)準(zhǔn)編碼/文檔的標(biāo)準(zhǔn)問題，例如縮進(jìn)、對齊方式、布 局、組件應(yīng)用、編碼和拼寫錯誤等。

5、50性能處理速度慢、因文件的大小而導(dǎo)致系統(tǒng)崩潰等。60:語法不符合所用程序設(shè)計語言的語法規(guī)則。70:設(shè)計缺陷設(shè)計錯誤、設(shè)計不符合用戶習(xí)慣等。缺陷嚴(yán)重程度序號缺陷嚴(yán)重等級描述1致命缺陷數(shù)據(jù)丟失，數(shù)據(jù)計算錯誤、數(shù)據(jù)傳遞錯誤、對數(shù)據(jù)庫造成破壞， 造成操作系統(tǒng)或其他支撐系統(tǒng)崩潰、 非正常關(guān)閉和非正常死機(jī)，不能執(zhí)行正常工作功能或重要功能。或者危及人身安全。2嚴(yán)重缺陷應(yīng)用系統(tǒng)崩潰、非正常關(guān)閉和無響應(yīng)，但沒有造成數(shù)據(jù)丟失。 系統(tǒng)的主要功能不能正確實現(xiàn)或不完整，嚴(yán)重地影響系統(tǒng)要求 或基本功能的實現(xiàn)，且沒有辦法更正。（重新安裝或重新啟動 該軟件不屬于更止辦法）3一般缺陷規(guī)定的非主要功能沒有實現(xiàn)或不完整、影響系統(tǒng)

6、的運行，設(shè)計 不合理造成性能低下，比較嚴(yán)重地影響系統(tǒng)要求或基本功能的 實現(xiàn)，但存在合理的更正辦法。（重新安裝或重新啟動該軟件 不屬,更止辦法）4輕微缺陷使操作者不方便或遇到麻煩，但它不影響執(zhí)行工作功能或重要 功能。5建議（非缺陷）從用戶角度考慮在軟件設(shè)計和功能實現(xiàn)等不完全合理之處提出 建議。缺陷優(yōu)先級序號缺陷優(yōu)先級描述1立即解決立即解決是指缺陷導(dǎo)致系統(tǒng)幾乎不能使用或者測 試不能繼續(xù)，需立即修復(fù)2高優(yōu)先級高優(yōu)先級是指缺陷嚴(yán)重影響測試，需要優(yōu)先考慮3正常排隊正常排隊是指缺陷需要正常排隊等待修復(fù)；。4低優(yōu)先級而低優(yōu)先級是指缺陷可以在開發(fā)人員有時間的時 候再被糾正般地，嚴(yán)重程度高的軟件缺陷具有較高的優(yōu)

7、先級，但是嚴(yán)重程度和優(yōu)先級并不總是一對應(yīng)。有時候嚴(yán)重程度高的軟件缺陷，優(yōu)先級不一定高，甚至不需要處理，而一些嚴(yán)重程度低的缺陷卻需要及時處理，反而具有較高的優(yōu)先級。例如，公司名字和軟件產(chǎn)品徽標(biāo)是重要的，一旦它們誤用了，這種缺陷是用戶界面的產(chǎn)品缺陷，并不影響用戶使用。但是它影響公司形象和產(chǎn)品形象，因此這也是優(yōu)先級高的軟件缺陷。缺陷狀態(tài)缺陷狀態(tài)描述New已提交的缺陷Open確認(rèn)“提交的缺陷”，等待處理Rejected小于解決，不需要修復(fù)或小是缺陷Fixed缺陷被修復(fù)Reopen缺陷未通過驗證Closed確認(rèn)被修復(fù)的缺陷，將其關(guān)閉tostory轉(zhuǎn)為需求缺陷發(fā)現(xiàn)的階段缺陷起源描述需求階段在需求階段發(fā)現(xiàn)的

8、缺陷設(shè)計階段在設(shè)計階段發(fā)現(xiàn)的缺陷編碼階段在編碼階段發(fā)現(xiàn)的缺陷集成測試階段P在集成測試階段發(fā)現(xiàn)的缺陷系統(tǒng)測試階段在系統(tǒng)測試階段發(fā)現(xiàn)的缺陷驗收測試階段:在驗收測試階段發(fā)現(xiàn)的缺陷維護(hù)階段在維護(hù)階段發(fā)現(xiàn)的缺陷缺陷引入的階段缺陷引入階段描述需求階段:需求階段引起的缺陷設(shè)計階段設(shè)計階段引起的缺陷編碼階段編碼階段引起的缺陷1.2. 缺陷管理流程對于缺陷管理（注1）,從發(fā)現(xiàn)缺陷到最終解決的流程圖如下:缺缺缺缺缺缺缺缺缺缺缺缺缺缺缺缺缺缺缺缺缺缺缺CM缺缺缺缺缺缺 An An An An4缺缺缺缺 缺2缺缺缺缺缺缺缺缺 An An An An缺缺缺缺 An An An An缺缺缺缺缺Rejected 缺缺缺An

9、 An1缺缺缺缺缺New缺圖1缺陷管理流程圖【注1】可以采用自動化的 BUG管理工具進(jìn)行管理， 例如公司的BUG追蹤系統(tǒng)，生成缺陷(1)缺陷的提交發(fā)現(xiàn)的缺陷均提交給項目內(nèi)指定人員，缺陷的狀態(tài)為：New由指定人員進(jìn)行評審、分配。提交缺陷必須填寫：缺陷的描述、優(yōu)先級、嚴(yán)重性、缺陷的狀態(tài)、解決人、發(fā)現(xiàn)缺陷的 階段，缺陷引入的階段等信息。這些信息由提交缺陷的人負(fù)責(zé)填寫。測試人員登錄BUG追蹤系統(tǒng)，將缺陷的信息錄入，然后提交給項目經(jīng)理審核。(2)缺陷的分配項目組內(nèi)對缺陷評審，決定缺陷計劃解決的版本、時間和負(fù)責(zé)人員。分配缺陷后的狀態(tài)可能為：Open & Rejected缺陷分配必須修改：缺陷的狀態(tài)

10、、解決人、計劃關(guān)閉的版本和評審信息。這些信息由缺陷的解決人(一般是項目經(jīng)理、開發(fā)經(jīng)理或者是模塊負(fù)責(zé)人)負(fù)責(zé)填寫。項目經(jīng)理登錄BUG追蹤系統(tǒng)，接到測試人員提交的缺陷信息，對缺陷進(jìn)行評審，如果評審缺陷通過，則該缺陷的狀態(tài)變?yōu)?Open,項目經(jīng)理將該缺陷分配給開發(fā)人員解決；如果 評審缺陷不通過，則該缺陷的狀態(tài)變?yōu)?Rejected,該缺陷不能作為缺陷進(jìn)入缺陷管理流程。(3)缺陷的解決缺陷由指定的開發(fā)人員解決后，經(jīng)過單元測試或代碼走查，填寫缺陷修改完成時間和缺陷處理結(jié)果描述。解決后的缺陷的狀態(tài)為：Fixed解決缺陷必須修改：缺陷的狀態(tài)、解決人、涉及到的代碼等信息。這些信息由解決缺陷 的人負(fù)責(zé)填寫。開發(fā)

11、人員登錄BUG追蹤系統(tǒng)，修復(fù)該缺陷后，填寫該缺陷的基本信息，缺陷狀態(tài)變?yōu)镕ixed ,提交給CM工程師。(4)缺陷的關(guān)閉經(jīng)過驗證后的缺陷由測試專員關(guān)閉，狀態(tài)為Closed,否則為：Reopen缺陷的驗證必須修改：缺陷的狀態(tài)、解決人、解決的版本等信息。這些信息由測試工程 師負(fù)責(zé)填寫。缺陷驗證后的關(guān)閉必須修改：缺陷的狀態(tài)、實際關(guān)閉缺陷的版本、解決的版本等信息。這些信息由測試專員負(fù)責(zé)填寫。測試工程師登錄 BUG追蹤系統(tǒng)，對狀態(tài)為 Fixed的缺陷進(jìn)行驗證，通過驗證，缺陷狀 態(tài)變?yōu)镃losed,否則狀態(tài)變?yōu)?Reopen,提交給開發(fā)人員重新修復(fù)。1.3. 缺陷報告階段性的測試完成后，測試工程師將該階段發(fā)現(xiàn)的缺陷進(jìn)行統(tǒng)計分析，可以作為測試報告的一部分，包括：缺陷的數(shù)量、缺陷類型分類、缺陷分類百分比等。1.4. 遺留缺陷跟蹤跟蹤遺留缺陷對于發(fā)布的產(chǎn)品，需要跟蹤產(chǎn)品發(fā)布后的運行情況。對遺留的缺陷跟蹤記錄并分析其影響范圍，直到遺留缺陷形成解決結(jié)果。產(chǎn)品發(fā)布后發(fā)現(xiàn)的缺陷產(chǎn)品發(fā)布后的缺陷來源有：客戶服務(wù)部門客戶服務(wù)人員、咨詢實施部項目實施工程師、客戶、開發(fā)和測試人員。該類缺陷發(fā)現(xiàn)后需要提交給項目組，納入缺陷管理，該類缺陷的發(fā)現(xiàn)階段標(biāo)識為“發(fā)布后”，便于分析原因。1.5. 缺陷分析通過缺陷的數(shù)據(jù)分析， 總結(jié)缺陷出現(xiàn)的原因、類型和規(guī)