欢迎光临
梦想从学习开始!

冒烟测试| 小熊测试

本文主要介绍 冒烟测试| 小熊测试,小熊希望对大家的学习或者工作具有一定的参考学习价值,在测试领域有所提升和发展。

在软件开发过程中,一直有高内聚,低耦合这样的说法,各个功能模块之间的耦合还是存在的,因此一个功能的改动,还是会影响到其他功能模块。

因此在开发人员修复了先前测试中发现的bug后,想知道这个bug的修复是否会影响到其他功能模块,需要做的就是冒烟测试。

搞清楚冒烟测试的起源,冒烟测试的目的后,不难想到,冒烟测试是这样的一种测试,不要求覆盖面有多广,但至少要保证覆盖待测产品的绝大部分功能;不要求每个功能都测的很详细,但至少要保证被修复了的bug所属的功能和系统其他骨干功能都是可用的(即这个版本能拿去做系统功能测试了)。

而要做到覆盖骨干功能和bug所属功能,却不是简简单单在页面中点几下就行了的。任何一个项目或者产品,骨干功能都有它的使用场景。冒烟测试就是要保证这些骨干功能的使用场景都能跑通,如果没跑通,后续的系统测试就没必要了。

其实做冒烟测试之前,都已经做了一个简单的安装部署测试了(你不安装部署,哪里来东西测呢)。按我自己的理解,其实这块也可以放入冒烟测试范畴的。想想看,安装部署是不是很类似电路板加电,让电路板开始工作呢?而后面的骨干使用场景测试,只是在这个基础上做的后续工作。如果安装部署后,待测产品跑到一半就down掉了,后面的骨干功能的使用场景还测个屁呀。

使用场景的是否能跑通的测试,不需要测一些异常的情况,保证基本功能覆盖到就行了。通常,冒烟测试是交给开发人员去做的。只有确认了功能可用后,交给测试人员去做才有意义。刚开始进公司时,小组里面有个人不做冒烟,只把他修改了的部分简单测了下,就交给我这边去测试。结果就是我测试到一半,发现有个很重要的功能用不了。这个时候,测试只要中止了。时间久了,大家对产品质量和测试工作有了一定认识(最主要是大家不急急忙忙地加班了,^__^ ),对我也有了一定的认可,因此做事也越来越正规了。现在我们小组的做法是,小组里面每个人扮演产品使用场景中的一个角色,然后大家一齐分工去完成每个场景里面各自角色要完成的任务,在这个过程中,观察待测项目是否正常。

后面需要冒烟上的优化做些什么呢,我想更多的还是从自动化上去着手,版本构建自动化,自动化冒烟测试等等。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持小熊分享邦(www.xxfxb.com),希望大家能坚持软件测试之路,谢谢。

赞(0) 打赏
未经允许不得转载:小熊分享邦 » 冒烟测试| 小熊测试

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏