近期在和一些研发团队沟通时，发现许多同学对于冒烟测试有一些理解的误区，CC先生就想来捋一捋这个概念。
误区一：开发不知道冒烟测试是干嘛的。
通常一提到冒烟测试，大家都习惯性的把关注点放在后面两个字:测试 ,开发的同学一听这个活动，很开心，这不是我们的活儿，应该是测试人员来完成的。真的是这样么？
先来看看维基百科上对冒烟测试的解释:
smoke testing is preliminary testing to reveal simple failures severe enough to, for example, reject a prospective software release. Smoke tests are a subset of [test cases] that cover the most important functionality of a component or system, used to aid assessment if main functions of the software appear to work correctly.[1][2] When used to determine if a computer program should be subjected to further, more fine-grained testing, a smoke test may be called an intake test.[1] Alternately, it is a set of tests run on each new build of a product to verify that the build is testable before the build is released into the hands of the test team.[5] In the DevOps paradigm, use of a BVT step is one hallmark of the continuous integration maturity stage.
冒烟测试这个名称的来历，最初是从电路板测试得来的。因为当电路板做好以后，首先会加电测试，如果板子没有冒烟再进行其它测试，否则就必须重新来过。
而在软件研发中，冒烟测试其实是微软首先提出来的一个概念，和微软一直提倡的每日build（构建版本）有很密切的联系。具体说，冒烟测试就是在每日build（构建版本）建立后，对系统的基本功能进行简单的测试。这种测试强调程序的主要功能进行的验证，而不会对具体功能进行更深入的测试。
冒烟只是这类测试活动更形象化一些的叫法，直接叫做BVT（Build Verification Testing）其实CC先生个人觉得更为贴切。
误区二：冒烟测试为一个测试阶段
有些团队在定制流程时会有一个阶段叫冒烟测试，但是就算不通过也会继续做后面其它部分的测试。就像平时进机场的时候机场口都会有个小哥哥或者小姐姐拿一个不知名的物体对你扫一次，大多数情况下旅客们都是面无表情的走过他们身边，扫就扫呗，又不少两斤肉。
实际上什么打火机啊，充电宝啊会在之后的安检过程才会被一一挑出来。
我们反过头来看当时微软提出来的这个概念，它的重点其实在于 daily build ，也就是说冒烟测试是随着每一次构建而走的，它应该是一个开关而不是一个研发流程中的测试阶段。
过，你可以继续后面的测试。
不过，直接返工等待下一次的构建。
这才是冒烟测试应有的态度。
误区三：冒烟测试需要把此次需求的主流程都走一遍
一些团队通常为了督促开发人员提高研发质量而把冒烟通过率作为一个衡量指标。CC先生认为出发点是极好的，实现手段上经常会有一点点小偏差。
冒烟测试主要是测试系统的主流程是否可用，如果这次的需求不涉及到太多主流程上面的更改，那真的有必要把这些案例都加入到冒烟测试中么？
最后，冒烟测试的最佳实践还是最好被自动化，在CI中每一个Build都自动的去执行主流程的测试，确保其是一个基本可用的版本。手工测试这事儿吧，西部世界都第二季完结了，你们还没醒悟么？
