LoadRunner性能测试实例
一、简介
性能测试，是通过自动化的测试工具模拟正常、峰值以及异常负载等的情况下，对系统的各项性能指标进行测试。
测试工具：LoadRunner(收费)、Jmeter（开源）、QaLoad ……
1）LR介绍
LoadRunner，是现在使用相对最为广泛的性能测试工具。它通过模拟上千万用户，来实施并发负载及实时性能监测的方式来确认和查找系统瓶颈。LoadRunner是一种适用于各种体系架构的自动负载测试工具，用来测试系统性能。
LR由三部分组成：
1.VuGen(虚拟用户生成器)用于捕获最终用户业务流程和创建自动性能测试脚本 (也称为虚拟用户脚本)。
2.Controller (控制器)用于组织、驱动、管理和监控负载测试。
3.Analysis (分析器)有助于您查看、分析和比较性能结果。
2） 测试要求：tesklink: http://localhost/testlink/login.php
1、 测试系统支持100个并发同时登录
2、 登录功能响应时间不超过5秒
3、 CPU使用率不超过80%
4、 内存使用率不超过75%
二、用VuGen录制脚本；
（1）按业务流程正确录制脚本
（2）增强脚本：
1）参数化
2）添加事务
3）集合点
4）检查点
5）关联 web_reg_save_param
web_reg_save_param
函数进行关联
6）Running-times Settings
log的设置方式 ： Always send messages（这种方式会一直打印输出日志，不仅在错误时）；
standard log——记录所有的请求反馈的日志，包括successful和fail的日志。
Extended log——可提供扩展的日志信息，包括：
Parameter subsititution——日志中打印所有中使用的参数值
Data returned by server——日志中打印每个客户端请求服务器返回的数据值
Advanced trace——日志中打印所有的消息信息和函数执行信息
通常我们选择“Parameter subsititution”.
6）编译；Replay
三、运行脚本，进行负载测试；
1）Design界面
（1）scenario script
Scenario Schedule
2）Run界面
（1）Available Graphs 选择监控项；
（2）Start Scenario
四、Analysis报告分析
Mercury Loadrunner Analysis 中最常用的5 种资源.
1. Vuser
2. Transactions
3. Web Resources
4. Web Page Breakdown
5. System Resources
1）首先查看Summary Report
Transaction Summary(事务摘要)：了解平均响应时间Average单位为秒。。。。。
2)分析集合点(查看集合点与平均事务响应时间的比较图)
图中较深颜色的是平均响应时间,浅色的为集合点,当Vuser 在集合点持续了1分后平均响应时间呈现最大值,可见用户的并发对系统的性能是一个很大的考验
3）Average Transaction Response Time 和Running Vuser 两个数据图
从图中可以看到Vuser_init_Transaction(系统登录)对系统无任何的影响,Vuser 达到15 个的时候平均事务响应时间才有明显的升高,也就是说系统达到最优性能的时候允许14 个用户同时处理事务,Vuser 达到30 后1 分,系统响应时间最大,那么这个最大响应时间是要推迟1 分钟才出现的,在系统稳定之后事务响应时间开始下降说明这个时候有些用户已经执行完了操作.同时也可以看出要想将事务响应时间控制在10S 内.Vuser 数量最多不能超过2 个.看来是很难满足用户的需求了.
4）Transaction Response Time(Percentile)
图中画圈的地方表示10%的事务的响应时间是在80S 左右.80S 对于用户来说不是一个很小的数字,而且只有10%的事务。
Transaction Response Time(Distribution)-事务响应时间(分布)
显示在方案中执行事务所用时间的分布.如果定义了可接受的最小和最大事务性能时间,可以通过此图确定服务器性能是否在可接受范围内.
5） 判断应用程序的问题
如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换(context switches/sec显示的上下文切换次数太高)那么就会占用大量的系统资源,如果系统的吞吐量降低并且CPU的使用率很高,并且此现象发生时切换水平在15000以上,那么意味着上下文切换次数过高.
从图的整体看.context switches/sec变化不大,throughout曲线的斜率较高,并且此时的contextswitches/sec已经超过了15000.程序还是需要进一步优化.
6）. 判断CPU瓶颈
如果processor queue length显示的队列长度保持不变(>=2)个并且处理器的利用率%Processortime超过90%,那么很可能存在处理器瓶颈.如果发现processor queue length显示的队列长度超过2,而处理器的利用率却一直很低,或许更应该去解决处理器阻塞问题,这里处理器一般不是瓶颈.
%processor time平均值大于95,processor queue length大于2.可以确定CPU瓶颈.此时的CPU已经不能满足程序需要.急需扩展.
7）. 判断内存泄露问题
内存问题主要检查应用程序是否存在内存泄漏,如果发生了内存泄漏,process\private bytes计数器和process\working set 计数器的值往往会升高,同时avaiable bytes的值会降低.内存泄漏应该通过一个长时间的,用来研究分析所有内存都耗尽时,应用程序反应情况的测试来检验.
图中可以看到该程序并不存在内存泄露的问题.内存泄露问题经常出现在服务长时间运转的时候,由于部分程序对内存没有释放,而将内存慢慢耗尽.也是提醒大家对系统稳定性测试的关注.