軟件測(cè)試技術(shù)缺陷報(bào)告與測(cè)試評(píng)估課件

軟件測(cè)試技術(shù)

第六章缺陷報(bào)告與測(cè)試評(píng)估軟件測(cè)試技術(shù)

第六章缺陷報(bào)告與測(cè)試評(píng)估1第六章缺陷報(bào)告與測(cè)試評(píng)估軟件缺陷的主要屬性軟件缺陷報(bào)告軟件缺陷的生命周期與處理流程 軟件測(cè)試的評(píng)估測(cè)試總結(jié)報(bào)告第六章缺陷報(bào)告與測(cè)試評(píng)估軟件缺陷的主要屬性2

6.1.軟件缺陷的主要屬性為了正確、全面地描述軟件缺陷首先需要了解缺陷的一些主要屬性，這些屬性為缺陷修復(fù)和缺陷統(tǒng)計(jì)分析提供了重要依據(jù)。軟件缺陷包括以下一些主要屬性：（1）缺陷標(biāo)識(shí)（Identifier）唯一標(biāo)識(shí)一個(gè)軟件缺陷的符號(hào)，通常用數(shù)字編號(hào)表示。當(dāng)使用缺陷管理系統(tǒng)時(shí)，由軟件自動(dòng)生成；6.1.軟件缺陷的主要屬性為了正確、全面地描述軟件缺陷3（2）缺陷類型（Type）表6-1軟件缺陷的類型缺陷類型描述功能對(duì)軟件使用產(chǎn)生重要影響，需要正式變更設(shè)計(jì)文檔。例如功能缺失、功能錯(cuò)誤、功能超出需求和設(shè)計(jì)范圍、重要算法錯(cuò)誤等界面影響人機(jī)交互的正確性和有效性，如軟件界面顯示、操作、易用性等方面的問(wèn)題性能不滿足性能需求指標(biāo)，如響應(yīng)時(shí)間慢、事務(wù)處理率低、不能支持規(guī)定的并發(fā)用戶數(shù)等接口軟件單元接口之間存在調(diào)用方式、參數(shù)類型、參數(shù)數(shù)量等不匹配、相互沖突等問(wèn)題邏輯分支、循環(huán)、程序執(zhí)行路徑等程序邏輯錯(cuò)誤，需要修改代碼計(jì)算錯(cuò)誤的公式、計(jì)算精度、運(yùn)算符優(yōu)先級(jí)等造成的計(jì)算錯(cuò)誤數(shù)據(jù)數(shù)據(jù)類型、變量初始化、變量引用、輸入與輸出數(shù)據(jù)等方面的錯(cuò)誤（2）缺陷類型（Type）缺陷類型描述功能對(duì)軟件使用產(chǎn)生重要4附表：缺陷類型描述文檔影響軟件發(fā)布和維護(hù)的、包括注釋在內(nèi)的文檔缺陷配置軟件配置變更或版本控制引起的錯(cuò)誤標(biāo)準(zhǔn)不符合編碼標(biāo)準(zhǔn)、軟件標(biāo)準(zhǔn)、行業(yè)標(biāo)準(zhǔn)等兼容操作系統(tǒng)、瀏覽器、顯示分辨率等方面的兼容性問(wèn)題安全影響軟件系統(tǒng)安全性的缺陷其它上述問(wèn)題中不包含的其它問(wèn)題附表：缺陷類型描述文檔影響軟件發(fā)布和維護(hù)的、包括注釋在內(nèi)的文5（3）缺陷嚴(yán)重程度(Severity)表6-2軟件缺陷的嚴(yán)重程度缺陷嚴(yán)重等級(jí)描述致命（Fatal）缺陷會(huì)導(dǎo)致系統(tǒng)的某些主要功能完全喪失，系統(tǒng)無(wú)法正常執(zhí)行基本功能，用戶數(shù)據(jù)遭到破壞，系統(tǒng)出現(xiàn)崩潰、懸掛和死機(jī)現(xiàn)象，甚至危及人身安全嚴(yán)重（Cirtical）系統(tǒng)的主要功能部分喪失，次要功能完全喪失，用戶數(shù)據(jù)不能正常保存，缺陷嚴(yán)重影響用戶對(duì)軟件系統(tǒng)的正常使用。包括可能造成系統(tǒng)崩潰等災(zāi)難性后果的缺陷、數(shù)據(jù)庫(kù)錯(cuò)誤等重要（Major）產(chǎn)生錯(cuò)誤的運(yùn)行結(jié)果，導(dǎo)致系統(tǒng)不穩(wěn)定，對(duì)系統(tǒng)功能和性能產(chǎn)生重要影響。例如，系統(tǒng)操作響應(yīng)時(shí)間不滿足要求，某些功能需求未實(shí)現(xiàn)、業(yè)務(wù)流程不正確、系統(tǒng)出現(xiàn)某些意外故障等較?。∕inor）缺陷會(huì)使用戶使用軟件不方便或遇到麻煩，但不影響用戶的正常使用，也不影響系統(tǒng)的穩(wěn)定性。主要指用戶界面方面的一些問(wèn)題，例如提示信息不準(zhǔn)確、錯(cuò)別字、界面不一致等（3）缺陷嚴(yán)重程度(Severity)缺陷嚴(yán)重等級(jí)描述致命6（4）缺陷優(yōu)先級(jí)(Priority)：缺陷的優(yōu)先級(jí)是從開發(fā)人員和測(cè)試人員的角度出發(fā)，以合理安排工作時(shí)間和提高工作效率為目標(biāo)進(jìn)行設(shè)置的；表6-3軟件缺陷的優(yōu)先級(jí)缺陷優(yōu)先級(jí)描述立即解決（ResolveImmediately）缺陷的存在導(dǎo)致系統(tǒng)幾乎無(wú)法運(yùn)行和使用，或者是造成測(cè)試無(wú)法繼續(xù)進(jìn)行，例如無(wú)法通過(guò)冒煙測(cè)試，必須立即予以修復(fù)高優(yōu)先級(jí)（HighPriority）缺陷嚴(yán)重，影響測(cè)試的正常進(jìn)行，需要優(yōu)先在規(guī)定的時(shí)間內(nèi)（如24小時(shí)內(nèi)）完成修改正常排隊(duì)（NormalQueue）缺陷需要修復(fù)，但可以正常排隊(duì)等待修復(fù)低優(yōu)先級(jí)（NotUrgent）缺陷可以在開發(fā)人員有時(shí)間的時(shí)候進(jìn)行修復(fù)，如果開發(fā)和測(cè)試時(shí)間緊迫，可以在下一軟件版本中進(jìn)行修正（4）缺陷優(yōu)先級(jí)(Priority)：缺陷的優(yōu)先級(jí)是從開發(fā)7（5）缺陷出現(xiàn)的可能性（Possibility）：缺陷出現(xiàn)的可能性是指某一缺陷發(fā)生的頻率；表6-4軟件缺陷出現(xiàn)的可能性（缺陷頻率）缺陷出現(xiàn)的可能性描述總是（Always）軟件缺陷的出現(xiàn)頻率是100%，每次測(cè)試時(shí)都會(huì)重現(xiàn)通常（Often）測(cè)試用例執(zhí)行時(shí)通常會(huì)產(chǎn)生，出現(xiàn)頻率大概是80%~90%有時(shí)（Occasionally）測(cè)試時(shí)有時(shí)會(huì)產(chǎn)生這一軟件缺陷，缺陷的出現(xiàn)概率是30%~50%很少（Rarely）測(cè)試時(shí)很少產(chǎn)生這一軟件缺陷，缺陷的出現(xiàn)概率是1%~5%（5）缺陷出現(xiàn)的可能性（Possibility）：缺陷出現(xiàn)的8（6）缺陷狀態(tài)（Status）：缺陷狀態(tài)用于描述跟蹤和修復(fù)缺陷的進(jìn)展情況，也反映了缺陷在其生命周期中的不同變化。表6-5軟件缺陷的狀態(tài)缺陷狀態(tài)描述提交（Submitted）已提交入庫(kù)的缺陷激活或打開（ActiveorOpen）缺陷提交得到確認(rèn)但還未解決，缺陷等待處理拒絕（Rejected）開發(fā)人員認(rèn)為不是缺陷或重復(fù)提交的缺陷，不需要修復(fù)已修正或修復(fù)（FixedorResolved）缺陷已經(jīng)被開發(fā)人員修復(fù)，但是還沒(méi)有經(jīng)過(guò)測(cè)試人員的驗(yàn)證驗(yàn)證（Verify）缺陷驗(yàn)證通過(guò)關(guān)閉或非激活（ClosedorInactive）測(cè)試人員驗(yàn)證后認(rèn)為缺陷已經(jīng)成功修復(fù)（6）缺陷狀態(tài)（Status）：缺陷狀態(tài)用于描述跟蹤和修復(fù)缺9缺陷狀態(tài)描述重新打開（Reopen）測(cè)試人員驗(yàn)證后認(rèn)為缺陷仍然存在，等待開發(fā)人員進(jìn)一步修復(fù)推遲（Deferred）缺陷推遲到下一個(gè)軟件版本中修復(fù)保留（Onhold）由于技術(shù)原因或第三方軟件的缺陷，開發(fā)人員暫時(shí)無(wú)法修復(fù)不能重現(xiàn)（Cannotduplicate）開發(fā)人員無(wú)法重現(xiàn)缺陷，需要測(cè)試人員補(bǔ)充說(shuō)明重現(xiàn)步驟附表：缺陷狀態(tài)描述重新打開測(cè)試人員驗(yàn)證后認(rèn)為缺陷仍然存在，等待開發(fā)10（7）缺陷起源（Origin）缺陷起源是指測(cè)試時(shí)第一次發(fā)現(xiàn)缺陷的階段，例如以下一些典型階段：需求、總體設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼、單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試、產(chǎn)品試運(yùn)行、產(chǎn)品發(fā)布后用戶使用階段。發(fā)現(xiàn)缺陷的階段越早，越有利于降低改正缺陷的費(fèi)用。（7）缺陷起源（Origin）11（8）缺陷來(lái)源（Source）缺陷來(lái)源是指軟件缺陷發(fā)生的地方。在軟件生命周期某一階段發(fā)現(xiàn)的缺陷可能來(lái)源于前期階段出現(xiàn)的錯(cuò)誤。

圖6-1軟件缺陷產(chǎn)生的階段（8）缺陷來(lái)源（Source）圖6-1軟件缺陷產(chǎn)生的階段12（9）缺陷根源（RootCause）缺陷根源是指造成軟件缺陷的根本因素，主要是開發(fā)過(guò)程、工具、方法等軟件工程技術(shù)與管理因素以及測(cè)試策略等因素，通過(guò)缺陷根源分析可以改進(jìn)軟件過(guò)程管理水平。（9）缺陷根源（RootCause）136.2軟件缺陷報(bào)告

6.2.1缺陷報(bào)告中的信息在實(shí)際工作中，經(jīng)常會(huì)出現(xiàn)由于軟件缺陷描述不清而無(wú)法重現(xiàn)缺陷、無(wú)法合理安排修復(fù)工作、后期無(wú)法對(duì)缺陷進(jìn)行統(tǒng)計(jì)分析等情況。6.2軟件缺陷報(bào)告6.2.1缺陷報(bào)告中的信息14一份完整的缺陷報(bào)告包括以下一些信息：（1）缺陷跟蹤信息；缺陷ID：唯一標(biāo)識(shí)一個(gè)軟件缺陷，便于跟蹤與查詢；標(biāo)題：缺陷的概括性文字描述；所屬項(xiàng)目：缺陷屬于哪個(gè)軟件項(xiàng)目；版本跟蹤：缺陷屬于軟件項(xiàng)目的哪一個(gè)版本，是新缺陷還是回歸缺陷；所屬模塊：缺陷位于哪個(gè)功能模塊。一份完整的缺陷報(bào)告包括以下一些信息：15（2）缺陷詳細(xì)信息測(cè)試步驟期望結(jié)果實(shí)際結(jié)果測(cè)試環(huán)境（2）缺陷詳細(xì)信息16（3）缺陷附件信息；（4）缺陷屬性信息類型：功能、用戶界面、性能、文檔等類型；嚴(yán)重程度：可以分為致命、嚴(yán)重、重要和較?。粌?yōu)先級(jí)：可以分為立即解決、高優(yōu)先級(jí)、正常排隊(duì)和低優(yōu)先級(jí)；出現(xiàn)頻率：按統(tǒng)計(jì)結(jié)果標(biāo)明缺陷發(fā)生的可能性1%~100%；缺陷起源、來(lái)源和根源信息。（3）缺陷附件信息；17（5）缺陷處理信息提交人員提交時(shí)間分配的修復(fù)人員修復(fù)期限修復(fù)時(shí)間缺陷驗(yàn)證人員驗(yàn)證意見(jiàn)驗(yàn)證時(shí)間（5）缺陷處理信息186.2.2缺陷報(bào)告模板

一份軟件缺陷報(bào)告可以包含非常豐富的缺陷描述信息。在實(shí)際工作中，一般根據(jù)軟件項(xiàng)目特點(diǎn)對(duì)上述缺陷描述信息進(jìn)行裁剪，制定合適的缺陷報(bào)告模板。6.2.2缺陷報(bào)告模板一份軟件缺陷報(bào)告可以包含非常豐19填寫模板信息時(shí)，需要遵守以下“5C”原則：Correct：對(duì)每個(gè)組成部分的描述準(zhǔn)確不會(huì)引起誤解。Clear：對(duì)每個(gè)組成部分的描述清晰，易于理解。Concise：描述信息只包含必不可少的內(nèi)容。Complete：包含重現(xiàn)缺陷的完整步驟和其它輔助信息。Consistent：按照一致的格式書寫全部缺陷報(bào)告。填寫模板信息時(shí)，需要遵守以下“5C”原則：20下表是一個(gè)較為通用的軟件缺陷報(bào)告模板，可以在實(shí)際工作中修改為更為適合特定工作要求的模板。表6-6軟件缺陷報(bào)告模板缺陷記錄缺陷ID

標(biāo)題（概述）

軟件名稱

模塊名

版本號(hào)

嚴(yán)重程度

優(yōu)先級(jí)

狀態(tài)

缺陷類型

發(fā)現(xiàn)階段

缺陷來(lái)源

缺陷頻率

可能性說(shuō)明

測(cè)試人員

分配修復(fù)人員

日期

下表是一個(gè)較為通用的軟件缺陷報(bào)告模板，可以在實(shí)際工作中修改為21

附表：缺陷記錄測(cè)試環(huán)境

測(cè)試輸入

預(yù)期結(jié)果

異常結(jié)果

缺陷重現(xiàn)步驟

附件

缺陷處理信息缺陷驗(yàn)證信息修復(fù)人

驗(yàn)證人

修復(fù)時(shí)間

驗(yàn)證時(shí)間

備注

驗(yàn)證結(jié)論附表：缺陷記錄測(cè)試環(huán)境測(cè)試輸入預(yù)期結(jié)果異常226.2.3缺陷報(bào)告的注意事項(xiàng)

測(cè)試人員在編寫缺陷報(bào)告之前，首先需要清楚缺陷報(bào)告的主要讀者以及他們最希望從缺陷報(bào)告中獲得哪些信息。因此，測(cè)試人員在編寫缺陷報(bào)告時(shí)需要注意以下一些事項(xiàng)：（1）保證能夠重現(xiàn)缺陷；6.2.3缺陷報(bào)告的注意事項(xiàng)測(cè)試人員在編寫缺陷報(bào)告之23因此，測(cè)試人員在編寫缺陷報(bào)告時(shí)需要注意以下一些事項(xiàng)：（1）保證能夠重現(xiàn)缺陷：如果測(cè)試人員發(fā)現(xiàn)不能保證重現(xiàn)一個(gè)缺陷，那么就需要給開發(fā)人員提供盡可能多的有效信息。如果無(wú)法重現(xiàn)或者沒(méi)有驗(yàn)證是否可以重現(xiàn)時(shí)，一定要在缺陷報(bào)告中進(jìn)行說(shuō)明；因此，測(cè)試人員在編寫缺陷報(bào)告時(shí)需要注意以下一些事24

（2）一個(gè)報(bào)告只針對(duì)一個(gè)缺陷：雖然有時(shí)多個(gè)缺陷的起因是一樣的，但是在真正修復(fù)缺陷之前并不能保證知道導(dǎo)致某個(gè)缺陷的原因。因此即使單獨(dú)報(bào)告缺陷顯得有些繁瑣，但也比延誤或遺漏缺陷要好。（2）一個(gè)報(bào)告只針對(duì)一個(gè)缺陷：雖然有時(shí)多個(gè)缺陷的起因是一樣25（3）描述準(zhǔn)確、清晰：缺陷標(biāo)題必須簡(jiǎn)短，而且要求描述和傳達(dá)出準(zhǔn)確的信息；（4）重視附件信息附件信息應(yīng)當(dāng)是缺陷重現(xiàn)步驟的補(bǔ)充信息，是對(duì)測(cè)試步驟的進(jìn)一步描述；（3）描述準(zhǔn)確、清晰：缺陷標(biāo)題必須簡(jiǎn)短，而且要求描述和傳達(dá)出26（5）使用中性語(yǔ)言：使用中性語(yǔ)言是指客觀地描述缺陷問(wèn)題。用帶有感情色彩的語(yǔ)句報(bào)告缺陷除了造成研發(fā)團(tuán)隊(duì)的溝通障礙和協(xié)作困難外，對(duì)修改缺陷沒(méi)有任何好處。（5）使用中性語(yǔ)言：使用中性語(yǔ)言是指客觀地描述缺陷問(wèn)題。用帶276.2.4分離和再現(xiàn)軟件缺陷

為了保證再現(xiàn)軟件缺陷，除了需要按照已經(jīng)介紹過(guò)的描述規(guī)則來(lái)描述軟件缺陷之外，還要遵循軟件缺陷分離和再現(xiàn)的方法。分離和再現(xiàn)軟件缺陷是充分體現(xiàn)測(cè)試人員測(cè)試才能的地方，需要在測(cè)試工作中不斷總結(jié)經(jīng)驗(yàn)，才能準(zhǔn)確地找出縮小問(wèn)題范圍的具體步驟和方法。6.2.4分離和再現(xiàn)軟件缺陷為了保證再現(xiàn)軟件缺陷，除28下面列舉一些常用的分離和再現(xiàn)軟件缺陷的方法和技巧：（1）確保所有的步驟都被記錄；（2）注意特定時(shí)間和運(yùn)行條件因素；（3）注意邊界條件、內(nèi)存容量和數(shù)據(jù)溢出問(wèn)題；（4）注意事件發(fā)生次序?qū)е碌能浖毕?；?）考慮軟件與其計(jì)算環(huán)境的相互作用；（6）不能忽視硬件。下面列舉一些常用的分離和再現(xiàn)軟件缺陷的方法和技巧：29

6.3軟件缺陷的生命周期與處理流程軟件缺陷的生命周期是指一個(gè)軟件缺陷從發(fā)現(xiàn)到最終被確認(rèn)修復(fù)的完整過(guò)程。在這一過(guò)程中，軟件缺陷會(huì)經(jīng)歷不同的狀態(tài)。一個(gè)典型的軟件缺陷生命周期經(jīng)歷了如下?tīng)顟B(tài)改變:6.3軟件缺陷的生命周期與處理流程軟件缺陷的生命周期是30提交→打開：測(cè)試人員提交發(fā)現(xiàn)的軟件缺陷，開發(fā)人員確認(rèn)后準(zhǔn)備修復(fù)。打開→修復(fù)：開發(fā)人員修復(fù)缺陷后通知測(cè)試人員進(jìn)行修復(fù)結(jié)果驗(yàn)證。提交→打開：測(cè)試人員提交發(fā)現(xiàn)的軟件缺陷，開發(fā)人員確認(rèn)后準(zhǔn)備修31驗(yàn)證→重新打開：測(cè)試人員執(zhí)行回歸測(cè)試，驗(yàn)證測(cè)試結(jié)果后認(rèn)為缺陷沒(méi)有完全被修復(fù)，再次打開缺陷等待開發(fā)人員重新進(jìn)一步修復(fù)。驗(yàn)證→關(guān)閉：測(cè)試人員執(zhí)行回歸測(cè)試，確認(rèn)缺陷已經(jīng)得到修復(fù)，然后將缺陷狀態(tài)設(shè)為最后的關(guān)閉狀態(tài)驗(yàn)證→重新打開：測(cè)試人員執(zhí)行回歸測(cè)試，驗(yàn)證測(cè)試結(jié)果后認(rèn)為缺陷32為了合理安排缺陷修復(fù)工作，避免遺漏任何一個(gè)缺陷，需要規(guī)劃軟件缺陷的處理流程，一般根據(jù)實(shí)際情況進(jìn)行靈活設(shè)置。上述典型軟件缺陷生命周期的處理流程如圖6-2所示。圖6-2缺陷典型處理流程為了合理安排缺陷修復(fù)工作，避免遺漏任何一個(gè)缺陷，需要規(guī)劃軟件33實(shí)際工作中，缺陷處理流程不可能像典型處理流程這樣簡(jiǎn)單，會(huì)面臨各種特殊的情況，造成軟件缺陷的生命周期更為復(fù)雜。需要考慮如下一些實(shí)際情況:開發(fā)人員認(rèn)為測(cè)試人員提交的軟件缺陷不是真正的缺陷或者是微不足道;實(shí)際工作中，缺陷處理流程不可能像典型處理流程這樣簡(jiǎn)單，會(huì)面臨34缺陷被不同測(cè)試人員重復(fù)提交;測(cè)試人員驗(yàn)證缺陷的修復(fù)結(jié)果后，認(rèn)為缺陷仍然存在或者沒(méi)有達(dá)到預(yù)期的修復(fù)效果，因而重新將缺陷設(shè)置為打開狀態(tài);缺陷優(yōu)先級(jí)比較低，項(xiàng)目研發(fā)周期有限，產(chǎn)品發(fā)布在即，缺陷可以推遲到下一版本中進(jìn)行處理;缺陷被不同測(cè)試人員重復(fù)提交;35軟件產(chǎn)品即將更新?lián)Q代，而修復(fù)某一缺陷的風(fēng)險(xiǎn)過(guò)大，可能會(huì)造成更多的問(wèn)題，經(jīng)項(xiàng)目管理人員同意后可以不必修復(fù);被推遲修復(fù)的軟件缺陷被證實(shí)很嚴(yán)重，需要立即予以修復(fù)，軟件缺陷的狀態(tài)被設(shè)置為重新打開。軟件產(chǎn)品即將更新?lián)Q代，而修復(fù)某一缺陷的風(fēng)險(xiǎn)過(guò)大，可能會(huì)造成更36由上述情況可見(jiàn)，缺陷的處理過(guò)程實(shí)際上是比較復(fù)雜的，會(huì)出現(xiàn)對(duì)缺陷修復(fù)與否和修復(fù)結(jié)果是否滿足要求的不同意見(jiàn)。因此，需要事先規(guī)定好對(duì)缺陷狀態(tài)的設(shè)置權(quán)限。一旦發(fā)現(xiàn)缺陷，就需要明確后期相關(guān)人員的工作職責(zé)，跟蹤軟件缺陷的生命周期，直到缺陷最終得到正確處理。由上述情況可見(jiàn)，缺陷的處理過(guò)程實(shí)際上是比較復(fù)雜的，會(huì)出現(xiàn)對(duì)缺37圖6-3軟件缺陷處理流程圖6-3軟件缺陷處理流程38圖6-3是一個(gè)考慮上述特殊情況后的缺陷處理流程，可以在實(shí)際工作中予以參考。從以上說(shuō)明可以理解，一個(gè)軟件缺陷除了常見(jiàn)的提交、打開、修復(fù)和關(guān)閉狀態(tài)外，還包括拒絕、驗(yàn)證、審查、推遲、保留、重新打開等附加狀態(tài)。圖6-3是一個(gè)考慮上述特殊情況后的缺陷處理流程，可以在實(shí)際工39對(duì)于缺陷數(shù)量只在幾十個(gè)范圍內(nèi)的小型軟件項(xiàng)目，用Excel制作的缺陷報(bào)告模板就可以應(yīng)對(duì)。但是對(duì)于大型軟件項(xiàng)目，要追蹤和管理成百上千個(gè)狀態(tài)不斷變化的軟件缺陷，必須使用合適的缺陷管理工具。對(duì)于缺陷數(shù)量只在幾十個(gè)范圍內(nèi)的小型軟件項(xiàng)目，用E40缺陷管理工具屬于測(cè)試管理類工具，相比其它測(cè)試類工具，學(xué)習(xí)和使用都較為簡(jiǎn)單。常用的有QC、禪道、Mantis、JIRA、TestLink、Bugzilla等。使用這些缺陷管理工具的優(yōu)勢(shì)體現(xiàn)在以下一些方面:缺陷管理工具屬于測(cè)試管理類工具，相比其它測(cè)試類工具，學(xué)習(xí)和使41強(qiáng)大的檢索功能和安全的審核機(jī)制。由于具有后臺(tái)數(shù)據(jù)庫(kù)支持，缺陷檢索、增加、修改、保存都很方便，并且能夠?qū)Ω郊M(jìn)行有效管理。通過(guò)權(quán)限設(shè)置，將缺陷操作權(quán)限與缺陷狀態(tài)相對(duì)應(yīng)，保證修改、刪除等缺陷操作的安全性。強(qiáng)大的檢索功能和安全的審核機(jī)制。由于具有后臺(tái)數(shù)據(jù)庫(kù)支持，缺陷42支持項(xiàng)目組成員間的協(xié)同工作。通過(guò)友好的網(wǎng)絡(luò)用戶界面以及Email等豐富多樣的配置設(shè)定，支持項(xiàng)目組各類成員及時(shí)了解缺陷狀態(tài)的變化情況，進(jìn)而根據(jù)對(duì)應(yīng)狀態(tài)合理地安排自己的工作，提高發(fā)現(xiàn)缺陷和改正缺陷的效率。支持項(xiàng)目組成員間的協(xié)同工作。通過(guò)友好的網(wǎng)絡(luò)用戶界面以及Ema43提高缺陷報(bào)告的質(zhì)量。保證缺陷報(bào)告的完整性和一致性，正確和完整地填寫缺陷報(bào)告的各項(xiàng)內(nèi)容，保證不同測(cè)試人員提交的測(cè)試報(bào)告格式統(tǒng)一。提高缺陷報(bào)告的質(zhì)量。保證缺陷報(bào)告的完整性和一致性，正確和完整44

6.4軟件測(cè)試的評(píng)估在軟件測(cè)試執(zhí)行過(guò)程中，需要階段性地總結(jié)和分析測(cè)試結(jié)果，確保測(cè)試過(guò)程的有效性。在軟件驗(yàn)收和發(fā)布之前，測(cè)試管理人員需要對(duì)整個(gè)測(cè)試過(guò)程和結(jié)果做出系統(tǒng)性的評(píng)價(jià)，評(píng)估測(cè)試的完成度是否達(dá)到了測(cè)試計(jì)劃規(guī)定的目標(biāo)、軟件的質(zhì)量是否滿足了用戶需求和設(shè)計(jì)要求，最終決定能否將軟件交付用戶驗(yàn)收或者最終發(fā)布。6.4軟件測(cè)試的評(píng)估在軟件測(cè)試執(zhí)行過(guò)程中，需要階段性地456.4.1測(cè)試評(píng)估的目的和方法軟件測(cè)試的評(píng)估主要有以下目的：對(duì)測(cè)試的進(jìn)展情況進(jìn)行量化分析，確定測(cè)試和缺陷修復(fù)工作的當(dāng)前狀態(tài)、效率和完成度，判斷測(cè)試工作可以結(jié)束的時(shí)間;6.4.1測(cè)試評(píng)估的目的和方法軟件測(cè)試的評(píng)估主要有以下目46最后完成測(cè)試報(bào)告或軟件質(zhì)量分析報(bào)告提供量化分析數(shù)據(jù)，例如給出測(cè)試覆蓋率和缺陷清除率等。分析軟件研發(fā)各階段的不足之處，找出測(cè)試和開發(fā)工作中的薄弱環(huán)節(jié)，為過(guò)程監(jiān)督、質(zhì)量控制和過(guò)程改進(jìn)提供定量化依據(jù)。最后完成測(cè)試報(bào)告或軟件質(zhì)量分析報(bào)告提供量化分析數(shù)據(jù)，例如給出47從以上內(nèi)容可以看出，測(cè)試評(píng)估強(qiáng)調(diào)定量化分析，是以定量化的分析結(jié)果科學(xué)地評(píng)價(jià)測(cè)試工作和軟件質(zhì)量，為軟件過(guò)程管理提供依據(jù)。測(cè)試評(píng)估主要包括以下兩種方法:從以上內(nèi)容可以看出，測(cè)試評(píng)估強(qiáng)調(diào)定量化分析，是以定量化的分析48覆蓋率評(píng)估:評(píng)估測(cè)試的覆蓋率，對(duì)測(cè)試完成程度進(jìn)行評(píng)測(cè)。最常見(jiàn)的覆蓋率評(píng)估分為需求覆蓋率評(píng)估和代碼覆蓋率評(píng)估。覆蓋率評(píng)估:評(píng)估測(cè)試的覆蓋率，對(duì)測(cè)試完成程度進(jìn)行評(píng)測(cè)。最常見(jiàn)49質(zhì)量評(píng)估:測(cè)試過(guò)程中產(chǎn)生的軟件缺陷報(bào)告提供了最佳的軟件質(zhì)量評(píng)估數(shù)據(jù)，通過(guò)缺陷分析可以對(duì)軟件的可靠性、穩(wěn)定性等進(jìn)行詳細(xì)分析，對(duì)軟件的性能進(jìn)行多方面的評(píng)測(cè)，獲得反映軟件質(zhì)量特征的多種指標(biāo)數(shù)據(jù)，在此基礎(chǔ)上確定軟件質(zhì)量與需求的相符程度。質(zhì)量評(píng)估:測(cè)試過(guò)程中產(chǎn)生的軟件缺陷報(bào)告提供了最佳的軟件質(zhì)量評(píng)506.4.2覆蓋率評(píng)估覆蓋率是一種常見(jiàn)的反映測(cè)試充分性和完成度的定量化指標(biāo)。測(cè)試活動(dòng)已驗(yàn)證過(guò)的軟件區(qū)域越多，軟件質(zhì)量得到保障的可能性越大，測(cè)試工作也越接近完成。因此，通過(guò)測(cè)試覆蓋率可以間接地反映測(cè)試工作的質(zhì)量和當(dāng)前軟件代碼的質(zhì)量。測(cè)試覆蓋又分為需求覆蓋和代碼覆蓋兩個(gè)方面。6.4.2覆蓋率評(píng)估覆蓋率是一種常見(jiàn)的反映測(cè)試充分性和511、需求覆蓋率對(duì)需求的全面覆蓋是軟件測(cè)試的基本要求，需求覆蓋率是測(cè)試到的功能和非功能需求占整個(gè)需求總數(shù)的百分比。1、需求覆蓋率52由于測(cè)試計(jì)劃和測(cè)試用例設(shè)計(jì)時(shí)已經(jīng)考慮了對(duì)需求的覆蓋，因此一般可以通過(guò)已計(jì)劃的、已實(shí)施的或成功完成的測(cè)試用例的執(zhí)行率來(lái)衡量需求覆蓋率，有時(shí)也可以通過(guò)測(cè)試需求的覆蓋率來(lái)衡量。由于測(cè)試計(jì)劃和測(cè)試用例設(shè)計(jì)時(shí)已經(jīng)考慮了對(duì)需求的覆蓋，因此一般53測(cè)試評(píng)估中，通常使用以下三種公式來(lái)計(jì)算需求的測(cè)試覆蓋率：計(jì)劃的測(cè)試覆蓋率=Tp/Rft（1）已執(zhí)行的測(cè)試覆蓋率=Tx/Rft（2）成功執(zhí)行的測(cè)試覆蓋率=Ts/Rft（3）測(cè)試評(píng)估中，通常使用以下三種公式來(lái)計(jì)算需求的測(cè)試覆蓋率：54上述三個(gè)公式中，Rft是測(cè)試需求的總數(shù)，Tp是用測(cè)試過(guò)程或測(cè)試用例表示的計(jì)劃測(cè)試需求數(shù)，Tx是用測(cè)試過(guò)程或測(cè)試用例表示的已執(zhí)行的測(cè)試需求數(shù)，Ts是用完全成功、沒(méi)有缺陷或意外結(jié)果的測(cè)試過(guò)程或測(cè)試用例表示的已執(zhí)行測(cè)試需求數(shù)。通過(guò)上述三種需求覆蓋率指標(biāo)可以評(píng)估剩余測(cè)試的工作量，確定測(cè)試工作的完成時(shí)間。上述三個(gè)公式中，Rft是測(cè)試需求的總數(shù)，Tp是用測(cè)試過(guò)程或測(cè)552、代碼覆蓋率代碼覆蓋率是指所測(cè)試的源代碼數(shù)量占代碼總數(shù)的百分比。代碼覆蓋率反映了測(cè)試用例對(duì)被測(cè)軟件代碼的覆蓋程度，也是衡量測(cè)試工作進(jìn)展情況的重要定量化指標(biāo)。2、代碼覆蓋率56很明顯，代碼覆蓋率與單元測(cè)試密切相關(guān)，是單元測(cè)試用例是否充分的重要衡量指標(biāo)。任何未經(jīng)測(cè)試的程序代碼都可能存在潛在缺陷，因此在實(shí)際測(cè)試前就應(yīng)當(dāng)根據(jù)程序規(guī)格說(shuō)明、具體代碼、規(guī)定的代碼覆蓋率要求設(shè)計(jì)出合理數(shù)量的測(cè)試用例。很明顯，代碼覆蓋率與單元測(cè)試密切相關(guān)，是單元測(cè)試用例是否充分57與手工分析需求覆蓋率不同，一般需要借助相應(yīng)的工具來(lái)統(tǒng)計(jì)代碼覆蓋率。下面列舉一些常用編程語(yǔ)言的代碼覆蓋率分析工具:C/C++：CUnit、CPPUnit、GoogleGTest、gcc+gcov+lcov等。Java

：

Clover、EMMA、JaCoCo、Jtest、MavenCobertura插件等。JavaScript：JSCoverage。Python：PyUnit+Coverage.py。PHP：PHPUnit+XDebug。Ruby：RCov。

與手工分析需求覆蓋率不同，一般需要借助相應(yīng)的工具來(lái)統(tǒng)計(jì)代碼覆58代碼覆蓋率在實(shí)際應(yīng)用中存在著一些誤區(qū)，主要反映在以下兩個(gè)方面：（1）片面追求高代碼覆蓋率:對(duì)于代碼覆蓋率的提升應(yīng)當(dāng)基于風(fēng)險(xiǎn)分析的方法，應(yīng)當(dāng)首先保證對(duì)關(guān)鍵模塊代碼的測(cè)試覆蓋，并確保徹底修復(fù)了所發(fā)現(xiàn)的軟件缺陷。只有通過(guò)風(fēng)險(xiǎn)分析，才能確定每一次提升代碼覆蓋率的實(shí)際價(jià)值；代碼覆蓋率在實(shí)際應(yīng)用中存在著一些誤區(qū)，主要反映在以下兩個(gè)方面59（2）認(rèn)為100%的代碼覆蓋率就能夠保證軟件質(zhì)量：實(shí)際上，即使測(cè)試了所有的軟件代碼，仍然不能保證軟件完全滿足了用戶需求和軟件設(shè)計(jì)要求，也不能代表測(cè)試覆蓋率很高。（2）認(rèn)為100%的代碼覆蓋率就能夠保證軟件質(zhì)量：實(shí)際上，即60實(shí)際上，即使測(cè)試了所有的軟件代碼，仍然不能保證軟件完全滿足了用戶需求和軟件設(shè)計(jì)要求，也不能代表測(cè)試覆蓋率很高。綜合以上說(shuō)明，可以進(jìn)一步理解代碼覆蓋率的實(shí)際意義：實(shí)際上，即使測(cè)試了所有的軟件代碼，仍然不能保證軟61量測(cè)試工作的完成度，為確定何時(shí)可以結(jié)束測(cè)試提供依據(jù)。確定沒(méi)有被測(cè)試覆蓋到的代碼，從而檢驗(yàn)前期測(cè)試設(shè)計(jì)是否充分，是否存在測(cè)試盲點(diǎn)。量測(cè)試工作的完成度，為確定何時(shí)可以結(jié)束測(cè)試提供依據(jù)。62檢測(cè)出程序中的錯(cuò)誤和無(wú)用代碼，促使程序設(shè)計(jì)和開發(fā)人員理清代碼邏輯關(guān)系，提升代碼質(zhì)量。作為檢驗(yàn)軟件質(zhì)量的輔助指標(biāo)。代碼覆蓋率高并不能說(shuō)明軟件質(zhì)量高，但是代碼覆蓋率低，軟件質(zhì)量也不可能得到有效保障。檢測(cè)出程序中的錯(cuò)誤和無(wú)用代碼，促使程序設(shè)計(jì)和開發(fā)人員理清代碼63

6.4.3質(zhì)量評(píng)估件缺陷反映了軟件與需求的偏差，因此測(cè)試工作中一般通過(guò)分析軟件缺陷來(lái)評(píng)估軟件的質(zhì)量。缺陷分析是軟件質(zhì)量評(píng)估的一種重要手段，缺陷分析指標(biāo)可以看做是度量軟件質(zhì)量的重要指標(biāo)。6.4.3質(zhì)量評(píng)估件缺陷反映了軟件與需求的偏差，因此測(cè)64軟件缺陷分析和評(píng)估有很多種方法，從簡(jiǎn)單的缺陷數(shù)量統(tǒng)計(jì)到復(fù)雜的基于數(shù)學(xué)模型的分析。常用的缺陷分析方法主要包括缺陷趨勢(shì)分析、缺陷分布分析、缺陷注入-發(fā)現(xiàn)矩陣分析，下面分別對(duì)上述3種方法進(jìn)行詳細(xì)介紹:軟件缺陷分析和評(píng)估有很多種方法，從簡(jiǎn)單的缺陷數(shù)量651、缺陷趨勢(shì)分析缺陷趨勢(shì)分析是根據(jù)缺陷數(shù)量隨時(shí)間變化的情況，分析和監(jiān)控開發(fā)與測(cè)試的進(jìn)展?fàn)顩r與質(zhì)量，預(yù)測(cè)未來(lái)軟件研發(fā)工作情況。1、缺陷趨勢(shì)分析66（1）缺陷發(fā)現(xiàn)率與測(cè)試?yán)锍瘫?；單位時(shí)間內(nèi)發(fā)現(xiàn)的缺陷數(shù)量稱為缺陷發(fā)現(xiàn)率，圖6-4反映了一般情況下缺陷發(fā)現(xiàn)率與測(cè)試成本之間的關(guān)系。圖6-4缺陷發(fā)現(xiàn)率與測(cè)試成本（1）缺陷發(fā)現(xiàn)率與測(cè)試?yán)锍瘫?；單位時(shí)間內(nèi)發(fā)現(xiàn)的缺陷數(shù)量稱為缺67實(shí)際工作中，缺陷發(fā)現(xiàn)率的變化情況并不會(huì)像圖6-4中的那樣理想，不同測(cè)試階段的缺陷發(fā)現(xiàn)能力不同，程序開發(fā)和缺陷修復(fù)的效率變化情況也會(huì)對(duì)缺陷發(fā)現(xiàn)率產(chǎn)生直接影響。重要的是通過(guò)缺陷趨勢(shì)分析及時(shí)掌握軟件的當(dāng)前狀態(tài)，合理制定測(cè)試下一階段的計(jì)劃。實(shí)際工作中，缺陷發(fā)現(xiàn)率的變化情況并不會(huì)像圖6-4中68圖6-5是微軟基于缺陷趨勢(shì)圖的里程碑定義，從缺陷趨勢(shì)圖可以找出“Bug收斂點(diǎn)”，第一次出現(xiàn)新增缺陷數(shù)量為零的時(shí)間點(diǎn)被定義為“零Bug反彈點(diǎn)”。圖6-5是微軟基于缺陷趨勢(shì)圖的里程碑定義，從缺陷69（2）缺陷趨勢(shì)與缺陷處理質(zhì)量缺陷趨勢(shì)分析還可以延伸到對(duì)測(cè)試質(zhì)量和缺陷修復(fù)質(zhì)量的分析。通過(guò)分析和對(duì)比新增缺陷、已修復(fù)缺陷和已關(guān)閉缺陷的變化趨勢(shì)，可以了解測(cè)試的效率和開發(fā)人員修復(fù)缺陷的效率，找出測(cè)試延期的原因，發(fā)現(xiàn)測(cè)試瓶頸（2）缺陷趨勢(shì)與缺陷處理質(zhì)量70為了獲得穩(wěn)定、規(guī)律性的趨勢(shì)曲線，一般采用缺陷累積數(shù)量進(jìn)行缺陷處理質(zhì)量分析，圖6-6是一個(gè)新增、已修復(fù)和已關(guān)閉缺陷的趨勢(shì)變化對(duì)比圖，趨勢(shì)曲線斜率的大小反映了缺陷的處理效率。為了獲得穩(wěn)定、規(guī)律性的趨勢(shì)曲線，一般采用缺陷累積數(shù)量進(jìn)行缺陷71為了獲得穩(wěn)定、規(guī)律性的趨勢(shì)曲線，一般采用缺陷累積數(shù)量進(jìn)行缺陷處理質(zhì)量分析，圖6-6是一個(gè)新增、已修復(fù)和已關(guān)閉缺陷的趨勢(shì)變化對(duì)比圖，趨勢(shì)曲線斜率的大小反映了缺陷的處理效率。為了獲得穩(wěn)定、規(guī)律性的趨勢(shì)曲線，一般采用缺陷累積數(shù)量進(jìn)行缺陷72實(shí)際測(cè)試工作中，通過(guò)繪制、分析和對(duì)比上述趨勢(shì)曲線，可以獲得以下一些非常有價(jià)值的有關(guān)開發(fā)和測(cè)試質(zhì)量的信息:缺陷越早被發(fā)現(xiàn)，對(duì)軟件質(zhì)量的影響越小，修復(fù)的成本也越低;實(shí)際測(cè)試工作中，通過(guò)繪制、分析和對(duì)比上述趨勢(shì)曲線，可以獲得以73缺陷打開與關(guān)閉的時(shí)間差決定了軟件項(xiàng)目的進(jìn)度，這一時(shí)間差當(dāng)然越小越好;如果新增缺陷曲線已趨于平緩，但缺陷修復(fù)和關(guān)閉曲線一直在新增曲線下面，說(shuō)明缺陷處理效率過(guò)低，缺陷處理瓶頸在開發(fā)人員那邊。;缺陷打開與關(guān)閉的時(shí)間差決定了軟件項(xiàng)目的進(jìn)度，這一時(shí)間差當(dāng)然越74當(dāng)新開始一個(gè)測(cè)試階段時(shí)，如果發(fā)現(xiàn)新增缺陷曲線出現(xiàn)一個(gè)突起，說(shuō)明有較多的缺陷在之前的測(cè)試階段未被發(fā)現(xiàn)，遺留到了本階段，或者說(shuō)明之前的缺陷修復(fù)引入了新的缺陷，需要盡快處理上述缺陷，穩(wěn)定軟件質(zhì)量。當(dāng)新開始一個(gè)測(cè)試階段時(shí)，如果發(fā)現(xiàn)新增缺陷曲線出現(xiàn)一個(gè)突起，說(shuō)75實(shí)際趨勢(shì)曲線不可能都是平滑的，當(dāng)發(fā)現(xiàn)任何與理想曲線存在顯著差異的地方，都意味著測(cè)試與開發(fā)工作出現(xiàn)了某種問(wèn)題，例如測(cè)試策略錯(cuò)誤或者是人力資源不足等，需要盡快分析問(wèn)題產(chǎn)生的原因。同時(shí)，分析結(jié)果為今后工作中進(jìn)行質(zhì)量改進(jìn)提供了非常有價(jià)值的經(jīng)驗(yàn)數(shù)據(jù)。實(shí)際趨勢(shì)曲線不可能都是平滑的，當(dāng)發(fā)現(xiàn)任何與理想曲線存在顯著差762、缺陷分布分析缺陷分布分析是將缺陷數(shù)量作為一個(gè)或多個(gè)缺陷屬性的函數(shù)來(lái)顯示，分析不同類型的缺陷對(duì)軟件質(zhì)量的影響情況，尋找測(cè)試工作的薄弱環(huán)節(jié)。2、缺陷分布分析77對(duì)缺陷進(jìn)行分類統(tǒng)計(jì)分析，常用的缺陷屬性有以下4種：狀態(tài)：新提交的、打開的、已修復(fù)的、已關(guān)閉的當(dāng)前缺陷狀態(tài)。優(yōu)先級(jí)：反映了修復(fù)缺陷的優(yōu)先順序。嚴(yán)重性：表示缺陷對(duì)軟件產(chǎn)品和用戶使用影響的惡劣程度。來(lái)源：導(dǎo)致缺陷的原因及其來(lái)源位置。對(duì)缺陷進(jìn)行分類統(tǒng)計(jì)分析，常用的缺陷屬性有以下4種：78

最為簡(jiǎn)單的缺陷分布分析是統(tǒng)計(jì)已發(fā)現(xiàn)的缺陷在軟件主要模塊中的分布情況，如圖6-7（a）所示。分析的結(jié)果可以直觀和清晰地表明哪些模塊中的缺陷較多，根據(jù)缺陷二八定律需要在后續(xù)工作中重點(diǎn)測(cè)試這些模塊。圖6-7主要功能模塊缺陷分布圖最為簡(jiǎn)單的缺陷分布分析是統(tǒng)計(jì)已發(fā)現(xiàn)的缺陷在軟件主79需要注意的是，單純的缺陷數(shù)量并不能決定模塊的質(zhì)量，應(yīng)當(dāng)采用缺陷密度來(lái)更為準(zhǔn)確地評(píng)估模塊代碼的質(zhì)量，如圖6-7（b）所示。缺陷密度是用平均估算法來(lái)度量代碼的質(zhì)量，一般通過(guò)下面的公式進(jìn)行計(jì)算，代碼行通常以千行為單位。

（4）需要注意的是，單純的缺陷數(shù)量并不能決定模塊的質(zhì)量，應(yīng)當(dāng)采用缺80圖6-8是一個(gè)缺陷優(yōu)先級(jí)分布圖，一般要求立即解決和高優(yōu)先級(jí)的缺陷數(shù)量不應(yīng)過(guò)多，否則意味著缺陷會(huì)頻繁阻塞測(cè)試工作的正常進(jìn)行，嚴(yán)重影響測(cè)試效率。

圖6-8軟件缺陷優(yōu)先級(jí)分布圖圖6-8是一個(gè)缺陷優(yōu)先級(jí)分布圖，一般要求立即解決81

對(duì)于缺陷嚴(yán)重性，可以采用加權(quán)的方法分析缺陷對(duì)軟件質(zhì)量的影響，如表6-7所示。表6-7軟件缺陷嚴(yán)重等級(jí)權(quán)值與缺陷影響缺陷嚴(yán)重等級(jí)權(quán)值缺陷數(shù)量嚴(yán)重性加權(quán)數(shù)量致命（Fatal）4N14N1嚴(yán)重（Cirtical）3N23N2重要（Major）2N32N3較?。∕inor）1N4N4對(duì)于缺陷嚴(yán)重性，可以采用加權(quán)的方法分析缺陷對(duì)軟件質(zhì)量的影82進(jìn)一步，可以給出更為直觀的嚴(yán)重性加權(quán)后的模塊缺陷分布圖，如圖6-9所示。圖6-9嚴(yán)重性加權(quán)后的模塊缺陷分布圖進(jìn)一步，可以給出更為直觀的嚴(yán)重性加權(quán)后的模塊缺陷分布圖，如圖83

更為深入的，可以分析缺陷的來(lái)源，也就是統(tǒng)計(jì)分析不同類型缺陷的數(shù)量，找出造成軟件缺陷的最主要原因。這一類型的缺陷分布分析有助于使測(cè)試人員將測(cè)試注意力集中到那些最容易產(chǎn)生缺陷的軟件區(qū)域，也能夠使開發(fā)人員在今后工作中更有針對(duì)性地提高代碼質(zhì)量。更為深入的，可以分析缺陷的來(lái)源，也就是統(tǒng)計(jì)分析不84

如圖6-10所示，缺陷主要來(lái)源于需求說(shuō)明、系統(tǒng)設(shè)計(jì)和數(shù)據(jù)庫(kù)，直觀提示這些軟件部分需要更為深入和細(xì)致的測(cè)試。圖6-10軟件缺陷來(lái)源分布圖如圖6-10所示，缺陷主要來(lái)源于需求說(shuō)明、系統(tǒng)設(shè)853、缺陷注入-發(fā)現(xiàn)矩陣分析軟件缺陷有“注入階段”和“發(fā)現(xiàn)階段”兩個(gè)階段。注入階段即缺陷的來(lái)源（Source）階段，是指在軟件開發(fā)的哪個(gè)具體階段造成了這個(gè)軟件缺陷；而發(fā)現(xiàn)階段是缺陷的起源（Origin）階段，是指在開發(fā)和測(cè)試過(guò)程中第一次發(fā)現(xiàn)該缺陷的階段。3、缺陷注入-發(fā)現(xiàn)矩陣分析86根據(jù)缺陷報(bào)告中缺陷來(lái)源和起源屬性，可以構(gòu)造如表6-8所示的“缺陷注入-發(fā)現(xiàn)矩陣”。表中的數(shù)字代表了在某一發(fā)現(xiàn)階段所找到并清除的由特定注入階段造成的軟件缺陷數(shù)量。表6-8缺陷注入-發(fā)現(xiàn)矩陣發(fā)現(xiàn)階段注入階段需求階段設(shè)計(jì)階段編碼與單元測(cè)試集成測(cè)試系統(tǒng)測(cè)試驗(yàn)收測(cè)試產(chǎn)品發(fā)布后發(fā)現(xiàn)總計(jì)本階段缺陷清除率需求1214452003732%設(shè)計(jì)―201661214643%編碼――10529169816763%注入總計(jì)12341254019119250根據(jù)缺陷報(bào)告中缺陷來(lái)源和起源屬性，可以構(gòu)造如表6-8所示的“87（1）軟件缺陷清除率通過(guò)“缺陷注入-發(fā)現(xiàn)矩陣”，可以計(jì)算得到以下兩種測(cè)試評(píng)估度量指標(biāo)。

階段缺陷清除率=（本階段發(fā)現(xiàn)的缺陷數(shù)/本階段注入的缺陷數(shù)）*100%（5）

階段缺陷泄漏率=（下游發(fā)現(xiàn)的本階段的缺陷數(shù)/本階段注入的缺陷數(shù)）*100%（6）（1）軟件缺陷清除率88階段缺陷清除率反映的是某一軟件研發(fā)階段的缺陷清除能力，是缺陷密度度量的擴(kuò)展，可以評(píng)估需求評(píng)審、設(shè)計(jì)評(píng)審、代碼審查和測(cè)試的質(zhì)量。缺陷發(fā)現(xiàn)階段和注入階段可以根據(jù)軟件項(xiàng)目特點(diǎn)進(jìn)行劃分，根本目的是評(píng)估出軟件開發(fā)各個(gè)環(huán)節(jié)的質(zhì)量，找出薄弱環(huán)節(jié)，從而有針對(duì)性地進(jìn)行過(guò)程改進(jìn)。階段缺陷清除率反映的是某一軟件研發(fā)階段的缺陷清除89設(shè)F為描述軟件規(guī)模的功能點(diǎn)數(shù)，D1為軟件開發(fā)過(guò)程中所發(fā)現(xiàn)的所有缺陷數(shù)，D2為軟件發(fā)布以后發(fā)現(xiàn)的缺陷數(shù)，D=D1+D2為發(fā)現(xiàn)的缺陷總數(shù)?？梢酝ㄟ^(guò)以下幾種度量方式來(lái)評(píng)估軟件的質(zhì)量：

軟件質(zhì)量（每個(gè)功能點(diǎn)的缺陷數(shù)）=D2/F

（7）

軟件缺陷注入率=D/F*100%（8）

整體軟件缺陷清除率=D1/D*100%

（9）設(shè)F為描述軟件規(guī)模的功能點(diǎn)數(shù)，D1為軟件開發(fā)過(guò)程中所發(fā)現(xiàn)的所90例如，某個(gè)軟件有100個(gè)功能點(diǎn)，開發(fā)過(guò)程中發(fā)現(xiàn)了20個(gè)軟件缺陷，軟件發(fā)布后又發(fā)現(xiàn)了3個(gè)缺陷，那么F=100，D1=20，D2=3，D=23。由上述公式計(jì)算可得：軟件質(zhì)量（每個(gè)功能點(diǎn)的缺陷數(shù)）=D2/F=3/100=0.03軟件缺陷注入率=D/F=23/100=23%整體軟件缺陷清除率=D1/D=20/23=86.96%整體軟件缺陷清除率一般需要達(dá)到85%以上，著名軟件公司主流產(chǎn)品的整體軟件缺陷清除率可以達(dá)到98%。例如，某個(gè)軟件有100個(gè)功能點(diǎn)，開發(fā)過(guò)程中發(fā)現(xiàn)了20個(gè)軟件缺91（2）缺陷潛伏期一個(gè)軟件缺陷被發(fā)現(xiàn)的時(shí)間越晚，其帶來(lái)的損害性就越大，修復(fù)的成本也會(huì)越高。缺陷潛伏期是一種特殊類型的缺陷分布度量，也稱為階段潛伏期，（2）缺陷潛伏期92為了體現(xiàn)缺陷潛伏期的長(zhǎng)短和缺陷的損害程度，首先需要給“缺陷注入-發(fā)現(xiàn)矩陣”中的元素賦予合適的權(quán)值，如表6-9所示。表6-9缺陷潛伏期的權(quán)值

發(fā)現(xiàn)階段注入階段需求階段設(shè)計(jì)階段編碼與單元測(cè)試集成測(cè)試系統(tǒng)測(cè)試驗(yàn)收測(cè)試產(chǎn)品發(fā)布后需求0123456設(shè)計(jì)―012345編碼――01234為了體現(xiàn)缺陷潛伏期的長(zhǎng)短和缺陷的損害程度，首先需要給“缺陷注93

如表6-8所示的“缺陷注入-發(fā)現(xiàn)矩陣”已經(jīng)明確表示了缺陷注入時(shí)間、發(fā)現(xiàn)時(shí)間及其數(shù)量，通過(guò)加權(quán)計(jì)算可以得到如表6-10所示的軟件缺陷損耗值，矩陣中的元素是經(jīng)過(guò)缺陷潛伏期加權(quán)后的已發(fā)現(xiàn)缺陷的數(shù)量。表6-10軟件缺陷的損耗值

發(fā)現(xiàn)階段注入階段需求階段設(shè)計(jì)階段編碼與單元測(cè)試集成測(cè)試系統(tǒng)測(cè)試驗(yàn)收測(cè)試產(chǎn)品發(fā)布后損耗總計(jì)階段缺陷損耗需求014815800451.22設(shè)計(jì)―01612385440.96編碼――0293227321200.72如表6-8所示的“缺陷注入-發(fā)現(xiàn)矩陣”已經(jīng)明確表94表6-10中顯示了一種度量指標(biāo)“缺陷損耗”。缺陷損耗綜合了缺陷潛伏期和缺陷分布因素，用來(lái)度量缺陷發(fā)現(xiàn)過(guò)程的有效性和修復(fù)缺陷所耗費(fèi)的成本，其計(jì)算公式如下：

（10）表6-10中顯示了一種度量指標(biāo)“缺陷損耗”。缺陷95例如，表6-10中由需求分析缺陷造成的缺陷損耗為45/37=1.22，45是加權(quán)求和后的損耗總計(jì)數(shù)值，37是表6-8中總共發(fā)現(xiàn)的需求分析缺陷數(shù)量。這樣計(jì)算產(chǎn)生的實(shí)際上是階段缺陷損耗，同樣的原理可以計(jì)算整體軟件的缺陷損耗。例如，表6-10中由需求分析缺陷造成的缺陷損耗為96缺陷損耗的數(shù)值越低，說(shuō)明缺陷的發(fā)現(xiàn)和修復(fù)過(guò)程越有效。當(dāng)把發(fā)現(xiàn)和注入階段相同時(shí)的缺陷權(quán)值設(shè)為0時(shí)，理想缺陷損耗的數(shù)值是0，也就是把各階段注入的缺陷全部在該階段發(fā)現(xiàn)并修復(fù)了。通過(guò)積累和分析項(xiàng)目長(zhǎng)期缺陷損耗的歷史數(shù)值，可以度量測(cè)試有效性的改進(jìn)趨勢(shì)。缺陷損耗的數(shù)值越低，說(shuō)明缺陷的發(fā)現(xiàn)和修復(fù)過(guò)程越有976.4.4性能評(píng)估通過(guò)性能測(cè)試可以獲得與軟件性能表現(xiàn)相關(guān)的各方面數(shù)據(jù)，性能評(píng)估就是基于這些數(shù)據(jù)分析、顯示和報(bào)告軟件的性能特征。性能評(píng)估通常與性能測(cè)試的執(zhí)行過(guò)程結(jié)合進(jìn)行，用于顯示性能測(cè)試的進(jìn)度和狀態(tài)，也可以在性能測(cè)試完成后對(duì)測(cè)試結(jié)果進(jìn)行統(tǒng)計(jì)分析。6.4.4性能評(píng)估通過(guò)性能測(cè)試可以獲得與軟件98主要的性能評(píng)估包括以下內(nèi)容：（1）動(dòng)態(tài)監(jiān)測(cè)：在測(cè)試過(guò)程中實(shí)時(shí)獲取和顯示被測(cè)軟件的性能表現(xiàn)、狀態(tài)、用例執(zhí)行進(jìn)度等信息；主要的性能評(píng)估包括以下內(nèi)容：99（2）響應(yīng)時(shí)間或吞吐量：用曲線圖等顯示響應(yīng)時(shí)間或吞吐量隨系統(tǒng)負(fù)載變化的情況，評(píng)估被測(cè)軟件對(duì)象在不同條件下的性能表現(xiàn)。除了顯示軟件的實(shí)際性能之外，還可以統(tǒng)計(jì)分析數(shù)據(jù)的平均值和標(biāo)準(zhǔn)差，對(duì)性能指標(biāo)的穩(wěn)定性作出評(píng)估。（2）響應(yīng)時(shí)間或吞吐量：用曲線圖等顯示響應(yīng)時(shí)間或吞吐量隨系統(tǒng)100（3）百分比報(bào)告：百分比報(bào)告用于計(jì)算和顯示各種百分比值；（4）追蹤和配置文件報(bào)告：通過(guò)這些信息可以更為準(zhǔn)確地定位性能瓶頸或性能異常等情況下的缺陷位置，分析和總結(jié)缺陷產(chǎn)生的具體原因；（3）百分比報(bào)告：百分比報(bào)告用于計(jì)算和顯示各種百分比值；101（5）比較報(bào)告：是一種最常用的評(píng)估軟件性能的形式。通過(guò)比較不同性能測(cè)試的運(yùn)行結(jié)果，評(píng)估性能改進(jìn)措施是否有效以及性能提升的程度，分析不同性能測(cè)試結(jié)果數(shù)據(jù)集之間的差異或趨勢(shì)。（5）比較報(bào)告：是一種最常用的評(píng)估軟件性能的形式。通過(guò)比較不102

6.5測(cè)試總結(jié)報(bào)告在完成測(cè)試評(píng)估的基礎(chǔ)上就可以著手編寫測(cè)試總結(jié)報(bào)告。測(cè)試總結(jié)報(bào)告是為了總結(jié)和評(píng)價(jià)測(cè)試活動(dòng)的結(jié)果，分析和討論軟件的風(fēng)險(xiǎn)和質(zhì)量狀態(tài)，發(fā)現(xiàn)測(cè)試工作仍然存在的不足之處，對(duì)測(cè)試計(jì)劃的完成情況進(jìn)行最終說(shuō)明。6.5測(cè)試總結(jié)報(bào)告在完成測(cè)試評(píng)估的基礎(chǔ)上103在IEEE標(biāo)準(zhǔn)829-2008和國(guó)家標(biāo)準(zhǔn)GB/T9386-2008中都給出了測(cè)試總結(jié)報(bào)告的編寫標(biāo)準(zhǔn)，兩者實(shí)質(zhì)要求類似，都要求給出實(shí)際測(cè)試與測(cè)試計(jì)劃的差異、綜合評(píng)估、測(cè)試結(jié)果匯總、測(cè)試項(xiàng)總體評(píng)價(jià)、結(jié)論和建議等。在IEEE標(biāo)準(zhǔn)829-2008和國(guó)家標(biāo)準(zhǔn)GB/T104這里以IEEE標(biāo)準(zhǔn)為例進(jìn)行說(shuō)明。IEEE標(biāo)準(zhǔn)如表6-11所示，分為階段測(cè)試報(bào)告和主測(cè)試報(bào)告兩種，Level代表了單元、集成、系統(tǒng)和驗(yàn)收測(cè)試中的一種。階段測(cè)試報(bào)告綱要主測(cè)試報(bào)告綱要LevelTestReportOutline1.Introduction1.1.Documentidentifier1.2.Scope1.3.References2.Details2.1.Overviewoftestresults2.2.Detailedtestresults2.3.Rationalefordecisions2.4.Conclusionsandrecommendations3.General3.1.Glossary3.2.Documentchangeprocedures

andhistoryMasterTestReportOutline1.Introduction1.1.Documentidentifier1.2.Scope1.3.References2.DetailsoftheMasterTestReport2.1.Overviewofallaggregatetestresults2.2.Rationalefordecisions2.3.Conclusionsandrecommendations3.General3.1.Glossary3.2.Documentchangeproceduresand

history表6-11IEEE829-2008測(cè)試報(bào)告綱要這里以IEEE標(biāo)準(zhǔn)為例進(jìn)行說(shuō)明。IEEE標(biāo)準(zhǔn)如表105兩類報(bào)告在介紹（Introduction）和常規(guī)（General）部分都包含如下信息。文檔標(biāo)識(shí)符（Documentidentifier）；范圍（Scope）；引用文件（References）；詞匯表（Glossary）；文檔變更過(guò)程和歷史記錄（Documentchangeproceduresandhistory）。兩類報(bào)告在介紹（Introduction）和常規(guī)（G106階段測(cè)試報(bào)告細(xì)節(jié)內(nèi)容（Details）如下：（1）測(cè)試結(jié)果綜述（Overviewoftestresults）（2）測(cè)試結(jié)果詳細(xì)說(shuō)明（Detailedtestresults）（3）決策理由（Rationalefordecisions）（4）結(jié)論與建議（Conclusionsandrecommendations）階段測(cè)試報(bào)告細(xì)節(jié)內(nèi)容（Details）如下：107主測(cè)試報(bào)告細(xì)節(jié)內(nèi)容（DetailsofMTR）如下：（1）測(cè)試總體結(jié)果綜述；測(cè)試活動(dòng)總結(jié)；測(cè)試任務(wù)結(jié)果總結(jié)；缺陷及其處理情況總結(jié)；評(píng)估軟件質(zhì)量；總結(jié)已完成的所有測(cè)試評(píng)估度量指標(biāo)；主測(cè)試報(bào)告細(xì)節(jié)內(nèi)容（DetailsofMTR）如下：108（2）決策理由：給出軟件測(cè)試通過(guò)、失敗或有條件通過(guò)（Conditional-Pass）的結(jié)論及其原因；（3）結(jié)論與建議：對(duì)軟件產(chǎn)品進(jìn)行全面評(píng)估，可以包括對(duì)失敗風(fēng)險(xiǎn)的估計(jì)。（2）決策理由：給出軟件測(cè)試通過(guò)、失敗或有條件通過(guò)（Cond109軟件測(cè)試技術(shù)

第六章缺陷報(bào)告與測(cè)試評(píng)估軟件測(cè)試技術(shù)

第六章缺陷報(bào)告與測(cè)試評(píng)估110第六章缺陷報(bào)告與測(cè)試評(píng)估軟件缺陷的主要屬性軟件缺陷報(bào)告軟件缺陷的生命周期與處理流程 軟件測(cè)試的評(píng)估測(cè)試總結(jié)報(bào)告第六章缺陷報(bào)告與測(cè)試評(píng)估軟件缺陷的主要屬性111

6.1.軟件缺陷的主要屬性為了正確、全面地描述軟件缺陷首先需要了解缺陷的一些主要屬性，這些屬性為缺陷修復(fù)和缺陷統(tǒng)計(jì)分析提供了重要依據(jù)。軟件缺陷包括以下一些主要屬性：（1）缺陷標(biāo)識(shí)（Identifier）唯一標(biāo)識(shí)一個(gè)軟件缺陷的符號(hào)，通常用數(shù)字編號(hào)表示。當(dāng)使用缺陷管理系統(tǒng)時(shí)，由軟件自動(dòng)生成；6.1.軟件缺陷的主要屬性為了正確、全面地描述軟件缺陷112（2）缺陷類型（Type）表6-1軟件缺陷的類型缺陷類型描述功能對(duì)軟件使用產(chǎn)生重要影響，需要正式變更設(shè)計(jì)文檔。例如功能缺失、功能錯(cuò)誤、功能超出需求和設(shè)計(jì)范圍、重要算法錯(cuò)誤等界面影響人機(jī)交互的正確性和有效性，如軟件界面顯示、操作、易用性等方面的問(wèn)題性能不滿足性能需求指標(biāo)，如響應(yīng)時(shí)間慢、事務(wù)處理率低、不能支持規(guī)定的并發(fā)用戶數(shù)等接口軟件單元接口之間存在調(diào)用方式、參數(shù)類型、參數(shù)數(shù)量等不匹配、相互沖突等問(wèn)題邏輯分支、循環(huán)、程序執(zhí)行路徑等程序邏輯錯(cuò)誤，需要修改代碼計(jì)算錯(cuò)誤的公式、計(jì)算精度、運(yùn)算符優(yōu)先級(jí)等造成的計(jì)算錯(cuò)誤數(shù)據(jù)數(shù)據(jù)類型、變量初始化、變量引用、輸入與輸出數(shù)據(jù)等方面的錯(cuò)誤（2）缺陷類型（Type）缺陷類型描述功能對(duì)軟件使用產(chǎn)生重要113附表：缺陷類型描述文檔影響軟件發(fā)布和維護(hù)的、包括注釋在內(nèi)的文檔缺陷配置軟件配置變更或版本控制引起的錯(cuò)誤標(biāo)準(zhǔn)不符合編碼標(biāo)準(zhǔn)、軟件標(biāo)準(zhǔn)、行業(yè)標(biāo)準(zhǔn)等兼容操作系統(tǒng)、瀏覽器、顯示分辨率等方面的兼容性問(wèn)題安全影響軟件系統(tǒng)安全性的缺陷其它上述問(wèn)題中不包含的其它問(wèn)題附表：缺陷類型描述文檔影響軟件發(fā)布和維護(hù)的、包括注釋在內(nèi)的文114（3）缺陷嚴(yán)重程度(Severity)表6-2軟件缺陷的嚴(yán)重程度缺陷嚴(yán)重等級(jí)描述致命（Fatal）缺陷會(huì)導(dǎo)致系統(tǒng)的某些主要功能完全喪失，系統(tǒng)無(wú)法正常執(zhí)行基本功能，用戶數(shù)據(jù)遭到破壞，系統(tǒng)出現(xiàn)崩潰、懸掛和死機(jī)現(xiàn)象，甚至危及人身安全嚴(yán)重（Cirtical）系統(tǒng)的主要功能部分喪失，次要功能完全喪失，用戶數(shù)據(jù)不能正常保存，缺陷嚴(yán)重影響用戶對(duì)軟件系統(tǒng)的正常使用。包括可能造成系統(tǒng)崩潰等災(zāi)難性后果的缺陷、數(shù)據(jù)庫(kù)錯(cuò)誤等重要（Major）產(chǎn)生錯(cuò)誤的運(yùn)行結(jié)果，導(dǎo)致系統(tǒng)不穩(wěn)定，對(duì)系統(tǒng)功能和性能產(chǎn)生重要影響。例如，系統(tǒng)操作響應(yīng)時(shí)間不滿足要求，某些功能需求未實(shí)現(xiàn)、業(yè)務(wù)流程不正確、系統(tǒng)出現(xiàn)某些意外故障等較?。∕inor）缺陷會(huì)使用戶使用軟件不方便或遇到麻煩，但不影響用戶的正常使用，也不影響系統(tǒng)的穩(wěn)定性。主要指用戶界面方面的一些問(wèn)題，例如提示信息不準(zhǔn)確、錯(cuò)別字、界面不一致等（3）缺陷嚴(yán)重程度(Severity)缺陷嚴(yán)重等級(jí)描述致命115（4）缺陷優(yōu)先級(jí)(Priority)：缺陷的優(yōu)先級(jí)是從開發(fā)人員和測(cè)試人員的角度出發(fā)，以合理安排工作時(shí)間和提高工作效率為目標(biāo)進(jìn)行設(shè)置的；表6-3軟件缺陷的優(yōu)先級(jí)缺陷優(yōu)先級(jí)描述立即解決（ResolveImmediately）缺陷的存在導(dǎo)致系統(tǒng)幾乎無(wú)法運(yùn)行和使用，或者是造成測(cè)試無(wú)法繼續(xù)進(jìn)行，例如無(wú)法通過(guò)冒煙測(cè)試，必須立即予以修復(fù)高優(yōu)先級(jí)（HighPriority）缺陷嚴(yán)重，影響測(cè)試的正常進(jìn)行，需要優(yōu)先在規(guī)定的時(shí)間內(nèi)（如24小時(shí)內(nèi)）完成修改正常排隊(duì)（NormalQueue）缺陷需要修復(fù)，但可以正常排隊(duì)等待修復(fù)低優(yōu)先級(jí)（NotUrgent）缺陷可以在開發(fā)人員有時(shí)間的時(shí)候進(jìn)行修復(fù)，如果開發(fā)和測(cè)試時(shí)間緊迫，可以在下一軟件版本中進(jìn)行修正（4）缺陷優(yōu)先級(jí)(Priority)：缺陷的優(yōu)先級(jí)是從開發(fā)116（5）缺陷出現(xiàn)的可能性（Possibility）：缺陷出現(xiàn)的可能性是指某一缺陷發(fā)生的頻率；表6-4軟件缺陷出現(xiàn)的可能性（缺陷頻率）缺陷出現(xiàn)的可能性描述總是（Always）軟件缺陷的出現(xiàn)頻率是100%，每次測(cè)試時(shí)都會(huì)重現(xiàn)通常（Often）測(cè)試用例執(zhí)行時(shí)通常會(huì)產(chǎn)生，出現(xiàn)頻率大概是80%~90%有時(shí)（Occasionally）測(cè)試時(shí)有時(shí)會(huì)產(chǎn)生這一軟件缺陷，缺陷的出現(xiàn)概率是30%~50%很少（Rarely）測(cè)試時(shí)很少產(chǎn)生這一軟件缺陷，缺陷的出現(xiàn)概率是1%~5%（5）缺陷出現(xiàn)的可能性（Possibility）：缺陷出現(xiàn)的117（6）缺陷狀態(tài)（Status）：缺陷狀態(tài)用于描述跟蹤和修復(fù)缺陷的進(jìn)展情況，也反映了缺陷在其生命周期中的不同變化。表6-5軟件缺陷的狀態(tài)缺陷狀態(tài)描述提交（Submitted）已提交入庫(kù)的缺陷激活或打開（ActiveorOpen）缺陷提交得到確認(rèn)但還未解決，缺陷等待處理拒絕（Rejected）開發(fā)人員認(rèn)為不是缺陷或重復(fù)提交的缺陷，不需要修復(fù)已修正或修復(fù)（FixedorResolved）缺陷已經(jīng)被開發(fā)人員修復(fù)，但是還沒(méi)有經(jīng)過(guò)測(cè)試人員的驗(yàn)證驗(yàn)證（Verify）缺陷驗(yàn)證通過(guò)關(guān)閉或非激活（ClosedorInactive）測(cè)試人員驗(yàn)證后認(rèn)為缺陷已經(jīng)成功修復(fù)（6）缺陷狀態(tài)（Status）：缺陷狀態(tài)用于描述跟蹤和修復(fù)缺118缺陷狀態(tài)描述重新打開（Reopen）測(cè)試人員驗(yàn)證后認(rèn)為缺陷仍然存在，等待開發(fā)人員進(jìn)一步修復(fù)推遲（Deferred）缺陷推遲到下一個(gè)軟件版本中修復(fù)保留（Onhold）由于技術(shù)原因或第三方軟件的缺陷，開發(fā)人員暫時(shí)無(wú)法修復(fù)不能重現(xiàn)（Cannotduplicate）開發(fā)人員無(wú)法重現(xiàn)缺陷，需要測(cè)試人員補(bǔ)充說(shuō)明重現(xiàn)步驟附表：缺陷狀態(tài)描述重新打開測(cè)試人員驗(yàn)證后認(rèn)為缺陷仍然存在，等待開發(fā)119（7）缺陷起源（Origin）缺陷起源是指測(cè)試時(shí)第一次發(fā)現(xiàn)缺陷的階段，例如以下一些典型階段：需求、總體設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼、單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試、產(chǎn)品試運(yùn)行、產(chǎn)品發(fā)布后用戶使用階段。發(fā)現(xiàn)缺陷的階段越早，越有利于降低改正缺陷的費(fèi)用。（7）缺陷起源（Origin）120（8）缺陷來(lái)源（Source）缺陷來(lái)源是指軟件缺陷發(fā)生的地方。在軟件生命周期某一階段發(fā)現(xiàn)的缺陷可能來(lái)源于前期階段出現(xiàn)的錯(cuò)誤。

圖6-1軟件缺陷產(chǎn)生的階段（8）缺陷來(lái)源（Source）圖6-1軟件缺陷產(chǎn)生的階段121（9）缺陷根源（RootCause）缺陷根源是指造成軟件缺陷的根本因素，主要是開發(fā)過(guò)程、工具、方法等軟件工程技術(shù)與管理因素以及測(cè)試策略等因素，通過(guò)缺陷根源分析可以改進(jìn)軟件過(guò)程管理水平。（9）缺陷根源（RootCause）1226.2軟件缺陷報(bào)告

6.2.1缺陷報(bào)告中的信息在實(shí)際工作中，經(jīng)常會(huì)出現(xiàn)由于軟件缺陷描述不清而無(wú)法重現(xiàn)缺陷、無(wú)法合理安排修復(fù)工作、后期無(wú)法對(duì)缺陷進(jìn)行統(tǒng)計(jì)分析等情況。6.2軟件缺陷報(bào)告6.2.1缺陷報(bào)告中的信息123一份完整的缺陷報(bào)告包括以下一些信息：（1）缺陷跟蹤信息；缺陷ID：唯一標(biāo)識(shí)一個(gè)軟件缺陷，便于跟蹤與查詢；標(biāo)題：缺陷的概括性文字描述；所屬項(xiàng)目：缺陷屬于哪個(gè)軟件項(xiàng)目；版本跟蹤：缺陷屬于軟件項(xiàng)目的哪一個(gè)版本，是新缺陷還是回歸缺陷；所屬模塊：缺陷位于哪個(gè)功能模塊。一份完整的缺陷報(bào)告包括以下一些信息：124（2）缺陷詳細(xì)信息測(cè)試步驟期望結(jié)果實(shí)際結(jié)果測(cè)試環(huán)境（2）缺陷詳細(xì)信息125（3）缺陷附件信息；（4）缺陷屬性信息類型：功能、用戶界面、性能、文檔等類型；嚴(yán)重程度：可以分為致命、嚴(yán)重、重要和較??；優(yōu)先級(jí)：可以分為立即解決、高優(yōu)先級(jí)、正常排隊(duì)和低優(yōu)先級(jí)；出現(xiàn)頻率：按統(tǒng)計(jì)結(jié)果標(biāo)明缺陷發(fā)生的可能性1%~100%；缺陷起源、來(lái)源和根源信息。（3）缺陷附件信息；126（5）缺陷處理信息提交人員提交時(shí)間分配的修復(fù)人員修復(fù)期限修復(fù)時(shí)間缺陷驗(yàn)證人員驗(yàn)證意見(jiàn)驗(yàn)證時(shí)間（5）缺陷處理信息1276.2.2缺陷報(bào)告模板

一份軟件缺陷報(bào)告可以包含非常豐富的缺陷描述信息。在實(shí)際工作中，一般根據(jù)軟件項(xiàng)目特點(diǎn)對(duì)上述缺陷描述信息進(jìn)行裁剪，制定合適的缺陷報(bào)告模板。6.2.2缺陷報(bào)告模板一份軟件缺陷報(bào)告可以包含非常豐128填寫模板信息時(shí)，需要遵守以下“5C”原則：Correct：對(duì)每個(gè)組成部分的描述準(zhǔn)確不會(huì)引起誤解。Clear：對(duì)每個(gè)組成部分的描述清晰，易于理解。Concise：描述信息只包含必不可少的內(nèi)容。Complete：包含重現(xiàn)缺陷的完整步驟和其它輔助信息。Consistent：按照一致的格式書寫全部缺陷報(bào)告。填寫模板信息時(shí)，需要遵守以下“5C”原則：129下表是一個(gè)較為通用的軟件缺陷報(bào)告模板，可以在實(shí)際工作中修改為更為適合特定工作要求的模板。表6-6軟件缺陷報(bào)告模板缺陷記錄缺陷ID

標(biāo)題（概述）

軟件名稱

模塊名

版本號(hào)

嚴(yán)重程度

優(yōu)先級(jí)

狀態(tài)

缺陷類型

發(fā)現(xiàn)階段

缺陷來(lái)源

缺陷頻率

可能性說(shuō)明

測(cè)試人員

分配修復(fù)人員

日期

下表是一個(gè)較為通用的軟件缺陷報(bào)告模板，可以在實(shí)際工作中修改為130

附表：缺陷記錄測(cè)試環(huán)境

測(cè)試輸入

預(yù)期結(jié)果

異常結(jié)果

缺陷重現(xiàn)步驟

附件

缺陷處理信息缺陷驗(yàn)證信息修復(fù)人

驗(yàn)證人

修復(fù)時(shí)間

驗(yàn)證時(shí)間

備注

驗(yàn)證結(jié)論附表：缺陷記錄測(cè)試環(huán)境測(cè)試輸入預(yù)期結(jié)果異常1316.2.3缺陷報(bào)告的注意事項(xiàng)

測(cè)試人員在編寫缺陷報(bào)告之前，首先需要清楚缺陷報(bào)告的主要讀者以及他們最希望從缺陷報(bào)告中獲得哪些信息。因此，測(cè)試人員在編寫缺陷報(bào)告時(shí)需要注意以下一些事項(xiàng)：（1）保證能夠重現(xiàn)缺陷；6.2.3缺陷報(bào)告的注意事項(xiàng)測(cè)試人員在編寫缺陷報(bào)告之132因此，測(cè)試人員在編寫缺陷報(bào)告時(shí)需要注意以下一些事項(xiàng)：（1）保證能夠重現(xiàn)缺陷：如果測(cè)試人員發(fā)現(xiàn)不能保證重現(xiàn)一個(gè)缺陷，那么就需要給開發(fā)人員提供盡可能多的有效信息。如果無(wú)法重現(xiàn)或者沒(méi)有驗(yàn)證是否可以重現(xiàn)時(shí)，一定要在缺陷報(bào)告中進(jìn)行說(shuō)明；因此，測(cè)試人員在編寫缺陷報(bào)告時(shí)需要注意以下一些事133

（2）一個(gè)報(bào)告只針對(duì)一個(gè)缺陷：雖然有時(shí)多個(gè)缺陷的起因是一樣的，但是在真正修復(fù)缺陷之前并不能保證知道導(dǎo)致某個(gè)缺陷的原因。因此即使單獨(dú)報(bào)告缺陷顯得有些繁瑣，但也比延誤或遺漏缺陷要好。（2）一個(gè)報(bào)告只針對(duì)一個(gè)缺陷：雖然有時(shí)多個(gè)缺陷的起因是一樣134（3）描述準(zhǔn)確、清晰：缺陷標(biāo)題必須簡(jiǎn)短，而且要求描述和傳達(dá)出準(zhǔn)確的信息；（4）重視附件信息附件信息應(yīng)當(dāng)是缺陷重現(xiàn)步驟的補(bǔ)充信息，是對(duì)測(cè)試步驟的進(jìn)一步描述；（3）描述準(zhǔn)確、清晰：缺陷標(biāo)題必須簡(jiǎn)短，而且要求描述和傳達(dá)出135（5）使用中性語(yǔ)言：使用中性語(yǔ)言是指客觀地描述缺陷問(wèn)題。用帶有感情色彩的語(yǔ)句報(bào)告缺陷除了造成研發(fā)團(tuán)隊(duì)的溝通障礙和協(xié)作困難外，對(duì)修改缺陷沒(méi)有任何好處。（5）使用中性語(yǔ)言：使用中性語(yǔ)言是指客觀地描述缺陷問(wèn)題。用帶1366.2.4分離和再現(xiàn)軟件缺陷

為了保證再現(xiàn)軟件缺陷，除了需要按照已經(jīng)介紹過(guò)的描述規(guī)則來(lái)描述軟件缺陷之外，還要遵循軟件缺陷分離和再現(xiàn)的方法。分離和再現(xiàn)軟件缺陷是充分體現(xiàn)測(cè)試人員測(cè)試才能的地方，需要在測(cè)試工作中不斷總結(jié)經(jīng)驗(yàn)，才能準(zhǔn)確地找出縮小問(wèn)題范圍的具體步驟和方法。6.2.4分離和再現(xiàn)軟件缺陷為了保證再現(xiàn)軟件缺陷，除137下面列舉一些常用的分離和再現(xiàn)軟件缺陷的方法和技巧：（1）確保所有的步驟都被記錄；（2）注意特定時(shí)間和運(yùn)行條件因素；（3）注意邊界條件、內(nèi)存容量和數(shù)據(jù)溢出問(wèn)題；（4）注意事件發(fā)生次序?qū)е碌能浖毕荩唬?）考慮軟件與其計(jì)算環(huán)境的相互作用；（6）不能忽視硬件。下面列舉一些常用的分離和再現(xiàn)軟件缺陷的方法和技巧：138

6.3軟件缺陷的生命周期與處理流程軟件缺陷的生命周期是指一個(gè)軟件缺陷從發(fā)現(xiàn)到最終被確認(rèn)修復(fù)的完整過(guò)程。在這一過(guò)程中，軟件缺陷會(huì)經(jīng)歷不同的狀態(tài)。一個(gè)典型的軟件缺陷生命周期經(jīng)歷了如下?tīng)顟B(tài)改變:6.3軟件缺陷的生命周期與處理流程軟件缺陷的生命周期是139提交→打開：測(cè)試人員提交發(fā)現(xiàn)的軟件缺陷，開發(fā)人員確認(rèn)后準(zhǔn)備修復(fù)。打開→修復(fù)：開發(fā)人員修復(fù)缺陷后通知測(cè)試人員進(jìn)行修復(fù)結(jié)果驗(yàn)證。提交→打開：測(cè)試人員提交發(fā)現(xiàn)的軟件缺陷，開發(fā)人員確認(rèn)后準(zhǔn)備修140驗(yàn)證→重新打開：測(cè)試人員執(zhí)行回歸測(cè)試，驗(yàn)證測(cè)試結(jié)果后認(rèn)為缺陷沒(méi)有完全被修復(fù)，再次打開缺陷等待開發(fā)人員重新進(jìn)一步修復(fù)。驗(yàn)證→關(guān)閉：測(cè)試人員執(zhí)行回歸測(cè)試，確認(rèn)缺陷已經(jīng)得到修復(fù)，然后將缺陷狀態(tài)設(shè)為最后的關(guān)閉狀態(tài)驗(yàn)證→重新打開：測(cè)試人員執(zhí)行回歸測(cè)試，驗(yàn)證測(cè)試結(jié)果后認(rèn)為缺陷141為了合理安排缺陷修復(fù)工作，避免遺漏任何一個(gè)缺陷，需要規(guī)劃軟件缺陷的處理流程，一般根據(jù)實(shí)際情況進(jìn)行靈活設(shè)置。上述典型軟件缺陷生命周期的處理流程如圖6-2所示。圖6-2缺陷典型處理流程為了合理安排缺陷修復(fù)工作，避免遺漏任何一個(gè)缺陷，需要規(guī)劃軟件142實(shí)際工作中，缺陷處理流程不可能像典型處理流程這樣簡(jiǎn)單，會(huì)面臨各種特殊的情況，造成軟件缺陷的生命周期更為復(fù)雜。需要考慮如下一些實(shí)際情況:開發(fā)人員認(rèn)為測(cè)試人員提交的軟件缺陷不是真正的缺陷或者是微不足道;實(shí)際工作中，缺陷處理流程不可能像典型處理流程這樣簡(jiǎn)單，會(huì)面臨143缺陷被不同測(cè)試人員重復(fù)提交;測(cè)試人員驗(yàn)證缺陷的修復(fù)結(jié)果后，認(rèn)為缺陷仍然存在或者沒(méi)有達(dá)到預(yù)期的修復(fù)效果，因而重新將缺陷設(shè)置為打開狀態(tài);缺陷優(yōu)先級(jí)比較低，項(xiàng)目研發(fā)周期有限，產(chǎn)品發(fā)布在即，缺陷可以推遲到下一版本中進(jìn)行處理;缺陷被不同測(cè)試人員重復(fù)提交;144軟件產(chǎn)品即將更新?lián)Q代，而修復(fù)某一缺陷的風(fēng)險(xiǎn)過(guò)大，可能會(huì)造成更多的問(wèn)題，經(jīng)項(xiàng)目管理人員同意后可以不必修復(fù);被推遲修復(fù)的軟件缺陷被證實(shí)很嚴(yán)重，需要立即予以修復(fù)，軟件缺陷的狀態(tài)被設(shè)置為重新打開。軟件產(chǎn)品即將更新?lián)Q代，而修復(fù)某一缺陷的風(fēng)險(xiǎn)過(guò)大，可能會(huì)造成更145由上述情況可見(jiàn)，缺陷的處理過(guò)程實(shí)際上是比較復(fù)雜的，會(huì)出現(xiàn)對(duì)缺陷修復(fù)與否和修復(fù)結(jié)果是否滿足要求的不同意見(jiàn)。因此，需要事先規(guī)定好對(duì)缺陷狀態(tài)的設(shè)置權(quán)限。一旦發(fā)現(xiàn)缺陷，就需要明確后期相關(guān)人員的工作職責(zé)，跟蹤軟件缺陷的生命周期，直到缺陷最終得到正確處理。由上述情況可見(jiàn)，缺陷的處理過(guò)程實(shí)際上是比較復(fù)雜的，會(huì)出現(xiàn)對(duì)缺146圖6-3軟件缺陷處理流程圖6-3軟件缺陷處理流程147圖6-3是一個(gè)考慮上述特殊情況后的缺陷處理流程，可以在實(shí)際工作中予以參考。從以上說(shuō)明可以理解，一個(gè)軟件缺陷除了常見(jiàn)的提交、打開、修復(fù)和關(guān)閉狀態(tài)外，還包括拒絕、驗(yàn)證、審查、推遲、保留、重新打開等附加狀態(tài)。圖6-3是一個(gè)考慮上述特殊情況后的缺陷處理流程，可以在實(shí)際工148對(duì)于缺陷數(shù)量只在幾十個(gè)范圍內(nèi)的小型軟件項(xiàng)目，用Excel制作的缺陷報(bào)告模板就可以應(yīng)對(duì)。但是對(duì)于大型軟件項(xiàng)目，要追蹤和管理成百上千個(gè)狀態(tài)不斷變化的軟件缺陷，必須使用合適的缺陷管理工具。對(duì)于缺陷數(shù)量只在幾十個(gè)范圍內(nèi)的小型軟件項(xiàng)目，用E149缺陷管理工具屬于測(cè)試管理類工具，相比其它測(cè)試類工具，學(xué)習(xí)和使用都較為簡(jiǎn)單。常用的有QC、禪道、Mantis、JIRA、TestLink、Bugzilla等。使用這些缺陷管理工具的優(yōu)勢(shì)體現(xiàn)在以下一些方面:缺陷管理工具屬于測(cè)試管理類工具，相比其它測(cè)試類工具，學(xué)習(xí)和使150強(qiáng)大的檢索功能和安全的審核機(jī)制。由于具有后臺(tái)數(shù)據(jù)庫(kù)支持，缺陷檢索、增加、修改、保存都很方便，并且能夠?qū)Ω郊M(jìn)行有效管理。通過(guò)權(quán)限設(shè)置，將缺陷操作權(quán)限與缺陷狀態(tài)相對(duì)應(yīng)，保證修改、刪除等缺陷操作的安全性。強(qiáng)大的檢索功能和安全的審核機(jī)制。由于具有后臺(tái)數(shù)據(jù)庫(kù)支持，缺陷151支持項(xiàng)目組成員間的協(xié)同工作。通過(guò)友好的網(wǎng)絡(luò)用戶界面以及Email等豐富多樣的配置設(shè)定，支持項(xiàng)目組各類成員及時(shí)了解缺陷狀態(tài)的變化情況，進(jìn)而根據(jù)對(duì)應(yīng)狀態(tài)合理地安排自己的工作，提高發(fā)現(xiàn)缺陷和改正缺陷的效率。支持項(xiàng)目組成員間的協(xié)同工作。通過(guò)友好的網(wǎng)絡(luò)用戶界面以及Ema152提高缺陷報(bào)告的質(zhì)量。保證缺陷報(bào)告的完整性和一致性，正確和完整地填寫缺陷報(bào)告的各項(xiàng)內(nèi)容，保證不同測(cè)試人員提交的測(cè)試報(bào)告格式統(tǒng)一。提高缺陷報(bào)告的質(zhì)量。保證缺陷報(bào)告的完整性和一致性，正確和完整153

6.4軟件測(cè)試的評(píng)估在軟件測(cè)試執(zhí)行過(guò)程中，需要階段性地總結(jié)和分析測(cè)試結(jié)果，確保測(cè)試過(guò)程的有效性。在軟件驗(yàn)收和發(fā)布之前，測(cè)試管理人員需要對(duì)整個(gè)測(cè)試過(guò)程和結(jié)果做出系統(tǒng)性的評(píng)價(jià)，評(píng)估測(cè)試的完成度是否達(dá)到了測(cè)試計(jì)劃規(guī)定的目標(biāo)、軟件的質(zhì)量是否滿足了用戶需求和設(shè)計(jì)要求，最終決定能否將軟件交付用戶驗(yàn)收或者最終發(fā)布。6.4軟件測(cè)試的評(píng)估在軟件測(cè)試執(zhí)行過(guò)程中，需要階段性地1546.4.1測(cè)試評(píng)估的目的和方法軟件測(cè)試的評(píng)估主要有以下目的：對(duì)測(cè)試的進(jìn)展情況進(jìn)行量化分析，確定測(cè)試和缺陷修復(fù)工作的當(dāng)前狀態(tài)、效率和完成度，判斷測(cè)試工作可以結(jié)束的時(shí)間;6.4.1測(cè)試評(píng)估的目的和方法軟件測(cè)試的評(píng)估主要有以下目155最后完成測(cè)試報(bào)告或軟件質(zhì)量分析報(bào)告提供量化分析數(shù)據(jù)，例如給出測(cè)試覆蓋率和缺陷清除率等。分析軟件研發(fā)各階段的不足之處，找出測(cè)試和開發(fā)工作中的薄弱環(huán)節(jié)，為過(guò)程監(jiān)督、質(zhì)量控制和過(guò)程改進(jìn)提供定量化依據(jù)。最后完成測(cè)試報(bào)告或軟件質(zhì)量分析報(bào)告提供量化分析數(shù)據(jù)，例如給出156從以上內(nèi)容可以看出，測(cè)試評(píng)估強(qiáng)調(diào)定量化分析，是以定量化的分析結(jié)果科學(xué)地評(píng)價(jià)測(cè)試工作和軟件質(zhì)量，為軟件過(guò)程管理提供依據(jù)。測(cè)試評(píng)估主要包括以下兩種方法:從以上內(nèi)容可以看出，測(cè)試評(píng)估強(qiáng)調(diào)定量化分析，是以定量化的分析157覆蓋率評(píng)估:評(píng)估測(cè)試的覆蓋率，對(duì)測(cè)試完成程度進(jìn)行評(píng)測(cè)。最常見(jiàn)的覆蓋率評(píng)估分為需求覆蓋率評(píng)估和代碼覆蓋率評(píng)估。覆蓋率評(píng)估:評(píng)估測(cè)試的覆蓋率，對(duì)測(cè)試完成程度進(jìn)行評(píng)測(cè)。最常見(jiàn)158質(zhì)量評(píng)估:測(cè)試過(guò)程中產(chǎn)生的軟件缺陷報(bào)告提供了最佳的軟件質(zhì)量評(píng)估數(shù)據(jù)，通過(guò)缺陷分析可以對(duì)軟件的可靠性、穩(wěn)定性等進(jìn)行詳細(xì)分析，對(duì)軟件的性能進(jìn)行多方面的評(píng)測(cè)，獲得反映軟件質(zhì)量特征的多種指標(biāo)數(shù)據(jù)，在此基礎(chǔ)上確定軟件質(zhì)量與需求的相符程度。質(zhì)量評(píng)估:測(cè)試過(guò)程中產(chǎn)生的軟件缺陷報(bào)告提供了最佳的軟件質(zhì)量評(píng)1596.4.2覆蓋率評(píng)估覆蓋率是一種常見(jiàn)的反映測(cè)試充分性和完成度的定量化指標(biāo)。測(cè)試活動(dòng)已驗(yàn)證過(guò)的軟件區(qū)域越多，軟件質(zhì)量得到保障的可能性越大，測(cè)試工作也越接近完成。因此，通過(guò)測(cè)試覆蓋率可以間接地反映測(cè)試工作的質(zhì)量和當(dāng)前軟件代碼的質(zhì)量。測(cè)試覆蓋又分為需求覆蓋和代碼覆蓋兩個(gè)方面。6.4.2覆蓋率評(píng)估覆蓋率是一種常見(jiàn)的反映測(cè)試充分性和1601、需求覆蓋率對(duì)需求的全面覆蓋是軟件測(cè)試的基本要求，需求覆蓋率是測(cè)試到的功能和非功能需求占整個(gè)需求總數(shù)的百分比。1、需求覆蓋率161由于測(cè)試計(jì)劃和測(cè)試用例設(shè)計(jì)時(shí)已經(jīng)考慮了對(duì)需求的覆蓋，因此一般可以通過(guò)已計(jì)劃的、已實(shí)施的或成功完成的測(cè)試用例的執(zhí)行率來(lái)衡量需求覆蓋率，有時(shí)也可以通過(guò)測(cè)試需求的覆蓋率來(lái)衡量。由于測(cè)試計(jì)劃和測(cè)試用例設(shè)計(jì)時(shí)已經(jīng)考慮了對(duì)需求的覆蓋，因此一般162測(cè)試評(píng)估中，通常使用以下三種公式來(lái)計(jì)算需求的測(cè)試覆蓋率：計(jì)劃的測(cè)試覆蓋率=Tp/Rft（1）已執(zhí)行的測(cè)試覆蓋率=Tx/Rft（2）成功執(zhí)行的測(cè)試覆蓋率=Ts/Rft（3）測(cè)試評(píng)估中，通常使用以下三種公式來(lái)計(jì)算需求的測(cè)試覆蓋率：163上述三個(gè)公式中，Rft是測(cè)試需求的總數(shù)，Tp是用測(cè)試過(guò)程或測(cè)試用例表示的計(jì)劃測(cè)試需求數(shù)，Tx是用測(cè)試過(guò)程或測(cè)試用例表示的已執(zhí)行的測(cè)試需求數(shù)，Ts是用完全成功、沒(méi)有缺陷或意外結(jié)果的測(cè)試過(guò)程或測(cè)試用例表示的已執(zhí)行測(cè)試需求數(shù)。通過(guò)上述三種需求覆蓋率指標(biāo)可以評(píng)估剩余測(cè)試的工作量，確定測(cè)試工作的完成時(shí)間。上述三個(gè)公式中，Rft是測(cè)試需求的總數(shù)，Tp是用測(cè)試過(guò)程或測(cè)1642、代碼覆蓋率代碼覆蓋率是指所測(cè)試的源代碼數(shù)量占代碼總數(shù)的百分比。代碼覆蓋率反映了測(cè)試用例對(duì)被測(cè)軟件代碼的覆蓋程度，也是衡量測(cè)試工作進(jìn)展情況的重要定量化指標(biāo)。2、代碼覆蓋率165很明顯，代碼覆蓋率與單元測(cè)試密切相關(guān)，是單元測(cè)試用例是否充分的重要衡量指標(biāo)。任何未經(jīng)測(cè)試的程序代碼都可能存在潛在缺陷，因此在實(shí)際測(cè)試前就應(yīng)當(dāng)根據(jù)程序規(guī)格說(shuō)明、具體代碼、規(guī)定的代碼覆蓋率要求設(shè)計(jì)出合理數(shù)量的測(cè)試用例。很明顯，代碼覆蓋率與單元測(cè)試密切相關(guān)，是單元測(cè)試用例是否充分166與手工分析需求覆蓋率不同，一般需要借助相應(yīng)的工具來(lái)統(tǒng)計(jì)代碼覆蓋率。下面列舉一些常用編程語(yǔ)言的代碼覆蓋率分析工具:C/C++：CUnit、CPPUnit、GoogleGTest、gcc+gcov+lcov等。Java

：

Clover、EMMA、JaCoCo、Jtest、MavenCobertura插件等。JavaScript：JSCoverage。Python：PyUnit+Coverage.py。PHP：PHPUnit+XDebug。Ruby：RCov。

與手工分析需求覆蓋率不同，一般需要借助相應(yīng)的工具來(lái)統(tǒng)計(jì)代碼覆167代碼覆蓋率在實(shí)際應(yīng)用中存在著一些誤區(qū)，主要反映在以下兩個(gè)方面：（1）片面追求高代碼覆蓋率:對(duì)于代碼覆蓋率的提升應(yīng)當(dāng)基于風(fēng)險(xiǎn)分析的方法，應(yīng)當(dāng)首先保證對(duì)關(guān)鍵模塊代碼的測(cè)試覆蓋，并確保徹底修復(fù)了所發(fā)現(xiàn)的軟件缺陷。只有通過(guò)風(fēng)險(xiǎn)分析，才能確定每一次提升代碼覆蓋率的實(shí)際價(jià)值；代碼覆蓋率在實(shí)際應(yīng)用中存在著一些誤區(qū)，主要反映在以下兩個(gè)方面168（2）認(rèn)為100%的代碼覆蓋率就能夠保證軟件質(zhì)量：實(shí)際上，即使測(cè)試了所有的軟件代碼，仍然不能保證軟件完全滿足了用戶需求和軟件設(shè)計(jì)要求，也不能代表測(cè)試覆蓋率很高。（2）認(rèn)為100%的代碼覆蓋率就能夠保證軟件質(zhì)量：實(shí)際上，即169實(shí)際上，即使測(cè)試了所有的軟件代碼，仍然不能保證軟件完全滿足了用戶需求和軟件設(shè)計(jì)要求，也不能代表測(cè)試覆蓋率很高。綜合以上說(shuō)明，可以進(jìn)一步理解代碼覆蓋率的實(shí)際意義：實(shí)際上，即使測(cè)試了所有的軟件代碼，仍然不能保證軟170量測(cè)