测试中有个有意思的测试：冒烟测试。不同于随机测试，冒烟测试侧重于前置动作。

　　套用我曾写过一片文章的段落来解释一下软件测试中的冒烟测试：

　　冒烟测试，是指在每日build建立后，对系统的基本功能进行验证的测试。冒烟测试这个名称的来历是从电路板测试得来的：当电路板做好以后，首先会加电测试，如果板子没有冒烟再进行其它测试，否则必须重新来过。如果冒烟测试没有通过，那么这个build也会返回给开发队伍进行修正，测试人员测试的版本必须首先通过冒烟测试的考验。

　　在软件测试工作中，开发每天都对已完成的源程序进行编译，然后连接组合成可执行的程序。冒烟测试不必面面俱到的，但是应该能够发现系统中较大的问题。通过了冒烟测试的build可以认为是经过充分测试、足够稳定的。这种测试强调功能的覆盖率，而不对功能的正确性进行验证，其目的是先通过基本的测试，如果基本的测试都有问题，可以直接打回开发部，从而减少测试部门时间的浪费。

　　如何有效的展开手机软件的冒烟测试：

　　1.启动每日构建；

　　2.制定测试用例；

　　3.SCM搭建环境，进行自动化编译；

　　4.测试人员接收版本下载 - 执行测试用例；

　　5.根据代码变更单验证开发人员修改故障；

　　6.统计相关数据。

　　站在测试人员的角度，首先如何制订一个好的测试用例。三种思路，三个方案：

　　1.测试套用正交表，运用正交法制定一套测试用例；

　　2.开发用正则表达式，提炼出一套测试用例；

　　3.以上两种方案，运用优选法制定一套测试用例。

　　无论采用哪种方案，都需要研发和测试人员共同进行评审，至于用例的效果可以从：测试覆盖率、测试有效率、重要功能测试有效率来进行量化结果。

　　如何能在冒烟测试执行中发现更多的bug:

　　利用代码变更单，没有代码变更代的冒烟做起来没有意义，首现能从代码变更单中看到更改的内容，其次根据代码变更单对修改点进行验证性测试，后也是重要的，根据修改点进行发散测试。

　　如何让冒烟测试用例维护起来:

　　基线项目可以将现有较好的冒烟测试用例作为产品基线冒烟测试用例。此后，随着版本更新、对bug的修改、新增模块等变化，逐渐会有一些测试用例会失去针对性和有效性，也有些测试用例会完全不适用，都需要测试用例管理员或相关人员进行维护，并追加新的测试用例。

　　当新的项目准备启动时，测试用例管理员需要及时删减测试用例中不适用的、冗余的用例。在获得新项目差异需求后，组织有经验的同事开发新的、有针对性的测试用例，提高冒烟测试用例的可用性和有效性。由测试经验和用例编写经验丰富的同事承担这项工作，以便把控冒烟测试用例的质量。

　　关于用例的建设：

　　1.测试用例管理员与开发经理沟通确认新增功能点；

　　2.确定原有用例中有哪些在新项目上仍然有效，删除不再适用的测试用例，由此建立一套新的测试用例.

　　测试用例管理员组织编写完成新增用例，并加入测试用例中，形成与新项目相配套的完整冒烟测试用例。新增用例用于测试与基线项目的差异之处。这部分的测试用例也可以独立成库，专门用于测试差异化需求，有利于保障基线版本之外的软件测试质量；

　　在测试用例的设计过程中，由测试用例管理员组织内部讨论和评审。在测试用例完成编写后，测试用例管理员需要发起同行评审，或邀请开发人员、项目经理开会评审，通过后，才能够正式发布使用。

　　对于第三方的软件不建议加入冒烟测试，专项测试更好。