大叔大婶带你走一条接地气的测试进阶之路

【周问日答】(5)原来这就是持续集成啊?

上一篇 / 下一篇  2017-10-22 23:51:28 / 个人分类:测试问答

【提问】

原来这就是持续集成啊?

【旧识】

很多年前在做项目的时候,其实就已经接触到了持续集成,只是那时候好像没有这么一种叫法,或者说也没现在处于互联网产品时代的这么火热,所以,有相当长的一段时间,一直认为持续集成是个新生事物,自己一直都没有接触过它,很神秘。

那时候只是很简单的目的,为了方便、快速地生成可部署、可测试的包。

这不就是自动构建吗?
那时候,项目开始的时候,就会建立一个新的 branch,开发写完某个功能,或者修复完一个 bug,就将 code check-in 到对应的版本分支里,根据开发和测试的计划,大概在代码集成阶段就会在一个 web 端的 build 系统里去创建 Daily Build Job,每天在中国时间的凌晨开始,系统自动检测 svn 里对应分支是否有代码更新,并从中 check-out 最新的 code,然后构建成 build。如果构建出错了,会生成 build failed log,能通过日子定位到相关的代码和开发工程师。测试工程师早上来上班第一件事,就是从 build server 上下载最新的 build,然后部署,开始一天的测试工作。

这不就是自动部署吗?
后来,测试工程师为了提升工作效率,想让自己一到办公室就可以开始测试,于是基于这个 Auto Build 系统,又开发了 Auto Deployment 脚本,自动检测是否有最新的包,有的话就去下载并自动安装。

这不就是自动验证吗?
再后来,测试工程师为了再次提升工作价值,让自己每天聚焦在更有意义的 bug 深度挖掘工作上,又将 BVT Automation 集成了进去,当自动部署完成之后,自动执行 BVT TA 脚本,用于检测最新的构建包是否存在一些很浅显的和阻碍性的缺陷。

最近,因为越来越多的同学会问到持续集成的问题,所以找了一些书和资料,学习了一下,然后问了自己一个问题:原来这就是持续集成啊?

【新知】

这几年持续集成的兴起,并不是因为测试工程师越来越“懒”,而是随着互联网产品的运营模式和敏捷研发的广泛应用,提升研发团队持续交付能力的一个很重要的技术越来越受用,那就是持续集成。

我们先来看看引入持续集成的好处:

  1. 随着项目越来越大,越来越复杂,每天各种各样的开发工程师都在 check-in 代码,如何能快速发现其中会导致构建失败的错误代码呢?-- 持续集成
  2. 随着研发速度越来越敏捷,测试工程师可能随时都需要一个可测的版本去验证 bug,做回归测试,而不能等待所有的开发都提交了最新的、完整的代码,再打一个没问题的测试包,那怎么办呢?-- 持续集成
  3. 产品也需要经常拿一个可用的、最新的版本去体验最新的功能,去验收已经完成的需求,他可以找谁呢?-- 持续集成
  4. 每日构建其实是一个重复性的活动,但又需要人每天去做这么一件事情,在它完成之前,大家都得等着,假如测试人员来的很早,那负责每日构建的人就要来的更早,怎样才能既减少人力的重复劳动,又能提高效率呢?-- 持续集成
  5. 我们现在有很多自动化测试工具、静态扫描工具和性能测试工具,那怎样才能让它们在有限的测试周期中发挥及时、有效的作用呢?-- 持续集成

作者简介:14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵


TAG: 软件测试 问答 测试技术

 

评分:0

我来说两句

日历

« 2024-03-25  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 71525
  • 日志数: 82
  • 建立时间: 2017-09-03
  • 更新时间: 2018-01-11

RSS订阅

Open Toolbar