测试工程师工作

凌晨两点，测试李然还在盯着屏幕上的工程测试报告。跑了六个小时的师工自动化脚本，挂了三个用例。测试其中一个报错信息写着“元素未找到”，工程另一个是师工“超时”，第三个干脆连日志都没打出来。测试他叹了口气，工程把第三个用例单独拎出来手动复现——结果一次就过了。师工这种“幽灵bug”最让人头疼，测试你没法跟开发说“它有时候会挂”，工程人家只会回你一句“我本地是师工好的”。

测试工程师的测试工作，外面的工程人看着就是“点点点”。我入行前也这么以为。师工真正干了三年才发现，点鼠标只是最表层的那一层皮。底下藏着的是对业务逻辑的理解、对系统架构的认知、对边界条件的敏感，还有跟开发扯皮时的那股子韧劲。

拿我上家公司的支付系统来说。需求文档写的是“用户余额不足时提示错误”。就这么一句话。但实际测试的时候你得想：余额刚好等于订单金额算不算不足？并发扣款时余额判断会不会出问题？负数金额传进去会怎样？浮点数精度丢失导致0.1+0.2不等于0.3怎么办？这些场景文档里一个字没提。你得自己画状态图，列等价类，把每个分支都跑一遍。跑完还要写SQL去数据库里对账，确认流水和余额变动一致。

自动化测试听起来高级，维护起来却是个体力活。页面改个按钮的class名，几十条用例集体报错。有段时间我们前端重构，我每天的工作就是改定位表达式。后来学乖了，把选择器抽成常量，页面对象模式重新封装了一遍。但新问题又来了——异步加载的元素，你永远不知道它什么时候出现。sleep(3)能解决百分之八十的问题，但剩下的百分之二十会让整个测试套件跑上半小时。最后换成显式等待，条件判断写了一大堆，代码量翻倍，可稳定性确实上去了。

性能测试又是另一回事。JMeter压测报告里TPS曲线突然掉底，你得判断是应用瓶颈、数据库锁、还是网络抖动。有一次我盯着Grafana面板看了四十分钟，发现GC日志里Full GC频率异常。调大堆内存后问题消失。但开发不认，说“你压测环境配置不对”。我只能把生产环境的JVM参数截图发过去，他才闭嘴。这种时候，测试工程师得比开发更懂运维。

最磨人的是回归测试。版本迭代快的时候，一周发三次。每次发版前要把核心流程跑一遍，手动的那种。登录、下单、支付、退款，循环往复。点到最后手指发麻，脑子却不敢走神——万一漏了某个分支，线上出事就是P0故障。有次我漏测了优惠券叠加场景，结果用户用两张满减券把订单金额砍到了负数。虽然没造成资损，但复盘会上被点名批评。从那以后，我养成了写测试清单的习惯，每一条都打勾，不凭记忆。

这行干久了，人会变得有点“多疑”。看到输入框就想试SQL注入，看到文件上传就想传个木马，看到接口返回就想改参数重放。朋友说我职业病，我觉得挺好。毕竟测试工程师的价值，就是在别人觉得“没问题”的地方，找出那个“万一”。

薪资方面，初级和高级差距很大。只会写用例、点页面的，在一线城市也就七八千。能搭自动化框架、做性能调优、搞持续集成的，两万起步。再往上走，得懂业务架构，能设计测试策略，甚至参与需求评审时提前拦截逻辑漏洞。我认识一个前辈，转行做了质量保障架构师，年薪六十万。他的日常是跟产品经理吵架，把不合理的验收标准怼回去。吵完再跟开发对齐单元测试覆盖率。听起来很爽，但背后是十年的代码积累和业务沉淀。

如果你刚入行，别急着学工具。先把HTTP协议搞明白，把数据库索引原理弄清楚，把Linux常用命令敲熟。这些底层的东西，比Selenium的API重要得多。工具会过时，但排查问题的思路不会。就像李然那个幽灵bug，最后发现是测试环境时钟同步出了问题。跟自动化脚本半毛钱关系没有。可你要是连NTP服务都不知道，查三天也查不出来。