理解冒烟测试

【背景】

在一份数据流图中看到某项目测试流程的第一步是冒烟测试，之前的理解是像电路板那样，有问题的地方会冒烟，但是结合项目有点难理解。

所以搜索冒烟测试相关资料，学习记录一下。

【内容】

01 概念解释

冒烟测试，是微软首先提出来的一个概念（Smoke Testing）,一直以来都被认为和 BVT(Build Verification Test --版本验证测试)扯不清。

但它们其实共同点都是强调要对程序的主要功能进行验证，只有通过了主要功能的测试，才能后续更细化的测试流程。

02 作用

冒烟测试属于自由体验，可以保证在主路径上不会有严重的缺陷存在，提高提测质量，解决测试阻塞的问题。

03 bug 的梳理

一般冒烟测试有三大类 bug：常规问题，crash 、体验类问题

<1> 常规类型的 bug

为冒烟测试常规缺陷，常规问题常规解决，这类缺陷在冒烟时由发现问题的人回归，并对解决的结果作出判断，评估该不该、是否已

被解决，或者拒绝的理由是否合理，如果有异议或者没修复可以要求重新打开该 bug。

<2> crash

属于非常严重的一类 bug，如果解决方案不够妥当，可能会引入其他问题，如果仅仅是在冒烟期间没有复现crash 就认为已修复，这样会太过草率。因此，每次冒烟的时候，开发要讲解该 crash 是如何修复的，以及为什么会发生该 crash ，大家一起评估过这个修复方法后才算结束。

<3>体验类 bug

比较特殊，如果觉得有产品缺陷的地方就可以提出此类 bug，产品会权衡要不要把这个bug 建议纳入到产品中来，推进产品完善。

由于冒烟是穿插在整个项目周期中的，在项目即将发布前可能依旧存在问题，此时修复这些问题，如果代码改动太大，可能会引发其他的bug，所以如果是在项目后期冒烟中发现很难解的bug需要评估改动范围，不然为了一个小问题而引入更多的bug就得不偿失了。

 

 

Reference

https://www.jianshu.com/p/180fc14b4171