LoadRunner压力测试操作步骤

原文来自:http://www.blogjava.net/ricki/archive/2007/07/18/130974.html

以创建交易脚本为例,详细的解释一下使用LoadRunner进行压力测试的过程。

一、 使用VUGen录制脚本

1、根据应用程序架构选择相应的协议。一般象B/S的程序用单一的http协议就可以了。

2、开始录制。根据所选协议的不同,出现的对话框不不同的。选择http协议的话需要录入url地址,在这步录入需要测试的地址如https://www.alipay3.net

3、录制脚本:在一个脚本中,默认有三个动作:vuser_init Action vuser_end。

通常把初始化操作放到vuser_init中,

具体需要测试的操作放在Action中,

vuser_end动作目前来说没有什么用处。

在创建交易脚本中,需要测试的操作包括创建支付宝交易、买家付款、卖家发货、买家确认收货。每一个操作都必须首先登陆才能进行。

4、添加事务:为了使录制的脚本更易读,录制过程中要为每一个独立的操作添加事务。比如说登陆、买家付款都放在一个单独的事务中。特别注意,因为本次测试目标是每秒内总的交易数,所以需要分别给每一个测试脚本的Action操作都加上一个统一的事务,名称都叫做“Action”,以便衡量是否可以达到目标。

具体步骤:

在tree视图下,在要开始的地方选择插入-》开始事务,

为事务命名,在结束的地方选择插入-》结束事务。这样,事务就添加好了!

5、添加验证点:脚本录制好后,在需要的地方加上验证点,来检测脚本是否执行成功。以登陆操作来说,在提交登陆的脚本后面,右击鼠标,选择Insert—NewStep,在出现的对话框中选择Web Checks—Text Check,进行文字验证,查找退出这两个字是否出现。如果出现就说明登陆成功了。

6、根据需要对变量参数化:在登陆操作中需要参数化的值包括:URL,登陆帐号、登陆密码。点击工具栏的Param List按钮可以创建参数。当新建一个参数后,LR会在当前脚本的目录下自动创建一个文件存放参数的值。我们不要这个默认的文件名,把所有参数的文件名都修改为“D:\LrData\Email.dat”[文件路径及名称都是可以手工修改的],这样可以在多个脚本中共享相同的变量。

a)        url、登陆帐号、登陆密码:这几个参数都是手工在LR中输入,然后保存到文件中。

b)        交易号:在查询交易明细脚本中,会随机的选取100个交易查看其明细。这种情况下,交易号直接从数据库中取得比较方便。但是必须在本地安装oracle客户端。如果没有装oralce客户端,可以首先登陆到PL/SQL中,查询100个交易号,选中把查询结果,选择导出到CSV文件中。

导出后,在LR中打开Param List,选中交易号这个参数,点击Edit With NotePad按钮,把csv文件的内容拷贝到这个里面即可。注意拷贝前需要用支持列编辑的文本工具打开csv文件,去掉前后的引号。保存文件成功后,在LR中就可以看到导出的交易号了。

7、在Vuser中运行脚本,确认脚本可以正常运行。




  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
LoadRunner性能测试工具实战视频教程【全套26集】 随机函数 在软件测试工具中如何巧用LoadRunner的随机函数。 LoadRunner有自带的随机函数,如果巧妙的加以采用,能解决一些看似很困难的实际问题。 一个项目的性能测试。与数据库直连,根据外部传入的SQL ID和SQL参数,从指定数据库中读取SQL模版,拼装成真实的SQL语句、执行,并将得到的结果放入缓存中。目的是减少数据库的压力。 该系统将支撑大量的SQL操作,性能自然成为备受关注的焦点之一。 由于它跟SQL语句相关,在真实环境下,同一时间可能执行着不同类型的SQL,即便是同一类型,其参数也各式各样。那么,怎样才能模拟出最符合实际情况的性能测试场景呢? 首先设计场景,即,在LoadRunner中按照比例随机取到某一类型的SQL,再随机传入参数给它,让最终的每条SQL都是随机生成,各不相同。 从场景中,可以看到,此处涉及双重随机。只采用loadruner的参数设置是无法实现的。此时需要想办法先按设定好的比例随机取到SQL,然后在每条SQL上随机取参数列表中的参数。 于是想到了loadrunner的随机函数。先实现随机取SQL ID,之后再在特定的SQL中随机取参数列表中的参数。 LoadRunner中,随机函数是rand(),它用来产生0到rand_max之间的随机整数。函数原型是 int rand (void); 然而调用rand之前,必须给随机数产生一个随机种子。这个种子由srand()函数产生。其原型是 int srand (seedTime); 2 分析占用率 1. 平均事务响应时间 Average Transaction Response Time 优秀:10s 2. 每秒点击率 Hits per Second LoadRunner分析页面 LoadRunner分析页面 当增大系统的压力(或增加并发用户数)时,吞吐率和TPS的变化曲线呈大体一致,则系统基本稳定。若压力增大时,吞吐率的曲线增加到一定程度后出现变化缓慢,甚至平坦,很可能是网络出现带宽瓶颈,同理若点击率/TPS曲线出现变化缓慢或者平坦,很可能是服务器响应时间增加,观察服务器资源使用情况,确定是否是服务器问题。 3. 请求响应时间 Time to Last Byte 4. 每秒系统处理事务数 Transaction per second 5. 吞吐量 Throughout 6. CPU利用率 Processor / %Processor Time 好:70% 坏:85% 很差:90%+ 7. 数据库操作消耗的CPU时间 Processor / %User Time 如果该值较大,可以考虑是否能通过友好算法等方法降低这个值。如果该服务器是数据库服务器, Processor\%User Time 值大的原因很可能是数据库的排序或是函数操作消耗了过多的CPU时间,此时可以考虑对数据库系统进行优化。 8. 核心态CPU平均利用率 Processor /%Privileged Time 如果该参数值和"Physical Disk"参数值一直很高,表明I/O有问题。可考虑更换更快的硬盘系统 9. 处理队列中的线程数 Processor / Processor Queue Length 如果该值保持不变(>=2)个并且%Processor Time 超过90%,那么可能存在处理器瓶颈。如果发现超过2,而处理器的利用率却一直很低,那么或许更应该去解决处理器阻塞问题,这里处理器一般不是瓶颈。 10. 文件系统缓存 Memory / Cache Bytes 50%的可用物理内存 11. 剩余的可用内存 Memory / Avaiable Mbytes 至少要有10% 的物理内存值 12. 每秒下载页数 Memory / pages/sec 好:无页交换 坏:CPU每秒10个页交换 很差:更多的页交换 13. 页面读取操作速率 Memory / page read/sec 如果页面读取操作速率很低,同时 % Disk Time 和 Avg.Disk Queue Length的值很高,则可能有磁盘瓶径。但是,如果队列长度增加的同时页面读取速率并未降低,则内存不足。 14. 物理磁盘利用率 Physical Disk / %Disk Time 好:<30% 坏:<40% 很差:<50%+ 15. 物理磁盘平均磁盘I/O队列长度 Physical Disk / Avg.Disk Queue Length 该值应不超过磁盘数的1.5~2 倍。要提高性能,可增加磁盘 16. 网络吞吐量 Network Interface / Byt

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值