51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 7637|回复: 11
打印 上一主题 下一主题

[资料] 冒烟测试

[复制链接]
  • TA的每日心情
    擦汗
    2017-10-23 11:42
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    跳转到指定楼层
    1#
    发表于 2008-12-10 01:33:46 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

    什么是冒烟测试

    [摘要] 关于冒烟测试,应该是微软首先提出来的一个概念,和微软一直 提倡的每日build有很密切的联系。具体说,冒烟测试就是在每日build建立后,对系统的基本功能进行简单的测试。这种测试强调功能的覆盖率,而不对 功能的正确性进行验证。从这一点看和所谓的“接受性(验收)测试(Acceptance Test)”非常相似。不同之处就在于他们执行的频率和被测的版本不同。

    [关键字] 软件测试 冒烟测试 验收测试
    关于冒烟测试,应该是微软首先提出来的一个概念,和微软一直提倡的每日build有很密切的联系。具体说,冒烟测试就是在每日build建立后,对系统的 基本功能进行简单的测试。这种测试强调功能的覆盖率,而不对功能的正确性进行验证。从这一点看和所谓的“接受性(验收)测试(Acceptance Test)”非常相似。不同之处就在于他们执行的频率和被测的版本不同。
    至于冒烟测试这个名称的来历,大概是从电路板测试得来的。因为当电路板做好以后,首先会加电测试,如果板子没有冒烟在进行其它测试,否则就必须重新来过。类似的如果冒烟测试没有通过,那么这个build也会返回给开发队伍进行修正,测试人员测试的版本必须首先通过冒烟测试的考验。

    冒烟测试的说法据说是:
    就象生产汽车一样,汽车生产出来以后,首先发动汽车,看汽车能否冒烟,如果能,证明汽车最起码可以开动了。说明完成了最基本的功能。
    冒烟测试一般用于每日构建(Nightly build),构建服务器首先从CVS服务器上,下载最新的源代码,然后编译单元测试,运行单元测试通过后,编译可执行文件,可执行文件若可运行,并能执 行最基本的功能,则认为通过了冒烟测试,这时,构建服务器会把程序打包成安装文件,然后上传到内部网站,第二天一早,测试人员来了以后,会收到构建服务器 发来的邮件提示昨晚是否构建成功。若构建成功,则测试人员进行相关的功能测试。所有这些功能的完成,一般是靠编写脚本完成的,目前比较常用的脚本有 TCL,Perl,Python及功能弱弱的批处理。用这些可以完成系统的每日构建。
    简单的说,就是先保证系统能跑的起来,不至于让测试工作做到一半突然出现错误导致业务中断。目的就是先通过最基本的测试,如果最基本的测试都有问题,就直接打回开发部了,减少测试部门时间的浪费

    冒烟测试准则
    在软件中,“冒烟测试”这一术语描述的是在将代码更改签入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后,冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行,且不会破坏整个版本的稳定性。
    注意:“冒烟测试”这一术语源自硬件行业。该术语源于此做法:对一个硬件或硬件组件进行更改或修复后,直接给设备加电。如果没有冒烟,则该组件就通过了测试。
    下面的准则描述了冒烟测试的最佳做法。遵循准则的效果会有很大的不同,从增强团队成员之间的交流,到形成特定的使用测试和调试工具的方式等。
    与开发人员协同工作
    由于冒烟测试特别关注更改过的代码,因此必须与编写代码的开发人员协同工作。必须了解以下内容:
    •        代码中进行了什么更改。若要理解该更改,必须理解使用的技术;开发人员可以提供相关说明。
    •        更改对功能有何影响。
    •        更改对各组件的依存关系有何影响。
    在进行冒烟测试前检查代码
    在运行冒烟测试前,进行侧重于代码中的所有更改的代码检查。代码检查是验证代码质量并确保代码无缺陷和错误的最有效、最经济的方法。冒烟测试确保通过代码检查或风险评估标识的主要的关键区域或薄弱区域已通过验证,因为如果失败,测试就无法继续。
    在干净的调试版本中安装私有二进制文件
    由于冒烟测试必须侧重于仅对更新后的二进制文件中的功能更改进行验证,所以必须通过使用被测试文件的调试二进制文件来使测试在干净的测试环境中运行。

    注意
    在冒烟测试中,使用不匹配的二进制文件进行测试是一个常见错误。为了避免此错误,当两个或多个更新后的二进制文件之间存在依赖项时,请在测试版本中包括所有更新后的二进制文件。否则,测试的结果可能无效。
    创建每日构建 (Daily Build)
    每日构建要求团队成员协同工作,并鼓励开发人员彼此保持同步。如果新版本的迭代被延迟,则该延迟很容易导致具有多个依赖项的产品不同步。遵循每日构建和冒烟测试的过程,任何更改过的或新的二进制文件都可确保实现高质量。
    有关设置重复版本的更多信息,请参见 在 Team Foundation Build 中运行生成。有关验证产品版本的更多信息,请参见如何:配置和运行生成验证测试 (BVT)。


    注意
    将高质量的每日构建作为团队最重要的任务。如果由于签入代码未进行冒烟测试而导致版本中断,则需要开发人员和测试人员停止所有其他工作,直到问题被解决为止。对导致中断版本的人员的处罚不应该很重,但这个处罚一定要能强调这样一个道理:正确的每日构建是团队最重要的任务。
    不需要执行穷举测试。冒烟测试的目的不是确保二进制文件 100% 没有错误。这样需要花费太多的时间。执行冒烟测试是为了在高级别验证版本。要确保二进制文件中的更改不会破坏常规版本的稳定性,也不会导致功能中出现严重错误。
    Web 测试和负载测试
    生成 Web 测试和负载测试时,在运行任何时间长、工作量大的测试之前运行冒烟测试是一种很好的做法。在 Web 测试和负载测试中,冒烟测试时间短,工作量也小。使用冒烟测试是为了在运行性能测试或压力测试之前,确保一切都已正确配置并可按预期运行。
    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏1
    回复

    使用道具 举报

    该用户从未签到

    2#
    发表于 2008-12-10 20:22:27 | 只看该作者
    Monkey Test
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    3#
    发表于 2008-12-16 12:37:21 | 只看该作者
    学到了
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    4#
    发表于 2008-12-16 13:40:14 | 只看该作者
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
    发表于 2008-12-16 14:31:12 | 只看该作者
        学习
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2009-1-14 17:36:45 | 只看该作者
    学习学习~
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2009-2-4 15:54:34 | 只看该作者
    非常不错,学习
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2011-7-20 09:46:17 | 只看该作者
    等会儿来看,还可以
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2011-10-9 20:52:49 | 只看该作者
    名称真多!
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2015-9-28 07:51
  • 签到天数: 6 天

    连续签到: 2 天

    [LV.2]测试排长

    10#
    发表于 2011-10-11 17:47:57 | 只看该作者
    我现在正在做冒烟测试。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2011-10-25 11:52:02 | 只看该作者
    冒烟测试 经常用的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2011-10-27 08:40:44 | 只看该作者
    谢谢分享
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-5-7 04:30 , Processed in 0.076644 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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