第一章 测试报告该如何撰写

简介

软件测试项目的最后阶段要依据测试结果对软件质量进行评估，并对整个软件测试过程进行总结。本章的前半部分主要介绍了评估软件质量和编写测试报告的一些常识，后半部分主要介绍项目总结和个人总结如何书写。

15.1  软件质量评估

测试评估是在测试结束后对整个测试过程与产品进行评估的过程，主要包括对于测试工作的总结、缺陷数据的分析及测试过程的评估。通过测试评估确定软件的各项指标是否满足测试标准的规定，检验应用程序是否合格。

测试的主要评测方法包括覆盖和质量。

Ø 测试覆盖是对测试完全程度的评测，它建立在覆盖测试基础上，测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。

Ø 质量是对测试对象的可靠性、稳定性及性能的评测。质量建立在对测试结果的评估和对测试过程中确定的变更请求（缺陷）的分析的基础上。

15.1.1  覆盖评测

覆盖指标回答了“测试的完全程度如何?”这一问题。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简而言之，测试覆盖是就需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度的任意评测，如用例的核实（基于需求的）或所有代码行的执行（基于代码的）。

系统的测试活动建立在至少一个测试覆盖策略基础上。覆盖策略陈述测试的一般目的，指导测试用例的设计。覆盖策略的陈述可以简单到只说明核实所有性能。

如果需求已经完全分类，则基于需求的覆盖策略可能足以生成测试完全程度的可计量评测。

例如，如果已经确定了所有性能测试需求，则可以引用测试结果来得到评测，如已经核实了75%的性能测试需求。

如果应用基于代码的覆盖，则测试策略是根据测试已经执行的源代码的多少来表示的。这种测试覆盖策略类型对于安全至上的系统来说非常重要。

这两种评测结果都可以通过公式手工得到或通过自动化测试工具计算得到。

Ø 基于需求的测试覆盖

基于需求的测试覆盖在测试生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识（如已计划的、已执行的和成功的测试覆盖）。

在执行测试活动中，使用两个测试覆盖评测，一个确定通过执行测试获得的测试覆盖，另一个确定成功的测试覆盖（即执行时未出现失败的测试，如没有出现缺陷或意外结果的测试）。这些覆盖评测通过以下公式计算：

测试覆盖（已执行的）= Tx/RfT

成功的测试覆盖（已执行的）= Ts/RfT

其中Tx是用测试过程或测试用例标识的已执行的测试数。Ts是用完全成功、没有缺陷的测试过程或测试用例表示的已执行的测试数。RfT（Requirement for Test）是测试需求的总数。

Ø 基于代码的测试覆盖

基于代码的测试覆盖过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之前是否已做定义。

基于代码的测试覆盖通过以下公式计算：

测试覆盖= Tc/Tiic

其中Tc是用代码语句、代码分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数。Tiic （Total number of items in the code）是代码中的项目总数。

15.1.2  质量评测 

质量是对测试对象的可靠性、稳定性及性能的评测。

1. 缺陷报告

可以用三类缺陷分析的报告提供缺陷评估。

Ø 缺陷分布（密度）报告允许将缺陷数量作为一个或多个缺陷参数的函数来显示。

Ø 缺陷状态与优先级。缺陷状态与优先级显示每种优先级的缺陷个数，一个成功测试的标准可以表示为缺陷在上述优先级上所应体现的分布方式。例如，对于一个成功的测试标准来说，可能不存在优先级为1的打开的缺陷，而且优先级为2的打开的缺陷要少于5个。例如如图15-1所示的缺陷分布图。

图15-1 缺陷分布图（按优先级）

Ø 缺陷状态与严重性。

（1）缺陷严重性报告显示每种严重性级别的缺陷个数，例如致命错误、未执行主要功能、次要错误等严重性级别。

（2）缺陷龄期报告是一种特殊类型的缺陷分布报告。缺陷龄期报告显示缺陷处于特定状态下的时间长短。缺陷龄期分析提供了有关测试有效性和缺陷排除活动的信息。例如，如果大部分龄期较长的、未解决的缺陷处于有待确认的状态，则可能表明没有充足的资源应用于再次测试工作。如图15-2 己关闭BUG按天龄期。

图15-2 己关闭Bug按天龄期

（3）缺陷趋势报告按状态（新的、已打开的或已修改）将缺陷数量作为时间的函数显示。趋势报告可以是累计的，也可以是非累计的。趋势报告确定缺陷率，在测试生命周期的初期，缺陷率增长很快，在达到顶峰后，就随时间以较慢的速率下降。我们可以根据这一趋势复审项目时间表。例如，在4个星期的生命周期中，如果缺陷率在第3个星期中仍然增长，则项目很明显没有按时间表进行。

如图15-3所示，在做项目时，缺陷趋势是遵循这样的规律：发现缺陷后应该立即打开并修改，在随后的升级版本中进行回归测试，这样关闭缺陷的速率就应该与打开缺陷的速率有相同的增减趋势。如果情况并非如此，则表明缺陷处理流程发生了问题，修复缺陷所需的资源或回归测试和确认修复所需的资源可能不足。

图15-3 缺陷状态分布图

缺陷报告对于评估软件质量具有很高的价值，一般在测试标准中会确定软件具有特定类别的缺陷的数量，我们通过缺陷分布评估可以轻松地核对该标准。注意，要有效生成此类报告，一般需要工具支持。

2. 性能评测

评估测试对象性能行为时，可以使用多种评测，这些评测侧重于获取与行为相关的数据，如响应时间、计时配置文件、执行流、操作可靠性和限制等。这些评测主要在评估测试活动中进行评估，但是也可以在执行测试活动中使用性能评测评估测试进度和状态。

主要的性能评测包括以下几点。

（1）动态监测——在测试执行过程中，实时获取并显示正在执行的各测试脚本的状态。

动态监测通常以柱状图或曲线图的形式提供实时显示/报告。该报告用于在测试执行过程中，通过显示当前的情况、状态及测试脚本正在执行的进度来监测或评估性能测试的执行情况。

例如，在如图15-4所示的柱状图中，有80个测试脚本正在执行相同的用例。图15-4中显示，有14个测试脚本处于空闲状态，12个处于查询状态，34个处于SQL执行状态，4个处于SQL连接状态，16个处于其他状态。随着测试的进行，将看到各状态脚本的数量会发生变化。显示的输出将是正常执行且正在执行中的典型测试执行。但是，如果在测试执行过程中，测试脚本始终保持一种状态或没有显示任何变化，则表明测试执行发生问题或者需要实施或执行其他性能评测。

图15-4 动态监测

（2）响应时间/吞吐量——测试对象针对特定主角和/或用例的响应时间或吞吐量的评测。

响应时间/吞吐量报告评测并计算与时间和/或吞吐量(处理的事务数)相关的性能行为。这些报告通常用曲线图显示，响应时间(或事务数)显示在y轴上，而事件数在x轴上，如图15-5所示。除了显示实际的性能行为外，它在计算并显示统计信息方面也很实用，如显示数据值的平均偏差和标准偏差。

（3）百分位报告——数据已收集值的百分位评测/计算。

百分位报告通过显示已收集数据类型的全体百分位值，提供了另一种性能统计计算方法。

（4）比较报告——代表不同测试执行情况的两个（或多个）数据集之间的差异或趋势。

比较不同性能测试的结果，以评估测试执行过程中所做的变更对性能行为的影响，这种做法是非常必要的。比较报告应该用于显示两个数据集（分别代表不同的测试执行）之间的差异或多个测试执行之间的趋势。

图15-5 响应时间/吞吐量报告

 （5）追踪报告——主角（测试脚本）和测试对象之间的消息/会话详细信息。

当性能行为可以接受时，或性能监测表明存在可能的瓶颈时（如当测试脚本保持给定状态的时间过长），追踪报告可能是最有价值的报告。追踪和配置文件报告显示低级信息。该信息包括主角与测试对象之间的消息、执行流、数据访问，以及函数和系统调用。