4. 逻辑盲区（下）：组合逻辑爆炸、隐式依赖关系、死代码与不可达路径

好，咱们接着聊逻辑盲区。上一章我们讲了条件覆盖、判定覆盖这些基础问题。这一章要聊的，才是真正让很多测试团队头疼的硬骨头。

我个人习惯把这类问题分成三类：组合爆炸、隐式依赖、以及死代码。这三类问题，说白了就是「测不全」、「想不到」、「白费劲」。我一个个来讲。

先问一个问题：一个系统有10个开关，每个开关有开/关两种状态。你打算怎么测？

答案是2的10次方，1024种组合。如果增加到20个开关呢？1048576种。这就是组合爆炸。

我在项目中遇到过最典型的场景——一个权限管理系统。用户角色、资源类型、操作权限、时间限制、IP白名单……五个维度，每个维度3-5个取值。你算算，全组合测试需要多少用例？

嗯，答案是几千甚至上万条。而项目排期只给了3天。

  核心问题： 全组合测试在工程上不可行。我们需要的是「聪明地测」，而不是「全部测」。

怎么聪明地测？正交实验法是个好工具。它的核心思想是：任意两个因素的任意两个取值，至少被覆盖一次。

举个例子。假设有3个因素：

全组合是3×3×3=27种。但用正交表L9(3^3)，只需要9种组合就能覆盖所有两两组合。

你看，27种降到了9种。效率提升了3倍。我建议你在做多参数组合测试时，优先考虑正交表。网上有现成的正交表生成工具，别自己手算。

小技巧： 如果因素数量或取值数量不匹配标准正交表，可以用「混合正交表」或「成对组合测试（Pairwise）」工具。我常用的是PICT，微软出的，免费好用。

组合爆炸是「测不过来」的问题。隐式依赖是「想不到」的问题。

什么叫隐式依赖？就是代码里没有显式写出来的关联关系。比如：

我曾经踩过一个坑。一个电商系统的订单状态机，看起来每个状态转换都是独立的。但测试时发现：当订单处于「已支付」状态时，如果用户同时发起「退款申请」和「修改收货地址」，系统会死锁。

为什么？因为这两个操作都修改了订单表的同一行记录，但加锁顺序不同。一个先锁订单再锁库存，另一个先锁库存再锁订单。死锁就这么产生了。

注意： 隐式依赖关系很难通过代码审查发现。我建议的做法是：
1. 画出系统的数据流图，标注所有共享资源
2. 对每个共享资源，列出所有可能的并发操作组合
3. 针对这些组合设计并发测试用例

说实话，没有银弹。但我有几个经验：

嗯，这里要注意：隐式依赖往往在单线程测试中表现正常，一上并发就出问题。所以并发测试不是可选项，是必选项。

死代码，就是永远不会被执行的代码。不可达路径，就是任何输入都无法触发的分支。

你想想看，如果你花了一整天给一段死代码写测试用例，结果发现它根本不会被执行——是不是很崩溃？

我在项目中遇到过最离谱的一次：一个if-else分支，条件判断写的是 if (x > 5 && x < 3)。你仔细看看，这个条件永远为假。因为没有任何数能同时大于5且小于3。所以else分支永远被执行，if分支是死代码。

// 死代码示例
if (x > 5 && x < 3) {
    // 这段代码永远不会被执行
    System.out.println("这行永远不会打印");
} else {
    System.out.println("这行永远被执行");
}

这种错误看起来低级，但在大型项目中非常常见。尤其是经过多次重构后，一些条件判断的逻辑被改来改去，最后变成了逻辑矛盾。

我建议用以下方法：

  一个经验： 如果一段代码超过3个月没有被任何测试覆盖到，而且没有人能说清楚它的作用——大概率是死代码。我建议直接删除，或者加个日志标记，等下次重构时清理。

下面这张图，是我对本章内容的总结。你可以把它当作一个检查清单，做测试设计时对照着看。

好了，这一章的内容就这些。组合爆炸、隐式依赖、死代码——这三个问题，说白了就是测试设计中的「三座大山」。翻过它们，你的测试覆盖率才能真正做到「有效覆盖」。

可可精品资料库