3、对应措施

　　缺陷漏测问题发生了，我们该如何进行弥补，吸取教训并采取一些对应的措施呢？这里上面的一些原因分别分享笔者的一些想法供各位读者参考：

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

　　在需求规格不明确的情况下，我们是无法编写出较为详细、准确的测试用例，只能先编写大概框架，待各条需求规格逐渐明确，再将测试用例进一步细化。在测试过程中，如果碰到规格没有明确的，需要和需求分析进行沟通，以便确定我们的一些疑惑点，完成测试工作。如果规格未进行定义，我们可以以沟通的结果作为基础编写一定的测试用例进行测试，待规格明确之后，再进行测试用例的增删修补。

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

　　需求规格变更，导致原来的测试用例与现在的规格不相符合。我们在执行测试用例过程中，如果碰到测试用例与规格不相符合的地方，我们需要记录下，并根据新规格补充完善测试用例，对存在有疑问的地方需要和规格设计进行沟通和确认，可以要求需求规格进行明确定义，事后将新增的、修改的测试用例整理成文，发给组内同事组织评审，并将评审之后的用例更新到用例库中去。

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

　　因为测试用例场景设计导致缺陷遗漏是在所难免的，编写测试用例的同事不可能把所有的场景都能想周全，把所有的场景下的    情况都写成测试用例这也是不大现实的。对于外部反馈的缺陷，是因为场景设计不全引起的，我们先分析出现问题的场景是客户必须的场景还是偶然的场景，如果该场景是客户操作习惯，我们可以通过和技术接口人沟通，确认该场景的一些具体细节，在完善测试用例的过程中我们也要考虑一些和该场景相关联的场景，将多种场景下测试用例及时完善、评审，增加到用例库中去。

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

　　我们需要面对现实，测试用例并不能覆盖所有的使用场景，但是，测试用例是经过由经验的人根据规格编写的，经过了需求分析、开发、测试及其他相关人员的评审，大程度的保证用例的准确性、全面性。测试用例不一定能保证所有的场景和功能点都能覆盖到，但是严格按照测试用例执行测试，能大程度上保证我们的软件质量，尽量避免出现缺陷。一句话，我们在测试过程中要严格按照测试用例执行，不要因为测试用例的繁琐而抛弃测试用例，进行随意的测试。如果是因为测试过程中随意的测试，导致出现遗漏问题，实在是不应该。

　　（5）测试任务紧张，留给测试的时间较少

　　在测试任务明显紧张的情况下，为避免出现明显缺陷遗漏，我们可以采取一些方式来大程度上保障缺陷的遗漏：

　　第一，根据功能模块划分测试优先级，主要的功能模块优先级高，安排有经验的人测试，安排新手测试一些不重要的功能模块或者很少使用的功能模块，在后续测试过程中，由有经验的同学将新手测试过的模块进行冒烟测试，确认是否有明显BUG；

　　第二，采用加班，对于加班，估计在座的各位同学没有谁不反感强制加班的，但是对于测试时间明显不足的情况下，加班是必不可少的，还是静下心来老老实实的加班干活，起码能在领导面前图个好表现；

　　第三，尽量避免在一些和开发扯不清的情况下浪费自己的时间，如果因为开发人员排查问题占用的时间较长，可以告诉测试负责人，由测试负责人采取相应措施，通过协商来避免类似问题蔓延；

　　第四，增加测试人手；

　　（6）测试人员私藏BUG

　　发现了问题，在确定是问题之后提交BUG库，不能因为和开发私下关系好手下留情，我们需要区分好工作关系和私人关系，不要因为私人关系而影响工作，同时BUG数量也是测试人员的工作绩效体现之一。

　　对于版本发布在即，而缺陷却未得到有效控制，这是项目管理者头大的事情。对于测试人员来说，抱着负责任的工作态度，不管在什么时间下发现了缺陷，都需要第一时间报告提提交，不能因为版本发布在即，而自己负责测试的模块发现了多个缺陷而心存畏惧，从而采取将BUG私藏而导致缺陷溜了出去，迟发现总比没发现好，在家里发现比在客户现场被发现的带来的损失要低得多。如果迟发现而不报告，对管理者来说是没发现，测试人员需要在发现缺陷立马报告出来，修改还是挂起，缺陷的风险如何，项目管理者会做全局考虑的，毕竟大多数同学还没有达到能对缺陷进行风险评估的水平。报告缺陷让项目管理者考虑总比自己私藏而被客户所发现要好，私藏BUG总会让自己有吃不了兜着走的。