SOA 组合业务服务的自动化测试
 

2009-06-26 作者：宋玉红,袁俊峰,杨晢 来源：IBM
 

通过本文您将了解组合业务服务的概念以及如何自动化的将 WebSphere Process Server，WebSphere Application Server，DB2 等应用中间件和 Rational Performance Tester for SOA quality，Rational Function Tester，等测试工具整合成一套完整的测试环境。

引言

组合业务服务 (Composite Business Service - CBS) 是在一起工作的业务服务和客户机现有应用程序的集合，目的是为了提供特定的业务解决方案。企业可以通过创新方式灵活地连接组合业务服务、用户界面和数据服务，以创建新的组合业务应用程序（由 Gartner, Inc. 提出的面向 aka 服务的业务应用程序）来支持业务需求。

图 1. CBS 与业务流程的映射

图 1 示意了 CBS 与业务流程的映射关系。业务流程由一系列业务服务实现。一个 CBS 就是这样一些业务服务的集合。集合中的业务服务应当满足这样一些条件：

  • 实现业务流程中的关键功能
  • 在行业中通用的业务逻辑
  • 具有标准的输入输出接口

CBS 的出现使得基于业务流程的解决方案的实施进程大大加快。相应的对于 CBS 的测试具有以下特点：

  • CBS 的通用性特点要求，CBS 要在不同软件平台环境下正确运行。
  • CBS 的并非最终产品，没有（或很少）图形界面的手工测试。

这些特点导致对 CBS 测试要求很高的自动化支持。

测试环境的框架

从操作层面来讲，作为黑盒测试，首要明确的是系统中存在哪些对外接口。图 2 是 IBM 总结的 SOA 架构概念模式，其中服务层 (Services)、业务流程层 (Business Process)、服务消费层 (Consumers)，这三部分通常是要暴露给最终用户的应用接口。

图 2. SOA 的架构概念模式

图 3 展示了一个真实的测试环境的系统各个组成部分。与概念模型相对应，在这个系统中有面向业务消费者的 web 浏览器 UI，和面向业务定制者的 SCA 接口以及 Web Service 接口。

图 3. 测试环境框架

为了实现以上的抽象的系统框架，我们需要一些在现实世界中实际存在的产品来搭建出我们所需的真实环境。根据实现，得出如下一套方案：

使用 DB2 实现系统持久层管理。

使用 WebSphere Application Server (WAS) 提供系统运行时支持环境。

使用集成了 ESB 的 WebSphere Process Server (WPS) 管理服务调度，提供 SCA 基础构件。

使用 Rational Performance Tester for SOA Quality (RPT for SOA Quality) 进行服务层接口测试。

使用 Rational Function Tester (RFT) 进行用户 UI 层接口测试。

图 4 直观的描述了 SOA 组合业务服务自动化测试方案。

图 4. SOA 组合业务服务自动化测试方案

需要说明的是，在项目中根据具体的测试需求，可能还需要添加 LDAP 服务器，文档管理服务器等，或用于离线业务的消息队列服务。而上面给出的测试环境是实现功能测试的最小集。

以下篇幅介绍如何自动化的将 WPS，DB2 等应用中间件和 RPT for SOA quality，RFT，等测试工具整合成一套完成的测试环境。

测试环境自动化配置的途径

本章主要介绍在测试环境自动化搭建过程中被广泛使用的两种方法。

使用响应文件进行静默安装

响应文件可以简化组件的安装和配置。响应文件是文本文件，包含安装和配置组件所需的产品和系统信息。执行无人照管（静默）安装时，此文件相当有用。安装过程从响应文件读取信息，而不是提示您进行填空。也可以使用文本编辑器添加组件或定制选项，将响应文件重新用于以后的安装。

虽然不同产品的响应文件内容存在区别，但大体上应遵循以下规范：响应文件由“属性 = 值”对组成；每一个对都代表了安装中对某一属性的设置；不同的对之间用回车符加以区分；可以在注释前使用字符 # 将注释添加到响应文件中。

以下示例说明了从简易安装脚本生成的响应文件。

总体来讲，要使用响应文件安装支撑软件，请遵循这些基本步骤：

一、编辑响应文件以检查其语法并确保信息正确无误。

二、运行安装脚本并指定响应文件。

三、检查软件是否被正确的安装成功。

使用脚本编制配置 WPS

WPS 提供了脚本编制工具 wsadmin。我们用这一工具来代替交互式的管理控制台，实现 WPS 配置的自动化。WPS 的全部管理活动都可以使用 wsadmin 工具完成。

图 5 描述 wsadmin 脚本编制解决方案中涉及的主要组件：

图 5. WebSphere Application Server 脚本编制解决方案

wsadmin 工具支持两种脚本语言：Jacl 和 Jython。在本文中采用 Jacl 实现脚本文件。当您使用脚本时，有五个对象可用：

  • AdminControl：用于运行操作命令；
  • AdminConfig：用于运行配置命令以创建或修改 WebSphere Application Server 配置元素；
  • AdminApp：用于管理应用程序；
  • AdminTask：用于运行管理命令；
  • Help：用于获取一般帮助；

脚本使用这些对象与运行在 WebSphere Application Server 进程中的 MBean 通信。MBean 是表示 Java 管理扩展（JMX）资源的 Java 对象。JMX 是附加于 Java 2 Platform Standard Edition（J2SE）的可选软件包。JMX 是提供简单和标准方法来管理 Java 对象的一种技术。您可以通过以参考资料 1 与参考资料 2 找到更多关于 Jacl 与 WPS 配置模型的信息。

一个具体的配置过程

作为一个典型的基于 SOA 的组合业务解决方案，我们在测试环境部署阶段要做的事情有：

  • 搭建一套由干净的操作系统组成的局域网；
  • 安装数据库管理工具；
  • 安装和配置应用服务器；
  • 安装和配置运行动态服务流程的流程服务器；
  • 安装 service layer 测试工具；
  • 安装 business process layer 测试工具；
  • 安装 GUI layer 测试工具；

我们采用表 1 中的产品作为上述工具的实现。

表 1. 工具清单
　
工具 采用产品
数据库管理工具 DB2 V8.2
应用服务器与流程服务器 Websphere Process Server V6.0.2（其中集成 Websphere Application Server 6.0.2）
service layer 测试工具 Rational Performance Tester for SOA Quality V7.0.1
business process layer 测试工具 Rational Performance Tester for SOA Quality V7.0.1
GUI layer 测试工具 Rational Function Tester V6.1

以上每一个步骤都可以当作一个脚本的一部分来执行，但是为了讲述方便，我们将把不同的步骤分开描述、分开执行。当然，最终您应当使用一种被操作系统支持的脚本语言将各个步骤衔接起来。

以下篇幅将讲述如何自动化部署这些工具和产品。操作系统选用 Windows Server 2003 为例。

安装 DB2 V8.2

DB2 提供了响应文件安装的方式。我们利用这种安装方式来实现 DB2 的静默安装。

第一步，生成响应文件。当使用交互式安装实用程序安装 DB2 时，在安装开始之前会提示您进行安装选择并提供必要的配置数据。响应文件的作用就是预置这些安装选项和配置数据。

可以用三种方法来生成响应文件：

  • 使用 DB2 Setup Wizard；
  • 使用 DB2 响应文件生成器实用程序（仅 Windows）；
  • 手动生成响应文件；

响应文件是 ASCII 文本文件。清单 1 是响应文件的样本。

清单 1. DB2 响应文件 

PROD=ENTERPRISE_SERVER_EDITION
LIC_AGREEMENT=ACCEPT
FILE=C:\Program Files\IBM\SQLLIB\
INSTALL_TYPE=TYPECAL
LANG=EN
DAS_CONTACT_LIST=LOCAL
DATABASE=WH_CDB
WAREHOUSE_CONTROL_DATABASE=WH_CDB
WAREHOUSE_SCHEMA=IWH
WH_CDB.DATABASE_NAME=DWCTRLDB
INSTANCE=DB2
INSTANCE=DB2CTLSV
WH_CDB.INSTANCE=DB2
WH_CDB.LOCATION=LOCAL
DB2.NAME=DB2
DB2CTLSV.NAME=DB2CTLSV
DEFAULT_INSTANCE=DB2
CTLSRV_INSTANCE=DB2CTLSV
DB2.SVCENAME=db2c_DB2
DB2CTLSV.SVCENAME=db2c_DB2CTLSV
DB2.DB2COMM=TCPIP
DB2CTLSV.DB2COMM=TCPIP
DB2.PORT_NUMBER=50000
DB2CTLSV.PORT_NUMBER=50001
DB2.FEDERATED=YES
DB2.AUTOSTART=YES
DB2CTLSV.AUTOSTART=YES
DB2.USERNAME=db2admin
DB2CTLSV.USERNAME=db2admin
WH_CDB.USERNAME=db2admin
DB2.PASSWORD=passw0rd
ENCRYPTED=DB2.PASSWORD
DB2CTLSV.PASSWORD=passw0rd
ENCRYPTED=DB2CTLSV.PASSWORD
WH_CDB.PASSWORD=passw0rd
ENCRYPTED=WH_CDB.PASSWORD
DAS_USERNAME=db2admin
DAS_PASSWORD=passw0rd
ENCRYPTED=DAS_PASSWORD
DB2_EXTSECURITY=YES
DB2_USERSGROUP_NAME=DB2USERS
DB2_ADMINGROUP_NAME=DB2ADMNS

另外，在 DB2 的安装文档中 \db2\Windows\samples\db2ese.rsp 文件是响应文件模板，其中包含了对以上属性设置的解释。

有 DB2 关响应文件的更多内容您可以查看参考资料 3。

第二步，使用响应文件静默安装 DB2。使用响应文件安装 DB2 仍需通过 setup.exe 来进行。不过需要给该安装程序输入响应文件的完整目录作为执行参数，以激活响应文件安装方式。清单 2 是执行响应文件安装方式的命令样式。

清单 2. 执行 DB2 响应文件 

SET buildpath=C:/tools/db2_82/FP10_WR21362_ESE/
%buildpath%setup /u c:/resf.rsp

还可以通过执行 setup /? 来查看 setup 的更多执行方式。

DB2 安装完成后，我们使用从 Windows 命令提示符创建 database。命令如下：

db2cmd db2 CREATE DATABASE MyDB ON 'C:' USING CODESET GBK TERRITORY CN

有关 DB2 响应文件的更多内容你可以查看参考资料 3。

安装 WPS V6.0.2 和配置概要

由于 WPS V6.0.2 中已经集成了 WAS V6.0.1 与 ESB，所以我们只需执行 WPS 的安装便可同时完成上述三者的安装，这位我们的自动化部署带来了极好的便利。

我们同样使用响应文件方式进行静默安装。由于文件过长，将其放在了文章的附件当中。

使用响应文件静默安装 WPS。使用响应文件安装 WPS 通过 Installwebsphere\tool pack\wps601\WBI\install.exe 来进行。需要给该安装程序输入响应文件的完整目录作为执行参数，以激活响应文件安装方式。清单 3 是执行响应文件安装方式的命令样式。

清单 3. 执行 WPS 响应文件 

SET wpsbuildpath=C:/tools/Installwebsphere/tool pack/wps602/WBI/
%wpsbuildpath%install -options install_wps.txt

有关 WPS 响应文件的更多内容你可以查看参考资料 4。

为 WPS 配置一个 DB2 Universal 数据源

在这一步中，我们利用 WPS 自带的命令行工具 (websphere/appserver/profiles/server1/bin/wsadmin)，编写 jacl 脚本，集成到 ant 中，利用 ant 强大的项目构建能力实现数据源的自动配置。

在本文的附件当中有完整的配置数据访问的 jacl 脚本。脚本大体可以分为三个模块：1. 配置 JDBC 提供程序；2. 配置新的数据源；3. 建立 CMP 连接工厂，将配置好的数据源用于容器管理的持久性。清单 4 是 jacl 脚本中建立 CMP 连接工厂部分的节选。这部分代码相当于从图形化管理界面中勾选“将此数据源用于容器管理的持久性（CMP）”。

清单 4. 建立 CMP 连接工厂 

 set jdbcAdapter ""
 # Get the cell's J2CResourceAdapter object
 # This could return multiple J2CResourceAdapters
 set j2cradapters [$AdminConfig list J2CResourceAdapter $node]
 foreach j2cradapter $j2cradapters {
 set j2craName [$AdminConfig showAttribute $j2cradapter name]
 if {$j2craName == "WebSphere Relational Resource Adapter"} {
 set jdbcAdapter $j2cradapter
 }
 }
 puts "J2CRA is $jdbcAdapter"
 # This will cause a corresponding CMP connection factory which corresponds
 # to this datasource to be created for the relational resource adapter
 set cmp_connfac_attrs [list [list name "$dsname\_CF"] 
 [list authMechanismPreference BASIC_PASSWORD] [list cmpDatasource $newds]]
 set cmp_connfac [$AdminConfig create CMPConnectorFactory $jdbcAdapter 
 $cmp_connfac_attrs]
 puts "CMPCF is $cmp_connfac"
 set authDataAliasList [list authDataAlias db2Alias]
 set mappingConfigAliasList [list mappingConfigAlias DefaultPrincipalMapping]
 set mappingList [list $authDataAliasList $mappingConfigAliasList]
 $AdminConfig create MappingModule $cmp_connfac $mappingList
$AdminConfig save

脚本运行命令为：

<%WPSProfileRoot%>\bin\wsadmin.bat -f "<%FullPathOfYourScript%>"

其中，<%WPSProfileRoot%> 代表 WPS 配置概要的完全路径，<%FullPathOfYourScript%> 代表你的数据访问配置脚本的完全路径。

有关 WPS 数据源配置的更多内容你可以查看参考资料 5。

安装 RFT、RPT for SOA Quality

完成以上三个步骤后，一个最基本的基于 SOA 的组合业务解决方案的支撑环境就已经搭建好了。不过我们还需将测试工具添加到该环境中，这样才能构成一个完整的测试支撑环境。前面提到了两个测试工具：RFT 和 RPT for SOA Quality。实际的安装需要分为三步进行：

  • 安装 RFT V 6.1；
  • 安装 RPT V 7.0.1；
  • 在 RPT 上安装 RPT for SOA Quality 插件。

安装 RFT V6.1，RFT 提供了一个标准的静默安装方式。该静默安装方式等同于从 Setup Wizard 进行典型安装。运行静默安装方式的命令如下：

<%RFTInstallRoot%>\setup\setup –silent [-P installLocation="d:\my appdev"]

其中，<%RFTInstallRoot%> 代表 RFT 安装包的实际路径；“[]”中为可选参数，通过设置参数 installLocation，可以更改 RFT 的安装路径。

安装 RPT V7.0.0.1，RPT V7.0.0.1 具有与 RFT V6.1 相似的静默安装方式。唯一不同是安装文件的名称变为了 install_win32.exe。命令如下：

<%RFTInstallRoot%>\ install_win32 –silent [-P installLocation="d:\my appdev"]

安装 RPT for SOA Quality 插件，当 RPT for SOA Quality 的安装程序能自动检测出本地系统上的 RPT 信息，无需手动指向。运行静默安装方式的命令如下：

<%RFTInstallRoot%>\ install_win32 –silent

注意：只有 RPT V7.0.0.1 或更高版本，才能支持 RPT for SOA Quality V7.0.1 插件。

总结

本文主要介绍了 SOA 组合业务服务的环境框架，以及自动化测试手段与工具。之后讲解了如何自动化的部署一套测试环境。本系列的下一篇文章将介绍如何在这样一套测试环境中实现被测实体的自动化部署。

在本系列的 上一篇 文章中，我们介绍了如何实现 SOA 测试环境的自动化安装 , 这一章我们将介绍如何自动每天定时安装新的待测 SOA 组件。

SOA 的体系架构中很强调“分布式”这个概念，不仅是构架的分布式，开发模式也体现了“分布式”的概念，SOA 的开发团队经常分布于全球不同的角落，比如：Service 层的开发位于中国、测试组位于中国、UI 层的开发位于美国。这种分布式的时区差异导致了如果美国出 Build 的时间是北京时间的凌晨 4：00，中国测试团队每天早上上班的第一件事就是从美国的服务器中取下 Build 然后把它部署到服务器上，重复的劳动不仅耗费大量的人力物力，且由于 SOA 组件的配置比较复杂，手工配置很容易出错，加大了测试团队的风险。

除了开发和测试的分布式模式带来的挑战之外，由于 SOA 是一个基于服务的构架，服务粒度的细化导致在一个企业级 SOA 应用中会有大量的服务需要发布出来，可能导致的部署的 EAR 包比传统构架的多，体系结构也比较复杂。有一个真实客户的例子，在采用 SOA 构架后其 IT 架构包括如下几部分：

  • 50 个 Websphere 的集群 (cluster)，200 个应用服务器 (application server) 在 40 个节点 (node) 上。
  • 整个应用程序包含 26 个 EAR 包在 11 个独立的实例上 (instance)，这就意味这 11*26 的部署工作。
  • 12 个 SIBus, 2 个 JMS queues，每个集群 (cluster) 一个数据源 (dada source)。

管理和配置这个复杂的环境无论对测试人员还是客户来说都是一个噩梦，自动化部署不仅可以大大提高测试的工作效率、减少项目风险而且可以向客户提供一种”one click”的解决方案，对客户屏蔽诸多技术的细节和配置的复杂性，提高客户对 SOA 技术的忠诚度。

本文将根据我们在项目中的经验总结出一种每天按需求自动下载、部署、配置 Build 的自动化方案。

自动下载 SOA 组件

SOA 的分布式开发环境

下图是一个很典型的 SOA 的开发和测试环境。

图 2.1 典型的 SOA 开发环境

在图中所示的这种软件开发环境中，Service 开发团队和测试团队位于中国，UI 开发团队位于美国，Service 开发团队和 UI 开发团队都有自己的 Build Server，用于存放自己每天所发布的 Build，测试团队有自己的一套 SOA 测试环境，它需要每天安装和配置 SOA 的 Service 组件和 UI 组件用于测试。本章将介绍测试团队如何在这种分布式环境中实现自动化测试。

自动获取 Build

在当前的脚本语言中 Ant 和 Python 是最流行的两种语言：Python 是一种非常灵活强大的动态脚本编程语言，具有完整的面向对象特性；Ant 是纯 Java 语言编写的，具有良好的跨平台性，由于 Ant 的构建文件时以 XML 书写，容易维护且结构清晰。我们将结合两种语言各自的优点运用于我们的脚本之中。我们以 Windows 为例，整个自动化脚本的目录结构如下所示：

图 2.2 自动化脚本的目录结构

有几个目录需要重点介绍一下：

EAR：是我们存放下载后 Build 的路径，他有两个子目录 service 和 UI 分别用于存放 SOA 的服务层和用户界面层的 Build。

Lib: 存放应用程序所需要的共享库，某些应用程序部署上后需要配置共享库。

在 BuildScript 目录下有一个 deployBuild.bat 文件，一个 buildToTest.py 文件。

图 2.3 BuildScript 目录下的文件

deployBuild.bat 文件主要用于定义一些 WPS profile 的位置、Build 放置的位置、WPS 登录用户名和密码等信息。

图 2.4 deployBuild.bat 文件的内容

文件中前 6 行都是运行环境的配置信息：

pathProfile: WPS 的 profile 路径。

pathProcServer: WPS 的安装路径。

pathBuildService: service 层 build 的放置目录。

pathBuildUI: UI 层 build 的放置目录。

authStmt: WPS 的用户名和密码，在启动了安全性后用命令行控制 WPS 时需要提供认证信息，在这个示例中我们的用户名和密码都是 IBM。

第七行是调用 buildToTest.py 的 python 文件，后面的数字 (2007102202) 是要安装 build 的版本号，这个版本号需要开发组和测试组共同协商，确定一个 build 的编号规则，自动脚本下载的 Build 号将以此为唯一标识。一般来说可以采用日期 + 序号的方法，如果所示的 2007102202 就表示的是 2007 年 10 月 22 日的第二个 build。

buildtoTest.py 文件主要定义了一些自动化的主要步骤。

import os, os.path
from time import strftime,localtime,ctime
import urllib
import smtplib
import sys
top_dir = os.getcwd()	
currentTime = strftime("%Y%m%d", localtime())
# Get Ears
retEars = os.system('ant -Dbuild.number=%s -buildfile %s/otherTargets.xml ftp-get-ears '
 %(sys.argv[1] ,top_dir + '/Script'))
# Uninstall and install UI
retunInstall = os.system('%s/uninstallAllUI.bat' %(top_dir + '/Script')) 
retinstall = os.system('%s/installAllUI.bat' %(top_dir + '/Script'))
# Uninstall and install services
retunInstall = os.system('%s/uninstallAllApps.bat' %(top_dir + '/Script')) 
retinstall = os.system('%s/installAllApps.bat' %(top_dir + '/Script'))

我们在 python 中定义了 3 个重要的任务：

GetEars: 该步骤用到了 ant 脚本 (otherTargets.xml) 的 ftp-get-ears 下载 build 到本地目录中，关于 otherTargets.xml 中 ftp-get-ears 的编写，我们在后面会做一个示例性的介绍。

Uninstall and install UI: 该步骤分别调用了一个卸载旧的 UI 组件 (uninstallAllApps.bat) 和装载新的 UI 组件 (installAllUI.bat) 的批处理命令 , 卸载 UI 的脚本我们将在后面介绍一个自动化框架。

Uninstall and install services: 该步骤和上面基本相似，不同之处是该步骤卸载和安装的对象是 service 的组件，卸载 Service 的脚本我们将在后面介绍一个自动化框架。

otherTargets.xml 的一个下载 Build 的代码片断如下所示：

<target name="ftp-get-ears">
<delete dir="../Build/"/>
		<mkdir dir="../Build/"/>
		<ftp action="get"
			server="127.0.0.1"	
			remotedir="/www/Demo /${build.number}/" 	
			userid="IBM" 
			password="IBM">
			<fileset dir="../Build">
				<include name="**"/>
			</fileset>
		</ftp>	
</target>

这个 target 由以下几个操作组成：

1. 删除 Build 文件夹：因为每天的 build 都会放入这个目录，为了保证该文件夹下的 build 都是最新的我们会在下载之前将该文件夹删除。

2. 新建 Build 文件夹：用于存放即将下载的新 build。

3. 下载 Build：我们在 <ftp action=”get”> 这个操作里面定义了 FTP 下载所需要的若干参数：

  • server : FTP 服务器的 IP 地址。
  • remotedir: FTP 服务器存放 build 的路径。
  • userid: 登陆 FTP 的用户名。
  • password: 用户名所对应的密码。

大家从这段代码可以看出 Ant 语言的优点：非常简洁，有强大的类库，能用简短的程序完成复杂的操作。如果还要加入其它的任务，只需要加入 <target></target> 代码片段。

自动安装和配置 SOA 组件

当待测试的新 SOA 组件从各个开发团队的 FTP 下载到本地服务器之后，我们就要将它们自动部署到测试服务器上，我们将采用 WebSphere 脚本配置和管理 SOA 组件。

wsadmin 简介

WebSphere Application Server wsadmin 工具提供运行脚本的能力 , 支持通过运行脚本来自动化环境的配置任务。wsadmin 工具支持整个范围的产品管理活动。

图 2.5 WebSphere Application Server 脚本解决方案

wsadmin 工具支持两种脚本语言：Jacl 和 Jython。当您使用脚本时，有五个对象可用：

AdminControl：用于运行操作命令。

AdminConfig：用于运行配置命令以创建或修改 WebSphere Application Server 配置元素。

AdminApp：用于管理应用程序。

AdminTask：用于运行管理命令。

Help：用于获取一般帮助。

脚本使用这些对象与运行在 WebSphere Application Server 进程中的 MBean 通信。MBean 是表示 Java 管理扩展（JMX）资源的 Java 对象。JMX 是附加于 Java 2 Platform Standard Edition（J2SE）的可选软件包。JMX 是提供简单和标准方法来管理 Java 对象的一种技术。

要使用脚本执行任务，必须首先执行以下步骤：

1．选择一种脚本语言。wsadmin 工具仅支持 Jacl 和 Jython 脚本语言。Jacl 是缺省指定的语言。如果要使用 Jython 脚本语言，使用 -lang 选项或者在 wsadmin.properties 文件中指定。

2．按脚本或概要文件，作为单个命令，交互地 启动 wsadmin 脚本客户机 。

启动 wsadmin 客户机方法是 : 进入特定概要文件所在的 bin 目录 profile_root/bin，如果启用安全性，执行如下命令。

wsadmin.bat -user wsadmin -password wsadmin

成功进入 wsadmin 的界面如下图所示 :

图 2.6 启动 wsadmin

使用 wsadmin 安装和配置 SOA 组件

假设安装和配置 SOA 组件需要如下几个步骤：

  1. 卸载老的 SOA 组件。
  2. 重启服务器：让服务器重新加载所有新的配置，避免由于某些重要的资源没有重新加载而导致新的服务组件验证失败。
  3. 安装新的 SOA 组件。
  4. 配置 J2C 认证条目。

下面将分别介绍以上几个步骤 Jython 和 Jacl 脚本的编写方法。

卸载旧 SOA 组件：

使用脚本卸载 SOA 组件相当简洁，只需指定要卸载的应用程序名称而不是企业归档（EAR）文件的名称。

使用 Jacl：

$AdminApp uninstall Department
$AdminConfig save

使用 Jython：

AdminApp.uninstall(‘Department')
AdminConfig.save()

其中：

$ 是使用其值替换变量名的 Jacl 运算符
AdminApp 是支持应用程序对象管理的对象
uninstall 是 AdminApp 命令
Department 是要卸载的应用程序名称

在执行所有的更改操作后都必须执行 save 命令保存。

卸载应用程序从 WebSphere Application Server 配置和安装了该应用程序的所有服务器中除去此应用程序。从安装目录删除应用程序二进制文件（EAR 文件内容）。当为单服务器 Application Server 版本保存配置时，或当为 Network Deployment 配置将配置更改从 Deployment Manager 同步到单个节点时会发生这种情况。

重新启动服务器：

一个企业级的 IT 系统需要很多复杂的配置，如果只是替换掉旧的 SOA 组件并不能保证系统所有的配置都是最新，为了保证系统的一致性一般会卸载 SOA 组件后重启服务器。用 wsadmin 重启服务器的方法就是分别调用 stop 和 start 命令。

使用 stopServer 命令停止服务器。此命令有若干语法选项。例如：

要停止 WebSphere Application Server Network Deployment 修订版上的服务器，可以在用如下的方法。

以下示例指定服务器名和节点名：

使用 Jacl：

$AdminControl stopServer serverName nodeName

使用 Jython：

AdminControl.stopServer('serverName', 'nodeName')

要在 WebSphere Application Server Network Deployment 修订版上启动服务器，可以在用如下的方法。

以下示例指定服务器名和节点名：

使用 Jacl：

$AdminControl startServer serverName nodeName

使用 Jython：

AdminControl.startServer('serverName', 'nodeName')

安装新 SOA 组件

安装的应用程序必须是企业归档（EAR）文件、Web 归档（WAR）文件、servlet 归档（SAR）文件或 Java 归档（JAR）文件。归档文件必须以 .ear、.jar、.sar 或 .war 结束，以便 wsadmin 工具能够安装此归档文件。wsadmin 工具使用这些扩展名来判定归档类型。如果文件是 WAR 或 JAR 文件，它将自动合并为 EAR 文件。

如果要安装指定 AdminApp useMetaDataFromBinary 选项的应用程序，那么只能在 WebSphere Application Server V6.x 部署目标上安装此应用程序。这还适用于在安装应用程序后，使用 AdminApp edit 命令对其进行编辑。如果使用 V5.x wsadmin 工具在 WebSphere Application Server V6.x 单元上安装或编辑应用程序，将只显示 V5.x wsadmin 工具可以使用的步骤。

执行以下步骤以将应用程序安装到运行环境：

  1. 确定在配置中安装应用程序时使用的选项。

    例如，如果配置包含节点、单元和服务器，那么在输入 install 命令时可以指定该信息。检查 AdminApp 对象的 install、installInteractive、edit、editInteractive、update 和 updateInteractive 命令的选项主题中 install 和 installinteractive 命令的有效选项列表，以找到 -node、-cell 和 -server 选项的正确语法。对于此配置，Jacl 命令是：

    $AdminApp install "location_of_ear.ear" {-node nodeName -cell 
 cellName -server serverName}

    还可以使用 options 命令获取企业归档（EAR）文件支持的选项列表，例如：

    使用 Jacl：

    $AdminApp options

    使用 Jython：

    AdminApp.options()
  2. 选择使用 install 或 installInteractive 命令来安装应用程序。

    可使用 install 命令以批处理方式安装应用程序，或可使用 installinteractive 命令以交互方式安装应用程序。交互方式通过一系列任务提示您提供信息。install 命令和 installinteractive 命令支持先前步骤中选择用于安装的选项集。

  3. 安装应用程序。对于本示例，仅将 server 选项与 install 命令一起使用，其中 server 选项的值是 serv2。使用基于配置选择的选项来定制 install 或 installInteractive 命令。

    使用 install 命令以批处理方式安装应用程序：（仅限于 Network Deployment 安装）以下命令使用 EAR 文件和命令选项信息来在集群中安装应用程序：

    使用 Jacl：

    $AdminApp install "c:/SOADemo/Department.ear" {-cluster cluster1}

    使用 Jython 列表：

    AdminApp.install('c:/SOADemo/Department.ear ', ['-cluster', 'cluster1'])

    使用 Jython 字符串：

    AdminApp.install('c:/SOADemo/Department.ear ', '[-cluster cluster1]')

    使用 installInteractive 命令以交互方式安装应用程序。下列命令提示您通过一系列安装任务来更改应用程序信息：

    使用 Jacl：

    $AdminApp installInteractive "c:/SOADemo/Department.ear"

    使用 Jython：

    AdminApp.installInteractive('c:/SOADemo/Department.ear')
  4. 保存配置更改。

    使用 Jacl：

    $AdminConfig save

    使用 Jython：

    AdminConfig.save()

    如果系统成功安装应用程序，那么此任务中的步骤将返回成功消息。安装大型应用程序时，该命令可能会在系统解压缩每个二进制文件前返回成功消息。在系统解压缩所有二进制文件后，才能启动应用程序。如果安装了大型应用程序，请在启动应用程序前使用 AdminApp 对象的 isAppReady 和 getDeployStatus 命令来验证系统是否已解压缩二进制文件。

    如果系统已准备好，可启动应用程序，那么 isAppReady 命令将返回值 true；如果系统未准备好，无法启动应用程序，那么返回值 false，如以下示例所示：

    使用 Jython：

    AdminApp.isAppReady('Department')

    使用 Jacl：

    $AdminApp isAppReady Department

    如果系统未准备好，无法启动应用程序，那么系统可能正在展开应用程序二进制文件。使用 getDeployStatus 命令来显示有关二进制文件展开状态的更多信息，如以下示例所示：

    使用 Jython：

    AdminApp.getDeployStatus('Department')

    使用 Jacl：

    $AdminApp getDeployStatus Department

配置新的 J2C 认证数据条目：

配置 J2C 认证的过程比以上步骤复杂一些，需要脚本完成如下几个步骤 :

  1. 识别父标识：

    使用 Jacl：

    set security [$AdminConfig getid /Cell:mycell/Security:/]

    使用 Jython：

    security = AdminConfig.getid('/Cell:mycell/Security:/')
print security

    示例输出：

    (cells/mycell|security.xml#Security_1)
  2. 获取必需的属性：

    使用 Jacl：

    $AdminConfig required JAASAuthData

    使用 Jython：

    print AdminConfig.required('JAASAuthData')

    示例输出：

    Attribute Type
alias String
userId String
password String
  3. 设置必需的属性：

    使用 Jacl：

    set alias [list alias myAlias]
set userid [list userId myid]
set password [list password secret]
set jaasAttrs [list $alias $userid $password]

    示例输出：

    {alias myAlias} {userId myid} {password secret}

    使用 Jython：

    alias = ['alias', 'myAlias']
userid = ['userId', 'myid']
password = ['password', 'secret']
jaasAttrs = [alias, userid, password]
print jaasAttrs

    示例输出：

    [['alias', 'myAlias'], ['userId', 'myid'], ['password', 'secret']
  4. 创建 JAAS auth 数据：

    使用 Jacl：

    $AdminConfig create JAASAuthData $security $jaasAttrs

    使用 Jython：

    print AdminConfig.create('JAASAuthData', security, jaasAttrs)

    示例输出 

    (cells/mycell|security.xml#JAASAuthData_2)
  5. 保存配置更改。
  6. 仅在 Network Deployment 环境中使节点同步。

验证安装

当脚本执行完之后，我们应该验证整个自动化过程是否成功，一般来说有两种方式：

1. 查看 log 日志 : 让所有控制台的输出全部重定向到文件系统中，通过控制台输出可以检查是否所有自动化脚本都成功执行。

2. 查看 console 页面：需要逐个检查欲配置的页面，比如我们要在 console 中查看要安装的 Application 是否成功：

图 2.7 应用安装成功

查看其它的自动化步骤是否成功就需要切换到相应的 console 中。

总结

本章主要介绍了 SOA 环境下如何自动化部署测试环境，这些自动化技术都是 IBM SOA 相关技术部门多年实践经验的结晶，在实际的项目中起到了非常重要的作用。本系列下一篇文章将介绍如何自动执行测试用例。

本系列文章的 第一部分 介绍了如何自动安装部署 SOA 的测试环境； 第二部分 介绍了 SOA 组件的自动化部署。本部分将着重介绍将 SOA Build 自动部署完成之后，如何进行 SOA 的自动化测试。

介绍

对于 SOA 的功能测试我们要分三层的测试：第一层是用 RFT（Rational Functional Tester）进行 UI 界面层的测试；第二层和第三层是用 Junit 进行 Business Process 层和 Service 层的测试。性能测试方面，用 RPT（Rational Performance Tester）进行 UI 界面层的测试，而 RPT for SOA 用 Business Process 层和 Service 层的性能测试

UI 界面层的自动化测试用例

（1）用 RFT 来录制的 UI 层的测试用例脚本。

使用 RFT 开发自动化测试脚本的过程大致是：录制对象映射，使用对象映射对 GUI 对象进行操作从而完成自动化测试。

图 3.1 RFT 流程图

　

（2）使用 RFT UI 测试框架来编写测试脚本。

有了这套框架可以为你的自动化测试项目提供以下帮助：

  • 加速脚本编写；
  • 快速调试以及易于维护；
  • 代码重用；
  • 很好的组织脚本文件；
  • 帮助协作；
  • 从他人经验得到益处；

这套框架由以下三个部分组成：通过 Appobjects，Tasks 以及 Testcases 来实现三层架构；ibm 工具包；以及配套的最佳实践。

Appobjects 用于存储关于应用程序 GUI 元素的信息。在 appobjects 里面你将写一些 getter 方法，这些 getter 方法返回对象给调用者，这些对象将用于查询和操作 GUI 元素。一般，这些 getter 方法将在 tasks 层调用。

Tasks 用于写一些可重用的方法，这些方法将对应用程序执行一些操作。如果需要操作和查询复杂的特定于某应用程序的控件，也可以写在 tasks 的方法中。Tasks 包里的方法将被 testcases 调用。

Testcases 便是最终的测试用例。它们将操作应用程序、验证其状态以及记录下结果。

（3）使用 RPT ( Rational Performance Tester) 来录制自动化测试用例脚本。

Rational Performance Tester（简称 RPT）是 IBM 基于 Eclipse 平台及开源的测试及监控框架 Hyades，开发出来的最新性能测试解决方案，总体架构如图一所示。它可以有效地帮助测试人员和性能工程师验证系统的性能，识别和解决各种性能问题。它适用于性能测试人员和性能优化人员，用于开发团队在部署基于 HTTP 和 HTTPs 通信协议的 Web 应用程序前，验证其可扩展性、性能和可靠性。

Business Process 和 Service 层自动化测试用例

在 Business Process 和 Service 层，业务接口通常以 SCA 或 Web Service 的接口暴露出来。在功能测试阶段，有很多编写测试用例的工具，这里我们使用 JUnit 来编写测试用例脚本。JUnit 是一个易用的，灵活的，开源的，测试平台。就像所有其他项目一样，它有很多优点，但也有不足之处。通过使用无需人工干预的 JUnit 自动测试平台，我们很容易累积起大量的 JUnit 测试程序从而保证以往的错误不会重现。另外，JUnit 便于和编译单元（如，Ant）以及 IDE 单元（如，Eclipse）集成。JUnit 中有两个基本对象，TestCase 和 TestSuite。TestCase 通过提供一组方法来实现一系列测试。例如，setup() 方法用来在每项测试开始前建立测试所需的测试环境，而 teardown() 方法用来在测试后销毁该环境。TestSuite 是由几个 TestCase 或其他的 TestSuite 构成的。你可以很容易的构成一个树形测试，每个测试都由持有另外一些测试的 TestSuite 来构成。被加入到 TestSuite 中的测试在一个线程上依次被执行。

在性能测试阶段，我们使用 RPT for SOA（Rational Performance Tester for SOA）来编写调用服务的脚本。

RPT for SOA Extension 根据 WSDL 进行语法解析，生成参数输入界面。测试人员可输入测试数据，RPT Recorder 会捕获到进行 Web Service 通信的协议内容，并记录到脚本中（如图 3.2）。

图 3.2 RPT for SOA 界面图

自动化测试用例执行脚本介绍

本文的第二部分介绍了测试 build 的自动卸载和安装部署。本部分介绍在新的 build 自动安装部署完成后，自动执行测试用例并将测试结果发给相关人员。

若要实现测试用例的自动执行，需要在第二部分中的 buildToTest.py 文件中添加四个重要任务：

  1. 判断 Build 是否安装成功

    系统获取服务器 profile 下的 \config\cells\localhostNode03Cell\applications 中已安装的 ear 文件，判断是否所有应该安装的 ear 文件都在其中，并且判断这些文件的 Date Modified 时间是否是当天。若从该文件夹下查询到所有的 ear 文件，说明新 Build 已成功安装。

  2. 执行测试用例并且获取测试结果

    在测试用例完成后，编写一个 Servlet 调用本 Junit 编写的测试用例。系统通过 

    sock=urllib.urlopen("http://localhost:9082/cbs.service.test.web/CBSServiceTestRunner? 
|--10--------20--------30--------40--------50--------60--------70--------80--------9|
|-------- XML error:  The previous line is longer than the max of 90 characters ---------|
suite=com.ibm.cbs.service.test.suite.CBSServiceSuite&xsl=cactus-report.xsl")

    测试用例被执行并且将结果按照 cactus-report.xsl 的格式组织。获取测试结果后，系统将结果写入 ServletTestRunner.xml 文件中。

    htmlSource = sock.read() 
sock.close() 
resultfile=open(top_dir+'/BuildScript-CMI-Service/ftp/'+currentTime+
                   '/ServletTestRunner.xml', 'w') 
resultfile.write(htmlSource) 
resultfile.close()
  3. 发送邮件

    系统调用 sendEmail.bat 将测试结果发送给相关人员。

    os.putenv('bvt_ir','OK')
sendEmail = os.system(os.path.join(top_dir, "BuildScript-CMI-Service", "sendEmail.bat"))
|--10--------20--------30--------40--------50--------60--------70--------80--------9|
|-------- XML error:  The previous line is longer than the max of 90 characters ---------|

    sendEmail.bat：

    call C:\Apache\apache-ant-1.6.2\bin\ant.bat -Dbvt.ir=%bvt_ir% -logfile sendEmail.log 
-buildfile C:\BuildScript-CMIV1R3\BuildScript-CMI-Service\otherTargets.xml send-mail
  4. 若 Build 并未安装成功，则发送错误信息邮件给相关人员。 
    call C:\Apache\apache-ant-1.6.2\bin\ant.bat -logfile sendErrorEmail.log -buildfile
 C:\BuildScript-new\ICMS-CBS_Merge-Service\otherTargets.xml send-error-mail

    otherTargets.xml 中定义了 send-mail 和 send-error-mail 的格式和内容 

    <target name="send-mail">
	<tstamp>
		<format property="build.time" pattern="yyyyMMddHH" locale="en"/>
	</tstamp>
	<mail mailhost="xxx.xxx.xxx.xxx" subject="Daily Build Announcement For CMIV1R3 
	  ${build.time}" 
	tolist="xxx@cn.ibm.com,xxx@cn.ibm.com,xxx@cn.ibm.com"		 
	 messagemimetype="text/plain">
		<from address="xxxx@cn.ibm.com"/>
		<replyto address="xxxx@cn.ibm.com"/>
<message>Hi All,
The build summary is as below,
Ear Name		 Build Status BVT Status 
xxx.xxx.xxx.xxx.ear Okey ${bvt.ir}
xxx.xxx.xxx.xxx.ear Okey ${bvt.ir}
…..
Pls. kindly find the daily build and bvt results as below,
	http://xxx.xxx.xxx.xxx/ICMS/CMIV1R3/${build.time}
	http:// xxx.xxx.xxx.xxx /ICMS/CMIV1R3/${build.time}/ServletTestRunner.xml
	
Best Regards
</message>
</mail>
</target>

统计执行结果

ServletTestRunner.xml 中统计了测试结果 :

图 3.3 Service 层功能测试结果

测试结果中统计了测试用例的数目，执行失败的用例数目，成功执行的测试用例的百分比，和执行用例所消耗的时间。测试人员可以根据总结报告查询执行失败的测试用例。

总结

本文介绍了 SOA 的自动化测试的框架。这个自动执行测试用例的框架也可以调用其它语言脚本编写的测试用例。此框架大量节约了测试人员的时间，实现了 SOA 的自动化测试。


火龙果软件/UML软件工程组织致力于提高您的软件工程实践能力，我们不断地吸取业界的宝贵经验，向您提供经过数百家企业验证的有效的工程技术实践经验，同时关注最新的理论进展，帮助您“领跑您所在行业的软件世界”。
资源网站: UML软件工程组织