軟件測試技術

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

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

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

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

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

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

標題（概述）

軟件名稱

模塊名

版本號

嚴重程度

優先級

狀態

缺陷類型

發現階段

缺陷來源

缺陷頻率

可能性說明

測試人員

分配修復人員

日期

下表是一個較為通用的軟件缺陷報告模板，可以在實際工作中修改為21

附表：缺陷記錄測試環境

測試輸入

預期結果

異常結果

缺陷重現步驟

附件

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

驗證人

修復時間

驗證時間

備注

驗證結論附表：缺陷記錄測試環境測試輸入預期結果異常226.2.3缺陷報告的注意事項

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

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

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

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

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

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

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

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

（4）需要注意的是，單純的缺陷數量并不能決定模塊的質量，應當采用缺80圖6-8是一個缺陷優先級分布圖，一般要求立即解決和高優先級的缺陷數量不應過多，否則意味著缺陷會頻繁阻塞測試工作的正常進行，嚴重影響測試效率。

圖6-8軟件缺陷優先級分布圖圖6-8是一個缺陷優先級分布圖，一般要求立即解決81

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

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

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

階段缺陷清除率=（本階段發現的缺陷數/本階段注入的缺陷數）*100%（5）

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

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

（7）

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

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

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

發現階段注入階段需求階段設計階段編碼與單元測試集成測試系統測試驗收測試產品發布后需求0123456設計―012345編碼――01234為了體現缺陷潛伏期的長短和缺陷的損害程度，首先需要給“缺陷注93

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

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

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

6.5測試總結報告在完成測試評估的基礎上就可以著手編寫測試總結報告。測試總結報告是為了總結和評價測試活動的結果，分析和討論軟件的風險和質量狀態，發現測試工作仍然存在的不足之處，對測試計劃的完成情況進行最終說明。6.5測試總結報告在完成測試評估的基礎上103在IEEE標準829-2008和國家標準GB/T9386-2008中都給出了測試總結報告的編寫標準，兩者實質要求類似，都要求給出實際測試與測試計劃的差異、綜合評估、測試結果匯總、測試項總體評價、結論和建議等。在IEEE標準829-2008和國家標準GB/T104這里以IEEE標準為例進行說明。IEEE標準如表6-11所示，分為階段測試報告和主測試報告兩種，Level代表了單元、集成、系統和驗收測試中的一種。階段測試報告綱要主測試報告綱要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測試報告綱要這里以IEEE標準為例進行說明。IEEE標準如表105兩類報告在介紹（Introduction）和常規（General）部分都包含如下信息。文檔標識符（Documentidentifier）；范圍（Scope）；引用文件（References）；詞匯表（Glossary）；文檔變更過程和歷史記錄（Documentchangeproceduresandhistory）。兩類報告在介紹（Introduction）和常規（G106階段測試報告細節內容（Details）如下：（1）測試結果綜述（Overviewoftestresults）（2）測試結果詳細說明（Detailedtestresults）（3）決策理由（Rationalefordecisions）（4）結論與建議（Conclusionsandrecommendations）階段測試報告細節內容（Details）如下：107主測試報告細節內容（DetailsofMTR）如下：（1）測試總體結果綜述；測試活動總結；測試任務結果總結；缺陷及其處理情況總結；評估軟件質量；總結已完成的所有測試評估度量指標；主測試報告細節內容（DetailsofMTR）如下：108（2）決策理由：給出軟件測試通過、失敗或有條件通過（Conditional-Pass）的結論及其原因；（3）結論與建議：對軟件產品進行全面評估，可以包括對失敗風險的估計。（2）決策理由：給出軟件測試通過、失敗或有條件通過（Cond109軟件測試技術

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

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

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

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

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

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

標題（概述）

軟件名稱

模塊名

版本號

嚴重程度

優先級

狀態

缺陷類型

發現階段

缺陷來源

缺陷頻率

可能性說明

測試人員

分配修復人員

日期

下表是一個較為通用的軟件缺陷報告模板，可以在實際工作中修改為130

附表：缺陷記錄測試環境

測試輸入

預期結果

異常結果

缺陷重現步驟

附件

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

驗證人

修復時間

驗證時間

備注

驗證結論附表：缺陷記錄測試環境測試輸入預期結果異常1316.2.3缺陷報告的注意事項

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

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

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

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

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

與手工分析需求覆蓋率不同，一般需要借助相應的工具來統計代碼覆167代碼覆蓋率在實際應用中存在著一些誤區，主要反映在以下兩個方面：（1）片面追求高代碼覆蓋率:對于代碼覆蓋率的提升應當基于風險分析的方法，應當首先保證對關鍵模塊代碼的測試覆蓋，并確保徹底修復了所發現的軟件缺陷。只有通過風險分析，才能確定每一次提升代碼覆蓋率的實際價值；代碼覆蓋率在實際應用中存在著一些誤區，主要反映在以下兩個方面168（2）認為100%的代碼覆蓋率就能夠保證軟件質量：實際上，即使測試了所有的軟件代碼，仍然不能保證軟件完全滿足了用戶需求和軟件設計要求，也不能代表測試覆蓋率很高。（2）認為100%的代碼覆蓋率就能夠保證軟件質量：實際上，即169實際上，即使測試了所有的軟件代碼，仍然不能保證軟件完全滿足了用戶需求和軟件設計要求，也不能代表測試覆蓋率很高。綜合以上說明，可以進一步理解代碼覆蓋率的實際意義：實際上，即使測試了所有的軟件代碼，仍然不能保證軟170量測