什么是漏测?具体地说,什么是测试漏测?
测试漏测是指软件产品在测试结束后出现了在测试过程中没有被发现的bug。我们知道,漏测是每一个软件测试者最头疼的事,一旦出现漏测:
首先给客户带来了非常不好的影响,特别是严重的功能性bug被漏测;
其次增加bug修复的成本,包括人力物力财力上;
再者给自己的测试团队也带来了不利影响,容易被别人质疑能力不足,难以取得信任。
不漏测这个很难避免的,微软的产品都天天打补丁呢(包括google、 facebook也经常打补丁)!
测试人员是没有办法保证不漏测的,但是尽可能少漏测,而且每次保证漏测的原因都是不一样的。
如何避免漏测
1. 吃透业务需求
需求评审阶段,产品经理、开发、测试在开会之前,一般都会收到一份需求文档和原型图。
在开会前,研读好需求文档后,做好理解不明确和产生歧义的地方,待产品经理组会来讲解需求时,针对不懂的地方进行提问,认真记录。
2.提高用例质量
提高用例覆盖率,结合业务设计有效业务场景,保证测试有效性。
3. 做好用例评审
测试人员结合用例对需求进行反串讲,把对需求的理解讲一遍,列出所有的测试点和测试场景,产品和开发同事评审是否有遗漏场景,如果没有异议,这样就可以很大程度上避免漏测了。
4.增加交叉测试
一个人精力毕竟有限,如果条件和时间允许,可以把测试过的功能交给你的搭档,让他帮忙再测试一下,毕竟每个人的测试思路不一样,也许也有收获也不一定呢。
5.有效回归测试
梳理主流程用例,尤其随着版本迭代和功能的增加,回顾测试用例极为重要,毕竟每次发版时,要保证主流程没问题吧,主流程都有问题,难道还敢上线?
6. bug仲裁
在上线前,查看还有哪些问题,是未解决的,与产品、开发、测试经理商量,哪些bug是允许带到线上的,如果三方达成一致,那么线上再出问题,也是已知的,就没什么问题了。
7. 做好漏测复盘
对待漏测态度上必须要重视,分析为何会漏测,是哪个环节出了问题,是流程问题还是技术问题?
同样的坑别踩第二次,技术不足的学习补齐,流程不足的规范流程。
把它当做一次提高的机会,也正因为这次机会,让你印象越深刻,能够避免下次不会再犯同样的错误。
总结
不得不说一句的是,漏测是不可能绝对避免的,我们能做的只能是尽量减少漏测现象,漏测现象会随着工作经验增加而逐渐减少。
感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取