AI测试到底测什么：从传统测试到不确定性测试

摘要

最近很多团队都在上线 AI 功能，但测试阶段很快会遇到一个核心问题：AI 每次回答都不完全一样，这东西到底该怎么测？

传统测试更关注功能是否按规则执行，AI 测试更关注输出是否可信、稳定、可控，是否真的能支撑业务上线。本文从测试工程师视角，拆解 AI 测试和传统测试的本质差异，梳理 AI 测试的核心质量维度、常见问题类型，以及测试思维该如何切换，适合作为 AI 测试系列的第一篇入门文章。

封面文案

AI功能能回答，
不代表能上线。

写给测试工程师的
AI测试入门第一课

---

最近很多团队都在上线 AI 功能。

AI 总结、AI 问答、AI 生成测试用例、AI Agent 自动执行任务，看起来都很酷。
但真正到了测试阶段，很多测试同学会马上遇到一个问题：

AI 每次回答都不完全一样，这东西到底该怎么测？

这就是 AI 测试和传统测试最本质的区别。

传统测试里，我们习惯验证的是：

输入一个明确条件，系统返回一个明确结果。

而 AI 测试面对的往往是：

输入是明确的，但输出不一定唯一。

所以，AI 测试不是简单把传统测试方法照搬过来，也不是只看页面有没有返回答案，而是要回答一个更关键的问题：

这个 AI 输出，是否可信、稳定、可控，是否真的可以支撑业务上线？

---

一、传统测试测的是什么？

先从大家最熟悉的传统测试说起。

在传统软件测试里，大多数场景都符合“确定性逻辑”。

比如一个登录功能。

输入

• 用户名正确
• 密码正确

预期结果

• 登录成功
• 跳转首页
• 返回用户信息

再比如一个审批功能。

输入

• 提交请假申请
• 审批人点击通过

预期结果

• 审批状态变为“已通过”
• 申请人收到通知
• 数据正确落库

这类系统有一个很典型的特点：

规则明确，预期结果明确，判断标准明确。

测试工程师在这里做的事情，本质上是验证：

• 功能是否符合需求
• 逻辑是否正确
• 数据是否正确
• 流程是否完整
• 异常是否可控

所以传统测试天然适合使用这些方法：

• 测试用例
• 断言
• 自动化脚本
• 接口校验
• 数据比对
• Pass / Fail 判断

换句话说，传统测试的核心是：

验证系统是否按既定规则执行。

---

二、AI 测试为什么不一样？

AI 系统最大的不一样，不是“用了模型”，而是它的输出不再完全确定。

比如你问 AI：

请总结这份需求文档。

你连续问三次，可能会得到三种表达略有不同的回答。

再比如你说：

请根据下面需求生成测试用例。

AI 生成出来的测试点、表述方式、优先级判断，也可能会有变化。

甚至在很多场景里，AI 的输出看起来“像是对的”，但其实可能存在这些问题：

• 遗漏关键点
• 理解偏差
• 逻辑不严谨
• 编造不存在的内容
• 没有严格遵守格式
• 没有真正基于文档回答

这就意味着，AI 测试不能只问：

有没有结果？

而必须继续问：

• 结果是不是可信？
• 结果是不是完整？
• 结果是不是稳定？
• 结果是不是遵守约束？
• 结果能不能被业务真正使用？

所以，AI 测试测的不是“AI 会不会说话”，而是：

AI 输出能不能被信任。

---

三、AI 测试不是测“聊天框”，而是测“AI系统”

很多人刚接触 AI 测试时，容易有一个误区：

AI 测试不就是问几个问题，看看回答得对不对吗？

这只是最表层。

实际上，一个真实上线的 AI 功能，背后通常不是只有一个模型，而是一整条系统链路。

比如一个“AI 文档问答”功能，背后可能包含：

用户提问
  ↓
问题预处理
  ↓
知识库检索
  ↓
检索结果重排序
  ↓
大模型生成答案
  ↓
格式化输出
  ↓
返回引用来源

再比如一个“AI Agent 自动建任务”功能，背后可能包含：

理解用户意图
  ↓
读取需求文档
  ↓
提取关键信息
  ↓
生成测试用例
  ↓
调用 Jira API
  ↓
创建任务
  ↓
返回执行结果

所以 AI 测试真正要测的，通常是以下几个层面：

• 模型输出质量
• Prompt 约束效果
• 知识库检索准确性
• 工具调用正确性
• 权限与安全边界
• 性能与成本表现
• 异常处理与回退机制

也就是说，AI 测试测的不是一个输入框，而是：

模型 + Prompt + 数据 + 检索 + 工具 + 业务规则 + 安全机制
共同组成的 AI 系统。

---

四、AI 测试的核心，不是“唯一正确答案”，而是“质量维度”

在传统测试里，我们很习惯写这种预期结果：

• 返回 code = 0
• 页面提示“提交成功”
• 列表展示 10 条数据
• 状态从 A 变成 B

但在 AI 测试里，很多场景没有唯一答案。

例如：

• 请总结这份会议纪要
• 请提炼这个 PRD 的测试重点
• 请根据需求生成测试用例
• 请判断这段周报质量如何

这些任务的结果，通常很难用单一标准判断“唯一正确”。

所以 AI 测试更适合从多个质量维度去评估。

1. 准确性

输出内容是否符合事实、符合原文、符合业务规则。

比如文档里写的是“验证码 5 分钟有效”，AI 却写成“10 分钟有效”，这就是准确性问题。

2. 完整性

是否遗漏核心信息。

比如总结一份需求文档时，只提到了主流程，没有提到异常流程、边界规则、风险点，这就是完整性不足。

3. 相关性

是否真正回答了用户的问题。

用户问的是“退款规则”，AI 却泛泛而谈整个订单流程，这说明相关性不够。

4. 稳定性

相同问题多次提问，结果是否波动过大。

不是要求字字相同，而是要求核心结论、关键点覆盖、格式结构相对稳定。

5. 可控性

是否遵守系统规则、角色约束、输出格式、业务边界。

比如要求输出 JSON，却返回自然语言长文；要求基于文档回答，却开始自由发挥，这都属于可控性问题。

6. 无幻觉

是否编造不存在的信息。

这是 AI 测试里非常关键的一项。
因为 AI 最大的风险之一，不是“不知道”，而是“看起来知道，但其实在编”。

7. 安全性

是否泄露敏感信息，是否能被越权利用，是否会输出不应输出的内容。

8. 可追溯性

尤其在知识库问答场景里，答案是否可以追溯到具体文档来源，引用是否真实可信。

所以 AI 测试的判断方式，不再只是：

Pass / Fail

而更像是：

多维度评估 + 分级判断 + 人工复核

---

五、AI 测试和传统测试的差异，到底差在哪？

直接看下面这张对比表。

对比项	传统测试	AI测试
输出结果	通常固定	不一定固定
预期结果	明确唯一	多数情况不唯一
判断方式	Pass / Fail	评分 + 分级 + 抽检
测试重点	功能逻辑是否正确	输出质量是否可信
主要缺陷	逻辑错误、接口错误、UI异常	幻觉、遗漏、理解偏差、格式失控
回归方式	自动化断言	测试集 + 评分规则 + 样例比对
风险类型	功能不可用	看似可用但结果不可靠
上线门槛	功能通过即可	还要看准确性、稳定性、安全性

这张表背后，其实反映的是测试思维的变化。

传统测试更关注：

系统有没有按规则执行。

AI 测试更关注：

系统在不确定输出下，能不能保持可信和可控。

---

六、AI 类产品最常见的问题，不是报错，而是“像对，但不真对”

传统系统的问题通常比较显性：

• 页面报错
• 接口超时
• 数据错误
• 状态不一致

而 AI 产品的问题，往往更隐蔽。

因为很多时候它不会报错，甚至回答看起来还挺像那么回事。
但仔细一看，可能存在这些问题。

1. 编造内容

文档里没有提到的规则，AI 自己补出来了。

例如用户问：

文档中退款规则是什么？

实际上文档里根本没有退款规则，但 AI 却给出了一套“看起来合理”的解释。

2. 遗漏关键点

AI 只总结了表面内容，没有提炼真正关键的信息。

比如总结需求文档时，没有提到风控限制、权限边界、异常处理。

3. 理解偏差

AI 把“可选项”理解成“必填项”，把“建议”理解成“必须”。

4. 格式不稳定

有时候按表格输出，有时候按段落输出；有时候字段完整，有时候字段缺失。

5. 多轮失忆

第一轮还记得上下文，第二轮就开始偏题，第三轮已经忘记之前的约束。

6. 不基于事实回答

知识库场景中，用户明明要求基于文档回答，AI 却混入了模型自己的通用知识。

7. 结果不可复现

今天效果很好，Prompt 微调一下，或者模型版本一变，结果质量突然下降。

这也是为什么 AI 测试非常强调：

• 典型问题沉淀
• 回归测试集
• 评分标准
• 缺陷样例库

因为 AI 的问题，很多不是“能不能运行”，而是：

运行了，但质量不稳。

---

七、AI 测试到底要覆盖哪些对象？

如果从落地角度看，AI 测试通常可以分成四类对象。

1. 模型输出测试

主要验证模型回答本身的质量。

关注点包括：

• 回答是否准确
• 是否完整
• 是否相关
• 是否有幻觉
• 是否遵守格式要求

2. Prompt 测试

主要验证提示词设计是否有效、稳定、抗干扰。

关注点包括：

• 角色约束是否生效
• 输出格式是否稳定
• 业务规则是否被遵守
• 用户干扰时是否失控
• 多轮场景下是否还能保持约束

3. RAG / 知识库测试

主要验证“检索 + 生成”整条链路是否可靠。

关注点包括：

• 文档上传和解析是否正常
• 检索是否召回正确内容
• 排序是否合理
• 答案是否真正基于文档
• 引用是否准确
• 无答案时是否拒绝编造
• 权限是否隔离

4. Agent 测试

主要验证 AI 是否能正确理解任务并完成执行。

关注点包括：

• 意图识别是否准确
• 任务拆解是否合理
• 工具调用是否正确
• 参数传递是否准确
• 执行顺序是否正确
• 工具失败后是否有兜底
• 高风险操作是否需要确认

所以如果有人问：

AI 测试到底测什么？

更准确的回答应该是：

测输出质量，测约束遵守，测链路可靠，测行为边界。

---

八、为什么很多团队做不好 AI 测试？

原因通常不是“不会用模型”，而是还在用传统思路做 AI 验收。

常见问题包括：

1. 只看功能通没通

页面能提问、能返回内容，就认为没问题。

但真正该问的是：

• 回答是否准确
• 是否遗漏核心信息
• 是否存在编造
• 是否符合业务要求

2. 没有评分标准

测试结论全靠主观感觉。

A 觉得“还行”，B 觉得“不靠谱”，最后没人能说清楚到底哪里有问题。

3. 没有沉淀回归集

每次都靠临时问几个问题，结果版本一变，就无法比较前后质量差异。

4. 只测简单场景

标准样例表现很好，一到复杂业务、多轮对话、长文档、异常输入，问题就出来了。

5. 只测模型，不测系统链路

以为模型效果好，业务效果就一定好。
但实际上很多问题发生在：

• Prompt 设计
• 检索策略
• 权限控制
• 工具调用
• 上下文拼接
• 格式约束

所以 AI 测试要真正做起来，必须从“单点功能验证”升级到“系统质量保障”。

---

九、测试工程师该如何切换到 AI 测试思维？

对测试工程师来说，最重要的不是一下子学会所有 AI 名词，而是先完成思维切换。

可以重点完成这几个转变。

从“验证唯一结果”转向“评估输出质量”

以前是判断对不对，现在要判断好不好、稳不稳、能不能用。

从“只测功能链路”转向“测结果可信度”

以前功能通了就差不多了，现在还要看输出是否可信。

从“断言式回归”转向“测试集式回归”

以前靠断言字段值，现在更多依赖：

• 标准测试集
• 评分规则
• 典型样例
• 人工抽检

从“页面思维”转向“系统思维”

不能只看前端交互，还要理解背后的：

• Prompt
• 知识库
• 检索
• 工具
• 权限
• 日志
• 模型参数

这个转变一旦完成，很多 AI 测试问题就会看得更清楚。

---

十、一个简单例子：为什么 AI 测试不能只写 Pass / Fail？

假设有一个功能：

用户上传需求文档，AI 自动生成测试用例。

如果按传统测试思路，可能会写成：

步骤

• 上传文档
• 点击生成

预期结果

• 成功生成测试用例

这个预期太粗了，几乎没有测试价值。

因为就算 AI 输出了一堆内容，也不能证明它真的可用。

更合理的 AI 测试思路应该是继续拆：

要看什么？

• 是否覆盖主流程
• 是否覆盖异常流程
• 是否覆盖边界场景
• 是否字段完整
• 是否符合指定格式
• 是否存在需求外编造
• 是否步骤可执行
• 是否优先级合理
• 多次生成是否稳定

这时候你会发现：

AI 测试真正测的，不是“生成了没有”，而是“生成得怎么样”。

这就是 AI 测试的核心差异。

---

十一、AI 测试的目标，到底是什么？

AI 测试最终目标，不是证明 AI 很强，也不是为了把每个回答都抠到一字不差。

它真正要解决的是：

如何把不确定的模型输出，变成可以评估、可以复现、可以回归、可以上线的质量体系。

换句话说，AI 测试要帮助团队回答这些问题：

• 这个 AI 功能能不能上线？
• 它的回答是否可信？
• 它会不会乱编？
• 它是否遵守业务规则？
• 它是否存在权限和安全风险？
• 它的质量是否稳定？
• 它出了问题后能不能追踪和回归？

只有这些问题有了答案，AI 功能才不只是“能演示”，而是真正具备上线能力。

---

十二、小结

AI 测试到底测什么？

可以浓缩成一句话：

传统测试验证系统是否按规则执行，AI 测试验证系统在不确定输出下是否依然可信、稳定、可控。

所以，AI 测试测的并不只是回答内容本身，而是整套 AI 系统的质量表现，包括：

• 输出准确性
• 内容完整性
• 回答相关性
• 结果稳定性
• 规则遵守能力
• 幻觉控制能力
• 权限与安全边界
• 检索和工具链路可靠性

对于测试工程师来说，这不是一套完全陌生的能力，而是在已有测试分析、异常设计、风险识别、质量判断基础上的一次升级。

从“测功能是否可用”，走向“测 AI 是否值得信任”，这就是 AI 测试的第一步。

---

写在最后

送你一句我觉得很适合作为 AI 测试系列主线的话：

AI功能能回答，不代表能上线。

如果你现在也在做 AI 相关项目，或者正在思考测试工程师怎么转向 AI 测试，欢迎交流。

你们团队现在最头疼的是哪类问题？

• AI 会编造
• 回答不稳定
• Prompt 不好回归
• 知识库检索不准
• Agent 调工具不可控

---

下一篇预告

下一篇继续写：

Prompt 测试入门：如何验证一个提示词是否稳定可靠

会重点展开这几个问题：

• Prompt 为什么也需要测试？
• 一个 Prompt 到底应该测什么？
• 如何设计 Prompt 测试用例？
• 怎样判断 Prompt 是“能用”还是“稳定可用”？
• Prompt 改了一版之后，怎么做回归？

---

AI测试系列主线：把不确定的 AI 输出，变成可评估、可回归、可上线的质量体系。