随着自动化测试在软件行业的不断深化以及持续集成的兴起，几乎所有的软件都在不同程度上采用了自动化测试的方法，并且越来越多的软件公司在软件开发上引入了持续集成的方法，然而，随着软件迭代的次数的不断增多，软件质 量要求的不断提高，传统的自动化测试已经不能满足项目开发过程中对自动化测试效率的要求，所以中培伟业就该问题探讨了一种解决方案，即将持续集成引入自动化测试。中培期望通过这样的结合，能够很好地提高现今软件行业中的测试效率。
一、什么是持续集成（Continuous Integration）？
　　这个概念到底是怎么定义，说实话很多不同的版本。这里我就把我理解的什么叫持续集成说下，其实持续集成是为了配合敏捷开发的速度和效率而产生的一个用于编译、测试、发布、部署的工具。为什么叫持续呢？其实就是编码人员提交了源码，那么该工具就可以进行编译，测试等一系列运作。怎么能够让编码人员很快的知道编码的异常。
二、工具的选择 ：Maven2、 Hudson（CruiseControl可以考虑）、SVN
　　首先我们来看看这个环境是怎么运作的吧！ 编码人员将代码提交到SVN，那么Hudson就监控到SVN有更新，那么Hudson就去SVN取出更新的源码。取出后就交给Maven去编译、测试、发布等操作。
　　所谓的持续集成通俗一点儿说：就是指对于开发人员的每一次代码提交，都自动地把Repository中所有代码Check out到一个空目录，并且自动运行所有Test Case。如果成功则接受这次提交，否则告诉所有人，这是一个失败的Revision。
　　更具体的解释可以参考Martin fowler的Continuous Integration  。
二、持续集成的价值与成本
　　有句时髦的话，叫做“存在即为合理”。既然持续集成已经存在了这么长的时间，而且没有消失的迹象，那就是有价值的东西。
那么它的价值何在？有人概括如下：
　　(1) 减小风险；(2) 减少手动过程；(3) 生成构建结果；(4) 安全感。
　　而持续集成的成本在于对持续集成代码的维护成本和集成的时间成本。因为随着项目进行，软硬件环境会越来越复杂，成品代码也会不断膨胀。此时，需要团队而修改或增加原有的测试代码，以适应这些变化，同时，每次集成所需时间也会变长，这就是持续集成的成本。
　　某个blog中提道：“这种集成是如此的频繁，多少次的代码Commit就有多少次持续集成。前提是集成的成本很低，或者说是完全自动化的。”
三、持续集成应该自动化什么呢？
　　我们要以尽可能少的成本来获得尽可能多的价值。这就要考虑哪些自动化是必要的啦。
　　Jez Humble提到至少有六点要做到自动化，
　　它们分别是(1)自动化的运行测试；
　　(2) 自动产生可部署的二进制成品；
       (3) 自动将成品自动部署到近似生产环境；
       (4) 自动为CodeBase打上标签；
       (5) 自动运行回归测试；
       (6)自动生成度量报告。
四、持续集成服务器的选择
　　在进行持续集成实践前，应当正确的选择并配置持续集成服务器。比较成熟的持续集成服务器包括：CruiseControl, Anthill, Bamboo, TeamCity, Continuum 等。CruiseControl作为开源产品，以其对于各种SCM（源码管理，制造业上是供应链关系管理）以及构建工具的广泛支持而被许多开发团队所接受。而开发自动化专家 Duvall 采用一致的评估标准和很多说明性示例，介绍了一些开源 CI 服务器，包括 Continuum、CruiseControl 和 Luntbuild。并指出“要根据 自己的 具体技术和政策需求对工具进行分析”。并用以下五个指标来评估CI工具，它们分别是：(1)  特性；(2)  可靠性；(3)  寿命；(4) 目标环境；(5) 易用性。结果如下表：
五、只有持续集成服务器是远远不够的
　　正如Jez Humble所说，CruiseControl和其它的CI工具本质上只不过是一个定时器，时间一到，做你让它做的事情。所以，必然要有其它工具与其结合，方显持续集成的本色。这些工具又是什么呢？
　　想测试的话，你就要用一些测试工具，如JUnit，JWebUnit，Selenium等等；
　　想检查代码标准的话，你就要用checkstyle等代码规范检查工具；
　　想要了解测试覆盖率的话，你可能就要用到JCoverage。
　　当然，想得到二进制文件，就要用到Ant，Make之类的工具啦。
六、最重要的事：实践与反思
　　也许这些东西大家都知道，而且有些人可能已经实践过啦。无论这些实践的结果是怎样的，一定不要忘记总结和反思。如果这些实践成功了，不要把它归功于这个工具，而是要总结一下为什么会成功，如果你愿意的话，还可以和大家分享一下。如果这些实践失败了，也不要把它归功于这个工具，而是要反思一下，是否正确地使用了这个工具，团队成员是否都喜欢这个工具，为什么？