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

【周问日答】(6)做到什么样才算是真正的持续集成?

上一篇 / 下一篇  2017-10-24 08:36:56 / 个人分类:测试问答

【提问】

做到什么样才算是真正的持续集成?

【旧识】

我本以为只要做到单元测试、每日集成和每日构建,就算是持续集成了。

  1. 开发工程师完成单元测试,提交代码至代码库;
  2. 开发工程师根据测试需求或项目计划,手工编译、打包各个组件包;
  3. 开发工程师在测试环境的相关服务器上部署不同的组件包;
  4. 开发工程师检查所有服务是否可以正常启动;
  5. 测试工程师执行 BVT 测试,确保基本功能正常;
  6. 测试工程师开始验证修复的缺陷,做回归测试和功能需求测试;

即使玩转了这个流程,也是存在一些问题的:

  1. 步骤1~4所需时间较长,还不包括中途出了问题,联调排查所耗费的时间;
  2. 步骤1~4需要等待开发工程师执行,在成功完成之前,测试工程师都处于等待状态;
  3. 步骤5如果发现 Block Issue,测试无法进行下去,还得重复步骤1~4,测试工程师又需要等待;
  4. 通常问题都是产生在第一天,而到第二天才会被发现,而且这些等待所消耗掉的时间都是宝贵的工作时间;

【新知】

要想解决存在的问题,就需要做到真正的持续集成(Continuous Integration, CI),从问题本身来看解决方案,其实就是在测试工程师第二天上班开始验证 bug 和开始测试工作之前,就把最新的、没有问题的、可测的版本包部署到测试服务器。

  1. 开发工程师提交代码至代码库,定时触发或事件触发自动完成单元测试和代码检查;
  2. 系统自动构建相应的组件包,定时触发或事件触发编译和打包动作;
  3. 在测试环境的相关服务器上自动部署相应的组件包;
  4. 部署完成后,自动执行 BVT 测试脚本;
  5. 自动发送部署结果和 BVT 测试结果;
  6. 单元测试、代码检查、编译、构建、部署和测试过程中的任何一个 block 问题都会自动报警,并通知相关工程师及时处理;
  7. 步骤1~6都可以通过 cron job 定时在下班后开始执行;

持续集成只是技术手段上的改进和优化,为了达到最终的目的,也就是持续交付(Continuous Delivery, CD),还有很多思想层面和工作方法方面需要提升。

我一直认为引入持续集成的难点在于重构的成本,你要想引入持续集成,你的代码结构可能需要重构、环境架构可能需要调整、你的自动化测试脚本更新速度要能跟的上持续集成的节奏。

这一切都需要投入一定的人力和物力,而且这些还都需要在项目进行的过程中,安静、有序、无害地被完成,因为项目的成本或工期制约,通常很难有一段完整的空档期去完成持续集成的引入和部署,所以,这个风险需要在项目初期考虑进去,尽量选择内部研发的项目进行试点推行。


TAG: 测试知识 测试问答

 

评分:0

我来说两句

日历

« 2022-09-28  
    123
45678910
11121314151617
18192021222324
252627282930 

数据统计

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

RSS订阅

Open Toolbar