漏测，相信对于每个测试同学而言，都是“谈虎变色”的事，但是实际工作中，我们稍有不谨慎便会和它来一次“亲密接触” 。那么，现在我们一起来聊聊测试中的漏测 。
一、漏测可能会产生的影响
一方面，会让他人对你的技术、业务能力产生怀疑，而且发生多次后，甚至会质疑你存在的价值;
另一方面，自己内心会很愧疚和自责，担心下次测试任务还会漏测，心里压力倍增，以至于影响下次测试任务的顺利进行;
再者，因为自己漏测而导致的公司损失，个人或团队都会受到一些处分，轻者警告批评、扣绩效，重者可能被迫劝退离职 。
所以对于测试同学而言，漏测真的是让人特别难受的事 。
文章插图
二、为什么会产生漏测现象
看到这里，也许你也和我一样，一定有很多话要说，甚至大堆的吐槽 。
其实大可不必，下面以我现有的工作经验，咱们客观地聊下产生漏测的可能原因：
● 测试的工作在公司不被重视，测试定义的测试标准完全被无视;
● 环境差异，测试环境没问题，但是在生产环境就各种问题;
● 没有明确的需求，总是说改就改;
● 没有测试流程概念，需求评审阶段因为没做到及时沟通，导致产品经理、开发、测试需求理解不一致;
● 测试完全没有上线的话语权，没有版本概念，说上线就上线，不通过测试直接上线，有遗留问题还是需要测试背锅;
● 开发因为自己开发时间不够，压缩测试时间;
● 一句话需求，没有明确的需求文档和原型图，开发未理解透彻，直接开始干了，干着干着开发觉得需求不合理私自改了，大多数在不影响大功能情况下是默许的;
● 一个人负责多个项目，少则四个，多则8到10个，很多项目一旦冲突并行，难免漏测，毕竟一个人精力有限，我想说的是，老板，咋那么扣呢，就不能多请个人?
● 测试同学自身原因，比如业务理解不透彻、用例设计覆盖不全等等 。
三、漏测到底是谁的责任?
我个人觉得应该理性看待，具体问题，具体分析 。
当上线后，出现bug后，肯定第一时间应该找测试，测试同学查看是否能复现这个问题，定位漏测问题原因 。
如果为页面有错别字、页面样式重叠严重的、功能不可用，用例覆盖不全面，业务理解不到位导致的这种非常浅显可以复现的问题，出了问题，找到测试，无可厚非 。
如果是“不可预测、未知”的问题，比如说性能测试中，给出指标并已经测试10000人并发，并已告知开发人、产品测试并发量的情况，而开发、产品人员均没有提出异议 。
但结果那天由于销量超好，并发量达到100000，系统崩溃了，这并不是我们能预测到的，所以是漏测，也不是一个人责任 。
所以要对问题定位分析之后才能定位出来，是什么原因，是需求不明确，理解歧义，开发引入，或是其他原因，然后及时补救，最后再去定责 。
四、如何避免漏测?
● 吃透业务需求
需求评审阶段，产品经理、开发、测试在开会之前，一般都会收到一份需求文档和原型图 。在开会前，研读好需求文档后，做好理解不明确和产生歧义的地方，待产品经理组会来讲解需求时，针对不懂的地方进行提问，认真记录 。
● 提高用例质量
提高用例覆盖率，结合业务设计有效业务场景，保证测试有效性 。
● 做好用例评审
测试人员结合用例对需求进行反串讲，把对需求的理解讲一遍，列出所有的测试点和测试场景，产品和开发同事评审是否有遗漏场景，如果没有异议，这样就可以很大程度的避免漏测了 。
● 增加交叉测试
一个人精力毕竟有限，如果条件和时间允许，可以把测试过的功能交给你的搭档，让他帮忙再测试一下，毕竟每个人的测试思路不一样，也许也有收获也不一定呢 。
● 有效回归测试
梳理主流程用例，尤其随着版本迭代和功能的增加，回顾测试用例极为重要，毕竟每次发版时，要保证主流程没问题吧，主流程都有问题，难道还敢上线?
可能有的同学说了，那么多用例，也执行不完呀，不是有web自动化吗，自动化跑呗，可能有的同学说不会呀，咱们学可以吗?
● bug仲裁
在上线前，查看还有哪些问题，是未解决的，与产品、开发、测试经理商量，哪些bug是允许带到线上的，如果三方达成一致，那么线上再出问题，也是已知的，就没什么问题了 。
推荐阅读
- 实测篇 如何选购智能手表？
- 渗透测试小工具-sqlmate
- 比普通主板贵一点，带WiFi的主板值不值得选？实测告诉你
- 2021年年度最佳开源软件
- 7个不可多得的宝藏软件，经典也实用
- 嵌入式软件架构设计
- 如何永久告别流氓软件，这5个杀毒神器，让你的电脑干干净净
- redis主从同步参数repl_backlog_size测算
- 单一职责原则：软件世界中最重要的规则 - DZone
- AMD|CPU、显卡等芯片还会缺货吗？Intel CEO悲观预测：2024年都好不了