AI生成测试用例最常见的8类问题：很多团队只测了“能生成”

很多团队第一次把 AI 用到测试工作里，最常见的场景就是：

让 AI 根据需求生成测试用例。

这个场景非常容易理解，也非常容易演示。

输入一段需求，AI 很快就能输出：

• 用例标题
• 前置条件
• 操作步骤
• 预期结果
• 优先级
• 测试类型

看起来很像一个“测试用例生成助手”。

所以很多团队验证这类能力时，容易停留在一个很浅的层面：

能不能生成？

只要 AI 能输出一张表，字段看起来完整，语言也还通顺，就觉得这个功能基本可用。

但真正进入测试工作后，你会发现：

AI 能生成测试用例，不代表生成的用例真的能用。

它可能：

• 漏掉关键规则
• 边界场景不足
• 异常场景太少
• 用例步骤不可执行
• 预期结果太空
• 编造需求里没有的规则
• 优先级乱标
• 看起来数量很多，但覆盖质量不高

所以测试这类 AI 功能，最重要的不是看它“有没有生成”，而是要看：

生成的用例是否准确、完整、可执行、可回归、能真正帮助测试工作。

这篇文章就专门拆解：

AI 生成测试用例最常见的 8 类问题，以及测试应该怎么盯。

---

一、先说结论：AI生成测试用例，最怕“看起来很完整”

AI 生成测试用例最大的迷惑性在于：

它很容易生成一堆看起来像样的内容。

比如你输入一个登录需求，它可以很快生成：

• 正常登录
• 密码错误
• 用户名为空
• 密码为空
• 验证码错误
• 登录成功跳转
• 登录失败提示

这些用例看起来都没问题。

但如果需求里真正关键的规则是：

• 验证码 60 秒内只能发送一次
• 验证码有效期 5 分钟
• 验证码错误超过 5 次锁定 10 分钟
• 同一账号一天最多发送 20 次验证码
• 已锁定账号不能继续登录

AI 如果只生成一些泛泛的登录用例，就明显不够。

这就是 AI 生成测试用例最常见的问题：

数量不少，但关键规则没覆盖。

所以测试这类功能时，不能只看输出数量，也不能只看格式是否完整，而要回到需求本身核对：

• 关键规则是否覆盖
• 边界条件是否覆盖
• 异常流程是否覆盖
• 业务限制是否覆盖
• 生成内容是否存在编造
• 用例是否真的可执行

---

二、问题1：只覆盖主流程，漏掉关键规则

这是最常见的问题。

AI 很容易抓住需求里的主流程，但漏掉真正影响测试质量的细节规则。

例如需求写：

用户可通过手机号和验证码登录。
验证码有效期为 5 分钟。
同一手机号 60 秒内只能发送一次验证码。
验证码错误超过 5 次后，账号锁定 10 分钟。

AI 可能生成：

用例标题	预期结果
手机号验证码登录成功	成功登录系统
验证码错误登录失败	提示验证码错误
手机号为空登录失败	提示手机号不能为空
验证码为空登录失败	提示验证码不能为空

这些用例不是错，但明显不完整。

它漏掉了：

• 验证码有效期 5 分钟
• 60 秒发送频率限制
• 错误超过 5 次锁定
• 锁定 10 分钟后恢复

这些才是测试真正要盯住的业务规则。

测试应该怎么盯？

对 AI 输出做一张“需求规则覆盖表”。

需求规则	是否生成用例	问题
验证码有效期 5 分钟	否	漏覆盖
60 秒内只能发送一次	否	漏覆盖
错误超过 5 次锁定	否	漏覆盖
锁定 10 分钟	否	漏覆盖
手机号为空校验	是	已覆盖

判断标准

不要只看 AI 生成了多少条，而要看：

需求里的关键规则是否被逐条映射成测试用例。

---

三、问题2：边界值用例不足

边界值是测试用例设计里的核心能力，但 AI 很容易只生成“正常值”和“异常值”，不生成真正的边界。

例如规则是：

报销金额超过 5000 元需直属上级审批，超过 20000 元需财务复审。

AI 可能生成：

• 报销 3000 元
• 报销 8000 元
• 报销 30000 元

这些能覆盖大概范围，但不够精确。

真正应该覆盖：

输入金额	目的
4999.99	不触发直属上级审批
5000	验证等于阈值是否触发
5000.01	验证超过阈值
19999.99	不触发财务复审
20000	验证等于阈值
20000.01	验证超过阈值

如果 AI 不生成这些边界值，测试价值就会下降。

测试应该怎么盯？

凡是需求里出现以下信息，都要检查 AI 是否生成边界用例：

• 超过 / 不超过
• 大于 / 小于
• 大于等于 / 小于等于
• 最多 / 最少
• 不少于 / 不高于
• 有效期
• 次数限制
• 金额限制
• 时间限制
• 长度限制

判断标准

边界类规则至少要覆盖：

阈值前、阈值点、阈值后。

如果只有一个“大概正常值”和一个“大概异常值”，不算充分。

---

四、问题3：异常场景太泛，不贴合业务

AI 很容易生成一些通用异常用例，比如：

• 输入为空
• 输入格式错误
• 网络异常
• 系统异常
• 权限不足

这些异常场景不是没用，但如果全部停留在通用层面，就会显得很“模板化”。

例如一个审批需求，真正重要的异常可能是：

• 审批人为空
• 审批节点被删除
• 审批中申请人撤回
• 审批人离职
• 下一节点无法找到
• 被驳回后能否重新提交
• 审批流版本变更后旧单据怎么处理

如果 AI 只生成“系统异常提示失败”，就没有抓到业务风险。

测试应该怎么盯？

检查异常场景是否来自需求本身，而不是泛泛模板。

可以按下面方式判断：

异常类型	是否贴合业务
字段为空	基础异常
接口失败	技术异常
审批节点缺失	业务异常
审批人离职	业务异常
被驳回后重新提交	业务异常
审批流变更影响历史单据	高价值业务异常

判断标准

异常用例不能只停留在“输入错误、系统失败”，还要覆盖：

业务流程中真正可能出错的状态和分支。

---

五、问题4：用例步骤不可执行

AI 生成的用例有时看起来完整，但测试同学拿去执行时会发现：

不知道怎么测。

例如：

用例标题	操作步骤	预期结果
验证账号锁定规则	输入多次错误验证码	账号被锁定

这个用例太粗。

问题在于：

• 输入几次？
• 是连续输入还是间隔输入？
• 第几次触发锁定？
• 锁定后再输入正确验证码会怎样？
• 锁定多久恢复？
• 用哪个账号？
• 是否需要提前清理状态？

更可执行的写法应该是：

字段	内容
用例标题	验证验证码连续错误 6 次后账号锁定
前置条件	用户账号正常，验证码登录功能可用
操作步骤	1. 输入正确手机号；2. 连续输入错误验证码 5 次；3. 第 6 次继续输入错误验证码；4. 再输入正确验证码尝试登录
预期结果	第 6 次错误后账号锁定；锁定期间即使输入正确验证码也不能登录；提示锁定 10 分钟

测试应该怎么盯？

检查 AI 输出是否具备执行条件：

• 前置条件是否明确
• 步骤是否可操作
• 输入数据是否具体
• 操作顺序是否清楚
• 预期结果是否可验证
• 是否说明状态变化
• 是否支持复测和回归

判断标准

一条好用例不是“看起来像用例”，而是：

测试人员照着步骤能执行，执行后能判断通过或失败。

---

六、问题5：预期结果太空

AI 生成用例时，经常把预期结果写得非常泛。

例如：

• 系统提示错误
• 页面显示正常
• 数据保存成功
• 流程执行成功
• 返回正确结果
• 操作失败并提示

这些预期结果最大的问题是：

不可验证。

比如“提示错误”，到底提示什么？

如果需求要求：

验证码错误时提示“验证码错误，请重新输入”。

那预期结果就不能只写：

系统提示错误。

应该写：

页面提示“验证码错误，请重新输入”，用户仍停留在登录页，登录状态不变。

测试应该怎么盯？

检查预期结果是否包含：

• 页面变化
• 文案提示
• 状态变化
• 数据变化
• 接口返回
• 权限变化
• 流程流转
• 后续影响

判断标准

预期结果必须能支撑判断：

这个用例到底算通过还是失败。

如果预期结果写得太泛，说明 AI 输出还不能直接作为正式用例使用。

---

七、问题6：编造需求里没有的规则

AI 为了让用例看起来完整，经常会补一些需求里没有写的规则。

例如需求只写：

用户可通过手机号和验证码登录。

AI 生成：

• 验证码有效期为 5 分钟
• 密码错误超过 5 次锁定账号
• 手机号必须实名认证
• 同一设备每日最多发送 10 次验证码

这些规则听起来都合理，但如果需求里没写，就是编造。

这类问题很危险。

因为测试用例会反过来影响团队对需求的理解。
如果 AI 编造了规则，测试同学可能会误以为需求里有这个要求，导致测试、研发、产品沟通成本上升。

测试应该怎么盯？

对 AI 生成的用例做“需求依据核对”。

AI生成内容	需求是否有依据	结论
验证码有效期 5 分钟	无	编造
手机号为空提示	有	通过
错误超过 5 次锁定	无	编造
发送验证码按钮倒计时	需求隐含但需确认	待确认

判断标准

AI 可以提出“建议补充测试点”，但必须区分：

• 需求明确写了；
• 根据需求可合理推导；
• 需要产品确认；
• AI 自行编造。

比较好的输出方式是：

以下为基于需求明确规则生成的用例；以下为建议补充确认项。

---

八、问题7：优先级标注不合理

很多 AI 生成测试用例时，会自动给 P0 / P1 / P2。

但优先级经常比较随意。

例如：

• 登录成功被标 P2
• 验证码为空被标 P0
• 账号锁定规则被标 P2
• 权限绕过场景被标 P1

这会影响测试排期和回归优先级。

测试应该怎么盯？

检查优先级是否基于：

• 业务主流程
• 用户影响面
• 出错后果
• 安全风险
• 数据风险
• 是否阻断上线
• 是否历史高发问题

建议规则

优先级	适用场景
P0	主流程、高风险、安全、权限、资金、数据一致性
P1	重要分支、常见异常、核心业务规则
P2	低频场景、体验问题、提示文案、非核心边界

判断标准

优先级不是装饰字段，而是测试执行策略的一部分。

如果 AI 随机标优先级，就不能直接进入正式用例库。

---

九、问题8：数量很多，但覆盖重复

AI 很容易为了显得“全面”，生成很多重复用例。

例如：

• 手机号为空
• 手机号不输入
• 手机号字段为空
• 未填写手机号
• 手机号为空点击登录

这几条本质上是同一个测试点。

如果 AI 一次生成 50 条用例，但里面有 20 条重复，实际价值并不高。

测试应该怎么盯？

检查用例是否存在：

• 标题重复
• 步骤重复
• 预期重复
• 测试目的重复
• 仅换了表达方式

可以用“测试点去重”的方式评估。

测试点	关联用例数	是否重复
手机号为空校验	5	重复过多
验证码为空校验	3	可合并
错误次数锁定	0	漏覆盖
发送频率限制	0	漏覆盖

判断标准

AI 生成用例不是越多越好，而是：

覆盖更多有效测试点，而不是堆更多相似标题。

---

十、AI生成测试用例验收检查表

可以把上面 8 类问题整理成一张检查表。

检查项	重点问题	风险等级
规则覆盖	是否漏掉关键业务规则	P0/P1
边界值	是否覆盖阈值前、中、后	P1
异常场景	是否贴合业务异常	P1
可执行性	步骤是否具体可操作	P1
预期结果	是否清晰可验证	P1
无幻觉	是否编造需求外规则	P0
优先级	P0/P1/P2 是否合理	P2
去重质量	是否大量重复堆数量	P2

上线前至少要重点确认：

• 不编造需求外规则；
• 不遗漏 P0 级关键规则；
• 主流程、边界、异常都能覆盖；
• 输出用例可执行、可验证；
• 重复率不能过高。

---

十一、测试结论怎么写？

不要只写：

AI 可以生成测试用例，功能基本可用。

更好的写法应该是：

本轮测试覆盖登录、审批、报销、权限控制等典型需求场景，重点验证 AI 生成测试用例的规则覆盖、边界值设计、异常场景设计、用例可执行性、预期结果清晰度和无幻觉能力。

整体来看，当前版本能够基于标准需求生成结构化测试用例，字段完整性较好，适合作为测试用例初稿生成工具使用。

当前主要问题包括：

1. 对金额、次数、时间等细粒度规则的边界值覆盖不足；
2. 异常场景偏通用，业务异常提炼不够；
3. 个别场景存在需求外规则编造；
4. 部分用例步骤和预期结果过于笼统，执行性不足；
5. 生成数量较多，但存在一定重复。

综合评估，当前版本建议定位为“测试用例草稿辅助生成”，不建议直接写入正式用例库。正式入库前需由测试人员复核规则依据、边界覆盖和预期结果。

这样的结论才真正有业务价值。

---

十二、小结

AI 生成测试用例最常见的问题，可以归纳为 8 类：

1. 只覆盖主流程，漏掉关键规则；
2. 边界值用例不足；
3. 异常场景太泛，不贴合业务；
4. 用例步骤不可执行；
5. 预期结果太空；
6. 编造需求里没有的规则；
7. 优先级标注不合理；
8. 数量很多，但覆盖重复。

所以测试这类功能时，不能只问：

能不能生成测试用例？

而要问：

生成的用例是否真的能帮测试人员提升质量和效率？

AI 生成测试用例最适合的定位，不是直接替代测试工程师，而是：

生成初稿，辅助补充思路，再由测试人员确认和优化。

---

写在最后

AI 生成测试用例是一个非常适合测试团队尝试的 AI 场景。

因为它贴近日常工作，价值容易感知，也很适合做 AI 测试能力的起点。

但它也最容易被高估。

看起来生成了几十条用例，不代表真的覆盖充分。
格式像测试用例，不代表可以直接执行。
语言很专业，不代表没有编造。

测试工程师在这里的价值不是被 AI 替代，而是负责判断：

• 哪些用例有价值；
• 哪些规则漏掉了；
• 哪些内容是编的；
• 哪些场景需要补；
• 哪些用例可以进入正式资产库。

一句话：

AI 可以帮你更快生成用例，但不能替你判断测试质量。