谈冒烟测试

        冒烟测试，刚进公司就接触到了。只是刚开始一直没有体会到冒烟的含义和精髓，一直觉得是冒烟测试就是把待测产品的主要功能测试一下就好了。后面回想一下，不是那么回事的。
        冒烟测试源自硬件行业，对一个硬件或者硬件组件改动后，直接给设备加电，看看设备会不会冒烟，没冒烟，就表示待测组件是经过了测试。
        在软件开发过程当中，一直有高内聚、低耦合这样的说法，各个功能模块之间的耦合仍是存在的，所以一个功能的改动，仍是会影响到其余功能模块。                                                                                                               所以在开发人员修复了先前测试中发现的bug后，想知道这个bug的修复是否会影响到其余功能模块，须要作的就是冒烟测试。                                                                                                                                                  搞清楚冒烟测试的起源，冒烟测试的目的后，不难想到，冒烟测试是这样的一种测试，不要求覆盖面有多广，但至少要保证覆盖待测产品的绝大部分功能；不要求每一个功能都测的很详细，但至少要保证被修复了的bug所属的功能和系统其余骨干功能都是可用的（即这个版本能拿去作系统功能测试了）。
        而要作到覆盖骨干功能和bug所属功能，却不是简简单单在页面中点几下就好了的。任何一个项目或者产品，骨干功能都有它的使用场景。冒烟测试就是要保证这些骨干功能的使用场景都能跑通，若是没跑通，后续的系统测试就不必了。
        其实作冒烟测试以前，都已经作了一个简单的安装部署测试了（你不安装部署，哪里来东西测呢）。按我本身的理解，其实这块也能够放入冒烟测试范畴的。想一想看，安装部署是否是很相似电路板加电，让电路板开始工做呢？然后面的骨干使用场景测试，只是在这个基础上作的后续工做。若是安装部署后，待测产品跑到一半就down掉了，后面的骨干功能的使用场景还测个屁呀。
        使用场景的是否能跑通的测试，不须要测一些异常的状况，保证基本功能覆盖到就好了。一般，冒烟测试是交给开发人员去作的。只有确认了功能可用后，交给测试人员去作才有意义。刚开始进公司时，小组里面有我的不作冒烟，只把他修改了的部分简单测了下，就交给我这边去测试。结果就是我测试到一半，发现有个很重要的功能用不了。这个时候，测试只要停止了。时间久了，你们对产品质量和测试工做有了必定认识（最主要是你们不急急忙忙地加班了，^__^ ），对我也有了必定的承认，所以作事也愈来愈正规了。如今咱们小组的作法是，小组里面每一个人扮演产品使用场景中的一个角色，而后你们一齐分工去完成每一个场景里面各自角色要完成的任务，在这个过程当中，观察待测项目是否正常。
        后面须要冒烟上的优化作些什么呢，我想更多的仍是从自动化上去着手，版本构建自动化，自动化冒烟测试等等。