很多团队提到 AI 测试，第一反应是让大模型写测试用例。这是最容易看到的能力，但如果讨论止步于生成代码，就会高估它的作用，也会低估验证成本。
一篇近期的系统性综述按照 PRISMA 方法筛选了 35 篇有实证结果的研究，覆盖测试生成、自愈自动化、视觉测试、缺陷预测、复杂系统验证和 AI 模型验证等方向。把这些研究放在一起看，会得到一个更有价值的结论：AI 正在把软件测试从出了问题再定位和修脚本的被动活动，变成持续校验自身输出的质量闭环。
这不是测试自动化终于可以不要人的故事。AI 更适合接管重复性的候选生成和风险筛选，让测试工程师把精力放回质量策略、业务断言和风险控制。
传统测试自动化解决了重复执行的问题，却没有真正解决维护问题。
测试用例仍要人工设计；页面结构稍有调整，XPath 或 CSS Selector 就可能失效；在高频 CI/CD 流水线中，每次提交都跑一遍全量回归，成本和反馈时间又难以接受。于是，自动化测试常常陷入一个尴尬循环：脚本越来越多，维护脚本本身也越来越像一项独立工作。
AI 带来的变化，可以概括为四种能力：生成、预测、恢复和验证。
这意味着测试不再只是在发布前找 bug。研发过程中需要持续判断：这次变化最可能影响哪里，哪些验证最值得先做，自动化给出的结论是否仍值得信任。
LLM 生成测试用例之所以受关注，是因为它直观地减少了测试设计的起步成本。它可以把自然语言需求转成候选场景，也可以结合代码上下文生成单元测试骨架。对于边界组合很多、准备数据繁琐的场景，AI 还可以生成合成测试数据，在不直接使用敏感生产数据的前提下，补充人工容易遗漏的异常输入。
不过，生成得出来与测试是对的是两回事。模型可能写出能编译却不符合业务规则的断言，也可能遗漏关键前置条件。因此，生成结果应当经过编译、执行、断言检查、静态分析和人工复核，而不是直接进入主干测试套件。
相比生成，更能改变维护成本的是自愈测试，因为它直接面对自动化长期运行时最常见的失效方式。
一个典型场景是：业务功能没有变化，但前端重构后页面元素的定位路径变了，原本稳定的 Selenium 脚本立刻失败。自愈机制会根据新的 DOM 结构、元素文本、属性或页面语义，寻找候选定位器，让测试继续执行。类似思路也可以延伸到接口测试：当 API 响应结构或安全校验规则演进时，系统协助识别变化并提出修复建议。
这里必须保留一道工程边界：恢复执行不等于恢复正确。特别是涉及资金、权限、合规和关键交易路径时，AI 可以给出候选定位或候选修复，但不能自行判定业务验证已经通过。可审计记录、人工确认和可回滚机制，仍然是自愈测试进入生产的前提。
在 CI/CD 环境中，最稀缺的资源通常不是测试用例数量，而是反馈时间。一次提交触发全量回归，既慢又浪费资源；只跑少量冒烟用例，又可能漏掉高风险变化。
缺陷预测和测试优先级排序，正是在解决这个矛盾。模型可以学习历史执行结果、模块复杂度、代码改动范围和提交模式，给出风险排序：哪些模块更可能出错，哪些用例更值得优先执行。团队不必等到所有测试结束，便能更早获得关键路径的风险反馈。
这篇综述纳入的部分研究报告，预测模型的准确率可超过 85% 到 90%；生成式测试研究还报告了覆盖率提升和初始用例编写时间缩短。这些数据说明方向具有潜力，却不应直接当作每个团队都能获得的生产承诺。研究的项目、数据集、指标和对比基线并不相同，模型在一个项目中有效，并不必然能迁移到另一个业务领域。
另一类容易被忽视的能力是视觉测试。DOM 测试可以判断按钮是否被点击，却未必发现文字重叠、元素遮挡、间距错位或不同分辨率下的布局崩坏。计算机视觉可以从最终渲染画面发现这类缺陷；强化学习 Agent 则进一步尝试依据屏幕内容探索界面，而不完全依赖特定平台的 DOM 定位器。
视觉理解尤其适合跨端界面、动态 GUI 或无稳定 DOM 的场景。但它的代价也很现实：截图比对容易受到非功能性变化干扰，强化学习和视觉模型还需要更高的训练与运行成本。是否采用，取决于缺陷风险能否覆盖这些额外投入。
测试正在面对一个新的事实：越来越多的软件把模型作为功能的一部分。
聊天机器人、推荐系统、ML API 和大模型应用的输出不再总是固定的输入 A 得到输出 B。如果仍然只依赖传统断言，测试很容易陷入两个极端：要么因为输出存在合理差异而频繁误报，要么因为断言过宽而放过真正危险的偏差。
因此，AI 驱动测试的另一面是测试 AI 本身。研究中已经出现了多种方向：用搜索式和变异测试发现深度学习框架缺陷，评估模型量化后是否损失可靠性，验证接入 ML API 的传统软件是否会被非确定性输出击穿，以及在机器人、云平台、量子软件等复杂环境中处理物理交互、分布式状态和执行噪声。
对业务团队而言，最重要的不是立刻采用这些前沿技术，而是先承认测试标准需要变化。除了功能是否通过，还要定义模型输出允许的范围、极端输入下的兜底行为、数据隐私边界、人工接管条件，以及异常结果出现后的追溯方式。没有这些边界，测试通过也无法说明模型接入后的系统值得信任。
AI 测试现在仍有四个绕不过去的问题：模型幻觉、外部 API 的延迟和成本、视觉与强化学习的算力开销，以及缺少统一的效果评价标准。更现实的挑战是，很多研究在开源项目或受控实验环境中验证；面对文档缺失、技术债重、数据敏感的大型遗留系统，效果还需要更充分的工业验证。
因此，团队不必从全自动测试平台开始。更稳妥的路线是分三步推进。
第一步，选择低风险、高重复、规则清晰的任务试点，例如生成测试数据、生成单元测试草稿、推荐回归用例，或辅助修复非核心页面的脆弱定位器。
第二步，把 AI 输出接入既有质量控制：编译、执行、断言、静态分析、审计记录、人工审批与一键回滚，缺一不可。AI 可以扩大候选方案、提高反馈速度，工程机制才负责确认这些方案是否可信。
第三步，在积累了足够的历史执行数据和稳定质量基线后，再引入缺陷预测、测试排序和更复杂的自主探索能力。此时应持续衡量反馈时长、关键路径覆盖率、缺陷逃逸率、误报率和人工维护时间，而不是只统计生成了多少条用例。
AI 不会替代测试工程师对业务正确性的判断，但会改变测试工程师的工作重心。未来更重要的能力，不是维护更多脚本，而是设计更可靠的质量策略，定义模型不可越过的边界，并让每一次自动化结论都可验证、可追溯、可纠正。
收录于 FunTester 原创专题：AI ，测试有点东西
相关阅读：AI 写用例之后，测试稀缺能力是什么 · AI 写的快，回归测试要跟上 · 看懂 AI 测试工具的四种类型 · 让测试速度真正跟上 AI 生成速度 · 生成测试用例 -> 意图驱动测试