一个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" control flow jump is made. This 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, "Software Testing Techniques", 2nd edition, New York: Van Nostrand Reinhold, 1990
Chilenski1994 John Joseph Chilenski and Steven P. Miller, "Applicability of Modified Condition/Decision Coverage to Software Testing", Software Engineering Journal, September 1994, Vol. 9, No. 5, pp.193-200.
RTCA/DO-178B, "Software Considerations in Airborne Systems and Equipment Certification", RCTA, December 1992, pp.31, 74.
Howden1982 "Weak Mutation Testing and Completeness of Test Sets", IEEE Trans. Software Eng., Vol.SE-8, No.4, July 1982, pp.371-379.
McCabe1976 McCabe, Tom, "A Software Complexity Measure", IEEE Trans. Software Eng., Vol.2, No.6, December 1976, pp.308-320.
Morell1990 Morell, Larry, "A Theory of Fault-Based Testing", IEEE Trans. Software Eng., Vol.16, No.8, August 1990, pp.844-857.
Ntafos1988 Ntafos, Simeon,"A Comparison of Some Structural Testing Strategies", IEEE Trans. Software Eng., Vol.14, No.6, June 1988, pp.868-874.
Roper1994 Roper, Marc, "Software Testing", London, McGraw-Hill Book Company, 1994
7 术语表
Fault ――― A bug. A defect。一个臭虫，一个过失。
Error ―――一个人为的错误，结果是一个fault。
Failure ―――fault的一个实时运行时的表现。