每日构建和冒烟测试

谈每日构建都会连带谈冒烟测试这个词。每日构建不是简单的指每日编译,编译和构建完成后必须对增加的新功能点进行系统测试,对已经测试过的功能点进行冒烟测试。每日构建是微软比较推荐的最佳实践,强调测试的早期介入和持续的版本集成。

  每日构建和冒烟测试的优点主要有:

  1、进度可见并可以控制到1-2天的细粒度,很容易看到进度的偏差

  2、及早的发现开发BUG和缺陷并分析解决,对开发人员的一种监督和促进,提高软件质量

  3、由于将大集成分解到每日构建中的小集成,避免了传统产品集成或集成测试时候出现的严重问题的可能。

  4、在项目中宣灌质量意识,强调第一次就把事情做好,而不是等测试来帮你发现问题

  每日构建和冒烟测试也存在一些风险和缺陷,具体主要有:

  1、给开发人员太大压力,开发每天都在较紧张环境中工作

  2、需要额外的测试人力资源和每日构建硬件环境的投入

  3、开发人员不能专注,既要分心去修改BUG,又要开发新的功能点

  4、对开发负责人要求更好,需要将功能细化到1-2天的有明确输出的功能点

  5、开发需要投入额外的精力来保证每日构建顺畅

  适用场景:

  1、对进度偏差控制和要求很高的项目

  2、开发检查点和里程碑制定的很细致的项目

  3、采用增量和迭代开发的项目,快速和敏捷开发的项目

  每日构建提前需要进行的准备工作:

  1、对开发进度计划的要求,需要细化出每1-2天的开发进度计划,可以到一个很小的功能点。

  2、对每日构建测试计划的要求,需要根据开发进度计划来安排冒烟测试和系统测试进度计划。

  3、需要提前准备好每日构建的环境(每日构建必须是独立的环境)

  每日构建和冒烟测试工作的实现可以人工来实现,但更多的需要借助些自动化的工具来完成。对于每日构建一般要提前编写好每日够建的脚本,可以借助Ant或NAnt构建工具来完成。每日构建脚本的复杂性跟项目或系统本身复杂性相关,对于简单的只有一个项目的解决方案,可能构建脚本会很简单,而对于较复杂的系统或项目构建脚本将会教复杂。NAnt是一个强大的通过构建脚本自动编译的工具,像我现在的项目在NAnt里面会做如下事情,而这个即使打开解决方案来编译也无法做到。

  1、调用批文件重新自动生成数据访问层组件

  2、创建相关的部署需要的cs_client,bs_client,server,service相关目录并拷贝公用文件

  3、按照公用项目->逻辑层->界面层顺序和项目间依赖关系对各个项目逐一编译

  4、调用外部工具soapsuds生成数据访问dll的代理类文件,逻辑层重新引用代理类进行编译(分布式部署需要)

  5、引用3,4步需要的dll对Web项目进行编译

  6、拷贝编译结果到相关的输出目录

  每日构建和每日编译的最大区别就在于是否进行了冒烟测试,系统必须通过了冒烟测试才能够算每日构建成功。而测试人员人工介入的测试是基于冒烟测试通过的基础上面的。这里很简单一个例子,如我们NAnt配置文件忘记拷贝一个公共文件到server目录了,这个时候每日编译可能是通过的,但如果把这个版本部署出去测试无法进行测试的。或者说冒烟测试的一个重要作用就是要彻底解决由于构建自身原因引起的各种缺陷或Bug。

  冒烟测试由于要验证整个编译的正确性,因此冒烟测试必须是针对整个系统进行冒烟测试。但冒烟测试只需要关注系统的主体功能即可,通过冒烟测试并不是说系统没有BUG,只是说通过了冒烟测试后可以说系统是一个稳定的版本,说系统的每日构建是成功了,代表系统可以转交专门的测试人员进行测试了。冒烟测试工作一般要采用自动化来进行,可以借助如LoadRunner等工具来录制自动化测试脚本,冒烟测试的脚本应该由专门的测试人员来维护,而且随着测试的进展冒烟测试脚本也应该是不断增加和补充的。

  对于每日构建失败,直接责任的开发人员需要程度责任并付出代价。微软顾问经常爱举的一个例子就是凌晨2,3点开发人员被叫到公司解决每日构建失败的问题的案例。实际操作可能很难,但对构建造成影响的必须要承担应有的责任。

  每日构建一般要配合使用源代码管理工具,而构建时间一般安排在每天下班后或晚上进行。开发人员需要保证每天检入的代码是能够顺利编译通过的,并保证在本机已经做了相关测试。每日构建并不是一定要要求每天都有新的功能点完成,如果今天开发完成的东西不是一个独立的可以提交测试的功能点,这个时候当天的源代码最好不要检入。代码的检入周期一般要在2-3天内,如果周期再长基本上就达不到每日构建的作用了。

  每日构建必须有独立和专门的构建服务器和构建环境。构建服务器和构建环境与测试环境的最大区别在于构建环境是完全Copy开发环境,单独出构建环境目的是保证构建过程不和开发环境和过程冲突。如果条件不允许的话可以将构建环境和测试环境合并,但构建环境必须和开发环境分离。

  每日构建的成功要素:

  1、每天都进行编译和冒烟测试

  2、冒烟测试脚本随着测试的进度不断完善和补充

  3、构建成功在项目中拥有较高的优先级

  4、通过过程的制定保证构建失败更多的是因为异常因素而非规则不清

  5、在压力下不要抛弃过程

====================================分割线================================

最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-10-04 18:38:48

每日构建和冒烟测试的相关文章

Ubuntu 17.10 每日构建 ISO 发布,仍使用 Unity 7 桌面环境

Ubuntu 17.10 (Artful Aardvark) 首个每日构建 ISO 映像正式开放下载. 刚公布发布日程表的 Ubuntu 17.10 现在已发布首个每日构建 ISO 映像.现在是它们更紧密地监控其开发周期的时候了,毕竟这是Ubuntu 时隔六年,决定放弃 Unity 桌面环境,回归 GNOME 桌面环境的过渡时期. Ubuntu 11.04 (Natty Narwhal) 于 2011 年 4 月 28 日宣布使用 Unity 作为默认桌面环境.这一举动在当时引起了不小的争议,U

Mozilla发布Servo浏览器每日构建版

试验性浏览器项目Servo背后的团队宣布提供每日构建版的下载. 截至目前,Servo只以源代码的形式提供,开发人员需要下载后自己编译.Servo团队希望,每日构建版(下载地址download.servo.org)能够扩大该浏览器的使用范围,并最终改进它的Web功能和性能.目前只提供Mac OS X和Linux版本,Windows和Android版本的问题还在处理中.每日构建版本现在还很不完善. 这个新浏览器的开发已经持续了数年之久.它是从头开始构建的,旨在构建一个全新的并行浏览器引擎,更好地利用

从单元测试到基于每日构造的自动测试

1.单元测试 XXXX作为一个新项目,和其他所有项目一样,在开发工作进行之初就在考虑如何保证代码开发的质量.答案很容易找到:充分的单元测试.但是以前真正做得好得项目却不多. 经过分析,总结了一下做好单元测试工作的四个要素: ――思想上的重视 ――计划上保证 ――测试手段保证 ――测试效果的可验证 1.1 思想上重视 从以往的开发过程总结了一些教训: ――开发人员模块在交付联调前,测试不充分,导致联调周期较长 ――代码进入维护期后,修改代码往往引起不可预期的错误.导致开发人员比较害怕在相对稳定的代

在.NET环境中实现每日构建(Daily Build)--ccnet,MSBuild篇

每日构建,对我们团队来说一个全新的概念.随着项目开发的进展,在开发过程需要及时反馈一些BUG 和功能要求的处理情况.而在这种情况下每天或隔一段时间Build一个版本,工作量还是比较大的,所以 就特别有必要引入每日构建.关于每日构建,在园里有已经有很多的文章了,特别是摩诘的<在.NET环境 中实现每日构建(Daily Build)--NAnt篇>更是从概念上和实践上手把手地介绍如果在.NET环境下实现每 日构建.但很遗憾,在我实现每日构建之前没有看到这篇文章,错失了一次快速入门的机会,不过感到庆

Linux 版 Firefox 每日构建版现在使用 Gtk+3

从7月23日的每日构建版(Nightly)开始,Firefox for Linux默认启用Gtk+3构建.以前Firefox for Linux默认启用的是Gtk+2.GTK+是GIMP和GNOME等自由软件项目采用的构建GUI的一套工具集,Gtk+3在2011年发布,过去几年已经有许多原来采用的Gtk+2的项目改用到了Gtk+3.Gtk+3今年早先时候已经进入到了Linux nightly中,但没有默认启用,需要到about:config中设置一下. 文章转载自 开源中国社区 [http://

200分(我只能发100分的帖子)求答案 每日构建

问题描述 我想做的是用svn+ant+cruiseControl来实现每日构建.我用ant从SVN服务器下载项目,然后用cruiseControl来定时构建.部署这个项目,再发邮件通知管理员有关这个项目的构建情况.请问谁能给我讲讲具体的步骤和过程,能结合小实例讲就更好了,求高人帮忙解决问题啊! 解决方案 解决方案二:该回复于2011-04-08 11:28:58被版主删除解决方案三:不懂,坐等高人的解决,学习思路....解决方案四:该回复于2011-04-08 14:41:57被版主删除解决方案

《配置管理最佳实践》——2.11 持续集成与每日构建

2.11 持续集成与每日构建 持续集成是一个相当流行的软件开发实践.现在,人们时常把持续集成和敏捷开发联系到一起.实际上,即使开发团队使用的不是敏捷开发的过程, 持续集成在他们之间也已经非常流行.另外一个很明显的现象是很多研发团队并不需要签入构建(commit build, check-in build),也就是说并不需要每次有代码签入代码库都要立刻触发一个构建.很多时候,每日构建已经足够用了,而且也容易实现.持续集成经常会发起很多没必要的失败构建,导致显示面板上出现很多没必要的失败记录.某些构

项目管理实践【三】每日构建【Daily Build Using CruiseControl.NET and MSBuild】

在上一篇项目管理实践教程二.源代码控制[Source Control Using VisualSVN Server and TortoiseSVN]中我们已经讲解了如何使用TortoiseSVN和VisualSVN Server来做简单的版本控制,这一篇我们将会讲解使用CruiseControl.NET和MSBuild来搭建每日构建系统. 在第一篇项目管理实践教程一.工欲善其事,必先利其器[Basic Tools] 中我们已经安装了CruiseControl.NET 1.4,因为我们还要用到MS

由点到线,关注测试进度

作为测试人员,以前的我们每天参照图1来了解手上还有多少活. 图1:等待测试的用户故事个数 存在的问题: (1)只有故事数量导致我们看不到故事后面工作量的变化.例如,今天测试通过,关闭了3个小的用户故事,但同时今天开发提交了3个大的用户故事.从数量上看,昨天和今天的待完成工作是一样的.在这张图表的暗示下,我们有时要刻意地拒绝优先测试那些比较简单的故事以便让这个数字快速变小的诱惑. (2)只看目前手头还有多少未完成的工作无法让人产生太多的成就感或者紧迫感.因为伴随着每日构建,待测试的故事数此消彼长,