测试工程师别再卷自动化了：我面了37个人后，发现真正拉开差距的是这3件事

先交代背景。我在一家做B端SaaS的公司带测试组，产品日活大概8万，核心订单表MySQL 8.0里1.2亿行，Redis 7.2缓存，K8s 1.28跑着60多个微服务。2024年3月到5月，我面了37个测试工程师，从15k到35k的都有。面试题里我必问一道：“你上家公司自动化做了多少条？发现过多少线上问题？”结果挺有意思——说做了800条、1200条的人不少，但能说清楚“哪条用例抓到过哪个P0故障”的，只有4个。这4个人里，有2个后来拿了offer，另外2个被别的组抢了。我一开始也迷信自动化，2019年自己用Python+requests+pytest+allure搭了一套接口自动化，从300条干到1200条，每天Jenkins 2.414凌晨2点跑，钉钉机器人推报告。结果呢？线上事故没降，反而因为测试数据污染，误报率从5%涨到18%。后来我花了两周翻故障复盘，才发现真正的问题不在脚本数量。

我复盘了最近12个月的P0/P1故障，一共43个。按根因分类：需求理解偏差17个，占39.5%；边界条件漏测11个，占25.6%；测试数据/环境问题8个，占18.6%；代码自身bug 5个，占11.6%；其他2个，占4.7%。注意，自动化脚本能覆盖的主要是“代码自身bug”和一部分“边界漏测”，加起来不到37%。而需求理解偏差和数据环境问题，靠UI自动化或者接口自动化根本防不住。所以我的第一个独立观点是：测试工程师的核心竞争力，不是写脚本，而是“风险建模”。你得知道钱在哪、用户在哪儿、哪条链路一断老板会半夜打电话。比如我们那个SaaS，最核心的是“下单-支付-开票”链路，支付回调超时设置的是15秒，但微信支付实际重试是30秒一次，这个参数我在压测时用JMeter 5.6.3模拟过，发现如果回调处理超过15秒，订单状态会卡在“待支付”，而用户已经扣款。这种问题，你写1000条接口断言也测不出来，得靠对业务和第三方接口的理解。

第二个观点：信息压缩能力比自动化覆盖率重要。什么叫信息压缩？就是你能不能用最少的人天，覆盖最大的风险。我见过一个测试同学，每周写200条用例，但全是“输入正确的用户名密码，登录成功”这种。另一个同学，一周只写30条，但他把“优惠券叠加”场景拆成了：满减券+折扣券+品类券+运费券，4种券两两组合16种，再加上券过期、券被领完、券限新客、券限商品，用等价类和边界值压到9条。结果上线后，优惠券相关的客诉从每月12起降到2起。具体步骤：第一，拉取最近3个月客诉和故障，按模块排序；第二，用Excel做“风险矩阵”，横轴是发生频率，纵轴是影响金额；第三，只对“高频+高影响”的模块做自动化，其他的用探索性测试。我们当时的阈值是：影响金额>5000元或影响用户>1000人，才进自动化回归集。这个数字不是拍脑袋，是财务给的客诉赔付均值。

第三个观点：工程杠杆。测试开发不是让你去写一个测试平台，而是让你用最小成本解决重复劳动。比如我们组之前每次回归要手动造50个订单，每个订单要选商品、填地址、用优惠券，平均4分钟一个，200分钟没了。后来我用Python+faker+requests写了个脚本，直接调内部API造数据，参数化生成手机号：'13' + str(int(time.time()))[-8:] + str(random.randint(100,999))，注意要处理数据库唯一索引。脚本跑了3个月，节省了大概120人时。但我也翻过车：一开始用faker 19.0的phone_number()，结果生成的是美国号码，后端校验不通过，白白跑了一晚上。所以具体参数要跟着公司规则走。工具版本方面，pytest 7.4.4、requests 2.31.0、allure-pytest 2.13.2、Jenkins 2.414、Docker 24.0.7，这些是我2024年5月还在用的，稳定，没踩大坑。

再说一个对比：功能测试、自动化测试、测试开发、质量效能，这四个岗位到底差在哪？我做了个表，按每天8小时算：

注意，这不是绝对，但能看出：越往后，写代码时间越多，但沟通分析时间也越多。如果你只会写脚本，不会跟产品、开发、运维扯皮，那35岁确实危险。我面过一个32岁的候选人，自动化很熟，但问他“如果开发说这个bug改不了，你怎么办？”他回答“提bug单，等他们改。”这种答案，我基本不会给过。因为测试工程师的很大一部分工作，是推动问题解决，不是记录问题。

最后给一个可执行的7天诊断步骤，你可以直接抄： 第1天：拉最近3个月线上故障和客诉，按模块统计数量和金额，找出TOP 3。 第2天：找开发要代码提交记录，看哪些文件改动最频繁，通常bug也最多。 第3天：把现有自动化用例跑一遍，统计通过率、误报率、执行时长。如果误报率>10%，先修用例，别加新用例。 第4天：挑一个TOP 3模块，用等价类+边界值重新设计20条用例，手动执行，记录发现的问题数。 第5天：把第4天中稳定的、重复执行的用例写成接口自动化，用pytest+requests，断言用jsonschema，数据用fixture清理。 第6天：接入Jenkins，设置每天2:00跑，钉钉通知只发失败用例和报告链接，别发全部。 第7天：算ROI：自动化节省的人天 / 维护成本。如果小于1，就砍掉那些用例。

说实话，我到现在也没完全搞懂K8s的operator，但这不影响我带团队。测试工程师的边界在变，以前是点点点，现在要懂业务、懂数据、懂一点运维。但别被“测试开发”四个字吓到，大部分公司不需要你从零写平台，需要的是你能用现成工具解决具体问题。我面了37个人，最后发现，那些能讲清楚“我为什么做这个测试决策”的人，比能背出Selenium 4.15新特性的人，更容易拿到高薪。就这样，别卷自动化条数了，先卷卷你的风险判断。