白盒测试的六种方法

去年帮一个团队排查支付回调的白盒bug，代码逻辑看起来没问题，测试单元测试也全绿。白盒结果一上预发环境就炸——问题出在一个嵌套了三层的测试if-else里，某个边界条件被漏掉了。白盒这就是测试白盒测试要解决的事：你盯着代码内部结构看，而不是白盒只戳接口看它返回什么。

白盒测试的测试方法不止一种，但常用的白盒有六种。它们各有各的测试脾气，用对了能挖出不同层次的白盒坑。

语句覆盖：最基础，测试也最容易糊弄人

语句覆盖的白盒目标很简单——让代码里每一行都跑一遍。听起来挺全，测试但它有个致命弱点：只测“跑没跑到”，白盒不测“跑对没跑对”。比如 if (x > 0 && y > 0)，你只要让x和y都为正就能覆盖这一行，但x为负、y为正的情况根本没碰。语句覆盖能给你一个“覆盖率90%”的漂亮数字，但剩下的10%往往藏着最恶心的bug。

判定覆盖：比语句覆盖多走一步

判定覆盖要求每个判断的真假分支都走到。刚才那个例子，你得设计两组数据：一组让条件为真，一组让它为假。这比语句覆盖强，但还不够。如果判断条件是复合的——比如 if (a || b)——判定覆盖只要求整个表达式真一次假一次，至于a和b各自有没有独立影响结果，它不管。

条件覆盖：盯着每个原子条件

条件覆盖拆得更细，它要求每个原子条件（a、b这种）都取到真和假。还是 if (a || b)，你得让a真b假、a假b真、a真b真、a假b假——至少覆盖到a和b各自的两面。但问题来了：条件覆盖满足了，判定结果可能反而没覆盖全。比如上面四种组合里，判定为假的情况（a假b假）你测了，但判定为真只测了一种，逻辑路径的覆盖未必完整。

判定/条件覆盖：试图两头兼顾

这个方法同时满足判定覆盖和条件覆盖。设计用例时，既让每个判断的真假分支都走到，又让每个原子条件的真假都取到。听起来完美，但实际用起来会发现用例数量膨胀得很快。一个五条件的判断，组合数直接上到32种。多数团队到这一步就开始偷懒了，挑几条“看起来重要”的路径测，剩下的靠运气。

条件组合覆盖：穷举所有原子条件组合

条件组合覆盖要求每个判断中所有原子条件的真假组合都至少出现一次。还是 a || b，四种组合全测。这能揪出条件之间相互干扰的bug——比如某个条件在特定组合下才触发异常。代价是用例数量指数级增长。我见过一个风控规则判断有七个条件，组合覆盖的用例写了整整两页Excel，跑一次要十几分钟。值不值？看代码的关键程度。

路径覆盖：最彻底，也最不现实

路径覆盖要求覆盖程序中所有可能的执行路径。循环体跑零次、一次、多次，嵌套判断的每条分支组合，全都要走到。理论上这是最强的覆盖标准，实际上几乎不可能做到——一个带循环的函数，路径数量可能是无限的。所以实践中通常只对关键模块做有限路径覆盖，比如限定循环次数为0、1、2，再配合其他方法补漏。

这六种方法没有谁替代谁的关系。语句覆盖给你底线，条件组合覆盖给你信心，路径覆盖给你理论上的完备性——但你的时间和机器资源是有限的。我的习惯是：核心交易链路用条件组合覆盖，普通业务逻辑用判定/条件覆盖兜底，工具类函数语句覆盖加边界值就够了。覆盖率数字是给人看的，真正管用的是你设计用例时脑子里那根弦——有没有哪个条件我还没让它翻过面？