1、概念描叙

　　所谓的漏测，是指软件产品的缺陷没有被在测试过程中发现，而是在版本发布之后，客服或用户在使用过程中发现存在有缺陷。如果软件产品在客户使用过程中出现问题，产生的后果是非常严重的。

　　我们都知道，缺陷越早被发现，发现和解决缺陷所花的成本越小，如果缺陷是在测试中发现的，那么所花的成本将小得多。测试是保证软件质量的重要手段之一，因此，进行漏测分析、预防漏测、促使缺陷尽可能在开发过程的早期被发现，是非常有意义的，它有利于降低软件产品成本、提高软件产品质量。

　　2、原因分析

　　谁都不敢打包票说自己经手测试的东西没有问题，包括老鸟，或多或少的会出现让缺陷从自己的手中溜走，谁也不能把软件所有的功能操作、运用场景想周全，但是像神一样的老鸟我不知道了，毕竟“姜还是老的辣”这不是一句空穴来风的话。

　　为什么会出现缺陷漏测，主要有以下几方面的原因：

　　（1）需求规格不明确，导致测试用例编写过于粗犷

　　需求还处于一个细化过程中，软件产品已经在开发过程中了，而测试用例的编写是基于需求规格的，规格描叙越细致，测试用例越能编写的准确，出现缺陷遗漏的情况可能越少，所以在初期阶段测试用例只能较为粗犷，只能待规格进一步细化，再完善补充测试用例，在实际工作中甚至出现边测试边根据细化的规格完善测试用例的情况。当然如果测试用例编写过于细致，后期的维护工作、成本将是巨大的，所有导致我们不能也不可能将测试用例编写过于特详细。

　　（2）需求规格变更，测试用例未及时更新

　　规格变更了，我们需要及时将测试用例更新，避免出现测试用例与规格不一致。但是在实际工作中我们没有养成随着规格的变更去更新测试用例的习惯，第一，我们很少有人是固定测试某一软件、某一功能模块，可能这段时间测试这个功能模块，下一阶段又换了新的功能模块，这样导致没有精力和心思去更新测试用例；第二，不能在短时间内熟悉原来编写该测试用例的作者的风格，随意增删修补，容易出现别的问题；第三，不知道由谁来主导测试用例的更新以及如何进行测试用例更新。

　　（3）测试用例覆盖不全面，场景出现遗漏

　　虽然说测试是软件质量保证的重要的一关，也是后一关，我们也需要尽我们的可能将BUG消灭在发布之前，这也是我们的职责所在。但是，我们不可能穷举出软件在客户现场使用的所有场景，我们只能在一些主要的场景下进行测试，并在测试过程中进行适当的发散测试，在有限的时间内大限度的发现BUG。

　　（4）测试过程中未严格按照测试用例执行

　　按照测试用例执行测试，可以让我们尽可能的不出现遗漏一些测试点。但是我们一些同学，不严格按照测试用例来执行测试，这样出现了一些遗漏BUG实在是不应该。但是，换句话说回来，我们发现的很多BUG都不是按测试用例执行发现出来的，都是在测试过程中随意测试发现的，而这些步骤在测试用例中并未体现，这回到了原因（3）的描叙，我们的测试用例不可能覆盖所有的场景

　　（5）测试任务紧张，留给测试的时间较少，导致功能点的测试在测试过程中被省略

　　测试任务紧张，我想在公司的每个人都曾经经历过，因为项目紧张，软件deadline是不可推迟的，而开发过程中可能应为种种原因，占用了大量的测试时间，测试时间被严重压缩，导致原定的测试计划不得不调整，一些功能点的测试无法测试到位。

　　（6）测试人员私藏BUG

　　私藏BUG，这是我们私下的一种称呼发现缺陷不报告的情况，不管是测试人员碍于情面，不给开发打BUG，只是私下和开发沟通，希望对方将缺陷修复；或者是因为发布版本迫在眉睫，却一而再、再而三的暴露出一些缺陷，导致测试人员产生了一些负担的想法，对一些缺陷采取不报告。

　　如果开发人员有负责的态度，会很快将缺陷问题修复好，但工作是做不完的，可能一段时间之后忘记了你曾经描叙的缺陷问题，而可怕的是，在繁忙的工作中，你也一不小心的将这个问题给忘记了，缺陷这么在明知的情况下打包到客户现场去了。

　　（7）测试环境受限，导致缺陷漏测

　　客户的实际使用环境可能是复杂的、多变的，我们可以尽可能的模拟、还原客户的实际环境，但是毕竟是模拟、还原的，而不是真实的环境，由于环境的差异，可能出现很多意想不到的问题，这些问题可能只在特性的环境、特定的操作步骤下才会暴露出来，在我们的测试环境还原不出来，只能基于客户现场的实际环境来解决问题。

　　（8）开发人员引入的新BUG

　　有一些开发人员只会针对你所提交的BUG中问题的描叙步骤解决，并不会去排查该问题有可能涉及的所有点，有可能出现解决了这个问题，而引入了一个新的问题。

　　其次，有极个别开发人员修复BUG的水平实在令人不敢恭维，不知道是不屑于修改这么弱智的BUG还是因为把心思用到了别的地方。

　　再者，一个不熟悉功能模块的开发人员来修复BUG，因为业务不熟悉，考虑不周全导致无意识的引入新的BUG。