LoadRunner测试结果分析
LoadRunner性能测试报告讲解
xxx系统性能测试报告姓名：班级：学号：目录1 前言 (3)2 被测系统定义 (3)2.1 功能简介 (3)2.2 性能测试指标 (3)3 系统结构及流程 (4)3.1 系统总体结构 (4)3.2 功能模块 (4)3.3 业务流程 (5)3.4 关键点描述 (5)3.5 性能测试环境 (5)4 性能测试 (6)4.1 性能测试概述 (6)4.2 测试目的 (6)4.3 测试方法及测试用例 (6)4.4 测试指标及期望 (7)4.5 测试数据准备 (8)4.6 运行状况记录 (9)5 测试过程及结果描述 (9)5.1 测试描述 (9)5.2 测试场景 (10)5.3 测试结果 (10)6测试分析和结论 (14)1前言目前，随着Web Tours订票系统在生产状态下日趋稳定、成熟，系统的性能问题也逐步成为了我们关注的焦点：随着订票过程中大数据量的“冲击”，在客户信息信息进入时，系统能稳定在什么样的性能水平，面临公司业务冲刺时，系统能否经受住“考验”，这些问题需要通过一个完整的性能测试来给出答案。
本报告前部分即是基于上述考虑，参考科学的性能测试方法而撰写的，用以指导即将进行的Web Tours订票系统的性能测试。
2HP Web Tours系统定义HP Web Tours 订票系统作为本次测试的被测系统，该业务系统的主要功能包括：搜索航班，预订机票并查看航班路线。
在本次测试中，将针对上述的功能进行压力测试，检查并评估在模拟环境中，系统对负载的承受能力，在不同的用户连接情况下，系统地吞吐能力和响应能力，以及在预计的数据容量中，系统能够容忍的最大用户数。
2.1功能简介HP Web Tours主要功能如下：➢用户注册➢登录➢查询航班2.2性能测试指标本次测试是针对HP Web Tours订票系统的性能特征和系统的性能调优而进行的，主要需要获得如下的测试指标。
1、系统的响应能力：即在各种负载压力情况下，系统的响应时间，也就是从客户端交易发起，到服务器端交易应答返回所需要的时间，包括网络传输时间和服务器处理时间。
LoadRunner常见测试结果分析（转）
LoadRunner常见测试结果分析（转）
在测试过程中，可能会出现以下常见的几种测试情况：
一、当事务响应时间的曲线开始由缓慢上升，然后处于平衡，最后慢慢下降这种情形表明：
* 从事务响应时间曲线图持续上升表明系统的处理能力在下降，事务的响应时间变长；
* 持续平衡表明并发用户数达到一定数量，在多也可能接受不了，再有请求数，就等待；
* 当事务的响应时间在下降，表明并发用户的数量在慢慢减少，事务的请求数也在减少。
如果系统没有这种下降机制，响应时间越来越长，直到系统瘫痪。
从以上的结果分析可发现是由以下的原因引起：
1. 程序中用户数连接未做限制，导致请求数不断上升，响应时间不断变长；
2. 内存泄露；
二、CPU的使用率不断上升，内存的使用率也是不断上升，其他一切都很正常；
表明系统中可能产生资源争用情况；
引起原因：
开发人员注意资源调配问题。
三、所有的事务响应时间、cpu等都很正常，业务出现失败情况；
引起原因：
数据库可能被锁，就是说，你在操作一张表或一条记录，别人就不能使用，即数据存在互斥性；
当数据量大时，就会出现数据错乱情况。
利用LoadRunner进行性能测试和结果分析
在场景执行的时候,虚拟用户的事务执行生成了结果数据,为了在执行测试期间监控场景的执行情况,我们可以用loadrunner的在线监测工具.为了观察执行结束后的总结情况, 你可以用下列工具:➤虚拟用户的执行日志文件包含了每个虚拟用户在场景中运行的所有记录,这些文件位于场景结果文件的目录中.(在单个用户的执行模式下,这些文件位于脚本目录中)➤控制器的输出窗口显示了场景执行的过程,如果场景执行失败,可以在这个输出窗口中找到有用的调试信息.➤分析图表帮助你定位系统的性能表现,并且提供有关事务和虚拟用户的有用信息,你也可以通过关联不同运行场景的结果到一个图表中来比较不同的图表,从而更加准确的定位性能问题➤图表数据和原始数据视图用Excel格式显示了生成图表数据的真实原始数据, 为了更深入的分析,你也可以把这些文件存储起来.➤分析模块提供的报告功能让你可以从整体上浏览整个性能的报告,包括每个图表的数据,你也可以创建一个Word格式的文件,其中会自动创建用户需要的各种格式.分析模块提供的常用图表可以分为以下一些主要类别:➤虚拟用户图表提供了虚拟用户的状态和统计信息➤错误信息图表提供了场景中错误发生的信息➤事务图表提供事务的性能和响应时间信息➤Web资源图表提供了吞吐量,每秒点击,HTTP每秒响应,每秒重试次数和web用户每秒下载页面的信息等➤Web页面细分图提供每个Web页面组件的大小和下载时间图等➤用户自定义数据点图提供用户自定义数据点的信息图等➤系统资源图表提供场景执行期间我们通过计数器添加的系统的资源统计信息➤网络监控图表提供网络延迟的图表信息➤防火墙服务器监控图表提供防火墙服务器的资源图表➤Web 服务器资源图表提供Web服务器比如Apache, IIS服务器等的资源使用信息➤Web 应用服务器图表提供各种web应用服务器的资源使用情况➤数据库服务器资源图表提供数据库服务器的资源使用情况此外,还提供了其他一些不太常用的图表信息,图表信息的多少取决于你的被测对象和场景中监控器以及计数器的选择情况. 下次我们会重点分析虚拟用户图表. 今天主要介绍虚拟用户类型和错误类型两种图表虚拟用户类型的图表可以提供三个图，分别是：* 运行虚拟用户图* 虚拟用户汇总图* 集合点图其中虚拟用户图显示的是执行负载测试的每一秒执行脚本的虚拟用户个数，以及他们的状态。
loadrunner结果分析
loadrunner结果分析LoadRunner结果分析文章分类:综合技术LoadRunner结果分析器(以下简称Analysis或Analysis模块)是一个独立的模块，它可以将测试结果和监控数据转化为数据库数据，以利于分析处理。
测试人员可以在分析器中选择感兴趣的图标，通过合并图，交叉图和自动关联等手段，对测试结果和监控数据进行分析处理，以确定性能瓶颈及其产生原因。
最后，分析器可以根据测试人员选择的感兴趣部分，自动生成HTML格式或Word格式的性能报告，这些报告可以作为福建，和性能测试报告一起提交，提供性能参考。
LoadRunner Controller在测试结束后，可以自动从压力产生器上将测试结果收集起来，并且和监控数据一起，生成结果数据，保存在设置的运行结果目录中。
分析器启动时，如果压力产生器在远端机器上，又没有选择自动收集数据，则会先收集测试结果数据。
否则会打开运行结果文件，将结果文件经过处理后导入到Microsoft Access数据库，然后按照设置的模板自动打开某些结果分析图。
——————————————现对各种图做一个简要总结————————————1、分析概要2、 Vuser图: 主要包括正在运行的Vuser图、 Vuser概要图、集合图。
此图可用于确定任何给定环境中服务器上的Vuser负载。
默认情况下，此图仅显示状态为运行的Vuser。
要查看其他的Vuser状态，请将筛选条件设置为所需的状态(^_^ ^_^ 我至今还没有找到设置筛选条件的地方)。
3、事务图:运行场景或会话步骤之后，可以使用一个或多个事务图分析测试过程中执行的事务。
事务图主要包括:平均事务响应时间图、每秒事务数图、每秒事务总数 ... ...3.1、平均事务响应时间图: 对于每个方式，此图将以不同的方式显示。
关于粒度的选择，差资料 ... ...注意: 默认情况下，只显示已通过的事务。
你可以将平均事务响应时间图与正在运行的Vuser图进行比较，了解正在运行的Vuser的数目对事务性能时间产生的影响。
LoadRunner性能测试指标分析
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 Analysis进行分析的第一步是看测试结果的综合报告，当发现事务运行不正常时，才需要进行更深入的分析。
1、用户事务分析。
“用户事务”主要针对业务而言，一个“用户事务”通常由一个或一系列的用户操作组成。
Action是用户的一系列操作的组合；Transaction是用户的某一具体的动作。
与用户事务相关的图表有以下8个（1）事务综述图（Transaction Summary）通过此图可以看出每个事务在测试时间内分别通过（Pass）和失败（Fail）了多少（2）事务平均响应时间分析图（Average Transaction Response Time）此图显示测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析应用系统的性能走向；另外还可以统计出测试场景运行时间内各事务的最大值、最小值、平均值等信息。
（3）每秒通过事务数分析图（Transactions per Second）TPS图显示在场景运行的每一秒中，每个事务通过的数量，通过它可以确定系统在任何给定时刻的实际事务负载；可以将TPS图与平均事务响应时间图进行对比，以分析事务数目对执行时间的影响。
（4）每秒通过事务总数分析图（Total Transactions per Second）“每秒通过事务总数分析”图显示场景运行时，在每一秒内通过的事务总数。
如果系统性能稳定，在同等压力下，此图应该接近直线，而不是逐渐倾斜。
与TPS相比，“每秒事务总数”关注服务器整体处理事务的情况，是宏观概念。
（5）事务性能摘要图（Transaction Performance Summary）“事务性能摘要”显示方案中所有事务的最小、最大和平均时间，可以直接判断响应时间是否符合用户的需求。
可以通过网页细分方法来分析某些响应时间长的事务。
（6）事务响应时间与负载分析图（Transaction Response Time Under Load ）这个分析图是“正在运行的虚拟用户”图和“平均事务响应时间”图的组合。
LoadRunner 测试结果分析
Transactions（用户事务分析）用户事务分析是站在用户角度进行的基础性能分析。
1、Transation Sunmmary（事务综述）对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。
2、Average Transaciton Response Time（事务平均响应时间）“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。
例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。
3、Transactions per Second（每秒通过事务数/TPS）“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。
通过它可以确定系统在任何给定时刻的时间事务负载。
分析TPS主要是看曲线的性能走向。
将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。
例：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。
4、Total Transactions per Second（每秒通过事务总数）“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。
5、Transaction Performance Sunmmary（事务性能摘要）“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是否符合用户的要求。
重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。
6、Transaction Response Time Under Load（事务响应时间与负载）“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性能数据，为扩展用户系统提供参考。
Loadrunner_PTS_Jmeter性能结果分析
PTS、Jmeter、LoadRunner压测对比（简单web压测）阿里云性能测试（Performance Testing）是全球领先的SaaS性能测试平台，具有强大的分布式压测能力，可模拟海量用户真实的业务场景，让应用性能问题无所遁形。
性能测试包含两个版本，Lite版适合于业务场景简单的系统，免费使用；企业版适合于承受大规模压力的系统，同时每月提供免费额度，可以满足大部分企业客户。
主要优势有：专业：分布式并发压测，施压能力无上限；模拟业务场景，性能缺陷暴露无疑；阿里性能专家在线，测试无忧。
易用：平台提供压测机，无需安装软件；脚本场景监控简单化，省时省力；1分钟上手，轻轻松松做性能测试。
经济：提供企业版免费额度，零成本使用；提前容量评估，促进业务快速发展；提升用户体验，快速扩大市场份额。
可靠：服务高质量容灾，可用性高达99.99%；测试结果真实准确；多种安全防护措施，保障数据安全。
用淘宝帐号/1688账号登陆，没有可以注册一个阿里云账号PTS Lite（简易版）: https:///lite/index.htmPTS (企业版): https:///aliyun/性能测试学习中心: https:///#/pub/ptsBBS论坛：/thread/243.html旺旺技术支持群：1473075831一、简单Web压测场景：场景：10个并发（立即启动），运行时间为10min，关闭（立即关闭）压测：简单web压测，http GET请求压测二、PTS、Jmeter、LoadRunner压测对比（功能（议增加Sampler:基本功能：（增加（（（具录制脚本（单录制/编写测试脚本：基本功能：（或编写脚本（缺点：（测使用复杂测试任务设计：执行10分钟（（INFOINFO/WARN/ERROR级别的日志；WARNWARN/ERRORERROR志（如想控制压测请求的发送频率，可设置步调时间；一但设置在指定的单位时间内只会发送一次压测请求，详见步调时间说明（发为测试任务：（进行排期设置，设定任务运行时间（行监控（个场景线程组设置：基本功能：（发用户数，准备时间，循环次数，运行时间（常规、梯度模式，目标模式需设置定时器，复杂基本功能：图形（Think Time 杂缺点：（支持并发较少（要了解各参数含义，业务规则较多实时监控结果显示（业务指标、ECS 指标、RDS 指标）：基本功能：（响应时间，并发数，请求状态（网络，磁盘（连接数，容量，缺点：（里云购买的ECS/RDS/SLB 缺点：详情，监控较少LoadRunner 基本功能：（（自定义选择，看（行状态（详情缺点：（下载测试结果：可通过聚合报告查看缺点：（（LoadRun 测试结果：通过Summary结果查看基本功能：（试结果编辑（保存缺点：（PTS使用阿里云ECS服务器进行压测，施压机与被压机都是阿里云ECS LoadRunner和Jmeter使用本地机器进行压测通过本地ping服务器，看响应时间大约在30ms左右。
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），若事务平均响应时间曲线趋高，则说明被测系统处理事务的速度开始逐渐变慢，即被测系统随着运行时间的变化，整体性能不断下降。
当系统性能存在问题时，该曲线的走向一般表现为开始缓慢上升，然后趋于平稳，最后缓慢下降。
原因是：被测系统处理事务能力下降，事务平均响应时间变长，在曲线上表现为缓慢上升；而并发事务达到一定数量时，被测系统无法处理多余的事务，此时曲线变现为趋于平稳；当一段时间后，事务不断被处理，其数量减少，在曲线上表现为下降。
LoadRunner性能测试报告
性能测试报告一、被测项目简介本次测试的对象是LR自带的飞机订票系统，该系统的类型是浏览器/服务器类型。
该系统包含的功能主要有用户登陆，选择出发地和目的地、选择出发时间和座位类型、选择航班功能、支付退出登录等。
二、测试规划➢测试计划➢测试重点本次的测试重点主要有：●用户登录功能●选择出发地和目的地功能➢测试环境●软件配置：Windows7旗舰版32位操作系统；HP LoadRunner 11.00Google Chrome 浏览器IE浏览器●硬件条件：处理器：Intel(R)Core(TM)*******************内存：2GB三、测试用例设计本次实验主要的测试方面是用户登录和航班选择，提前注册好十个账号，和十种不同的但正确的航班选择；并用于接下来的参数化。
十组账号信息如下：航班信息如下：四、测试脚本1.录制的脚本+说明录制的脚本如下：vuser_init(){return 0;}Action(){web_url("WebTours","URL=http://127.0.0.1:1080/WebTours/","Resource=0","RecContentType=text/html","Referer=","Snapshot=t1.inf","Mode=HTML",LAST);lr_think_time(19);lr_start_transaction("login"); //定义事务登录web_submit_form("login.pl","Snapshot=t2.inf",ITEMDATA,"Name=username", "Value={username}", ENDITEM,"Name=password", "Value={password}", ENDITEM,"Name=login.x", "Value=82", ENDITEM,"Name=login.y", "Value=9", ENDITEM,LAST);lr_end_transaction("login", LR_AUTO); //事务结束web_image("Search Flights Button","Alt=Search Flights Button","Snapshot=t3.inf",LAST);lr_think_time(9);lr_start_transaction("book"); //定义事务订票web_submit_form("reservations.pl","Snapshot=t4.inf",ITEMDATA,"Name=depart", "Value={from}", ENDITEM,"Name=departDate", "Value=01/10/2015", ENDITEM,"Name=arrive", "Value={to}", ENDITEM,"Name=returnDate", "Value=01/11/2015", ENDITEM,"Name=numPassengers", "Value=1", ENDITEM,"Name=roundtrip", "Value=<OFF>", ENDITEM,"Name=seatPref", "Value=Window", ENDITEM,"Name=seatType", "Value=First", ENDITEM,"Name=findFlights.x", "Value=78", ENDITEM,"Name=findFlights.y", "Value=4", ENDITEM,LAST);lr_think_time(9);web_submit_form("reservations.pl_2","Snapshot=t5.inf",ITEMDATA,"Name=outboundFlight", "Value={b}", ENDITEM,"Name=reserveFlights.x", "Value=74", ENDITEM,"Name=reserveFlights.y", "Value=9", ENDITEM,LAST);lr_end_transaction("book", LR_AUTO); //订票事务结束lr_think_time(6);web_submit_form("reservations.pl_3","Snapshot=t6.inf",ITEMDATA,"Name=firstName", "Value=s", ENDITEM,"Name=lastName", "Value=s", ENDITEM,"Name=address1", "Value=s", ENDITEM,"Name=address2", "Value=s", ENDITEM,"Name=pass1", "Value=s s", ENDITEM,"Name=creditCard", "Value=2", ENDITEM,"Name=expDate", "Value=2", ENDITEM,"Name=saveCC", "Value=<OFF>", ENDITEM,"Name=buyFlights.x", "Value=66", ENDITEM,"Name=buyFlights.y", "Value=9", ENDITEM,LAST);web_image("SignOff Button","Alt=SignOff Button","Snapshot=t7.inf",LAST);return 0;}vuser_end(){return 0;}#ifndef _GLOBALS_H#define _GLOBALS_H//--------------------------------------------------------------------// Include Files#include "lrun.h"#include "web_api.h"#include "lrw_custom_body.h"//--------------------------------------------------------------------// Global Variables#endif // _GLOBALS_H2.参数化因为本次实验的测试重点是登录和航班选择，因此在这两个部分分别进行参数化并定义事务。
loadrunner结果分析
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 错误信息，需要的时间）。
LoadRunner性能测试结果分析
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。
loadrunner测试_200个不同用户登陆的报告模板
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左右时用户全部退出访问。
loadrunner结果分析analysis
六.结果分析
监控指标数据分析 5.磁盘I/O UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate）， 如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。 Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而 Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。
四.事物响应时间分析
分析选项：
1.Download Time下载时间分析——组成页面的每个请求下载时间 ponent（Over time）各模块的时间变化——通过这个功能可以 分析响应时间变长是因为页面生成慢，还是因为图片资源下载慢 3.Download Time（Over time）模块下载时间——针对每个组成页面元 素的时间组成部分分析，方便确认该元素的处理时间组成部分 4.Time to Buffer（Over time）模块时间分类——列出该元素所使用的 时间分配比例，是受Network Time影响的多还是Server Time影响的多 receive时间很长，这个一般是网络问题，当然如果你确认网络不存在 问题，那么你就要看看是不是客户端的问题
（1）浏览器向服务器发送请求，一般该请求先发送到DNS服务器，把
DNS解析成IP地址。这个DNS解析时间可以确定DNS服务器是否有问题
（2）解析出IP地址后，请求被送到服务器，浏览器和服务器之间需要建 立一个初始化连接，建立该连接的过程就是连接时间，可以判断网络情 况，也可以判断服务器是否能够响应这个请求
first buffer time一般表示请求的真正响应时间。
Re，带宽越 大，下载时间越短。
五.报告
详细报告：自动汇总显示测试中重要的数 据。点击reports—new report可打开创建报 告页面，设置完毕后生成报告可导出为 word或者PDF格式。
具体实例教你如何做LoadRunner结果分析
具体实例教你如何做LoadRunner结果分析作者修改日期简单描述姜全尧07.07.10 增加对监视参数的解释,修改部分描述语言1．前言:LoadRunner最重要也是最难理解的地方--测试结果的分析.其余的录制和加压测试等设置对于我们来讲通过几次操作就可以轻松掌握了.针对Results Analysis我用图片加文字做了一个例子,希望通过例子能给大家更多的帮助.这个例子主要讲述的是多个用户同时接管任务,测试系统的响应能力,确定系统瓶颈所在.客户要求响应时间是1个人接管的时间在5S内.2．系统资源:2.1 硬件环境：CPU：奔四2.8E硬盘：100G网络环境：100Mbps2.2 软件环境：操作系统：英文windowsXP服务器：tomcat服务浏览器：IE6.0系统结构：B/S结构3．添加监视资源下面要讲述的例子添加了我们平常测试中最常用到的一些资源参数.另外有些特殊的资源暂时在这里不做讲解了.我会在以后相继补充进来。
Mercury Loadrunner Analysis中最常用的5种资源.1.Vuser2.Transactions3.Web Resources4.Web Page Breakdown5.System Resources在Analysis中选择“Add graph”或“New graph”就可以看到这几个资源了.还有其他没有数据的资源,我们没有让它显示.如果想查看更多的资源,可以将左下角的display only graphs containing data置为不选.然后选中相应的点“open graph”即可.打开Analysis首先可以看的是Summary Report.这里显示了测试的分析摘要.应有尽有.但是我们并不需要每个都要仔细去看.下面介绍一下部分的含义：Duration(持续时间)：了解该测试过程持续时间.测试人员本身要对这个时期内系统一共做了多少的事有大致的熟悉了解.以确定下次增加更多的任务条件下测试的持续时间。
LoadRunner性能测试报告分析
xxx系统性能测试报告姓名：班级：学号：目录1 前言 (3)2 被测系统定义 (3)2.1 功能简介 (3)2.2 性能测试指标 (3)3 系统结构及流程 (4)3.1 系统总体结构 (4)3.2 功能模块 (4)3.3 业务流程 (5)3.4 关键点描述 (5)3.5 性能测试环境 (5)4 性能测试 (6)4.1 性能测试概述 (6)4.2 测试目的 (6)4.3 测试方法及测试用例 (6)4.4 测试指标及期望 (7)4.5 测试数据准备 (8)4.6 运行状况记录 (9)5 测试过程及结果描述 (9)5.1 测试描述 (9)5.2 测试场景 (10)5.3 测试结果 (10)6测试分析和结论 (14)1前言目前，随着Web Tours订票系统在生产状态下日趋稳定、成熟，系统的性能问题也逐步成为了我们关注的焦点：随着订票过程中大数据量的“冲击”，在客户信息信息进入时，系统能稳定在什么样的性能水平，面临公司业务冲刺时，系统能否经受住“考验”，这些问题需要通过一个完整的性能测试来给出答案。
本报告前部分即是基于上述考虑，参考科学的性能测试方法而撰写的，用以指导即将进行的Web Tours订票系统的性能测试。
2HP Web Tours系统定义HP Web Tours 订票系统作为本次测试的被测系统，该业务系统的主要功能包括：搜索航班，预订机票并查看航班路线。
在本次测试中，将针对上述的功能进行压力测试，检查并评估在模拟环境中，系统对负载的承受能力，在不同的用户连接情况下，系统地吞吐能力和响应能力，以及在预计的数据容量中，系统能够容忍的最大用户数。
2.1功能简介HP Web Tours主要功能如下：➢用户注册➢登录➢查询航班2.2性能测试指标本次测试是针对HP Web Tours订票系统的性能特征和系统的性能调优而进行的，主要需要获得如下的测试指标。
1、系统的响应能力：即在各种负载压力情况下，系统的响应时间，也就是从客户端交易发起，到服务器端交易应答返回所需要的时间，包括网络传输时间和服务器处理时间。
loadrunner结果分析报告
LoadRunner 结果分析报告1. 引言在软件开发的过程中，性能测试是一个至关重要的环节。
性能测试能够帮助我们评估系统的负载能力、稳定性和响应时间等关键指标。
本文将通过分析LoadRunner 测试结果来评估系统的性能表现，为进一步的优化提供指导。
2. 测试背景在进行结果分析之前，首先需要了解测试背景。
我们在一个电子商务平台上进行了性能测试，模拟了多个用户同时访问系统的情况。
测试目的是评估系统在高负载下的性能表现，并发现潜在的性能问题。
3. 测试设计在进行性能测试之前，需要明确测试的设计。
我们使用了 LoadRunner 这一常用的性能测试工具。
测试设计主要包括测试场景的设置、虚拟用户的模拟和测试数据的准备等。
3.1 测试场景设置我们选择了一些常见的用户行为作为测试场景，包括登录、浏览商品、添加购物车和下单等。
这些场景模拟了用户在电商平台上的典型行为。
3.2 虚拟用户模拟为了模拟真实的用户场景，我们使用了 LoadRunner 提供的虚拟用户功能。
通过设置虚拟用户的数量和行为，我们可以模拟多个用户同时访问系统的情况。
3.3 测试数据准备为了模拟真实的情况，我们需要准备一些测试数据。
这些数据包括用户信息、商品信息和订单信息等。
通过使用真实的数据，我们可以更准确地评估系统的性能。
4. 测试结果分析在进行性能测试后，我们得到了一系列的测试结果数据。
下面将详细分析这些数据，以评估系统的性能表现。
4.1 吞吐量分析吞吐量是衡量系统性能的重要指标之一，它表示在单位时间内系统处理的请求数量。
我们通过 LoadRunner 的结果数据计算出了系统在不同负载下的吞吐量，并绘制成图表进行分析。
4.2 响应时间分析响应时间是用户感知系统性能的关键指标，它表示用户发送请求到系统返回结果的时间。
我们通过 LoadRunner 的结果数据计算出了系统在不同负载下的平均响应时间，并绘制成图表进行分析。
4.3 错误率分析错误率是衡量系统稳定性的指标之一，它表示系统在处理请求时出现错误的比率。
LoadRunner压力测试结果分析探讨
LoadRunner压力测试结果分析探讨分析原则：1. 具体问题具体分析（这是由于不一致的应用系统，不一致的测试目的，不一致的性能关注点）2. 查找瓶颈时按下列顺序，由易到难。
服务器硬件瓶颈网络瓶颈（对局域网，能够不考虑）服务器操作系统瓶颈（参数配置）中间件瓶颈（参数配置，数据库，web服务器等）应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）分析的信息来源：1. 根据场景运行过程中的错误提示信息2. 根据测试结果收集到的监控指标数据一．错误提示分析分析实例：1．Error: Failed to co nnect to server “172.17.7.230″: [10060] ConnectionError: timed out Error: Server “172.17.7.230″ has shut down the connection prematurely分析：A、应用服务死掉。
（小用户时：程序上的问题。
程序上处理数据库的问题，实际测试中多半是服务器链接的配置问题）B、应用服务没有死（应用服务参数设置问题）对应的Apache与tomcat的最大链接数需要修改，假如连接时收到connection refused消息，说明应提高相应的服务器最大连接的设置，增加幅度要根据实际情况与服务器硬件的情况来定，建议每次增加25%！C、数据库的连接(数据库启动的最大连接数（跟硬件的内存有关）)D、我们的应用程序spring操纵的最大链接数太低2. Error: Page download timeout (120 seconds) has expired分析：A、应用服务参数设置太大导致服务器的瓶颈B、页面中图片太多C、在程序处理表的时候检查字段太大多D、实际测试时有些资源需要请求外网，而我们的测试环境是局域网环境分析：A、脚本设计错误，造成页面特殊。
服务器有响应！B、并发数过大，造成服务器响应延迟。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
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），若事务平均响应时间曲线趋高，则说明被测系统处理事务的速度开始逐渐变慢，即被测系统随着运行时间的变化，整体性能不断下降。
当系统性能存在问题时，该曲线的走向一般表现为开始缓慢上升，然后趋于平稳，最后缓慢下降。
原因是：被测系统处理事务能力下降，事务平均响应时间变长，在曲线上表现为缓慢上升；而并发事务达到一定数量时，被测系统无法处理多余的事务，此时曲线变现为趋于平稳；当一段时间后，事务不断被处理，其数量减少，在曲线上表现为下降。
如果被测系统没有等待机制，那么事务响应时间会越来越长，最后系统崩溃。
4.再分析每秒通过事务数（Transactions per Second/TPS），该曲线表示被测系统在运行的任意时刻，每个事务通过、失败的情况，其是考查系统性能的一个重要参数。
若随着压力的增加，曲线如果开始变化缓慢或有平稳的趋势，则有可能是服务器开始出现瓶颈。
[5].分析每秒通过事务总数（Total Transactions per Second），该曲线显示在任意时刻被测系统通过的事务总数、失败的事务总数。
该曲线走向和TPS曲线走向一致。
[6].事务性能摘要（Transaction Performance Sunmmary）该曲线表示被测系统中所有事务的最小、最大和平均事务响应时间。
[7].事务在负载情况下的响应时间（Transaction Response Time Under Load），该曲线表示在不同数量的虚拟用户情况下的事务响应时间情况。
该图对分析具有渐变负载的测试场景比较有用。
[8].事务响应时间（百分比）（Transaction Response Time（Percentile）），该曲线可以容易地分析出在给定的响应时间范围内事务量的百分比重。
[9].事务响应时间（分布）（Transaction Response Time(Distribution)），该图可以容易地分析出在给定响应时间范围内的事务量情况。
其实，若并不是十分详细地分析测试结果，第4步与第5步选其一分析，第6步、第7步、第8步为可选项，因为在第1步就在一定程度上分析了，而第9步又与第8步功能相识。
LoadRunner生成测试结果图在很大的程度上具有一定的重复性，只不过是在不同情况下的具体显示。
LoadRunner测试结果分析之我见二上述测试过程的重点在于事务，而LoadRunner生成的测试结果图并不局限于事务上，其中还有是关于Vusers、Errors、Web Resources、Web Page diagnostics 的测试图。
1.对于Vusers的测试图有3种：Running Vusers、Vusers Summary、Rendezvous，其中Running Vusers是关于虚拟用户加压、施压、减压的情况图；Vusers Summary是用户运行结果的综述图；Rendezvous是虚拟用户的集合点情况图。
这三种图单独分析没有多大的价值，一般都是和其他图合并分析。
2.对于Errors的分析，若是在上述测试中发现被测系统运行中有很多错误，则Errors测试结果有分析的必要，否则，就不必发费时间在Errors上了。
其主要包括Error Statistics、Error Statistics（by description）、Errors per Second（by description）、Errors per Second、Total Errorss per Second，Error Statistics是带有错误代码编号的饼状图，Error Statistics（by description）不仅有错误代码编号，而且带有错误消息，Errors per Second是每秒错误数的曲线图，Errors per Second 与Errors per Second（by description）的区别也是在于是否带有错误消息。
Total Errorss per Second是被测系统每秒错误总数的曲线图。
若要对系统进行错误分析，则Error Statistics与Error Statistics（by description）、Errors per Second（by description）与Errors per Second择其一即可，不过带有错误描述的图更加具体。
3. Web Resources测试主要是对Web服务器性能的分析。
3.1每秒点击次数（Hits per Second）是Vusers每秒向Web服务器提交的HTTP 请求数。
查看其曲线情况可以判断被测系统是否稳定，曲线呈下降趋势表明Web 服务器的响应速度在变慢，当然其原因可能是服务器瓶颈问题，但是也有可能是Vusers数量减少，访问服务器的请求减少。
点击数：不是根据用户的鼠标点击次数计算，而是根据客户端向服务器发起的请求次数计算。
例如：若一个页面里包含10张图片，那么在访问该页面时，鼠标仅点击1次，但是服务器收到的请求数却为1+10（每张图片都会向服务器发出请求）。
此时其点击次数为11。
3.2吞吐量（Throughput）度量单位是字节，另外也有兆字节，其是度量服务器性能的重要指标，表示服务器在任意时间的吞吐能力，即任意时间服务器发送给Vusers的流量。
吞吐率=吞吐量/测试时间，单位时间里服务器发送给Vusers的流量。
点击率=吞吐量/测试时间，单位时间里Vusers发送给服务器的HTTP请求数。
[3.3]状态代码概要（HTTP Status Code Summary）表示从服务器返回的带有HTTP状态的数量分布。
其HTTP状态有HTTP 200、HTTP 302、HTTP404等。
该图可以容易看出HTTP响应状况。
[3.4]每秒HTTP响应数（HTTP Responses per Second）表示每秒从服务器返回的HTTP状态的曲线图。
其和HTTP Status Code Summary不同在于后者是总体数量分布，而它是分布在时间段上的平均分布状况。
[3.5]每秒重试次数（Retries per Second）表示单位时间内服务器尝试的连接次数。
服务器重试连接的情况：初始连接未经授权、要求代理服务器身份验证、服务器关闭了初始连接、初始连接无法连接到服务器、服务器最初无法解析负载生成器的IP地址。
重试次数概要（Retries Summary）是表示服务器重试连接次数量的饼图。
[3.6]连接数（Connections）显示任意时间点的TCP/IP连接数。
借助此图，分析应该何时添加其他连接。
每秒连接数（Connections Per Second）显示单位时间里新建或关闭的TCP/IP连接数。
该图呈下降趋势，就表明每秒连接数减少，也即服务器性能下降。
对于页面资源的测试结，3.1步和3.2步应该分析，3.3步和3.4步在分析综述（Analysis Summary）中已经做了一定的分析，没有特定需求可以不做分析，若是想了解在什么时间出现何种HTTP（如错误HTTP 404），则要分析3.4步。
至于3.5步可以了解在何时进行了重新连接，是什么原因导致。
3.6步分析恰当的时间添加连接。
LoadRunner测试结果分析之我见三前面分析的Web Resource（网络资源）的测试情况，其主要关注的是服务器性能，而系统本身和环境都有可能存在问题，页面诊断（Web Page Diagnostics）主要就是关注这方面的问题。
页面诊断可以很好地定位环境问题，如客户端问题、网络问题等，也可以很好的分析系统本身的问题，如网页问题。
1．Web Page Diagnostics （网页诊断）对测试过程中所有的页面进行一个信息汇总，可以很容易地观察出哪个页面下载耗时，然后选择该页面得其页面分解图，分析耗时原因。
Web Page Diagnostics是一个汇总图，选择要分析的页面，可得到其4张图：Download Time、Component（Over Time）、Download Time （Over Time）、Time To First Buffer（Over Time）。
Download Time分析页面不同组件在不同阶段的所需时间，其阶段主要包括：DNS Resolution：DNS域名解析所需的时间；Connect：与Web服务器建立初始连接所需的时间；SSL Handshaking：建立SSL连接所用的时间；FTP Authentication：认证客户端所需的时间；First Buffer：初始HTTP请求至WEB服务器响应成功所需的时间；Receive Time：浏览器从服务器接受字节并完成下载所经时间；Client Time：因思考时间或其它客户端问题导致的请求发生延迟所经时间；Error：从发出HTTP请求到接收到错误消息所需的时间。
这样就可以分析出时间花费在哪里，进而定位问题。
Component（Over Time）页面上不同组件在不同时间的平均下载时间曲线图。
Download Time（Over Time）不同组件在不同时间的平均下载时间面积图。