LoadRunner

[转]LoadRunner教程 

LoadRunner可以说是现在应用最广泛的性能测试工具.性能测试已经成测试的一个重要的组成部分.
  在没有网络没有得到广泛应用之前,人们通常使用单机版的软件.随着互联网的广泛应用,软件制作厂商不但要注意软件的功能,而且还要重视软件的性能.


  很多时候软件的功能已经达到了要求,但是在系统上线后却发现随着大量并发用户访问的增加,最终导致系统崩溃,为企业带来重大的经济损失.


  本教程会以实例的方式讲解在实际工作中使用LoadRunner如何完成性能测试。


  教程需要的测试环境请大家自行搭建,本站提供相关实例的源代码。


  好了,前言已经写完了,下面我们将正式开始。
 

定义需求


  不管我们做什么类型的测试,必须有一个测试目标,这个测试目标就是我们的测试需求。在大部分情况下是没有明确的需求,我们需要自己来定义需求。


  看看这个例子:某互联网IT公司开发了一个WEB应用系统,系统完成r后需要进行测试。如果你是一名测试人员,你会经常到听老板对你说 ”对系统进行性能测试,测试了告诉我结果“ ,听起来很简单需求,在仔细的思考之后我们就会发现太多模糊的需求。对系统的哪一部分进行?测试通过的标准是什么?应该如何运用并发用户策略?


  如果你不知道有性能测试工具可以使用,你还会发愁如何制造多用户同时访问的测试?如果公司的人数较多,你可能还会想可以让大家一起来访问这个网站看看效果如何,在现实中也确有这种测试方法,我就遇到过,公司在没有引入性能测试工具之前真的就是找了100多人在内部进行了并发测试,很显然这是一个无可奈何的方法,希望大家不要进行同样的测试,如果你正在考虑做类似的事情,那么你需要仔细的阅读以后的教程。


软件测试|性能测试|功能测试|LoadRunner教程|WinRunner教程|TestDirector教程|软件测试培训


  继续回到我们的话题定义需求,对于上面的例子我们应该如何定义需求呢?


  其实有两种方法可以使用:

  一、性能测试的需求已经明确写入了《设计说明书》。我们知道系统大约有多少个并发用户,用户要求完成哪些类型的操作……,这种需求的确定通常是基于设计需求,或来源于实际的数据。


  二、性能测试的需求是找到系统性能瓶颈,这个需求听起来比较大,我们需要确定操作类型和操作习惯,这些可以来源于对系统的分析,在实施过程中需要找出系统的性能瓶颈。这个对于初学者有一定难度,同时也是我们最常见的测试需求。


  很显然对于这个例子我们的目标可以将测试需求定义为找出系统的性能瓶颈。


  好了,现在我们已经知道自己的测试目标是什么了,接下来我们考虑如何进行具体的操作与实施。

 

在上一节中我们已经知道了自己的工作目标,接下来我们要思考如何完成这些工作。

  此时为了完成测试目标我们会去寻找一些工具,接下来我们将会介绍如何使用LoadRuner完成性能测试。


  确定了测试工具后,我们需要制定工作流程。在LoadRunner的技术手册给出了性能测试的基本工作流程。这里我们一起来看看这个工作流程包含哪些工作,以及这个流程为我们带来了哪些概念。


  建立测试计划 -> 制作测试脚本 -> 设定测试场景 -> 运行测试场景 -> 监视测试场景 -> 分析测试结果

 


  以上是性能测试的基本流程。由于我们是第一次进行性能测试,对于测试计划可以先跳过由制作测试脚本开始我们的测试工作。


  制作测试脚本:制作一系列的操作动作,以B/S结构为例我们要告诉测试工具我们需要打开哪些链接,输入哪些数据。


  设计测试场景:是标明制作好的脚本应该如何运行,要多少个虚拟用户?虚拟用户如何运行?运行多少时间?


  监视测试场景:是指在测试运行过程中对指定服务器的性能进行监视,监控数据用于后期的数据分析。


  分析结果:从数据中找出性能瓶颈。


  在这里插播一下LoadRunner的测试原理(刚才忘了说明)LoadRunner的测试原理很简单,用多线程或多进程的方式向服务器端发送大量的数据包,同时接收服务器的返回结果。举个例子:用户注册的性能测试,打开注册页,输入注册信息,然后提交,对于性能测试而言注册信息的收入过程LoadRunner并不会进行记录,当提交时客户端向服务器端发送请求,这个才是LoadRunner真正关心的内容。不知道我说清楚了没有,如果有疑问的朋友可以跟帖提出疑问。


  回到我们的上一个话题测试流程,当知道了流程中每一步的工作任务后,我们要开始一步步的完成每一个任务。


  在LoadRunner中分别不同的工具对应测试流程中的每一步。


  制作测试脚本-----VirtualUserGenerator


  设定测试场景-----Controller


  运行测试场景-----Controller


  监视测试场景------Controller


  分析测试结果------Analysis
 

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、付费专栏及课程。

余额充值