文章目录 / 点击展开
AI 可以快速列出测试候选和样板代码，但它最容易生成“能运行、不能发现问题”的测试。正确流程不是追求文件数量，而是先说明契约，再生成测试矩阵，最后验证每个测试真的会在实现出错时失败。
第一步：提取函数契约
提供函数、类型定义、调用方和已有测试，让 AI 先回答输入范围、输出、错误行为、副作用和不变量。契约不清楚时，生成的断言通常只是对当前实现照抄。
分析以下函数的可观察契约，不要生成测试代码。
列出：正常输入、边界值、非法输入、错误类型、副作用、依赖和必须保持的不变量。
指出哪些行为能从代码确认，哪些需要产品或调用方补充。如果实现与业务约定冲突，应先确认预期，而不是让测试把错误行为永久固定下来。
第二步：建立测试矩阵
把用例按四组组织：主路径、边界值、异常输入和历史回归。每条用例写清输入、前置状态、期望结果和它防止的风险。
边界不只包括空值和最大值，还应考虑重复提交、顺序变化、时区、Unicode、浮点精度、权限差异、并发更新和依赖超时。只选择与函数职责相关的边界，避免机械堆用例。
第三步：分批生成测试代码
一次只生成一个行为组，并要求遵循仓库现有测试框架、命名、fixture 和 mock 方式。不要让模型发明不存在的 helper，也不要为了方便而过度 mock 被测逻辑本身。
根据已确认的测试矩阵，为“异常输入”这一组生成测试。
要求：使用仓库现有测试框架；每个测试只验证一个行为；断言业务结果或明确错误；禁止新增生产代码；列出需要的 fixture。生成后先运行单个测试文件，再运行受影响模块。测试失败时，先判断是实现缺陷、用例假设错误还是环境问题，不要让 AI 反复修改断言直到变绿。
第四步：验证测试的有效性
最简单的方法是临时破坏关键实现，确认对应测试会失败，再恢复代码。条件允许时使用变异测试，检查反转条件、删除分支或替换返回值后是否能被测试捕获。
覆盖率只能说明代码被执行，不能说明结果被正确验证。重点查看分支覆盖、关键业务路径和历史缺陷是否有回归用例。
第五步：控制脆弱测试
避免断言内部调用次数、私有方法和完整序列化快照，除非这些本身就是契约。测试应允许安全重构，同时能捕获用户可见行为变化。
时间、随机数、网络和全局状态应通过可控依赖隔离。对于并发和异步代码，要明确等待条件，不使用任意 sleep 掩盖竞态。
合并前检查清单
- 每个测试是否对应一条明确契约或历史风险。
- 是否包含边界、异常和权限场景。
- 断言是否验证结果，而不是只验证执行过程。
- mock 是否只隔离外部依赖，没有复制生产逻辑。
- 临时破坏实现时，关键测试是否会失败。
- 单测和相关集成测试是否都通过。
- 测试名称能否说明条件和预期行为。
常见问题
AI 能自动达到 100% 覆盖率吗
可以生成覆盖代码行的测试，但 100% 覆盖率不等于高质量。优先覆盖关键分支和业务风险，不要为了数字加入没有有效断言的用例。
旧代码没有文档怎么办
先从调用方、错误处理和现有行为提取候选契约，再让业务或维护者确认。不要把当前实现自动视为正确规范。
测试生成后维护成本会不会更高
会，如果测试依赖内部实现或重复过多。使用参数化、共享 fixture 和面向行为的断言，可以控制维护成本。
发现生产缺陷时，可配合 AI 接口日志分析 建立复现步骤，再将该场景固化为回归测试。