这段时间忙着把团队里的测试用例生成流程做了一次改造核心思路就一条用AI把测试设计里的重复劳动接过去。今天这篇先把大框架和完整操作流程写透后续再看情况补其他环节。先说结论AI生成测试用例这件事靠谱程度取决于两件事一是你喂给它的输入材料是否规范二是你会不会用提示词把它的输出框在正确的轨道上。这两点做好了AI写出来的第一版用例质量基本能达到老测试工程师手写水平的七八成剩下两成靠评审和人工修正收尾。这篇文章适合被测试用例写到手软的QA、以及想用AI提效但不知道从哪下手的测试开发直接照着操作。1. 先想清楚AI生成测试用例到底在解决什么问题1.1 测试用例设计的核心逻辑并没有变很多团队一提到AI生成测试用例第一反应是让AI替我把用例写了。这个预期其实有点跑偏。AI真正能干的事是把你从一大堆体力活里解放出来但测试设计的方法论——等价类划分、边界值分析、场景法、判定表——这些底层逻辑一个都不能少。AI不是要取代这套逻辑而是要加速这套逻辑的执行。用一个生活化的类比AI就像一个基础扎实但完全没有业务经验的实习生。你给他一份清晰的需求文档把规则、边界、异常场景都写明白他能快速产出一份基本合格的用例草稿。但如果你自己都没想清楚需求丢给AI一句帮我写登录功能的测试用例那它只能靠猜猜出来的东西自然没法用。所以整个流程的第一个关键动作不是写提示词而是先把需求输入材料整理到位。我在实际操作中的做法是AI负责枚举和铺量我负责判断和取舍。也就是说让AI把某个功能模块的所有正常流、异常流、边界值尽量铺开我再基于对业务的理解把真正重要的用例挑出来把冗余的删掉把漏掉的补上。这种分工方式既保留了测试工程师的核心价值又能把用例编写周期压缩一半以上。1.2 AI能做什么不能做什么心里要有数根据我这两三个月的实践AI在测试用例生成上的能力边界大概是这样能做根据结构化的PRD生成功能测试用例正常流程覆盖得又快又全边界值设计基本靠谱能按照指定格式输出标准用例能帮你把接口字段的必填、类型、长度约束枚举出来还能在输入有明显规则漏洞时主动追问。不太能做理解模糊的业务规则背后的真实意图识别跨模块的隐式关联影响判断历史线上事故中哪些点是回归重点自动分辨一句话需求里没说清的部分到底是默认不做还是需求遗漏。这里要特别强调一个高频坑很多AI工具在生成用例时会出现幻觉也就是会编造一些需求里根本不存在的功能点或交互细节。比如你把一个订单查询功能的PRD给它它可能会写验证订单可以导出Excel但你的需求里根本没有导出功能。这种幻觉用例如果流到执行阶段轻则浪费时间重则干扰真正的测试重点。所以我给自己定了一条铁规矩AI生成的每一版用例我都要对照原始需求文档逐条过一遍重点看有没有多出来的功能点、有没有改掉的原字段规则、有没有被忽略的异常分支。这个人工兜底步骤省不了但它只需要花在审查上不需要从零开始写时间成本已经降了很多。2. 投喂给AI的材料决定用例质量的三个输入源2.1 PRD需求文档怎么整理给AI现在很多产品经理写PRD格式五花八门有的很规范Few word文档、流程图、规则说明齐活有的就是几张原型截图加一段会议纪要。AI能消费的是结构化的文字描述所以投喂之前要做一个翻译动作把PRD转成AI能看懂的条目化描述。我给团队定的整理模板大概长这样功能名称明确在测什么如用户注册需求背景用一两句话说明这个功能为什么存在AI理解背景后写用例会更贴合真实场景核心流程按顺序描述正常操作路径如用户输入手机号 - 获取验证码 - 输入验证码 - 设置密码 - 注册成功业务规则逐条列出所有显性规则如手机号必须是11位大陆手机号、验证码有效期5分钟、密码至少8位含字母和数字异常场景列出需求已说明的异常分支如验证码错误提示、手机号已注册提示、密码不符合复杂度要求边界约束涉及长度、数量、金额等限定时一定要写清楚如用户名最长20个字符、单次最多上传5张图片这个整理过程看起来繁琐但其实很有价值。你在整理的时候相当于把PRD重新读了一遍很多原本埋在文字里的规则会被你主动提取出来这本身就是一个需求评审的缩小版。我团队里现在有一条约定没有整理成这个格式的需求先不上AI生成用例因为喂进去也是浪费Token输出质量没保证。2.2 接口文档与数据库字段信息补充看不见的约束功能测试用例如果要做得深光看PRD远远不够。PRD里不会写这个字段在数据库里是varchar(20)但AI如果知道这个约束就能自动生成长度为19、20、21的边界测试用例这种用例在真实项目中往往是bug的高发区。我通常会把接口文档里和这个功能相关的接口参数整理成一张表一起丢给AI。表头字段包括参数名、类型、是否必填、长度限制、取值范围、备注。比如做登录功能时把手机号和密码的接口约束整理清楚AI生成的用例在边界值这块的质量会有一个非常明显的提升。数据库字段信息的作用也类似。比如订单号字段如果设置了唯一索引AI知道这个信息后会自动追加一条重复提交相同订单号的用例这一类用例在手工编写时经常被漏掉。当然不是所有场景都需要拉数据库字段一般做支付、订单、账号这类数据强相关模块时值得把这个信息补进来做纯展示类页面时就不必了。2.3 历史用例与参考案例给AI一个对齐风格的锚点AI生成的内容有一个特点对用户提供的样例非常敏感。如果你希望AI产出的用例风格、字段、层级跟你们团队已有的用例完全一致最有效的方法是给它一份你们之前的手写用例作为参考。这个动作我在实际使用中发现特别管用。早前我直接让AI生成用例它给出来的字段是前置条件、测试步骤、预期结果但我们团队老用例的格式是前置条件、操作步骤、预期输出、数据准备字段名差异导致后面写自动化脚本时要重新映射。后来我在提示词里贴了两条团队历史用例做示例AI输出的格式马上就对齐了基本上不用二次调整。另外一个参考案例的用途是让AI理解什么粒度的用例才是合格的。不同的团队对用例粒度的定义差异很大有的用例细分到每个按钮每次点击都写一条有的用例每个业务场景写一条。这个颗粒度偏好很难用文字说清楚但给两个正反例AI立刻就能领会。所以每次用AI写新模块用例时我会从旧用例库里挑两条典型用例一正一反附在提示词后面。3. AI提示词让大模型一次就写出可用用例的四个技巧3.1 角色设定与任务边界要写得像给实习生派活提示词的核心作用不是套魔法咒语而是把模糊的需求说清楚。你在给AI写提示词时就当作你在给一个刚入职的测试实习生布置任务。实习生最怕的不是活多而是不知道边界——你希望他做A他没做反而把B做了一大堆。所以我的提示词第一段固定是角色和任务边界你是一名有8年经验的测试工程师擅长功能测试用例设计掌握等价类划分、边界值分析、场景法、判定表等测试设计方法。 现在需要你为一个[具体模块]功能设计功能测试用例。 只需要设计功能层面的用例不需要做性能测试、安全测试和兼容性测试的相关设计。这样做的效果是AI输出的内容会被牢牢限制在功能测试这个范畴不会动不动给你加一条验证系统在高并发下的表现这种用不了的用例。任务边界写清楚等于帮AI划了一条工作范围线省去后面大量删改。3.2 先列测试点再展开用例避免AI发挥过头直接用一句话让AI生成20条用例很容易出现一个问题它可能只覆盖了主流程和少数异常流遗漏了大量分支场景但因为它输出的是完整格式的用例你一眼扫过去很难发现哪里漏了。这个问题不像AI多写那么显眼但危害更大——漏测可比多测严重多了。解决方法是分两步走第一步只让AI列出这个功能的测试点清单不看完整步骤先确认覆盖范围第二步再让AI针对确认后的测试点逐条展开成完整用例。我在提示词里是这么写的请先针对该功能列出测试点清单包括正常流程、异常分支、边界值、权限校验、数据重复等维度清单条目控制在20-30条之间。 先只输出清单不要展开用例细节。拿到清单之后我会花几分钟跟产品经理或开发确认有没有遗漏的关键场景确认没问题了再追加一句请针对以上测试点清单逐条展开成完整的功能测试用例。这种两段式做法的好处是把AI的枚举能力和人的判断能力分别发挥到了最大覆盖率的底子会好很多。3.3 明确用例字段、覆盖方法和优先级如果不对用例格式做任何约束AI默认输出的字段基本是用例名称、前置条件、操作步骤、预期结果这个格式不是不行但在团队落地时会遇到很多问题比如没有用例编号没法和自动化脚本建立映射没有优先级执行的时候不知道怎么排序。我建议在提示词里把输出格式的硬性要求直接写死按团队的模板来。这里给出一个常用的功能测试用例字段模板请按照以下字段输出用例 用例编号、所属模块、用例标题、优先级P0/P1/P2、前置条件、测试数据、操作步骤、预期结果除了格式还有覆盖方法的要求。建议明确写出在设计用例时请综合使用等价类划分法、边界值分析法、场景法、错误推测法。 对于所有涉及长度限制的字段必须覆盖最小合法值、最大合法值、最大合法值1、最小合法值-1四个边界。为什么这样写因为AI默认的边界值设计能力虽然不错但它不一定做得那么系统。你如果不提最小合法值-1这类具体描述AI可能只在输入值合法的一侧生成用例非法侧的边界覆盖经常有遗漏。把方法论要求写进提示词里相当于给AI装了一个设计检查单。3.4 迭代追问一次输出不满意别急着放弃AI生成用例很少有一次就能直接用的。我的经验是拿到第一版输出后至少在脑海里过三遍第一遍看覆盖是否全面第二遍看格式是否符合要求第三遍看业务规则有没有理解偏差。发现问题后不要推倒重来而是用追加追问的方式让AI自己修正。我常用的追问模板有这几类- 请补充异常输入场景例如参数缺失、非法的业务状态、重复提交等 - 请补充权限维度例如无权限用户、普通用户、管理员的区别 - 请检查用例中是否缺少对XX规则的覆盖该规则在需求中是xx - 请合并标题或步骤相似的用例避免重复 - 请重新标记优先级P0只保留核心主流程和严重异常分支这个多轮对话式的操作方式比一次性让AI输出完美结果稳定得多也更符合AI的工作方式。你每追加一轮它在已有基础上修正输出的稳定性和质量都在提升。现在我在团队里推行的方法就是第一版AI生成第二版人审补充输入第三版AI修订最多三轮之内收工。4. 完整实操用AI生成用户注册功能测试用例4.1 准备输入材料一个精简版PRD示例为了让这个过程更直观我准备了一个精简版的注册功能PRD实际工作中你的PRD信息量会更大但核心要素是类似的功能名称用户注册手机号注册 需求背景用户通过手机号注册为新用户注册成功后默认未实名认证。 核心流程 1. 用户输入手机号点击获取验证码 2. 系统校验手机号格式校验通过后发送6位数字验证码 3. 用户输入验证码点击注册 4. 系统校验验证码正确性校验通过后进入密码设置页 5. 用户设置登录密码点击完成注册 业务规则 1. 手机号必须为11位大陆手机号以1开头 2. 验证码有效期5分钟超过有效期需要重新获取 3. 同一手机号60秒内只能获取一次验证码 4. 验证码错误累计5次后该验证码作废需重新获取 5. 登录密码要求8-20位必须包含字母和数字 6. 已注册的手机号不允许重复注册需提示该手机号已注册 7. 验证码接口单IP请求上限为每小时20次 异常场景 1. 手机号格式不正确时提示错误且不发送验证码 2. 验证码输入错误提示验证码错误请重新输入 3. 验证码过期后提交提示验证码已过期请重新获取 4. 密码复杂度不足时提示具体规则 5. 注册协议未勾选时提示需要同意协议这份材料里既有正常流也有显式规则、边界约束、异常分支喂给AI生成出来的用例质量会相对有保障。4.2 一段可以直接抄的提示词模板基于我前面说的几个要点给出一段我目前用得比较顺手的完整提示词模板你可以直接复制到任意主流大模型对话工具里试用你是一名有8年经验的测试工程师擅长功能测试用例设计掌握等价类划分、边界值分析、场景法、错误推测法等测试设计方法。 现在需要你为用户注册手机号注册功能设计功能测试用例。只需要功能测试层面不需要性能、安全、兼容性测试。 需求如下 [将上面的PRD内容粘贴到这里] 请先输出测试点清单包括正常流程、异常分支、边界值、权限校验、数据重复等维度条目控制在25-35条之间。先只输出清单不要展开用例。 请综合使用等价类划分法、边界值分析法、场景法。对于手机号和密码字段务必覆盖合法边界的最小值、最大值、超出最大值1位、小于最小值1位。这一步输出的测试点清单我一般会人工对照需求过一遍重点查异常分支和边界值有没有缺项。确认没问题后再追加展开指令测试点清单没问题。请针对以上清单逐条展开成完整的功能测试用例。 请按以下字段输出用例编号、所属模块、用例标题、优先级P0/P1/P2、前置条件、测试数据、操作步骤、预期结果。 P0只保留核心主流程和严重异常分支例如注册成功、验证码错误5次、手机号已注册。4.3 人工审查修正AI输出里的典型问题拿到AI展开后的完整用例直接拿去执行是不太现实的至少我在实际操作中每次都发现几个共性问题在这里给各位提前排雷第一个问题是优先级给得不合理。AI对P0的理解往往偏宽动不动把验证码输入超时后点击注册提示错误也标成P0这会让执行阶段的排序失真。我的处理方式是末尾加一轮人工重排P0用例控制在总数的20%以内重点覆盖用户主路径和资金、数据安全问题。第二个问题是隐含约束漏掉。上面这个PRD里有一个验证码错误累计5次后作废的规则AI在第一版输出里大概率只会生成验证码错误时提示不会主动生成连续错5次之后第6次输入正确的验证码也会被拒绝这种深层用例。这种场景需要人工补充进去或者用追问方式让AI补充。从这个角度看AI更适合做铺底深挖场景还得靠人。第三个问题是重复度高。AI在展开用例时容易出现步骤表述不同但逻辑相同的情况比如输入不存在的验证码和输入错误格式的验证码覆盖的其实是同一类问题。合并这类重复用例需要人工判断不用指望AI自己消重消得很干净。4.4 从用例到自动化脚本的衔接现在很多团队生成测试用例的最终目的是做自动化回归。AI在这个环节的提效也非常明显你可以让它直接基于已确认的用例生成接口自动化脚本框架。比如把一条用例的操作步骤和预期结果贴给它追加下面这段提示词请将以上用例转换为Python接口自动化测试脚本使用requests库模拟发送验证码和注册接口调用。 脚本需要包含断言断言内容基于用例的预期结果。请使用pytest测试框架组织。请先定义通用请求封装和测试数据。实际用下来AI生成的脚本虽然不能保证一次跑通但接口路径、参数结构、断言逻辑这些骨架都是对的调试成本比从零开始写低很多。需要注意的关键点是AI需要知道接口的真实协议信息所以前面提到的接口文档在这里又要发挥作用了。如果AI对接口一无所知它只能凭猜生成脚本那肯定没法用。5. 常见问题与AI生成用例的避坑实录5.1 五个高频问题速查表我在多个项目的实践中总结出AI生成测试用例最常见的问题供各位直接对照排查问题类型表现排查方法应对方式幻觉出现需求中不存在的功能或规则对照原需求逐条检查功能点人工删除补充真实需求描述后追问漏覆盖异常流、边界值大量缺失检查是否每个业务规则都有逆向用例追加请补充XX规则的反向用例追问重复度高多条用例逻辑相同、表达不同按前置条件操作步骤抽象去重人工合并标注唯一编号优先级失真P0用例占比过高统计P0占比目标控制在20%以内人工重排P0只保留主流程核心异常需求漂移PRD改版后AI仍按旧版输出每次改需求后重新走生成流程把变更点单独拎出来让AI重新生成增量用例这里面的需求漂移问题特别值得多说一句。很多团队用AI生成过一次用例之后就把这段历史对话直接当标准用例库用了后面需求改了也不管。这是最大的坑。AI生成的内容不是一劳永逸的它的保鲜期跟需求文档的保鲜期是一致的。PRD一改涉及变动的模块就要把变更点单独抽出来重新让AI生成增量用例再做一轮评审合并。5.2 AI能否独立完成用例评审有人问过我一个问题既然AI能生成用例能不能让AI自己评审自己生成的用例我的答案是可以部分但绝不能全部。AI的自我评审能力更适合做格式审查、完整性检查这类机械性任务比如检查所有用例是否都有前置条件和预期结果检查P0用例是否都用到了数据准备字段。这类似一个初级复核员干的活确实能减轻不少工作量。但业务层面的评审AI永远替代不了人的原因在于业务语义的判断基准不在AI那边。比如某一条用例涉及资金类操作到底按P0还是按P1处理需要结合历年线上问题、用户影响面、产品诉求来判断这些信息AI都没有。所以我的建议是让AI做格式审查员让人做业务评审员两条线并行效率和质量的平衡最好。5.3 团队落地时的三个实操建议如果你看完前面这些内容准备在团队里推AI生成测试用例这里有三个我踩过坑之后总结的落地建议第一提示词模板要用团队自己的语言沉淀。每个团队对用例的字段、格式、颗粒度要求不同完全照搬别人的提示词模板效果不会好。正确做法是先用两三个历史模块做试验把提示词逐步调整成与团队用例风格一致的版本最后固化下来放到团队知识库里新成员来了直接复制使用。第二建立AI初稿人工评审的标准流程不要打乱已有的评审环节。AI生成用例不是不评审的理由反而是更需要评审。因为AI可能一本正经地生成一条覆盖了错误业务逻辑的用例这种用例看起来比没有用例更危险它会给你一种测过了的错觉。第三做好用例数据的版本化。AI生成的用例要和历史手写用例一起纳入测试管理系统或版本控制并且保留生成时所用的需求版本号。这样一来当需求变动时可以快速判断哪些用例已经失效哪些需要重新生成。这一点在项目迭代快、需求变更频繁的团队里尤为重要。5.4 关于用例质量和覆盖率的一点个人心得最后说点掏心窝子的话。AI生成测试用例这个事刚上手时容易产生两个极端心态要么觉得AI不行生成的东西改起来比自己写还费劲要么觉得AI太行了什么模块都往里丢结果漏了一堆关键场景。这两个极端我都走过。后来我想明白一个问题AI生成用例的核心价值不在第一次输出的内容质量而在它把枚举所有可能场景这个动作的速度提升到了秒级。人的精力是有限的手工写用例时人的注意力消耗在逐条组织语言上留给创造性挖掘业务深坑的精力就少了。AI接了枚举的活人自然能把精力集中在判断、取舍、深挖这些AI不擅长的点上。这才是这个工作流真正值钱的地方。实际执行的时候我现在固定下来的模式就是需求评审一结束我把PRD结构化材料整理好让AI跑一遍测试点清单人确认覆盖范围再让AI展开成完整用例最后人工逐条审查并同步到用例管理平台。整个过程大概能比手工编写节省一半时间而用例的覆盖率和可执行性至少不低于团队之前的平均水平。后续这块还可以往下扩展的方向有不少。比如让AI基于测试执行结果自动分析用例失败原因或者让AI根据线上用户反馈反推需要补充的回归用例这些场景本质上和AI生成测试用例是同一套思路把上下文喂给模型让模型产出结构化的测试资产人来判断和拍板。搞通了这一个闭环其他环节的自动化也就是时间问题了。