在需求这个错综复杂的迷宫中，漏测就像是个黑不见底的黑洞，隐藏着诸多难以察觉的问题。造成漏测的罪魁祸首主要有六种，它们就像六张牌一样，单独或组合在一起，让测试工作变得如同在雾里射箭，方向明明正确却总是射不中靶心。 只要一提到Bug，“又漏测了？”这句话就成了测试人员每天都要面对的质问。老板通常会先把责任推给测试，然后再把锅甩给开发。在老板的逻辑里，代码已经被赋予了价值，BUG的存在被认为是商业运作的常态。而测试人员似乎成了专门找碴的人，常常把那些最简单、最容易复现的Bug忽略掉。结果就是测试人员总是被指责做得再多也是白费功夫。 分析大量的案例不难发现，需求、变更、用例、执行、环境和偷改这六张牌永远是导致漏测的幕后推手。需求不清晰就像给房子打了一个歪的地基，后续所有环节都会按照错误的剧本演下去；产品经理随意更改需求却不通知测试，用例还没更新功能已经合并到了线上；用例设计得不够全面或者评审走过场导致用例库成了摆设；执行过程中数据不透明导致责任无法落实；测试环境与线上环境差异过大导致数据出现漂移；开发人员悄悄更改代码又不告知测试人员等问题都可能引发漏测。 为了避免被无端背锅，当发现漏测时可以先套用这套“三问模型”来寻找原因：用例是否覆盖了所有可能的场景？如果没有覆盖就需要重新讨论范围问题；范围是否考虑到了关联功能？如果没有就需要进一步扩大范围；覆盖率是否达到了100%？如果没有就需要采取技术手段来保证下次不再遗漏。 对于明显的错别字上线才暴露这种情况，主要责任在于测试人员没有仔细检查；而并发量过高导致系统崩溃这种情况则需要各方共同承担责任：开发人员没有补全场景、测试人员没有扩大边界、产品经理没有提出更高并发的需求。 如果你是一位刚入行或者想转行做测试的人，“需求—用例—环境”这三件套是必须要吃透的。在需求阶段要用思维导图把模糊的表述拆解成可验证的点；在写用例阶段要写清楚前提条件、操作步骤和预期结果并关联业务字典；在环境阶段上线前至少要跑一遍“环境一致性脚本”来确保数据不会出现漂移。 当你能把漏洞变成可验证的测试点时，你就能从一个背锅侠变成一名防漏卫士。这样不仅能提升自己的专业能力还能避免因为漏测带来的尴尬局面。