什么是冒烟测试
冒烟测试，英文名称smoke test，在国际软件测试工程师认证（ISTQB）基础级大纲中的定义是：所有定义的或计划的测试用例的一个子集，它覆盖组件/系统的主要功能，以查明程序的绝大部分关键功能是否正常工作，但忽略其细节部分。
冒烟测试的同义词
冒烟测试的同义词包括置信测试（confidence test）、健全性测试（sanitytest）、验证测试（verificationtest）、预测试（intaketest）。
冒烟测试的来源
冒烟测试这一术语来源于硬件行业。
冒烟测试最初是从电路板测试得来的。当电路板做好以后，首先会直接做加电测试，如果没有冒烟，再进行其它测试，否则就必须重新来过。电路板上冒烟测试时间非常短，就是“一哧溜”的时间，也许就1秒钟。
在软件研发中，冒烟测试据说是来源于微软（《微软项目求生法则》），它和微软一直提倡的每日构建（build）有很密切的联系。冒烟测试是在每日构建（build）后，对系统的基本功能进行简单的测试，这种测试强调对程序的主要功能进行验证测试，而不会对具体功能进行更深入的测试。
每日构建（build）后的冒烟测试，如果采用自动化的执行方式，执行时间也很短，通常是几秒钟，最多是几分钟的时间。
冒烟测试的形象化理解
有人认为，冒烟测试耗时短，仅用“一袋烟功夫”足够了。
也有人认为，软件中的冒烟测试是形象地类比了电路板基本功能检查。任何电路板焊好后，先通电检查，如果存在严重缺陷，电路可能就会短路，板子“冒烟”。
无论何种说法，在软件中，冒烟测试只是这类测试活动的形象化叫法，直接叫版本验证测试（Build Verification Testing）也许更为贴切。
冒烟测试的用途
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，是针对软件版本包进行详细测试之前的预测试。
执行冒烟测试的主要目的是快速确认软件基本功能正常，可以进行后续的正式测试工作。如果冒烟测试的测试例不能通过，则不必做进一步的测试。
冒烟测试是在软件开发过程中的一种针对软件版本包的快速基本功能验证策略，是对软件基本功能进行确认验证的手段，并非对软件版本包的深入测试。
冒烟测试的价值
冒烟测试是业界的最佳实践。一个好的冒烟测试过程，对于软件测试效率的提升具有重要意义。
（1）冒烟测试可以快速检验软件的基本质量是否达到要求。
通过冒烟测试，能够快速确认软件是否具备测试准入条件，避免出现正式测试阶段全面开展后才发现阻塞型缺陷等严重影响测试进度浪费人力物力的情况。
（2）冒烟测试可以帮助测试人员熟悉测试流程。
通过冒烟测试，测试人员可以迅速熟悉测试总体流程。一方面有助于测试人员准确制定测试时间计划，合理安排工作进度；另一方面也有助于测试人员提前做好相关设备、数据的准备，为正式测试的开展奠定基础。
（3）在原代码改动之后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。
冒烟测试与正式测试的区别
冒烟测试与正式测试的区别在于二者侧重点不同，冒烟测试关注的是阻塞型缺陷，包括但不限于流程不通、主要功能未实现等，而正式测试则属于全面、细致的测试，需要尽可能的发现全部缺陷并按其严重性进行区分。
冒烟测试的注意事项
冒烟测试过程中，需要注意的点包括：
1、选择合适的冒烟测试用例
进行冒烟测试之前，需要确定冒烟测试的用例集，冒烟测试用例集要覆盖软件的基本功能。通过冒烟测试，可以确保后续的测试流程没有严重、阻塞性的问题。
由于冒烟测试的时间一般都比较短，冒烟测试的用例不宜太多，一般建议在总用例数的10-15%之间。
一些测试团队通常为了督促开发人员提高研发质量，把冒烟通过率作为一个衡量指标。他们可能会选择较多的测试用例，把一些不涉及到主流程的测试用例也纳入冒烟测试范围，导致冒烟测试难于通过。我认为，这种“过渡”的冒烟测试与冒烟测试的根本目的是相违背的，不利于整体项目的开展，也容易引起开发团队与测试团队的对立。
2、测试与开发协同
冒烟测试阶段，有几个特点，
一是该阶段软件可能存在较多缺陷，特别是阻塞型缺陷，测试工作随时可能陷入停滞状态；
二是该阶段测试人员对软件的流程、功能等熟悉程度较低，难免会出现找不到合适的测试方法，甚至是找不到功能模块的情况，从而延迟测试进度；
三是该阶段的时间在软件生命周期中所占的时间比例较低，冒烟测试具有注重通过性、轻细节的特点，这就需要开发人员实时响应，尽快解决各类问题。
因此，在冒烟测试阶段，测试人员与开发人员的协同工作十分重要。
3、注重效率
冒烟测试应以效率为先，尽量缩短测试时间，提高测试效率。
冒烟测试要在关注主流程、重点功能的前提下，抓关键缺陷，对于诸如页面不美观、用户体验不佳等缺陷，可在冒烟阶段有选择的予以过滤（放过）。
4、通过冒烟测试评估测试用例，完善测试用例
冒烟测试过程同时也是对测试用例进行评估的一个过程。测试人员要充分利用这一阶段，对前期形成的测试用例进行检验，及时对测试用例进行完善，使测试用例更贴合实际，更具有可执行。
5、选择合适的冒烟测试执行方式
冒烟测试可以手动执行，也可以自动化执行。
稳定的系统适合自动化冒烟测试，集成过程中的系统适合手工冒烟测试。集成过程中的系统往往不够“稳定”，导致维护自动化测试用例的代价比较大，故一般适合通过手工执行的方式进行自动化测试。
如果能做到自动化，将冒烟测试集成到持续集成中，版本构建完成后，立即执行冒烟测试。根据持续集成以及冒烟脚本的执行结果，判断版本是否哦可用，是否继续开展测试。
6、冒烟测试用例需要不断更新
冒烟测试的用例应根据版本变化，持续的进行优化和更新。
此外，可以将冒烟测试失败的次数、失败的原因记录下来，开发周期结束后，反向推动开发质量的改进。
文章来自网络，侵权联系删除！！
网友评论