性能测试的目标就是通过为所有涉及到的组件收集分析数据,识别性能的瓶颈。这包括应用程序等级性能监控,例如应用程序服务器级别 instrumentation for IBM® WebSphere® Application Servers (版本5或者更高的版本),以及 BEA WebLogic Version 8 或者使用面向应用程序服务器的 Application Response Measurement (ARM) API 的数据收集,例如 JBoss、Apache Tomcat 等等。另外,数据库等级监控可以是 ARM 激活的。在这种意义下,所有的数据库活动都能够被收集和显示为 UML 顺序图。启用现实生活的应用程序监控仅仅是性能测试监控的一个方面。数据收集的这些级别(应用程序和数据库等级)在不具备收集服务器端资源级别监控(应用程序的各个组件正是运行于此)的情况下是无法完成的。
IBM Rational Performance Tester 支持三种以上默认的实时资源水平监控方法,其中包括:
- IBM® Tivoli® Monitoring
- UNIX® 或者 Linux®
rstatd
后台程序 - Microsoft® Windows® Performance Monitor (perfmon)
作为一个例子,如果要使用 Windows Performance Monitor 进行监控,您就需要启用资源监控。按照以下步骤收集 Windows Performance Monitor 的分析数据。
- 选择调度;
- 在 Schedule Element Details 面板中,点击 Resource Monitoring 标签;
- 勾选选项 Enable resource monitoring,如图22中所示;
- 对于一个新的安装,点击 New 添加它。您还能够将一个现已存在的服务器添加为被监控的,或者从之前定义的服务器中进行编辑。
图 22. 启用资源监控,步骤一
- 在您点击 Add New 之后,您就能够在 Location 标签下输入您的
username
和password
。 - 然后,您能够在 Resource 标签下选择您所希望的 statistics,如图23中所示,并且在 Options 标签下选择 polling 和 time-out intervals。
图 23. 启用资源监控,步骤二
请注意:
如果要通过 IBM Tivoli Monitoring 和 UNIX (或者 Linux)的 rstatd 进行监控,您就必须确保在它们被连接之前就已经启动并且运行。除了实时系统监控之外,您还能够从 IBM Tivoli Monitoring 将历史数据导入到一个性能报告之中。例如,从菜单中选择 File > Import,然后选择 Profile 和 Logging > Resource Monitoring Data。下一幅屏幕将允许您指定 Tivoli 监视服务器。现在,您只能够导入 IBM Tivoli Monitoring 历史数据,如图24中所示。
图 24. 从 Tivoli 中导入历史数据
使用 Rational Performance Tester 的好处之一就是在线(以及不在线)分析报告能够被生成出来分析性能,以及工具找出特定问题的根源的能力。默认的报告远不止通常的目的。如果需要更加高级的报告,您就能够定制分析报告,从而为更加深刻的洞察性能问题生成更加有意义的、深入的报告。在 IBM Rational Performance Tester 中提供四种类别的 HTTP 报告:
- 性能报告
- 页面元素报告
- 百分点报告
- 确认报告
请注意:
不同性能报告的细节将在本系列文章的第 2 部分中进一步阐述。
性能报告由高级别的报告组成,例如全部运行成功率、一个显示全部已完成用户的概要页面、流逝的时间总计、所有页面的平均响应时间,等等。在线性能报告为方便定位被显示为不同的格式(9个标签)。例如,图25中显示了响应与时间的概要格式。
图 25. 性能报告:响应与时间的概要
页面元素报告,一个5个标签的报告,由其自己的默认分析报告集组成,例如 Response vs. Time Details 和 Page Element Throughput。图26中显示了一个典型的页面元素吞吐量报告。
图 26. 页面元素报告——页面元素吞吐量
百分点报告,一个4个标签的报告,显示了同页面响应时间相关联的百分点范围。它所提供的默认报告包括概要和 85th、90th 以及 95th 百分点。这一报告类型通常被用于决定异常的情况,例如页面活动中的震荡。通过关联百分点和页面,数据能够在每个页面级别上被集合以识别那些关键百分点的页面行为。这些报告是一种表达 85% 的页面在 X 毫秒内被完成、90% 的页面在 Y 毫秒内被完成等的方式。您能够创建百分点和页面响应时间之间的关系,以便它为您提供保障 85% 的页面能够在指定时间内被响应。然后,通过将报告同百分点报告进行可视化的比较,您就能够轻易的看到任意时刻异常事件发生的情况。
图27捕获了 85th 百分点,而且对于一个页面来说,精确捕获到 90th 和 95th 百分点也并不是一件不寻常的事情,它意味着事情都进展的很顺利。如例子中所示,85% 的用户都在 16,954 毫秒内完成 Yahoo! Entertainment 页面的下载。
图 27. 百分比报告——85th
验证点报告,一个3个标签的报告,为页面提供了“通过”或者“失败”的状态,以便进行确认。确认是测试脚本下面的 Test Content 下面的集合。它是一种判断页面请求是“通过”还是“失败”测试的方法。测试的内容可以是 HTML 页面标题、HTML 返回代码、以及 HTML 响应大小(请参见 Windows > references > Performance Test Generation > Verification Points)。验证点能够为每一个页面打开,如图28中所示:
图 28. 验证点——启用
页面验证点报告列出了每一个页面及其相应的“通过”或者“失败”率,以及百分比通过率。一个例子“页面验证点”报告显示了完成的页面的通过率。在图29所示的例子中,没有失败的页面;因此,通过率是百分之百。
图 29. 验证点——页面验证点
除了这四个报告,您还能够挖掘到页面级别,以便更好的理解基于页面级别的响应时间。
- 挖掘一个页面,选择 Page Performance 默认性能报告中的标签上的一个页面(垂直工具条),并且右键单击选择 Display Page Element Responses。例如,图30中显示了 My MTV Movie Awards '07 页面,以及 Breaking News on Yahoo! 被选中用于挖掘。
图 30. 页面元素响应,步骤一
图 31. 页面元素响应,步骤二
文章来源于领测软件测试网 https://www.ltesting.net/