一、性能测试的策略
重要的：基准测试、并发测试、在线综合场景测试
递增测试、极限测试...
1、基准测试：Benchmark Testing
含义：就是单用户测试，单用户、单测试点、执行n次；
作为后续测试的标杆，基本的准绳。
说明：还需要使用三大组件，VuGen 脚本-> Controller 场景 -> Analysis 结果
2、递增测试：不断加压，负载测试、压力测试的共性。
比如：每隔一定时间（1s, 5s, 10s ..）逐步加载VU，逐步加压；或在不同场景中使用不同VU数表示不同的压力。
3、并发测试：Concurrency Testing
含义：多用户在几乎同一时刻执行某一业务操作，形成一种严格的并发访问（LR精确到毫秒级别），观察系统在瞬时较大压力情况下的承受能力。--- 严格的并发（狭义的并发）
4、在线综合场景测试：号称“更真实模拟实际生产环境”
三个要素：
1）多用户：结合需求考虑在线用户数
2）多任务（脚本）：至少3个
3）在线执行一段时间：1个小时左右
注意：
1）多用户一起运行，就可能存在并发；（广义的并发）
但是，不需要像并发测试那样设置集合点，不需要严格的刻意并发。
2）综合场景测试过程中，所有VU循环执行相应的业务操作。（Action部分）
举例：100用户在线综合场景
100VU共同对SUT执行各自操作，其中50VU查询商品、30VU添加购物车、20VU查询订单，在线持续运行1h.
问题：为什么不模拟大量的登录操作？
业务用户不可能一直在登录，要模拟真实的用户体验。
5、疲劳强度测试：压力更大、时间更长的在线综合场景测试。比如：对SUT进行长时间测试，一般12h、24h、7*24h
银行、互联网系统要求全年7*24不间断运行
要求：稳定*、安全
目的：检测系统的稳定性，比如长时间运行过程中是否出现内存泄露、磁盘空间不足、大量异常等问题。
6、内存泄露检查：通过正常的性能测试，如果SUT的内存曲线走势不正常时，则关注其他相关指标，通过其走势判断是否出现内存泄露。
内存泄露：C/C++/Java都存在，就是内存不够用。
以Java为例：JVM内存 栈区、堆区、方法区
Student s1 = new Student();
引用 --> 对象 在堆区分配
(对象的内存地址)
s1 = null;
对象不断分配而未及时回收，导致堆内存空间不足，内存泄露。Java虽然有GC机制（内存对象垃圾收集机制-自动），但是也可能存在内存泄露问题。
ABC 人工智能 大数据 云计算
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:workscriptday03uy 编译 -> 回放
定义和调用函数的目的：复用已有的功能 不断的使用
web_reg_find("Text=Welcome, <b>jojo</b>, to", LAST);
web_reg_find("Text=Denver for London", LAST);
3、检查点函数：web_reg_find("Text=xxx", LAST);
xxx就是需要检查的文本
规律1：对于B/S系统，LR脚本中具有两种函数：
1）C语言函数：函数名比较简约 strcmp 字符串比较
strcmp("abc", "abb");
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_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的压力越小。
8、完成案例：针对buy进行基准测试
方法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:workscenarioday03uy_基准测试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）
第二项：Run for __ days and __(HH:MM:SS)
运行时间是由Duration说的算，Action迭代的次数取决于实际情况，Duration指的是Action持续迭代的时间，时间将至，LR会发出指令，通知VU结束运行。 Stop
2）如何统计性能测试结果数据？
建议对场景运行3次，在测试报告中，取中间值：
场景运行 平均事务响应时间
第1次 0.215s
第2次 0.203s
第3次 0.279s
结果取值：0.215s
3）目前暂时忽略系统资源监控（后续统一补充）
以上就是基准测试。
三、并发测试 Concurrency Testing
1、含义：多用户在几乎同一时刻执行某一业务操作，形成一种严格的并发访问（LR精确到毫秒级别），观察系统在瞬时较大压力情况下的承受能力。-- 狭义的并发
2、并发测试的三要素（面试题：并发测试需要注意什么）
1）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秒用户未到齐，先释放到达集合点的用户，形成局部并发。
3）完成5VU并发购票其它设置：
<1> 控制台中：VU数 5个
<2> VU行为：
初始化：默认
加载方式：默认同时 目前VU较少
持续时间：运行直到结束 每个VU只需迭代1次
<3> Run-time Settings:
迭代次数：1次
Pacing: 无需间隔时间
Log: 默认日志
Think time: 默认忽略，让VU更快到达集合点，更严格
-> 运行场景 -> 查看结果报告
补充系统资源监控：
系统资源：CPU、Memory、Disk、Network...
内存 硬盘 网络
比如：CPU中 %Processor Time 指标、计数器（多项）
表示CPU使用率、CPU忙的时间的百分比
阈值：70%~80%
测试结果报告：
结果1：5VU并发购票
1）事务指标：
事务名 最小 平均 最大 标准方差 90%时间 成功 失败
buy 0.234 0.409 0.531 0.126 0.531 5 0 0
login 0.563 0.807 1.278 0.245 1.278 5 0 0
buy的平均事务响应时间：0.409s 符合需求 <3s
最大：0.531 比较合理
标准方差：0.126 比较稳定
buy的TPS：每秒事务数（吞吐率、效率）
最小 平均 最大
0 0.5个 5个/秒
成功率：100%
2）点击率：12.5次/秒
3）系统资源情况：
%Processor Time CPU使用率：
最小 平均 最大 标准方差
59.896 69.792 82.813 9.613
平均：69.792% 非常接近阈值70%
最大：82.813% 超过阈值
初步结论：事务时间特效良好，但CPU使用率过高，怀疑CPU存在瓶颈（核实：CPU 1个 单核 处理能力不够）
优化建议：要么增加CPU数量、增加CPU内核数；
要么使用主频更快的CPU。 2.5GHz
结果2：10VU并发购票
1）事务指标：
事务名 最小 平均 最大 标准方差 90%时间 成功 失败
buy 0.25 0.444 1.203 0.271 0.547 10 0 0
login 0.531 0.941 2.562 0.565 1.095 10 0 0
buy的平均事务响应时间：0.444 符合需求 <3s
最大：1.203 比较合理
标准方差：0.271 比较稳定
buy的TPS：每秒事务数（吞吐率、效率）
最小 平均 最大
0 0.833个 6个/秒
成功率：100%
2）点击率：20.833次/秒
3）系统资源情况：
%Processor Time CPU使用率：
最小 平均 最大 标准方差
58.854 85.287 100 15.687
平均：85.287% 超过阈值70%
最大：100% 满百
初步结论：事务时间特效良好，但CPU使用率过高，确定CPU存在瓶颈（核实：CPU 1个 单核 处理能力不够）
优化建议：要么增加CPU数量、增加CPU内核数；
要么使用主频更快的CPU。 2.5GHz
综合建议：要采用配置更好的服务器主机；
同时兼顾操作系统、软件的部署和配置。
归纳：
1、测试策略：基准测试、并发测试、在线综合场景测试
2、基准测试：单用户、单测试点、执行n次/n时间
3、并发测试：多用户并发执行某功能点
三要素：Action中加事务、事务前加集合点、场景中设置并发策略 集合点函数：lr_rendezvous("集合点名");