51Testing软件测试论坛

标题: 【转自网络】基于 Jazz 产品的数据操作 [打印本页]

作者: lsekfe 时间: 2016-2-2 09:25
标题: 【转自网络】基于 Jazz 产品的数据操作

简介： 准备去测试大量的数据是性能测试的一个重要组成部分。但是，很少有更有效的方法能使这个过程变得更完善，特别是在软件开发生命周期的早期阶段更是如此。基于 IBM® Jazz™ 技术的软件构建在一个轻松、面向资源型的结构之上，在这个结构上创建、取消、更改及删除操作可以使用 HTTP 协议来得以实施。本文介绍了一种方法，平衡使用 IBM® Rational® Performance Tester 以及 Mozilla Firefox Poster 插件。这种方法并不依赖于产品构建变更以及程序界面更改，而且与当前其他的方法相比，它所提供的测试方式性能更佳。

比较测试数据生成方法

对于一个性能测试，您必须找到一种有效的方法，去为软件开发早期阶段的测试创建大量的数据。这些数据集合必须能够模拟真实的产品使用环境，而数据的规模从小到大，这样您就可以找到测试产品中存在的性能瓶颈了。

表 1 包含了 IBM® Rational® Quality Manager 数据集合定义的范例。

表 1. Rational Quality Manager 中的数据集定义
　

ItemType	Low	Med	High
WorkItem	6888	19068	31048
TestCase	3964	9152	17701
CategoryType	10	10	10
Category	0	0	0
TestPlan	101	148	196
TestExecutionRecord	2394	2666	4661
ExecutionResult	0	0	1
TestPhase	202	296	392
AssetConfiguration	404	450	1363
RequirementItem	0	0	0
TestEnvironment	270	270	553
LabResource	601	2156	2410
Request	4971	13062	11256
Reservation	954	3355	4116

Vaughn Rokosz 是一位 IBM Rational 系统确认测试员，为向系统添加测试数据定义了以下的方法：

使用测试自动化工具，例如 IBM® Rational® Performance Tester 或者 IBM® Rational® Functional Tester，通过模拟用户的操作来实现测试环境。
使用公共 API 或者命令行工具来开发特定的实现工具。
如果程序支持导入的话就从客户那里导入测试数据。
使用与关系数据库一起提供的块载入工具来初始化数据库表。
使用内部的 API 来开发特定的实现工具。

有一些向系统添加测试数据的方法可以对实施造成挑战。例如，基于 Jazz Foundation Services 的程序可以通过存储服务来访问存储库。这种逻辑数据模型，使得使用第四种方法中描述的块载入工具直接载入数据库变得不现实起来。

在程序开发生命周期的开始阶段还存在另外一个问题。那就是得不到用户界面，或者它使用起来很不稳定。这个难题使得方法 1 与 3 变得不可行，因为这两种方法都是建立在客户操作的基础之上。就算程序足够稳定，这两种方法使用起来也是十分耗时的。

为了解决这些难题，您需要在当前的构建代码下使用 API 开发一种方法实现数据。使用这种方法的风险在于，它需要适应构建变更的大量努力。为了解决这个难题，您需要找到一个有效的工具，该工具独立于构建变更之外。

发现 Jazz Foundation Services 的价值

基于 IBM® Jazz™ 技术的程序被认为是 Jazz Foundation Services 的扩展，它基于 Representational State Transfer，或者 RESTful 规格，以及面向资源型的结构。每一个程序都提供了服务和数据作为 REST APIs。在这种情况下，数据可以作为可处理的资源显示，特别是作为 URI 显示。另一方面，它可以作为一个 Web 服务程序，为其资源提供创建、读取、更改和删除界面。这些界面可以由 HTTP 协议中的 POST、 GET、UPDATE 和 DELETE 方法实施。这种松散结合的结构使得不同的产品之间可以进行集成，并支持客户与 Jazz Team Server 按照相同的方法来交流，而不管服务实施的方式如何。

图 1. Jazz Foundation Services

实现基于 REST API 的数据

在基于 Jazz 程序的 REST API 基础之上，我们推出了一种数据实现方法，它结合了方法 1 与 2 的优点，这一点在第一部分中有所介绍。为了演示怎样得到该方法，您可以使用 Rational Quality Manager 作为目标服务器。

对于这个练习，数据实现的目标在于，创建 20 个测试规划，并向每一个规划添加 1000 个测试用例。我们可以用于演示这种方法的其他工具还包括 Rational Performance Tester，Firefox 浏览器，以及 Firefox Poster 插件。

对于这个范例，作者假设，您可以在系统认证测试（SUT）通过之前就创建一个模板。对于本测试规划范例的模板文件是 testplan_001，它包含了一个测试用例，名字叫做 testcase_001。

通过 REST API 得到一个资源模板

有一些程序在安装期间提供了 REST API。例如，您可以从不同的 Sample 文件夹中得到各种资源的 XML 模板，它位于安装目录之下。您还可以通过 URI 来访问测试规划的 XML 方案：

https://<RQMServer>:<Port>/jazz/secure/service/com.ibm.rqm. integration.service.IIntegrationService/resources/Quality+Manager/testplan?metadata=schema|-------10--------20--------30--------40--------50--------60--------70--------80--------9||-------- XML error: The previous line is longer than the max of 90 characters ---------|

如果您没有看到这些模板信息，那么您可以通过 REST API 来得到目标资源的 XML 模板，只有在存储库中有一个目标资源就行。您必须确保可以得到该资源的 URI。您可以通过以下的某种方法来得到 URI ：

从开发者处可以得到的 API 文件
对位于客户端信息的链接
Rational Performance Tester 记录的 HTTP 协议以得到指定资源的 URI

在您得到 URI 之后，您可以使用它来为每一个记录类型得到资源模板。该模板独立于产品构建更改之外，因为它是从当前的存储库中获得的。下面是一个范例，关于 Rational Quality Manager 中的记录类型测试用例：

使用 URI 来得到浏览器中所列的测试用例。

图 2. 得到测试用例列表

在结果中，选择 testcase_001。打开它时，右击页面并从菜单中选择 View > Page source。如图 3 所示，您可以为 XML 格式的测试用例记录得到源代码，将该页面保存为名为 testcase_001.xml 的文件，它是测试用例记录的资源模板。

图 3. testcase_001 XML 模板中的代码

您可以使用这些相同的步骤，以得到 testplan_001.xml 测试规划的 XML 模板文件。

使用 Firefox Poster 插件记录操作

Poster 是 Mozilla Firefox 浏览器的一款插件，它可以模拟一个程序与 HTTP 服务器之间的交流。您可以使用标准的 HTTP 操作：PUT、 POST、GET 或者DELETE，来发送和接受来自 URI 的内容。

您可以按照下面的方法来使用 Rational Performance Tester 和 Poster 插件以自动创建数据存储库：

启动 Rational Performance Tester HTTP 记录器。Firefox 与 Poster 会打开和记录浏览器所发送和接受的请求与响应。
如果您是第一次链接到 Jazz 服务器，那么您会看到一个对话框让您登录。因为 Poster 作为一次 Firefox add-on 操作运行，所以它会与您对 Jazz 服务器的登录一起共享认证的部分。Rational Performance Tester 可以自动记录和处理该部分。
选中 Poster 所执行的资源操作。审查 Poster 对话框中的三个区域（见于图 4）：
- URL： 确定它符合于您想要交流的资源。
- Action： 选择 GET/POST/PUT 以分别获取、添加或者编辑内容。
- 发送的内容： 在 POST/PUT 中使用，其中的内容可以添加或者编辑。在这一步中必须更改像标识符或者标题这样的元素值，以校正结果并使其容易确认。
点击 Go，就会向服务器发送请求。如果您得到的响应代码是 201，那么 POST 操作就会创建一个新的资源。如果您得到的响应代码是 200，那么 PUT 操作将会更改资源。

图 4. 使用 Poster 插件来生成 testcase_001

通过使用 Rational Performance Tester 与 Poster 以记录下面的操作，您可以生成一条测试脚本，它模拟了范例中的场景。查看图 5 中 Rational Performance Tester 测试脚本以黄色强调显示的页名：

登录
创建测试规划：创建一个测试规划（Poster 所做的 POST）
得到测试规划：得到新创建的测试规划（由 Poster 或者浏览器得到）
创建测试用例：创建一个测试用例（Poster 所做的 POST）
编辑测试规划：向测试规划添加新创建的测试用例（Poster 所做的 PUT）

编辑测试脚本

在您编辑测试脚本时，您必须编辑这些元素（图 5）以集成 Rational Performance Tester 数据池、引用，而且可以使用其他所有的功能。

添加一个循环或者做一个安排以生成大型的数据集。
查看图 5 中的循环范例。它可以生成 20 个测试规划，每一个规划又有 1000 个测试用例。
在请求 URI 或者数据内容中输入一些值。
脚本独立于资源类型之外。您可以使用其他资源类型来替换 URI 以生成不同的资源。可以替换资源 ID 以生成不同 ID 的资源。为了确保资源独一无二，您可以编辑资源标题以及其他的元素。查看图 5 中右边的窗格以得到该范例。
创建数据相关性以支持资源关系。

图 5. 编辑测试脚本

在图 5 中，注意通用代码 ModifyCase 与 ModifyPlan 让每一个测试规划拥有它的 1000 个测试用例。在每一个测试规划 XML 数据内容中，一个测试用例是通过添加如图 6 所示的 XML 元素 test case template 来联系。

ModifyCase 中的通用代码使用 测试用例模板 了作为输入参数，以生成 1000 个测试用例 XML 文件。它的输出会合并为测试规划 XML 文件，它通过 ModifyPlan 通用代码中的 get testplan 请求获得，以生成一项更改的测试规划。代码合并了 XML 文件，您可以找到图 6 中 XML 合并方式的流程图。 Rational Performance Tester 中灵活的输入环境使得目标资源内容独立起来。

图 6. 使用通用代码与数据相关性创建资源关系

总结

这种数据生成方法可以自动实现独立于开发环境与程序界面的数据。为了实现这种方法，您所需要的，只是产品的 REST API，因为这种方法只是独立于构建更改之外。同样，因为这种方法通过 API 直接对服务器资源发挥作用，所以它的性能要优于本文第一部分中所概括的其他方法。例如，您可以使用这种方法，在 4 分钟内实现 1,000 个 Rational Requirement Composer 资源。如果我们使用本文第一部分中所描述的其他一种上传方法，那么这个过程要超过一个小时。

随着 Jazz 与 RESTful 服务在程序开发界变得越来越流行，您在本文中学到的方法，对于测试阶段有价值，对于程序开发生命周期的其他阶段也很有用。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)