0%

冒烟测试与回归测试

前言:冒烟测试和回归测试,都只是测试的一种过程,这两种测试贯穿了整个 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阻塞导致测试进度阻塞 。

冒烟测试时机:

  • 新增功能提测时
  • Bug修改或需求变更对原有功能模块逻辑和业务修改范围过大的时候

冒烟测试时间安排:

  • 冒烟测试的时间可根据模块的复杂程度来定,复杂度越高的模块,预测试的时间可以安排的长些
  • 冒烟测试时间一般不超过该模块一轮测试时间的10%
  • 冒烟测试标准: 有以下任何一条执行结果,预测试不通过
  • 提测模块中,不可测试的功能点占总功能点的40%以上
  • 崩溃或 Bug 导致70%以上的功能无法测试(即测试用例被阻塞)
  • 崩溃频繁导致无法进行测试。
  • 抽时随机测试,半小时内发现 Bug 数量超过20以上
  • 个别重大 Bug 影响60%以上的功能逻辑
  • 冒烟测试主要是防止构建版本不合格的情况下,浪费大量时间进行后续的细分测试。

回归测试

回归测试一般用于软件后期迭代和维护过程中。主要是因为可能新 Bug的发现,修复后对其它功能造成的影响,或者开发者对错误的理解不够透彻,引发的其它 bug。新功能的追加,新代码可能对原有代码带来的影响。因此每当APP发生变化时,我们就必须重新测试现有的功能,以便确定修改是否达到了预期的目的,检查修改是否损害了原有的正常功能。同时,还需要补充新的测试用例来测试新的或被修改了的功能。为了验证修改的正确性及其影响就需要进行回归测试。

回归测试主要是杜绝新代码的融入给原版本带来的不可预测的影响或者引发其他bug 的产生。

这两种测试必须贯穿我们开发的整个过程,防止出现重大 bug 的出现。

番外

冒烟测试,是微软首先提出来的一个概念,和微软一直提倡的每日build(构建版本)有很密切的联系。具体说,冒烟测试就是在每日build(构建版本)建立后,对系统的基本功能进行简单的测试。这种测试强调程序的主要功能进行的验证,也叫版本验证测试,提交测试。

冒烟测试这个名称的来历,是从电路板测试得来的。因为当电路板做好以后,首先会加电测试,如果板子没有冒烟在进行其它测试,否则就必须重新来过。类似的如果冒烟测试没有通过,那么这个build也会返回给开发队伍进行修正,测试人员测试的版本必须首先通过冒烟测试的考验。

冒烟测试的说法据说是:象生产汽车一样,汽车生产出来以后,首先发动汽车,看汽车能否冒烟,如果能,证明汽车最起码可以开动了。说明完成了最基本的功能。

冒烟测试一般用于每日构建(Nightly build),构建服务器首先从CVS服务器上,下载最新的源代码,然后编译单元测试,运行单元测试通过后,编译可执行文件,可执行文件若可运行,并能执行最基本的功能,则认为通过了冒烟测试,这时,构建服务器会把程序打包成安装文件,然后上传到内部网站,第二天一早,测试人员来了以后,会收到构建服务器发来的邮件提示昨晚是否构建成功。若构建成功,则测试人员进行相关的功能测试。所有这些功能的完成,一般是靠编写脚本完成的,目前比较常用的脚本有TCL,PERL,PYTHON及功能弱弱的批处理。用这些可以完成系统的每日构建。

总的来说,冒烟测试就是先保证系统能跑的起来,不至于让测试工作做到一半突然出现错误导致业务中断。目的就是先通过最基本的测试,如果最基本的测试都有问题,就直接打回开发部了,减少测试部门时间的浪费。

而回归测试,是软件维护阶段对软件修改后进行的测试。

在软件生命周期中的任何一个阶段,只要软件发生了改变,就可能给该软件带来问题。软件的改变可能是源于发现了错误并做了修改,也有可能是因为在集成或维护阶段加入了新的模块。当软件中所含错误被发现时,如果错误跟踪与管理系统不够完善,就可能会遗漏对这些错误的修改;而开发者对错误理解的不够透彻,也可能导致所做的修改只修正了错误的外在表现,而没有修复错误本身,从而造成修改失败;修改还有可能产生副作用从而导致软件未被修改的部分产生新的问题,使本来工作正常的功能产生错误。同样,在有新代码加入软件的时候,除了新加入的代码中有可能含有错误外,新代码还有可能对原有的代码带来影响。因此,每当软件发生变化时,我们就必须重新测试现有的功能,以便确定修改是否达到了预期的目的,检查修改是否损害了原有的正常功能。同时,还需要补充新的测试用例来测试新的或被修改了的功能。为了验证修改的正确性及其影响就需要进行回归测试。

扩展阅读

坚持原创技术分享,您的支持将鼓励我继续创作!

欢迎关注我的其它发布渠道