由于对于不同复杂度的代码逻辑，可以衍生出许多种执行路径，只有选择适当的测试方法，才能帮助我们从代码的迷雾森林中找到正确的方向。
1、语句覆盖（Statement Coverage）
对程序的逻辑覆盖很少，只关心判定表达式的值，是很弱的逻辑覆盖标准。
- 【基本思想】：设计若干测试用例，运行被测程序，使程序中每个可执行语句至少执行一次。
- 【优点】：检查所有语句、代码覆盖率高
- 【缺点】：无法检查出条件、循环语句的错误
2、判定覆盖（Decision Coverage）
判定覆盖比语句覆盖强一些，能发现一些语句覆盖无法发现的问题。但是往往一些判定条件都是由多个逻辑条件组合而成的，进行分支判断时相当于对整个组合的最终结果进行判断，这样就会忽略每个条件的取值情况，导致遗漏部分测试路径。
- 【基本思想】：设计若干测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断真假值均曾被满足。
- 【优点】：判定覆盖具有比语句覆盖更强的测试能力。
- 【缺点】：往往大部分的判定语句是由多个逻辑条件组合而成，若仅仅判断其整个最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径，判定覆盖仍是较弱的逻辑覆盖。
3、条件覆盖（Condition Coverage）
通常而言条件覆盖比判定覆盖强，因为条件覆盖使得判定中的每一个条件都取到了不同的结果，这一点判定覆盖则无法保证。但条件覆盖也有缺陷，因为它只能保证每个条件都取到了不同结果，但没有考虑到判定结果，因此有时候条件覆盖并不能保证判定覆盖。
- 【基本思想】：设计若干测试用例，执行被测程序以后要使每个判断中每个条件的可能取值至少满足一次。
- 【优点】：能够检查所有的条件错误。
- 【缺点】：不能保证所有的分支（判定）都能覆盖，仍是较弱的覆盖方式。
4、判定/条件覆盖（Decision/Condition Coverage）
判定/条件覆盖，说白了就是我们设计的测试用例可以使得判断中每个条件所有的可能取值至少执行一次（条件覆盖），同时每个判断本身所有的结果也要至少执行一次（判定覆盖）。不难发现判定条件覆盖同时满足判定覆盖和条件覆盖，弥补了两者各自的不足，但是判定条件覆盖并未考虑条件的组合情况。
- 【基本思想】：设计足够的测试用例，使得判断条件中的所有条件可能至少执行一次取值，同时所有判断的可能结果至少执行一次。
- 【优点】：既考虑了每一个条件，又考虑了每一个分支，发现错误的能力强于分支覆盖和条件覆盖
- 【缺点】：仍然不能覆盖所有的路径，有进一步提升的空间
5、条件组合覆盖（Branch Condition Combination Coverage）
条件组合覆盖，测试用例应该使得每个判定中的各个条件的各种可能组合都至少出现一次。显然，满足条件组合覆盖的测试用例一定是满足判定覆盖、条件覆盖和判定条件覆盖的。
- 【基本思想】：设计足够的测试用例，使得所有可能的条件取值组合至少执行一次。
- 【优点】：能够检查所有的条件错误
- 【缺点】：不一定能使程序中的每条路径都执行到，用例数明显增加
6、路径覆盖（Path Coverage）
路径覆盖，意思是说我们设计的测试用例可以覆盖程序中所有可能的执行路径。这种覆盖方法可以对程序进行彻底的测试用例覆盖，比前面讲的五种方法覆盖度都要高。
- 【基本思想】：要求设计足够多的测试用例，使得程序中所有的路径都至少执行一次 。
- 【优点】：这种测试方法可以对程序进行彻底的测试，比前面五种的覆盖面都广。
- 【缺点】：需要设计大量、复杂的测试用例，使得工作量呈指数级增长，不一定把所有的条件组合都覆盖。
总结一下：
- 在实际的操作中，要从代码分析和代码调研入手，可以选择上述方法中的某一种，或者好几种方法的结合，设计出高效的测试用例，尽可能全面地覆盖到代码中的每一个逻辑路径。
- 白盒测试又很少能使用手工进行，选择一款不错的自动化工具也是很重要的，之前工作中使用的testbed工具进行这种覆盖测试非常方便，而且提供一个MC/DC（修正条件/判定覆盖）的方式，在能够保证覆盖效果的情况下，尽可能减少测试用例的数量。
建议收藏加关注，这块内容需要持续验证才能在项目中熟练使用。
链接：https://www.zhihu.com/question/385083557/answer/1128108136