1. 为什么需要AI驱动用例生成：从两条完全不同的语言体系说起
我见过的绝大多数测试团队，都卡在同一个地方：需求文档写了一大堆，测试用例却少得可怜。产品经理交付的需求描述，是人话，带上下文、带业务背景、带隐含假设；而测试用例要面对的，是操作步骤、输入数据、预期结果、边界条件。这两者之间隔着一道巨大的翻译鸿沟——把一段“用户登录后可以看到自己的订单列表并按状态筛选”的需求描述，变成“输入正确用户名密码点击登录，断言页面出现订单列表，点击待付款状态，断言列表被过滤”这样的可执行操作，中间需要的不只是语言转换，还有对业务逻辑、系统边界、异常路径的理解。
人工翻译这道鸿沟，成本一直很高。我见过一个上千条用例的大型系统，测试团队光是把最近一个季度的需求变更同步到用例库里，就花了三周。更麻烦的是，需求描述里的很多东西是模糊的——比如“用户可以修改订单地址”，这句话没有说地址在哪些状态下能改，哪些状态下不能改，改了之后对已生成的面单有什么影响。这些模糊点，传统做法靠测试人员自己去问、去猜、去翻历史缺陷记录。问得细的团队，用例质量就高；问得粗的，上线就出事故。
AI驱动测试用例生成，我个人的理解，本质上是把这道翻译与补全工作交给大语言模型去做。它读入需求描述，理解业务语义，结合你给它的系统上下文、历史用例风格、测试规范，输出结构化测试用例，甚至直接生成可执行的自动化脚本。它的价值不是取代测试人员，而是把测试人员从“逐条翻译需求”的体力活里解放出来，让他们把时间花在真正需要判断力的地方——比如评审AI生成了哪些场景，补哪些它想不到的边界，判断哪些用例优先级最高。
这套流程适合谁？适合已经有明确需求文档但用例维护跟不上迭代速度的团队，适合刚启动自动化测试但脚本编写效率低下的项目，也适合想统一团队用例规范、减少个人风格差异的测试组织。哪怕你不是测试工程师，只要你在做任何“把描述变成操作步骤”的工作——比如运维把故障处理手册变成执行脚本，运营把活动规则变成配置检查点——这套方法论都能迁移过去。核心就一句话：学会用AI处理结构化程度低、但规则性强的转换任务。
2. 核心思路拆解：一条需求是怎么变成一条可执行用例的
2.1 先想清楚输入输出，别一上来就调模型
很多人在做AI用例生成的时候，第一个冲动是“我把需求文档拖进对话框，让它给我生成用例”。这么做出来的东西，偶尔能看，大多数时候不能用。问题不在模型能力，在于输入太随意、输出没约束。
我建议先把流程想成一条流水线，而不是一次魔法对话。流水线的输入是需求描述，输出是一个可执行的测试用例对象。这个对象至少要有这么几个字段：用例编号、前置条件、操作步骤（步骤之间要有明确的执行顺序）、测试数据（输入值、期望值）、预期结果、优先级、自动化脚本的映射信息（比如元素定位、接口路径）。
有了这个结构，你才知道每一步要让AI做什么。我把整条链路拆成四层：
第一层是需求理解层。把原始需求描述做结构化清洗，提取出用户角色、操作动作、业务对象、规则约束这四个要素。这一层解决的是“需求到底说了什么”的问题。比如“用户可以修改订单地址”这句，用户角色是“已登录的用户”，操作动作是“修改”，业务对象是“订单地址”，规则约束呢？需求文本里没有，那就标记为待确认，而不是让AI瞎猜。
第二层是测试场景识别层。基于理解结果，展开测试场景。这一步最考验技巧——要让AI从一条正向路径推出变体：正常路径、分支路径、异常路径、边界路径。不是让它自由发散，而是给它场景模板。比如对“修改”这个动作，天然就有：修改成功、修改后保存失败、修改内容为空、修改内容超长、修改时无权限、修改时系统异常。这些维度是测试方法论沉淀下来的，AI只是按你的框架去填充。
第三层是用例生成层。把识别出的场景逐条展开成完整用例文本，包含操作步骤、测试数据、预期结果。这一层要绑定你的团队格式规范，不能让AI自由发挥。我在后面会给出可直接复用的Prompt模板，这一步做扎实了，生成质量会非常稳。
第四层是可执行化层。把用例文本转换成自动化脚本。这里有两个关键步骤：一是把自然语言步骤映射到测试框架的操作命令，比如“点击登录按钮”映射为点击操作加元素定位；二是把测试数据写入脚本变量。很多失败的项目就死在最后这一步——用例生成得挺好，一转脚本全是断裂的定位符。
2.2 为什么说“上下文”比“模型参数”更重要
坊间有个误解，觉得生成结果好不好全看选了什么模型、温度参数设了多少。我实测下来，决定质量的从来不是参数，是你给模型的上下文质量。
一份好的上下文，至少包含五块内容：需求原文、系统规则说明、历史用例范本、输出格式模板、测试数据字典。系统规则说明尤其重要。比如你这个系统里，订单有哪几种状态、地址修改有没有频次限制、哪些字段校验是后端强校验，这些不告诉模型，它就只能基于通用常识去猜，而通用常识在这个垂直系统里经常是错的。
历史用例范本的作用更大。大语言模型的生成方式本质上是在模仿“相似输入对应的相似输出”。你给三条高质量的、人工维护的历史用例作为范本，告诉它“我团队写用例是这个风格”，它产出的结果就跟着严谨。我给团队落地的时候做过对照：同样一个需求，不给范本直接生成，出来的用例是“教科书风格”，边界条件寥寥无几；给了两条带前置条件和精确测试数据的范本之后，生成的用例几乎可以直接评审通过。
所以这一篇指南里最想强调的思路是：AI用例生成不是“让AI替你思考”，而是“你把思考框架搭好，让AI替你执行翻译”。你搭的框架越清晰，执行出来的结果越稳定。
3. 实操过程与核心环节实现：从零搭一条生成链路
3.1 最小链路怎么搭：三个组件就够了
这个方案不需要引入多复杂的系统，一条最小链路只要三部分：需求输入整理环节、大语言模型调用中间层、输出解析与校验工具。
需求输入整理环节，就是把原始需求描述按前面说的四要素模板，转成AI能稳定理解的结构。这一步我强烈建议做成一个固定的输入模板，而不是直接把产品经理的需求文档丢进去。原因很简单：需求文档里通常有大段背景描述、历史说明、甚至讨论记录，AI抓取关键要素时会抓偏。你手动或者让AI先做一次抽取，把“角色、动作、对象、约束”抽出来填进模板，后面的生成质量会明显提升。
大语言模型调用中间层，就是写一段脚本调用通用大语言模型的API，把组装好的Prompt发过去，接收返回结果。不需要在本地部署模型，也不需要调复杂的微调流程。我实测下来，用多数主流商用API或者开源模型的对话接口，都可以达到生产可用的效果。
输出解析与校验工具，是用来解决“AI返回格式不稳定”这个老大难问题的。我建议在Prompt里强制要求AI以JSON格式返回用例集，然后在代码里做一次结构校验：字段缺失就丢弃重试，步骤数少于预期就报错。千万别让AI返回人类阅读友好的大段文字，否则后续转可执行脚本时你还要再做一次解析，平白多一道出错环节。
3.2 给AI搭“脚手架”：一份可直接抄的Prompt模板
这是全篇最核心的实操内容。我直接把用了几十轮、迭代多版之后验证可用的Prompt骨架写出来，你在团队里拿到手，替换成自己的系统信息就能用。
整个Prompt分为五段。第一段是角色声明，告诉AI它的身份是资深测试工程师，精通某系统领域的业务逻辑与测试设计。第二段是系统规则信息，把测试对象的关键业务规则列出来，比如订单的状态流转规则、权限控制逻辑、数据校验规则。这段信息建议由熟悉业务的测试工程师手写维护，它是AI生成好用例的地基。第三段是历史用例范本，给两条格式标准、覆盖不同类型路径的用例。第四段是本次要生成用例的需求描述，以及你从需求里抽取出来的四要素。第五段是明确的输出格式要求——JSON数组，每个元素包含前置条件、操作步骤、测试数据、预期结果、优先级五个字段。
实际操作中，我还会在Prompt末尾加一句要求：“如果需求描述中存在信息缺失，在JSON的missing_info字段中列出需要向需求方确认的问题，不要臆造规则。”这一句话至少堵住了三种瞎编情况：AI自己编一个不存在的校验规则、AI假设了一个与业务不符的状态流转、AI把需求中的模糊语句默认成了正向路径。
Prompt的细节决定成败。我踩过的坑有两个：一是步骤数量不限制，AI一次性给你生成30步的长流程，其中一大半是无关紧要的操作，评审成本极高。后来我在Prompt里明确写了“单个用例的操作步骤控制在5到10步，超过10步拆分为多条用例”，情况立刻好转。二是测试数据不给示例，AI生成的手机号、身份证号、金额字段很多都不可用，不是格式不对，是业务上不可能存在。解决方式是给一个测试数据字典的摘要，比如“手机号使用138开头后8位随机数，金额必须大于0且精确到小数点后两位”，AI生成的数据立马变得可用。
3.3 生成之后必经的一道工序：质量校验与清洗
AI生成的用例，哪怕Prompt写得再细，也不能直接进用例库。我的经验是，必须安排一道三道关卡的质量流水线。
第一道是结构校验，用程序检查AI返回的JSON是否符合字段格式要求。这道关卡跑得最快，通常几十秒就能把一个批次的结果过一遍。第二道是规则校验，把AI生成的用例与系统规则做比对，发现矛盾就打回重写。比如系统规则里写“已支付订单不可修改收货地址”，AI生成的用例里却有一条“修改已支付订单的收货地址，预期修改成功”，这就要拦截下来。这道校验可以人工做，也可以再让AI基于同一份系统规则做一次自查，输出与规则冲突的用例清单。第三道是冗余检查，把AI生成的多条用例做相似度比对，去掉步骤几乎相同、只改了测试数据的重复项。很多AI生成结果会产生大量“看起来不同、实际重复”的用例，比如对十个城市分别生成一条地址修改用例，其实一条参数化用例就够了。
清洗之后还有一个动作容易被忽略：给每条用例打上可执行性标记。标记的值要回答一个问题——这条用例能否直接转换为自动化脚本？能，就标记为“可直接转脚本”；不能，就标记为“需人工补充数据或定位信息”。这个标记直接影响后续的自动化执行排期，别跟用例混在一起。
3.4 从用例文本到可执行脚本：最后一步的转换细节
用例文本清洗完毕，下一步是把它转成可执行的自动化脚本。我用过两条路线，都给你说清楚优劣。
第一条路线是直接用AI生成完整脚本代码。把用例JSON加上被测系统的技术栈信息（前端框架、元素定位策略、接口协议等），让AI生成一段完整脚本。这条路线的优点是快，缺点是出错率不低——AI生成的元素定位符经常与实际页面不匹配，导致脚本跑到一半就中断。如果你走这条路，建议用代码片段级别的生成，也就是让AI生成单个步骤的执行函数，而不是生成一整个几十行的测试方法。
第二条路线是生成“半成品脚本”：AI负责生成每个操作步骤的伪代码或自然语言描述，然后测试人员把它填入团队自带的测试框架模板里。比如你们框架里已经封装好了click_by_text这样的公共方法，AI就只需要输出click_by_text("登录")这样的调用行。这条路线前期要写一些框架代码，但长期稳定性好，因为最终进入运行环境的代码，都经过测试人员的加工，而不是直接把AI输出丢进CI里。
我团队目前实际用的是第二条路线。做法是先给AI一份“框架API字典”，里面写明框架提供了哪些公共操作函数、每个函数的参数含义。Prompt里要求它只输出由这些函数组成的脚本片段，不许自己发明新的函数名。这样一来，AI生成的脚本在语法层面上永远在框架能力范围内，不会生成一个框架里根本不存在的wait_for_element_to_vanish。
4. 常见问题与排查技巧实录
4.1 AI生成的步骤与需求对不上、甚至自己编规则
这是最常见的问题，九成出现在系统规则信息缺失的场景里。有一次我有意做了个对照组，不给AI任何业务规则，直接丢一条“用户可以申请退货”的需求进去，结果它生成的用例里出现了“用户必须上传退货视频才能申请退货”这种需求里根本没有提到的规则。
排查思路很简单：先看Prompt里有没有足够多的系统规则。如果没有，就补。如果已经有规则但还是编，那就需要在Prompt的末尾强化“信息缺失时列在missing_info字段”的指令，并且把missing_info字段标注为必填。经历过几次之后，AI一般会养成“不确定就先问”的保守习惯，而不是大胆假设。
4.2 覆盖度严重不足：只生成了正常路径
AI有一个天生趋势，就是只往“成功路径”上走。输入一个用户故事，它倾向于生成“输入正确信息→操作→成功”这条主线用例，异常分支和边界值覆盖很少。
我的解法是给AI一个测试场景维度清单，显式地要求它按清单逐项展开。这个清单我放在Prompt的系统规则信息段之后，每次生成都强制带上。清单内容大概是：正常路径、必填项缺失、字段格式错误、数据边界值、权限不足、数据不存在、系统异常、并发冲突、逆向操作。AI看到这个清单，就会逐个维度去试，覆盖度立刻上来了。如果生成的用例还缺某一个维度，就在清洗阶段标记出来，单独发一批增量请求让AI专项补全。
4.3 脚本转换后一跑就挂：定位符失效和步骤断裂
这种情况的特点很典型：AI生成的脚本语法完全没问题，一执行就黄。原因通常是两个：一是点击目标用的是页面文本或动态属性，而实际页面在不同状态下文本会变；二是AI拿到的系统上下文里没有包含当前页面的真实DOM结构，只能凭想象生成定位符。
解决的办法，是我前面提到的“框架API字典”方案。把团队封装好的、不依赖于具体页面结构的操作函数提供给AI，比如click_by_text()这类，它在新页面上也能稳定工作。但这里仍然有一个老问题是AI解决不了的：它在生成的时候并不知道当前页面上有哪些可点击的元素。所以对于页面元素变动频繁的核心链路，我建议先把页面对象模型导出给AI，它基于实际页面结构来生成脚本，成功率会高很多。
4.4 生成速度慢、调用成本高、大批量跑不动
一次生成几十条用例没问题，一旦涉及几百上千条，时间成本和费用都会拉满。我实测过一个中等规模模块，让AI逐条生成大约要跑一个多小时，费用不菲。
几个可行的优化手段：一是批量合并请求，一个Prompt里放10条需求，一次返回50到80条用例，效率提升非常明显，质量并不明显下降。二是缓存相似用例，把历史生成中清洗后未修改的用例存入向量库，新需求下发时先做相似度检索，能直接复用的就直接引用，只有真正的新场景才调模型。三是错峰执行，把大批量生成任务放在低峰时段跑，配合重试机制，把偶发的超时错误自动捡起来继续。
5. 最后说几句实在话
这套AI驱动测试用例生成的流程，我前后实践了将近一年，迭代了不知多少轮Prompt和清洗规则。最大的体会是：AI在这里的定位更像一个“极其勤快的初级助理”，它能把需求描述转成格式规范、框架统一、覆盖面完整的用例初稿，但你不能指望它替你理解业务。团队里最懂业务的那个人，仍然要把关规则、补全边界、裁决争议。
个人建议分两步走。第一步，先把Prompt模板和清洗流程跑起来，挑一个中等复杂度的业务模块做试点，对比一下AI生成和人工编写在评审时间上的差异。我这边第一次实测的结果是：评审时间从原来的人工逐条评审，缩到了只看AI清洗后的增量部分和冲突清单。第二步，再考虑把链路固化到工程体系里，比如接入需求管理平台，需求状态一变就自动触发用例生成任务，把用例初稿作为需求评审的附件发给与会人员。
有一点必须提醒：AI生成的用例，无论如何清洗，上线前一定要有测试负责人签字确认。它不是测试设计的终结者，而是测试设计效率的放大器。用好这个放大器，你的团队释放出来的精力，能放在真正有意义的事情上——比如探索性测试，比如全链路压测，比如花时间把最容易被线上打脸的那几条业务规则学透。
