AI 時代，軟件測試工程師的價值是甚麼？

简介： AI时代，测试工程师价值已从“找Bug”升维为“守底线、控风险、推提效”：善用AI提效重复工作，聚焦复杂场景验证、模型边界测试、质量体系构建与研发流程优化，成为产品质量的最终把关人和效能提升的驱动者。

前段时间在知乎上刷到一个问题: 「软件测试工程师的价值是什么？」

底下什么说法都有，吵得不亦乐乎。

索性，今天我们也来聊聊这个话题。

平时没人问这个问题的。当它冒出来的时刻，往往都不怎么愉快。

要么是线上出了事故，老板在群里甩下一句，这个版本是怎么测的。要么是面试场上，面试官笑眯眯看着你，等你说出一段像样的回答。这两年又多了一个时刻，AI 学会了写用例、写脚本、跑回归、生成测试报告，每隔一段时间就有新工具刷屏，总有诸多声音在疯传，测试的天要塌了，测试人都要失业了。

这个问题我也被咨询过很多次。今天认真答一回，先从流传最广的那个讲起。

靠找 bug 这件事，撑不起一个岗位

流传最广的答案，测试的价值就是找 bug。

这个答案最大的麻烦，是它会顺理成章地推出另一个结论。AI 找 bug 比人快，不睡觉，不喊累，还便宜。要是这个岗位的核心就是找 bug，那确实没什么好辩护的。

但你想想，公司是按 bug 单的数量给测试发工资的吗。

提一百个 bug，全是边边角角的样式问题，上线那天最要命的坑没人看见，这一百张单子一文不值。反过来，一个 bug 没提，但每一版都说得出哪里稳、哪里悬、这版能不能发，这样的人，团队抢着要。

我做了那么多年研发管理，面试过不少测试同学。简历上都写着精通自动化，真到定薪，拉开差距的从来不是谁的脚本多。有人交付的是一堆脚本，跑得挺欢，漏了关键场景，照样上线炸。有人交付的是一句「这版能上」。这句结论背后，是他知道哪些模块历史上炸过、这次的改动碰没碰到那些雷区。

前者卖产出，后者卖判断。公司为判断力付的钱，一直比产出贵。

每个人只看得到自己那一段

那判断力这个东西，开发自己不能有吗。代码是他写的，他最熟，省一个测试岗岂不是更省钱。

这个疑问有个前提，开发对自己的代码足够了解。坏就坏在这个了解上。

写代码的人，心里装着一套预期。输入什么，输出什么，什么条件走哪条分支。让他自测，他会不自觉地照着这套预期来，用最顺的路径，给最正常的数据。你不能说他偷懒，他只是很难跳出自己脑子里的那套定型思维。

自测通过，证明的也只是代码跑起来像他想的样子。至于他想的样子对不对，跟旁边的模块接不接得上，用户会不会按他想的方式操作，这些自测都答不了。

还有个更深层的原因。一个系统往往是多个人共同开发出来的，每个人负责自己的模块，把自己负责的功能做到极致。但产品能不能用，从来不取决于单独某个模块，取决于整个链路。A 模块返回的字段，是 B 模块没料到的格式。C 以为 D 会做校验，D 以为 C 做了。每一段单看都是好代码，拼在一起，用户下不了单。

这种接缝上的事，得有人横跨所有模块地看。公司里这个视角是现成的，就是测试。需求评审他在，接口联调他在，每个版本的集成验证还在。这跟谁更聪明没关系，跟位置有关系，测试是团队里唯一全程盯着接缝的角色。

线上出事故，问题先过测试的手

前面讲的这些，都发生在平静的日子里。真让一个岗位的价值现形的，是出事的时候。

线上系统半夜出问题，告警打进来，事故群里挤进来一堆人。代码的问题开发负责解决，环境的问题运维负责排查。剩下测试，很多人觉得他顶多在群里围观。

还真围观不了。出了事第一个要回答的，是哪个环节出的问题。生产环境几十个服务搅在一起，日志翻半天，监控看花眼，开发和运维各查各的，最怕互相等。测试是全程验过这条链路的人，下单挂了，他心里有数，是支付接口的新改动，还是昨晚发版碰了配置。

环境的问题，他得协助运维排查，代码的问题，他得复现后告诉开发。那一晚的线索，大半是从测试手里转出去的。

还有两件事也落在测试身上。一件是影响面，哪些功能坏了，伤到多少用户，得有人一句一句报清楚，这是给拍板回滚的人看的。另一件是收尾，回滚到哪个版本、补丁上来行不行，得有人从头再验一遍，确认系统真的恢复，不带出二次事故。

AI 加入原有工作流后，这道题换了问法

这两年，写用例、造数据、跑回归、出报告，这些活确实越来越多是工具在干了。以前它们能占掉一个测试的大半天，现在 AI 几分钟出初稿，人筛一遍就能交。这个变化不用装看不见，趋势来了，你也拦不住。

最先消失的岗位，都是一句话能讲完的岗位，所有产出都能被生成。纯点鼠标、纯记录的手工执行测试，在这个范围里。

但 AI 写的用例，覆盖的只是它知道的部分。哪个接口三年前出过事故，哪个需求当年因为一个大客户临时改过逻辑，哪段老代码碰不得，这些它自己编不出来，得有人喂。喂它的人，得先自己知道。

所以这个岗位的行情，得拆开看。执行那一层在跌价，判断那一层在涨价。知道测什么、不测什么、测到哪一步算够、这版能不能发，这些问题的答案，AI 给不了，得有人押。

回到这个话题本身

AI 时代下，软件测试工程师不再只是机械执行用例、点点界面的执行者，核心价值是站在用户、业务与风险视角，定义测试目标、设计校验逻辑、识别 AI 模型的隐性缺陷与边界风险，把控产品质量底线。

拿到一个需求，先替用户问，我会不会这么用，会不会那么填。再替业务问，这个功能挂了，公司损失最大的是哪一笔。最后替团队问，这次改动最可能出事的地方在哪。三个问题答下来，测什么、测到哪算够，就有了底。

被测的东西本身也在变。越来越多产品把大模型接了进去，测试对象从功能变成Agent 与模型。功能好测，输入固定，输出对不对一眼能看到。模型难缠，同一个问题问两遍，答案能不一样。这类缺陷不会在界面上报错，只会一点一点磨掉用户的信任。把它们找出来，划出模型能干什么、不能干什么的边界，这是 AI 时代给测试出的新题。

还有个反着来的活。开发用 AI 写代码，测试用 AI 出用例、造数据，快是真快，产出的东西谁来兜底。AI 写的代码，得有人验过才能合入。AI 生成的用例，得有人复核断言和覆盖，别拿着一份漂亮的全绿报告就放心。这层验证不加上，越快，出事越快。

省下来的精力也有去处。重复的回归、机械的脚本、成批的数据，交给工具日夜跑，人去啃机器啃不动的部分。跨模块的复杂场景，一次并发、一次降级、一次数据迁移，组合起来千变万化，得有人一寸一寸推。单个 bug 之外看趋势，哪个模块月月出问题，就推动从需求评审、变更管理这些源头堵。日子久了，这些事攒成团队的质量底子，发布快不快、敢不敢，全看这套底子硬不硬。

所以这个岗位在 AI 时代的角色，拆开说就是两头。一头把关，产品稳不稳定、合不合业务预期，上线前有人签字负责。一头推动，工具怎么用、流程怎么改，让团队的质量和效率一起往上走。

写用例的活给了机器，担风险的活留给人，这个分工，短期内变不了。

写在最后

所以，最后概括起来，AI时代，软件测试工程师的价值应该体现在：

善用 AI 工具提效重复回归、生成脚本与数据，把精力聚焦在复杂场景验证、风险分析、质量体系建设、推动研发流程优化，同时评估 AI 生成内容与代码的可靠性，保障产品稳定可用、符合业务预期，成为质量风险的把关人和质量效能的推动者。