在 AI 时代，测试工程师还有未来吗

今天这篇文章，是本号过年前的最后一篇。

我想认真聊聊这些年来，尤其是最近 AI 席卷之下，我对测试，或者说测试开发这个岗位的一些思考。

本文会尽量少使用 AI 润色。如果你愿意看完，欢迎在评论区或私信和我讨论，我也非常渴望有人能就其中的一些问题，对我指点迷津。

这些年，我经常陷入一种自信与自卑反复拉扯的状态。有时会觉得自己很强，团队离不开我；有时又会觉得自己什么都不会，也做不出什么真正有价值的东西，对职业产生强烈的不安全感。

我曾经有过一段时间，非常认真地考虑转开发，最后还是选择继续做测试。我相信，很多有一定技术能力的测试同行，都反复想过这个问题。另一方面，科班学生也可能因为课程设置和网络信息的影响，对测试这个岗位并不了解，往往因为“测试开发”里带着“开发”二字，而把它当成开发岗位的备选——这一点我在以前的文章中也写过。

1. 测试工程师的过去和未来

“测试开发”和“测试”到底有什么区别吗？

至少在今天，尤其是一线城市和互联网行业里，我认为已经没有本质区别了。

在计算机和软件刚刚诞生的年代，并不存在“测试工程师”这个职业。写代码的人写完之后，顺手测一下，这是再自然不过的事情。后来，软件规模变大，Bug 的代价开始变高，逐渐有人专门负责验证别人写的程序是否正确。但在那个阶段，测试更像是一项任务，而不是一种职业。

再往后，软件越来越复杂，软件工程成为一门学科，测试方法论、测试阶段划分开始出现。随着 PC 普及和商业软件爆发，软件的使用者不再只是专业人士，而是“普通用户”，“测试工程师”这个角色才逐渐成型：不再参与业务代码开发，而是专职负责测试。

进入互联网时代后，测试岗位进一步细分，出现了自动化工程师、测试开发工程师、质量保障工程师等各种 title。但又将近二十年过去，你再打开招聘软件会发现，这些 title 背后的工作内容和要求，已经高度趋同。

伪装

很多时候，“测试开发”更像是一种对外的包装。应届生入职后才发现，实际工作内容和传统测试并无本质区别。这一点不需要太多证明，几乎是行业共识。

在经济增速放缓、竞争加剧的背景下，应届生整体能力越来越强，但业务并不真的需要那么多“测试开发”。招聘方又不能直说“我们只是需要一个点点点的测试”，“测试开发”听起来更高级。

成本

在一些团队里，“测试开发”被当作更便宜的开发使用。当开发人力紧张，又不愿意增加正式开发 HC 时，把一部分开发不愿意做的事情交给测试开发，成了一种现实选择。

故事

“开发”是测试工程师的一种晋升手段。在公司开发平台的测试比业务测试更能讲故事，也就更容易拿到资源。

更有趣的是，由于开发平台的测开基本是全职做平台，往往快速流失业务能力，做出的成品难以得到业务团队的好评。另外，在平台项目中，往往既没有产品经理，也没有测试角色，此时，团队回归了上个世纪的工作方式：需求、开发、测试都集中在同一批人身上。

AI 来了，测试工程师的未来在哪里？

和开发相比，我脑中一直有两种相互冲突的判断。

一种认为，测试的门槛低于开发，AI 会优先替代测试；另一种则认为，测试工作中包含更多“人性化判断”，反而更难被完全替代。

但无论如何，我不愿意用“顶级测试无法被替代”来安慰自己。更现实的判断是：测试行业一定会经历一次剧烈震荡，相当一部分人会被迫转行。谁都不该高估自己，赌自己是那个幸运儿。

也许就在五年内。

我会吐槽现在 AI 生成的测试用例质量不高，会吐槽AI执行用例慢、效果一般，但在 AI 进化的速度面前，这些都只是时间问题。对所有人来说，稳妥的选择，不是去赌行业、赌公司，而是不断增强自身能力的可迁移性。

2. 测试岗的边界

难以撰写的年报

产品经理的核心目标是赚钱，开发的核心目标是生产产品，测试的核心目标则是减少 Bug。

那么，作为一个测试，你要如何撰写你的年报？

正因如此，测试往往会主动扩展自己的边界：写工具、造平台、建设流程，让工作看起来更加“工程化”。当然，晋升也需要这些。

于是，测试的评价体系，开始向开发靠拢。除了出事的时候，没人在意质量如何被保障。

团队的缓冲

在任何公司、任何项目中，都天然存在冲突。

需求想快、想多、想变；开发想稳、想少、想可控；业务想要结果，却不想承担技术成本；管理层只关心一件事：别炸。

于是，组织中一定会出现一层“缓冲层”——不直接创造最终价值，但负责吸收不确定性、风险、情绪和混乱。测试，恰恰就是这层缓冲。

你一辈子也遇不到几个实现结果与 PRD 完全一致的需求，消化这些不确定性往往就是靠测试。

3. 测试岗的护城河

如果要谈护城河，首先必须承认：开发岗位的护城河本身，也正在被削弱。

不要轻易用“顶级开发永远有饭吃”、“AI 写的代码没人能维护”来安慰自己。先抛开情绪，只问几个现实问题：一个团队到底需要多少顶级开发？在 AI 的辅助下，这个数量是会上升，还是下降？如果过去一个人只能维护一份代码，那么现在是否可以同时维护两份、甚至三份？

护城河的瓦解并不是一瞬间发生的，而是通过不断降低从业门槛来完成的。这种变化，在学习阶段体现得尤为明显。借助 AI，学生和转行者学习编程的速度被大幅压缩，而计算机行业本身又缺乏法律、医疗那样明确的准入壁垒。

在这样的背景下，再回头看测试岗位，现实只会更加残酷。

我当然清楚，在实际工作中，一个优秀的测试和一个差劲的测试之间，差距巨大。但问题在于，这种差距往往只有在你已经进入团队、深入系统之后，才会被真正感知。在招聘筛选、岗位调整、成本收缩时，测试的不可替代性，反而最难被证明。

测试的技术门槛普遍低于开发，却对经验判断、责任心和软素质提出更高要求。但这些能力难以量化，也难以展示。于是，测试只能不断给自己叠加背景、项目和 title，试图用履历为能力背书。

而这，正是我对这个职业感到不安的地方。

结语

本文负能量较多，我并不是想否定测试这个岗位。测试依然重要，质量依然重要。

但重要，并不等于安全；不可或缺，也不等于不可替代。

在 AI、组织成本和行业周期多重因素叠加的当下，我越来越觉得，与其纠结自己会不会被替代，不如更诚实地问自己一个问题：我现在积累的能力，是否具备跨岗位、跨阶段的生命力。

这或许也是我反复自信、又反复自卑的根源。