测试覆盖度评估是衡量阶段性软件测试执行状态的重要手段之一，来确定测试是否达到事先设定的测试任务完成的标准。测试覆盖率则是测试覆盖度评估中一种量化的表示方法，一般通过被测试的软件产品需求、功能点、测试用例数或程序代码行等来进行计算。
软件测试覆盖率常用的计算公式：
- 功能覆盖率= 至少被执行一次的测试功能点数/ 测试功能点总数 （功能点）
- 需求覆盖率= 被验证到的需求数量 /总的需求数量 （需求）
- 覆盖率= 至少被执行一次的测试用例数/ 应执行的测试用例总数 （测试用例）
- 语句覆盖率= 至少被执行一次的语句数量/ 有效的程序代码行数
- 判定覆盖率= 判定结果被评价的次数 / 判定结果总数
- 条件覆盖率= 条件操作数值至少被评价一次的数量 / 条件操作数值的总数
- 判定条件覆盖率= 条件操作数值或判定结果至少被评价一次的数量/(条件操作数值总数+判定结果总数)
- 上下文判定覆盖率= 上下文内已执行的判定分支数和/(上下文数*上下文内的判定分支总数)
- 基于状态的上下文入口覆盖率= 累加每个状态内执行到的方法数/(状态数*类内方法总数)
- 分支条件组合覆盖率= 被评测到的分支条件组合数/分支条件组合数
- 路径覆盖率= 至少被执行一次的路径数/程序总路径数
除此之外，覆盖率还包括类覆盖率、函数覆盖率、代码块覆盖率等，如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回 测试结果分析和质量报告
版权所有，软件测试演义® ——系列讨论的目录，见：
软件测试演义——中高级系列（序）
发表于 @ 2006年12月16日 20:41:00|评论(loading...)|编辑