上周三凌晨两点，测试笔记我盯着屏幕上那条刺眼的测试笔记红色报错，心里只有一个念头：这破测试用例又骗了我。测试笔记

事情很简单。测试笔记一个支付回调接口，测试笔记测试环境跑了三十遍都正常，测试笔记预发布环境也过了。测试笔记上线后第二天，测试笔记财务那边发现有三笔订单状态卡在“处理中”，测试笔记用户钱扣了，测试笔记订单没变。测试笔记我翻日志，测试笔记回调确实进来了，测试笔记参数也对，测试笔记但业务逻辑就是测试笔记没执行。最后定位到问题：预发布环境的Redis集群配置和线上不一致，导致分布式锁在线上没释放，后续请求全堵在锁上。测试环境里锁超时设了30秒，线上是5秒。没人改过这个值，它是从配置中心拉下来的——测试环境和线上用的是两套配置。

这就是测试笔记要记的第一件事：环境差异比代码bug更阴险。你写再多断言，跑再多覆盖率，环境一变，全白搭。后来我养成了一个习惯，每次上线前，把测试环境、预发布、线上三套配置的diff打印出来，逐行扫。Redis超时、线程池大小、重试次数、超时时间——这些数字看着不起眼，出事就是大事。

再说个反直觉的。很多人觉得测试用例写得越细越好，步骤越具体越稳。我不同意。

去年我接手一个老项目，前任留下的测试用例有八百多条，每条都写得像操作手册：点这个按钮，等三秒，输入这个值，再点那个。结果呢？前端改了个按钮ID，三百条用例全挂。维护成本比写新功能还高。我后来把那些用例全删了，只保留核心业务路径的十二条，剩下的改成接口层校验和关键数据断言。跑得快，改得少，漏测反而少了。因为真正会出问题的，从来不是“按钮点不点得动”，而是“钱扣了订单状态对不对”。

测试的粒度是个玄学。太细了，你维护不起；太粗了，你抓不住bug。我的经验是：把测试写在业务逻辑的边界上，而不是UI的像素上。比如一个优惠券核销，别测“点击核销按钮后弹窗文案是不是‘成功’”，测“核销后数据库里券状态从1变2，且同一用户不能重复核销”。前者前端一改就废，后者只要业务规则不变，跑三年都不用动。

还有件事挺有意思。我见过不少团队，测试报告写得漂漂亮亮，通过率99.8%，结果上线还是出问题。为什么？因为那0.2%的失败用例被“已知问题”标签盖住了。人天生倾向于忽略小概率，但线上事故往往就藏在那0.2%里。我现在带人，要求很直接：失败用例要么修，要么删，不许标“已知”。标了就等于埋雷，哪天炸了都不知道怎么死的。

最后说个我自己的教训。有次我写了个自动化脚本，每天定时跑全量回归，跑了三个月没出过问题。我飘了，觉得这套东西稳了。结果第四个月，脚本里一个依赖的第三方接口改了返回格式，脚本没报错，因为它只判断了HTTP状态码200，没校验body。那一个月里，所有回归都是假通过。发现的时候，线上已经积了一堆兼容性问题。

所以现在我的测试笔记里多了一条：任何自动化校验，必须包含数据断言，不能只看状态码。状态码是给机器看的，数据才是给人看的。你信机器，机器骗你的时候连招呼都不打。

测试这行，干久了会发现，工具、框架、覆盖率数字都是表面功夫。真正管用的，是你对业务的理解，对边界的敏感，还有那份“总觉得哪里不对”的直觉。直觉不是天生的，是踩坑踩出来的。每踩一个，记一笔，下次绕开。就这么简单。