LoadRunner性能测试学习笔记.doc

一、 性能测试基本概念
1、 性能测试:模拟真实得生产环境,以各种不同得压力(模拟大量用户)去测试被测系统、去"攻击"测试系统。同时记录下被测系统中 各台 服务器得各种重要资源情况,包括cpu、内存、磁盘与网络等资源。
2、 性能测试得目得？
识别系统中得弱点、评估系统能力、进行系统调优,提高系统得可靠性、稳定性。
3、 在具备什么条件下可以开展性能测试工作。
答:功能测试通过;一般需要进行性能测试得系统,大多就是用户量比较大、业务使用比较频繁、对响应时间要求较高、比较重要得功能模块。(注意:性能测试之前要做好系统备份)
4、 性能测试时首先瞧性能需求,如果没有需求,这时要根据与客户交流、被测系统得相关资料、以及性能测试工程师得经验,去编写测试计划,进行性能测试。
5、 被测系统
SUT (System Under Test)
AUT (Application Under Test)
EUT (Environment Under Test)
6、 LoadRunner工作原理:(录制--回放得工作方式)与QTP类似
1） 录制时,LoadRunner记录下 客户端与服务器 二者之间得对话。
2） 回放时,LoadRunner模拟 真实得客户端 向服务器发起请求,并按照脚本去验证服务器得应答
7、 LoadRunner得三大组件及功能:(三个火枪手) OALoad工具类似(触类旁通)
1） 虚拟用户脚本生成器(Virtual User Generator)VuGen VUG
功能:录制、编辑、调试测试脚本
2） 压力调度控制台 (Controller)
功能:创建场景、运行场景、监控场景、收集测试数据(场景:就就是一个大型得配置文件)
3） 压力结果分析器 (Analysis)
功能:把收集到得测试数据以图表得形式展示出来,生成测试报告
8、 LoadRunner基本测试流程:
1） 指定性能测试计划(部分) Word
2） 创建测试脚本
3） 编辑、运行测试脚本
4） 创建场景
5） 运行、监控场景,收集数据
6） 生成测试报告,分析测试结果
9、 什么就是事务,为何要创建事务？
答:事务分为事务得开始、结束与之间得业务操作,事务用于度量服务器性能得。(事务响应时间)
我们可以对比较关心得某个或某些业务操作,设定为一个事务,LR会记录不同事务得响应时间。
10、 请求响应时间=客户端时间+网络时间+服务器时间
11、 负载测试与压力测试得区别: (国内混用,国外有差别,笔试时需要注意)
1） 共同点都就是在测试过程中逐步加压
2） 负载测试:强调系统正常工作情况下得性能指标; Load Testing(见好就收)
压力测试:目得就是发现在什么条件下系统得性能变得不可接受,发现应用程序性能下降得拐点; Stress Testing(使劲折腾)
举例:一座大桥,桥上写最大载重量得车辆,不超过60吨
但就是在桥梁内部建筑资料,最大载重量,不超过70吨
12、 吞吐量与点击率得概念、区别？
1） 吞吐量(Throughput):用户从服务器端获得全部数据量,单位就是字节(Byte)。
吞吐量/传输时间,就就是吞吐率,就是服务器每秒处理得数据量。
2） 点击率(Hits per Second):客户端每秒向服务器提交请求数。(鼠标得一次点击,请求数可能为n个)
说明:吞吐量就是总量,就是累计时间内全部数据量。
吞吐率反映服务器得处理速度与性能,也就是衡量网络性能得重要指标。点击率越大,对服务器得压力也越大。
13、 并发测试与在线测试得区别？
1） 并发与在线得区别:并发得压力就是一种瞬时压力,在线得压力就是一段时间得压力。
2） 20用户并发得压力相当于200用户在线得压力。(1:10比例)
在写测试计划时作为参考依据。2000用户在线,设计为200用户并发。(并发操作:查询、登录、删除、添加)
14、 QTP与LoadRunner得区别:
1） QTP: 功能测试工具 (自动化)
LR: 性能测试工具 可以测多用户
2） QTP关心得就是界面(UI),关心得就是对象(对象库得概念);
LR只关心客户端与服务器之间得数据包(请求包、应答包),不关心对象,更不需要比对对象得属性值,只关心抓包(捕捉数据包)。
如果用户界面变了,但就是业务逻辑不变:QTP脚本需要变化,LR脚本不需改变。
3） LR关心得就是客户端与服务器之间得对话,前提就是选择正确得网络协议(相当于网络得语言)。
4） LR不能补录。录制失败,从头再来。
注意:录制过程中出现失误,该次录制作废,从New开始重新录制;
录制时要慢,等待页面资源下载完毕后再进行下一步操作。
二、 性能测试得策略
重要得:基准测试、并发测试、综合场景测试 (前3个项目必备)
极限测试、递增测试
次要得:疲劳强度测试(大型系统中)、内存泄露测试、
数据容量测试。
共同点:向被测系统发起攻击
1、 基准测试:就就是单用户测试(重点)
注意:还就是需要使用控制台,运行场景,自动搜集数据,通过Analysis进行结果分析。
2、 递增测试:每隔一定得时间(1s,5s,10s)逐步加载虚拟用户,逐步加压。
用途:登录测试时,可以递增测试
3、 并发测试:多用户并发执行某一操作(同一时刻,LR精确到毫秒级别)。
注意:并发测试就是一种严格得测试,主要考察系统对瞬时较大压力得承受能力。
4、 综合场景测试:
概念:号称“能够最真实得模拟 实际生产环境”。
综合场景得几个要素:多用户、多个脚本(至少3个)、在线执行一段时间(1个小时、50分钟等)
注意:一般不需要设置并发点。
多用户一起运行,一定会有并发。
比如:100用户在线综合场景:
100用户 共同对被测系统执行操作,其中30用户执行浏览首页操作,50用户执行查询订单操作,20用户执行提交订单操作。(要真实模拟人数比例)
问题:为什么不模拟大量得登录操作？
因为用户不可能一直在登录,模拟真实情况。
以上操作,用户在循环执行。
5、 响应时间:业内一般有“358原则”,系统响应时间在3秒以内,则用户能够接受;响应时间在5秒以内,用户能够忍受;响应时间超过8秒,用户不能忍受。
比如:一般需求指标,不超过3秒
6、 疲劳强度测试:在一定得强度(压力)下,对系统进行长时间得性能测试,一般为7*24小时、或24小时、12小时等。
比如:银行系统,7*24*365 全天候不间断运行
考察疲劳强度测试时,要考察其平均响应时间,以及各台服务器得各项资源情况。
比如:集群 负载均衡、降低成本
7、 内存泄露检查:通过正常得性能测试,如果被测系统得内存曲线走势不正常,则关注其相应得各项重要得内存指标,通过对应走势来确定就是否发生内存泄露。
8、 数据容量测试:使用大容量得数据添加到数据库中,观察被测系统就是否能够正常运行。
比如:向数据库中添加200G数据量,再进行测试,甚至几个T大数据,一般就是T级、P级得数据量
1024Byte = 1KB
1024K = 1M
1024M = 1G
1024G = 1T
1024T = 1P
9、 极限测试:使用并发测试、在线测试等方法,测试出系统能够承受得极限压力(如最大用户数),或系统能够达到得最大处理能力(如最大吞吐量)。测试方法可以采用递增测试,比如对系统进行100用户、500用户、1000用户等测试。(也称为:摸高测试)
三、 三大基本测试(基准测试,并发测试与综合场景测试)得具体方法及配置
1、 归纳基准测试:
方法1:单用户循环5次
1） 调试好脚本(加检查点,在VuGen中运行成功)
2） 打开控制台,设置Run-time Settings
3） 迭代次数:5
4） Pacing值:随机2~3 (每次迭代之间得时间间隔)
5） Think time: 忽略 (请求之间得时间间隔)
忽略得原因:单用户对系统压力较小,忽略与否对结果影响不大。
方法2:单用户持续运行1分钟
1） 调试好脚本(加检查点,在VuGen中运行成功)
2） 打开控制台,设置Run-time Settings
3） Pacing值:随机2~3
4） Think time: 忽略
5） Duration: 1分钟
提示:配置好后,观察图表状态,有所变动,才修改成功。
注意:当Run-time Settings中迭代与VU部署设置(Duration)有冲突时,Duration得优先级较高。
比如:Duration选择第二项,就以此为准
Run for __ days and __ (HH:MM:SS)
如果选择第一项:Run until pletion 还就是听Duration,只就是它放权了。
Duration就是一把手,让二把手瞧着办,此时Run-time Settings说得算。
测试报告中得结果,应该测试三次,取中间值。
比如:0、1秒 0、3秒 0、4秒 结果取0、3秒
2、 并发测试
a、并发测试两个条件
1） 脚本中要有集合点(并发点)
2） 控制台中要设置并发策略(选择第一项,所有虚拟用户到达集合点后释放)
集合点: 5个线程,代表5个VU 并发执行一次购票

等所有线程到达集合点时,才一起释放,此时得压力最大(瞬时压力)。
注意:要在事务开始之前,设置并发点
b、并发点只有在并发测试中使用。
案例:在脚本中添加并发点,执行并发测试
需求:并发购票
注意:在事务脚本之前添加
lr_start_transction("buy");
在事务开始之前 --> 点击Insert --> Rendezvous
--> 输入集合点名称Rendezvous Name: buy 一般与事务名相同
就会生成脚本:lr_rendezvous("buy");
--> 编译 pile(同时会立即保存)
注意:脚本中发生变动(加了检查点、集合点、代码等)
1） 一定要点击编译 pile按钮,同时也会自动保存
2） 在控制台中要刷新脚本
c、并发策略得设置:
并发策略就是在控制台配置:
控制台界面选择Scenario菜单 --> Randezvours、、、(并发点)
--> 打开窗口,设置策略 --> 点击Policy(策略)按钮
第1项:Release when 100% of all Vusers arrive at the rendezvous、(一般都选择此项)
当100%虚拟用户到了集合点时释放虚拟用户VU
(所有VU得n%) 10个VU 都算 10 * n%
第2项:Release when 100% of all running Vusers arrive at the rendezvous、
当100%正在运行得VU到达集合点时释放VU
(所有正在运行得VU得n%)
如果10个VU只有5个正在运行,5 * n%
第3项:Release when 1 Vusers arrive at the rendezvous、
指定n个虚拟用户达到集合点,再释放
d、并发测试案例:完成5个VU得并发
控制台 -> Basic schedule -> Quantity 改为 5
Start Vusers: 用户数少,登录时间快,不用改
Duration: 选Run until pletion 表示瞬时压力
继续设置Run-time Settings:
Run Logic: 迭代次数 1
Pacing: 改为As soon as the previous iteration ends、
Log: 默认
Think time: 默认 忽略 Ignore think time(好比:不停地发请求,不给喘息时间)
e、并发测试要点回顾:
1） 事务前设置并发点(lr_rendezvous("buy");)
2） 控制台中设置并发策略
3） 要忽略Think time
3、 综合场景测试
综合场景测试号称能够最真实得模拟实际生产环境
综合场景得几个要素:多用户、多个脚本(至少3个)、在线执行(多种操作)一段时间(1小时、50分钟等),一般就是不加并发点。
注意:只要就是多用户,就存在并发
综合场景测试过程中,所有用户循环执行相应得操作
1） 录制好3个脚本:购买机票buy、查询路线search、浏览航班scan
添加好事务点、检查点;(无需集合点)
转移事务中得Think time脚本至事务之外:lr_think_time(23);
将脚本载入到控制台中,并设置人数比例:
Group Name Quantity
buy 2
search 4
scan 4
2） 设置场景
Schedule by:
Scenario: 按场景 场景中,多个VU统一配置、行动 (选择)
Group: 按组 每个组,组内VU统一行动 (按组行动)
重点设置左下角Global Schedule:
以上三个脚本都选中,一次配置三个(出现黑框) -->
a、Start Vusers双击-> 设置一个小得递增 单选第2项
--> 1 00:00:01 [HH:MM:SS] --> OK
该设置表示:每隔1秒钟加载一个VU--> 及时观察右边效果图:锯齿状
b、Duration 双击
--> 单选第2项:Run for 0 days and 00:30:00 (HH:MM:SS)--> OK
该设置表示:确定指定测试运行得时间为30分钟 (项目中一般50分钟、1小时)
如果第1项:Run until pletion 直到结束,适合于循环,确定次数;
如果第3项:Run indefinitely 一直跑,直到手动停止
3） Run-time Settings设置
说明:迭代次数默认1 具体次数由持续时间决定
a、pacing: 随机4-6秒 或 5-9秒
正常:2-3秒,教学机较慢,设置偏大些,保证不出错
b、日志log: 保留原有选项(出错时发送)
原因:大量日志也会占用磁盘空间。
c、Think time: 随机百分比,适当调大 200% - 300%
d、Continue on error: 错误时继续
原因:长时间执行大量事务,个别出错继续运行,不影响全局。
e、Vuser选择 线程 方式。节省系统资源
f、网络:模拟用户得网络,使用最大带宽
g、模拟缓存:选择不模拟
h、Option 选项:3个120改为600
一般疲劳测试设置600足够了。
4） 配置Windows resources
选择Run视图-->右击窗口-->Add Measurements、、、
-->Monitered Server Machines: 选机器 点击Add、按钮 -->
Machine Information:
Name: localhost 指定监控服务器得IP地址,主机名,目前就就是本地主机
Platform: WINXP
--> OK
Resource Measurements on: localhost 清空里面所有选项
自己完成选项得添加(固定13项)--> 点击Add按钮 --> 选择以下内容:
Memory中有4项:(内存)
Available MBytes --> Add
%mitted Bytes in Use --> Add
Page Faults/sec --> Add
Pages/sec --> Add
Network Interface中有2项: (网络)
Bytes Total/sec --> MS TCP Loopback inter、、、回环 --> Add
本地主机才选回环
Packets/sec --> MS TCP Loopback inter、、、回环 --> Add
本地主机自己与自己通信,用回环
PhysicalDisk中有4项(2个队列):(磁盘)见到Total就选
Avg、Disk Queue Length --> Total --> Add
Current Disk Queue Length --> Total --> Add
Disk Read Bytes/sec --> Total --> Add
Disk Write Bytes/sec --> Total --> Add
Processor中有2项:(进程)
%Processor Time --> Total --> Add Total表示总与
%User Time --> Total --> Add
System中有1项: (系统)
Processor Queue Length --> Add
--> OK
以上一共13项windows监控资源,具体说明如下:

注意:运行过程中如果有错误,观察Scenario Status中得Errors 部分 0 (点开链接,寻找出错原因)
如果就是场景设置问题,需要重新设置场景,重新运行
如果就是脚本得问题,需要停止场景并调试脚本,重新运行
四、 参数化
1、 含义:同样得业务,出现不同得数据,考虑采用脚本参数化技术
2、 步骤:
确定参数化得数据-->准备数据-->提供策略-->参数化
3、 准备数据 (目前:File方式)
1） 每个参数使用独立文件 (参数池)
2） 多个参数共享同一个文件 (常用)
Excel工具、Column(序号、列名)、First Data(从哪开始)
4、 参数池得策略(难点)
1） Select next row 选择下一行 (How? 如何取?)
a、顺序 Sequential: 从第一行开始顺序向下选取
b、唯一 Unique: 从第一行开始,唯一向下选取
c、随机 Random: 随机取值
d、Same line as xxx: 取值策略与参数xxx相同 (同一行)
2） Update value on 更新方式 (When? 何时取?)
a、每次迭代 Each iteration: 每次迭代时取值。(Action一次)
b、每次遇到 Each occurrence: 每次遇到该参数时。
c、取值一次 Once: 脚本运行过程中只取值一次。
3） When out of values: 选择Unique才有,数据不足时处理情况:
a、放弃虚拟用户 Abort Vuser
b、以循环得方式继续 Continue in a cyclic manner
c、持续最后一个值 Continue with last value
经典需求:注册脚本,多用户,则参数池策略组合
Unique + Each iteration + Abort Vuser
另外,常用得组合:SE组合 (顺序 + 每次迭代)
5、 综合题(帮助理解参数池得策略)
某参数现有备用数据a1, a2, a3, 、、、 a30; 脚本迭代4次;3个VU;
完成一项结果: (必须掌握！)
1） 顺序 + 每次迭代 <重要>
VU1: a1 a2 a3 a4 顺序 每个VU取值序列相同
VU2: a1 a2 a3 a4 每个VU都从第一个开始往下取
VU3: a1 a2 a3 a4 每个VU共迭代4次,取4次值
2） 唯一 + 每次迭代(无特殊说明,块大小为自动分配) <重要>
VU1: a1 a2 a3 a4 唯一 从第一行依次唯一向下选取
VU2: a5 a6 a7 a8 每个VU都不同
VU3: a9 a10 a11 a12 每个VU共迭代4次,取4次值
3） 随机 + 每次迭代 <重要>
VU1: a18 a3 a5 a17
VU2: a20 a18 a13 a22
VU3: a30 a2 a28 a14
4） 顺序 + 每次遇到
VU1: a1 a2 a3 a4
VU2: a1 a2 a3 a4
VU3: a1 a2 a3 a4
顺序:每个VU都从第一个顺序向下取值 Action中参数只出现1次
每次遇到:每个VU遇到4次
(注意:使用参数模拟器,会出问题,不能被模拟,因为不确定数据量就是否足够)
5） 唯一 + 每次遇到(块大小为6) <重要>
VU1: a1 a2 a3 a4
VU2: a7 a8 a9 a10
VU3: a13 a14 a15 a16
唯一:块大小6 第一块(a1 a2 a3 a4 a5 a6)
第二块(a7 a8 a9 a10 a11 a12)
第三块(a13 a14 a15 a16 a17 a18)
每次遇到:每个VU遇到4次,取每块中得前4个
6） 随机 + 每次遇到
VU1: a5 a8 a11 a20
VU2: a7 a5 a9 a15
VU3: a12 a17 a24 a26
每次遇到:由于参数只出现一次,效果等同于每次迭代
7） 顺序 + 一次 <重要>
VU1: a1 a1 a1 a1
VU2: a1 a1 a1 a1
VU3: a1 a1 a1 a1
顺序:每个VU取值一样;一次:只取第一个值
8） 唯一 + 一次 <重要>
VU1: a1 a1 a1 a1
VU2: a2 a2 a2 a2
VU3: a3 a3 a3 a3
唯一:每个VU从第一开始,唯一向下取值
一次:每个VU取值后,不再换值
9） 随机 + 一次 <重要>
VU1: a5 a5 a5 a5
VU2: a16 a16 a16 a16
VU3: a18 a18 a18 a18
随机:每个VU任意取值; 一次:取值一次,不再换值
10） 唯一 + 每次迭代 (块大小为6)注意与 2)得区别
VU1: a1 a2 a3 a4
VU2: a7 a8 a9 a10
VU3: a13 a14 a15 a16
唯一:块大小6 第一块(a1 a2 a3 a4 a5 a6)
第二块(a7 a8 a9 a10 a11 a12)
第三块(a13 a14 a15 a16 a17 a18)
五、 常用函数
1、 web_find函数
1） 写在相应请求之后
2） Run-time Settings需要设置:可用
3） 左边界:RightOf
4） 右边界:LeftOf
5） web_find执行效率低于web_reg_find、
2、 lr_output_message就是LR得输出函数,经常用于脚本得调试。
3、 脚本中快速定位
1） 从日志定位到脚本行:双击日志、根据行号 Ctrl + g
2） 从脚本行定位到日志中:右击脚本 -> Go to Step in Replay log
4、 检查点函数区别
1） web_find() (LR普通函数)
特点:从HTML页面中查找指定得文本字符串(比较占资源、效率低、较少使用)
2） web_image_check()
a、alt参数:当鼠标悬浮在图片上时显示得名字,给用户瞧得
b、src参数:图片得路径名及图片名称,给程序员瞧得
3） web_reg_find() (LR注册性函数)
特点:在缓存中(Html源代码级别)查找相应得内容
效率高,最常用
web_reg_find要写在相应请求之前,因为就是注册性函数
规律:LR所有注册性函数,含有reg字样,都要写在相应请求之前。
5、 脚本代码阅读说明(重要):
web_reg_find("Text=ABC", "SaveCount=abc_count", LAST);
web_url("Step", "URL=、、、", LAST);
if (strcmp(lr_eval_string("{abc_count}"), "0") == 0) {
lr_output_message("not found");
} else{
lr_output_message("%s times", lr_eval_string("{abc_count}"));
}
1） LR脚本中有两种变量,一种就是C语言得变量,需要在脚本得开始处定义(如:int a; );另一种就是LR得变量,出现在LR得函数里,不需要定义,但就是如果使用LR变量得实际值,则必须加{} (如:{name})
2） lr_eval_string函数 起到一个桥梁得作用,将LR得变量介绍给C语言得函数使用。 LR变量 --> C语言能够理解得字符串(高级脚本调试时常用)
该函数得返回结果,就可以给C语言函数当做参数使用。
lr_eval_string("{abc_count}");
lr_eval_string("{name}");
3） strcmp(a, b) 表示比较两个字符串变量得值就是否相等,如果返回0,则表示两个字符串相等。(C语言函数)
4） lr_eval_string("{abc_count}")
lr_eval_string之后默认接(); ()中就是字符串,所以加 " "
" " 中不就是普通字符串,而就是LR字符串变量,固定需要用{ }
5） C语言中%s表示字符串格式符,经常用于输出语句;%d 表示整数得格式符。
六、 关联
1、 关联产生得原因
产生问题得原因:Client端 WebServer端
真实情况:
Client 请求1 -------> WebServer
响应1 <------- 提供一个uid 123
请求2 携带uid 123 ---->
响应2 <---------
LR模拟情况(第3项):
Client 请求3 携带uid 123 ---> WebServer
响应3 <------- 提供一个uid 456
请求4 携带uid 123 ---->
响应4 <--------- 错误原因:uid不匹配
某些系统得服务器在第一次与客户端打交道时,会附带一个id(该id随不同用户得变化而变化);当客户端之后发请求时需要该id才能继续;而LR在录制时形成得id就是一个静态得id(如123),这就导致客户端在发请求时无法获取服务器每次发送得动态得id,导致脚本失败。(脚本调试方向:将静态得id换成动态id)
关联得概念:Correlation
把脚本中某些写死得数据,转变为服务器所发送得、动态得、每次都不一样得数据。
何时做关联:正常录制,但就是回放不成功,考虑就是否关联。
2、 一般关联得操作得三大步骤:
1） 从服务器返回得数据中选取需要进行关联得数据。(找数据)
2） 将该数据存入脚本得一个参数中。
变动得数据在脚本中就是参数,由于就是变化得,所以叫动态ID
3） 将脚本中需要使用数据得地方用该参数代替。
动态ID:需要关联得数据
比如:每一次执行脚本都会变动得值,就需要关联
执行一次就变动一次,或录制一次也会变动一次
3、 如何找到动态ID
1） 原理:每执行(或者录制)一次,都会变动得值。
2） 录制两个一模一样业务流程得脚本,进行比对,找出动态ID。
3） 动态ID一般就是一串无规律得字符串(少数情况下有规律)。
4） 动态ID一般不就是坐标值、think time时间、检查点函数,也不就是整段得请求。
关联类型:
1） 手动关联 (常用)
2） 自动关联 (经常导致脚本失败,LR回退,很少使用 了解)
手动关联得具体步骤:
1） 录制脚本,回放有错误。确定由于动态数据造成得。
2） 再录制一份相同流程得脚本。
3） 使用WDiff工具进行比较。(操作熟练,可以省略)
4） 使用web_reg_save_param()函数,在源文件中找到需要关联得字符串(动态数据),存入一个参数中。
5） 把录制时数据替换为该参数(动态数据)
web_ reg_save_param注册性函数,需要写在相应请求之前:寻找相应请求
4、 如何查找到相应请求？(为了在相应请求之前写关联函数)
1） 拷贝动态ID适当长度(太长有可能在显示时换行、太短可能重复较多),从Generation Log得第一行开始查找！！！
如果查找到得位置在服务器得应答包中,说明查找正确。
(第一次,就是从服务器发出得ID)
在脚本中拷贝ID得一小段:114276、5 ctrl + c
点击Generation Log --> 从第一行开始查找 ctrl + f
--> ctrl + v 查找该文本
找到位置在应答包中 Response标题 With Id 14
2） 查找到之后,选取适当长度得左右边界,拷贝下来,准备写函数。
name=userSession value=114276、568975294fiHiVAVpAVzzzzzHDfczipzAzV
3） 先向下慢慢翻找,找到与当前应答id号相同得id号得请求,该请求即为相应请求。(90%得情况都就是在下方不远处)
4） 如果找不到,则回到原位置,向上慢慢找到最近得一条请求。
5） Request 与 Event 都就是请求。
web_url("、、、 "Snapshot=t1、inf", ); 快照名就是唯一得,作为线索
寻找脚本中ti、inf对应得请求位置。将拷贝得串信息粘贴到请求之前。
6） 找到相应请求之后,在请求之前写关联函数,并将后续脚本中用到动态ID得位置用函数中得参数替代。
web_reg_save_param("uid", //参数名称
"LB=左边界得字符串", //左边界
"RB=右边界得字符串", //右边界
LAST);
相应请求;
之后,将脚本中得ID值,用参数uid代替:
"Name=userSession", "Value=114276、568975294fiHiVAVpAVzzzzzHDfczipzAzV", ENDITEM,
改为:
"Name=userSession", "Value={uid}", ENDITEM,
即可。{uid} 取得LR得变量值,LR语法范围内有效得。
编译脚本 --> 回放
5、 从业务逻辑去分析请求,相应请求所在得位置,当前脚本就是基于HTML方式录制,结构较简单,所以当客户端 第一次对服务器发请求时,服务器就已经分配了动态ID,来识别不同得用户。所以第一次发请求就就是相应请求。(基于URL得录制方式,则比较复杂,需要更加仔细分析)
所谓相应请求,就就是 产生动态ID得应答 得相应请求。
七、 性能测试分析
性能测试结束后,要对测试结果进行分析。分为三种情况:
1、 测试结果完全符合需求,不需要分析。
2、 测试结果存在问题(不符合需求,时间超长),直接通过测试报告(Analysis)查找到原因。直接写出报告。(前提:对应Analysis中结果描述非常清楚。)
3、 如果通过测试报告没有得出结果(性能瓶颈),这种情况比较复杂。
4、 比如发现某些事务响应时间超长(最普遍),该如何处理？
1） 通过Analysis报告中几个比较重要得图表进行查瞧,初步定位问题,再通过网页细分图(网页诊断图)去确定响应时间长在系统得哪个部分。大多数情况下,时间长在服务器端。
(响应时间 = 客户端时间 + 网络时间 + 服务器时间)
2） 要进一步确定就是哪台服务器(复杂得系统服务器n,甚至几十台--集群)
答案:通过 监控服务器得系统资源图,能够很容易地定位出哪台服务器不正常。
3） 如果就是应用服务器(在企业中也常称为中间件),如Tomcat、JBoss、Weblogic、WebSphere,发生问题,调整服务器配置参数即可。
共性:都就是软件,都安装在服务器主机上提供企业级应用得支持。
区别:免费、收费(上百万)
Tomcat: Apache开源组织、免费
Weblogic: BEA公司出品,后来被Oracle收购了
WebSphere: IBM公司应用服务器
4） 大部分情况都就是数据库服务器出现问题,可以通过专门得 数据库监控工具 去监控,甚至可以提取到相应有问题得sql语句。可以对sql语句进行分析、调优,进而提升被测系统得性能。
5、 以上得调试流程不适合于每个被测系统,绝大部分得系统可以在前面得某些步骤中即可停止,完成性能分析过程。
6、 页面细分图:
1） 操作:右击Graphs --> Add New Item --> Add New Graphs、、、
--> 打开 Open a New Graph窗口,在Web Page Diagnostics中进一步查瞧细分图。
a、Web Page Breakdown
页面中得组件,也叫做页面中得元素。包括组成网页得内容:文字、图片、音频、视频、动画、、、
b、Page ponent Breakdown (Over Time)
页面组件细分图(随时间变化) 更细致
c、Page Download Time Breakdown
页面下载时间细分图
响应时间:包括请求后,响应得各个阶段
八项中主要关注前4