LR的基本操作

1、如何进行性能测试？ 先整体，后局部
1）分析需求（功能需求-业务逻辑、性能需求-性能指标）
常用指标：平均事务响应时间、
TPS Transaction Per Second每秒事务数、
最大并发用户数、系统资源特性...
2）制定性能测试计划 - 测试经理
主要考虑：测试范围、人员分配、时间进度、用例设计
测试策略：基准测试、并发测试、在线综合场景测试...
3）执行计划，使用LoadRunner，结合三大组件：
<1> VuGen: 根据协议录制和调试脚本，模拟1VU运行脚本
设置Run-time Settings 运行时设置
脚本增强技术：事务（平均事务响应时间、TPS）、检查点、集合点、参数化、关联...
<2> Controller: 设置、运行和监控场景，自动获取测试结果数据；
a. 场景模式：手工场景、共享设置、不使用百分比分配VU
b. 脚本组：组名、脚本路径、VU数量、...
c. VU的行为：初始化、加载方式、持续时间...
d. 设置Run-time Settings： 运行时设置
e. 系统资源监控
<3> Analysis: 对测试结果以各种图表形式展示，便于性能分析，获得性能测试报告。

一、性能测试的策略
重要的：基准测试、并发测试、在线综合场景测试
递增测试、极限测试...
1、基准测试：Benchmark Testing
含义：就是单用户测试，单用户、单测试点、执行n次；
作为后续测试的标杆，基本的准绳。
说明：还需要使用三大组件，VuGen 脚本-> Controller 场景 -> Analysis 结果
2、递增测试：不断加压，负载测试、压力测试的共性。
比如：每隔一定时间（1s, 5s, 10s ..）逐步加载VU，逐步加压；或在不同场景中使用不同VU数表示不同的压力。
3、并发测试：Concurrency Testing
含义：多用户在几乎同一时刻执行某一业务操作，形成一种严格的并发访问（LR精确到毫秒级别），观察系统在瞬时较大压力情况下的承受能力。
4、在线综合场景测试：号称“更真实模拟实际生产环境”
也称为：混合交易测试
交易也叫事务Tranasction
三个要素：
1）多用户：结合需求考虑在线用户数
2）多任务（脚本）：至少3个
3）在线执行一段时间：1个小时左右
注意：
1）多用户一起运行，就可能存在并发；
但是，不需要像并发测试那样设置集合点，不需要严格的刻意并发。
2）综合场景测试过程中，所有VU循环执行相应的业务操作。
举例：100用户在线综合场景
100VU共同对被测系统SUT执行各自操作，其中50VU查询商品、30VU添加购物车、20VU查询订单，在线持续运行1h.
问题：为什么不模拟大量的登录操作？
业务用户不可能一直在登录，要模拟真实的用户体验。

996 247

5、疲劳强度测试：压力更大、时间更长的在线综合场景测试。比如：对SUT进行长时间测试，一般12h、24h、7*24h
银行、互联网系统要求全年7*24不间断运行
要求：稳定*、安全
目的：检测系统的稳定性，比如长时间运行过程中是否出现内存泄露、磁盘空间不足、大量异常等问题。

6、内存泄露检查：通过正常的性能测试，如果SUT的内存曲线走势不正常时，则关注其他相关指标，通过其走势判断是否出现内存泄露。（了解）
内存泄露：C/C++/Java都存在，就是内存不够用。
以Java为例：JVM内存 栈区、堆区、方法区
Student s1 = new Student();
引用 --> 对象 在堆区分配
(对象的内存地址)
对象不断分配而未及时回收，导致堆内存空间不足，内存泄露。Java虽然有GC机制（内存对象垃圾收集机制-自动），但是也可能存在内存泄露问题。

7、数据容量测试：大数据量测试
比如：向数据库中添加200GB的数据量，再进行测试，有时甚至是几个TB.
大数据：Big Data 一般是T级、P级以上的数据量
核心：数据建模、数据挖掘 商业分析
根据以往的交易数据分析出未来的趋势，为商业决策提供重要依据。
1024Byte = 1KB
1024K = 1M
1024M = 1G
1024G = 1T
1024T = 1P
E Z Y ...

面试题：如何向数据库中插入大量的数据？比如插入10亿条
思路：SQL insert into 表名 values(值1, ...);
自动化：循环 反复执行insert
变量、参数化 代替固定的字面值
数据库可以写过程化语句，结合sql编程。

8、极限测试：也称为压力测试、摸高测试
含义：使用并发测试、在线综合场景测试等方法，测试出系统能够承受的极限压力（如最大并发用户数）或系统能达到的最大处理能力（最大吞吐量、TPS），可以采用递增测试等方法，比如对系统进行100VU、200VU、300VU...的性能测试。

二、基准测试：单用户、单测试点、执行n次/一段时间；
1、需求：对购票操作进行基准测试。
2、测试脚本中要加检查点。
原因：LR报告中（Test Results）验证的只是针对网络层面，服务器收到客户端的请求包，并将应答包返回给客户端，但是LR默认不会验证应答包中的数据是否正确。
性能测试的前提是功能的实现，如果误以为功能实现，会引起测试结果的误差。

案例：先录制buy脚本，插入文本检查点。
先打开SUT，熟悉购票业务流程；
录制流程：
New -> 选择vuser_init -> OK -> 首页面
-> 输入jojo和bean
-> 开始事务login -> 点击Login
-> 选中"Welcome, jojo, to" -> 插入文本检查点
Insert text check (小望远镜图标按钮)
-> 结束事务login
-> 切换到Action -> 点击Flights（等待页面加载完毕）
-> 选择城市从Denver到London -> Continue -> Continue
-> 开始事务buy -> 点击Continue
-> 针对"Denver for London" 添加文本检查点
-> 结束事务buy
-> 切换到vuser_end -> 点击Sign Off
-> 关闭浏览器 -> Stop
保存在：D:\work\script\day03\buy 编译 -> 回放

定义和调用函数的目的：复用已有的功能 不断的使用
web_reg_find("Text=Welcome, <b>jojo</b>, to",
LAST);
web_reg_find("Text=Denver for London",
LAST);
web_reg_find("Text=待检查的页面源代码文本", LAST);
来自于协议 HTTP响应数据包文本

3、检查点函数：web_reg_find("Text=xxx", LAST);
xxx就是需要检查的文本
规律1：对于B/S系统，LR脚本中具有两种函数：
1）C语言函数：函数名比较简约 strcmp 字符串比较
2）LR函数：一般lr_或web_开头
<1> 通用的函数：不同协议代码通用 - 重要！
lr_start_transaction lr_end_transaction 事务
lr_think_time 思考时间、等待时间
<2> Web[HTTP/HTML]协议下的函数： web_开头
web_url URL请求 web_submit_form 提交表单请求
web_link 模拟点击链接发送请求
web_reg_find 检查点函数
规律2：web_reg_find函数 带有reg字样
带有reg字样的函数，称为“注册性函数” regist 注册
特殊之处：必须写在相应请求之前！
相应请求：引起需要检查的响应所对应的请求。
相应请求之后，返回响应，响应中需要检查文本。
规律3：检查的是页面源代码文本 HTML语法
Welcome, <b>jojo</b>, to
Denver for London

初始化脚本 36行 附近相关代码 错误
vuser_init.c(36): Error -26366:
检查点的文本找不到
"Text=Welcome, <b>jojo1</b>, to" not found for web_reg_find

技巧：如何快速提高调试代码的能力？
必要时可以故意将代码改错，分析错误提示和原因。
根据错误提示信息找到错误位置，并调试。

4、只有添加过检查点的脚本运行正确，才说明脚本基本正确。（脚本需要适当的增强）

需求：循环订3张票 VuGen中Run-time Settings按钮
运行时设置
Run Logic 运行逻辑
Iteration Count: 迭代次数
Number of Iteration: 默认1 改为3次
注意：循环的只是Action部分
vuser_init和vuser_end部分仅执行一次

5、控制台和VuGen中设置Run-time Settings的联系和区别
1）如果从控制台中直接打开脚本，VuGen中的设置会带过来
2）如果控制台中也进行了设置，并且值不同，控制台的优先级更高；
3）建议：统一在控制台中设置

步调
6、Pacing值：每次迭代之间的时间间隔。 单位：秒
每次迭代：LR每次执行Action脚本代码
规律：Pacing值越大，对SUT的压力越小。

7、Think time：脚本每个步骤之间的时间间隔。 单位：秒
每个步骤：一般都是每个请求
web_url 访问某个URL请求
web_submit_form 提交表单请求
web_link 点击超级链接请求
用途：可以控制脚本中是否使用think time，以及如何使用
如果Ignore 忽略，则脚本中lr_think_time(18); 会失效。
规律：Think time值越大，对SUT的压力越小。

面试题：Pacing和Think time有何区别？
共同点：都是时间间隔，单位都是秒
时间间隔越长，对服务器压力越小
Pacing是迭代Action的时间间隔；
Think time是步骤、请求之间的时间间隔。

8、完成案例：针对buy进行基准测试 buy_基准测试_v1
方法1：单用户循环执行n次 比如5次
1）调试好脚本（在VuGen运行通过）
2）打开控制台，加载buy脚本
设置脚本组：组名、脚本路径、VU数量
Run Mode中，单选Basic Schedule
将Quantity改为1 单用户
3）打开控制台中的Run-time Settings:
迭代次数： 改为5
4）Pacing值：迭代的间隔时间
有三种方案：
<1> As soon as the previous iteration ends
只要上一次迭代结束 -- 紧锣密鼓
<2> 在上一次迭代结束后 设置为随机的2.000~3.000秒
固定的 延迟
With a _fixed_ delay of _6.000_ sec
随机的 时间精确到小数点后3位 2.768
With a _random_ delay of _2.000_ to _3.000_ sec
间隔
<3> At _fixed_ intervals, every _6.000_ sec
_random_ every _2.000_ to _3.000_ sec
5）Think time: 思考时间/等待时间
Ignore think time: 忽略思考时间 （选择）
脚本中lr_think_time函数会失效，目前对结果无影响
Replay think time: 可设置具体策略
-> 点击OK
6）设置VU的行为：
<1> 初始化：默认运行前初始化
<2> 加载方式：默认同时加载 就1VU
<3> 持续时间Duration：默认运行直到结束
保存场景文件：D:\work\scenario\day03\buy_基准测试1
-> 切换到Run视图
运行场景 Start Scenario

归纳基准测试：
方法1：单用户循环执行n次 比如5次
1）调试好脚本（加事务、检查点，在VuGen运行成功）
2）打开控制台，加载相关脚本 buy
3）设置VU数量：1个
4）设置VU 行为：初始化、加载方式、持续时间
5）设置Run-time Settings:
<1> 迭代次数：n次 比如5次
<2> Pacing: 随机2.000~3.000秒 迭代之间的间隔时间
<3> Think time: 可忽略 请求之间的间隔时间
原因：单用户对系统的压力较小，忽略对结果无影响。

方法2：单用户持续运行n时间 比如1分钟
1）调试好脚本（加事务、检查点，在VuGen运行成功）
2）打开控制台，加载相关脚本 buy
3）设置VU数量：1个
4）设置VU 行为：初始化、加载方式、
持续时间Duration: 改为持续运行1分钟
5）设置Run-time Settings:
<1> 迭代次数：1次 此处不起作用，取决于Duration
<2> Pacing: 随机2.000~3.000秒 迭代之间的间隔时间
<3> Think time: 可忽略 请求之间的间隔时间
原因：单用户对系统的压力较小，忽略对结果无影响。

说明：
1）当Run-time Settings中的迭代次数和Duration冲突时，Duration的优先级更高。
Duration：
第一项：运行直到结束
还是听Duration的，只是放权了，运行的次数取决于迭代次数。（方法1）
适用于：明确迭代次数时使用，比如迭代5次 限次数

第二项：Run for __ days and __(HH:MM:SS)
运行时间是由Duration说的算，Action迭代的次数取决于实际情况，Duration指的是Action持续迭代的时间，时间将至，LR会发出指令，通知VU结束运行。 Stop
适用于：明确限定Action迭代的时间，比如1分钟 限时间

2）如何统计性能测试结果数据？
建议对场景运行3次，在测试报告中，取中间值：
场景运行 平均事务响应时间
第1次 0.216s
第2次 0.203s
第3次 0.279s
结果取值：0.216s
3）目前暂时忽略系统资源监控（后续统一补充）

以上就是基准测试。

三、并发测试 Concurrency Testing
1、含义：多用户在几乎同一时刻执行某一业务操作，形成一种严格的并发访问（LR精确到毫秒级别），观察系统在瞬时较大压力情况下的承受能力。
2、并发测试的三要素（面试题：并发测试需要注意什么）
1）Action脚本中要添加事务；
既可以获取和事务相关的性能指标；时间 TPS 成功率
又可以作为并发的范围，从事务开始处一起并发
Action脚本中才可能执行并发
2）事务开始之前要加集合点（并发点）；严格的并发
3）控制台场景中要设置并发策略。 并发的规模

集合点：5个线程，代表5个VU，并发执行一次购票
buy事务的开始
o-----------|o----------
o-----------|o----------
o-----------|o----------
o-----------|o----------
o-----------|o----------
此处设置集合点（并发点）
Action脚本中，在buy事务开始之前，设置集合点；
等所有VU到达集合点时，才一起释放，此时的压力最大
-- 瞬时压力
并发策略：比如，当所有VU到达集合点时一起释放

3、集合点只有在并发测试时才使用。
-- 营造一种严格的并发（狭义的并发）
日常多任务也存在并发（广义的并发）

4、案例：5VU并发购票
1）先录制buy脚本，添加事务、检查点
技巧：脚本的备份 File -> Save As 另存为 buy1
2）Action中，buy事务开始之前添加集合点
光标在事务开始之前 lr_start_transaction("buy");
点击 Insert -> Rendezvous 集合点
-> 输入集合点名称 Rendezvous Name: buy 同事务名
就会生成脚本：lr_rendezvous("buy");
LR的通用函数 集合点函数
-> 及时保存 -> 编译 Compile 保证最新版本
3）打开控制台，设置并发策略
加载buy1脚本
注意：如果加载后的脚本修改了，先编译脚本，并在控制台中刷新脚本：
针对控制台中脚本组 右击-> Details 细节
-> Refresh 刷新 下拉菜单：
1) 常用Script: 刷新脚本
2) Runtime Settings: 不常用 将VuGen中设置覆盖过来
建议统一在控制台中设置为好
选择Scenario菜单 -> Rendezvous 设置并发策略
-> 窗口中，点击Policy按钮 策略
第1项：Release when 100% of all Vusers arrive at the
rendezvous. （选择此项）
当100%的所有VU到达集合点时一起释放
比如：10VU都算 10*100% 10*n%
第2项：Release when 100% of all running Vusers arrive at the rendezvous.
当100%的正在运行的VU到达集合点时一起释放
比如：10VU中只有5个正在运行 5*100% 5*n%
第3项：Release when 1 Vusers arrive at the rendezvous. 指定n个VU到达集合点时一起释放
补充：Timeout between Vusers: 30sec
超时时间：从先到达集合点的VU开始计时，如果超时30秒用户未到齐，先释放到达集合点的用户，形成局部并发。
4）完成5VU并发购票其它设置：
<1> 控制台中：VU数 5个
<2> VU行为：
初始化：默认
加载方式：默认同时 目前VU较少
持续时间：运行直到结束 每个VU只需迭代1次
<3> Run-time Settings:
迭代次数：1次
Pacing: 无需间隔时间
Log: 默认日志
Think time: 默认忽略，让VU更快到达集合点，更严格
<4> 系统资源监控 目前只添加部分一项 未来十几项
Run视图 -> Windows Resources Windows系统资源
右键 -> 添加指标 Add Measurements...
Add 添加监控的主机名Name：localhost
平台Platform：WINXP
清空旧的指标，Add添加新的：
类别：Processor 处理器，就是CPU
%Processor Time CPU使用率
阈值：不超过80%
-> 运行场景 -> 查看结果报告 buy_并发测试_5VU_r1
平均事务响应时间：0.384秒
CPU使用率平均值：73.698% 接近80% 担心CPU瓶颈

场景文件：buy_并发测试_5VU
业务名 策略名 并发规模

buy_并发测试_10VU
平均事务响应时间：0.386秒
CPU使用率平均值：88.542% 超过80% 存在CPU瓶颈

归纳：
1、测试策略：基准测试、并发测试、在线综合场景测试
2、基准测试：单用户、单测试点、执行n次/n时间
3、并发测试：多用户并发执行某功能点
三要素：Action中加事务、事务前加集合点、场景中设置并发策略 集合点函数：lr_rendezvous("集合点名");