数据流覆盖

        这种路径覆盖的变种只考虑从分配的变量到后续参考的变量之间的子路径的情况。它的优点就是它所考虑到的路径都是和程序处理数据的方法直接相关。它第一个缺点是它并不包含判定覆盖。另外一个缺点就是复杂。研究学者提出了几种变种，但这几种都是增加了它的复杂度的。比如说，这些改进了的度量方法因为计算语句中的变量的使用方法与在判定语句中的变量使用方法不同而不同，本地与全局变量的使用不同而不同。通过对代码优化进行数据流分析，指针也会造成问题的产生。

目标码分支覆盖

        这种度量报告了每个机器语言条件转移命令是成功的转移到分支了还是失败了。这种度量给出的结果与编译器更加相关而不是程序结构。造成这种情况的原因是编译器的代码生成和优化技术, 能够生成可以承受相似的源代码结构[***]。

        因为分支会被指令管道所中断，所以有时候编译器需要避免生成分支，而且要生成替代此分支的非分支指令序列。编译器经常由于要让函数少调用一些其它函数而要向函数里内嵌一些代码。如果此类函数包含了分支，那么与源代码比起来，它相应的机器码就会非常明显的增加了不少。

        你最好是针对原始的源代码来进行充足的测试，因为它比目标码更加与程序的需求相关。

循环覆盖

        这种度量报告了每个循环是否被执行了0次，1次，以及多于1次。对于DO-WHILE循环，循环覆盖报告的是你是否执行了1次和超过1次。这种度量最有价值的地方就是它可以决定WHILE循环和FOR循环执行超过一次，这样的信息其它度量是不能提供的。具我所知，只有GCT实现了这种度量。

RACE覆盖

        这种度量报告了是否多线程在同一时间执行了同样的代码。它可以帮助查到同时对资源存取这样的问题。它对于多线程程序的测试是非常有用的，比如说在一个操作系统里使用。 据我所知，只有GCT实现了这种度量。

关系操作符覆盖

        这种度量报告的是具有关系操作符（<,<=,>,>=）的时候，边界值的情况。 它假想的是这些边界测试用例查到一些差一（OFF-BY-ONE）错误，以及用了错误的关系操作符（比如，用<代替了正确的<=）

下面举个C/C++的例子来讲：

if (a < b)
statement;

        关系操作符覆盖报告是否有A==B的这种情况发生。如果A==B发生了，若程序也给出正确的反应，那你就可以知道此关系操作符是<=是错的。到目前为止，我就只知道GCT是有实现这个度量的。

弱转换覆盖[***]（Weak Mutation Coverage）

        这种度量与关系操作符覆盖相似，但它更具有概括性[Howden1982]。它所报告的是测试用例是否显露了错误的操作符操作数的使用问题。首先，它会将程序表达式里原有的操作符与变量用替身操作符与替身变量取代，比如说使用"-"号替代掉"+"号，然后它再报告这个被转换掉的条件的覆盖率。

        这种度量目前暂时还主要处于学术界中[译者：此篇源文与译文的年数相差较大，可能不太准确]，它有多种不同的解释[***]。而且在它可以具体应用之前，被测程序需要达到不少的特殊要求才行。同样的，具我所知，它目前只在GCT中得到实现。

表覆盖

        这种度量讲的是在某一数组中的每一个元素是否被引用了。这种方法对于被有限状态机控制的程序非常有用。

度量方法的比较

        当一个强的度量方法包含了另一个比较弱的度量方法时，你只能比较他们之间的相对的强处。

        判定覆盖包括了语句覆盖，原因是当执行过每一条分支的时候，肯定会导致每一条语句都被执行了。
        条件/判定覆盖包括了判定覆盖与条件覆盖（这是由它们的定义得出来的）
        路径覆盖包括了判定覆盖
        断言覆盖包括了路径覆盖和多条件覆盖，以及其它大多数度量方法。

        学术界也认为强的度量方法包含了弱的度量方法。覆盖度量方法是不能从数量上进行比较。

发布标准中的覆盖率目标

        每一个项目都必须要根据可用的测试资源以及防止推迟发布的重要性，来选择一个可以作为发布标准的覆盖率最小值。
        很明显的，和安全相关的软件，它的覆盖率就要有一个高一些的值。还有，你也可以把单元测试的覆盖率最小通过值设置得比系统测试的要高。它这样做的原因是低层次的代码错误可以影响到很多高层的调用代码。