代码写不过 AI,那就做它替不了的那件事:2026给测试的 3 条活路

上周有位读者发来一段话：做了三年功能测试，日常工作就是照着用例点，越点越慌，觉得 AI 正在加速把自己挤出去。末尾问了一句——还能怎么办。

这不是他一个人的问题。我在测试这行待了十来年，从全靠手点到半自动化，再到今天 AI 铺进流程，每一轮技术换代都带走一批人，也托起一批人。

带走的和托起的，差别不在会不会用新工具，而在工作里还剩多少是别人拿不走的部分。

所以真正要回答的是：你站在哪一边。

下面三条路我都见过有人走通，不是理论推演，是可以照着做的。

这是起步最省力的一条，但也是天花板最高的一条。

道理很朴素：模型再聪明，也不清楚你们公司那笔交易为什么不允许退款，不知道某个字段填错会顺着哪条链路污染下游。这类知识不写在公开文档里，它长在需求评审的争论里、长在上一次事故的复盘里、长在老员工一句「这里历史上改过」里。

换句话说，业务理解是你和 AI 之间最厚的一道墙。

我认识一位做金融测试的朋友，编码能力谈不上出众，但支付清算的每一个环节他都能从头讲到位。后来他跳到一家头部互金公司，薪酬涨了接近一倍。原因不复杂：懂这块的人太少，从零带一个新人至少要半年，而他入职当天就能接需求。

这条路怎么走：

选定一个行业（金融、电商、医疗、教育都行）长期扎下去

把主流程连同所有分支画成脑图，直到能默背

沉淀只有这个行业才会遇到的测试场景

让简历上写的是「五年电商测试」，而不是「五年测试」

代码可以被生成，但你坐在产品经理对面问出那句「这个场景线上真会发生吗」，暂时还生成不出来。

如果你不排斥写代码，这条路相当稳。

单纯的手工执行正在被压缩，但工具与平台侧的缺口反而越开越大。几乎每个团队都需要有人搭框架、写自动化脚本、维护流水线。

这里的核心竞争力不是代码量，而是你让团队省下了多少时间。

举个小例子：一条回归用例手工跑三十分钟；用 UI 自动化重写一次，往后每次三分钟；再顺手做一个造数工具，原来配一套数据要一小时，现在点一下就好。

老板不会因为你写了几千行代码给你加分，他只会记得这个季度发布没再通宵。

这条路怎么走：

先固定一门语言，Java 或 Python 二选一，别两边都浅

掌握接口测试工具（Postman、JMeter）

写一个方向上的自动化脚本（Web 选 Selenium，移动端选 Appium 或 Espresso）

进阶：了解持续集成，也就是每次提交自动触发构建和测试的机制，常用 Jenkins、GitLab CI

提醒一句：不需要成为算法专家，能交付别人真在用的工具就够了。

这条路想象空间最大，也最容易被误解。

我指的不是「让聊天机器人帮忙写几条用例」——那已经属于基本功，不产生溢价。我指的是这几件事：

用 AI 批量造测试数据，替代人工配比

用 AI 读日志，从几十万行里快速锁定异常片段

用 AI 做回归筛选，只跑本次改动真正影响到的功能

用 AI 做缺陷预测，提前标出高风险模块

这几项在招聘市场上都还属于稀缺技能。

我带过一个测试，把自己每天重复的操作列成清单，写了个 Agent——一种能按步骤自主完成任务的小程序，自动登录系统、跑检查项、出日报。原本每天要占掉一小时，现在完全不用管。他不是什么高手，只是比同事多花了两个周末去研究。

这条路怎么走：

先把 AI 当副驾驶：写用例、读日志、造数据、润色报告

学会写提示词，知道怎么约束输出格式

进阶：了解 RAG，也就是先检索相关资料再让模型作答，减少胡编

再往上：用模型 API 拼一些自己的小工具

同样不需要推导公式，不需要训练模型。会用，就已经领先一大截。

直接给结论：

三条并不互斥。比较理想的组合是：业务理解打底，AI 用来提效，能力往测试开发那一侧靠。

如果实在不知道从哪开始，有个笨办法——把上周的工作按耗时排个序，挑最占时间那件事，问自己它能不能被工具或模型替代掉一半。能，就从那里开始。

关于「AI 会不会取代测试」的焦虑，我听过太多次。但每一轮技术换代里被清出局的，从来不是某个岗位名称，而是始终不肯挪动的那批人。

AI 时代测试工程师的价值没有归零，只是换了位置：从按脚本执行，变成设计验证方案、判断风险取舍。现在要做的不是反复确认自己会不会被淘汰，而是从上面三条里挑一条，走起来。

既然看到这里了，如果觉得有用，随手点个赞、在看、转发三连吧。

THANKS FOR READING