loadrunner测试报告

LoadRunner测试结果分析一、LoadRunner测试结果分析之我见LoadRunner生成测试结果并不代表着这次测试结果的结束，相反，这次测试结果的重头戏才刚刚开始。

如何对测试结果进行分析，关系着这次测试的成功与否。

网上关于LoadRunner测试结果如何分析的介绍相当匮乏，在总结他人的观点和自己的实验体会基础上来介绍如何进行LoadRunner测试结果分析。

1. LoadRunner测试结果分析的第一步应该是查看分析综述（Analysis Summary），其包括统计综述（Statistics Summary）、事务综述（Transaction Summary）、HTTP 响应综述（HTTP Responses Summary）三部分。

在统计综述中查看Total Errors的数量，HTTP 响应综述中查看HTTP 404数量，若数值相对较大（HTTP 404则相对于HTTP 200），则说明系统测试中出错较多，系统系能有问题；另外查看事务的平均响应时间和其90%的事务平均响应时间，若时间过长，超过测试计划中的要求值，则说明系统的性能不满足我们的要求。

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

3. 接着分析事务平均响应时间（Average Transaciton Response Time），若事务平均响应时间曲线趋高，则说明被测系统处理事务的速度开始逐渐变慢，即被测系统随着运行时间的变化，整体性能不断下降。

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

原因是：被测系统处理事务能力下降，事务平均响应时间变长，在曲线上表现为缓慢上升；而并发事务达到一定数量时，被测系统无法处理多余的事务，此时曲线变现为趋于平稳；当一段时间后，事务不断被处理，其数量减少，在曲线上表现为下降。

性能测试报告模板[性能测试报告]一、概述本文是针对某款软件系统性能测试的报告，旨在评估该系统在不同负载下的稳定性和性能表现。

具体测试范围包括用户登陆、数据查询、操作流程等方面。

二、测试环境测试环境如下：服务器：XXX数据库：MySQL操作系统：Windows Server 2008 R2浏览器：Chrome、Safari等测试工具：LoadRunner三、测试方案本次测试主要针对以下方面：1.用户登陆:通过模拟用户登陆操作，测试系统对于并发登陆请求的响应性能。

2.数据查询:通过模拟大量数据查询操作，测试系统在并发查询时的稳定性和响应速度。

3.操作流程:通过模拟常用操作流程，测试系统在高压力下的稳定性和响应速度。

四、测试结果1.用户登陆方面：测试数据表明，系统在并发登陆请求达到100个时响应时间稳定在500ms左右，无明显的性能下降。

2.数据查询方面：测试数据表明，系统在并发查询请求达到500个时，响应时间在1秒左右，并无严重的性能下降。

但在超负载时会出现某些查询操作超时的情况。

3.操作流程方面：测试数据表明，系统在各种操作流程下的响应时间都比较稳定，且在并发操作压力下，系统有良好的稳定性和较快的响应速度。

五、性能改进建议基于以上测试数据和分析，我们提出以下性能改进建议：1.优化数据库设计和操作方式，提高查询和更新效率。

2.增加缓存机制，提高系统响应速度，减轻数据库负载。

3.优化系统代码，简化操作流程，提高系统稳定性和响应速度。

六、总结通过本次测试，我们对该系统的性能表现进行了评估，并提出了针对性的改进建议。

希望本报告能对公司的产品性能提升有所帮助。

1 衡量web 性能的基本指标（1）响应时间：响应时间=网络响应时间+应用程序响应时间，反映完成某个业务所需要的时间，响应时间通常随负载的增加而增加。

响应时间的单位一般为“秒”或者“毫秒”。

（2）吞吐量：反应系统处理能力指标，随着负载的增加，吞吐量往往增长到一个峰值后下降，队列变长。

通常情况下，吞吐量用“请求数/秒”或者“页面数/秒”来衡量。

（3）服务器资源占用：反应系统能耗指标。

随着用户和吞吐量的上升，服务器的资源会被占用的越来越多，直到服务器资源被完全占用。

资源利用率通常以占用最大值的百分比n%来衡量。

（4）轻负载区：随着用户数量的上升，响应时间基本上没有太大的变化，吞吐量随着用户的增加而增加，说明这个系统资源是足够的，所以没有出现响应时间和吞吐量的明显变化。

在这个状态下，系统完全能够轻松地处理业务，所以称之为轻负载区。

（5）重负载区：当用户数量继续上升，响应时间开始明显上升，吞吐量上升速度开始变慢，并且到达峰值，随后开始小幅回落，逐渐稳定。

在这个阶段中，系统已经达到了处理的高峰，由于资源的逐渐匮乏，吞吐量下降，而响应时间变长。

在这个状态下，说明系统资源已经高负荷使用，处理能力达到极限。

在重负载区有几个数据比较关键：轻负载区到重负载区分界点的用户数：这个用户数是系统最优的高性能用户数，系统资源正在被高效的分配和利用。

重负载区中的吞吐量峰值：这个峰值就是系统的最高处理能力，而同时的用户数也是系统所能达到的高性能处理能承受的用户数，在这个时刻资源利用率应该正好达到峰值。

重负载区到负载失效区分界点的用户数：这个用户数是系统所能达到性能需求的最大在线用户数，超过这个数目的用户将无法正常使用系统。

负载失效区：当用户数量继续增加，响应时间会大幅上升，而吞吐量会逐渐加速下降，资源被消耗殆尽。

当响应时间超出用户能够忍受的范围时，这部分用户将会选择放弃访问。

通过上面的说明可以看出一个系统最好能够工作在轻负载区，接近重负载区即可，不能出现系统进入负载失效区的情况。

LoadRunner⽣成测试报告//上⼀篇的代码有点问题，问题出在 web_reg_find()函数中，这个函数简单的说是搜索下⼀步操作的请求对象（html）页⾯中是否存在相应的⽂本字符串。

所以⽤在登录操作中，它搜索的是主页.html，⽤在注册中它搜索的就是注册页⾯，这⾥必须得感谢下51test论坛的luming同学帮我解决了这个问题。

（所以虽然可以回放成功，但其实只是运⽓好，上⼀篇的⽰例代码就不去修改了,去掉web_reg_find函数就⾏了）。

（⼀）代码1 Action()2 {3 /*集合点*/4 lr_rendezvous("同时登录");56 /*事务开始*/7 lr_start_transaction("login");89 //加载相应的url10 web_url("WebTours",11 "URL=http://127.0.0.1:1080/WebTours/",12 "Resource=0",13 "RecContentType=text/html",14 "Referer=",15 "Snapshot=t44.inf",16 "Mode=HTML",17 LAST);1819 //检查下⼀步操作请求对象（HTML页⾯）中是否存在相应的⽂本字符串20 web_reg_find("Text=Welcome,","Search=Body",LAST);2122 //登录23 web_submit_form("login.pl",24 "Snapshot=t45.inf",25 ITEMDATA,26 "Name=username", "Value={username}", ENDITEM,27 "Name=password", "Value={password}", ENDITEM,28 "Name=login.x", "Value=58", ENDITEM,29 "Name=login.y", "Value=11", ENDITEM,30 LAST);31 /*事务结束*/32 lr_end_transaction("login", LR_AUTO);33 return 0;34 }（⼆）设置、运⾏场景1. 运⾏Controller。

LoadRunner常见测试结果分析（转）
在测试过程中，可能会出现以下常见的几种测试情况：
一、当事务响应时间的曲线开始由缓慢上升，然后处于平衡，最后慢慢下降这种情形表明：
* 从事务响应时间曲线图持续上升表明系统的处理能力在下降，事务的响应时间变长；
* 持续平衡表明并发用户数达到一定数量，在多也可能接受不了，再有请求数，就等待；
* 当事务的响应时间在下降，表明并发用户的数量在慢慢减少，事务的请求数也在减少。

如果系统没有这种下降机制，响应时间越来越长，直到系统瘫痪。

从以上的结果分析可发现是由以下的原因引起：
1. 程序中用户数连接未做限制，导致请求数不断上升，响应时间不断变长；
2. 内存泄露；
二、CPU的使用率不断上升，内存的使用率也是不断上升，其他一切都很正常；
表明系统中可能产生资源争用情况；
引起原因：
开发人员注意资源调配问题。

三、所有的事务响应时间、cpu等都很正常，业务出现失败情况；
引起原因：
数据库可能被锁，就是说，你在操作一张表或一条记录，别人就不能使用，即数据存在互斥性；
当数据量大时，就会出现数据错乱情况。

LOADRUNNER稳定性测试报告1.引言稳定性测试是软件开发过程中非常重要的一环，它能够评估系统在长时间高负载条件下的表现，发现潜在的性能问题，并为性能优化提供依据。

本报告通过使用LOADRUNNER进行稳定性测试，对系统的稳定性进行评估，并提供相关测试结果和分析。

2.测试目标本次稳定性测试的目标是评估系统在长时间高负载情况下的性能表现，并寻找系统可能存在的潜在性能问题。

3.测试环境- 系统环境：Windows Server 2024-软件版本：LOADRUNNER12.5- 测试工具：LOADRUNNER Controller和LOADRUNNER Agent4.测试过程4.1准备阶段在测试之前，我们首先对系统进行了性能需求分析，并确定了测试场景、用户行为脚本和负载模型。

同时，我们对系统和测试环境进行了配置和准备，包括安装LOADRUNNER软件、配置测试环境、准备测试数据等。

4.2测试步骤我们按照预先确定的测试场景和负载模型，使用LOADRUNNER Controller进行测试。

测试期间，我们监控系统的性能指标，并记录关键数据，如响应时间、吞吐量和错误率等。

4.3结果分析执行稳定性测试后，我们对测试结果进行了整理和分析。

通过对比不同负载下的性能指标，我们可以评估系统在高负载情况下的可靠性和稳定性，并发现潜在的性能瓶颈和问题。

5.测试结果5.1响应时间在测试期间，我们记录了系统的平均响应时间，并根据负载情况绘制了相应的图表。

从结果可以看出，随着负载增加，系统的响应时间逐渐增加。

但整体来说，系统的响应时间在可接受的范围内，并没有出现明显的性能问题。

5.2吞吐量我们还记录了系统的吞吐量，即每秒钟处理的请求数量。

通过对比不同负载下的吞吐量，我们可以评估系统的处理能力。

测试结果显示，系统在高负载情况下的吞吐量仍然维持在较高的水平，没有出现明显的性能下降。

5.3错误率我们还跟踪了系统的错误率，即请求失败或出错的比例。

LoadRunner性能测试指标分析·Memory:·Available Mbytes简述：可用物理内存数.如果Available Mbytes的值很小（4 MB或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。

参考值：4 MB或更小，至少要有10%的物理内存值·Page/sec (Input/Out)简述：为了解析硬页错误，从磁盘取出或写入的页数。

一般如果Page/sec持续高于几百，那么您应该进一步研究页交换活动。

有可能需要增加内存，以减少换页的需求（你可以把这个数字乘以4k就得到由此引起的硬盘数据流量）。

Pages/sec的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所致。

参考值：·Page Fault简述：处理器每秒处理的错误页（包括软/硬错误）。

当处理器向内存指定的位置请求一页（可能是数据或代码）出现错误时，这就构成一个Page Fault。

如果该页在内存的其他位置，该错误被称为软错误（用Transition Fault/sec记数器衡量）；如果该页必须从硬盘上重新读取时，被称为硬错误。

许多处理器可以在有大量软错误的情况下继续操作。

但是，硬错误可以导致明显的拖延。

参考值：·Page Input/sec简述：为了解决硬错误页，从磁盘上读取的页数。

参考值：·Page reads/sec简述：为了解决硬错误页，从磁盘上读取的次数。

解析对内存的引用，必须读取页文件的次数。

阈值为>5.越低越好。

大数值表示磁盘读而不是缓存读。

参考值：·Cache Bytes简述：文件系统缓存，默认情况下为50%的可用物理内存。

如IIS5.0运行内存不够时，它会自动整理缓存。

需要关注该计数器的趋势变化。

该指标只显示最后一次观察的值，它不是一个平均值。

参考值：·pool paged bytes简述: 指在分页池中的字节数，分页池是系统内存中可供对象使用的一个区域。

软件测试实验报告loadrunner引言软件测试是保证软件质量的重要手段，而性能测试则是其中的一部分。

在实际应用中，软件的性能往往是用户持续使用的关键因素。

本实验通过使用LoadRunner工具对一个Web应用进行性能测试，旨在评估系统的可扩展性和稳定性。

实验目的1. 了解性能测试的概念和一般流程；2. 掌握LoadRunner工具的基本使用方法；3. 学会分析性能测试结果并调优。

实验环境- 操作系统：Windows 10- 浏览器：Google Chrome- LoadRunner版本：12.55实验步骤步骤一：录制脚本1. 打开LoadRunner主界面，在“组织测试”中选择“录制脚本”；2. 输入脚本名称，选择协议为“Web HTTP/HTML”，点击“开始录制”按钮；3. 在弹出的浏览器中输入被测应用的URL，进入应用的登录页面；4. 按照测试用例的要求进行操作，录制脚本过程中可以对测试步骤进行注释和标记；5. 完成录制后，点击“停止录制”按钮。

步骤二：设计场景1. 在LoadRunner主界面，选择“组织测试”中的“设计场景”；2. 在“设计场景”界面中，将录制的脚本添加到“事务”中，可以设置事务的名称和模式；3. 将事务进行参数化，设置不同的参数取值，以模拟用户的不同行为；4. 可以设置事务之间的延迟时间，模拟用户的思考和操作过程。

步骤三：运行测试1. 在LoadRunner主界面，选择“执行测试”；2. 在“执行测试”界面中，选择要执行的场景，设置并发用户数、循环次数等参数；3. 启动测试并观察测试过程中的各项指标的变化情况，包括响应时间、吞吐量、错误率等；4. 完成测试后，查看测试报告，分析测试结果。

步骤四：优化调整1. 根据测试报告，可以发现系统的瓶颈和性能问题所在；2. 可以对系统进行优化调整，比如增加硬件资源、调整系统配置、修改代码逻辑等；3. 重新运行测试，对比测试结果，看优化效果。

Loadrunner分析结果图说明1、Running Vusers图使用Vuser 图可以确定方案，执行期间Vuser 的整体行为。

X 轴表示从方案开始运行以来已用的时间。

Y 轴表示方案中的Vuser 数。

Vuser-Rendezvous 图主要反映Vuser 是在什么时候集合在这个点上,又是怎样的一个被释放的过程.图中可以看到在1分4秒的地方50个用户全部集中到达集合点，持续了5分48秒开始释放用户，整个过程持续了6分钟。

2、Hits per Second图“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。

通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。

通过对查看“每秒点击次数”，可以判断系统是否稳定。

系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。

3、Throughput图“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。

其度量单位是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。

可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。

X 轴表示从方案开始运行以来已用的时间。

Y 轴表示服务器的吞吐量（以字节为单位）。

“吞吐率”图和“点击率”图的区别：“吞吐率”图，是每秒服务器处理的HTTP申请数。

“点击率”图，是客户端每秒从服务器获得的总数据量。

4、Transaction Summary图对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。

5、Average Transaction Response Time图“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。

例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。

压力测试报告拟制Prepared By 日期Date审核Reviewed By 日期Date目录第1章系统概述 (4)第2章方案设计 (4)第3章方案一测试结果........................................................................ 错误!未定义书签。

3.1 方案摘要.................................................................................... 错误!未定义书签。

3.2 运行结果.................................................................................... 错误!未定义书签。

第4章方案二测试结果........................................................................ 错误!未定义书签。

4.1 方案摘要.................................................................................... 错误!未定义书签。

4.2 运行结果.................................................................................... 错误!未定义书签。

第5章结论............................................................................................ 错误!未定义书签。

第6章附录............................................................................................ 错误!未定义书签。

1.1 分析事务的响应时间第一步，看“Transaction Performance Summary”图，确认那个事务的响应时间比较大，超出了我们的标准。

看下图，login 事务的平均响应时间最长。

为了定位问题，明白为什么login 事务的响应时间比较长，现在我们要分解login 事务，分析该页面上每一个元素的性能。

在上图中，选择要分解的事务曲线，然后点鼠标右键，选择“Web Page Breakdown for login”1.2 分解页面通过分解页面可以得到：比较大的响应时间到底是页面的哪个组件引起的？问题出在服务器上还是网络传输上。

这里为了解说各个时间（比如：DNS 解析时间、连接时间、接受时间等）下面简单说一下浏览器从发送一个请求到最后显示的全过程。

1.浏览器向Web Server 发送请求，一般情况下，该请求首先发送到DNS Server 把DNS名字解析成IP 地址。

解析的过程的时间就是。

这个度量时间可以确定DNS 服务器或者DNS 服务器的配置是否有问题。

如果DNS Server 运行情况比较好，该值会比较小。

2.解析出Web Server 的IP 地址后，请求被送到了Web Server，然后浏览器和WebServer 之间需要建立一个初始化连接，建立该连接的过程就是。

这个度量时间可以简单的判断网络情况，也可以判断Web Server 是否能够响应这个请求。

如果正常，该值会比较小。

3. 建立连接后，从Web Server 发出第一个数据包，经过网络传输到客户端，浏览器成功接受到第一字节的时间就是。

这个度量时间不仅可以表示WebServer 的延迟时间，还可以表示出网络的反应时间。

4. 从浏览器接受到第一个字节起，直到成功收到最后一个字节，下载完成止，这段时间就是。

这个度量时间可以判断网络的质量（可以用size/time 比来计算接受速率）其他的时间还有SSL Handshaking（SSL 握手协议，用到该协议的页面比较少）、ClientTime （请求在客户端浏览器延迟的时间，可能是由于客户端浏览器的think time 或者客户端其他方面引起的延迟）、Error Time（从发送了一个HTTP 请求，到Web Server 发送回一个HTTP 错误信息，需要的时间）。

Jmeter与loadrunner性能测试工具对比报告测试范围：即时库存系统中选定的三个测试接口：订单取消接口，客户下单接口，wms出库完成接口；
测试环境：测试过程中所有硬件及软件资源均相同，包括压力机，应用服务器，数据库服务器，中间件服务器及相关配置。

每一轮测试结束后数据库数据均清空。

尽可能排除外部因素对本次测试结果的影响。

测试目的：验证两种性能测试工具本身对同一性能测试点的性能指标差异。

测试结果：如下图所示：
测试结论：
1、通过三个接口的测试发现两种工具本身在系统响应时间上的差别基本处在“十毫秒”量级
上。

2、jmeter相比loadrunner在系统响应时间上略短，系统处理能力略高；
测试问题：通过统计测试结果发现，jmeter在统计系统处理能力，即TPS时，它算出的结果不是平均值，是一个不断上升增加的状态，最后需要手动进行平均，该问题还需在后期测试中进一步验证。

工具使用可行性分析：
1、针对直接调用java代码的一些webservice接口、应用程序的性能测试。

2、数据库sql性能测试。

LoadRunner性能测试结果分析性能测试的需求指标：本次测试的要求是验证在30分钟内完成2000次⽤户登录系统，然后进⾏考勤业务，最后退出，在业务操作过程中页⾯的响应时间不超过3秒，并且服务器的CPU使⽤率、内存使⽤率分别不超过75%、70%LoadRunner性能测试结果分析内容：1、结果摘要LoadRunner进⾏场景测试结果收集后，⾸先显⽰的该结果的⼀个摘要信息，如图1- 2所⽰。

概要中列出了场景执⾏情况、“Statistics Summary（统计信息摘要）”、“Transaction Summary（事务摘要）”以及“HTTP Responses Summary（HTTP响应摘要）”等。

以简要的信息列出本次测试结果。

图1- 2性能测试结果摘要图场景执⾏情况：该部分给出了本次测试场景的名称、结果存放路径及场景的持续时间，如图1- 3所⽰。

从该图我们知道，本次测试从15:58:40开始，到16:29:42结束，共历时31分2秒。

与我们场景执⾏计划中设计的时间基本吻合。

图1- 3场景执⾏情况描述图Statistics Summary（统计信息摘要）该部分给出了场景执⾏结束后并发数、总吞吐量、平均每秒吞吐量、总请求数、平均每秒请求数的统计值，如图1- 4所⽰。

从该图我们得知，本次测试运⾏的最⼤并发数为7，总吞吐量为842,037,409字节，平均每秒的吞吐量为451,979字节，总的请求数为211,974，平均每秒的请求为113.781，对于吞吐量，单位时间内吞吐量越⼤，说明服务器的处理能越好，⽽请求数仅表⽰客户端向服务器发出的请求数，与吞吐量⼀般是成正⽐关系。

图1- 4统计信息摘要图Transaction Summary（事务摘要）该部分给出了场景执⾏结束后相关Action的平均响应时间、通过率等情况，如图1- 5所⽰。

从该图我们得到每个Action的平均响应时间与业务成功率。

注意：因为在场景的“Run-time Settings”的“Miscellaneous”选项中将每⼀个Action当成了⼀个事务执⾏，故这⾥的事务其实就是脚本中的Action。

（CPU,内存） 11.timeout的设置，thinktime的意义
使用率保持在70%-85%较理想，低了说明其它 瓶颈（或大型程序对CPU利用率不足）
Processor queue>2且CPU使用率过低说明系 统架构不理想
Processor queue>2且CPU使用率过高说明 CPU瓶颈
C/S系统中，CPU，内存若某一项根据用户请求 的增加而未发生增加一般是由硬件瓶颈造成
吞吐量（ Throughput ）
吞吐量极限为网络带宽的10%左右，若均值低于5% ， 基本可视为网络无瓶颈
一般随着负载的增加呈线性增长
每秒连接数（ Connections Per Second ）
当添加系统负载，而每秒连接数无明显增加时，一般为 服务器，数据库连接池限制
录制脚本：将所有功能录制在一个脚本中的不同 事务中
内存（Availiable bytes）
内存随着固定用户，固定操作，持续一段时间后 可用内存明显减少一般是发生内存泄露（稳定性 测试）
平均响应时间（ Average Transaction Response Time ）
衡量系统性能的重要参数 检查其有效性时一般采用对比，其他参数校验
对比：与不同负载时进行数值对比，一般会呈现线性增 长（针对大型软件），出现状态拐点时进行参数校验 其他参数校验：获取响应时间时看其他参数是否异常（比 如CPU，内存，吞吐量等）
状态
上升：指数函数一般性能较差，另一种为性能理想或系 统瓶颈
下降：出现情况比较少，一般是由于服务异常 水平：负载不够或瓶颈
周期性：波动较大的图形注意周期性
平稳状态线：状ห้องสมุดไป่ตู้相对比较稳定的状态 拐点：相对平稳状态间的拐点

LoadRunner报告分析报告1. 引言本文将对LoadRunner的报告进行详细分析，帮助读者了解应用测试的性能瓶颈和优化方向。

LoadRunner是一款常用的性能测试工具，通过模拟真实用户的行为对系统进行压力测试，从而评估系统的性能和可靠性。

2. 报告概览在本节中，我们将对LoadRunner报告的整体概况进行分析。

报告包括以下几个关键指标：2.1 响应时间分析LoadRunner报告提供了每个请求的平均响应时间、最大响应时间和最小响应时间等指标。

通过对这些指标的分析，我们可以了解系统在不同负载下的响应情况。

2.2 事务响应时间分布LoadRunner报告还提供了事务响应时间的分布情况。

通过观察事务响应时间的分布情况，我们可以了解系统中存在的性能瓶颈和优化的空间。

2.3 错误分析LoadRunner报告中的错误分析可以帮助我们定位系统中出现的错误，并分析错误的原因。

通过对错误的分析，我们可以找到系统中的问题，并提出相应的解决方案。

3. 响应时间分析在这一节中，我们将对LoadRunner报告中的响应时间进行详细分析。

通过对响应时间的分析，我们可以了解系统在不同压力下的性能表现。

3.1 平均响应时间平均响应时间是衡量系统性能的重要指标之一。

根据报告显示的平均响应时间，我们可以了解系统对用户请求的平均处理时间。

如果平均响应时间过长，说明系统的性能存在问题，需要进一步优化。

3.2 最大响应时间最大响应时间是指系统处理用户请求的最长时间。

通过分析最大响应时间，我们可以找到系统中存在的性能瓶颈。

如果最大响应时间过长，可能会导致用户体验不佳，需要优化系统的性能。

3.3 最小响应时间最小响应时间是指系统处理用户请求的最短时间。

通过分析最小响应时间，我们可以了解系统在轻负载下的性能表现。

如果最小响应时间过长，可能会导致用户等待时间增加，需要优化系统的性能。

4. 事务响应时间分布在这一节中，我们将对LoadRunner报告中的事务响应时间分布进行分析。

200个不同用户登陆结果分析1、L oadrunner测试结果分析如下:Summary（场景摘要）结果及分析如下:Secenario name 场景名称Results in session 场景运行的结果目录Duration 场景运行时间Maximum running vusers（场景最大用户数）Total throughput （bytes）（总带宽流量）Average throughput （bytes/second）（平均每秒宽带流量）Total hit（总点击数）Average hits per second（平均每秒点击数）图1-1此次测试我用了200个用户, 163个passed, 所以实际参与测试的虚拟用户总共有163个。

其中, 总的吞吐量为535484969bytes, 平均吞吐量为1459087bytes, 总的请求量为12321, 平均每秒请求量为33.572, 错误共有37个。

从该图可以看出, 该网页在用户登陆方面存在问题。

图1-2图1-3（注: Action.c(92): Error -27796: Failed to connect to server "61.177.55.188:8080": [10060] Connection timed out.Action.c(104).Erro.-27727.Ste.downloa.timeou.(12.seconds.ha.expire.whe.downloadin.reso urce(s).Se.th."Ste.Timeou.cause.b.resource.i..warning.Run-Tim.Settin.t.Yes/N.t.hav.thi.mes sag.a..warning/error.respectively.Error: missing newline in D:\Program Files\HP\LoadRunner\tutorial\账户登陆1\Name.dat）Running Vusers结果及分析如下:图2-1通过上面图形结果可知, 在刚开始虚拟用户为100个, 11s左右时达到200个, 从1min45s 后逐渐减少, 6min7s左右时用户全部退出访问。

六.结果分析

监控指标数据分析 1.最大并发用户数： 应用系统在当前环境（硬件环境、网络环境、软件 环境（参数配置））下能承受的最大并发用户数。 在方案运行中，如果出现了大于3个用户的业务操 作失败，或出现了服务器shutdown的情况，则说明 在当前环境下，系统承受不了当前并发用户的负载 压力，那么最大并发用户数就是前一个没有出现这 种现象的并发用户数。 如果测得的最大并发用户数到达了性能要求，且各 服务器资源情况良好，业务操作响应时间也达到了 用户要求，那么OK。否则，再根据各服务器的资源 情况和业务操作响应时间进一步分析原因所在。
三.新加监控图




通过graph—add new graph或者在会话浏览器 窗口右击选择add new item—add new graph来 打开新加监控图页面 新加监控图页面默认显示监控到数据的部分资 源，可以将右上角的display only graphs containting data不选查看所有资源。 常用的5种资源是：vuser、transactions、web resources、web page breakdown、system resources 点击工具栏上的合并图按钮，可选择两个不同 的监控图进行合并查看
内存资源成为系统性能的瓶颈的征兆: 很高的换页率(high pageout rate); 进程进入不活动状态; 交换区所有磁盘的活动次数可高; 可高的全局系统CPU利用率; 内存不够出错(out of m分析 4.处理器： UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增 加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server, 可接受的最大上限是80-85% 合理使用的范围在60%至70%。 Windows资源监控中，如果System\Processor Queue Length大于2， 而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。 CPU资源成为系统性能的瓶颈的征兆: 很慢的响应时间(slow response time) CPU空闲时间为零(zero percent idle CPU) 过高的用户占用CPU时间(high percent user CPU) 过高的系统占用CPU时间(high percent system CPU) 长时间的有很长的运行进程队列(large run queue size sustained over time)