AI生成测试用例的7个坑，第3个差点造成线上事故

覆盖率92%，11个测试全过——然后线上崩了

大家好，我是某互联网公司的测试架构师。

上个月，团队里一个测试同事用AI生成了一个用户认证模块的测试套件。跑了一下——11个测试全部通过，覆盖率92%。他在群里发了个截图，配文：“AI真香。”

两周后，线上出了一个Bug：用户用特殊字符组成的密码可以绕过验证。

回看测试代码，11个测试里没有一个测试过特殊字符输入。所有测试都在测“正常情况”和“AI能想到的异常”。真正的Bug藏在AI没想到的边界里。

这不是个例。今天我把过去一年踩过的坑全倒出来，第三个差点造成线上事故。

坑一：AI只测“它能想到的”

AI生成的测试有一种魔力：跑起来全绿，覆盖率报表漂亮，但线上该崩还是崩。

为什么？因为AI的测试覆盖了“它被训练见过的异常模式” 。训练数据里的代码示例，很少包含“密码前后有空格”“密码里有Unicode字符”“超长邮箱地址”这种真实世界的脏数据。

真实案例： AI给用户认证模块生成了11个测试，覆盖了正常注册、空邮箱、空密码。但没覆盖密码太短、密码太长、XSS注入、前后空格、Unicode字符、超长邮箱。上线后特殊字符绕过验证，直接出事故。

避坑方法： 每次AI写完测试后，手动补充一个“脏数据集”——空字符串、仅空格、超长字符串、SQL注入、XSS、Unicode特殊字符、零宽字符、前后空格、换行符注入。用@pytest.mark.parametrize跑一遍。

坑二：断言写得太“弱”，测了等于没测

AI生成的断言往往只校验返回值格式，不校验业务正确性。支付折扣、金额取整、幂等逻辑，AI容易写出“看起来能跑，但无法真实校验业务缺陷”的弱断言。

真实案例： 一个电商项目的UI自动化脚本，AI生成了3000行代码，覆盖了正向下单、支付、退款流程。但脚本只实现了点击操作，没有断言支付成功后订单状态变为待发货，也没有处理支付超时的异常场景。测试时没发现问题，上线后直接引发生产故障。

避坑方法： 审核AI生成的断言时，问自己一个问题：“这个断言如果被删掉，测试还能发现什么Bug？”如果答案是“什么都发现不了”，这个断言就是弱的。

坑三：高覆盖率幻觉——差点造成线上事故的那个坑

这是我最想讲的一个坑，也是差点让我们团队出事故的那个。

AI生成的单元测试，覆盖率可以做到95%以上，看起来“测得很全”。但覆盖率不等于缺陷检出率。

真实案例： 一个金融科技团队全面推行AI生成测试用例，半年后发现——在AI生成用例覆盖率达到95%后，线上缺陷的漏报率居然比纯手工测试时期还要高。

问题出在审核环节。测试工程师陈阳因为相信AI生成的“100%路径覆盖、0错误”报告，忽略了“输入字段为空+并发写入”这种AI逻辑无法覆盖的“荒谬组合”。最终导致生产环境崩溃。

还有一个案例更典型：三起生产事故均发生在CI/CD流水线通过“100%行覆盖+95%分支覆盖”门禁之后，但实际存在关键路径未被触发。AI生成的测试仅模拟HTTP 200响应，遗漏了超时熔断分支；生产中因网络抖动触发panic，导致订单重复提交。库存扣减的测试使用固定初始值stock=100，未覆盖stock=0边界场景，也未校验数据库事务回滚后的真实状态。

为什么覆盖率会骗人？ 因为AI会大量生成无意义、无校验的空用例、重复分支用例，单纯拉高行覆盖率数字，但无实际缺陷检测能力，造成覆盖率指标失真。

避坑方法： 用AST插桩强制执行所有if/else分支的panic路径，用运行时捕获状态变更序列对比测试前后的对象图差异。行覆盖率是参考，分支覆盖率和状态覆盖率才是真相。

坑四：边界条件“系统性缺失”

AI生成的用例高度集中在“黄金路径”——用户登录成功、订单创建成功、支付回调成功。但边界条件和异常路径严重缺失。

真实案例： 一个项目让AI生成了120条测试用例、3000行UI自动化脚本。上线后一小时，大量用户无法完成订单支付。排查发现：AI生成的用例漏了订单金额为0.01元的边界值、支付时网络中断重试这两个关键场景。

另一个典型：一个支付功能的需求文档15页，AI生成了300条用例。Review时发现——80%是“正常流程”的重复变体（“用户A支付成功”“用户B支付成功”），边界条件严重缺失（并发支付、网络中断、金额精度），还有大量用例依赖不存在的测试数据（“使用已过期的优惠券”，但系统根本没有优惠券功能）。

避坑方法： 不要让AI“批量生成”，让它“精准补全”。先用工具分析现有用例库，找出真正的覆盖盲区，再让AI针对盲区生成用例。

坑五：幻觉——AI“编”出根本不存在的接口和数据

AI在没有明确约束时，会生成“看起来合理”的内容，而非“实际有用”的用例。它会凭空编造接口、假设错误的数据结构、引用不存在的业务规则。

真实案例： 用AI生成50条测试用例，其中有8条需要修正。三种典型问题：AI“编”了一个不存在的接口（/api/v1/inventory/adjust）；隐性业务规则它不知道（“VIP用户不受库存上限限制”只存在于产品经理的脑子里）；返回结构假设错了（预期用error字段，实际返回的是message字段）。

避坑方法： 把隐性规则写进文档。哪怕只是一句“VIP用户不受库存上限限制”，写进去，AI就能覆盖到。AI的用例设计能力很强，但它强在“翻译”，不强在“补充”。

坑六：生成和质检混在一起，AI既当运动员又当裁判

这是最容易被忽略但影响最大的坑。

同一个AI模型，既生成代码，又生成测试。 模型基于对需求的某种理解生成代码，然后基于同样的理解生成测试。如果最初的假设是错的，代码和测试会共享同一个盲区。

真实案例： 一个函数错误地给每个求和结果加了1，但AI生成的测试套件却验证了这个错误行为——因为测试和代码来自同一个“大脑”，它只会验证自己认为对的东西。

避坑方法： 让不同的AI生成代码和测试，或者用独立的测试框架来评估AI生成的测试。AI不能给自己批改作业。

坑七：把“生成”当成“质检”，验证成本一分没降

这是所有坑的“根因”。

AI把“生成”的成本打到了接近零，但“验证”的成本，一分钱没降。以前一个开发一天写500行代码，他自己至少读过每一行。现在AI一天给他5000行，他还是一个人，还是那双眼睛。

真实数据： 拿一套电商项目的需求文档让AI批量生成用例，几分钟出了两三百条，格式工整、字段齐全。然后逐条质量评审——**261条用例里，能直接用的只有26.4%**，一半以上要人工改，还有两成干脆是错的。预期结果写着“页面展示正确”，提示信息是一对空引号，标题说测A功能、步骤里跑的却是B。

避坑方法： 产出进流程前，必须过一道质检。质检本身也要标准化——用维度、用指标、用checklist，别靠手感review。

最后

AI的错误和人的错误不是一个物种。 人会犯懒，会漏写边界，这些毛病测试摸得很熟。AI的错误是幻觉，是自信满满地编一个不存在的接口字段，是用一本正经的语气写错业务逻辑。人的错误会心虚，AI的错误永远理直气壮。

这七个坑，踩过三个以上的团队不在少数。但坑不可怕，可怕的是不知道自己在坑里。

AI把“生成”的成本打到了接近零，但“验证”的成本，一分钱没降。

你的不可替代性，不在你会用多少个AI工具，而在你能看出AI生成的东西哪里不对。

下次你用AI生成测试用例的时候，别只看覆盖率。问自己一句：

“这11个测试全过了，但线上会崩在哪里？”