震惊，冒烟测试还可以这样

作者：sweetojiang团队：腾讯移动品质中心TMQ

一、冒烟测试，什么鬼

冒烟测试，名字听起来很奇怪，冒烟和测试完全就没有什么关系，为什么两者会联系到一起？冒烟测试本是说硬件测试时进行加电，如果电路板没有冒烟则说明电路设计没有问题，后来冒烟测试引入到了软件测试中，用来验证主路径是否畅通。

软件冒烟测试往往在敏捷开发团队中有着非常大的帮助，在目前这种快速开发迭代的节奏下，如果依旧采用常规的提测、测试、回归流程，显得过于死板和迟钝，产品中存在的问题不能以第一时间反馈给各角色，而冒烟测试则是集合了整个团队的力量共同助力产品的质量。这里所说的冒烟测试是穿插在整个项目流程的各个阶段，从而在项目周期中把控产品质量。

那你可能会问了，如此大规模的冒烟测试，倾尽团队各方的力量，它到底有哪些优势值得我们投入这么多精力？下面我们就来讲讲冒烟有什么厉害之处。

[1498619165229_8933_1498619276352.png]

二、冒烟测试的优势

冒烟测试，虽说是测试方法的一种，那你认为它仅仅是一种测试，那就太过浅显了，冒烟测试可以弥补很多常规测试中不足，冒烟不仅可以测出bug，更早的发现产品缺陷，还可以发现产品层面的问题，另外，也会弥补测试中机型不足的问题，同时也可以进一步提升提测质量。

[1498619175080_7455_1498619286349.png]

在产品研发的过程中，常常会有这么一个问题，所有的人只熟悉自己负责的模块，而每天一次的冒烟让每一个角色都可以融入到产品中，更多了解自己的产品，发现产品的优缺点，提出自己对于产品的想法。对于产品经理，可以第一时间接触到产品，在产品的刚有雏形的时候来验收产品，避免研发过程中需求理解错误，减少修复成本。

一般在测试工作中，机型有限，测试时不能兼顾到所有机型，然而某些缺陷只在特定机型上才会暴露，如果等到产品上线发现适配问题再修复，修复成本会很大，冒烟测试中多了十几个机型，更容易暴露机型问题。

除了机型问题，在常规的测试中，提测质量往往是一个痛点，虽然开发有自测，可是总还是有一些浅显的问题存在，更有甚者还会阻塞测试工作，提测前进行冒烟可以完美的解决这一问题，冒烟测试属于自由体验，可以保证在主路径上不会有严重的缺陷存在，提高提测质量，解决测试阻塞的问题。

冒烟的时候经常会有一个有趣的现象，大家会热烈的讨论某个功能该如何做，每个人说出自己的见解，更正不合理的产品需求，最后把解决方案记录在bug列表中转为产品需求。

在不断的冒烟测试中，代码上的缺陷不断被修复，同时产品功能也在不断完善。原来冒烟测试这么厉害，教练，我要学！既然要学总要有各流程吧，下面我们介绍一些冒烟测试中的“套路”。

三、冒烟ing

冒烟流程是既简单又很复杂，短短半小时看似短暂，却像是浓缩了一整个项目流程进来：首先得把主角“打包”出来，然后组织大家去冒烟，收集冒烟中的问题，最后录入系统给相应负责人解决。

[1498619187399_8937_1498619298432.png]

冒烟包在build包的过程中经常会有各种问题，因此需要在时间上预留一些buff，通常情况下需要提前半小时build包，在build包前需要确认各开发今天写的代码都已经更新至svn。

每个版本由一个开发和一个测试负责，开发负责打包并收集各开发的feature和体验路径，测试负责将上一次冒烟修复的bug打印出来给大家回归。

各角色在冒烟的时候不仅要体验新产品，也需要履行各自的职责：开发需要引导大家体验自己的feature，并讲解需求，产品经理和设计师需要关注需求是否正确实现，测试则是要让大家回归已解决的bug（谁提的bug谁回归），拒绝的bug需要开发给出拒绝的原因，如果不合理，提bug人可以将bug重新打开。

冒烟结束后，测试负责人需要根据bug list中的内容，将bug分模块，类型（bug，建议），具体格式为：

标题格式说明：【版本+模块名+FT+冒烟测试】【BUG/建议】xxxx--提bug人 ，最后全部提给该版本的冒烟开发负责人，由他统一分配bug。

冒烟测试中提出了这么多问题，怎么分类，如何处理，每一天的冒烟既是一个新的开始也是一个对上一次冒烟的闭环，bug分类的不同，发现阶段的不同，其解决的方式也有所不同。

四、查杀BUG

冒烟中，同一个bug在不同的手机上会有不同的表现，因此经常会有重复bug出现，或相似bug，表现不一致就会提bug，这样导致bug的“含金量”不高，一个版本下来可能有效的冒烟bug只有6、7成，但是在bug面前宁肯让其重复也不能遗漏。

[1498619204436_2967_1498619315444.png]

[1498619215948_3303_1498619326934.png]

这是我们Feature Team某个版本的冒烟bug数据，单冒烟一项就提了153个bug，bug虽多，线上质量却从未出过问题。

有效的bug有7成，拒绝bug以重复bug和建议类bug偏多，约占到总bug的89%。那剩下的3成拒绝bug应该如何看待，难道拒绝了就没有存在的价值了吗？

[1498619226981_8397_1498619337988.png]

并非如此，重复bug一般说明问题该bug容易复现，因此需要重点照顾，虽然被定位为无效bug，但是重复bug可以帮助开发找到需要重点关注的地方。建议类bug一般是对产品需求的看法，千人千面，并不是所有的意见都符合产品逻辑，但是这些建议却值得产品经理去思考。

有效的bug该如何解决，当然bug的种类很多，不同类型的bug解决的方式也有所区别，目前我们冒烟测试有三大类bug：常规问题，crash以及体验类问题。

[1498619242263_2544_1498619353265.png]

常规类型的bug为冒烟时的常规缺陷，常规问题常规解决，这类缺陷在冒烟时由发现问题的人回归，并对解决的结果作出判断，评估该bug是否已被解决，或者拒绝理由是否合理，如果有异议可以要求重新打开该bug。

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

体验类bug比较特殊，如果觉得有产品缺陷的地方就可以提这一类bug，这类bug一般会转到产品名下，产品会权衡要不要把这个建议纳入到产品中来。

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

五、冒烟技巧

上面说了这么多，真正要施行下去是有一定难度的，每天让大家从工作中抽出宝贵的半小时时间用于体验产品，对于每天加班的开发来说是很难接受的，那有没有什么捷径可以走，这么厉害的东西不能出师未捷身先死啊，总得通过某些方式把它推行下去吧。

1、用数据说明冒烟的优势

冒烟过程中会出现各种bug，这些bug的提前暴露可以在项目初期就开始修复，提升代码质量，成果非常可观，可以通过一两个版本的数据情况让大家认识到冒烟对产品质量的重要程度。

2、项目PM的支持

任何工作的顺利进行都需要有上级的支持，项目PM对冒烟测试的支持可以减少冒烟测试中遭遇的各种阻力。

3、冒烟时间&地点

通常情况下，冒烟应当选择在人比较疲劳的时候，这个时间段工作效率不高，可以利用这个时间进行冒烟，解决了时间利用率低的问题，同时也能缓解工作的疲劳。

至于地点，只要不是在自己的工位上冒烟就可以，最好能找个茶水间，让大家放松心情的同时进行冒烟。

如此以来，可以让项目组成员意识到，冒烟不仅仅是工作的一部分，同时可以缓解工作的疲劳，提升大家冒烟的积极性。

4、物质奖励

冒烟的时候可以准备零食给大家，对于冒烟积极的同学可以提供物质奖励。

当然，组织冒烟的技巧不仅限于此，此时就是你开辟脑洞的时刻了，只要能让冒烟测试顺利的开展下去，再“卑劣”的想法都值得去尝试。

六、总结

在版本快速迭代的节奏下，冒烟测试不仅成为常规测试的一个有效补充，也为其他角色了解测试搭建了一个很好的桥梁，这个过程需要各个人员积极的参与和优化才能得到理想的效果。

获取更多测试干货，请搜索微信公众号：腾讯移动品质中心TMQ！