对于开发活动来说，代码提交是一个很重要的事件，代码变更被提交到版本控制服务器后（成为一次revision），意味着该变更的影响范围从该开发人员自己推广到了更广阔的范围：

　　其他开发人员将可以通过update代码将该变更合并到自己的变更中去，影响到其他开发人员的修改；

　　测试人员将可以从版本控制服务器上通过构建并得到结果，对合并该变更后的产品进行测试；

　　其他的试用，需求验收人员都可以看到该变更的变化和影响，如果在开发环境中看，则太麻烦了，对于不懂技术的人来说门槛太高。

　　因为持续集成意味着“完成”即“以发布”，所以这次提交的变更很有可能会影响到最终使用这个产品的用户。

　　测试中有一个非常重要的经济学原则：产品问题或者BUG被发现的越早，其被修复的成本就越低。所以说，提交测试是一个非常重要和有价值的阶段，如果不能被充分利用起来那就太浪费了。更何况提交测试还可以为后续的其他测试需要的简单测试过的二进制的包，避免因为前置条件不满足而导致其他的测试，试用，验收活动无法展开。提交测试的特点是功能很基础，靠近开发过程容易被程序化（见下图），需要被频繁的执行，这些特点决定了提交测试必然是自动化程度很高的，在实践中一般要求接近全部自动化（除了冒烟测试可能有手动外）。

　　按照时间顺序，提交测试由一下一些部分组成： 开发环境构建>>CodeReview>>提交至SVN>>提交后构建（包括编译，单元测试，代码检查etc.）>>自动推送部署至Alpha测试场所（Alpha安装包，Update工具，Alpha FTP， Alpha应用） >> 每日冒烟测试 下面将按照提交测试的这些次序，介绍各项实践：一. CodeReview 持续集成一个很重要的内容就是需要很好的内建质量，软件工程中主要就是代码质量，提高代码质量的工具多种多样，比如可以利用构建中的代码检查工具，比如FindBugs， Similar Code etc.，来规范代码，发现不规范的代码，如果不通过工具检查，则最好构建失败。提高代码质量还有一种有效的方式就是代码审查，即CodeReview，通过开发者之间互相评审代码提高代码质量。因为可以看到变更集，具体到哪个开发人员提交了哪些代码，有些时候甚至可以让开发者对应的测试者也可以参与到CodeReview，这样有几个好处：

　　● 让测试熟悉所测产品的业务代码，提升代码的阅读能力

　　● 提早发现代码里面的bug，低成本保障质量，防患于未然

　　● 提前预知并评估并确认测试范围，减少测试工作量

　　● 促进开发、测试间的沟通、交流和协作

　　具体实践中的工具可以用ReviewBoard，在结合SVN的pre-commit hook，如果该次变更没有codereview过，则无法提交。 二. 自动构建   构建可以解决开发、测试、集成、验收等工作的混乱，同时本身也是一种最基本的测试。在没有采用构建之前，测试的组的工作状态是，每个人更新代码，然后编译在开发环境下面测试，有时候甚至跑不起来，不是开发人员忘记上传代码无法编译，就是测试人员编译过程有遗漏，而且每个人的测试版本都不一样，测试这边有问题，结果到开发那边又没有问题，不但麻烦，而且无法快速定位问题出在哪里。这种混乱导致大部分时间浪费在了沟通上，大量的郁闷。有一个形象的对话，可以见这里。 自动构建主要包括编译，单元测试，生成二进制包等等，分为提交前开发者构建，和提交后在持续集成服务器中的构建，这边主要指后者。 最先了解构建这个概念，是从《观止-微软创建NT和未来的夺命狂奔》一书获得的，里面的大卫.卡特勒对构建十分重视，甚至分配专门的构建员，或亲自做构建。

　　在构建这里介绍一个非常好用的持续集成工具：Hudson。有很好的定时任务管理，可以配置各种脚本Ant，BAT等等，还可以与很多其他的工具结合的非常好，有很多好用的插件，比如FishEye，SVN，邮件发送，FTP，FindBugs等等，是做自动化测试的利器。构建包括编译和单元测试，如果是Java应用，编译就可以用Ant，单元测试可以用JUnit，TDD方面有一本很好的书：《测试驱动开发》。