软件测试 —— 冒烟测试（Smoke Test，ST）_软件测试行业 冒烟用例
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
需要这份系统化的资料的朋友，可以戳这里获取
如果通过测试，才会进行下一步的测试(功能测试，集成测试，系统测试等等)。
简化：门槛测试，一个开关而不是一个阶段。
目的：版本验证测试BVT（Build Verification Testing）。
时间：开发转测试，历时半至一个小时，很短。
对象：需求覆盖，主功能路径。
优点：节省测试时间，防止build失败。
缺点：覆盖率还是比较低。
操作：对着需求文档把新功能过一遍；把所有流程功能走一遍；用monkey跑个一两个小时；如果有历史用例的话，可以把用例分级，冒烟级、详细级、回归级等等
用例：冒烟测试基本上不需要什么用例，如果有的话，就用详细用例里，覆盖需求文档级别的用例就可以了
冒烟测试，是版本验证测试，主要确认新的版本是否存在致命性bug，冒烟测试最大的优点在于节约测试的时间成本，减少测试轮数。
回归测试，是软件维护阶段对软件修改后进行的测试，指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
2. 定义
冒烟测试这个名称的来历，最初是从电路板测试得来的。因为当电路板做好以后，首先会加电测试，如果板子没有冒烟再进行其它测试，否则就必须重新来过。
而在软件研发中，冒烟测试其实是微软首先提出来的一个概念，和微软一直提倡的每日build（构建版本）有很密切的联系。具体说，冒烟测试就是在每日build（构建版本）建立后，对系统的基本功能进行简单的测试。这种测试强调程序的主要功能进行的验证，而不会对具体功能进行更深入的测试。
3. WHY
为什么进行冒烟测试？软件测试从业者都知道，bug发现的越晚，修复bug的成本就越高。那成本高在哪里呢？
- 影响的代码多，开发的修复成本会增加
- 影响的功能范围较大，测试回归的范围增加
- 容易引发更多的bug，拉长测试周期，还有质量风险
- 更多的bug，会增加bug的提交、沟通成本
所以，如何尽早发现bug，把bug置解决是降低成本和控制止风险的有效方式，也是QA的主要职责之一。因此使用冒烟测试的方式，对开发提测的代码进行审查，找出那些非常浅显的bug是很有必要的
4. 特点
(1) 这种测试强调程序的主要功能进行的验证，而不会对具体功能进行更深入的测试。
(2) 冒烟测试是随着版本转测进行的，它应该是一个开关(判断版本能否转测试)而不是一个研发流程中的测试阶段。
(3) 冒烟测试用例一般选取的是测试用例中level 0的用例，保证主功能可用。
(4) 冒烟测试就是在一个新版本出来的时候，将软件的全部功能过一遍，看有没有什么大问题。如果功能可以正常运行，不会影响测试进行，那么这个版本就可以真正开始测试了。如果功能有重大问题或影响测试进行，那么这个版本就是不合格的，不用进行进一步的测试。
5. 实现
开展冒烟测试工作有助于尽早发现软件代码存在的问题，提高软件代码的质量和开发效率。
基于持续集成(Continuous Integration，CI)")的冒烟测试采用自动化测试脚本进行测试工作，能够提高测试效率，减少测试人员大量的重复测试验证工作。
冒烟测试的最佳实践还是最好被自动化，在CI中每一个Build都自动的去执行主流程的测试，确保其是一个基本可用的版本。
冒烟测试可以手动执行，也可以自动化执行。稳定的系统适合自动化冒烟测试，集成过程中的系统适合手工冒烟测试，因为冒烟测试内容在动态变化，变化中的自动化脚本维护工作量比较大。
6. 案例选择原则
既然只是个准入门槛那就不会选择全部案例进行测试，根据经验，选择全部案例数的 40%-50% 测试通过率在 80% 左右即可视为冒烟测试通过，允许测试准入，那这部分案例如何选择呢？
遵循以下原则
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
需要这份系统化的资料的朋友，可以戳这里获取
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
4613a03fab5e56a57acb)**
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！