1、第十章第十章 评估测试评估测试主题主题n 什么是评估测试n 评估测试的方法概述评估测试概述评估测试n 评估测试（Assessment testing）：是指对测试过程中的各种测试现象和结果进行记录、分析和评价的活动。n 评估测试的目的：u量化测试过程，判断测试进行的状态，决定什么时候测试可以告一个段落。u为最后的测试或质量分析报告生成所需的数据，如缺陷清除率、测试覆盖等。评估测试的方法评估测试的方法n 测试覆盖评估n 软件质量评估n 软件产品性能评估n 缺陷评估测试覆盖评估测试覆盖评估n 测试覆盖评估：是对测试完全程度的评估，它建立在测试覆盖基础上，测试覆盖是由测试需求和测试用例的覆盖或已执行
2、代码的覆盖表示的。u基于需求的测试覆盖。u基于代码的测试覆盖。基于需求的测试覆盖基于需求的测试覆盖n 基于需求的测试覆盖公式：测试覆盖率=T(p,i,s)/RfT%其中：T是用测试过程或测试用例表示的测试(Test)数（已计划的、已实施的或成功的）。RfT是测试需求(Requirement for Test)的总数。n 已计划的测试覆盖公式：计划的测试覆盖率=Tp/RfT%其中：Tp是用测试过程或测试用例表示的计划测试需求数。RfT是测试需求的总数。基于需求的测试覆盖基于需求的测试覆盖n 已实施的测试覆盖公式：测试覆盖率=T(p,i,s)/RfT%其中：Ti是用测试过程或测试用例表示的已执行的
3、测试需求数。RfT是测试需求的总数。n 已执行的成功测试覆盖公式：成功的测试覆盖率=Ts/RfT%其中：Ts是用完全成功、没有缺陷的测试过程或测试用例表示的已执行测试需求数。RfT是测试需求的总数。基于需求的测试覆盖基于需求的测试覆盖n 案例：综上所述，本劳模模范综合信息管理系统基于需求的测试覆盖需求基于代码的测试覆盖基于代码的测试覆盖n 基于代码的测试覆盖率公式：基于代码的测试覆盖率=Ie/TIic%其中：Ie是用代码语句、代码分支、代码路径、数据状态判定点或数据元素名表示的已执行代码数。TIic(Total number of Items in the code)是代码中的项目总数。评估软
4、件质量评估软件质量n 质量是对测试对象（系统或测试的应用程序）的可靠性、稳定性以及性能的评测。n 软件测试质量评估目的：u确定产品是否通过验收。u确定何时发布产品；u与其他类似产品相比较，对产品进行选择；u在使用该产品时评估其正面及负面的影响；u确定何时优化或替换该产品。软件质量评估软件质量评估n 软件测试质量评估的内容主要有：外部和内部质量功能性可靠性易用性效率维护性可移植性适合性准确性互操作性保密安全性功能性的依从性成熟性容错性易恢复性可靠性的依从性易理解性易学性易操作性吸引性易用性的依从性时间特性资源利用性效率依从性易分析性易改变性稳定性易测试性维护性的依从性适应性易安装性共存性易替换性
5、可移植性的依从性软件产品性能评估软件产品性能评估n 主要的性能评测包括以下几点：u动态监测：在测试执行过程中，实时获取并显示正在监测指标的状态数据，通常以柱状图或曲线图的形式提供实时显示，从而监测或评估性能测试执行情况。u响应时间/吞吐量：测试对象针对特定主角和/或用例的响应时间或吞吐量的评测。u百分比报告：数据已收集值的百分位评测/计算。u比较报告：代表不同测试执行情况的两个（或多个）数据集之间的差异或趋势。u追踪和配置文件报告：测试用例和测试对象之间的消息和会话详细信息。缺陷评估缺陷评估n 缺陷评估是对测试过程中缺陷达到的比率或发现的比率，提供一个软件可靠性指标。对于缺陷分析，常用的主要缺
6、陷参数有四个：u状态：缺陷的当前状态；u优先级：必须处理和解决缺陷的相对重要性；u严重性：最终用户、组织或第三方的影响等；u起源：导致缺陷的起源故障及其位置，或排除该缺陷需要修复的构件。缺陷评估缺陷评估n 软件测试的缺陷评估可依据以下4类形式的度量提供缺陷评测：u缺陷数量；u缺陷消除率（DRE）；u缺陷潜伏期；u缺陷密度。缺陷度量缺陷度量-缺陷数量缺陷数量n 用缺陷数量作为测试有效性度量的两个问题u 所有的Bug并不都是均等的。有必要对bug进行“加权”或采用影响等级分类。u 最初存在的数量对发现的bug数量有着重要的影响n 采用类似项目的比较来度量发现的缺陷数量时间项目A项目B缺陷度量缺陷度
7、量-缺陷消除率缺陷消除率(DRE)n 在我们可能发现的bug集合中，我们到底发现了多少bug?n 定义：u DRE=u 未发现的Bug数量=客户发现的bug数量测试期间发现的bug数量测试期间发现的Bug数量+未发现的bug数量缺陷度量缺陷度量-缺陷消除率缺陷消除率(DRE)n 使用该度量，必须清楚以下几点u 必须考虑Bug的严重程度和分布状况。u 我们怎么才知道客户到什么时候会发现所有的bug?u 这种度量是“马后炮”性质的度量。对当前项目的测试有效性度量无意义，但有利于组织的测试有效性的长期趋势度量。u 我们什么时候开始计算Bug?u 有些Bug在测试中发现不了！受测试环境的影响，发现不了
8、的bug是否需要考虑度量。缺陷度量缺陷度量-缺陷消除率缺陷消除率(DRE)提出需求设计代码/单元测试集成测试系统测试验收测试产品200造成的Bug数量30306012013013011050100发现的bug数量80401002050DRE=(80+40+100+20+50+30)/(80+40+100+20+50+30+30)=91%系统测试的DRE=系统测试发现的bug数量/（系统测试发现的bug数量+验收测试和产品中发现的bug数量）=50/（50+30+30）=45%缺陷度量缺陷度量-产品缺陷产品缺陷n 在产品中或客户发现的缺陷数量。n 测试员没有发现的或者是在发布之前未修复的。缺陷度
9、量缺陷度量-缺陷潜伏缺陷潜伏期期n 我们发现bug的时间越晚，这个bug所带来的损害就越大，修复这个bug所耗费的成本就越多。n 缺陷潜伏期尺度缺陷造成阶段发现阶段需求概要设计详细设计编码单元测试集成测试系统测试验收测试试点产品产品需求0123456789概要设计012345678详细设计01234567编码0123456总计缺陷度量缺陷度量-缺陷损耗缺陷损耗n 损耗是使用阶段潜伏期和缺陷分布来度量缺陷消除活动的有效性的一种度量。n 缺陷损耗的计算损耗=n 损耗的数值越低，说明发现过程越有效。n 作为一个绝对值，损耗几乎没有任何意义；但是，当用损耗来度量测试有效性的长期趋势时，它就会显示出自己
10、的价值。缺陷数量*发现的阶段潜伏期缺陷总量缺陷度量缺陷度量-缺陷密度缺陷密度n 计算u 缺陷密度=n 两个问题u 我们把什么当作缺陷 是否将较小的缺陷和严重缺陷作同等对待，是否加权。我们是否计算单元测试的bug数量？还是只计算以后发现的bug数量？计算在评审/审查期间发现的bug数量？u 度量模块的大小也是一个问题，代码行的数量会因为编程人员的技术水平和所使用的语言的不同而不同。缺陷数量代码行或功能点的数量评估测试完成标准评估测试完成标准n 实行了所有的测试策略并达到完成标准。n 测试结束后，开发组对实现有误的测试需求项的修改达到如下程度：u四、五级错误的修复率达到100%。u二、三级错误的修复率达到80%以上。u一级错误的修复率达到60%以上n 需求说明书、用户手册、操作手册和编码实现一致。评估测试完成标准评估测试完成标准n 案例：评估劳动模范综合信息管理系统，缺陷统计情况如图。本次测试共发现缺陷20个，修复17个，还有3个缺陷未修复。一级缺陷修复率为85%，二级缺陷修复率为80%，三、四五级缺陷修复率均为100%，符合测试通过准则要求。Question?Question?谢谢！
