我叫陈默，测试干测试这行已经八年了。工程入行那年，师自公司服务器托管在一个小机房里，介绍夏天温度能飙到四十度，测试我们管那叫“桑拿房”。工程现在回想起来，师自那会儿的介绍测试远没现在这么“讲究”——没有自动化框架，没有CI流水线，测试全靠手工点鼠标，工程点得多了，师自手指头都磨出茧子来。介绍

我入行是测试因为一个bug。大学那会儿帮老师做教务系统，工程我负责写学生选课模块。师自上线第一天，三百多人同时选课，系统直接瘫了。数据库死锁，页面白屏，后台日志刷得跟瀑布似的。老师急得满头汗，我蹲在机房角落里，把SQL一条条拎出来看，最后发现是索引没建好，全表扫描把数据库拖垮了。那次之后我就想明白一件事——代码写出来不是终点，它得能在真实环境下扛得住事。测试，就是给代码“扛事”的机会。

后来我正式做了测试工程师，发现这活儿比想象中复杂。别人觉得测试就是“找茬”，其实不然。真正好的测试，得先理解业务逻辑，再琢磨技术实现，最后还得预测用户会怎么“乱来”。我有个习惯，拿到新功能，先不急着写用例，而是去翻产品经理的原始需求文档，再跟开发聊两句，看看他们有没有藏着掖着没说的边界情况。有一回，开发说“这个接口超时重试三次就行”，我问他“重试之间要不要退避？并发时会不会同时重试？”他愣了几秒，说“你比我想得周全”。

这些年我踩过最大的坑，是过度依赖自动化。那阵子我特别迷恋写脚本，把回归测试全用Python重写了，跑起来确实快，省了不少时间。可后来有个版本，界面改动特别大，自动化脚本全废了，还得回头手工测。那两周我天天加班到半夜，才意识到——自动化和手工测试不是替代关系，是互补。脚本适合处理重复性高、结果可预期的场景，但真正难搞的，往往是那些“没想到”的意外。比如用户上传了一个0字节的文件，或者网络断了一秒又连上，这种场景靠脚本是模拟不出来的，得靠人脑去“钻牛角尖”。

现在我做测试，更关注“边界”和“异常”。边界是数据上的，比如金额最大能填多少？字符长度超了会怎样？异常是状态上的，比如用户点了两次提交？支付回调延迟了？这些地方最容易出问题，也最考验测试的耐心和想象力。我有个习惯，测一个新功能前，先列一份“用户蠢操作清单”——把能想到的傻操作全写下来，然后挨个试。什么连续点击、快速滚动、切后台再切回来、手机横竖屏切换，这些看起来“不正经”的姿势，往往能暴露真正的问题。

有同行问我，测试这么枯燥，你怎么坚持下来的？我笑着说，你见过用户因为一个贴心提示而发来感谢邮件吗？我见过。有个老用户，用我们的记账软件三年了，有次我测出一个汇率计算的小误差，修掉之后，他在应用商店写了长长一段好评，说“终于不用自己拿计算器对了”。那一刻我觉得，测试不只是找bug，是在替用户把好最后一道关。那些藏在细节里的踏实感，比写多少行代码都有成就感。

测试这行，门槛不高，但天花板很高。有人觉得是“点工”，有人觉得是“保障”，我倒觉得，它更像一个翻译官——把用户的需求翻译给开发听，把系统的脾气翻译给用户懂。这条路，我还想走很久。