第一次碰到这个单词是在入职笔试的时候。以前一直在日企干开发的工作，对于这个词还真没有太深刻的认识，当时误认为是压力测试，今天总算找到正解，纠正错误认识。
冒烟测试的由来：
smoke test(冒烟测试)最初源自微软以及很多大的软件公司，"daily build and smoke test" -- 即每天自动编译及smoke test，这里的smoke test仅仅是一个简单的测试，看看我们编译好的产品是否“冒烟”以检查每天编译的结果是否成功。 具体来说，冒烟测试就是在每日构建完成后，对系统的基本功能进行简单的测试。这种测试强调功能的覆盖率，而不对功能的正确性进行验证。
smoke test可以极大的减少集成失败的风险。 带来的好处 虽然这是一个非常简单的过程，但却有非常重要的意义： 1、能最小化集成风险 项目组可能 遇到的一个很大的风险是，项目组成员根据不同的系统功能各自开发不同的代码，但是当这些代码集成为一个系统的时候，也许系统完成不了预期的功能。这种风险 的发生取决于项目中的这种不兼容性多久才被发现，由于程序界面已经发生了变化，或者系统的主要部分已经被重新设计和重新实现了，相应的排错工作将非常困难 和耗时。极端情况下，集成的错误可能会导致项目被取消掉。每日构造和冒烟测试可以使这种集成错误变得非常小，而且便于解决，防止了很多集成问题的产生。 2、能减小产品低质量的风险 这种风险是和集成不成功、集成出错相关联的。每天对集成的代码做一些少量的冒烟测试，即可杜绝项目中那些基本的质量问 题。通过这种方式，使系统达到一种周知的良好状态，维护这样的系统可以防止系统逐步恶化到耗费大量时间排查质量问题的地步。 3、能简单化错误诊断 当系统每天都进行build和测试时，系统任何一天发生的错误都能够变得十分精细，便于排查。比如在17日系统还运行正常，18日就出错了，那么只需要检 查这两次build之间的代码变化就可以了。 4、能极大鼓舞项目组的士气 看到产品的不断成长，能够极大的鼓舞项目组的士气，有时甚至不管这个产品 到底用来做什么。开发人员可能会为系统显示了一个矩形而感到激动。通过每日构造，产品每天进步一点点，保证项目士气的持续高涨。
至于冒烟测试这个名称的来历，大概是从电路板测试得来的。因为当电路板做好以后，首先会加电测试，如果板子没有冒烟在进行其它测试，否则就必须重新 来过。类似的如果冒烟测试没有通过，那么这个build也会返回给开发队伍进行修正，测试人员测试的版本必须首先通过冒烟测试的考验。 冒烟测试的说法据说是： 就象生产汽车一样，汽车生产出来以后，首先发动汽车，看汽车能否冒烟，如果能，证明汽车最起码可以开动了。说明完成了最基本的功能。 冒烟测试一般用于每日构建(Nightly build)，构建服务器首先从CVS服务器上，下载最新的源代码，然后编译单元测试，运行单元测试通过后，编译可执行文件，可执行文件若可运行，并能执 行最基本的功能，则认为通过了冒烟测试，这时，构建服务器会把程序打包成安装文件，然后上传到内部网站，第二天一早，测试人员来了以后，会收到构建服务器 发来的邮件提示昨晚是否构建成功。若构建成功，则测试人员进行相关的功能测试。所有这些功能的完成，一般是靠编写脚本完成的，目前比较常用的脚本有 TCL，Perl，Python及功能弱弱的批处理。用这些可以完成系统的每日构建。 简单的说，就是先保证系统能跑的起来，不至于让测试工作做到一半突然出现错误导致业务中断。目的就是先通过最基本的测试，如果最基本的测试都有问题，就直 接打回开发部了，减少测试部门时间的浪费。