所谓的漏测，是指软件产品的缺陷没有被在测试过程中发现，而是在版本发布之后，客服或用户在使用过程中发现存在有缺陷。如果软件产品在客户使用过程中出现问题，产生的后果是非常严重的。
我们都知道，缺陷越早被发现，发现和解决缺陷所花的成本就越小，如果缺陷是在测试中发现的，那么所花的成本将小得多。测试是保证软件质量的最重要手段之一，因此，进行漏测分析、预防漏测、促使缺陷尽可能在开发过程的早期被发现，是非常有意义的，它有利于降低软件产品成本、提高软件产品质量。
2、原因分析
谁都不敢打包票说自己经手测试的东西没有问题，包括老鸟，或多或少的会出现让缺陷从自己的手中溜走，谁也不能把软件所有的功能操作、运用场景想周全，但是像神一样的老鸟我就不知道了，毕竟“姜还是老的辣”这不是一句空穴来风的话。
为什么会出现缺陷漏测，主要有以下几方面的原因：
（1）需求规格不明确，导致测试用例编写过于粗犷
需求还处于一个细化过程中，软件产品就已经在开发过程中了，而测试用例的编写是基于需求规格的，规格描叙越细致，测试用例就越能编写的准确，出现缺陷遗漏的情况就可能越少，所以在初期阶段测试用例就只能较为粗犷，只能待规格进一步细化，再完善补充测试用例，在实际工作中甚至出现边测试边根据细化的规格完善测试用例的情况。当然如果测试用例编写过于细致，后期的维护工作、成本将是巨大的，所有导致我们不能也不可能将测试用例编写过于特详细。
（2）需求规格变更，测试用例未及时更新
规格变更了，我们需要及时将测试用例更新，避免出现测试用例与规格不一致。但是在实际工作中我们没有养成随着规格的变更去更新测试用例的习惯，第一，我们很少有人是固定测试某一软件、某一功能模块，可能这段时间测试这个功能模块，下一阶段又换了新的功能模块，这样就导致没有精力和心思去更新测试用例；第二，不能在短时间内熟悉原来编写该测试用例的作者的风格，随意增删修补，容易出现别的问题；第三，不知道由谁来主导测试用例的更新以及如何进行测试用例更新。
（3）测试用例覆盖不全面，场景出现遗漏
虽然说测试是软件质量保证的最重要的一关，也是最后一关，我们也需要尽我们的可能将BUG消灭在发布之前，这也是我们的职责所在。但是，我们不可能穷举出软件在客户现场使用的所有场景，我们只能在一些主要的场景下进行测试，并在测试过程中进行适当的发散测试，在有限的时间内最大限度的发现BUG。
（4）测试过程中未严格按照测试用例执行
按照测试用例执行测试，可以让我们尽可能的不出现遗漏一些测试点。但是我们一些同学，不严格按照测试用例来执行测试，这样出现了一些遗漏BUG实在是不应该。但是，换句话说回来，我们发现的很多BUG都不是按测试用例执行发现出来的，都是在测试过程中随意测试发现的，而这些步骤在测试用例中并未体现，这就回到了原因（3）的描叙，我们的测试用例不可能覆盖所有的场景
（5）测试任务紧张，留给测试的时间较少，导致功能点的测试在测试过程中被省略
测试任务紧张，我想在公司的每个人都曾经经历过，因为项目紧张，软件deadline是不可推迟的，而开发过程中可能应为种种原因，占用了大量的测试时间，测试时间被严重压缩，导致原定的测试计划不得不调整，一些功能点的测试无法测试到位。
（6）测试人员私藏BUG
私藏BUG，这是我们私下的一种称呼发现缺陷不报告的情况，不管是测试人员碍于情面，不给开发打BUG，只是私下和开发沟通，希望对方将缺陷修复；或者是因为发布版本迫在眉睫，却一而再、再而三的暴露出一些缺陷，导致测试人员产生了一些负担的想法，对一些缺陷采取不报告。
如果开发人员有负责的态度，会很快将缺陷问题修复好，但工作是做不完的，可能一段时间之后就忘记了你曾经描叙的缺陷问题，而可怕的是，在繁忙的工作中，你也一不小心的将这个问题给忘记了，缺陷就这么在明知的情况下打包到客户现场去了。
（7）测试环境受限，导致缺陷漏测
客户的实际使用环境可能是复杂的、多变的，我们可以尽可能的模拟、还原客户的实际环境，但是毕竟是模拟、还原的，而不是真实的环境，由于环境的差异，可能出现很多意想不到的问题，这些问题可能只在特性的环境、特定的操作步骤下才会暴露出来，在我们的测试环境还原不出来，只能基于客户现场的实际环境来解决问题。
（8）开发人员引入的新BUG
有一些开发人员只会针对你所提交的BUG中问题的描叙步骤解决，并不会去排查该问题有可能涉及的所有点，有可能出现解决了这个问题，而引入了一个新的问题。
其次，有极个别开发人员修复BUG的水平实在令人不敢恭维，不知道是不屑于修改这么弱智的BUG还是因为把心思用到了别的地方。
再者，一个不熟悉功能模块的开发人员来修复BUG，因为业务不熟悉，考虑不周全导致无意识的引入新的BUG。
3、对应措施
缺陷漏测问题发生了，我们该如何进行弥补，吸取教训并采取一些对应的措施呢？这里就上面的一些原因分别分享笔者的一些想法供各位读者参考：
（1）需求规格不明确，导致测试用例编写过于粗犷
在需求规格不明确的情况下，我们是无法编写出较为详细、准确的测试用例，只能先编写大概框架，待各条需求规格逐渐明确，再将测试用例进一步细化。在测试过程中，如果碰到规格没有明确的，需要和需求分析进行沟通，以便确定我们的一些疑惑点，完成测试工作。如果规格未进行定义，我们可以以沟通的结果作为基础编写一定的测试用例进行测试，待规格明确之后，再进行测试用例的增删修补。
（2）需求规格变更，测试用例未及时更新
需求规格变更，导致原来的测试用例与现在的规格不相符合。我们在执行测试用例过程中，如果碰到测试用例与规格不相符合的地方，我们需要记录下，并根据新规格补充完善测试用例，对存在有疑问的地方需要和规格设计进行沟通和确认，可以要求需求规格进行明确定义，事后将新增的、修改的测试用例整理成文，发给组内同事组织评审，并将评审之后的用例更新到用例库中去。
（3）测试用例覆盖不全面，场景出现遗漏
因为测试用例场景设计导致缺陷遗漏是在所难免的，编写测试用例的同事不可能把所有的场景都能想周全，把所有的场景下的 情况都写成测试用例这也是不大现实的。对于外部反馈的缺陷，是因为场景设计不全引起的，我们先分析出现问题的场景是客户必须的场景还是偶然的场景，如果该场景是客户操作习惯，我们可以通过和技术接口人沟通，确认该场景的一些具体细节，在完善测试用例的过程中我们也要考虑一些和该场景相关联的场景，将多种场景下测试用例及时完善、评审，增加到用例库中去。
（4）测试过程中未严格按照测试用例执行
我们需要面对现实，测试用例并不能覆盖所有的使用场景，但是，测试用例是经过由经验的人根据规格编写的，经过了需求分析、开发、测试及其他相关人员的评审，最大程度的保证用例的准确性、全面性。测试用例不一定能保证所有的场景和功能点都能覆盖到，但是严格按照测试用例执行测试，能最大程度上保证我们的软件质量，尽量避免出现缺陷。就一句话，我们在测试过程中要严格按照测试用例执行，不要因为测试用例的繁琐而抛弃测试用例，进行随意的测试。如果是因为测试过程中随意的测试，导致出现遗漏问题，实在是不应该。
（5）测试任务紧张，留给测试的时间较少
在测试任务明显紧张的情况下，为避免出现明显缺陷遗漏，我们可以采取一些方式来最大程度上保障缺陷的遗漏：
第一，根据功能模块划分测试优先级，主要的功能模块优先级最高，安排有经验的人测试，安排新手测试一些不重要的功能模块或者很少使用的功能模块，在后续测试过程中，由有经验的同学将新手测试过的模块进行冒烟测试，确认是否有明显BUG；
第二，采用加班，对于加班，估计在座的各位同学没有谁不反感强制加班的，但是对于测试时间明显不足的情况下，加班是必不可少的，还是静下心来老老实实的加班干活，最起码能在领导面前图个好表现；
第三，尽量避免在一些和开发扯不清的情况下浪费自己的时间，如果因为开发人员排查问题占用的时间较长，可以告诉测试负责人，由测试负责人采取相应措施，通过协商来避免类似问题蔓延；
第四，增加测试人手；
（6）测试人员私藏BUG
发现了问题，在确定是问题之后就提交BUG库，不能因为和开发私下关系好就手下留情，我们需要区分好工作关系和私人关系，不要因为私人关系而影响工作，同时BUG数量也是测试人员的工作绩效体现之一。
对于版本发布在即，而缺陷却未得到有效控制，这是项目管理者最头大的事情。对于测试人员来说，抱着负责任的工作态度，不管在什么时间下发现了缺陷，都需要第一时间报告提提交，不能因为版本发布在即，而自己负责测试的模块发现了多个缺陷而心存畏惧，从而采取将BUG私藏而导致缺陷溜了出去，迟发现总比没发现好，在家里发现比在客户现场被发现的带来的损失要低得多。如果迟发现而不报告，对管理者来说就是没发现，测试人员需要在发现缺陷就立马报告出来，修改还是挂起，缺陷的风险如何，项目管理者会做全局考虑的，毕竟大多数同学还没有达到能对缺陷进行风险评估的水平。报告缺陷让项目管理者考虑总比自己私藏而被客户所发现要好，私藏BUG总会让自己有吃不了兜着走的一天。
（7）测试环境受限，导致缺陷漏测
环境的组合是无穷的，我们没有足够的时间、足够的成本在足够多的环境中测试软件。我们要保障在主要的操作系统环境、主要的网络环境中，我们的软件的功能、性能能达到我们预期的设计，对于操作系统环境，我们需要针对当前的使用比例来排序。这里以某产品线上一款软件为例：对于Client软件来说，WIN XP 和WIN 7的使用的最多。除了WIN 7 和WIN XP之外，我们不知道客户是否还会有人在WIN VISTA、WIN 2000上使用我们的软件，所有还需要测试WIN VISTA、WIN 2000。
对于网络环境，我们一般是在以太网环境中测试，对于客户的其余网络环境，我们在有条件、有需要的情况下也需要进行常规测试。
（8）开发人员引入的新BUG
开发人员是否会因为修复某个BUG而引入新的BUG呢？开发人员一般都会说没问题，我们要做的就是将开发人员修复的BUG确认验证，并将相关联的功能点尽可能的遍历到，因为如果出新问题的话，在与修复的BUG相关联的功能的地方可能性比较大，当前BUG修改之后开发自己会进行测试后才会提交，但与之相关联的功能点并不一定会去测试一把。
如果碰到极个别开发人员修复BUG的情况实在令人不敢恭维，或者是因为一个不熟悉模块业务的开发人员修复的BUG，我们就只能多花点时间，将回归测试的功能点尽量覆盖全面，避免出现缺陷遗漏。
开发人员修复已知BUG引入新的BUG，是开发团队提交代码流程的范围，比如华为的代码提高很严谨，层层审核，引入新BUG的可能性较小，但是中小型公司，代码管理混乱，甚至自己组长都不审核，出问题简直是必然的。所以规范代码提交流程是重中之重。
4、漏测分析的好处
不管是因为什么原因导致缺陷流到客户现场，问题发生了，我们首先要做的就是弥补缺陷带来的影响，项目组要评估由此带来的风险、损失，修正缺陷，提供完善的版本给客户使用。做完前面的这些工作之后，我们可以、甚至是需要自觉的进行思考总结，吸取经验教训，并将出问题的这些情况补充、完善到测试用例中去，对一些常见的情况还需要进行组内学习，避免在以后的工作中再次犯下同样的错误。
如果能做的更好一步，我们可以学习并进行统计，对这些遗漏的BUG予以分类，缺陷的严重程度、所属功能模块、遗漏原因分类等等。我们在进行缺陷漏测分类活动时，可以由专人组织发起讨论，将需求、开发、测试、技术支持以及其他所有产品生命周期中相关部门的代表组织到一起对近期的漏测进行分析讨论，特别是技术支持人员能够提供很多非常详细的关于漏测缺陷的信息，这对漏测分类、累积经验、教训吸取非常有帮助。
进行缺陷漏测分析的目的是为了促进软件质量和开发测试过程得到持续改进，使我们在测试过程中可以考虑得更加周全，弥补思维僵局。具体来讲，就是通过分析测试过程中漏测的缺陷，采取一些相应的预防措施以避免今后再发生类似的漏测。测试过程的持续改进将提高测试环境的效果和测试执行的效率、降低遗留到用户处的缺陷数和缺陷解决成本，从而提升软件的质量。
在实际工作中，漏测分析过程应该重点关注那些普遍、严重而解决成本高的问题。具体来讲，进行漏测分析的目标是：
● 对漏测进行分类以便于更进一步深入的分析
● 对分类数据进行统计
● 在统计分析的基础上进行全过程的标识和变更
● 在对一些特殊的漏测项进行分析的基础上，对过程的一些局部进行标识和变更
● 运用度量数据说明过程变更的效果
● 如何进行漏测分析
5、总结
缺陷漏测是不能杜绝的，缺陷漏测发生后，我们需要学会思考，吸取经验教训，尽可能的降低缺陷的漏测量。