IBM Rational Tester for SOA Quality 将面向服务架构(service-oriented
architecture,SOA)的应用程序的功能和回归测试的创建、执行,及分析进行了自动化。IBM Rational Performance
Tester Extension for SOA Quality 为那些同样的 SOA 应用程序提供性能测试能力。本文介绍了两种产品的一些基本功能,并且展示了一个测试
Web 服务的真实实例。
作者的提示:
本文利用了 IBM® Rational® Performance Tester Version 7.0.0、IBM®
Rational® Tester for SOA Quality Version 7.0.0 Open Beta、Microsoft®
Windows® 2000 Professional SP2,和在本文最初发表时可用的 Google Web API。
Rational Tester for SOA Quality 是 Rational Performance Tester 的扩展。如果您不熟悉它,花点时间了解它的基础知识将带来帮助,因为本文不包含如何使用该软件。要了解更多关于使用
Rational Performance Tester 的信息,请参阅参考资源中包含的链接。
当您开始时,您要用您的 Java™ Message Service(JMS)或 Simple Object Access
Protocol(SOAP) Web 服务所需的库和配置文件来设置您的测试环境。对于此实例,您将导入要测试的 Web 服务所需的
Web 服务描述语言(Web Services Description Language,WSDL)的定义文件。如果您需要,您还可以导入安全认证,并且用对于
Web 服务调用和消息返回的安全算法来创建 SOAP 安全认证。
在您记录您的第一个测试之前,您的工作平台中将需要一个 WSDL 文件。对于本文,您将使用 Google Web API 来测试
Google Spelling Suggestion。为了向您的工作平台添加 WSDL 文件,您将使用 Web Services
Explorer,它是一个便利的小工具,您将发现您使得相当多。
向您的工作平台添加 WSDL 文件有许多方法,但最简单的方法是使用 Web Services Explorer。要启动 Web
Services Explorer:
- 在 Menu 中,选择 Run > Launch the Web Services Explorer(参见图
1。)
图 1. 启动 Web Services Explorer
- 这样就打开了 Web Services Explorer,如图 2 所示。
图 2. Web Services Explorer
- 在右上角选择 WSDL Page 按钮,如图 3 所示。
图 3. WSDL Page 按钮
- 在 Web Services Explorer Navigator 视图中,选择 WSDL Main
元素。这将显示出 Open WSDL 操作(参见图 4。)。
图 4. 选择 WSDL Main 来打开 Open WSDL 操作视图
- 在 WSDL URL 字段中,输入到您想要测试的 Web 服务的 URL。举例来说,使用
http://api.google.com/GoogleSearch.wsdl 。当您输入完
URL 之后,选择 Go。(参见图 5。)
图 5. WSDL Binding Details 屏幕
当 WSDL 绑定细节加载之后,您应该看到 Operations(doGoogleSerach、doSpellingSuggestion,和
doGetCachedPage)和 Endpoints(http://api.google.com/search/beta2)。在
Status 视图中,您还应该看到“... was successfully opened”消息。
现在您有了新的 WSDL 页,您需要测试它。测试将会告诉您是否在您的环境中正确地配置了所有东西。您的 WSDL 文件可能有您需要处理的安全设置,或者您可能需要在您的配置设置中配置代理信息,或者可能引起许多其他的可能的困难。这样,您就在记录第一个测试之前知道一切都在运转。要测试您的服务:
- 单击 Actions 视图中的 doSpellingSuggestion 链接(参见图 6。)。
图 6. 调用 WSDL 操作
这样做打开了 Actions 视图下的 Invoke a WSDL Operation 窗格。有两种进行此操作的方法。一个是
Form 视图(您刚在图 6 中见到的视图),另一个是显示 XML 代码的 Source 视图。要在视图间切换,单击 Actions
视图左上角的 Source 链接。您可以来回切换,使用您最喜欢的,或手边任务需要的视图。举例来说,使用 Form
视图。
注意:
Google API 需要许可证号,您可以在帐户注册区创建。
- 输入您的 Google 授权号,以及您想要拼写检查的短语。当您输入完该信息时,单击 Go。(参见图 7。)
图 7. 输入操作参数
在您调用 Web 服务时,您将看到屏幕底部的进度条。当结果返回时,您将在 Status 视图中看到,如图 8 所示。(您还可以在该视图中的
Source 和 Form 格式之间切换。)
图 8. Source 视图中 Google 拼写检查的结果
- 现在您知道您的 Web 服务可以工作,那么将其添加到您的工作平台。要这样做,就在 Web Services Explorer
Navigator 视图中,选择 root WSDL node for the Google API。这将显示出如图
9 的 WSDL Details 视图。
图 9. 查看 WSDL 细节
- 在 Actions 视图的右上角,选择图 10 中所示的 Import WSDL to workbench
按钮。这将打开 Import WSDL to workbench 操作。
图 10. 选择 Import WSDL to workbench 的按钮
- 选择您的工作平台项目,选择 Import WSDL document 复选框,输入
WSDL
文件名 ,并选择 Go。(参见图 11。)
图 11. 将 WSDL 文件导入您的工作平台
在 Status 视图中,您应该看到确认消息。(参见图 12。)
图 12. WSDL 文件导入成功的消息
在 Test Navigator 视图中,您应该看到添加到您所选择的项目下面的 WSDL 文件。(参见图 13。)
图 13. 确认将 WSDL 文件导入到 Test Navigator 中
现在您的工作平台中有了一个可以用于测试的工作的 Web 服务。接下来,您将了解如何利用 Rational Tester for
SOA Quality 记录新的测试。
您通过记录 Web 服务调用和返回消息来创建您的测试(类似于您上面做的)。您可以通过 HTTP 代理,一个生成的 Java™
测试客户端,或含有 API 探针的现有的 Java 客户端来实现。当您开始记录时,您通过生成调用来与 Web 服务交互。当您登出时会话结束。所记录的会话是一系列调用和消息返回。您还可以手工地创建
Web 服务,或者由 Business Process Execution Language(BPEL)模型创建。
在此处的实例中,没有这样的问题,但是对于其他 Web 服务来说,必须设置您的测试环境,并且在您测试之前了解这些指导,从而生成可靠的测试:
- 为 JMS Web 服务的测试配置环境: JMS 协议需要访问服务器所依赖的库。您必须准备带有这些库的环境来构建大
JMS 客户端,设置工作平台使用的虚拟机的 class path,并设置 Agent Controller 使用的虚拟机的
class path。
- 为 SOAP 安全配置环境: SOAP 安全协议需要访问实现 SOAP 安全算法的库。您必须准备带有这些库的环境来使用
SOAP 安全,设置 Eclipse 使用的虚拟机的 class path,并设置 Agent Controller 使用的虚拟机的
class path。
- 为 JMS Web 服务验证 WSDL 语法顺应性:各种各样的 JMS 提供者所使用的描述 Web 服务的语法各有不同。在测试
JMS Web 服务之前,您必须确保您的 WSDL 文件顺应工具的需求。
在完成这些设置之后,有五种创建测试的方法:
- 利用 Web Services Explorer 来记录 Web 服务测试:您可以通过 HTTP 代理记录
Web 服务测试。当您记录时,HTTP 代理(位于本地计算机上)将记录发生在工作平台 Web Services Explorer
和 Web 服务之间的所有的消息调用和消息返回。
- 通过装置 Java 客户端来记录 Web 服务测试:您可以通过装置现有的 Java 独立客户端的源代码来记录
Web 服务测试。当您记录时,记录器将 API 探针源代码加入 Java 客户端的源代码中。当您运行客户端时,API 探针记录发生在客户端和
Web 服务之间的所有的消息调用和消息返回。客户端的原始源代码没有修改。
- 利用 HTTP 代理记录 Web 服务测试:您可以通过专用的 HTTP 代理记录 Web 服务测试。当您记录时,代理侦听
Java 独立客户端和 Web 服务之间的 Web 服务调用和消息返回。
- 由 BPEL 模型创建 Web 服务测试:您可以使用来自工作平台的 Business Process Execution
Language 资源来自动化地生成一组符合 BPEL 模型中执行的路径的 Web 服务测试。
- 手工地创建 Web 服务测试:您可以在不记录的情况下创建 Web 服务测试,您可以仅仅按照需要添加测试元素,并且手工地在测试编辑器中编辑测试元素细节。
下一个实例介绍了利用 Web Services Explorer 记录 Web 服务测试。(同样参见图
14。)
- 在 File 菜单或工具栏中选择 Create New Test From Recording。
- 在 Create New Test From Recording 对话框中,选择 Web Service
Recording using the Web Service Explorer,然后选择 Next。
图 14. 利用 Web Services Explorer 记录
- 为测试集选择 location 并为测试集
enter a name 。选择 Next。(参见图
15。)
图 15. 为测试集选择位置
- 下一个对话框列出了您记录可以依据的 WSDL 文件。当前没有文件列出,因此选择 Add(参见图 16。)。
图 16. 向您的资源列表中添加 WSDL 文件
- 这样做打开了工作区对话框中的 WSDL 资源。选择 GoogleSearch WSDL,然后选择 OK。(参见图
17。)
图 17. 在您的工作区中选择 WSDL 文件
- 您现在应该看到列出了 WSDL 文件。选择 Next。参见图 18。
图 18. 从资源列表中选择 WSDL 文件
- 为测试输入任意端口、超时时间,或代理设置,并选择 Next。(参见图 19。)
图 19. 输入端口和代理设置
- 阅读 Privacy Warning,单击 I accept 复选框,并选择 Finish。(参见图
20。)
图 20. 接受 Privacy Warning
当您单击 Finish 时,将出现一些不同的东西。首先,测试记录器将初始化。在部署和启动记录器文件的同时,您应该看到
Initializing Recording 对话框(参见图 21。)。
图 21. 初始化记录器
当记录器启动时,您将在屏幕右下方看到 Recorder Control 视图。它将告诉您记录器正在监听的地方,并且包含了您完成时要用的
Stop Recording 按钮(参见图 22。)。
图 22. Recorder Control
Web Services Explorer 将打开来自工作平台的 WSDL 页(参见图 23。)。
图 23. 对于 WSDL Binding Details 操作的 Web Services
Explorer 打开了
在此,您正在记录。继续运行您想要记录的任意测试。当在 Web Services Explorer 中测试 WSDL 文件时,您可以按照前面的同样方式进行:
- 选择您想要使用的操作,填充表单,并单击 Go。您将知道您的测试正在被记录,因为每次您调用时,Recorder
Control 中将记录一个事件。
- 当您完成时,单击 Recorder Control 视图中的 Stop Recording 按钮,在生成您的测试时
Performance Test Generator 将显示出来。(参见图 24。)
图 24. 测试生成过程完成了
当测试生成过程完成之后,测试集将在 Test Editor 视图中打开。现在您将准备对您的测试进行变更。
在记录之后,您可以在测试中编辑调用和消息返回。您可以用各种测试数据来代替所记录的测试值,或者向测试中添加动态数据。您还可以为消息返回中的
XML 文档的内容设置验证点。
变更 Test Element 细节
在测试中可以变更的项比本文中介绍的多,而这里是一些基本的:
如果您选择了 Test Element Details 中的一个测试元素,那么会默认显示出 Overview
选项卡。(参见图 25。)
图 25. Test Element Details 中的 Overview 选项卡
在 Test Element Details Overview 选项卡上,您应该注意到了 Time Out and
Think Time。
- Time Out 是用毫秒表示的超时值。如果在指定时间之后没有收到响应,将产生错误。
- Think Time 指定当测试由多个虚拟用户运行时,对于每个用户观测的程序性计算的时间延迟。Think
Time 是实际用户在执行操作之前阅读或思考所花费的时间总量的统计仿真。
注意:
如果您想要变更这些字段的默认值,那么您可以单击 Window > Preferences > expand Test
> expand Performance Test,然后单击 Web Service Test Generation。当变更设置之后,单击
Apply。
如果您查看其他视图,那么Source 视图允许您查看该调用的源 XML 文档。Source 页显示的 ID 标签指的是测试的内部表示。如果您去掉这些标签,那么您将去掉所有现有的引用和替换。在删除了之后,您就不能重新创建这些标签了。
Detailed 视图提供了调用元素的详细树型视图。Attributes 和 Namespaces
选项卡可以让您通过 Add、Edit,和 Remove 按钮编辑元素属性和命名空间。Attachments 视图列出了所有附属于调用的
MIME(Multipurpose Internet Mail Extensions)附件。
当您查看这些各种各样的选项卡时,您将看到一些绿色的值。绿色的值是可能的数据池候选。下面的部分 Adding dynamic
data to a Web service test(向 Web 服务测试添加动态数据) 中将介绍更多数据池的信息。
验证应用程序行为
要在 Web 服务测试过程中查看应用程序的预期行为,您可以在消息返回之后添加验证点。当您添加验证点时,来自 Web 服务消息返回的结果将与验证点测试元素中指定的预期数据进行比较。在执行过程中,验证点在
Web Service Verification Point 报告中生成 Pass、Fail、Error,或 Inconclusive
状态。
这里有您可以添加的三种类型的验证点:
- Equal(相等) 或 contain(包含) 验证点
- XPath 查询验证点
- Attachment(附件)验证点
添加 equal(相等) 或 contain(包含) 验证点
Web 服务 equal(相等) 或 contain(包含) 验证点能使您验证消息返回的内容与预期的标准是否匹配。相等或包含验证点能使您直接比较
Web 服务返回的 XML 文档。像 IBM® Rational® Functional Tester 和 Rational
Performance Tester 一样,Rational Tester for SOA Quality 还支持这种验证点的正则表达式。
添加 XPath 查询验证点
Web 服务查询验证点能使您验证消息返回与 XPath 查询是否匹配。XPath 是用于在 XML 文档中寻找信息的语言,因此它可以用于通过
XML 文档的元素和属性定位。查询验证点能使您验证 XML Path 语言查询所返回的节点数量与验证点中指定的预期节点数量是否匹配。参考资料中有关于创建
XPath 表达式的参考。
添加附件验证点
Web 服务附件验证点能使您验证 Web 服务消息返回的附件与指定的标准是否匹配。附件验证点能使您验证预期的附件是否被消息返回传递。当所有附件标准都与验证点测试元素中指定的预期标准匹配时,附件验证点将返回
Pass 状态。如果所有标准都不匹配,验证点返回 Fail 状态。
您可以在 Rational Tester for SOA Quality 的 Help 文件中找到关于每种验证点的更多信息。
向 Web 服务测试添加元素
您可以向测试中添加各种元素,例如 Web 服务调用、消息返回、注释、循环,或条件。举例来说:
- 您可以在测试中使用 Web 服务调用元素向 Web 服务发送请求。
- 您可以使用 Web 服务消息返回元素接收 Web 服务调用的结果。
- 您可以在测试的部分中插入
IF-THEN 逻辑,从而只在满足具体条件时运行那些部分。
- 您可以将测试的一部分定义为运行指定次数的循环。
transaction(事务)是您会感兴趣的,一组特殊的测试元素中的执行元素。事务可以包含 Web 服务测试元素或其他事务。
要向 Web 服务测试中添加元素,您可以右键单击 Test Contents 中的根元素,并选择 Add,或者您可以右键单击任意请求元素,并单击
Insert(参见图 26。)
图 26. 向 Web 服务测试添加元素
您可以在 Rational Tester for SOA Quality 的 Help 文件中找到关于每种元素的更多信息。
向 Web 服务测试添加动态数据
Web 服务协议数据视图能使您查看形成 Web 服务调用和消息返回的 XML 文档。它还允许您在测试执行之后比较预期的和实际的
XML 数据。如果您导航到 Test Element Details 中的 Detailed 视图,那么您可以为请求中包含的每个值添加数据替换。
如果您右键单击想要替换的值,并选择 Substitute From,您就可以从 Datapool Variables
和 Built-in Datasources 中选择(参见图 27。)
图 27. 替换测试中的动态数据
当您选择 root test 元素时,Test Element Details 中的 Common
Options 视图中列出了可用的数据池。您可以在此关联数据池,或者您可以在进行替换时关联它们。您可以在 IBM Rational
Performance Tester 和 Rational Tester for SOA Quality 的 Help 中找到关于添加动态数据的更多信息。
Rational Tester for SOA Quality 是功能回归测试工具。要用一个用户快速运行您的测试,您所需的就是右键单击测试集,选择
Run As,然后选择 Performance Test。(参见图 28。)
图 28. 用一个用户运行您的测试
Rational Performance Tester Extension for SOA Quality 只是 Rational
Tester for SOA Quality 的扩展,它能够使您通过在多用户仿真环境中回放相同的测试来估计您的 SOA 和 Web
服务的性能。您用 Performance Schedules 来仿真工作负载。然后就像您执行其他 Rational Performance
Tester 测试一样执行那些进度。您的测试可以重复运行,您可以指定执行进度和用户组来仿真由大量虚拟用户所生成的工作负载。
一旦您拥有了那些进度,您就可以把测试执行部署到可以寄存在远程计算机上的虚拟用户上。每个虚拟用户执行测试客户端的一个实例。测量并记录响应时间。核对并记录验证点。
您通过在执行过程中生成的各种报告来评估测试所产生的结果。您还可以设计定制的报告。您可以看到的默认报告是 Overall
Web Service Performance Report。该报告本质上过分简化了。对于本示例测试,它真的只是百分比完成指示器。然而,如果您翻到图
29 中所示的 Summary Web Service Performance Report 中,您将看到更多的详细信息。
图 29. Summary Web Service Performance Report
在此报告中,您会看到多少用户完成了,测试执行了多久,执行了多少调用,以及多少调用成功了。如果您有验证点,那么在此将显示出那些测试的摘要信息,以及图
30 中的内容。
图 30. Call Summary with verification points
另一个可用的 Web Service Performance 报告在此环境中没有多大意义,因为这些测试实例很简单,并且这些测试只基于一个用户。然而,有其他报告需要您审阅。如果您右键单击您执行的性能测试,您就可以显示出此次执行的测试日志。(参见图
31。)
图 31. 显示出此次性能测试执行的测试日志
在测试日志中,您可以看到测试执行时使用的所有公共的属性,您可以看到所执行事件的详细列表,并且您可以深入到每个事件的详细属性。如果您有一个失败的验证点(参见图
32。),那么您可以查看该验证点的高级属性、实际的和预期的结果,和(如果您集成了 IBM® Rational®
ClearQuest®)与验证点相关的所有缺陷。如果必要还可以添加缺陷。
图 32. 查看测试日志中的验证点失败
要查看验证点的详细信息,使用 Web Service Protocol Data 视图,如图 33 所示。在该视图中,您可以看到返回的消息信封和验证点中的详细信息。
出于某个原因,该视图默认不显示出来,因此您可能需要选择 Window > Show View > Other,,并在
Show View 窗口中,选择 Test > WS Protocol Data 来打开它。
本文从初学者的角度介绍利用 IBM Rational Tester for SOA Quality 和 IBM Rational
Performance Tester Extension for SOA Quality 进行服务测试。如果您完全不了解 SOA
和 Web 服务测试,那么您还将得益于花些时间阅读并学习 XML、Web 服务,和 Rational Performance Tester
的基础知识。下面的参考资料部分中的链接将帮助您入门。
学习
获得产品和技术
讨论
|