接口测试–Cruisecontrol和Clover配置详解
1 CruiseControl配置文件结构
CC主配置文件 config.xml 的根结点是<cruisecontrol>，该结点很简单，没有什么需要配置的属性。<cruisecontrol>下支持三种元素，如下：
| <cruisecontrol> <system/> <plugin/> <project/> </cruisecontrol> |
目前 CC 支持多个项目（multi project），因此可以有多个并行的<project>元素。在<project>元素下面都是跟CC插件有关的配置项，结构如下：
| <cruisecontrol> <project> <plugin/> <listeners/> <bootstrappers/> <modificationset/> <schedule/> <log/> <publishers/> </project> </cruisecontrol> |
2 CruiseControl配置详解
2.1 <system>
| <system> <configuration> <threads count=”2″ /> </configuration> </system> |
通过<system>结点可以配置同一时刻构建项目的最大线程数。如上的配置指定了同一时刻最多能构建2个项目。
2.2 <project>
<project>是一个工作的基本单位，在同个config.xml文件中必须是唯一标示一个项目的。config.xml可以包含多个不 同的<project>，这些项目都在一个队列中运行。在队列中能同时构建多少个项目取决于<system>中线程数的配置。
<project>的主要属性和对应说明如下：
| 属性名 | 是否必须 | 说明 |
| Name | 是 | 唯一标示一个项目 |
| buildafterfailed | 否 | 是否在构建出错时继续构建 |
如：<project buildafterfailed=”true”>
2.3 <listeners>
<listeners>提供给监听插件实例的容器，里面可以具体配 置<currentbuildstatusftplistener>、<currentbuildstatuslistener>、<currentbuildstatuspagelistener>、<cmsynergysessionmonitor>、<lockfilelistener> 等监听插件。比较常用的如<currentbuildstatuspagelistener>，该插件会将本次构建的状态描述写到指定的文件 中。如：
| <listeners> <currentbuildstatuslistener file=”logs/myTest/status.txt” /> </listeners> |
2.4 <bootstrappers>
< bootstrappers>在构建之前运行，CC 提供的 bootstrapper 包括了两个种类：一种用于向其他插件提供项目当前构建的状态，还有一种是从某个源码控制系统更新本地文件。<bootstrappers>下 面的元素比较多，这里分别例举几种常用的元素：
<currentbuildstatusbootstrapper>指定了状态文件的位置，主要是用来访问项目当前构建的状态，CC 的<publishers> 结点下的<currentbuildstatuspublisher>会将构建的状态写入这个文件，CC 的 web 用户接口要向用户提供最近一次构建的信息， 其web组件会访问该文件来获得当前项目进行构建的状态。
<cvsbootstrapper>、<svnbootstrapper>分别针对的是CVS和SVN源码控制系统。因为我们每 次项目的构建都应该基于最新的代码，因此在构建之前就要获得最新的项目文件。如果项目是通过Ant构建，这个工作是由Ant的buildfile来完成 的，如果这个buildfile本身在构建开始之前发生了变化，就应该先更新这个buildfile，然后才通过buildfile来对项目进行构建。同 样，如果项目是基于Maven构建，这个时候也需要更新pom文件。如在Ant构建的项目中：
| <bootstrappers> <antbootstrapper anthome=”~/apache-ant-1.7.0″ buildfile=”projects/${project.name}/build.xml” /> </bootstrappers> |
在Maven构建的项目中，可以指定项目的路径：
| <bootstrappers> <svnbootstrapper localWorkingCopy=”myTest/myTest” /> </bootstrappers> |
2.5 <modificationset>
<modificationset>包括了 SourceControl 插件的配置信息，用于检查各个源码控制系统中是否发生变化，<schedule>会用到这里面的配置信息，如果检测到变化，会触发构建过 程。<modificationset>的属性 quiet period（ 单位为秒）定 义了一个时间值。如 果 CC 检查到了变化，会自检查到变化的源码控制系统的最后一次 check in 的时间开始等待，等待的时间由quiet period 决定，等待结束之后才触发构建（build）过程，主要是防止在 check in 的过程当中就触发构建过程（可能 check in 只做了一半，这个时候触发构建显然是不正确的）。
CVS的配置示例：
| <modificationset quietperiod=”30″> <cvs cvsroot=”:pserver:anonymous@localhost:2401/sandbox” localworkingcopy=”myTest”/> </modificationset> |
SVN的配置示例：
| <modificationset quietperiod=”100″> <svn localWorkingCopy=”myTest/ myTest ” /> </modificationset> |
2.6 <schedule>
<schedule >指定了构建的时间间隔，新的版本已经支持定义某个具体时间触发构建。<schedule>定时驱 动<modificationset>，如果检测到变化，就执行所指定的goal。目前 CC 支持的 builder 插件包括了 Apache 的 Ant 和 Maven，下面都是以Maven为例。当 CC 启动指定的Maven时，Maven作为独立的进程被调用，因此需要具体指定mvnhome、项目pom.xml文件和build的目标goal。如：
| <schedule interval=”3600″> <maven2 mvnhome=”~/tools/apache-maven-2.0.8″ pomfile=”myTest/myTest/pom.xml” goal=”-U clean package” /> </schedule> |
这个构建目标里包含了一组Maven的goal：
-U：强制从远程仓库更新snapshots和releases
clean：清除生成的class文件
package：打包，按照Maven的lifecycle，会依次执行validate、compile、test、package等生命周期。
2.7 <log>
<log >指定项目日志保存的地点，主要是合并项目构建过程 junit 测试结果的报表文件(xml)。<log>的用法很简单，通常是指定 CC 的合并日志的目录就可以了，对于比较复杂的、多模块的项目是非常有用的。例如：
| <log> <merge dir=”myTest/myTest/app-client/target/surefire-reports” /> <merge dir=”myTest/myTest/app-server/target/surefire-reports” /> </log> |
2.8 <publishers>
在 build loop 结束之后将运行 Publishers，无论 build 是成功还是失败，都会运行 publisher，发布 build 的结果。
<publishers> 下面最常用的 publisher 插件是<currentbuildstatuspublisher> ， <email> 和<artifactspublisher>。
<currentbuildstatuspublisher>的主要作用是用来显示build loop 的结果，包 括了编译信息，JUnit测试结果信息，以及变更的信息。该插件和<currentstatusbootstrapper>插件访问的文件是 同一个文件。
而<email>主要是用来通知使用者。最常用的用法是根据不同的结果发送到不同的邮件列表，如每次 build，无论成功失败都发送给某个邮件列表，还是成功(<onsuccess>)、失败(<onfailure>)的时候才 分别发送的邮件列表。
<artifactspublisher>用于对构建过程中产生的人工制品进行发布，如发布Clover插件生成的报表。至于如何在CC中集成Clover插件将在下面谈到，这里不做赘述。
在淘宝，结合开发的阿里旺旺消息通知插件很容易将构建通知消息发送给指定的负责人，让各负责人第一时间知道此次构建的信息。旺旺消息通知插件在build 失败时、build结果和上次不一致时（上次build failed、此次success或者上次success、此次failed）才发消息给指定的人员，一直build success将不会发通知消息，避免消息的冗余，因为更多时候我们只关注build failed的通知。如：
| <publishers> <wangwangCCPlugin> <only nickname=”your wangwang name” /> <only nickname=”other wangwang name” /> </wangwangCCPlugin> </publishers> |
3 Clover和测试覆盖率
测试覆盖率，简单的说，就是评价测试活动覆盖产品代码的指标。测试的目的，是确认产品代码按照预期一样工作，也可以看作是产品代码工作方式的说明文档。进 一步考虑，测试覆盖率可以看作是产品代码质量的间接指标－－之所以说是间接指标，因为测试覆盖率评价的是测试代码的质量，并不是产品代码的质量。
衡量测试覆盖率的指标很多，常用的指标有：
1，Statement coverage，也称作Line coverage，用于评价测试的代码语句覆盖率。
2，Basic block coverage， 是Statement coverage的一个变种，它把没有一个分支的代码区域作为一个计量单位，而不是简单的代码行，用于一个if-else分支代码行数远远大于另一个的情 况，在这种情况下，statement coverage指标并不适用。
3，Decision coverage（也称作Branch coverage），用于评价代码分支地测试覆盖率。
4，Path coverage，和Decision coverage相似，用于评价代码从开始到结束所有路径的测试覆盖率。
5，Function coverage，用于评价代码方法的测试覆盖率。
Clover是Atlassian组织的一款优秀统计测试覆盖率插件，可以免费用于非商业途径，基本支持以上列举的几种覆盖类型。Clover是支持 Maven2插件规范，可以为Maven2构建的项目生成报告。结合Maven2，Clover有如下常用命令。
3.1 clover2:instrument
此命令将构建Clover数据库并在产品代码中的关键位置插入统计代码。当执行这个命令时，将会构建一个存放Clover相关数据的数据库，并将统计代码 和源代码一起编译进行埋点；如果这个数据库已经存在，这个命令会向存在的数据库中插入最新的统计数据。当执行测试方法时，埋点代码将会生成日志信息存放到 数据库中。这些日志信息可用于检查代码覆盖率、生成报表和日志统计。
3.2 clover2:clover
此命令将根据clover database日志信息生成覆盖统计报表。
3.3 clover2:aggregate
此命令主要用于多模块项目的统计而设。使用此命令会将各子模块的clover database中的日志信息合并到一个数据库中，在运行clover2:clover时会从合并后的数据库中读取数据生成一个合并后的报告。
关于Cruisecontrol与Clover的实践将在稍后连载，敬请关注！
转载务必注明出处Taobao QA Team