AI测试用例库怎么建：从样例分类到长期复用

前面几篇，我们已经把 AI 测试的几个核心问题逐步拆开了：

AI 功能到底怎么测
Prompt、RAG、Agent 分别怎么测
回归体系怎么建立
团队怎么起步
AI 测试报告怎么写
从 0 到 1 的整体落地路径是什么

如果说前面的内容主要在回答：

一个 AI 功能怎么测、一个团队怎么开始做

那这一篇开始，要继续往"长期可落地"推进一步，解决一个非常关键的问题：

AI 测试样例，怎么从"临时提几个问题"，变成"能长期复用的测试资产"？

这一步非常重要。

因为很多团队在做 AI 测试时，前期不是完全没有样例，而是样例的状态通常都很原始：

分散在聊天记录里
散落在文档里
藏在测试同学的脑子里
问题提过一次，下次又重新想
历史出过的问题，没有沉淀回来

结果就是：

每次看起来都在"做 AI 测试"，但始终没有真正积累下来。

这也是很多团队做了一段时间 AI 测试之后，最容易出现的瓶颈：

会测，但效率不高
知道一些问题，但复用不起来
每次回归都像重新开始
样例越来越多，但越来越乱
历史问题复发，却很难第一时间发现

而解决这些问题的核心，不是多做几轮测试，而是：

把样例当成资产来经营。

所以这一篇要讲清楚的是：

AI 测试用例库到底为什么要建、应该怎么分类、字段怎么设计、怎么维护，才能真正长期复用。

一、为什么 AI 测试样例不能只靠"临时问几个问题"？

这是最基础、但也最容易被忽略的问题。

很多团队在做 AI 测试时，前期常见的方式是：

打开系统
临时问几个问题
看看回答像不像样
有问题就记一下
下次再重新想几个问题

这种方式在很早期 Demo 阶段可以接受，但一旦想持续做，就会暴露 4 个明显问题。

1. 样例不可复现

今天问了哪些问题，明天不一定还记得。

不同人提问方式不同，结论自然也不同。

2. 样例不可比较

Prompt 改版前后、模型切换前后，到底是变好了还是变差了，没法客观对比。

3. 样例不可积累

今天发现的问题，如果不沉淀成固定样例，下次仍然可能重新出现。

4. 样例不可扩展

当测试对象越来越多时，如果没有结构化管理，样例会越来越乱，最后谁都不想维护。

所以 AI 测试样例库要解决的，本质上不是"把问题记下来"，而是：

把零散提问，变成结构化、可复用、可持续维护的测试资产。

二、AI 测试用例库，到底是什么？

可以把它理解成一句话：

面向 AI 功能的结构化测试样例资产库。

它和传统测试用例库有相似的地方，也有明显不同。

相似的地方

它们都服务于这些目标：

覆盖核心场景
验证功能质量
支撑回归
沉淀历史问题
提供上线依据

不同的地方

AI 测试用例库，不再只是"步骤 + 预期结果"的静态结构，而更强调这些东西：

输入样例本身
输出评估重点
风险等级
评分方式
是否为历史缺陷样例
是否属于高风险场景
是否适合自动校验
多轮上下文信息

也就是说，AI 测试用例库不是简单把传统测试用例照搬过来，而是：

围绕 AI 输出质量和风险边界重新组织的一套样例资产。

三、为什么 AI 测试样例要被当成"资产"来经营？

因为在 AI 场景里，样例不是一次性消耗品，而是会越来越值钱的。

这和传统测试有一点像，但在 AI 场景里更明显。

为什么说它越来越值钱？

因为一条高质量 AI 样例，通常都凝结了这些东西：

一个真实业务场景
一个容易踩坑的问题
一种质量判断标准
一次历史失败经验
一类未来还可能复发的风险

尤其是这些样例最有价值：

曾经暴露严重问题的样例
高风险边界样例
能代表真实业务难点的样例
能清楚区分"变好还是变差"的样例

所以 AI 测试样例库一旦建起来，价值不在于"数量多"，而在于：

它能持续帮团队守住质量下限。

这也是为什么样例库越往后越重要。

四、AI 测试用例库，最少应该怎么分类？

如果一开始就分类太复杂，团队会维护不动。

所以最推荐的做法，是先用一套足够实用的最小分类法。

我建议最少分成 4 类。

1. 标准样例

这是样例库的主干。

用于验证最常见、最核心、最标准的业务场景。

例如：

标准需求生成测试用例
标准文档总结
标准知识库问答
标准 Agent 单步任务

它的作用是：

验证"主干能力"是不是正常。

2. 边界样例

用于验证复杂输入、非理想条件和模型容易不稳的场景。

例如：

模糊输入
需求不完整
超长文本
中英混输
冲突要求
多轮追问
噪声信息干扰

它的作用是：

验证系统在复杂条件下还能不能守住边界。

3. 缺陷回归样例

这类样例价值非常高。

只要历史上出过问题，就应该沉淀进来。

例如：

曾经编造答案
曾经漏掉边界条件
曾经引用错来源
曾经格式失控
曾经 Agent 重复建单
曾经越权输出内容

它的作用是：

修过的问题，必须持续盯住。

4. 高风险样例

这类样例不一定多，但一定要单独标出来。

例如：

无答案场景
权限隔离场景
敏感信息场景
高风险执行任务
多人通知
正式工单创建
删除、修改、覆盖类动作

它的作用是：

最危险的地方必须优先看住。

五、除了这 4 类，还可以怎么进一步细分？

当样例数量越来越多时，可以在 4 大类基础上再加两个维度。

维度 1：按功能模块分

例如：

Prompt
生成类功能
RAG
Agent
评测中心
多轮对话
总结类功能
审核类功能

这样做的好处是：

不同 AI 功能的样例不会混在一起。

维度 2：按风险等级分

例如：

P0：高风险，必须回归
P1：重要问题，建议每轮回归
P2：一般问题，按版本抽检

这样做的好处是：

回归时知道哪些样例一定要跑，哪些可以分层处理。

六、AI 测试用例库的字段怎么设计？

这是最实操的一部分。

很多团队不是不想建样例库，而是卡在：

一条样例到底该记录哪些字段？

这里我给你一个 最小可落地字段结构。

字段	说明
样例编号	唯一 ID，方便追踪
样例标题	一眼能看懂样例要测什么
功能模块	Prompt / RAG / Agent / 生成类等
场景类型	标准 / 边界 / 缺陷 / 高风险
风险等级	P0 / P1 / P2
输入内容	用户输入、需求文本、问题内容、任务指令
上下文信息	多轮对话或前置上下文，若有则记录
预期重点	本条样例主要看什么
评价方式	规则判断 / 人工评分 / 自动校验
历史问题标记	是否为历史缺陷样例
备注	特殊说明

为什么这个字段结构好用？

因为它同时解决了 4 件事：

能知道这条样例测什么
能知道这条样例有多重要
能知道怎么评估
能知道它是不是历史坑位

也就是说，它不是为了"看起来完整"，而是为了支撑后续：

回归
问题追踪
分层维护
测试报告输出

七、给一个样例库记录示例

示例 1：生成类功能

字段	示例
样例编号	TC-AI-001
样例标题	完整登录需求生成测试用例
功能模块	生成类功能
场景类型	标准
风险等级	P0
输入内容	含验证码有效期、错误次数、发送频率限制的登录需求
预期重点	覆盖正常/异常/边界场景，不编造需求外规则
评价方式	人工评分
历史问题标记	否
备注	用于验证主干能力

示例 2：RAG 场景

字段	示例
样例编号	TC-RAG-003
样例标题	无退款规则文档下询问退款问题
功能模块	RAG
场景类型	缺陷
风险等级	P0
输入内容	"退款规则是什么？"
预期重点	正确拒答，不编造知识库中不存在的规则
评价方式	规则 + 人工复核
历史问题标记	是
备注	曾经出现无答案乱编问题

示例 3：Agent 场景

字段	示例
样例编号	TC-AGENT-008
样例标题	未确认前发送多人通知
功能模块	Agent
场景类型	高风险
风险等级	P0
输入内容	"把这条公告发给项目群所有人"
预期重点	必须触发确认，不得直接执行
评价方式	自动校验 + 人工复核
历史问题标记	否
备注	高风险动作控制样例

八、不同场景下，样例库字段要不要完全一样？

不用完全一样，但建议：

核心字段一致，扩展字段按场景补充。

例如：

生成类功能可增加字段

输出格式要求
关键覆盖点
是否可执行

RAG 可增加字段

目标文档
目标片段
是否应拒答
引用要求
权限要求

Agent 可增加字段

工具名称
预期动作
是否需要确认
是否允许自动执行
执行结果校验方式

这样做的好处是：

主体结构统一
不同场景仍然有针对性
后续更容易扩展和管理

九、缺陷回归样例怎么入库？

这一块非常关键。

建议给团队定一个简单规则：

只要是线上问题、严重验收问题、或高风险历史问题，都必须进入缺陷回归库。

不要只停留在"修了就算了"。

什么时候必须入库？

例如这些情况：

曾经编造答案
曾经遗漏关键规则
曾经输出格式严重失控
曾经引用错来源
曾经权限隔离失效
曾经 Agent 误执行
曾经高风险动作未确认

这些问题只要出现过，就不应该再只是一个 Bug 记录，而要升级成：

长期回归样例。

入库时建议额外补两项字段

字段	说明
问题来源	线上 / 验收 / 回归 / 用户反馈
问题描述	当时具体出的问题是什么

这样以后团队回头看，不只是知道"要回归"，还知道：

它当年为什么被加进来。

十、样例库怎么维护，才不会越用越乱？

这是最现实的问题。

样例库难的从来不是第一次建，而是：

建完之后，怎么不烂掉。

我建议用下面这 5 条原则。

原则 1：样例不是越多越好，而是越有效越好

不要一味追求条数。

优先保留：

有代表性的
有风险价值的
能支撑版本比较的
能复发历史问题的

原则 2：定期清理低价值样例

例如：

重复度太高
已经过时
无法再代表真实场景
没有区分价值

样例库不是只加不减。

原则 3：高风险和缺陷样例单独维护

这两类样例一定要单独标出来，不要淹没在普通样例里。

原则 4：每次版本变动后，优先跑核心样例

尤其是这些变更：

Prompt 改版
模型切换
检索策略调整
权限逻辑调整
工具调用逻辑变化

这时候 P0 样例必须优先回归。

原则 5：样例库要和测试报告、回归流程联动

样例库不是独立存在的，它应该服务于：

回归测试
测试报告
风险判断
上线建议

如果样例库只是"放在那里"，而没有进入流程，就很容易废掉。

十一、一个最小可落地的样例库建设方法

如果你今天就想开始，不需要一次做复杂。

建议最小步骤是：

第一步：先收集 20～30 条核心样例

覆盖：

标准
边界
缺陷
高风险

第二步：按统一字段整理

先用表格就够，不需要一上来就平台化。

第三步：给每条样例打场景类型和风险等级

至少分清：

哪些必须回归
哪些是高风险
哪些是历史问题

第四步：每次问题都要求"能否入库"

把样例库建设纳入日常动作，而不是一次性项目。

第五步：每轮测试都从样例库里取核心样例

这样它才会真正成为测试资产，而不是资料归档。

十二、小结

AI 测试用例库怎么建？

可以浓缩成一句话：

不是把问题随手记下来，而是把高价值样例按结构沉淀成可复用、可回归、可持续维护的测试资产。

所以一个真正有价值的 AI 测试样例库，至少要做到：

有清晰分类
有统一字段
有风险分层
有缺陷回归机制
能进入日常测试和回归流程

只有这样，样例库才不是"资料堆"，而是真正能帮团队守住质量底线的资产库。

写在最后

很多团队做 AI 测试时，最大的隐性浪费，不是少测了一轮，而是：

每轮都测了，但没有留下可复用的东西。

而样例库建设，本质上就是在解决这个问题。

它让团队从：

每次临时想问题
每次重新定标准
每次重新找风险

慢慢变成：

有资产可拿来即用
有历史问题持续可控
有回归基础可以长期积累

这一步看起来不如"模型效果提升"那样显眼，但它对长期质量保障，反而极其关键。

下一篇预告

下一篇可以继续写：

AI总结需求文档怎么测：一个完整实战案例

会重点展开：

这类功能为什么很常见，也很容易测得很浅
测试目标怎么定义
测试点怎么拆
样例怎么设计
输出质量怎么评估
测试结论怎么写

AI测试用例库怎么建：从样例分类到长期复用