AI测试工具的测试覆盖率从45%到92%，故障率反而涨了15%

共鸣

周三下午两点，测试架构师老张盯着屏幕上的代码审查请求，手指悬在鼠标上迟迟没点下去。

他刚刚用AI工具花了半小时生成了新模块的全部测试用例，结果AI吐出了整整1.2万行YAML格式的配置文件。密密麻麻的字段像瀑布一样滚过屏幕，他揉了揉发酸的眼睛，心想：这要是逐行审查一遍，今天别想下班了。

更讽刺的是，他隐约记得上个月刚清理过一批类似的AI生成用例——那些冗余的边界条件从没触发过任何bug。办公室里空调嗡嗡作响，窗外知了的叫声一阵阵传来，老张的咖啡早凉透了。他盯着屏幕上那行绿色的"生成完成"，突然觉得这四个字有点刺眼。

隔壁工位的小李探过头来："张哥，这批用例跑过了吗？"

"跑是跑过了。"老张叹了口气，"但我压根没细看。"

小李愣了一下："那……就直接合了？"

老张没说话。他心里清楚，这1.2万行配置里，相当一部分是重复的边界枚举，还有大量用例压根覆盖不到实际业务场景。但他实在没精力一行行去抠——Testim2024年的研究报告显示，AI辅助测试工具能将测试用例生成时间从1-2天缩短到20-30分钟，这效率听着让人心动，可没人告诉过他，省下的时间都去哪了。

你省下的编写时间，全花在了审查AI留下的迷宫里。

焦虑

老张的困境不是个例。

我前阵子帮某中型互联网公司2024年Q2做测试诊断，他们的自动化覆盖率从45%飙升到92%，按理说该庆祝，但生产环境的故障率反而上升了15%。测试总监百思不得其解，拉着我开会分析。

"老贺，你帮我看看，这到底怎么回事？"他指着屏幕上的数据，"用例多了，覆盖率上去了，怎么bug反而抓不住？"

我翻了翻他们的测试仓库，发现问题出在那些AI生成的用例上——大量边界条件测试用例覆盖的是根本不会发生的场景。比如一个支付接口，AI生成了几十个测试"负数金额""零元支付""超大金额"的用例，看起来很严谨，但实际业务逻辑在金额进入系统之前就已经做了拦截。这些用例在技术上是"正确"的，但对系统质量没有任何贡献，反而制造了大量假阳性告警。

测试团队每次看到告警通知，第一反应是"又是AI生成的那些用例"，慢慢就养成了忽略的习惯。当假阳性告警堆积到一定程度，团队会产生告警疲劳——真正的问题，就藏在这些被忽略的告警里。错过一个真实告警，就可能错过一次发现熵债的机会。

老张听完这个故事，沉默了很久。

"所以问题不在AI？"他问。

"问题在于AI放大了你们的决策惯性。"我说，"AI写的测试，最危险的错误不是代码错误，而是让人误以为它没问题。"

当团队默认接受AI的输出，审查环节就变成了走过场。认知税就这样悄悄转移了——从"写"转移到了"审"，而"审"的成本比"写"高得多。因为审查一个已生成的用例，需要你理解它的业务意图、技术逻辑、边界合理性，这比从头写一个用例的认知消耗更大。

老张揉了揉太阳穴："那我这1.2万行……"

"你现在面临的不是审查问题，是决策瘫痪。"我打断他，"AI给了你太多选择，而你没有足够的信息去判断哪些值得保留。"

认知翻转

老张的问题，让我想起去年参加CT-GenAI大纲讨论时的一个争论。

当时大纲里有个学习目标GenAI-2.2.1，要求考生理解如何使用提示词进行测试分析。有专家觉得K2级别就够了——理解概念就行。但我坚持在实践环节加入动手实验，把级别提到K3。

理由很实际：如果测试工程师只会背定义，面对真实的DeepSeek或通义千问时，根本不知道怎么设计一个有效的提示词进行测试分析。

争论持续了整整一个下午。会议室的白板上画满了流程图，有人站起来比划，有人摇头叹气。最后我们达成共识：在实践目标H2级别补充了通过练习提示链与人工核验的方法，循序渐进地分析给定用户故事，并对验收标准进行细化。

后来，参加过这个培训认证的人反馈说，正是那堂实验课让他们真正理解了"测试AI"和"被AI测试"的区别。

我把这个故事讲给老张听。

"你的问题不是AI生成得太多，而是你把AI当成了替代品，而不是工具。"

老张皱起眉头："什么意思？"

"你用AI生成用例，然后逐行审查——这是把AI当成了需要你校验的初级工程师。但AI不是人，它不会因为你的审查而学习，只会因为你的提示而改变输出。"

窗外的天色暗了下来，办公室里的人走得差不多了。老张盯着屏幕上那1.2万行配置，突然问了一句："那我现在该怎么办？"

AI不会自动优化系统，它只负责把隐藏的复杂性账单摆到桌面上。

真正的降熵需要人类做出艰难取舍，而省略这一步的AI应用只会产出更大规模的合理废墟。

行动

老张决定换个方式。

他没有一头扎进那1.2万行配置里逐行审查，而是先做了件事：把AI生成的用例按业务模块分类，然后拉上产品经理和开发负责人开了一个小时的会。

"这几个模块的边界条件，哪些是真实场景？哪些是理论上的极端情况？"

产品经理看着投影上的分类，指着其中一叠说："这几个场景用户根本不会碰到，我们可以不做。"

开发负责人补充道："这几个接口有前置校验，这些用例可以删掉。"

一个小时后，那1.2万行配置被砍到了4000行。老张没有逐行审查，而是把精力集中在真正需要判断的部分。

"AI产量越大，人类审查成本越高，可能导致默认接受，从而固化而非消除冗余。"我在电话里跟老张说，"你现在做的，是在AI输出和最终决策之间加了一层过滤。"

老张的声音听起来轻松了不少："说实话，我之前一直觉得AI是用来省时间的，没想到真正省时间的，是把AI的输出当素材，而不是成品。"

我笑了。这让我想起有一次帮一家传统制造企业做TMMi评估，他们想评估是否达到了Level 2。评估时我发现一个有意思的现象：他们其实有测试流程文档，而且写得很规范——但没人看。为什么？因为文档是质量管理部写的，测试团队觉得那是"给审核看的"，不是"给我们用的"。

后来我建议他们做一件事：让测试团队自己重新写一遍测试方针。不是改，是重新写。结果写出来的内容和原来几乎一样，但态度完全不同——因为是"我们写的"。

老张现在做的，本质上是一样的：不是被动接受AI的输出，而是主动决定哪些输出值得保留。

思考

两个月后，老张给我发了条消息。

"老贺，我们团队现在的规则是：AI生成的用例，必须先过一轮业务过滤，再进入技术审查。上个月生产环境的故障率降了20%，而我们的用例总量反而少了。"

我回了一句："恭喜。"

他发来一个笑脸，然后说："其实想想挺讽刺的。AI明明是效率工具，结果真正提高效率的，是学会了拒绝AI。"

我仿佛能看到手机另一端的他——靠在椅背上，窗外是城市黄昏的车灯河流。故障率降了20%意味着那层过滤真的生效了，不是AI变强了，而是他们团队学会了在AI的输出和真正需求之间画一条线。

"你知道吗，我现在每次让AI生成用例，都会先问自己三个问题。"老张的消息又跳出来，"这个场景用户真的会遇到吗？这个测试失败了我们真的有能力修吗？通过了它，我们对系统的理解有增加吗？如果三个问题都答不上来，那就删掉。"

我想起他之前问我的那句"那我现在该怎么办"。当时他盯着屏幕，眼神里满是焦虑。现在他学会了在AI的噪音里识别真正重要的信号，这比任何工具都重要。

"领测老贺我在这行干了快30年，见过太多技术浪潮。"我回复他，"每一波浪潮来的时候，大家都在问'怎么用'。但真正重要的，往往是'怎么不用'——哪些需求不该接，哪些功能不该做，哪些AI输出不该留。"

他回了一个竖大拇指的表情。

我看着屏幕，想了想，又打下一行字：

"AI时代，判断力比执行力更重要。"

当你让AI在一分钟内生成1000条测试用例时，真正的能力已经不再是"写"，而是"判断"。当你用AI把覆盖率从45%推到90%时，真正的风险已经不是"测不够"，而是"测不对"。

现在，打开你的测试仓库，找一份AI生成的用例文件，问自己一个问题：这里面的用例，有多少是我真正理解了业务场景后，主动选择保留的？

如果答案是"不清楚"，那你可能已经交了认知税了。

窗外的蝉鸣还在响，办公室里很安静。我合上电脑，脑海里浮现老张的故事。从焦虑到行动，从行动到思考，他走过的路也是很多测试人正在走的路。

AI不是洪水猛兽，也不是灵丹妙药。它是一面镜子，照出的是我们自己的认知边界。当我们学会在AI的噪音里识别真正重要的信号，我们才真正掌握了测试的核心能力。

现在，轮到你打开那扇门了。