1. 核⼼
冒烟测试就是完成⼀个新版本的开发后，对该版本最基本的功能进⾏测试，保证基本的功能和流程能⾛通。
如果不通过，则打回开发那边重新开发；
如果通过测试，才会进⾏下⼀步的测试(功能测试，集成测试，系统测试等等)。
简化：门槛测试，⼀个开关⽽不是⼀个阶段。
⽬的：版本验证测试BVT（Build Verification Testing）。
时间：开发转测试，历时半⾄⼀个⼩时，很短。
对象：需求覆盖，主功能路径。
优点：节省测试时间，防⽌build失败。
缺点：覆盖率还是⽐较低。
操作：对着需求⽂档把新功能过⼀遍；把所有流程功能⾛⼀遍；⽤monkey跑个⼀两个⼩时；如果有历史⽤例的话，可以把⽤例分级，冒烟级、详细级、回归级等等
软件测试流程⽤例：冒烟测试基本上不需要什么⽤例，如果有的话，就⽤详细⽤例⾥，覆盖需求⽂档级别的⽤例就可以了
冒烟测试，是版本验证测试，主要确认新的版本是否存在致命性bug，冒烟测试最⼤的优点在于节约测试的时间成本，减少测试轮数。
回归测试，是软件维护阶段对软件修改后进⾏的测试，指修改了旧代码后，重新进⾏测试以确认修改没有引⼊新的错误或导致其他代码产⽣错误。
2. 定义
上对冒烟测试的解释:
smoke testing is preliminary testing to reveal simple failures severe enough to, for example, reject a prospective software release. Smoke tests are a subset of [test cases] that cover the most important functionality of a component or system, used to aid assessment if main functions of the software appear to work correctly. When used to determine if a computer program should be subjected to furthe
r, more fine-grained testing, a smoke test may be called an intake test. Alternately, it is a set of tests run on each new build of a to verify that the build is testable before the build is released into the hands of the test team. In the DevOps paradigm, use of a BVT step is one hallmark of the maturity stage.
冒烟测试这个名称的来历，最初是从电路板测试得来的。因为当电路板做好以后，⾸先会加电测试，如果板⼦没有冒烟再进⾏其它测试，否则就必须重新来过。
⽽在软件研发中，冒烟测试其实是微软⾸先提出来的⼀个概念，和微软⼀直提倡的每⽇build（构建版本）有很密切的联系。具体说，冒烟测试就是在每⽇build（构建版本）建⽴后，对系统的基本功能进⾏简单的测试。这种测试强调程序的主要功能进⾏的验证，⽽不会对具体功能进⾏更深⼊的测试。
冒烟只是这类测试活动更形象化⼀些的叫法，直接叫做BVT（Build Verification Testing）其实个⼈觉得更为贴切。
3. WHY
为什么进⾏冒烟测试？软件测试从业者都知道，bug发现的越晚，修复bug的成本就越⾼。那成本⾼在哪⾥呢？
1. 影响的代码多，开发的修复成本会增加
2. 影响的功能范围较⼤，测试回归的范围增加
3. 容易引发更多的bug，拉长测试周期，还有质量风险
4. 更多的bug，会增加bug的提交、沟通成本
所以，如何尽早发现bug，把bug置解决是降低成本和控制⽌风险的有效⽅式，也是QA的主要职责之⼀。因此使⽤冒烟测试的⽅式，对开发提测的代码进⾏审查，出那些⾮常浅显的bug是很有必要的
4. 特点
(1) 这种测试强调程序的主要功能进⾏的验证，⽽不会对具体功能进⾏更深⼊的测试。
(2) 冒烟测试是随着版本转测进⾏的，它应该是⼀个开关(判断版本能否转测试)⽽不是⼀个研发流程中的测试阶段。
(3) 冒烟测试⽤例⼀般选取的是测试⽤例中level 0的⽤例，保证主功能可⽤。
(4) 冒烟测试就是在⼀个新版本出来的时候，将软件的全部功能过⼀遍，看有没有什么⼤问题。如果功能可以正常运⾏，不会影响测试进⾏，那么这个版本就可以真正开始测试了。如果功能有重⼤问题或影响测试进⾏，那么这个版本就是不合格的，不⽤进⾏进⼀步的测试。
5. 实现
开展冒烟测试⼯作有助于尽早发现软件代码存在的问题，提⾼软件代码的质量和开发效率。
基于的冒烟测试采⽤⾃动化测试脚本进⾏测试⼯作，能够提⾼测试效率，减少测试⼈员⼤量的重复测试验证⼯作。
冒烟测试的最佳实践还是最好被⾃动化，在CI中每⼀个Build都⾃动的去执⾏主流程的测试，确保其是⼀个基本可⽤的版本。
冒烟测试可以⼿动执⾏，也可以⾃动化执⾏。稳定的系统适合⾃动化冒烟测试，集成过程中的系统适合⼿⼯冒烟测试，因为冒烟测试内容在动态变化，变化中的⾃动化脚本维护⼯作量⽐较⼤。
6. 案例选择原则
既然只是个准⼊门槛那就不会选择全部案例进⾏测试，根据经验，选择全部案例数的 40%-50% 测试通过率在 80% 左右即可视为冒烟测试通过，允许测试准⼊，那这部分案例如何选择呢？
遵循以下原则
A选取重要功能案例。
重要功能案例⾄少应占冒烟案例的 30%，特别关注对软件功能实现具有重要影响的功能模块测试案例，例如：⼀个事件（业务）的增加、删除、修改、查询，⼀个统计、计算逻辑的的结果校验等。
B选取主要流程
主、分流程，对于主流程案例原则上应选取，分⽀流程案例可视其与主流程关联度和影响度从⾼到低选择部分。如主流程未通过，即使总案例通过率达到通过标准，该软件也应被拒绝准⼊，待开发⼈员修正后重新进⼊冒烟测试环节。例如：⼀个审批流程，即使增加、删除、修改、查询的功能均通过，但如果整个流程环节中出现阻塞，⽆法完成完整的审批，则应视为冒烟未通过。
C筛选数据案例
筛选与主流程、重要功能相关度⾼的数据测试案例，原则是确保数据的埋设满⾜主流程、重要功能测试条件。例如：想校验⼀个商品购买的正确性，就离不开商品种类、单位、库存、价格、购买数量等数据相关案例。这仅是⼀个简单的商品购买，如果是统计分析则更需要⼤量不同种类、不同时点的数据作为测试基础。
7. 涉及⾓⾊
冒烟测试在测试环境搭建与执⾏过程中，涉及到的⼈员包括：测试架构师、管理⾃动化⼯⼚的测试⼯
程师、开发⼯程师、持续集成⼯程师、质量⼯程师。
8. 冒烟测试 V.S. 回归测试
冒烟测试，是版本验证测试，主要确认新的版本是否存在致命性bug，冒烟测试最⼤的优点在于节约测试的时间成本，减少测试轮数。
回归测试，是软件维护阶段对软件修改后进⾏的测试，指修改了旧代码后，重新进⾏测试以确认修改没有引⼊新的错误或导致其他代码产⽣错误。
摘录⽹址
1.
2.
3.
4.
5.
6.
发布评论