冒烟测试（转）

　　冒烟测试一般基于Nightly build，构建服务器首先从CVS服务器上，下载最新的源代码，然后编译单元测试，运行单元测试通过后，编译可执行文件，可执行文件若可运行，并能执行最基本的功能，则认为通过了冒烟测试，这时，构建服务器会把程序打包成安装文件，然后上传到内部网站，第二天一早，测试人员来了以后，会收到构建服务器发来的邮件提示昨晚是否构建成功。若构建成功，则测试人员进行相关的功能测试。所有这些功能的完成，一般是靠编写脚本完成的，目前比较常用的脚本有 TCL，Perl，Python及功能弱弱的批处理。用这些可以完成系统的每日构建。

　　简单的说，就是先保证系统能跑的起来，不至于让测试工作做到一半突然出现错误导致业务中断。目的就是先通过最基本的测试，如果最基本的测试都有问题，就直接打回开发部了，减少测试部门时间的浪费

　　记得有一次面试中面试官问了我一个问题,谈谈什么是冒烟测试,我当时就傻了,估计人家从这个问题中就得出结论,我还是个新手,也许测试还没入门呢!不过只有跌倒过一次,才不会再次在原来的地方跌倒,不然那样就太糟糕了.就因为这样我回去好好翻了翻资料,把冒烟测试理清楚了,原来如此!

      冒烟测试,严格来说就是一个基本功能点的验证测试,可能是我在上家公司的产品质量不怎么样的缘故吧,我们做得比较多的是冒烟测试,每次只要开发人员一提交测试版本到测试部门,我们会严格按照冒烟测试的流程和标准来执行,一旦基本功能点不通过,我们将不予受理测试任务,并可以保留对开发人员的上诉意见,虽然我们每次执行的不是很严格,但每次总会做这么一个过程.不是为了针对谁,而且版本测试必须要有这样一个冒烟测试的过程来约束开发人员,让他们洁身自好,真正负责任的去做产品,帮助开发人员提高自身的质量意识,从而可以更有效的提高产品的质量,和版本发布速度.也许说,效率是要靠团队来推动的.

     下面我想具体说说冒烟测试如何执行,并且如何规范标准,还有就是该由谁来做?

     冒烟测试必须在每次提交新的测试版本前执行,且执行规范需根据需求设计文档来要求,开发在每次接受新的开发需求时,必须按照需求文档严格整理出冒烟测试点,也就是基本功能点,毕竟这些功能点都是开发人员要完成的,可能会认为这个工作不重要,如果整理出了这些基本功能点,就不会导致后期版本发布时出现功能遗漏,或者功能实现有缺陷等等问题,只有将所有的问题保留在前期的需求评审阶段,才能更有效率完成用户的需求,后期出问题的几率也就大大降低.

     冒烟测试的规范,其实冒烟测试规范取决于人,而不在于流程,如果需求分析做的很细致,就不可能不规范,就不会冒烟标准,更不会存在争议的问题所在,所以这就需要开发在设计阶段对需求的把握,要实现什么样的功能,达到什么样的效果,其实开发在做之前是有预想的,但是到底是否符合用户的需求,就要看跟用户的需求沟通和评审,所以这里所说的准备还是由设计阶段产生的冒烟测试点,然后定义实现的情况,并给出最后评审.当然不同的项目是不一样的,但是准则是冒烟测试不通过,产品是不能提交给测试人员测试的,因为它不具备测试条件.

     冒烟测试的执行到底该由谁来做,我们以前公司也经常碰到这样的矛盾,其实开发人员不愿意做测试是事实,但是提高产品的质量最后还是由开发人员自己来完成,这一点测试人员也无能为力,但如何才能让他们体会到这一点呢.那就需要通过严格的考核标准来推动,有压力才有动力,这个准则任何时候都是有效果的.其实严格来说,测试人员肯定是要做冒烟测试的,因为这是测试流程中的首要阶段,也是必要条件之前,测试人员执行冒烟测试不通过,就说明版本不具备测试条件,重新发回给开发人员.但是如果每次都出现这种问题,因为冒烟测试不通过而打回原形必然回耽误大家的时间,而为了节省这个时间,提高版本发布的效率,那就需要开发人员自己做冒烟测试,只有开发在提版本之前做一个版本自身体检,才能让这个版本健康的发布出去,这样才会有效的提高大家的工作效率,开发人员做冒烟测试是应该,因为这也是对自身工作负责任的一种态度,通过冒烟测试他们能够检查一次那些需求没有实现,是有遗漏的,就不会将原本就无效的版本发给测试,导致最后还要被发回重申,既浪费时间,又大大降低效率,何必呢?

      所以说任何一个理论的诞生都是有它的依据和道理的,虽然麻烦一点,但是效率提高了很多,何乐而不为呢!