AI Agent测试失败越频繁，你的团队越危险

导读

我认识一个测试工程师，姑且叫他老周吧，在一家中型互联网公司干了八年，简历写出来很漂亮——主导过多次架构重构的测试工作，带过团队，经历过项目从零到一。

去年他们公司上了AI测试平台，号称能让测试效率提升十倍。老周一开始很兴奋，觉得终于可以从繁琐的手工用例里解脱出来了。

半年后我问他效果怎么样，他说很好，效率确实高了。

我又问他：那你现在主要做什么？

他愣了一下，说：审核AI生成的测试用例，看看对不对，然后执行。

我再问他：那些用例，你觉得不对的情况多吗？

他又愣了一下，说：不多，基本都对。

我最后问他：那你的价值是什么？

他想了很久，有点失落的最后说：我也不知道，反正每天都很忙。

一个正在被软件测试行业忽视的真相：AI测试越普及，测试工程师的独立判断力却越来越退化

这就是老贺想说的事情。不是AI不好，而是我们在不知不觉中，把自己活成了一个“确认按钮”。

一、什么是被“AI驯化”

我先解释一下“驯化”这个词。

野生动物被驯化，不是被关进笼子里，而是它的本能反应被慢慢改变。狗看到人会摇尾巴，不是因为它天生喜欢人，而是因为千百年来，那些不摇尾巴的狗没被留下来。

测试工程师正在经历类似的过程。

你可能没意识到，但如果你每天的工作流程是这样的：

早上打开电脑 → AI生成一批测试用例 → 你看看有没有明显的问题 → 如果没有就执行 → 下午AI分析测试覆盖率 → 你看看报告 → 如果没有红色警告就提交 → 晚上AI生成测试报告摘要 → 你复制到日报里 → 发送。

现在你还想让小龙虾（openclaw）直接自己干了，你就不参与了。你觉得这个流程看起来很高效对吧？产出比半年前高多了，日报内容更丰富了，主管也觉得你很忙。

但你有没有想过：在这个流程里，你的判断力在做什么？

大多数时候，你的判断是：“嗯，看起来没问题。”

这个判断需要什么能力？几乎不需要。你不需要理解业务逻辑，不需要分析用户行为路径，不需要判断这个功能上线后会不会出现预料之外的连锁反应。

你只需要识别“明显不对”的情况。

而AI生成的测试用例，“明显不对”的概率本来就很低。

所以你的工作，逐渐变成了一种心理安慰——你在告诉自己“我还在参与这个决策”，实际上你只是在给AI的输出盖一个“已读”的章。

这不是在使用工具，这是被工具使用。

二、效率陷阱：那些没人说的事实

现在几乎所有关于AI测试的文章，都在讲同一个故事：自动化程度提高了，回归测试时间缩短了，缺陷发现更及时了。

这些是真的吗？可能是。

但这是全部的真相吗？绝对不是。

让我问你几个问题：

第一个问题：如果所有测试活动都可以被预设规则覆盖，那测试工程师这个岗位存在的意义是什么？

你可能会说：AI只能处理规则内的场景，规则外的还是需要人来判断。

好，那我们来想一个具体的场景。

你负责支付模块的测试，这个模块已经跑了两年的自动化用例，覆盖率维持在85%以上。AI接手后，覆盖率提升到了92%，执行时间从四小时缩短到了四十分钟。

有一天，产品经理告诉你，我们要上一个新功能：用户可以用积分抵现，抵现比例动态计算，涉及到三个子系统、两种会员等级、四种优惠券叠加方式。

这个功能的测试，你怎么设计？

你让AI生成用例，它会基于什么？基于现有的系统文档、基于历史的测试数据、基于你喂给它的业务规则。

但这个新功能的核心价值是什么？是“让用户觉得占了便宜”。

这不是一个可以写进规则的场景。

用户“觉得占便宜”是一个心理学问题，不是逻辑问题。你需要理解用户的心理模型，需要想象用户在什么情况下会产生“划算”的感觉，需要判断系统的计算方式会不会在某些边界情况下让用户觉得“被骗了”。

这些东西，AI能帮你吗？它能生成测试用例，但它生成不了“测试意图”。

第二个问题：你的日报里，有多少内容是你自己思考的结果？

我见过很多测试工程师的日报，开头是AI生成的项目进度概述，中间是AI整理的缺陷统计，后面是AI总结的风险评估。

如果把这些AI生成的内容去掉，你自己的输出是什么？

可能是：“今日主要工作为执行AI生成的测试用例，未发现新问题。”

这句话放三个月前的日报里，你会觉得有成就感吗？

第三个问题：当AI出错的时候，你能发现吗？

Capgemini在2025年发布的《World Quality Report》里提到，有50%的组织表示自己缺乏AI和机器学习方面的专业知识。这个比例和2024年一模一样。

也就是说，整个行业在说了一年“全面接入AI”之后，在AI能力建设上几乎没有进步。

但这并不影响大家继续高喊“AI赋能测试”。

于是出现了我前面说的那种荒诞：一个连模型偏差都解释不清的团队，在用AI做“智能风险评估”；一个连CI稳定性都搞不定的公司，让Agent自动提交代码修复；一个测试环境三年没统一过的项目组，讨论“让AI自己处理环境差异”。

这不是在提效，这是在给一辆刹车有问题的车换上更快的发动机。

三、比失业更可怕的是：测试思维退化

很多人担心AI会让测试工程师失业。

我不太担心这个。

我担心的是另一件事：十年后，我们还能不能认出“测试工程师”这个角色。

以前我面试测试工程师，会问三类问题：

第一类是关于思维的——你怎么设计一个复杂系统的测试策略？你怎么在没有明确需求的情况下发现潜在风险？你怎么判断一个缺陷该不该修？

第二类是关于沟通的——你怎么跟开发人员解释一个bug的严重性？你怎么说服产品经理接受你的测试结论？你怎么让非技术人员理解技术债务的风险？

第三类是关于学习的——你有没有自己搭建过测试框架？你有没有研究过某个技术的底层原理？你有没有在不熟悉的领域快速上手的能力？

这三个能力，有一个共同的特点：它们都很难被工具替代。

但现在的面试官开始问另一类问题了：你调过哪些模型的temperature参数？你用过哪些Prompt模板来优化测试用例生成？你怎么评估AI生成测试用例的质量？

这些是技能问题，不是能力问题。

技能是可以被工具替代的。你今天会用某个AI测试平台，三年后可能就不需要人会用了，因为工具会更智能，更易用。

但思维方式和学习能力，永远不可能被工具替代。

我不是说学会用AI工具是错的。技能是重要的。

但当一个岗位的选拔标准，从“你怎么想”变成“你怎么喂AI”，这个岗位就已经开始变味了。

我还记得我做测试工程师的时候，有一种测试方法叫“探索性测试”。没有预设的测试用例，没有脚本，没有计划。

你拿着一份需求文档，坐在电脑前，靠经验和直觉去找系统的漏洞。

你需要想象用户会怎么用这个系统，然后去验证你的想象。你需要挑战开发人员的假设，找到那些“应该不会发生但其实会发生”的场景。

这种测试没法自动化，因为它依赖于你的直觉、你的经验、你的创造力。

现在面试新人的时候，有时候会问：你知道什么是探索性测试吗？做过吗？

很多候选人的回答是：知道，但我们现在都用AI做自动化测试，探索性测试不适用。

听到这个回答，我不知道该说他们是对的，还是该说他们错过了什么。

AI确实能做很多事情，但它做不了“直觉”这种东西。

直觉是什么？直觉是你见过足够多的场景之后，大脑在潜意识里形成的快速判断能力。

这种能力只能通过大量的实战经验积累。它没法通过看文档获得，没法通过学Prompt技巧获得，更没法通过调用API获得。

而探索性测试，恰恰是培养这种直觉最好的方式。

当AI替代了大部分的探索性测试场景，测试工程师的直觉能力就会慢慢退化。

这不是危言耸听，这是规律。

四、Agent不是加速器，是照妖镜

现在行业内有一种说法：AI Agent是开发者的加速器，能让每个人的产能提升十倍。

这个说法老贺不完全同意。

Agent不是加速器，它是照妖镜。

它照出来的不是AI的能力，是你自己的问题。

为什么很多团队用不好Agent？因为他们以为是AI不够聪明，其实是团队的基础太烂。

举几个我见过的真实例子。

第一个例子：一家公司上了AI代码审查Agent，结果发现Agent生成的修复建议，有一半都用不了。原因是他们的代码风格不统一、命名规范混乱、注释几乎不存在。AI能看懂代码，但它没法弥补团队多年的技术债务。

第二个例子：一家公司用Agent自动生成测试用例，结果生成的用例有一堆是无效的，因为他们的系统文档早就过时了，AI参考的是三年前的旧资料。

第三个例子：一家公司让Agent根据Bug描述自动生成测试脚本，结果Agent经常改错地方，因为它没法准确理解Bug的上下文，而这恰恰是因为他们的Bug描述写得模模糊糊，三言两语，没有复现步骤，没有环境信息。

每次遇到这种情况，当事人的第一反应都是：AI不行。

但真相是什么？真相是，AI只是把你团队本来就存在的问题，放大十倍展示出来了。

我曾经在一家传统企业做TMMi咨询，他们的CI流程，三年没跑通过一次完整的回归测试。不是因为技术上有多难，是因为团队协作问题、需求变更频繁问题、测试环境不统一问题，一直没人解决。

你去问他们现在的计划是什么，答案是：“准备引入AI来自动化修复测试失败的问题。”

我跟他们的技术负责人说，你先让CI能完整跑通一次再说。

他问我：AI不是应该能自己处理这些吗？

那一刻我就知道，这场所谓的“AI转型”，大概率会以失败告终。不是AI不够好，是他们的基础太差了，好工具也救不了。

AI不会掩盖管理问题，它只会以更快的速度引爆它。

你看到那些在Anthropic、Google顺利落地Agent的案例，觉得是AI厉害。

不是的。那是人家十几年的工程治理、代码规范、文档建设、团队协作的综合体现。AI只是最后那块拼图。

而大多数公司，连前面的拼图都没准备好，就想直接抄最后的答案。

这不是在提效，这是在拿生产环境做实验。

五、最大的盲区：测试本身并不可靠

几乎所有的AI测试方案，都有一个默认的假设：

测试本身是可靠的，是稳定的，是可以被信任的。

这个假设是有问题的。

现实情况是：大多数公司的测试套件，其实处于半死不活的状态。

Mock写得随意，今天能跑通，明天换个参数就报错。断言写得很脆弱，稍微改个边界值，整个用例就废了。测试数据靠人工维护，用例执行成功率看心情，有时候跑十次能过七次，有时候只能过三次。

在这种情况下，你让AI去“参考测试反馈做决策”，就像让医生根据一份错漏百出的体检报告来开药。

体检报告错了，医生开错药，责任是医生的吗？

更让人担忧的是：一旦AI开始大量生成测试代码，这些代码由谁来维护？

现在的测试代码已经很难维护了，文档缺失、逻辑复杂、重构困难。

AI生成的代码，因为是自动化产物，往往比人工写的更难理解——你不知道它为什么这么写，你只知道它生成的测试通过了。

如果连人工写的测试代码都经常腐化，AI生成的只会腐化得更快，因为它是在特定上下文下生成的，一旦上下文变了，它的逻辑可能就不适用了。

结果会是什么？

我们正在制造一场“测试雪崩”：

AI生成测试 → 测试质量下降 → 错误反馈给系统 → AI基于错误反馈继续优化 → 更多错误测试 → 更大的混乱。

没有人愿意谈这个问题，因为它太扫兴了。

大家都想听“AI让测试更高效”的故事，没人想听“AI可能让测试变得更混乱”的警告。

但领测老贺作为一个真正负责任的测试行业的从业者，不应该只说你想听的话。

六、给不想变成“确认按钮”的你

批评是容易的，建设是难的。

我不想只泼冷水，我也想说一些真正有用的话。

如果你不想在五年后变成一个高级的“AI确认按钮”，有几件事你可以做：

第一，每天留一个小时，不碰任何AI工具。

这一个小时，用来处理需要深度思考的工作——设计测试策略、分析边界场景、评估架构风险、跟开发讨论技术方案。

不是为了对抗AI，而是为了保持大脑的“野外生存”能力。

你不能每天都坐车，偶尔也要走走路，不然腿会退化。

第二，把AI的定位从“替代者”改成“参考者”。

AI生成的东西，永远是原材料，不是成品。

你要做的是加工，把原材料变成真正有价值的东西。没有你的加工，AI生成的永远是半成品。

第三，定期做一次“裸测”练习。

关掉所有AI工具，用最原始的方式——看文档、想场景、写用例、执行、记录、评估。

做完之后，跟你用AI辅助的结果对比一下。你会发现，有时候人工做的比AI好，有时候AI做的比人工快。

重要的是，你要知道自己的边界在哪里。知道边界在哪里，才不会被工具牵着走。

第四，把学习AI的时间，合理分配。

学会调参、学会写Prompt、学会用新工具，这些都是有用的技能。

但别让它占据你全部的学习时间。你还要花时间去理解业务、理解用户、理解系统、理解人性。

这些东西，AI学不会，但它们能让你变成一个更好的测试工程师。

第五，在团队里推动“AI治理”的概念。

AI生成的代码应该有审查流程，AI生成的测试应该有二次确认，AI输出的结论应该有人类测试专家背书。

不是因为AI不可信，而是因为过度信任任何系统都是危险的。

写在最后

老贺干测试块三十年，见过太多次“革命性技术”改变这个行业。

自动化测试刚出来的时候，有人说测试工程师要失业了。结果是自动化测试让测试工程师可以做更多事情。

敏捷开发流行的时候，有人说测试工程师的角色要消失了。结果是测试工程师在敏捷团队里找到了新的定位。

现在AI来了，同样的论调又出现了。

但我想说，每一次技术变革，都是一次重新洗牌。

洗掉的是那些拒绝学习、固守旧模式的人。

留下的是那些能够拥抱变化、但不被变化裹挟的人。

测试工程师的核心价值，从来不是写用例、执行用例、生成报告。

测试工程师的核心价值，是确保软件系统值得被信任。

这个价值，需要经验、需要直觉、需要判断力、需要和人沟通的能力、需要对业务的深刻理解。

这些东西，AI可以辅助，但AI替代不了。

怕的是，在AI辅助的过程中，我们慢慢忘记了什么才是真正重要的。

所以，在你下一次习惯性地把问题丢给AI之前，先问自己一个问题：

如果明天断网，你能解决这个问题吗？

如果答案是“不能”，那你要担心的，不是AI抢了你的饭碗。

而是你正在变成一个，离不开AI的高学历“确认按钮”。