我入行软件测试，软件纯属误打误撞。测试大学学的工程是信息管理，毕业那年互联网公司来校招，师自简历投了开发岗被刷，介绍HR看我逻辑还凑合，软件问我愿不愿意做测试。测试我当时连测试用例是工程什么都不知道，就点头了。师自第一份工作是介绍在一家做 ERP 的外包公司，每天对着密密麻麻的软件采购单、库存表点鼠标，测试点得我怀疑人生。工程

真正让我对测试改观的师自，是介绍一次线上事故。凌晨两点，客户打电话说库存数据对不上，财务系统直接锁死。运维拉日志，开发查代码，最后定位到一个字段类型转换的 bug——数据库里存的是字符串“100”，代码里当成整数做加法，结果 100 加 50 变成了 10050。开发修复只用了一分钟，但数据要回滚，账要重算，客户那边十几个仓库停摆了一整天。那个 bug 其实在测试环境完全能复现，只要我在“数量”输入框里敲一个带引号的数字。但我没测，因为测试用例里写的是“输入正常数字”，我照着执行，没想过要打破砂锅问到底。

从那以后我明白一件事：测试不是照着脚本点鼠标，而是要想办法把系统“搞坏”。我开始学着把自己当成一个恶意的用户，专门挑那些“正常人不会那么操作”的路径去试。比如注册页面，别人输入正确的邮箱，我偏要输入带空格的；别人点一次提交，我偏要连点十次；别人用鼠标，我偏要用 Tab 键把页面上的按钮挨个走一遍。后来我发现，很多崩溃都是这么逼出来的。

干了三年，我跳槽去了一家做支付接口的创业公司。那边测试环境极其简陋，没有自动化框架，全靠手工。我接手了一个对接银行网关的项目，对方银行给的文档模棱两可，测试数据只有一组成功的样例。我没法在测试环境造出“余额不足”“卡已冻结”“交易超时”这些异常场景，只能去读银行那边返回的错误码文档，自己写了个小工具，模拟各种返回报文，硬是把异常分支全跑了一遍。上线第一个月，线上收到的支付异常工单是零。那是我第一次觉得，测试的价值不是“找出了多少个 bug”，而是“让某些 bug 根本不可能发生”。

当然，手工测试有天花板。我后来学了 Python，自己写接口自动化脚本，把重复性的回归测试交给机器。但我不迷信自动化——有些东西机器测不出来，比如页面加载时那个一闪而过的错位，或者用户点击按钮后那种微妙的卡顿感。这种体感层面的问题，只能靠人坐在电脑前，一遍一遍地点，一遍一遍地看。所以我的工作习惯是：自动化跑主流程，手工去摸边角料。

现在如果有人问我测试最重要的是什么，我会说是“怀疑的直觉”。这种直觉不是天生的，是靠一次次线上事故、一次次和开发争论“这到底算不算 bug”练出来的。开发觉得“用户不会这么操作”，我说“用户比你想象的更懒也更蠢”；开发说“这个概率太小了”，我说“线上几万笔交易，小概率就是必然”。

测试这行，门槛不高，但做好很难。难在你要时刻跟自己的惰性对抗——明明跑了十遍没问题，第十一遍还要不要跑？难在你要跟开发的情面对抗——明明关系不错，但该提的 bug 还是得提。可正是这些“难”，让这个岗位有了不可替代性。我不觉得测试低人一等，反而觉得，能在一个系统上线前拦住那个能让人破产的 bug，比写出一万行代码都带劲。