内容


在持续交付 DevOps 实践中使用 Rational Quality Manager

使用 Ant API 来调用自动化的测试脚本

Comments

本文将介绍如何使用 ANT API 调用自动化的测试脚本。此过程使得维护测试、测试机器和测试历史记录变得更容易。

IBM® Rational® Quality Manager 是一个规划测试和管理测试结果的协作式中心。从图 1 中可以看出,Rational Quality Manager 是构建于 Jazz™ 平台之上的 Rational 协作式应用程序生命周期管理解决方案的一部分。通过使用 Rational Quality Manager,可以维护自动化和手动的测试用例,实现测试用例的需求可跟踪性,还可管理缺陷和开发计划等变更。它能够与来自其他供应商的产品很好地集成在一起。请参阅 与 Rational Quality Manager 集成的产品 的完整列表。

图 1. 协作式生命周期管理产品
CLM 管理需求、质量和变更
CLM 管理需求、质量和变更

了解持续交付的各个阶段

在持续交付或持续集成实践中,签入代码和向生产服务器部署产品之间的过程是自动完成的。通常,这两个阶段之间无需手动干预。在大多数情况下,编码和部署之间存在各种不同的阶段,如图 2 所示。

  • 开发人员的代码被交付给一个称为主要分支或集成分支的分支。一种好的做法是提供特性代码(产品中包含的代码)以及在单次交付中测试此新代码所需的自动化测试。
  • 该代码被签入到一个源代码控制分支或树中,然后触发一次构建。这次构建是按照固定的时间表执行的,或者可以在检测到文件更改后开始构建。
  • 如果构建成功,这次构建的结果会安装在一个 staging 服务器上,该服务器不是生产服务器。这个 staging 服务器现在运行着开发人员交付的更改集。
  • 在这个 staging 服务器上运行一组测试,确保开发人员的代码未让任何功能退化,而且新功能上的新测试能很好地运行。这是第一道质量门槛。
  • 如果所有测试都已通过(这些累积结论会得出 “继续” 或 “不继续” 的明确决策),更改集会提升到所谓的生产分支或稳定分支中。这是在生产环境中运行的源代码。
  • 在稳定分支上触发一次构建,构建输出部署在生产服务器上。有时会在生产服务器上运行一组简单的冒烟测试,确保包含开发人员所做的更改的新构建版本能良好地运行。这是第二道质量门槛。
图 2. 一个简单的交付管道
集成分支、稳定分支、生产
集成分支、稳定分支、生产

添加一道质量门槛

软件开发团队常常拥有已被广泛接受的构建系统。系统涵盖手动构建的设计该流程的 ANT 和 Perl 脚本,以及更复杂的商业 DevOps 产品。无论使用何种系统类型,都可引入这道质量门槛。本文针对的是更常见的情形,其中团队拥有一个构建和部署工具,该工具在 ANT、Rake、Jython、简单 Java™ 代码或其他一些工具(比如 Maven 或 Hudson)中提供了程序性挂钩。

创建自动化脚本

尽管自动化脚本严格来讲不是添加质量门槛的过程的一部分,但它是确保质量的一个关键方面。在大多数情况下,您已编写了开发人员在其开发环境中运行来进行功能验证的测试脚本。您的测试通常在一个测试创作平台中使用测试开发工具(比如 Selenium、Java JUnit、Rational Functional Tester、HP QTP 或其他工具)来编写。每个测试单元都必须具有足够细的粒度,以便为特定故障提供有用的验证。避免测试涉及太大的范围,这会使得某个故障让很大一部分产品特性受到质疑。避免测试的关注点太窄,这会使得编写有意义的测试方案变得很麻烦。本文使用了一个 Java JUnit 测试脚本示例作为演示脚本;但是,为了将这个示例用于其他测试脚本类型,可以对它进行扩展。

定义一个测试脚本

在创建脚本后,将它连接到 Rational Quality Manager,以便 Rational Quality Manager 可运行它。Rational Quality Manager 使用了脚本类型 的概念。每种脚本类型对应于一个称为测试适配器 的执行组件。在图 3 中的示例中,脚本类型为 JUnit 或 Selenium 脚本,用于指向一个 Selenium Web 驱动程序测试或 JUnit 测试。在持续交付实践中,测试脚本 JAR 文件安装在测试机器上。下面的一节将会介绍如何设置适配器。

图 3. 创建 Rational Quality Manager 测试脚本
创建测试脚本
创建测试脚本

定义测试用例

如图 4 所示,您需要向 Rational Quality Manager 测试用例添加一段 Rational Quality Manager 测试脚本。测试用例是 Rational Quality Manager 中一个基本的可执行实体。测试执行的结果和对测试用例的引用是一起维护的。它们被称为测试用例执行结果。一种不错的做法是在测试用例与测试脚本之间保持一对一的关系,并为它们分配相同的名称。可以在运行时指定适配器。可以使用类别来对测试用例进行分组。如果希望在以后对特定的产品、组件或对您选择的其他任何形式的分组运行报告,类别可能很有用。

图 4. 创建 Rational Quality Manager 测试用例
向测试用例添加测试脚本
向测试用例添加测试脚本

创建测试套件

Rational Quality Manager 中的测试套件(如图 5 所示)提供了一种聚合一组测试用例的方法。使用测试套件,可以管理您想要针对给定质量门槛而运行的自动化测试脚本。例如,测试套件 “构建验证测试” 可能是一个测试脚本集合,用于确定应用程序的绿色线程是否已遭到破坏。如果应用程序拥有用户界面,那么测试套件可能包含一组检验主要 UI 功能的 UI 自动化测试。您可能希望在将构建版本提升到下一阶段之前,在构建版本上运行此测试套件。接下来,您可能有另一系列的测试套件来更详细地测试每个主要特性。例如,一组 API 测试可能测试基础的 REST 接口。您可以添加希望在测试套件运行时运行的所有测试用例。

图 5. 测试套件
向测试套件添加测试用例
向测试套件添加测试用例

创建测试套件执行记录 (TSER)

对于您创建的测试套件,创建一个 TSER,如图 6 所示。通常,您需要制定一个测试计划。将该测试套件添加到测试计划中。为每个测试计划创建一个 TSER。

图 6. 创建测试套件执行记录
不同 ID 的记录列表
不同 ID 的记录列表

安装和部署

这一步通常在持续交付工具中完成。您可以使用 IBM® uDeploy®(一个自定义构建脚本)或 Chef 等工具,在源代码成功构建后安装构建版本。在此阶段中,必须将您的应用程序和测试资产(比如所有 Junit 类和需要的 JAR)安装在目标机器上一个已知的位置。以后在定义 Rational Quality Manager 测试脚本时会使用这个位置。如果使用自动化的测试脚本,比如 IBM® Rational® Functional Tester,那么还可以使用 Rational Functional Tester 适配器支持的共享位置选项,将测试资产传送到目标机器。

Rational Quality Manager 适配器

Rational Quality Manager 有一个叫做适配器的组件,它是一个远程组件,通常安装在测试机器上。此适配器与 Rational Quality Manager 服务器进行通信,并调用 Rational Quality Manager 要求它运行的测试脚本。然后,这些测试的结果会传送回 Rational Quality Manager。

安装合适的适配器

在安装阶段,还要安装 Rational Quality Manager 适配器。如果编写 JUnit/Selenium,则需要安装 Selenium JUnit 适配器;如果编写 Rational Functional Tester,则需要安装 Rational Functional Tester 适配器。在配置适配器并且必须指定适配器名称的时候,可以使用运行该适配器的机器的完全限定域名。此做法很容易识别在运行测试用例和测试套件时要使用的适配器。有关的更多细节,请参阅有关 运行自动化测试和测试适配器 的文档。

使用 Rational Quality Manager ANT API 调用测试

您的主要工具或许就是一段 ANT 脚本。Rational Quality Manager 提供了一个基于 ANT 的 API,名为 Rational Quality Manager 执行工具,用于调用运行的测试用例的执行记录和测试套件的执行记录。Rational Quality Manager 执行工具从与特定质量门槛关联的 build.xml 文件调用。使用的 TSER id 被作为一个属性保存在一个有关联的属性文件中。例如,清单 1 中的代码调用了 Rational Quality Manager 集成测试。

清单 1. 调用 Rational Quality Manager 集成测试
<executeTestSuiteExecRecord
   userId="${rqmUser}"
   passwordFile="${root}/${rqmPasswordFile}"
   rqmServerUrl="${rqmServerUri}"
   projectName="${rqmProjectName}"
   testSuiteExecRecordId="${rqmTestSuiteERId}"
   suiteStepAdapterIds="${testClientServer}"
   arguments="-passVariables=true -exitOnComplete=true 
-variables=com.ibm.rqm.oslc.test.serverHost:${deployedServer},server:$
{deployedServer},buildLabel:${buildLabel}" />

可以使用 -variables 选项将任何配置或执行信息传递给测试。您可以了解 执行工具和参数 的更多信息。

使用结果进入到测试周期中的下一步

在完成操作时,Rational Quality Manager 执行工具 ANT 任务会设置两个属性,以反映执行状态和执行结果的链接。这两个属性分别是 rqmExec:verdictrqmExec:result_url。可以向构建记录添加一个日志文件和测试结果。如果使用了 IBM® Rational Team Concert™,那么可以执行以下任务:

  • 使用 Rational Team Concert ANT taskdef logPublisher,将 Rational Team Concert 构建结果的状态设置为 Rational Quality Manager 执行的状态。
  • 使用 Rational Team Concert ANT taskdef linkPublisher,在 Rational Team Concert 构建结果中添加一个指向 Rational Quality Manager 执行记录的链接。

查阅这些有关 Ant 任务 的更多信息。清单 2 给出了将结果和结果 URL 写入日志文件的示例代码。

清单 2. 将结果写入日志文件
<echo file="${root}/QMIntegrationTestsLog.txt" >
   Verdict: ${rqmExec:verdict}
   Execution Result: ${rqmExec:result_url}
</echo>

清单 3 显示了基于执行状态而设置一个属性的示例代码。

清单 3. 基于执行状态设置一个属性
<condition property="QMExecStatus" value="OK" else="ERROR">
   <equals arg1="${rqmExec:verdict}"
   arg2="com.ibm.rqm.execution.common.state.passed"/>
</condition>

清单 4 展示了如何将日志文件附加到构建记录。

清单 4. 将日志文件附加到构建记录
<logPublisher 
   repositoryAddress="${repositoryAddress}" 
   userId="${jazzUserId}" passwordFile="${jazzPasswordFile}"
   buildResultUUID="${buildResultUUID}" 
   filePath="${root}/QMIntegrationTestsLog.txt" 
   label="QM Integration Test Log" 
   status="${QMExecStatus}" 
/>

清单 5 展示了如何将测试结果链接附加到构建记录。

清单 5. 将结果附加到构建记录
<linkPublisher 
   repositoryAddress="${repositoryAddress}" 
   userId="${jazzUserId}" 
   passwordFile="${jazzPasswordFile}" 
   buildResultUUID="${buildResultUUID}" 
   url="${rqmExec:result_url}" 
   label="Rational Quality Manager Execution Result" 
   componentName="Rational Quality Manager Execution Result"
/>

分析结果

测试周期开始后,对于一个特定的构建版本,您可从 Test Suite Result 下钻到 Test Case Result 并查看结果,如图 7 所示。(测试套件结果的链接使用 linkPublisher 添加到构建版本中。)您还会获得结果的图形表示。

图 7. 测试用例结果细节
该条形图显示了通过的测试和失败的测试
该条形图显示了通过的测试和失败的测试

积累足够多的结果后,就可以通过挖掘结果数据来获取更多情报。此功能只有 Rational Quality Manager 等质量管理工具才提供。(没有它,您的文件系统上将会只有结果文件。)例如,通过使用质量管理工具,您可以按类别查看执行状态,如图 8 所示。类别已在 测试用例定义 一节中介绍。

图 8. 按类别对结果进行分析
该条形图显示了不同类别的状态
该条形图显示了不同类别的状态

结束语

Rational Quality Manager 提供了一种结构化的简单方式来管理需要在 DevOps 的持续交付实践中运行的测试。您可以采用递增方式使用它来构建成熟的 DevOps 产品,无需返工。与在构建工具中手动编写测试脚本相比,测试用例管理和测试结果分析是两个非常强大的优势。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational, DevOps
ArticleID=981713
ArticleTitle=在持续交付 DevOps 实践中使用 Rational Quality Manager
publish-date=08282014