我把 AI 软件测试分成了四代

QUOTE

它们都叫 AI 测试，但交付的层级差了三档。

事情是这样的。

AI 软件测试，现在究竟走到第几代了。

这个问题我一直没太想好怎么答。因为打开市面上任何一个 AI 测试工具的官网，你看到的词都长得差不多，智能、高效、自动化，一个个都说自己端到端、零人工。

但它们真正交到你手里的东西，差得离谱。

有的就是个随叫随到的副驾，你贴一段需求进去，它帮你补几个测试点，剩下的还得你自己来。有的已经能批量给你吐用例、吐脚本、吐测试数据了，但吐完就撒手不管，能不能跑起来你自己看。有的能自己钻进系统里跑任务，失败了还会重试。还有极少数，琢磨的压根不是这次怎么测，而是怎么让业务约束在每次代码改完之后，都重新受一遍检验。

都叫 AI 测试，交付的层级差了三档。

如果你只用生成了多少条用例、省了多少编写时间来判断，那很容易把产出速度，当成验证能力。

这篇，我试着给它一个答案。

我给自己划了一条线，不看 AI 会多少花哨动作，只看它已经在验证闭环里，承担了哪一段责任。

顺着这条线捋下来，现在的 AI 软件测试，大概能分成四代。

AI Copilot，Test Generator，Agentic Testing，Continuous Verification。

从左边走到右边，AI 在验证这件事上站的位置，越来越靠里。

先给个结论，一句话一代。

第一代 AI Copilot，只出主意，判断权还在人手里。

第二代 Test Generator，开始批量生产测试资产，交付物是用例、脚本和数据。

第三代 Agentic Testing，接到的是一整个任务，自己跑流程、追结果。

第四代 Continuous Verification，维护的是一套持续生效的验证证据。

真正拉开四代差距的，是 AI 接管了验证闭环里的哪一段责任。活干多干少，反而是其次。

得说明一句，这是我自己的一套划分，不是行业标准，更不是按产品发布时间排的榜单。这四种形态会长久共存，同一个团队里的不同系统，也可能各自停在不同的阶段。

我用代这个字，只想说清楚一件事，每往前一步，AI 接手的那段责任，都更关键一点。

本文看点

第一代最常见，也最容易上手，就是把 AI 当成一个随叫随到的 Copilot。

你把需求、接口定义、或者一段代码贴给模型，让它补测试点，解释逻辑，顺手生成几段单元测试。然后呢，人复制，人修改，人执行。

GitHub Copilot 的官方文档里，生成单元测试、集成测试、端到端测试，都归在这一类。

它确实有用。对着空白页发愣的时候，它能很快给你搭个骨架出来。碰到你熟悉的功能，它还会提醒你补上空值、边界、异常分支。有点像身边多了个反应特别快的实习生。

但方向盘始终在人手里。

上下文是人挑的，问题是人问的，结果是人的手搬进工程的，数据和环境是人备的，最后到底对不对，也是人说了算。

就拿这次批量扣款的改造来说。AI 能提醒我测超时、测重试、测补偿。但材料里要是没写清「首次扣款成功、回调失败」这个状态，那还得我自己追问一句，第二次重试会不会重复扣款。

输入的材料漏掉一个关键约束，AI 就会沿着这个缺口，一直往下写 = =

所以第一代只解决了更快想到、更快写出来。至于这些测试能不能稳定跑起来，能不能真发现缺陷，它一个都没回答。

第二代就不一样了，它开始走流水线。

系统读需求，读代码，读接口定义，也读你已有的用例和代码变更，然后批量往外吐用例、吐脚本、吐测试数据。吐出来的东西也不是直接用，得过一遍编译、执行、覆盖率、稳定性这些规则，明显不能用的直接筛掉。

人的活也跟着变了。以前是逐条从零写，现在变成准备上下文、定生成规则、评审剩下的资产。

还是拿批量扣款来说。第二代流水线能一口气生成正常扣款、回调失败、重复请求、补偿触发好几类用例，再把跑不起来的脚本筛掉。

Meta 有个叫 TestGen-LLM 的东西，是挺具体的一个例子。它不把模型吐出来的东西直接当测试，中间要过构建、稳定执行、新增覆盖这几道过滤。

这几个数只属于论文里那个特定评估，不能当成所有企业测试系统的通用成功率。但它让我注意到一件事，生成之后，还有一层筛选成本。

从模型生成成功，到得到一条值得留下的测试，中间隔着一整套工程过滤。没有这套机制，批量生成只会更快地制造评审负担。

第二代的提升，主要在规模和工程化上。它盯的还是测试资产。它能交一批脚本出来，但它自己进不了复杂环境，构造不了跨系统状态，触发不了异步异常，更追不到数据库、消息和账务结果里去做判断。

「如果最后交出来的，还是一份用例表，或者一组等着别人执行的脚本，那一次生成再多，说到底也还是个 Generator。」

第三代真正变的，是任务形式。

人不再一步步指挥 AI 怎么写，改成丢一个目标过去。去探索这次改动，规划测试，准备数据，执行关键流程，失败了接着处理，最后留下可复现的结果。

Agent 看着环境反馈，决定下一步调什么工具。它不会生成完就收工，而是在观察、行动、再观察这个循环里往前推。

Playwright Test Agents 就把这种分工摆得很清楚。Planner 探索应用、形成测试计划，Generator 把计划转成可执行测试，Healer 在失败之后重放步骤、翻页面、尝试修复。这三个可以单独用，也能串成一条循环。

不过得提醒一句，这是网页测试的能力示例。换成批量扣款，还得受控地准备账务数据、控制故障注入、访问交易和流水结果，不能直接照搬网页 Agent 那套操作。

到这一步，测试的基本单位，从一条用例，变成了一项验证任务。

假设某个版本改了批量扣款的规则，同时加了失败重试和补偿。

第二代系统能生成正常扣款、超时重试、重复请求、补偿成功这些脚本。第三代 Agent 得真把任务跑起来。准备待扣款数据，制造一次短暂的下游失败，看重试有没有发生，查最终交易状态，再回头核对扣款记录、补偿记录、账务流水。

很多问题，只有真进到那个状态里，才会冒出来。页面会变，接口之间有依赖，消息会延迟，失败之后还会长出新分支。

Agent 值钱的地方，是它能顺着这些反馈，继续往下走。

能把流程跑完，不等于知道系统对不对。

Agent 要是只盯着页面上那个「处理成功」，后台已经重复扣款了，它根本看不见。要是预期结果直接从当前代码里取，那测试和实现，就可能在同一个错误假设上达成一致。最麻烦的是自动修复，它可能把业务行为的变化，误当成脚本漂移，然后啪一下，把一次本该暴露的失败，重新修绿了。

页面显示处理成功，账上扣了两次。。。

到了第三代，执行已经不是唯一的瓶颈。真正开始稀缺的，是 Oracle，你到底拿什么，来判断对错。

第四代目前更像一个正在成形的方向。我把它叫做 Continuous Verification。说它是第四代，其实带着点预测的意思，我自己也还没见过谁完整跑通。

这里的「持续」，跟把现有用例每天多跑几遍，是两回事，也不是再加一个会执行的 Agent。

它指的是，验证机制开始和代码生成一起工作。需求意图被整理成可执行的 Contract、Property、Invariant。每次代码变更，都会触发跟风险相关的测试、变异、反例搜索。上线之后，回放、影子流量、灰度结果、运行时监控继续盯着这些约束。收集到的证据，再回流给 Coding Agent、发布门禁、和做决策的人。

2026 年有人提出了 VibeContract，是个挺有意思的研究设想。它主张把自然语言意图拆成任务级契约，明确输入、输出、约束、行为属性，并且保持任务、契约、生成代码之间的追踪关系。这些契约接着被用到测试、运行时验证和调试里。质量保障跟着代码生成一起发生，不用等代码写完，再补一遍。

Anthropic 也有一个把 Claude Agent 和 Property-Based Testing 揉在一起的研究，展示了另一块正在成形的能力。Agent 去读类型、文档、函数名、调用关系，提出代码应该满足的 Property，再借助 Hypothesis 生成输入、找反例。

回到批量扣款。第四代不太在意那几条脚本本身跑没跑通，它盯的，是下面这些约束能不能一直成立。

有了这些独立于当前实现的约束，系统还能主动搞点破坏。把幂等判断删掉，把成功状态提前更新，重复发回调，改补偿顺序，看看现有测试能不能把这些错误拦住。上线之后，同一批约束，还能接着核对真实运行信号。

面对这个重试场景，证据里还应该有业务单 ID、两次处理的流水、回调与重试记录、幂等规则版本，而且都能追溯回这次变更。

到这一步，测试交付的东西变了。脚本和报告只是副产品。真正要交出来的，是一条能回答「为什么允许发布」的证据链。

这也是第三代和第四代最容易混的地方。第三代盯着任务能不能自己完成，第四代追问的是，结论能不能由独立、可追溯、持续更新的证据撑起来。

聊到这儿，其实可以拉一张清单，同一个需求，四代系统最后分别留下什么。

你发现没有，从第一代走到第四代，表面上是 AI 在越干越多，但真正变的，是交付物。

用例数量这个东西，只能说明前两代的一部分价值。到了第三代，要看任务是不是真完成了。到了第四代，更要看那个通过的结论背后，有没有可靠证据。

所以真的别急着给自己的平台，贴上第四代的标签。

四代框架，不是让你明天就往系统里堆 Agent、堆 Property、堆 Mutation、堆运行时验证。底层条件没准备好，系统越自主，制造的噪声反而越多。

需求材料长期自相矛盾，测试环境又没法稳定构造状态，关键结果没有观测入口，历史缺陷只躺在复盘文档里，那 Agent 就算把流程跑完，也拿不出可信的结论。

想判断一个团队走到哪一代，不用先看产品宣传。问自己五个问题就够了。

回答到哪，能力大概就到哪。

这段建议截图，发给你们团队一起对一对。

真要想往前推，也别一上来就建完整平台。可以先挑一个高风险规则，把它写成可执行约束，补齐状态观测，故意注入一个过去发生过的错误，再看现有测试能不能发现它。等这条证据链跑通，再往下一条扩。

这比一上来就做一个全自主测试 Agent，更容易验证你的投入，到底有没有换来质量提升。

这四代走下来，最容易被自动化的是内容生产和重复操作。最难交出去的，是约束选择和证据判断。

到了 Agent 阶段，人得把话说清楚，哪些风险值得追，哪些状态必须构造，可靠的结果去哪儿拿。到了 Continuous Verification 阶段，测试人员还得把一次生产事故，提炼成可执行的 Property、Contract、变异规则，让它去保护后面同类的系统。

测试这份工作，会从维护一批用例，慢慢转向设计一套验证机制。

前者关心这一次怎么测。后者关心以后每一次变化，系统能不能知道该验证什么，怎么挑战错误，又拿什么证明通过。

说到这儿，我反而更确定一件事。AI 测试接下来的竞争，不会只是比谁执行得快。

当生成和操作都越来越便宜，真正稀缺的，是可信信号。

一个失败，到底是脚本问题、环境问题，还是产品缺陷。一个通过，到底表示流程跑完了，还是关键业务约束，确实没被破坏。

「AI 测试真正的瓶颈，为什么不是执行速度，而是可信信号。」

我们从小就被教一句话，眼见为实。但在系统里，眼见往往最不实。页面告诉你成功了，账上可能已经扣了两次。流程跑完了，业务约束可能早就被破坏得一干二净。

所以第四代盯的，从来不是那几条脚本。它盯的是，当所有人都说没问题的时候，我们到底拿什么，敢说一句，没问题。

REFERENCE

文里提到的几个东西，出处放这儿，感兴趣的自己去看。

GitHub Copilot 官方文档 · Writing tests with GitHub Copilot

Automated Unit Test Improvement using Large Language Models at Meta（TestGen-LLM）

Playwright Test Agents 官方文档

Anthropic · Finding bugs with Claude and property-based testing

VibeContract · The Missing Quality Assurance Piece in Vibe Coding