刚开始接触AI生成测试用例的时候我其实挺怀疑的。毕竟测试用例这活儿看起来是“填空题”实际上处处都是业务逻辑、边界条件和异常路径的博弈。真让AI来写它能懂“登录失败5次要锁定账号”这种隐含规则吗它能分清“商品库存为0”和“商品库存不存在”是两条完全不同的用例吗带着这些疑问我花了两周时间用AI跑完了一个完整的功能模块——从PRD解析、用例生成到断言补全再到一部分自动化脚本的产出。这一轮实操下来我对AI在测试领域的定位有了完全不一样的认识。它不是来替代测试工程师的而是像一个记忆力极强、反应极快、但偶尔会“一本正经胡说八道”的实习生。你给他的指令越清晰他产出的质量就越稳定你撒手不管他就能给你编出一堆不可能发生的场景。这篇文章是我自己的实战记录不吹不黑我会把完整的提示词、操作步骤、踩过的坑、以及最后的成果都摊开来说。如果你想用AI提高测试用例的产出效率这篇内容应该能帮你少走不少弯路。1 整体思路AI不是“自动写用例机”而是一套提示词驱动的需求解析流水线在动手之前我先把需求理清楚了。我要做的不是拿一个工具把PRD丢进去然后“啪”地一声变出100条用例。那是不可能的也是不负责任的。真正能落地的方案是把AI当成一个能理解需求、能识别边界、能按格式输出的协作引擎。基于这个前提我把整个流程拆成了三段式管道需求拆解阶段把杂乱的中文PRD、会议纪要、原型说明转成结构化的“功能清单”和“业务规则”。用例生成阶段基于功能清单用等价类划分、边界值分析、场景法这些经典黑盒用例设计方法生成功能用例、接口用例和异常用例。格式固化阶段让AI按公司模板输出用例编号、前置条件、测试步骤、预期结果、优先级、用例类型。这个思路看着简单但实际操作中容易翻车的地方在于:大多数人直接把原始需求贴给AI然后期待它“理解”业务。可AI根本没有“理解”这回事它只有“模式匹配”。你给它的信息越结构化它匹配出的用例越贴近业务你给它一段充满口语的会议记录它就会回你一堆泛泛而谈的“点击按钮—验证结果”之类的废话。我用的是分层提示词策略。第一层先让AI当“需求分析师”把原始资料整理成功能点列表第二层再让AI当“资深测试工程师”基于功能点列表逐条生成用例第三层让AI当“测试组长”对生成的用例进行审查排除重复项、补充遗漏的边界条件。这个思路借鉴了当前比较热门的Agent工作流概念——把一个大任务拆成多个小步骤每一步用不同的“角色设定”来驱动效果比单次对话要好得多。在实际操作中我的具体做法是先建立一个专用的对话会话避免上下文干扰然后把PRD内容分段喂给AI每段不超过1000字防止长文本导致的注意力分散每喂一段就要求AI输出“该段落涉及的功能点和潜在业务规则”最后把所有的功能点汇总再进行用例生成。这套流程跑下来AI生成的用例覆盖率比我之前凭感觉写的要高不少。有一点必须说清楚AI生成用例的质量上限完全取决于你的提示词质量和输入信息的结构化程度。它不可能“无中生有”地理解你公司那些写在职级文档里的潜规则比如“管理员不能给自己降权”这种逻辑如果PRD里没有AI大概率是生成不出来的。所以提示词工程就是我们工程师要补的那块短板。2 核心提示词工程让AI从“胡说八道”到“句句有理”2.1 角色设定与任务分解的提示词写法我见过很多人问“为什么我用AI写出来的用例这么水”然后打开对话窗口一看提示词就一句话“帮我写登录功能的测试用例”。这种提示词换成人类测试组长也没法干活根本没有说清楚公司模板是什么、要覆盖哪类测试、优先级怎么定、前置条件需要哪些数据。我自己用的第一段提示词是这样的你现在是一位有8年经验的资深测试工程师擅长黑盒测试用例设计精通等价类划分、边界值分析、场景法、错误推测法。 请根据我提供的功能描述设计一份功能测试用例清单。 要求 1. 覆盖正常流程、异常流程、边界值、权限控制、数据校验五个维度 2. 每条用例包含用例编号、所属模块、用例标题、前置条件、测试步骤、预期结果、优先级高/中/低、用例类型功能/接口/异常 3. 步骤必须具体到操作层级比如“输入框输入”、“点击按钮”、“等待响应”不允许出现“进行验证”这种模糊表述 4. 如果需求描述中缺少必要信息请先列出你的疑问不要自行假设。这段提示词里有几个关键设计点值得展开说。明确角色和年限。别小看“8年经验”这个设定。我在对比测试中发现同一条需求设定成“3年经验”和“10年经验”生成用例的细致程度差异巨大。后者会更主动地考虑“网络超时”、“接口幂等性”、“并发重复提交”这类深层问题而前者偏向于“输入正确内容—点击—成功”这种表面路径。限定测试设计方法。等价类划分、边界值分析、场景法这些术语AI是熟悉的。你把方法名词写进提示词它就会下意识地按照这些方法论的结构去生成用例而不是天马行空地乱写。这相当于给AI套了一个“方法论框架”。明确输出格式。输出格式本身就是一种约束。你要求它填表格字段它就会按字段去思考你只要求“写用例”它就只会给你列一堆小标题和概述根本没法直接用。允许提问。AI默认倾向是“尽量满足用户请求”哪怕需求信息不足它也会硬着头皮编。你必须给它一个“允许提出疑问”的出口它才不会瞎猜。我实测下来如果补上这句话AI至少会主动问清楚“登录方式是手机号还是邮箱”、“是否有验证码”、“账号锁定策略是什么”这三个问题这就给了我们补充信息的机会。2.2 PRD解析模板如何把零散需求转成AI能理解的结构化规则第二步是给AI喂需求。我整理了一个标准化的PRD解析模板把原始需求里的信息分类成“功能名称”、“操作路径”、“业务规则”、“数据约束”、“异常场景”、“关联系统”六个维度让AI按这个结构输出。来看一个具体的需求原文和我的解析模板对比。原始需求描述用户可以通过手机号注册平台账号注册时需要输入手机号、验证码、密码密码要求8-20位且包含字母和数字。同一个手机号只能注册一次注册成功后自动登录。如果手机号已被注册提示“该手机号已注册”。这是一段非常典型的中文PRD描述看着清楚但漏掉了很多测试需要的细节。我把这段需求喂给AI同时附上解析模板请将以下需求按照指定结构进行解析 - 功能名称 - 操作路径 - 业务规则 - 数据约束字段类型、长度、格式要求 - 异常场景系统提示、业务阻断、边界情况 - 关联系统是否需要短信服务、是否需要用户中心 需求原文...AI返回的结果大概是这样解析维度结果功能名称手机号注册操作路径注册页 → 输入手机号 → 获取验证码 → 输入验证码 → 输入密码 → 确认注册 → 自动登录业务规则1. 同一个手机号仅可注册一次2. 注册成功自动登录3. 手机号已被注册时阻断并提示“该手机号已注册”数据约束手机号11位1开头验证码6位数字密码8-20位必须同时包含字母和数字异常场景手机号格式错误、验证码错误/过期、密码不符合规则、手机号已注册、验证码发送失败、注册接口超时关联系统短信服务验证码、用户中心账号创建与登录这一步做完之后AI生成用例的信息基础就扎实了。这时候再跑用例生成输出质量会明显上一个台阶因为它有了明确的数据字典和业务规则清单不会乱编边界条件。比如没有经过结构化解析时AI很有可能漏掉“验证码过期”和“验证码连续输错限制”这两个异常场景结构化之后它至少会主动列出这几个风险点。2.3 用例生成与格式固化让AI懂得“模板思维”公司的用例管理工具一般都有自己的模板格式。有些公司用Excel有些用TestRail有些用禅道。AI生成用例如果想落地最后一步就必须把输出内容对齐到公司模板上。我用的方法是给AI一个“格式示例”让它模仿。不要用文字描述“请在用例编号里带上模块缩写”直接给它一个填好的例子它就能精准模仿。来看一个我当时用的格式示例用例示例 模块用户注册 用例编号TC_REG_001 用例标题使用正确的手机号、验证码和密码注册成功 前置条件平台注册页可访问短信服务正常该手机号未被注册 测试步骤 1. 打开注册页面 2. 输入正确格式手机号 13800138000 3. 点击“获取验证码” 4. 输入接收到的6位验证码 123456 5. 输入密码 Abc12345 6. 点击“注册”按钮 预期结果 1. 系统提示“注册成功” 2. 页面自动跳转至首页 3. 当前会话处于登录状态 优先级高 用例类型功能测试这个示例最核心的价值在于展示了“具体的数据”应该怎么写。我在对比测试中发现如果格式示例里用“输入正确的手机号”而不是“输入13800138000”AI生成的用例里就全是“输入正确的手机号”这种偷懒写法。但只要你给了一次具体的示例数据它后续生成步骤时就会自动带上具体数值。这个技巧对后续自动化脚本生成帮助非常大——正因为有具体的测试数据转成脚本时几乎不用改。生成完用例之后我还会追加一轮“去重审查”的提示词请审查以上生成的用例执行以下操作 1. 删除与现有用例重复度超过90%的用例 2. 找出缺少边界值的用例补充边界数据比如密码长度的8位、20位、21位 3. 检查每个异常场景是否有对应的预期系统提示语 4. 输出审查后的完整用例清单。这一步是为了解决AI生成时的两个天然毛病重复率高、边界值覆盖不全。AI在生成用例时非常容易出现两个用例之间只是“测试步骤文案略微不同”的情况看起来数量庞大实际有效用例只有一半。审查轮能把这个水份挤掉不少。3 实操过程与核心环节实现从PRD到完整用例集的一次全流程记录3.1 用阶梯式提问解析PRD避免“一次性全部导入”在实际操作中我发现直接把整个PRD文档一次性粘贴给AI效果并不好。语言模型对长文本的注意力分配不均匀5000字的PRD它往往只记住了前面500字和最后300字中间的核心约束常常被忽略。所以我的实操方法是把PRD拆成多个功能模块逐模块喂给AI。拿一个真实的商城项目来举例PRD里包含登录注册、商品浏览、购物车、订单结算、优惠券、支付、售后七个模块。我分七轮对话每一轮只处理一个模块每轮都执行“原始需求输入→结构化解析→功能点确认”三步操作。全部跑完之后再汇总所有功能点统一进行用例生成。以一个具体模块的操作过程为例商品浏览模块。我输入的内容是商品列表页展示商品缩略图、名称、价格、销量支持按分类筛选、按价格排序商品下架后不再展示商品详情页展示轮播图、商品参数、用户评价。AI结构化解析之后的输出包含业务规则业务规则编号规则内容BR-PRD-01商品列表页必须展示缩略图、名称、价格、销量四个核心字段BR-PRD-02分类筛选后列表内容必须与所选分类匹配BR-PRD-03价格排序支持升序和降序BR-PRD-04已下架商品在列表页不展示但通过历史链接访问详情页时应提示“商品已下架”BR-PRD-05商品参数和用户评价在详情页正常展示看到AI列出来的BR-PRD-04我心里就很踏实了。因为原PRD只写了“商品下架后不再展示”这引发了一个非常重要的边界问题已下架商品的历史链接还能不能访问如果不能理解这个隐藏场景很多测试人员会把“下架”的用例只写到列表页而漏掉详情页的回访场景。AI能主动把这个边界找出来靠的正是我把每一条业务规则都单独拆开、让它逐条推演的结果。这一步给我的启发是不要等AI生成用例之后才发现需求理解跑偏在PRD解析阶段就要用问答式互动把模糊点全部问清楚。AI可以帮你做需求澄清前提是你给了它一个“允许提问”的机制。3.2 从功能点批量生成用例现场还原一次完整生成对话功能点解析完成之后我开始批量生成用例。下面是当时生成“优惠券模块”用例时的关键提示词和AI返回结果的部分摘录能比较清楚地展示整个交互过程。我给的提示词以下是优惠券模块的功能点清单 1. 用户可以在结算页选择可用优惠券 2. 优惠券分为满减券和折扣券 3. 每张优惠券有使用门槛、有效期、适用商品范围 4. 一个订单只能使用一张优惠券 5. 优惠券在订单取消后可退回 6. 优惠券过期后不可使用。 请基于以上功能点设计优惠券模块的功能测试用例覆盖正常流程、异常流程、边界值、业务规则验证四个方面。AI返回的用例节选用例编号用例标题优先级用例类型TC_COUPON_001订单金额满足满减门槛时使用满减券成功抵扣高功能测试TC_COUPON_002订单金额低于满减门槛时优惠券不可使用且有明确提示高异常测试TC_COUPON_003折扣券在适用商品范围内正常抵扣高功能测试TC_COUPON_004折扣券对非适用商品不可使用高业务规则测试TC_COUPON_005订单金额恰好等于满减门槛时使用优惠券成功中边界值测试TC_COUPON_006订单金额为满减门槛减0.01元时优惠券不可用中边界值测试TC_COUPON_007同一订单选择多张优惠券时仅允许勾选一张中业务规则测试TC_COUPON_008订单提交后取消优惠券退回至用户账户中业务规则测试TC_COUPON_009优惠券过期前一天下单但未支付过期后支付时优惠券状态处理低边界值测试TC_COUPON_010优惠券已使用后再下单无法再次使用高业务规则测试这条用例清单的完成度让我比较满意。TC_COUPON_009尤其惊艳它想到了跨状态的时间边界问题——下单时券是有效的但支付时已经过期这种情况下系统是允许支付还是提示重新选择支付方式这个场景如果没有几年的电商测试经验很容易漏掉。AI能生成出来说明它在海量测试用例的训练数据中见过类似场景然后通过模式匹配迁移到了这个项目里。当然它也不是每次都这么聪明。同样在这个模块里它还生成了一条“使用优惠券后订单金额为负数”的用例。这种场景物理上就不会出现因为优惠券的使用前提是“订单金额满足门槛”满减券不可能把金额减成负数。我直接在审查阶段把它删掉了。3.3 接口测试用例补全从功能用例反推接口层覆盖功能用例覆盖的是页面操作层但测试不能只停留在UI。我继续让AI基于同一份功能点清单生成了对应的接口测试用例重点覆盖参数校验、接口幂等性、权限控制、并发场景。当时我给的提示词比较简单直接请基于优惠券模块的功能点清单设计对应的后端接口测试用例。 重点关注 1. 必填参数缺失和参数格式错误 2. 重复提交订单时优惠券是否会重复使用 3. 不同用户身份普通用户/管理员的权限隔离 4. 并发请求下同一张优惠券被两个订单同时使用时的系统处理。AI生成的接口测试用例中有几条值得拿出来说用例编号接口场景预期结果TC_API_001提交订单接口缺少 couponId 参数系统返回400参数校验错误不生成订单TC_API_002提交订单接口传入不存在的 couponId系统返回404或明确提示优惠券不存在TC_API_003同一张优惠券在A、B两个订单中同时提交只有一个订单成功使用优惠券另一个订单提示优惠券已被使用TC_API_004用户A的优惠券在用户B的订单中使用系统返回无权限使用该优惠券TC_API_005同一订单重复点击提交按钮发送两次相同请求后端幂等控制生效只生成一个订单TC_API_006优惠券接口在订单取消后再次查询状态为“已退回”返回状态码200优惠券状态为availableTC_API_003这个并发用例AI能想到很大程度上是因为我在提示词里明确写了“并发请求”三个字。如果你不写它很少主动往这个方向想。这也印证了一个规律AI是优秀的执行者但不是一个优秀的提问者。你给它的提示词里包含的测试维度越丰富它产出的用例就越有深度。3.4 用例整理与去重如何把AI输出变成能直接用的交付物AI生成完用例之后不是直接复制粘贴到用例管理工具里就完事了。它给的原始清单里有几个典型问题重复用例多、用例标题表述不够简洁、前置条件和测试步骤混在一起、预期结果过于笼统。我当时花了不少精力做后处理主要的操作有四项第一项按业务模块拆分用例编号。AI默认生成的编号是TC_001、TC_002这种流水号没有模块信息。我手动添加了模块缩写比如用户注册是TC_REG、商品浏览是TC_PRD、购物车是TC_CART、订单结算是TC_ORD、优惠券是TC_COUPON、支付是TC_PAY。这样在测试管理工具里筛选和执行时看编号就能知道属于哪个模块。第二项合并重复的边界用例。AI特别喜欢把“密码长度为8位”和“密码长度为9位”拆成两条用例但实际上这两条用例对测试结论没有本质区别。我保留了最小边界8位、最大边界20位、超界值7位、21位四条核心边界用例中间值合并成了一条“密码长度在8-20位之间的随机值注册成功”的用例。第三项把预期结果从“系统给出提示”改成具体提示语。AI在生成预期结果时经常偷懒用“系统出现错误提示”这种模糊写法。我在审查时逐条要求它补充具体的提示语文案比如“该手机号已注册”、“验证码错误”、“密码长度不符合要求”并把这些文案与PRD里定义的文案一一核对。这一步对后续UI自动化断言非常关键没有具体的预期文案自动化脚本根本无从下手。第四项补充测试数据准备说明。每个用例的前置条件里我会额外标注需要准备的测试数据。比如“使用满减券成功抵扣”这条用例前置条件是“准备一张满100减20的优惠券并确保当前订单金额在120元以上”。这个习惯是从接口测试时代带过来的在手工测试执行时测试数据准备本身就是最大的时间消耗。AI可以帮你把数据准备动作也写进前置条件里减少执行时的思考成本。经过这四步处理之后AI产出的初始用例清单从120条精简到了86条有效性和可执行性都大幅提高。这个数字对比也能看出来AI的输出是“原材料”不是“成品”。一个合格的测试工程师价值恰恰体现在把原料加工成成品的判断力上。4 AI生成用例的边界、幻觉与常见问题排查实录4.1 经典翻车案例AI一本正经地编造功能AI生成测试用例最大的风险不是它写得不够多而是它写得“太像真的了”。我在做登录注册模块时就遇到过一次典型的AI幻觉问题。当时的需求里只写了“支持手机号注册”AI在生成用例时主动补了一条“支持微信第三方授权登录”的用例。我看到之后还挺高兴以为是AI帮我发现了PRD的缺失。但是当我翻遍整个PRD和原型图之后确认了这个项目根本没有微信登录的需求。AI之所以会生成这条用例是因为在它训练数据中“注册登录”和“第三方登录”是高频共现组合它自动补全了这个关联。这类问题非常隐蔽。尤其是当你对业务不够熟悉的时候AI编出来的功能会和真需求混在一起让你防不胜防。我当时的应对策略是引入“交叉验证轮”让AI生成完用例之后要求它把每条用例对应的“需求来源”标注出来——是来自PRD原文、还是来自合理推断、还是来自假设。这样就能一眼看出哪些用例是没有需求依据的“幻觉产物”。提示词如下请在每条用例末尾添加“需求来源”字段取值为 - PRD原文直接来自需求文档的明确描述 - 逻辑推断基于业务逻辑的合理推导如边界值、异常流程 - 假设PRD未提及AI自行脑补的规则。这个要求加上之后AI会自动给自己的输出打上标签方便我快速审查被标记为“假设”的用例大部分都会被直接删掉少部分经过业务确认后会转成真正的需求缺陷反馈给产品经理。4.2 上下文遗忘问题长对话生成质量为什么会越来越差另一个高频问题是上下文遗忘。我用同一个对话窗口连续处理7个功能模块到第5个模块的时候明显感觉AI生成的用例质量开始下滑经常把商品模块的规则套用到订单模块上。原因很简单AI的上下文窗口有限早期的对话内容会被逐渐压缩或丢弃。尤其是如果中间穿插着大量用例文本到后面它“记住”的已经不是功能点清单而是自己生成过的那堆用例了。我的解决办法是开启多个独立的对话窗口一个模块一个会话不混用。每个会话的第一条消息就是“模块功能点清单 格式示例”。不要嫌复制粘贴麻烦这种隔离式对话能显著提升后续生成质量。如果对话过程中发现AI开始“跑偏”不要再追加提问去“纠正”它直接开一个新会话把修正后的提示词重新喂一遍效果来得更快。还有一个细节在一个会话里不要交叉输入多个模块的PRD。你一旦混着输入AI就会把两个模块的规则混淆生成“在结算页选择收货地址”这种牛头不对马嘴的用例。4.3 断言泛化预期结果写得过于笼统怎么办AI生成用例时最让我头疼的其实不是功能描述而是“预期结果”写得不够具体。具体表现为能用“系统提示正确信息”就不写具体文案能用“页面正常展示”就不写展示内容。这种泛化断言对人工测试执行影响还能接受但是对自动化测试来说等于废纸。我当时用的补救提示词是请对所有用例中的预期结果进行细化 - 涉及系统提示的写出具体的提示文案 - 涉及数据展示的写出具体的数据内容和展示位置 - 涉及接口返回的写明状态码和关键返回字段 - 涉及状态跳转的写明跳转前后的页面路径。这个细化步骤跑完之后AI生成的用例可执行性明显提升。比如有一条用例的预期结果从“页面展示订单信息”优化成了“订单详情页展示订单号20250407123456、商品名、单价、数量、支付金额、订单状态为待支付”这种颗粒度的预期结果直接能作为自动化脚本的断言依据。4.4 关于AI生成用例是否值得在团队中推广的几点建议经过这次全流程实验我的结论是AI生成测试用例这套方法完全值得在团队中推广但它必须搭配一套严格的工作流否则你会从“写用例的人”变成“删垃圾用例的人”。整理几个核心建议现有用例资产是最好的提示词种子。把公司过往的项目用例拿出来让AI做“风格学习”再让它按照这种风格生成新用例产出的用例风格会和团队习惯非常一致减少后期整理成本。提示词沉淀比单次生成结果更值钱。把这次总结出的角色设定、PRD解析模板、用例生成规则、审查规则整理成团队内部的Skill文档后续其他成员可以基于同一套体系直接复用。AI负责数量和覆盖人类负责质量和判断。我的个人体会是AI在等价类划分、边界值分析这类有明确方法论指导的场景中表现稳定而在需要业务经验沉淀的隐含规则、跨模块联动、权限控制这类场景中人的判断力仍不可替代。最理想的状态是AI先跑一轮广撒网测试工程师再在它产出的基础上做精加工。注意合规要求。使用AI处理需求文档时要注意脱敏处理。我当时把公司PRD中的敏感字段比如真实的手机号、订单号、客户名做了一次替换用测试专用的假数据喂给AI。这既保护了公司信息安全也顺便让AI生成的测试数据直接可复用。5 从用例到自动化一份提示词走完“用例生成—脚本生成—代码审查”的前置思考跑完了手工测试用例的生成流程后我明显觉得不过瘾。毕竟生成用例只是第一步如果能把用例直接变成自动化脚本才算真正打通了从需求到测试执行的链路。我当时尝试了一个简化版的自动化落地流程效果还行在这里做个简单分享。我用的方法是把已经格式化的用例表格复制给AI让它转换成Pytest风格的Python脚本。给AI的提示词如下以下是一组功能测试用例请按照Pytest框架编写自动化脚本。 要求 1. 使用pytest requests库暂不涉及UI自动化 2. 每条用例对应一个测试函数函数命名清晰表达场景 3. 测试数据使用fixture管理避免重复造数据 4. 断言信息必须包含具体的状态码和关键返回字段 5. 对依赖前置数据如优惠券的用例使用setup方法创建测试数据。 用例表格如下 ...AI返回的脚本架构是干净可用的一个conftest.py存放公共fixturetest_coupon.py存放优惠券相关用例utils.py封装了公共请求方法。虽然代码不算复杂但作为自动化测试的起点已经足够。这里我最大的感悟是只有用例阶段的“预期结果”写得足够具体脚本生成阶段才能顺滑衔接。如果你的预期结果全是“系统提示成功”这种话AI生成脚本时也会卡住最后只能写出一堆空有函数名没有断言的壳子。代码生成之后我还顺手试了一下代码审查功能。把AI生成的脚本再贴回给AI要求它从代码规范、异常捕获、断言完整性、重复代码抽取四个维度做审查。它给我提了几个合理的改进建议比如“测试函数之间没有隔离A用例修改的测试数据会影响B用例”以及“断言时建议先断言状态码再断言业务code最后断言message分层更清晰”。这些建议的质量大概相当于一位工作了两三年的自动化测试工程师Review的水平作为辅助参考够用了。从整个流程的交互过程来看“需求分析—用例生成—脚本生成—代码Review”确实可以串成一条流水线。而这条流水线的核心底座就是一套高质量、结构化、可复用的提示词资产。这也呼应了AI辅助测试领域的一句实话真正值钱的不是AI输出的那一坨文字而是你输入的那几行提示词背后凝结的知识。6 整个实操中我最想保留的几个习惯和下一步动作文章写到这里整个从PRD到用例、再到自动化前置探索的路程基本讲完了。最后分享几个我在实操过程中沉淀下来的小习惯这些都是踩过坑之后才总结出来的希望对你有帮助。第一个习惯是永远保留一轮“AI自我检查”。AI生成完用例之后我会固定追加一句提示词“请以测试组长的视角审查以上用例找出覆盖薄弱点并补充3-5条用例同时指出哪些用例可以合并删除。”这个操作相当于多了一个免费的“测试同行评审”尤其是面对复杂业务模块时往往能补出几个令人眼前一亮的边界场景。第二个习惯是给AI喂一个“反面教材”。所谓反面教材就是故意给AI看一条写得很差、很不具体的用例并明确告诉它“这是反面示例不要模仿”。实践证明AI对反面示例的敏感度远高于正面示例它能更准确地区分“好的用例”和“坏的用例”之间的差异。我通常会把公司里那些历史遗留的、表述模糊的用例挑出一两条作为反面教材。第三个习惯是定期把有效用例反馈回AI作为学习样本。我会把每次经过人工确认、最终通过评审的用例保存下来整合成一份《高通过率用例集》。在下次新项目启动时把这个用例集作为参考样本喂给AI让它“按照已确认的高质量用例风格”生成新用例。这其实就是提示词工程里的Few-Shot技巧用高质量的样例约束模型的输出风格实测下来效果比任何“风格形容词”都管用。关于下一步我会在这个系列后续文章里继续记录把AI生成的用例接入CI流水线结合容器执行自动化测试再把测试报告和AI的缺陷分析能力结合起来逐步摸索出一条更完整的AI辅助测试落地路径。如果你也在尝试用AI做测试用例生成或者在踩我踩过类似的坑欢迎把我上面分享的这些提示词拿去直接用跑完一轮记得回来告诉我效果如何。