测试工程师干了三年才想明白：写用例和写代码都不是最难的

刚入行那会儿，我满脑子都是“测试没前途，得转测开”。于是天天学Java、刷LeetCode、背测试框架源码，以为这样就能摆脱“点工”的帽子。结果真开始做测开以后，发现自己只是从“手工点按钮”变成了“写脚本点按钮”。2022年我们组搞了一套UI自动化平台，跑了三个月才发现：最稳定的用例不是写得多好，而是前端压根没改过那种。业务迭代一快，你的脚本天天红，修脚本的时间比重写功能还长。后来我想想，是不是我们一开始就把问题问错了？测试工程师的分界线从来不是“会不会写代码”，而是你能不能让系统按照你的意志“不那么听话”地工作。

手工测试被污名化，但真正的脏活累活没人肯干

现在社区里都吹“测开是技术天花板”，很多公司招聘要求上写“必须熟悉Java/Python/Go，有工具开发经验”。可你去看那些大规模复杂系统，比如分布式事务、支付对账、权限体系，真正把它们测透的往往还是那帮老测试——他们就靠一张脑图、一个Excel表、一肚子业务脏数据。我同事做过一个极端case：为了复现线上偶发的用户余额负数，她翻了两年前的数据库备份，找到了一批被逻辑删除的充值记录，手工拼出时间线才还原出触发条件。这个场景你要用自动化，第一步就没法建模，因为触发条件是“运营在某天上传了一个格式错误的CSV，且碰巧用户在那之前改过手机号”。这种案例我经历得多了之后，反而对那些“每天跑几百条自动化用例”的人产生怀疑：你跑得再快，有没有验证过系统在“不该工作的时候”是什么表现？

测试开发是给懒惰的机器服务，还是给真实的用户服务？

我见过最荒诞的项目，测试团队花了半年搞了个全流程自动生成测试报告的框架，报告里能自动截图、自动归档、自动发邮件，仪式感拉满。但核心的“测试数据构造”环节还靠人工往Excel里填，而且因为框架要求数据必须符合特定格式，导致很多真实场景的异常数据根本塞不进去。测试工具越建越厚，测试思维却越来越薄。这个问题根源在于我们把“效率”当成了指标，把“覆盖率”当成了目的。我自己的教训是：与其花一周封装一个“优雅”的断言库，不如花一下午把那个最烦人的定时任务跑完，然后手动把系统时间调慢两分钟，看看会发生什么——很多bug就是这么来的。2019年我们做过一次统计，线上严重缺陷里有38%都跟时间、状态、权限边界有关，而这些场景自动化用例覆盖率只有7%。为什么低？因为脚本写起来太麻烦，而且产品经理觉得“正常用户不会这么操作”。可现实是，正常用户也会把手机时间自动同步关掉。

我心目中“全新”的测试工程师能力模型：破坏性想象

如果说写代码是“建设性逻辑”，那测试工程师真正的核心能力是“破坏性想象”——你要在脑子里预演系统什么时候会失效，失效之后要以什么样的姿势难看地崩掉。这种能力没法靠背诵RFC或者刷并发题获得，它来自你对人性和概率的感知。举个例子：你测试一个注册功能，想到密码长度限制、强弱校验、数据库唯一索引都不算本事；你想到“用户会在密码框里粘贴一串带换行符的文本，而前端刚好把换行符trim了，但后端没trim，最后导致密码明明输对了却登不上去”——这才叫本事。这种case不需要高深代码，需要的是“怀疑一切的日常感”。我甚至觉得，一个好的测试工程师应该具备一种“心理猥琐状态”：不停反问“如果我是骗子、loser、焦虑的用户，我会怎么乱搞？”这个状态没法被AI替代，因为大模型擅长生成合理的东西，却很难主动生成“基于真实人性的无理操作”。

对行业的一点不合群建议：别急着卷自动化，先学会手测失效模式

如果你是个刚入行的测试，别听那些培训机构一上来就让你学Selenium、学性能测试。我觉得你最好先干三件事：第一，把一个最简单的登录功能手动测至少100遍，每次用不同的输入顺序、粘贴内容、网络状态、重复提交次数，然后把每次的“先决条件”详细记录下来，你会发现很多你以为的“随机bug”其实全都有固定的前置组合；第二，把你们系统里所有与时间和金额相关的枚举值找出来，比如超时时间、重试次数、积分折算比例，然后挨个去问产品经理“为什么是5秒不是3秒，为什么是100次不是99次”——大部分人会卡住，而卡住的地方就是缺陷种子；第三，从明天开始，每天强迫自己提一个“非正常用户行为”的缺陷单，不用担心被打回，被打回来你就追着开发问原因，问多了你就知道他们默认做了多少“正常限位”。至于测开工具，那是你打破头之后才需要的东西。我做了三年测试，到现在我还是会手工去改数据库某个字段，然后看界面会不会乱码——这个动作虽然很low，但昨天还真帮我抓到了一条线上超过48小时的脏数据。

总而言之，测试工程师真正值钱的不是“更快的完成测试”，而是“能想到别人从未期待过的失败方式”。这个行业被“测开热”带偏太久了，以至于大家忘了测试的初衷——我们不是来证明系统能跑的，我们是来证明系统会怎么坏的。