测试这活儿，测试干久了真会怀疑人生。测试上周五我跑一个支付接口的测试回归，用例全绿，测试日志干净得像刚擦过的测试玻璃。结果呢？测试生产环境一上线，用户下单直接超时。测试后来查了半天，测试是测试测试环境里那个mock服务太“配合”了，返回延迟永远控制在50毫秒以内，测试而真实网关在高峰期要抖到2秒开外。测试你说这算谁的测试锅？

这事让我想起刚入行那会儿，带我的测试老张总爱说一句话：“测试不是证明没问题，是测试找问题。”当时觉得他装深沉，测试现在想想，这话糙理不糙。我们天天盯着断言、覆盖率、通过率这些数字，可数字不会告诉你——用户根本不会按你设计的路径点按钮。有一次我测一个上传功能，按规格文档把文件大小、格式、并发全测了个遍，全过。结果产品上线第二天，有人传了个带emoji的文件名，后端直接抛异常。我盯着那个报错看了半天，心里只有一个念头：这年头，连文件名都开始内卷了。

说回正题。测试这行当，最坑人的不是bug本身，是“你以为你测过了”。我有个习惯，每轮测试结束会问自己三个问题：我漏了什么？我哪里想当然了？我有没有被自己的惯性带着走？前阵子测一个优惠券分摊逻辑，我按业务规则写了二十多条用例，覆盖了满减、折扣、叠加、互斥。但有个场景——用户用积分抵扣后再申请退款，退款金额怎么算？我压根没往那儿想。后来是客服那边报了个工单，说用户退款金额对不上。我翻出代码一看，好嘛，积分抵扣的部分在退款时被重复计算了。这bug不复杂，但藏得够深，深到让我怀疑自己是不是只会照着需求文档“抄作业”。

测试做到后面，拼的不是手速，是心性。你得学会跟“不确定”共处。比如性能测试，压测工具报了个平均响应时间800ms，你觉得还行。可你换个网络环境试试？换个低端手机试试？真实用户手里的设备千奇百怪，有的安卓机性能烂得能让你怀疑厂商是不是在卖电子垃圾。我有个同事，专门拿自己三年前的老手机当测试机，他说这叫“真实用户视角”。虽然有点损，但确实能砸出不少问题。

还有个事儿，说出来可能有点玄乎。测试测久了，你会对代码产生一种“气味感”。不是闻味道，是看代码结构就能预判哪儿容易出bug。比如那种if套if套了五六层的函数，或者一个方法里塞了十几个参数还带默认值的，基本跑不掉。不是说我有多神，而是这类代码本身就意味着逻辑复杂、分支爆炸，人脑根本记不全所有组合。这时候别硬扛，老老实实写个随机测试或者用属性基测试去扫，比手工点点点靠谱多了。

最后说点实在的。测试报告这东西，写给别人看的时候，别光贴一堆绿色勾勾。我现在的习惯是，每条用例后面加一栏“我为什么这么测”，把业务场景、风险点、甚至当时的怀疑都写进去。刚开始觉得麻烦，后来发现，这玩意儿比用例本身值钱。因为三个月后你再回头看，光看步骤根本想不起当时在防什么，但看看备注，思路一下就接上了。测试这活儿，说白了就是跟健忘和马虎作斗争——包括自己的健忘，自己的马虎。