1. 先讲个前提AI生成测试用例为什么火又为什么容易“翻车”1.1 我是在什么场景下开始用AI写测试用例的先说背景。我们团队是一个做企业级系统的测试小组产品线覆盖订单、支付、库存、权限几个核心域回归用例常年维持在三千条以上。最早接触AI生成测试用例是因为一个很现实的痛点每次发版前产品文档改一版接口字段加几个手工维护用例的时间和写用例的时间几乎持平。组里一直想找个办法把“自然语言描述需求”到“可执行测试用例”这段路自动化掉。当时选型也纠结过。直接用大模型生成脚本看起来很美但真正跑起来之后问题远比想象中多。不是AI不能用而是我们一开始对它的定位就错了。很多团队把AI当成一个“需求转用例的翻译器”喂一句描述期望吐出一组能直接跑回归的完整用例。实际用下来AI更像一个“想象力极其丰富但经常自作主张的实习生”你让它发挥它能把不存在的字段都给你编出来你把它管得太死它又只会输出千篇一律的模板货。这篇文章不是来推荐某个AI工具的也不是讲“AI替代测试工程师”那套大词的。我想认真拆一下我们在实际项目里踩过的七个坑。这些坑从低危到高危都有第三个坑甚至让一个接口带着错误状态码走进了线上回归门禁差一点就把事故放过去了。每一段我都会讲清楚现象是什么根因是什么我们后来用什么办法绕开的。如果你也在用AI生成测试用例或者正准备引入这篇应该能帮你省掉不少学费。1.2 AI写用例的底层逻辑概率生成不是需求推导先说一个必须建立的基本认知AI生成测试用例的原理本质是“基于上下文做概率性的文字续写”而不是“基于需求做确定性的逻辑推导”。也就是说大模型并不知道你的业务规则“为什么”是这样它只是在海量训练数据中学到了“类似需求一般会有什么测试点”的模式。这个区别决定了AI生成用例的天然缺陷。比如你写“用户下单支付成功库存扣减”AI会大概率补上“校验库存是否足够”“校验订单状态是否为已支付”“校验支付流水是否生成”这些常规点。这部分确实能帮我们省不少事。但当你要求它生成“余额不足时部分抵扣和赠送金叠加使用后的支付结果校验”如果训练样本里类似场景不够多它就可能用自己的常识强行补一段逻辑看起来合理实际上和你们的业务规则完全对不上。所以从第一天起就要把AI当成“测试设计助理”而不是“测试用例权威”。你给它喂什么上下文它输出什么质量你没给它讲清楚的边界它一定会自己脑补。这个认知不建立起来后面的几个坑基本都会踩一遍。2. 七个坑逐一拆解问题、现象、根因和规避方法2.1 坑一提示词太“虚”生成一堆正确的废话第一个坑几乎人人都会踩。提示词写得太模糊AI给你输出一堆“放之四海而皆准”的用例。比如你写“请生成登录功能的测试用例”它能给你写出三十条从“输入正确的用户名密码点击登录登录成功”到“连续输错密码五次账户锁定”看着哪条都对实际上哪条都用不上。因为这些内容你们团队的老测试员三年前就写过了你需要的是覆盖你们特有逻辑的用例而不是公开课级别的演示案例。真正的解法是给AI足够密集的“业务上下文”。我们把提示词分成了几个固定部分模块背景、接口信息或页面入口、核心业务规则、已有用例格式样例、需要重点覆盖的风险点。举个例子不是跟AI说“测试订单详情”而是说“订单详情页需要覆盖用户本人查看订单、子账号查看非本人订单、订单已取消但页面仍可访问、优惠金额分摊后与订单总金额相差不超过0.01元”。同样的模型前一种提示词生成的东西基本不能用后一种生成的东西评审一遍就能入库。我印象最深的是我们组一个同事第一次用AI生成用例时写了一句“请生成支付模块的功能测试用例”模型返回了三十条他和产品对了一遍真正能和业务规则对上的只有三条。后来改成结构化的“业务规则异常分支断言要求”三段式提示词同样的三十条里能用的直接变成二十一条。差别不是在模型而是在你有没有把规则说清楚。2.2 坑二把旧需求喂给AI用例版本错位第二个坑更隐蔽你把需求文档丢给AI但没告诉它“这是哪个版本”。很多系统的需求文档是迭代式维护的一个功能可能从V1.0一路改到V2.3文档里同时混杂着过期逻辑和当期逻辑。AI不像人它不会主动问“这里是不是已经下线了”它会默认你给的所有信息都是要覆盖的然后老老实实给过期的业务流程生成一套完整的用例。我们就有过这样的经历一个活动页在V2.1时下线了“老用户专享礼包”但需求文档里这段描述没删干净AI生成用例时把“老用户领取专享礼包”作为主流程写了进去。测试同学又恰好没细看用例直接进了回归集。结果每次跑回归这条用例必失败成了整个团队都知道的“定时炸弹”后来排查了半天才发现根本不是代码问题是用例在对着不存在的需求做校验。规避方法其实很简单给AI喂上下文前先做一次“需求剪枝”。把文档里和下个版本无关的内容删掉或者至少用一句话明确“以下为V2.3版本有效规则其他版本规则不做参考”。多花五分钟做这件事能省掉后面几小时的排查时间。现在我们的约定是AI生成的用例必须标注“需求来源版本号”没有标注版本号的用例不允许进入用例库。2.3 坑三断言像“安慰剂”差点放跑线上事故第三个坑是全篇的重点因为我们真的因为它差点出事。当时我们要为一个支付接口生成用例业务场景是“余额支付成功后订单状态变为已支付同时生成一笔流水”。AI给出的用例里断言部分长这样预期结果接口返回200返回码为0提示支付成功。这条用例在联调环境里跑了很多次都没问题因为正常路径确实返回200和code为0。后来线上出了一个隐蔽故障数据库写入超时订单表状态没有更新但接口层因为重试机制的原因最终给前端返回了HTTP 200响应体里的业务code仍然是0只在data字段里放了一个isSuccessfalse。这份写死的断言代码为expect(response.code).toBe(0)接口返回200字段也一样测试直接绿色通过。回归门禁放行了这个故障差一点点就被带上线。后来是下游的对账系统发现订单状态与支付流水不一致才把事故拦住。整个过程中AI生成的用例没有任何报警因为用例校验的是“长得很像成功”的信号而不是真实的业务结果。那一次之后我们把AI生成用例的断言规范彻底改了。生成用例时提示词里强制加入“断言内容必须包括业务状态变更、关键字段联动、幂等性判断、失败路径状态码”。接口返回200、code0这类“壳子”判断只能算辅助断言不能作为唯一的判定依据。以上面的例子来说正确的断言应该是支付成功后的订单状态必须为“已支付”且必须生成一条支付流水且流水金额与订单金额一致。不是说AI生成的断言完全不能用而是说AI很容易把“响应看起来正常”和“业务真的正常”画等号。这是它训练语料里的惯性也是测试设计师真正有价值的地方。我们后来把所有AI生成的断言都改成“强断言弱断言”的组合强断言校验业务结果弱断言记录响应壳信息。只有强断言全部通过用例才算通过。2.4 坑四用例之间互相重复回归成本翻倍第四个坑体现在用例规模上。AI生成用例有一个典型毛病同一份需求稍微换个说法它就能再给你生成一批。比如“用户未登录时访问订单页”和“未登录用户点击订单入口”在AI看来是两个不同的测试点但在实际系统里可能走的是同一条拦截逻辑。如果你不去重跑回归时就会重复执行同一段路径单条用例三秒钟三千条重复用例就是两个半小时。我们团队最夸张的一次一个下单模块AI生成了150条用例人工评审后发现真正有独立业务价值的只有62条。剩下的一半多有的是前置条件完全相同、只是换了个数据描述有的是预期结果互相矛盾一条断言“弹出库存不足”另一条断言“允许提交等待补货”。这种互相打架的用例放进同一套回归集里后果就是每次执行都有人要去解释“到底按哪条算”。去重的核心逻辑是“按业务场景聚合而不是按描述文字聚合”。我们现在让AI生成用例时给每个用例加上“唯一标识因子”一栏比如“前置状态操作对象关键输入预期业务状态”。用这四个因子做hash重复和等价用例就能自动识别出来。人工评审时重点看那些hash相同但描述不同的用例判断它们是冗余还是互补。2.5 坑五覆盖率高不代表有效覆盖AI最爱凑数说到覆盖率这里有个特别误导人的数字。AI生成用例后如果直接套用传统覆盖率工具去统计比如接口覆盖率和分支覆盖率数字通常会很漂亮。因为AI特别擅长在所有输入框里都填一遍“空值、超长值、特殊字符”把那些看起来不同的输入组合全部覆盖掉。但问题是覆盖率数字漂亮不代表风险被覆盖了。说一个我们碰到过的例子。AI为一个退款接口生成了三类边界值用例退款金额0元、退款金额超过订单金额、退款金额为负数。覆盖率工具一看三个分支都跑到指标100%。但我们人工检查后才发现这个接口真正的风险点在于退款原因类型与审核流程的关联不同原因类型会触发不同审核节点。AI根本没生成这部分用例因为在它拿到的提示词里我们没有强调审核流转规则。覆盖率是一个结果指标不是风险指标。AI擅长在“粒度”上做全面但系统崩不崩往往取决于“链路”上有没有盲区。所以我们的实践是不把覆盖率当成AI生成用例的验收目标而是额外让AI生成“链路场景用例”例如“下单-支付-发货-确认收货-申请售后”这种跨节点的场景。宁可要十条链路用例也不要一百条孤立的边界值用例。2.6 坑六把生产数据、敏感信息直接塞给AI这个坑不发生在用例逻辑上发生在数据安全上。很多测试同学为了方便直接把生产环境的用户手机号、身份证号、订单信息复制进提示词让AI生成对应的用例。这样做有两层风险第一这些数据可能落入模型服务商的日志里一旦被训练进模型等于把用户的隐私数据扩散了出去第二你等于把线上的真实结构信息暴露给了外部系统给后续的安全审计埋雷。我们团队在这件事上吃过教训。有一次入职不久的测试同学为了让AI生成“老用户召回活动”的用例直接把线上导出的一批脱敏不彻底的用户数据粘了进去。后来安全同事做例行检查时发现了这个操作虽然确认数据没有泄露出去但流程上停了半周还专门做了风险评估。正确的做法是所有喂给AI的数据必须经过“数据脱敏”环节。手机号用138****0000这种掩码格式身份证号用随机生成的假号码订单金额、优惠金额可以保留真实数值结构但要去掉任何能反查到真实用户的信息。同时在提示词里明确写明“以下数据均为测试模拟数据不涉及真实用户”。这事听起来基础但很多团队真到了赶工的时候就会把这条底线忘得一干二净。2.7 坑七没有建立用例评审和回收机制最后一个坑是流程层面的。AI生成的用例如果没有人评审、没有人维护时间一长就会变成一堆“僵尸用例”。这些用例跑着跑着开始报错但没人知道它是该修还是该删有些功能明明已经下线半年了AI生成的用例还在回归集里每天打卡。我们接手过一套从别组移交过来的AI用例资产一千多条用例只有三分之一能跑通剩下三分之二要么依赖的环境没了要么业务规则已经改了。最让人头疼的是所有用例都没有维护记录你根本不知道当初为什么加这条也没法判断现在能不能删。后来我们定了一条规矩AI生成的用例必须经过“生成-评审-标记-回收”四个环节。生成环节由AI完成评审环节必须由业务熟悉度最高的测试工程师签字确认标记环节在用例描述里打上“AI生成”标签方便追溯回收环节每隔两个月清理一次凡是连续三次跑失败的用例自动进入“待处置清单”需要由人和业务共同确认是修复还是删除。3. 一套能落地的打法从提示词到CI接入3.1 先定边界AI生成用例的输入输出约定把几个坑讲完再聊一下我们现在运行的完整流程。先说输入一个标准的AI用例生成请求必须包含四个部分需求版本号、业务规则摘要、接口或页面入口清单、断言要求。输出端也有固定格式每条用例必须包含用例编号、前置条件、操作步骤、测试数据、预期结果、关联需求、风险等级。这种格式化的好处是AI生成的用例可以直接进入评审流不需要测试人员再花时间整理格式。更重要的是“预期结果”里强制要求写明业务层面的最终状态而不是只写接口返回码。这一步直接把第三个坑的复发概率压到了最低。顺便提一下其实AI生成用例的格式要求本身就是一种约束。只要你把格式定义得足够细模型的幻觉率就会明显下降。我们对比过自由格式生成的用例和严格格式生成的用例评审通过率大概差了四倍。别小看提示词里的“格式约束”这一项这可能是性价比最高的控制手段。3.2 提示词模板我给团队的参考版本下面这套模板是我们内部在用的可以按项目情况改整体思路不变。模块背景此模块为订单状态机模块覆盖待支付、已支付、已发货、已完成、已取消五个状态。当期有效版本为V2.3。业务规则只有待支付状态允许执行取消操作已支付状态下用户申请退款后订单进入退款中状态已完成订单不允许再次发起售后。接口信息接口路径/order/cancel关键入参orderId、operatorId、cancelReason断言要求强断言取消成功后订单状态必须变为已取消且变更记录落库弱断言接口返回200响应格式为JSON。请基于以上信息生成接口测试用例每条用例必须包含前置条件、操作步骤、测试数据、预期结果、强断言、弱断言、风险等级。这套模板看着不复杂但合在一起就足够把AI引导到正确的范围里。关键是永远要告诉它“哪些是属于你们系统的特殊规则”而不是让它从通用的软件测试知识里自由发挥。3.3 用例评审“三步法”AI生成用例不能完全没人管但也不用逐条人工重写。我们现在用的是“三步法”。第一步先让AI按模块生成用例同时输出一个“用例结构清单”列出它计划覆盖的业务场景和风险点。评审人只审这个清单确认哪些方向对、哪些方向偏了五分钟就能完成。第二步AI按确认过的清单生成详细用例。评审人不再看图而是按“前置条件是否真实存在、断言是否验证业务结果、数据是否脱敏、是否存在重复”四个维度快速过一遍。这一步可能只需要看整体逻辑不用每一步都手动执行。第三步从AI生成的用例里挑出高风险场景小范围人工执行一轮再把执行结果回写进用例描述。这个闭环特别重要它等于给AI生成的用例做了一次“实测校准”。经过三步法处理的用例入库之后的维护成本能降低一半以上。3.4 如何把AI用例接进CI并自动去重接入CI/CD是很多团队关心的事。我们的做法是AI生成的用例先进入一个专门的“candidate”目录不直接并入主回归集。每天凌晨定时执行一次候选用例集统计通过率、失败率、耗时分布。连续三天通过率都达到95%以上的用例才由测试负责人合并进主回归集。自动去重这块上面提到过用“前置状态操作对象关键输入预期业务状态”做hash。在CI流水线里每次候选用例集执行前系统会自动算一遍这个hash值如果和主回归集中的已有用例重复就自动标注“疑似重复”并推送给评审人做最终裁决。这套机制跑了一个季度后我们主回归集的用例数量没有明显膨胀反而因为持续清理执行总时长比引入AI之前还降低了三成。AI真正帮我们省下的不是写用例的时间而是把我们从重复性的“模板劳动”里解放出来去关注真正需要人的经验和判断力的地方。4. 常见问题排查与技巧实录4.1 现场排查对照表在使用AI生成测试用例的过程中我们沉淀了一张排查表遇到问题可以直接对照定位。现象可能根因排查方向用例描述合理但执行必失败需求版本错位用例覆盖了已下线逻辑检查需求来源版本号比对当期有效规则断言只检查返回码不检查业务状态提示词中未强调业务结果断言重写提示词加入强断言字段用例大量重复未设置唯一标识因子用前置状态操作对象关键输入预期业务状态做hash去重覆盖率很高但核心流程没测到AI在边界值上凑数链路场景缺失提示词中加入“链路场景用例”要求用例中包含敏感数据直接复制了生产环境数据接入脱敏处理环节禁止原始数据进入提示词用例没人维护越攒越乱缺少回收机制建立“生成-评审-标记-回收”闭环这张表不是万能的但它能帮你从“这系统怎么回事”快速跳转到“这个问题该从哪里下手修”。4.2 我踩过几次坑之后沉淀的几条原则第一个原则永远不要让AI承担最终判断。AI生成用例是提效工具它不能替你做业务判断更不能替你对线上事故负责。凡是涉及钱、权限、用户隐私的用例人一定要逐条看。第二个原则把提示词当成代码来维护。提示词不是一次性写完之后就扔了的业务规则变了提示词就要同步改。我们团队现在给每个模块维护一份提示词文件放在项目仓库里纳入版本管理谁改了规则谁就要更新对应的提示词。第三个原则用“已知缺陷”反向校验AI。AI生成的用例如果覆盖不到历史缺陷那它其实没有真正帮你守护质量。我们把过去一年的线上缺陷整理成了一个“缺陷回归场景库”每次让AI做用例生成时把和当前模块相关的历史缺陷塞进提示词里作为强制覆盖项。这样一来AI生成用例的能力就能持续往历史教训上聚焦而不是每次从头发明一套。4.3 用好AI但别迷信AI人机协同的边界说到底AI生成测试用例这件事真正的价值不在“替代”而在“把低效重复的部分压缩掉”。它最擅长的是把需求描述迅速铺开帮测试工程师建立场景清单省掉从空白页开始写的痛苦。但它不擅长的是理解你们系统的特殊约定、历史包袱和隐性风险这些事情只有常年待在项目里的人才知道。我的建议是团队在用AI生成用例时一定要把“谁对最终质量负责”这句话写在流程文档的第一行。AI可以出错流程可以优化但最终拍板的人必须清楚自己在拍什么。只要这个边界不模糊AI就能成为测试团队里最得力的助理如果边界模糊了AI生成的那些看似完美的用例就会变成质量体系里最危险的漏洞。 
长河君 · 2026/11/2 12:47:11 · 阅读 1.2k AI生成测试用例的七个坑与落地实践
1. 先讲个前提AI生成测试用例为什么火又为什么容易“翻车”1.1 我是在什么场景下开始用AI写测试用例的先说背景。我们团队是一个做企业级系统的测试小组产品线覆盖订单、支付、库存、权限几个核心域回归用例常年维持在三千条以上。最早接触AI生成测试用例是因为一个很现实的痛点每次发版前产品文档改一版接口字段加几个手工维护用例的时间和写用例的时间几乎持平。组里一直想找个办法把“自然语言描述需求”到“可执行测试用例”这段路自动化掉。当时选型也纠结过。直接用大模型生成脚本看起来很美但真正跑起来之后问题远比想象中多。不是AI不能用而是我们一开始对它的定位就错了。很多团队把AI当成一个“需求转用例的翻译器”喂一句描述期望吐出一组能直接跑回归的完整用例。实际用下来AI更像一个“想象力极其丰富但经常自作主张的实习生”你让它发挥它能把不存在的字段都给你编出来你把它管得太死它又只会输出千篇一律的模板货。这篇文章不是来推荐某个AI工具的也不是讲“AI替代测试工程师”那套大词的。我想认真拆一下我们在实际项目里踩过的七个坑。这些坑从低危到高危都有第三个坑甚至让一个接口带着错误状态码走进了线上回归门禁差一点就把事故放过去了。每一段我都会讲清楚现象是什么根因是什么我们后来用什么办法绕开的。如果你也在用AI生成测试用例或者正准备引入这篇应该能帮你省掉不少学费。1.2 AI写用例的底层逻辑概率生成不是需求推导先说一个必须建立的基本认知AI生成测试用例的原理本质是“基于上下文做概率性的文字续写”而不是“基于需求做确定性的逻辑推导”。也就是说大模型并不知道你的业务规则“为什么”是这样它只是在海量训练数据中学到了“类似需求一般会有什么测试点”的模式。这个区别决定了AI生成用例的天然缺陷。比如你写“用户下单支付成功库存扣减”AI会大概率补上“校验库存是否足够”“校验订单状态是否为已支付”“校验支付流水是否生成”这些常规点。这部分确实能帮我们省不少事。但当你要求它生成“余额不足时部分抵扣和赠送金叠加使用后的支付结果校验”如果训练样本里类似场景不够多它就可能用自己的常识强行补一段逻辑看起来合理实际上和你们的业务规则完全对不上。所以从第一天起就要把AI当成“测试设计助理”而不是“测试用例权威”。你给它喂什么上下文它输出什么质量你没给它讲清楚的边界它一定会自己脑补。这个认知不建立起来后面的几个坑基本都会踩一遍。2. 七个坑逐一拆解问题、现象、根因和规避方法2.1 坑一提示词太“虚”生成一堆正确的废话第一个坑几乎人人都会踩。提示词写得太模糊AI给你输出一堆“放之四海而皆准”的用例。比如你写“请生成登录功能的测试用例”它能给你写出三十条从“输入正确的用户名密码点击登录登录成功”到“连续输错密码五次账户锁定”看着哪条都对实际上哪条都用不上。因为这些内容你们团队的老测试员三年前就写过了你需要的是覆盖你们特有逻辑的用例而不是公开课级别的演示案例。真正的解法是给AI足够密集的“业务上下文”。我们把提示词分成了几个固定部分模块背景、接口信息或页面入口、核心业务规则、已有用例格式样例、需要重点覆盖的风险点。举个例子不是跟AI说“测试订单详情”而是说“订单详情页需要覆盖用户本人查看订单、子账号查看非本人订单、订单已取消但页面仍可访问、优惠金额分摊后与订单总金额相差不超过0.01元”。同样的模型前一种提示词生成的东西基本不能用后一种生成的东西评审一遍就能入库。我印象最深的是我们组一个同事第一次用AI生成用例时写了一句“请生成支付模块的功能测试用例”模型返回了三十条他和产品对了一遍真正能和业务规则对上的只有三条。后来改成结构化的“业务规则异常分支断言要求”三段式提示词同样的三十条里能用的直接变成二十一条。差别不是在模型而是在你有没有把规则说清楚。2.2 坑二把旧需求喂给AI用例版本错位第二个坑更隐蔽你把需求文档丢给AI但没告诉它“这是哪个版本”。很多系统的需求文档是迭代式维护的一个功能可能从V1.0一路改到V2.3文档里同时混杂着过期逻辑和当期逻辑。AI不像人它不会主动问“这里是不是已经下线了”它会默认你给的所有信息都是要覆盖的然后老老实实给过期的业务流程生成一套完整的用例。我们就有过这样的经历一个活动页在V2.1时下线了“老用户专享礼包”但需求文档里这段描述没删干净AI生成用例时把“老用户领取专享礼包”作为主流程写了进去。测试同学又恰好没细看用例直接进了回归集。结果每次跑回归这条用例必失败成了整个团队都知道的“定时炸弹”后来排查了半天才发现根本不是代码问题是用例在对着不存在的需求做校验。规避方法其实很简单给AI喂上下文前先做一次“需求剪枝”。把文档里和下个版本无关的内容删掉或者至少用一句话明确“以下为V2.3版本有效规则其他版本规则不做参考”。多花五分钟做这件事能省掉后面几小时的排查时间。现在我们的约定是AI生成的用例必须标注“需求来源版本号”没有标注版本号的用例不允许进入用例库。2.3 坑三断言像“安慰剂”差点放跑线上事故第三个坑是全篇的重点因为我们真的因为它差点出事。当时我们要为一个支付接口生成用例业务场景是“余额支付成功后订单状态变为已支付同时生成一笔流水”。AI给出的用例里断言部分长这样预期结果接口返回200返回码为0提示支付成功。这条用例在联调环境里跑了很多次都没问题因为正常路径确实返回200和code为0。后来线上出了一个隐蔽故障数据库写入超时订单表状态没有更新但接口层因为重试机制的原因最终给前端返回了HTTP 200响应体里的业务code仍然是0只在data字段里放了一个isSuccessfalse。这份写死的断言代码为expect(response.code).toBe(0)接口返回200字段也一样测试直接绿色通过。回归门禁放行了这个故障差一点点就被带上线。后来是下游的对账系统发现订单状态与支付流水不一致才把事故拦住。整个过程中AI生成的用例没有任何报警因为用例校验的是“长得很像成功”的信号而不是真实的业务结果。那一次之后我们把AI生成用例的断言规范彻底改了。生成用例时提示词里强制加入“断言内容必须包括业务状态变更、关键字段联动、幂等性判断、失败路径状态码”。接口返回200、code0这类“壳子”判断只能算辅助断言不能作为唯一的判定依据。以上面的例子来说正确的断言应该是支付成功后的订单状态必须为“已支付”且必须生成一条支付流水且流水金额与订单金额一致。不是说AI生成的断言完全不能用而是说AI很容易把“响应看起来正常”和“业务真的正常”画等号。这是它训练语料里的惯性也是测试设计师真正有价值的地方。我们后来把所有AI生成的断言都改成“强断言弱断言”的组合强断言校验业务结果弱断言记录响应壳信息。只有强断言全部通过用例才算通过。2.4 坑四用例之间互相重复回归成本翻倍第四个坑体现在用例规模上。AI生成用例有一个典型毛病同一份需求稍微换个说法它就能再给你生成一批。比如“用户未登录时访问订单页”和“未登录用户点击订单入口”在AI看来是两个不同的测试点但在实际系统里可能走的是同一条拦截逻辑。如果你不去重跑回归时就会重复执行同一段路径单条用例三秒钟三千条重复用例就是两个半小时。我们团队最夸张的一次一个下单模块AI生成了150条用例人工评审后发现真正有独立业务价值的只有62条。剩下的一半多有的是前置条件完全相同、只是换了个数据描述有的是预期结果互相矛盾一条断言“弹出库存不足”另一条断言“允许提交等待补货”。这种互相打架的用例放进同一套回归集里后果就是每次执行都有人要去解释“到底按哪条算”。去重的核心逻辑是“按业务场景聚合而不是按描述文字聚合”。我们现在让AI生成用例时给每个用例加上“唯一标识因子”一栏比如“前置状态操作对象关键输入预期业务状态”。用这四个因子做hash重复和等价用例就能自动识别出来。人工评审时重点看那些hash相同但描述不同的用例判断它们是冗余还是互补。2.5 坑五覆盖率高不代表有效覆盖AI最爱凑数说到覆盖率这里有个特别误导人的数字。AI生成用例后如果直接套用传统覆盖率工具去统计比如接口覆盖率和分支覆盖率数字通常会很漂亮。因为AI特别擅长在所有输入框里都填一遍“空值、超长值、特殊字符”把那些看起来不同的输入组合全部覆盖掉。但问题是覆盖率数字漂亮不代表风险被覆盖了。说一个我们碰到过的例子。AI为一个退款接口生成了三类边界值用例退款金额0元、退款金额超过订单金额、退款金额为负数。覆盖率工具一看三个分支都跑到指标100%。但我们人工检查后才发现这个接口真正的风险点在于退款原因类型与审核流程的关联不同原因类型会触发不同审核节点。AI根本没生成这部分用例因为在它拿到的提示词里我们没有强调审核流转规则。覆盖率是一个结果指标不是风险指标。AI擅长在“粒度”上做全面但系统崩不崩往往取决于“链路”上有没有盲区。所以我们的实践是不把覆盖率当成AI生成用例的验收目标而是额外让AI生成“链路场景用例”例如“下单-支付-发货-确认收货-申请售后”这种跨节点的场景。宁可要十条链路用例也不要一百条孤立的边界值用例。2.6 坑六把生产数据、敏感信息直接塞给AI这个坑不发生在用例逻辑上发生在数据安全上。很多测试同学为了方便直接把生产环境的用户手机号、身份证号、订单信息复制进提示词让AI生成对应的用例。这样做有两层风险第一这些数据可能落入模型服务商的日志里一旦被训练进模型等于把用户的隐私数据扩散了出去第二你等于把线上的真实结构信息暴露给了外部系统给后续的安全审计埋雷。我们团队在这件事上吃过教训。有一次入职不久的测试同学为了让AI生成“老用户召回活动”的用例直接把线上导出的一批脱敏不彻底的用户数据粘了进去。后来安全同事做例行检查时发现了这个操作虽然确认数据没有泄露出去但流程上停了半周还专门做了风险评估。正确的做法是所有喂给AI的数据必须经过“数据脱敏”环节。手机号用138****0000这种掩码格式身份证号用随机生成的假号码订单金额、优惠金额可以保留真实数值结构但要去掉任何能反查到真实用户的信息。同时在提示词里明确写明“以下数据均为测试模拟数据不涉及真实用户”。这事听起来基础但很多团队真到了赶工的时候就会把这条底线忘得一干二净。2.7 坑七没有建立用例评审和回收机制最后一个坑是流程层面的。AI生成的用例如果没有人评审、没有人维护时间一长就会变成一堆“僵尸用例”。这些用例跑着跑着开始报错但没人知道它是该修还是该删有些功能明明已经下线半年了AI生成的用例还在回归集里每天打卡。我们接手过一套从别组移交过来的AI用例资产一千多条用例只有三分之一能跑通剩下三分之二要么依赖的环境没了要么业务规则已经改了。最让人头疼的是所有用例都没有维护记录你根本不知道当初为什么加这条也没法判断现在能不能删。后来我们定了一条规矩AI生成的用例必须经过“生成-评审-标记-回收”四个环节。生成环节由AI完成评审环节必须由业务熟悉度最高的测试工程师签字确认标记环节在用例描述里打上“AI生成”标签方便追溯回收环节每隔两个月清理一次凡是连续三次跑失败的用例自动进入“待处置清单”需要由人和业务共同确认是修复还是删除。3. 一套能落地的打法从提示词到CI接入3.1 先定边界AI生成用例的输入输出约定把几个坑讲完再聊一下我们现在运行的完整流程。先说输入一个标准的AI用例生成请求必须包含四个部分需求版本号、业务规则摘要、接口或页面入口清单、断言要求。输出端也有固定格式每条用例必须包含用例编号、前置条件、操作步骤、测试数据、预期结果、关联需求、风险等级。这种格式化的好处是AI生成的用例可以直接进入评审流不需要测试人员再花时间整理格式。更重要的是“预期结果”里强制要求写明业务层面的最终状态而不是只写接口返回码。这一步直接把第三个坑的复发概率压到了最低。顺便提一下其实AI生成用例的格式要求本身就是一种约束。只要你把格式定义得足够细模型的幻觉率就会明显下降。我们对比过自由格式生成的用例和严格格式生成的用例评审通过率大概差了四倍。别小看提示词里的“格式约束”这一项这可能是性价比最高的控制手段。3.2 提示词模板我给团队的参考版本下面这套模板是我们内部在用的可以按项目情况改整体思路不变。模块背景此模块为订单状态机模块覆盖待支付、已支付、已发货、已完成、已取消五个状态。当期有效版本为V2.3。业务规则只有待支付状态允许执行取消操作已支付状态下用户申请退款后订单进入退款中状态已完成订单不允许再次发起售后。接口信息接口路径/order/cancel关键入参orderId、operatorId、cancelReason断言要求强断言取消成功后订单状态必须变为已取消且变更记录落库弱断言接口返回200响应格式为JSON。请基于以上信息生成接口测试用例每条用例必须包含前置条件、操作步骤、测试数据、预期结果、强断言、弱断言、风险等级。这套模板看着不复杂但合在一起就足够把AI引导到正确的范围里。关键是永远要告诉它“哪些是属于你们系统的特殊规则”而不是让它从通用的软件测试知识里自由发挥。3.3 用例评审“三步法”AI生成用例不能完全没人管但也不用逐条人工重写。我们现在用的是“三步法”。第一步先让AI按模块生成用例同时输出一个“用例结构清单”列出它计划覆盖的业务场景和风险点。评审人只审这个清单确认哪些方向对、哪些方向偏了五分钟就能完成。第二步AI按确认过的清单生成详细用例。评审人不再看图而是按“前置条件是否真实存在、断言是否验证业务结果、数据是否脱敏、是否存在重复”四个维度快速过一遍。这一步可能只需要看整体逻辑不用每一步都手动执行。第三步从AI生成的用例里挑出高风险场景小范围人工执行一轮再把执行结果回写进用例描述。这个闭环特别重要它等于给AI生成的用例做了一次“实测校准”。经过三步法处理的用例入库之后的维护成本能降低一半以上。3.4 如何把AI用例接进CI并自动去重接入CI/CD是很多团队关心的事。我们的做法是AI生成的用例先进入一个专门的“candidate”目录不直接并入主回归集。每天凌晨定时执行一次候选用例集统计通过率、失败率、耗时分布。连续三天通过率都达到95%以上的用例才由测试负责人合并进主回归集。自动去重这块上面提到过用“前置状态操作对象关键输入预期业务状态”做hash。在CI流水线里每次候选用例集执行前系统会自动算一遍这个hash值如果和主回归集中的已有用例重复就自动标注“疑似重复”并推送给评审人做最终裁决。这套机制跑了一个季度后我们主回归集的用例数量没有明显膨胀反而因为持续清理执行总时长比引入AI之前还降低了三成。AI真正帮我们省下的不是写用例的时间而是把我们从重复性的“模板劳动”里解放出来去关注真正需要人的经验和判断力的地方。4. 常见问题排查与技巧实录4.1 现场排查对照表在使用AI生成测试用例的过程中我们沉淀了一张排查表遇到问题可以直接对照定位。现象可能根因排查方向用例描述合理但执行必失败需求版本错位用例覆盖了已下线逻辑检查需求来源版本号比对当期有效规则断言只检查返回码不检查业务状态提示词中未强调业务结果断言重写提示词加入强断言字段用例大量重复未设置唯一标识因子用前置状态操作对象关键输入预期业务状态做hash去重覆盖率很高但核心流程没测到AI在边界值上凑数链路场景缺失提示词中加入“链路场景用例”要求用例中包含敏感数据直接复制了生产环境数据接入脱敏处理环节禁止原始数据进入提示词用例没人维护越攒越乱缺少回收机制建立“生成-评审-标记-回收”闭环这张表不是万能的但它能帮你从“这系统怎么回事”快速跳转到“这个问题该从哪里下手修”。4.2 我踩过几次坑之后沉淀的几条原则第一个原则永远不要让AI承担最终判断。AI生成用例是提效工具它不能替你做业务判断更不能替你对线上事故负责。凡是涉及钱、权限、用户隐私的用例人一定要逐条看。第二个原则把提示词当成代码来维护。提示词不是一次性写完之后就扔了的业务规则变了提示词就要同步改。我们团队现在给每个模块维护一份提示词文件放在项目仓库里纳入版本管理谁改了规则谁就要更新对应的提示词。第三个原则用“已知缺陷”反向校验AI。AI生成的用例如果覆盖不到历史缺陷那它其实没有真正帮你守护质量。我们把过去一年的线上缺陷整理成了一个“缺陷回归场景库”每次让AI做用例生成时把和当前模块相关的历史缺陷塞进提示词里作为强制覆盖项。这样一来AI生成用例的能力就能持续往历史教训上聚焦而不是每次从头发明一套。4.3 用好AI但别迷信AI人机协同的边界说到底AI生成测试用例这件事真正的价值不在“替代”而在“把低效重复的部分压缩掉”。它最擅长的是把需求描述迅速铺开帮测试工程师建立场景清单省掉从空白页开始写的痛苦。但它不擅长的是理解你们系统的特殊约定、历史包袱和隐性风险这些事情只有常年待在项目里的人才知道。我的建议是团队在用AI生成用例时一定要把“谁对最终质量负责”这句话写在流程文档的第一行。AI可以出错流程可以优化但最终拍板的人必须清楚自己在拍什么。只要这个边界不模糊AI就能成为测试团队里最得力的助理如果边界模糊了AI生成的那些看似完美的用例就会变成质量体系里最危险的漏洞。