内容


使用 Rational Performance Tester Extension for SOA Quality 来测试 IBM Rational Quality Manager REST API

使用 RPT SOA 的通用服务客户端、测试编辑器与测试日志来与 RQM 的 REST API 交互

Comments

引言

IBM® Rational® Quality Manager 是一种用来管理质量保证团队项目的测试管理与质量管理工具。它建立在 IBM Rational Jazz™ 平台的基础之上,并继承了其 Representational State Transfer (REST)功能和基于 Rational Jazz 格式的机理。通过 REST API 对 Rational Quality Manager 服务器的负载测试,最好使用 IBM Rational Performance Tester Extension for SOA Quality 来完成。但是,这种方式的测试由于以下的几个原因可能会很困难:

  • SOA 质量扩展并没有为 Jazz 认证机理提供内构型的支持。
  • 记录 Rational Quality Manager 与 SOA 质量扩展 HTTP 代理记录器之间的会话,会生成复杂的测试场景,它会很难理解和处理。

本文中所描述的最佳操作,包括使用通用服务客户端来与 Rational Quality Manager 提供的 RESTfull Web 服务交互,以及生成不复杂且使用方便的测试场景。

本文的写作背景是 IBM Rational Quality Manager 2.0.0.1 iFix003 标准版本与 IBM Rational Performance Tester 对于 SOA Quality 8.1.1 的扩展版。

Jazz 验证机理与测试下的服务

为了对 Rational Quality Manager 构建一个简单的负载测试,您必须验证 Rational Quality Manager 服务器。Rational Quality Manager 使用基于 Jazz 格式的用户验证方案。

https://jazz.net/wiki/bin/view/Main/JFSCoreSecurity#User_Authentication 处对这个方案进行了描述。在 https://jazz.net/wiki/bin/view/Main/WritingAJazzClient 处对 IBM Rational Jazz Team Server 上的方案进行描述。

简单来说,客户端必须得到认证,以获得来自服务器的会话 ID,然后使用该 ID 作为所有对服务器随后响应的 cookie。您可以使用通用服务客户端来获得会话 ID。

这里您所交互的 Rational Quality Manager 服务会处理管理测试用例的问题。Rational Quality Manager 发布了大多数其工件的 XML 代表,包括测试用例,通过 URL 与以下地址类似的 Atom feed 来进行发布:

https://rqmserver:9443/jazz/service/
com.ibm.rqm.integration.service.IIntegrationService/testcase

其中 rqmserver 是您的 Rational Quality Manager 服务器或者 IP 地址。

对于后续的步骤,您需要拥有 Atom 所发布的测试用例的 URL。

图 1. Rational Quality Manager 测试用例 feed
feed 所显示的两个测试用例
feed 所显示的两个测试用例

接下来的工件可以使用各种 REST 命令来查询:

  • 使用 GET 来获得 XML 表达式。
  • 使用 POST 来创建工件。
  • 使用 PUT 来编辑工件。
  • 使用 DELETE 来删除工件。

使用通用服务客户端来验证 Rational Quality Manager 服务器

按照以下方法来验证 Rational Quality Manager 服务器:

  1. 在 Performance 视图中,使用 ad-hoc 工具栏按钮来打开通用服务客户端:
图 2. 打开通用服务客户端
通用服务客户端工具栏按钮
通用服务客户端工具栏按钮

Services 页面显示了 Web 服务描述语言 (WSDL)文件的库、末端请求以及所有请求的历史。Transport 页面管理了配置。在这个例子中,交互配置基于 HTTPS。

图 3. 通用服务客户端服务页面
客户端页面显示了请求与历史
客户端页面显示了请求与历史
  1. 查询测试用例的 XML 代表:
  1. 点击 Add EndPoint request,并输入测试用例的 GET 方法与 URL:
图 4. 创建一个末端请求
请求向导中的 URL 与 Method 区域
请求向导中的 URL 与 Method 区域

注意:
默认的 HTTP 并没有包含 HTPPS,所以比该请求创建一个特定的 HTPPS 配置。

  1. 点击 New,输入一个名字,并选择 Keep Alive 以及 SSL certificate
图 5. 创建一个协议配置
HTTP 配置选项
HTTP 配置选项
  1. 点击 Open SSL Editor,并点击 Rename。
  2. 给 SSL 配置重命名:
图 6. 给 SSL 配置重命名
SSL 配置的新名字
SSL 配置的新名字
  1. 点击 OK 三次,点击 Next,然后点击 Finish 以创建请求。

请求会在通用服务客户端的右边显示出来:

图 7. 通用服务客户端中显示的请求
通用服务请求内容
通用服务请求内容
  1. 点击 Invoke 以访问请求并显示服务器的响应。请求与响应会存储到请求历史中:

有了请求历史框,用户就可以快速获得他们发送的请求以及相应的回应。

图 8. 请求历史框
Request History 显示了请求与响应

在这个例子中,来自服务器的响应信息是空白的,但是 Response Properties 页面却包含了信息:

图 9. 响应属性
Response Properties 页面包含了 cookies
Response Properties 页面包含了 cookies

上面提到的会谈 ID (这里是一个 JSESSIONID cookie)受到了我们特定的关注。指向查询用例(作为位置属性)的 URL 还包含了重要的信息。但是,被设置为 authrequiredx-com-ibm-team-repository-web-auth-msg 响应头意味着您必须遵循 Jazz 认证方案。

提示:
属性名与值必须被选中并复制,这可以方便使用已有的值来创建请求。

为了遵循认证方案,您需要访问 URL 的另一个 GET 操作,将会话 ID 作为一个 cookie 发送,并使用相同的 HTTPS 配置。

图 10. 使用 JSESSIONID 会话 ID 的末端请求
请求包含了 JSESSIONID  会话 ID cookie
请求包含了 JSESSIONID 会话 ID cookie
  1. 调用通用服务客户端中的操作,并评审响应的属性:
图 11. 需要认证的响应
HTTP 头需要认证
HTTP 头需要认证

响应属性包含了被设置为 认证X-com-ibm-team-repository-web-auth-msg HTTP 头,但是没有包含一个换向的位置。Jazz 认证机理指定了,下一步是在做好了准备以后进行认证。

  1. 使用 POST 操作来将用户的信息(包括用户名和密码都是“admin”)指向以下的位置处: https://rqmserver:9443/jazz/ authenticated/j_security_check?j_username=admin&j_password=admin

服务器还包含了 Path=jazz cookie 声明。User Authentication Jazz 方案需要 application/x-www-form-urlencoded content-type 头。

认证请求如下面的屏幕截图所示:

图 12. 认证请求
请求后的用户信息
请求后的用户信息
  1. 调用请求并看到响应属性不再包含有 x-com-ibm-team-repository-web-auth-msg 头。
图 13. 认证通过
响应不再需要认证
响应不再需要认证

Location 属性会指向与认证前相同的 URL。

使用请求历史来完成认证过程

您可以利用通用服务客户端 Request History 框,来获得第二个请求。对新的请求使用它来作为一个基础可以节省时间:

  1. 在 Request History 框中,选中您所做的第二个请求:
图 14. 从 Request History 处获得一个请求
第二个请求被选中的

请求会在通用服务客户端的右边显示出来,并且可以调用。

  1. 点击 Invoke 并查看响应中的 Location 属性。它包含了一个并没有重新定向的 URL。实际上,URL 是您在初始 GET 操作中使用的原始地址。
图 15. 没有换向的 URL
Location 属性 URL 并没有换向
Location 属性 URL 并没有换向

您可以获取 Request History 框中的第一个请求,并添加 JSESSIONID cookie 以让它发挥作用:

图 16. 添加 JSESSIONID cookie 之后的首个请求
GET 请求包含了 JSESSIONID cookie
GET 请求包含了 JSESSIONID cookie

在您调用 GET 请求之后,响应包含了一条信息,它是 Rational Quality Manager 测试用例的 XML 描述。该屏幕截图显示了 Form 视图中的 XML 描述:

图 17. 测试用例 XML 描述的 Form 视图
测试用例内容在 Form 视图中显示出来
测试用例内容在 Form 视图中显示出来

Tree 视图将 XML 元素按照层级结构的树形方式显示出来,而 Source 视图则显示了 XML 代码 :

图 18. 测试用例 XML 描述的 Source 视图
Source 视图中作为 XML 显示的测试用例内容
Source 视图中作为 XML 显示的测试用例内容

生成并评审服务测试

请求的前面序列可以被转化为一个服务测试脚本:

  1. 在 Request History 中选择所有的请求,并点击 Generate Test Suite
图 19. 从 Request History 中生成一个服务测试
生成一个测试系列的 New Test 向导
生成一个测试系列的 New Test 向导
  1. 点击 New Project 以创建一个容器项目,将服务测试重命名为 getTestCase,并点击 Finish。服务测试包含了所有的请求与它们的响应:
图 20. 请求与测试中的响应
生成的测试包含了请求与响应
生成的测试包含了请求与响应

通用服务客户端中使用的 HTTPS 配置获取后存储在测试中。

图 21. 测试中的 HTTP 配置
Propertes 框中的 HTTP 配置
Propertes 框中的 HTTP 配置

所有的请求都会使用 HTTP 配置:

图 22. 请求使用的 HTTP 配置
使用 RQM-HTTPS 配置的一个请求
使用 RQM-HTTPS 配置的一个请求

自动化的数据协调使得测试可以运行

自动化的数据协调功能,是 Rational Performance Tester 的一项强大的特性。有了这个特性,您就可以实时地运行服务测试了,不管通用服务客户端中场景的复杂性如何。

在测试编辑器中,点击 View > Display Data Correlation。第一个替换器通过首个响应之后的请求,显示了测试生成器会检测到 JSESSIONID cookie 的使用。替换器创建了对响应 cookie 的引用,并用其引用来替换随后请求中的值。

图 23. 测试中的数据协调情况
使用 JSESSIONID cookie 的数据替换性
使用 JSESSIONID cookie 的数据替换性

图 23 的大图

有了数据协调性,当测试运行时,服务器返回的 JSESSIONID cookie 会被请求所使用,即使它的值没有存储在服务测试中也是这样。

确认点

在您运行测试之前,您可以使用一个确认点来检查最后一次 GET 请求的状态。

按照以下方法来创建一个确认点:

  1. 点击 View > Display all Test Contents,并选择最后的响应。
  2. 点击 Add > Equal Verification Point

在运行时,该测试元素会将服务器返回的 XML 信息,与存储在测试之中的 XML 信息进行比较。您还可以使用其他的一些比较选项:

图 24. 创建一个平等的确认点
TestCase1 内容的确认点
TestCase1 内容的确认点

通用 Java 代码

这个确认点本身就已经可以检查测试用例获取的状态。但是,您可以使用另一个 Rational Performance Tester 特性:通用 Java™ 代码,来确认处于测试之中系统的其他方面。

例如,您可以检查响应的 HTTP 状态代码。对于这个程序,使用最后一次响应并评审测试。

按照以下方法来向测试添加通用 Java 代码:

  1. 打开 Response Properties 页面:
图 25. 测试之中的 Response 属性
测试之中的 Response 属性
测试之中的 Response 属性

状态代码是 200,这意味着“OK”。在剩余的步骤中,您可以创建一个对该值的引用,并使用它作为 Java 通用代码声明的一个论断。在运行时,该代码会检查实际的状态是否是 200,并根据该状态记录通过或者失败。

  1. 点击 200 值以激活它。
  2. 右击值,并选择 Create Reference
  3. 当 Edit Reference Name 对话框出现的时候,您可以接受默认的值,并点击 OK
图 26. 向 HTTP 状态代码创建一条引用
引用创建对话框
引用创建对话框

引用会得到创建,而编辑器会用蓝色将值强调显示出来:

图 27. 测试编辑器强调显示引用
引用值是一个阴影的背景
引用值是一个阴影的背景
  1. 为了向测试添加通用的代码,选择测试的根节点,并点击 Add > Custom Code
图 28. 向测试添加通用代码
点击根节点并向测试添加通用代码
点击根节点并向测试添加通用代码

通用代码元素会与项目中的 Java 类一起联系起来。

  1. 更改默认的类名,这样它就有意义了: test.CheckHTTPStatus
图 29. 更改通用代码名
Test Element Details 重命名了通用代码
  1. 点击 View Code 以生成类并在编辑器中将其打开。运行时类的行为由 exec 方法所定义,这是尚未指定的:
public String exec(ITestExecutionServices tes, String[] args) {
    return null;
}
  1. 将内容更改为以下代码 :
代码行 1. 指定 exec 方法
public String exec(ITestExecutionServices tes, String[] args) {

    if (args[0].equals("200")) {
tes.getTestLogManager().reportVerdict("Status code is 
correct",VerdictEvent.VERDICT_PASS,VerdictEvent.REASON_SEE_DESCRI
PTION);
    }
    else {
        tes.getTestLogManager().reportVerdict("Status code is not 
correct",VerdictEvent.VERDICT_FAIL,VerdictEvent.REASON_SEE_DESCRIP
TION);
    }
    return null;
}
  1. 添加 Java 导入声明,它需要去识别 VerdictEvent 类:
import org.eclipse.hyades.test.common.event.VerdictEvent;

该代码会检查通用代码论证的值。您必须定义该值。

  1. 打开测试编辑器,并点击通用代码 Arguments 区域旁边的 Add。Select Arguments 对话框会打开,在这个对话框中您可以选择一个数据源作为论断。
  2. 展开最后一个 GET 条目,并选择 Cookie: 200 引用;然后点击 Select
图 30. 向 Custom Code 添加一个论断
引用作为一个通用代码论断来使用
引用作为一个通用代码论断来使用

引用会添加至通用代码论断列表中去:

图 31. 论断会添加到通用代码中
通用代码论断列表
  1. 保存测试,并点击测试编辑器中的 Run

分析测试运行的结果

在测试运行期间,Service Test 报告会自动打开,并进行实时更新。但是,只有内构平等确认点才是该报告的一部分。为了达到测试运行事件的一个更加精确的视图,右击 Performance Test Runs 视图中的运行结果,并选择 Display Test Log

图 32. 显示 Test Log 报告
显示测试日志的菜单

Test Log 报告提供了所有测试事件的高级信息。为了打开日志,您可以点击测试日志 Events 项,并展开 Events 树形结构

图 33. Test log 事件
日志列出了测试运行事件
日志列出了测试运行事件

平等确认点是事件列表的一部分。日志还指示了通用代码记录的 pass 事件。选择 Java 通用代码中设置的字符串:

图 34. 通用代码状态字符串
Test 日志的通用代码状态字符串
Test 日志的通用代码状态字符串

当您在评审 Test Log 报告时,Service Content 页面会得到相应的更新。例如,它会显示来自最后一次服务器响应中的 XML 信息:

图 35. Service Content 页面
Service Content 页面上的测试用例代码
Service Content 页面上的测试用例代码

Service Content 页面还显示了确认点的预期 XML 内容与实际 XML 内容:

图 36. Service Content 页面上的一个确认点
返回的数据与确认点内容
返回的数据与确认点内容

最后,Test Log 报告会显示使用来自服务器 JSESSIONID cookie 的后续请求:

图 37. 服务器提供的 JSESSIONID cookie
RQM 服务器发送的 JSESSIONID cookie
RQM 服务器发送的 JSESSIONID cookie
图 38. 请求所使用的 JSESSIONID cookie
稍后请求所使用的 JSESSIONID cookie
稍后请求所使用的 JSESSIONID cookie

定制服务测试以发送各种的 REST 请求

为了向 Rational Quality Manager 服务器发送另一个请求,我们可以再次使用通用服务客户端,并得到服务器的确认。但是,一个快速的方法由服务测试的重复使用组成,它已经包含了需要的认证步骤作为基础。

  1. 在 Test Navigator 中,右击测试,并选择 Copy
  2. 将测试粘贴到项目之中。
  3. 右击复制的内容,并选择 Rename,并将其命名为 createTestCase
  4. 为了创建一个测试用例,您必须使用 POST 操作来向服务器发送测试用例的完整 XML 代表。
    1. 在测试中,点击 Transport 项,并将 Method 更改为 POST,而不是 GET。向服务器发送的是 XML 测试用例 而不是一条空白的信息。
    2. 将 URL 更改为目标测试用例服务: https://rqmserver:9443/jazz/ service/com.ibm.rqm.integration.service.IIntegrationService/testcase)
图 39. 更改请求的方法
从 Method 列表中选择 POST
从 Method 列表中选择 POST
  1. 按照以下的方法,来访问测试用例的 XML 代表:
    1. 选择最后一次回应以应用到 Service Content 页面。
    2. 选择所有它的内容并复制选择的文本:
图 40. 从 Service Content 页面来复制 XML 测试数据
Service Content 工具栏中的 Copy 按钮
Service Content 工具栏中的 Copy 按钮

图 40 的大图

  1. 将内容粘贴到最后一次请求信息的 Source 视图中:
图 41. 将 XML 数据粘贴到一条请求信息中
粘贴以后最后一次请求的信息内容
粘贴以后最后一次请求的信息内容

您将内容粘贴到最后一次请求中,因为 XML 信息在用户认证之前,将不会得到进一步的处理,这样在实际 POST 请求发出之前,其内容是毫无意义的。

而且,在 首个 请求中必须更改 URL。按照服务器中的换向操作,可以由引用的使用来得到处理。

按照以下的方法来更改首个请求之中的 URL:

  1. 为首个请求点击 Transport 项。
  2. 使 URL 区域出于可编辑状态,并选择 Remove Substitution
  3. 将 URL 更改为 https://rqmserver:9443/jazz/service/ com.ibm.rqm.integration.service.IIntegrationService/testcase
图 42. 更改 URL
首个请求 URL 的 Transport 页面
首个请求 URL 的 Transport 页面

为了回答这次请求,服务器响应 Location 头包含了换向 URL。

  1. 选择测试编辑器中的换向 URL,右击选择,并创建一条引用:
图 43. 使用换向 URL 来创建一个引用
您在右击 Location 时会打开的菜单
您在右击 Location 时会打开的菜单
  1. 将引用命名为 URL1。
  2. 重复上述的步骤,以向第三个和第四个服务器响应 Location 值创建两个额外的引用,并将响应命名为 URL2URL3
图 44. 使用第二个换向 URL 创建一条引用
Test Editor Edit Reference Name 窗口
Test Editor Edit Reference Name 窗口
  1. 为了让请求遵循这些换向,您可以用以下的引用来替换相应的 URLs :
    1. 选择第二个请求 URL 的整个文本区域,右击,然后点击 Substitute > Select Data Source
    2. 选择 URL 引用,并点击 Select
图 45. 选择一个数据源引用
URL1 引用作为数据源来选中
URL1 引用作为数据源来选中
  1. 重复第 7 步,用 URL2 来替换第四个请求的 URLs,用 URL3 来替换第五个请求的 URLs。
  2. 从最后一次响应中删除平等的确认点,因为现在它已经是不相关的。
  3. 编辑通用代码,这样它就会检查以下的状态: 201 – Created HTTP
if (args[0].equals("201")) {
    tes.getTestLogManager().reportVerdict("Status code is correct",
VerdictEvent.VERDICT_PASS,VerdictEvent.REASON_SEE_DESCRIPTION);
}
  1. POST 请求中测试用例的名字更改为一个新值:
图 46. 重命名新的测试用例
POST 请求视图中的测试用例名字
POST 请求视图中的测试用例名字
  1. 保存测试。
  2. 运行测试。服务器 Atom 会显示创建的测试用例:
图 47. 更新的测试用例 feed
Atom feed 显示了新的测试用例
Atom feed 显示了新的测试用例

结论

对 Rational Quality Manager REST API 的调用都可以使用通用服务客户端来进行访问。而且,可以生成、编辑并运行包含该请求的服务测试。

按照类似的方法,使用其他命令(一般是 PUTDELETE)的 REST 请求可以使用 Rational Performance Tester 通用服务客户端与测试编辑器中的方便特性,来得到创建和访问。

实际上,因为测试的持续时间并没有超过 Rational Quality Manager 会话暂停期,所以一个测试中的所有请求都会使用相同的 JSESSIONID。您需要根据本文中描述的过程,每次服务测试进行一次认证,这将极大地简化测试场景的精化与维护工作。


相关主题


评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=578254
ArticleTitle=使用 Rational Performance Tester Extension for SOA Quality 来测试 IBM Rational Quality Manager REST API
publish-date=09142010