基于缺陷模式的軟件測(cè)試(第12章)課件

1、1第12章基于缺陷模式的軟件測(cè)試 2內(nèi)容提要12.1概述12.1.1 相關(guān)定義12.1.2 軟件缺陷的產(chǎn)生原因12.1.3 減少缺陷的關(guān)鍵因素12.1.4 軟件缺陷的特征12.2軟件缺陷屬性12.2.1 缺陷類型12.2.2 缺陷嚴(yán)重程度12.2.3 同行評(píng)審錯(cuò)誤嚴(yán)重程度12.2.4 缺陷優(yōu)先級(jí)12.2.5 缺陷狀態(tài)12.2.6 缺陷起源12.2.7 缺陷來(lái)源12.2.8 缺陷根源3內(nèi)容提要12.3軟件缺陷的嚴(yán)重性和優(yōu)先級(jí)12.3.1 缺陷的嚴(yán)重性和優(yōu)先級(jí)的關(guān)系12.3.2 處理缺陷的嚴(yán)重性和優(yōu)先級(jí)的常見錯(cuò)誤12.3.3 缺陷的嚴(yán)重性和優(yōu)先級(jí)的表示和確定12.4 軟件缺陷管理和CMM的關(guān)系12

2、.4.1 初始級(jí)的缺陷管理12.4.2 可重復(fù)級(jí)的缺陷管理12.4.3 已定義級(jí)的缺陷管理12.4.4 定量管理級(jí)的缺陷管理12.4.5 持續(xù)優(yōu)化級(jí)的缺陷管理4內(nèi)容提要12.5 報(bào)告軟件缺陷12.5.1 報(bào)告軟件缺陷的基本原則12.5.2 IEEE軟件缺陷報(bào)告模板12.6軟件缺陷管理12.6.1 缺陷管理目標(biāo)12.6.2 人員職責(zé)12.6.3 缺陷生命周期12.6.4 缺陷管理系統(tǒng)12.7軟件缺陷分析12.7.1 缺陷分析方法12.7.2 缺陷分析指標(biāo)12.8小結(jié)512.1概述軟件業(yè)的發(fā)展推動(dòng)了社會(huì)經(jīng)濟(jì)的快速發(fā)展，但是軟件質(zhì)量卻變得越來(lái)越難以控制。從某種程度上說(shuō)，軟件產(chǎn)品的競(jìng)爭(zhēng)力已經(jīng)不完全取決

3、于技術(shù)的先進(jìn)，更重要的是取決于軟件質(zhì)量的穩(wěn)定。然而對(duì)于軟件開發(fā)而言軟件缺陷始終是不可避免的，為此付出的代價(jià)和成本是巨大的。研究表明，大約有60%的錯(cuò)誤是在設(shè)計(jì)階段之前注入的，并且修正一個(gè)軟件錯(cuò)誤所需要的費(fèi)用將隨著軟件生存期的進(jìn)展而上升。錯(cuò)誤發(fā)現(xiàn)得越晚，修復(fù)它的費(fèi)用就越高，而且呈指數(shù)上升的趨勢(shì)。在軟件的編碼測(cè)試階段遺漏編碼缺陷，如果到系統(tǒng)測(cè)試時(shí)才發(fā)現(xiàn)，那么這時(shí)糾正缺陷所花費(fèi)的成本是在編碼階段糾錯(cuò)花費(fèi)的成本的7倍以上，而且測(cè)試后程序中殘存的錯(cuò)誤數(shù)目與該程序中已發(fā)現(xiàn)的錯(cuò)誤數(shù)目（即檢錯(cuò)率）很可能成正比。712.1.1 相關(guān)定義軟件錯(cuò)誤：軟件錯(cuò)誤是指在軟件生存期內(nèi)的不希望或不可接受的人為錯(cuò)誤，其結(jié)果是導(dǎo)

4、致軟件缺陷的產(chǎn)生?？梢?，軟件錯(cuò)誤是一種人為過(guò)程，相對(duì)于軟件本身，是一種外部行為。軟件缺陷：軟件缺陷是存在于軟件（文檔，數(shù)據(jù)或程序）之中的那些不希望或不可接受的偏差。其結(jié)果是軟件運(yùn)行于某一特定條件時(shí)出現(xiàn)軟件故障，這時(shí)稱軟件缺陷被激活。軟件故障：軟件故障是指軟件運(yùn)行過(guò)程中出現(xiàn)的一種不希望或不可接受的內(nèi)部狀態(tài)。比如：軟件處于執(zhí)行一個(gè)多余循還過(guò)程時(shí)，我們說(shuō)軟件出現(xiàn)故障。若此時(shí)沒(méi)有適當(dāng)?shù)拇胧ㄈ蒎e(cuò)）加以處理，便產(chǎn)生軟件失效。軟件故障是一種動(dòng)態(tài)行為。軟件失效：軟件失效是指軟件運(yùn)行時(shí)產(chǎn)生的一種不希望或不可接受的外部行為結(jié)果。 軟件失效機(jī)理8軟件缺陷管理：在軟件開發(fā)過(guò)程中對(duì)所發(fā)現(xiàn)的缺陷進(jìn)行跟蹤并確保每個(gè)被發(fā)現(xiàn)

5、的軟件缺陷被關(guān)閉。邏輯上僅有2種方法應(yīng)用于開發(fā)低缺陷的軟件缺陷預(yù)防缺陷排除1012.1.3 減少缺陷的關(guān)鍵因素軟件在版本發(fā)布后發(fā)現(xiàn)和解決一個(gè)軟件存在的問(wèn)題所需的費(fèi)用，通常要比在需求和設(shè)計(jì)階段發(fā)現(xiàn)、解決問(wèn)題高出約100倍；當(dāng)前的軟件項(xiàng)目約40%到50%的費(fèi)用花費(fèi)在可以避免的重復(fù)工作上；大約80%的可避免的重復(fù)工作產(chǎn)生于20%的缺陷；大約的80%缺陷產(chǎn)生于20%的模塊，約一半的模塊缺陷是很少的；大約的90%軟件故障來(lái)來(lái)自于的10%缺陷；有效的審核可以找出約60%的缺陷；有的目的性審核能夠比無(wú)方向的審核多捕獲約35%的缺陷；人員的專業(yè)性訓(xùn)練可減少高達(dá)約75%的缺陷出現(xiàn)率；同等情況下，開發(fā)高可信賴的軟

6、件產(chǎn)品與開發(fā)低可信賴的軟件產(chǎn)品相比，成本要高出近50%。然而，如果考慮到軟件項(xiàng)目的運(yùn)行和維護(hù)成本的話，這種投資是完全值得的；大約40%到50%的用戶程序都包含有非常細(xì)小的缺陷。1112.1.4 軟件缺陷的特征1、缺陷的發(fā)生都是有原因的2、缺陷的重現(xiàn)性3、缺陷的累積性、放大性（見下頁(yè)圖所示）4、缺陷的修復(fù)可能又引進(jìn)新的缺陷12典型瀑布模型的軟件缺陷的累積和放大效應(yīng)14缺陷標(biāo)識(shí)（Identifier）：缺陷標(biāo)識(shí)是標(biāo)記某個(gè)缺陷的一組符號(hào)。每個(gè)缺陷必須有一個(gè)唯一的標(biāo)識(shí)；缺陷類型 （Type）：缺陷類型是根據(jù)缺陷的自然屬性劃分的缺陷種類，一般包括功能缺陷、用戶界面缺陷、文檔缺陷、軟件配置缺陷、性能缺陷、

7、系統(tǒng)/模塊接口缺陷等；缺陷嚴(yán)重程度 （Severity）：缺陷嚴(yán)重程度是指因缺陷引起的故障對(duì)軟件產(chǎn)品的影響程度；缺陷優(yōu)先級(jí)（Priority）：缺陷的優(yōu)先級(jí)指缺陷必須被修復(fù)的緊急程度；缺陷狀態(tài)（Status）：缺陷狀態(tài)指缺陷通過(guò)一個(gè)跟蹤修復(fù)過(guò)程的進(jìn)展情況；缺陷起源（Origin）：缺陷來(lái)源指缺陷引起的故障或事件第一次被檢測(cè)到的階段；缺陷來(lái)源（Source）：缺陷來(lái)源指引起缺陷的起因；缺陷根源（Root Cause）：缺陷根源指發(fā)生錯(cuò)誤的根本因素。1512.2.1 缺陷類型缺陷類型編號(hào)缺陷類型描述10F- Function影響了重要的特性、用戶界面、產(chǎn)品接口、硬件結(jié)構(gòu)接口和全局?jǐn)?shù)據(jù)結(jié)構(gòu)。并且設(shè)計(jì)

8、文檔需要正式的變更。如邏輯，指針，循環(huán)，遞歸，功能等缺陷。20A- Assignment需要修改少量代碼，如初始化或控制塊。如聲明、重復(fù)命名，范圍、限定等缺陷。30I- Interface與其他組件、模塊或設(shè)備驅(qū)動(dòng)程序、調(diào)用參數(shù)、控制塊或參數(shù)列表相互影響的缺陷。40C- Checking提示的錯(cuò)誤信息，不適當(dāng)?shù)臄?shù)據(jù)驗(yàn)證等缺陷。50B Build/package/merge由于配置庫(kù)、變更管理或版本控制引起的錯(cuò)誤。60D- Documentation影響發(fā)布和維護(hù)，包括注釋。70G- Algorithm算法錯(cuò)誤。80U-User Interface人機(jī)交互特性：屏幕格式，確認(rèn)用戶輸入，功能有效性

9、，頁(yè)面排版等方面的缺陷。90P-Performance不滿足系統(tǒng)可測(cè)量的屬性值，如：執(zhí)行時(shí)間，事務(wù)處理速率等。100N-Norms不符合各種標(biāo)準(zhǔn)的要求，如編碼標(biāo)準(zhǔn)、設(shè)計(jì)符號(hào)等。1712.2.3 同行評(píng)審錯(cuò)誤嚴(yán)重程度#缺陷嚴(yán)重等級(jí)描述1Major主要的，較大的缺陷2Minor次要的，小的缺陷1812.2.4 缺陷優(yōu)先級(jí)#缺陷優(yōu)先級(jí)描述1Resolve Immediately缺陷必須被立即解決。2Normal Queue缺陷需要正常排隊(duì)等待修復(fù)或列入軟件發(fā)布清單。3Not Urgent缺陷可以在方便時(shí)被糾正。1912.2.5 缺陷狀態(tài)缺陷狀態(tài)描述Submitted已提交的缺陷Open確認(rèn)“提交的缺

10、陷”，等待處理Rejected拒絕“提交的缺陷”，不需要修復(fù)或不是缺陷Resolved缺陷被修復(fù)Closed確認(rèn)被修復(fù)的缺陷，將其關(guān)閉2012.2.6 缺陷起源缺陷起源描述Requirement在需求階段發(fā)現(xiàn)的缺陷 Architecture在構(gòu)架階段發(fā)現(xiàn)的缺陷 Design在設(shè)計(jì)階段發(fā)現(xiàn)的缺陷 Code在編碼階段發(fā)現(xiàn)的缺陷 Test在測(cè)試階段發(fā)現(xiàn)的缺陷 2112.2.7 缺陷來(lái)源缺陷來(lái)源描述Requirement由于需求的問(wèn)題引起的缺陷 Architecture由于構(gòu)架的問(wèn)題引起的缺陷 Design由于設(shè)計(jì)的問(wèn)題引起的缺陷 Code由于編碼的問(wèn)題引起的缺陷 Test由于測(cè)試的問(wèn)題引起的缺陷 I

11、ntegration由于集成的問(wèn)題引起的缺陷 2212.2.8 缺陷根源缺陷原因描述目標(biāo)如：錯(cuò)誤的范圍，誤解了目標(biāo)，超越能力的目標(biāo)等；過(guò)程，工具和方法如：無(wú)效的需求收集過(guò)程，過(guò)時(shí)的風(fēng)險(xiǎn)管理過(guò)程，不適用的項(xiàng)目管理方法，沒(méi)有估算規(guī)程，無(wú)效的變更控制過(guò)程等。人如：項(xiàng)目團(tuán)隊(duì)職責(zé)交叉，缺乏培訓(xùn)。沒(méi)有經(jīng)驗(yàn)的項(xiàng)目團(tuán)隊(duì)，缺乏士氣和動(dòng)機(jī)不純等。缺乏組織和通訊如：缺乏用戶參與，職責(zé)不明確，管理失敗等。2412.3.1 缺陷的嚴(yán)重性和優(yōu)先級(jí)的關(guān)系嚴(yán)重性（Severity）顧名思義就是軟件缺陷對(duì)軟件質(zhì)量的破壞程度，反應(yīng)其對(duì)產(chǎn)品和用戶的影響，即此軟件缺陷的存在將對(duì)軟件的功能和性能產(chǎn)生怎樣的影響。在軟件測(cè)試中，軟件缺陷的

12、嚴(yán)重性的判斷應(yīng)該從軟件最終用戶的觀點(diǎn)做出判斷，即判斷缺陷的嚴(yán)重性要為用戶考慮，考慮缺陷對(duì)用戶使用造成的惡劣后果的嚴(yán)重性。優(yōu)先級(jí)表示修復(fù)缺陷的重要程度和應(yīng)該何時(shí)修復(fù)，是表示處理和修正軟件缺陷的先后順序的指標(biāo)，即哪些缺陷需要優(yōu)先修正，哪些缺陷可以稍后修正。確定軟件缺陷優(yōu)先級(jí)，更多的是站在軟件開發(fā)工程師的角度考慮問(wèn)題，因?yàn)槿毕莸男拚樞蚴莻€(gè)復(fù)雜的過(guò)程，有些不是純粹的技術(shù)問(wèn)題，而且開發(fā)人員更熟悉軟件代碼，能夠比測(cè)試工程師更清楚修正缺陷的難度和風(fēng)險(xiǎn)。2512.3.2 處理缺陷的嚴(yán)重性和優(yōu)先級(jí)的常見錯(cuò)誤正確處理缺陷的嚴(yán)重性和優(yōu)先級(jí)不是件非常容易的事情，對(duì)于經(jīng)驗(yàn)不很豐富的開發(fā)人員經(jīng)常會(huì)發(fā)生如下的情形：將比較

13、輕微的缺陷報(bào)告成較高級(jí)別的缺陷和高優(yōu)先級(jí)，夸大缺陷的嚴(yán)重程度，經(jīng)常給人“狼來(lái)了”的錯(cuò)覺，將影響軟件質(zhì)量的正確評(píng)估，也耗費(fèi)開發(fā)人員辨別和處理缺陷的時(shí)間。將很嚴(yán)重的缺陷報(bào)告成輕微缺陷和低優(yōu)先級(jí)，這樣可能掩蓋了很多嚴(yán)重的缺陷。如果在項(xiàng)目發(fā)布前，發(fā)現(xiàn)還有很多由于不正確分配優(yōu)先級(jí)造成的嚴(yán)重缺陷，將需要投入很多人力和時(shí)間進(jìn)行修正，影響軟件的正常發(fā)布?；蛘哌@些嚴(yán)重的缺陷成了“漏網(wǎng)之魚”，隨軟件一起發(fā)布出去，影響軟件的質(zhì)量和用戶的使用信心。2712.4 軟件缺陷管理和CMM的關(guān)系CMM 是指“軟件能力成熟度模型”，其英文全稱為Capability Maturity Model for Software，英文縮

14、寫為SW-CMM，簡(jiǎn)稱CMM。它是對(duì)于軟件組織在定義、實(shí)施、度量、控制和改善其軟件過(guò)程的實(shí)踐中各個(gè)發(fā)展階段的描述。CMM的核心是把軟件開發(fā)視為一個(gè)過(guò)程，并根據(jù)這一原則對(duì)軟件開發(fā)和維護(hù)，進(jìn)行過(guò)程監(jiān)控和研究，以使其更加科學(xué)化、標(biāo)準(zhǔn)化、使企業(yè)能夠更好地實(shí)現(xiàn)商業(yè)目標(biāo)。2812.4.1 初始級(jí)的缺陷管理處于CMM一級(jí)（或稱為初始級(jí)）的軟件組織，對(duì)軟件缺陷的管理無(wú)章可循。工程師們只是在發(fā)現(xiàn)缺陷后，修改相應(yīng)的軟件。通常，沒(méi)有人會(huì)去記錄自己發(fā)現(xiàn)的缺陷。也沒(méi)有人知道在新的軟件版本里，究竟糾正了哪些缺陷，還有哪些缺陷未被糾正。而且，只有在下一輪測(cè)試中才有可能知道那些所謂己被糾正了的缺陷是否真的被糾正了，更重要的是

15、糾正過(guò)程是否引入了新的缺陷。所以這樣的軟件組織的項(xiàng)目交貨期表現(xiàn)出強(qiáng)烈的不可預(yù)測(cè)性。并且，為了獲得一個(gè)高質(zhì)量的軟件產(chǎn)品（如果能夠的話），通常要在測(cè)試上花費(fèi)大量的人力。2912.4.2 可重復(fù)級(jí)的缺陷管理在 CMM 二級(jí)（或稱為可重復(fù)級(jí)）的軟件組織中，軟件項(xiàng)目會(huì)從自身的需要出發(fā)，制定本項(xiàng)目的缺陷管理過(guò)程。一個(gè)完備軟件缺陷管理過(guò)程通常會(huì)包括如下幾個(gè)方面：提交缺陷；分析和定位缺陷；提請(qǐng)修改相應(yīng)的軟件；修改相應(yīng)的軟件；驗(yàn)證修改。項(xiàng)目組會(huì)完整地記錄開發(fā)過(guò)程中的缺陷，監(jiān)控缺陷的修改過(guò)程，并驗(yàn)證修改缺陷的結(jié)果。3012.4.3 已定義級(jí)的缺陷管理CMM 三級(jí)（或稱為己定義級(jí)）的軟件組織會(huì)匯集組織內(nèi)部以前項(xiàng)目的

16、經(jīng)驗(yàn)教訓(xùn)，制定組織級(jí)的缺陷管理過(guò)程。并且，要求項(xiàng)目根據(jù)組織級(jí)的缺陷管理過(guò)程定制本項(xiàng)目的缺陷管理過(guò)程。從而，整個(gè)軟件組織中的項(xiàng)目都遵循類似的過(guò)程來(lái)管理缺陷。好的缺陷管理實(shí)踐成為所有項(xiàng)目的實(shí)踐，而教訓(xùn)也為所有項(xiàng)目所了解。更重要的是，隨著組織的不斷發(fā)展完善，組織的過(guò)程會(huì)得到持續(xù)性的改進(jìn)，所有項(xiàng)目的過(guò)程也都會(huì)相應(yīng)的改進(jìn)。3112.4.4 定量管理級(jí)的缺陷管理沒(méi)實(shí)現(xiàn)缺陷預(yù)防的缺陷密度CMM4（已管理級(jí)）：建立軟件過(guò)程能力基線3212.4.5 持續(xù)優(yōu)化級(jí)的缺陷管理實(shí)現(xiàn)了缺陷預(yù)防的缺陷密度CMM5（持續(xù)優(yōu)化級(jí)）：強(qiáng)調(diào)對(duì)組織的過(guò)程進(jìn)行持續(xù)性改進(jìn)3312.5 報(bào)告軟件缺陷12.5.1 報(bào)告軟件缺陷的基本原則準(zhǔn)確

17、報(bào)告軟件缺陷是非常重要的，因?yàn)椋呵逦鷾?zhǔn)確的軟件缺陷描述可以減少軟件缺陷從開發(fā)人員返回的數(shù)量；提高軟件缺陷修復(fù)的速度，使每一個(gè)小組能夠有效的工作；提高測(cè)試人員的信任度，可以得到開發(fā)人員對(duì)清晰的軟件缺陷描述有效的響應(yīng)；加強(qiáng)開發(fā)人員，測(cè)試人員和管理人員的協(xié)同工作，讓他們可以更好的工作；34軟件缺陷的有效描述規(guī)則軟件缺陷的有效描述規(guī)則，主要包括：?jiǎn)我粶?zhǔn)確。每個(gè)報(bào)告只針對(duì)一個(gè)軟件缺陷。在一個(gè)報(bào)告中報(bào)告多個(gè)軟件缺陷的弊端是常常會(huì)導(dǎo)致缺陷部分被注意和修復(fù)，不能得到徹底的修正。可以再現(xiàn)。提供缺陷的精確操作步驟，使開發(fā)人員容易看懂，可以自己再現(xiàn)這個(gè)缺陷，通常情況下，開發(fā)人員只有再現(xiàn)了缺陷，才能正確地修復(fù)缺陷。完

18、整統(tǒng)一。提供完整、前后統(tǒng)一的軟件缺陷的步驟和信息，例如：圖片信息，Log文件等。短小簡(jiǎn)練。通過(guò)使用關(guān)鍵詞，可以使軟件缺陷的標(biāo)題的描述短小簡(jiǎn)練，又能準(zhǔn)確解釋產(chǎn)生缺陷的現(xiàn)象。如“主頁(yè)的導(dǎo)航欄在低分辨率下顯示不整齊”中“主頁(yè)”、“導(dǎo)航欄”、“分辨率”等是關(guān)鍵詞。特定條件。許多軟件功能在通常情況下沒(méi)有問(wèn)題，而是在某種特定條件下會(huì)存在缺陷，所以軟件缺陷描述不要忽視這些看似細(xì)節(jié)的但又必要的特定條件（如特定的操作系統(tǒng)、瀏覽器或某種設(shè)置等），能夠提供幫助開發(fā)人員找到原因的線索。如“搜索功能在沒(méi)有找到結(jié)果返回時(shí)跳轉(zhuǎn)頁(yè)面不對(duì)”。補(bǔ)充完善。從發(fā)現(xiàn)bug那一刻起，測(cè)試人員的責(zé)任就是保證它被正確的報(bào)告，并且得到應(yīng)有的重

19、視，繼續(xù)監(jiān)視其修復(fù)的全過(guò)程。不做評(píng)價(jià)。在軟件缺陷描述不要帶有個(gè)人觀點(diǎn)，對(duì)開發(fā)人員進(jìn)行評(píng)價(jià)。軟件缺陷報(bào)告是針對(duì)產(chǎn)品、針對(duì)問(wèn)題本身，將事實(shí)或現(xiàn)象客觀地描述出來(lái)就可以，不需要任何評(píng)價(jià)或議論。3512.5.2 IEEE軟件缺陷報(bào)告模板3612.6軟件缺陷管理12.6.1 缺陷管理目標(biāo)由于不同的軟件開發(fā)組織在軟件開發(fā)過(guò)程、質(zhì)量保證體系的不同，缺陷管理的方式和處理流程也不盡相同。但其目的都是對(duì)各階段測(cè)試發(fā)現(xiàn)的缺陷進(jìn)行跟蹤管理，以保證各級(jí)缺陷的修復(fù)率達(dá)到標(biāo)準(zhǔn)。一般而言缺陷管理應(yīng)當(dāng)具有以下目標(biāo)：及時(shí)了解并跟蹤每個(gè)被發(fā)現(xiàn)的缺陷；確保每個(gè)被發(fā)現(xiàn)的缺陷都能夠被處理。這里處理的意思不一定是被修正，也可能是其他處理方式

20、（例如，在下一個(gè)版本中修正）。對(duì)于每個(gè)被發(fā)現(xiàn)的缺陷的處理方式應(yīng)當(dāng)在開發(fā)組織內(nèi)中達(dá)成一致。收集缺陷數(shù)據(jù)并根據(jù)缺陷趨勢(shì)曲線來(lái)識(shí)別測(cè)試過(guò)程是否結(jié)束。決定測(cè)試過(guò)程是否結(jié)束有很多種方式，通過(guò)缺陷趨勢(shì)曲線來(lái)確定測(cè)試過(guò)程是否結(jié)束是常用并且較為有效的一種方式。收集缺陷數(shù)據(jù)并在其上進(jìn)行數(shù)據(jù)分析，作為組織的過(guò)程財(cái)富。3712.6.2 人員職責(zé)參與缺陷管理過(guò)程人員角色包括項(xiàng)目經(jīng)理、項(xiàng)目測(cè)試負(fù)責(zé)人、測(cè)試人員、項(xiàng)目相關(guān)開發(fā)人員、質(zhì)量保證人員，其職責(zé)描述如下：項(xiàng)目經(jīng)理（PM）：負(fù)責(zé)指派缺陷給相關(guān)責(zé)任人。項(xiàng)目測(cè)試負(fù)責(zé)人（TM）:決定缺陷管理方式和工具，擬定決策評(píng)審計(jì)劃；管理所有缺陷關(guān)閉情況；審核測(cè)試人員提交的缺陷；對(duì)測(cè)試人

21、員的工作質(zhì)量進(jìn)行跟蹤與評(píng)價(jià)。測(cè)試人員（TE）負(fù)責(zé)報(bào)告系統(tǒng)缺陷記錄，且協(xié)助項(xiàng)目人員進(jìn)行缺陷定位；負(fù)責(zé)驗(yàn)證缺陷修復(fù)情況，且填寫缺陷記錄中相應(yīng)信息；負(fù)責(zé)執(zhí)行系統(tǒng)回歸測(cè)試；提交缺陷報(bào)告；負(fù)責(zé)被測(cè)軟件進(jìn)行質(zhì)量數(shù)據(jù)和分析。項(xiàng)目相關(guān)開發(fā)人員（DE）修改測(cè)試發(fā)現(xiàn)的缺陷，并提交成果物做再測(cè)試；負(fù)責(zé)接收各自的缺陷記錄，并且修改；負(fù)責(zé)提供缺陷記錄跟蹤中其它相應(yīng)信息。質(zhì)量保證人員（SQA）監(jiān)控項(xiàng)目組缺陷管理規(guī)程執(zhí)行情況。3812.6.3 缺陷生命周期軟件缺陷的狀態(tài)在其生命周期中變化如下：缺陷從隱藏在產(chǎn)品中被發(fā)現(xiàn)，這時(shí)缺陷狀態(tài)為“創(chuàng)建”。得到缺陷修復(fù)請(qǐng)求以后，開發(fā)經(jīng)理將缺陷修復(fù)任務(wù)分配給相應(yīng)的開發(fā)人員進(jìn)行修復(fù)，這時(shí)缺陷

22、的狀態(tài)變?yōu)椤耙逊峙洹?。開發(fā)人員得到缺陷修復(fù)任務(wù)以后，根據(jù)缺陷的描述重現(xiàn)缺陷的癥狀、修復(fù)缺陷，然后提交測(cè)試人員驗(yàn)證修改，這時(shí)缺席的狀態(tài)變?yōu)椤耙研迯?fù)”。測(cè)試人員驗(yàn)證修改的有效性，若缺陷的修正得到最終確認(rèn)，其狀態(tài)變?yōu)椤耙汛_認(rèn)”。最終缺陷提交者或者測(cè)試人員，關(guān)閉這個(gè)缺陷，結(jié)束其生命周期。這時(shí)缺陷狀態(tài)變?yōu)椤耙殃P(guān)閉”?；镜能浖毕萆芷?9實(shí)踐中的軟件缺陷生命周期 實(shí)踐中的軟件缺陷生命周期4012.6.4 缺陷管理系統(tǒng)缺陷管理系統(tǒng)是用來(lái)管理軟件缺陷整個(gè)生命的工作流系統(tǒng)，跟蹤缺陷從發(fā)生到被修正并發(fā)布的整個(gè)過(guò)程。它能夠加強(qiáng)缺陷修正的過(guò)程控制，是缺陷管理的實(shí)現(xiàn)工具。缺陷跟蹤系統(tǒng)能否成功的實(shí)施取決于相應(yīng)的缺陷

23、跟蹤流程的設(shè)計(jì)和軟件設(shè)計(jì)。其作用主要表現(xiàn)在：提高軟件缺陷報(bào)告的質(zhì)量。軟件缺陷報(bào)告的一致性和正確性是衡量軟件測(cè)試過(guò)程專業(yè)化程度的重要指標(biāo)之一。通過(guò)正確和完整填寫軟件缺陷管理系統(tǒng)提供的各項(xiàng)內(nèi)容，可以保證不同測(cè)試工程師的缺陷報(bào)告格式統(tǒng)一。實(shí)時(shí)管理和控制缺陷狀態(tài)。軟件缺陷查詢、篩選、排序、添加、修改保存、權(quán)限控制是缺陷管理系統(tǒng)的基本功能和主要優(yōu)勢(shì)。通過(guò)方便的數(shù)據(jù)庫(kù)查詢和分類篩選，便于迅速定位缺陷和統(tǒng)計(jì)缺陷的類型。通過(guò)權(quán)限設(shè)置，保證只有適當(dāng)權(quán)限的人才能修改或刪除軟件缺陷，確保了數(shù)據(jù)安全性。量化修復(fù)工作量。通過(guò)缺陷管理系統(tǒng)建立對(duì)缺陷數(shù)據(jù)的分析功能可以幫助軟件組織對(duì)員工績(jī)效、項(xiàng)目進(jìn)展情況等等進(jìn)行評(píng)估，幫助企業(yè)改進(jìn)軟件過(guò)程提高員工工作效率。確保每一個(gè)缺陷能被處理，避免缺陷被遺忘或信息丟失等情況的發(fā)生。提供解決問(wèn)題的知識(shí)，開發(fā)人員利用缺陷跟蹤系統(tǒng)，對(duì)已解決的問(wèn)題所采用方法進(jìn)行學(xué)習(xí)，提高軟件缺陷修復(fù)效率。BugzillaClearQuest41缺陷管理系統(tǒng)比較 工具名稱BugzillaClearQuest流程定制支持支持查詢功能支持支持郵件通知支持支持系統(tǒng)架構(gòu)B/SC/S，B/S支持平臺(tái)Linux，F(xiàn)reeBSD，WindowsUnix，Windows數(shù)據(jù)庫(kù)SQL ServerOacle，SQL Server復(fù)雜度簡(jiǎn)單復(fù)雜產(chǎn)品價(jià)格