📝 面试求职： 「面试试题小程序」 ，内容涵盖 测试基础、Linux操作系统、MySQL数据库、Web功能测试、接口测试、APPium移动端测试、Python知识、Selenium自动化测试相关、性能测试、性能测试、计算机网络知识、Jmeter、HR面试，命中率杠杠的。（大家刷起来…）
📝 职场经验干货：
冒烟测试的概念
冒烟测试，又称版本验证测试（Build Verification Testing，BVT），是在软件开发过程中，对新编译或修复后的软件版本进行的一种快速基本功能验证测试。是软件研发过程中，一个很重要的环节。
我最早接触冒烟测试这个名词，还是在大学时期学习软件工程这门课程的时候，后来进入软件测试行业之后，才对冒烟测试有了更实际和具体的了解。
冒烟用例的标准
在思考如何挑选冒烟用例之前，我们首先需要明白，冒烟测试的目的是什么？
冒烟用例一般来说是为了检验系统的主要业务流程或核心功能能够走通，达到可以测试的状态。
基于这个目的，我们就可以确定，冒烟用例一定是所有测试用例中优先级最高的、代表性最高的。
我们在编写完测试用例之后，都会给测试用例设置执行优先级，比如由P0 ~P3，P0的一般是优先级最高的，基本就是覆盖系统核心业务流程和核心功能的。
所以，对于我们来说，冒烟用例可以在全部测试用例完成输出完成之后，在其中进行挑选。
所以，测试用例的分级是很重要的，如果优先级设置不科学，可能会导致挑选的冒烟用例不恰当，从而降低冒烟测试的质量。
结合我在工作中的了解以及网络上查阅的信息，一般来说冒烟用例大概占到全部测试用例的10%左右。
当然这个不是绝对的，只能当作参考，我们还是需要根据实际的项目需求去挑选出合适的冒烟用例。
对于大型的且业务复杂的软件系统和小型的没有复杂业务的软件系统来说，挑选的冒烟用例的比例肯定是不一样的，只要我们的冒烟用例能达到我们检验系统主要功能的目的，就可以说是合适的。
一般来说，冒烟用例由测试人员负责编写并提供给研发，研发人员在提测代码之前需要按照冒烟用例执行冒烟测试。
图2、冒烟用例样例
冒烟测试的实施
在日常工作中，通常是在需求评审之后，研发人员开始进行概要设计和详细设计，测试人就开始根据需求编写测试用例，用例全部输出完成之后，需要进行测试用例评审。
在组织完测试用例评审会议后，测试人员根据根评审意见调整用例，将最终的确定的冒烟用例提交给研发人员，研发人员需要按照测试人员提供的冒烟用例严格执行，确保冒烟用例全部执行且通过后，方能将测试代码提交至测试人员，相当于一个准入规则。
在代码提测之后，测试人员也会根据同样的冒烟用例进行冒烟测试，如果有执行不通过的冒烟用例，那么就认为本次提测的冒烟测试是不合格的。
如果问题比较多或者已经严重阻塞测试进程了，可能需要重新将代码回退给开发，需要他们修改并再次冒烟通过后再提交给测试人员；如果问题比较少且只影响局部，那么只需要研发及时修改问题就好了，测试人员可以先测试其它不受影响的内容。
冒烟用例首先是需要研发人员进行执行的，作为测试人员，我们一方面要保证我们提供给研发的冒烟用例是比较高质量的，就是花费研发人员较少的时间去检验系统是否达到提测标准，另一方面，我们需要根据实际情况去适当调整冒烟策略。
比如遇到时间非常紧急的情况，研发可能没有足够时间去执行冒烟、项目进度太赶，没有按照规范执行冒烟测试的条件等等，这时候可能需要做一些调整，比如在原有冒烟用例的基础上再删减一些，尽可能减少研发冒烟测试的投入。
在冒烟测试实施过程中，可能会受到一些阻力，在我过往的工作经历中，就遇到过因为研发没有时间执行冒烟测试的情况或者测试人员没有时间提供冒烟用例的情况。
前者是测试已经提供了冒烟用例，但是研发真的没有时间或来不及执行冒烟，后者是因为测试人员根本没时间输出测试用例。这两种情况下，我们当时就是不得已省略了冒烟测试的这个环节。
虽然是省略了这个正式冒烟的环节，但是对于开发提测的代码基本要求还是有的，起码要能跑的通吧。另外这种不进行冒烟测试的情况总体而言还是比较少的。
如果在一个项目研发过程中，经常性的不去执行冒烟测试，那么大概率说明团队当前是不重视质量建设的，要么就是项目的计划排期不合理，长此以往，是不利于保障软件质量的。
冒烟测试的记录
开发、测试执行冒烟测试后的测试结果都是要及时进行记录的，一方面是为了工作留档，另一方面是为了方便后续统计复盘。
记录冒烟测试结果不是我们的最终目的，最终的目的是为了在一定时间范围内，通过冒烟记录结果来呈现整个团队在过往一段时间对于冒烟测试的执行力度，这也能反应大家近段时间对于质量工作的严谨度。
比如，在我上家公司，我们整个项目团队通常会以月为周期进行冒烟测试结果的复盘，讨论问题产生的原因和改进办法。但是如果研发团队连续1 -2周的冒烟不通过率比较高，我们就会及时召集项目组相关人员进行复盘。
根据我过往的经历来讲，冒烟通过率不高，主要有以下几点原因：
一、开发人员未严格按照冒烟用例执行测试；
二、开发人员在本地而非测试环境执行冒烟测试，由于环境差异导致测试结果存在偏差。
三、需求存在变动，没有及时通知到测试人员，导致测试用例预期结果与新需求不一致；
以上三个原因，实际碰到最多的还是一、二两点。
图3、冒烟测试记录
冒烟测试的意义
软件质量保障工作其实是一个系统性的工程，从更宏观的角度来看，软件质量保障工作涉及到项目所有干系人，包括项目经理、产品经理、研发人员和测试人员都是和软件质量保障工作密切相关的，尤其是研发和测试。
而冒烟测试，作为质量保障工作的一个小的环节，是在软件研发过程进行实施的。我认为冒烟测试有以下几点意义：
1. 提高提测代码质量，减少测试、研发投入成本。
实施冒烟测试，能够在代码提测之前有效评估代码质量，尽早的暴露出问题，从而降低提测后因质量不高或产生阻塞等问题而导致的测试效率低下、后期研发修复问题成本升高等问题。
从而在整体上提高软件质量，减少测试成本和研发修复问题成本，降低项目上线的风险。
2. 促进团队合作。
冒烟测试工作需要研发团队和测试团队合作来完成，通过合作，能够在团队间形成共同体意识，共同为软件质量保驾护航。
3. 强化质量意识。
将质量保障思想落实到到日常研发工作中，通过执行冒烟测试强化大家对于软件质量的重视程度。
4. 反馈研发质量，促进工作提效。
通过冒烟测试的记录，能够反馈当前团队的研发质量、工作状况等，为后续工作提升提供参考。
小结
其实刚开始在第一家公司做测试的时候，冒烟测试在团队中并没有引起重视，大家可能更多的觉得冒烟测试会耽误时间，降低工作效率，就连当时身为测试人员的我也是这么认为的。
直到后来，经历过比较成熟的项目团队和测试团队，我才真正懂得冒烟测试的价值，绝不是浪费时间的工作，冒烟测试保障质量的一个环节，如果实施得好，整体上来看还是会省力不少。
在如今的公司和团队中，大家也是非常重视软件质量的，只要条件允许，我们都是会严格执行冒烟测试，坚持过一段时间发现确实对于提升软件质量，降低后期投入成本大有裨益，事实证明这是值得做的工作。
以上是我在测试工作中对于冒烟测试工作的一点感悟，欢迎大家指正！
最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
