把一份需求文档交给 AI ，几十秒后，前置条件、操作步骤和预期结果都有了。格式很整齐，数量也比人工拆解得快。

真正逐条审查时，测试人员却可能发现： AI 补了需求里没有的解锁方式，把模糊的时间边界写成了确定规则，还漏掉了多端并发这类真正高风险的场景。

这就是 AI 生成测试用例最容易带来的错觉：用例写完了，不代表测试设计完成了。

AI 和人工设计用例，差的不只是速度

人工设计通常从业务风险开始。测试人员会联系历史缺陷、系统状态、接口依赖和线上故障，再选边界值、决策表或状态迁移等设计方法。这个过程较慢，但其中包含了需求文档没写出来的项目上下文。

AI 的优势在另一边。它擅长识别需求文本中的对象、动作、条件和结果，再把这些语义元素组合成标准化草稿。它还能快速扩展正常、异常和边界场景，保持字段格式一致。

可它并不掌握业务事实。 NIST AI 600-1 把生成式 AI “自信地输出错误、虚假或偏离输入的内容”称为虚构，也就是常说的 AI 幻觉。用在测试设计中，它可能把“常见做法”补成“本系统规则”。

因此，测试人员的角色并没有简单地从编写者变成审核者。还要做三件事：决定给 AI 哪些可信材料，规定它不能越过的边界，并对正式进入用例库的内容负责。

先给 AI 画边界，再让它生成

一句“请根据需求生成完整的测试用例”，几乎把所有判断空间都留给了模型。需求越模糊， AI 自行补全的内容越多。

无论使用对话工具，还是把生成流程做成 skill agent ，都应先固定一份“生成合同”。下面这段可直接作为起点：

任务：根据指定需求生成可审核的测试用例草稿。

事实来源：只允许使用需求 ID 、验收条件、接口契约和已确认业务规则。

禁止行为：不得虚构字段、接口、错误码、页面文案和业务规则。

不确定项：无法从材料证明的内容写入“待确认问题”，不生成确定预期。

输出字段：用例 ID 、来源 ID 、风险、前置条件、步骤、可观测预期、数据恢复方式、内容类型。

内容类型：只能是“需求明示”“逻辑推导”或“风险建议”。

生成前：先列出需求歧义和缺失信息，再生成用例。

这份合同解决了两个问题。一是每条用例都能追回需求、风险或已确认规则；二是 AI 遇到空白时必须停下来提问，不再用概率最高的说法填空。

如果平台支持 JSON Schema ，可以用严格结构锁定输出字段和枚举值。 OpenAI 文档对 Structured Outputs 的定义是让模型输出匹配指定 schema 。

但它只约束“形状”，字段里的业务事实仍需要核验。

skill agent 还应固定版本信息：模型版本、生成规则版本、提示模板版本和知识库快照。

当模型或规则改变时，用一组已人工审定的需求与用例做回归评估，检查幻觉、漏项和格式退化。 ISTQB CT-GenAI 也把评估生成结果、迭代优化提示和管理 LLM 风险列为独立能力。

一个登录需求，怎样从“看起来对”审到“有依据”

看一个简化案例。以下需求和用例均为教学示例，不代表真实系统规则。

REQ-LOGIN-017：同一账号在 10 分钟内连续输错密码 5 次后，账号锁定 30 分钟。锁定期间，即使密码正确也拒绝登录，页面统一显示“账号或密码错误”。

AI 很容易生成“连续错误 5 次后锁定”这条主路径，同时补出“登录成功后清空错误次数”和“通过短信提前解锁”。后两条都很合理，却找不到需求依据。正确处理是把它们移到“待确认问题”，不让猜测伪装成预期结果。

接着检查 AI 没写的地方。经过人工审核后，这组草稿至少应区分下面几类内容：

-可直接执行： 10 分钟内输错 4 次，账号不锁定；第 5 次输错后立即锁定。

-可直接执行：账号已锁定，输入正确密码，登录仍被拒绝，且页面只显示统一提示。

-待确认问题：第 1 次失败后刚好到 10 分钟又发生第 5 次失败，是否算在窗口内？

-风险建议：同一账号在两台设备上同时失败，计数是否原子累加？这需要产品和开发确认实现口径。

-恢复要求：每条用例结束后清理失败计数和锁定状态，避免下一条用例受污染。

审核时不必从头重写。沿着五个问题逐条过：来源能否追溯，前置状态是否可建立，步骤是否可执行，预期结果是否可观测，数据是否能恢复。再用边界值、决策表和状态迁移等方法补风险。

ISTQB CTFL v4.0.1 要求在需求、风险、测试用例、测试结果和缺陷之间保持可追溯性。这条原则放到 AI 生成场景更实用：一条找不到来源的用例，应该先降级为候选项，不能用整齐格式换取“已覆盖”的结论。

AI 用例要先进候选池，不要直接进基线库

如果 AI 每次都重新生成一批用例，再把旧内容整批覆盖，用例库很快会失去稳定 ID 、历史审核记录和缺陷关联。之后即使数量更多，团队也难以知道哪条用例真正变了。

更稳妥的做法是把 AI 输出当作候选资产，并让它经过明确状态：

1 AI 草稿

保留来源、生成配置和未确认项

2 人工审核

删除虚构内容，补边界、风险和恢复

3 业务确认

处理需求歧义和跨角色规则

4 基线用例

分配稳定 ID ，纳入执行与回归计划

5 变更或退役

按需求差异更新，保留审核历史

这条流程的关键是“差异更新”。需求变了， agent 应该输出新增、修改、失效和待确认项，而不是又给一份无法对比的全量用例。

每条候选用例至少要保留需求版本、来源 ID 、内容类型、模型版本、 skill 或提示版本、生成时间、审核人和审核结论。保留这些字段的目的很实际：出问题时能回答它从哪里来，谁同意它进库，哪次变更影响了它。

管理效果也别只看“AI 一次生成了多少条”。更值得记录的是人工接受率、无依据内容的驳回原因、审核耗时、需求覆盖缺口，以及漏测缺陷对应的用例缺失。指标要帮团队改规则，不能只用来证明 AI 使用得频繁。

如果团队还没有稳定的需求 ID 、审核责任和变更记录，暂时不要追求全量自动生成。先选一条边界清楚的需求，用固定合同生成草稿，完成一次人工审核和差异入库。

回到开头那批看起来很完整的用例。测试人员真正要审的，是每条结论有没有依据，哪些风险还没有被表达，以及这份草稿是否有资格成为团队的长期测试资产。

更多软件测试相关推荐：

软件测试更多干货文章

软件测试就业培训

  文章来源：网络  版权归原作者所有

上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8103)，我们将立即处理