测试回顾版-Loadrunner入门级-小强作品（1-5）

 参考教材：

http://www.boobooke.com/bbs/viewthread.php?tid=7795&extra=page%3D1

 

一共23个

 

总体评价：入门级----顺便完整回顾下Loadrunner的基础知识

 

第一讲：性能测试常见用语-性能测试基本概念剖析

 

（并发用户数量）与服务器进行交互的在线用户总量（）可以通过对服务器日志的分析得到

（请求响应时间）从client端发出请求到得到响应的整个时间，一般包括网络响应时间和server的响应时间（要区分）

（事物响应时间）完成这个事物所需要的时间（性能测试中重点关注指标）

（吞吐率）单位时间在网络上面传输的数据量（衡量网络性能的主要指标）从server返回到client的数据量

（吞吐量）网络上面传输的数据总量（单位时间内系统处理的客户请求数量）

（TPS）每秒钟系统能够处理事物的数量

（点击率）每秒发送的HTTP请求的数量，点击率越大对server的压力也越大

（资源利用率）对不同资源使用的程度，比如服务器的CPU，内存等

 

响应时间=网络传输时间+应用延迟时间

应用延迟时间=数据库延迟时间+应用服务器延迟时间

 

而“系统响应时间”指应用系统从请求发出开始到客户端接收到所有数据所消耗的时间。

这样，“系统响应时间”加上“呈现时间”，才是完整的用户感受到的响应时间。

 

经验公式：企业内部的文本系统如OA，平均每天访问系统用户数的10%作为平均的并发用户数。

并发用户最大值在这个值基础上面乘2~3

 

正常的话：吞吐量=（虚拟用户个数*每个虚拟用户发出的请求（单击）数量）/性能测试所用时间

遇到性能瓶颈的时候上面公式不成立

其中每个虚拟用户发出的请求（单击）数量= 时间/思考时间

 

首先计算出系统的并发用户数

统计出系统平均的吞吐量

统计出平均每个用户发挥的请求数量

根据上面公式计算思考时间

 

1：要保证每次执行的数据库具有相同的数据环境，不然得出的结果不可比

2：J2EE和DONET应用服务器需要先预热，让代码都编译为本地代码

 

性能测试专注的是服务端和应用之间的通信数据，而不是应用的GUI操作。

 

第二讲：Loadrunner目录分析

（我还是第一次认真看目录，以前除了破解的时候覆盖过，还真没看过）

 

AnalysisTemplates---- 分析模板，可以自己建一个自己的

Bin-----可执行程序，注意里面的CHM帮助文档。真是多，一共21个。好多网上流传的竟然就在这里真好。。。财富。

bincerts--安全证书

classes--可能用到的一些jar包

dat--备份文件和配置信息

ejbcomponent--ejb用的一些组件，相关的jar包

help--帮助中心，一共17个文档，db.pdf竟然是Mercury Virtual User Generator User’s Guide，晕厥，是不是打SP4补丁的时候出问题了。

include--头文件（可以编写自定义函数，保存为.h的头文件格式，并放在这个目录，以后只需要调用这个头文件就可以正常使用了）

samples---一些实例，有java的

tutorial---快速入门的实例，可以直接使用

WebTours--实例网站，

 

template--这个目录好像好多东西。是什么模板。以前还真没注意

winpcap--一个网络协议驱动的安装程序

 

第三讲：Loadrunner界面分析1

 

 Task模式？

 

VuGen

1：拥有不同的VuGen,所以可以模拟多种协议。在方案中执行是以VuGen脚本来执行

2：VuGen因为类型不同，生成的脚本的结构和内容会不同

3：VuGen只能录制windows上面的会话，但是录制出来的脚本可以在linux，unix上面运行。（RFT也是这样的）

 

新建脚本的方式

1：默认的新建单协议版本---（所以协议选择非常重要）

2：新建多协议版本

3：使用最近使用过的协议创建脚本---

 

 Task模式

给你一步一步的提示，只需要按照提示进行下一步就行了

 

一些设置

1：Tools--Recording options 里面需要注意的就是那个自动关联选项

2：Vuser-Runntime settings 

Run logics 迭代次数，Insert Block （可以把好几个action放在一个Block里面）

Pacing迭代的设置  ，设置以一种怎么样的方式开始下一次反复。

Log 日志的设置，设置成是否启动。以及日志级别

Think Time脚本中思考时间设置，

msicellaneous这个里面，线程还是进程。出现错误后的处理方式，主要配置其他运行时候的设置

speed slimulation用来模拟网速

 

选择那个展示浏览器在回放中的选项，如果被录制网站有activex插件或者js插件等是，VuGen回放的时候，

会需要人手工干预。但是在controller里面不需要干预了。 

 

 第四讲：Loadrunner界面分析2

 

 

Controller

1:可以用Controller 来管理和维护方案

2：使你可以从单一控制点简单有效的控制所有Vuser

 

创建运行场景

1：创建手动的

通过创建并指定脚本，负载生成器和每个组中包括的Vusers数，可以生成手动方案。

也可以通过百分比模式定义在方案中使用的Vusers的总数，并为每个脚本分配负载生成器和占总数一定百分比的Vusers。

注意的：

持续时间的设置将覆盖Vusers的迭代设置，如果设置为5分钟，将运行尽可能多的迭代。（到底多少有机会细查）

Vusers组的设置不适合百分比的模式

 

2：创建面向目标的（这个工作中我还没用到过）

在方案里面可以创建你希望实现的测试目标

可以定义5种类型的目标，虚拟用户数，每秒点击次数（仅Web Vusers），每秒事务数，每秒页面数（仅Web Vusers）[或者方案的事务响应时间]

验证给定条件下，系统在不同的硬件设备之间表现的诧异

 

3：运行方案

运行方案的时候，Loaruner将

记录在Vusers中设置的事务的持续时间，执行包括在Vusers脚本中的集合，收集Vusers生成的错误，警告，和通知信息。

在运行时候可以看任何Vuser的状态，或者让Vusers组和各个Vuser在停止前完成他们正运行的操作，或者立即停止运行。

 

4：Result的设置

Results--Results settings

建议name的命名方式--场景运行时间_脚本名称_虚拟用户数_场景持续时间

(有没有必要搞的这么麻烦~)

 

 

 5：监视方案

 

controller里面的runtime settings会覆盖脚本自己的runtime settings

 

 

第五讲：Loadrunner界面分析3+IP欺骗

 

 

1：Analysis分析基础

 

查看summary，主要是虚拟用户数和事务，

查看负载生成器和服务器的系统资源情况，往往内存泄露表现在CPU利用率过高。

查看虚拟用户和事务

查看错误发生的情况

查看Web资源和细分网页

 

（突然想到一个问题，贴出来）

Maximum Running Vusers跟虚拟的用户数不一致

遇到一个比较奇怪的问题，我虚拟了150个用户，运行成功后，Maximum Running Vusers:108，也没有提示错误，而且下面的action是pass的是150个,到底是什么问题呢，我去页面上看结果数据时，却是150个
如果都是默认设置的话，应该没有设置集合点，那么在虚拟了150个用户，运行成功后，Maximum Running Vusers:108是有可能的。
因为Maximum Running Vusers是最大“并发”用户数，而不是一共运行了多少用户。你在action前面加上集合点重新运行试试看

 

2：IP欺骗

 

Loadrunner--Tools--IP Wizard

在controller的scenario中启用IP欺骗，Scenario--Enable IP Wizard（必须在连接到Load generator前启用Ip欺骗）

Tools--expert mode

Tools--options--general

测试结束后要释放IP也是在Loadrunner--Tools--IP Wizard中操作（怕影响别人上网）

 

注意：

必须是固定IP，不支持动态IP

重启计算机后，可以用Ipconfig -all来查看IP地址

 

 远程的机器上面必须安装Loadrunner的Agent程序

ramp down 虚拟用户减少的方式

 

net use // [服务器IP]/ipc$/user:administrator*(然后输入administrator的用户口令，输入回车)

 

可以使用技巧在数据尚未接收完成时进行呈现来减少用户感受到的响应时间”

 

我们在定义响应时间的时候，是从应用的使用者/客户的角度出发的。从这个角度出发，响应时间被定义成“ 对请求做出响应所需要的时间”。我们以一个web应用为例，假设web应用有一个“提交用户留言”的功能，考察这个功能的响应时间，就应该是“从用户填写完留言，点击提交按钮开始，到页面刷新完成，用户看到完整的返回页面为止”所消耗的所有时间——这个定义非常完整，但若从用户的实际感受来看的话，这里还是有一点模糊的地方。

我们可以把上文提到的交互过程细化一下：

用户点击“提交”按钮-》请求被发送到服务器-》服务器处理-》服务器返回页面-》浏览器接收服务器的返回并render页面

模糊之处在于最后一个环节：“浏览器接收服务器的返回并render页面”，如果我们坚定的认为“只有当页面完整的显示完成，才是响应时间的结束”，这不会是一个问题。但实际上，对大多数用户来说，看到页面上开始显示数据或是图片，用户就会认为“我已经得到了响应”，从这个角度来说，用户感受到的响应时间实际上是“从请求发出开始，到用户看到页面开始呈现出的内容结束”所需要的时间。

那为什么我们不采用“从请求发出开始，到用户看到页面开始呈现出的内容结束” 这样一个定义方式呢？关键在于这里涉及到用户的认知行为，带有主观色彩，不完全是客观的标准，因此不适合作为一个需要被度量的性能指标。另一方面，不同的浏览器有不同的行为（例如parse的方式和render的方式），如果需要把这些浏览器本身的行为都考虑到性能测试中的话，我们很难为所有的系统建立统一的测试模型——实际上，现在的主流性能测试工具（例如JMeter，LoadRunner，Webload等）都完全不考虑客户端的呈现过程。