漏测,相信对于每个测试同学而言,都是“谈虎变色”的事,但是实际工作中,我们稍有不谨慎便会和它来一次“亲密接触”。那么,现在我们一起来聊聊测试中的漏测。
![](https://i-blog.csdnimg.cn/blog_migrate/c18fc3c1980f6fdf83c73397704c967e.png)
漏测可能会产生的影响
一方面,会让他人对你的技术、业务能力产生怀疑,而且发生多次后,甚至会质疑你存在的价值;
另一方面,自己内心会很愧疚和自责,担心下次测试任务还会漏测,心里压力倍增,以至于影响下次测试任务的顺利进行;
再者,因为自己漏测而导致的公司损失,个人或团队都会受到一些处分,轻者警告批评、扣绩效,重者可能被迫劝退离职。
所以对于测试同学而言,漏测真的是让人特别难受的事。
为什么会产生漏测现象
看到这里,也许你也和我一样,一定有很多话要说,甚至大堆的吐槽。
其实大可不必,下面以我限有的工作经验,咱们客观的聊下产生漏测的可能原因:
测试的工作在公司不被重视,测试定义的测试标准完全被无视;
环境差异,测试环境没问题,但是在生产环境就各种问题;
没有明确的需求,总是说改就改;
没有测试流程概念,需求评审阶段因为没做到及时沟通,导致产品经理、开发、测试需求理解不一致;
测试完全没有上线的话语权,没有版本概念,说上线就上线,不通过测试直接上线,有遗留问题还是需要测试背锅;
开发因为自己开发时间不够,压缩测试时间;
一句话需求,没有明确的需求文档和原型图,开发未理解透彻,直接开始干了,干着干着开发觉得需求不合理私自改了,大多数在不影响大功能情况下是默许的;
一个人负责多个项目,少则四个,多则8到10个,很多项目一旦冲突并行,难免漏测,毕竟一个人精力有限,我想说的是,老板,咋那么扣呢,就不能多请个人?
测试同学自身原因,比如业务理解不透彻、用例设计覆盖不全等等。
以上为我觉得可能产生漏测的原因,如果还有遗漏,还请留言给我,一起讨论学习。
漏测到底是谁的责任?
我个人觉得应该理性看待,具体问题,具体分析。
当上线后,出现bug后,肯定第一时间应该找测试,测试同学查看是否能复现这个问题,定位漏测问题原因。
如果为页面有错别字、页面样式重叠严重的、功能不可用,用例覆盖不全面,业务理解不到位导致的这种非常浅显可以复现的问题,出了问题,找到测试,无可厚非。
如果是“不可预测、未知”的问题,比如说性能测试中,给出指标并已经测试10000人并发,并已告知开发人、产品测试并发量的情况,而开发、产品人员均没有提出异议。
但结果那天由于销量超好,并发量达到100000,系统崩溃了,这并不是我们能预测到的,所以是漏测,也不是一个人责任。
所以要对问题定位分析之后才能定位出来,是什么原因,是需求不明确,理解歧义,开发引入,或是其他原因,然后及时补救,最后再去定责。
如何避免漏测?
1,吃透业务需求
需求评审阶段,产品经理、开发、测试在开会之前,一般都会收到一份需求文档和原型图。在开会前,研读好需求文档后,做好理解不明确和产生歧义的地方,待产品经理组会来讲解需求时,针对不懂的地方进行提问,认真记录。
2,提高用例质量
提高用例覆盖率,结合业务设计有效业务场景,保证测试有效性。
3,做好用例评审
测试人员结合用例对需求进行反串讲,把对需求的理解讲一遍,列出所有的测试点和测试场景,产品和开发同事评审是否有遗漏场景,如果没有异议,这样就可以很大程度的避免漏测了。
4,增加交叉测试
一个人精力毕竟有限,如果条件和时间允许,可以把测试过的功能交给你的搭档,让他帮忙在测试一下,毕竟每个人的测试思路不一样,也许也有收获也不一定呢。
5,有效回归测试
梳理主流程用例,尤其随着版本迭代和功能的增加,回顾测试用例极为重要,毕竟每次发版时,要保证主流程没问题吧,主流程都有问题,难道还敢上线?
可能有的同学说了,那么多用例,也执行不完呀,不是有web自动化吗,自动化跑呗,可能有的同学说不会呀,咱们学可以吗?
1,bug仲裁
在上线前,查看还有哪些问题,是未解决的,与产品、开发、测试经理商量,哪些bug是允许带到线上的,如果三方达成一致,那么线上再出问题,也是已知的,就没什么问题了。
2,做好漏测复盘
对待漏测态度上必须要重视,分析为何会漏测,是哪个环节出了问题,是流程问题还是技术问题?
同样的坑别踩第二次,技术不足的学习补齐,流程不足的规范流程。
把它当做一次提高的机会,也正因为这次机会,让你印象越深刻,能够避免下次不会再犯同样的错误。
总结
不得不说一句的是,漏测是不可能绝对避免的,我们能做的只能是尽量减少漏测现象,只要不出大问题,漏测现象会随着工作经验增加而逐渐减少。
所以测试的时候,一定要仔细、细致、认真,毕竟一次漏测可能会影响很多人,所以万万马虎不得呀。