初识冒烟测试

   网上搜索了下，大概是这样的。

   冒烟测试 smoke testing ，故名思议，测试的时间比较短，一袋烟的功夫就能测试完。它专门针对一个新的版本，对于要提交的版本进行冒烟测试。测试通过的话，该新版本正式进入测试阶段，若没有通过冒烟测试，则该版本打回给重新修改。

   对于测试中发现一个bug，提交后，开发人员开始修改，修改完，测试人员，针对修改的部分，以及系统中的相关的地方的测试的活动，就是冒烟测试。

    执行冒烟测试的流程：

    1.确定冒烟测试用例。测试经理和项目经理等相关人员从测试用例库中选择重要的测试用例，标记为冒烟测试用例。

    2.开发发布测试版本，测试人员执行冒烟测试。冒烟测试通过的话，正式进入测试阶段。反之，开发人员重新编译版本，直至通过。开发发布版本的时候需说明此次新增的功能模块有哪些，新增的功能模块的开发负责人，（这里不一定要有，根据公司情况，有的是由开发经理来分配bug。）修复的bug有哪些。

    3.报告冒烟测试。测试组执行完冒烟测试，编写本次冒烟测试的结果。接受本次版本或者拒绝本次版本，假如拒绝的话，需要说明失败的原因和详细的缺陷描述。

    总结：冒烟测试集合了项目中最重要的功能和模块，一旦出错，系统就陷于不能使用的境地，其严重性不言而喻，而每次提高测试版本的质量，也是成倍控制的一种方式，将测试前移，从源头做起，节省成本，提高产品质量的出路，先从冒烟测试做起。

（首先是测试针对需求来确定出当前测试内容的主要的功能和其中的主要的流程，即在测试用例中选中重要的测试用例，标记为冒烟测试用例。同时 跟开发人员确认出这个功能所要达到的效果。然后在开发推出新版本的时候，需要同时说明，就进行这些功能和流程的测试。若都通过，则正式的进入测试阶段。反之，开发对这个系统重新进行修改，测试人员将冒烟测试报告编写完毕，发给开发人员。）

   冒烟测试，其实很能节约测试所需要的时间，因为在测试过程中，会碰到很多的问题，情况不好的时候，就是开发没有时间自己测试，直接交给测试人员来测试，这样的话，半天功夫可以记录一堆bug，比如，新建按钮不起作用，比如，保存后，页面没有变化等等。这样是没有多大意义的。测试的成就也不能在这里体现出来。而一旦认真执行了冒烟测试，那么测试人员就有更多的时间来寻找更深层次的bug。

   冒烟测试一般是在版本变更时候进行。当然，部分模块修改，改好后进行测试，这个部分修改也算是小版本。新的问题又来了，这个需要版本控制，目前工作中没有明确涉及过版本的变更。只是有大版本的区分。

（——版本是如何控制的呢？——）