AI生成测试用例功能怎么测：一个完整实战案例

前两篇我们分别讲了两件事：

第一，AI 测试到底测什么。

第二，Prompt 为什么也需要测试。

如果说前两篇解决的是"怎么看待 AI 测试"，那这一篇开始，就进入真正的实战问题：

一个具体的 AI 功能，到底该怎么测？

这里我选一个最适合测试工程师入门、也最容易落地的场景：

AI 根据需求文档自动生成测试用例。

这个能力现在很常见。

很多测试平台、研发效能平台、AI 助手、甚至 IM 内嵌机器人，都在做这类功能。

表面上看，这个功能很简单：

输入一段需求
点击生成
AI 输出测试用例

但真正做测试时你会发现，问题远没有这么简单。

因为你不能只验证"有没有生成结果"，还必须判断：

生成的内容是否准确
是否覆盖关键场景
是否存在编造
是否真的可执行
是否适合作为测试资产使用

这篇文章就用这个场景，完整走一遍 AI 功能测试思路。

一、先明确：这个功能到底在测什么？

先不要急着写测试用例。

测试 AI 功能时，第一步不是直接点页面，而是先明确被测能力到底是什么。

以"AI 生成测试用例"为例，被测能力通常不是单一动作，而是一整套输出链路。

可以把它拆成下面这件事：

text 复制代码

输入需求信息
  ↓
AI理解需求内容
  ↓
识别功能点、规则、边界、异常
  ↓
组织成测试用例结构
  ↓
按指定格式输出

所以这个功能真正要测的，不只是"生成成功"，而是至少包括这几层：

是否理解了需求
是否抓到了核心业务规则
是否覆盖了正常、异常、边界场景
是否按要求输出字段
是否没有编造需求外内容
是否具备实际测试执行价值

这一步很重要。

因为如果你一开始就把预期写成：

成功生成测试用例

那后面的测试几乎没有意义。

二、一个真实可测的需求示例

为了让这篇文章更落地，我们先假设一个具体需求。

示例需求

text 复制代码

用户可以通过手机号和验证码登录系统。
验证码有效期为 5 分钟。
验证码错误超过 5 次后，账号锁定 10 分钟。
同一手机号 60 秒内最多发送 1 次验证码。
未注册手机号不可登录，页面提示"账号不存在"。

这是一个非常典型、也很适合拿来测试 AI 生成能力的需求。

因为它同时包含了：

主流程
时间限制
次数限制
错误处理
异常提示
边界规则

理论上，一个"还不错"的 AI，应该至少能从这里提炼出这些测试方向：

正常登录
验证码有效期
验证码输错次数限制
账号锁定逻辑
发送频率限制
未注册账号处理
提示文案校验
边界值场景

如果这些都没覆盖到，那输出质量就有问题。

三、这个功能的测试目标是什么？

测试之前，要先定义目标。

这类 AI 功能的测试目标，不应该写成：

验证 AI 是否可以生成测试用例。

这个目标太浅。

更合理的测试目标应该是：

验证 AI 是否能够基于输入需求，生成结构完整、内容准确、覆盖合理、可实际使用的测试用例。

可以继续细化成 5 个子目标：

1. 结构完整

是否按要求输出固定字段，例如：

用例标题
前置条件
测试步骤
预期结果
优先级

2. 内容准确

是否正确理解需求，没有误读业务规则。

3. 覆盖合理

是否覆盖正常、异常、边界场景，而不是只生成主流程。

4. 无幻觉

是否没有补充需求中根本没写的规则。

5. 可执行

生成的步骤和预期是否足够清晰，能被测试人员直接使用或轻量修改后使用。

这 5 点，基本就是这个功能的核心验收标准。

四、测试这类 AI 功能，第一步该怎么拆测试点？

很多测试同学第一次做 AI 功能测试时，容易卡在这里：

不知道测试点怎么拆。

其实你可以沿着 AI 输出链路拆，而不是沿着页面流程拆。

这里推荐一个很实用的拆法：分 6 个维度。

1. 输入测试

先测输入本身。

重点包括：

输入需求是否支持纯文本
长需求是否可处理
模糊需求是否可识别
缺失规则的需求会不会乱编
中英文混合是否影响理解
含表格或列表描述时是否能识别

这一层的核心是：

AI 对输入的理解起点是否稳定。

2. 需求理解测试

重点看 AI 是否真正理解了需求。

例如上面的登录需求里，AI 应该识别出这些规则：

登录方式是"手机号 + 验证码"
验证码有效期 5 分钟
错误超过 5 次锁定 10 分钟
60 秒内只能发 1 次验证码
未注册手机号不可登录

如果 AI 把"错误超过 5 次"理解成"5 次及以上立即锁定"，或者漏掉"60 秒限制"，那就是理解问题。

3. 场景覆盖测试

重点看生成的用例是否覆盖到该覆盖的场景。

至少应包括：

正常场景
异常场景
边界场景
提示文案场景
状态限制场景

很多 AI 输出表面看很完整，但实际只覆盖主流程。

这种内容不能算真正合格。

4. 输出结构测试

重点看格式是否稳定。

例如：

字段是否完整
是否固定顺序输出
表格格式是否正确
是否有缺列、空列、乱序
多次生成结构是否稳定

如果生成结果时而是表格，时而是分段文本，那接入产品后就很难用。

5. 输出质量测试

重点看内容是否能被真正使用。

例如：

测试步骤是否具体
预期结果是否明确
标题是否清晰
优先级是否基本合理
是否能指导实际测试执行

这是很多 AI 功能最容易"看起来不错，实则不够用"的地方。

6. 稳定性与回归测试

重点看同样输入多次生成时，质量是否波动过大。

不是要求一字不差，而是看：

核心规则是否稳定覆盖
输出结构是否基本一致
关键场景是否不会时有时无
改了 Prompt 后旧问题是否复发

这一步决定了这个功能能不能进入持续使用阶段。

五、AI 生成测试用例，最容易出现哪些问题？

这类功能的问题很典型，基本集中在下面几种。

1. 只覆盖主流程，不覆盖异常和边界

例如只生成：

正常登录成功
验证码输入正确

但没有覆盖：

验证码过期
错误次数过多
账号锁定
未注册手机号
发送频率限制

这种输出最常见，也最没有实战价值。

2. 需求理解不准确

例如把：

验证码错误超过 5 次后锁定

理解成：

错误 5 次就锁定

或者漏掉"锁定 10 分钟后恢复"的隐含验证方向。

3. 编造需求外规则

例如需求里没写"验证码长度 6 位"，但 AI 自己补了一条长度校验测试。

这类内容看起来很专业，但如果不是需求明确给出的规则，就属于幻觉或过度发挥。

4. 输出格式不稳定

同一个需求多次生成，有时是表格，有时是项目符号；有时字段齐全，有时缺少优先级。

这会直接影响后续复制、导出、接入系统。

5. 步骤不够可执行

例如只写：

输入正确验证码
检查结果

这种描述太粗，测试人员仍然需要大量人工重写。

6. 优先级不合理

例如把"正常登录"标成 P2，把"文案展示"标成 P0。

这类问题说明 AI 在业务判断上不够成熟。

六、怎么设计测试数据？

AI 功能测试里，测试数据设计非常关键。

因为如果你的输入样本都太标准、太干净，AI 往往会表现得很好。

真正的问题，通常出现在复杂输入里。

这里建议至少准备 5 类数据。

1. 标准完整需求

用于验证基础能力。

例如：

text 复制代码

用户可以通过手机号和验证码登录系统。
验证码有效期为 5 分钟。
验证码错误超过 5 次后，账号锁定 10 分钟。
同一手机号 60 秒内最多发送 1 次验证码。
未注册手机号不可登录，页面提示"账号不存在"。

预期：能输出相对完整的结构化测试用例。

2. 模糊需求

用于验证是否乱编。

例如：

text 复制代码

支持手机号登录。

预期：应提示信息不足，而不是自己补完验证码逻辑、限制规则等。

3. 长需求

用于验证复杂输入理解能力。

例如一个包含多模块、多规则、多状态流转的长 PRD。

预期：能提炼重点，但不应严重漏项。

4. 混合需求

用于验证抗噪声能力。

例如把需求、说明、备注、历史改动混在一起。

预期：能聚焦当前有效需求，不被历史无关信息干扰。

5. 冲突或缺失需求

用于验证边界判断能力。

例如：

text 复制代码

用户可通过手机号登录。
验证码相关规则待补充。

预期：明确指出规则缺失，而不是默认生成一套验证码时效和次数限制。

七、可以怎么写测试用例？

下面给一个适合这类 AI 功能的测试用例示例结构。

用例标题	输入特点	检查点	预期结果	优先级
标准需求生成测试用例	规则完整	结构、覆盖、准确性	输出完整测试用例表，覆盖主流程/异常/边界	P0
模糊需求生成测试用例	信息不足	是否编造	不乱编，提示缺失信息	P0
含次数限制需求	有明确次数规则	是否覆盖次数场景	生成输错次数与锁定用例	P0
含时效规则需求	有时间限制	是否覆盖时效边界	生成过期/未过期测试场景	P0
多次重复生成	同一输入重复执行	稳定性	核心测试点和结构基本一致	P1
指定表格输出	明确要求 Markdown 表格	格式遵循	固定字段表格输出	P1
混合噪声需求输入	含无关备注	抗干扰	聚焦有效需求，不明显跑偏	P1
缺失关键规则需求	规则不完整	边界控制	明确指出缺失信息，不补写业务规则	P0

这类表格的价值在于：

它不再只是测"功能是否能点通"，而是在测 AI 输出质量。

八、怎么评估 AI 输出质量？

AI 功能测试如果没有评估标准，很容易陷入一句话：

感觉还行。

这句话对上线没有帮助。

建议至少建立一个基础评分模型。

示例评分标准

评分项	分值	说明
需求理解准确性	25	是否正确理解核心规则
场景覆盖完整性	25	是否覆盖正常/异常/边界
输出结构完整性	15	字段是否齐全、格式是否稳定
内容可执行性	15	步骤和预期是否明确可用
无幻觉	10	是否没有编造需求外规则
稳定性	10	多次生成时质量是否波动可接受

总分 100 分。

一个简单判断方式

90 分以上：可直接进入候选上线版本
75～89 分：可用，但需要继续优化
60～74 分：存在明显风险，不建议直接上线
60 分以下：输出质量较差，需要重新设计 Prompt 或方案

评分的意义不是"绝对精确"，而是让团队对结果有一个统一判断框架。

九、一个示例：什么样的输出算合格，什么不算？

还是以上面的登录需求为例。

不太合格的输出

text 复制代码

1. 测试登录功能
2. 测试验证码是否正确
3. 测试错误验证码
4. 测试未注册用户

这个输出的问题很明显：

太粗
没字段
没步骤
没预期
没优先级
没边界值
没时间规则
没锁定逻辑

看起来"生成了"，但其实几乎不可用。

相对合格的输出应该至少像这样

用例标题	前置条件	测试步骤	预期结果	优先级
注册用户使用正确验证码登录成功	用户已注册，已收到有效验证码	输入正确手机号和有效验证码，点击登录	登录成功，进入首页	P0
验证码过期后登录失败	用户已注册，验证码已超过 5 分钟	输入正确手机号和过期验证码，点击登录	登录失败，提示验证码失效	P0
验证码连续输错超过 5 次账号锁定	用户已注册	连续输入错误验证码 6 次	第 6 次后账号被锁定 10 分钟，并有对应提示	P0
同一手机号 60 秒内重复发送验证码	用户已注册	60 秒内连续点击发送验证码	第二次发送失败，提示发送过于频繁	P1
未注册手机号登录失败	手机号未注册	输入未注册手机号并请求验证码登录	登录失败，提示"账号不存在"	P0

这个输出虽然仍然可能需要人工优化，但已经具备初步使用价值。

十、这个功能上线前，至少要关注哪些风险？

如果这是一个准备上线的 AI 功能，我建议至少关注下面 5 类风险。

1. 业务误导风险

AI 生成的用例看起来很像那么回事，但遗漏关键规则，导致测试覆盖不足。

2. 幻觉风险

AI 补充需求里没有的规则，误导测试人员写错用例。

3. 格式不稳定风险

输出结构不稳定，无法接入表格、导出、系统流转。

4. 质量波动风险

同一个需求今天生成得好，明天模型参数变了又退化。

5. 过度依赖风险

团队直接拿 AI 输出当正式测试资产，不做复核，导致问题被放大。

所以对这类功能，更合理的上线定位通常不是：

完全替代测试工程师写用例

而是：

作为测试设计辅助工具，提高初稿生成效率，但保留人工复核。

这个定位会更现实，也更利于控制质量风险。

十一、测试结论应该怎么写？

很多 AI 功能测试最后容易停在"功能基本可用"。

这句话太空泛。

更好的写法应该围绕质量结论来写。

例如：

示例测试结论

本轮测试覆盖标准需求、模糊需求、缺失规则需求、多次重复生成、格式指定输出等场景。

整体来看，AI 生成测试用例功能已具备基础可用性，能够基于明确需求生成结构化测试用例，并覆盖主要正常与部分异常场景。

当前主要问题包括：

对边界场景覆盖不够稳定；
个别情况下存在补充需求外规则的现象；
输出优先级判断不完全合理；
多次生成结果存在一定波动。

综合评估，当前版本适合作为测试设计辅助工具灰度使用，不建议在无人工复核前提下直接作为正式测试资产输出。

这样的结论，才真正具备上线参考价值。

十二、小结

AI 生成测试用例功能怎么测？

可以浓缩成一句话：

不是测它有没有生成内容，而是测它生成的内容能不能被真正使用。

所以测试这类功能时，重点不是页面链路，而是输出质量本身。

至少要覆盖这些维度：

需求理解是否准确
场景覆盖是否合理
输出结构是否稳定
内容是否可执行
是否存在幻觉
多次生成是否稳定

同时还要明确一个现实定位：

现阶段，大多数 AI 生成测试用例能力，更适合作为"辅助生成"而不是"完全替代"。

只有这样，测试结论才不会失真，功能上线预期也会更合理。

写在最后

如果你们团队也在尝试"AI 自动生成测试用例"，建议不要只关注两个问题：

能不能生成
看起来像不像用例

而是多问一步：

它真的覆盖关键场景了吗？
它有没有误导测试设计？
它的输出能不能稳定复用？
它需要人工改多少？
它是提效工具，还是可交付资产？

这几个问题，才真正决定这个功能有没有业务价值。

下一篇预告

下一篇继续写：

RAG知识库问答测试：如何判断 AI 是否真的基于文档回答

会重点展开：

RAG 系统的测试链路怎么拆
文档上传、解析、切片、检索、生成分别怎么测
如何验证答案真的来自文档
无答案场景为什么最容易暴露问题
权限隔离和引用溯源怎么验