摘要：最近笔主带着两位新入职的同事进行了公司新平台的压力测试，工具选择的当然是Loadrunner，小笔发现有很多刚入门Loadrunner的小白都会遇到很多相似的问题，但是这些问题并不能在各大搜索网站上得到完善的解决。因此，小笔选中了51testing这个流量给力认可度高的专业测试平台给各位loadrunner新手提拱一份参考，希望能够帮助到有需要的朋友。
在如今的大数据时代，软件、测试、自动化测试都在扮演者不可或缺的重要角色，我们开发一个平台要求的已经不仅仅是功能要正确，更要考虑的是随着访问量的增加给客户带来的压力体验。
OK，引文部分已经完成，下面我们一起走进Loadrunner的压力测试吧。
跟着小笔一起动手来完成此次的压力测试吧！一个完整的压力测试三部曲：
1.脚本录制->2. 场景设计->3. 结果分析
场景介绍：此处我们选择最具有代表意义的多用户并发登录系统，我们测试150个用户并发登录平台A的时候给系统增加的压力情况。
测试背景： Windows Server 2008+Loadrunner11+IE8
1．录制脚本（Virtual User Generator）
安装好Loadrunner后（安装比较容易，在此暂且省略），打开Virtual User Generator进行脚本录制，录制时相关设置：
Step 1、Catalog选择'Web(HTTP/HTML)'，点击[Create] 按钮。
Step 2、[URL Address]的值输入需要测试系统的地址，点击[OK]按钮。
Step3、开始进行登录系统的脚本录制，一般情况下，我们在录制的过程中需要切分action，不同的操作放在相对应的action里，此处因为操作简单，我们暂且不去细分。
Step4、生成脚本
Step5、优化脚本：添加集合点，事务，思考时间。
事务：定义一个action的范围，以便对此action进行某种操作。比如对该action进行计时操作。
语句：lr_start_transaction("login");
集合点：正如字面意思，等待所有的事务集合到一起进行的操作，用来执行负载测试。要实现此操作，可以同步 Vuser 以便恰好在同一时刻执行任务。通过创建集合点，可以配置多个 Vuser 同时执行某个操作。当某个 Vuser 到达该集合点时，将进行等待，直到参与该集合的全部 Vuser 都到达。指定数量的 Vuser 均到达后，释放所有这些 Vuser。
语句：lr_rendezvous("login");
思考时间：思考时间即等待时间，是一种延迟操作，很好理解。
语句：lr_think_time(5);
2．场景设计（Controller）
Step1、打开 controller，添加上面优化好的脚本，设置场景模式。（此处命名为testLogin）设置场景如下：
Step2、点击【Start Scenario】运行脚本，结果如下：
Step 3、点击紫色框中按钮，生成测试结果报告。
2．结果分析（Analysis）
Analysis 可以说是Loadrunner压力测试的重点和难点，所以对于新手而言 analysis不是测试的结束，而是开始。因此，对于各项测试结果我们要做出准确的理解和判断。在本次的实践中，我们做的是一个比较简单的场景，那么针对此场景的各项结果如下：
【测试报告分析摘要】，这里显示了实际测试过程中，总体的测试结果。我们可以选择更过的图来分析系统的负载情况。
【Running Vuser】结果分析：Vuser是并发测试选取的虚拟用户，从下图中可以看出，Vuser是每5秒增加5个，在02:20秒的时候达到了顶峰值150，持续运行了一分钟后，逐渐退出系统。
【Hits per Second】结果分析：每秒提交的HTTP请求数量，在本场景中执行的时间比较短，因此结果不是很明显，建议大家此处可以放宽执行时间，这样得到的结果比较准确。
【Throughput】结果分析：吞吐量是指返回的应用层数据的值，吞吐量单位是以字节数为准，表示Vuser在任何给定的某一秒上从服务器获得的数据量。借助此图我们可以依据服务器吞吐量来评估Vuser产生的负载量。该数据越小说明系统的带宽依赖就越小，通过这个数据可以确定是不是网络出现了瓶颈。
【Tansaction summary】结果分析：事务概要说明，统计执行的事务数量，比如在本次场景中，login和exist这两个事务的值都是855次。同事也监控了事务的Pass数和Fail数，了解负载的事务完成情况。通过的事务数越多，说明系统的处理能力越强；失败的事务数越小说明系统越可靠。这个比较容易理解，不多阐述。
【Average Transaction Response Time】- 事务响应时间结果分析：这里需要注意的一个问题是因为在Transaction Response Times里面是场景运行时记录的响应时间的最大值最小值与平均值，而Average Transaction Response Time 是按照采样率每隔几秒钟取一个值画出来的图，然后根据图来记录最大值最小值和平均值，在报告中也可以看到，Average Transaction Response Time中写的是图最大值、图小值和图平均值。如果将采样率设置小一些，这两个值就会比较接。所以，抽象率是关键。那么下图现实的结果可以看出，login这个action最大值是14.978，最小值是2.134，平均值是7.869；exist最小值是0.02，最大值0.214，平均值是0.078 。这些时间是可以接受的压力响应的时间。
本次测试过程中常见问题汇总：
之所以加上问题汇总是因为笔主觉得大家在做压力测试的时候，这类问题的出现率很高，所以，在此稍微总结一下。
问题1：averager esponse time响应时间过长？（与实际偏差甚大完全不合理）
解决方法：导致此问题的原因很多，但是我们可以从以下几类去分析：1、是否在脚本中添加了多长时间的思考时间。2、事务和集合点的先后顺序是否正确，正确的顺序是把集合点放在事务前面，反之则也会增加事务响应时间的值。3、网速问题，网速一般不会造成太大的偏大，但是不排除并发量很大的情况下造成的延误。
问题2：LoadRunner超时错误
解决方法：首先在运行环境中对超时进行设置，默认的超时时间可以设置长一些，再设置多次迭代运行，如果还有超时现象，需要在“Runtime Setting”>“Internet Protocol：Preferences”>“Advanced”区域中设置一个“winlnet replay instead of sockets”选项，再回放是否成功。
问题3：LoadRunner脚本中出现乱码
解决方法：重新录制脚本，在录制脚本前，打开录制选项配置对话框进行设置，在“Recording Options”的“Advanced”选项里先将“Surport Charset”选中，然后选中支持“UTF-8”的选项。
问题4：在录制过程中IE页面上，某些控件显示有问题，导致录制不了。
解决方法：一般情况下，将被测系统的URL加入到可信任站点即可解决此类问题。
问题5：Error -27796：Failed to connect to server‘XXXX’
这个问题可以说是经常遇到但是不易被解决的难题，我们大致可以这样去排查
（1）检查run time setting中的请求超时时间Preferences中点击Options‘HTTPrequest connect timeout’，‘HTTP-request receieve timeout’，‘Step download timeout’，查看其值是否为1000、1000、10000；run time setting设置完了后记住还需要在control组件的option的run time setting 中设置相应的参数；
（2）Browser Emulation中的Download non-HTML resources选项去掉，点击OK即可如果还不能解决的话，继续尝试第3种方法
（3）设置runt time setting中的internet protocol-preferences中的advaced区域有一个winlnet replay instead of sockets选项，选项后再回放就成功了。如果实在不行的话就试试重启大法吧，因为有些问题的确可能是因为工具问题，网络问题，机子问题等等。
总结：用Loadrunner进行压力测试难免会遇到各种问题，细心排查总能一一解决，所以笔者想对刚刚踏入这一行业的朋友说，不急不燥认真去思考，问题总能被解决。希望此篇文章对大家有所帮助，任何问题都可以留言喔。
最后：
可以到我的个人号：atstudy-js，可以免费领取一份10G软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！其中包括了有基础知识、Linux必备、Mysql数据库、抓包工具、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试等。
这些测试资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！