前言
冒烟测试就是完成一个新版本的开发后，对该版本{BANNED}{BANNED}最佳佳基本的功能进行测试，如果通过测试，才会进行下一步的测试(功能测试，集成测试，系统测试等等)。冒烟测试的目的就是为了减小 软件的测试成本！试想一下，如果完成的一个版本，不去做冒烟测试，而是直接去做余下的测试，做着做着发现做不下去了，因为测试过程中发现{BANNED}{BANNED}最佳佳基本的业务功能模块都存在bug，更别说相关的其他功能模块了，更别说集成测试等其他测试了，而bug发现的越早其修复bug所耗费的成本越低，如果不做冒烟测试，可以想象成本代价风险多高！
回归测试我有两层理解，一是就是当你修复一个bug后，把之前的测试用例再次应用到修复后的版本上进行测试。二是当一个新版本开发好后，而且冒烟测试通过，此时可以先用上一个版本的测试用例对新版本进行测试，看是否有bug！其实回归测试用的很多，比如新增加一个功能模块等等，所以自动化测试可以高效率的进行回归测试。
近期在和一些研发团队沟通时，发现许多同学对于冒烟测试有一些理解的误区，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.
冒烟测试这个名称的来历，{BANNED}{BANNED}最佳佳初是从电路板测试得来的。因为当电路板做好以后，首先会加电测试，如果板子没有冒烟再进行其它测试，否则就必须重新来过。
图1 冒烟的电路板.jpg
而在软件研发中，冒烟测试其实是微软首先提出来的一个概念，和微软一直提倡的每日build（构建版本）有很密切的联系。具体说，冒烟测试就是在每日build（构建版本）建立后，对系统的基本功能进行简单的测试。这种测试强调程序的主要功能进行的验证，而不会对具体功能进行更深入的测试。
冒烟只是这类测试活动更形象化一些的叫法，直接叫做BVT（Build Verification Testing）其实CC先生个人觉得更为贴切。
二、误区二：冒烟测试为一个测试阶段
误区二：冒烟测试为一个测试阶段
有些团队在定制流程时会有一个阶段叫冒烟测试，但是就算不通过也会继续做后面其它部分的测试。就像平时进机场的时候机场口都会有个小哥哥或者姐姐拿一个不知名的物体对你扫一次，大多数情况下旅客们都是面无表情的走过他们身边，扫就扫呗，又不少两斤肉。
实际上什么打火机啊，充电宝啊会在之后的安检过程才会被一一挑出来。
图2 安检中.png
我们反过头来看当时微软提出来的这个概念，它的重点其实在于 daily build ，也就是说冒烟测试是随着每一次构建而走的，它应该是一个开关而不是一个研发流程中的测试阶段。
过，你可以继续后面的测试。
不过，直接返工等待下一次的构建。
这才是冒烟测试应有的态度。
三、误区三：冒烟测试为一个测试阶段
误区三：冒烟测试需要把此次需求的主流程都走一遍
一些团队通常为了督促开发人员提高研发质量而把冒烟通过率作为一个衡量指标。CC先生认为出发点是极好的，实现手段上经常会有一点点小偏差。
冒烟测试主要是测试系统的主流程是否可用，如果这次的需求不涉及到太多主流程上面的更改，那真的有必要把这些案例都加入到冒烟测试中么？
{BANNED}{BANNED}最佳佳后，冒烟测试的{BANNED}{BANNED}最佳佳佳实践还是{BANNED}{BANNED}最佳佳好被自动化，在CI中每一个Build都自动的去执行主流程的测试，确保其是一个基本可用的版本。
阅读(444) | 评论(0) | 转发(0) |
