冒烟测试（转）

http://tech.ddvip.com/2009-04/1239695756114957.html

 

上大学的时候在课本里见过冒烟测试这个概念，感觉很深奥：有人形象地类比新电路板功基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷，电路板可能会短路，板子冒烟了。后来上网看冒烟测试是测试人员每天早上在正式测试之前，先跑下主流程，走得通再进行一天测试工作。等自己实际投入工作，发现公司针对自己实际情况会对冒烟测试有新的诠释。

　　通过自己亲身参与几个项目之后，对冒烟测试有了一些体会。能够做好一个快而且准的冒烟测试，我觉得要注意以下几点：

　　一、冒烟测试的准备工作

　　1、主流程和主功能的确认

　　因为我们公司的冒烟测试是测试在正式进入三轮之前对整个项目的主流程地验证，如果主流程不通过，是不可以开始正式测试的。这点就要求测试人员对自己项目的整体把握程度要强，在前期了解清楚需求后，把最重要的流程和功能列举出来，在冒烟测试前和开发人员一一确认，这对于冒烟测试是非常重要的一环。最好能够将功能点和流程在冒烟测试时要的预期结果和开发人员说明清楚。（虽然冒烟测试不像正式进入测试阶段要求测试结果那么准确，但是冒烟测试也最好列一个指标。有指标我们才能测衡量试是否通过。）

　　2、预计冒烟测试的最短和最大时间

　　根据列出来的功能点和开发人员以往提交测试人员代码质量的可信度，评估下冒烟测试在不同环境下可能花费的最大时间和最小时间，然后列到测试计划中。

　　3、冒烟测试数据的准备

　　必须在前期对主要功能对应表的结构都了解地很透彻，需要准备的数据及时准备好。真正冒烟测试开始后，就不会因为准备数据或者了解表存储结构而浪费时间。

　　二、冒烟测试的执行工作

　　测试工程师严格按照前期的约定去校验主流程，全部校验完和开发人员报告情况！这个阶段其实在考验测试工程的执行能力，1就是1，2就是2，不可以马虎。可能放过一个主要的测试功能点，都可以对后面的测试进度有所影响，从而影响软件质量。

　　三、冒烟测试的总结工作

　　冒烟测试结束后的报告很重要，在报告里将冒烟情况说明：

　　1、时间：冒烟测试是否按时完成？按时完成皆大欢喜；但有延误的话，要分析这段时间是不是会对后面正式测试的时间有影响。如果影响比较大可以给开发提建议，看后期有什么补救的方法可以既保证了质量又保证了按时上线，比如提高开发人员修复BUG的效率，测试时间顺延等。

　　2、问题：分析冒烟测试中发现的问题，和开发人员强调这个影响主流程的问题在冒烟修复验证通过后，不能在正式测试中再次出现，否则加大测试人员重复验证的工作量，影响测试进度。

　　对于一个小项目，也许冒烟测试只是花费2，3个小时就结束了，但是冒烟测试是麻雀虽小，五脏六腑全有。从前期确认主要功能，到最后的总结报告，我觉得每个流程都不能马虎，只有都准备好了，才能真正意义达到“冒烟测试”意义：仅用一袋烟功夫完成测试。

 

http://www.enet.com.cn/article/2007/0423/A20070423555102.shtml

关于冒烟测试，应该是微软首先提出来的一个概念，和微软一直提倡的每日build有很密切的联系。具体说，冒烟测试就是在每日build建立后，对系统的基本功能进行简单的测试。这种测试强调功能的覆盖率，而不对功能的正确性进行验证。从这一点看和所谓的“接受性（验收）测试（Acceptance Test）”非常相似。不同之处就在于他们执行的频率和被测的版本不同。

　　至于冒烟测试这个名称的来历，大概是从电路板测试得来的。因为当电路板做好以后，首先会加电测试，如果板子没有冒烟在进行其它测试，否则就必须重新来过。类似的如果冒烟测试没有通过，那么这个build也会返回给开发队伍进行修正，测试人员测试的版本必须首先通过冒烟测试的考验。

　　冒烟测试的说法据说是：

　　就象生产汽车一样，汽车生产出来以后，首先发动汽车，看汽车能否冒烟，如果能，证明汽车最起码可以开动了。说明完成了最基本的功能。

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

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