软件测试系列——冒烟测试(Smoke Test,ST)

1. 核心

冒烟测试就是完成一个新版本的开发后,对该版本最基本的功能进行测试,保证基本的功能和流程能走通。

  如果不通过,则打回开发那边重新开发;

  如果通过测试,才会进行下一步的测试(功能测试,集成测试,系统测试等等)。

简化:门槛测试,一个开关而不是一个阶段。

目的:版本验证测试BVT(Build Verification Testing)。

时间:开发转测试,历时半至一个小时,很短。

对象:需求覆盖,主功能路径。

优点:节省测试时间,防止build失败。

缺点:覆盖率还是比较低。

操作:对着需求文档把新功能过一遍;把所有流程功能走一遍;用monkey跑个一两个小时;如果有历史用例的话,可以把用例分级,冒烟级、详细级、回归级等等

用例:冒烟测试基本上不需要什么用例,如果有的话,就用详细用例里,覆盖需求文档级别的用例就可以了

冒烟测试,是版本验证测试,主要确认新的版本是否存在致命性bug,冒烟测试最大的优点在于节约测试的时间成本,减少测试轮数。

回归测试,是软件维护阶段对软件修改后进行的测试,指修改了旧代码后,重新进行测试以确认修改没有引入新的错误导致其他代码产生错误

2. 定义

  维基百科上对冒烟测试的解释:
  smoke testing is preliminary testing to reveal simple failures severe enough to, for example, reject a prospective software release. Smoke tests are a subset of [test cases] that cover the most important functionality of a component or system, used to aid assessment if main functions of the software appear to work correctly.[1][2] When used to determine if a computer program should be subjected to further, more fine-grained testing, a smoke test may be called an intake test.[1] Alternately, it is a set of tests run on each new build of a product to verify that the build is testable before the build is released into the hands of the test team.[5] In the DevOps paradigm, use of a BVT step is one hallmark of the continuous integration maturity stage.

  冒烟测试这个名称的来历,最初是从电路板测试得来的。因为当电路板做好以后,首先会加电测试,如果板子没有冒烟再进行其它测试,否则就必须重新来过。

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

  冒烟只是这类测试活动更形象化一些的叫法,直接叫做BVT(Build Verification Testing)其实CC先生个人觉得更为贴切。

3. WHY

为什么进行冒烟测试?软件测试从业者都知道,bug发现的越晚,修复bug的成本就越高。那成本高在哪里呢?

  1. 影响的代码多,开发的修复成本会增加
  2. 影响的功能范围较大,测试回归的范围增加
  3. 容易引发更多的bug,拉长测试周期,还有质量风险
  4. 更多的bug,会增加bug的提交、沟通成本

所以,如何尽早发现bug,把bug置解决是降低成本和控制止风险的有效方式,也是QA的主要职责之一。因此使用冒烟测试的方式,对开发提测的代码进行审查,找出那些非常浅显的bug是很有必要的

4. 特点

  (1) 这种测试强调程序的主要功能进行的验证,而不会对具体功能进行更深入的测试。

  (2) 冒烟测试是随着版本转测进行的,它应该是一个开关(判断版本能否转测试)而不是一个研发流程中的测试阶段。

  (3) 冒烟测试用例一般选取的是测试用例中level 0的用例,保证主功能可用。

  (4) 冒烟测试就是在一个新版本出来的时候,将软件的全部功能过一遍,看有没有什么大问题。如果功能可以正常运行,不会影响测试进行,那么这个版本就可以真正开始测试了。如果功能有重大问题或影响测试进行,那么这个版本就是不合格的,不用进行进一步的测试。

5. 实现

  开展冒烟测试工作有助于尽早发现软件代码存在的问题,提高软件代码的质量和开发效率。

  基于持续集成(Continuous Integration,CI)的冒烟测试采用自动化测试脚本进行测试工作,能够提高测试效率,减少测试人员大量的重复测试验证工作。

  冒烟测试的最佳实践还是最好被自动化,在CI中每一个Build都自动的去执行主流程的测试,确保其是一个基本可用的版本。

  冒烟测试可以手动执行,也可以自动化执行。稳定的系统适合自动化冒烟测试,集成过程中的系统适合手工冒烟测试,因为冒烟测试内容在动态变化,变化中的自动化脚本维护工作量比较大。

6. 案例选择原则

  既然只是个准入门槛那就不会选择全部案例进行测试,根据经验,选择全部案例数的 40%-50% 测试通过率在 80% 左右即可视为冒烟测试通过,允许测试准入,那这部分案例如何选择呢?

  遵循以下原则

  A选取重要功能案例。

    重要功能案例至少应占冒烟案例的 30%,特别关注对软件功能实现具有重要影响的功能模块测试案例,例如:一个事件(业务)的增加、删除、修改、查询,一个统计、计算逻辑的的结果校验等。

  B选取主要流程

    主、分流程,对于主流程案例原则上应选取,分支流程案例可视其与主流程关联度和影响度从高到低选择部分。如主流程未通过,即使总案例通过率达到通过标准,该软件也应被拒绝准入,待开发人员修正后重新进入冒烟测试环节。例如:一个审批流程,即使增加、删除、修改、查询的功能均通过,但如果整个流程环节中出现阻塞,无法完成完整的审批,则应视为冒烟未通过。

  C筛选数据案例

    筛选与主流程、重要功能相关度高的数据测试案例,原则是确保数据的埋设满足主流程、重要功能测试条件。例如:想校验一个商品购买的正确性,就离不开商品种类、单位、库存、价格、购买数量等数据相关案例。这仅是一个简单的商品购买,如果是统计分析则更需要大量不同种类、不同时点的数据作为测试基础。

7. 涉及角色

  冒烟测试在测试环境搭建与执行过程中,涉及到的人员包括:测试架构师、管理自动化工厂的测试工程师、开发工程师、持续集成工程师、质量工程师。

8. 冒烟测试 V.S. 回归测试

冒烟测试,是版本验证测试,主要确认新的版本是否存在致命性bug,冒烟测试最大的优点在于节约测试的时间成本,减少测试轮数。

回归测试,是软件维护阶段对软件修改后进行的测试,指修改了旧代码后,重新进行测试以确认修改没有引入新的错误导致其他代码产生错误

摘录网址

  1. 什么是冒烟测试?什么时候做冒烟测试?
  2. 冒烟测试和回归测试的区别
  3. 「冒烟测试」是什么,怎样写出一个测试用例呢?
  4. 冒烟测试
  5. 你真的了解什么是冒烟测试么?
  6. 什么是 CI/CD?

原文地址:https://www.cnblogs.com/haimishasha/p/12243599.html

时间: 2024-10-01 04:20:37

软件测试系列——冒烟测试(Smoke Test,ST)的相关文章

冒烟测试(Smoking Tesing)

冒烟测试这一术语源自硬件行业.对一个硬件或硬件组件进行更改或修复后,直接给设备加电.如果没有冒烟,则该组件就通过了测试. 在软件中,“冒烟测试”这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程.在检查了代码后,冒烟测试是确定和修复软件缺陷的最经济有效的方法.冒烟测试设计用于确认代码中的更改会按预期运行,且不会破坏整个版本的稳定性. 冒烟测试据说是微软起的名字,可以理解为该种测试耗时短,仅用一袋烟功夫足够了.冒烟测试的对象是每一个新编译的需要正式测试的软件版本,目的是确认

软件测试系列之入门篇

一.你知道软件测试有多重要吗? 在国际上,软件测试(软件质量控制)是一件非常重要的工程工作,测试也作为一个非常独立的职业.在IBM.Microsoft等开发大型系统软件公司,很多重要项目的开发测试人员的比例能够达到1:2甚至1:4. 在国内软件测试的地位还不够高,并且大多只停留在软件单元测试.集成测试和功能测试上.软件测试从业人员的数量同实际需求有不小差距,国内软件企业中开发人员与测试人员数量一般为5:1,因此,国内的软件测试产业化还有待开发和深掘. 说到这里不知道你反应是高兴还是失望?但是我却

软件测试系列之了解篇

趣味小故事: Bug词原意臭虫或虫子. [第一个计算机Bug诞生68年]1945年9月,编译器发明者格蕾斯·哈珀正领着她的小组构造"马克二型"计算机.突然,马克二型死机了:哈珀在某出错继电器上发现一只被电死的飞蛾:她将蛾子贴到记事本中并注明"第一个发现虫子实例".从此,计算机错误称为Bug,将发现Bug并纠正的过程叫"Debug"! 一.缺陷 什么是软件缺陷(即bug) 计算机软件或程序中存在的某种破坏正常运行能力的问题.错误,或者隐藏的功能缺陷

软件测试系列之黑白盒

知识角: 软件分为两部分,一部分是数据,另一部分是程序.数据包括键盘输入,鼠标单击,磁盘文件,打印输出等:程序是指可执行的流程,转换,逻辑和运算.而我们测试最常用的一个方法也是按同样的方式划分进行测试. 一.软件测试的四种方法 软件测试常用的方法有黑盒测试,白盒测试,静态测试,动态测试. 先来简单的了解一下它们各自的含义吧: 黑盒测试 又称功能性测试或行为测试,在完全不考虑程序内部结构和内部特性的情况下,在程序接口进行测试.它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接

冒烟测试

冒烟测试的对象是每一个新编译的需要正式测试的软件版本,目的是确认软件基本功能正常,可以进行后续的正式测试工作. 在一般软件公司,软件在编写过程中,内部需要编译多个版本(Builds),但是只有有限的几个版本需要执行正式测试(根据项目开发计划) ,这些需要执行的中间测试版本,在刚刚编译出来后,软件编译人员需要进行基本性能确认测试,例如是否可以正确安装/卸载,主要功能是否实现, 是否存在严重死机或数据严重丢失等Bug.如果通过了该测试,则可以根据正式测试文档进行正式测试.否则,就需要重新编译版本,再

软件测试中常见测试流程

测试的流程: 需求阶段流程图: 单元/集成测试阶段流程图 系统测试阶段流程图 压力测试流程图 性能测试流程图 仅仅了解就够复杂的了,实际操作过程中的问题肯定更多.像压力测试.性能测试,一般的情况下我哪里用得上啊.虽然也知道些什么分布式应用.海量存储之类的,但是我连1T的数据都没见过.光说说那是是空话=.= 第二个问题:软件测试的常规方法. 软件测试中常见测试流程,布布扣,bubuko.com

引用文档-软件测试分类及测试中三个主要概念

软件测试分类及测试中三个主要概念 原文链接:https://blog.csdn.net/qq_35867537/article/details/77477775 1.      软件测试分类 按测试技术分 按测试技术,软件测试可分为:黑盒测试.白盒测试.灰盒测试 黑盒测试:在程序接口进行测试,它只是检查程序功能是否按照规格说明书的规定正常使用.也被称为功能测试或者数据驱动测试. 白盒测试:要完全了解程序结构和处理过程,它按照程序内部逻辑测试程序,检验程序中每条通路是否按预定要求正确工作.也被称为

如何通过冒烟测试前置来把控提测质量?

一 你是否碰到过开发提测速度很快,导致项目排队,结果介入测试时,第一条用例都跑不通的情况? 你是否碰到过因为开发提测质量差,导致反复修改,反复提测,反复重复验证的情况? 你是否碰到过因为开发提测质量差,导致一个修改影响了一大票老功能,从而让项目质量岌岌可危的情况? 你是否碰到过因为开发提测质量差,导致项目后期通过压缩测试时间来保证项目进度的情况? 你是否碰到过开发拍胸脯承诺这次肯定没问题,结果测试数据稍一变通就跑不通过的情况? 不管你有没有碰到过,我反正是全都碰到过. 有人说,这开发太水了,咋不

冒烟测试和回归测试的区别

区别: 冒烟测试就是完成一个新版本的开发后,对该版本最基本的功能进行测试,保证基本的功能和流程能走通.如果不通过,则打回开发那边重新开发:如果通过测试,才会进行下一步的测试(功能测试,集成测试,系统测试等等).冒烟测试优点是节省测试时间,防止build失败.缺点是覆盖率还是比较低. 回归测试我有两层理解,一是就是当你修复一个bug后,把之前的测试用例再次应用到修复后的版本上进行测试.二是当一个新版本开发好后,而且冒烟测试通过,此时可以先用上一个版本的测试用例对新版本进行测试,看是否有bug. 拓