性能测试分析-Graph Analysis

Version 1.0

Author ZongYu.Yao

Write By :2010-8-21 记录更改历史

总的来说，无论是做功能测试还是做性能测试，我们分析、比对的基础都是基于被用户确认的《用户需求规格说明》来进行的。

这里就简单的从几个图来做一个小的分享，要能够对系统的性能进行分析，那么首先我们应该看懂各个反映系统情况的图表。

以下图表的场景为：

10个Vuser做登录，未做集合点，未在VuGen中添加相应的事务（仅做了动态数据的关联）

场景的创建方式：手工创建场景（未按百分比划分虚拟用户）。

场景的设定为：

Controller中的RunTimeSetting值均为组件缺省值。

相应的VuGen脚本语言为：

Action()

{

// [WCSPARAM WCSParam_Diff1 36 103871.085297691fDtcizipQfDcAfHpcVDH] Parameter {WCSParam_Diff1} created by Correlation Studio

web_reg_save_param("WCSParam_Diff1",

"LB=userSession value=",

"RB=>",

"Ord=1",

"RelFrameId=1.2.1",

"Search=Body",

"IgnoreRedirections=Yes",

LAST);

web_url("WebTours",

"URL=http://127.0.0.1:1080/WebTours/",

"TargetFrame=",

"Resource=0",

"RecContentType=text/html",

"Referer=",

"Snapshot=t1.inf",

"Mode=HTML",

LAST);

lr_think_time(10);

web_submit_data("login.pl",

"Action=http://127.0.0.1:1080/WebTours/login.pl",

"Method=POST",

"TargetFrame=",

"RecContentType=text/html",

"Referer=http://127.0.0.1:1080/WebTours/nav.pl?in=home",

"Snapshot=t2.inf",

"Mode=HTML",

ITEMDATA,

"Name=userSession", "Value={WCSParam_Diff1}", ENDITEM,

"Name=username", "Value=yyl", ENDITEM,

"Name=password", "Value=123", ENDITEM,

"Name=JSFormSubmit", "Value=on", ENDITEM,

"Name=login.x", "Value=57", ENDITEM,

"Name=login.y", "Value=9", ENDITEM,

LAST);

web_url("SignOff Button",

"URL=http://127.0.0.1:1080/WebTours/welcome.pl?signOff=1",

"TargetFrame=body",

"Resource=0",

"RecContentType=text/html",

"Referer=http://127.0.0.1:1080/WebTours/nav.pl?page=menu&in=home",

"Snapshot=t3.inf",

"Mode=HTML",

LAST);

return 0;

}

VuGen中的RunTimeSetting设置为：组件启动后的缺省设置。

1、我们需要关注VUSER这个表，这个表所反馈的是在场景执行过程中，我们的

虚拟用户数变化的一个情况。如：

从该图中我们可以得出系统在1：00分钟的时候，所加载的虚拟用户数为最大值。持续时间为：2分05秒左右。

PS：在VUSER的图形中，需要关注的就是VUSER表，如果在场景中我们加入了Rendezvous。那么我们还需要调出Rendezvous图表，分析系统的并发情况。（该文档中所涉及的场景未做Rendezvous的添加，故未对该图表进行调出分析）。

2、我们需要关注的第二个比较重要的表是Transaction下面的Avg Transaction

Response Time

对于平均事物响应时间的分析可以直接帮助我们分析得出，事物响应时间的

一个趋势（系统对于事物的平均响应时间越长，表示系统处理一个事物所需

要的时间越长，那么处于等待队列中的请求，被响应到处理完成所需要的时

间就会越长）。

3、第三个较重要的Transaction相关的图

TPS（Transaction Per Second）

TPS一定程度上的与我们的ATRT是相关的。很简单：平均事务响应时间越长，

那么我们的什么？TPS就会越低。两者从比例上来说是成反比的，一高就会

一低。该数据值越高，表明被测的系统处理能力越强。

从上图我们可以得出系统在1分13秒左右的时候TPS为1.5个，我们说，TPS

数值的大小反映了系统的最大处理能力。那么这里的最高值是不是就可以说

我们系统的最高处理能力就是1.5个事务呢？

这里是不能这么说的，原因是因为，TPS还受着负载的影响，会随着负载的

增加一开始是逐渐增加（什么原因？读者想必都已经理解到了，呵呵），当系

统进入繁忙期后，TPS就会有所下降。所以，我们还需将TPS的图表结合Vuser

的图表进行分析，查看1.5TPS值出现的时间点，我们的负载是多少。

4、Transaction Summary图