为什么进行冒烟测试？

为什么进行冒烟测试？

为什么进行冒烟测试？软件测试从业者都知道，bug发现得越晚，修复bug的成本就越高。那成本高在哪里呢？

1、影响的代码多，开发的修复成本会增加。

2、影响的功能范围较大，测试回归的范围增加。

3、容易引发更多的bug，拉长测试周期，还有质量风险。

4、更多的bug，会增加bug的提交、沟通成本。

所以，如何尽早发现bug，把bug置解决是降低成本和控制止风险的有效方式，也是QA的主要职责之一。因此使用冒烟测试的方式，对开发提测的代码进行审查，找出那些非常浅显的bug是很有必要的

冒烟测试特点

1、这种测试强调程序的主要功能进行的验证，而不会对具体功能进行更深入的测试。

2、冒烟测试是随着版本转测进行的，它应该是一个开关(判断版本能否转测试)而不是一个研发流程中的测试阶段。

3、冒烟测试用例一般选取的是测试用例中level 0的用例，保证主功能可用。

4、冒烟测试就是在一个新版本出来的时候，将软件的全部功能过一遍，看有没有什么大问题。如果功能可以正常运行，不会影响测试进行，那么这个版本就可以真正开始测试了。如果功能有重大问题或影响测试进行，那么这个版本就是不合格的，不用进行进一步的测试。

冒烟测试可以在软件开发周期中发现并解决潜在缺陷或存在的错误，从而确保软件的质量，减少后续测试成本。同时，它也能够提高开发团队的效率，帮助团队更快地确定软件版本的可靠性，以便及时调整开发策略。

冒烟测试分类

冒烟测试的对象是每一个新编译的需要正式测试的软件版本。通过冒烟测试，在软件代码正式编译并交付测试之前，先尽量消除其表面的错误，减少后期测试的负担。冒烟测试的执行者是版本编译人员，因此可以说，冒烟测试是预测试，在实际的软件测试工作中，冒烟测试在软件研发的不同阶段有所不同。大体可以分为三类：

1、形成集成测试版本以前：验证各个单元能够成功执行，并保证测试版本能够顺利集成；

2、形成集成测试版本：以保证新的或者更改过的代码不破坏集成版本的完成性和稳定性；

3、后期预测试缺陷的修正：针对每个缺陷所做的缺陷修正都要先在干净的链接环境中进行冒烟测试，测试通过后才能更新相关软件版本。

冒烟测试注意事项

冒烟测试执行，与正式测试的区别在于二者侧重点不同，冒烟测试关注的是阻塞型缺陷，包括但不限于流程不通、主要功能未实现等，而正式测试则属于全面、细致的测试，需要尽可能的发现全部缺陷并按其严重性进行区分。冒烟测试过程中，需要注意的是：

1、开发协同

冒烟测试阶段有几个特点：

一是该阶段软件可能存在较多缺陷，特别是阻塞型缺陷，测试工作随时可能陷入停滞状态；

二是该阶段测试人员对软件的流程、功能等熟悉程度较低，难免会出现找不到合适的测试方法甚至是找不到功能模块的情况从而延迟测试进度；

三是该阶段的时间一般仅占整个软件生命周期的极小部分，这就需要开发人员实时响应，尽快解决各类问题。因此，在冒烟测试阶段，测试人员与开发人员的协同工作十分重要。

2、注重效率

冒烟测试应以效率为先，尽量缩短测试时间提高测试效率。要在关注主流程、重点功能的前提下，抓关键缺陷验数据准备，对于诸如页面不美观、用户体验不佳等缺陷可在冒烟阶段有选择的予以过滤。例如：测试系统登录，关注点应针对用户名、密码、校验码的输入及提交完成，对于非法字符的校验、登录框是否美观、错误提示是否准确等均属于次要关注点，不纳入冒烟测试范围。

3、评估用例

冒烟测试过程同时也是对测试用例进行评估的一个过程，要充分利用这一阶段，对前期形成的测试案例进行检验，及时对案例进行补充、删减和修订，使案例更贴合实际，更具有可执行。

冒烟测试实现

开展冒烟测试工作有助于尽早发现软件代码存在的问题，提高软件代码的质量和开发效率。

基于持续集成(Continuous Integration，CI)的冒烟测试采用自动化测试脚本进行测试工作，能够提高测试效率，减少测试人员大量的重复测试验证工作。

冒烟测试的最佳实践还是最好被自动化，在CI中每一个Build都自动的去执行主流程的测试，确保其是一个基本可用的版本。

冒烟测试可以手动执行，也可以自动化执行，稳定的系统适合自动化冒烟测试，集成过程中的系统适合手工冒烟测试，因为冒烟测试内容在动态变化，变化中的自动化脚本维护工作量比较大。

冒烟测试的流程

一般来说，冒烟测试的流程如下：

1、准备测试环境：为进行冒烟测试准备好测试环境。

2、规划测试用例：根据项目需求和软件功能，编写冒烟测试用例。

3、执行测试用例：按照测试用例进行测试，测试过程中要及时记录测试结果和问题。

4、生成测试报告：根据测试结果生成测试报告，对测试的结果进行评估和分析。

5、提交缺陷：如有发现任何错误或问题，及时记录并报告给开发人员进行修改。

冒烟测试的技巧

1、选择关键场景：在冒烟测试中选择关键路径和高风险模块作为测试重点，以帮助发现系统错误。

2、测试最新版本：确保每次测试都是基于最新的软件版本进行的，避免测试过时的代码。

3、构建维护：不仅要验证软件的基本工作，还要保证构建本身没有问题，并且能够正确安装和配置。

4、数据选择：使用测试数据时，必须考虑到数据的完整性、有效性和正确性。

5、测试日志：测试过程中必须维护日志，以方便记录测试进度、结果和发现的问题等信息。

冒烟测试案例选择原则

既然只是个准入门槛那就不会选择全部案例进行测试，根据经验，选择全部案例数的 40%-50% 测试通过率在 80% 左右即可视为冒烟测试通过，允许测试准入，那这部分案例如何选择呢？

遵循以下原则：

1、选取重要功能案例

重要功能案例至少应占冒烟案例的 30%，特别关注对软件功能实现具有重要影响的功能模块测试案例，例如：一个事件（业务）的增加、删除、修改、查询，一个统计、计算逻辑的的结果校验等。

2、选取主要流程

主、分流程，对于主流程案例原则上应选取，分支流程案例可视其与主流程关联度和影响度从高到低选择部分。如主流程未通过，即使总案例通过率达到通过标准，该软件也应被拒绝准入，待开发人员修正后重新进入冒烟测试环节。例如：一个审批流程，即使增加、删除、修改、查询的功能均通过，但如果整个流程环节中出现阻塞，无法完成完整的审批，则应视为冒烟未通过。

3、筛选数据案例

筛选与主流程、重要功能相关度高的数据测试案例，原则是确保数据的埋设满足主流程、重要功能测试条件。例如：想校验一个商品购买的正确性，就离不开商品种类、单位、库存、价格、购买数量等数据相关案例。这仅是一个简单的商品购买，如果是统计分析则更需要大量不同种类、不同时点的数据作为测试基础。

冒烟测试涉及角色

冒烟测试在测试环境搭建与执行过程中，涉及到的人员包括:测试架构师、管理自动化工厂的测试工程师、开发工程师、持续集成工程师、质量工程师。

冒烟测试总结

冒烟测试就是完成一个新版本的开发后，对该版本最基本的功能进行测试，保证基本的功能和流程能走通。

如果不通过，则打回开发那边重新开发；

如果通过测试，才会进行下一步的测试(功能测试，集成测试，系统测试等等)。

简化：门槛测试，一个开关而不是一个阶段。

目的：版本验证测试BVT（Build Verification Testing）。

时间：开发转测试，历时半至一个小时，很短。

对象：需求覆盖，主功能路径。

优点：节省测试时间，防止build失败。

缺点：覆盖率还是比较低。

操作：对着需求文档把新功能过一遍；把所有流程功能走一遍；用monkey跑个一两个小时；如果有历史用例的话，可以把用例分级，冒烟级、详细级、回归级等等

用例：冒烟测试基本上不需要什么用例，如果有的话，就用详细用例里，覆盖需求文档级别的用例就可以了

冒烟测试，是版本验证测试，主要确认新的版本是否存在致命性bug，冒烟测试最大的优点在于节约测试的时间成本，减少测试轮数。

回归测试，是软件维护阶段对软件修改后进行的测试，指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。