AI时代，代码审查正在"内卷"：为什么你仍然需要白盒测试

你有没有发现，程序员最近分成了两派？

一派彻底拥抱了 AI。写代码？不存在的，全靠 Copilot 和 Cursor 生成。他们管这叫"Vibe Coding"——氛围编程，字面意思就是：感觉对了就行，别细究。另一派则还在坚持逐行 Review，用他们的话说，"AI 写的代码，不仔细看一遍，根本不知道里面埋了什么雷"。

有意思的是，这两派吵来吵去，却都在回避一个本质问题：不管代码是人写的还是 AI 写的，它最终跑在同一个 CPU 上，出问题了都是你的系统崩。

所以问题不是"要不要审查"，而是"审什么"。

今天聊一个被严重低估的概念——白盒测试。别急着划走，它不是什么老古董。恰恰相反，在 AI 生成代码成潮的今天，理解它比任何时候都重要。

从"外面看"到"里面看"

黑盒测试我们都熟：给输入，看输出，不关心里面怎么实现的。测试淘宝的搜索功能，不管搜索代码怎么写的，搜出来结果对就行。

这是大多数团队现在做的事。AI 生成的代码？不就是多了一个"自动化的黑盒"吗？

问题是，有些 Bug 藏在"里面"，从外面根本看不见。

举一个真实的场景。某团队的 AI 生成了一段订单处理逻辑：

if (order.status == "pending" and order.amount > 0):
    process_payment(order)

表面看，逻辑清晰，没问题。但测试人员跑了一遍"pending"状态的订单，都能通过。

然后线上崩了。

原因是：当 order.amount 是 null（数据库里允许为空）时，null > 0 在 Python 里既不是 True 也不是 False，是个运行时异常。代码从"外面看"完全正常，但在 CPU 内部有一条隐秘的路径正在等待着炸掉你的服务。

这就是白盒测试的价值——它不看输入输出，它看路径。

六层覆盖，你在第几层？

白盒测试有一套成熟的"透视"体系，叫做覆盖标准。从低到高，一共六层。

第一层：语句覆盖。 每行代码至少跑一次。这是最低要求，好比去医院体检，只量个体温就说"你很健康"。体温正常，不代表你没病。

第二层：判定覆盖（分支覆盖）。 每个判断的真假分支都跑一次。上面的例子，null > 0 这个判定分支没有被覆盖，所以 Bug 溜进去了。

第三层：条件覆盖。 判断里的每个条件都要分别取到真和假。上面的例子有 order.status == "pending" 和 order.amount > 0 两个条件，语句覆盖没有测到 amount 为 null 的情况，条件覆盖就会专门测这两种。

第四层：判定/条件覆盖。 同时满足判定覆盖和条件覆盖。简单说就是：每个分支跑一次，每个条件的真假也跑一次。要求高了一截。

第五层：条件组合覆盖。 每个判定里条件的各种组合都出现一次。如果有 if (a and b)，就要测 a真b真、a真b假、a假b真、a假b假 四种。覆盖程度很高，但测试用例数量也爆炸了。

第六层：路径覆盖。 所有可能的执行路径都跑一次。这是覆盖的终点，也是最难实现的目标——随着代码分支增多，路径数量呈指数级增长。一个只有 10 个判断的方法，可能的路径数就有 1024 条。