大叔大婶带你走一条接地气的测试进阶之路
【周问日答】(6)做到什么样才算是真正的持续集成?
上一篇 /
下一篇 2017-10-24 08:36:56
/ 个人分类:测试问答
【提问】
做到什么样才算是真正的持续集成?
【旧识】
我本以为只要做到单元测试、每日集成和每日构建,就算是持续集成了。
- 开发工程师完成单元测试,提交代码至代码库;
- 开发工程师根据测试需求或项目计划,手工编译、打包各个组件包;
- 开发工程师在测试环境的相关服务器上部署不同的组件包;
- 开发工程师检查所有服务是否可以正常启动;
- 测试工程师执行 BVT 测试,确保基本功能正常;
- 测试工程师开始验证修复的缺陷,做回归测试和功能需求测试;
即使玩转了这个流程,也是存在一些问题的:
- 步骤1~4所需时间较长,还不包括中途出了问题,联调排查所耗费的时间;
- 步骤1~4需要等待开发工程师执行,在成功完成之前,测试工程师都处于等待状态;
- 步骤5如果发现 Block Issue,测试无法进行下去,还得重复步骤1~4,测试工程师又需要等待;
- 通常问题都是产生在第一天,而到第二天才会被发现,而且这些等待所消耗掉的时间都是宝贵的工作时间;
【新知】
要想解决存在的问题,就需要做到真正的持续集成(Continuous Integration, CI),从问题本身来看解决方案,其实就是在测试工程师第二天上班开始验证 bug 和开始测试工作之前,就把最新的、没有问题的、可测的版本包部署到测试服务器。
- 开发工程师提交代码至代码库,定时触发或事件触发自动完成单元测试和代码检查;
- 系统自动构建相应的组件包,定时触发或事件触发编译和打包动作;
- 在测试环境的相关服务器上自动部署相应的组件包;
- 部署完成后,自动执行 BVT 测试脚本;
- 自动发送部署结果和 BVT 测试结果;
- 单元测试、代码检查、编译、构建、部署和测试过程中的任何一个 block 问题都会自动报警,并通知相关工程师及时处理;
- 步骤1~6都可以通过 cron job 定时在下班后开始执行;
持续集成只是技术手段上的改进和优化,为了达到最终的目的,也就是持续交付(Continuous Delivery, CD),还有很多思想层面和工作方法方面需要提升。
我一直认为引入持续集成的难点在于重构的成本,你要想引入持续集成,你的代码结构可能需要重构、环境架构可能需要调整、你的自动化测试脚本更新速度要能跟的上持续集成的节奏。
这一切都需要投入一定的人力和物力,而且这些还都需要在项目进行的过程中,安静、有序、无害地被完成,因为项目的成本或工期制约,通常很难有一段完整的空档期去完成持续集成的引入和部署,所以,这个风险需要在项目初期考虑进去,尽量选择内部研发的项目进行试点推行。
相关阅读:
- 如何有效控制需求变更?【转】 (fengyun32, 2009-1-08)
- WEB测试总结(架构、设计)--参考 (fengyun32, 2009-1-08)
- 软件测试知识(1) (muyang327, 2009-2-14)
- 软件测试知识(2) (muyang327, 2009-2-14)
- 测试人员的误区:迷信自动化 (fengyun32, 2009-3-05)
- Web测试需要了解的知识 (zzzmmmkkk, 2013-6-02)
- 软件测试知识框架——黑盒 (Aimelyccc, 2013-6-24)
- 【周问日答】(1)测试策略能帮助我们做什么? (sunsky528, 2017-10-18)
- 【周问日答】(2)制定测试策略有没有章法可循? (sunsky528, 2017-10-19)
- 【周问日答】(3)为什么一定要做单元测试? (sunsky528, 2017-10-21)
收藏
举报
TAG:
测试知识
测试问答