缺陷管理流程描述

1、在軟件的開發(fā)、評(píng)審、測(cè)試和使用的過程中，我們都可能面臨或碰到軟件產(chǎn)品沒有按 照設(shè)計(jì)要求運(yùn)行、使用不方便或在某種程度上不能滿足用戶的要求等此類問題，這些我們 可 以通稱為缺陷。軟件缺陷是軟件開發(fā)過程中的”副產(chǎn)品”。缺陷會(huì)存在于軟件產(chǎn)品的整個(gè)生命周期中： 可以是軟件代碼的問題、系統(tǒng)文檔（開發(fā)文檔和測(cè)試文檔等）存在的問題，或者是用戶的幫 助文檔和使用指南方面的問題等。測(cè)試是發(fā)現(xiàn)缺陷的主要手段，也是它的主要目的。測(cè)試活動(dòng)和開發(fā)活動(dòng)一樣，是項(xiàng)目 質(zhì)量保證不可或缺的重要部分。因此，對(duì)于測(cè)試活動(dòng)的主要產(chǎn)物：缺陷，我們需要建立一個(gè) 完善的缺陷管理流程，來對(duì)缺陷進(jìn)行報(bào)告、查詢、分類、跟蹤、處理和驗(yàn)證等。本文主要

2、針對(duì)在開發(fā)測(cè)試活動(dòng)中發(fā)現(xiàn)的缺陷，其相應(yīng)的缺陷管理流程以及在流程中主 要的缺陷狀態(tài)、參與缺陷的角色和缺陷相矢的主要活動(dòng)以及缺陷的等級(jí)分類等。缺陷狀態(tài)的主要處理過程:和缺陷相尖的角色：測(cè)試工程師：在這里主要是指發(fā)現(xiàn)和報(bào)告缺陷的測(cè)試人員。在一般流程中，他需要：，以及在build中的驗(yàn)證測(cè)試和后面正式版本的驗(yàn)證測(cè)試。開發(fā)工程師：這里主要指對(duì)這個(gè)缺陷進(jìn)行研究和修改的開發(fā)人員。同時(shí)，他需要對(duì) 修改后的缺陷在提交測(cè)試人員正式測(cè)試驗(yàn)證之前需要進(jìn)行驗(yàn)證測(cè)試。缺陷評(píng)審委員會(huì)：主要由項(xiàng)目經(jīng)理、測(cè)試經(jīng)理、質(zhì)量經(jīng)理、開發(fā)經(jīng)理以 及資深的 開發(fā)、測(cè)試工程師等組成。他們對(duì)缺陷進(jìn)行確認(rèn)以及將之分配給相應(yīng)的開發(fā)人員進(jìn) 行修改。

3、版本經(jīng)理：負(fù)責(zé)將已經(jīng)解決的缺陷相尖的配置信息融入到新的版本，提交新的測(cè) 試和相尖的驗(yàn)證測(cè)試。缺陷狀態(tài)的含義解釋：New （新缺陷）：軟件中新發(fā)現(xiàn)報(bào)告的缺陷，一般由測(cè)試人員提交。當(dāng)然也可 能 是開發(fā)人員自己在單元或代碼測(cè)試過程中提交，或從軟件使用的最終用戶或測(cè) 試現(xiàn) 場(chǎng)反饋得到的缺陷報(bào)告。Accepted （接受）：經(jīng)過缺陷評(píng)審委員會(huì)的確認(rèn)，認(rèn)為缺陷確實(shí)存在。Assign （分配）：將這個(gè)缺陷分配給相尖的開發(fā)人員來進(jìn)行修改。Open （打開）：處于這個(gè)狀態(tài)時(shí)，缺陷已經(jīng)被確認(rèn)并已經(jīng)分配給相尖的開發(fā)人員 進(jìn)行相尖的修改。Deliver （交付）：解決缺陷問題的方法已經(jīng)找到，并且已經(jīng)將修改后的代碼等

4、打 上標(biāo)簽，交付給版本經(jīng)理。Resolved （解決）：版本經(jīng)理將相矢的標(biāo)簽等融入某個(gè)build，交付給相尖的開 發(fā)小組進(jìn)行驗(yàn)證測(cè)試，測(cè)試通過，則缺陷狀態(tài)改為解決狀態(tài)。Fixed （已修改）：版本經(jīng)理將已經(jīng)解決的缺陷標(biāo)簽融入某個(gè)版本，交付給相矢的 測(cè)試小組進(jìn)行驗(yàn)證測(cè)試，測(cè)試通過，則缺陷狀態(tài)修改為已修改狀態(tài)。Closed （結(jié)束）：缺陷狀態(tài)處于已修改后，自動(dòng)變?yōu)榻Y(jié)束狀態(tài)。上面簡(jiǎn)單介紹的缺陷狀態(tài)是在缺陷管理過程中主要的狀態(tài)，或者是在缺陷處理順利時(shí)所 經(jīng)歷的狀態(tài)。實(shí)際上，缺陷還有其他一些其他的狀態(tài)，或者可以認(rèn)為是輔助的狀態(tài)5分別 是：Investigate （研究）：當(dāng)缺陷分配給開發(fā)人員時(shí)，開發(fā)人員

5、并不是都直接可以找 到相尖的解決方案的。開發(fā)人員需要對(duì)缺陷和引起缺陷的原因進(jìn)行調(diào)查研究，這時(shí) 候我們可以將缺陷狀態(tài)改為研究狀態(tài)。Query&Reply （詢問和回答）：負(fù)責(zé)缺陷修改的工程師認(rèn)為相尖的缺陷描述信息 不夠明確、或希望得到更多和缺陷相尖的配置和環(huán)境條件、或引起缺陷時(shí)系統(tǒng)產(chǎn)生 的調(diào)試命令和信息等ODeclined （拒絕）：缺陷評(píng)審委員會(huì)通過相尖的討論研究，認(rèn)為不是缺陷?；蛲?過開發(fā)人員的調(diào)查研究，認(rèn)為不是缺陷，開發(fā)人員可以將具體的理由加入到缺 陷描 述中，缺陷評(píng)審委員會(huì)根據(jù)此將缺陷狀態(tài)修改為拒絕狀態(tài)。Duplicate （重復(fù)）：缺陷評(píng)審委員會(huì)認(rèn)為這個(gè)缺陷和某個(gè)已經(jīng)提交的缺陷是同一

6、個(gè)問題，因此設(shè)置為重復(fù)狀態(tài)。Defferred （延期）：缺陷不在當(dāng)前版本解決。I-*/ IJ /缺陷的嚴(yán)重度和優(yōu)先級(jí)分類：缺陷的嚴(yán)重度指得是假如缺陷沒有修改， 由這個(gè)缺陷引發(fā)的問題對(duì)客戶的影 響程度。而缺陷的優(yōu)先級(jí)指得是解決這個(gè)缺陷需要的時(shí)間（或者在多少時(shí)間內(nèi)必須解決這個(gè)缺陷）。對(duì)于一個(gè)缺陷，我們首先會(huì)給它指定一個(gè)嚴(yán)重度，而后給出它的優(yōu)先 級(jí)。我們下面來簡(jiǎn)單介紹缺陷的嚴(yán)重度和優(yōu)先級(jí)的分類，提供一些分類的建議和思想。缺陷的嚴(yán)重度，我們可以通過1到4來劃分：*嚴(yán)重度1 最高級(jí)別：產(chǎn)品在正常的運(yùn)行環(huán)境下無法給用戶提供服務(wù)，并且沒有其他的工作方式來補(bǔ)救。我們可以將下面的問題定義為嚴(yán)重度1級(jí)：1 問題

7、會(huì)自發(fā)的影響系統(tǒng)的數(shù)據(jù)傳輸。2用戶使用正常的操作步驟，就會(huì)影響系統(tǒng)提供的服務(wù)。*嚴(yán)重度2高級(jí)別：極大的影響了系統(tǒng)提供給用戶的服務(wù)，有其他的工作方式來緩解這種影響。舉例：1.系統(tǒng)中的一些單板會(huì)自動(dòng)重啟，單沒有影響它們所提供的傳輸性能。2.用戶使用正常的命令，會(huì)導(dǎo)致系統(tǒng)重啟或掛起，但不影響系統(tǒng)的數(shù)據(jù)傳 輸。*嚴(yán)重度3中等級(jí)別：系統(tǒng)需要增強(qiáng)的或存在的一些缺陷，但有相應(yīng)的補(bǔ)救方法來解決這個(gè)缺陷o舉例：1.系統(tǒng)的一塊單板失效了，但系統(tǒng)沒有上報(bào)相應(yīng)的告警。2.功能特征設(shè)計(jì)不符合系統(tǒng)的需求，不影響系統(tǒng)的業(yè)務(wù)，并且有相應(yīng)的補(bǔ) 救 方法。*嚴(yán)重度4低級(jí)別：細(xì)小的問題，不需要補(bǔ)救方法或功能增強(qiáng)的請(qǐng)求。舉 例： 1-上報(bào)的信息不符合系統(tǒng)的需求，描述不精確或可能對(duì)用戶有些誤導(dǎo)。2. GUI界面問題，不精確或可能對(duì)用戶有些歧義。缺陷的優(yōu)先級(jí)，我們可以進(jìn)行下面的分類：*緊急的（Emergency）:缺陷會(huì)對(duì)系統(tǒng)弓|起重大問題，必須盡快解決。必須的（Must）:在客戶的下