如何看待测试过程当中的漏测发生

漏测，相信对于每一个测试同窗而言，都是“谈虎变色”的事，可是实际工做中，咱们稍有不谨慎便会和它来一次“亲密接触”，那么，如今咱们来聊聊测试中的漏测。

漏测将会产生的影响

一方面，会让他人对你的技术、业务能力产生怀疑，并且发生屡次后，甚至会质疑你存在的价值；

另外一方面，本身心里会很愧疚和自责，担忧下次测试任务还会漏测，内心压力倍增，以致于影响下次测试任务的顺利进行；

再者，由于本身漏测而致使的公司损失，我的或团队都会受到一些处分，轻者警告批评、扣绩效，重者可能被迫劝退离职。

因此对于测试同窗而言，漏测真的是让人特别难受的事。

为何会产生漏测现象

看到这里，也许你也和我同样，必定有不少话要说，甚至大堆的吐槽。其实大可没必要，下面以我限有的工做经验，我们客观的聊下产生漏测的可能缘由：

• 测试的工做在公司不被重视，测试定义的测试标准彻底被无视；
• 环境差别，测试环境没问题，可是在生产环境就各类问题；
• 没有明确的需求，老是说改就改；
• 没有测试流程概念，需求评审阶段由于没作到及时沟通，致使产品经理、开发、测试需求理解不一致；
• 测试彻底没有上线的话语权，没有版本概念，说上线就上线，不经过测试直接上线，有遗留问题仍是须要测试背锅；
• 开发由于本身开发时间不够，压缩测试时间；
• 一句话需求，没有明确的需求文档和原型图，开发未理解透彻，直接开始干了，干着干着开发以为需求不合理私自改了，大多数在不影响大功能状况下是默许的；
• 一我的负责多个项目，少则四个，多则8到10个，不少项目一旦冲突并行，不免漏测，毕竟一我的精力有限，我想说的是，老板，咋那么扣呢，就不能多请我的？
• 测试同窗自身缘由，好比业务理解不透彻、用例设计覆盖不全等等。

以上为我以为可能产生漏测的缘由，若是还有遗漏，还请后台留言给我，一块儿讨论学习。

漏测究竟是谁的责任？

我我的以为应该理性看待，具体问题，具体分析。

当上线后，出现bug后，确定第一时间应该找测试，测试同窗查看是否能复现这个问题，定位漏测问题缘由。

若是为页面有错别字、页面样式重叠严重的、功能不可用，用例覆盖不全面，业务理解不到位致使的这种很是浅显能够复现的问题，出了问题，找到测试，无可厚非。

若是是“不可预测、未知”的问题，好比说性能测试中，给出指标并已经测试10000人并发，并已告知开发人、产品测试并发量的状况，而开发、产品人员均没有提出异议。

但结果那天因为销量超好，并发量达到100000，系统崩溃了，这并非咱们能预测到的，因此是漏测，也不是一我的责任。

因此要对问题定位分析以后才能定位出来，是什么缘由，是需求不明确，理解歧义，开发引入，或是其余缘由，而后及时补救，最后再去定责。

如何避免漏测？

吃透业务需求

需求评审阶段，产品经理、开发、测试在开会以前，通常都会收到一份需求文档和原型图。在开会前，研读好需求文档后，作好理解不明确和产生歧义的地方。

待产品经理组会来说解需求时，针对不懂的地方进行提问，认真记录。

提升用例质量

提升用例覆盖率，结合业务设计有效业务场景，保证测试有效性。

用例评审

测试人员结合用例对需求进行反串讲，把对需求的理解讲一遍，列出全部的测试点和测试场景，产品和开发同事评审是否有遗漏场景，若是没有异议，这样就能够很大程度的避免漏测了。

交叉测试

一我的精力毕竟有限，若是条件和时间容许，能够把测试过的功能交给你的搭档，让他帮忙在测试一下，毕竟每一个人的测试思路不同，也许也有收获也不必定呢。

回归测试

梳理主流程用例，尤为随着版本迭代和功能的增长，回顾测试用例极为重要，毕竟每次发版时，要保证主流程没问题吧，主流程都有问题，难道还敢上线？

可能有的同窗说了，那么多用例，也执行不完呀，不是有web自动化吗，自动化跑呗，可能有的同窗说不会呀，我们学能够吗？

bug仲裁

在上线前，查看还有哪些问题，是未解决的，与产品、开发、测试经理商量，哪些bug是容许带到线上的，若是三方达成一致，那么线上再出问题，也是已知的，就没什么问题了。

作好漏测复盘

对待漏测态度上必需要重视，分析为什么会漏测，是哪一个环节出了问题，是流程问题仍是技术问题？

一样的坑别踩第二次，技术不足的学习补齐，流程不足的规范流程。

把它当作一次提升的机会，也正由于此次机会，让你印象越深入，可以避免下次不会再犯一样的错误。

总结

不得不说一句的是，漏测是不可能绝对避免的，咱们能作的只能是尽可能减小漏测现象，只要不出大问题，漏测现象会随着工做经验增长而逐渐减小。因此测试的时候，必定要仔细、细致、认真，毕竟一次漏测可能会影响不少人，因此万万马虎不得呀。