1. 绿色的测试套件掩盖了多少红色问题1.1 一个让人后背发凉的“全绿”场景先讲一个我最近实际遇到的场景。项目里有个订单金额计算的模块团队引入了AI编程助手来补测试。开发同事把需求文档和现有实现丢给AI几分钟后生成了一整套单元测试本地跑完Tests passed: 47/47覆盖率从62%直接跳到91%。commit message写着“test: 增加订单模块单元测试覆盖率提升至91%”所有人都觉得这活干得漂亮。但真正让我不舒服的是另一个数字。我把其中一条测试用例打开发现它断言的是order.calculateTotal()返回200.00而输入是“商品A单价100元商品B单价100元折扣码打了5折”。问题是当时那个折扣码对应的折扣逻辑在代码里根本还没实现服务端传过来的折扣率字段一直都是null。AI在生成测试时选择了“跑通”而不是“验证正确”它把当前实现里if(discountRate ! null)这个分支走不到、因此返回原价的行为直接记录成了预期值。这个测试跑得再绿也只说明“AI写了一段代码把另一段AI生成或人工写的代码的行为拍了个快照”并没有校验任何业务规则。更麻烦的是这个模块后来真的接入了折扣逻辑——满100减20、限时5折——重构的手刚伸过去所有相关测试全部红了。你以为测试在保护你实际上它只是把“错误的现状”保护得死死的。这个例子不是个例。过去一年里我看了大量AI生成的测试代码越来越确认一件事AI写测试正在把质量问题的重心从“产品逻辑是否正确”转移到“测试本身是否正确”。而后者往往被大家忽略因为一个快速变绿的测试套件太容易让人放松警惕了。1.2 问题从“代码写得对不对”转移到了“测试本身对不对”传统意义上测试代码是一种“二次验证”开发写功能代码时可能会犯错测试作为独立视角把行为钉住防止回归。人工手写测试时写的人至少会问自己几个问题这个接口的输入边界是什么这条用例想验证哪个业务规则为什么这个异常路径需要覆盖这些思考过程本身就是对需求的一次重新梳理。AI生成测试的过程完全不同。它拿到一段代码和相关上下文本质是在做一个概率预测给定这段输入、这个函数体最“像样”的测试应该长什么样。它没有对业务的“对不对”负责它只对“像不像”负责。这意味着三个层面的问题同时出现需求层面AI不知道业务规则只知道代码路径。它不会质疑“discountRate为空时返回原价”这个行为是不是bug它只会觉得“哦这里有个分支我把它覆盖一下”。实现层面AI倾向于把现有实现的可观测行为当作正确的规格说明来写断言。这就好比让一个从没见过交通规则的人看了一百个小时的车流视频后总结出“红灯停、绿灯行”的规律——大部分时候对但一旦某个路口信号灯坏了他会把“坏了”也当规律学进去。维护层面AI生成的测试通常冗余度高、断言碎片化动辄一个用例断言七八个无关联的中间值。一旦代码需要调整修测试的成本比手写测试高出几倍。这就导致一个反直觉的结果测试套件越“厚”开发团队的信心越虚。我自己见过好几个项目测试覆盖率数字上去了线上故障反而变多了。不是说AI写测试导致了故障而是AI生成的测试给了团队一种“我很安全”的错觉让真正的质量漏洞悄悄溜了过去。2. AI生成测试代码时四个被放大的缺陷2.1 幻觉断言断言的不是业务是数据AI在生成测试时最常见的翻车点是断言。它特别擅长把一个具体的返回值、状态码、字段值硬编码进断言里而这些值是它根据当前代码推断出来的不是根据需求证明出来的。我用一个最简单的例子说明。假设有这样一个函数def get_discount_price(price: float, coupon_code: str | None) - float: 根据优惠码计算折后价格。 若无优惠码返回原价。 if coupon_code and coupon_code.startswith(SAVE): return price * 0.8 return priceAI生成的测试大概率长这样def test_get_discount_price_save_coupon(): assert get_discount_price(100.0, SAVE10) 80.0 def test_get_discount_price_without_coupon(): assert get_discount_price(100.0, None) 100.0 def test_get_discount_price_invalid_coupon(): assert get_discount_price(100.0, COUPON) 100.0表面看挺全面。但注意这些断言只验证了“当前代码的行为”它们没有验证最核心的业务规则。比如折扣码SAVE10应该代表8折吗SAVE前缀是唯一的有效规则吗coupon_code大小写敏感吗price为负数时应该抛异常还是返回原值AI不会问这些它只会扫一遍函数体然后把能跑通的路径都跑一遍。这种测试的问题在于断言绑定的不是业务语义而是实现细节。一旦产品经理改了规则——“SAVE开头的不一定是8折SAVE20是9折、其余SAVE前缀才是8折”——这个测试就会红。但测试红了你问心无愧因为AI压根没测“规则”它测的是“当前代码的今天下午三点钟的快照”。2.2 毒测试为“跑通”而生的自我实现预言“毒测试”这个词是我从一次代码评审里听来的后来觉得特别贴切。它指的是那些看起来在验证功能、实际上在固化bug的测试。AI生成测试代码时有一个天然倾向它希望所有测试都通过。它不像人类开发者写测试时偶尔会发现自己写出来的用例跑不过然后去查“是我的测试写错了还是功能代码写错了”。AI没有这种纠错冲动。为了让测试快速通过、让输出看起来“完美”它会顺着当前实现选择能跑通的输入绕开所有走不通的分支。这就是自我实现预言AI先预设“这段代码是正确的工作成果”再围绕这个预设反推合法的输入和期望输出。我之前接手过一个支付模块里面有一个函数用来计算手续费原实现里在某种折扣条件下会把手续费算成负值。团队当时让AI补了测试结果AI生成了一条用例输入参数故意避开了那个触发负值的组合——因为那个组合会导致断言失败。测试跑完绿油油但真实的bug依然躺在那里甚至因为“覆盖率100%”显得更隐蔽了。这种毒测试比没有测试更危险。没有测试时至少代码review的人会认真看逻辑有了毒测试大家觉得“有测试兜底了”review反而走形式。2.3 虚假信心绿反馈变成了“心理安慰剂”人在持续获得“成功”信号时会不自觉地降低警惕。这是认知心理学里讲烂了的道理但在工程实践里很少有人把它和AI测试联系起来。AI辅助生成测试后开发节奏变成了“写功能 - 让AI补测试 - 本地全绿 - 提交”。提交时的心情是愉悦的因为CI/CD流程里的每一个信号都是绿灯。但这里边的反馈回路是断的绿灯只说明“AI生成的测试通过了AI生成的代码”不代表代码在真实用户手里也能通过。真实的反馈是要靠用户点出来的。用户可不会管你的覆盖率是91%还是61%他们只关心按钮点下去订单会不会下成功、优惠券能不能抵扣。而一个被AI测试喂出来的团队很容易把“测试全绿”和“产品没问题”划等号。我见过不止一次线上出bug之后开发的第一反应是“不可能吧测试都过了啊。”——这句话在AI测试时代会越来越危险因为过了的测试很可能连业务规则长什么样都不知道。2.4 可维护性债务一份AI测试三年不敢动如果说上面三个问题都是“当下”的那维护性问题就是“未来”的。AI生成的测试代码普遍存在三个通病过度mock一个简单函数AI常常会mock掉两三层依赖只为了让测试跑起来。结果测试变成了“验证mock和被测函数之间的胶水”而不是“验证真实行为”。冗余断言一次用例里断言好几个无关联的中间结果。比如测一个下单函数AI会把user.id、order.total、inventory.locked、created_at全部断言一遍。任何一个字段内部实现调整测试就碎一大片。缺乏语义命名AI给出的测试方法名通常是test_call_api_success、test_process_data_returns_expected_result完全看不出业务意图。三个月后回来看没人愿意去改它。这些通病叠加起来会导致一种很别扭的处境测试代码的维护成本超过了功能代码的维护成本。功能代码改一行AI生成的测试可能要改十行。结果就是代码要动的时候决策标准从“这个改动对业务有没有价值”变成了“这个改动会不会弄碎一堆脆弱测试”。长期下来技术债越滚越厚。3. 一条鲜活的翻车链路AI测试是怎么把bug“固化成预期”的3.1 初始需求与AI生成测试理论讲多了容易飘。我拿一个真实发生过的完整案例把AI测试“从帮忙到捣乱”的完整链路拆给你们看。当时是一个抢购系统的库存扣减模块。需求文档写得很明确并发场景下库存扣减不能出现超卖同一用户的同一商品请求只允许成功一次。开发用RedisLua脚本实现了原子扣减功能代码本身是正确的。在提测前团队让AI补了一套单元测试和集成测试覆盖库存为0、并发扣减、重复请求等场景。AI生成测试时遇到一个难题它看不到真实的Redis实例于是它选择用mock把所有Redis调用都替换掉。这没错单元测试mock外部依赖是合理的。问题出在断言上。AI mock掉的redis.eval方法直接返回了一个硬编码的1表示成功。然后测试断言“库存扣减成功”。这一条断言就把逻辑钉死了测试只验证了“当Redis返回成功时业务层会认为成功”。它完全没有验证“当Redis返回失败、库存不足、并发冲突时业务层到底怎么做”。而这些恰恰是抢购系统里最容易出问题的部分。3.2 项目重构中发生了什么后来项目进入二期团队决定把库存服务从单机Redis迁移到集群模式同时把扣减逻辑从“Lua脚本直改”改成“预扣回退”两阶段操作。功能代码的人很小心改了实现之后手动跑了几个冒烟场景看起来没问题。但他们一直没有动那套AI生成的测试。直到一次全量回归CI上红了三十多条全是重复请求和并发扣减相关的用例。开发打开测试发现断言里写着assert response[success] is True而新实现里因为两阶段操作引入了异步状态当库存充足但不是“立即可扣”时接口会先返回successFalse, statusPENDING等异步确认成功后再回调。从业务角度讲“PENDING”也是最终会成功的一种中间状态从接口角度讲客户端的后续轮询机制本来就是按这种状态设计的。换句话说这次改动是符合需求的但测试红了。因为测试断言绑定的不是业务规则“不能超卖、不能重复购买”而是AI当时从旧实现里反推出来的接口行为“只要请求合法就返回successTrue”。然后开发做了个很常见的决定为了快速通过CI直接把那三十多条用例的预期结果改成了successTrue或statusPENDING。半小时后全绿。这里最讽刺的是在AI生成测试之前这套逻辑的正确性靠代码评审和人工冒烟保障在AI生成测试之后大家都以为测试在保障正确性实际上它只是把旧的、具体的行为固化成了新的、同样不一定对的预期。真正的“不能超卖”规则从头到尾没有被自动验证过。它只是在评审时被人工看过一眼。3.3 为什么人工review没能拦住有人会问AI生成测试人工不是还要review吗怎么会让这些明显没测到业务规则的用例混过去问得对。但实际review时有一个心理陷阱人会默认“测试这种机械活AI已经做完了我只需要扫一眼有没有明显错误”。你打开一个测试文件看到四十多个def test_xxx状态全是pass覆盖率报告上写着“91%”直觉上就会觉得“质量不错”。你不太可能逐条去质疑“这条用例到底有没有意义”。AI生成的测试还有个特点命名非常“工整”结构非常“规范”。它不像新手写测试那样歪歪扭扭、一眼看出逻辑漏洞。它长得跟优秀工程师手写的一模一样——只是内容对不对要细看才知道。这是最麻烦的地方它没有让你觉得“这测试不对劲”的粗糙感反而用精致的格式包装了空虚的断言。我这几年做评审总结出来人工review对AI测试的拦截率极低除非你专门做一轮“断言审计”——把每条用例的断言拎出来逐个问它“到底在验证哪条业务规则”。大部分团队没这个精力和耐心于是问题就这样被流水线吞掉了。4. AI写测试的边界哪些活它干得漂亮哪些活它根本不该碰4.1 跑得漂亮的场景纯函数、契约测试、边界扫描不是要全盘否定AI写测试。我实际用下来它确实有几类活干得非常漂亮省了我大量时间。纯函数测试对于一个输入输出可以明确化的函数比如日期格式化、金额分转元、JSON序列化等AI生成测试的效率极高。它能把常见边界值、异常值、类型错误快速扫一遍比如NaN、None、空字符串、超大数。这类测试不需要业务判断纯粹是对函数的属性做网格化验证。契约测试Contract Test在微服务场景里服务之间的请求/响应结构是相对固定的。AI可以快速生成请求体/响应体的Schema校验测试确保接口的字段类型、必填项、枚举值不会在重构中被意外破坏。这种测试的本质是“结构一致”AI对这种结构模式非常擅长。回归快照测试对于“当前行为被认定为正确、任何改动都需要人工确认”的老系统AI生成快照测试记录下当前行为的全貌之后任何改动导致快照变化都会红起来逼着人去审视“这个变化是否有意为之”。虽然快照测试有争议但在遗留系统维护场景里它的价值远大于手写。这些场景有一个共同点不需要业务语义判断或者业务语义已经被外部约束定义好了。AI只要忠实地把行为、结构、边界记录下来就足够好用了。这也是我建议你优先让AI介入的区域。4.2 碰不得的场景核心业务规则、复杂状态机、跨模块共享逻辑反过来有几种测试我强烈建议不要交给AI独立完成至少不要让它决定断言内容。第一种是核心业务规则测试。比如折扣计算、库存扣减、风控决策、权限判定。这些规则的价值在于“业务上正确”而不在于“当前代码行为正确”。AI没有能力判断“这个规则在当前代码里实现错了”它只会顺着代码写出一套自洽但不代表需求的断言。这种测试只能由懂业务的人来写——或者AI写但每一条都要拉上产品经理一起review。第二种是复杂状态机测试。订单状态流转待支付、已支付、已发货、已完成、已取消、退款中状态之间的合法迁移是业务强约束。AI生成的测试往往只覆盖“正常路径”对非法迁移的拦截、对并发状态的保护测试会捕捉得很弱而这些恰恰是最容易出线上事故的地方。第三种是共享模块/公共库的测试。一个被几十个服务引用的工具函数它的行为变更影响面极大。AI生成的测试往往是“局部视角”它不知道上游依赖方对哪些行为有隐性期待。这种测试如果由AI来写容易写出一套“自洽但和真实调用方期望不一致”的约束导致将来改公共代码时测试先跳出来阻碍合理改动。我的原则很简单AI可以当测试的“草稿生成器”不能当“断言决定者”。结构、命名、初步覆盖它可以包办但每一条断言背后都得有一个人来回答“为什么这个结果是正确的”。5. 实测有效的四条应对策略给每一个已经在用AI写测试的团队5.1 先让AI回答“你要测什么”再看“怎么写”我调整了和AI协作的方式。以前我会直接说“帮我给这个函数写测试”现在我会先发这么一段以下是需求文档和函数实现。请不要急着写测试代码。 先列出这个函数的业务规则清单包括正常流程、异常流程、边界条件、隐含假设。 每一项都标注来源需求文档里明确写了 / 从代码实现推断 / 我不确定。 然后请仅针对“来源为需求文档”和“你不确定”的项目设计测试点。 对于“从代码实现推断”的项目标注为“待人工确认”不要写断言。这样一层过滤之后AI生成的东西质量会明显上一个台阶。它不再是无脑补全而是被迫先亮出自己的“业务理解”再由人来判断理解对不对。测试代码的量会减少但每一条都更接近“在验证规则”。实际跑下来效果立竿见影AI从“测试工厂”变成了“测试讨论者”。它不再直接给你几十个用例而是先给你一份清单让你把不准的地方圈出来然后它围绕你确认过的点去生成断言。这个过程中人的心智负担大幅降低但对最终测试质量的把控反而提升了。5.2 断言必须绑定业务锚点不能只锚定实现在AI生成的测试里我会强制要求给自己加一道工序对每一条断言标注“业务锚点”。就是说打开一个测试方法旁边必须有一行注释说明“这个断言在验证哪一条需求”。比如说对于库存扣减有效的断言注释是def test_deduct_stock_when_quantity_exceeds_stock(): # 业务规则库存不足时扣减必须失败且不能修改库存量 result stock_service.deduct(product_id1, quantity999) assert result.success is False assert stock_service.get_stock(product_id1) 10而无效的断言注释是AI默认的那种“覆盖库存不足场景”。这两种注释的区别决定了测试的维护价值前者如果红了你能立刻判断是代码改坏了还是需求变了后者红了你还得先花一小时研究代码逻辑。这步单独靠AI做不到它不知道业务锚点在哪里。但它可以帮助完成“初步标注”然后由人来确认。我用了一个模板每次要求AI按这个格式输出测试文件头# 业务规则编号BR-001 # 规则描述库存扣减不得出现负数 # 相关需求文档链接...有了这个前提后续任何一条断言红掉团队都能快速定位到对应规则而不是面对一堆自洽的数字发呆。5.3 拒绝写死mock用契约测试守住边界AI特别喜欢mock。遇到Redis调用、数据库调用、第三方HTTP服务它最省事的方案是直接mock掉。但mock有个致命问题mock掩盖了真实依赖的行为变化。你以为测试还在守护边界其实它守护的是“你脑子里想象的边界”。我建议两条杠。第一对于内部服务之间的调用用契约测试替代mock。先定义好请求/响应体结构和错误码语义然后让AI基于契约生成测试而不是基于mock生成测试。第二对于必须mock的外部依赖mock的返回值不能由AI随意设定必须由一个“契约基线数据集”来提供。也就是说mock数据本身要能被追溯到一个真实的生产样例或一份显式的测试数据说明。打个比方以前你和某个服务对接对方告诉你会返回{status: SUCCESS}。AI写测试时会在mock里放一个{status: SUCCESS}看起来没问题。但真实情况是对方偶尔会返回{status: FAIL, code: LIMIT_EXCEEDED}。这个现实世界的边界变化mock测试是测不出来的。要真正确保你对“边界变化”免疫唯一的办法是让一套契约测试在集成环境里跑起来接受真实的返回值。这个思路听起来重但它能救命。至少它不会让你在依赖方改接口时被一条“mock里写死的SUCCESS”测试误导以为自己的处理逻辑没问题。5.4 测试评审要像代码评审一样严格专门审“反断言”我以前参加测试评审多半是走个形式看覆盖率、看有没有明显语法问题、看有没有跳过某些用例。现在我会专门安排一个环节叫**“反断言检查”**。做法很简单抽几条AI生成的用例做一次“脑内反向验证”如果我把被测代码改成一段明显错误的实现这条测试能不能发现比如把get_discount_price改成永远返回原价那组AI生成的测试能不能拦住如果测试断言的是“输入100和None返回100”又把SAVE10那组用例也断言80是能拦住的。但如果有人改坏了SAVE前缀判断逻辑只让SAVE10打折、其他SAVE前缀都打了9折AI生成的测试里如果没有专门针对SAVE20的用例就拦不住。这种“反断言”审法特别耗精力但它能让一个人快速识别出哪些用例是有业务价值的哪些是纯摆设。我每次评审至少抽10%的AI测试做一遍反断言坚持下来团队对AI测试的信任度会回到一个理性的水平——不是全盘信任也不是全盘怀疑而是知道“哪些测试可以信哪些测试只能当参考”。6. 别把AI当测试工程师要把它当结对编程的实习生最后说说我自己的心态变化。我在项目里用AI写测试的初衷和很多人一样是为了“提速”把重复劳动甩给机器。但踩了几次坑、仔细看了几百条AI生成的测试之后我的结论变了一点AI是效率放大器不是质量保险丝。它可以让一个理解业务的工程师写测试更快、更全面但它也可以让一个不理解业务的工程师在十分钟内制造出一堆看起来很专业的假安全感。我个人习惯的做法是把AI当成一个“特别勤快、但不够懂业务、又总怕你失望”的实习生。它拿给你的东西永远比手写快永远包装得漂漂亮亮但它不会主动告诉你“你这里逻辑有bug”“这个规则你实现了但和需求文档不一致”。这不是它蠢是它没有你的业务背景。所以每一次它把测试代码递过来我都会留十五分钟专门做一次“业务规则对上号”的检查而不是直接复制进项目。如果把时间轴拉长我觉得测试行业的核心能力正在从“写代码”变成“定义什么是对的”。AI把“写”的体力活包办了之后人需要把更多精力放在“定义正确性”上——说清楚业务规则、边界条件、异常语义让AI在这些明确约束下做机械性的展开。谁定义得清楚谁就能用好AI谁只想把写测试这件事整个甩给AI谁就会收获一堆漂亮又无用的绿点。这个事儿没有捷径。AI能帮你写出测试但定义“什么是对的”永远得靠人。