自动化核查系统上线三个月，自动漏测率不降反升，化核从原来的查出侧何8%跳到了12%。排查原因时发现，把控问题出在“核查”本身——系统把规则设得太死，自动把人工复核的化核环节砍得太狠，结果把本该拦下的查出侧何缺陷全放过去了。
漏测的把控根源从来不在技术，而在流程设计。自动自动化核查本质上是化核把质量标准固化成代码，但代码只能捕捉它被训练过的查出侧何模式。有一次线上事故，把控是自动前端按钮在特定分辨率下错位，自动化脚本只测了标准视口，化核压根没覆盖到。查出侧何测试人员当时觉得“系统都跑过了”，就没再手动看，结果翻车了。
要控制漏测，得先承认自动化核查的边界。它擅长重复性高、规则明确的检查，比如字段格式、接口返回值、页面元素是否存在。但对那些需要“判断力”的场景——交互逻辑是否合理、视觉是否协调、异常流程是否优雅——它就是个睁眼瞎。认清这点，才能谈把控。
我的做法是给自动化核查加“分层闸门”。第一层跑全量回归，筛出硬性报错；第二层抽检核心链路，用脚本模拟真实用户操作路径，但故意混入异常数据；第三层才是关键——强制安排人工抽检，比例不低于20%，专门盯那些自动化“不敢断言”的模块。这三层下来，漏测率能压回3%以内。别嫌麻烦，省掉人工的那一步，省下的时间迟早加倍赔回去。
还有个细节容易被忽略：核查规则本身要定期“体检”。业务变了，页面改了，但脚本里的断言还停留在三个月前，那漏测就是必然。我见过一个团队，支付流程改了折扣计算方式，测试脚本还在校验旧的价格公式，结果上线后优惠金额全错，自动化还报“通过”。后来我们定了个规矩——每次需求变更，必须同步更新核查用例，并且由开发、测试、产品三方签字确认，谁漏更谁担责。
另外，漏测数据不能只记个数就完事。每次漏测都要做根因回溯：是规则没覆盖到？还是数据构造有问题？或者是环境差异导致脚本误判？把漏测案例按原因分类，两个月后你会发现，八成漏测集中在两三个固定环节。把这些环节单独拎出来，加针对性检查，比盲目扩充用例有效得多。
说到底，自动化核查是工具，不是保险箱。它帮你兜住常规错误，但那些非常规的、边界性的、需要直觉判断的问题，还得靠人补位。把控漏测，本质是把握好机器和人的分工——机器跑量，人跑心。