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

为什么要持续集成？

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

1、 能最小化集成风险

        项目组可能遇到的一个很大的风险是，项目组成员根据不同的系统功能各自开发不同的代码，但是当这些代码集成为一个系统的时候，也许系统完成不了预期的功能。这种风险的发生取决于项目中的这种不兼容性多久才被发现，由于程序界面已经发生了变化，或者系统的主要部分已经被重新设计和重新实现了，相应的排错工作将非常困难和耗时。极端情况下，集成的错误可能回导致项目被取消掉。每日构造和冒烟测试可以使这种集成错误变得非常小，而且便于解决，防止了很多集成问题的产生。
2、 能减小产品低质量的风险

        这种风险是和集成不成功、集成出错相关联的。每天对集成的代码做一些少量的冒烟测试，即可杜绝项目中那些基本的质量问题。通过这种方式，使系统达到一种周知的良好状态，维护这样的系统可以防止系统逐步恶化到耗费大量时间排查质量问题的地步。
3、 能简单化错误诊断

        当系统每天都进行build和测试时，系统任何一天发生的错误都能够变得十分精细，便于排查。比如在17日系统还运行正常，18日就出错了，那么只需要检查这两次build之间的代码变化就可以了。
4、 能极大鼓舞项目组的士气

        看到产品的不断成长，能够极大的鼓舞项目组的士气，有时甚至不管这个产品到底用来做什么。开发人员可能会为系统显示了一个矩形而感到激动。通过每日构造，产品每天进步一点点，保证项目士气的持续高涨。
        大家可能认为每日构建是一件很难的事，其实不然，只要方法得当、流程措施有力，每日构建还是容易做起来的。想象一下，Windows NT是无比复杂的系统，包括了560万行代码，共有4万个源文件，微软仍能坚持每日构建。对于我们只有十数万行规模的产品，做一做每日构建又能有多难呢？！

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

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

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

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

测试脚本该由谁来维护

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

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

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

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

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

日常调试与规范测试

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