内容


IBM Rational Tester for SOA Quality 的测试执行和性能报告

跟踪服务性能是一个快速动作

Comments

IBM® Rational® Tester for SOA Quality 能够自动化面向服务的结构体系(SOA)应用软件的功能测试和回归测试的创建、执行和分析。在这篇文章中您将注意到 IBM Rational Tester for SOA Quality 的报告。更明确地说,您将仔细观察同时使用 Test Log viewer 和在一个 Web 服务执行报告中可得的各种选项的情况。

Rational Tester for SOA Quality 产品是 Rational Performance Tester 应用软件的扩展。如果您对 Rational Tester for SOA Quality 或者 Rational Performance Tester 并不熟悉,您就应该花一点时间来阅读一些下面 参考资源 部分中的介绍性文章。

测试设置

这篇文章是利用 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 来编写的。

这篇文章将使用 Google Web API 的 Web 服务进行测试。您可以在下面的 参考资源 部分找到指向 这个服务的 WSDL 链接。在这篇文章的测试套件中我们有三个测试,在 API 中每个操作都有一个测试;这些测试的内容显示在下面的图 1 中。

图1. GoogleAPI 测试套件的测试内容
Test contents for the GoogleAPI test suite
Test contents for the GoogleAPI test suite

测试一: doGetCachedPage()

第一个测试调用了 doGetCachedPage() 操作。它传入了 API key 和 IBM developerWorks (http://www.ibm.com/developerworks/)的 url 地址作为参数。对于这个例子,我们有一个等价的验证点,它可以为应答消息找到一个精确的匹配。我将这个测试用例设置为失败通过验证点。

测试二: doGoogleSearch()

第二个测试调用了 doGoogleSearch() 操作。它传入了 API key,"developerWorks" 的 q 值; 初始值 为 0, maxResults 值为 10, 以及其它一些默认值。对于这个测试用例,我们有一个包含的验证点,它只在这个 developerWorks 上寻找代码片段: “"An online collection of tutorials, sample code, standards, and other resources <br> provided experts at IBM to assist software developers using open standards <b>...</b>"。我将这个测试用例设置为通过它的验证点。

测试三: doSpellingSuggestion()

第三个测试调用了 doSpellingSuggestion() 操作。它传入了 API key 和短语IBM Rationla Performance Tester 。对于这个测试,我再次设置了一个寻找结果正确拼写的包含验证点。我将这个测试用例设置为通过它的验证点。

对我们的三个测试都进行了设置,现在我们能够看到一些不同的测试结果类型。

Test Log viewer

Test Log viewer 是查找一个测试详细资料最佳的来源。是查找功能性 Web 服务测试结果的首选位置,也是查找一个 Web 服务性能测试详细资料的位置。它有两个视图,Overview 和 Events。在 Overview 视图中,您能找到总体说明和公共属性。总体说明包括名称、描述以及测试套件的相关文件路径。公共属性包括起始和停止时间、测试运行的结果,测试套件的类型等等。这个视图还包括表明整个测试运行总体结果的报告。表格 1 展示了您可能见到的结果的类型。

表格1.可能的结果以及结果图标
结果图标描述
错误Error表明最初的请求并没有成功地发送到这个服务器上,也没有从服务器上接受到任何应答,或者应答不完整或者没有被解析。
失败fail表明验证点与期望的应答并不匹配或者期望的应答并没有接受到。
未决的inconclusive表明您提供这个自定义代码定义了一个未决的的结果。
通过pass表明这个验证点匹配或者接受到了这个期望的应答。

在 Events 视图,您可以找到您测试运行的详细情况。这个 Events 树列出了所有的测试执行事件,比如脚本起始和终结、循环、调用、通知,或者结果。当您在 Events 树中选择一个对象时,被选择的事件或者对象的属性会显示在 Common Properties 和 Detailed Properties 之下。Common Properties 显示了 Events 树中被选择事件的时间和文本。点击 Properties 下面元素的名称从而打开您在 Events 树中选择的事件的测试套件、测试用例,或者测试行为。Text 域显示了关于您在 Events 树中选择的事件的消息。Defects 部分与 ClearQuest 整合在一起,允许您登陆或者查看与被选择元素联合在一起的元素的缺陷。

让我们仔细看看 Google Web API 的测试套件。图2用图阐述了一个来自自动产生的目录的 Events 树的例子。

图2. Google Web API 测试套件的事件树
Events tree for the Google Web API test suite
Events tree for the Google Web API test suite

在您浏览这个树时(从顶端开始一直向下移动),您会发现在这个树中每一个层次的结果清单;Google API 序列元素显示了结果清单和每一个显示它本身结果的验证点。每个 Web 服务客户机之间的时延是自动添加的;缺省值是零毫秒。最后,每一个调用都与它相应的请求和验证点被列出。

对于一个验证点的详细情况,您将会使用 Web Service Protocol 视图。在这个视图中,您可以看到返回信息包和验证点的详细情况。由于某些原因,这个视图不会在默认情况下显示,因此您要通过选择 Window > Show View > Other, 打开它,然后在 Show View 视图中,选择 Test > WS Protocol Data。 图3让我们看到了 doSpellingSuggestion() 验证点的情况。

图3. Web Service Protocol 视图
Web Service Protocol view
Web Service Protocol view

您还可以在 Web Service Protocol 视图中看到一个请求或者应答 Web 服务客户机的 XML。图4说明了 doSpellingSuggestion() 应答的 XML。

图4. doSpellingSuggestion() 的应答 XML
Response XML for doSpellingSuggestion()
Response XML for doSpellingSuggestion()

Web 服务性能报告

Web 服务性能报告对 Web 服务的功能性测试的概要说明和 Web 服务的性能测试的详细信息都是很有用的。这些报告最关键之处是您在测试刚结束时制定概要说明的能力。

制定 Web 服务的报告

当您运行测试的时候,您看到的第一个报告是Overall 报告;图5举例说明了一个例子。这个报告默认情况下显示了 Web 服务调用成功的的百分比,以及您的测试套件中验证点的通过率。

图5. Web 服务性能的Overall 报告
Overall Web service performance report
Overall Web service performance report

用这个报告您可以做很多美妙的事情。要看您的选项,请右键点击这个报告的任何地方,然后选择 Add/Remove Performance Counters > Web Services Performance Counter...,这将打开 Add/Remove Web Services Performance Counter 向导,如图6中所述。

图6. Add/Remove Web Services Performance Counter 向导
Add/Remove Web Services Performance Counter wizard
Add/Remove Web Services Performance Counter wizard

如果您展开了任何一个计数器类别,您将看到计数器的不同类型,比如:

  • 成功率
  • 平均、最小、最大,以及标准偏差应答时间或者链接时间
  • 总验证点数量
  • 验证点的总包含数以及百分比包含数

看看一个具体的例子。如果您打开了 Response Time,可以为所有 Web 服务返回的平均应答时间添加一个计数器,如图7所示。

图7.添加一个 Average Response Time For All Returns 计数器
Adding an Average Response Time For All Returns counter
Adding an Average Response Time For All Returns counter

如果您添加了这个计数器,这个 Overall 报告就会改变,正如您在图8中所看到的。

图8. 带有 Average Response Time For All Returns 计数器的 Overall 报告
Overall report with the addition of the Average Response Time For All Returns counter added
Overall report with the addition of the Average Response Time For All Returns counter added

在这个例子中,您可以看到这个 Web 服务返回的平均应答时间是 831.33 毫秒。为了确保您所看到的是准确的计数器/值,您可以转变到 Response Time vs. Time Detail 报告(另一个建在沿着 Web Service Performance Report 视图底部的位置),并看看每个 Web 服务的应答时间,如图9所示。

图9.Response Time vs. Time Detail 报告中的 Performance Summary 表
Performance Summary table from the Response Time vs. Time Detail report
Performance Summary table from the Response Time vs. Time Detail report

如果您平均这三个数字就得到 831.33 。我经常尝试仔细检查我第一次添加到报告的计数器。那主要是因为我不相信我自己,而不是我不相信这个工具。这个检验点让我知道我正在做我想做的事情。我不喜欢在我的性能报告中有错误出现。由于某些原因,管理层总想他们在第一次就很精确。

您可以用与您添加 Average Response Time For All Returns 计数器一样的方法为所有的报告添加或者除掉计数器。打开 Average Response Time For All Returns 向导并查看每个报告的选项。添加不同的计数器并查看会发生什么。当您用两种方法查看数据以后,您将会找到什么是您工作中所需要的。

当您关闭对您起作用的这个报告时,您会被询问您是否想保存您的更改。如果您想要您的更改变成 Web Services Performance Report 的一部分就继续向前,继续下一步并保存。如果您不能保证您会经常需要这个信息,就不要保存,但是要在每次需要的时候将它添加进去(或者创建一个新类型的报告)。

Web Service Verification Point 报告

Web Service Verification Point 报告包括您测试中的验证点的详细情况。如果这个报告没有添加很多新数据,就说明它们表现的是验证点很健康的概要说明。此外,如果在您的测试套件中有很多验证点,这些报告在快速定位结果时是很有用的。

要显示 Web Services Verification Point 报告,右键点击这个图标并选择 Web Services Reports > Web Services Verification Point Report。 这样就会打开这个开始于 Summary 视图报告,如图10所示。

图10. Summary Web Services Verification Point 报告
Summary Web Services Verification Point report
Summary Web Services Verification Point report

另一个关于这个报告的视图显示了这个测试套件中各种验证点的详细情况。例如,显示在图11中的 Return Contain Verification Points 视图着眼于这个序列中两个包含验证点的结果。

图11. Return Contain Verification Points 视图
Return Contain Verification Points view
Return Contain Verification Points view

您可以添加和删除这些报告中的计数器,正如上面您在 Overall Web Service Performance 报告中使用的方法一样。

提示和小窍门

您在分析结果上花费的时间越多,您就会对学习怎样用快速方法找到您所需要的信息产生更浓厚的兴趣。这个部分的提示和小窍门会对您找到何时可以加速学习进度有所帮助。

同时浏览多个报告

通常,您需要并排浏览两个报告。您可能想要对它们进行比较,或者您只是想一次吸收更多的信息。要想一次浏览两个报告(事实上,还可以是任何数量的报告;只要您愿意可以对很多报告进行并排浏览),只需要点击这个报告的标题,然后将指针拖拽到这个浏览器区域的左边缘并停放,如图12所示。

图12.拖拽这个报告
Dragging the report
Dragging the report

这个指针变成了黑色箭头。这两个运行的报告就会并排显示,如图13所示。

图 13.两个并列的报告
Two reports side by side
Two reports side by side

过滤结果

通过过滤这个报告中的结果,您可以过滤掉不必要的数据,将精力放在对您有重要作用的数据上来。对于我所谈到的,您可以过滤任何报告。只要右键点击这个报告(正如您要添加一个计数器)并选择 Apply Filter 就可以了。这样就会打开 Performance Counter Filter 对话框,如图14所示。

图14. Performance Counter Filter 对话框
Performance Counter Filter dialog
Performance Counter Filter dialog

这里有您可以利用的三个选项的简短说明:

  • 根据计数过滤: 显示项目的具体数目。例如,如果您选择这个选项然后键入 15,这个报告将会 15个 项目,并有最高或者最低值(取决于您选择的单选按钮)。
  • 根据值过滤: 基于对具体值的比较来显示项目。例如,如果您选择这个选项,然后键入15,这个报告将显示所有高于或低于15的选项(取决于您选择的单选按钮)。
  • 根据标签过滤: 显示匹配于具体标签的项目。如果您过滤的是一个表格,这个标签通常是一个页面,并列在左边的部分中。如果您过滤的是一个图表,这个标签是图表中的图例。

评估一个特定时间范围的结果

另一个选项,类似于过滤,是缩小这个测试的时间段。要重新计算特殊起始和终止时间的结果,您可以指定这个报告的具体时间段。您可以键入自定义的起始和终止时间,从这个测试运行的倾斜上升或者倾斜下降的阶段过滤出数据。这种能力能够集中于一个具体的时间段让您观察,比如,结果来自于虚拟用户最多数量的时间段中对 Web 服务的调用。或许那正是您真正关心您的验证点的通过/失败率的时间。重新评估测试结果来考虑仅仅在这个特殊时间段采集的数据。

如果您想要更改这个执行报告,右键点击并选择 Change Time Range...,这样打开了 Select Time Range 对话框,显示在图15中。

图15. Select Time Range 对话框
Select Time Range dialog
Select Time Range dialog

点击 New Time Range 并添加新的时间段到这个 Available Time Ranges 列表中。点击 Finish ,这个报告就会刷新,放大这个时间轴,只显示这个具体时间段的数据。重新计算的结果会反应这个被选择时间段的数据。注意这个最新的具体时间段与报告一起保存了。重新恢复到这个完整的报告,右键点击这个报告,选择 Change Time Range..., 然后选择来自 Available Time Ranges 列表的 Overall Time Range

输出结果到 CSV、 XML 或者 HTML

您可以将测试结果输出到 CSV、 XML 或者 HTML。在很多情况下这样做是很有帮助的。最常见的是,您想这样做来总结从另一个工具中采集的测试数据,或者为了存档和报告的目的。

为了进一步的分析,您可以输出这个运行的整个结果或者这个结果的特殊部分到一个 CSV 文件中。输出一次运行的结果:

  1. 选择 File > Export.
  2. 在 Export 视图中,点击 Performance test run statistics,然后点击 Next。
  3. 键入这个 CSV 文件的名称(带有.CSV 扩展名),然后点击 Next
  4. 选择运行来输出,然后点击 Next。 运行结果是按照年月日顺序排列的,并在这个列表的底部有最近的运行结果。
  5. 此时,您可以选择您想要输出的信息的类型。完成后点击 Finish

为了进一步分析,您可以以 XML 的格式输出测试日志。以 XML 的格式输出一个测试日志:

  1. 选择 File > Export。
  2. 在 Export 视图中,点击 Test execution history, 然后点击 Next
  3. 在 Export Test Execution History 视图中,浏览您想要储存这个日志的文件夹。然后点击 Next。 如果您只键入一个文件名,这个日志将会输出到文件中。
  4. 选择这个日志来输出,然后点击 Finish。

您可以输入整个报告,或者报告上的一个标签页到 HTML 格式。输出一个报告到 HTML:

  1. 在 Performance Test 运行视图中,右键点击报告或者标签来输出,然后选择 Export to HTML。
  2. Specify file path for HTML exported file 中,选择一个目录来存储新生成的报告,然后点击 Next。 尽管您当前的项目选项是默认的,但您也可以地在这个项目之外创建一个文件夹保存输出的报告。
  3. 点击 Finish。
  4. 可选的,为了进一步分析,您可以将这个输出报告粘帖到一个电子数据表程序中。

响应时间细分和资源监测数据

由于这里并没有进入细节部分(因为这篇文章已经够长了,而且其他人对这部分报告的了解可比我还多),但值得注意的是您仍可以包括为响应时间细分数据和资源监测数据的信息。资源监测数据由一系列定期收集的观察资料组成。您可以实时收集数据,或者您可以从 IBM Tivoli Enterprise™ Monitoring Server 得到它。除了响应时间细分数据,资源监测数据能够向您提供一个能够在问题决定方面有帮助的完整系统视图。这里有一些能够帮助您收集和分析的数据细分类别:

  • CPU 使用状况(总体的,为单个处理机的,或者甚至是为单个进程的)
  • 可用内存
  • 磁盘使用状况
  • TCP/IP 和网络吞吐量

这个特性为您的服务提供了更完整的视图来帮助分离问题。您可以利用 IBM Tivoli Monitoring 代理或者 Rational Performance Tester 在测试(或者这个代理)中监测这个系统。为了查看资源监测数据您可以利用 Profiling 和 Eclipse 的 Logging 视图。

当这个系统运行时,响应时间细分数据为您显示了被测试系统的每一部分所花费的时间。响应时间细分数据与从测试或者测试调度执行的 Web 服务调用关联在一起:

  • 确定代码问题
  • 了解哪个应用软件在哪个服务器上遇到了性能瓶颈
  • 进一步精确地确定哪个包、类或者方法导致了问题的发生

要获取响应时间细分数据,您必须在一个测试或者调度中启用响应时间细分,并且设置数据的被俘获数量。数据收集基础结构(当您安装 Rational Performance Tester 工具时您会看到它)来收集响应时间细分数据。要确定这个应用软件运行在哪个主机,以及您想要从哪个主机收集数据,就必须安装整个数据收集基础结构并运行它。另外,您必须配置(或者装置)每一个应用服务器来使用数据收集基础结构。

下一步

现在您了解了怎样进入报告并更改它们,花一点时间来运行各种计数器和可利用的报告。确保能够观察数据输出为不同的格式(尤其是 CSV)。对于大型测试,尝试过滤和改变您的时间段来看看您是否能够从结果中去除一些干扰数据。


相关主题


评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational, SOA and web services
ArticleID=239057
ArticleTitle=IBM Rational Tester for SOA Quality 的测试执行和性能报告
publish-date=07052007