执行篇

第23回 严格执行测试

虽然我们都认为，有效的测试计划是指导测试用例设计、测试执行的指导性文件，是成功测试的前提和必要条件，测试用例设计是测试工作的核心，测试用例的成功设计已经完成了一半的测试任务，但是测试的执行是基础，是测试计划和测试用例实现的基础，严格的测试执行使测试工作不会半途而废。而且，测试执行的管理相对复杂些，在整个测试执行阶段中，我们需要面对一系列问题，如：

• 如何确保测试环境满足测试用例所描述的要求？
• 如何保证每个测试人员清楚自己的测试任务和要达到的目标？
• 如何保证每个测试用例得到百分之百的执行？
• 如何保证所报告的软件缺陷正确、描述清楚、没有漏掉信息？
• 如何在验证Bug或新功能与回归测试之间寻找平衡？
• 如何跟踪Bug处理的进度使严重的Bug及时得到解决？

要实现上述目标，得到一个真实、符合要求的执行过程，需要很好地全程跟踪测试过程、过程度量和评审、借助有效的测试管理系统等来实现。主要的方法和措施有：

1. 提高测试人员素质和责任心，树立良好的质量文化意识和专业素质，奖惩分明。
2. 严格审查测试环境，包括硬件型号、网络拓扑结构、网络协议、防火墙或代理服务器的设置、服务器的设置、应用系统的版本，包括被测系统以前发布的各种版本和不定包、以及相关的或依赖性的产品。
3. 将要执行的所有测试用例进行分类，构造成测试套件（Test Suite），然后在此基础上建立要执行的测试任务，这样任务的分解有助于进度和质量的有效控制，减少风险。
4. 所有测试用例、测试套件、测试任务和测试执行结果，都通过测试管理系统进行管理，使之测试执行的操作、过程记录在案，具有良好的可跟踪性、控制性和追溯性，容易控制好测试进度和质量。
5. 对每个阶段的测试结果进行分析，保证阶段性的测试任务得到完整的执行并达到预定的目标。
6. 缺陷的跟踪和管理一般由数据库系统来执行，容易对缺陷进行跟踪、统计分析和趋势预测，并设定一些有效的规则和流程来配合测试执行
   如通过系统自动发出邮件给相应的开发人员和测试人员，使得任何缺陷都不会错过，并能得到及时处理。
7. 良好的沟通，不仅和测试人员保持经常的沟通，还可以和项目组的其他人员（保持有效的沟通，如每周例会，可以及时发现测试中问题或不正常的现象。

第24回 测试进度和成本的控制

项目的进度管理是一门艺术，是一个动态的过程，需要不断调度、协调，保证项目的均衡发展，实现项目整体的动态平衡。项目开始前的计划，对任务的测试需求有一个大体的认识，但深度不够，进度表可能只是一个时间上的框架，其中一定程度上是靠计划制定者的经验来把握的。随着时间的推移、测试的不断深入，对任务会有进一步的认识，对很多问题都不再停留在比较粗的估算上，项目进度表会变得越来越详细、越准确。

项目的进度管理主要通过里程碑、关键路径的控制并借助工具来实现，同时要把握好进度与质量、成本的关系，以及充分了解进度的数量和质量的双重特性。

1．进度的数量和质量的双重特性

任何一项工作，最开始总是很容易看到进度，就比如盖房子，从无到有，变化是很明显的。可是越到后来，它的进度越来越不明显。软件测试也是如此，开始测试之初，Bug比较容易发现，但测试的进展并不是按Bug的数量来计算的，越到后面，Bug越来越难发现。要提高测试进度的质量，将严重的、关键的问题在第一时间发现出来，这样才不至于在最后阶段使得开发人员要对代码做大规模的变动，无法保证测试的时间，从而影响软件的质量。这就是测试项目进度的数量和质量的双重特性，我们在关注进度的同时要把握好这两个特性，在注重进度速度的同时，还要看进度前期的质量。

2．测试进度的管理方法

首先，尽量利用历史数据，从以前完成过的项目来进行类比分析，以确定质量和进度所存在的某种数量关系，来控制进度和管理质量。可以采用对进度管理计划添加质量参数的方法，也就是通过参数调整进度和质量的关系。

其次，可以采用测试项目进度的度量方法：测试进度S曲线法和缺陷跟踪曲线法。在进度压力之下，被压缩的时间通常是测试时间，这导致实际的进度随着时间的推移，与最初制定的计划相差越来越远。而如果有了正式的度量方法，这种情况就很难出现，因为在其出现之前就有可能采取了行动。

第25回 准确报告软件缺陷

软件缺陷的描述是是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发小组交流的最初且最好的机会。一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。否则，它就会使信息含糊不清，可能会误导开发人员。准确报告软件缺陷是非常重要的，因为：

• 清晰准确的软件缺陷描述可以减少软件缺陷从开发人员返回的数量
• 提高软件缺陷修复的速度，使每一个小组能够有效的工作
• 提高测试人员的信任度，可以得到开发人员对清晰的软件缺陷描述有效的响应
• 加强开发人员，测试人员和管理人员的协同工作，让他们可以更好的工作

在多年实践的基础上，我们积累了较多的软件缺陷的有效描述规则，主要是：

• 单一准确。每个报告只针对一个软件缺陷。在一个报告中报告多个软件缺陷的弊端是常常会导致缺陷部分被注意和修复，不能得到彻底的修正。
• 可以再现。提供缺陷的精确操作步骤，使开发人员容易看懂，可以自己再现这个缺陷，通常情况下，开发人员只有再现了缺陷，才能正确地修复缺陷。
• 完整统一。提供完整、前后统一的软件缺陷的步骤和信息，例如：图片信息，Log文件等。
• 短小简练。通过使用关键词，可以使软件缺陷的标题的描述短小简练，又能准确解释产生缺陷的现象。如“主页的导航栏在低分辨率下显示不整齐”中“主页”、“导航栏”、“分辨率”等是关键词。
• 特定条件。许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件（如特定的操作系统、浏览器或某种设置等），能够提供帮助开发人员找到原因的线索。如“搜索功能在没有找到结果返回时跳转页面不对”。
• 补充完善。从发现bug那一刻起，测试人员的责任就是保证它被正确的报告，并且得到应有的重视，继续监视其修复的全过程。
• 不做评价。在软件缺陷描述不要带有个人观点，对开发人员进行评价。软件缺陷报告是针对产品、针对问题本身，将事实或现象客观地描述出来就可以，不需要任何评价或议论。

软件缺陷属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因。

1. 缺陷标识：是标记某个缺陷的唯一的表示，可以使用数字序号表示。

2. 缺陷类型：是根据缺陷的自然属性划分缺陷种类，如表1所示

表1软件缺陷类型列表

3. 缺陷严重程度：是指因缺陷引起的故障对软件产品的影响程度，所谓“严重性”我指的是在测试条件下，一个错误在系统中的绝对影响。如表2所示

表2软件缺陷严重等级列表

4. 缺陷产生的可能性：指缺陷在产品中发生的可能性，通常可以用频率来表示，如表3所示。

表3 缺陷产生可能性列表

5. 缺陷优先级：指缺陷必须被修复的紧急程度。“优先级”的衡量抓住了在严重性中没有考虑的重要程度因素，如表4所示。

表4 软件缺陷优先级列表

一般来讲，缺陷严重等级和缺陷优先级相关性很强，但是，具有低优先级和高严重性的错误是可能的，反之亦然。例如，产品徽标是重要的，一旦它丢失了，这种缺陷是用户界面的产品缺陷，但是它阻碍产品的形象。那么它是优先级很高的软件缺陷。

6. 缺陷状态：指缺陷通过一个跟踪修复过程的进展情况，也就是在软件生命周期中的状态基本定义，如表5所示。

表5 软件缺陷状态列表

7. 缺陷来源：指缺陷所在的地方，如文档、代码等，如表6所示。

表6 软件缺陷来源列表

8. 缺陷根源：指造成上述错误的根本因素，以寻求软件开发流程的改进、管理水平的提高，如表7所示。

表7 软件缺陷根源列表

第26回 提高测试覆盖度

测试覆盖度评估是衡量阶段性软件测试执行状态的重要手段之一，来确定测试是否达到事先设定的测试任务完成的标准。测试覆盖率则是测试覆盖度评估中一种量化的表示方法，一般通过被测试的软件产品需求、功能点、测试用例数或程序代码行等来进行计算。

软件测试覆盖率常用的计算公式：

1. 功能覆盖率= 至少被执行一次的测试功能点数/ 测试功能点总数 （功能点）
2. 需求覆盖率= 被验证到的需求数量 /总的需求数量 （需求）
3. 覆盖率= 至少被执行一次的测试用例数/ 应执行的测试用例总数 （测试用例）
4. 语句覆盖率= 至少被执行一次的语句数量/ 有效的程序代码行数
5. 判定覆盖率= 判定结果被评价的次数 / 判定结果总数
6. 条件覆盖率= 条件操作数值至少被评价一次的数量 / 条件操作数值的总数
7. 判定条件覆盖率= 条件操作数值或判定结果至少被评价一次的数量/(条件操作数值总数+判定结果总数)
8. 上下文判定覆盖率= 上下文内已执行的判定分支数和/(上下文数*上下文内的判定分支总数)
9. 基于状态的上下文入口覆盖率= 累加每个状态内执行到的方法数/(状态数*类内方法总数)
10. 分支条件组合覆盖率= 被评测到的分支条件组合数/分支条件组合数
11. 路径覆盖率= 至少被执行一次的路径数/程序总路径数

除此之外，覆盖率还包括类覆盖率、函数覆盖率、代码块覆盖率等，如EMMA中

测试评估可以说贯穿整个软件测试过程，可以在测试每个阶段结束前进行，也可以在测试过程中某一个时间进行，目的只有一个，提高测试覆盖度，保证测试的质量。通过不断的测试覆盖度评估或测试覆盖率计算，及时掌握测试的实际状况与测试覆盖度目标的差距，及时采取措施，就可以提高测试的覆盖度。

测试覆盖度的评估依赖于不同的测试阶段或不同的测试方法。如在单元测试中，测试覆盖率是建立在被测试的代码行、程序分支和程序路径等的度量之上，从软件质量保证的要求出发，单元测试的覆盖率要达到80％之上。白盒测试方法主要以程序语句、判定－条件、条件组合和（基本）路径等覆盖率来衡量，和单元测试是吻合的。而在系统功能测试中，则以功能点、测试用例、需求数等覆盖率来衡量。

要获得、提高测试覆盖率，常常需要借助测试工具。下面就以两个测试工具为例。

1. EMMA

EMMA 是一个用于检测和报告 JAVA 代码覆盖率的开源工具，支持许多种级别的覆盖率指标：包，类，方法，语句块（basic block）和行，特别是能测出某一行是否只是被部分覆盖，如条件语句短路的情况。EMMA能生成 text、xml、html 等形式的报告，以满足不同的需求，其 html 报告提供逐层细化查询功能，能够从 package 开始一步步链接到我们所关注的某个方法。EMMA 能和 Makefile 和 Ant 集成，效率很高，便于应用于大型项目。

EMMA 是通过向 .class 文件中插入字节码的方式来跟踪记录被运行代码信息的。EMMA 支持两种模式：On the fly 和 Offline 模式。On the fly 模式往加载的类中加入字节码，相当于用 EMMA 实现的 application class loader 替代原来的 application class loader。On the fly 模式比较方便，缺点也比较明显，如不能为被 boot class loader 加载的类生成覆盖率报告，也不能为像 J2EE 容器那种自己有独特 class loader 的类生成覆盖率报告。这时，必须求助于 Offline 模式，Offline 模式是在类被加载前，加入字节码。EMMA 也支持两种运行方式：Command line 和 Ant。

2. Rational PureCoverage

PureCoverage 是一个面向VC, VB 或者Java 开发的测试覆盖程度检测工具,可以自动检测测试完整性和未被测试的范围，在每一个测试阶段生产详尽的测试覆盖程度报告。PureCoverage 将在一个对话框中列出所有应用程序模块，开发人员只需针对每个应用程序构件，就可以简单地设置基于代码行或函数的代码覆盖级别。不仅可以查看每次程序运行的图形化覆盖数据，还可以直接地、实时地控制覆盖数据的记录。对于最关心或最重要的功能模块，可以详细地收集覆盖数据；而对于不太重要的模块， 只收集较常规的覆盖数据，帮助开发人员进行有效地测试。

系统的测试活动，依据测试目标，建立在至少一个测试覆盖策略基础上，而覆盖策略帮助进行测试覆盖度的有效评估。覆盖策略有

• 基于需求的测试覆盖评估，依赖于对已执行/运行的测试用例的核实和分析，所以基于需求的测试覆盖评测就转化为评估测试用例覆盖率：测试的目标是确保100%的测试用例全部成功地执行。
• 基于代码的测试覆盖评估，是对被测试的程序代码语句、路径或条件的覆盖率分析。如果应用基于代码的覆盖，则测试策略是根据测试已经执行的源代码的多少来表示的。这种测试覆盖策略类型对于安全至上的系统来说非常重要。

如果测试需求已经完全分类，则基于需求的覆盖策略可能足以生成测试完全程度评测的量化指标。例如，如果已经确定了所有性能测试需求，则可以引用测试结果来得到评测，如已经核实了90％的性能测试需求。除此之外，如果测试软件的数量较大，还要考虑数据量。

第27回 测试结果分析和质量报告

如同代码是程序员的成果之一，测试报告和质量报告是测试人员的主要成果之一。对于一个好的测试报告，是建立在正确的、足够的测试结果的基础之上，不仅要提供必要的测试结果的实际数据，同时要对结果进行分析，发现产品中问题的本质，对产品质量进行准确的评估。

1．缺陷分析

对缺陷进行分析，确定测试是否达到结束的标准，也就是判定测试是否已达到用户可接受的状态。在评估缺陷时应遵照缺陷分析策略中制定的分析标准，最常用的缺陷分析方法有：

• 缺陷分布报告，允许将缺陷计数作为一个或多个缺陷参数的函数来显示，生成缺陷数量与缺陷属性的函数，如缺陷在程序模块的横向分布、严重性缺陷在不同的产生原因上的分布等。
• 缺陷趋势报告，按各种状态将缺陷计数作为时间的函数显示，如缺陷数量在整个测试周期的时间分布。趋势报告可以是累计的，也可以是非累计的，可以看出缺陷增长和减少的趋势；
• 缺陷年龄报告，是一种特殊类型的缺陷分布报告，显示缺陷处于活动状态的时间，展示一个缺陷处于某种状态的时间长短，从而了解处理这些缺陷的进度情况。
• 测试结果进度报告，展示测试过程在被测应用的几个版本中的执行结果以及测试周期，显示对应用程序进行若干次迭代和测试生命周期后的测试过程执行结果

同时，也可以在项目结束后进行缺陷分析，以改进开发和测试进程，如：

• 通过缺陷（每日或每周新发现的缺陷）趋势分析来了解测试的效率，也可根据丢失的Bug数目和发现总的Bug数，可以了解测试的质量。可以根据执行的总测试用例数，计算出每发现一个Bug所需要的测试用例数、测试时间等，对不同阶段、不同模块等进行对比分析。
• 通过缺陷数量或在模块的分布情况，可以掌握程序代码的质量，如通过对每千行代码所含的Bug数分析，了解程序代码质量。通过缺陷（每日或每周修正/关闭的缺陷）趋势分析开发团队解决Bug的能力或状态

2．产品总体质量分析

对测试的结果进行整理、归纳和分析，一般借助于Excel文件、数据库和一些直方图、圆饼图、趋势图等来进行分析和表示，主要的方法有对比分析、根本原因（Root Cause）查找、问题分类、趋势（时间序列）分析等。

• 对比分析，软件来执行测试结果与标准输出的对比工作，因为可能有部分的输出内容是不能直接对比的（比如，对运行的日期时间的记录，对运行的路径的记录，以及测试对象的版本数据等），就要用程序进行处理。
• 根本原因（Root Cause）查找，“分析”是找出不吻合的地方并指出错误的可能起因。
• 问题分类，“分类”包括各种统计上的分项，例如，对应的源程序的位置，错误的严重级别（提示、警告、非失效性错误、失效性错误等），新发现的还是已有记录的错误。
• 趋势（时间序列）分析，根据所发现的软件缺陷历史数据进行分析，预测未来情况。
• 其它统计分析，通过对缺陷进行分类，然后利用一些成熟的统计方法对已有数据进行分析，以了解软件开发中主要问题或产生问题的主要原因，从而比较容易提高软件质量。

第28回 测试过程和结果度量

测试阶段的过程度量内容或项目比较多，包括软件测试进度、测试覆盖度、测试缺陷出现/到达曲线、测试缺陷累积曲线、测试效率等。在进行测试过程度量时，要基于软件规模度量（如功能点、对象点等）、复杂性度量、项目度量等方法，从三个不同的测度来完整度量测试的过程状态：

1. 测试广度的测量提供了多少需求(在所有需求的数目中)在某一时刻已经被测试，来度量测试计划的执行、测试进度等状态；
2. 测试深度是对被测试覆盖的独立基本路径占在程序中的基本路径的总数的百分比的测度，基本路径数目的度量可以用McCabe环形计算复杂度方法来计算。
3. 过程中收集的缺陷数度量，发现的、修正的和关闭的缺陷数量在过程中的差异、发展趋势等，为过程质量、开发资源额外投入、软件发布预测提供重要依据。

如前所述，测试过程的度量可以将过程状态度量和过程结果度量结合起来分析，是测试过程度量更有效。

在测试阶段，主要的过程质量度量有：

• 缺陷度量或缺陷分布度量
• 测试用例的深度、质量和有效性
• 测试执行的效率和质量
• 缺陷报告的质量
• 测试覆盖度（测试整体的质量）
• 测试环境的稳定性或有效性

缺陷度量是测试阶段的主要度量内容，包括产品缺陷度量和缺陷过程度量。产品缺陷度量将在下一回做详细介绍，而测试环境的稳定性或有效性度量，就像软件有效性一样，用MTTF来测量。所以下面将简单介绍其他度量内容，如软件缺陷到达模式、PTR出现/积压模型、测试用例的度量、基于需求的测试覆盖评估、基于代码的测试覆盖评估等等。

1. 基于时间的缺陷到达模式

产品的缺陷密度、或者测试阶段的缺陷率是一个概括性指标，缺陷到达模式可以提供更多的过程信息，有时即使得到的整体缺陷率是一样的，但其质量差异可能较大，原因就是缺陷到达的模式不一样。越多的缺陷到达越早，则测试过程质量就越好。无论是从测试进展的观点，还是从用户重新发现(customer rediscoveries)的观点来看，缺陷的过程跟踪是非常重要的，开发周期里大量的严重缺陷将有可能阻止测试的进展，也必然直接影响软件产品的质量和性能。

相对产品发布时间、上一个版本的缺陷水平来说，经常会被项目经理或开发经历问的就是：

• 缺陷何时到达峰值？这个峰值有时多少？
• 在到达峰值后又要化多少时间趋于（降低）到一个低而稳定的水平？
• 低而稳定的水平持续多少时间，当前版本可以发布？

回答这些问题，正是缺陷达到模式要实现的目标。定性的分析比较容易，测试团队越成熟，峰值到达得越早，有时可以在第一周末或第二周就到峰值。这个峰值的数值取决于代码质量、测试用例的设计质量和测试执行的策略、水平等，多数情况下，可以根据基线（或历史数据）推得。从一个峰值达到一个低而稳定的水平，需要长得多的时间，至少是达到峰值所用的时间的4-5倍。这个时间取决于峰值、缺陷移除效率等等。

2. PTR累积模型

测试的目标在于尽早地发现软件缺陷，通过测试用例可以更有效、更快地发现软件中缺陷，而软件缺陷通过PTR（问题跟踪报告，Problem Tracking Report）来描述。因此，PTR的数量一定程度上代表了软件的质量。每个缺陷/PTR都有一个生命周期，从测试人员发现问题并形成报告（称为PTR出现，也称缺陷到达），开发/设计人员要重现、修正这个PTR/缺陷，并构建、提交包含已修正PTR/缺陷的新软件包(New Build)给测试组，所修正的问题得到验证直到该问题通过测试为止（称为PTR关闭），测试过程中特定时间PTR保持的数量（所有新发现的PTR和关闭的PTR的差值）——PTR累积/积压值。PTR出现／累积模型就是根据问题跟踪报告的两种数据——某个时间单位内的PTR出现值和某个时间PTR累积值来度量测试中所发现的缺陷变化过程，即软件产品质量状态的变化过程。

3．测试用例的深度、质量和有效性

测试用例是测试执行的基础，其质量的好坏直接关系到测试的质量，也就影响着软件质量的保证过程。测试用例的度量将包含测试用例的深度、质量和有效性，而且包含自动化程度的度量，即多少比例的测试用例已被自动化了。
测试用例的深度（TCD, Test Case Depth）度量可以表示为每KLOC的测试用例数或每个功能点/对象点的测试用例数，而测试用例的效率可以用每100或1000个测试用例所发现的缺陷数来衡量，不同的测试阶段是不一样，应该对同一阶段的不同版本进行比较，而不宜对同一版本的不同阶段进行比较。而测试用例的质量（TCQ, Test Case Quality）可以用由测试用例发现的缺陷数量来度量，即

TCQ = 测试用例发现的缺陷数量/总的缺陷数量

因为还有一部分缺陷可以通过ad-hoc 测试（随机、自由的测试）、集体走查(Work-through)和Fire-drill测试(类似消防训练的用户压力/验收测试)等其他手段发现缺陷

4．测试执行的效率和质量

测试执行的质量一般可以用软件发布后所遗留的软件缺陷和总缺陷数的比值来衡量，一般要求低于0.5%，也可以通过种子公式或交叉测试等方法衡量。测试执行的效率可以用下列几种方法来综合度量：

• 每个人日所执行的测试用例数
• 每个人日所发现的缺陷数
• 每修改的KLOC所运行的测试用例数

5．缺陷报告的质量

缺陷报告质量可以评估测试人员工作质量的方法之一，如可测量的指标有：

• 缺陷报告有效性，所有修正/关闭的（等级高的）缺陷和测试人员所报的所有（等级高的）缺陷的比值，这个值越接近1，有效性就越高，如果考察等级高的缺陷，其正常值大约在0.92 – 0.96
• 缺陷报告质量，可以用一些中间状态为“需要补充信息”、“不是缺陷”的缺陷数量来衡量，一般占总缺陷数的3%-5%为正常，高于或低于这个值都可能不正常，高于5%，可能说明缺陷报告质量低；低于3%，可能说明测试人员缺少怀疑精神。

6．基于需求的测试覆盖评估

基于需求的测试覆盖评估是依赖于对已执行/运行的测试用例的核实和分析，所以基于需求的测试覆盖评测就转化为评估测试用例覆盖率：测试的目标是确保100%的测试用例全部成功地执行。一般在测试计划中，就定义了测试的工作量、测试用例数量和测试用例覆盖率（98%-100%），我们根据事先确定的测试日程安排，可以将测试计划值做成曲线，然后根据实际执行结果，定期（每天或每周）去画实际值曲线，从而可以进行测试全过程监控和预测。

在执行测试活动中，评估测试用例覆盖率又可分为两类测试用例覆盖率估算：

• 确定已经执行的测试用例覆盖率，即在所有测试用例中有多少测试用例已被执行。假定Tx已执行的测试过程数或测试用例数，Rft是测试需求的总数：
• 已执行的测试覆盖 ＝ Tx／Rft
• 确定成功的测试覆盖，即执行时未出现失败的测试，如没有出现缺陷或意外结果的测试，假定Ts是已执行的完全成功、没有缺陷的测试过程数或测试用例数。
• 成功的测试覆盖 ＝ Ts／Rft

7．基于代码的测试覆盖评估

基于代码的测试覆盖评测是对被测试的程序代码语句、路径或条件的覆盖率分析。如果应用基于代码的覆盖，则测试策略是根据测试已经执行的源代码的多少来表示的。这种测试覆盖策略类型对于安全至上的系统来说非常重要。

评估代码覆盖率，需要断定测试目标期望的、总的测试代码行数，在测试中真正执行的代码行数及其百分比，将此结果记录在测试评估报告中。测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之前是否已经定义。

基于代码的测试覆盖通过以下公式计算：已执行的测试覆盖 ＝ Tc／Tnc

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

第29回 软件质量度量

软件产品质量度量是软件质量度量重要组成之一，其度量的对象是软件产品，测量其软件平均失效时间、缺陷密度、适用性、可靠性等产品的质量属性，用于对软件产品进行评价，并在此基础之上不断优化产品设计、产品制造和产品服务。

软件产品质量度量包括软件复杂度、客户满意度的度量，由于篇幅所限，在此略去。 软件产品质量度量，则主要集中在软件缺陷的度量，而且这和软件测试有直接的关系。

质量是反映软件与需求相符程度的指标，而缺陷被认为是软件与需求不一致的某种表现，所以通过对测试过程中所有已发现的缺陷进行评估，可以了解软件的质量状况。也就是说，软件缺陷评估是评估软件质量的重要途径之一，软件缺陷评估指标可以看作是量度软件产品质量的重要指标，而且缺陷分析也可以用来评估当前软件的可靠性或预测软件产品的可靠性变化。

软件评估首先是建立基线，为软件产品的质量、软件测试评估设置起点，这个基准线上再设置测试的目标，作为对系统评估是否通过的标准。缺陷评测的基线是对某一类或某一组织的结果的一种度量，这种结果可能是常见的或典型的，如10000行源程序(LOC)是程序规模的一个基准，每一千行代码有3个错误是测试中错误发现率的基准。基准对期望值的管理有很大帮助，目标就是相对基准而存在，也就是定义可接受行为的基准，如表1所示。

表1某个软件项目质量的基准和目标

软件缺陷评估的方法相对比较多，从简单的缺陷计数到严格的统计建模，基于缺陷分析的产品质量评估方法有以下几种：

• 缺陷密度——软件缺陷在规模上的分布
• 缺陷率——缺陷在时间上的分布
• 整体缺陷清除率
• 阶段性缺陷清除率
• 缺陷趋势、预期缺陷发现率
• 软件产品性能评估技术
• 借助工具的其他方法

1．缺陷密度

Myers有一个关于软件测试的著名的反直觉原则：在测试中发现缺陷多的地方，还有更多的缺陷将会被发现。这个原则背后的原因在于：如果缺陷发现缺陷多的地方、漏掉的缺陷可能性也会越大，或者告诉我们测试效率没有被显著改善之前，那么在纠正缺陷时将引入较多的错误。这条原理的数学表达就是缺陷密度的度量——每KLOC或每个功能点（或类似功能点的度量——对象点、数据点、特征点等）的缺陷数，缺陷密度越低意味着产品质量越高。

• 如果缺陷密度跟上一个版本相同或更低，就应该分析当前版本的测试效率是不是降低了？如果不是，意味着质量的前景是乐观的；如果是，那么就需要额外的测试，还需要对开发和测试的过程进行改善。
• 如果缺陷密度跟上一个版本高，那么就应该考虑在此之前为显著提高测试效率进行了有效的策划并在本次测试中得到实施？如果是的，虽然需要开发人员更多的努力去修正缺陷，但质量还是得到更好的保证；如果没有，意味着质量恶化、质量很难得到保证。这时，要保证质量，就必须延长开发周期或投入更多的资源。

2．缺陷率

缺陷率的通用概念是一定时间范围内的缺陷数与错误几率（OFE，opportunities for error）的比值。前面我们已经讨论过软件缺陷和失败的定义，失败是缺陷的实例化，可以用观测到的失败的不同原因数目来近似估算软件中的缺陷数目。

软件产品缺陷率，即使对一个特定的产品，在其发布后不同时段也是不同的。例如，对应用软件的角度来说，90%以上的缺陷是在发布后两年内被发现出来，而对操作系统，90%以上的缺陷通常在产品发布后需要四年的时间才能被发现出来。

3．整体缺陷清除率

让我们先引入几个变量，F为描述软件规模用的功能点；D1为在软件开发过程中发现的所有缺陷数；D2为软件发布后发现的缺陷数；D为发现的总缺陷数。因此，D=D1+D2。

对于一个应用软件项目，则有如下计算方程式（从不同的角度估算软件的质量）：

• 质量 = D2/F；
• 缺陷注入率 = D/F；
• 整体缺陷清除率= D1/D；

假如有100个功能点，即F=100，而在开发过程中发现了20个错误，提交后又发现了3个错误，则：D1 =20，D2 =3, D= D1+D2 =23

• 质量(每功能点的缺陷数)=D2/F= 3/100= 0.03 ( 3% )
• 缺陷注入率= D/F= 20/100= 0.20 ( 20%)
• 整体缺陷清除率= D1/D= 20/23= 0.8696 ( 86.96%)

有资料统计，美国的平均整体缺陷清除率目前只达到大约85%，而对一些具有良好的管理和流程等著名的软件公司，其主流软件产品的缺陷清除率可以超过98%。

众所周知，清除软件缺陷的难易程度在各个阶段也是不同。需求错误、规格说明、设计问题及错误修改是最难清除的，如表2所示。

表2 不同缺陷源的清除效率

表3反映的是CMM五个等级是如何影响软件质量的，其数据来源于美国空军1994年委托SPR（美国一家著名的调查公司）进行的一项研究。从表中可以看出，CMM级别越高，缺陷清除率也越高。

表3 SEI CMM级别潜在缺陷与清除率

4．阶段性缺陷清除率

阶段性缺陷清除率是测试缺陷密度度量的扩展。除测试外，它要求跟踪开发周期所有阶段中的缺陷，包括需求评审、设计评审、代码审查。因为编程缺陷中的很大百分比是同设计问题有关的，进行正式评审或功能验证以增强前期过程的缺陷清除率有助于减少出错的注入。基于阶段的缺陷清除模型反映开发工程总的缺陷清除能力。

进一步分析缺陷清除有效性(DRE，Defect Remove Efficiency)，DRE可以定义为：

开发阶段清除的缺陷数/产品潜伏的缺陷总数 x 100％

因为潜伏缺陷的总数是不知道的，必须通过一些方法获得其近似值，如经典的种子公式方法。当用于前期的和特定阶段的时候，此时DRE相应地被称为早期缺陷清除有效性和阶段有效性，对给定阶段的潜伏缺陷数，可以估计为：

当前阶段的潜伏缺陷数 = 当前阶段排除的缺陷数＋以后发现的缺陷数

给定阶段的DRE度量值越高，遗漏到下一个阶段的缺陷就越少。

缺陷是在各个阶段注入到阶段性产品或者成果中去，通过表4 描述的与缺陷注入和清除相关联的活动分析，可以更好地理解缺陷清除有效性。回归缺陷是由于修正当前缺陷时而引起相关的、新的缺陷，所以即使在测试阶段，也会产生新的缺陷。

表 4 与缺陷注入和清除相关联的活动

清除的缺陷数等于检测到的缺陷数减去不正确修正的缺陷数。如果不正确修正的缺陷数所占的比例很低（经验数据表明，测试阶段大概为2％），清除的缺陷数就近似于检测到的缺陷数。

第30回 总结

软件测试演义——中高级系列（序）要结束了，但我认为这仅仅是开始，有许多东西要学，有许多东西要深入下去，不断探讨，才能完成在软件测试上的使命......

如果要对 “软件测试演义“ 有一个总结的话，可以用一句话来概括，软件测试是一门地地道道的学问，同时也是一门艺术。

测试的学习，也是从厚到薄，再从薄到厚。但我们真正进入了软件测试领域后，我们才会发现、或真正感到有许多东西要学。

说起软件测试学问，在 软件测试全貌 里可以略见一斑，如静下心来看看：

• 基于有限状态机
• 基于形式化规格说明
• 基于控制流的准则
• 分布式系统的测试
• 变异测试

同时，要了解软件测试的一些新的技术和新的平台，例如有不少新的开源测试工具需要了解，如Selenium/EMMA等，还有更多的自动化测试框架，如:

• STAF: Software Testing Automation Framework
• SAFT: Software Automation Framework Support

自动化脚本技术也是在不断发展，如从数据驱动(data-driven)向关键字驱动（Keyword-driven），使测试脚本中业务逻辑、操作（action）和数据得到分离，不仅仅是数据和脚本代码的分离。

更让我们始终感到有压力的是，软件本身发展很快，软件测试要不断适应软件的发展。不仅涉及语言（ASP/PHP/Java, C++/C＃, Ruby.. .) 、平台（OS + .NET, J2EE, ...) 等变化，还涉及模式、方法和技术的变化。如从面向对象（OO, Object-Oriented）软件的测试，到面向构件(CO, Component-Oriented)、面向方面(AO, Aspect-Oriented)、面向服务架构（SOA，Service-oriented architecture）、面向SaaS(Software as a service, 软件即服务) 软件开发等的测试，不断创新，无一不要求我们学习、再学习。

软件测试作为艺术，充满了很多的辨证统一的矛盾体：

• 白盒测试方法和黑盒测试方法
• 静态测试 (static test) 和 动态测试( Dynamic test)
• 手工测试（Manual test）和自动化测试(Automated Test)
• 有计划测试（Planned Test）和随机测试（Ad-hoc test 或Random test）
• 新功能测试（new feature test）和回归测试 (Regression testing)

更具有挑战的是，在效率和质量风险中获得平衡，在不断和风险、巨大的环境组合、无穷的测试用例数等进行搏斗。需要辨证地从多个视角去看待它，不断的思考以获得适宜的测试方法和策略，并最终依赖TA的实现、有效的管理，达到我们的质量目标。

从测试人员个人讲，要不断地实践，上前线打仗是锻炼士兵的最好办法，测试也是一样，测试方法、测试用例设计、测试脚本开发、测试工具使用和执行等，都需要和实际项目结合起来，也是最基本的要求。

从测试团队讲，可能要不断进行 测试的革命，依据”测试成熟度模型“，推进团队的成熟、发展，使团队不仅拥有测试各个领域的技术和经验，更重要形成一套开放的、自我改进的、相对完善的测试体系，包括思想、方法、工具和基础设施等。

要对大家有一个交待，一个真正的总结，就是再将薄变厚，写成一本系统的、实用的、手把手教大家做测试的、高水平的软件测试指导书。目前，正在和电子工业出版社的博文视点（BroadView）合作，今年8-9月份有望和大家见面。