ARTICLE · 1033504
手把手教你用AI生成测试用例:从需求文档到用例落地
“老师，网上都说AI能生成测试用例，我试了一下，丢给ChatGPT一份需求文档，它确实吐了一堆东西出来，但看着挺像样，用起来全是坑。到底哪里出了问题？”这个问题太典型了，大家卡住的往往不是“不会用AI”，而是不知道一条完整的链路长什么样。今天我就把这条链路完整拆开，从你手里那份PRD开始，一步一步走到可执行的测试用例。照着做，一小时内就能跑通第一个项目。
你最终要做出什么
在开始之前，先看清楚目标。一条完整的“需求文档→测试用例”链路，产出应该是这样的：
一份结构化的测试需求清单（从PRD里抽出来的功能模块、API端点、业务规则、边界条件）
一套可执行的测试用例（带明确的输入数据、操作步骤、预期结果、优先级）
一份覆盖率分析（哪些场景覆盖了，哪些没覆盖，为什么）
不是让AI“写一堆用例给你看”，而是让AI帮你把需求文档转化成可验证的测试资产。这个认知摆正了，后面才不会走偏。
第一步：喂文档——80%的质量在这一步就决定了
我见过最多的错误，就是直接把Word文档或者PDF截图丢给AI，然后抱怨“生成的东西没法用”。文档质量决定生成质量，这一条没有例外。
文档应该长什么样
格式优先用Markdown。 PRD用Markdown写，标题层级用＃＃和＃＃＃，功能点用列表，表格保留。模型对Markdown的结构理解最准。
接口文档导出OpenAPI JSON。 如果你的接口文档是手写的Excel，先转成OpenAPI 3.0格式，不然字段类型和必填标记经常识别错。
把“模糊词”改成“可验证的断言”。 PRD里写“系统应返回友好提示”，AI没法生成可验证的断言。它只能自己补一个，结果就是用例跑通了但断言跟实际不符。凡是涉及返回内容的描述，写具体：状态码、响应字段名、错误码范围。
第二步：让AI先“读”需求，而不是直接“写”用例
这一步很多人跳过了，但它是整个链路里最关键的环节。直接把需求丢给AI说“给我生成测试用例”，AI会跳过“理解”阶段，直接进入“编造”阶段。结果就是看似合理但经不起推敲的东西。正确的做法是：分两步走。先让AI解析需求，你确认无误后，再让它生成用例。
需求解析Prompt模板
你是一个资深测试工程师，擅长需求分析和测试设计。请阅读以下需求文档，输出一份结构化的测试需求清单，包含：
功能模块列表：文档中涉及哪些独立的功能模块？
API端点清单：涉及哪些接口？每个接口的路径、方法、核心参数是什么？
业务规则分类：按验证规则、安全规则、流程规则、约束规则分类列出。
边界条件分类：按值边界、格式边界、长度边界、数量边界、时间边界分类列出。
需求缺口与逻辑不闭环：文档中哪些地方描述模糊、缺失或自相矛盾？需要人工补充的信息是什么？
第三步：写Prompt——让AI生成真正可用的用例
需求解析确认后，进入用例生成。这一步的核心是：别让AI自由发挥。一个合格的用例生成Prompt，至少包含四层信息：角色、任务、输入材料、输出格式。
要求
用例格式：每条用例包含以下字段——用例ID、所属模块、用例标题、前置条件、测试步骤、输入数据、预期结果、优先级（P0/P1/P2）、测试类型（功能/边界/异常/安全）。
覆盖维度：每个功能点至少覆盖——正常流程（Happy Path）、等价类边界、异常输入、权限/安全场景。
优先级规则：核心业务主流程标P0；重要异常场景标P1；体验类/边缘场景标P2。
避免重复：同一场景不要生成多条语义相同的用例。
标注依据：每条用例的“预期结果”应能追溯到需求文档中的某条规则或字段定义。
一个关键技巧：让AI“先列框架，再填内容”
直接让AI一次性生成几十条用例，它容易在后半段“偷懒”——用例变短、断言模糊、边界场景简化。更好的做法是两轮生成：
第一轮：只让AI列出用例标题和优先级，不展开细节。 第二轮：选定要生成的用例（比如优先P0和P1），让AI逐条展开完整内容。
这样你可以在第一轮就过滤掉重复和低价值的用例，第二轮集中让AI把高质量的用例写透。
第四步：验证——AI生成的东西，凭什么信？
这一步是很多教程不会告诉你的，但它是区分“会用AI”和“被AI坑”的分水岭。AI会出错：漏场景、理解偏差、断言不合理，甚至有“幻觉”——生成一条看起来完全合理但实际不存在的规则。
三层验证法
第一层：溯源验证（抽检） 随机抽取20%的用例，逐条对照需求文档，检查“预期结果”是否能在文档中找到依据。
第二层：场景验证（全量） 把所有用例的“测试类型”列出来，做一次分布统计。如果发现90%都是“功能”类型，几乎没有“边界”和“异常”，说明AI偷懒了，需要重新调整Prompt补生成。
第三层：执行验证（抽样） 选10条P0用例，实际跑一遍。不要求全部通过，但如果大量用例执行后结果与预期完全不符，说明需求理解出了系统性问题，需要回到第二步重新解析。
一个真实的反面案例
我有个学员，用AI生成了一套登录模块的用例，看着挺全。结果上线后漏测了一个场景：用户连续输错密码3次后，账户被锁定，但锁定期间用正确密码也无法登录，用户以为密码错了，继续尝试，导致锁定时间被重置。
AI没有生成这条用例，因为需求文档里只写了“密码错误3次锁定账户”，没写“锁定期间的正确密码尝试是否重置计时器”。
这就是AI的盲区：它只能基于你给的信息做推理，不会替你发现“信息本身就不完整”。
这也是为什么第二步的“需求缺口分析”如此重要。
第五步：落地——从用例到可执行资产
生成的用例如果只躺在文档里，价值为零。你需要把它变成可执行、可管理、可追溯的测试资产。
三条落地路径
路径一：导出到测试管理平台 把AI生成的用例导出为Excel或CSV，导入到你的测试管理工具（TestRail、PingCode、ONES等）。如果团队用的是支持AI辅助用例生成的一体化平台，可以直接在平台内完成“需求→用例→执行→报告”的闭环。
路径二：生成自动化脚本 在Prompt中追加要求：“同时输出对应的Pytest测试代码，使用requests库发送HTTP请求，包含断言和参数化。”AI可以直接产出可运行的接口测试脚本。我上周跑的一个电商中台项目，AI同步生成了47条接口用例，覆盖正常流、缺参异常、空值边界、超长边界、无认证测试。
路径三：接入CI/CD 把生成的自动化脚本提交到Git仓库，通过Jenkins或GitHub Actions触发执行。AI生成的用例ID可以和CI流水线中的失败用例关联，形成反馈循环：执行结果→失败分析→优化Prompt→重新生成。
学员最容易踩的3个坑
坑一：文档太烂，怪AI不行。 我反复强调：文档质量决定生成质量。Word里的嵌套列表、PDF里的表格、模糊的“友好提示”，都是AI的杀手。先花20分钟整理文档，能省2小时返工。
坑二：生成完不验证，直接提交。 AI生成的用例必须经过溯源验证。我见过学员直接把AI生成的用例当“完成品”提交给团队，结果评审时被挑出一堆问题，反而比手写还慢。
坑三：追求“全自动”，忘了“人机协同”。 目前没有任何一个工具能实现从PRD到可执行用例的完全无人干预。正确的模式是：AI生成初稿 → 人工精修 → AI补充 → 人工确认。 人工的价值不在于“写”，在于“判断”。
最后
AI生成测试用例这件事，工具和方法都不是门槛，真正的门槛是“判断力”。
AI能帮你枚举场景，但判断哪些场景真正重要、哪些断言是合理的、哪些Bug必须修——这些是人的价值。
你过去对业务的理解、对质量的敏感度，AI替代不了。你要做的，是给这些能力装上一个AI引擎。
如果你也想系统学习AI测试，欢迎来领取免费试听课，从工具到项目实战，带你亲手用AI生成一套测试用例，感受一下它到底能帮你做什么、不能帮你做什么。
联系方式：13539280278
微信号：Derive203003
QQ号：358771433
多测师官网：www.duoceshi.net