为什么越来越多测试工程师开始焦虑了

有一种焦虑，不是突然来的，是慢慢渗进来的。

去年年底，我在一个测试工程师的线上社群里看到一条消息。发消息的人做了八年测试，在某互联网公司担任高级测试工程师。他说：

“我们组今年没有招新人，原来六个人做的活，现在五个人在做。但工时没变，我问 leader，他说效率工具补上了。我突然不知道自己该怎么往前走了。”

这条消息底下有 200 多条回复。很多人说“同感”，有人说正在考虑转行，有人说正在自学 Python 和 AI 相关的东西，也有人说“不知道学什么”。

这种集体性的迷茫，不是矫情，不是焦虑过度，而是对一个正在发生的真实变化的如实感知。

这篇文章想认真讨论一个问题：测试工程师的焦虑，到底从哪里来？它有没有被过度渲染？面对它，我们能做什么？

一、焦虑的来源是真实的，不是被炒作出来的

先说一个让很多人不舒服的事实：这几年，测试岗位的招聘需求确实在结构性收缩。

这不是网上的传言。招聘平台的数据、各公司公开的组织调整信息，都指向同一个方向——基础测试岗，尤其是以手工测试、功能验证为主要工作内容的岗位，正在被压缩。这一趋势在国内外科技公司里同步出现。

与此同时，AI 辅助测试工具的能力边界在过去两三年里快速扩张。可以生成用例的、可以自动执行回归测试的、可以分析代码变更范围的工具，已经不再停留在“Demo 阶段”，部分团队已经把它们真正用进了日常流程。

有一组行业观察数据值得关注：AI 实现的自动化测试覆盖率可超 90%，并且能够精准识别代码中的隐藏 Bug。这不是说人工测试彻底没用了，而是说曾经需要大量人力堆砌的那些工作，它的门槛正在被 AI 快速拉平。

更直接的信号来自裁员数据。AI 确实正在重塑岗位结构，并逐渐成为一项相对独立且日益重要的裁员动因，尤其体现在客服、后台支持以及部分软件测试等白领和支持性岗位上。

当然，这件事有一定的复杂性。更多专家和从业者觉得，很多公司只是“借 AI 的壳，圆裁员的梦”。经济周期、组织结构调整、行业竞争压力——这些因素共同作用，AI 只是其中一个变量，但不一定是最主要的那个。

然而，这对处于焦虑中的测试工程师来说，区别并不大。无论是 AI 真的替代了工作，还是企业借 AI 之名压缩了编制，结果都是：岗位变少了，要求变高了，留给“只会手工测试”的人的空间越来越小了。

这种焦虑，是真实的，有依据的，不是自己吓自己。

二、焦虑背后，是一个被长期忽视的结构性问题

但如果只是说“AI 来了，测试要完蛋了”，这个结论就太粗糙了。

焦虑的真正根源，比“AI 替代”更深一层。它是测试这个职业，在很长一段时间里，对自身能力的定义太窄了。

很多测试工程师，包括做了好几年的资深测试，把自己的核心价值绑定在了“执行”上——执行用例、执行回归、执行验收。这个模式在软件行业高速扩张的阶段是行得通的，因为项目多、需求多，人手永远不够，执行能力就是生产力。

但这个时代正在结束。

当 AI 能够在几分钟内生成一份覆盖率合理的用例草稿，当自动化工具可以在每次代码提交后自动跑完回归测试，当 CI/CD 流水线把测试嵌进了开发流程——单纯依靠“执行”的价值，就被快速稀释了。

AI 可以在几分钟内跑完你三天的工作量——回归测试、UI 比对、接口验证，统统自动化。这句话听起来危言耸听，但在某些类型的项目里，它正在成为现实。

问题不是 AI 太厉害，而是：很多测试工程师的护城河，从一开始就建在了沙滩上。

“我会写用例”——AI 也会。

“我会跑回归”——自动化工具也会。

“我会提 Bug”——Sonar、各类静态分析工具也在提。

那测试工程师真正不可替代的东西是什么？这个问题，很多人从来没有认真问过自己。焦虑，部分来源于此。

三、被替代的不是测试这件事，而是测试里某种做事方式

这里要做一个重要的区分，否则容易陷入另一种误区——要么觉得 AI 无所不能（恐慌），要么觉得 AI 对测试没影响（盲目乐观）。

实际情况是：AI 替代的，是测试工程里高度模式化、可结构化的那部分工作。

哪些是可结构化的？

• 根据接口文档生成边界值用例
• 根据代码变更推荐回归测试集
• 执行标准化的功能验证流程
• 生成测试报告和覆盖率统计

这些工作，在一个配置得当的 AI 工具面前，已经可以做到七八十分。而且还在持续进步。

哪些是 AI 目前还做不好的？

• 理解没有写进文档的隐性业务规则
• 判断一个 Bug 的实际业务影响有多大
• 发现“功能上没问题，但用户体验上说不过去”的问题
• 在复杂的分布式系统里做跨链路因果推断
• 决定这个版本该测什么、不该测什么、测到什么程度

后面这些，需要的是业务理解、系统认知、判断力和风险意识。这些东西，不是靠堆砌用例积累出来的，而是靠长期深入地参与产品开发、贴近真实用户、在一次次线上事故中磨砺出来的。

2025 年的测试工程师，不再是“找 Bug 的人”，而是质量的设计者、风险的预判者、用户体验的代言人。这句话有些理想化，但方向是对的。

一个真实的案例可以说明这种区别：某 App 的新用户引导流程，自动化测试跑过了所有用例，没有发现任何功能问题。但上线后发现 40 岁以上的用户完成率只有 20%，因为某一步操作对于不习惯智能手机的用户来说过于复杂。这个问题，没有写在需求文档里，AI 生成的用例也不会覆盖它，但一个对用户有感知的测试工程师，是有可能在测试阶段就发现这个隐患的。

这就是不可替代性所在的地方。

四、一个现实的观察：焦虑的人往往有三个共同特征

和很多测试工程师聊过之后，我发现那些焦虑感最强的人，往往有几个共同之处：

特征1：技能树单一，且集中在“生产”而非“判断”。

每天大量时间花在写用例、执行测试、提 Bug 上，对测试策略、质量体系、风险决策几乎没有涉及。这种人，换一个项目可以快速上手，但很难在岗位缩减时显示出不可替代性。

特征2：对 AI 工具的态度是“等等看”，而不是“先用起来”。

很多人抱着一种心态：等 AI 成熟了再学。但这个等待的成本远比想象的高。现在用 AI 工具的人，正在建立的是“如何驾驭 AI、如何审查 AI 输出、如何把业务知识注入 AI”的能力。这个能力差距，六个月后就会很明显。

特征3：对自己的业务理解程度估计过低，或者从未认真盘点过。

有意思的是，很多工作了三五年的测试工程师，其实已经积累了大量 AI 短期内无法具备的东西——对特定业务的深度理解、对高风险模块的直觉感知、对团队协作模式的把握。但他们往往不知道如何把这些东西显性化、系统化，让它们成为可以被看见的价值。

五、与其焦虑，不如做三件具体的事

说了这么多，最后要落到实际行动上。不是鸡汤式的“拥抱变化”，而是三件可以从下周开始做的事。

1、把你的业务知识显性化

找出你负责的模块里，那些只有你知道、文档里没有写清楚的业务规则和历史坑点。把它们整理出来——不是为了写文档，而是为了搞清楚“我的价值到底在哪里”。

这个整理的过程，你会发现自己比想象的更难被替代。同时，这些内容也是未来构建 AI 辅助测试 Skill 的核心原材料。

2、认真用一次 AI 工具来生成测试用例，然后做严格审查

找一个你最熟悉的模块，让 AI 生成一份测试用例草稿，然后逐条审查：它遗漏了什么？它理解错了什么业务规则？审查的过程，就是在弄清楚你的判断力和 AI 的边界分别在哪里。

这比看十篇“AI 测试趋势分析”文章，都更有价值。

3、把测试策略，而不是测试执行，变成你的核心输出

下一个版本发布前，尝试写一份“测试策略报告”：这次变更的高风险区域在哪里？哪些地方可以用自动化覆盖？哪些地方必须靠人工判断？资源有限时，优先级如何排？

这份东西，AI 目前写不好，但你可以。而且它的价值，远超一份 200 行的测试用例表。

结语：焦虑是信号，不是终点

AI 替代人类，并不是像终结者一样某天突然把人类一脚踢开，而是一个“滑块”不断向右（高自主性）缓慢移动的过程。

测试工程师的焦虑，是对这个滑块移动的真实感知。这种感知是准确的，也是有价值的——比那些感知不到变化、还在用五年前的方式工作的人，要清醒得多。

但焦虑只是起点，不是答案。

如果这种感知能推动你认真盘点自己的价值所在，推动你去用那些正在改变行业的工具，推动你把更多时间从“生产”迁移到“判断”——那它就是一个有用的信号。

测试工程师不会消失。但“只会写用例跑回归”的测试工程师，正在越来越难找到位置。

这不是威胁，是现实。而现实，是用来应对的，不是用来焦虑的。