Loadrunner超全使用攻略（下）
上一篇 / 下一篇 2018-06-29 16:31:37 / 个人分类：软件测试
引言：看本文之前，先把“Loadrunner超全使用攻略（上）”给消化掉，下面就直接开始承接上篇的内容。
Controller
虚拟用户脚本已经编写好了，但是虚拟用户脚本只是代表一个用户的某种行为，要想实现并发操作，那就是要模拟很多用户的相同操作。
在真正的实际设计场景前，有几个概念需要理解下，什么是“系统用户数”、“在线用户数”、“并发用户数”？举一个例子说明下，假设有一个综合性的网站，用户只有在注册后登录系统才能够享有新闻、论坛、博客、免费信箱等服务内容，通过数据库统计知道了系统的用户数量为4000人，4000即为“系统用户数”；通过操作日志可以知道，系统最高峰时有500个用户同时在线，这里“在线用户数”即为500；这500个用户的需求肯定是肯定是不尽相同的， 有的人喜欢看新闻、有的人喜欢写博客、收发邮件等。假设70%的人在看新闻，10%的人什么也不干，剩下的20%的人写博客，那么真正对服务器造成压力的就是这500人中的20%。那么如何估算“并发用户数”？
（1）C=nL/T (2) C1=C+3 √3
在公式（1）中，C是平均的并发用户数；n是login session的数量；L是login session的平均长度；T是考察的时间段长度。
在公式（2）中，C1是并发用户数的峰值，C就是公式（1）中的得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的
下面给出一个实例来讲述公式的应用。假设有一个OA系统，该系统有3000个用户，平均每天有大约400个用户要访问系统，对一个典型用户来说，一天之内用户从登录到退出系统的平均时间为4h，在一天之内，用户只在8小时之内使用该系统。带入公式（1）得到C=400*4/8=200，那么C1=200+3* √200=242
除了上述方法外，还有一种更为广泛但精度比较差的根据经验的方法，相应的经验公式为：C=n/10和C1=r*C。通常用访问系统用户最大数量的10%作为平均的并发用户数量；并发用户数的最大数量可以通过在并发数上乘以一个调整因子r得到，通常r的取值为2~3。
当然在实际测试过程中的话，会根据公司要求的来进行并发测试，比如要求支持5000的并发请求，那么就按照5000来设计，等服务上线后，查看日志、数据库然后运用上面的公式再分析每个阶段实际的并发用户数。
Controller
1.打开Controller，会出现一个“New Scenario”对话框，把刚刚编写好的”Login_CreateGroup”和”platform_room”这2个脚本添加到“Scripts in Scenario”。为什么要添加2个脚本，而不是在一个脚本中把我们要操作的步骤全部编写好呢？ 这就有点像写代码，我们会把一些经常要用的且能共用的弄成一个库，那样谁要用的时候就直接引入这个库，会提高效率。所以在设计我平台服务器的性能脚本时候，我就尽量把每个接口都各自编写成脚本，然后在场景设计中就把这些脚本进行组合。
2.这里介绍下“Schedule by”中的2个重要选项“Scenario”和“Group”,Scenario(场景)：当你按场景进行计划时候，Controller将会同时运行所有参与场景的Vuser组，也就是说，定义的场景运行计划同时应用与所有Vuser组，而Controller将每个操作按比例应用与所有Vuser；Group（组）：当你按Vuser组进行计划时，参与场景的每个Vuser组按其自己单独的计划运行，也就是说，对于每个Vuser组，你可以指定何时开始运行Vuser组，更直白一点的说，就是当Vuser组和Vuser组之间有依赖关系的时候，就用Group方式。
3.接下来就说说设计场景，根据业务需要先登录验证（会返回token），创建分组（会返回groupid），然后请求分配服务地址和登录会议室，所以，只需要登录和创建分组一次，就能拿到后续登录会议室需要的token和grouip，于是只要运行脚本“Login_CreateGroup”一次，然后再运行脚本“platform_room”很多次就能实现“一个会议室同时登录很多人”的场景，而且这里需要注意的一点是，这2个脚本是有依赖关系的，“Login_CreateGroup”是要在“platform_room”前面先执行完后，“platform_room”才能执行的。对应到Controller里面的设置如下图：
4.场景设计完了，接下来就可以执行了， 但是我们性能测试不单单只是给被测系统加压， 还要关注整个测试过程中产生的数据， 然后选出我们所关心的数据，为进一步分析定位问题提供帮助。所以，在开始RUN之前，先添加一下自己关心的，要监控的数据，下图是我监控的一些数据：
5.接下来就可以RUN了，在Running过程中可能会遇到一个问题就是loadrunner卡在那边不动了，然后后面的case都失败了，通过观察监控的“Windows Resources”发现某一时段内CPU达到100%了，究其原因发现是因为设置太多的Vusers了（比如5000），这时候负载机因为自身的资源条件限制而引起的，为了解决这一问题，我们可以采用loadrunner的分布式加压来解决。
什么是分布式加压呢？
分布式加压其实就是用另外一台负载机来帮助我们实现一定量的Vusers，那就需要在另一台负载机上安装loadrunner11软件，然后在本地负载机的Controller的Load Generators里Add另一台负载机的Name（可以填写IP地址，比如192.168.6.173），然后点击connect按钮，查看status是否变为Ready状态，最后就可以在不同的虚拟用户组指定不同的负载机来帮助我们完成性能测试了。
场景运行完成以后， 不代表我们的性能测试结束， 相反，这才是性能测试的开始，因为接下来，需要对运行数据进行分析，找出性能瓶颈，然后调优或者提交BUG。
Analysis
在介绍Analysis的使用之前， 下面将针对一些常用的监控资源进行说明。
大致将监控分为3类
①负载机的系统监控与被测系统监控（一般包括CPU使用率、内存、磁盘IO等）
②服务器处理能力的指标监控（一般包括吞吐量、每秒事物数、各个事物的响应时间、每秒单击数等）
③网络监控（根据经验，就是查看对比前后流量，ping服务器等）
CPU利用率（% Processor Time）：指处理器执行非闲置线程时间的百分比。这个计数器设计成用来作为处理器活动的主要指示器。它通过在每个时间间隔中衡量处理器用于执行闲置处理线程的时间，并且用100%减去该值得出。可将其视为范例间隔用于做有用工作的百分比。根据应用系统情况，在80%±5%范围内波动为宜。过低，则服务器CPU利用率不高；过高，则CPU可能成为系统的处理瓶颈。
可用物理内存（ Available MBytes ）：当这个数值变小时，Windows开始频繁地调用磁盘页面文件。如果这个数值很小，例如小于5 MB，系统会将大部分时间消耗在操作页面文件上。一般要保留10%的可用内存。最低不能<4M，此值过小可能是内存不足或内存泄漏。
磁盘IO（% Disk Time）：指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。正常值<10，此值过大表示耗费太多时间来访问磁盘，可考虑增加内存、更换更快的硬盘、优化读写数据的算法。若数值持续超过80 (此时处理器及网络连接并没有饱和)，则可能是内存泄漏。
事务平均响应时间:（ Average Transaciton Response Time ）：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。好<2s、良好2~5s、差6~10s
吞吐量（ Throughput ）:可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。
每秒点击次数（ Hits per Second ）:通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。
虚拟用户数（Running Vusers）: 这个主要用于与其他监控数据结合来分析问题的。
执行结果分析过程
场景执行完成以后，需要对运行过程中收集的数据信息进行分析，从而来了解系统性能表现能力，确定系统性能瓶颈。在Loadrunner Controller中，通过单击【Results】>【Analyze Results】菜单项，启动Loadrunner Analysis应用，如果左侧的Graphs中没有出现你想要的图，就点击工具条按钮“Add New Graph…”，把关心的图加入进来，如下图：
合并图的应用
有时候看单一的图，很难看出图与图之间的关联，这时候可以采用合并图来进行有机的结合。合并图的方法就是先选择一张合并图，然后在图的空白处单击鼠标右键选择【Merge Graphs…】选项，接着选择被合并图（可以选择合并图类型、可以更改标题），如下图：
合并图的应用
合并图共提供了3种方式：叠加（Overlay）、平铺（Tile）和关联（Correlate），下面针对这3种合并方式做一下简单的介绍。
（1）叠加方式：使得两个图使用相同横轴的图的排列方式。合并图的左侧纵轴显示当前图的值，右侧纵轴显示被合并图的值。
（2）平铺方式：两个图一个位于另一个之上，合并图在下方，而被合并图在上方，使得两个图共同使用一个横轴，两个图分别使用搁置的纵轴
（3）关联方式：使得合并图的纵轴将变成合并图的横轴，被合并图的纵轴将变成合并图的纵轴。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8052)，我们将立即处理。
TAG: