关注 霍格沃兹测试学院公众号，回复「资料」, 领取人工智能测试开发技术合集

接口是通的，日志是全的，功能演示也没问题。 可一到真实用户手里，系统就开始露出另一张脸：同样的问题，今天答得像专家，明天像在瞎编；知识库明明更新了，回答还在引用旧内容；工具已经接好了，执行结果却总在关键一步出错。

这几年，很多团队都在补一门新课：不是怎么把 AI 接进业务，而是接进去之后，怎么把质量稳住。

传统系统的测试难，难在功能多、链路长、回归重。 AI 系统的测试更难，难在你面对的已经不是一个单纯按规则运行的程序，而是一套由模型、Prompt、知识库、工具、上下文、记忆和编排逻辑共同作用的复杂系统。

问题看起来还是“它为什么答错了”， 但测试真正要回答的，已经变成了另一件事：

它为什么这次对、下次错；为什么演示时稳定、上线后失真；为什么代码没报错，用户却觉得它根本不能用。

---

目录

1. 传统测试方法，为什么一到 AI 系统就开始吃力

2. AI 系统测试到底难在哪

3. AI 测试真正难的，不只是模型不稳定

4. AI 系统测试怎么做，才不是上线前临时试几句

5. 测试工程师在 AI 时代，真正稀缺的能力是什么

---

一、传统测试方法，为什么一到 AI 系统就开始吃力

过去做传统软件测试，很多前提默认是成立的：

• 输入边界大致能枚举

• 执行逻辑大致能推导

• 输出结果通常能精确断言

• 缺陷一旦复现，重跑大概率还能复现

AI 系统没有把这些前提彻底推翻，但确实把它们逐个打松了。

维度	传统系统	AI 系统
输入	结构化、边界相对明确	自然语言、开放、多变
处理过程	规则、分支、状态机	概率生成、检索增强、工具协同
输出	通常唯一或有限解	多解、表述不固定
缺陷表现	报错、异常、逻辑缺陷	幻觉、偏题、不一致、越权、误调用
回归方式	跑接口、跑 UI、比对结果	还要做效果评估、稳定性评估、安全评估
风险来源	代码、配置、依赖服务	模型、Prompt、知识库、上下文、工具、记忆

所以，真正变化的不是“系统里多了个大模型”，而是测试对象本身换了。

过去测试面对的是一个规则系统。 现在测试面对的是一套带有概率生成能力、上下文依赖、持续漂移和外部执行能力的系统。

这也是为什么很多团队会突然觉得，原来那套方法不是完全失效了，而是明显不够用了。

---

二、AI 系统测试到底难在哪

1. 输入空间直接爆炸了

传统系统里，输入再复杂，往往还能围绕字段范围、边界值、异常值来设计。 AI 系统里，用户输入是自然语言，而自然语言最大的特点不是复杂，而是变体无限。

同样是在问退款规则，用户可能会说：

• 帮我查下退款规则

• 这个订单退不了怎么办

• 你们七天无理由怎么判

• 我昨天买的今天还能退吗

• 这种情况到底算不算能退

业务语义相近，表达形式完全不同。

这意味着测试不能只覆盖“标准问法”，还要覆盖口语、省略、错别字、反问、否定、多轮追问、上下文承接、诱导式表达。 传统测试里，很多时候怕的是边界漏测。 AI 测试里，更常见的问题是：边界根本不是固定的。

---

2. 输出不再总是唯一答案

这也是 AI 测试和传统测试最大的分水岭之一。

不过这里有个常见误区需要先纠正：并不是所有 AI 任务都没有标准答案。

分类、抽取、审核、打标、意图识别、结构化生成这类任务，依然可以建立清晰的评测集和断言规则。 真正难的是开放式生成场景，例如问答、总结、改写、RAG 问答、多轮对话、Agent 执行。

这些场景的问题，不是“完全没法评”，而是它们经常没有唯一表述。 测试要看的，不再只是“值是否相等”，而是：

• 是否事实正确

• 是否覆盖关键点

• 是否忠于知识来源

• 是否前后一致

• 是否出现无依据扩写

• 是否触碰业务和安全边界

也就是说，AI 测试的断言方式，已经从“结果是否唯一”转向了“质量是否达标”。

---

3. 一个问题答错，根因常常不在模型

这是 AI 系统最容易误判的地方。

用户看到的是“回答错了”， 但工程上，错误可能出现在完全不同的环节。

以一个 RAG 系统为例，答错可能是因为：

• 问题改写阶段把用户意图理解偏了

• 检索没有召回到关键文档

• 重排把真正重要的片段压到了后面

• Prompt 约束不够严，让模型开始自由发挥

• 知识库版本更新不一致

• 历史上下文把旧信息带进了当前回答

如果进一步走到 Agent 场景，问题还会扩展到：

• 工具选错

• 参数组错

• 权限失控

• 失败后没有回退

• 同一步骤重复执行

所以 AI 系统的缺陷，很多都不是单点 bug，而是链路耦合 bug。

---

4. 可观测性比传统系统差得多

传统系统出了问题，通常比较容易看定位链路：

• 哪个接口超时

• 哪条 SQL 出错

• 哪个字段不符合预期

• 哪个状态码异常

AI 系统不是这样。 很多问题表面上只是“回答不太对”，但真要定位，就要同时看：

• 原始输入

• 系统 Prompt

• 检索召回内容

• 重排结果

• 模型返回

• 工具调用轨迹

• 历史对话上下文

• 最终输出

如果这些中间态没有被保留，没有评估埋点，没有统一日志，最后很容易出现一种常见局面：

线上说它不对，研发说本地复现不了，测试说根因看不出来。

所以 AI 测试不只是“测答案”，还在推动系统具备足够的可观测性和可诊断性。

---

5. 版本漂移和数据漂移会不断重写结果

传统系统上线后，只要代码没变，行为通常不会自己变。 AI 系统不同。

下面任意一个因素变化，效果都可能跟着变：

• 模型版本切换

• 温度和采样参数变化

• Prompt 调整

• 知识库增量更新

• 重排策略变化

• 工具接口返回变化

• 用户问题分布变化

这也是为什么 AI 测试最难的地方，往往不是第一次上线，而是后续持续迭代。 一个版本升级，看起来只是换了模型； 但对测试来说，等于要重新回答这些问题：

• 准确率是不是提升了

• 幻觉率是不是反而升了

• 老问题有没有被重新引入

• 时延和成本有没有恶化

• 某些业务口径是不是跑偏了

传统回归更偏向功能一致性。 AI 回归更像是在做效果基线管理。

---

6. Agent 让风险从“答错”升级成“做错”

普通问答系统，主要风险还是说错。 Agent 系统的风险，是做错。

当模型开始具备工具调用和任务执行能力，测试对象就从“文案输出”变成了“行为执行”。 它可能会：

• 查数据库

• 调接口

• 发消息

• 创建工单

• 操作浏览器

• 执行脚本

• 写入系统状态

这时候测试关注点已经变了：

• 它有没有选对工具

• 参数是否正确

• 有没有越权调用

• 失败后能不能安全回退

• 会不会重复执行

• 遇到歧义指令时会不会误操作

传统系统很多时候是在展示结果。 Agent 系统是在产生行为。 行为一旦出错，代价往往比回答错一句话严重得多。

---

三、AI 测试真正难的，不只是模型不稳定

很多团队刚接触 AI 测试时，第一反应都是一句话： 模型不稳定，所以不好测。

这句话只说对了一部分。

模型的概率生成特性，确实会带来波动。 但 AI 测试真正复杂的地方，不只是“同一句话两次输出不完全一样”，而是整套系统结构已经变了。

先看输出结果。 并不是所有 AI 场景都天然没有标准答案。 分类、抽取、审核、结构化生成这些任务，依然可以做强断言或接近强断言。 真正麻烦的是开放式生成任务，它们没有唯一表述，却又必须满足正确性、完整性、一致性、忠实性和安全性等多重要求。

再看问题来源。 很多线上故障表面看像模型回答错了，根因却并不在模型。 一个回答偏了，背后可能是检索没命中、重排有问题、知识过期、Prompt 约束冲突、工具参数错误，甚至是上下文污染。

再看质量保障方式。 人工多问几句，当然能发现一些明显问题，但这远远不够。 人工体验可以发现问题，却无法形成稳定回归。 今天试出来的结果，明天未必还能复现；这次看似优化有效，下次版本切换后也很难判断到底是真提升，还是只是碰巧答对。

所以，AI 系统测试之所以更难，不是因为它神秘，也不是因为它完全不可控。 真正的原因是：

• 输入更开放

• 链路更耦合

• 评估更复杂

• 可观测性要求更高

• 版本漂移更频繁

• 安全边界更大

测试方法不跟着升级，问题迟早会在生产环境里补回来。

---

四、AI 系统测试怎么做，才不是上线前临时试几句

真正可落地的 AI 测试，不靠“多问几轮”，而要做成工程化体系。 至少要把下面几件事搭起来。

1. 先拆层，再测试

不要一上来就问“这个 AI 助手好不好”。 先拆系统。

一个典型 AI 系统，至少可以拆成下面几层：

层级	核心关注点
输入层	表达覆盖、脏数据、歧义输入、对抗输入
Prompt 层	指令约束、角色设定、格式控制、拒答策略
检索层	召回率、命中率、噪音率、时效性
生成层	正确性、完整性、一致性、幻觉率
工具层	参数正确性、幂等性、异常处理、权限边界
Agent 层	规划能力、路径选择、重试策略、失败恢复
系统层	时延、成本、并发、监控、审计日志

这样做的价值在于，问题一出现，不至于所有锅都甩给模型。

---

2. 建测试集，而不是靠临场发挥

很多团队做 AI 测试，最大的问题不是不会测，而是没有自己的样本资产。 没有测试集，就没有基线；没有基线，就谈不上真正的回归。

至少应该准备这几类数据：

• 业务高频问题集

• 事实准确性问题集

• 检索忠实性问题集

• 边界问题集

• 对抗问题集

• 多轮会话问题集

这些数据不是为了把系统“考倒”，而是为了把系统真正高风险、最常见、最有业务价值的场景固定下来。 AI 项目越往后做，测试资产的重要性会越高。

---

3. 断言要升级成多层评估

AI 场景下，单纯做字符串比对很快就会失效。 更实用的方式，是把断言拆成几类：

规则断言看格式是否正确，字段是否齐全，是否触发明确业务规则。

语义断言看是否覆盖关键点，是否答非所问，是否和参考答案语义一致。

来源断言看回答是否真正来自知识库，是否出现无依据扩写，是否引用过期内容。

行为断言看工具是否正确调用，是否重复提交，是否发生越权或异常操作。

指标断言看准确率、幻觉率、工具成功率、时延、成本等是否达标。

AI 测试真正成熟的标志，不是能提很多“体验问题”，而是能把这些问题一步步转成可重复、可比较、可自动化的评估项。

4. 离线评估、灰度验证、线上监控，一个都不能少

AI 测试绝不是上线前的一次性动作。 更稳妥的方式，是把验证过程拆成三段：

离线评估在固定测试集上跑版本对比，先看质量变化。

灰度验证在小流量场景下观察真实用户反馈，验证离线结论是否成立。

线上监控持续看实际问题分布、漂移情况、时延和成本异常，再把问题样本回流到测试集。

---

五、测试工程师在 AI 时代，真正稀缺的能力是什么

AI 系统测试变难，并不意味着测试岗位价值下降。 恰恰相反，很多团队现在真正缺的，不是“会调模型的人”，而是会做 AI 质量治理的人。

1. 能把“感觉不对”翻译成“可评估问题”

产品说回答不太好，用户说体验不稳定，研发说本地没复现。 这时候，测试要能继续往下拆：

• 是准确性问题，还是完整性问题

• 是检索没命中，还是生成在胡乱补全

• 是上下文串了，还是工具参数错了

• 是模型退化了，还是知识库脏了

这个能力，本质上不是执行用例，而是在建问题框架。

---

2. 能看懂 AI 链路，而不是只盯最终文案

未来很多测试岗位，都会从“结果校验”走向“链路校验”。 不只要看页面和接口，还要能理解：

• Prompt 设计逻辑

• 检索与重排机制

• 上下文组装方式

• 工具调用协议

• Agent 编排流程

• 评估指标体系

不会这些，很多 AI 问题根本没法准确定性。

---

3. 能搭样本资产和回归基线

AI 系统最怕的不是第一次做不出来， 而是每次改完以后，谁都说不清到底是变好了还是变差了。

所以测试最核心的资产，会越来越集中在：

• 标注样本集

• 高风险场景集

• 对抗样本集

• 版本对比结果

• 线上问题回流集

谁能把这些东西搭起来，谁就在团队里真正有不可替代性。

---

4. 懂安全边界和风险控制

AI 一旦接工具、接业务、接生产权限，测试就必须看更大的范围：

• 提示注入

• 越权访问

• 数据泄漏

• 危险操作误触发

• 审计日志缺失

• 人机协同边界不清

未来 AI 测试和安全测试、质量治理、系统治理，边界会越来越近。

---

写在最后

大模型、RAG、Agent 正在一点点进入真实业务。 很多团队以为压力最大的是模型能力，真正上线后才发现，更先顶不住的，往往是测试体系。

因为系统已经变了。 如果测试方法还停在过去，问题迟早会在生产环境里补课。

AI 时代不会让测试消失。 但它会淘汰只会沿用旧方法、却不愿意升级思路的做法。

接下来真正有价值的测试，不只是发现 bug， 而是帮助团队回答一个更关键的问题：

这个 AI 系统，到底能不能稳定、安全、可信地交给真实用户。

这件事，越往后走，越重要。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。