上周和几个测试经理吃饭，一桌子人菜没怎么动，全在聊一个话题：团队还要不要养那么多测试执行的人。
起因是有个朋友的公司，研发团队开始全面接入 AI 编程助手，顺带试了用大模型直接生成接口测试用例和自动化脚本。结果发现，以前需要两个中级测试工程师干三天的回归测试，现在一个实习生点几下鼠标，一个下午就跑完了。而且覆盖率报告、缺陷分析自动出，连 bug 单都帮你写好。
那个朋友说了一句很扎心的话：“我现在看着工位上那些还在手动写用例、逐条点页面的兄弟，后背发凉。”
类似的事情不是个例。从去年下半年开始，测试社区里“被优化”“被转岗”的帖子明显多了起来。很多人突然意识到：当大模型不仅能写代码，还能自己验证代码的时候，“测试”这个岗位，似乎正在被重新定义。
这篇文章，我想把这件事的技术本质拆开来看，把焦虑变成理解，把理解变成可操作的方向。
目录
一、裁员名单上的“测试”与正在发生的逆转
二、测试的本质，从来不是“找Bug”
三、大模型“自测”的工程内核：一个闭环是怎样建成的
四、同一需求，两种解法：传统路径 vs AI自主测试
五、测试工程师的新护城河：从“执行”到“决策”
六、你现在的系统，真的经得起“被自测”吗？
一、裁员名单上的“测试”与正在发生的逆转
过去十年，测试岗位经历过几轮冲击：自动化测试说要消灭手工测试，没消灭完；云测平台说要替代本地执行，也没替代完。但这一次，风向真的变了。
变化的核心不是“自动化”，而是“自主化”。
以前的自动化测试，本质上是一种确定性规则执行：你告诉它输入什么、预期什么，它跑完告诉你过还是不过。脚本是人写的，逻辑是人设计的，断言是人定义的。工具只是手脚，大脑还是人。
现在的大模型不一样。它能直接阅读产品需求文档，自行推断出测试场景，生成对应的测试数据，写出可执行的代码，运行后分析日志，发现异常后还能自动聚类失败原因，甚至给出修复建议。
这就是一个初级的、不完美的但确实在运转的“测试闭环”。在这个闭环里，人的位置第一次显得有点尴尬——因为你不再是被替代的手脚，而是大脑也开始被局部替代。
但这就是结局吗？我倒觉得，这恰恰是测试这个岗位真正专业化的开始。
当AI能完成80%的执行工作时，那20%的风险决策才是你的核心价值。
二、测试的本质，从来不是“找Bug”
很多测试人被裁的时候想不通：“我明明每天在认真找bug啊。”
问题恰恰出在这里。如果你把测试等同于“找bug”，那你确实很容易被替代，因为大模型找bug的能力正在指数级增长。它能一天跑几十条探索性路径，能在毫秒级内判断返回值的合法性，能把边界组合穷举到人根本想不到的量级。
但测试的本质，根本就不是“找bug”。
工程上，测试的核心职能是质量风险管理。这句话说起来简单，拆开三层含义就清楚了：
风险识别：这个系统的质量风险到底集中在哪些地方？不是所有功能都值得测，不是所有bug都值得修。资源永远有限，测试的第一要务是回答“测哪里、测多深”。
风险决策：测出来的这些问题，哪些可以上线后再修，哪些必须上线前修复？谁来做这个权衡？谁来承担拍板的后果？
风险预防：怎么让类似的问题下次不出现？是流程要改，还是架构要做防御性设计？测试策略怎么跟着版本演进？
这三件事，大模型一件都做不了。它只能在你划定好的风险边界里高效地“跑腿”，但它无法定义边界，更无法承担责任。
很多初级测试工程师之所以感到焦虑，不是因为AI太强，而是因为过去的工作内容里，真正涉及质量风险管理的部分太少，而纯执行的部分太多。
三、大模型“自测”的工程内核：一个闭环是怎样建成的
光讲概念不够，我们进到技术实现层面，看看大模型“自己测自己”到底是怎么跑起来的。你可以把市面上那些AI测试工具看作一个自主测试Agent，它的架构核心其实相当工程化。
用一张图把它的运行逻辑画出来：
这个流程不是一次性跑完的，它天然支持多轮迭代。比如失败分析Agent发现某个接口总是超时，它可能会自主决定生成一批带不同参数的超时场景，回去再压一轮，确认是不是系统性的性能瓶颈。
把这个架构拆开看，它实际上由四个关键的工程模块支撑：
第一，上下文工程。 大模型不是凭空知道被测系统长什么样的。它需要通过RAG或提示词注入，获得接口文档、数据库Schema、历史缺陷记录、业务规则等上下文。上下文的质量直接决定生成用例的精准度。
第二，工具使用。 测试Agent需要调用真实的测试执行环境——可能是API测试工具、UI自动化框架、命令行、数据库客户端，甚至是k8s的调试端口。模型要能按需调用这些工具，并且能解读工具返回的结果。
第三，记忆与状态管理。 长任务执行过程中，需要记住哪些场景已经测过了，哪些发现是新的，上下文有没有溢出。这涉及到向量数据库、摘要压缩等记忆机制。
第四，反思与纠错。 跑出来的结果不一定是真bug，可能是环境问题、用例设计偏差、断言过严等。一个好的自测Agent需要具备对自身产出的反思能力，比如分析失败原因是SUT问题还是测试本身问题，并自我修正。
这里面每一项，做到80分容易，做到95分极难。而恰恰那5分的差距，就是不同团队拉开距离的地方。
四、同一需求，两种解法：传统路径 vs AI自主测试
为了让你更有体感，我拿一个真实的小需求来对比。
需求：“用户下单接口，当库存不足时返回错误码20001，并记录一条库存不足的订单日志。”
传统测试路径：
测试工程师阅读需求，手工拆解出正常场景、库存为0、库存负数、库存刚好够但并发下可能超卖等场景。
在用例管理平台上逐条编写用例，写明前置条件、步骤、预期结果。
部署测试环境，准备测试数据（比如制造一个库存为0的商品）。
手工或用脚本调用接口，人工比对返回值和数据库日志。
发现问题后，自己判断是bug还是测试数据问题，然后提bug单。
全程耗时约4-6小时（熟练工）。
AI自主测试路径：
产品经理直接在需求平台里把描述写好，测试Agent自动拉取。
Agent结合历史缺陷数据判断出“库存”是高风险字段，自动生成12条测试用例，涵盖边界值、负数、并发、数据类型异常等。
调用测试执行环境，自动准备数据（构造库存为0的记录），执行用例，收集返回值和数据库写入。
发现两条用例失败：一条是库存负数时接口返回了20000而非20001；另一条是并发场景下，日志记录的订单号串行出现重复。失败分析Agent判断前一条是真bug，后一条可能和数据库事务隔离级别有关，标记为需人工确认。
自动生成缺陷报告，把两条失败的堆栈、复现步骤、相关日志关联到需求单下，并@对应的开发。
全程耗时约20分钟，人只需花15分钟处理那条“需人工确认”的case。
差距肉眼可见。但请注意，在这套流程里，人并没有消失，只是换了战场——从原来的“手工验证者”变成了“风险审查者”和“策略制定者”。你要判断AI用例设计是否合理，要拍板那条并发日志重复到底算不算bug，你要决定这种程度的自测能不能覆盖线上的风险。
你的价值，不在执行的链条里，而在决策的节点上。
测试工程师的未来身份，不是操作工，而是质量体系的风险操盘手。
五、测试工程师的新护城河：从“执行”到“决策”
那具体怎么转型？我从工程落地角度给三个方向，每个都能直接指导学习路径。
方向一：测试架构与模型验证能力
当AI生成大量测试资产后，谁来验证这些用例的充分性？谁来判断生成的覆盖率报告是否有意义？这需要测试架构能力——设计合理的分层测试策略，定义何谓“测过”、何谓“测好”。在校生和初级工程师最容易上手的切入点是学习如何评审AI生成的测试资产，而不是自己去造轮子。
方向二：质量度量与风险建模
AI能输出一大堆结果，但没法告诉你“这个版本能不能发”。发版决策是基于风险量化的。你需要掌握质量度量模型、缺陷逃逸分析、发布风险评估等方法。这种能力，学校里不教，工作中又极度稀缺，正是中级工程师向上突破的关键。
方向三：AI测试基础设施搭建
别只当工具的使用者，要当自己团队AI测试能力的构建者。这涉及到上面说的上下文工程、工具链设计、记忆与反馈回路搭建。谁能为团队搭建起一个运转有效的自测Agent，谁就是不可替代的核心骨干。
你发现没有，这三个方向都没有要求你成为算法工程师，也没有要求你转行做开发。它们是在原有的测试知识体系上，叠加一层工程化和系统化的思维训练。缺的，从来不是天赋，而是一套系统性的新知。
六、你现在的系统，真的经得起“被自测”吗？
最后我们回到那个餐桌上的焦虑。朋友们问我：你是不是在劝测试转行？
我的回答一直没变：劝的不是转行，是转念。
大模型“自己测自己”的时代确实来了，但它暴露的不是测试这个岗位没有价值，而是过去那种只做执行、不做思考的工作方式没有价值。
接下来几年，测试团队一定会大幅缩编，但留下来的每个人，都必然具备一种能力：能够设计一套让AI稳定输出质量的体系，并能为这个体系的输出结果负责。
我留一个问题给你，也欢迎你在评论区告诉我你的真实判断：
你们现在的系统，如果明天就用AI自主生成和执行测试，你敢不敢不经人工复核就直接采信它的结论？如果不能，卡住你的那件事，具体是什么？
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
