夜雨聆风让 AI 给一个函数补单元测试，已经不算新鲜事。把需求交给它，它能列场景；把页面交给它，它能规划操作、生成脚本，失败后还可能尝试修复定位器。
这些能力很容易制造一种错觉：既然 AI 已经会写、会跑、会修测试，软件质量是不是也可以逐步交给它？
问题恰恰出在这里。
会完成测试动作，不等于知道什么结果才算正确；能让流水线变绿，也不等于产品风险真的下降。 从生成测试到承担质量责任，中间还隔着业务预期、确定性验证和发布决策。
要看清 AI 时代的软件测试，得先把这几件事重新分开。
测试真正生产的是证据
很多人对测试的第一印象，是测试人员执行用例、发现 Bug，或者流水线跑出一串绿色结果。
但测试真正要解决的问题是：在有限时间、数据和环境下，我们掌握的证据，够不够支持一次产品决定？
这个决定可能是允许代码合并，可能是确认一次数据迁移，也可能是判断一个版本能否发布。测试不能证明软件绝对没有缺陷，它只能提高发现重要问题的概率，降低团队做决定时的不确定性。
这也解释了为什么测试远不止单元测试和 UI 自动化。需求有没有歧义、权限是否越界、数据库迁移能否回滚、性能是否退化、生产环境能否观测，都属于质量证据的一部分。
如果一开始只把测试理解成“写脚本”，AI 带来的提升就会被错误地等同于“生成更多脚本”。脚本数量上升了，真正的风险却未必被覆盖。
AI 已经很能干，但不同任务的可信度差得很远
截至 2026-08-11，AI 用于测试已经出现了清楚的能力梯度。
最成熟的一层，是围绕明确代码和规则做辅助工作：生成单元测试或 API 测试脚手架，补充边界场景，构造 Mock 和测试数据，汇总失败日志，解释堆栈。这里的共同特点是，结果可以交给编译器、测试框架和既有规则继续验证。
第二层已经可用，但必须受约束。例如从需求生成测试计划，让 Agent 操作浏览器完成 UI 测试，根据代码变更选择回归范围，或者修复失效的页面定位器。它们不只是在生成文本，而是在规划和执行动作，因此需要稳定环境、最小权限、操作审计和明确停止条件。
第三层仍然处于探索阶段：让通用测试 Agent 自主理解大型系统、自动修改业务断言、决定跳过失败用例，甚至直接承担发布责任。
能力之间最大的差别，在于模型输出有没有独立的验真机制。
Meta 的 TestGen-LLM 工业实验很能说明问题：75% 的候选测试可以正确构建，57% 能稳定通过，最终只有 25% 真正增加了覆盖。模型生成候选的能力已经很强，但有用结果仍要经过构建、重复执行和覆盖验证一层层筛选。
AI 最适合扩大候选空间，确定性工具最适合测量、约束和留证。 两者组合，才比单独依赖模型可靠。
最难自动化的是“什么才算对”
测试里有一个容易被忽略的概念：测试预言机。它回答的是，程序运行之后，什么结果才算正确。
登录成功应该跳到哪个页面，余额计算要遵守哪些例外，订单超时后应该退款还是继续等待，这些答案往往藏在业务规则、历史兼容、合同约束和人的判断里。
AI 可以很快生成一个语法正确的断言，却可能断言了错误结果。更隐蔽的情况是，它直接照着当前实现写测试。这样的测试即使全部通过，也只能证明“实现和自己一致”，无法发现实现本身就错了。
这也是覆盖率经常被误用的原因。覆盖率只能说明哪些代码执行过，不能说明断言是否正确，更不能说明关键业务风险是否被覆盖。
更可靠的做法，是把验收标准、接口契约和业务不变量先写清楚，再配合参考实现、差分测试、变形测试或变异测试检验故障发现能力。高风险断言仍需要领域人员确认。
AI 可以帮助形成预期结果的候选，但不能只凭自己的输出成为最终裁判。
可靠的 AI 测试是一条受控闭环
如果把 AI 放进完整测试流程，一个更可信的结构是：
1. 代码、需求或配置发生变化，系统先装配相关上下文。
2. AI 分析风险，提出测试场景、脚本或修复候选。
3. 规则、沙箱和最小权限限制它能做什么。
4. 编译器、测试框架、静态分析、契约或业务规则负责验真。
5. AI 可以分析失败、提出归因和修复建议，但推断必须指向原始证据。
6. 人或明确授权的规则决定是否接受修改、放宽门禁和发布。
7. 生产监控再把真实故障和行为变化送回下一轮测试。
这条闭环里，有几条底线不能因为“自愈”或“智能化”而放松。
自愈可以修复定位器和等待策略，但不能为了变绿而静默改掉业务断言；失败分析可以给出可能原因，但不能把推测直接写成根因；测试 Agent 可以探索页面，却不应该默认拥有修改生产数据和直接发布的权限。
模型、提示词、上下文、工具、数据和权限也要版本化。否则一次测试即使通过，团队也未必能解释当时使用了什么条件，更无法复现和审计。
当被测对象本身就是 AI，测试还要再加一层
AI 用于测试是一条线，测试 AI 系统是另一条线。两者不能混在一起。
一个带模型、知识库和工具调用的 AI 应用，仍然需要传统的软件测试：API、权限、并发、超时、重试、缓存、部署和可观测性都没有消失。
与此同时，还要检查新的问题：训练和检索数据是否泄漏，模型输出是否稳定，提示词变化是否引起退化，RAG 是否找到正确资料，Agent 是否越权调用工具，提示注入能否突破安全边界。
精确格式、权限和工具副作用，可以继续使用确定性断言。开放式回答则更适合使用黄金样本、明确评分规则、规则评分器、模型评分器和人工抽检组合。离线评测比较版本，线上监控发现真实分布变化。
NIST 的 AI TEVV 框架强调在接近真实部署的情境中评估可靠性、鲁棒性、安全、隐私和公平等属性。OWASP GenAI LLM Top 10 2026 则提供了生成式 AI 应用安全风险的当前入口。
这里没有一个“一次评测、永久合格”的终点。模型、数据、上下文和真实用户行为都可能变化，评测必须与生产监控连接起来。
团队落地时，先跑通一个可以测量的小闭环
AI 测试最容易走偏的起点，是先采购一个看起来什么都能做的平台，再倒推团队要解决什么问题。
更稳妥的方式，是选择一个变更频繁、已经有基本单元测试或 API 测试的模块，做四周左右的最小试点：
1. 只让 AI 为本次变更补充测试，不同时修改生产代码和业务断言。
2. 用编译、稳定重复执行、覆盖差异和变异测试过滤候选。
3. 由开发或测试人员审核，记录接受、修改和拒绝的原因。
4. 观察有效测试接受率、缺陷发现、反馈时间、不稳定率和人工复核工时。
只有这些指标持续证明风险下降或反馈变快，才扩展到 UI Agent、跨服务测试选择和自动修复。
World Quality Report 2025–26 显示，43% 的受访组织仍在 QA 中试验生成式 AI，只有 15% 实现企业级规模化；测试数据和工具采用也仍是主要难点。这至少说明，行业已经从概念讨论走向实际试验，但治理能力并没有自动跟上工具演示。
AI 可以扩大自动化，不能消除质量责任
以后再看到一个 AI 测试方案，可以先不问它能生成多少用例，而问四件事：
• 它准备降低什么业务风险？
• 谁定义正确结果？
• 生成结果通过了哪些独立验证？
• 谁对门禁例外和发布决定负责？
如果这四个问题没有答案，更多脚本、更高覆盖率和更自主的 Agent，可能只是更快地产生不可信结果。
真正值得追求的方向不是无人负责的全自动测试，而是：让 AI 提高探索和生成速度，让确定性系统守住验证，让人对业务风险与发布决定负责。