loadrunner使用步骤说明Word格式文档下载.docx

上传人:b****7 文档编号:22643042 上传时间:2023-02-05 格式:DOCX 页数:16 大小:271.51KB
下载 相关 举报
loadrunner使用步骤说明Word格式文档下载.docx_第1页
第1页 / 共16页
loadrunner使用步骤说明Word格式文档下载.docx_第2页
第2页 / 共16页
loadrunner使用步骤说明Word格式文档下载.docx_第3页
第3页 / 共16页
loadrunner使用步骤说明Word格式文档下载.docx_第4页
第4页 / 共16页
loadrunner使用步骤说明Word格式文档下载.docx_第5页
第5页 / 共16页
点击查看更多>>
下载资源
资源描述

loadrunner使用步骤说明Word格式文档下载.docx

《loadrunner使用步骤说明Word格式文档下载.docx》由会员分享,可在线阅读,更多相关《loadrunner使用步骤说明Word格式文档下载.docx(16页珍藏版)》请在冰豆网上搜索。

loadrunner使用步骤说明Word格式文档下载.docx

如果是B/S的系统,请输入要访问的网址(如果访问本机,要用代替localhost,如)。

如果是C/S则为空。

Workingdirectory:

工具目录,也就是分析信息的保存路径。

RecordintoAction:

将录制结果放到Action里面

3.点击Options

在Recording界面选择HTML-basedscript

HTML-bsedscript是默认的模式,该模式可以为每个用户请求生成单独的函数.

URL-basedscript则可以捕获所有作为用户操作的结果发送到服务器的HTTP请求,然后一一记录下来.URL-basedscript模式甚至可以捕获非HTML应用程序,例如小程序和非浏览器应用程序.

使用HTML-basedscript录制的代码直观,易于理解和维护,而基于URL-basedscript模式录制生成的代码内容看起来会比较多,好象将HTML方式中的一个函数拆分成了很多独立的函数一样,但是这种代码的可伸缩性更强,记录了更详细的用户操作信息.

选择哪种模式应该根据实际需要来进行,下面是一些常见的参考原则:

1.基于浏览器的应用程序推荐使用HTML-basedscript

2.不是基于浏览器的应用程序推荐使用URL-basedscript

3.如果基于浏览器的应用程序中包含了javascript,并且该代码向服务器发送了请求,比如DataGrid的分页按钮等,推荐使用URL-basedscript;

4.基于浏览器的应用程序中使用了HTTPS安全协议,建议使用URL-basedscript方式录制.

如果使用HTML-basedscript模式录制后不能成功回放,可以考虑改用URL-basedscript模式来进行录制

点击PortMapping,Capturelever选WinINetleveldata

当capturelevel为Socketleveldata的时候将捕获HTTP、SMTP、POP3、IMAP、OracleNCA和WinSocket协议。

选择此选项将无法录制到Web项目的操作

当capturelevel为WinINetleveldata的时候将捕获HTTP、FTP、Gopher协议

当capturelevel为SocketleveldataandWinINetleveldata二者皆捕获

录制代码乱码问题:

选Advanced,Supportcharset选UTF-8

接下来,点击OK,开始录制,会自动启动配置的IE浏览器,跳转到指定的web项目地址。

接下来就可以对Web项目进行操作。

录制过程中通过Insertstarttransaction,insertendtransaction添加开始事务和添加结束事务,一个开始就应该对应一个结束。

事务(Transaction)用于模拟用户的一个相对完整的、有意义的业务操作过程,例如登录、查询、添加、删除,这些都可以作为事务,而一般不会把每次HTTP请求作为一个事务。

也可以在向导的第三步进行添加事务,还有检查点的添加。

具体操作步骤如下:

1、开始录制

2、点击事务开始按钮,输入“登录”

3、输入用户名密码点击登录按钮

4、点击事务结束按钮,确定。

(注意:

事务的开始与结束的名称一定要一致)

最后点击Stop按钮停止,生成代码。

5、点击Run按钮,不报错。

6、在Tools里面打开CreateControllerScenario

这里有两个选项:

手动设置场景和自动设置场景,一般选择手动设置场景。

将代码添加进去。

进行配置

Start总用户数,每隔15秒有2个用户加入进来。

十个用户访问5分钟。

每隔30秒,停止掉5个用户。

所对应的配置图如下:

点击Run开始

结构显示如下:

左上方显示的是当前的用户信息,右上方显示的是事务的信心,通过还是不通过等,中间左边是一些可供选择的信息,中间右边是具体的图形,点击图形,在下面显示对应的数值。

双击折线图,会放大,对应的数据在下方会显示。

在添加组运行的时候,分别有这样几个参数:

Down(还有剩余的用户,没有达到预期量的剩余人数),Pending(在等待期间),Init(初始化),Ready(预备),Run(运行),Rendez,Passed,Failed,Error,GradualExiting,Exiting,Stopped几个信息,在运行时,他们的和加起来是总的虚拟人数。

3、结果分析:

对应结果的简要分析主要看RunningVuseres,

TranResponseTime,Tran/Sec(Passed)和Throughput。

RunningVuseres:

表示当前的用户数。

TranResponseTime:

表示事务的响应时间。

Tran/Sec(Passed):

表示每秒钟通过的事务数。

Throughput:

表示吞吐量(服务器返回给客户端的所有字节数)。

详细的分析如下:

1.分析综述(AnalysisSummary),其包括统计综述(StatisticsSummary)、事务综述(TransactionSummary)、HTTP响应综述(HTTPResponsesSummary)三部分。

 MecuryLoadrunnerAnalysis中最常用的5种资源.

  1.Vuser虚拟用户

  2.Transactions事务

  3.WebResources网络资源

  4.WebPageBreakdown

5.SystemResources(主要包括:

CPU使用率、可用物理内存、CPU的队列长度)

在统计综述中查看“测试结果分析网址”2011/11/16Errors的数量,对于吞吐量,单位时间间内吞吐量越大,说明服务器的处理能越好,而请求数仅表示客户端向服务器发出的请求数,与吞吐量一般是成正比关系。

HTTP响应综述中查看HTTP404数量,若数值相对较大(HTTP404则相对于HTTP200),则说明系统测试中出错较多,系统系能有问题;

另外查看事务的平均响应时间和其90%的事务平均响应时间,若时间过长,超过测试计划中的要求值,则说明系统的性能不满足我们的要求。

2.LoadRunner测试结果图,首先对事务综述(TransactionSummary)进行分析,该图可以直观地看出在测试时间内事务的成功与失败情况,所以比第一步更容易判断出被测系统运行是否正常。

事务平均响应时间(AverageTransacitonResponseTime),若事务平均响应时间曲线趋高,则说明被测系统处理事务的速度开始逐渐变慢,即被测系统随着运行时间的变化,整体性能不断下降。

当系统性能存在问题时,该曲线的走向一般表现为开始缓慢上升,然后趋于平稳,最后缓慢下降。

原因是:

被测系统处理事务能力下降,事务平均响应时间变长,在曲线上表现为缓慢上升;

而并发事务达到一定数量时,被测系统无法处理多余的事务,此时曲线变现为趋于平稳;

当一段时间后,事务不断被处理,其数量减少,在曲线上表现为下降。

如果被测系统没有等待机制,那么事务响应时间会越来越长,最后系统崩溃。

每秒通过事务数(TransactionsperSecond/TPS),该曲线表示被测系统在运行的任意时刻,每个事务通过、失败的情况,其是考查系统性能的一个重要参数。

若随着压力的增加,曲线如果开始变化缓慢或有平稳的趋势,则有可能是服务器开始出现瓶颈。

意思就是增加压力的时候,每秒的事务量会减小!

每秒通过事务总数(TotalTransactionsperSecond),该曲线显示在任意时刻被测系统通过的事务总数、失败的事务总数。

该曲线走向和TPS曲线走向一致。

事务性能摘要(TransactionPerformanceSunmmary)该曲线表示被测系统中所有事务的最小、最大和平均事务响应时间。

事务平均响应时间和他90%的平均响应时间,若时间过长,查过测试计划中的要求值。

则说明系统不满足我们的要求。

3对于Vusers的测试图有3种:

RunningVusers、VusersSummary、Rendezvous,其中RunningVusers(虚拟用户的数量)是关于虚拟用户加压、施压、减压的情况图;

VusersSummary是用户运行结果的综述图;

Rendezvous是虚拟用户的集合点情况图。

4.对于Errors的分析,若是在上述测试中发现被测系统运行中有很多错误,则Errors测试结果有分析的必要,否则,就不必发费时间在Errors上了。

其主要包括ErrorStatistics、ErrorStatistics(bydescription)、ErrorsperSecond(bydescription)、ErrorsperSecond、TotalErrorssperSecond,ErrorStatistics是带有错误代码编号的饼状图,ErrorStatistics(bydescription)不仅有错误代码编号,而且带有错误消息,ErrorsperSecond是每秒错误数的曲线图,ErrorsperSecond与ErrorsperSecond(bydescription)的区别也是在于是否带有错误消息。

TotalErrorssperSecond是被测系统每秒错误总数的曲线图。

若要对系统进行错误分析,则ErrorStatistics与ErrorStatistics(bydescription)、ErrorsperSecond(bydescription)与ErrorsperSecond

择其一即可,不过带有错误描述的图更加具体。

5.WebResources测试主要是对Web服务器性能的分析。

每秒点击次数(HitsperSecond)是Vusers每秒向Web服务器提交的HTTP请求数。

查看其曲线情况可以判断被测系统是否稳定,曲线呈下降趋势表明Web服务器的响应速度在变慢,当然其原因可能是服务器瓶颈问题,但是也有可能是Vusers数量减少,访问服务器的请求减少。

点击数:

不是根据用户的鼠标点击次数计算,而是根据客户端向服务器发起的请求次数计算。

例如:

若一个页面里包含10张图片,那么在访问该页面时,鼠标仅点击1次,但是服务器收到的请求数却为1+10(每张图片都会向服务器发出请求)。

此时其点击次数为11。

吞吐量(Throughput)度量单位是字节,另外也有兆字节,其是度量服务器性能的重要指标,表示服务器在任意时间的吞吐能力,即任意时间服务器发送给

Vusers的流量。

吞吐率=吞吐量/测试时间,单位时间里服务器发送给Vusers的流量。

点击率=吞吐量/测试时间,单位时间里Vusers发送给服务器的HTTP请求数。

状态代码概要(HTTPStatusCodeSummary)表示从服务器返回的带有HTTP状态的数量分布。

其HTTP状态有HTTP200、HTTP302、HTTP404、HTTP500等。

该图可以容易看出HTTP响应状况。

各个状态所表示的含义是:

2XX表示客户端请求成功,服务器已成功接收客户端的请求

3XX表示重定向客户端浏览器必须采取更多的操作来实现请求

302对象已经移动

400无法解析此请求。

HTTP400相对于HTTP200的错误数较多的话就说明系统有问题。

XX:

访问由于凭据无效被拒绝。

XX:

访问由于服务器配置倾向使用替代身份验证方法而被拒绝。

访问由于ACL对所请求资源的设置被拒绝。

Web服务器上安装的筛选器授权失败。

ISAPI/CGI应用程序授权失败。

由于Web服务器上的URL授权策略而拒绝访问。

403禁止访问:

访问被拒绝。

禁止访问:

执行访问被拒绝。

读取访问被拒绝。

写入访问被拒绝。

需要使用SSL查看该资源。

需要使用SSL128查看该资源。

客户端的IP地址被拒绝。

需要SSL客户端证书。

客户端的DNS名称被拒绝。

太多客户端试图连接到Web服务器。

Web服务器配置为拒绝执行访问。

密码已更改。

服务器证书映射器拒绝了客户端证书访问。

客户端证书已在Web服务器上吊销。

在Web服务器上已拒绝目录列表。

Web服务器已超过客户端访问许可证限制。

客户端证书格式错误或未被Web服务器信任。

客户端证书已经到期或者尚未生效。

无法在当前应用程序池中执行请求的URL。

无法在该应用程序池中为客户端执行CGI。

Passport登录失败。

404找不到文件或目录。

文件或目录未找到:

网站无法在所请求的端口访问。

需要注意的是错误只会出现在具有多个IP地址的计算机上。

如果在特定IP地址/端口组合上收到客户端请求,而且没有将IP地址配置为在该特定的端口上侦听,则IIS返回HTTP错误。

例如,如果一台计算机有两个IP地址,而只将其中一个IP地址配置为在端口80上侦听,则另一个IP地址从端口80收到的任何请求都将导致IIS返回错误。

只应在此服务级别设置该错误,因为只有当服务器上使用多个IP地址时才会将它返回给客户端。

文件或目录无法找到:

锁定策略禁止该请求。

MIME映射策略禁止该请求。

405用于访问该页的HTTP动作未被许可。

406客户端浏览器不接受所请求页面的MIME类型。

407Web服务器需要初始的代理验证。

410文件已删除。

412客户端设置的前提条件在Web服务器上评估时失败。

414请求URL太大,因此在Web服务器上不接受该URL。

500服务器内部错误;

系统开发程序写的有问题;

系统不兼容;

参数化的时候取值有问题等等

服务器错误:

Web服务器上的应用程序正在关闭。

Web服务器上的应用程序正在重新启动。

Web服务器太忙。

服务器上的无效应用程序配置。

不允许直接请求。

UNC授权凭据不正确。

URL授权存储无法找到。

URL授权存储无法打开。

该文件的数据在配置数据库中配置不正确。

URL授权域无法找到。

500100内部服务器错误:

ASP错误。

501标题值指定的配置没有执行。

502Web服务器作为网关或代理服务器时收到无效的响应。

每秒HTTP响应数(HTTPResponsesperSecond)表示每秒从服务器返回的HTTP状态的曲线图。

其和HTTPStatusCodeSummary不同在于后者是总体数量分布,而它是分布在时间段上的平均分布状况。

6.页面诊断(WebPageDiagnostics)可以很好地定位环境问题,如客户端问题、网络问题等,也可以很好的分析系统本身的问题,如网页问题。

(1)WebPageDiagnostics(网页诊断)对测试过程中所有的页面进行一个信息汇总,可以很容易地观察出哪个页面下载耗时,然后选择该页面得其页面分解图,分析耗时原因。

WebPageDiagnostics是一个汇总图,选择要分析的页面,可得到其4张图:

DownloadTime、Component(OverTime)、DownloadTime(OverTime)、TimeToFirstBuffer(OverTime)。

DownloadTime分析页面不同组件在不同阶段的所需时间,其阶段主要包括:

DNSResolution:

DNS域名解析所需的时间;

Connect:

与Web服务器建立初始连接所需的时间;

SSLHandshaking:

建立SSL连接所用的时间;

FTPAuthentication:

认证客户端所需的时间;

FirstBuffer:

初始HTTP请求至WEB服务器响应成功所需的时间;

ReceiveTime:

浏览器从服务器接受字节并完成下载所经时间;

ClientTime:

因思考时间或其它客户端问题导致的请求发生延迟所经时间;

Error:

从发出HTTP请求到接收到错误消息所需的时间。

这样就可以分析出时间花费在哪里,进而定位问题。

Component(OverTime)页面上不同组件在不同时间的平均下载时间曲线图。

DownloadTime(OverTime)不同组件在不同时间的平均下载时间面积图。

TimeToFirstBuffer(OverTime)不同组件不同时间第一次缓冲时间面积图。

(2)PageComponentBreakdown不同组件的平均响应时间占整个页面平均响应时间的百分比,此为饼状图,可以很容易的分析出页面的那个组件耗时较多。

(3)PageComponentBreakdown(OverTime)任意时间不同组件的响应时间曲线图。

(4)PageDownloadTimeBreakdown页面中不同组件在不同阶段的柱状图,容易看出不同阶段所占面积大小。

(5)PageDownloadTimeBreakdown(OverTime)任意时间不同组件在不同阶段响应时间曲线图。

(6)TimetoFirstBufferBreakdown不同页面第一次缓冲并下载完成所需时间的柱状图,此图在分析测试结果时十分重要,其不仅能分析出哪个页面耗费时间长,而且能分析出之所以耗时是网络问题还是服务器问题。

FirstBufferTime分为NetworkTime和ServerTime,客户端发出http请求并接收到服务器端的应答报文(ACK)所经时间为NetworkTime,客户端从接收到ACK到完成下载所经时间为ServerTime。

若ServerTime明显大于NetworkTime且是其几倍,此时服务器性能是问题关键。

(7)TimetoFirstBufferBreakdown(OverTime)不同页面在任一时间点的NetworkTime和ServerTime分布曲线图。

(8)DownloadComonentSize(KB)不同页面在载整个下载量所占百分比例图。

在对于页面诊断的分析中,应先查看PageComponentBreakdown,分析哪个页面所占比例较大,然后分析其是不是造成耗时的原因。

若是,再查看TimetoFirstBufferBreakdown,分析出其是网络问题,还是服务器问题。

再分析TimetoFirstBufferBreakdown(OverTime)中的曲线,进一步分析原因。

可以进一步查看WebPageDiagnostics做具体分析。

在运行期间,图表的下方,对应的有状态,颜色,规模,最大值,最小值,平均值,标准值和最终值都会有明显的记录。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 党团工作 > 入党转正申请

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1