上线前一晚我看着测试报告里那一排排绿色勾勾心里说不出的踏实。这套新系统的核心模块80%的测试用例都是我用AI生成的覆盖率达到90%以上比之前手写的时候还高出不少。我当时还跟同事开玩笑说这波是科技改变生产力。结果第二天上午十点线上第一个业务高峰直接把我从椅子上炸了起来——核心接口超时任务积压用户反馈接踵而至。后来复盘的时候技术负责人只说了一句话你们这测试测了个寂寞。这句话我记到现在。今天把整个经过、踩坑的原因、以及后来重新梳理出来的做法完整记录下来希望准备用AI写测试用例的朋友们少走点弯路。这里的坑不是AI不够强而是我们太相信AI生成的测试报告了。它确实能帮你写出大量看似规范的测试代码但能不能真正守住线上质量完全是另一回事。1. 从手工写用例到AI批量生成效率上头的那个阶段先交代一下背景。我们做的是一个偏业务中台的项目主要提供用户权益相关的查询和发放接口涉及积分、优惠券、任务奖励几个模块对账逻辑多状态流转复杂。接手这套系统测试的时候存量接口已经有六十多个之前的手工测试用例只覆盖了主流程边界和异常场景几乎是裸奔状态。我当时的计划是趁着版本迭代把所有核心接口的测试补全。但手写用例的速度实在太慢了一个接口的正常场景加异常场景写下来半天就没了。这个时候我看到团队里有人在用AI写单测就试了试——把接口文档、参数字段说明、返回结构喂给AI让它生成一套完整的接口测试用例。说实话第一步的效果是惊艳的。我给AI的提示词很简单角色设定成测试工程师要求覆盖正常、异常、边界三类情况输出JUnit风格的测试代码。一分钟左右几十个测试方法就出来了。它们看起来非常专业方法命名规范断言写得很具体连异常码的校验都有甚至还能生成一些我压根没想到的反例比如手机号格式、金额精度之类的。当时我的判断是AI的能力边界远超预期手工写用例的性价比已经完全比不上它了。于是我做了一个大胆的决定——所有新接口的测试用例全部由AI生成老接口的存量用例也分批交给AI重写统一补全延长。我甚至开始把生成的用例直接贴进CI流水线让它们成为合并代码的强制门槛。那两周的效率确实高得吓人光用例数量就从几百条涨到了两千多条覆盖率数据也一路攀升。部门内部汇报的时候我还专门拉了个对比图展示效率提升了将近四倍。现在回头看真正的问题不是效率而是我完全忽略了测试用例的质量和测试用例的数量根本不是一回事。覆盖率绿条拉满只是说明代码被执行到了并不说明执行的结果是被正确校验的——AI在这个环节挖的坑当时我完全没看出来。2. AI生成的测试为什么会失效三个最隐蔽的盲区这次事故之后我把AI生成的那些用例从头到尾翻了一遍专门做了个失败原因分类最后总结出AI生成测试用例最容易翻车的三个盲区。它们不是AI偶尔会犯的错而是其生成机制决定的、必然会出现的结构性问题。2.1 需求语义理解偏差AI在用自己的理解代替系统的真实约束第一个盲区是语义理解偏差。AI生成测试用例时依据的是接口文档和参数描述但接口文档是简化过的很多隐式的业务约束根本不会写进去。AI读到的只是文字层面的规则它无法真正理解这个系统在业务上的语义边界。举一个我们实际踩到的例子。积分发放接口文档上写的是支持批量发放单次上限1000条AI生成的测试用例确实覆盖了1001条这种超限场景断言会返回参数错误。逻辑上好像没错但它在另一个字段上翻车了——那是一个积分类型的枚举值文档里写的是A购物奖励B活动补偿C系统修正。AI基于枚举校验生成了测试但它不知道线上真实数据里有历史遗留的D值是早期版本对接外部系统时写进去的特殊类型。所以接口真正要守住的能力是兼容D值、但不允许新业务写D值AI生成的用例把D值直接当成非法输入断言接口应该拒绝。结果就是我拿着这套正确的用例跑回归老数据的兼容场景压根没被覆盖到。上线之后第一个调用老积分类型数据的请求就直接走了异常分支因为测试里根本没这个场景所有相关断言全是按AI理解的规则写的一旦遇到真实世界的脏数据整个链路就垮了。测试用例的本质是对需求约束的形式化表达。AI能读懂字段描述读不懂业务上下文这是大模型的先天限制。你拿一套不太准确的需求描述喂给它它只会产出更加自洽但不一定正确的断言集合——在错误的路上走得越远越坚定。2.2 Assertion样式同质化看似全面的断言实际全在测同一件事第二个问题更隐蔽我愿称之为断言同质化。AI生成测试用例的时候它的输出风格高度趋同——每个接口的用例都倾向于校验非空、类型正确、业务码为0、数据条数匹配。这套断言模板看起来无懈可击但实际测试的全部是接口有没有正常返回而不是接口返回的结果是不是正确的。说白了这就像你考试的时候每道题都写解题过程完整、答案格式正确但没有一道题真正去验证答案的数值对不对。AI没有能力为每一个业务场景设计独立的、差异化的断言逻辑它更倾向于给出一组通用安全检查点。这些检查点拼成一套漂亮的测试报告但内核是非常单薄的。举我们真实的例子。优惠券发放接口AI生成的断言是返回码为0、用户ID非空、优惠券数量正确。看着很全面吧但它漏掉了两个关键的差异点一是同一批券在不同用户之间不能重复发同一张券码二是并发条件下同一用户领取同一模板的券不能出现两张码相同的券。这两个业务断言是需要理解发放逻辑和唯一性约束的AI生成不出来因为它看到的只是接口文档层面的输入输出映射。结果上线之后并发压测一跑重复券码的问题立刻暴露如果那天高峰流量再大一点直接就是资损事故了。那之后我一直坚持一个做法AI生成的每个用例都要人工过一遍断言重点检查这个断言是不是在以不同的方式重复表达同一件事。如果一堆用例的断言本质上都是不等于空和等于成功码那它们就没有提供真正的保护只是数据上的虚胖。2.3 测试数据与运行环境的强耦合代码能用数据不存在第三个坑是我完全没有预料到的也是这次上线故障的直接导火索。AI生成的用例里测试数据往往是内置的固定值比如用户ID10086、手机号13800000000这种。我最初没太在意觉得这是AI图省事真跑起来的时候用测试环境的数据替换掉就行。但问题是AI不会帮你考虑测试环境的真实数据状态。它默认你有一个干净的、数据齐全的测试环境并且环境里还保留着一套它期望存在的种子数据。而我们的测试环境是长期复用的数据早就被前几轮测试改得乱七八糟外键关联、状态流转全都对不上了。这个问题的隐蔽之处在于用例在本地跑的时候是绿的在CI上跑的时候却经常闪红而且每次报错的地方都不固定。排查的时候你会误以为是环境问题然后清理数据、重启服务、重新跑一遍绿了就放过去了。但环境的偶发性成功会掩盖用例本身的脆弱性让你完全失去对测试结果的信任感。等你真的需要依赖这批用例去守住线上质量的时候它们反而在最关键的时刻给你放了一记烟雾弹。2.4 缺少平台视角单接口正确不代表链路正确最后补一条严格来说它不算AI的坑而是我在使用方式上的疏忽。AI生成用例时输入的是单个接口的文档所以产出的自然也是单接口层面的测试。但线上的故障从来不是单个接口的问题基本都是多个接口串起来的数据流转和状态协同问题。我生成测试用例那段时间大批量的工作都聚焦在每个接口本身返回是否正确对跨接口的场景几乎没有覆盖。比如先领券再使用的流程AI会分别生成领券接口的用例和使用接口的用例但它们断开了。领券接口返回成功后券的状态在数据库里是否立即可用使用接口读到的数据和领券接口写入的数据是否一致这些链路级的问题AI根本无法通过分析单个接口文档来作答。我当时天真地用覆盖率很高来安慰自己但覆盖率统计的是代码行不是业务链路。线上系统跑的是链路测试系统盯的是代码这中间的断层就是事故的温床。3. 上线当天的故障链路从报警到定位的完整复盘事故发生在上午十点零八分。监控告警弹出来的时候我第一反应是是不是数据库慢查询因为最近数据量涨得挺快。但紧接着第二个告警也弹了积分发放接口的异常率上升到了34%我意识到这不是性能问题是业务逻辑出问题了。我先查了日志。异常日志很明确积分类型校验失败。我当时的表情大概是很困惑的因为AI生成的测试用例里明确写了这个校验逻辑而且测试报告显示这个场景是通过的。既然测试通过怎么线上还会校验失败带着这个疑问我翻了CI上最后一次测试执行的记录。测试确实跑了也确实通过了但跑测试的时候喂给接口的积分类型只有A、B、C三种完全没有D值。而线上的真实请求里D值占了将近三成这些请求全部命中异常分支接口直接拒绝处理。最讽刺的是AI生成的用例里写了D值非法这个断言。也就是说AI不但没帮我们守住这个场景反而给这个错误行为上了保险——用例断言接口应该拒绝D值所以测试永远全绿线上该挂还是挂。我后来跟同事复盘的时候说这套用例就是我们亲手给Bug套上的合法外衣。紧接着我们又发现第二个问题。排查过程中我尝试手动调那个接口发现有些请求能成功有些请求处理得非常慢。定位到代码之后原因很清晰批量发放的数据里只要混入一笔脏数据整批就进入重试逻辑每一笔都重新走一遍完整的状态机。这个问题其实在测试环境里出现过类似苗头——CI上有过一次超时测试记录但我当时判断是环境抖动重跑了一回变绿就放过去了。第三个问题暴露在最关键的时刻。我们用脚本对线上数据做了一轮对账发现一批券码存在重复。这个问题的严重程度我到现在想起来还后背发凉如果用户集中使用资损是妥妥的。问题的根源在于并发场景下的唯一性约束测试完全缺失因为AI不会生成需要感知分布式锁和数据库唯一索引的测试用例。这些逻辑在单测里是被Mock掉的在接口测试里又是以串行方式跑的并发场景完全没暴露。从发现问题到临时止血我们花了大约四十分钟靠的是手写一个紧急脚本把积压的异常数据捞出来做清洗和修复。但问题最核心的部分——测试为什么没有拦住这些问题——我到当天晚上才真正想明白不是测试执行不到位而是测试设计和业务真相之间出现了巨大的偏差。AI生成的测试用例验证的是自己以为的需求不是线上真实的逻辑。那个晚上我写了一份事故总结开头第一句就是测试报告全绿恰恰是最大的风险信号——说明要么断言太弱要么用例根本没往真实场景上靠。从那以后我对任何全绿的结果都多问一句绿在哪个维度上是代码覆盖的绿还是业务保障的绿4. 事故之后的测试策略重构AI怎么用、人工盯什么血泪教训换来的经验不能只停留在再也不信AI这种情绪层面。事故处理完之后我做了一整套测试策略的调整核心思路是八个字AI提效人工守门。下面具体讲讲现在是怎么做的。4.1 AI负责生成骨架人负责把业务断言嵌进去我现在用AI生成测试用例的方式跟之前完全不同。我不会直接让它生成完整测试类而是让它先根据接口文档生成一个测试骨架方法名、参数构造、Mock策略、路径覆盖的框架。这些工作AI做得确实又快又好人类写起来太琐碎了。但生成完骨架之后有一个强制步骤逐个方法过业务断言。我会把接口的真实业务规则逐一映射到对应的测试方法上凡是AI生成的默认断言全部打上标记逐个确认这个断言是否有业务来源。如果找不到业务来源直接删除如果觉得有用但不是当前版本的需求就挪到待定列表不放进CI。举现在的例子积分发放接口的测试方法里AI生成的骨架中有一个积分类型为D时返回错误的断言。我拿到手之后的第一件事就是删掉它然后改成两条真实业务断言一条是D类型在查询场景下必须正常工作另一条是D类型在新增场景下必须被拒绝。这一字之差就是测AI以为的逻辑和测真实业务的区别。4.2 强制三类人工用例兜底链路、并发、数据兼容在AI生成骨架之外我规定每轮迭代必须有三个方向的人工用例补充AI生成的用例再多也不能替代它们。第一类是跨接口链路用例。单接口层面AI能生成得很全面但跨接口的流程必须靠人来设计。我们定期梳理核心业务链路把一路上的接口调用、数据流转、状态变化都串成完整的用例放到独立的测试套件里和单接口测试分开跑。这类用例不追求数量多但每一条都要模仿真实用户的操作路径。第二类是并发和幂等用例。AI生成的测试跑起来基本全是串行的但线上没有串行所有请求都是并发的。我们现在对每个核心写接口都设计并发场景的专项测试比如同用户重复领券、批量发放重叠批次、任务奖励重复入账这些问题只有并发跑才看得到。第三类是数据兼容用例。线上环境永远存在历史遗留的脏数据测试环境则永远是干净的。现在做测试之前我会先导出一批线上真实数据脱敏后灌入测试环境专门验证接口对历史异常数据的处理能力。这个方向AI完全不敏感因为它的认知来源永远是理想状态的文档。4.3 断言审查机制每次提测必须过一遍断言差异清单现在我要求每次提测之前测试负责人必须做一件事把AI生成的用例和人工补写的用例分开列出来专门审查AI部分的断言。重点是找出那些看起来在测异常、实际上在测试环境里永远触发不了的用例这类用例是最大的安全隐患。怎么识别它们核心判断标准是断言依赖的数据你是否能在测试环境和CI环境里稳定构造出来。如果不能这条用例看起来是绿的但实际上是白跑的因为它的断言对象根本没有出现断言本身就是通过了。再补充一种情况AI生成的用例非常喜欢Mock外部依赖比如缓存、消息队列、外部接口。Mock没有问题但Mock掉了的东西实际上是把你想要验证的逻辑跳过了。我们在审查的时候有一个动作把AI生成的Mock代码全部摊开逐个检查被Mock掉的依赖里有没有涉及核心业务规则的能力。一旦有这条用例就不能通过必须改成真实的依赖或者半托管的测试替身否则它验证的只是空转逻辑。现在我把这个审查动作做成了模板叫断言差异清单。一张表里列着用例编号、AI原始断言、业务真实约束、差异说明、处理动作。每一轮提测之前这张表必须在review记录里完整可查。工作量大吗确实比之前全自动跑一遍要大得多但上线不崩这件事比效率重要一百倍。4.4 CI里的分层守护快、准、稳三道门流程设计上我现在把测试跑成了三层。第一层是AI生成的骨架用例跑得最快放在提测阶段起到快速反馈的作用主要抓参数格式、正常路径、基础异常码。第二层是人工补写的业务断言和链路用例放在回归阶段跑得慢一点但必须有它们负责真正的业务保障。第三层是并发和兼容性场景放在灰度阶段这些用例可能需要专门的环境和数据准备耗时最长但上线前必须全部通过。这个分层设计的核心思想是不能让最便宜的测试决定最贵的风险。速度快、数量多的AI用例价值在于帮开发快速定位低级问题真正决定上不上线的永远是那些慢、贵、但深刻贴合业务的用例。这套理念我在事故之后跟开发团队对齐过多次现在大家形成了共识测试报告分两层看一层是用例执行结果一层是用例设计质量前者看红绿后者看业务逻辑覆盖。5. 给同样准备用AI写测试的同行几条身家性命的建议经验教训总结完了最后给同样准备在这一块发力的朋友一些直接的、来自一线的建议。这些不是我坐在电脑前想出来的是我在事故线上一点一点攒出来的。第一永远保留一个AI能力边界的心理预期。AI擅长的是把文档变成代码不擅长的是理解业务上下文、感知数据状态、预判线上环境。你用它提效没问题但别把它当专家。它在测试用例这个领域更像一个执行力超强但完全不了解业务背景的实习生产出必须人工深度review。第二不要把覆盖率当成质量指标。代码覆盖率是手段不是目的。90%的覆盖率配上同质化的断言给不了你任何安全感。真正值得盯的指标是核心业务规则的断言覆盖率具体来说就是把系统里最重要的业务规则列出来逐条确认有没有对应的测试断言而不是看代码行数跑了多少。第三测试用例也需要验收标准。AI生成的用例不是产出即合格。我现在会把可运行、断言有业务依据、依赖数据可稳定构造、CI环境可复现四条标准作为用例的准入条件任何一条不满足就退回修改。不要因为是AI生成的就降低对它的要求。说实话AI写出来的东西往往格式特别齐整反而更容易让人放松警惕。第四越是看起来聪明的用例越要警惕。AI有时候会生成一些花哨的边界测试比如毫秒级时间戳竞争、随机数种子判断之类的东西。这种用例看起来档次很高但实际价值往往很低甚至因为过于复杂而变成测试里的定时炸弹。我现在克制得很用例越简单、越直指业务越好。第五把AI生成用例的过程留痕。我们内部要求保存每一次生成用的提示词、输入的接口文档版本、输出的原始用例以及人工修改的记录。这不是为了追责而是为了复盘——一旦测试在某个场景上漏了可以追溯到底是AI没生成还是生成了但被人工删了还是根本没有进入CI。这种溯源能力在事故处理里极其重要没有它你只能对着测试报告猜。最后说说我现在的心态。我依然在用AI生成测试用例而且用得很频繁骨架、边界参数、Mock策略这些场景它做得比我手写快得多。但我对它的态度已经从信任变成了管理。它是一台需要你盯着仪表盘的引擎不是自动驾驶的方向盘。测试这个岗位的本质是守门人守门人手里的工具越来越强是好事但眼睛永远不能离开那扇门。如果这篇分享能让屏幕前的你少经历一次全绿上线然后崩掉的体验那这些字就没白写。测试行业正在被AI重塑但我越来越相信一件事AI最值钱的产出是让测试工程师从重复劳动里解脱出来把宝贵的时间花在真正决定系统生死的地方——理解业务、设计场景、守住那些文档里不会写的、但用户一定会遇到的边界。