控制流测试

控制流测试 (Control Flow Testing)：是一种在考虑测试对象的控制流情况下导出测试用例的测试方法，并且借助于控制流图能评估测试的完整性（覆盖率）。

原则

• 控制流图是一个带有开始节点和结束节点的有向图
• 程序的指令（语句）是通过节点来表示的
• 一个不带分支和汇总的语句序列可以简单地用一个节点来表示
• 语句之间的路径通过有向线（控制流）表示
• 控制流图的开始和结束节点在实际应用中常常被省略

测试活动

1. 列出应该覆盖的路径
2. 设计输入、输出使得程序能按逻辑含义走到此路径
3. 运行测试来观察此路径是否走到。如果没有走到，则要么是对逻辑理解不足，要么是逻辑本身有错误。

主要的控制流测试方法：

• 语句覆盖
• 分支覆盖
• 判定覆盖
• 路径覆盖（包括结构化的路径覆盖等）

语句覆盖

语句覆盖（C₀-覆盖）/ 语句覆盖测试 / 语句测试（Statement testing）：在控制流中每条可执行的语句至少被执行一次！

• 必要的、最简单的，但也是最弱的标准
• 无法检测到缺失的语句
• 但能发现无法执行到的语句（死代码）

覆盖率：
语句覆盖 = 已执行的语句数目 / 所有语句的总数目 * 100%

语句即节点，控制流图内的所有节点都走到即为 100% 语句覆盖

分支覆盖

分支覆盖（C₁-覆盖）/ 分支覆盖测试 / 分支测试（Branch testing）：在控制流图内的每一条边都至少被执行一次！

• 在实践中作为最小的测试标准
• 能发现无法执行到的程序分支
• 无法发现缺失的分支
• 没有测试到分支的组合

覆盖率：
分支覆盖 = 已执行的分支数目 / 分支总数目 * 100%

每一条边即每一条控制流（有向线）都走过了，才为 100% 分支覆盖

判定覆盖

判定覆盖 / 判定测试（Decision testing）：每一个可能的判定输出都应该被测试到！

• 如果达到 100% 判定覆盖，则等价于分支覆盖
• 但这里计数的不是分支，而是判定的输出，判定覆盖在小于 100% 时，判定的覆盖率与分支的覆盖率可能有所不同！

覆盖率：
判定覆盖 = 已执行的判定结果 / 所有的判定结果总数 * 100%

判定覆盖计数的是判定的结果，即布尔值true和false的个数

示例代码：

if (x > y) {
    y = x;
}
if (y > z) {
    z = y;
}

这段代码一共有两个if判定，每个判定都可以有true和false两个判定结果，一共是四个判定结果。

所以如果只用一条 case 同时覆盖x > y和y > z，实际上执行到的是两个判定结果，判定覆盖率为 2 / 4 = 50%

在同一条 case 的情况下，画出控制流图，分支覆盖一共有 9 条有向线（包括开始节点和结束节点的两条有向线），有两条分支没有走到，所以分支覆盖率为 7 / 9 = 77.8%

路径覆盖

路径覆盖（C_∞-覆盖，C₄-覆盖）/ 路径覆盖测试 / 路径测试（Path testing）：在控制流图内的每一个分支序列（路径）都应该执行一次！

强标准，因为

• 在包含循环时，可能会有无数的路径
• 在具有 k 个连续的分支时，则会有 2^k种不同的路径

定制选择有意义的路径（Beizer）
限制重复次数：循环覆盖测试方法
限制考虑的路径：片段对覆盖（Segment pair）

针对路径测试，按照 Beizer 的启发式方法 [Beizer90]：

• 从最简单的、功能上有意义的路径开始（从入口到出口的最简单路径）
• 每次新的路径应该只是对现有的微小变化（如果可能，仅只改变一个判定输出/真值）
• 优先考虑短的路径、简单路径、功能上有意义的路径、不带循环的路径
• 应该达到 100% 判定覆盖
• 避免功能上无意义的路径，如果为了达到判定覆盖必须执行这路径，则应该检查是否是一个错误，如果不是，则增加此路径。
• 优先考虑那些很有可能是实际执行的路径

从开始节点到结束节点之间全部可能的路径都走过才是 100% 路径覆盖

• 部分路径测试经常用在安全关键软件的测试中
• 常用条件覆盖方法组合使用，因为它们检查软件的另一个方面
• 当只需要增加少量的测试用例时，它可以作为分支测试的深入
• 应该使用工具来创建控制流图

结构化的路径覆盖

结构化的路径覆盖（C_i(k)-覆盖）：执行在一个内循环中运行次数还没有超过 k 次的所有路径！

对于 k = 2 时，这种方法也成为内部边界 - 路径覆盖（Boundary Interior）

仅仅当 k 为很小值时才有实际意义。

其他针对循环的测试的标准：

• 最小和最大迭代次数，排除迭代数
• 在程序中的循环一般：嵌套、交叉、非结构化的循环

条件测试

• 简单条件测试
• 条件测试/判定测试 或 判定条件测试
• 改进的条件/判定测试（MC/DC）
• 复合条件测试

它们的区别是测试的深度（从上往下越来越深入），需要的测试用例数，以及能发现多少缺陷

简单条件测试

简单条件测试（Condition testing：一个布尔表达式内的每个原子条件（Atomic condition） 都应该对其二个值（真/TRUE 和 假/FALSE）进行测试。

一个原子条件是一个不包含逻辑运算符 NOT、AND 或 OR 的条件

如果在程序内的所有条件都仅仅是一个原子条件，则相应的简单条件测试对应为判定测试。

满足简单条件覆盖不一定会满足判定覆盖，所以简单条件测试仅仅是理论上进行探讨，没有太大实际意义

条件测试/判定测试 或 判定条件测试

条件测试/判定测试（Decision condition testing）：

• 每一个判定都应该要对它的二个值（真和假）进行测试
• 每个原子条件都应该要对它的二个值（真和假）进行测试

包含了简单条件覆盖以及判定覆盖。通常不需要比简单条件覆盖更多的测试用例，但是必须谨慎选择。

• 此方法适合于测试那些重要的，但还不是关键和核心的代码
• 此方法与后面的二种方法相比需要较少的测试用例，但是比单纯的判定覆盖要更繁琐（还要看原子条件的覆盖）

改进的条件/判定测试（MC/DC 测试）

改进的条件/判定测试（Modified Condition/Decision Coverage）

• 每一个判定都应该要对它的二个真值（真和假）进行测试
• 每一个原子条件都应该对它的二个真值（真和假）进行测试
• 在测试中能够表明，每一个原子条件的值独立地影响表达式的结果

针对单个的原子条件，必须关注具有不同结果的测试用例，结对进行比较。

1. 先列出所有可能的真值组合
2. 选出那些单个原子条件影响结果的测试用例对

• 提供一个更高的控制流覆盖并能发现比条件覆盖/判定覆盖更多的缺陷
• 需要更多的测试用例，但是：
  • 当有 n 个原子条件，通常需要 n+1 个测试用例。测试用例的数目与条件的数目是线性关系（线性增长）。
  • 很适合安全关键系统，例如，在航空和航天业广泛采用改进的条件测试/判定测出（MC/DC）方法

限制：耦合的条件

例如： (A AND B) OR ((NOT A) AND C)

这些条件称作耦合（重叠），而这些耦合的项往往无法实现 MC/DC 测试。

解决方法：

• MC/DC 仅仅针对不耦合的条件
• 对于含有耦合条件的每个判定作为特例，视不同的情况生成测试用例

限制：短路/精简的评判（Short-circuiting）

在有条件的进行评价的程序设计语言中往往无法达到 MC/DC 的覆盖。

解决方法：必须降低“测试用例对”的要求，对于每个原子条件生成一对测试用例，

• 要覆盖这个条件的二个真值（真/假）
• 要覆盖整个判定式的二个真值（真/假）
• 所有其他原子条件具有相同的逻辑或不进行评估。

复合条件测试

复合条件测试（Multiple condition testing）：测试原子条件的所有可能的真值（真/假）组合

• 复合条件覆盖包含了 MC/DC 覆盖
• 因为测试用例可以从真值表直接导出，所以测试的设计更为简单
• 缺点：非常耗资（n 个原子条件将会有 2ⁿ个组合）
• 长期需要稳定可靠的嵌入式系统测试中常会使用此方法（例如，在电话网内的交换机系统，按要求应该运行 30 年），但也逐渐被 MC/DC 所替代