当一个编程 Agent 接到补测试任务，它往往能很快交出一份看起来很完整的结果：测试文件新增了，断言写了，CI 通过了，覆盖率也上涨了。
但线上问题如果藏在异步重试、权限切换、跨服务时序或脏数据回放里，这些新增测试未必触及真正失效的路径。
这不是 AI 不会写测试，而是我们太早把问题翻译成了框架熟悉的题目：为一个方法补单测，为一条分支补断言，把覆盖率推过阈值。AI 会努力完成这个题目，却未必会追问：题目本身是否漏掉了最容易失效的路径。
所以，AI 时代不是不需要测试框架，而是不该让测试框架先替 AI 定义问题。框架应该负责收敛已被证实的结论，AI 则应该先有空间去寻找尚未命名的失败路径。
测试全绿只说明当前测试预言被满足，不等于系统一定正确。它能证明已经写下来的规则，却不会自动发现尚未被表达的风险。
一个常见场景是：代码变更涉及支付状态更新。Agent 很容易为成功、失败、异常三条返回路径补上单元测试，Mock 外部依赖，再验证返回值和调用次数。可真正的风险可能在另一个维度：重复回调会不会重复入账，超时回调晚于成功回调时状态会不会回退，幂等键跨租户会不会冲突，账务与通知的顺序能不能被重放。
前一组测试没有错，只是它们验证了一个更小的问题。若任务入口就是补单测，AI 很可能停在方法边界；若入口是寻找变更可能破坏的业务不变量，它才会扩展到状态、时间、数据和依赖关系。
测试框架擅长让已知路径稳定重复。探索未知路径，需要另一套能力。
测试框架是工程经验的压缩包。目录结构、夹具、Mock、断言、并行策略、报告和 CI 门禁，都在回答同一个问题：当团队已经知道要验证什么时，怎样以低成本、可重复的方式持续验证。
这正是框架最有价值的地方。它让一次问题修复在几个月后仍能被复现和拦截，也让团队不用每次从零解释测试怎么跑。
问题发生在探索之前。把测试类、Mock 交互和覆盖率报表当成唯一表达，等于提前收窄了 AI 的搜索空间。它会偏向验证局部实现，而不主动构造状态机边界、时间序列反例、权限组合和数据不变量。
框架可以是探索时可调用的工具，但不应成为探索时唯一的思考地图。这里的后置，指的是认知顺序，不是禁用 JUnit、pytest、Mock 服务或测试运行器。
AI 需要的不是一组更长的测试模板，而是测试活动最基础的四种能力。
| 能力 | AI 要完成的工作 | 产出 |
|---|---|---|
| 上下文理解 | 读懂调用链、数据模型、权限规则、配置和历史故障 | 受影响路径与风险假设 |
| 执行与观测 | 运行变体、采集日志、比对 Trace、观察状态转移 | 可解释的异常信号 |
| 假设与反例构造 | 改变输入边界、事件顺序、超时、重试和依赖故障 | 最小反例与复现步骤 |
| 测试预言构造 | 用业务不变量、契约、差分结果或参考实现判断对错 | 可验证的正确性标准 |
测试预言就是判断系统行为是否正确的规则。它不是多写几条断言，而是先说清哪条业务规则不能被系统突破。先把正确性从实现细节中抽出来，测试才有机会识别实现看似正常、业务结果却已经偏离的情况。
例如，支付成功后余额只能增加一次，这是一条业务不变量。对同一请求重复回调不改变最终状态，也是一条业务不变量。确认了这些规则以后，团队才决定用单测、契约测试、集成测试、回放用例还是线上监控去守住它们。
更适合 AI 的流程可以分成三层：自由探测、证据收敛、回归守护。
这一层的目标是扩大问题空间。Agent 可以在受控沙箱里读取代码、接口定义、历史缺陷和脱敏 Trace，主动改变输入、顺序、时间以及故障注入条件。
此时最重要的产物不是一段马上合入的测试代码，而是一份证据包：问题假设、最小复现步骤、预期与实际差异、关键日志、随机种子或请求样本，以及尚未排除的替代解释。证据包让一次探索能够被他人复现和挑战，而不是把偶然失败直接包装成测试结论。
explore/
hypothesis.md
reproduce.md
traces/
counterexamples/
没有可重复的复现，不进入下一层。不能说明预言来自业务规则、对照结果还是历史行为，也不进入 CI。
这一层要确认故障是否真实、是否稳定、是否值得成为长期测试资产。团队需要检查复现能否重复，预言是否准确，失败是否来自环境噪声，测试是否过度绑定当前实现。
必要时，可以用差分测试、属性测试、变异测试或真实依赖回放挑战已有结论。收敛不是让一个失败样本偶然通过，而是回答三个问题：故障是否稳定，预言是否正确，维护成本是否值得长期承担。
OpenAI 在 2026 年对 138 个 SWE-bench Verified 难例的人工审计中发现，59.4% 存在实质性的测试设计或问题描述缺陷，其中包括过窄和过宽的测试。它不是生产测试的行业比例，却提醒我们：当 AI 很快就能满足测试时，测试预言本身是否准确，会成为更明显的瓶颈。
只有经过收敛的结论，才进入正式框架和 CI。这里才需要命名、分层、夹具管理、隔离策略、重试边界、报告、并行执行和质量门禁。
框架在这一层非常强大。它把一次问题发现变成团队日后不必重新思考的保护网。
一个稳定的回归测试，不只表达某行代码该怎么跑。它还表达了一条团队共同认可的事实：当这些前置条件成立时，系统必须保持这个行为。
因此，框架更像可执行的团队记忆。它适合保存已经验证过的知识，不适合过早规定 AI 只能如何寻找知识。
一段能运行的测试代码不等于回归资产。只有风险、预言、依赖边界和稳定性都能说明白，它才值得被团队长期维护。
Meta 的 TestGen-LLM 工业案例很能说明这个分工。在 Instagram Reels 与 Stories 的评估中，75% 的生成候选测试能够构建，57% 能稳定通过，25% 能提高覆盖率。这个案例不能代表所有语言、模型或团队，但它说明了一个事实：模型可以广泛提出候选，系统必须严格筛选哪些候选值得进入回归资产。
Meta 的另一项基于运行观察的测试生成工作，将 518 个测试纳入生产，并让这些测试在 CI 中执行超过 960 万次。它的输入来自已有的可靠端到端测试。自动化确实能扩大测试资产，但可信的规模仍依赖可观测、可重放、可集成的执行地基。
覆盖率依然有用，但它只是过程指标。它告诉我们代码是否被经过，不能证明断言足以识别错误。
覆盖率回答的是代码有没有走过；变异得分更接近断言能否识别被引入的错误。二者都不能单独证明业务正确。
一项 2025 年的 LLM 单元测试研究给出了警示案例：某些测试套件达到100% 覆盖率，变异得分却只有 4%。这不是说所有高覆盖测试都无效，而是说可见指标很容易被做满，真正的预言能力却可能没有同步提高。
对 AI 生成或协助生成的测试，团队更值得持续观察这些结果指标：
框架后置，不等于允许 AI 无约束运行。需要前置的是安全边界，不该过早固定的是答案模板；这两类约束解决的不是同一个问题。
| 应前置的安全边界 | 不应过早固化的思考模板 |
|---|---|
| 脱敏数据、只读副本、密钥隔离、命令白名单、时长与成本预算 | 只能写单测、必须先 Mock、只能补现有目录、只看覆盖率阈值 |
| 禁止生产写入、限制外部调用、保留执行审计 | 预设故障一定发生在哪个方法、预设哪个断言才算答案 |
前者保护系统和资源，应该严格执行。后者会限制问题发现，应该根据证据按需引入。
一旦证据表明单测就是最佳载体，就应该果断使用 JUnit、pytest 或团队现有框架。一旦风险跨越服务边界，就不该为了形式上的统一，硬把它压回一组 Mock 里。
不必一次性重写测试体系。可以先从高风险变更或 AI 参与较多的模块开始。
这样做的关键不是多建一套流程，而是让探索和守护不再互相伤害。AI 可以在前面大胆地找问题，框架则在后面严谨地留下答案。
AI 时代，测试框架没有过时。它只是从 AI 的思考边界，变成了团队可信知识的边界。
先让 AI 去寻找我们尚未命名的失败路径，再让框架把被证实的结论变成可重复、可审查、可回归的保护网。这样的测试体系，既不会把 AI 困在旧模板里，也不会把团队暴露在无证据的自动化里。
测试框架最好的位置，不是在探索的起点，而是在事实被发现之后。
相关阅读
##### FunTester 名片｜万粉千文，百无一用