内容


使用 Rational Performance Tester 执行 WebSphere Commerce 性能测试,第 1 部分

使用 Rational Performance Tester 设计测试

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 使用 Rational Performance Tester 执行 WebSphere Commerce 性能测试,第 1 部分

敬请期待该系列的后续内容。

此内容是该系列的一部分:使用 Rational Performance Tester 执行 WebSphere Commerce 性能测试,第 1 部分

敬请期待该系列的后续内容。

简介

WebSphere Commerce 是 IBM 的企业电子商务解决方案。网站性能和可靠性是人们一直关注的一个问题。要解决此问题,可通过 Rational Performance Tester 等工具执行性能测试和件事。一个 WebSphere Commerce 解决方案由多个软件应用程序和集成组成,因此,性能问题可能很复杂,而且是多方面的。部署的硬件资源是另一个因素,因为它们可能会限制整体解决方案的可伸缩性。

要执行性能测试,首先要制定一个测试计划,定义用来评估结果的目标和标准。测试在性质上是迭代式的,因为结果可能导致应用程序调优、代码修改或资源重新分配。然后必须重新测试这些更改来观察是性能是提高了还是降低了。

编写测试需要理解生产中发生了哪些商业事务,以及如何真实地重新创建这些事务。事务信息可从 Web 分析工具中找到,或者通过检查应用程序日志和数据库表来找到。要模拟的事务量应该基于正常和峰值业务活动期间所预期的情况。可以在 Rational Performance Tester 中使用进度表和随机选择器的特性来模拟这种情况。

性能测试需要提供有意义且可由利益相关者解释的结果。一些相关的重要性能指标包括:

  • 订单吞吐量
  • 响应时间
  • 页面查看次数
  • CPU 利用率
  • 缓存命中率
  • 数据库 SQL 活动

订单吞吐量显示了解决方案可处理的事务的收益率。可增加测试工作负载来查看是否可以支持更大的订单吞吐量,同时不超出响应时间和 CPU 资源等限制。响应时间直接影响到客户满意度,与吞吐量呈反比关系。页面查看次数指标表明了网站的流行度,无论它是否创造收入。架构师和开发人员对系统细节感兴趣,比如 CPU 利用率、缓存命中率和数据库 SQL 活动,他们需要知道修改哪些方面来实现更高性能。Rational Performance Tester 可联系应用程序度量指标来提供这些细节。

这是一个由 3 部分组成的文章系列的第 1 部分。第 1 部分将介绍设计编写过程中的设计和重用。第 2 部分将介绍如何实现浏览 Commerce 目录。第 3 部分将介绍问题判定并提供调查测试问题的技巧。

设计测试

本文将介绍设计 Rational Performance Tester 测试的一些建议。本文的内容包括:

  • 模块化测试以重用它们
  • 使用局部和全局变量
  • 清理 cookie 缓存
  • 设置针对响应的验证点
  • 按进度表对事务中的任务进行排序
  • 配置自动 HTTP 重定向

所有示例中使用的目录是平衡的,包含 3 个一级类别。每个类别有两个子类别,每个子类别有 3 款产品,如 图 1 所示。

图 1. 目录结构
该图显示了一个目录结构,其中包含 3 个一级类别,每个类别包含 2 个子类别,每个子类别包含 3 款产品
该图显示了一个目录结构,其中包含 3 个一级类别,每个类别包含 2 个子类别,每个子类别包含 3 款产品

模块化和重用

在 Rational Performance Tester 中,测试的构建通常从记录开始。在这一节中,将记录一个注册用户的一次端到端浏览对话,并将它修改为可重用的测试,然后用它来构建一个测试进度表。

记录会经历以下路径,如 图 2 中所述:主页 → 登录 → 通过 Departments 按钮浏览到顶级类别 #2 → 浏览到子类别 #4 → 显示产品 #10 → 退出

图 2. 测试记录
该图显示了测试记录内容

该记录生成了一组页面,这些页面可划分到 4 个可重用的测试中:

  • 主页
  • 登录
  • 浏览
  • 退出

将一组页面或测试分组到一个事务块下,使 Rational Performance Tester 能够报告该事务的统计数据。通过将记录拆分为小型的测试,并在事务中使用它们,您可以为来宾用户和注册用户创建一个浏览事务,如 图 4 所示。

变量

这些测试会彼此传递一些信息。使用全局变量将数据从一个测试传递到下一个测试。

这些全局变量中的大部分变量都是从数据池设置的。其中一些通过直接变量赋值或自定义代码来设置。

一种最佳实践是在一个单独的测试(具有类似 InitVariables 的名称)中从数据池初始化所有全局变量,然后将它放在进度表的开头处。这么做可以避免只要一个数据池更改就需要修改所有测试的情况。

应创建另一个测试来设置虚拟用户在每次迭代中的登录 ID。如果用户 ID 为 sadmin1 到 sadmin300,自定义代码可从此范围随机生成一个登录 ID。此自定义代码可放在同一个 InitVariables 测试中,或者放在新测试中。使用第二个选项并创建一个新测试 InitUser。Rational Performance Tester 在选择将一个值替换为什么值时,在测试数据来源中还有一个内置的随机数生成器。

使用一个包含一行值的数据池来初始化所有测试中的变量。每个测试都需要主机名、目录 ID、语言 ID 和商店 ID。UsedIdPrefix 和 MaxRegisteredUsers 值用于生成登录 ID。Rational Performance Tester 还允许建立一个进度表来从一个文件初始化全局变量,并让一个用户组拥有自己的变量初始化表。这些示例中使用了数据池方法。

图 3. 常量数据池
该图显示了常量数据池
该图显示了常量数据池

性能进度表类似于 图 4 中所示的进度表。

图 4. 测试进度表
该图显示了测试进度表
该图显示了测试进度表

每个选择器下方的事务块帮助定义规则,以防变量没有正确设置或验证点出现失败。

请注意,登录和退出测试不在事务之下,而在事务之外。在真实的进度表中,注册用户不仅要执行浏览事务,还要将产品添加到购物车,订购产品,将产品添加到愿望清单或结算订单。这些测试中的每一种测试都可放在自己的事务下。

如果登录和退出响应时间应包含在事务中,那么应该将它们移动到事务内。

InitVariables 测试使用了常量数据池。变量容器的标签 OUTPUT 用于逻辑地表明这些变量是此测试的输出;也就是说,它们由此测试设置,并由其他测试使用。这些全局变量的可视性必须是 “All tests for this user”,如 图 6 所示。

图 5. InitVariables 测试
该图显示了 InitVariables 测试
该图显示了 InitVariables 测试
图 6. 变量可视性
该图显示了变量可视性

需要使用 InitVariables 测试中设置的变量的测试,应设置一个标为 INPUT 的变量容器并声明同样的变量。这些变量必须具有相同的名称,而且可视性必须设置为 “All tests for this user”,这意味着它们会在测试之间共享。

举例而言,在主页测试中,全局变量 StoreId 是从 InitVariables 测试中设置的。它被用于替换主页中任何硬编码的商店 ID。

图 7. StoreId 变量和替换值
该图显示了 StoreId 变量和替换值
该图显示了 StoreId 变量和替换值

控制 cookie 缓存

进度表中的第一个测试应清除 cookie 缓存,因为它要模拟一个新的 Web 浏览器会话。如果在进度表中使用了一个循环来重复测试,那么配置 cookie 缓存的行为很重要。cookie 缓存已被清除,如 图 8 中所示。

图 8. 清除 cookie 缓存
该图展示了如何清除 cookie 缓存
该图展示了如何清除 cookie 缓存

验证点

要验证测试的正确性,需要创建验证点。这些验证点用于检查响应是否有问题。如果页面包含错误或意外的内容,性能结果将会是无效的。有 3 种类型的验证点:响应大小、响应代码和响应内容。可通过 Add 上下文菜单来为响应创建它们。也可以通过单击测试树中的测试名称并单击 Add,为整个测试创建它们。响应代码验证点和响应大小验证点也可以在测试首选项中自动打开。图 9 展示了如何添加一个验证点。

图 9. 添加一个验证点
该图展示了如何添加一个验证点
该图展示了如何添加一个验证点

举例而言,图 10 展示了创建内容验证点的对话框。您可以根据响应内容中是否存在一些字符串来定义验证。

图 10. 创建内容验证点
该图展示了内容验证点的创建
该图展示了内容验证点的创建

在输入一个字符串后,还可以设置验证点失败时的操作,比如停止当前事务或退出当前循环迭代,如 图 11 所示。

图 11. 验证点操作
该图显示了验证点操作
该图显示了验证点操作

可在测试或进度表回放期间使用验证点报告来监视验证点。这提供了一次测试运行的正确性的实时信息。图 12 显示了一个验证点报告。

图 12. 验证点报告
该图显示了验证点报告
该图显示了验证点报告

使用测试进度表

如之前所述,模块化测试后,您可以按顺序将它们放在一个事务容器下的进度表中。根据所模拟的场景,您可以创建不同的顺序或事务。例如,图 13 中的进度表包含一个事务 RegisteredShopper_CompleteOrder,包含完成一个订单所需的测试。

图 13. 已注册的购物者事务的进度表
该图显示了已注册的购物者事务的进度表
该图显示了已注册的购物者事务的进度表

可以基于注册的购物者版本,为来宾购物者创建一个新进度表,如 图 14 所示。定义一个新事务 GuestShopper_CompleteOrder,并对完成事务所需的测试进行排序。请注意,重用了在已注册的购物者和来宾购物者之间通用的测试,而添加或删除了其他测试,因为这些测试是特定于某个事务的。

图 14. 来宾购物者事务的进度表
该图显示了来宾购物者事务的进度表
该图显示了来宾购物者事务的进度表

一个 Rational Performance Tester 进度表中的虚拟用户划分为用户组,该进度表提供了随机选择器来选择不同的事务。您可以向一个用户组分配一个百分比或绝对数量的虚拟用户。在 图 15 中,进度表显示了已注册和来宾购物者用户组,每个组包含所有虚拟用户的 50%。依据在随机选择器中的权重,来宾购物者即可以执行完整订单,也可以执行浏览事务。事务 GuestShopper_CompleteOrder 和 GuestShopper_Browse 都拥有权重 1,这意味着它们具有相等的权重,所以执行每个事务的几率为 50%。

图 15. 完整进度表
该图显示了完整进度表
该图显示了完整进度表

自动 HTTP 重定向

Rational Performance Tester V8.3 和更高版本可自动跟踪 HTTP 重定向,无需在测试中明确显示重定向的请求。HTTP 重定向意味着一个请求返回对另一个 URL 的请求。一个 HTTP 重定向的示例发生在登录请求中。登录请求返回一个 HTTP 代码 302,这意味着它是一种重定向且新请求是 OrderItemMove。OrderItemMove 被重定向到 OrderCalculate。OrderCalculate 被重定向到 AjaxLogonForm,后者是最终的请求。

没有自动 HTTP 重定向的登录测试必须包含这 3 个请求,才能成功完成登录。重定向请求链是硬编码的。如果登录有一个新的重定向顺序,该顺序需要重新硬编码。

图 16. 登录重定向
该图显示了登录重定向
该图显示了登录重定向

更可靠的方法是跟踪重定向的发生。这就是自动 HTTP 冲定性,通过将登录的预期响应状态码从 [302 – Found] 更改为 [200 – OK] 来实现。这会告诉 Rational Performance Tester 完成所有重定向,直到最终获得 [200 – OK],这在登录测试中是 AjaxLogonForm 页面。

图 17图 18 所示,通过更改预期的响应状态码并禁用重定向的请求,将登录测试设置为使用自动重定向。它被回放并表明所有重定向请求都已正确发出。

图 17. 登录自动重定向
该图显示了登录自动重定向
该图显示了登录自动重定向
图 18. 登录自动重定向回放
该图显示了登录自动重定向回放
该图显示了登录自动重定向回放

结束语

在这个关于使用 Rational performance Tester 设计测试的文章系列的这一部分(第 1 部分)中,为测试设计实现了一些最佳实践。在第 2 部分中,将实现一个浏览 WebSphere Commerce 目录的真实示例,其中将应用这些最佳实践的一部分。

致谢

非常感谢来自 Rational Performance Tester 的以下人员的审阅和提供的宝贵建议:

  • Kent Siefkes - 首席架构师,Rational Performance Tester
  • Dawn Peters - 软件设计师,Rational 质量和需求管理

相关主题


评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere, Rational
ArticleID=1014951
ArticleTitle=使用 Rational Performance Tester 执行 WebSphere Commerce 性能测试,第 1 部分: 使用 Rational Performance Tester 设计测试
publish-date=09152015