AI测试从 0 到 1：开篇总览
随着大模型、AI Agent、智能知识库、自动化生成工具逐渐进入业务系统，测试工作正在发生明显变化。
过去，我们测试一个功能，通常关注的是：
输入是否正确，输出是否符合预期，流程是否稳定。
例如登录、下单、审批、消息发送，这类功能的预期结果相对明确，测试人员可以通过测试用例、接口断言、自动化脚本来验证结果。
但 AI 类产品不同。
同样一个问题，AI 可能每次回答都不完全一样；同样一份文档，不同模型的总结质量可能差异明显；同样一个任务，AI Agent 可能会选择不同的工具、不同的执行路径。
这就带来了一个新的问题：
当结果不是完全确定的时候，测试应该怎么做？
这正是 AI 测试要解决的问题。
一、什么是 AI 测试？
AI 测试不是简单地测试一个聊天窗口，也不是只看模型能不能回答问题。
更准确地说，AI 测试是对 AI 系统的能力、稳定性、准确性、安全性、可控性和业务价值进行验证。
传统测试更关注：
功能是否可用。
AI 测试更关注：
AI 的输出是否可信、是否稳定、是否可控、是否能真正解决业务问题。
例如，一个"AI 总结文档"功能，看起来只是用户上传文档，AI 输出总结。但测试时需要关注的不只是"能不能生成总结"，还要看：
| 测试维度 | 需要验证的问题 |
|---|---|
| 准确性 | 总结内容是否符合原文 |
| 完整性 | 是否遗漏关键结论、风险、待办 |
| 幻觉问题 | 是否编造文档中不存在的内容 |
| 格式遵循 | 是否按照要求输出标题、要点、结论 |
| 多轮能力 | 继续追问时是否能保持上下文 |
| 权限控制 | 是否会引用无权限文档内容 |
| 稳定性 | 多次生成结果是否差异过大 |
| 性能成本 | 响应时间、Token 消耗是否可接受 |
所以，AI 测试的核心并不是"让 AI 输出一个答案"，而是判断：
这个答案能不能被用户信任，能不能被业务使用，能不能支撑上线。
二、为什么测试工程师需要学习 AI 测试？
AI 功能正在从"辅助工具"变成"业务能力"。
现在很多系统已经开始接入 AI，例如：
| 场景 | AI能力 |
|---|---|
| 企业 IM | 消息总结、文档总结、智能问答 |
| 知识库 | 文档检索、RAG 问答、引用溯源 |
| OA系统 | 请假识别、审批建议、流程推荐 |
| 测试平台 | 自动生成测试用例、缺陷分析、报告生成 |
| 客服系统 | 智能回复、工单分类、意图识别 |
| 项目管理 | 风险识别、周报总结、任务拆解 |
这些功能上线后，如果没有 AI 测试体系，很容易出现以下问题：
- AI 看起来能回答，但内容不准确。
- AI 输出很像真的，但其实是编造的。
- 简单问题表现很好，复杂业务场景效果很差。
- 演示环境很好，上线后不稳定。
- 没有评估标准，测试只能凭感觉判断好坏。
- 没有回归集，Prompt 或模型一变，质量无法验证。
传统测试工程师如果只用原来的方式测试 AI，很容易陷入一个误区：
只验证功能链路是否通了，却没有验证 AI 输出质量是否可靠。
因此，AI 测试会成为测试工程师非常重要的新能力。
三、AI 测试主要测哪些对象？
AI 测试可以分成几个典型方向。
1. 大模型能力测试
这是最基础的一类测试，主要验证模型自身能力。
例如：
| 能力类型 | 测试内容 |
|---|---|
| 问答能力 | 是否能正确回答业务问题 |
| 总结能力 | 是否能准确总结文档、聊天记录 |
| 推理能力 | 是否能根据上下文做判断 |
| 多轮对话 | 是否能记住前文并持续理解 |
| 格式遵循 | 是否能按 JSON、表格、Markdown 输出 |
| 代码能力 | 是否能生成可运行代码或脚本 |
| 翻译能力 | 是否准确、自然、符合语境 |
这类测试的重点不是"模型会不会说话"，而是看它在具体任务中的表现是否满足业务要求。
2. Prompt 测试
Prompt 是 AI 应用中非常关键的一部分。
很多时候，AI 输出质量不稳定，并不一定是模型能力不行，而是 Prompt 设计不够清晰、约束不够明确、边界条件不完整。
例如，一个测试用例生成 Prompt：
text
你是一个资深测试工程师。
请根据需求文档生成测试用例。
输出字段包括：用例标题、前置条件、测试步骤、预期结果、优先级。测试时要关注：
| 测试点 | 说明 |
|---|---|
| 角色是否生效 | 是否真的以测试工程师视角分析 |
| 格式是否稳定 | 是否每次都输出指定字段 |
| 规则是否遵守 | 是否按业务约束生成 |
| 是否乱扩展 | 是否加入需求中没有的内容 |
| 是否抗干扰 | 用户要求忽略规则时是否仍能守住边界 |
Prompt 测试是测试工程师入门 AI 测试最适合的切入口。
3. RAG / 知识库测试
RAG 是当前最常见的 AI 应用架构之一。
它的基本流程是：
text
用户提问
↓
从知识库检索相关内容
↓
把检索结果交给大模型
↓
生成答案这类系统的测试不能只看最终回答，还要看整个链路：
| 环节 | 测试重点 |
|---|---|
| 文档上传 | 格式、大小、权限、异常文件 |
| 文档解析 | 文本、表格、图片、标题是否解析正确 |
| 切片策略 | Chunk 是否合理 |
| 检索召回 | 是否能找到正确内容 |
| 重排序 | 正确内容是否排在前面 |
| 答案生成 | 是否基于文档回答 |
| 引用溯源 | 引用是否真实、准确 |
| 无答案处理 | 文档中没有答案时是否拒绝编造 |
| 权限隔离 | 是否会召回无权限文档 |
RAG 测试的核心问题是：
AI 的答案是否真的来自知识库，而不是模型自己猜的。
4. AI Agent 测试
AI Agent 是更复杂的一类 AI 系统。
普通 AI 聊天主要是"回答问题"，而 Agent 是"执行任务"。
例如：
text
帮我分析这个需求，生成测试用例，并创建 Jira 任务。这个任务可能包含多个步骤：
text
理解用户意图
↓
读取需求文档
↓
分析功能点
↓
生成测试用例
↓
调用 Jira API
↓
创建任务
↓
返回执行结果Agent 测试要关注的不只是回答内容，还包括：
| 测试维度 | 说明 |
|---|---|
| 意图识别 | 是否理解用户真正想做什么 |
| 任务拆解 | 是否合理规划步骤 |
| 工具选择 | 是否调用正确工具 |
| 参数传递 | API 参数是否正确 |
| 执行顺序 | 多步骤流程是否正确 |
| 异常恢复 | 工具失败后是否能处理 |
| 权限控制 | 高风险操作是否需要确认 |
| 最终结果 | 是否真正完成任务 |
AI Agent 测试会更接近"业务流程测试 + 接口测试 + 安全测试 + AI 输出评估"的组合。
四、AI 测试和传统测试有什么不同？
AI 测试并不是完全推翻传统测试，而是在传统测试基础上增加新的质量维度。
| 对比项 | 传统测试 | AI测试 |
|---|---|---|
| 预期结果 | 通常明确固定 | 可能不唯一 |
| 判断方式 | Pass / Fail | 评分 + 分级 + 人工复核 |
| 测试重点 | 功能流程是否正确 | 输出是否可信可控 |
| 缺陷类型 | 功能异常、接口错误、数据错误 | 幻觉、遗漏、理解偏差、格式失控 |
| 回归方式 | 自动化断言 | 测试集 + 评分标准 + 人工抽检 |
| 风险重点 | 功能不可用 | 看似可用但结果不可信 |
传统测试更像是在验证：
系统有没有按规则执行。
AI 测试更像是在验证：
系统有没有在不确定性中保持可信。
五、AI 测试的核心指标
AI 测试需要建立自己的质量指标。
常见指标包括：
| 指标 | 含义 |
|---|---|
| 准确率 | 回答是否正确 |
| 召回率 | 是否找到了应该找到的信息 |
| 幻觉率 | 是否编造不存在的信息 |
| 格式合规率 | 是否按要求输出 |
| 稳定性 | 多次执行结果是否一致 |
| 引用准确率 | 引用来源是否正确 |
| 拒答准确率 | 无答案或敏感问题是否正确拒答 |
| 响应时间 | AI 返回结果耗时 |
| Token 消耗 | 单次调用成本 |
| 人工修正率 | 输出结果需要人工修改的比例 |
在实际项目中，不一定一开始就建立复杂指标体系。可以先从几个最关键的指标开始：
text
准确性
完整性
无幻觉
格式合规
可执行性
响应时间六、AI 测试的基本流程
一个完整的 AI 测试流程可以这样设计：
text
1. 明确AI功能目标
↓
2. 梳理业务场景
↓
3. 设计测试数据
↓
4. 编写Prompt测试用例
↓
5. 执行多轮测试
↓
6. 对AI输出进行评分
↓
7. 记录缺陷和典型样例
↓
8. 优化Prompt、模型参数或业务规则
↓
9. 建立回归测试集
↓
10. 输出AI质量报告其中最关键的是三件事：
-
测试数据集
用来覆盖不同业务场景、异常场景、边界场景。
-
评分标准
用来避免测试人员只凭主观感觉判断好坏。
-
回归集
用来保证 Prompt、模型、知识库或参数调整后质量不会倒退。
七、测试工程师如何从 0 开始学习 AI 测试？
建议不要一开始就直接研究复杂框架，而是按下面路径逐步进入。
第一阶段：理解基础概念
先掌握以下关键词：
| 概念 | 说明 |
|---|---|
| LLM | 大语言模型 |
| Prompt | 给模型的指令 |
| System Prompt | 系统级提示词 |
| Token | 模型处理文本的基本单位 |
| Temperature | 控制输出随机性 |
| Context Window | 上下文窗口 |
| Hallucination | 幻觉，模型编造内容 |
| Embedding | 文本向量化 |
| Vector DB | 向量数据库 |
| RAG | 检索增强生成 |
| Agent | 能调用工具执行任务的 AI 系统 |
第二阶段：从 Prompt 测试入手
这是最适合测试工程师的入门方向。
可以先选择一个简单场景：
text
输入一段需求，让 AI 生成测试用例。然后测试：
text
是否覆盖主流程
是否覆盖异常场景
是否字段完整
是否步骤可执行
是否编造需求外内容
是否能按表格输出
是否能多轮补充这个阶段的目标是建立对 AI 输出质量的判断能力。
第三阶段：学习 RAG 测试
当你理解 Prompt 测试后，可以进一步测试知识库问答。
例如：
text
上传一份产品需求文档，然后向 AI 提问。需要验证：
text
是否能找到正确章节
是否能基于文档回答
是否能引用来源
文档没有答案时是否不编造
文档更新后答案是否同步
无权限文档是否不会被召回这个阶段的目标是理解 AI 应用中"检索"和"生成"的关系。
第四阶段：学习 Agent 测试
最后再进入 Agent 测试。
Agent 测试比普通 AI 问答更复杂，因为它涉及工具调用和任务执行。
例如：
text
让 AI 自动生成测试用例，并创建任务。需要测试：
text
任务拆解是否合理
工具选择是否正确
API 参数是否正确
执行失败是否有兜底
高风险操作是否需要确认
最终结果是否真实完成这个阶段的目标是从"测试 AI 输出"升级为"测试 AI 执行链路"。
八、AI 测试最容易踩的坑
在刚开始做 AI 测试时，容易出现几个误区。
1. 只测功能可用，不测输出质量
很多 AI 功能从页面看是正常的：
text
可以输入问题
可以返回答案
页面没有报错但真正的问题可能是：
text
答案不准确
内容有遗漏
引用不正确
有幻觉
格式不稳定AI 测试不能只停留在"链路通了"。
2. 没有标准，只凭感觉判断
如果没有评分标准，不同测试人员对同一个回答可能给出完全不同的结论。
因此至少要定义基础标准：
| 评分项 | 分值 |
|---|---|
| 准确性 | 30 |
| 完整性 | 20 |
| 相关性 | 15 |
| 格式合规 | 15 |
| 可执行性 | 10 |
| 无幻觉 | 10 |
有了标准，AI 测试才可以沉淀、复盘和回归。
3. 只测简单问题，不测复杂业务场景
AI 最容易在简单样例中表现良好。
真正的问题通常出现在：
text
长文档
多规则
多角色
多轮对话
权限边界
指令冲突
业务例外情况所以测试数据不能只准备"标准问题"，还要准备复杂和异常数据。
4. 没有回归集
AI 系统经常会调整：
text
模型版本
Prompt
知识库内容
切片策略
检索参数
温度参数
工具调用逻辑任何一个变化都可能影响输出质量。
如果没有回归集，就无法判断：
这次优化到底是变好了，还是引入了新问题。
九、AI 测试的最终目标
AI 测试的目标不是证明 AI 很强，也不是单纯找出 AI 的错误。
它的核心目标是：
建立一套可评估、可复现、可回归、可上线的 AI 质量保障体系。
换句话说，AI 测试要帮助团队回答几个关键问题：
text
这个AI功能能不能上线？
它的回答是否可信？
它是否会乱编？
它是否能遵守业务规则？
它是否有权限和安全风险？
它的成本是否可控？
它是否需要人工复核？只有这些问题有了明确答案，AI 功能才具备真正上线的基础。
十、开篇总结
AI 测试是测试工程师面向未来的重要能力。
它不是传统测试的替代，而是传统测试能力的扩展。
传统测试让我们知道：
系统功能是否正确。
AI 测试让我们进一步判断：
AI 输出是否可信，AI 行为是否可控，AI 能力是否真正产生业务价值。
对于测试工程师来说，最好的入门方式不是一开始就研究复杂理论，而是从一个具体场景开始：
text
让 AI 根据需求生成测试用例，然后评估它生成得好不好。从 Prompt 测试开始，再逐步进入 RAG 测试、Agent 测试、自动化评估和 AI 质量体系建设。
这就是 AI 测试从 0 到 1 的第一步。