本文描述在VcTester的IDE环境下实施持续集成的组织管理模式，也即，先理解持续集成在VcTester环境大致是如何组织的，涉及源码与测试代码如何维护，版本管理如何组织等。在了解这些基础知识之后，我们在另一篇文章《使用VcTester构造持续集成及每日构建平台》中再详细介绍如何使用VcTester工具一步一步去操作。

为什么要持续集成？

持续集成是一种先进的研发模式，极限编程、微软每日构建等实践都验证了它是高效的开发手段。Steve McConnell在《IEEE Software best practices: Daily Build and Smoke Test》一文中总结了这种操作模式具有如下优点：

1、 能最小化集成风险

2、 能减小产品低质量的风险

3、 能简单化错误诊断

4、 能极大鼓舞项目组的士气

大家可能认为每日构建是一件很难的事，其实不然，只要方法得当、流程措施有力，每日构建还是容易做起来的。想象一下，Windows NT是无比复杂的系统，包括了560万行代码，共有4万个源文件，微软仍能坚持每日构建。对于我们只有十数万行规模的产品，做一做每日构建又能有多难呢？！

每日构建、冒烟测试、持续集成

这几个概念存在一些差异，前两者来源于微软件的实践，后者持续集成意含较为广泛，虽非XP的专有实践（实际上，在XP实践之前已有不少公司在实践持续集成了，象IBM早在上世纪60年代就尝试集成迭代开发模式，类似持续集成，提法不同而已），但许多人认为它发端于极限编程。

每日构建指研发中的版本能每天自动构建，每日构建常配合冒烟测试，而在XP的持续集成概念，应包括版本能自动构建，同时遵循“代码写一点测一点”的开发模式，包括了测试实践方面的一些规定。

应该说版本构建是公共的，持续集成的相关测试是私有的，如下图，每日构建由服务器自动完成，生成最新版本供全产品人员使用（甚至用于产品发布），不同角色的测试人员各自取最新版本各自展开工作，即使同一阶段的测试工作，不同测试人员所针对的被测特性各不相同，每个人都针对其中的一个剖面开展工作。

测试脚本该由谁来维护

持续集成实践集中于编码与白盒测试阶段，通常是自己编码自己测试，既然要坚持持续集成了，日积月累的测试脚本该由谁来维护呢？是不是每次测试后都将大家的脚本合并一起？许多人都对这个问题感到困惑，从表面上看各人的脚本应该合一起维护，但合一起后，又如何维护呢？大家都互不熟悉别人的脚本是怎么写的。

第4代白盒测试的方法论指出，测试代码也是一种产品代码，应与产品源码对等的看待。理解这一点，我们不难推断，测试脚本也应该是“谁编写就归谁维护”，因为产品源码就是这么做的。

另一个问题，白盒测试用例需不需要合并？在单元测试阶段，测试用例是不必合并的，谁写的用例就归谁使用，也归同一个人维护，不存在把大家的用例合并起来的需求。当然，特定情况下，比方从各人维护的用例库中抽取部分基础用例，构造冒烟测试集，这时是有合并需求的，但该情况应视为特例，因为构造冒烟测试集，只是简单的从已有用例中挑选，选出用例的维护责任不应发生迁移。

在集成测试阶段，测试用例也不必合并，如果是自己设计用例测试自己写的代码，这类用例没必要与别人合并。如果是较高层次的集成，不是自己测自己了，比方系统级集成测试，由专门的测试人员针对模块接口（或子系统接口）编写用例，这时，一人写脚本测试多人编写的代码，或者多人写脚本测试多人编写的代码，其用例设计可能有合并的需求。当然不合并也可以，无非回归测试时，按多个工程的测试集分别去跑，若要合并，目的也不外乎让用例维护更方便些，我们把多人设计用例看成工作分摊的一种手段，合并用例的过程可视作用例设计的固有过程，也即，合并前每个人都维护自己的测试工程，合并后，各人的测试工程在新工程下体现为一个测试集分支，在VcTester中，测试集是可以层层嵌套的，测试集合并后要处理各个集合之间的相互关联、或相互影响的关系，这自然应被看作一种测试设计过程。所以，如果将甲和乙设计的测试用例合并，合并工作由丙承担，合并后所有用例又转移给丁维护，那么，合并后甲、乙、丙都得向丁交接工作。

总结一下，代码与用例的维护责任遵循一个原则：代码或用例是谁写的就该由谁来维护，将多人维护的用例合并，其过程也是一种测试设计过程，这完全类似于功能模块的集成过程，将多人开发的模块合起来是联调，没人把联调不看作一种开发工作。

日常调试与规范测试

VcTester遵循第4代白盒测试方法的理念，将测试脚本与产品源码对等的编辑、调试、测试与维护，如下图：

编辑及调试产品源码，与编辑及调试测试脚本不仅在同一IDE环境下进行，而且几乎同时或者说紧密交叉着推进，一次调试中我们几乎无法区分当前操作是为了把源码调通过，还是为了把脚本调通过。结果评估也是，考察产品功能是否正确，与判断当前测试是否通过几乎重合，测试通过常意味着产品功能跑正确了，反之亦然。

从上图还可看出，产品源码或测试脚本的调试方式（Debug方式）运行，与发布方式（Release方式）运行存在一些区别。首先，Debug运行是日常工作的主体，Release运行是阶段性工作，或者说，将日常调试成果按规范方式运行一遍；其次，Debug方式下针对脚本的工作与针对源码的工作混杂一起，两者并不严格区分，而Release方式下两者是严格区分的，源码编译后成为用于发布的产品，批量运行脚本则是正规测试，如回归测试、冒烟测试等。

由上述差异，我们不难看出，日常调测与规范测试在持续集成实践中应该分开操作的，日常调测遵守一种工作形式，规范测试遵守另一种形式。在VcTester环境下，调试是很自由的，任意写一段脚本，选中执行就能读写变量、调用被测函数，此方式下，编写脚本及产品代码不拘形式，不必时时按照规范的格式进行，而规范测试则有严格要求，至少，产品源码与测试脚本能编译通过，运行产品或运行脚本要使用一个确定的调用入口。

再进一步，持续集成的日常调试中，在VcTester集成环境下调试源码与脚本，需支持将当前工作文件从版本机checkout或checkin，也支持VC工程自动构建（将build/rebuild/clean等操作集成到VcTester环境），我们可借助菜单或快捷键完成这几种操作。但开展规范测试不必再依赖VcTester环境，写一个批处理文件用DOS命令就把需要的源码文件或脚本模块从版本机取出来，也用DOS命令自动编译被测工程，及启动被测系统运行。

所以，理解了上述日常调测与规范测试两种工作形式，我们就不难理解VcTester为什么要采用“远端交互运行”与“本端自动运行”这两种模式，更详细信息请参考《VcTester共享版使用手册》中“远端模式与本端模式”一节。

持续集成是以开发人员为主体的工作，开发人员自己写代码，同时自己编写用例进行白盒测试。前面提到这些测试操作是私有的，每位开发人员都在同一被测工程的某一视图展开工作。所以，在VcTester集成环境中他只需打开自己关心的几个被测文件与用例文件。日常调试时，被测工程使用一个宏开关控制当前系统处于“交互运行”模式，而回归测试时，自动构建服务器定义特定宏开发编译出“自动运行”模式下的被测程序，每位开发人员可在他的桌面平台编写一个批处理程序，把从服务器获取测试版本、启动测试等步骤集成在一起，运行该批处理程序就启动规范测试了。

持续集成的组织形式

实施持续集成不仅是IT工具的问题，更是流程管理的问题，如果流程不规范或管理不恰当，也常常导致持续集成做不下去。前面我们理清了用例的维护方式，以及日常调试与规范测试的区别，这两个容易误解的问题解决后，我们再讲讲持续集成该如何去组织。当然，法无常法，道无常道，持续集成应用于不同企业有不同的工作方式，这里我们只讲述持续集成的一般组织形式，以及实施过程中的注意事项。

实施持续集成首先要具备一个良好的组织机构，至少，要指定一个每日构建负责人，可以由版本管理员兼任，如果在大规模的研发团队中，不妨设置一个专职的构建负责人，该负责人将对维持正常的每日构建运作承担主要责任。之外，还得有质量或测试方面的负责人，确保每日构建生成的版本有相应的动态测试或静态测试跟进，并保证测试达到某一质量目标。

其次，制定严格的管理措施，应强调：

1. 每日构建应每天都做，即使源码没有更新，也要每天去build。

2. 保证导致构建中断的任何问题立即解决

3. 应有措施保证每次代码checkin有修改记录，每日构建负责人还要维护每日构建的操作记录，构建记录有助于回溯某些BUG从哪个版本开始引入的。

4. 需要始终保持“写一点测一点”的开发模式，使用VcTester工具应严格遵循“红绿灯通行机制”（参见《第4代白盒测试方法介绍（理论篇）》），对测试设计不能及时跟进的行为要有控制措施。

然后，持续集成还要有恰当的特性开发进度配合。请注意：

1. 应事先规划各个基线版本，包括不同层次的版本，如路标版本、特性版本等，明确各个版本的交付日期

2. 在恰当时间点冻结特性、冻结代码

3. 要让持续集成行之有效，还得将开发任务分解到足够小

最后，我们再强调一下，持续集成应坚持质量优先的理念，凡有BUG应先解决BUG才能进入下一步开发，每完成一项开发任务（通常以两、三天为单位），测试跟进后，若测试覆盖率指标或测试程度指标没达到要求时，应先增加用例设计使测试较为充分后，才能进入下一个功能开发。质量优先原则与进度要求并不矛盾，通常坚持质量优先并不拖后进度，而坚持进度优先的，常常是进度后拖了，质量又没得到保证。

参考文献：

1. Steve McConnell, "IEEE Software best practices: Daily Build and Smoke Test"

2. Microsoft Press, 1995, "Dynamics of Software Development"

3. ezTester(China)，Wayne Chan,《第4代白盒测试方法介绍（理论篇）》

4. ezTester(China)，Wayne Chan,《第4代白盒测试方法介绍（VcTester实践篇）》

5. ezTester(China)，《VcTester共享版使用手册》

6. ezTester(China)，《使用VcTester构造持续集成及每日构建平台》

7. ezTester(China)，《VcTester持续集成框架的应用价值》