关于冒烟测试和回归测试的概念

鉴于之前跟开发提到提测前需要进行冒烟测试，然后几个开发一脸迷茫的问我：什么叫冒烟测试？所以我准备跟大家从以下几个方面简单的分享一下什么是冒烟测试。

一、软件测试的分类

1、按开发阶段：单元测试、集成测试、系统测试、验收测试
2、按测试实施组织：α、β、第三方
3、按测试执行方式：静态测试、动态测试
4、按是否查看代码：黑盒测试、白盒测试、灰盒测试
5、按是否手工执行划分：手工测试、自动化测试
6、按测试对象划分：性能测试、安全测试、兼容性测试、文档测试、易用性测试（用户体验测试）、业务测试、界面测试、安装测试
7、按测试地域划分：本地化测试、国际化测试

 

二、冒烟测试（Smoke Testing）的概念

        Smoke Testing 的概念最早源于制造业，用于测试管道。测试时，用鼓风机往管道里灌烟，看管壁外面是否有烟冒出来，以便检验管道是否有缝隙。这一测试显然比较初级，更深层一点的测试至少要进行渗油测试、带压测试等等。Smoke Testing 只是一种初级、直观的测试。

　　软件测试中的 Smoke Testing 实际上用的是其引申含义，而且是引申了不止一道的含义，在这里，Smoke Testing 其实是个俚语就跟很多其他源于美国软件行业的名词一样。

  　Smoke Testing 在软件测试中的意义，应该说取的是其原始概念中的目的而非手段。通过 Smoke Testing，在软件代码正式编译并交付测试之前，先尽量消除其表面的错误，减少后期测试的负担。因此可以说，Smoke Testing 是预测试。

       冒烟测试是指对提交测试的软件在进行详细深入的测试之前而进行的预测试，这种预测试的主要目的是暴露导致软件需重新发布的基本功能失效等严重问题。冒烟测试可以由开发人员执行，也可以由测试人员来执行。即，在版本编译后正式提交测试之前由开发人员执行；或开发发布版本后，测试人员在接受这个版本作为正式版本进一步测试前执行。

       微软提出在审查了变更的代码后，冒烟测试是确认修复的缺陷及功能变更是否有效的最经济有效的方法。冒烟测试能手动执行，也可以在版本编译后自动化执行，它是对基本功能的确认，非深入测试，但要覆盖到面，即所有的更改点都要进行确认。采用自动化执行是，可以结合每日构件后进行自动化的每日smoking test，如果测试通过，则把更改后的代码自动合并到主干代码仓库中，作为正式提交测试的版本。

三、冒烟测试可以实施的步骤

对于smoking test在软件开发过程中的应用，下面提出一种可实施的步骤：
1. 根据软件的变更，包括新需求的实现、bug修复，设计出更改满足预期的功能级checklist。

2. 准备好测试环境。如：软件的运行环境是嵌入式产品，如手机，数码相机，医疗仪器等，需准备好用户使用的真实运行环境。如果是windows平台运行环境，请准备干净的操作系统。

3.执行checklist，确认基本功能有效，足以支持更进一步的详细、全面测试。

四、冒烟测试的优缺点

冒烟测试就是在每日build建立后，对系统的 基本功能进行简单的测试。

冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。

SmokeTest优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低。 

五、冒烟测试（Smoke Testing）与回归测试（Regression testing）的区别

冒烟测试就是新版本送测后的测试，以决定是否要继续测试乃至发布。回归测试就是解决一个问题后的测试，方向是判断新的代码是否引入了新问题。冒烟测试一般用于每日构建(Nightly build)，构建服务器首先从CVS服务器上，下载最新的源代码，然后编译单元测试，运行单元测试通过后，编译可执行文件，可执行文件若可运行，并能执行最基本的功能，则认为通过了冒烟测试。而回归测试，是软件维护阶段对软件修改后进行的测试。两种测试用在软件生命的不同周期。

根据对冒烟测试和回归测试的理解，总结了二者的一些区别，如下：

	冒烟测试	回归测试
使用阶段	单元测试之后	软件维护阶段
测试侧重点	新版本送测后，对基本功能的粗略测试	解决一个问题后，判断是否引入新的问题
消耗时间	节省时间	消耗时间长
覆盖率	低	高
执行人	提测前是开发；版本上线前是测试	测试