2.7 路径覆盖（Path Coverage ）
这个度量报告是否函数的每一个可能的分支都被执行了。一个路径就是一个从函数的入口到函数的出口的唯一的系列分支。 也称呼为断言覆盖（predicate coverage）。断言覆盖可以看出可以组合的逻辑条件的路径[Beizer1990 p.98]。
因为循环引入了一个很大的路径数，这个度量只考虑一个有限数量的循环可能性。有很多的变种来处理循环，内部边界路径测试（Boundary-interior path testing）只考虑循环的两个可能性。重复零次和多于零次的重复[Ntafos1988]。对于do-while 循环，两种，零次反复和多于零次反复。 路径覆盖的一个好处是：需要彻底的测试。 但有两个缺点：
一是，路径是以分支的指数级别增加的，例如：一个函数包含10个IF语句，就有1024个路径要测试。如果加入一个IF语句，路径数就达到2048。 二是，许多路径不可能与执行的数据无关。例如 if (success)
statement1; statement2; if (success)
statement3;
路径覆盖认为以上语句包含四个路径，实际上只有两个是可行的：success=false 和 success=true.
研究者发明了很多种的路径覆盖技术来避免大数量的路径。如，n-length sub-path coverage 报告你是否exercised each path of length n branches.其它变种包括linear code sequence and jump (LCSAJ) coverage 和data flow coverage.
3 其它度量
这里介绍一些其它的基本的很少使用的度量的益处和弱点。
3.1 函数覆盖（Function Coverage ）
这个度量报告是否你调用了每个函数或过程。对于初步的测试来保证至少在所有的软件没有总的不足非常有用。 大多数覆盖率工具都支持。
3.2 函数出入口覆盖（Function Exits Coverage）
报告对函数的入口、出口和终止指令.覆盖情况统计。 据我所知，TestRT支持此覆盖。 3.3 调用覆盖（Call Coverage ）
这个度量报告是否你执行每个函数调用。前提是缺陷一般发生在模块的接口处。 也称呼为调用对覆盖（call pair coverage）。 据我所知，TestRT支持此覆盖。
3.4 线性代码顺序及跳转覆盖（Linear Code Sequence and Jump (LCSAJ) Coverage ） 这个是路径覆盖（path coverage ）的一个变更。考虑到在源代码中只有子路径可以被容易的替，不需要一个流程图。一个LCSAJ 是一系列源代码线执行的序列。 优点是这个度量比判定覆盖测试的更彻底，而且避免了路径覆盖的指数级的难度。缺点是它不能避免不可实行的路径。 据我所知，LDRA TestBed支持此覆盖。
3.4.1 覆盖率的计算公式：
如下图所示：
一个LCSAJ是由以下四个特征的数量决定的。
A Start Point：可以是程序的开始或任何控制流跳转的目标的线。
A Linear Code Sequence：通过可以系列处理的控制流的代码体。可以由几个连续的基本块组成。
An End Point：The first line encountered from which a jump is made which has been reached from the start point by the unbroken linear sequence of code.
A Target Point： The point to which the End Points\will be the Start Point of the next LCSAJ. Therefore, since the start point of the linear code sequence is a line which is the target of another jump, these fragments are also called jump-to-jump paths.
这个例子的计算此LCSAJ覆盖的分母就是11。
3.5 数据流覆盖（Data Flow Coverage ）
这是path coverage的一个变种，只是考虑到从变量的分配到后来的变量的引用的子分支。
好处是直接适当的报告程序处理的数据。一个缺点是不包含判定覆盖，另一个缺点是太复杂。很多的变量，用于计算的、用于判定的、局部的、全局的，如果有指针就更复杂。
3.6 目标代码分支覆盖（Object Code Branch Coverage ） 这个度量报告是否机器语言条件分支通过了分支。
这个度量给出的报告更多的是依赖编译器而不是程序结构。因为目标代码的结构和源程序的结构很不相似。而且，分支破坏了指令通道，编译起有时候避免产生一个分支，而替换为一个系列的无分支指令。
3.7 循环覆盖（Loop Coverage ）
这个度量报告你是否执行了每个循环体零次、只有一次还是多余一次（连续地）。对于do-while 循环，循环覆盖报告是否执行了每个循环体只有一次还是多余一次（连续地）。
这个度量的有价值的方面是确定是否对于while循环和for循环执行了多于一次，这个信息在其它的覆盖率报告中是没有的。
据我所知，GCT和rational TestRT可以执行这个度量。
3.8 竞争覆盖（Race Coverage）
这个度量报告是否多个线程在同一时间执行了同一块代码。它帮助检测资源的同步失败问题。对于多线程的程序例如操作系统程序非常有用。 据我所知，GCT可以执行这个度量。
3.9 比较操作符覆盖（Relational Operator Coverage）
这个度量报告是否对于比较操作符(<, <=, >, >=)是否发生了边界条件。假设边界条件测试用例发现了off-by-one errors ，并且 错误使用了比较操作符，例如把< 用作了<=。例如，考虑如下的C/C++ 代码： if (a < b)
statement;
比较操作符报告是否发生了条件a==b。如果If a==b 发生了而且程序执行正常，那么。。。。。。
据我所知，GCT可以执行这个度量。
3.10 弱变化覆盖（Weak Mutation Coverage）
这个度量和relational operator coverage 相似，但是更普遍[Howden1982]。它报告是否测试用例发生了错误的引用了操作符和操作数。 据我所知，GCT可以执行这个度量。
3.11 表覆盖（Table Coverage）
这个度量显示是否一个特殊的数组的每个入口都被引用。这个度量对于一个通过有限状态机来控制的程序非常有用。
4 比较各种覆盖
· Decision coverage 包含statement coverage，
· Condition/decision coverage 包含decision coverage 和 condition coverage · Path coverage 包含 decision coverage.
· Predicate coverage 包含 path coverage 和multiple condition coverage Academia说强的覆盖率度量包含了弱的覆盖率度量。 各种覆盖率度量结果不能从数量上比较。
4.1 对Release版本的覆盖目标
每个项目都要选择一个最低的覆盖率目标，对安全标准严格要求的软件应该制定一个高的目标。单元测试的目标应该比系统测试的高，因为一个在低水平代码的failure 可以影响到多个高水平代码的调用者。
用statement coverage, decision coverage或condition/decision coverage ，在发行版本前80 -90 或更多的覆盖率。可能有人觉得制定的目标少于100 的覆盖率不能保证软件质量，但是你耗在覆盖率技术上的时间如果用于其它测试技术，例如代码走读等，将会发现更多的faults，要避免制定的目标少于80 。
4.2 中间版本的覆盖目标
选择一个好的中间的覆盖率目标可以很大的提高测试的生产力。
当你发现最多的 failures用了最少的努力， 那你就有最高的测试生产力。努力怎么测量呢？创建测试用例，把它们加入到你的测试套并运行它们的总时间就是。
5 总结
覆盖分析是一种结构化测试技术，帮助弥补测试套中的缝隙。对缺少具体的、没有更新需求定义项目帮助很多。分支条件组合覆盖（Condition/Decision Coverage ）技术我觉得是对于 C, C++和Java语言的最好的。 设置一个目标100 的覆盖率(对于任一种覆盖率) 都将阻止测试的生产力，在发放版本之前，定一个80 -90 或更多的目标对于语句、分支、条件覆盖率较好。
6 参考
Beizer1990 Beizer, Boris, \Nostrand Reinhold, 1990
Chilenski1994 John Joseph Chilenski and Steven P. Miller, \Condition/Decision Coverage to Software Testing\Software Engineering Journal,
September 1994, Vol. 9, No. 5, pp.193-200.
RTCA/DO-178B, \Considerations in Airborne Systems and Equipment Certification\
Howden1982 \Mutation Testing and Completeness of Test Sets\IEEE Trans. Software Eng., Vol.SE-8, No.4, July 1982, pp.371-379.
McCabe1976 McCabe, Tom, \Eng., Vol.2, No.6, December 1976, pp.308-320.
Morell1990 Morell, Larry, \Theory of Fault-Based Testing\IEEE Trans. Software Eng., Vol.16, No.8, August 1990, pp.844-857.
Ntafos1988 Ntafos, Simeon,\Comparison of Some Structural Testing Strategies\IEEE Trans. Software Eng., Vol.14, No.6, June 1988, pp.868-874.
Roper1994 Roper, Marc, \Testing\London, McGraw-Hill Book Company, 1994
7 术语表
Fault ――― A bug. A defect。一个臭虫，一个过失。 Error ―――一个人为的错误，结果是一个fault。 Failure ―――fault的一个实时运行时的表现
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/tofy/archive/2004/08/11/71630.aspx