那个会自己写测试用例的AI，今天把我逼到了墙角

今天下午的用例评审会上，我站在投影仪前，一句话都说不出来。

屏幕上左边是我的Excel，右边是新来的那个AI工具生成的测试用例。我们比的是同一个模块：购物车的优惠券叠加功能。

我的用例：17条。 AI的用例：43条。

我的用例覆盖：正常场景+几个边界值。 AI的用例覆盖：正常场景、边界值、异常流、组合场景、性能考虑、甚至还有两条安全相关的。

我的用例耗时：一上午。 AI的用例耗时：43秒。

产品经理扭头看我，眼神里写着一句话：你这一上午在干嘛？

我张了张嘴，想说“我思考了”，想说“我结合了业务理解”，想说“我考虑了历史缺陷”——但看着那43条用例，我突然觉得这些话都很虚。

那一刻，我感觉自己被逼到了墙角。

一、事情要从一周前说起

上周五，我们组来了个“新同事”——一个AI测试助手。领导在群里发了个通知，说这是公司采购的，让大家试用，还说“希望能提升测试效率”。

我当时没太当回事。AI写代码我见过，Copilot确实挺厉害，但写测试用例？那种需要理解业务、需要结合系统现状、需要判断优先级的事情，AI能干？

我干了八年测试，从功能到自动化到测开，自认为对“怎么写好用例”这事还是有发言权的。一个刚来的AI，能比我强？

但今天这个评审会，把我打醒了。

二、我和AI的“对决”

回到今天的评审会。我们测的是一个促销活动：满减+优惠券+会员折扣可以叠加，但有互斥规则。

我提前一天开始准备。翻需求文档，看交互稿，查历史缺陷，画脑图，写Excel。一上午的时间，我列出了17条用例，覆盖了：

• 满减正常生效
• 优惠券正常使用
• 会员折扣计算
• 三者叠加的场景
• 金额边界值（比如刚好满减门槛、差1分不够门槛）

我觉得挺全了。还给用例分了优先级，P0、P1、P2标得清清楚楚。

今天下午评审会，我刚讲完我的17条，旁边的实习生小陈说：“我也用那个AI跑了一下，生成了一份，要不对比看看？”

我说行啊，放出来看看。

然后43条用例，一页一页翻过去。我的脸色，一页一页变白。

我的用例里有一条：“满减和优惠券同时使用，计算是否正确。”AI的用例把这条拆成了四条：

• 满减金额大于优惠券，优先用哪个
• 优惠券金额大于满减，优先用哪个
• 两者互斥时，系统是否提示
• 两者互斥时，用户选择了其中一个，另一个是否自动置灰

我的用例里有一条：“会员折扣计算正确。”AI的用例补充了：

• 会员折扣与满减叠加时，是先减后折还是先折后减
• 会员折扣与优惠券叠加时，是否受优惠券使用门槛影响
• 不同会员等级折扣不同，切换会员等级后重新计算

我的用例里完全没有的：

• 并发场景：同一时间多个请求，优惠券库存扣减是否正确
• 数据一致性：下单失败后，优惠券是否返还
• 安全场景：绕过前端限制，直接调接口能否重复使用同一张券
• 兼容性：不同端（APP、小程序、H5）优惠计算是否一致

43条用例看完，会议室安静了五秒。

产品经理打破沉默：“那个……AI这个，能直接导入我们用例库吗？”

实习生说能。

产品经理看我一眼，没说话。

但那个眼神我读懂了。

三、会后，我坐下来认真研究了这个AI

散会后我没走，拉上实习生，让他教我这是怎么用的。

其实不复杂。他把需求文档的PDF喂给AI，然后问了几个问题：

1. “根据这个需求，列出所有可能的测试场景，按功能、异常、边界、性能、安全分类”
2. “针对优惠券叠加规则，生成具体的测试用例，包含前置条件、步骤、预期结果”
3. “这个功能可能会有哪些坑？历史版本出过哪些问题？”
4. “哪些场景优先级最高？”

AI就一条一条往外吐。

我问实习生：“你调的？”

他说不是，就原样问的。还说：“哥，其实它还能干更多。比如把接口文档扔进去，它能直接生成接口测试脚本；把历史缺陷扔进去，它能分析哪个模块最容易出bug。”

我沉默了。

四、AI到底是怎么做到的？

回家路上我一直在想：AI凭什么能写出比我全的用例？

我不是不懂业务。购物车这个模块我测过三次，每次迭代我都参与。历史缺陷我也知道，优惠券库存扣减出过事，并发场景确实容易漏。

但AI比我强在哪？我琢磨了一路，大概想明白了：

第一，它没有“思维定势”。

我写用例的时候，习惯顺着业务流程走：加购→选券→下单→支付。这是一条“快乐路径”。但AI没有这种路径依赖，它会把每个环节拆开，单独去想“这个环节可能会出什么问题”。

第二，它记得住所有“套路”。

八年的经验告诉我，测试用例有几类：正常、异常、边界、性能、安全、兼容、数据一致性……但我写的时候，不会每类都过一遍，太费时间。AI没有这个问题，它像一张检查清单，每个维度都过一遍，漏掉的概率就低。

第三，它没有“我觉得”。

我有时候会想：“这个场景不太可能发生吧，用户不会这么操作。”然后就不写了。但AI不管可不可能，只要逻辑上存在，它就列出来。事实证明，用户的操作永远超出你的想象，“不可能”的场景往往最容易出bug。

五、但我也发现了AI的“蠢”

冷静下来之后，我又仔细看了那43条用例，发现了几个问题：

问题一：有些用例跑不通

有一条是“用户未登录状态下使用优惠券”。AI可能不知道，未登录状态下根本进不到购物车页面，直接跳登录了。这条用例在真实系统里不存在。

问题二：优先级不分

AI把所有用例都列出来，但没告诉我哪些要先测。43条用例，如果全跑一遍，两天时间就没了。但版本这周五就要上线，我只有半天时间测购物车。

问题三：重复的不少

有好几条用例其实测的是同一个逻辑，只是数据不同。比如“优惠券金额100”和“优惠券金额200”，本质上是一回事，不需要拆成两条。

问题四：不懂“历史坑”

我知道这个模块的并发之前出过事，所以并发场景我会重点测。但AI不知道这段历史，它把并发和普通异常放在同一个优先级，差点被我忽略。

六、所以，我和AI谁赢了？

写到这，你可能以为我要说“AI赢了，我被取代了”。

其实不是。

今天晚上的复盘，我在笔记本上写了一句话：AI让我看到了我的盲区，但我也看到了AI的盲区。

AI的盲区是什么？

• 它不懂“这不可能”。有些场景逻辑上成立，但系统设计决定了它永远不会发生。这种判断需要经验。
• 它不懂“这个更重要”。43条用例，哪个必须先测？哪个可以延后？哪个风险最高？这需要结合版本节奏、开发质量、用户影响来判断。
• 它不懂“历史教训”。去年那次线上故障，是因为什么？那个坑以后怎么避免？这些不在文档里，在人的记忆里。

所以，谁赢了？

我觉得没输赢。或者说，我和AI加在一起，赢过了昨天的我。

明天我会这么做：让AI先跑一遍，给我初稿。然后我过一遍，删掉那些“不可能”的，合并那些重复的，把那些“历史坑”相关的打上高亮。最后，我根据版本节奏，排好优先级，开始测试。

43条变成25条，但每条都是精的。

七、写给和我一样的测试人

如果你也干了五六年测试，可能和我一样，心里有点不舒服——AI怎么就比我强了？

我想了一天，想明白一件事：不是AI变强了，是我变懒了。

八年经验，本应该让我更懂怎么设计用例、怎么判断优先级、怎么结合系统现状。但我不知不觉把这八年过成了一年——重复第一年的方法，只是越来越熟练，没有越来越深入。

AI没有经验，所以它只能按套路出牌。但也正因为没有经验，它不会“我觉得这个不重要”。

那我们的优势是什么？

是判断力。是取舍。是知道什么该测、什么可以放、什么必须深挖。

这些，AI暂时还做不到。

写在最后：那个被逼到墙角的下午

今天下班，我又在工位上坐了一会儿。看着那个AI工具生成的43条用例，想起下午会议室里的尴尬。

有点难受，但更多的是清醒。

我把那43条用例打印出来，贴在本子上，旁边写了一行字：

“你看，这里还有这么多你没想过的地方。”

明天开始，我得重新学一遍——怎么设计用例、怎么思考测试、怎么结合经验和工具。

那个会自己写测试用例的AI，今天把我逼到了墙角。

但被逼到墙角之后，要么蹲下，要么翻过去。

我选后者。