使用清单 6 中基于表格的格式，可以定义多个接受测试。也可以将测试分组成套，一次执行一整套测试。
使用 Ant 驱动 Selenium
        Selenium 的伟大之处在于它是在考虑了 CI 的基础上从头创建的，因为你能在像 Ant 那样的构建工具中运行 Selenium。此外，由于框架设计者的高瞻远瞩，如果任何 Selenium 接受测试失败，您也可以让整个构建失败。例如，清单 7 展示了一个 Ant 任务，该任务使用 Selenium 远程控制服务器在一个 Web 应用程序中执行一系列表格驱动测试：

清单 7. 使用 Ant 运行 Selenium
<?xml version="1.0" encoding="iso-8859-1"?>
<project name="functional-tests" default="run-selenium-tests" basedir=".">
  <property file="${basedir}/selenium.properties"/>
  <import file="${basedir}/common-environment.xml"/>
  <property name="acceptance.test.lib.dir"
                value="${functional.test.dir}" />
  <property name="firefox" value="*firefox" />
  <property name="base.url"
                value="http://${web.host.name}:${web.port}" />
  <property name="acceptance.test.list.dir"
                value="${functional.test.dir}" />
  <property name="acceptance.test.report.dir"
                value="${functional.test.dir}" />
  <target name="run-selenium-tests">
    <mkdir dir="${reports.dir}" />
    <java jar="${acceptance.test.lib.dir}/selenium-server.jar"
            fork="true">
      <arg line="-htmlSuite "${firefox}""/>
      <arg line=""${base.url}""/>
      <arg line=""${acceptance.test.list.dir}/${test.suite}""/>
      <arg line=""${reports.dir}/index.html""/>
      <arg line="-timeout ${timeout}"/>
    </java>
  </target>
  <target name="stop-server">
    <get taskname="selenium-shutdown"
       src="http://${web.host.name}:
      ${selenium.rc.port}/selenium-server/driver/?cmd=shutDown"
      dest="result.txt" ignoreerrors="true" />
     <echo taskname="selenium-shutdown"
              message="Errors during shutdown are expected" />
  </target>
</project>

        执行 Selenium 测试时，当框架打开 Web 浏览器、闪电般执行测试，然后关闭该浏览器并生成 HTML 报告时，不要被吓到。这是一种在开发生命周期的早期更快更容易地发现问题的方法（此时它们更易处理）。
使用 Cobertura 报告代码覆盖率
        现在已经编写了一些测试，如何确定所有这些测试执行什么 呢？幸运的是，此问题可由像 Cobertura 这样的代码覆盖工具来解答。代码覆盖工具可报告测试覆盖率 —— 以行覆盖或分支覆盖形式表示 —— 它表示测试运行时所涉及的代码量。
        清单 8 展示了一个 Ant 脚本。该脚本使用 Cobertura 生成一份关于代码覆盖率的 HTML 报告，代码覆盖率通过运行一系列 JUnit 测试获得：

清单 8. 使用 Ant 和 Cobertura 报告代码覆盖率
<target name="instrument-classes">
  <mkdir dir="${instrumented.dir}" />
  <delete file="cobertura.ser" />
  <cobertura-instrument todir="${instrumented.dir}">
    <ignore regex="org.apache.log4j.*" />
    <fileset dir="${classes.dir}">
      <include name="**/*.class" />
      <exclude name="**/*Test.class" />
    </fileset>
  </cobertura-instrument>
</target>

<target name="run-instrumented-tests" depends="instrument-classes">
  <mkdir dir="${logs.junit.dir}" />
  <junit fork="yes" haltonfailure="true" dir="${basedir}" printsummary="yes">
    <sysproperty key="net.sourceforge.cobertura.datafile" file="cobertura.ser" />
    <classpath location="${instrumented.dir}" />
    <classpath location="${classes.dir}" />
    <classpath refid="test.class.path" />
    <classpath refid="project.class.path"/>
    <formatter type="plain" usefile="true" />
    <formatter type="xml" usefile="true" />
    <batchtest fork="yes" todir="${logs.junit.dir}">
      <fileset dir="${test.component.dir}">
     <patternset refid="test.sources.pattern"/>
      </fileset>
    </batchtest>
  </junit>
</target>

        Cobertura 产生了一个如图 1 中所示的 HTML 报告。请注意行覆盖和分支覆盖的百分比是以包计算的。可单击每一个包，获得类级别的行百分比和路径百分比，甚至能看到执行的源代码行和它们执行的次数。

图 1. 使用 Cobertura 和 Ant 生成 HTML 报告

                 
        已经介绍了多种类型的测试，甚至介绍了如何测量这些测试的覆盖率 —— 但是如何确保以正常的间隔执行 这些测试呢？恰好，这正是 CI 服务器（如 CruiseControl）大显身手的地方，接下来对它进行介绍。
持续运行测试
        一旦将这些各式各样的开发人员测试类型合并到一个构建过程中时，可以将这些测试中的一些（或者全部）作为 CI 过程的一部分运行。例如，清单 9 是 CruiseControl 的 config.xml 文件的一个片段，我在其中定义了一些东西。首先，我让 CruiseControl 每两分钟监控一次 Subversion 库中的改变。如果发现任何改变，则 CruiseControl 将启动一个叫做 build-${project.name}.xml 的委托 构建脚本（通常，此脚本用 Ant 编写）。该委托构建脚本调用项目的构建脚本，后者执行编译并运行测试。
        我也定义了一些逻辑，将所有不同类型的测试结果合并到一个 CruiseControl 日志文件中。而且，我还利用 CruiseControl 的功能将不同工具生成的报告链接（使用 artifactspublisher 标签）到 Build Artifacts 链接中，Build Artifacts 可以从 CruiseControl 的显示板应用程序中获得。

清单 9. 使用 CruiseControl 的 CI
...
<modificationset quietperiod="30">
  <svn RepositoryLocation="http://your-domain.com/trunk/brewery"
    username="bfranklin"
    password="G0Fly@Kite"/>
</modificationset>
<schedule interval="120">
  <ant anthome="apache-ant-1.6.5" buildfile="build-${project.name}.xml"/>
</schedule>
<log dir="logs/${project.name}">
  <merge dir="projects/${project.name}/_reports/unit"/>
  <merge dir="projects/${project.name}/_reports/component"/>
  <merge dir="projects/${project.name}/_reports/performance"/>
  <merge dir="projects/${project.name}/_reports/functional"/>
  <merge dir="projects/${project.name}/_reports/coverage"/>
</log>
<publishers>
  <artifactspublisher
    dir="projects/${project.name}/_reports/"
    dest="projects/artifacts/${project.name}"/>
</publishers>
...

        在将每个源变更应用到版本控制库中时，不必运行每个定义的测试。例如，可以设置 CI 系统执行构建（通常称作提交构建），该构建只在代码签入时运行单元测试。可以为提交构建补充一些更重量级的构建，例如像运行组件测试、功能测试、性能测试以及甚至执行代码检查的构建（请参阅 参考资料）。这些构建可以以更低的频率运行（如一天一次）。您也可以选择在提交构建之后立即运行这些测试和检查。
调用所有测试
        持续测试包括了广度和频度。通过授权执行不同类型的测试，可获得更大范围的覆盖和信任。此外，通过持续运行这些测试，几乎能在问题产生就发现它们.仅仅进行单元测试（至少我所定义的单元测试），并不能使你在项目上走得很远。取得更高的代码覆盖率并且增加团队的信心，需要通力合作并执行自动化组件测试、性能测试和功能测试。此外，使用框架和像 JUnit、Selenium 以及 Cobertura 这样的工具能轻松实现构建自动化，这也意味着在 CI 系统的帮助下，能够在每次将变更提交到版本控制库中时，有效地执行测试套件。这肯定是一种万无一失的提高平均成功率的方法，您不这么认为吗？