收藏本站 收藏本站
积木网首页 - 软件测试 - 常用手册 - 站长工具 - 技术社区
软件测试 > LoadRunner > 正文

首页 | 领域细分: 游戏测试 安全测试 手机测试 Web测试 | 技术研究: 单元测试 入门教程 用例设计 性能测试 功能测试 | 测试职场: 面试精选 职场发展 面试试题

测试管理: 配置及流程 - 需求管理 - 质量验收 - 缺陷管理 - 其它管理相关 | 开发语言: PHP技巧 - PHP基础 - PHP实例 - PHP错误代码

测试工具: LoadRunner JiRa QuickTestPro RoBot WinRunner TestDirector 其它测试工具 | 数据库: Mysql数据库 Oracle数据库 CSS/DIV基础 HTML基础

阳光互帮互助小组每日一帖-冒烟测试

来源:互联网 日期:2012-08-11 11:00
什么是冒烟测试
[摘要] 关于冒烟测试,应该是微软首先提出来的一个概念,和微软一直 提倡的每日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 测试和负载测试中,冒烟测试时间短,工作量也小。使用冒烟测试是为了在运行性能测试压力测试之前,确保一切都已正确配置并可按预期运行。

本周排行

别人正在浏览

强悍的草根IT技术社区,这里应该有您想要的!
Copyright © 2010 Gimoo.Net. All Rights Rreserved  京ICP备05050695号