51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 594|回复: 0
打印 上一主题 下一主题

[转贴] 软件测试 —— 冒烟测试(Smoke Test,ST)

[复制链接]
  • TA的每日心情
    无聊
    2024-7-11 13:41
  • 签到天数: 33 天

    连续签到: 1 天

    [LV.5]测试团长

    跳转到指定楼层
    1#
    发表于 2023-11-22 11:46:15 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    1. 核心
    冒烟测试就是完成一个新版本的开发后,对该版本最基本的功能进行测试,保证基本的功能和流程能走通。
      如果不通过,则打回开发那边重新开发;
      如果通过测试,才会进行下一步的测试(功能测试,集成测试,系统测试等等)。
    简化:门槛测试,一个开关而不是一个阶段。
    目的:版本验证测试BVT(Build Verification Testing)。
    时间:开发转测试,历时半至一个小时,很短。
    对象:需求覆盖,主功能路径。
    优点:节省测试时间,防止build失败。
    缺点:覆盖率还是比较低。
    操作:对着需求文档把新功能过一遍;把所有流程功能走一遍;用monkey跑个一两个小时;如果有历史用例的话,可以把用例分级,冒烟级、详细级、回归级等等
    用例:冒烟测试基本上不需要什么用例,如果有的话,就用详细用例里,覆盖需求文档级别的用例就可以了
    冒烟测试,是版本验证测试,主要确认新的版本是否存在致命性bug,冒烟测试最大的优点在于节约测试的时间成本,减少测试轮数。
    回归测试,是软件维护阶段对软件修改后进行的测试,指修改了旧代码后,重新进行测试以确认修改没有引入新的错误导致其他代码产生错误
    2. 定义
      冒烟测试这个名称的来历,最初是从电路板测试得来的。因为当电路板做好以后,首先会加电测试,如果板子没有冒烟再进行其它测试,否则就必须重新来过。
      而在软件研发中,冒烟测试其实是微软首先提出来的一个概念,和微软一直提倡的每日build(构建版本)有很密切的联系。具体说,冒烟测试就是在每日build(构建版本)建立后,对系统的基本功能进行简单的测试。这种测试强调程序的主要功能进行的验证,而不会对具体功能进行更深入的测试。
    3. WHY
    为什么进行冒烟测试?软件测试从业者都知道,bug发现的越晚,修复bug的成本就越高。那成本高在哪里呢?
    • 影响的代码多,开发的修复成本会增加
    • 影响的功能范围较大,测试回归的范围增加
    • 容易引发更多的bug,拉长测试周期,还有质量风险
    • 更多的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,冒烟测试最大的优点在于节约测试的时间成本,减少测试轮数。
    回归测试,是软件维护阶段对软件修改后进行的测试,指修改了旧代码后,重新进行测试以确认修改没有引入新的错误导致其他代码产生错误

    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏
    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-25 06:10 , Processed in 0.062681 second(s), 24 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表