冒烟测试和回归测试
冒烟测试和回归测试
前言：冒烟测试和回归测试，都只是测试的一种过程，这两种测试贯穿了整个 app 的生命周期。
冒烟测试
冒烟测试，究竟是什么
冒烟测试，是微软首先提出来的一个概念（Smoke Testing）,一直以来都被认为和 BVT(Build Verification Test --版本验证测试)扯不清。但它们其实共同点都是强调要对程序的主要功能进行验证，只有通过了主要功能的测试，才能后续更细化的测试流程。
冒烟测试的优势
冒烟测试，虽说是测试方法的一种，但如果紧紧认为它是一种测试，那就太过浅显了。冒烟测试可以弥补很多常规测试中的不足，冒烟不仅可以测出 bug，更早的发现产品缺陷，还可以发现产品层的问题，也会进一步提升提测质量。
在常规的测试中，提测质量往往是一个痛点，虽然开发有自测，可是总还是有一些浅显的问题存在，更有甚者还会阻塞测试工作，提测前进行冒烟可以完美的解决这一问题，冒烟测试属于自由体验，可以保证在主路径上不会有严重的缺陷存在，提高提测质量，解决测试阻塞的问题。
冒烟的时候经常会有一个有趣的现象，大家会热烈的讨论某个功能该如何做，每个人说出自己的见解，更正不合理的产品需求，最后把解决方案记录在bug列表中转为产品需求。在不断的冒烟测试中，代码上的缺陷不断被修复，同时产品功能也在不断完善。
冒烟流程
冒烟流程是既简单又很复杂，短短半小时看似短暂，却像是浓缩了一整个项目流程进来：首先得把主角“打包”出来，然后组织大家去冒烟，收集冒烟中的问题，最后录入系统给相应负责人解决。
冒烟包在build包的过程中经常会有各种问题，因此需要在时间上预留一些buffer（缓冲时间），通常情况下需要提前半小时build（构建）包，在build包前需要确认各开发今天写的代码都已经更新至svn或者 git。
每个版本由一个开发和一个测试负责，开发负责打包并收集各开发的feature（新功能，特色等）和体验路径，测试负责将上一次冒烟修复的bug打印出来给大家回归。
各角色在冒烟的时候不仅要体验新产品，也需要履行各自的职责：开发需要引导大家体验自己的feature，并讲解需求，产品经理和设计师需要关注需求是否正确实现，测试则是要让大家回归已解决的bug（谁提的bug谁回归），拒绝的bug需要开发给出拒绝的原因，如果不合理，提bug人可以将bug重新打开。
冒烟结束后，测试负责人需要根据bug list中的内容，将bug分模块，类型（bug，建议），具体格式为：
标题格式说明：【版本+模块名+FT+冒烟测试】【BUG/建议】xxxx–提bug人 ，最后全部提给该版本的冒烟开发负责人，由他统一分配bug。
冒烟测试中提出了这么多问题，怎么分类，如何处理，每一天的冒烟既是一个新的开始也是一个对上一次冒烟的闭环，bug分类的不同，发现阶段的不同，其解决的方式也有所不同。
bug 的梳理和查杀
一般冒烟测试有三大类 bug：常规问题，crash 以及体验类问题。
- 常规类型的 bug 为冒烟测试常规缺陷，常规问题常规解决，这类缺陷在冒烟时由发现问题的人回归，并对解决的结果作出判断，评估该不该、是否已被解决，或者拒绝的理由是否合理，如果有异议或者没修复可以要求重新打开该 bug。
- crash 属于非常严重的一类 bug，如果解决方案不够妥当，可能会引入其他问题，如果仅仅是在冒烟期间没有复现crash 就认为已修复，这样会太过草率。因此，每次冒烟的时候，开发要讲解该 crash 是如何修复的，以及为什么会发生该 crash ，大家一起评估过这个修复方法后才算结束。
- 体验类 bug 比较特殊，如果觉得有产品缺陷的地方就可以提出此类 bug，产品会权衡要不要把这个bug 建议纳入到产品中来，推进产品完善。
由于冒烟是穿插在整个项目周期中的，在项目即将发布前可能依旧存在问题，此时修复这些问题，如果代码改动太大，可能会引发其他的bug，所以如果是在项目后期冒烟中发现很难解的bug需要评估改动范围，不然为了一个小问题而引入更多的bug就得不偿失了。
冒烟测试技巧
- 用数据说明冒烟优势
冒烟过程中会出现各种 bug，这些 bug 的提前暴露可以在项目初期就开始修复，提升代码质量，成功非常可观，可以通过一两个版本的数据让大家认识到冒烟对开发和产品质量的重要程度。
- 项目 PM 的支持
任何工作的顺利进行都需要有上级的支持，项目 PM 对冒烟测试的支持可以减少冒烟测试中的阻力。
- 冒烟时间&地点
冒烟应该选择人比较疲劳的时候，这个时候工作效率不高，可以可用这个间隙半休息的状态进行冒烟，例如茶水间，例如休息室，能讨论，能有零食慰藉，，提升大家冒烟的积极性。
总结
在版本快速迭代的节奏下，冒烟不仅仅是常规测试的一个有效补充，也是大家参与项目了解项目的桥梁。总结冒烟主要达成以下几项：
- 冒烟测试的目的: 确认提测模块的基本功能、实现逻辑符合需求，可以进行后续的正式测试工作，将正式测试未知的风险降至最低，防止bug阻塞导致测试进度阻塞 。
-
冒烟测试时机:
- 1.新增功能提测时
- 2.Bug修改或需求变更对原有功能模块逻辑和业务修改范围过大的时候
-
冒烟测试时间安排:
- 冒烟测试的时间可根据模块的复杂程度来定，复杂度越高的模块，预测试的时间可以安排的长些
- 冒烟测试时间一般不超过该模块一轮测试时间的10%
-
冒烟测试标准: 有以下任何一条执行结果，预测试不通过
- 提测模块中，不可测试的功能点占总功能点的40%以上
- 崩溃或 Bug 导致70%以上的功能无法测试（即测试用例被阻塞）
- 崩溃频繁导致无法进行测试。
- 抽时随机测试，半小时内发现 Bug 数量超过20以上
- 个别重大 Bug 影响60%以上的功能逻辑
冒烟测试主要是防止构建版本不合格的情况下，浪费大量时间进行后续的细分测试。
回归测试
回归测试一般用于软件后期迭代和维护过程中。主要是因为可能新 Bug的发现，修复后对其它功能造成的影响，或者开发者对错误的理解不够透彻，引发的其它 bug。新功能的追加，新代码可能对原有代码带来的影响。因此每当APP发生变化时，我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。同时，还需要补充新的测试用例来测试新的或被修改了的功能。为了验证修改的正确性及其影响就需要进行回归测试。
回归测试主要是杜绝新代码的融入给原版本带来的不可预测的影响或者引发其他bug 的产生。
这两种测试必须贯穿我们开发的整个过程，防止出现重大 bug 的出现。
参考：
