AI生成单元测试怎么验收？边界用例、断言质量与回归检查指南

AI可以快速补齐单元测试，但“生成了测试”不等于“测试有效”。验收的重点不是测试文件有多长，也不是覆盖率数字有多高，而是测试能否在代码行为错误时及时失败。编写前应先明确函数契约、输入约束、返回结果和异常规则，让测试依据业务要求检查实现，而不是照抄当前代码的写法。

先核对函数契约，再审查测试范围

对每个被测函数，先列出允许的输入、返回值、错误处理和不应改变的副作用。例如金额折扣函数需要明确零金额是否允许，折扣为零和达到上限时如何计算，负数或非数字参数是否应被拒绝。若这些规则没有写清楚，AI很容易根据函数内部条件生成测试，结果只是重复实现逻辑，无法独立验证需求。

验收时可按以下顺序检查场景：

• 正常输入：选择能够代表常见业务流程的数据，核对返回结果和必要的状态变化。
• 空值与缺省值：分别确认空字符串、空集合、空对象或未传参数的处理方式，不要把所有情况都混成一个用例。
• 非法输入：检查类型错误、格式错误、负数、超出范围的值，以及异常类型或错误码是否符合契约。
• 边界条件：覆盖零值、最小值、最大值、临界值，以及刚好低于或高于临界值的输入。

重点检查断言是否验证了业务结果

无效测试常见的表现是只断言函数没有抛错、返回值不为空，或只检查调用次数。这样的断言即使实现把金额算错、状态写错，测试也可能继续通过。应优先比较具体返回值、关键字段、异常类型和持久化后的业务状态；对于集合结果，还要确认数量、内容和顺序是否符合契约。

例如折扣函数的测试不应只写“调用成功”，而应验证零金额仍为零、临界折扣得到明确金额、非法折扣触发约定的错误。若结果涉及浮点计算，应采用项目约定的金额表示和比较方式，避免把精度问题误判为业务错误。同时检查断言对象是否真的是本次调用产生的结果，防止测试误用预先写死的同一实现逻辑。

隔离会让结果不稳定的依赖

单元测试应尽量只验证目标单元。网络请求、当前时间、随机数、文件系统、环境变量和真实数据库都可能让同一测试在不同时间或环境下得到不同结果。验收AI生成的测试时，要确认这些依赖是否被替换为可控的模拟对象、固定时钟、确定的随机种子或隔离的测试数据；同时检查模拟对象的行为是否与真实接口契约一致，避免“模拟得太宽松”而掩盖调用错误。

还要关注测试之间是否共享可变状态。一个测试留下的数据不应决定另一个测试的结果，测试顺序改变后也不应出现无关失败。对网络和外部服务的验证可以放在更合适的集成测试中，不要为了让单元测试通过而依赖真实线上资源。

运行测试，并进行故障注入检查

首先在干净环境运行生成的测试，确认测试本身能够被发现、执行和重复运行。随后不要只接受“全部通过”的结果，还应有意修改一处与需求相关的实现，例如把金额比较中的大于等于改成大于，或把折扣计算中的加法改成减法，再重新运行测试。若所有测试仍然通过，就说明现有断言或场景可能没有覆盖该行为，需要补充用例。

故障注入不要求随意破坏代码，而应针对每条关键业务规则设计小幅、可回退的错误。还可以逐个删除关键断言、替换返回值或改变异常处理，观察测试是否能失败。这个过程比单看覆盖率更能说明测试是否具有发现回归的能力。

覆盖率只能作为辅助信号

代码覆盖率可以提示哪些语句、分支或路径尚未执行，但它不能证明断言正确，也不能证明输入具有代表性。测试可能经过了每一行代码，却只检查“没有报错”；反过来，少量针对关键规则的测试也可能比大量重复用例更有价值。因此验收应同时记录场景清单、断言内容和故障注入结果，把覆盖率作为发现遗漏的线索，而不是质量结论。

最终可用一份简短清单复核：契约是否明确，正常与异常输入是否覆盖，边界两侧是否有用例，断言是否检查业务结果，外部依赖是否可控，测试是否能独立重复运行，以及有意引入错误后是否会失败。满足这些条件，AI生成的测试才更适合作为代码审查和持续回归的一部分。