昨天下午三点十七分，漏测测试组的失帮小王在群里发了一条消息：“支付接口那个漏测，客户那边出问题了。措施”群里安静了整整五分钟。漏测没人敢接话。失帮

这已经是措施本季度第三次因为漏测导致的线上事故了。前两次我们开了复盘会，漏测写了改进文档，失帮甚至把测试用例模板重新翻修了一遍——但该漏还是措施漏。问题出在哪儿？漏测我盯着那堆流程文件想了很久，最后发现一个扎心的失帮事实：我们把“漏测”当成一个技术问题在解决，可它本质上是措施管理问题，甚至是漏测人性问题。

先说一个我观察到的失帮真实现象。测试用例评审会上，措施没人会主动说“这个场景我没想到”。大家默认评审只是走个过场，真正的关注点全在“今天能不能按时发版”。于是，测试人员潜意识里会倾向于把用例写得“看起来全面”，而不是“真的全面”。边界值、异常流、并发场景——这些词写得越多，越容易让人产生一种虚假的安全感。等出了问题翻用例库，发现那条路径压根没被覆盖，但用例文档里密密麻麻的几百条case，谁又能逐条去验证覆盖度呢？

所以我的第一个建议很直接：把“漏测率”纳入测试人员的个人绩效，但不搞连坐。具体做法是，每次线上缺陷被确认是漏测导致，就要求对应测试人员写一份200字的“漏测归因”，不是检讨书，而是纯粹的技术分析——为什么当时没想到？是需求理解偏差，还是数据流没吃透？这份归因要公开，发到团队群里。别小看这个动作，公开本身就是压力，比扣钱管用得多。

第二个措施有点反常规。我们试着在提测前增加一个“反向测试”环节。什么是反向测试？就是故意用错误的方式去操作功能。比如用户注册流程，正常测试是填对信息，但我们会专门安排一个人去乱点、乱输、乱跳转，甚至故意篡改本地存储的数据。这个角色叫“破坏者”，每次轮换，不固定人选。为什么有效？因为正向用例写多了，思维会固化，而破坏者的视角天然是发散的。上个月我们抓到一个严重漏洞，就是破坏者用手机改了系统时间后调用了优惠券接口——这场景正经测试用例里根本不会写。

第三个措施跟工具无关，跟沟通节奏有关。漏测高发的时段，往往不是项目初期，而是临近上线的最后三天。那会儿人都在赶工，心态浮躁，用例执行变得机械。我们干脆立了个规矩：上线前48小时，禁止新增测试用例。只允许执行已评审过的用例，如果发现新场景，宁可推迟上线，也不临时塞进去。这个规定刚出来时被骂惨了，说太死板。但执行了两个月，漏测率确实降了——因为大家知道，与其慌慌张张补用例，不如一开始就把需求聊透。

最后说一点务虚的。漏测这件事，本质上是测试人员对产品逻辑的“想象力不足”。想象力怎么培养？靠的是对业务场景的沉浸感。我要求测试组的同事每个月必须去客服部坐半天，听用户怎么骂产品。你听过真实用户用方言描述“我明明点了保存但数据丢了”的时候，那种语气里的愤怒，比任何需求文档都更能让你记住这个场景。这招见效慢，但一旦起了作用，是根治性的。

方案讲完了。但说句实话，没有哪套措施能保证零漏测。软件是人写的，人就会犯错。我们做的所有努力，不过是把犯错的概率压低一点，再压低一点。就像开车不能保证不出事故，但系好安全带、看后视镜、保持车距，总比闭着眼踩油门强。对吧？

(责任编辑：焦点)