性能测试 LoadRunner11
一、性能测试基本概念（术语）
1、并发 Concurrency
在线 Online
并行：多个任务占据各自资源，一起运行
并发：多个任务占据同一资源，一起运行，需要争抢资源
1)、并发和在线的区别：
并发的压力是一个瞬时压力，一般针对同一类型的业务。
在线的压力是一段时间内的压力情况。
2)、20用户并发的压力相当于200用户在线的压力。（1:10的比例）
写测试计划时，可以参考，比如2000用户在线，一般是200个用户并发。
（并发登录、并发查询、并发删除等）
2、请求响应时间(TTLB,Time to last byte)=客户端时间+网络时间+服务器时间
单位，一般是秒/毫秒
可以通过内网测试规避掉网络的问题，客户端一般不会成为性能的瓶颈，
所以大部分情况下，如果请求响应时间长，性能瓶颈出现在服务器端。
建议：Web服务器和数据库服务器最好分开部署，可以分别监控
3、事务响应时间：前提是在录制脚本时，插入事务点
4、吞吐量(TP)：Throuthput 是总量，是累计时间的全部数据量，
用户在任意给定1秒从服务器获得的全部数据量，单位，字节
吞吐率(TPS)：在单位时间内的吞吐量
吞吐量/传输时间 每秒
TPS: Transaction Per Second 每秒事务数(事务数/秒)
点击率：每秒钟用户向Web服务器提交的Http请求数。
不是指鼠标点击的次数，比如：点击一个按钮，服务器返回一个页面，页面中包括了3个图片，
则当前发起的点击数：1+3 = 4个Http请求。
*.html 带有<img src="" /> 每个图片都是一个资源.都会重新发请求
吞吐率和点击率区别：
吞吐率：服务器每秒处理的数据量
点击率：客户端每秒向服务器提交的HTTP请求数
5、请求和响应：
客户端向服务器发起请求（Request），
服务器向客户端返回应答（响应 Response）。
6、资源利用率：一般指系统中CPU、内存、磁盘、网络等主要资源的使用情况。（了解，有难度）案例：测试登录模块在8个用户的情况下系统的性能情况
要求：用户数：8人 VU
用户加载方式：每2秒加载1个VU
运行时间：所有用户运行完脚本
登录用户名：jojo
密码：bean
操作：
1）录制好脚本 login day02/login
->点击New图标 -> New Virtual User -> 默认协议
-> Create 准备录制
-> 填写基本信息：
选择软件架构：Internet Applications (B/S) 默认
Win32 Applications (C/S)
选择浏览器类型：默认IE
URL Address: 被测系统的网址
http://127.0.0.1:1080/WebTours/
或http://localhost:1080/WebTours/
Working directory: LR工作路径 默认 常用工具命令
Record into Action: 录制脚本的位置 默认Action
(vuser_init 初始化 Action vuser_end 结束)
-> OK 自动打开浏览器 AUT,开始录制
关注小操作条 （录制控制 关注数字变化，数字稳定才继续）
-> 输入jojo bean
-> 开始事务 名称login (插入事务) -> OK
-> Login按钮
-> 结束事务 login -> OK
-> 改为vuser_end模式，点击Sign Off 退出
-> 关闭浏览器 -> 点击蓝色按钮 Stop 结束录制
-> 保存到新创建的day02/login文件夹中，脚本名：login
2）打开控制台Controller,使用login脚本，配置场景
打开Controller -> 默认手工场景模式 ->
将Use the Percentage Mode to... 去掉打钩
目的：用户数不使用百分比模式
-> Browse按钮 选择脚本 login -> OK
提示：如果脚本选错了，可以在后续主界面中修改
-> 设置8个VU: Run Mode: 选择Basic schedule
将Quantity 改为 8
-> 每2秒钟加载一个VU: 左下角窗口 Global Schedule
-> Start vusers: Start all Vusers simultaneously
默认是 同时加载8个虚拟用户，需要更改
-> 双击Start vusers -> Edit Action
-> 选择第2个单选钮，改为 1 Vusers every 00:00:02
(HH:MM:SS)
-> OK
-> Schedule Graphics 计划预览图
横坐标：Time 测试时间 纵坐标：Vusers 虚拟用户个数
每隔2秒钟加载一个虚拟用户
虚线表示 不确定
-> 设置运行时间: -> Duration中
Run until completion 运行直到结束 （脚本结束） 选择
Run for __ days and ___ (HH:MM:SS) 固定时间多久
Run indefinitely 不限定 无限制运行，测试者点击结束才结束
-》正常测试，还需要设置Windows Resources 监控的系统资源
（暂时不配置）
-> 切换到Run界面（运行场景）
（之前是Design 设定场景）
-> 设置好场景，可以运行场景
-> Start Scenario 按钮
点击Vusers按钮，进一步查看VU运行状态：
Done. Passed 1 iteration(s) attemped: 1successed.
结束 经过 1次迭代尝试1次成功了
观察场景运行结果图：
Running Vusers 正在运行的虚拟用户
Hit per Second 点击率
Throughput 吞吐量
点击正上方，右边倒数第3个图标按钮：
查看 Hp LoadRunner Analysis 结果分析报告
Reports 报告
Graphs 图片
Running Vusers 虚拟用户运行情况
Hit per Second 点击率
Throughput 吞吐量
Transaction Summary 事务概要
Average Transaction Response Time 平均事务响应时间二、性能测试策略
重要的：
基准测试(单用户)、并发测试、综合场景测试 （前3个项目必备）
极限测试、递增测试
次要的：
疲劳强度测试（大型系统中）、内存泄露测试、
数据容量测试。
共同点：向被测系统发起***1、基准测试：就是单用户测试 （重点）
注意：还是需要使用控制台，运行场景，自动搜集数据，通过Analysis进行结果分析。
2、并发测试：多用户并发执行某一操作（同一时刻，LR精确到毫秒级别）。
注意：并发测试是一种严格的测试，主要考察系统对瞬时较大压力的承受能力。
3、综合场景测试：号称“能够最真实的模拟 实际生产环境”。
综合场景的几个要素：
多用户、
多个脚本（至少3个，就是做多个不同的任务）、
在线执行一段时间（1个小时、50分钟等）
注意：一般不需要设置并发点。
多用户一起运行，一定会有并发。
综合场景测试过程中，所有用户 循环 执行相应的操作。
比如：100用户在线综合场景
100用户 共同对被测系统执行操作，
其中30用户执行浏览首页操作，
50用户执行查询订单操作，
20用户执行提交订单操作。
（要真实模拟人数比例）
问题：为什么不模拟大量的登录操作？
因为用户不可能一直在登录，模拟真实情况。
以上操作，用户在循环执行。
响应时间：业内一般有“358原则”，
系统响应时间在3秒以内，则用户能够接受；
响应时间在5秒以内，用户能够忍受；
响应时间超过8秒，用户不能忍受。
比如：一般需求指标，不超过3秒4、递增测试：每隔一定的时间(1s,5s,10s)逐步加载虚拟用户，逐步加压。
用途：登录测试时，可以递增测试
极限测试：使用并发测试、在线测试等方法，测试出系统能够承受的极限压力（如最大用户数），
或系统能够达到的最大处理能力（如最大吞吐量）。
测试方法可以采用递增测试，比如对系统进行100用户、500用户、1000用户等测试。
（也称为：摸高测试）
5、疲劳强度测试：在一定的强度（压力）下，对系统进行长时间的性能测试，
一般为724小时、或24小时、12小时等。
比如：银行系统，724*365 全天候不间断运行
考察疲劳强度测试时，要考察其平均响应时间，以及各台服务器的各项资源情况。
比如：集群 负载均衡、降低成本
以上是比较常见的测试类型，经常出现在测试计划中。6、内存泄露测试：
通过正常的性能测试，如果被测系统的内存曲线走势不正常，则关注其相应的各项重要的内存指标，
通过对应走势来确定是否发生内存泄露。
7、数据容量测试：使用大容量的数据添加到数据库中，观察被测系统是否能够正常运行。
比如：向数据库中添加200G的数据量，再进行测试。甚至几个T
大数据 Big Data 一般是T级、P级的数据量
1024Byte = 1KB
1024K = 1M
1024M = 1G
1024G = 1T
1024T = 1P
E Z Y
三、基准测试：单用户测试
1、测试脚本要加检查点。
原因：LR报告中的验证只是针对网络层面上，服务器收到客户端发送的数据包，之后将应答包发回给客户端，
但是LR不会验证应答包中数据是否正确。
案例1：对下订单操作进行基准测试。先录制脚本，插入检查点。
先打开AUT，熟悉整个业务流程；
打开VuGen -> 新建 输入URL -> 先录制登录
-> vuser_init -> 输入jojo和bean -> 开始事务 login
-> 点击Login -> 欢迎页面：
添加检查点：
选中“Welcome, jojo” 点击Insert text check 插入文本检查点
-> 结束事务login
-> Action模式 -> 点击Flights
-> 选择城市：从Denver 到 London
-> Continue -> Continue
-> 开始事务buy -> Continue -> 订单结果页面
添加检查点：
选中“Denver for London” 插入文本检查点
-> 结束事务buy
-> vuser_end模式 -> Sign Off -> 关闭浏览器 -> Stop
脚本保存：day02\buy 再回放
web_reg_find("Text=Welcome, <b>jojo,",LAST);
web_reg_find("Text=Denver for London",LAST);
检查点函数：web_reg_find() web_或lr_开头
reg字样的函数：注册性函数
web_submit_form() 提交表单的请求
对于B/S系统，LR脚本中的LR函数都是以lr_或web_开头。
（另外，还有C语言函数 strcmp）
web_reg_find函数，带有reg字样的函数称为：注册性函数
该类函数的特殊：必须写在相应请求之前。
加过检查点的脚本如果运行（回放）正确，则说明该脚本正确。
（学会调试脚本）需求：循环订3张票
VuGen中的Run-time Settings按钮 （运行时设置）
Run Logic 运行逻辑 -> Iteration Count 迭代次数 默认1 改为3
注意：循环的只是Action. 次数登录仅一次
init和end脚本仅执行一次。
注意：
1、控制台中和VuGen中设置Run-time Settings当前区别和联系：
1）如果从控制台直接打开脚本，则脚本中Run-time Settings设置会自动显示在控制台的Run-time Settings中。（带过来）
2）如果控制台和脚本中同时设置了Run-time Settings，并且值不同，控制台的优先级高。
2、Pacing值：每次迭代之间的时间间隔。
迭代：脚本Action从第一行到最后一行。迭代一次
Pacing值越大，对AUT的压力越小。
3、Think time: 脚本中步骤之间的时间间隔。
（请求之间的间隔）案例：针对buy脚本，进行基准测试 （方法1：单用户循环5次）
打开VUG录制脚本
1）调试好脚本（在VuGen中运行成功）
保存脚本文件：scrip/day02/buy1
打开Controller，设置场景
2）打开控制台，加载buy脚本
首先设置人数： Run Mode 单选Basic schedule模式
Quantity改为1 单用户模式
3）打开控制台Run-time Settings设置
Run Logic 迭代次数 5 （优先使用）
Pacing值 -- Start new Iteration 建议设置随机2~3秒
As soon as the previous interation ends 只要前一次迭代结束
关注第3项：
At fixed intervals, every 60.000 sec
random every 2.000 to 3.000 sec
fixed: 固定的
intervals 间隔
random: 随机的
Think time:
Ignore think time 忽略思考时间 选择 为了简单化
Replay think time 具体设置思考时间策略
-> 点击OK
6) Global Schedule设置
Initialize:初始化 Vuser在Run之前先初始化（保持默认）
Start Vusers: Start all Vusers simulaneously
就一个VU 默认
Duration: Run until completion 运行直到结束 默认
-> 切换到Run
开始运行场景： Start Scenario
6）结果分析
分析结果图：Running Vusers
横轴：Elapsed Time 测试时间
纵轴：# of Vusers 虚拟用户数量
点击启动后，场景初始化需要时间，无需关注
分析结果图：Hits per Second 点击率（每秒点击量）
横轴：Elapsed Time 测试时间
纵轴：# Hits per Second 点击率
数据偏低，因为是单用户
分析结果图：Throughput 吞吐量（服务器处理过的数据）
横轴：Elapsed Time 测试时间
纵轴：# Bytes/sec
由于时间不长，规律无法体现
保存场景文件：ctl/day02/buy1
打开Anlysis：倒数第3个图形按钮
最关心的是：事务响应时间
Transcation Name Average 平均事务响应时间
buy 0.23 合理的
login 0.406 合理的
细节可以关注左上角列表：各种常用指标图表
（先了解，后续会专门讲解）
保存结果文件：result/day02/buy12.归纳 基准测试：
方法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分钟
提示：配置好后，观察图表状态，有所变动，才修改成功。3、注意点：
当Run-time Settings中迭代和VU部署设置(Duration)有冲突时，Duration的优先级较高。
比如：Duration选择第二项，就以此为准
Run for __ days and __ (HH:MM:SS)
如果选择第一项：Run until completion 还是听Duration
只是它放权了。Duration是一把手，让二把手看着办，此时Run-time Settings说的算。
Duration:指Run的Action时间
测试报告中的结果，应该测试三次，取中间值。
（如：0.1秒 0.3秒 0.4秒 结果取0.3秒）
以上就是基准测试。简答题：
2、基准测试、并发测试的概念和做法？
1）基准测试就是单用户测试，需要打开控制台，获取Analysis中的结果。
（方法1：单用户循环n次；方法2：单用户执行n时间）
2）并发测试是多用户执行某一操作，形成瞬时压力（精确到毫秒），是一种严格的测试，
主要考察系统对瞬时较大压力的承受能力。
3、并发测试和在线测试的区别？
1）并发和在线的区别：
并发的压力是一种瞬时压力，
在线的压力是一段时间的压力。
2）20用户并发的压力相当于200用户在线的压力。（1:10比例）
在写测试计划时作为参考依据。2000用户在线，设计为200用户并发。
（并发操作：查询、登录、删除、添加）
4、吞吐量和点击率的概念、区别？
1）吞吐量（Throughput）:用户从服务器端获得全部数据量，单位是字节(Byte)。
2）吞吐量/传输时间，就是吞吐率，是服务器每秒处理的数据量。
3）点击率（Hits per Second）:客户端每秒向服务器提交Http请求数。
（鼠标的一次点击，请求数可能为n个）
说明：吞吐量是总量，是累计时间内全部数据量。
吞吐率反映服务器的处理速度和性能，也是衡量网络性能的重要指标。
点击率越大，对服务器的压力也越大。
Files/Doc.zip脚本中如何加注释
1）单行注释 //
2）多行注释 / /
一、昨天作业题：
1、思考：QTP和LoadRunner的区别。
1）QTP: 功能测试工具 （自动化）
LR: 性能测试工具 可以测多用户
2）QTP关心的是界面(UI)，关心的是对象（对象库的概念）；
LR只关心客户端和服务器之间的数据包（请求包、应答包），
不关心对象，更不需要比对对象的属性值，只关心抓包（捕捉数据包）。
如果用户界面变了，但是业务逻辑不变：QTP脚本需要变化，LR脚本不需改变。
3）LR关心的是客户端和服务器之间的对话，前提是选择正确的网络协议（相当于网络的语言）
4）LR不能补录。录制失败，从头再来。
注意：录制过程中出现失误，该次录制作废，从New开始重新录制；
录制时要慢，等待页面资源下载完毕后再进行下一步操作。