冒烟测试,是微软首先提出来的一个概念,和微软一直提倡的每日build(构建版本)有很密切的联系。具体说,冒烟测试就是在每日build(构建版本)创建后,对系统的基本功能进行简单的测试。这种测试强调程序的主要功能进行的验证,也叫版本验证测试,提交测试。
冒烟测试这个名称的来历,是从电路板测试得来的。由于当电路板作好之后,首先会加电测试,若是板子没有冒烟在进行其它测试,不然就必须从新来过。相似的若是冒烟测试没有经过,那么这个build也会返回给开发队伍进行修正,测试人员测试的版本必须首先经过冒烟测试的考验。
冒烟测试的说法听说是:象生产汽车同样,汽车生产出来之后,首先发动汽车,看汽车可否冒烟,若是能,证实汽车最起码能够开动了。说明完成了最基本的功能。
冒烟测试通常用于每日构建(Nightly build),构建服务器首先从CVS服务器上,下载最新的源代码,而后编译单元测试,运行单元测试经过后,编译可执行文件,可执行文件若可运行,并能执行最基本的功能,则认为经过了冒烟测试,这时,构建服务器会把程序打包成安装文件,而后上传到内部网站,次日一早,测试人员来了之后,会收到构建服务器发来的邮件提示昨晚是否构建成功。若构建成功,则测试人员进行相关的功能测试。全部这些功能的完成,通常是靠编写脚本完成的,目前比较经常使用的脚本有TCL,PERL,PYTHON及功能弱弱的批处理。用这些能够完成系统的每日构建。
总的来讲,冒烟测试就是先保证系统能跑的起来,不至于让测试工做作到一半忽然出现错误致使业务中断。目的就是先经过最基本的测试,若是最基本的测试都有问题,就直接打回开发部了,减小测试部门时间的浪费。
而回归测试,是软件维护阶段对软件修改后进行的测试。
在软件生命周期中的任何一个阶段,只要软件发生了改变,就可能给该软件带来问题。软件的改变多是源于发现了错误并作了修改,也有多是由于在集成或维护阶段加入了新的模块。当软件中所含错误被发现时,若是错误跟踪与管理系统不够完善,就可能会遗漏对这些错误的修改;而开发者对错误理解的不够透彻,也可能致使所作的修改只修正了错误的外在表现,而没有修复错误自己,从而形成修改失败;修改还有可能产生反作用从而致使软件未被修改的部分产生新的问题,使原本工做正常的功能产生错误。一样,在有新代码加入软件的时候,除了新加入的代码中有可能含有错误外,新代码还有可能对原有的代码带来影响。所以,每当软件发生变化时,咱们就必须从新测试现有的功能,以便肯定修改是否达到了预期的目的,检查修改是否损害了原有的正常功能。同时,还须要补充新的测试用例来测试新的或被修改了的功能。为了验证修改的正确性及其影响就须要进行回归测试。服务器