接口测试—持续集成与Cruisecontrol

1 持续集成概念引入

在没有应用持续集成之前，传统的开发模式是项目一开始就划分模块，然后等所有的代码都开发完成之后再集成到一起进行测试。随着软件技术的发展，各种 软件方法百花齐放，软件规模也在扩大，软件需求越来越复杂，软件已经不能简单地通过划分模块的方式来开发，需要项目内部互相合作，划分模块这种传统的模式 的弊端也越来越明显。由于很多 bug 在项目的早期就存在，到最后集成的时候才发现问题，开发者需要在集成阶段花费大量的时间来寻找 bug 的根源，加上软件的复杂性，问题的根源很难定位，甚至出现不得不调整底层架构的情况。在这个阶段的除虫会议（bug meetings）特别多，会议的内容基本上都是讨论 bug 是怎么产生的，最后往往发展成为不同模块的负责人互相推诿责任。

持续集成最大的优点是可以避免这种传统模式在集成阶段的除虫会议。持续集成主张项目的开发人员频繁地将他们对源码的修改提交(check in)到一个单一的源码库，并验证这些改变是否对项目带来了破坏，持续集成包括以下几大要点：

1.1 访问单一源码库，将所有的源代码保存在单一的源码库， 让所有人都能从源码库获取最新的源代码（以及以前的版本）。

1.2 支持自动化构建脚本，使构建过程完全自动化，让任何人都可以只输入一条命令就完成系统的构建。

1.3 测试完全自动化，要求开发人员提供测试的代码，让任何人都可以只输入一条命令就运行一套完整的系统测试。

1.4 提倡开发人员频繁地提交（check in）修改过的代码。

持续集成的关键是完全的自动化，读取源代码、编译、连接、测试，整个构建过程都应该自动完成。对于一次成功的构建，要求在这个自动化过程中的每一步都不能出错，而最重要的一步是测试，只有最后通过测试的构建才是成功的构建。

 

2 CruiseControl框架体系

CruiseControl 是一种持续集成过程的框架，包括了旺旺消息通知、邮件通知，Ant、Maven 和各种源码控制工具（SVN、CVS）的插件，并提供了web接口，用于查看当前和以前的构建的结果。下面如无特殊说明，将用CC 来代表CruiseControl。

 

Fig 2.0 CC简单部署图

 

图Fig 2.0描述了持续集成的硬件环境。图中包括了一台独立的源码库服务器，以及开发人员的终端，同时也可以是源码库服务器的客户端。可以看到，CC 在一台独立的服务器上运行，这是推荐的一种结构，出自对性能和不影响原有的开发环境的考虑。当然也可以将 CC 放在源码库的同一台服务器上甚至某个开发人员的终端上。从这个图还可以看出，能比较容易的将 CC 引入到现有的开发模式中，只需要增加一台独立的服务器。

 

3 CruiseControl自动构建机制

持续集成最重要的特征之一是自动化，而CC的 Build Loop 就是为支持自动化而设计的，Build Loop 也是 CC 的核心。

Build Loop 从字面上理解就是循环构建的意思，CC 提供了一个daemon进程，该进程自动根据配置的时间间隔，也可以指定某个具体时间，来读取CC配置文件并进行循环构建（build cycle），每次 CC 都会重新加载配置文件，因此修改了配置文件不用重新启动CC。

Build Loop过程的工作流程如下：访问源码控制系统，查看是否有代码被修改，如果有，从最后提交时间开始等待一个quiet period的时间后，获取源码的新版本，并根据配置对源码进行一次 Build，构建一个日志文件，最后向开发、测试人员通知 build 的结果。下图是Build Loop的工作流程。

 

Fig 3.0 CC自动构建流程

关于Cruisecontrol的详细配置将在稍后连载，敬请关注！ 

 

VN:F [1.9.6_1107]

please wait...

Rating: 9.0/10 (1 vote cast)

接口测试白皮书连载---持续集成与Cruisecontrol , 9.0 out of 10 based on 1 rating 转载务必注明出处Taobao QA Team