【文档说明】软件测试技术-第六章-缺陷报告与测试评估课件.pptx，共(109)页，422.018 KB，由小橙橙上传

转载请保留链接：https://www.ichengzhen.cn/view-45276.html

以下为本文档部分文字说明：

软件测试技术第六章缺陷报告与测试评估第2页/共109页第六章缺陷报告与测试评估1.软件缺陷的主要属性2.软件缺陷报告3.软件缺陷的生命周期与处理流程4.软件测试的评估5.测试总结报告第3页/共109页6.1.软件缺陷的主要属性为了正确、全面地描述软件缺陷首先需要了解缺陷的一些

主要属性，这些属性为缺陷修复和缺陷统计分析提供了重要依据。软件缺陷包括以下一些主要属性：（1）缺陷标识（Identifier）唯一标识一个软件缺陷的符号，通常用数字编号表示。当使用缺陷管理系统时，由软件自动生成；第4页/共109页（2）缺陷类型（Type）表6-1软件缺陷的类

型缺陷类型描述功能对软件使用产生重要影响，需要正式变更设计文档。例如功能缺失、功能错误、功能超出需求和设计范围、重要算法错误等界面影响人机交互的正确性和有效性，如软件界面显示、操作、易用性等方面的问题性能不满足性能需求指标，如响应时间慢、事务处理率低、不能支持规定的并发用户数等接口软

件单元接口之间存在调用方式、参数类型、参数数量等不匹配、相互冲突等问题逻辑分支、循环、程序执行路径等程序逻辑错误，需要修改代码计算错误的公式、计算精度、运算符优先级等造成的计算错误数据数据类型、变量初始化、变量引用、输入与输出

数据等方面的错误第5页/共109页附表：缺陷类型描述文档影响软件发布和维护的、包括注释在内的文档缺陷配置软件配置变更或版本控制引起的错误标准不符合编码标准、软件标准、行业标准等兼容操作系统、浏览器、显示分辨率等方面的兼容性问题安全影响软件系统安全性的缺陷其它上述问题中不包含的其它问题第6页/共10

9页（3）缺陷严重程度(Severity)表6-2软件缺陷的严重程度缺陷严重等级描述致命（Fatal）缺陷会导致系统的某些主要功能完全丧失，系统无法正常执行基本功能，用户数据遭到破坏，系统出现崩溃、悬挂和

死机现象，甚至危及人身安全严重（Cirtical）系统的主要功能部分丧失，次要功能完全丧失，用户数据不能正常保存，缺陷严重影响用户对软件系统的正常使用。包括可能造成系统崩溃等灾难性后果的缺陷、数据库错误等重要（Majo

r）产生错误的运行结果，导致系统不稳定，对系统功能和性能产生重要影响。例如，系统操作响应时间不满足要求，某些功能需求未实现、业务流程不正确、系统出现某些意外故障等较小（Minor）缺陷会使用户使用软件不方便或遇到麻烦，但不影响用户的正常使用，也不影响系统的稳定性。主

要指用户界面方面的一些问题，例如提示信息不准确、错别字、界面不一致等第7页/共109页（4）缺陷优先级(Priority)：缺陷的优先级是从开发人员和测试人员的角度出发，以合理安排工作时间和提高工作效率为目标进行设

置的；表6-3软件缺陷的优先级缺陷优先级描述立即解决（ResolveImmediately）缺陷的存在导致系统几乎无法运行和使用，或者是造成测试无法继续进行，例如无法通过冒烟测试，必须立即予以修复高优先级（HighPriority）缺陷严重，影响测试的正常进行

，需要优先在规定的时间内（如24小时内）完成修改正常排队（NormalQueue）缺陷需要修复，但可以正常排队等待修复低优先级（NotUrgent）缺陷可以在开发人员有时间的时候进行修复，如果开发和测试时间紧迫，可以在下一软件版本中进行

修正第8页/共109页（5）缺陷出现的可能性（Possibility）：缺陷出现的可能性是指某一缺陷发生的频率；表6-4软件缺陷出现的可能性（缺陷频率）缺陷出现的可能性描述总是（Always）软件缺陷的出现频率是100%，每次测试时都会重现通常（Often）测试用例执行时通常会产生，出现频率大概

是80%~90%有时（Occasionally）测试时有时会产生这一软件缺陷，缺陷的出现概率是30%~50%很少（Rarely）测试时很少产生这一软件缺陷，缺陷的出现概率是1%~5%第9页/共109页（6）缺陷状态（Status）：缺陷状态用于描述跟踪和修复缺陷的进展情况，也反映了

缺陷在其生命周期中的不同变化。表6-5软件缺陷的状态缺陷状态描述提交（Submitted）已提交入库的缺陷激活或打开（ActiveorOpen）缺陷提交得到确认但还未解决，缺陷等待处理拒绝（Rejected）开发人员认为不是缺陷或重复提交的缺陷，不需要修复已修正或修复（Fixedo

rResolved）缺陷已经被开发人员修复，但是还没有经过测试人员的验证验证（Verify）缺陷验证通过关闭或非激活（ClosedorInactive）测试人员验证后认为缺陷已经成功修复第10页/共109页缺陷状态描述重新打开（

Reopen）测试人员验证后认为缺陷仍然存在，等待开发人员进一步修复推迟（Deferred）缺陷推迟到下一个软件版本中修复保留（Onhold）由于技术原因或第三方软件的缺陷，开发人员暂时无法修复不能重现（Canno

tduplicate）开发人员无法重现缺陷，需要测试人员补充说明重现步骤附表：第11页/共109页（7）缺陷起源（Origin）缺陷起源是指测试时第一次发现缺陷的阶段，例如以下一些典型阶段：需求、总体设计、详细设计、编码、单元测试

、集成测试、系统测试、验收测试、产品试运行、产品发布后用户使用阶段。发现缺陷的阶段越早，越有利于降低改正缺陷的费用。第12页/共109页（8）缺陷来源（Source）缺陷来源是指软件缺陷发生的地方。在软件生命周期某一阶段发现的缺陷可能来源于前期阶段出现的错误。需求分析56%其它10

%编码7%设计27%图6-1软件缺陷产生的阶段第13页/共109页（9）缺陷根源（RootCause）缺陷根源是指造成软件缺陷的根本因素，主要是开发过程、工具、方法等软件工程技术与管理因素以及测试策略等因素，通过缺陷根源分析可以改进软件过程管理水平。

第14页/共109页6.2软件缺陷报告6.2.1缺陷报告中的信息在实际工作中，经常会出现由于软件缺陷描述不清而无法重现缺陷、无法合理安排修复工作、后期无法对缺陷进行统计分析等情况。第15页/共109页一份完整的缺陷报告包括以下一些信息：（1）缺陷跟踪

信息；缺陷ID：唯一标识一个软件缺陷，便于跟踪与查询；标题：缺陷的概括性文字描述；所属项目：缺陷属于哪个软件项目；版本跟踪：缺陷属于软件项目的哪一个版本，是新缺陷还是回归缺陷；所属模块：缺陷位于哪个功能模块。第16页/共109页（2）缺陷详细信息测试步骤

期望结果实际结果测试环境第17页/共109页（3）缺陷附件信息；（4）缺陷属性信息类型：功能、用户界面、性能、文档等类型；严重程度：可以分为致命、严重、重要和较小；优先级：可以分为立即解决、高优先级、正常排队和低优先级；出

现频率：按统计结果标明缺陷发生的可能性1%~100%；缺陷起源、来源和根源信息。第18页/共109页（5）缺陷处理信息提交人员提交时间分配的修复人员修复期限修复时间缺陷验证人员验证意见验证时间第19页/共10

9页6.2.2缺陷报告模板一份软件缺陷报告可以包含非常丰富的缺陷描述信息。在实际工作中，一般根据软件项目特点对上述缺陷描述信息进行裁剪，制定合适的缺陷报告模板。第20页/共109页填写模板信息时，需要遵守以下“5C”原则：Correct：对每个组成部分的描述准确不会引起误解。Clear

：对每个组成部分的描述清晰，易于理解。Concise：描述信息只包含必不可少的内容。Complete：包含重现缺陷的完整步骤和其它辅助信息。Consistent：按照一致的格式书写全部缺陷报告。第21页/共109页下表是一个较为通用的软件

缺陷报告模板，可以在实际工作中修改为更为适合特定工作要求的模板。表6-6软件缺陷报告模板缺陷记录缺陷ID标题（概述）软件名称模块名版本号严重程度优先级状态缺陷类型发现阶段缺陷来源缺陷频率可能性说明测试人员分配修复人员日期第22页/共109页附表：缺陷

记录测试环境测试输入预期结果异常结果缺陷重现步骤附件缺陷处理信息缺陷验证信息修复人验证人修复时间验证时间备注验证结论第23页/共109页6.2.3缺陷报告的注意事项测试人员在编写缺陷报告之前，首先需要

清楚缺陷报告的主要读者以及他们最希望从缺陷报告中获得哪些信息。因此，测试人员在编写缺陷报告时需要注意以下一些事项：（1）保证能够重现缺陷；第24页/共109页因此，测试人员在编写缺陷报告时需要注意以下一些事项：（1）保证能够重

现缺陷：如果测试人员发现不能保证重现一个缺陷，那么就需要给开发人员提供尽可能多的有效信息。如果无法重现或者没有验证是否可以重现时，一定要在缺陷报告中进行说明；第25页/共109页（2）一个报告只针对一个缺陷：虽然有时多个缺陷的起因是一样的，但

是在真正修复缺陷之前并不能保证知道导致某个缺陷的原因。因此即使单独报告缺陷显得有些繁琐，但也比延误或遗漏缺陷要好。第26页/共109页（3）描述准确、清晰：缺陷标题必须简短，而且要求描述和传达出准确的信息；（4）重视附

件信息附件信息应当是缺陷重现步骤的补充信息，是对测试步骤的进一步描述；第27页/共109页（5）使用中性语言：使用中性语言是指客观地描述缺陷问题。用带有感情色彩的语句报告缺陷除了造成研发团队的沟通障碍和协作困难外，对修改缺陷没有任何好处。第28页/共10

9页6.2.4分离和再现软件缺陷为了保证再现软件缺陷，除了需要按照已经介绍过的描述规则来描述软件缺陷之外，还要遵循软件缺陷分离和再现的方法。分离和再现软件缺陷是充分体现测试人员测试才能的地方，需要在测试工作

中不断总结经验，才能准确地找出缩小问题范围的具体步骤和方法。第29页/共109页下面列举一些常用的分离和再现软件缺陷的方法和技巧：（1）确保所有的步骤都被记录；（2）注意特定时间和运行条件因素；（3）注意边界条

件、内存容量和数据溢出问题；（4）注意事件发生次序导致的软件缺陷；（5）考虑软件与其计算环境的相互作用；（6）不能忽视硬件。第30页/共109页6.3软件缺陷的生命周期与处理流程软件缺陷的生命周期是指一个软件缺陷从发现到最终被确认修复的完整过程。在这一过程中

，软件缺陷会经历不同的状态。一个典型的软件缺陷生命周期经历了如下状态改变:第31页/共109页提交→打开：测试人员提交发现的软件缺陷，开发人员确认后准备修复。打开→修复：开发人员修复缺陷后通知测试人员进行修复结果验证。第32页/共

109页验证→重新打开：测试人员执行回归测试，验证测试结果后认为缺陷没有完全被修复，再次打开缺陷等待开发人员重新进一步修复。验证→关闭：测试人员执行回归测试，确认缺陷已经得到修复，然后将缺陷状态设为最后的关闭状态第33页/

共109页为了合理安排缺陷修复工作，避免遗漏任何一个缺陷，需要规划软件缺陷的处理流程，一般根据实际情况进行灵活设置。上述典型软件缺陷生命周期的处理流程如图6-2所示。提交缺陷报告分配缺陷修复任务处理缺陷报告关闭缺陷报告验证修复结果通过未通过图6-2缺陷典型处理流

程第34页/共109页实际工作中，缺陷处理流程不可能像典型处理流程这样简单，会面临各种特殊的情况，造成软件缺陷的生命周期更为复杂。需要考虑如下一些实际情况:开发人员认为测试人员提交的软件缺陷不是真正的缺陷或者是微不足

道;第35页/共109页缺陷被不同测试人员重复提交;测试人员验证缺陷的修复结果后，认为缺陷仍然存在或者没有达到预期的修复效果，因而重新将缺陷设置为打开状态;缺陷优先级比较低，项目研发周期有限，产品发布在即，缺陷可以推迟到下一版本中进行处理;第36页/共10

9页软件产品即将更新换代，而修复某一缺陷的风险过大，可能会造成更多的问题，经项目管理人员同意后可以不必修复;被推迟修复的软件缺陷被证实很严重，需要立即予以修复，软件缺陷的状态被设置为重新打开。第37页/共109页由上述情况可见，缺陷的处理过程实际上是比较复

杂的，会出现对缺陷修复与否和修复结果是否满足要求的不同意见。因此，需要事先规定好对缺陷状态的设置权限。一旦发现缺陷，就需要明确后期相关人员的工作职责，跟踪软件缺陷的生命周期，直到缺陷最终得到正确处理。第38页/共109页图6-

3软件缺陷处理流程提交和打开缺陷（Open)开始缺陷仲裁分配缺陷决议正常修复(Fixed)验证重新打开(Reopen)设置缺陷为延期状态(Deferred)结束关闭(Closed)无法重现缺陷推迟修复不是

缺陷缺陷重复退回并要求补充信息推迟到下一版本已修复未修复第39页/共109页图6-3是一个考虑上述特殊情况后的缺陷处理流程，可以在实际工作中予以参考。从以上说明可以理解，一个软件缺陷除了常见的提交、打开、修复和关闭状态外，还包括拒绝、验证、审查、推迟、保留、重新打开等附加状态。第40页/共

109页对于缺陷数量只在几十个范围内的小型软件项目，用Excel制作的缺陷报告模板就可以应对。但是对于大型软件项目，要追踪和管理成百上千个状态不断变化的软件缺陷，必须使用合适的缺陷管理工具。第41页/共109页缺陷管理工具属于测试管理类工具，相比其它测试类工具，学

习和使用都较为简单。常用的有QC、禅道、Mantis、JIRA、TestLink、Bugzilla等。使用这些缺陷管理工具的优势体现在以下一些方面:第42页/共109页强大的检索功能和安全的审核机制。由于具有

后台数据库支持，缺陷检索、增加、修改、保存都很方便，并且能够对附件进行有效管理。通过权限设置，将缺陷操作权限与缺陷状态相对应，保证修改、删除等缺陷操作的安全性。第43页/共109页支持项目组成员间的协同工作。通过友好的网络

用户界面以及Email等丰富多样的配置设定，支持项目组各类成员及时了解缺陷状态的变化情况，进而根据对应状态合理地安排自己的工作，提高发现缺陷和改正缺陷的效率。第44页/共109页提高缺陷报告的质量。保

证缺陷报告的完整性和一致性，正确和完整地填写缺陷报告的各项内容，保证不同测试人员提交的测试报告格式统一。第45页/共109页6.4软件测试的评估在软件测试执行过程中，需要阶段性地总结和分析测试结果，确保测试过程的有效性。在软件验收和发布之前，测试管理人员需要对整个测试过程和结果做出系

统性的评价，评估测试的完成度是否达到了测试计划规定的目标、软件的质量是否满足了用户需求和设计要求，最终决定能否将软件交付用户验收或者最终发布。第46页/共109页6.4.1测试评估的目的和方法软件测试的评估主要有以下目的：对测试的进展情况进行量

化分析，确定测试和缺陷修复工作的当前状态、效率和完成度，判断测试工作可以结束的时间;第47页/共109页最后完成测试报告或软件质量分析报告提供量化分析数据，例如给出测试覆盖率和缺陷清除率等。分析软件研

发各阶段的不足之处，找出测试和开发工作中的薄弱环节，为过程监督、质量控制和过程改进提供定量化依据。第48页/共109页从以上内容可以看出，测试评估强调定量化分析，是以定量化的分析结果科学地评价测试工作和软件质量，为软件过程管理提供依据。测试评估主要包括以下两种方法:第49页/共109页覆盖率

评估:评估测试的覆盖率，对测试完成程度进行评测。最常见的覆盖率评估分为需求覆盖率评估和代码覆盖率评估。第50页/共109页质量评估:测试过程中产生的软件缺陷报告提供了最佳的软件质量评估数据，通过缺陷分析可以对软

件的可靠性、稳定性等进行详细分析，对软件的性能进行多方面的评测，获得反映软件质量特征的多种指标数据，在此基础上确定软件质量与需求的相符程度。第51页/共109页6.4.2覆盖率评估覆盖率是一种常见的反映测试充分性和完成度的定量化指标。测试活动已验证过的软件区域越

多，软件质量得到保障的可能性越大，测试工作也越接近完成。因此，通过测试覆盖率可以间接地反映测试工作的质量和当前软件代码的质量。测试覆盖又分为需求覆盖和代码覆盖两个方面。第52页/共109页1、需求覆盖率对需求的全面覆盖是软件测试的基本要求，需求覆盖率是测试到的功能和非功能需求占整

个需求总数的百分比。第53页/共109页由于测试计划和测试用例设计时已经考虑了对需求的覆盖，因此一般可以通过已计划的、已实施的或成功完成的测试用例的执行率来衡量需求覆盖率，有时也可以通过测试需求的覆盖率来衡量。第54页/共109页测试评估中，通常使用以下三种公式来

计算需求的测试覆盖率：计划的测试覆盖率=Tp/Rft（1）已执行的测试覆盖率=Tx/Rft（2）成功执行的测试覆盖率=Ts/Rft（3）第55页/共109页上述三个公式中，Rft是测试需求的总数，Tp是用测试过程或测试用例表示的计划测试需求数，Tx是用测试过程或测试用例表

示的已执行的测试需求数，Ts是用完全成功、没有缺陷或意外结果的测试过程或测试用例表示的已执行测试需求数。通过上述三种需求覆盖率指标可以评估剩余测试的工作量，确定测试工作的完成时间。第56页/共109页2、代码覆盖率代码覆盖率是指所测试的源代码数量占代码

总数的百分比。代码覆盖率反映了测试用例对被测软件代码的覆盖程度，也是衡量测试工作进展情况的重要定量化指标。第57页/共109页很明显，代码覆盖率与单元测试密切相关，是单元测试用例是否充分的重要衡量指标。任何未经测试的

程序代码都可能存在潜在缺陷，因此在实际测试前就应当根据程序规格说明、具体代码、规定的代码覆盖率要求设计出合理数量的测试用例。第58页/共109页与手工分析需求覆盖率不同，一般需要借助相应的工具来统计代码覆盖率。下面列举一些

常用编程语言的代码覆盖率分析工具:C/C++：CUnit、CPPUnit、GoogleGTest、gcc+gcov+lcov等。Java：Clover、EMMA、JaCoCo、Jtest、MavenCobertur

a插件等。JavaScript：JSCoverage。Python：PyUnit+Coverage.py。PHP：PHPUnit+XDebug。Ruby：RCov。第59页/共109页代码覆盖率在实际应用中存在着一些误区，主要反映在以下两个方面：（1）片面追求高代码覆盖率:对于

代码覆盖率的提升应当基于风险分析的方法，应当首先保证对关键模块代码的测试覆盖，并确保彻底修复了所发现的软件缺陷。只有通过风险分析，才能确定每一次提升代码覆盖率的实际价值；第60页/共109页（2）认为100%的代码覆盖率就能够保证软件质量：实际上，即使测试了所有的软件代码，仍然不能

保证软件完全满足了用户需求和软件设计要求，也不能代表测试覆盖率很高。第61页/共109页实际上，即使测试了所有的软件代码，仍然不能保证软件完全满足了用户需求和软件设计要求，也不能代表测试覆盖率很高。综合以上说明，可以进一步理解代码覆盖率的实际意义：第62页/共1

09页量测试工作的完成度，为确定何时可以结束测试提供依据。确定没有被测试覆盖到的代码，从而检验前期测试设计是否充分，是否存在测试盲点。第63页/共109页检测出程序中的错误和无用代码，促使程序设计和开发人员理清代码逻辑关系，提升代码质量。作为检验软件

质量的辅助指标。代码覆盖率高并不能说明软件质量高，但是代码覆盖率低，软件质量也不可能得到有效保障。第64页/共109页6.4.3质量评估件缺陷反映了软件与需求的偏差，因此测试工作中一般通过分析软件缺陷来评估软件的质量。缺陷分析是软件质量评

估的一种重要手段，缺陷分析指标可以看做是度量软件质量的重要指标。第65页/共109页软件缺陷分析和评估有很多种方法，从简单的缺陷数量统计到复杂的基于数学模型的分析。常用的缺陷分析方法主要包括缺陷趋势分析、缺陷分布分析、缺陷注入-发现矩阵分析，下面分别对上述3

种方法进行详细介绍:第66页/共109页1、缺陷趋势分析缺陷趋势分析是根据缺陷数量随时间变化的情况，分析和监控开发与测试的进展状况与质量，预测未来软件研发工作情况。第67页/共109页（1）缺陷发现率与测试里程碑；单位时

间内发现的缺陷数量称为缺陷发现率，图6-4反映了一般情况下缺陷发现率与测试成本之间的关系。测试成本新发现的缺陷软件发布日期测试时间图6-4缺陷发现率与测试成本第68页/共109页实际工作中，缺陷发现率的变化情况

并不会像图6-4中的那样理想，不同测试阶段的缺陷发现能力不同，程序开发和缺陷修复的效率变化情况也会对缺陷发现率产生直接影响。重要的是通过缺陷趋势分析及时掌握软件的当前状态，合理制定测试下一阶段的计划。第69页/共109页图6-5是微软基于缺陷趋势图的

里程碑定义，从缺陷趋势图可以找出“Bug收敛点”，第一次出现新增缺陷数量为零的时间点被定义为“零Bug反弹点”。第70页/共109页（2）缺陷趋势与缺陷处理质量缺陷趋势分析还可以延伸到对测试质量和缺陷修复质量的分析。通过分析和对比新增缺陷、已修复缺陷和已关闭缺陷的变化趋势，可以了解

测试的效率和开发人员修复缺陷的效率，找出测试延期的原因，发现测试瓶颈第71页/共109页为了获得稳定、规律性的趋势曲线，一般采用缺陷累积数量进行缺陷处理质量分析，图6-6是一个新增、已修复和已关闭缺陷的趋势变化对比图，趋势

曲线斜率的大小反映了缺陷的处理效率。第72页/共109页为了获得稳定、规律性的趋势曲线，一般采用缺陷累积数量进行缺陷处理质量分析，图6-6是一个新增、已修复和已关闭缺陷的趋势变化对比图，趋势曲线斜率的大小反映了缺陷的处理效率。第73页/共109页实际测试工作中，通过绘

制、分析和对比上述趋势曲线，可以获得以下一些非常有价值的有关开发和测试质量的信息:缺陷越早被发现，对软件质量的影响越小，修复的成本也越低;第74页/共109页缺陷打开与关闭的时间差决定了软件项目的进度，这一时间差当然越小越好;如果新增缺陷曲线已趋于平缓，但缺陷修复和关闭曲线一直在新增曲

线下面，说明缺陷处理效率过低，缺陷处理瓶颈在开发人员那边。;第75页/共109页当新开始一个测试阶段时，如果发现新增缺陷曲线出现一个突起，说明有较多的缺陷在之前的测试阶段未被发现，遗留到了本阶段，或

者说明之前的缺陷修复引入了新的缺陷，需要尽快处理上述缺陷，稳定软件质量。第76页/共109页实际趋势曲线不可能都是平滑的，当发现任何与理想曲线存在显著差异的地方，都意味着测试与开发工作出现了某种问题，例如测试策略错

误或者是人力资源不足等，需要尽快分析问题产生的原因。同时，分析结果为今后工作中进行质量改进提供了非常有价值的经验数据。第77页/共109页2、缺陷分布分析缺陷分布分析是将缺陷数量作为一个或多个缺陷属性的函数来显

示，分析不同类型的缺陷对软件质量的影响情况，寻找测试工作的薄弱环节。第78页/共109页对缺陷进行分类统计分析，常用的缺陷属性有以下4种：状态：新提交的、打开的、已修复的、已关闭的当前缺陷状态。优先级：反映了修

复缺陷的优先顺序。严重性：表示缺陷对软件产品和用户使用影响的恶劣程度。来源：导致缺陷的原因及其来源位置。第79页/共109页最为简单的缺陷分布分析是统计已发现的缺陷在软件主要模块中的分布情况，如图6-7（a）

所示。分析的结果可以直观和清晰地表明哪些模块中的缺陷较多，根据缺陷二八定律需要在后续工作中重点测试这些模块。缺陷数量模块名称ABCDE(a)模块的缺陷数量缺陷密度模块名称ABCDE(a)模块的缺陷密度图6-7主要功

能模块缺陷分布图第80页/共109页需要注意的是，单纯的缺陷数量并不能决定模块的质量，应当采用缺陷密度来更为准确地评估模块代码的质量，如图6-7（b）所示。缺陷密度是用平均估算法来度量代码的质量，一般通过下面的公式进行计算，代码行通常以千行为

单位。（4）=软件缺陷数量软件缺陷密度代码行或功能点的数量第81页/共109页图6-8是一个缺陷优先级分布图，一般要求立即解决和高优先级的缺陷数量不应过多，否则意味着缺陷会频繁阻塞测试工作的正常进行，严

重影响测试效率。缺陷数量优先级低优先级正常排队高优先级立即解决图6-8软件缺陷优先级分布图第82页/共109页对于缺陷严重性，可以采用加权的方法分析缺陷对软件质量的影响，如表6-7所示。表6-7软件缺陷严重等级权值与缺陷影响

缺陷严重等级权值缺陷数量严重性加权数量致命（Fatal）4N14N1严重（Cirtical）3N23N2重要（Major）2N32N3较小（Minor）1N4N4第83页/共109页进一步，可以给出更为直观的严重性加权后的模块缺陷分布图，如图6-9所示。图6-9严重性加权后的模块缺陷分布图严

重性加权数量模块A模块B模块C模块D较小重要严重致命第84页/共109页更为深入的，可以分析缺陷的来源，也就是统计分析不同类型缺陷的数量，找出造成软件缺陷的最主要原因。这一类型的缺陷分布分析有助于使测试人员将测试注意力集中到那些最容易产生缺陷的软件区域，也能够使开发人员在今后工作中更

有针对性地提高代码质量。第85页/共109页如图6-10所示，缺陷主要来源于需求说明、系统设计和数据库，直观提示这些软件部分需要更为深入和细致的测试。图6-10软件缺陷来源分布图第86页/共109页3、缺陷

注入-发现矩阵分析软件缺陷有“注入阶段”和“发现阶段”两个阶段。注入阶段即缺陷的来源（Source）阶段，是指在软件开发的哪个具体阶段造成了这个软件缺陷；而发现阶段是缺陷的起源（Origin）阶段，是指在开发和测试过程

中第一次发现该缺陷的阶段。第87页/共109页根据缺陷报告中缺陷来源和起源属性，可以构造如表6-8所示的“缺陷注入-发现矩阵”。表中的数字代表了在某一发现阶段所找到并清除的由特定注入阶段造成的软件缺陷数量。表6-8缺陷注入-发现矩阵发现阶段注入阶段需求阶段设计阶段编码与单元测试集成测试系统测试验

收测试产品发布后发现总计本阶段缺陷清除率需求1214452003732%设计―201661214643%编码――10529169816763%注入总计12341254019119250第88页/共109

页（1）软件缺陷清除率通过“缺陷注入-发现矩阵”，可以计算得到以下两种测试评估度量指标。阶段缺陷清除率=（本阶段发现的缺陷数/本阶段注入的缺陷数）*100%（5）阶段缺陷泄漏率=（下游发现的本阶段的缺陷数/本阶段注入的缺陷数）*100%（6）第89页/共109页阶段缺陷清除率反映的是某一软件

研发阶段的缺陷清除能力，是缺陷密度度量的扩展，可以评估需求评审、设计评审、代码审查和测试的质量。缺陷发现阶段和注入阶段可以根据软件项目特点进行划分，根本目的是评估出软件开发各个环节的质量，找出薄弱环节，从而有针对

性地进行过程改进。第90页/共109页设F为描述软件规模的功能点数，D1为软件开发过程中所发现的所有缺陷数，D2为软件发布以后发现的缺陷数，D=D1+D2为发现的缺陷总数。可以通过以下几种度量方式来评估软件的

质量：软件质量（每个功能点的缺陷数）=D2/F（7）软件缺陷注入率=D/F*100%（8）整体软件缺陷清除率=D1/D*100%（9）第91页/共109页例如，某个软件有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%。第92页/共109页（2）缺陷潜伏期一个软件缺陷被发现的时间越晚，其带来的损害性就越大，修复的成本也会越高。缺陷潜伏期是一种特殊类型的缺陷分布度量，也称为阶段潜伏期，第93页/共109页为了体现缺陷潜伏期的

长短和缺陷的损害程度，首先需要给“缺陷注入-发现矩阵”中的元素赋予合适的权值，如表6-9所示。表6-9缺陷潜伏期的权值发现阶段注入阶段需求阶段设计阶段编码与单元测试集成测试系统测试验收测试产品发布后需求0123456设计―012345

编码――01234第94页/共109页如表6-8所示的“缺陷注入-发现矩阵”已经明确表示了缺陷注入时间、发现时间及其数量，通过加权计算可以得到如表6-10所示的软件缺陷损耗值，矩阵中的元素是经过缺陷潜伏期加权后的已发现缺陷的数量。表6-10软件缺陷的损耗值发现阶段注入阶段需求阶段设计阶段编码与

单元测试集成测试系统测试验收测试产品发布后损耗总计阶段缺陷损耗需求014815800451.22设计―01612385440.96编码――0293227321200.72第95页/共109页表6-10中显示了一种度

量指标“缺陷损耗”。缺陷损耗综合了缺陷潜伏期和缺陷分布因素，用来度量缺陷发现过程的有效性和修复缺陷所耗费的成本，其计算公式如下：（10）=阶段缺陷数量缺陷潜伏期权值缺陷损耗缺陷总量第96页/共109页例如，表6-10中由需求分析缺陷造成的缺陷损耗为45/

37=1.22，45是加权求和后的损耗总计数值，37是表6-8中总共发现的需求分析缺陷数量。这样计算产生的实际上是阶段缺陷损耗，同样的原理可以计算整体软件的缺陷损耗。第97页/共109页缺陷损耗的数值越低，说明缺陷的发现和修复过程越有效。当把发现

和注入阶段相同时的缺陷权值设为0时，理想缺陷损耗的数值是0，也就是把各阶段注入的缺陷全部在该阶段发现并修复了。通过积累和分析项目长期缺陷损耗的历史数值，可以度量测试有效性的改进趋势。第98页/共109页6.

4.4性能评估通过性能测试可以获得与软件性能表现相关的各方面数据，性能评估就是基于这些数据分析、显示和报告软件的性能特征。性能评估通常与性能测试的执行过程结合进行，用于显示性能测试的进度和状态，也可以在性能测试完成后对测试结

果进行统计分析。第99页/共109页主要的性能评估包括以下内容：（1）动态监测：在测试过程中实时获取和显示被测软件的性能表现、状态、用例执行进度等信息；第100页/共109页（2）响应时间或吞吐量：用曲线图等显示响应时间或吞吐量随系统负载变化的情况，评估被测软件对象在不同条件下的性能表现。除了显

示软件的实际性能之外，还可以统计分析数据的平均值和标准差，对性能指标的稳定性作出评估。第101页/共109页（3）百分比报告：百分比报告用于计算和显示各种百分比值；（4）追踪和配置文件报告：通过这些信息可以更为准确地定位

性能瓶颈或性能异常等情况下的缺陷位置，分析和总结缺陷产生的具体原因；第102页/共109页（5）比较报告：是一种最常用的评估软件性能的形式。通过比较不同性能测试的运行结果，评估性能改进措施是否有效以及性能提升的程度，分析不同性能测试结果数据集之间的差异或趋势。第103页/共109页6.5测试总结

报告在完成测试评估的基础上就可以着手编写测试总结报告。测试总结报告是为了总结和评价测试活动的结果，分析和讨论软件的风险和质量状态，发现测试工作仍然存在的不足之处，对测试计划的完成情况进行最终说明。第104页/共

109页在IEEE标准829-2008和国家标准GB/T9386-2008中都给出了测试总结报告的编写标准，两者实质要求类似，都要求给出实际测试与测试计划的差异、综合评估、测试结果汇总、测试项总体评价、结论和建议等。第105页/共109页这里以IEEE标准为例进行说明。IEEE标准如表6-11所

示，分为阶段测试报告和主测试报告两种，Level代表了单元、集成、系统和验收测试中的一种。阶段测试报告纲要主测试报告纲要LevelTestReportOutline1.Introduction1.1.Documentidentifier1.2.Scope1.3.Reference

s2.Details2.1.Overviewoftestresults2.2.Detailedtestresults2.3.Rationalefordecisions2.4.Conclusionsandreco

mmendations3.General3.1.Glossary3.2.DocumentchangeproceduresandhistoryMasterTestReportOutline1.Introduction1.1

.Documentidentifier1.2.Scope1.3.References2.DetailsoftheMasterTestReport2.1.Overviewofallaggregatetestresults2.2.Rationalefordeci

sions2.3.Conclusionsandrecommendations3.General3.1.Glossary3.2.Documentchangeproceduresandhistory表6-11IEEE829-2008测试报告纲要第106页/共109页两类报告在介绍（Introdu

ction）和常规（General）部分都包含如下信息。文档标识符（Documentidentifier）；范围（Scope）；引用文件（References）；词汇表（Glossary）；文档变更过程和历史记录（Documentchangeproceduresandhist

ory）。第107页/共109页阶段测试报告细节内容（Details）如下：（1）测试结果综述（Overviewoftestresults）（2）测试结果详细说明（Detailedtestresults）（3）决策理由（Rationalefordecisions）（4）结论与建议

（Conclusionsandrecommendations）第108页/共109页主测试报告细节内容（DetailsofMTR）如下：（1）测试总体结果综述；测试活动总结；测试任务结果总结；缺陷及其处理情况总结；评估软件质量；总结已完成的所有测试评估度量指标；第109

页/共109页（2）决策理由：给出软件测试通过、失败或有条件通过（Conditional-Pass）的结论及其原因；（3）结论与建议：对软件产品进行全面评估，可以包括对失败风险的估计。