LoadRunner基本使用流程及结果分析(图文)
性能测试结果分析基础教程(图文并茂)
Loadrunner 结果分析基础教程Loadrunner测试结果分析如下：1、Analysis Summary 结果及分析如下：此次测试我用了30个用户，但有1个failed，5个error。
所以实际参与测试的虚拟用户总共有24个。
其中，总的吞吐量为3448691bytes，平均吞吐量为12965bytes，总的请求量为720，平均每秒请求量为2.707。
从该图可以看出，该系统存在一定的问题，在失败和错误的数量来看占到了总虚拟用户的20%，该比例还是挺大的，所以从这个方面可以看出在系统登录方面还存在一定问题。
2、Running Vusers结果及分析如下：通过上面图形结果可知，在刚开始虚拟用户为0，30秒多时突然达到24个用户访问，一直到4：17秒将为16个用户，到4：25秒24个用户全部访问结束。
3、Hits perSecond结果及分析如下：该图为每秒点击次数，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请数。
通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。
通过对查看“每秒点击次数”，可以判断系统是否稳定。
系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。
由上图不难看出：分别在0s、40s、1：12s三个时间点点击数最大，到后面基本处于稳定状态。
4、Througput结果分析如下：该图和上面第三个图恰好相识，由上图不难看出：分别在0s、40s、1：12s三个时间点吞吐量最大，到后面基本处于稳定状态，这不难看出是由于点击数引起的。
5、Transaction Summary 结果分析如下：有该图不难看出，该系统处于正常运行状态。
6、Vuser Summary 结果分析如下：由该图不难看出：虚拟用户通过的占96%，失败的占4%。
所以，从整体上来看，大部分用户运行正常。
7、Error Statistics 结果分析如下：从上图不难看出:错误数据只有1个，所以也可以看出系统基本运行正常。
LoadRunner使用手册
LoadRunner基本测试过程由以下四个步骤组成：1. 步骤一：创建脚本∙通过录制应用程序中典型最终用户执行的操作来生成虚拟用户（Vuser），将该用户的操作录制到自动虚拟用户脚本中，以便作为负载测试的基础。
2.步骤二：设计场景3.步骤三：运行场景∙运行用来模拟真实用户执行操作的脚本，并可以通过让多个虚拟用户（Vuser)同时执行这些操作来在系统中创建负载。
4.步骤四：分析结果∙提供包含深入的性能分析信息的图和报告。
使用这些图和报告，可以标识应用程序中的瓶颈，并确定需要对系统进行哪些更改来提高系统性能。
通过LoadRunner模拟登陆，设计操作路径新建录制1.1.新建录制信息1、新建一个web[Http]的[图-1.1][图-1.1]2、开始录制操作，先输入要录制的网页路径[图-2.1]、[图-2.2][图-2.1][图-2.2]3、开始录制4、录制结束,录制结束后点击停止[红色方框圈着的] [图-4.1][图-4.1]5、输入访问人数[图-5.1]6、运行[图-6.1]7、查看1人操作的时间[图-7.1]8、保存录制结果[图-8.1]9、新建运行[图-9.1][图-9.1] 10、选择要进行分析的文件[图-10.1]、[图-10.2][图-10.1][图-10.2]11、设置测试的方式[绝对并发，相对并发] [图-11.1][图-11.1]a)设置Edit Scheduleb)开始：Load all Vusers simultaneously 同时一起执行。
i.Load all Vusers simultaneously:绝对并发,同时访问。
ii.Start：每次执行访问的次数Vusers every:相隔多少时间iii.c)执行：Run until completion 直到完成i.d)结束：直到结束才停止。
i.12、设置访问用户数[图-12.1] 或[图-12.2] 都可以设置[图-12.1][图-12.2]13、点击运行分析[图-13.1][图-13.1]14、点击后，弹出对话框，询问，是否将结果默认保存到xx路径，最好自己设置，以便于查找测试结果信息。
使用loadrunner的流程
使用LoadRunner的流程1. 简介LoadRunner是一款性能测试工具，可用于模拟并测试不同负载条件下的应用程序性能。
它是业界著名的性能测试工具之一，广泛应用于软件开发和测试领域。
本文将介绍使用LoadRunner的基本流程，包括录制脚本、编辑场景、运行测试、分析结果等内容。
2. 录制脚本使用LoadRunner进行性能测试的第一步是录制脚本。
脚本录制是指将用户对应用程序的操作记录下来，以便后续可以回放并模拟用户行为。
下面是录制脚本的步骤：•打开LoadRunner，选择录制模式。
•配置录制设置，包括选择要录制的应用程序和协议。
•启动录制，执行各项操作，包括登录、浏览网页、提交表单等。
•停止录制，保存录制的脚本文件。
3. 编辑场景录制完脚本后，需要对场景进行编辑和定制，以模拟真实的负载条件。
场景是指一组用户行为的集合，可以包括不同的用户数量、并发用户数量、用户的思考时间、延迟时间等。
以下是编辑场景的步骤：•打开LoadRunner，选择编辑场景模式。
•导入录制的脚本文件。
•配置场景参数，包括虚拟用户数量、并发用户数量、需模拟的业务负载等。
•设置运行时的动态参数，如需替换用户名、密码等敏感信息。
•配置场景的持续时间、循环次数、运行模式等。
4. 运行测试场景编辑完成后，可以开始运行性能测试。
在运行测试期间，LoadRunner将模拟多个虚拟用户并发访问目标应用程序，记录并分析系统的性能指标。
以下是运行测试的步骤：•打开LoadRunner，选择运行测试模式。
•配置测试设置，包括选择要运行的场景、设置测试目标等。
•启动测试运行，观察测试运行的过程。
•监控系统性能指标，如响应时间、吞吐量、服务器负载等。
5. 分析结果性能测试完成后，需要对测试结果进行分析。
LoadRunner提供了丰富的分析工具，用于分析各项性能指标，找出性能瓶颈并提供建议。
以下是分析结果的步骤：•打开LoadRunner的分析工具。
Loadrunner分析结果图说明
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图“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。
例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。
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使用图解
loadRunner测试基本步骤：录制脚本→脚本调试→加载脚本、设置参数→压力测试→测试完成、生成测试报告以某系统签到签退测试脚本为例：1、录制脚本运行loadRunner，点击create/edit scripts图1.1 loadRunner主界面—录制脚本点击弹出窗口的new Vuser script…按钮图1.2 脚本选择界面弹出选择脚本协议窗口，默认为web(HTTP/HTML)，签到签退功能测试的类型是web，所以直接点击ok图1.3 协议选择界面在下图中，在URL Address中输入测试入口地址，输入完成后，点击ok，开始录制图1.4 录制脚本参数设置界面图1.5 点击ok后，弹出窗口，开始录制图中红色标识部分为脚本录制的阶段。
一共有三个：vuser_init（初始化）、Action （动作）、vuser_end（结束）以签到压力测试为例，我们要测试的动作为签到，初始化为用户登录，结束可以为用户退出，也可以为用户点一下其它按钮。
输入用户名、密码，登录系统图1.7 脚本录制—初始化阶段，登录完成。
登录完成后，初始化阶段完成，经红色标识部分调整为Action，开始动作部分—签到。
调整为Action后，开始录制动作。
在门户首页点击个人事务，点击签到点击确认，完成签到动作签到动作完成后，Action录制完成。
结束动作开始。
我们以点击一下沟通中心作为整个操作的结束，沟通中心页面加载完成后，点击结束按钮，脚本录制完成。
2、脚本调试点击下图中标识的按钮，进行脚本回放图2.1 脚本回放再次点击回放按钮图2.2 脚本回放完成后，再次点击回放按钮图2.3 系统参数比较先选择下方的参数，然后点击correlate，参数比较完成图2.4 点击查看脚本按钮图2.5 脚本中记录用户名密码参数的位置图2.6 脚本中其它参数的位置找到脚本中记录用户名密码参数的位置，替换为另一个人如wujq（将脚本中zhouyun 改为wujq），找到其它需要修改的参数的位置，如empId，由于员工一天只允许签一次到，所以empId是必须修改的（wujq的员工id为7942，所以empId部分修改为7942）。
LoadRunner的基本使用
LoadRunner 8.1基本使用刘韧LoadRunner 8.1基本使用 (1)一、脚本录制 (2)二、脚本回放 (3)三、创建负载测试 (4)四、场景设置 (4)五、主要数据图表的介绍 (5)一、脚本录制在LoadRunner中要进行脚本的录制，点击“开始”—>“程序”—> “Mercury LoadRunner”—> “LoadRunner”，进入LoadRunner页面，在负载测试选项卡下选择“Create/Edit Scripts”(创建/编辑脚本)，如图1-1所示。
图1-1在进行脚本录制之前首先要选择适合的协议（比如Web应用程序的选择Web （HTTP/HTML）），如图1-2所示。
图1-2在选择适合的协议之后会自动弹出录制对话框或者点击Start Record按钮同样可以进入录制对话框，在对话框中可以指定目标URL、Aplications的类型（一种是Internet类型，一种是Win32类型）、录制到指定的Action，如图1-3所示。
图1-3在录制过程中或者是录制结束之后可以通过/对录制的脚本添加事务开始/结束标志，通过添加集合点（集合点的添加只能在Action中进行，vuser_init和vuser_end 中不能添加集合点）。
添加事务可以使得每一个操作的事务响应时间更加准确的获得用户每一个操作的响应时间。
添加集合点可以帮助我们生成有效可以控制的并发操作。
集合点如果添加在事务中，那么等待的时间也将记录在事务响应时间中，这样会引起事务响应时间的不正确。
二、脚本回放脚本录制结束之后将视图切换至Tasks点击脚本回放可以回放刚才脚本录制的过程，如图2-1所示。
图2-1脚本回放之后将脚本保存，以便运行场景的时候加载。
三、创建负载测试在脚本回放成功之后，就可以创建负载测试了，点击RUN LOAD TEST如图3-1所示，进入Controller界面。
图3-1四、场景设置点击Run LoadTest之后将会出现一个新建场景对话框，其中Manual Scenario为手工场景，Goal-Oriented Scenario为目标场景，如图4-1所示。
4、LoadRunner基础培训之结果分析
Analysis ：常见图介绍_ Hit per Second
Analysis ：常见图介绍_ Hit per Second
Page Download Time Breakdown页面下载时间细分图 图中详细列出了每个页面所消耗的时间分布，图中每一个指标含义见表1所示。通过这些指
标的数据，我们可以轻易的判断是哪个时间慢。
Analysis ：常见图介绍_ Page Download Time Breakdown
Page Download Time Breakdown页面下载时间细分图组成，表1：
Analysis ：常见图介绍_ Throughput
Throughput吞吐量图 显示方案运行过程中服务器上每秒的吞吐量。吞吐量的单位为字节，表示 vuser在一秒时
间内从服务器获得的数据量。借助此图可以依据服务器吞吐量来评估vuser产生的负载量，可 以和平均事务响应时间图对照观察，以查看吞吐量对事务性能产生的影响。
一般CPU使用率要求不超过75%，物理内存使用率不超过70%。(n_Html
Analysis ：报告类型介绍_SLA
Analysis ：报告类型介绍_自定义
Loadrunner：常见问题汇总
Thanks!
Analysis ：常见图介绍_ UNIX Resources
UNIX Resources系统资源图 系统资源图显示了在场景执行过程中被监控的机器系统资源使用情况，一般情况下监控机
器的CPU、内存、网络、磁盘等各个方面。本次测试监控的是测试服务器的CPU使用率与内存 使用率，以及处理器队列长度。
LoadRunner使用步骤
LoadRunner进行压力测试一．LoadRunner 概要介绍1.1简介LoadRunner 是一种预测系统行为和性能的工业标准级负载测试工具。
通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。
通过使用LoadRunner ，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。
目前企业的网络应用环境都必须支持大量用户，网络体系架构中含各类应用环境且由不同供应商提供软件和硬件产品。
难以预知的用户负载和愈来愈复杂的应用环境使公司时时担心会发生用户响应速度过慢，系统崩溃等问题。
这些都不可避免地导致公司收益的损失。
Mercury Interactive 的LoadRunner 能让企业保护自己的收入来源，无需购置额外硬件而最大限度地利用现有的IT 资源，并确保终端用户在应用系统的各个环节中对其测试应用的质量，可靠性和可扩展性都有良好的评价。
LoadRunner 是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。
LoadRunner 的测试对象是整个企业的系统，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助您更快的查找和发现问题。
此外，LoadRunner 能支持广范的协议和技术，为您的特殊环境提供特殊的解决方案。
1.2基本步骤使用LoadRunner 完成测试一般分为四个步骤：1）Vitrual User Generator 创建脚本✧创建脚本，选择协议✧录制脚本✧编辑脚本✧检查修改脚本是否有误2）中央控制器（Controller）来调度虚拟用户✧创建Scenario，选择脚本✧设置机器虚拟用户数✧设置Schedule✧如果模拟多机测试，设置Ip Spoofer3）运行脚本✧分析scenario4）分析测试结果二.项目背景介绍2.1 背景概述“LMS网校考试平台”是一个典型的三层B/S架构的MIS系统（客户端/应用服务器/数据库管），中间层是业务逻辑层，应用服务器处理所有的业务逻辑，但应用服务器本身不提供负载均衡的能力，而是利用开发工具提供的ORB（对象请求代理）软件保证多个应用服务器间的负载均衡。
Loadrunner详细分析资料ppt课件
脚本参数
随机数(Random Number) 独一数(Unique Number) 虚拟用户编号(VuserId) 组名字(GroupName) 文件(File) 文件(File)来自数据源
20
脚本参数
21
脚本参数 –随机数
RandomNumberTest() {
int i; for(i=0;i<10;i++){
5
创建工程 - 界面引见
录制脚本 运转脚本
参数列表
编译脚本 添加活动 事务开场
运转设置 切换输出 活动树
事务终了
活动脚本
录制参数
6
启动录制
录制参数
7
录制过程
8
录制的结果
9
录制参数配置 录制方式 阅读器选择 高级配置 关联配置
10
录制参数配置 – 录制方式
11
录制参数配置 – 阅读器选择
Starting action VuserIdTest. VuserIdTest.c(5): VuserId=1 VuserIdTest.c(5): VuserId=1 VuserIdTest.c(5): VuserId=1 VuserIdTest.c(5): VuserId=1 VuserIdTest.c(5): VuserId=1 VuserIdTest.c(5): VuserId=1 VuserIdTest.c(5): VuserId=1 VuserIdTest.c(5): VuserId=1 VuserIdTest.c(5): VuserId=1 VuserIdTest.c(5): VuserId=1 VuserIdTest.c(7): Error: VuserId=1 Ending action VuserIdTest.
LoadRunner基本使用流程(图文)
上海祥殷信息技术有限公司2012年12月一、录制脚本1. 打开2. 点击编辑脚本3. 点击按钮新建脚本4. 弹出对话框，选着web（http/html）5. 输入网址，点击ok6. 录制脚本，录制结束后，点击一下按钮停止录制7. 录制成功后，生成脚本8. 点击如下按钮回放脚本9. 点此按钮，可新增action10. 点此按钮可以进行录制和回放设置11. 弹出的参数话界面一般回放设置下这里就好12. 点击图中图表设置参数化13. 弹出的设置界面，主要设置红色区域的几个地方14. 下图按钮为脚本调试15. 下图按钮为设置时间的其实点和结束点的按钮16. 下图两个按钮分别为与hp 质量管理工具 ALM 连接按钮和创建场景按钮17．插入事件，分别表示时间的开始和结束事件插入成功：18. 设置集合点二、创建场景1.在vugen中点击图中按钮创建场景2.弹出编辑框，设置场景，设置完成后点击ok第一个是目标场景第二个是手动场景其中手动场景可以设置加载虚拟用户数3.双击这里选着加压主机4.选择主机ip，和系统5. 点击ok 关闭对话框图中红色区域是选着场景执行方式：模拟真是环境还是基于时间表模拟6. 下图中：1） Schedule by 选项表示加载方式，基于脚本还是基于组2） Run mode 表示加载模式：分别表示模拟真实情况和还是基于场景7.双击下图红色区域，可选着加压力度8.双击红色区域，可设置压力下完运行时间9.双击下面红色的内容，可以选着虚拟用户停止的模式10.弹出设置选项框，可以选着停止的方式全部一下停止每多少时间停止多少个的方式停止11.点击run，来到执行界面12.在执行界面点击start Scenario,开始跑场景13.下图为执行过程中14. 场景跑完后显示如图界面：其中右边红色区域是运行过程中监控服务器的资源占用率等等的一些信息，在左边还可以添加或查看其他的一些图标15.点击下面按钮也能添加加压主机16.经15后，弹出选项框，点击add可以输入主机信息17.设置ip欺骗三、结果分析1.点击下面按钮，进入分析结果界面2.分析界面如下：3.点击这里的图表可以查看各结果的，然后对结果进行分析4.按照如下操作可以增加新的图表5.右键图表选着合并图表，可以合并分析6.合并后的图表。
LoadRunner使用
，Sybase等
LoadRunner使用
Controller
监测器
LoadRunner使用
Analysis
常用功能
添加图表 合并图表 设置粒度 数据筛选
LoadRunner使用
LoadRunner使用
Vugen
参数化
◦ “Select next row ”有以下几种选择：多个VU如何取值
Sequential：按照顺序一行行的读取。每一个虚拟用户都会 按照相同的顺序读取 Random：在每次循环里随机的读取一个，但是在循环中一 直保持不变 Unique ：每个VU取唯一的值。注意：使用该类型必须注意 数据表有足够多的数。 Same Line As 某个参数（比如Name）：和前面定义的参数 Name 取同行的记录。通常用在有关联性的数据上面。
Vugen
配置运行时设置（Runtime settings）
设置迭代次数 设置迭代间步进 设置执行日志 设置思考时间
LoadRunner使用
Vugen
调试、运行脚本
断点（F9)、单步(F10） 日志跟踪 参数化
LoadRunner使用
Vugen
参数化
LoadRunner使用
Vugen
参数化
◦ “Update value on”有如下几种选择：多次迭代如何取值
once在所有的反复中都使用同一个值， each iteration则每次反复都要取新值， each occurrence则只要发现该参数就要重新取值，也就是 如果一个action中有多个该参数，每遇到一个就要重新取一个 值。
LoadRunner操作手册整理
第一章Loadrunner11简介随着软件开发技术不断发展和日益成熟，现代应用程序也越来越复杂。
应用程序可以利用数十个甚至数百个组件完成以前用纸或人工完成的工作。
在业务处理过程中，应用程序复杂度与潜在故障点数目之间有直接的关联。
这使得找出问题根本原因变得越来越困难。
软件惊人的变化速度和激增的复杂性为软件开发过程带来了巨大的风险。
严格的性能测试是量化和减少这种风险最常见的策略。
使用HP LoadRunner 进行自动化负载测试是应用程序部署过程中一个非常重要的环。
1.1为什么要实现性能自动化测试自动化性能测试是利用产品、人员和流程来降低应用程序、升级程序或补丁程序部署风险的一种手段。
自动化性能测试的核心是向预部署系统施加工作负载，同时评估系统性能和最终用户体验。
一次组织合理的性能测试可以让用户清楚以下几点：➢应用程序对目标用户的响应是否足够迅速？➢应用程序是否能够游刃有余地处理预期用户负载？➢应用程序是否能够处理业务所需的事务数？➢在预期和非预期用户负载下应用程序是否稳定？➢是否能够确保用户在使用此应用程序时感到满意？通过回答这些问题，自动化性能测试可以量化业务状况的更改所带来的影响。
这反过来也可以让用户清楚部署此应用程序的风险。
有效的自动化性能测试可帮助您做出更加明智的发行决定，防止发行的应用程序带来系统停机和可用性问题。
1.2 LoadRunner 包含哪些组件LoadRunner 包含以下组件：➢Virtual User Generator 录制最终用户业务流程并创建自动化性能测试脚本，即Vuser 脚本。
➢Controller 组织、驱动、管理并监控负载测试。
➢Load Generator 通过运行Vuser 产生负载。
➢Analysis 用于查看、剖析和比较性能结果。
➢Launcher 使您可以从单个访问点访问所有LoadRunner 组件。
1.3了解LoadRunner 术语场景场景文件根据性能要求定义每次测试期间发生的事件。
loadrunner操作手册
LoadRunner操作手册1、LoadRunner操作，我们主要使用三大部分：Virtual User Generator、Controller、Analysis○1Virtual User Generator：录制脚本○2Controller：设置运行场景○3Analysis：分析2、首先我们打开Virtual User Generator，如图所示：打开后的界面：然后点击菜单file->new 新建一个脚本，打开后界面如下：由于我们B/S大部分使用的协议为WEB(HTTP/HTML)（如果不是可以选择其他协议），所以我们选择协议为WEB(HTTP/HTML)然后单击Create，接下来打开下图界面：在URL中输入你需要测试系统地址，Record into Action中有三个Action：Vuser_init：用来初始化的，比如登陆该界面Action：用来记录你所测试业务的，比如输入用户名和密码登陆Vuser_end：比如退出（注销）Application type 默认即可Program to record 是浏览器的位置一般默认即可Record the application startup 这项要打勾设置后单击OK按钮，开始录制，录制结束后保存。
关于在脚本中添加事务和集合点的设置。
1．事务添加方法，如下图：开始事务时间要在脚本内容前面，点击开始事务按钮，如下图打红勾：打开后设置事务名字（就是要测试的内容名字，比如：首页登录），如下图：然后点击ok，如下图：然后设置事务结束时间，点击打红勾按钮，如下图：打开后如下图：这个直接点ok就行，注意事务结束时间在脚本内容后面，如下图：2.集合点设置集合点要设在事务开始时间前面。
打开集合点设置按钮，如下图所示：名字按自己意思输入即可，然后点击ok。
添加好了如下图：此图就是集合点和事务的设置好了的图，位置要按这样设置。
3、然后打开Controller，如图所示：这样是在录好了脚本后直接在菜单tools打开当前脚本的controller，来设计场景。
LoadRunner_process_and_sharing
LoadRunner流程以及分享作者：钟庆雄_英文Jacky一：性能流程图：二：性能测试模型：三：性能需求：3.1、性能测试点的选取*发生频率非常高的（例如：某邮箱核心业务系统中的登录、收发邮件等业务，它们在每天的业务总量中占到90%以上）*关键程度非常高的（产品经理认为绝对不能出现问题的，如登录等）*资源占用非常严重的（导致磁盘I/O非常大的，例如某个业务进行结果提交时需要向数十个表存取数据，或者一个查询提交请求时会检索出大量的数据记录）下面看来分析某邮箱系统的需求：按照某某邮箱20000万注册用户，其中日活跃用户数为1.5%的规模计算：日活跃用户=20000*1.5%=300万日活跃用户人均每天发6封邮件，用户使用客户端收发邮件比例20%，则：每天发邮件投递量=300万*6*20%=360万封3.2、如何得到每秒的邮件数？方式一：严格的根据2/8原则，80%的邮件集中在20%的时间发送。
集中发邮件数： 3600000*80%=28800000封集中发送的时间：24*20%=4.8小时=17280秒每秒发送邮件数：2880000/17280=166.7封/秒方式二，根据某某邮箱业务模型表，每天忙时集中邮件系数0.15，邮件平均峰值系数2,则：峰值邮件量=3600000*0.15*2/3600=300封/秒注：忙时集中系数=忙时业务量/全天业务量在两种方式的分析中，方法二得出的结果是方法一的将近一倍，我们不要根据经验理所当然的去分析，要深入的了解系统，我们要对行业指标及计算方式。
如果按照第一种方式，性能测试达标了，但系统真正上线后可能远远超出了我们的评估。
2008年北京奥运运门票系统就是一个典型的案例。
3.3再来分析系统的登录：去年全年处理“WEB登录”交易约 100 万笔，考虑到 3 年后交易量递增到每年 200万笔。
假设每年交易量集中在 8 个月，每个月 20 个工作日，每个工作日 8 小时，试采用 80～20 原理估算系统服务器高峰期“WEB登录”的交易吞吐量应达到怎样的一个处理能力200万/8=25万/月25万/20=1.25万/日1.25万*80%/(8*20%*3600)=1.74TPS四：二八原则：业务场景分析是为了在测试中尽可能的模拟实际业务发生时的真实负载，并制定服务性能指标。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
一、录制脚本1. 打开2. 点击编辑脚本1/ 463. 点击按钮新建脚本4. 弹出对话框，选着web（http/html）2/ 465. 输入网址，点击ok3/ 466. 录制脚本，录制结束后，点击一下按钮停止录制7. 录制成功后，生成脚本8. 点击如下按钮回放脚本4/ 469. 点此按钮，可新增action10. 点此按钮可以进行录制和回放设置5/ 466 / 4611. 弹出的参数话界面 一般回放设置下这里就好12. 点击图中图表设置参数化13. 弹出的设置界面，主要设置红色区域的几个地方14. 下图按钮为脚本调试7/ 4615. 下图按钮为设置时间的其实点和结束点的按钮16. 下图两个按钮分别为与hp质量管理工具ALM连接按钮和创建场景按钮8/ 4617．插入事件，分别表示时间的开始和结束9/ 46事件插入成功：18. 设置集合点10/ 46二、创建场景1.在vugen中点击图中按钮创建场景2.弹出编辑框，设置场景，设置完成后点击ok第一个是目标场景第二个是手动场景其中手动场景可以设置加载虚拟用户数11/ 463.双击这里选着加压主机12/ 464.选择主机ip，和系统13/ 465.点击ok关闭对话框图中红色区域是选着场景执行方式：模拟真是环境还是基于时间表模拟14/ 466.下图中：1）Schedule by选项表示加载方式，基于脚本还是基于组2）Run mode表示加载模式：分别表示模拟真实情况和还是基于场景15/ 4616 / 467. 双击下图红色区域，可选着加压力度8.双击红色区域，可设置压力下完运行时间17/ 4618 / 469. 双击下面红色的内容，可以选着虚拟用户停止的模式10.弹出设置选项框，可以选着停止的方式全部一下停止每多少时间停止多少个的方式停止19/ 4620 / 4611. 点击run ，来到执行界面12. 在执行界面点击start Scenario,开始跑场景21 / 4613. 下图为执行过程中14. 场景跑完后显示如图界面：其中右边红色区域是运行过程中监控服务器的资源占用率等等的一些信息，在左边还可以添加或查看其他的一些图标15.点击下面按钮也能添加加压主机22/ 4616.经15后，弹出选项框，点击add可以输入主机信息23/ 4617.设置ip欺骗24/ 4625/ 46三、结果分析1.点击下面按钮，进入分析结果界面2.分析界面如下：26/ 463.点击这里的图表可以查看各结果的，然后对结果进行分析27/ 464.按照如下操作可以增加新的图表28/ 4629 / 465. 右键图表选着合并图表，可以合并分析6. 合并后的图表具体实例教你如何做LoadRunner结果分析LoadRunner 最重要也是最难理解的地方--测试结果的分析.其余的录制和加压测试等设置对于我们来讲通过几次操作就可以轻松掌握了.针对Results Analysis 我用图片加文字做了一个例子,希望通过例子能给大家更多的帮助.这个例子主要讲述的是多个用户同时接管任务,测试系统的响应能力,确定系统瓶颈所在.客户要求响应时间是1 个人接管的时间在5S 内.30/ 462.系统资源: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 Breakdown31/ 465. System Resources在Analysis 中选择“Add graph”或“New graph”就可以看到这几个资源了.还有其他没有数据的资源,我们没有让它显示.如果想查看更多的资源,可以将左下角的display only graphs containing data 置为不选.然后选中相应的点“open graph”即可.打开Analysis 首先可以看的是Summary Report.这里显示了测试的分析摘要.应有尽有.但是我们并不需要每个都要仔细去看.下面介绍一下部分的含义：Duration(持续时间)：了解该测试过程持续时间.测试人员本身要对这个时期内系统一共做了多少的事有大致的熟悉了解.以确定下次增加更多的任务条件下测试的持续时间。
Statistics Summary(统计摘要)：只是大概了解一下测试数据,对我们具体分析没有太大的作用.Transaction Summary(事务摘要)：了解平均响应时间Average单位为秒.其余的看不看都可以.都不是很重要.【注】51Testing授权IT168独家转载，未经明确的书面许可，任何人或单位不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
内容导航32/ 464.分析集合点在录制脚本中通常我们会使用到集合点,那么既然我们用到了集合点,我们就需要知道Vuser 是在什么时候集合在这个点上,又是怎样的一个被释放的过程.这个时候就需要观察Vuser-Rendezvous(集合点) 图.图1可以看到大概在3 分50 的地方30 个用户才全部集中到start 集合点,持续了3 分多,在7 分30 的位置开始释放用户,9 分30 还有18 个用户,11 分10 还有5 个用户,整个过程持续了12 分.33/ 46图2上面图2 是集合点与平均事务响应时间的比较图.注:在打开analysis 之后系统LR 默认这两个曲线是不在同一张图中的.这就需要自行设置了.具体步骤如下:点击图上.右键选择merge graphs.然后在select graph to merge with 中选择即将用来进行比较的graph.如图3:34/ 46图3图2 中较深颜色的是平均响应时间,浅色的为集合点,当Vuser 在集合点持续了1分后平均响应时间呈现最大值,可见用户的并发对系统的性能是一个很大的考验.接下来看一下与事务有关的参数分析.下看一张图.35/ 46图4这张图包括Average Transaction Response Time 和Running Vuser 两个数据图.从图中可以看到Vuser_init_Transaction(系统登录)对系统无任何的影响,Vuser 达到15 个的时候平均事务响应时间才有明显的升高,也就是说系统达到最优性能的时候允许14 个用户同时处理事务,Vuser 达到30 后1 分,系统响应时间最大,那么这个最大响应时间是要推迟1 分钟才出现的,在系统稳定之后事务响应时间开始下降说明这个时候有些用户已经执行完了操作.同时也可以看出要想将事务响应时间控制在10S 内.Vuser 数量最多不能超过2 个.看来是很难满足用户的需求了.做一件事有时候上级会问你这件事办得怎么样了.你会说做完一半了.那么这个一半的事情你花了多少时间呢?所以我们要想知道在给定时间的范围内完成事务的百分比就要靠下面这个图(Transaction Response Time(Percentile)36/ 46图中画圈的地方表示10%的事务的响应时间是在80S 左右.80S 对于用户来说不是一个很小的数字,而且只有10%的事务,汗.你觉得这个系统性能会好么!实际工作中遇到的事情不是每一件事都能够在很短的时间内完成的,对于那些需要时间的事情我们就要分配适当的时间处理,时间分配的不均匀就会出现有些事情消耗的时间长一些,有些事情消耗的短一些,但我们自己清楚.LR 同样也为我们提供了这样的功能,使我们可以了解大部分的事务响应时间是多少?以确定这个系统我们还要付出多少的代价来提高它.Transaction Response Time(Distribution)-事务响应时间(分布)显示在方案中执行事务所用时间的分布.如果定义了可以接受的最小和最大事务性能时间,可以通过此图确定服务器性能是否在可接受范围内.37/ 46很明显大多数事务的响应时间在60-140S.在我测试过的项目中多数客户所能接受的最大响应时间也要在20S 左右.140S 的时间!很少有人会去花这么多的时间去等待页面的出现吧!通过观察以上的数据表.我们不难看到此系统在这种环境下并不理想.世间事有果就有因,那么是什么原因导致得系统性能这样差呢?让我们一步一步的分析.系统性能不好的原因多方面,我们先从应用程序看.有的时候我不得不承认LR 的功能真的很强大,这也是我喜欢它的原因.先看一张页面细分图.38/ 46一个应用程序是由很多个组件组成的,整个系统性能不好那我们就把它彻底的剖析一下.图片中显示了整个测试过程中涉及到的所有web 页.web page breakdown中显示的是每个页面的下载时间.点选左下角web page breakdown 展开,可以看到每个页中包括的css 样式表,js 脚本,jsp 页面等所有的属性.在select page to breakdown 中选择页面.见图.39/ 46在Select Page To Breakdown 中选择后,在下方看到属于它的两个组件,第一行中Connection 和First Buffer 占据了整个的时间,那么它的消耗时间点就在这里,我们解决问题就要从这里下手.40/ 46也有可能你的程序中client 的时间最长.或者其他的,这些就要根据你自己的测试结果来分析了.下面我们来看一下CPU,内存.硬盘的瓶颈分析方法:首先我们要监视CPU,内存.硬盘的资源情况.得到以下的参数提供分析的依据.%processor time(processor_total):器消耗的处理器时间数量.如果服务器专用于sql server 可接受的最大上限是80% -85 %.也就是常见的CPU 使用率.%User time(processor_total)::表示耗费CPU的数据库操作，如排序，执行aggregate functions等。
如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。
%DPC time(processor_total)::越低越好。
在多处理器系统中，如果这个值大于50%并且Processor:% Processor Time非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。
%Disk time(physicaldisk_total):指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。