一、概述
（win10+IE11+LR12.02 | 50个虚拟用户并发目前不能破解）
LoadRunner是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进行测试。企业使用LoadRunner能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。 LoadRunner可适用于各种体系架构的自动负载测试，能预测系统行为并评估系统性能。版本v12.02新版本最大的特色是大大增强了移动应用程序的测试 ^^
汽车有他的性能，比如速度，加速时间，稳定性；电脑硬件有他的性能，比如CPU的频率，处理的速度，游戏的性能。而计算机软件也有他的性能，比如软件运行速度如何，系统稳定性如何等等。性能的好坏不能凭空想象。必须有一些数据来说明来比较。所以我们软件性能测试就是通过得到软件在各种运行情况下的数据来进行分析，来判断软件的性能。一个软件对于不同的人群，他所关注的性能方面是不一样的。比如对于用户来说，他关心的是程序响应的时间，也就是他点一个提交按钮，多长时间可以得到结果。而对于系统管理员他关注的可能是软件在运行时，对系统资源的使用情况，在大量用户使用时的表现如何，能否长时间稳定的工作；而对于开发人员，他们更关心的是系统结构是否合理，SQL执行速度是否够快，有没有内存泄漏等情况。而对于我们测试人员来说，我们需要站在多个 角度来关心性能问题。
1、LoadRunner 包括：
➤ VuGen
它是用于创建Vuser 脚本的HP 工具。可以使用VuGen 通过录制用户执行的典型业务流程来开发Vuser 脚本。VuGen 通过录制客户端和服务器之间的活动来创建脚本，使用此脚本可以模拟实际情况（模拟多个用户在系统中同时工作或访问系统）。
1）监控应用程序和服务器之间的通信
2）生成需要的函数调用
3） 将生成的函数调用插入到 Vuser 脚本中
➤ Controller
使您可以从单一控制点轻松、有效地控制所有Vuser， 并在测试执行期间监控场景性能。
➤ Analysis
在HP LoadRunner Controller 或HP Performance Center 内运行负载测试场景后可以使用Analysis。Analysis 图可以帮助您确定系统性能并提供有关事务及Vuser的信息。通过合并多个负载测试场景的结果或将多个图合并为一个图， 可以比较多个图。 性能测试主要术语
2、 性能测试主要术语（分析指标）
2.1、响应时间
对请求作出响应所需要的时间
一般情况下响应时间是分为多个步骤的，首先从客户端发出请求，经过网络达到服务器N1，应用服务器处处理S1，访问数据库服务器N2，数据库服务器处理时间为D1，然后返回给应用服务器的网络时间为N3，应用服务器处理时间S2，在传个客户端的网络时间是N4。那么整个响应时间应该为T=N1+S1+N2+D1+N3+S2+N4,当然如果还用到其他服务器，还要加上其他时间。而实际上，除开这T，还有一个客户端的显示时间也要可以算做响应时间。所以时间Tx = T +Ts。但实际上Ts很大程度上是由用户的机器决定的，所以我们一般只关注T，所以通常把T称做响应时间。
一般一个网站，被普遍接受的响应时间是2/5/10，就是说2秒内给用户响应是很满意的；2~5秒是可以接受，但对速度有些不满；响应时间超过5秒，用户将无法接受！但不同的软件，响应时间的标准要根据实际情况来定。比如一个数据库备分软件，你能要求他5秒内搞定一个1G的数据库吗？
2.2、并发用户数 ＜ 同时在线人数＜系统用户数
并发不一定是并行：如果只有一个CPU核心，那么同时只能处理一个进程，其他进程就必须等待，这些进程可能同时提出CPU请求，那么他们是并发的。如果有多个CPU，就可以同时处理多个进程。同时处理的进程是并行的。我们从宏观角度看不出两者的区别，但微观上，并行是永远同时进行的，而并发则不是。
并发用户数：分为业务并发用户数、服务器并发用户数
➤ 业务并发用户数： 一段时间内有多少个用户在使用我们的系统（这些用户的操作可能不同，比如浏览用户、发请求用户、发呆用户等），eg 理发店有一个师傅，同一时间只能给一个人理发，这个时候来了5个用户，我们就可以说这5是业务并发用户数;
➤ 服务器并发访问数： 在同一个时间点，向服务器发起请求的用户数; eg 来的5个用户，有3个是需要理发的。他们同时向师傅提出理发的请求，这就是对服务器而言的并发用户数了;
PS1：而对于我们测试，关注比较多的就是业务并发数, 通常直接把业务并发数称为并发用户数。通常把每天系统访问数的10%作为平均并发用户数，最大并发一般为平均值的2-3倍。
PS2：其他其他相关用户数
a. 系统用户数：指一个系统可以支持多少个注册用户。这是一个静态的概念。
b.同时在线人数（最大在线人数）：最大的业务并发用户数，只是 ”挂” 在系统上，部分用户可能对服务器不产生压力，是一个动态的概念。超过这个数的用户连接系统可能就会遇到性能障碍。
eg.假设有一个网站，注册用户才能登录使用各种功能，如上传头像，阅读专家文章等。该系统有20万注册用户，这就是说有20万用户可以使用这个网站的所有功能，20万就是这个网站的“系统用户数”，网站有一个在线统计功能，从统计数据中可以看到，同时登录网站的人数的最高记录是2万，就是有2万人同时用浏览器打开着这个网站。2万就是“同时在线人数”
PS3：千万不要脱离场景去谈并发：eg .100%的用户都在发呆和100%用户都在请求资源的压力肯定不同, 有单一场景、综合场景；
2.3、吞吐量
吞吐量是指单位时间内系统处理客户请求的数量
一般来说可以从业务角度的‘页面数/秒’，‘请求数/秒’来衡量，也可以通过‘字节数/秒’等多个方面来衡量。我们可以通过前面的响应时间和并发数来确定一个交互系统的性能。而对于非交互系统，吞吐量更能反映性能。而对于交互系统，吞吐量反映了服务器承受的压力，他能够说明系统级别的负载能力而且在性能调优过程中也有重要作用。比如通过‘字节数/秒’反映网络，服务器架构的制约，用‘单击数/秒’表示主要受服务器和应用代码的限制。
【-------------------综上-----------------】
通过吞吐量，并发数和响应时间，我们可以大概了解一个系统的性能。当并发数增大时，吞吐量会增大，响应时间有所增加。但并发数继续增加时，响应时间增大的幅度变大，而吞吐量逐渐平缓稳定。当并发数继续增大，响应时间会明显快速增大，而吞吐量可能因为服务器压力过大，反而出现下降。所以一定要结合起来一起看。
2.4、其他经常用到的指标
思考时间：从业务角度来说，就是在操作过程中停顿的时间，比如用户想自己密码的时间。使用思考时间，是为了更好的模拟真实的应用环境。具体设置多少时间也有一个公式来计算，但尽量按照正常的操作时间来操作，LR会自动把你未操作的时间自动设为思考时间。
3、性能测试的方法
3.1：性能测试(Performance Testing)
通过模拟系统生产运行的压力量和使用场景组合，测试系统是否满足性能要求。也就是说在指定的环境下运行，来验证系统能力。这种测试首先需要对测试的场景的业务比较熟悉，在就是要有一个明确的目标，比如能否达到100用户并发时响应时间不超过5秒。最后就是这种测试的环境是确定的。
3.2：负载测试（Load Testing）----性能调优
负载测试是在被测系统上不断增加压力，直到性能指标。比如响应时间超过指标或资源饱和。这种方法被称为Scalability Testing可量性测试。主要目的是找到系统处理能力的极限。一般会给定一些条件，比如响应时间不超过10秒，CPU利用率底于65%。同样这个测试也需要一个给定的环境，也要考虑执行时的场景。而且在性能调优时也用这种方法来查看前后的差异。
3.3：压力测试(Stress Testing)
是指系统在一定饱和状态下，如CPU，内存在饱和状态下处理的能力。主要观察的是系统在压力情况下的性能表现，重点观察是否会出现错误,响应时间如何。通常这些测试的描述会为，当CPU使用率在75%以上，内存使用70%以上，等作为测试依据。这种测试一般用于系统稳定性测试。
3.4：配置测试（Configuration Testing）
通过对系统软硬件的调整，了解不同环境对性能的影响，找到最优的分配方式。一般是在对系统性能有一定了解的基础上，多用于性能调优。
3.5：并发测试（Concurrency Test）
这就是前面说的用户同时对一个资源或模块数据发出请求的情况。通过这种测试手段可以发现系统中一些性能问题，比如资源竞争，死锁，内存泄露等问题。他可以在各个测试阶段使用。
3.6：可靠性测试（Reliability Testing）
通过给系统加载一定压力的情况下，让系统长时间运行，测试他在这种条件下能否稳定运行。主要是验证系统能否长期稳定运行。测试过程中，需要关注系统的资源情况。
3.7：失效恢复测试（Failover Testing）
这个主要是测试系统在部分发生故障时，用户能否继续使用，多少用户会受到影响。一般测试时要指出系统发生故障时能支持多少用户访问，采取什么应急措施。
二、安装
点击查看安装LR12下载、安装、破解 ：Link 点击查看11+12中文教程
三、VuGen 实践 （录制、回放、增强、调试）
1、开发vUser脚本的工作流：
2、 录制VUser脚本 （Web项目为例子，使用一个基于Web的旅行社系统示例 ，来录制一个HTTP协议的脚本 ，先把示例服务启动）
0) 启动示例服务，如下窗口关掉即停止服务
1）新建脚本
2）录制,可以使用LR自带的示例网站webTours Link (因为是本地启动，url用 http://localhost:1080/WebTours/index.htm 快些,使用无线网也会快些)
注：关于loadrunner录制时无Internet访问的解决办法： 点击查看 （其实这是loadrunner本身代理问题，loadrunner录制时会自动帮你代理，如果你不在录制时设置的话就会无法访问。）
注：录制过程中弹出如下弹框：
3）录制结果如下，生成的脚本含有刚才录制的信息，点击菜单栏，回放按钮，回放如果有红色，是报错信息，没有红色，如下图，说明运行成功，显示passed即为成功。脚本便可使用。
3、增强/编辑VUser脚本（可以查看步骤工具箱，查看API ，增强方法范例如下）
1） 事务 （开始事务和结束事务名称要保持一致,否则会报错 找不到结束事务语句）。可以录制时插入，也可以手工插入；
用来获得某一行为所消耗时间的函数
为了衡量服务器的性能，我们需要定义事务，一系列操作的集合，插入事务方便后续的分析。比如：我们在脚本中有一个数据查询操作，为了衡量服务器执行查询操作的性能，我们把这个操作定义为一个事务，这样在运行测试脚本时，loadrunner运行到该事务的开始点时，loadrunner就会开始计时，直到运行到该事务的结束点，计时结束。这个事务的运行时间在结果中会有反映。
事务的4种结束类型：
LR_AUTO：事务根据内部的HTTP请求响应状态码，判断这一个事务是否执行通过（2XX、3XX状态码则为事务通过，否则失败）
LR_PASS：事务任何情况下都以PASS结束
LR_FAIL：事务任何情况下都以FAIL结束
LR_STOP：事务任何情况下都以STOP结束
PS: 如果以HTTP状态码作为是否事务成功/失败的依据，那么对于一些友好的错误页面（状态码可能是200）则无法判断了，因此，强制以某个状态结束，一般是已经进行了某条件判断。
2）参数化 （更加真实的模拟实际用户操作）
是在参数上面右键，选择“Replace with a Parameter”，-------参数化的常量必须为有效常量！！！
3）检查点（文本检查点、图像检查点） Link （验证返回的页面上是否有特定的内容，添加检查点后必须要启用检查点选项才能生效）
3.1）web_reg_find（）函数 -----“在缓存中查找相应的内容”
位置:
”该函数写在要查找内容的请求之前（否则可能会报错），通常情况下写在如下六个函数之前：
Web_castom_request()、web_image()、 web_link()、 web_submit_data()、 web_submit_form()、web_url()
常用参数及含义:
web_reg_find("Search=Body", //定义查找范围
"SaveCount=ddd", //定义查找计数变量名称
"Text=aaaa", //定义查找内容
LAST);
3.2）web_find（）函数 -----“在页面中查找相应的内容”
位置:
”该函数在页面内容显示出来以后，在页面中进行查找，所以只能写在要查找内容之后：
常用参数及含义: （该函数只能在基于HTML模式录制的脚本中进行查找）
web_find("web_find", //定义该查找函数的名称
"RightOf=a", //定义查找字符的右边界
"LeftOf=b", //定义查找字符的左边界
"What=name", //定义查找内容
LAST)；
❤ 综上，web_reg_find()（）与web_find()的区别是，前者是在放在操作前，比如登录前，后者是放在操作后，比如登陆后。推荐用前者web_reg_find（）比较好用：在页面中查找“登录成功”的字符串，如果找到该字符串在日志中输出“登录成功”，如果找不到该字符串，则在日志中输出“登录失败”，此时使用该函数没有依据来做此判断，但使用web_reg_find()函数，使用它其中的SaveCount可以进行判断
3.3）web_image_check() 函数 -----在页面中查找一个具体的图片
常用参数及含义:
参数说明：web_image_check("web_image_check","Alt=","Src=",LAST);;
参数解释：“Alt”和“Src”的值直接取该图片在网页源代码中相应参数的值。(若为空字符串，则视为非法)
位置：放到web_url() 后面. 此功能仅支持基于HTML的脚本。
4 ) 集合点 （只能放在action部分； 和事务结合使用，且放在事务前；）-------需要在场景中设置集合点策略！！！！！
插入集合点是为了衡量在加重负载的情况下服务器的性能情况。在测试计划中，可能会要求系统能够承受1000人同时提交数据，在loadrunner中可以通过在提交数据操作前面加入集合点，这样当虚拟用户运行到提交数据的集合点时，loadrunner就会检查同时有多少用户运行到集合点，如果不到1000人，loadrunner就会命令已经到集合点的用户再次等待，当在集合点等待的用户达到1000人时，loadrunner命令1000人同时去提交数据，测试统计出来的结果，就是一个完全并发的结果，从而达到测试计划中的需求。
5）范例
3、配置运行时设置 点击查看引用
4、以独立模式运行VUser脚本
5、讲VUser脚本集成到场景中 （可以进行集合点设置）
四、Controller 实践 （场景设计、场景运行）
1、创建场景
1）在VUser中创建场景，或者直接打开Controller
2）设置场景 >设计> 全局计划 （启动vuse策略、持续时间、 结束vuser策略）
右侧可以看到虚拟用户的运行时间图
3）集合点策略 ：运行> 集合 （集合点策略）
PS: 只有在在第一部分录制脚本后，在脚本中插入了集合点，在第二部分场景这里才能设置。
集合点提供了以下3种策略：
a．当百分之多少的用户到达集合点时脚本继续。
b．当百分之多少的运行用户到达集合点时脚本继续
c．多少个用户到达集合点时脚本继续。
这3个策略的区别在于：假设脚本由100个用户来运行，但100个用户并不是一开始就共同运行的。假设每隔1分钟添加10个用户，也就是说10分钟后系统才有100个在线用户。这里100就是指系统访问的所有用户数，而不同时间的在线用户数是不同的。设置的集合点策略百分比均为100%。
在场景运行时，当Vuser脚本运行到集合点函数时，该虚拟用户会进入集合点状态直到集合点策略满足后才释放。
策略1是指当全部用户都运行到了集合点函数才释放集合，让这100个用户并发运行后面的脚本。
策略2是指当前时间如果只有10个用户在线，那么只需要这10个用户都运行到了集合点函数就释放集合，让这10个用户并发运行后面的脚本。
策略3就比较好理解了，当到达集合点的用户数达到自己设置的数量后就释放等待，并发运行后面的脚本。
可以在多个脚本上设置相同的集合点名称来实现多个脚本同时并发的效果。
集合点超时：
在脚本运行时，每个虚拟用户到达集合点时都会去检查一下集合点的策略设置，如果不满足，那么就在集合状态等待，直到集合点策略满足后，才运行下一步操作。但是可能存在前一个虚拟用户和后一个虚拟用户达到集合点的时间间隔非常长的情况，所以需要指定一个超时的时间，如果超过这个时间就不等待迟到的虚拟用户了。
超时时间是指虚拟用户之间的时间差，当出现两个虚拟用户到达集合点的时间差超过设定的超时时间时，所有在集合点处于等待状态中的用户将全部释放。
4）运行场景, 先添加load generator,否则提示没有load generator
四、Analysis 实践 （结果分析）
1、结果分析
在Controller中分析结果 (结果>分析结果)，或者直接打开Analysis
各种分析结果图如下所示：
2）现在我们可以调出Vuser中的集合图，可以看并发的：Graph---Add New Graph
2、常见问题分析
CPU过载内存溢出问题分析