三、持续集成及其自动化编译
"持续集成（Continuous Integration）"的概念来自于XP（极限编程）的一个实践, 我们的开发模式是建立在CMM的基础之上,引入了某些XP的概念，所以我们的思想是取各方面的精华来适合自己。
持续集成是指能够自动的集成已经提交(Check-in)的代码，直至发布到测试服务器供测试的整个过程。
1、实现自动化日构建需要做以下几部分的工作：
2、将所有的源代码保存在单一的开发服务器，让所有人都能从这里获取最新的源代码（需要用配置管理工具存放源代码: 如VSS/CVS/ClearCase）。
3、使创建过程完全自动化，让任何人都可以只输入一条命令就完成系统的创建。
4、使测试完全自动化，让任何人都可以只输入一条命令就运行一套完整的系统测试。
5、确保所有人都可以得到最新、最好的可执行文件。
6、自动化编译： 为了能够提供自动化测试，所以所有的代码必须能够实现自动化编译。其实很多在做持续集成的公司都实现了改功能：如java程序可以采用在Ant + Junit 的基础之上添加自己的功能既可以实现持续集成―――我们把这个工具叫：日构建
但很多公司并没有实现对JSP的自动编译，对于采用jsp编写的web页面，它是编译执行语言，由于第一次执行要先编译，即第一次的速度稍慢，如果要采用自动化测试工具winrunner进行功能测试时，则会失败。因为自动化测试工具最基本的要求是：进入条件和出口条件必须在录制与回放时完全相同。 2、持续集成最的好处：
完全可以取代人工的发布， 在J2EE中有个角色叫deployer., 它的主要工作就是经常发布新的系统供开发、测试，一般每发布一次至少要一个小时，如遇到一些问题一个上午就耗费掉了， 但使用“日构建”后就可以完全实现自动化，时间几乎只等于编译时间。
它完全避免了开发者们的"除虫会议"--以前开发者们经常需要开这样的会，因为某个人在工作的时候踩进了别人的领域、影响了别人的代码，而被影响的人还不知道发生了什么，于是bug就出现了。
这样的bug绝大多数都可以在引入的同一天就被发现。由于一天之中发生变动的部分并不多，所以可以很快找到出错的位置。
持续集成可以把发现的错误根据源代码的作者，以邮件和日志的方式分发给作者，第二天一上班的第一件事就是先修改错误。
持续集成可以减少集成阶段"捉虫"消耗的时间、 频繁发布新版本的时间，从而最终提高生产力和软件质量。
3、理想的持续集成的实现方法：
A)、同一个软件产品要有集中的同一台开发服务器，即所有人的最新的、各自编译通过的源代码都在配置管理工具如VSS中。
B）、有一台运行主创建的机器，有计划的运行日构建, 日构建中有一个创建进程，该创建进程是在一个随时保持运行的Java类中进行的，如果没有创建任务，创建进程就一直循环等待。
C）、守护进程将全部代码（包括原程序和配置文件，数据库脚本等）提取到创建机器的一个目录中。提取完成之后，守护进程就会在这个目录里调用Ant脚本。
D）、Ant会接管整个创建过程，对所有源代码做一次完整的创建。Ant脚本会负责整个编译过程，并把得到的class文件放进六个jar包里，发布到EJB服务器上。
创建结束之后，创建守护进程会给所有向最新一次创建归还了代码的开发者发一个e-mail，汇报创建的情况。
E）、当Ant完成了编译和发布的工作之后，创建守护进程就会在EJB服务器上开始运行新的jar，同时开始运行BVT测试套件：即利用Junit进行单元测试。
单元测试完成后，日构建会把单元测试报告发给有错误的开发人员。
F)、为了利用自动化工具（WINRUNNER）进行功能测试，必须对JSP编译，利用jspc命令进行包装一层，就可以自动的对所有的jsp文件进行编译， 但由于编译jsp的时间非常长（越比编译java代码时间长），所以一般利用单独的编译服务器进行编译。 发布编译好的jsp文件进行自动化测试的成功率高（因为第一次运行jsp文件非常慢，而自动化测试最忌讳运行时和录制时等待得时间不一样）。 而功能性自动化测试也需要按计划有顺序的执行，这需要TestDirector测试管理系统来调度Winrunner进行测试。
让所有的重复的繁琐的事情都完全自动化，并且要经常进行集成，让重复的测试自动化。
文章来源于领测软件测试网 https://www.ltesting.net/
