测试总被排进“先变化”名单，但变化的不是最关键那层

外界一提岗位替代，测试工程师总会被排到靠前位置。原因也不难理解。生成用例、补单测、做冒烟、跑回归、汇总差异，这些动作都很适合被脚本化，而大模型进一步增强了脚本化和自动生成的能力。于是很多人顺着这个逻辑继续往前推：既然 AI 已经能生成测试，那测试工程师是不是会比开发更早被吞掉。

这个判断的问题在于，它把测试理解成了“执行用例的人”。可现实里的测试价值，从来不只是执行动作，而是定义质量边界、设计失败样本、解释异常结果、决定是否放行，以及在系统越来越复杂时，替团队看住“哪里最容易出事”。

当系统变成长任务，测试对象也变了

Anthropic 在 eval 文章里把一个核心问题讲得很透：没有评测体系，团队会在迭代中盲飞。OpenAI 在实践指南里也不断强调，要先有任务定义和基线，再谈自动化规模。AWS 的 agentic AI 安全指南则提醒得更直接，输入验证、权限收束和 guardrails 本身就应该被当成系统设计的一部分。

这些信息合在一起，指向的并不是“测试价值下降”，而是“测试对象变了”。以前很多团队测试的是一个页面或一个接口，现在越来越多团队测试的是一条任务链：它会不会误读目标，会不会误调工具，会不会在失败后继续错误执行，会不会在边界模糊时做出不该做的动作。

这已经不是传统意义上“跑一轮功能回归”就能覆盖的问题了。

测试的重心，会慢慢往前移

所以测试工程师真正的变化，不是整体消失，而是职责重心明显左移、也明显变厚。

  • 要学会把自然语言目标压成 eval case，而不是只等开发把功能做完再接手。
  • 要设计 verifier 和 grading 规则，而不是只看页面结果对不对。
  • 要引入异常样本、对抗样本和安全样本，而不是只验证 happy path。
  • 要读 trace、看 tool calls、查失败链路，而不是只盯最终输出。

如果把这个趋势讲得更直白一点，未来更值钱的测试工程师，会越来越像“评测工程师”和“质量系统工程师”的混合体。

哪些测试工作会先变得不一样

最先被压缩的，其实是那些高度重复、上下文要求低、判断空间小的测试环节。

  • 按脚本机械点击页面、重复执行固定流程。
  • 只做格式正确性确认，不参与成功标准设计。
  • 用例长期不维护，只在发布前最后执行一次。
  • 发现问题之后无法定位原因，只能把现象原样转回研发。

这些工作过去也很重要，但它们的共同特点是容易标准化，也容易被 AI 和自动化工具先吃掉。

反过来，更难被替代的测试能力会集中在另外一边：会设计高质量 eval、会补失败样本、会做安全边界校验、会搭 verifier、会解释一次异常到底是模型问题、工具问题还是流程问题。

结尾：测试不会退场，只会更靠近质量系统中心

我的倾向判断是：测试工程师不会先被替代，测试工程师会先被重写成更靠前、更靠系统的一类角色。被压缩的是机械执行层，被放大的则是质量定义、评测设计和失败治理。

所以如果你今天还把测试的核心价值理解成“多跑几轮”，那确实会越来越危险。但如果你开始把自己的位置理解成“替团队定义什么叫通过、什么叫越界、什么叫必须人工接管”，那这轮变化反而会把测试重新抬到软件组织的中轴线上。

更新附注

  • 版本：v1.1

更新日期：2026-04-01 更新原因：重写标题、首屏判断与结尾收束，把文章焦点进一步收拢到“评测、verifier 与放行规则”。