使用 STAF/STAX 实现测试自动化和持续集成-集成与构建-火龙果软件工程

分享到

使用 STAF/STAX 实现测试自动化和持续集成

作者 Fabio Negrello，火龙果软件发布于 2013-11-21

使用 STAF/STAX 框架缩短开发时间并提高软件质量

回归和增量测试在可能由成百上千需求组成的应用程序测试过程中起着重要作用。增量测试有时可以手动执行，而回归测试需要自动化工具或框架。对多个操作系统、架构和中间件软件的支持，比如应用程序服务器和数据库，使得对自动化框架的需求变得更加紧迫。本文简要地介绍 STAF/STAX 测试自动化框架，并且展示如何使用它来构建一个框架，在复杂试验台中实现测试自动化和持续集成。

关于回归和增量测试

回归测试往往用于确保软件变更不会在软件中引入新的问题或故障。另外，还可以用它来确保您不会重新引入之前修复的错误。如果软件对第三方组件和库有诸多依赖项，比如 XML 处理 API 或 JPA 等数据库提取 API，那么新问题的引入会非常常见。在这些情况下，数据库架构的一个小小的改动就可能会导致难以预测的应用程序行为变更。如果软件本身很复杂，对常见代码段的一个小小的更改都会招致不可预测的副作用。

当需要对某个中间件软件的先前版本或不同平台提供持续支持时，这提高了在维护或开发期间引入问题的概率。在某个数据库中间件版本中有效的补丁或功能可能在不同的版本中带来灾难性的后果。而且在添加功能时，只有中间件的较新版本可用的 API 可能会给使用先前版本的客户端带来损害。在支持不同平台时，要对依赖于命令行接口或脚本的功能进行完全测试。否则不同的行为可能会在 Windows? 和 Linux? 等不同的操作系统中出现。

回归测试针对整体软件，并考虑该软件与其他组件或应用程序的相互依赖性。在开发期间，要专注于正在开发的特定模块或功能。您可以在实现模块或功能时递增式地测试它们，而且有时需要使用存根引用其他尚未实现的功能。如果增量测试结构化良好并且足够独立，以至于您可以在给定环境中（比如必要中间件软件、机器或配置）重复它们，那么您可以在未来的回归测试中重用它们。这一结构及其独立性减少了返工，并改进了测试质量，因为每一段代码在开发时都经过详细审查测试。

当您在一组架构、操作系统和中间件版本上测试开发中的功能时，可以考虑使用自动化增量测试。以针对 Linux、AIX?、Windows 7 和 Windows XP 支持的一个命令行接口为例。在开发期间，在这些操作系统中每个操作系统上执行测试可能都需要花费不少资源和时间。在某些情况下，测试新功能所需的时间超过开发它所需的时间。考虑到许多功能是由不同开发人员在一个项目中同时开发的，这一情况变得更加麻烦。让这一格局变得更加复杂的是，用于测试的机器数量通常是有限的，即使使用的是虚拟机。测试通常需要一个预配置环境，包括数据库服务器、应用程序服务器，等等。专用于测试的机器越多，更新和配置它们所需的时间就越多。由于自动化增量测试由一个工具在一组环境或试验台中运行，您可以节省在每个环境中手动运行测试所需的时间，从而更好地共享资源。

自动化回归测试可以使用与增量测试一样的试验台。例如，将回归测试设置为一天运行一次之后，无需消耗通常可能用于开发和增量测试的资源。您可以设置冗长的回归测试，让它按照更长的间隔运行，比如在周末运行。

STAF/STAX Framework

软件测试自动化框架 (STAF) 是一个开源框架，包含专门适用于构建自动化解决方案的一组内置服务。这些服务是可重用的组件，提供了 STAF 中的所有功能。每个 STAF 服务提供一组特定功能，比如：

1.日志记录

2.文件系统操作

3.安全性和进程调用

4.一组请求的定义

其他服务，比如电子邮件服务、FTP 服务和计时器服务，都不是内置的，但可轻松插入框架中。

STAX 服务是一个在 Java? 环境中实现的特殊服务，或支持通过 XML 调用其他 STAF 服务的执行引擎。它还提供了以下支持：

1.并行执行

2.执行控制的用户定义的粒度

3.对嵌套测试用例的支持

4.控制执行时长的能力

5.在运行时导入模块的能力

6.对现有 Python 和 Java 模块和包的支持

STAX 定义的 XML 元素能够像编程语言一样运作，包含语言的所有必要元素：

1.循环

2.条件

3.错误处理

4.函数调用

可以使用元素脚本嵌入 Python 脚本，从而支持更复杂的逻辑和对于定义 Python 模块的访问。

Python 代码由 Jython 运行。Jython 选择使用 Python 编程语言语法，让其在 Java 平台上运行。这样可以实现与 Java 库和其他 Java 应用程序的集成，从而提高 Java 开发人员团队的工作效率。

STAX 的一个有趣特性是，它允许导入包含辅助功能的现有 STAX 文件。该特性改进了自动化代码的组织和代码的重用。

STAF 作为一个守护进程运行，监听来自预配置端口的请求。STAF 服务通过这些请求加以访问，这些请求是所需命令的指令。 Stafcmd 是 STAX 定义的元素，可用于表示一个请求。如清单 1 所示，一个请求包含：

1.命令运行的位置

2.运行它的服务

3.实际命令

清单 1. 清单 1 一个请求的示例

<stafcmd>
    <location>'lab01.mydomain.com'</location>
    <service>'FS'</service>
    <request>'CREATE DIRECTORY /tmp/CVT_TEMP' </request>
</stafcmd>

清单 1 中的代码请求在机器 lab01.mydomain.com 上创建目录 /tmp/CVT_TEMP。定义该命令的服务是 ‘FS’（文件系统服务）。如果命令运行位置不是 ‘local’，请求命令的 STAF 实例发送请求到指定位置。这一通信对于调用方来说不明显。一个在本地机器中创建目录的请求拥有相同的语法。惟一的区别在于，由您指定位置 ‘local’，然后 STAF 了解到必须在本地（而非其他机器中）运行命令。

使用 STAF/STAX 实现测试自动化

1.自动化测试执行所需的步骤取决于您测试的软件。大多数自动化解决方案的主要步骤是：

准备测试用例环境

创建远程目录

将所需映像和必备项复制到远程环境

将映像和必备项放置或解压到正确的位置

启动数据库或应用程序服务器

创建数据库

安装应用程序

2.运行测试用例

3.收集信息（结果、覆盖率信息和日志）

4.释放资源

删除临时文件夹

删除数据库

5.使用结果构建报告（JUnit、Coverage 或 HTML 报告）

6.将结果存储在本地或远程服务器（使用 FTP、共享文件夹或其他工具）

7.发送通知（电子邮件）

您可以使用 STAF/STAX 执行所有这些步骤，如以下示例所示。

准备测试用例环境

组织试验台的一种方式是为每个环境创建一个属性文件，您需要在该文件中为测试用例置入有用的所有属性，比如：

1.数据库端口

2.服务器端口

3.软件安装目录

4.测试用例需要的任何其他属性

每个属性文件代表特定机器上的一个测试环境。一台机器可以有多个环境。例如，一个环境可能定义 DB2 数据库和 WebSphere v8.5 服务器。同一台机器上的另一个环境包含 Oracle 数据库和 WebSphere v7.0 服务器的属性。每个属性文件代表特定机器上的一个测试环境。

在准备阶段，开发人员必须迭代环境集，并启动一组命令来准备在远程机器中执行测试，在该机器中定义了所有环境。

清单 2清单 2 显示对环境的一个基本循环：

清单 2. 清单 2 环境的基本循环

<script>
    env_list = ['LinuxDB2Websphere8','WindowsDB2Webshere85']
</script>
<paralleliterate var="env_name" in="env_list">
    <sequence>
        <message log="STAXMessageLog">
           'Preparing to launch tests on %s' % env_name
        </message>
        <tcstatus result="'info'">
           'Reading environment information from %s' % env_name
        </tcstatus>
        <script>
           file_path = "%s/CVT/config/%s.properties" % (temp_dir, env_name)
        </script>
        <call function="'read_properties'">
            {'properties_file' : file_path}
        </call>
        <script>
            props_dict = STAXResult
            try:
               mach_name = props_dict.get('STAF_MACHINE')
            except:
               raise Exception('Property STAF_MACHINE not found in Env %s' % env_name)
        </script>

… prepare remote environment for tests

</sequence>
</paralleliterate>

创建远程目录

测试执行准备涉及到创建一个或多个目录，在其中放入 STAX 脚本以及必要的库和产品映像。一个建议采用的结构是：

<TEMP_DIR>/CVT_TEMP/PRODUCT → 放置库和所需映像的目录。

TEMP_DIR>/CVT_TEMP/CVT → 辅助 STAX 脚本和测试所需的其他资源。

要获取系统临时目录的位置，必须解析具有该值的一个 STAF 变量，如清单 3 所示。

清单 3. STAF 变量解析

<stafcmd>
    <location>mach_name</location>
    <service>'VAR'</service>
    <request>'RESOLVE STRING {STAF/Env/TEMP}'</request>
</stafcmd>
<script>
    temp_dir = STAFResult
    product_dir = 'CVT_TEMP/PRODUCT/%s' % temp_dir
</script>

目录是使用文件系统服务 (FS) 创建的，如清单 4 所示。

清单 4. 创建目录

<stafcmd>
    <location>mach_name</location>
    <service>'FS'</service>
    <request>'CREATE DIRECTORY %s FULLPATH' % (product_dir)</request>
</stafcmd>

复制必要映像和必备项到远程环境

在准备远程环境时，复制压缩的映像和必备项，然后将它们提取到目标目录。要复制一个文件，可以使用清单 5 中的 COPY 请求：

清单 5. 复制压缩的映像和必备项

<stafcmd>
     <location>'LOCAL'</location>
     <service>'FS'</service>
     <request>'COPY FILE %s/%s TODIRECTORY %s TOMACHINE %s' % \
         (local_directory, zip_file, remote_temp_dir, mach_name)</request>
</stafcmd>

将映像和必备项放入或解压缩到适当位置

要解压缩映像，可以使用清单 6 中的 ZIP 服务：

清单 6. 解压缩一个映像

<stafcmd name="'Unzip %s on %s' % (zip_file, mach_name)">
    <location>mach_name</location>
    <service>'ZIP'</service>
    <request>'UNZIP ZIPFILE %s/%s TODIRECTORY %s REPLACE' % \
        (source_directory, zip_file, target_directory)</request>
</stafcmd>

启动数据库或应用程序服务器

进程元素代表在指定机器上运行的 STAF 进程。可以使用它来启动脚本或可执行代码，并等待其完成。其中您可以指定以下选项：

1.命令本身

2.其参数

3.工作目录

4.进程使用的环境变量

参见清单 7。

清单 7. 进程元素

<script>
    ...
    cmd = 'C:/PROGRA~1/IBM/WebSphere85/profiles/Dmgr01/bin/startManager.bat'
    parms = '-username %s -password %s' % (user, passwd)
</script>
<process name="'cmd %s %s' % (cmd, parms)">
    <location>mach_name</location>
    <command mode="'shell'">cmd</command>
    <parms>parms</parms>
    <workdir>work_dir</workdir>
    <envs>envs</envs>
    <console use="console" />
    <stdout>stdoutFile</stdout>
    <stderr>stderrFile</stderr>
    <returnstdout />  
    <returnstderr />  
</process>

进程元素提供运行脚本和可执行代码的基本工具。当您在测试执行期间运行许多不同的脚本时，建议创建一个辅助 STAX 函数来包装调用，记录运行的命令及其参数，并检查退出代码。

创建数据库

process 元素还可用于启动创建数据库的脚本。清单 8 中的代码用于创建一个 DB2 数据库：

清单 8. 创建 DB2 数据库

<script>
    script_name = 'db2Setup.bat'
    db_script_dir = 'C:/CVT_TEMP/PRODUCT/bin'
    cmd_str = 'db2cmd -w -i -c %s %s -d %s -u %s -p %s' % \
        (script_name, migrate, db_name, db_user, db_pswd)
</script>
<process name="'cmd %s %s' % (cmd, parms)">
    <location>mach_name</location>
    <command mode="mode">cmd</command>
    <workdir>db_script_dir</workdir>
    <console use="console" />
    <returnstdout />  
    <returnstderr />  
</process>

安装应用程序

安装过程通常涉及到在非交互模式下调用脚本或可执行代码。该过程类似于调用设置数据库的脚本的过程，如清单 8 所示。

运行测试用例

尽管 STAF/STAX 有助于设置测试环境，但测试代码（STAX 和 python 脚本）变得很复杂，或者在测试不同形式的同一场景时会出现重复。这一复杂性使得维护变得很困难，尤其当并非所有测试人员和开发人员都有深厚的编程技能时。尽管 STAF/STAX 提供可靠的基础框架，您可能会重用以前使用其他语言编写的测试，并整合报告工具，无需测试人员扫描有时并不直观的 STAX 日志。对于 Java 语言，JUnit 是最常用的测试框架。JUnit 可与大部分开发软件相集成，支持使用提高测试代码编写效率的相关框架。例如，您可以使用 DDTUnit 将测试逻辑与测试数据分离开来。ANT 生成的 JUnit 报告也可用于组织报告，以及查找测试用例中的故障。

通过 STAX 脚本调用 JUnit

尽管您可以将 JUnit 作为一个简单的 Java 类直接启动，使用 ANT 更易于调用它。JUnit ANT 任务封装了 JUnit 调用，设置类路径，并使用 XML 文件格式记录测试的执行。然后该 XML 文件可被名为 junitreport 的另一个任务用于生成 HTML 格式的报告。

样例文件 JUnitUtil.xml 中定义的 run_junit_ant 函数可用于为一组测试用例或套件调用 JUnit。它创建了一个临时的 ANT 项目，其中包含一个类路径 junit.tmp.classpath，该类路径中包含在参数 lib_dirs 和 libs 中指定的 JAR 文件。在此之后，它会启动在样例文件 JUnitRunner.xml 中定义的目标 junit.run，引用类路径。（要获取 JUnitRunner.xml 和 JUnitUtil.xml 样例文件，请参见下载）。目标启动任务 junit，如清单 9 所示：

清单 9. 启动任务 JUnit

<project name="cvt.junit.runner" default="junit.run" basedir=".">
  <import file="${junit.tmp.classpath.import}" />
  <target name="junit.run" description="Runs the unit test cases.">
    <echo message="Generating JUnit output at ${output.dir}"/>    
    <junit dir="${work.dir}" fork="yes" forkmode="once" printsummary="on" 
           haltonfailure="no" haltonerror="no" showoutput="true" 
           failureproperty="ut.failed">            
      <jvmarg value="-Djava.util.logging.config.file=${java.util.logging.config.file}"/>
      <sysproperty key="net.sourceforge.cobertura.datafile"
        file="{net.sourceforge.cobertura.datafile}" />
      <classpath refid="junit.tmp.classpath" />            
      <test name="${cvt.test.class}" haltonfailure="no" 
        outfile="TEST-${cvt.test.class}" todir="${output.dir}">
        <formatter type="xml"/>
      </test>
    </junit>       
    <fail if="ut.failed" 
          message="Some of the tests failed. Check the JUnit report for details." />
  </target>
</project>

net.sourceforge.cobertura.datafile 属性可用于生成测试覆盖率信息（参见 Cobertura 项目，了解有关的更多信息）。您可以在 run_junit_ant 函数的 jvm_args 参数中提供该属性值。

收集信息（结果、覆盖率信息和日志）

传递压缩文件比逐一传输单个文件更加高效。要在远程机器上压缩一个目录，可以使用 ZIP 请求。在清单 10 中，目录 'C:/CVT_TEMP/CVT/logs' 在机器 mach_name 中被压缩为 ZIP 文件 'C:/CVT_TEMP/testcase_123_results.zip'。

清单 10. 使用 ZIP 请求在远程机器中压缩目录

<script>
   zip_file = 'C:/CVT_TEMP/testcase_123_results.zip'
   results_dir = 'C:/CVT_TEMP/CVT/logs'
</script>
<stafcmd name="'Compressing results'">
   <location>mach_name</location>
   <service>'ZIP'</service>
   <request>'ADD ZIPFILE %s DIRECTORY %s RECURSE RELATIVETO %s' % \
       (zip_file, results_dir, results_dir)</request>
</stafcmd>

压缩之后，您可以使用清单 11 中的 COPY FILE 请求获取结果。

清单 11. 使用 COPY FILE 请求

<script>
    local_results_dir = 'C:/CVT_TEMP/results'
</script>
<stafcmd>
    <location>mach_name</location>
    <service>'FS'</service>
    <request>'COPY FILE %s TODIRECTORY %s' % (zip_file, local_results_dir)</request>
</stafcmd>

在分散于不同网络的机器上执行测试时，可能会出现防火墙问题。一种较安全的方法是使用 GET BINARY 请求获取调用返回的整个二进制文件。这样做的优势在于，无需远程机器解析和访问本地机器。劣势在于，您可能无法获取大型文件，除非在传输之前将它们分成小文件。

释放资源

删除目录的请求非常简单明了。指定要删除的目录和目录所在的机器，如清单 12 所示：

清单 12. 请求目录删除

<stafcmd name="'Delete remote directory'">
   <location>mach_name</location>
   <service>'FS'</service>
   <request>'DELETE ENTRY %s RECURSE CONFIRM' % \
      (file, ignore_param)</request>
</stafcmd>

要删除数据库，请停止服务器，或者采取其他操作，可以使用清单 12 中所述的进程元素。

使用结果构建报告（JUnit 报告）

要生成一个 JUnit 报告，使用与运行 JUnit 测试用例相同的方法：创建一个辅助的 ANT 项目来启动创建 JUnit 报告的任务，如清单 13 所示：

清单 13. 创建一个辅助的 ANT 项目

<project name="cvt.junit.report" basedir=".">
   <target name="junit.report">
        <echo message="Generating JUnit Report at ${junit.report.todir}"/>
        <echo message="Reading results from ${junit.report.dir}"/>
        <mkdir dir="${junit.report.todir}" />
        <junitreport todir="${junit.report.todir}">
            <fileset dir="${junit.report.dir}">
                <include name="TEST-*.xml" />
            </fileset>
            <report todir="${junit.report.todir}" />
        </junitreport>
        <echo message="JUnit Report Generated"/>
    </target>
</project>

要启动脚本，可通过进程元素调用它：

清单 14. 通过进程元素启动脚本

<script>
    from java.io import File
    f = File(STAXJobXMLFile)
    ant_script = File(f.getParentFile(),'utilities/JUnitReport.xml').getAbsolutePath()
    ant_script = ant_script.replace('\\','/')
    java_envs = ''
    java_envs = '%s -Djunit.report.todir=%s' % (java_envs, output_dir)
    java_envs = '%s -Djunit.report.dir=%s' % (java_envs, work_dir)
    parms = '%s -f %s junit.report' % (java_envs, ant_script)
</script>
<process name="'cmd %s %s' % (ant_cmd, parms)">
    <location>mach_name</location>
    <command mode="'shell'">ant_cmd</command>
    <parms>parms</parms>
    <workdir>work_dir</workdir>
    <console use="console" />
    <stdout>stdout</stdout>
    <stderr>stderr</stderr>
    <returnstdout />  
    <returnstderr />  
</process>

将结果存储在本地或远程服务器（使用 FTP 或一个共享文件夹）

在运行可用于验证测试结果的所有报告之后，在一个或多个文件中压缩它们。如果您将它们存储到 Web 服务器上，那么可以更轻松地访问结果，开发人员和测试人员可立即访问它们。参见清单 15 中的示例。

清单 15. 压缩报告

<stafcmd>
    <location>'local'</location>
    <service>'FTP'</service>
    <request>'PUT HOST %s URLPATH %s FILE %s USER %s PASSWORD %s' % \
        (CVT_FTP_SERVER, remotePath, localPath, ftp_user, ftp_passwd)
    </request>
</stafcmd>

发送通知（电子邮件）

您可以使用 EMAIL 服务向开发人员或测试人员发送有关增量或回归测试的通知。staf.cfg（bin 目录中的 STAF 配置文件）中的服务配置很简单。它需要一台电子邮件服务器和包含服务实现的 JAR 文件的路径。您可以从 STAF 下载页面下载文件，如下所示：

SERVICE email LIBRARY JSTAF EXECUTE c:/staf/services/email/STAFEmail.jar \
              PARMS "MAILSERVER na.relay.ibm.com"

清单 16 显示了发送电子邮件请求的结构：

清单 16. 发送电子邮件请求的结构

<stafcmd name="'send_email'">
    <location>'local'</location>
    <service>'EMAIL'</service>
    <request>email_cmd</request>
</stafcmd>

其中 email_cmd 使用如清单 17 中所示的格式（来自电子邮件服务用户指南）：

清单 17. email_cmd 的格式

SEND < TO <Address> | CC <Address> | BCC <Address> >...
     [FROM <user@company.com>] [CONTENTTYPE <contenttype>]
     < MESSAGE <Message> | FILE <File> [MACHINE Machine] >
     [SUBJECT <subject>] [NOHEADER] [TEXTATTACHMENT <file>]...
     [BINARYATTACHMENT <file>]... [ATTACHMENTMACHINE <machine>]
     [RESOLVEMESSAGE | NORESOLVEMESSAGE]
     [AUTHUSER <User> AUTHPASSWORD <Password>]

使用与 STAF/STAX 的持续集成

从开发人员的角度来看，持续集成包括频繁地将新代码和更改集成到代码存储库中，并持续验证这些更改不会破坏现有代码。

验证通常由一个自动化构建系统执行，该系统可检测更改发生的时间，或在预定时间运行内部版本。内部版本确认可能的代码破坏，并优先执行一组单元测试来验证基本功能得到维护。内部版本可能经常运行，也可能很长时间才运行一次。用户通常不想在持续集成系统中包含组件测试，因为运行每个内部版本花费的时间有点长。

持续执行组件测试的一个可行解决方案是采用一个独立的系统。该系统对当前代码库执行自动化测试，或根据请求执行特定测试。考虑通过 STAX 运行一个循环，该循环：

1.检索最新的生产和测试映像

2.验证是否安排了预定的回归测试

3.检测测试代码更改（每个测试用例的 STAX 脚本）

4.验证是否安排了增量测试请求

一天执行一次回归测试，包括所有测试。每当有代码更改（比如补丁或新特性）需要测试时，就可以执行增量测试。例如，要测试现有命令行接口的一个新参数，执行特定于该命令行接口的增量测试。执行增量测试可以提高团队生产效率，因为它们提供故障识别的时间比等待夜间回归测试更早。

要验证一个映像（包含待测软件或测试资源的捆绑包）是否被更新，可以检索文件修改时间，将这个时间与本地文件中存储的上一次修改时间进行比较。用于检索一台 FTP 服务器中一个文件的修改时间的 Python 命令是：

ftp.cwd(ftp_url_path)
ftpMDTM = ftp.sendcmd('MDTM %s' % file)
#Example of result: '213 20101129060511'

如果文件自上一次验证之后被修改，您可以使用 STAX FTP 服务或 Python FTP 模块下载它。验证是否需要执行回归测试很简单，只需比较当前时间与预定时间即可。如果当前时间比预定时间晚，则执行回归测试。

一个更复杂的功能是执行增量测试的能力。增量测试是在选定的环境集中运行一列或一组预定义测试用例的一个请求。一种可能的实现方式是定期验证新请求是否在与 Web 服务器共享的一个文件中。您可以使用本地 Web 服务器提供的一个 HTML 页面，在该文件中包含请求，包含的信息包括：

1.请求（一组预定义测试用例或单个测试用例的一个列表）

2.产品版本

3.运行测试用例的环境列表

4.会话 ID

5.请求的识别

6.处理请求所需的其他内部信息

在以下示例中，代码显示在多个行上，以满足格式限制。通常它是一行级联码。

t||testcase_nop||FRS-1.0.0||LinuxDB2Websphere85,ZLinuxDB2Websphere8||false||true|
|4EF60DC3B825707D6BAE349047B4E664||fnegre@br.ibm.com||ready||20121023220123||default

图 1 显示了用于请求增量测试的一个页面示例。

以 Apache Tomcat 这样的 Web 服务器为接口，使用 STAF/STAX 脚本执行持续集成，这样就可以扩展最终用户的选项数量，例如：

1.添加指定自定义映像（由开发人员/测试人员/支持分析师在本地生成的映像）的功能

2.添加从 FTP 服务器直接下载映像的功能

3.取消执行中的请求

4.为当前执行可视化 STAX 用户日志

5.可视化日志和历史记录以及其他报告

图 2 显示了包含系统主功能链接的主页面的实现。Web 服务器还有助于显示集成系统的状态，比如：

1.执行中的测试用例

2.开始时间

3.请求者

4.处于测试中的环境

5.结果链接（测试已经完成）

图 2. 持续集成系统的主索引

在图 3 显示的页面中，用户可以访问之前的执行产生的结果，这个结果是根据环境名称进行组织的。结果包含测试用例日志、JUnit 报告、覆盖率报告以及测试产生的其他任何有用信息。请注意，报告中有 6 个环境。所有测试用例于夜间在这些环境中运行，白天可用于执行增量测试。可用的环境包括 Linux for System z、Windows 和 Linux (Red Hat) 机器。可以通过为每个新环境创建属性文件将新环境插入系统中。

图 3. 图 3 回归日志的访问

包含基本功能的一个持续集成系统可以按照以下顺序逐渐构建：

在一台机器上运行单个测试用例的 STAX 脚本

在更新/准备测试用例之后，在多个环境中运行多个测试用例的 STAX 脚本

在夜间运行以上脚本的 STAX 脚本

通过 HTTP 页面和状态页面执行增量测试来可视化当前执行的功能

结束语

使用 STAF/STAX 为持续集成构建测试用例和基础架构的一个显著优势就是，能够根据需要灵活地扩展测试自动化系统，创建可集成到系统中的新功能和脚本。当一个项目采用敏捷开发，能够使用 STAF/STAX 自动化所有测试并将它们集成到一个持续集成系统中时，您可以及时测试新功能或补丁。此外，经用户请求，在一组不同的环境之间执行增量测试可缩短开发时间，提高软件质量。