軟件測試技術-第6章-缺陷報告與測試評估

軟件測試技術

第六章缺陷報告與測試評估第六章缺陷報告與測試評估軟件缺陷的主要屬性軟件缺陷報告軟件缺陷的生命周期與處理流程 軟件測試的評估測試總結報告

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

圖6-1軟件缺陷產(chǎn)生的階段（9）缺陷根源（RootCause）缺陷根源是指造成軟件缺陷的根本因素，主要是開發(fā)過程、工具、方法等軟件工程技術與管理因素以及測試策略等因素，通過缺陷根源分析可以改進軟件過程管理水平。6.2軟件缺陷報告

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

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

標題（概述）

軟件名稱

模塊名

版本號

嚴重程度

優(yōu)先級

狀態(tài)

缺陷類型

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

缺陷來源

缺陷頻率

可能性說明

測試人員

分配修復人員

日期

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

測試輸入

預期結果

異常結果

缺陷重現(xiàn)步驟

附件

缺陷處理信息缺陷驗證信息修復人

驗證人

修復時間

驗證時間

備注

驗證結論6.2.3缺陷報告的注意事項

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

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

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

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

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

代碼覆蓋率在實際應用中存在著一些誤區(qū)，主要反映在以下兩個方面：（1）片面追求高代碼覆蓋率:對于代碼覆蓋率的提升應當基于風險分析的方法，應當首先保證對關鍵模塊代碼的測試覆蓋，并確保徹底修復了所發(fā)現(xiàn)的軟件缺陷。只有通過風險分析，才能確定每一次提升代碼覆蓋率的實際價值；（2）認為100%的代碼覆蓋率就能夠保證軟件質量：實際上，即使測試了所有的軟件代碼，仍然不能保證軟件完全滿足了用戶需求和軟件設計要求，也不能代表測試覆蓋率很高。實際上，即使測試了所有的軟件代碼，仍然不能保證軟件完全滿足了用戶需求和軟件設計要求，也不能代表測試覆蓋率很高。綜合以上說明，可以進一步理解代碼覆蓋率的實際意義：量測試工作的完成度，為確定何時可以結束測試提供依據(jù)。確定沒有被測試覆蓋到的代碼，從而檢驗前期測試設計是否充分，是否存在測試盲點。檢測出程序中的錯誤和無用代碼，促使程序設計和開發(fā)人員理清代碼邏輯關系，提升代碼質量。作為檢驗軟件質量的輔助指標。代碼覆蓋率高并不能說明軟件質量高，但是代碼覆蓋率低，軟件質量也不可能得到有效保障。

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

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

（4）圖6-8是一個缺陷優(yōu)先級分布圖，一般要求立即解決和高優(yōu)先級的缺陷數(shù)量不應過多，否則意味著缺陷會頻繁阻塞測試工作的正常進行，嚴重影響測試效率。

圖6-8軟件缺陷優(yōu)先級分布圖

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

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

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

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

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

軟件質量（每個功能點的缺陷數(shù)）=D2/F

（7）

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

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

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

發(fā)現(xiàn)階段注入階段需求階段設計階段編碼與單元測試集成測試系統(tǒng)測試驗收測試產(chǎn)品發(fā)布后需求0123456設計―012345編碼――01234

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

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

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

6.5測試總結報告在完成測試評估的基礎上就可以著手編寫測試總結報告。測試總結報告是為了總結和評價測試活動的結果，分析和討論軟件的風險和質量狀態(tài)，發(fā)現(xiàn)測試工作仍然存在的不足之處，對測試計劃的完成情況進行最終說明。在IEEE標準829-2008和國家標準GB/T9386-2008中都給出了測試總結報告的編寫標準，兩者實質要求類似，都要求