冒烟测试

一.冒烟测试是干嘛的

通常一提到冒烟测试，大家都习惯性的把关注点放在后面两个字:测试 ,开发的同学一听这个活动，很开心，这不是我们的活儿，应该是测试人员来完成的。真的是这样么？

冒烟测试这个名称的来历，最初是从电路板测试得来的。因为当电路板做好以后，首先会加电测试，如果板子没有冒烟再进行其它测试，否则就必须重新来过。

file

而在软件研发中，冒烟测试其实是微软首先提出来的一个概念，和微软一直提倡的每日build（构建版本）有很密切的联系。具体说，冒烟测试就是在每日build（构建版本）建立后，对系统的基本功能进行简单的测试。这种测试强调程序的主要功能进行的验证，而不会对具体功能进行更深入的测试。

冒烟只是这类测试活动更形象化一些的叫法，直接叫做BVT（Build Verification Testing）其实CC先生个人觉得更为贴切。

二.冒烟测试不是一个测试阶段

有些团队在定制流程时会有一个阶段叫冒烟测试，但是就算不通过也会继续做后面其它部分的测试。就像平时进机场的时候机场口都会有个小哥哥或者小姐姐拿一个不知名的物体对你扫一次，大多数情况下旅客们都是面无表情的走过他们身边，扫就扫呗，又不少两斤肉。

实际上什么打火机啊，充电宝啊会在之后的安检过程才会被一一挑出来。

我们反过头来看当时微软提出来的这个概念，它的重点其实在于 daily build ，也就是说冒烟测试是随着每一次构建而走的，它应该是一个开关而不是一个研发流程中的测试阶段。

过，你可以继续后面的测试。不过，直接返工等待下一次的构建。这才是冒烟测试应有的态度。

三.不需要从头就开始测试

一些团队通常为了督促开发人员提高研发质量而把冒烟通过率作为一个衡量指标。CC先生认为出发点是极好的，实现手段上经常会有一点点小偏差。

冒烟测试主要是测试系统的主流程是否可用，如果这次的需求不涉及到太多主流程上面的更改，那真的有必要把这些案例都加入到冒烟测试中么？

最后，冒烟测试的最佳实践还是最好被自动化，在CI中每一个Build都自动的去执行主流程的测试，确保其是一个基本可用的版本。当这个单独job确实没问题后，再归类到一个大版本中，去进行详细的测试流程。