说起冒烟测试大家都觉得很重要，但是冒烟测试应该如何做呢？
冒烟测试真的是看看是不是“冒烟”
冒烟测试这个名称的来历，最初是从电路板测试得来的。因为当电路板做好以后，首先会加电测试，如果板子没有冒烟再进行其它测试，否则就必须重新来过。第一个讲这个概念引入软件制品流程中的是微软公司，在微软引入冒烟测试是为了解决每日构建的质量验证问题。当每日构建完成后，通过冒烟测试对系统的基本功能进行简单的测试。可以看出，冒烟测试强调对主要功能进行验证，而不是大而全的测试。我们常说的BVT测试（Build Verification Testing）其实是冒烟测试的另外一种叫法。
我相信有很多人会反驳，BVT是BVT，冒烟测试是冒烟测试，不是一回事，这两个概念是不是相等在行业内也有两种观点，大家各执一词，我更倾向于这两个名词就是一个概念的说法。
冒烟测试选取测试用例原则
冒烟测试是指初步的进行测试，并以此展示那些足以影响系统发布的错误，因此冒烟测试的测试用例应该是测试用例集的一个子集，主要是为了覆盖一些系统或者组件的重要功能而设计的，主要评价一个系统是否能正常运行。这也决定了冒烟测试的测试用例测试粒度不能太小，也不能太深入。在冒烟测试用例设计中，除去选取此次变更更加关注的业务流程外，更应该包含一些基本问题的验证，例如：“程序是否运行？”，“用户界面是否打开？”或“单击事件是否有效？”等。
如《 Lessons Learned in Software Testing》所写，“冒烟测试仅仅是在短时间广泛地覆盖产品功能。如果关键功能无法正常工作或关键bug尚未修复，那么你们的团队就不需要浪费更多时间去安装部署以及测试。”
冒烟测试设计方法
冒烟测试是在通过开发域的质量门禁后就马上开始的测试，如果冒烟测试失败，那么就应该给出最基本问题判断，这样才能快速的解决最根本的问题，那么这些诊断信息类似被测系统无法应用是外部依赖服务没有启动而导致的。这部分可以结合自动化测试误报来解决。
冒烟测试通常会快速地进行，好处就是反馈也是很快，因此这部分并不要大而全的测试设计，而是应该有错侧重。并且冒烟测试用例也不是一成不变的，也是随着每一次比变更的交付而不断变化的。
