LoadRunner（3）

一、性能测试的策略
　　重要的：基准测试、并发测试、在线综合场景测试
　　递增测试、极限测试...

　　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:\work\script\day03\buy 编译 -> 回放

　　　　　　　　定义和调用函数的目的：复用已有的功能 不断的使用
　　　　　　　　　　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:\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）
　　　　　　　　　　　　第二项：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("集合点名");