上线前三天，测试实战支付模块的测试实战回归测试全绿。我盯着屏幕上的测试实战通过率，心里那点不安被压了下去。测试实战结果第四天凌晨两点，测试实战运维在群里甩了张截图：订单状态卡在“待支付”，测试实战用户点一次扣一次库存，测试实战钱没进来，测试实战货先没了。测试实战后来复盘，测试实战问题出在一个极边缘的测试实战分支——优惠券叠加跨境汇率换算时，金额精度丢失，测试实战前端四舍五入显示正常，测试实战后端入库直接截断。测试实战测试用例覆盖了优惠券，测试实战也覆盖了汇率，偏偏没覆盖两者同时发生。

这就是测试最操蛋的地方。你永远不知道漏掉的是哪条路径。教科书教你等价类划分、边界值分析，实际项目里真正杀死你的，往往是两个正常功能交叉后的异常组合。我后来养成个习惯：每写完一组用例，强迫自己问一句——“如果这两个条件同时成立呢？”这招不保证万无一失，但至少能把半夜被叫醒的概率砍掉一半。

说个具体的。去年做电商App的购物车模块，需求文档写的是“商品数量上限99件”。按常规思路，测99、测100、测0、测负数，完事。但我多看了一眼数据库字段——quantity int(2)。int(2)最大存99，没问题。可如果运营后来搞活动，临时把上限调到150呢？DDL一改，代码没同步，插入直接报错。我把这个隐患标在测试报告里，开发顺手把字段改成了int(4)。没出事故，但这种事你赌不起。

测试用例不是越多越好。我见过一个团队，登录功能写了200条用例，连“密码框输入火星文”都覆盖了。结果呢？真正导致线上事故的是第三方登录回调超时没处理。200条用例里一条都没提。精力是有限的，得砸在刀刃上。我的判断标准很简单：这个功能挂了，用户会不会骂娘？会，就往死里测。不会，抽测核心路径就行。别拿覆盖率当KPI，那玩意儿骗自己用的。

自动化测试也一样。别一上来就追求全量覆盖。先把冒烟测试跑通，再把高频回归的用例自动化掉。我见过最离谱的，一个创业团队花了三个月搭自动化框架，结果产品迭代太快，脚本维护成本比手动测试还高。自动化是手段，不是目的。能用手点三分钟搞定的事，别写半小时脚本。

还有一点，测试环境的数据要脏。干净数据跑出来的通过率没有意义。真实用户的数据什么样？手机号带空格、地址里有emoji、商品名夹杂生僻字、并发请求下同一个用户点了两次提交。我习惯在测试库里故意塞一批“脏数据”，每次跑用例都带着它们。刚开始开发嫌烦，后来线上出了次乱码事故，他们主动来找我要这批数据。

最后说个心态问题。测试不是找茬，是排雷。开发写完代码，你跑过去说“你这有bug”，他第一反应是防御。换个说法：“这个场景下用户可能会这样操作，你看要不要处理一下？”效果完全不一样。我干了八年测试，最大的收获不是发现了多少bug，而是学会了怎么让团队愿意一起把质量扛起来。一个人盯不住所有角落，但一群人互相补位，漏网之鱼就少得多。

凌晨两点那件事之后，我在工位上贴了张便签：“你漏掉的，用户一定会帮你找到。”到现在没撕。