测试的主要评测方法

简介

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

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

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

覆盖评测

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

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

如果需求已经完全分类，则基于需求的覆盖策略可能足以生成测试完全程度的可计量评测。例如，如果已经确定了所有性能测试需求，则可以引用测试结果来得到评测，如已经核实了 75% 的性能测试需求。

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

两种评测都可以手工得到（公式如下所示）或通过测试自动化工具计算得到。

基于需求的测试覆盖

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

• 测试覆盖通过以下公式计算：

测试覆盖 = T^(p,i,x,s) / RfT

其中：
T 是用测试过程或测试用例表示的测试 (Test) 数（已计划的、已实施的或成功的）。

RfT 是测试需求 (Requirement for Test) 的总数。

• 在制定测试计划活动中，将计算测试覆盖以决定已计划的测试覆盖，其计算方法如下：

测试覆盖（已计划的） = T^p / RfT

其中：
T^p 是用测试过程或测试用例表示的已计划测试 (Test) 数。

RfT 是测试需求 (Requirement for Test) 的总数。

• 在实施测试活动中，由于测试过程正在实施中（按照测试脚本），在计算测试覆盖时使用以下公式：

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

其中：
T^x 是用测试过程或测试用例表示的已执行的测试 (Test) 数。

RfT 是测试需求 (Requirement for Test) 的总数。

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

  这些覆盖评测通过以下公式计算：

  测试覆盖（已执行的） = T^x / RfT

  其中：
  T^x 是用测试过程或测试用例表示的已执行的测试 (Test) 数。

  RfT 是测试需求 (Requirement for Test) 的总数。

成功的测试覆盖（已执行的） = T^s / RfT

其中：
T^s 是用完全成功、没有缺陷的测试过程或测试用例表示的已执行测试 (Test) 数。

RfT 是测试需求 (Requirement for Test) 的总数。

如将以上比率转换为百分数，则以下基于需求的测试覆盖的陈述成立：

x% 的测试用例（上述公式中的 T^(p,i,x,s)）已经覆盖，成功率为 y%

这一关于测试覆盖的陈述是有意义的，可以将其与已定义的成功标准进行对比。如果不符合该标准，则此陈述将成为预测剩余测试工作量的基础。

基于代码的测试覆盖

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

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

测试覆盖 = I^e / TIic

其中：
I^e 是用代码语句、代码分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数。

TIic (Total number of Items in the code) 是代码中的项目总数。

如将该比率转换为百分数，则以下基于代码的测试覆盖的陈述成立：

x% 的测试用例（上述公式中的 I）已经覆盖，成功率为 y%

这一关于测试覆盖的陈述是有意义的，可以将其与已定义的成功标准进行对比。如果不符合该标准，则此陈述将成为预测剩余测试工作量的基础。

质量评测

测试覆盖的评估提供对测试完全程度的评测，在测试过程中已发现缺陷的评估提供了最佳的软件质量指标。因为质量是软件与需求相符程度的指标，所以在这种环境中，缺陷被标识为一种更改请求，该更改请求中的测试对象与需求不符。

缺陷评估可能建立在各种方法上，这些方法种类繁多，从简单的缺陷计数到严格的统计建模不一而足。

严格的评估假定测试过程中缺陷达到的比率或发现的比率。常用模型假定该比率符合泊松分布。则有关缺陷率的实际数据可以适用于这一模型。生成的评估将评估当前软件的可靠性，并且预测继续测试并排除缺陷时可靠性如何增长。该评估被描述为软件可靠性增长建模，这是一个活跃的研究领域。由于该类型的评估缺乏工具支持，所以应该慎重平衡成本与其增加价值。

缺陷分析就是分析缺陷在与缺陷关联关系的一个或多个参数值上的分布。缺陷分析提供了一个软件可靠性指标。

对于缺陷分析，常用的主要缺陷参数有四个：

• 状态：缺陷的当前状态（打开的、正在修复或关闭的等）。
• 优先级：必须处理和解决缺陷的相对重要性。
• 严重性：缺陷的相关影响。对最终用户、组织或第三方的影响等等。
• 起源：导致缺陷的起源故障及其位置，或排除该缺陷需要修复的构件。

可以将缺陷计数作为时间的函数来报告，即创建缺陷趋势图或报告；也可以将缺陷计数作为一个或多个缺陷参数的函数来报告，如作为缺陷密度报告中采用的严重性或状态参数的函数。这些分析类型分别为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据。

例如，预期缺陷发现率将随着测试进度和修复进度而最终减少。可以设定一个阈值，在缺陷发现率低于该阈值时才能部署软件。也可根据执行模型中的起源报告缺陷计数，以允许检测“较差的模块”、“热点”或需要再三修复的软件部分，从而指示一些更基本的设计缺陷。

这种分析中包含的缺陷必须是已确认的缺陷。不是所有已报告的缺陷都报告实际的缺陷，这是因为某些缺陷可能是扩展请求，超出了项目的规模，或描述的是已报告的缺陷。然而，需要查看并分析一下，为什么许多报告的缺陷不是重复的缺陷就是未经确认的缺陷，这样做是有价值的。

缺陷报告

Rational Unified Process 以三类形式的报告提供缺陷评估：

• 缺陷分布（密度）报告允许将缺陷计数作为一个或多个缺陷参数的函数来显示。
• 缺陷龄期报告是一种特殊类型的缺陷分布报告。 缺陷龄期报告显示缺陷处于特定状态下的时间长短，如“提出的”。在龄期类别中，缺陷还可以按其他属性分类，如“拥有者”。
• 缺陷趋势报告按状态（新的、已打开的或关闭的）将缺陷计数作为时间的函数显示。趋势报告可以是累计的，也可以是非累计的。
• 测试结果和进度报告显示对测试的应用程序进行若干次迭代和测试生命周期后的测试过程执行结果。

许多此类报告对于评估软件质量具有很高的价值。一般测试标准中包括有关特定类别（如严重性级别）中打开的缺陷数的陈述。通过缺陷分布评估可以轻松地核对该标准。对测试需求进行过滤或分类，该评估可以侧重于不同的需求集。

要有效生成此类报告，一般需要工具支持。

缺陷密度报告

缺陷状态与优先级

应该给定所有缺陷的优先级，通常可行的做法是设定四种优先级中的一种：

1. 立即解决
2. 高优先级
3. 正常排队
4. 低优先级

一个成功测试的标准可以表示为缺陷在上述优先级上所应体现的分布方式。例如，对于一个成功的测试标准来说，可能不存在优先级为 1 的打开的缺陷，而且优先级为 2 的打开的缺陷要少于 5 个。例如下面的缺陷分布图：

image.png

很明显该图显示的情况没有达到标准。请注意，该图需要通过过滤器才能只显示需要的打开的缺陷。

缺陷状态与严重性

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

缺陷状态与在实施模型中的位置

缺陷起源报告显示缺陷在实施模型元素上的分布情况。

缺陷龄期报告

缺陷龄期分析提供了有关测试有效性和缺陷排除活动的良好反馈。例如，如果大部分龄期较长的、未解决的缺陷处于有待确认的状态，则可能表明没有充足的资源应用于再次测试工作。

缺陷趋势报告

趋势报告确定缺陷率并提供了一个出色的测试状态视图。在测试生命周期中，缺陷趋势遵循着一种比较好预测的模式。在生命周期的初期，缺陷率增长很快。在达到顶峰后，就随时间以较慢的速率下降。

image.png

要发现问题，可以根据这一趋势复审项目时间表。例如，在四个星期的生命周期中，如果缺陷率在第三个星期中仍然增长，则项目很明显没有按时间表进行。

这一简单的趋势分析假定：缺陷是立即关闭的，且在随后的工作版本中对修复进行测试，这样关闭缺陷的速率应该遵循与打开缺陷的速率相同的增减趋势。如果情况并非如此，则表明缺陷解决流程发生了问题；缺陷修复所需的资源或再次测试和确认修复所需的资源可能不足。

image.png

该报告反映的趋势显示，在项目开始时，发现和打开新缺陷的速率很快，但随着时间推移，该速率不断降低。打开的缺陷的趋势与新缺陷的趋势相似，但稍微滞后一些。关闭的缺陷的趋势随着打开的缺陷的修复和核实而不断增长。这些趋势描述的是成功的工作。

如果您的趋势与这些趋势差别显著，则表明存在问题，并可以确定可能需要附加资源以应用于开发或测试特定区域的时间。

当与测试覆盖评测结合起来时，缺陷分析可提供出色的评估，测试完成的标准也可以建立在此评估基础上。

性能评测

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

主要的性能评测包括：

• 动态监测 - 在测试执行过程中，实时获取并显示正在执行的各测试脚本的状态。
• 响应时间/吞吐量 - 测试对象针对特定主角和/或用例的响应时间或吞吐量的评测。
• 百分位报告 - 数据已收集值的百分位评测/计算。
• 比较报告 - 代表不同测试执行情况的两个（或多个）数据集之间的差异或趋势。
• 追踪报告 -主角（测试脚本）和测试对象之间的消息/会话详细信息。

动态监测

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

image.png

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

响应时间/吞吐量报告

正如其名称的含义一样，响应时间/吞吐量报告评测并计算与时间和/或吞吐量（处理的事务数）相关的性能行为。这些报告通常用曲线图显示，响应时间（或事务数）在“y”轴上，而事件数在“x”轴上。

image.png

除了显示实际的性能行为外，它在计算并显示统计信息方面也很实用，如显示数据值的平均偏差和标准偏差。

百分位报告

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

image.png

比较报告

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

追踪和配置文件报告

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

本文转自网络