BUG漏测的思考
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。
3 对应措施
缺陷漏测问题发生了，我们该如何进行弥补，吸取教训并采取一些对应的措施呢？这里就上面的一些原因分别分享笔者的一些想法供各位读者参考：
（1）需求规格不明确，导致测试用例编写过于粗犷
在需求规格不明确的情况下，我们是无法编写出较为详细、准确的测试用例，只能先编写大概框架，待各条需求规格逐渐明确，再将测试用例进一步细化。在测试过程中，如果碰到规格没有明确的，需要和需求分析进行沟通，以便确定我们的一些疑惑点，完成测试工作。如果规格未进行定义，我们可以以沟通的结果作为基础编写一定的测试用例进行测试，待规格明确之后，再进行测试用例的增删修补。
（2）需求规格变更，测试用例未及时更新
需求规格变更，导致原来的测试用例与现在的规格不相符合。我们在执行测试用例过程中，如果碰到测试用例与规格不相符合的地方，我们需要记录下，并根据新规格补充完善测试用例，对存在有疑问的地方需要和规格设计进行沟通和确认，可以要求需求规格进行明确定义，事后将新增的、修改的测试用例整理成文，发给组内同事组织评审，并将评审之后的用例更新到用例库中去。
（3）测试用例覆盖不全面，场景出现遗漏
因为测试用例场景设计导致缺陷遗漏是在所难免的，编写测试用例的同事不可能把所有的场景都能想周全，把所有的场景下的 情况都写成测试用例这也是不大现实的。对于外部反馈的缺陷，是因为场景设计不全引起的，我们先分析出现问题的场景是客户必须的场景还是偶然的场景，如果该场景是客户操作习惯，我们可以通过和技术接口人沟通，确认该场景的一些具体细节，在完善测试用例的过程中我们也要考虑一些和该场景相关联的场景，将多种场景下测试用例及时完善、评审，增加到用例库中去。
（4）测试过程中未严格按照测试用例执行
我们需要面对现实，测试用例并不能覆盖所有的使用场景，但是，测试用例是经过由经验的人根据规格编写的，经过了需求分析、开发、测试及其他相关人员的评审，最大程度的保证用例的准确性、全面性。测试用例不一定能保证所有的场景和功能点都能覆盖到，但是严格按照测试用例执行测试，能最大程度上保证我们的软件质量，尽量避免出现缺陷。就一句话，我们在测试过程中要严格按照测试用例执行，不要因为测试用例的繁琐而抛弃测试用例，进行随意的测试。如果是因为测试过程中随意的测试，导致出现遗漏问题，实在是不应该。
（5）测试任务紧张，留给测试的时间较少，
在测试任务明显紧张的情况下，为避免出现明显缺陷遗漏，我们可以采取一些方式来最大程度上保障缺陷的遗漏：
第一，根据功能模块划分测试优先级，主要的功能模块优先级最高，安排有经验的人测试，安排新手测试一些不重要的功能模块或者很少使用的功能模块，在后续测试过程中，由有经验的同学将新手测试过的模块进行冒烟测试，确认是否有明显BUG；
第二，采用加班，对于加班，估计在座的各位同学没有谁不反感强制加班的，但是对于测试时间明显不足的情况下，加班是必不可少的，还是静下心来老老实实的加班干活，最起码能在领导面前图个好表现；
第三，尽量避免在一些和开发扯不清的情况下浪费自己的时间，如果因为开发人员排查问题占用的时间较长，可以告诉测试负责人，由测试负责人采取相应措施，通过协商来避免类似问题蔓延；
第四，增加测试人手；
（6）测试人员私藏BUG
发现了问题，在确定是问题之后就提交BUG库，不能因为和开发私下关系好就手下留情，我们需要区分好工作关系和私人关系，不要因为私人关系而影响工作，同时BUG数量也是测试人员的工作绩效体现之一。
对于版本发布在即，而缺陷却未得到有效控制，这是项目管理者最头大的事情。对于测试人员来说，抱着负责任的工作态度，不管在什么时间下发现了缺陷，都需要第一时间报告提提交，不能因为版本发布在即，而自己负责测试的模块发现了多个缺陷而心存畏惧，从而采取将BUG私藏而导致缺陷溜了出去，迟发现总比没发现好，在家里发现比在客户现场被发现的带来的损失要低得多。如果迟发现而不报告，对管理者来说就是没发现，测试人员
补充：综合编程 , 其他综合 ,
