上周面了六个测试工程师，测试能写自动化脚本的工程有四个，但问到“如果让你从零搭建一套接口测试框架，师招你会怎么设计”时，测试只有一个人能说清楚数据驱动和关键字驱动的工程区别。剩下五个的师招回答基本是“用Postman调通就行”。这行缺人吗？测试缺。但缺的工程不是点点点的功能测试，是师招能扛住质量底线的工程师。

我做了八年测试，测试待过创业公司也待过大厂。工程招聘网站上挂出去的师招JD，十份里有八份写着“熟悉Selenium、测试Appium、工程JMeter”，师招实际到岗后干的活是写用例、提bug、跟开发扯皮。这不是招聘，这是凑人头。真正需要测试工程师介入的场景，往往出现在项目中期——接口联调频繁报错、回归测试跑一遍要两天、线上偶尔冒出个脏数据没人说得清来源。这时候你再招人，黄花菜都凉了。

说个具体案例。去年我负责一个支付网关的重构项目，开发团队十二个人，测试只有两个。其中一个还是刚转岗的应届生。上线前三天，发现退款接口在并发场景下会重复扣款。怎么发现的？不是靠自动化脚本，是那个应届生手动构造了二十组异常参数，一组一组试出来的。他不懂什么测试金字塔，但他知道“钱的事不能靠猜”。后来我把他招进了现在的团队。学历一般，但值。

招聘测试工程师，我通常不看简历上写了多少工具。看什么？看他怎么描述最近一次发现的bug。如果他说“登录功能有问题”，直接pass。如果他说“弱网环境下，token过期后重新登录，购物车数据会丢失，原因是本地缓存没清”，这个人至少知道测试的颗粒度在哪。再问他一句：这个bug你提给开发的时候，附了哪些信息？能说出“操作步骤、日志截图、复现概率、影响范围”的，基本可以约二面。

自动化能力当然要考。但我不会让他现场写代码。我给他一个登录接口的文档，让他口述测试用例设计。有人上来就说“正常登录、密码错误、账号不存在”，没了。有人会补上“SQL注入、超长字符、并发同一账号、token有效期边界”。后者不一定写过多少脚本，但他脑子里有张网。这张网比会调Selenium API值钱得多。

性能测试也是重灾区。很多候选人简历写着“精通JMeter”，问TPS和响应时间的关系，答“TPS越高越好”。再问“如果TPS上不去，你怎么排查”，就卡住了。我遇到过一个小伙子，他说先看线程组配置，再看服务端连接池，最后查数据库慢查询。他还补了一句：“有时候是压测机自己的网卡打满了，别问我怎么知道的。”这种人，我当场就发了offer。

测试工程师的招聘，本质上是在找一种思维方式。能不能把模糊的需求拆成可验证的断言，能不能在开发说“这不是bug”的时候拿出证据链，能不能在版本发布前说“这个风险我担不了”。这些没法写在JD里，但面试的时候聊二十分钟就能感觉出来。

如果你正在招测试，别只盯着工具列表。问他最近一次跟开发吵架是因为什么，问他有没有主动删过自己写的用例，问他线上出故障时第一反应是什么。答案比证书实在。如果你正在找测试工作，别背面试题了。去翻翻你提过的bug记录，挑三个能讲清楚前因后果的，比什么都强。

这行不缺人，缺的是把质量当回事的人。