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

1、12內(nèi)容提要內(nèi)容提要p12.1概述概述l12.1.1 相關(guān)定義l12.1.2 軟件缺陷的產(chǎn)生原因l12.1.3 減少缺陷的關(guān)鍵因素l12.1.4 軟件缺陷的特征p12.2軟件缺陷屬性軟件缺陷屬性l12.2.1 缺陷類型l12.2.2 缺陷嚴(yán)重程度l12.2.3 同行評(píng)審錯(cuò)誤嚴(yán)重程度l12.2.4 缺陷優(yōu)先級(jí)l12.2.5 缺陷狀態(tài)l12.2.6 缺陷起源l12.2.7 缺陷來源l12.2.8 缺陷根源3內(nèi)容提要內(nèi)容提要p12.3軟件缺陷的嚴(yán)重性和優(yōu)先級(jí)軟件缺陷的嚴(yán)重性和優(yōu)先級(jí)l12.3.1 缺陷的嚴(yán)重性和優(yōu)先級(jí)的關(guān)系l12.3.2 處理缺陷的嚴(yán)重性和優(yōu)先級(jí)的常見錯(cuò)誤l12.3.3 缺陷的嚴(yán)重性

2、和優(yōu)先級(jí)的表示和確定p12.4 軟件缺陷管理和軟件缺陷管理和CMM的關(guān)系的關(guān)系l12.4.1 初始級(jí)的缺陷管理l12.4.2 可重復(fù)級(jí)的缺陷管理l12.4.3 已定義級(jí)的缺陷管理l12.4.4 定量管理級(jí)的缺陷管理l12.4.5 持續(xù)優(yōu)化級(jí)的缺陷管理4內(nèi)容提要內(nèi)容提要p12.5 報(bào)告軟件缺陷報(bào)告軟件缺陷l12.5.1 報(bào)告軟件缺陷的基本原則l12.5.2 IEEE軟件缺陷報(bào)告模板p12.6軟件缺陷管理軟件缺陷管理l12.6.1 缺陷管理目標(biāo)l12.6.2 人員職責(zé)l12.6.3 缺陷生命周期l12.6.4 缺陷管理系統(tǒng)p12.7軟件缺陷分析軟件缺陷分析l12.7.1 缺陷分析方法l12.7.2

3、 缺陷分析指標(biāo)p12.8小結(jié)小結(jié)512.1概述概述p軟件業(yè)的發(fā)展推動(dòng)了社會(huì)經(jīng)濟(jì)的快速發(fā)展，但是軟件質(zhì)量軟件業(yè)的發(fā)展推動(dòng)了社會(huì)經(jīng)濟(jì)的快速發(fā)展，但是軟件質(zhì)量卻變得越來越難以控制。從某種程度上說，軟件產(chǎn)品的競卻變得越來越難以控制。從某種程度上說，軟件產(chǎn)品的競爭力已經(jīng)不完全取決于技術(shù)的先進(jìn)，更重要的是取決于軟爭力已經(jīng)不完全取決于技術(shù)的先進(jìn)，更重要的是取決于軟件質(zhì)量的穩(wěn)定。件質(zhì)量的穩(wěn)定。p然而對(duì)于軟件開發(fā)而言軟件缺陷始終是不可避免的，為此然而對(duì)于軟件開發(fā)而言軟件缺陷始終是不可避免的，為此付出的代價(jià)和成本是巨大的。付出的代價(jià)和成本是巨大的。l研究表明，大約有60%的錯(cuò)誤是在設(shè)計(jì)階段之前注入的，并且修正一個(gè)

4、軟件錯(cuò)誤所需要的費(fèi)用將隨著軟件生存期的進(jìn)展而上升。l錯(cuò)誤發(fā)現(xiàn)得越晚，修復(fù)它的費(fèi)用就越高，而且呈指數(shù)上升的趨勢(shì)。p在軟件的編碼測(cè)試階段遺漏編碼缺陷，如果到系統(tǒng)測(cè)試時(shí)在軟件的編碼測(cè)試階段遺漏編碼缺陷，如果到系統(tǒng)測(cè)試時(shí)才發(fā)現(xiàn)，那么這時(shí)糾正缺陷所花費(fèi)的成本是在編碼階段糾才發(fā)現(xiàn)，那么這時(shí)糾正缺陷所花費(fèi)的成本是在編碼階段糾錯(cuò)花費(fèi)的成本的錯(cuò)花費(fèi)的成本的7倍以上，而且測(cè)試后程序中殘存的錯(cuò)誤倍以上，而且測(cè)試后程序中殘存的錯(cuò)誤數(shù)目與該程序中已發(fā)現(xiàn)的錯(cuò)誤數(shù)目（即檢錯(cuò)率）很可能成數(shù)目與該程序中已發(fā)現(xiàn)的錯(cuò)誤數(shù)目（即檢錯(cuò)率）很可能成正比。正比。6殘存的錯(cuò)誤和已發(fā)現(xiàn)的錯(cuò)誤數(shù)目殘存的錯(cuò)誤和已發(fā)現(xiàn)的錯(cuò)誤數(shù)目的關(guān)系的關(guān)系 712

5、.1.1 相關(guān)定義相關(guān)定義p軟件錯(cuò)誤軟件錯(cuò)誤：軟件錯(cuò)誤是指在軟件生存期內(nèi)的不希望或不可接受：軟件錯(cuò)誤是指在軟件生存期內(nèi)的不希望或不可接受的人為錯(cuò)誤，其結(jié)果是導(dǎo)致軟件缺陷的產(chǎn)生?？梢?，軟件錯(cuò)誤的人為錯(cuò)誤，其結(jié)果是導(dǎo)致軟件缺陷的產(chǎn)生?？梢姡浖e(cuò)誤是一種人為過程，相對(duì)于軟件本身，是一種外部行為。是一種人為過程，相對(duì)于軟件本身，是一種外部行為。p軟件缺陷軟件缺陷：軟件缺陷是存在于軟件（文檔，數(shù)據(jù)或程序）之中：軟件缺陷是存在于軟件（文檔，數(shù)據(jù)或程序）之中的那些不希望或不可接受的偏差。其結(jié)果是軟件運(yùn)行于某一特的那些不希望或不可接受的偏差。其結(jié)果是軟件運(yùn)行于某一特定條件時(shí)出現(xiàn)軟件故障，這時(shí)稱軟件缺陷被激活

6、。定條件時(shí)出現(xiàn)軟件故障，這時(shí)稱軟件缺陷被激活。p軟件故障軟件故障：軟件故障是指軟件運(yùn)行過程中出現(xiàn)的一種不希望或：軟件故障是指軟件運(yùn)行過程中出現(xiàn)的一種不希望或不可接受的內(nèi)部狀態(tài)。比如：軟件處于執(zhí)行一個(gè)多余循還過程不可接受的內(nèi)部狀態(tài)。比如：軟件處于執(zhí)行一個(gè)多余循還過程時(shí)，我們說軟件出現(xiàn)故障。若此時(shí)沒有適當(dāng)?shù)拇胧ㄈ蒎e(cuò)）加時(shí)，我們說軟件出現(xiàn)故障。若此時(shí)沒有適當(dāng)?shù)拇胧ㄈ蒎e(cuò)）加以處理，便產(chǎn)生軟件失效。軟件故障是一種動(dòng)態(tài)行為。以處理，便產(chǎn)生軟件失效。軟件故障是一種動(dòng)態(tài)行為。p軟件失效軟件失效：軟件失效是指軟件運(yùn)行時(shí)產(chǎn)生的一種不希望或不可：軟件失效是指軟件運(yùn)行時(shí)產(chǎn)生的一種不希望或不可接受的外部行為結(jié)果。接

7、受的外部行為結(jié)果。 軟件失效機(jī)理8p軟件缺陷管理：在軟件開發(fā)過程中對(duì)所發(fā)軟件缺陷管理：在軟件開發(fā)過程中對(duì)所發(fā)現(xiàn)的缺陷進(jìn)行跟蹤并確保每個(gè)被發(fā)現(xiàn)的軟現(xiàn)的缺陷進(jìn)行跟蹤并確保每個(gè)被發(fā)現(xiàn)的軟件缺陷被關(guān)閉。件缺陷被關(guān)閉。p邏輯上僅有邏輯上僅有2種方法應(yīng)用于開發(fā)低缺陷的種方法應(yīng)用于開發(fā)低缺陷的軟件軟件l缺陷預(yù)防l缺陷排除912.1.2 軟件缺陷的產(chǎn)生原因軟件缺陷的產(chǎn)生原因p程序編寫錯(cuò)誤程序編寫錯(cuò)誤p編寫程序未按照規(guī)定編寫程序未按照規(guī)定p軟件越來越復(fù)雜軟件越來越復(fù)雜p開發(fā)人員的態(tài)度開發(fā)人員的態(tài)度p溝通上的問題溝通上的問題p需求變更太過頻繁需求變更太過頻繁p進(jìn)度上的壓力進(jìn)度上的壓力p管理上的失誤管理上的失誤系統(tǒng)

8、開發(fā)的三個(gè)平衡點(diǎn)1012.1.3 減少缺陷的關(guān)鍵因素減少缺陷的關(guān)鍵因素p軟件在版本發(fā)布后發(fā)現(xiàn)和解決一個(gè)軟件存在的問題所需的費(fèi)用，軟件在版本發(fā)布后發(fā)現(xiàn)和解決一個(gè)軟件存在的問題所需的費(fèi)用，通常要比在需求和設(shè)計(jì)階段發(fā)現(xiàn)、解決問題高出約通常要比在需求和設(shè)計(jì)階段發(fā)現(xiàn)、解決問題高出約100倍；倍；p當(dāng)前的軟件項(xiàng)目約當(dāng)前的軟件項(xiàng)目約40%到到50%的費(fèi)用花費(fèi)在可以避免的重復(fù)的費(fèi)用花費(fèi)在可以避免的重復(fù)工作上；工作上；p大約大約80%的可避免的重復(fù)工作產(chǎn)生于的可避免的重復(fù)工作產(chǎn)生于20%的缺陷；的缺陷；p大約的大約的80%缺陷產(chǎn)生于缺陷產(chǎn)生于20%的模塊，約一半的模塊缺陷是很的模塊，約一半的模塊缺陷是很少的；少

9、的；p大約的大約的90%軟件故障來來自于的軟件故障來來自于的10%缺陷；缺陷；p有效的審核可以找出約有效的審核可以找出約60%的缺陷；的缺陷；p有的目的性審核能夠比無方向的審核多捕獲約有的目的性審核能夠比無方向的審核多捕獲約35%的缺陷；的缺陷；p人員的專業(yè)性訓(xùn)練可減少高達(dá)約人員的專業(yè)性訓(xùn)練可減少高達(dá)約75%的缺陷出現(xiàn)率；的缺陷出現(xiàn)率；p同等情況下，開發(fā)高可信賴的軟件產(chǎn)品與開發(fā)低可信賴的軟件同等情況下，開發(fā)高可信賴的軟件產(chǎn)品與開發(fā)低可信賴的軟件產(chǎn)品相比，成本要高出近產(chǎn)品相比，成本要高出近50%。然而，如果考慮到軟件項(xiàng)目的。然而，如果考慮到軟件項(xiàng)目的運(yùn)行和維護(hù)成本的話，這種投資是完全值得的；運(yùn)行

10、和維護(hù)成本的話，這種投資是完全值得的；p大約大約40%到到50%的用戶程序都包含有非常細(xì)小的缺陷。的用戶程序都包含有非常細(xì)小的缺陷。1112.1.4 軟件缺陷的特征軟件缺陷的特征1、缺陷的發(fā)生都是有原因的2、缺陷的重現(xiàn)性3、缺陷的累積性、放大性（見下頁圖所示）4、缺陷的修復(fù)可能又引進(jìn)新的缺陷12典型瀑布模型的軟件缺陷的累積和放大效應(yīng)1312.2軟件缺陷屬性軟件缺陷屬性 認(rèn)識(shí)軟件缺陷，首先了解軟件缺陷的概念，軟件缺陷的描述方法，其次就是了解軟件缺陷的屬性。對(duì)于開發(fā)人員，需要定義軟件缺陷屬性，作為參考，按照優(yōu)先級(jí)、嚴(yán)重程度修復(fù)軟件缺陷，不至于遺漏嚴(yán)重的軟件缺陷。對(duì)于測(cè)試人員，利用軟件缺陷屬性可以跟

11、蹤軟件缺陷，保證軟件質(zhì)量。14p缺陷標(biāo)識(shí)（缺陷標(biāo)識(shí)（Identifier）：缺陷標(biāo)識(shí)是標(biāo)記某個(gè)缺陷的一：缺陷標(biāo)識(shí)是標(biāo)記某個(gè)缺陷的一組符號(hào)。每個(gè)缺陷必須有一個(gè)唯一的標(biāo)識(shí)；組符號(hào)。每個(gè)缺陷必須有一個(gè)唯一的標(biāo)識(shí)；p缺陷缺陷類型類型 （Type）：缺陷類型是根據(jù)缺陷的自然屬性劃：缺陷類型是根據(jù)缺陷的自然屬性劃分的缺陷種類，一般包括功能缺陷、用戶界面缺陷、文檔分的缺陷種類，一般包括功能缺陷、用戶界面缺陷、文檔缺陷、軟件配置缺陷、性能缺陷、系統(tǒng)缺陷、軟件配置缺陷、性能缺陷、系統(tǒng)/模塊接口缺陷等；模塊接口缺陷等；p缺陷嚴(yán)重程度缺陷嚴(yán)重程度 （Severity）：缺陷嚴(yán)重程度是指因缺陷：缺陷嚴(yán)重程度是指因缺陷

12、引起的故障對(duì)軟件產(chǎn)品的影響程度；引起的故障對(duì)軟件產(chǎn)品的影響程度；p缺陷優(yōu)先級(jí)（缺陷優(yōu)先級(jí)（Priority）：缺陷的優(yōu)先級(jí)指缺陷必須被修：缺陷的優(yōu)先級(jí)指缺陷必須被修復(fù)的緊急程度；復(fù)的緊急程度；p缺陷狀態(tài)（缺陷狀態(tài)（Status）：缺陷狀態(tài)指缺陷通過一個(gè)跟蹤修：缺陷狀態(tài)指缺陷通過一個(gè)跟蹤修復(fù)過程的進(jìn)展情況；復(fù)過程的進(jìn)展情況；p缺陷起源（缺陷起源（Origin）：缺陷來源指缺陷引起的故障或事：缺陷來源指缺陷引起的故障或事件第一次被檢測(cè)到的階段；件第一次被檢測(cè)到的階段；p缺陷來源（缺陷來源（Source）：缺陷來源指引起缺陷的起因；：缺陷來源指引起缺陷的起因；p缺陷根源（缺陷根源（Root Caus

13、e）：缺陷根源指發(fā)生錯(cuò)誤的根本：缺陷根源指發(fā)生錯(cuò)誤的根本因素。因素。1512.2.1 缺陷類型缺陷類型缺陷類型缺陷類型編號(hào)編號(hào)缺陷類型缺陷類型描述描述10F- Function影響了重要的特性、用戶界面、產(chǎn)品接口、硬件結(jié)構(gòu)接口和全局?jǐn)?shù)據(jù)結(jié)構(gòu)。并且設(shè)計(jì)文檔需要正式的變更。如邏輯，指針，循環(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/p

14、ackage/merge由于配置庫、變更管理或版本控制引起的錯(cuò)誤。60D- Documentation影響發(fā)布和維護(hù)，包括注釋。70G- Algorithm算法錯(cuò)誤。80U-User Interface人機(jī)交互特性：屏幕格式，確認(rèn)用戶輸入，功能有效性，頁面排版等方面的缺陷。90P-Performance不滿足系統(tǒng)可測(cè)量的屬性值，如：執(zhí)行時(shí)間，事務(wù)處理速率等。100N-Norms不符合各種標(biāo)準(zhǔn)的要求，如編碼標(biāo)準(zhǔn)、設(shè)計(jì)符號(hào)等。1612.2.2 缺陷嚴(yán)重程度缺陷嚴(yán)重程度#缺陷嚴(yán)重缺陷嚴(yán)重等級(jí)等級(jí)描述描述1Critical不能執(zhí)行正常工作功能或重要功能。或者危及人身安全。2Major嚴(yán)重地影響系統(tǒng)要求

15、或基本功能的實(shí)現(xiàn)，且沒有辦法更正。（重新安裝或重新啟動(dòng)該軟件不屬于更正辦法）3Minor嚴(yán)重地影響系統(tǒng)要求或基本功能的實(shí)現(xiàn)，但存在合理的更正辦法。（重新安裝或重新啟動(dòng)該軟件不屬于更正辦法）4Cosmetic使操作者不方便或遇到麻煩，但它不影響執(zhí)行工作功能或重要功能。5Other其它錯(cuò)誤。1712.2.3 同行評(píng)審錯(cuò)誤嚴(yán)重程度同行評(píng)審錯(cuò)誤嚴(yán)重程度# #缺陷嚴(yán)重等級(jí)缺陷嚴(yán)重等級(jí)描述描述1Major主要的，較大的缺陷2Minor次要的，小的缺陷1812.2.4 缺陷優(yōu)先級(jí)缺陷優(yōu)先級(jí)# #缺陷優(yōu)先級(jí)缺陷優(yōu)先級(jí)描述描述1Resolve Immediately缺陷必須被立即解決。2Normal Queue

16、缺陷需要正常排隊(duì)等待修復(fù)或列入軟件發(fā)布清單。3Not Urgent缺陷可以在方便時(shí)被糾正。1912.2.5 缺陷狀態(tài)缺陷狀態(tài)缺陷狀態(tài)缺陷狀態(tài)描述描述Submitted已提交的缺陷Open確認(rèn)“提交的缺陷”，等待處理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 缺陷來

17、源缺陷來源缺陷來源缺陷來源描述描述Requirement由于需求的問題引起的缺陷 Architecture由于構(gòu)架的問題引起的缺陷 Design由于設(shè)計(jì)的問題引起的缺陷 Code由于編碼的問題引起的缺陷 Test由于測(cè)試的問題引起的缺陷 Integration由于集成的問題引起的缺陷 2212.2.8 缺陷根源缺陷根源缺陷原因缺陷原因描述描述目標(biāo)如：錯(cuò)誤的范圍，誤解了目標(biāo)，超越能力的目標(biāo)等；過程，工具和方法如：無效的需求收集過程，過時(shí)的風(fēng)險(xiǎn)管理過程，不適用的項(xiàng)目管理方法，沒有估算規(guī)程，無效的變更控制過程等。人如：項(xiàng)目團(tuán)隊(duì)職責(zé)交叉，缺乏培訓(xùn)。沒有經(jīng)驗(yàn)的項(xiàng)目團(tuán)隊(duì)，缺乏士氣和動(dòng)機(jī)不純等。缺乏組織和通

18、訊如：缺乏用戶參與，職責(zé)不明確，管理失敗等。2312.3軟件缺陷的嚴(yán)重性和優(yōu)先級(jí)軟件缺陷的嚴(yán)重性和優(yōu)先級(jí)p缺陷嚴(yán)重性和缺陷優(yōu)先級(jí)是表征軟件缺陷的兩個(gè)缺陷嚴(yán)重性和缺陷優(yōu)先級(jí)是表征軟件缺陷的兩個(gè)重要因素，它影響軟件缺陷的統(tǒng)計(jì)結(jié)果和修正缺重要因素，它影響軟件缺陷的統(tǒng)計(jì)結(jié)果和修正缺陷的優(yōu)先順序，特別在軟件測(cè)試的后期，將影響陷的優(yōu)先順序，特別在軟件測(cè)試的后期，將影響軟件是否能夠按期發(fā)布。軟件是否能夠按期發(fā)布。p對(duì)于軟件測(cè)試初學(xué)者或者沒有對(duì)于軟件測(cè)試初學(xué)者或者沒有軟件開發(fā)軟件開發(fā)經(jīng)驗(yàn)的測(cè)經(jīng)驗(yàn)的測(cè)試工程師而言，對(duì)于這兩個(gè)概念的理解，對(duì)于它試工程師而言，對(duì)于這兩個(gè)概念的理解，對(duì)于它們的作用和處理方式往往理解的

19、不徹底，實(shí)際測(cè)們的作用和處理方式往往理解的不徹底，實(shí)際測(cè)試工作中不能正確表示缺陷的嚴(yán)重性和優(yōu)先級(jí)。試工作中不能正確表示缺陷的嚴(yán)重性和優(yōu)先級(jí)。l這將影響軟件缺陷報(bào)告的質(zhì)量，不利于盡早處理嚴(yán)重的軟件缺陷，可能影響軟件缺陷的處理時(shí)機(jī)。2412.3.1 缺陷的嚴(yán)重性和優(yōu)先級(jí)的缺陷的嚴(yán)重性和優(yōu)先級(jí)的關(guān)系關(guān)系p嚴(yán)重性（嚴(yán)重性（Severity）顧名思義就是軟件缺陷對(duì)軟件質(zhì)量）顧名思義就是軟件缺陷對(duì)軟件質(zhì)量的破壞程度，反應(yīng)其對(duì)產(chǎn)品和用戶的影響，即此軟件缺陷的破壞程度，反應(yīng)其對(duì)產(chǎn)品和用戶的影響，即此軟件缺陷的存在將對(duì)軟件的功能和性能產(chǎn)生怎樣的影響。的存在將對(duì)軟件的功能和性能產(chǎn)生怎樣的影響。l在軟件測(cè)試中，軟件

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

21、2 處理缺陷的嚴(yán)重性和優(yōu)先處理缺陷的嚴(yán)重性和優(yōu)先級(jí)的常見錯(cuò)誤級(jí)的常見錯(cuò)誤p正確處理缺陷的嚴(yán)重性和優(yōu)先級(jí)不是件非常容易正確處理缺陷的嚴(yán)重性和優(yōu)先級(jí)不是件非常容易的事情，對(duì)于經(jīng)驗(yàn)不很豐富的開發(fā)人員經(jīng)常會(huì)發(fā)的事情，對(duì)于經(jīng)驗(yàn)不很豐富的開發(fā)人員經(jīng)常會(huì)發(fā)生如下的情形：生如下的情形：l將比較輕微的缺陷報(bào)告成較高級(jí)別的缺陷和高優(yōu)先級(jí)，夸大缺陷的嚴(yán)重程度，經(jīng)常給人“狼來了”的錯(cuò)覺，將影響軟件質(zhì)量的正確評(píng)估，也耗費(fèi)開發(fā)人員辨別和處理缺陷的時(shí)間。l將很嚴(yán)重的缺陷報(bào)告成輕微缺陷和低優(yōu)先級(jí)，這樣可能掩蓋了很多嚴(yán)重的缺陷。如果在項(xiàng)目發(fā)布前，發(fā)現(xiàn)還有很多由于不正確分配優(yōu)如果在項(xiàng)目發(fā)布前，發(fā)現(xiàn)還有很多由于不正確分配優(yōu)先級(jí)造成

22、的嚴(yán)重缺陷，將需要投入很多人力和時(shí)間進(jìn)先級(jí)造成的嚴(yán)重缺陷，將需要投入很多人力和時(shí)間進(jìn)行修正，影響軟件的正常發(fā)布。行修正，影響軟件的正常發(fā)布。或者這些嚴(yán)重的缺陷成了或者這些嚴(yán)重的缺陷成了“漏網(wǎng)之魚漏網(wǎng)之魚”，隨軟件一起，隨軟件一起發(fā)布出去，影響軟件的質(zhì)量和用戶的使用信心。發(fā)布出去，影響軟件的質(zhì)量和用戶的使用信心。2612.3.3 缺陷的嚴(yán)重性和優(yōu)先級(jí)的缺陷的嚴(yán)重性和優(yōu)先級(jí)的表示和確定表示和確定p對(duì)于缺陷的嚴(yán)重性，如果分為對(duì)于缺陷的嚴(yán)重性，如果分為4級(jí)，則可以參考下面的方法確定：級(jí)，則可以參考下面的方法確定：l非常嚴(yán)重的缺陷，例如，軟件的意外退出甚至操作系統(tǒng)崩潰，造成數(shù)據(jù)丟失。l較嚴(yán)重的缺陷，例如

23、，軟件的某個(gè)菜單不起作用或者產(chǎn)生錯(cuò)誤的結(jié)果；l軟件一般缺陷，例如，本地化軟件的某些字符沒有翻譯或者翻譯不準(zhǔn)確；l軟件界面的細(xì)微缺陷，例如，某個(gè)控件沒有對(duì)齊，某個(gè)標(biāo)點(diǎn)符號(hào)丟失等；p對(duì)于缺陷的優(yōu)先性，如果分為對(duì)于缺陷的優(yōu)先性，如果分為4級(jí)，則可以參考下面的方法確定：級(jí)，則可以參考下面的方法確定：l最高優(yōu)先級(jí)，例如，軟件的主要功能錯(cuò)誤或者造成軟件崩潰，數(shù)據(jù)丟失的缺陷。l較高優(yōu)先級(jí)，例如，影響軟件功能和性能的一般缺陷；l一般優(yōu)先級(jí)，例如，本地化軟件的某些字符沒有翻譯或者翻譯不準(zhǔn)確的缺陷；l低優(yōu)先級(jí)，例如，對(duì)軟件的質(zhì)量影響非常輕微或出現(xiàn)幾率很低的缺陷；2712.4 軟件缺陷管理和軟件缺陷管理和CMM的關(guān)

24、系的關(guān)系pCMM 是指是指“軟件能力成熟度模型軟件能力成熟度模型”，其英文全，其英文全稱為稱為Capability Maturity Model for Software，英文縮寫為，英文縮寫為SW-CMM，簡稱，簡稱CMM。p它是對(duì)于軟件組織在定義、實(shí)施、度量、控制和它是對(duì)于軟件組織在定義、實(shí)施、度量、控制和改善其軟件過程的實(shí)踐中各個(gè)發(fā)展階段的描述。改善其軟件過程的實(shí)踐中各個(gè)發(fā)展階段的描述。CMM的核心是把軟件開發(fā)視為一個(gè)過程，并根的核心是把軟件開發(fā)視為一個(gè)過程，并根據(jù)這一原則對(duì)軟件開發(fā)和維護(hù)，進(jìn)行過程監(jiān)控和據(jù)這一原則對(duì)軟件開發(fā)和維護(hù)，進(jìn)行過程監(jiān)控和研究，以使其更加科學(xué)化、標(biāo)準(zhǔn)化、使企業(yè)能夠

25、研究，以使其更加科學(xué)化、標(biāo)準(zhǔn)化、使企業(yè)能夠更好地實(shí)現(xiàn)商業(yè)目標(biāo)。更好地實(shí)現(xiàn)商業(yè)目標(biāo)。2812.4.1 初始級(jí)的缺陷管理初始級(jí)的缺陷管理p處于處于CMM一級(jí)（或稱為初始級(jí)）的軟件組織，對(duì)軟件缺一級(jí)（或稱為初始級(jí)）的軟件組織，對(duì)軟件缺陷的管理無章可循。工程師們只是在發(fā)現(xiàn)缺陷后，修改相陷的管理無章可循。工程師們只是在發(fā)現(xiàn)缺陷后，修改相應(yīng)的軟件。通常，沒有人會(huì)去記錄自己發(fā)現(xiàn)的缺陷。也沒應(yīng)的軟件。通常，沒有人會(huì)去記錄自己發(fā)現(xiàn)的缺陷。也沒有人知道在新的軟件版本里，究竟糾正了哪些缺陷，還有有人知道在新的軟件版本里，究竟糾正了哪些缺陷，還有哪些缺陷未被糾正。哪些缺陷未被糾正。p而且，只有在下一輪測(cè)試中才有可能知

26、道那些所謂己被糾而且，只有在下一輪測(cè)試中才有可能知道那些所謂己被糾正了的缺陷是否真的被糾正了，更重要的是糾正過程是否正了的缺陷是否真的被糾正了，更重要的是糾正過程是否引入了新的缺陷。所以這樣的軟件組織的項(xiàng)目交貨期表現(xiàn)引入了新的缺陷。所以這樣的軟件組織的項(xiàng)目交貨期表現(xiàn)出強(qiáng)烈的不可預(yù)測(cè)性。出強(qiáng)烈的不可預(yù)測(cè)性。p并且，為了獲得一個(gè)高質(zhì)量的軟件產(chǎn)品（如果能夠的話），并且，為了獲得一個(gè)高質(zhì)量的軟件產(chǎn)品（如果能夠的話），通常要在測(cè)試上花費(fèi)大量的人力。通常要在測(cè)試上花費(fèi)大量的人力。2912.4.2 可重復(fù)級(jí)的缺陷管理可重復(fù)級(jí)的缺陷管理p在在 CMM 二級(jí)（或稱為可重復(fù)級(jí)）的軟件組織中，二級(jí)（或稱為可重復(fù)級(jí)）

27、的軟件組織中，軟件項(xiàng)目會(huì)從自身的需要出發(fā)，制定本項(xiàng)目的缺軟件項(xiàng)目會(huì)從自身的需要出發(fā)，制定本項(xiàng)目的缺陷管理過程。一個(gè)完備軟件缺陷管理過程通常會(huì)陷管理過程。一個(gè)完備軟件缺陷管理過程通常會(huì)包括如下幾個(gè)方面：包括如下幾個(gè)方面：l提交缺陷；l分析和定位缺陷；l提請(qǐng)修改相應(yīng)的軟件；l修改相應(yīng)的軟件；l驗(yàn)證修改。p項(xiàng)目組會(huì)完整地記錄開發(fā)過程中的缺陷，監(jiān)控缺項(xiàng)目組會(huì)完整地記錄開發(fā)過程中的缺陷，監(jiān)控缺陷的修改過程，并驗(yàn)證修改缺陷的結(jié)果。陷的修改過程，并驗(yàn)證修改缺陷的結(jié)果。3012.4.3 已定義級(jí)的缺陷管理已定義級(jí)的缺陷管理pCMM 三級(jí)（或稱為己定義級(jí)）的軟件組織會(huì)匯三級(jí)（或稱為己定義級(jí)）的軟件組織會(huì)匯集組織

28、內(nèi)部以前項(xiàng)目的經(jīng)驗(yàn)教訓(xùn)，制定組織級(jí)的集組織內(nèi)部以前項(xiàng)目的經(jīng)驗(yàn)教訓(xùn)，制定組織級(jí)的缺陷管理過程。缺陷管理過程。p并且，要求項(xiàng)目根據(jù)組織級(jí)的缺陷管理過程定制并且，要求項(xiàng)目根據(jù)組織級(jí)的缺陷管理過程定制本項(xiàng)目的缺陷管理過程。本項(xiàng)目的缺陷管理過程。l從而，整個(gè)軟件組織中的項(xiàng)目都遵循類似的過程來管理缺陷。l好的缺陷管理實(shí)踐成為所有項(xiàng)目的實(shí)踐，而教訓(xùn)也為所有項(xiàng)目所了解。p更重要的是，隨著組織的不斷發(fā)展完善，組織的更重要的是，隨著組織的不斷發(fā)展完善，組織的過程會(huì)得到持續(xù)性的改進(jìn)，所有項(xiàng)目的過程也都過程會(huì)得到持續(xù)性的改進(jìn)，所有項(xiàng)目的過程也都會(huì)相應(yīng)的改進(jìn)。會(huì)相應(yīng)的改進(jìn)。3112.4.4 定量管理級(jí)的缺陷管理定量管理

29、級(jí)的缺陷管理沒實(shí)現(xiàn)缺陷預(yù)防的缺陷密度CMM4（已管理級(jí)）：建立軟件過程能力基線3212.4.5 持續(xù)優(yōu)化級(jí)的缺陷管理持續(xù)優(yōu)化級(jí)的缺陷管理實(shí)現(xiàn)了缺陷預(yù)防的缺陷密度CMM5（持續(xù)優(yōu)化級(jí)）：強(qiáng)調(diào)對(duì)組織的過程進(jìn)行持續(xù)性改進(jìn)3312.5 報(bào)告軟件缺陷報(bào)告軟件缺陷p12.5.1 報(bào)告軟件缺陷的基本原則報(bào)告軟件缺陷的基本原則l準(zhǔn)確報(bào)告軟件缺陷是非常重要的，因?yàn)椋呵逦鷾?zhǔn)確的軟件缺陷描述可以減少軟件缺陷從開清晰準(zhǔn)確的軟件缺陷描述可以減少軟件缺陷從開發(fā)人員返回的數(shù)量；發(fā)人員返回的數(shù)量；提高軟件缺陷修復(fù)的速度，使每一個(gè)小組能夠有提高軟件缺陷修復(fù)的速度，使每一個(gè)小組能夠有效的工作；效的工作；提高測(cè)試人員的信任度，可以

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

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

32、保證它被正確的報(bào)告，并且得到應(yīng)有的重視，繼續(xù)監(jiān)視其修復(fù)的全過程。l不做評(píng)價(jià)。在軟件缺陷描述不要帶有個(gè)人觀點(diǎn)，對(duì)開發(fā)人員進(jìn)行評(píng)價(jià)。軟件缺陷報(bào)告是針對(duì)產(chǎn)品、針對(duì)問題本身，將事實(shí)或現(xiàn)象客觀地描述出來就可以，不需要任何評(píng)價(jià)或議論。3512.5.2 IEEE軟件缺陷報(bào)告模板軟件缺陷報(bào)告模板3612.6軟件缺陷管理軟件缺陷管理p12.6.1 缺陷管理目標(biāo)缺陷管理目標(biāo)l由于不同的軟件開發(fā)組織在軟件開發(fā)過程、質(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)的缺陷；及

33、時(shí)了解并跟蹤每個(gè)被發(fā)現(xiàn)的缺陷；確保每個(gè)被發(fā)現(xiàn)的缺陷都能夠被處理。這里處理的意思不一確保每個(gè)被發(fā)現(xiàn)的缺陷都能夠被處理。這里處理的意思不一定是被修正，也可能是其他處理方式（例如，在下一個(gè)版本定是被修正，也可能是其他處理方式（例如，在下一個(gè)版本中修正）。對(duì)于每個(gè)被發(fā)現(xiàn)的缺陷的處理方式應(yīng)當(dāng)在開發(fā)組中修正）。對(duì)于每個(gè)被發(fā)現(xiàn)的缺陷的處理方式應(yīng)當(dāng)在開發(fā)組織內(nèi)中達(dá)成一致?？梼?nèi)中達(dá)成一致。收集缺陷數(shù)據(jù)并根據(jù)缺陷趨勢(shì)曲線來識(shí)別測(cè)試過程是否結(jié)束。收集缺陷數(shù)據(jù)并根據(jù)缺陷趨勢(shì)曲線來識(shí)別測(cè)試過程是否結(jié)束。決定測(cè)試過程是否結(jié)束有很多種方式，通過缺陷趨勢(shì)曲線來決定測(cè)試過程是否結(jié)束有很多種方式，通過缺陷趨勢(shì)曲線來確定測(cè)試過程是

34、否結(jié)束是常用并且較為有效的一種方式。確定測(cè)試過程是否結(jié)束是常用并且較為有效的一種方式。收集缺陷數(shù)據(jù)并在其上進(jìn)行數(shù)據(jù)分析，作為組織的過程財(cái)富。收集缺陷數(shù)據(jù)并在其上進(jìn)行數(shù)據(jù)分析，作為組織的過程財(cái)富。3712.6.2 人員職責(zé)人員職責(zé)p參與缺陷管理過程人員角色包括項(xiàng)目經(jīng)理、項(xiàng)目測(cè)試負(fù)責(zé)人、測(cè)試人員、參與缺陷管理過程人員角色包括項(xiàng)目經(jīng)理、項(xiàng)目測(cè)試負(fù)責(zé)人、測(cè)試人員、項(xiàng)目相關(guān)開發(fā)人員、質(zhì)量保證人員，其職責(zé)描述如下：項(xiàng)目相關(guān)開發(fā)人員、質(zhì)量保證人員，其職責(zé)描述如下：l項(xiàng)目經(jīng)理（PM）：負(fù)責(zé)指派缺陷給相關(guān)責(zé)任人。負(fù)責(zé)指派缺陷給相關(guān)責(zé)任人。l項(xiàng)目測(cè)試負(fù)責(zé)人（TM）:決定缺陷管理方式和工具，擬定決策評(píng)審計(jì)劃；決定缺

35、陷管理方式和工具，擬定決策評(píng)審計(jì)劃；管理所有缺陷關(guān)閉情況；管理所有缺陷關(guān)閉情況；審核測(cè)試人員提交的缺陷；審核測(cè)試人員提交的缺陷；對(duì)測(cè)試人員的工作質(zhì)量進(jìn)行跟蹤與評(píng)價(jià)。對(duì)測(cè)試人員的工作質(zhì)量進(jìn)行跟蹤與評(píng)價(jià)。l測(cè)試人員（TE）負(fù)責(zé)報(bào)告系統(tǒng)缺陷記錄，且協(xié)助項(xiàng)目人員進(jìn)行缺陷定位；負(fù)責(zé)報(bào)告系統(tǒng)缺陷記錄，且協(xié)助項(xiàng)目人員進(jìn)行缺陷定位；負(fù)責(zé)驗(yàn)證缺陷修復(fù)情況，且填寫缺陷記錄中相應(yīng)信息；負(fù)責(zé)驗(yàn)證缺陷修復(fù)情況，且填寫缺陷記錄中相應(yīng)信息；負(fù)責(zé)執(zhí)行系統(tǒng)回歸測(cè)試；負(fù)責(zé)執(zhí)行系統(tǒng)回歸測(cè)試；提交缺陷報(bào)告；提交缺陷報(bào)告；負(fù)責(zé)被測(cè)軟件進(jìn)行質(zhì)量數(shù)據(jù)和分析。負(fù)責(zé)被測(cè)軟件進(jìn)行質(zhì)量數(shù)據(jù)和分析。l項(xiàng)目相關(guān)開發(fā)人員（DE）修改測(cè)試發(fā)現(xiàn)的缺陷，并提

36、交成果物做再測(cè)試；修改測(cè)試發(fā)現(xiàn)的缺陷，并提交成果物做再測(cè)試；負(fù)責(zé)接收各自的缺陷記錄，并且修改；負(fù)責(zé)接收各自的缺陷記錄，并且修改；負(fù)責(zé)提供缺陷記錄跟蹤中其它相應(yīng)信息。負(fù)責(zé)提供缺陷記錄跟蹤中其它相應(yīng)信息。l質(zhì)量保證人員（SQA）監(jiān)控項(xiàng)目組缺陷管理規(guī)程執(zhí)行情況。監(jiān)控項(xiàng)目組缺陷管理規(guī)程執(zhí)行情況。3812.6.3 缺陷生命周期缺陷生命周期p軟件缺陷的狀態(tài)在其生命周期中變化如下：軟件缺陷的狀態(tài)在其生命周期中變化如下：l缺陷從隱藏在產(chǎn)品中被發(fā)現(xiàn)，這時(shí)缺陷狀態(tài)為“創(chuàng)建”。l得到缺陷修復(fù)請(qǐng)求以后，開發(fā)經(jīng)理將缺陷修復(fù)任務(wù)分配給相應(yīng)的開發(fā)人員進(jìn)行修復(fù)，這時(shí)缺陷的狀態(tài)變?yōu)椤耙逊峙洹?。l開發(fā)人員得到缺陷修復(fù)任務(wù)以后，根

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

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