LoadRunner

一、设计场景 　　 1、设计性能测试场景 　　Controller有两个视图：设计(Design)视图和运行(Run)视图。启动Controller，在Controller主界面里，我们可以看到这两个视图。 　　 1、设计视图 　　设计视图显示场景中的所有Vuser组/脚本的列表、负载生成器(Load Generator)计算机一级分配给每个组/脚本的Vuser数。该视图还显示有关场景计划(手动场景)或目标(面向目标的场景)的基本信息。单击"Design"选项卡。 　　 　　 2、运行视图 　　场景一旦开始运行，Controller自动切换到运行视图，运行视图显示有关运行的Vuser和Vuser组的信息以及联机监视器图。单击"Run"选项卡，我们可以看到运行视图。 　　 　　设计性能测试场景主要是在设计视图中完成的，我们知道在性能测试中，场景的设计是十分重要的，它决定整个性能测试的成败。 　　在设计视图中，场景有两种类型：手工场景和面向目标场景，其中手工场景还有百分比模式。 　　(1)、手工场景(Manual Scenario):创建虚拟用户组，设置虚拟用户数目以及其他Run-time信息。 　　手工场景是我们常用的设计模式，负载测试就常用它。手工场景符合我们的性能测试常规思路： 第一步，设置虚拟用户的数目、脚本以及他们运行的方式； 第二步，运行，得出服务器的响应时间等指标。 　

一、安装 1、运行“setup.exe” 2、点击安装，其中会有提示缺少“MicrosoftVisual C++ 2005 SP1运行组件”，下载这个组件。这里安装“vcredist_x86.exe”。安装完成后在一次运行“setup.exe”时，安装程序会自动检查所需组件是否都已安装，确定都安装后弹出如下页面 假如下载后还是报错如下： 解决的办法 ：在安装包中的 \lrunner\Chs\prerequisites 路径中找到对应的组件手动安装好就解决了 3、安装完成后，系统会自动打开“Loadrunner LicenseInformation”窗口： 并提示你的“license”只有十天的使用期。 此时，可以启动Loadrunner了。 Loadrunner 破解详解 破解篇 1、下载破解文件，此处我们使用已经下载好的文件“lm70.dll”和“mlr5lprg.dll”。 2、将“lm70.dll”，“mlr5lprg.dll”这两个文件复制并粘贴到LR11安装目录下的bin文件夹下,一般是C:\Program Files\Mercury\LoadRunner\bin。复制时注意要先将loadrunner关闭，否则会出现复制出错的提示。 3、注意，win7的话一定要 以管理员身份运行启动程序 ，启动后，点击 configuration->loadrunner license

入门gatling是因为公司随着业务的发展，导致因为流量问题日益增多，所以公司希望开展压力测试来探索公司容量从而合理规划服务集群数量，在技术选型时候考虑了的主流的压测工具LoadRunner、Jmeter、Ngrinder等等。首先排除的就是LoadRunner，因为LoadRunner免费使用的额度较小无法满足当时的压测需求，而且收费较高使用成本较大，所以放弃了这款软件的使用，后续又对比了Jmeter和Ngrinder这两款工具，Jmeter在中国市场较好文档齐全，遇见了问题可以与大量志同道合的朋友们进行交流，而且功能齐全，针对不同的协议都可以进行压测。Ngrinder是基于Grinder的开源的web性能测试平台，由韩国最大互联网公司NHN公司的开发团队进行了重新设计和完善，文档相对也比较完善，而且在中国京东的压测平台ForceBot也是基于此开发的，充分体现了二次开发的可能性。关于几款软件的对比 因为有许多文章详细解释过了，所以这里不对这些问题做过多阐述。 工具对比文章： nGrinder详细介绍及性能工具对比 性能压测工具选型对比 上面两篇文章就很好的对比了现在比较主流的几款压测工具各个之间的差异，其中阿里和腾旭还推出了各自的压测平台，阿里压测平台PTS和腾旭的压测大师。在调研的时候正好看到了有赞全链路压测的一些文章，发现了一个新的压测工具gatling

一、为什么要合并图表 说明：合并图表是为了更好的定位系统瓶颈，比如把虚拟用户运行图和平均响应事务时间合并，能直观体现虚拟用户数量 对服务器处理事务产生的影响； 二、Analysis合并图 1. Running Vusers(虚拟运行用户) 2. Average Transaction Response Time(平均事务响应时间) 说明：在合并之前，我们先拿两张图来演示 1). Running Vusers(虚拟运行用户) 2). Transaction Response Time(平均事务响应时间) 2.1 合并图操作说明 1. 操作说明： 1). 打开合并选项菜单 (Ctrl+M 或者 在要合并的图表上点击鼠标右键->merge Graphs) 2). 标1：选择要合并的图(并入) 如：Running Vusers 3). 标2：选择并入的方式： (1). Overlay(叠加) (2). Tile(平铺) (3). Correlate(关联) 2.2 合并方式-Overlay(叠加) 说明：两个图使用相同的X轴，并入的图Y轴合并后在最右侧； 2.3 合并方式-Tile(平铺) 说明：两个图公用一个X轴，Y轴各自保持不变，并入图在上方； 2.4 合并方式-Correlate(关联) 说明： 1. 主图的Y轴变成合并后的X轴，合并图的Y轴，为合并后的Y轴； 2. 合并的时候

Threads ——线程数 当前全部线程数 ============================================ Available MBytes ——物理内存的可用数 指计算机上可用于运行处理的有效物理内存的字节 数量。这个计数器只显示上一次观察到的值；它 不是一个平均值。 至少要有10%的物理内存值，如果available Mbytes值一直很小（4M或更小），说明计算机 总的内存可能不足，或某程序没有释放内存 ============================================= Page Faults/sec ——处理器每秒钟处理的错误页数 当进程引用特定的虚拟内存页，该页不在其在主内存的工作集当中时， 将出现页面错误 u 如果该页位于待机列表（说明已经位于主内存中），或被共享该页的 其它进程所使用，该错误被称为软错误（用Transition Fault/sec计 数器衡量），则错误处理不会导致从磁盘读取该页；如果该页必须从 硬盘上重新读取时，被称为硬错误。许多处理器可以在有大量软错误 的情况下继续操作。但是，硬错误可以导致明显的拖延。 u 如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内 存可能是瓶颈。 ============================================ Pages/sec

最近组内同事针对性能测试LR的脚本部分做了介绍，是个不错的分享。会后反思自己也有很长一段时间没做性能测试了，根据以往的经验，有必要做些整理和补充，本文主要介绍一些Loadrunner性能测试的学习方法、思路、流程以及测试过程中需要注意的点。脚本相关的介绍在这篇文章就不过多描述了，有兴趣的朋友网上进行查找，资料也相对比较丰富。 一、Loadrunner初步了解 关于Loadrunner的学习，初期重点关注Vuser Generator的使用，需掌握以下内容，再去实战操作基本就不难了。 录制脚本的基本步骤； 理解基础函数的含义：lr_start_transaction(),lr_end_transaction(),web_reg_find(),web_url(),web_submit_form(); 会看输出窗口中的Replay log； Vuser-Run Time Setting中Run logic\log\Think Time的设置； 脚本的迭代； 手动写脚本，掌握基本函数； Loadrunner参数的设置； 针对我们目前的项目基本上是做HTTP/HTTPS协议的压测，大家手上有项目时，可以通过录制了解一下整个HTTP请求及响应的情况，学习一下Loadrunner内置的函数。 另外参数设置、迭代、关联函数等等希望大家查一下资料弄懂，实践一下不同方式有什么不同。 二、性能指标

一、参数化作用 脚本参数化体现了数据驱动的思想，即测试脚本和测试数据分离的思想。脚本体现 测试流程，数据体现测试案例。 参数化可以减少脚本的大小和脚本数量 参数化使业务更接近真实的客户业务 二 参数化的场合 程序中具有日期时间数据。 实现唯一性约束：如注册业务。 实现数据约束：如银行业务的动态码每次都不同，需要参数化。 缓存数据约束 数据库查询是从硬盘中读取查询结果，再读到内存，内存再读到缓存，最后将 缓存中的数据发送到处理器中处理。若每次使用一致的查询条件，数据库的查 询结果将会一致，由于数据已经在缓存中，系统不再读取硬盘，从而得到的响 应时间要快于真实情况，这种情况也要参数化 三、参数化的方式 ： 其实参数化得方式有很多种，这里简述几种比较常见人方式。其实方式略有不同，但其结果都是将数据添加进来。 1、 编辑数据 点击Create Table 会出现表格，在表格，再次点击Edit with Notepad ，然后会打开一个记事本，我们可以对记事本进行添加数据 2、 添加dat数据文件 点击File输入框后面的“ Browse.. ”按钮，找到本地的txt数据文件，进行添加就可以了。 需要注意的是，文件里面的数据不要乱写，每条数据一行，不然会读取有误。 Loadrunner 的参数值没有最大的限度； lr 安 装 路 径 \config\vugen.ini 文 件 ， 在 此 文

本文主要介绍使用Loadrunner调用Webservice接口进行性能测试时，相关脚本编写及优化方法总结。 1. Webservice协议脚本编写流程 下面介绍使用Loadrunner 11调用Webservice 接口通用的流程与方法 1.1 新建脚本，选择"Webservice"协议 1.2 选择Manage Services->Import，输入URL（注意需要在Webservice地址后面加上?wsdl），最后选择Impoort 1.3 点击脚本中Action脚本中return 0前，后选择Add Service Call 1.4 在打开的New Web Service Call窗口中，选择输入参数inputXML，勾选Include argument in，在Value中可以随便填写一些字符（接下来脚本中，我们会做一些 参数化设置） 1.5 同理，选择输出参数中SubmitNLSMSRequestResult，后选择Save returned value in param，最后选择OK 这样调用一次Webservice 接口就保存在Action脚本中 1.6 参数化 在脚本中用" <mobileno>13312345678</mobileno><smscontent>飞信</smscontent>"（此接口输入参数示例）替换"xxx" 选中"13312345678

一、为什么学习事务？ 需求： 1. 统计订票网站登录业务需要的具体时间； 2. 登录账户不是jojo，则登录业务失败； 问题：统计时间有很多办法可以做到，但如何把登录业务标记成功或失败呢？ 二、什么是事务？ 概念：事务（Transaction）是用户在应用软件上操作的一个业务或多种业务集合(actions)的统称； 作用： 1. 通过事务可标记业务开始和结束，并且可统计相应业务的操作时间(事务时间)【重点】 2. 通过事务状态机制，可判断相应业务执行的成功与失败；【了解】 3. 通过事务来衡量服务器性能； 三、添加事务 说明：LR添加事务有两种方式： 1). 录制脚本的时候添加【了解】 2). 运行脚本的时候添加【推荐】 3.1 添加事务-录制时添加【了解】 3.2 添加事务-运行脚本时添加【重点】 提示： 1. 插入事务开始 lr_start_transaction("Name") 1. 插入方式： 1). Ctrl+T 2). 鼠标右键Insert->Start Transaction 3). 工具栏菜单(Insert)->Start Transaction 2. 参数 Name:事务名称 2. 插入事务结束 lr_end_transaction("Name", "status") 1. 插入方式：参考插入事务开始 2. 参数 Name:事务名称和开始事务名相同； status

一、http_load 程序非常小，解压后也不到100K http_load以并行复用的方式运行，用以测试web服务器的吞吐量与负载。 但是它不同于大多数压力测试工具，它可以以一个单一的进程运行，一般不会把客户机搞死。 还可以测试HTTPS类的网站请求。 下载地址：http_load-12mar2006.tar.gz 安装很简单 #tar zxvf http_load-12mar2006.tar.gz #cd http_load-12mar2006 #make && make install 基本用法： http_load -p 并发访问进程数 -s 访问时间 需要访问的URL文件 参数其实可以自由组合，参数之间的选择并没有什么限制。 比如你写成http_load -parallel 5 -seconds 300 urllist.txt也是可以的。 我们把参数给大家简单说明一下。 -parallel 简写-p ：含义是并发的用户进程数。 -fetches 简写-f ：含义是总计的访问次数 -rate 简写-p ：含义是每秒的访问频率 -seconds 简写-s ：含义是总计的访问时间 准备URL文件：urllist.txt，文件格式是每行一个URL，URL最好超过50－100个测试效果比较好。 文件格式如下： 1、http://www.qixing318.com/ 2、http:/