我平时算是个AI工具的重度使用者代码生成、文档整理都很依赖它。但这次我必须承认AI差点让我把一套订单系统直接送上线就崩。事情是这样的我负责给一个订单子系统补接口测试用例图省事把接口清单丢给AI批量生成。AI吐回六十多个pytest用例CI跑起来全绿我还挺满意。结果发布前做压测现场发现库存并发回滚扣多了再往前一查问题根子恰恰出在AI生成的用例上——它们太“正常”了只测了单一用户、单一请求、顺畅链路线上真正的杀手场景一个没碰到。这篇文章不聊理论就把我如何被AI测试用例坑进去、又如何一步步把它拉回正轨的过程完整写下来包括每个坑的具体表现、我怎么排查的以及现在我用AI写测试用例的固定套路。适合刚把AI引入测试流程、或者正在犹豫要不要让AI批量生成用例的团队参考。1. 项目复盘AI测试用例差点让系统上线就崩1.1 这个项目到底在做什么我为什么想到用AI项目是一套电商订单子系统核心链路是用户下单、支付回调、取消订单。技术栈不复杂服务端接口加MySQL和Redis支付对接的是外部通道。我负责整理端到端接口测试既要保证业务流程能走通也得在版本发布前尽量兜住回归风险。工作量大是第一感受。取消订单、支付回调、库存回滚、退款补偿每个接口都拆出一堆分支。我当时的判断是这种体力活完全可以交给AI先干一版。于是我把接口路径、请求参数定义、响应结构一股脑贴给AI下了个指令“帮这个订单模块生成pytest接口测试用例尽量覆盖全”。AI输出的初稿确实像模像样。用例数量不少命名规范断言也有有好多我没想到的变体比如超时返回、参数缺省这种。我扫了几眼又跑了一遍全是绿的就把它并入了回归流水线。事后复盘问题恰恰出在“扫了几眼”上AI生成的用例可以很快但我没有意识到它给出的“覆盖”只是入口覆盖不是风险覆盖。1.2 那个差点爆掉的业务场景具体长什么样出问题的是取消订单接口。业务规则本身不太复杂只有待支付、已支付、未发货状态可以取消已支付订单要触发退款取消成功后要把库存回滚回去重复取消则要做幂等处理不能报错也不能重复回滚。AI生成的取消订单用例大概长这样def test_cancel_order_success(): order_id create_order() resp client.post(/api/order/cancel, json{order_id: order_id}) assert resp.status_code 200 assert resp.json()[code] 0这个用例只验证了接口返回200和业务code等于0然后就没有然后了。订单状态真的变了吗没验。库存真的加回去了吗没验。退款流程有没有正确触发也没验。更麻烦的是AI压根没考虑两个用户同时取消同一订单或同一订单被重复取消的场景。压测时我们用了两百个并发同时取消同一笔订单结果库存被回滚了不止一次。排查发现逻辑是先读订单状态再更新状态最后执行库存回滚两个线程同时读到“待支付”状态时都会往下走回滚分支库存记录就多扣了一次。这种并发场景在AI给的用例里完全不存在。要不是压测拦了一把这个带病版本发出去用户量一大必然出事故。2. 拆解AI测试用例的三个致命短板2.1 短板一写出来的全是“假绿”断言根本没落到底AI生成的用例最大的特征是“返回什么都接受”。状态码是200业务码是0它就认为没问题了。这种断言最直接的问题在于它验证的是接口有没有响应而不是业务有没有做对。我说个具体例子。支付回调接口逻辑要求是收到支付平台通知后更新订单状态同时写支付流水。AI给的用例只检查了接口返回成功但线上曾经出现过数据库事务提交失败、订单状态没更新的情况那种异常这个用例根本发现不了。因为断言里压根没有查订单表、没有校验流水数、也没有验证回调的幂等性。正确做法是把“业务成功”定义清楚。比如取消订单接口断言范围应该是订单状态已变为CANCELLED、库存已增加、退款单已生成、重复取消也不抛错。我后来给AI写prompt时会明确要求“所有用例断言不能只停留在HTTP状态码必须验证业务副作用。”这句话加进去之后AI生成用例的质量明显上了一个台阶。2.2 短板二过度mock把系统的真实风险全挡在门外AI在生成测试用例时经常建议用mock隔离外部依赖。听起来很合理它也确实能提高跑测速度。但AI不会区分什么依赖可以mock、什么依赖不能mock。最典型的例子是Redis缓存。AI为了省事直接把Redis读写的部分mock掉了。结果呢缓存穿透、缓存过期、并发更新缓存这些真实场景全部测不到。这些恰恰是线上最容易出问题的地方。支付通道也被mock了只留下一个固定成功的假通道。那系统里真正核心的“支付超时怎么办、支付失败怎么补偿、重复回调怎么处理”就全变成盲区了。我现在给自己定了个规矩测试用例可以mock但只能mock测试环境里不存在的第三方系统比如外部支付通道、短信平台。自己系统内部的Redis、数据库、消息队列一律用真实的。mock越少测试结果越接近真实环境越能唬住人——反过来说每个人都喜欢测试能跑得快一点但如果因为mock导致问题测不出来前面省下的时间会连本带利还给线上故障。2.3 短板三测试数据太“干净”一进生产就露馅AI生成测试数据有很明显的AI味手机号是13800138000身份证号18位整整齐齐库存是100价格是99.9。这种数据好看但跟生产环境差了太远。真实环境的数据根本不是这样订单号可能特别长备注可能有几百个字符手机号可能有特殊前缀库存可能是0甚至负数价格可能是0.01元或者是免费商品。再比如数据库字段有唯一索引生产环境里总会有重复提交、并发插入的记录AI生成的数据就很少模拟这种冲突。吃了一次亏之后我让AI专门生成“脏数据”用例它反而做得不错。让它构造超长字符串、NULL字段、重复主键、负库存、时间戳精度不一致这些AI生成出来的用例比我手工写的还快。关键是我得想起来把这些数据形态带到测试场景里而不是让AI自己想。它默认会给你一份“全世界都在正常运行”的数据但我们干测试的恰恰要站在“全世界都在不正常运行”这一边去设计用例。3. 实操纠正我是怎么把AI测试用例从坑里拉出来的3.1 第一步把AI生成的用例全部降级为“初稿”重新梳理风险那次差点上线就崩之后我做的第一件事不是继续用AI补用例而是把所有AI产物全部重新审视。我拉了一张表格把每个接口按业务风险重新过了一遍这个接口涉及钱吗涉及状态变更吗涉及幂等吗涉及并发吗涉及外部依赖吗每个涉及项都要有对应的用例。原来AI生成了六十多个用例我梳理完发现真正能顶用的不到一半。剩下的要么是重复场景要么是断言不到位要么是数据不真实。这一步确实费时间但值。因为整理完风险点之后我不仅知道AI漏了什么也知道了系统哪些地方最脆弱后面让AI补齐用例就有了明确方向。3.2 第二步用状态矩阵去喂AI逼它生成全状态流转用例我发现AI拿到单个接口定义时只会生成局部视角的用例。它看不到这个接口在不同前置状态下应该有不同的行为。于是我把订单系统的状态机整理出来写成了状态流转矩阵CREATED订单已创建待支付PAID已支付SHIPPED已发货COMPLETED已完成CANCELLED已取消REFUNDING退款中REFUND_FAILED退款失败我把这个矩阵作为上下文喂给AI让它每个状态到每个状态的合法跳转、非法跳转都生成用例特别注意哪些操作在非法状态下必须被拒绝。这一步效果很明显。AI很快就补出了“已发货订单不允许取消”“退款失败后的补偿操作”“重复取消返回统一结果”这类用例而这些之前完全没有。3.3 第三步给AI下硬性约束不允许它“自由发挥”命令AI生成测试用例时光说“帮我写接口测试”是不行的。我现在会在prompt里强制写清楚下面几条约束所有用例必须验证数据库或缓存中的真实状态不能只检查返回码必须包含并发场景至少要两个线程同时操作同一资源必须包含失败注入比如支付超时、回滚失败、重复回调不允许mock系统内部的Redis、数据库、消息队列测试数据要包含边界值和非法值这些约束本质上是把测试设计的原则前置到了prompt里。AI确实很聪明你给它边界越清晰它生成的东西越接近可用。反过来你只给一个宽泛的接口描述它更倾向生成看起来面面俱到、实际什么都测不深的“样板间”用例。3.4 第四步把AI用例纳入常规review流程不让它直接入库我后来规定AI生成的测试代码和人工写的测试代码一样必须经过review才能进仓库。review重点四件事一是断言是否足够强二是依赖是否真实三是异常分支是否覆盖四是数据形态是否贴合生产。整个过程听起来好像没什么炫技但确实是我在项目里最值的一步。AI可以是很强的初稿生成器但它不能替代测试设计本身。你让AI生成测试用例它只是把你喂给它的上下文重新编排了一遍。如果你的上下文里没有业务风险的意识那么它生成的用例再好看也是空的。4. AI测试用例常见问题速查与排查套路4.1 我把踩过的坑整理成了一张速查表常见现象根本原因排查方法用例全绿但线上出问题断言只落在状态码上没落到业务结果拿一个线上故障反推用例能否捕获不能捕获就是断言有问题mock掉之后用例稳定联调时又崩过度隔离了系统内部组件逐层移除mock用真实依赖重新跑测试测试数据跑得通但覆盖不全数据太“标准”缺少边界值给AI补充脏数据、边界值、重复值要求用例数量很多但大量重复prompt范围太宽AI只做表面枚举收敛到单个接口状态矩阵再分场景生成并发相关bug一直没被发现测试完全基于单线程增加多线程并发用例至少覆盖同资源竞争偶尔失败、重新跑又过用例间存在数据耦合或时序依赖每个用例独立初始化测试数据保证互不干扰这张表现在贴在我们测试组文档最前面。每次有新人觉得AI生成的用例可靠的时候我先让他们把表读一遍再拿最近一次的线上问题去试AI基本都能发现AI用例的死角。4.2 排查AI用例质量我用了一个很土但很有效的方法有一种办法可以快速识别AI生成的测试用例到底有没有用叫“变异测试”。具体操作很简单手动把业务代码里的一行逻辑改错比如把“扣减库存”改成“增加库存”然后跑测试用例。如果用例能在变异后失败说明它对这个行为变化敏感如果变异后测试依然全绿那就说明这个用例根本没验证到点上。我用这个方法去试AI生成的那批用例时结果非常难看。改掉“取消订单后库存必须回滚”的逻辑AI用例照样绿。改掉“订单状态必须变更为CANCELLED”AI用例还是绿。原因是它的断言根本没有查数据库状态。这部分我后来手动补齐了再跑变异测试总算能把这些关键错误挡住了。这个方法不复杂但对AI测试用例的质量校验非常有效因为AI可以把代码写得像模像样可它是否真的验证到了业务流程的关键逻辑只有变异测试能直接暴露出来。我在每一次让AI生成完用例后至少挑三个核心业务逻辑做变异测试通过了我才敢信它。4.3 我现在用的三段式prompt效果比一句话指令好得多很多人用AI生成测试用例就丢一句话“帮这个接口写测试”。这其实是在浪费AI。我实践下来最好用的是三段式prompt第一部分给角色和范围第二部分给业务规则第三部分给硬性约束。举个例子我一个典型的prompt是这样的你是一位资深测试工程师负责订单模块的接口测试。 被测接口是取消订单接口要求如下 1. 只有待支付、已支付、未发货状态可以取消 2. 已支付订单必须触发退款 3. 取消成功后必须回滚库存 4. 重复取消必须幂等不能重复回滚 5. 并发取消同一订单不能导致数据异常 请生成pytest用例注意 - 不能只断言HTTP状态码必须验证订单状态和库存结果 - 必须覆盖状态非法、重复取消、并发取消、退款失败四类场景 - 测试数据要包含边界值和非法值 - 不要mock系统内部的Redis和数据库对比一下就知道了这种prompt生成出来的用例命中率高很多。原因很简单我先把测试设计的核心思路压缩成了输入AI的角色就变成了一个“执行者”而不是一个替我做测试设计的“决策者”。把测试设计工作留给自己AI负责写字这样才能真正用好它。5. 我现在到底怎么用AI写测试用例5.1 先把AI定位成“初稿机器”不是“测试负责人”经过那一轮折腾我对AI的定位彻底改变了。它擅长的是把你给它明确的边界条件快速转成可执行代码但它不擅长从零判断一个系统的业务风险在哪里。所以我现在的工作流是先自己把业务风险、状态流转、异常分支梳理清楚再让AI去做初稿生成和执行。如果你一上来就让AI“看着办”它给你的永远是最常见、最标准、最安全的路径。但这恰恰和测试的目标背道而驰因为测试要的恰恰是非常见、非标准、不安全的那部分覆盖。5.2 把接口定义和业务规则直接喂进去不让AI猜我后来发现AI生成测试用例的质量很大程度取决于你给它多少上下文。只给它一个接口路径它就是在猜接口的输入输出自然生成不了什么有效的断言。如果我把接口的请求参数定义、响应结构、枚举值、状态字段说明全部贴给它它生成出来的用例明显更贴业务。我把自己的经验总结成一句话你给AI的信息密度决定AI生成用例的有效密度。上下文越完整AI越能产出贴合真实业务的测试用例。上下文越少AI越会拿通用模板来糊弄你。测试用例是拿来保命的不是拿来凑数的。5.3 增加一个人肉review环节这是我的底线无论AI现在变得多强我在测试流程里始终留了一个不可省略的环节人工审用例。不是不信任AI而是因为它没有经历过业务线上那几场事故不熟悉那些看起来离谱却被用户真实撞出来的场景。人可以站在“系统哪里最容易爆”的角度去审视用例AI暂时做不到。我现在的人肉review清单很简单每个用例有没有独立初始化数据断言有没有落到业务状态而不是状态码有没有覆盖重复操作、并发操作、失败补偿、数据异常四类场景测试数据与生产环境数据形态是否一致。任何一条不合格AI生成得再快都不会被接入流水线。5.4 顺手分享一个小技巧用历史线上问题反向校验AI用例最后一个建议也是我自认为最实用的每让AI生成一批用例就挑几个过去发生过的线上问题去验证这批用例能不能把它拦下来。比如以前的线上事故是某个订单因为状态判断错误被重复取消那你就看AI用例里有没有这个场景没有就补进去。这相当于用真实世界的事故数据去校准AI生成的用例。因为AI不知道你们系统的旧事故记录它只会按常理出牌。而我们的工作恰恰是要超越常理把那些几乎不会发生但一发生就要命的情况提前测出来。这个方法不需要什么额外工具但效果比单纯让AI多生成几百条用例强得多。那次差点上线就崩的经历我现在回忆起来还冒冷汗。但也正是那次让我彻底想明白了一件事AI生成测试用例的价值是“快”不是“准”。准的部分必须靠人去补。ICS的教训比任何课程都值钱。
