LR的操作进阶

1、如何进行一次性能测试？
1）分析需求（功能需求-业务逻辑；性能需求-性能指标）
常见的性能指标：
平均事务响应时间、TPS、最大并发用户数、点击率、吞吐量、系统资源监控...
2）制定性能测试计划：选择测试工具-LoadRunner11
测试范围、测试用例、测试策略、人员分配、进度安排、提交物...
常见的测试策略：
<1> 基准测试：单用户、单测试点、持续运行n次或n时间
<2> 并发测试：多用户、单测试点、严格并发执行
三要素：1. Action脚本需要添加事务
lr_start_transaction("事务名");
...
lr_end_transaction("事务名", LR_AUTO);
2. 事务开始之前要加集合点
lr_rendezvous("集合点名");
3. 控制台场景中设置并发策略
比如：让n%的所有VU到达集合点时一起释放
<3> 综合场景测试：多用户、多测试点、在线执行一段时间
3）执行测试计划：LoadRunner的三大组件
<1> VuGen: 录制和调试脚本、1VU回放脚本、设置Run-time Settings; -- 模拟功能的实现、为后续运行提供增强点
<2> Controller: 设置、运行、监控场景 Scenario
场景模式、脚本组（组名、脚本路径、VU数量）、
VU行为（初始化、加载方式、持续时间）、
Run-time Settings（迭代次数、Pacing、Log、Think time）、系统资源监控
<3> Analysis: 结果分析

2、QTP和LoadRunner的区别？
1）QTP: 功能自动化测试工具
LR: 性能测试工具 模拟大量VU，产生压力/负载
2）QTP关心的是界面（UI），关心的是对象（对象库）；LR只关心客户端和服务器之间的数据包（请求包、应答包），不关心对象，更不需要比对对象的属性值，只关心抓包（捕捉数据包-抓包工具：Wireshark、Fiddler等）-- LR关心网络协议（参考当前项目使用的技术协议）
3）如果用户界面改变了，但业务逻辑不变：
QTP的脚本需要变化，LR的脚本不需要改变。
4）LR不能补录，录制失败，从头再来。

一、LoadRunner工具的组成
1、VuGen 虚拟用户脚本生成器
脚本好比：武器 VuGen好比：兵工厂 VU好比：士兵
2、Controller 压力调度控制台 好比：总指挥部
3、Analysis 压力结果分析器 好比：军情分析部门
4、Load Generator 负载生成器/压力产生器
好比：总指挥部指挥下的作战部队 VU好比士兵
原理：就是使用一台物理机，使用其性能生成大量的VU产生负载（压力）。 通过进程或线程模拟
比如：一个部队支持2000人，如果需要10000人？
方法1：找性能更好的测试机，起更多VU；
方法2：联机测试-使用多台测试机的性能联合产生VU。
面试题：如果不用联机测试，如何起更多的VU?
使用配置更高的测试机
面试题：如何搭建性能测试环境？（重要） 如图
思路：涉及面多（硬件、软件、架构...），整个团队共同讨论的问题。具体问题具体分析--看需求
5、Agent 代理程序 好比：通讯兵
原理：Agent进程默认开启，部署在不同的测试机，协调得到步调一致的VU.
状态：默认开启，如果关闭，如何打开？
开始 -> 所有程序 -> HP LoadRunner
-> Advanced Settings 高级设置
-> LoadRunner Agent Process
结论：如果想让某台测试机参与联机测试，至少需要安装Load Generator，并且启动Agent进程才可收到控制台的命令。
6、Monitor 监控系统 好比：作战观察团
原理：监控被测系统服务器主要资源指标的计数器。
比如监控CPU、Memory、Disk、Network等资源情况
常用计数器：%Processor Time CPU使用率

分析LR工具组成图：结合三大、四大组件为主要线索
SUT 被测系统
Java Client/IE Client: C/S 或 B/S的 客户端
HTTP Protocol: HTTP协议
Capture & Record 捕捉 和 录制
Scripts 脚本
Run-time Settings: 运行时设置
Scenario 场景
Schedules 计划安排
Run Log 运行日志
LG 产生 VU 负载的来源
Monitoring 监控系统资源
Start/Stop 开始/结束
Client Emulation 客户端 模拟
Report & Graphs 报告和图表
各种形式：Word、网页格式、Excel、Access数据库、水晶报告、Mercury Diagnostics 诊断图

Ajax：异步的JavaScript和XML -- 异步通信协议
同步：A任务完成后，B才能开始
异步：A正在执行，B也可开始运行
举例：浏览器局部刷新，比如验证码、注册时用户名验证

二、LoadRunner工具组成图：
1、对于给定SUT，VuGen可以按照指定的协议（Http协议、Ajax等软件使用的相关的技术协议），对于不同客户端（PC、移动；浏览器B/S、App C/S）进行捕捉和录制，生成脚本。考虑对脚本增强：事务、检查点、集合点、参数化、关联、流程控制等；
2、在VuGen设置Run-time Settings，模拟1VU运行；
3、在控制台Controller中，设置场景（测试计划）：场景模式、脚本组（组名、脚本路径、VU数量、Load Generators）、VU行为（初始化、加载方式、持续时间）、Run-time Settings、各台服务器的系统资源监控（Monitor），运行和监控场景，获取运行日志；
4、场景运行结束后，使用Analsis获取结果报告和图表，便于分析，完成性能测试报告。

三、参数化：脚本增强技术
以不变的业务（脚本流程），处理不同的数据 -- 更真实
常量、字面值 -- 不可改变
public static final double PI = 3.1415926535897932;
变量 -- 名称不变、值可以改变
int age = 23; age = 25;
思想：以不变应万变！ 变量名不变，值可改变
具备参数池：管理不同的数据、制定不同的策略。

1、定义：
对脚本中的常量（字面值）进行参数化，让不同VU在执行相同脚本时，分别使用参数池中的不同数据代替这些常量，从而达到模拟用户真实使用系统的情况。

2、步骤：
1）确定哪些数据要参数化； 比如jojo 和 bean
2）准备参数池：类型 + 数据 + 策略
3）将数据使用参数代替。

3、案例：针对购票脚本buy的登录部分进行参数化
准备工作：注册一些新的用户账户
账户信息保存原理：当前不存数据库，而是保存在普通文件
C:\Program Files\HP\LoadRunner\WebTours\MercuryWebTours\users
保存不同账户文件，文件名就是用户名，第一行是密码
后续为用户其它信息、购票记录
首页 -> Sign up now 注册账户
Username: qq Password: 123 Confirm: 123 确认密码
-> 提交
录制buy脚本：事务、检查点 day04\buy
录制时使用jojo和bean
1）确定哪些数据要参数化:
init脚本中：jojo和bean 需要参数化
技巧：搜索文本中字符串 ctrl+f F3 继续搜索
双击选中jojo -> 右击
-> Replace with a Parameter 使用一个参数代替
弹出窗口：
Parameter Name: username 参数名/LR变量名
Parameter Type: File 参数类型-文件 常用
Original value: jojo 原有初值
-> {username} LR变量取值方式 {LR变量名}
注意：检查其它相关的常量，也需要替换 F3继续搜索
选中jojo -> Use Existing Parameter 使用已存在的参数
-> 选择username -> {username}
同理：也将密码bean 都替换成 -> {password}

2）准备参数池：类型+数据+策略 打开参数池配置窗口
VuGen中倒数第2个按钮：Open Parameter List
比如：点击username->Edit with Notepad 使用记事本编辑
username
jojo
qq
| <-- 使用ctrl+a 全选 检查格式：
确保光标在最后一行数据的下一行的开头
保存ctrl+s 及时关闭记事本，避免版本问题
将First data: 1改为2 从第2行开始取数据

同理：选择password 编辑文本password.dat 增加一行123
First data: 2
目前效果：采用qq和123完成登录
编译 -> 回放脚本

提示：如果脚本运行失败，根据回放日志Replay Log，查看错误位置，根据提示的行，找到附近代码，根据提示的原因进行调试。
初始化脚本 36行附近 文本找不到
vuser_init.c(36): Error -26366: "Text=Welcome, <b>jojo</b>, to" not found for web_reg_find

技巧：调试脚本时，可以启用扩展日志，查看参数的替代信息。 Run-time Settings -> Log
-> Extended Log 扩展日志
-> Parameter substitution 参数替代信息
运行后，从日志中查看到参数的使用情况。
Notify: Parameter Substitution: parameter "username" = "qq"

练习：让jojo和qq各自订一张票（参数池策略）
建议：清空jojo和qq的订票记录，便于观察
打开Parameter List窗口：
将username和password的First data: 都改为1
都从第1行开始取数据
打开Run-time Settings: 迭代次数：2次
编译 -> 运行
遇到问题：jojo登录1次，订票2次
vuser_init 1次 -> Action 2次 -> vuser_end 1次
登录脚本 参数化 购票
登录脚本 参数化
解决方法：将init脚本中的代码剪切到Action中，参与迭代
注意：保持原有代码的语法格式
vuser_init(){
可以转移....
return 0;
}

四、参数池的策略初步（Parameter List窗口中设置）
特点：功能强大、全面，产品的一个卖点
1、Select next row （How? 如何取？）取值方式
选择下一行
1）Sequential 顺序的 （默认）
每个VU都从第1行开始顺序向下取值；
2）Random 随机取：每个VU都可随机从参数池中取值
3）Unique 唯一取：每个VU都唯一取值，不能重复
比如：用户注册，用户名不能重复
4）Same line as xxx: 和xxx参数同行取值、策略相同
比如：password 设置为 Same line as username

2、Update value on （When? 何时取？）更新时机
1）Each Iteration: 每次迭代时更新 （默认）
2）Each Occurrence: 每次遇到参数时更新
3）Once 仅取一次 每个VU一次选择，不再改变

说明：案例中采用的是默认的SE组合：顺序 + 每次迭代
Sequential + Each Iteration
脚本Action迭代2次，值需要更新2次，由于采用顺序方式，第一次迭代取第1行：jojo和bean；第二次迭代取第2行：qq和123.
username password
jojo bean
qq 123
| |

五、参数化案例：使用脚本参数化技术，注册30个账户
1、具体要求：
1）脚本中需要添加事务、检查点（自动检查）
2）确保30个账户全部注册成功
3）建议使用VuGen调试，1VU压力较小，容易成功
测试数据时，要促进成功。
2、先准备账户数据：使用Excel 设计 qq1~qq30 1~30
新建data.xls
3、录制用户注册脚本reg
New -> 选择协议 -> Create -> 确认URL
-> Action 注册需要迭代 -> OK
-> Sign up now
-> 输入Username: www Password:123 Confirm:123
-> 开始事务reg -> Continue -> 欢迎页面：
-> 插入文本检查点：Thank you, www,
-> 结束事务reg
-> 切换到vuser_end -> 点击Continue -> Sign Off
-> 关闭浏览器 -> Stop
保存脚本：day04\reg 技巧：多备份 另存为reg1

参数化：方式1 设计两个参数{usernam} {password}
使用两个独立的文件保存各自数据：
username.dat 和 password.dat
选中两处www -> 替换成{username} 新建、已存在
选中两处123 -> 替换成{password}
技巧：双击 ctrl + f F3
打开Parameter List： 设置数据 + 策略
先选中username -> 拷贝qq1~qq30 编辑username.dat
再选中password -> 拷贝1~30 编辑password.dat
注意文本格式：ctrl+a 检查 没有多余的字符，多留一行
使用策略：默认SE组合 顺序+每次迭代
注意迭代次数不能超过30次，否则数据会重复使用
-> 关闭窗口
设置Run-time Settings:
1）迭代次数：10
2）Pacing：选择第2项 随机Random 2.000~3.000
3）Log: 日志 为了更详细，可以启用扩展日志
Standard Log 标准日志
Extended Log 扩展日志 （选择）
Parameter substitution 查看参数替代信息 （选择）
说明：调试脚本时经常启用扩展日志，分析数据获取的规律
4）Think time: 选择Replay think time 启用
-> Use random percentage of recorded think time:
使用 随机 百分比 脚本已记录 思考时间
Min: 50% Max: 150%
假如脚本中：
lr_think_time(10); 随机等待5~15秒 比如：8.76秒
目的：模拟用户不规律的等待时间，更真实
建议：测试数据时，减小压力，促进成功。
配置完成 -> 编译 回放

方式2：两个参数共享一个数据文件 username.dat
前提：username和password有关系
打开day04\reg脚本 另存为 reg2
-> 将脚本中www -> {username}
123 -> {password}
技巧：双击 ctrl+f F3 新的、已存在的代替
-> 准备数据 + 策略：
data.xls 拷贝数据 -> 粘贴到username.dat文件
编辑文件：两列属性共享一个文件
使用批量替换技巧，将制表符Tab 替换成英文的逗号 ,
username,password
qq1,1
qq2,2
...
qq30,30
| <-- ctrl+a 检查格式

在Select Column中：可以指定选择哪一列
1）根据列号：1 2 3 ...
2）根据列名：username password 见名知意 推荐使用
在File format中：指定格式
默认使用逗号分隔每一列 Comma 推荐使用
其它：Tab 制表符 或 Space 空格

-> 针对username设置：选择列号1 或 列名username
First data: 11 从qq11开始
策略：默认SE组合 顺序+每次迭代
-> 针对password设置：
将File：改为username.dat 共享一个文件
选择列号2 或 列名 password
技巧：重新开启窗口才更新
First data: 11 从11开始
策略：默认SE组合
或 Same line as username 和username同行取值
此时First data失效
-> OK
设置Run-time Settings: （同方法1）
1）迭代次数：20次
2）Pacing: 随机2.000~3.000秒
3）Log: 扩展日志，查看参数替代信息
4）Think time: 随机50%~150% 也可忽略
-> 编译 -> 运行

复习：
1、如何进行一次性能测试？
1）分析需求（功能需求-业务逻辑；性能需求-性能指标）
常见的性能指标：
平均事务响应时间、TPS、最大并发用户数、点击率、吞吐量、系统资源监控...
2）制定性能测试计划：选择测试工具-LoadRunner11
测试范围、测试用例、测试策略、人员分配、进度安排、提交物...
常见的测试策略：
<1> 基准测试：单用户、单测试点、持续运行n次或n时间
<2> 并发测试：多用户、单测试点、严格并发执行
三要素：1. Action脚本需要添加事务
lr_start_transaction("事务名");
...
lr_end_transaction("事务名", LR_AUTO);
2. 事务开始之前要加集合点
lr_rendezvous("集合点名");
3. 控制台场景中设置并发策略
比如：让n%的所有VU到达集合点时一起释放
<3> 综合场景测试：多用户、多测试点、在线执行一段时间
3）执行测试计划：LoadRunner的三大组件
<1> VuGen: 录制和调试脚本、1VU回放脚本、设置Run-time Settings; -- 模拟功能的实现、为后续运行提供增强点
脚本增强技术：事务（时间、TPS、并发的起点）、检查点（响应包进行检查）、集合点（并发测试才有）、参数化（类型+数据+策略）、关联、流程控制（分支、循环）、函数调用（代码复用）...
<2> Controller: 设置、运行、监控场景 Scenario
场景模式、
脚本组（组名、脚本路径、VU数量、Load Generators）、
VU行为（初始化、加载方式、持续时间）、
Run-time Settings（迭代次数、Pacing、Log、Think time）、系统资源监控：CPU、Memory、Disk、Network等
<3> Analysis: 结果分析

练习讲解：使用参数化技术注册30个账户
方式1：两个参数使用各自独立的dat文件
方式2：两个参数共享一个数据文件 username.dat
前提：username和password有关系
打开day04\reg脚本 另存为 reg2
-> 将脚本中www -> {username} {LR变量名} 取值
123 -> {password}
技巧：双击 ctrl+f F3 新的、已存在的代替
-> 准备数据 + 策略：
data.xls 拷贝数据 -> 粘贴到username.dat文件
编辑文件：两列属性共享一个文件
使用批量替换技巧，将制表符Tab 替换成英文的逗号 ,
username,password
qq1,1
qq2,2
...
qq30,30
| <-- ctrl+a 检查格式

在Select Column中：可以指定选择哪一列
1）根据列号：1 2 3 ...
2）根据列名：username password 见名知意 推荐使用
在File format中：指定格式
默认使用逗号分隔每一列 Comma 推荐使用
其它：Tab 制表符 或 Space 空格

-> 针对username设置：选择列号1 或 列名username
First data: 11 从qq11开始
策略：默认SE组合 顺序+每次迭代
-> 针对password设置：
将File：改为username.dat 共享一个文件
选择列号2 或 列名 password
技巧：重新开启窗口才更新
First data: 11 从11开始
策略：默认SE组合
或 Same line as username 和username同行取值
此时First data失效
-> OK
设置Run-time Settings: （同方法1）
1）迭代次数：20次
2）Pacing: 随机2.000~3.000秒
3）Log: 扩展日志，查看参数替代信息
4）Think time: 随机50%~150% 也可忽略
-> 编译 -> 运行

结论：具体问题具体分析
方式1：适合参数之间没有关系时使用，比如员工姓名、商品的价格分开管理；
方式2：适合参数之间有关系时使用，比如员工的多个属性:
id,username,password,salary,birthday,address
1001,Tom,123,6000.0,1995-05-23,海淀
...
共享一个文件，每一行就是一个员工的信息（记录），每一列就是每个属性（字段）。

一、综合场景测试：号称能更真实模拟实际生产环境
又称为：混合交易测试 （交易就是事务 Transaction）
1、三要素：
1）多用户：根据需求指定VU数 压力的来源
2）多任务：根据需求结合多个任务混合执行 3个以上
通过多个脚本体现
3）在线持续运行一段时间：一般1h左右

2、录制脚本时建议进行必要的设置：
1）让页面的标题变为自动的文本检查点。
（<title>标题文本</title>）
建议：开发方在设计网页时，给不同的页面使用不同的标题，用于辅助的检查。比如成功页面和错误页面的标题不同。
操作：VuGen -> Edit Recording Options 编辑录制选项
选择Advanced高级 ->
选择Generate web_reg_find functions for page title.
为页面标题生成检查点函数。

2）为VuGen录制时指定合适的字符编码集：
原因：为了避免录制后脚本中文乱码问题
原理：char c1 = 'A'; 65 打印出 c1 + 1 66
每个字符都对应一个数字 -- 字符编码
常见的字符编码表：
美国 AscII 编码表 1Byte中7bit 0~127 128种字符
字符 十进制数 编码
'0' --- 48
'1' --- 49
'A' --- 65
'a' --- 97
西欧 Latin-1/ISO8859-1 1Byte中8bit 256种字符
任何字符集都和AscII向下兼容：
结论：英文和数字不会出现乱码问题
中国：GBK/GB2312 2Byte 表示更多整数 -- 字符
国际通用：UTF-8 可变长 英文1Byte/中文3Byte
支持多种国家的字符集，项目中常用
中文乱码的原理：编解码方式的不统一
编码 解码
'你' '好' GBK 1122 3344 GBK '你' '好'
Latin-1 ?? 不存在
UTF-8 '鍦' '嚎'
操作：建议将字符集改为适合当前项目的编码表
比如常用UTF-8
Support charset -> UTF-8
能够避免录制后脚本中的中文出现乱码。

3、需求：针对WebTours项目核心测试点进行一次综合场景测试，针对购票、查看航班、浏览线路操作进行10用户在线综合场景，持续运行1小时（压缩为20分钟）。

4、先录制脚本：script\day05目录下
注意添加事务、检查点：
1）购票 buy
2）查询航班 search
New -> vuser_init -> 输入jojo和bean
-> 开始事务login -> 点击Login -> 结束事务login
-> 改为Action -> 点击Flights
-> 选择城市从Denver到Paris -> 开始事务search
-> 点击Continue -> 检查点“Denver to Paris”
-> 结束事务search
-> 改为vuser_end -> Sign Off -> 关闭浏览器 -> Stop

3）浏览线路 scan
New -> vuser_init -> 输入jojo和bean
-> 开始事务login -> 点击Login -> 结束事务login
-> 改为Action -> 开始事务scan -> 点击Itinerary按钮
-> 结束事务scan
-> 改为vuser_end -> Sign Off -> 关闭浏览器 -> Stop

5、脚本注意事项：
1）合理添加事务：后续场景中针对不同事务自动统计平均事务响应时间、TPS等结果；
2）适合添加检查点：不添加导致结果无法核实，如果添加过多会影响工具性能。建议手工添加1~2个，结合自动页面标题检查点即可。
3）问题：是否启用Think time？ 思考时间/等待时间
分析：为了保证业务的真实性，需要思考时间，模拟用户步骤之间的等待；如果事务内含有思考时间，会累加到平均事务响应时间中，对结果产生影响。
结论：建议启用思考时间，并将事务内的lr_think_time();转移到事务开始之前。
操作：对三个脚本的不同部分进行检查，尤其是事务内
buy search scan init 和 Action
注意：及时编译 -> 回放 确保最新版本
4）在线综合场景的脚本中不需要设置集合点，只有并发测试才需要。因为虽然多用户可能存在并发，但无需像并发测试那样形成瞬时压力。如果有集合点，建议注释掉：
//lr_rendezvous("集合点名");
5）参数化：根据业务需要进行，目前暂时忽略。
6）场景设置的前提：确保脚本录制、调试、回放成功。

6、打开控制台Controller，设置10VU综合场景
使用手工场景、不使用百分比方式分配VU
（1）设置场景模式、脚本组：
New Scenario -> Browse 依次载入day05\三个脚本
buy、search、scan 配置脚本组：
-> Basic Schedule
Group Name Quantity
buy.3 2
search 4
scan 4
一共10个VU，根据用户习惯设置合适的比例，模拟真实的访问效果。
（3）场景方式：
Schedule by:
1) Scenario: 默认按照场景方式（选择）
特点：所有脚本组共享同一个场景
2) Group: 按照组方式，分组设置场景
特点：不脚本组可以单独设置场景
用途：适合多个组之间有协作关系时使用，比如reg注册30个账户给buy业务使用，reg组要先于buy组执行，使用组方式。
（3）设置VU的行为：
将三个组都选中（出现黑框），一起设置：
1）初始化：默认运行之前初始化
2）加载方式Start Vusers：设置小递增，每隔1s加载1个VU
双击 -> 单选第2项： 1 00:00:01(HH:MM:SS)
-> OK 效果图：锯齿状
3）持续时间Duration: 指定20分钟（项目中一般1h左右）
-> 单选第2项 Run for 0 days and 00:20:00(HH:MM:SS)
说明：所有VU在20分钟内，循环执行各自Action脚本，时间将至，自动结束退出。
第1项：运行直到结束，适合明确迭代次数时使用；
比如固定注册30个账户
第2项：适合明确持续时间时使用；
第3项：一直运行，直到手工停止。
4）退出方式：可以采用递减退出，避免突然的压力对测试结果产生影响，比如设置为每隔1s减少1个VU.

及时保存场景文件：
D:\work\scenario\day05\10VU综合场景 *.lrs

（4）设置Run-time Settings
选中三个脚本组 -> Run-time Settings -> 弹出窗口：
选中多运行模式 RTS:
Sharded RTS 共享 / Individual RTS 独立
所有组统一设置一遍 每个组依次设置一遍
1）迭代次数：1 此处不起作用，由Duration决定 20分钟
2）Pacing: 改为第2项，随机4.000~6.000s
3）Log: 启用 Enable logging （选择）
Log options: 日志选项
Send message only when an error eccurs （选择）
出错时才发消息
Always send message 总是发消息，会写日志文件
Log message at the detail level of: 日志消息级别
Standard Log 标准日志（选择）
Extended Log 扩展日志
4）Think time: 启用，使用随机百分比50%~150%
Use random percentage of recorded think time.
Min: 50% Max: 150%
5）Additional attributes: 附加选项/特殊参数值 不设置
6）Miscellaneous: 杂项/其它
<1> Error Handling 错误处理
-> Continue on error 打钩 错误时继续
原因：长时间测试过程中会执行大量的事务，不用因为个别错误而停止场景的运行。出现大量的错误，需要手工停止并及时纠正。-- 瑕不掩瑜
错误率：0.3%以内 1000个事务，错误3个以内可以接受
<2> Multithreading: 多线程 Thread线程 模拟 VU
Run Vuser as a process 以进程方式模拟 相对稳定
Run Vuser as a thread 以线程方式模拟（选择）省资源
<3> 自动定义事务：都不选择
原因：事务由自己定义，如果自动事务过多（每个Action、每个步骤），会导致结果数据多而杂，影响判断。
7）Network网络：Speed Simulation 网速模拟
选择：Use maximum bandwidth 使用最大的带宽
原因：准备充足的带宽，将最大的压力尽快呈现给服务器
8）Browser Emulation: 浏览器模拟
Simulate browser cache 模拟浏览器的缓存 Cache
缓存的原理：拿空间换时间！-- 提高系统性能的重要思想
使用更多的内存空间 赢得 更快的访问时间
结论：目前测试不使用缓存，为了让每次访问都公平对待
如果使用缓存，让客户端更省力，降低后台压力
后续都选中：每次都当做新用户看待 -- 公平
下载非HTML资源、每次迭代模拟新用户、每次迭代清缓存
9）Internet Protocol: 互联网协议
Proxy: 选中No Proxy 不要代理
Preferences: 后续疲劳强度测试也够用
-> Options 选项 -> 将三个120都改为600 (秒)
都是超时时间，保证充分的时间，促进成功率。
连接
包括：Http-request connect timeout(sec) -> 600
接收
Http-request reveive timeout(sec) -> 600
Step download time(sec) -> 600
-> OK 同样是在其它组

（5）配置Windows resources 系统资源监控
（后续查看平均结果作为参考）
配置好Run-time settings后，继续配置Windows resources
（Run视图 右下角窗口）
右击窗口-> Add Measurements... ->
Monitered Server Machines: 选机器 点击Add.按钮 ->
Machine Information:
Name: localhost 指定监控服务器的IP地址，主机名
目前就是本地主机
Platform: WINXP 系统平台
-> OK
Resource Measurements on: localhost 清空里面所有选项
自己完成选项的添加（固定13项+1）
-> 点击Add按钮 -> 选择以下内容：
<1>Processor中有2项：（处理器 CPU）
%Processor Time -> Total -> Add Total表示总和
%User Time -> Total -> Add
<2>Memory中有4+1项：（内存）
Available MBytes -> Add
%Committed Bytes in Use -> Add
Page Faults/sec -> Add
Pages/sec -> Add
Page Reads/sec -> Add 页面读取率
<3>Network Interface中有2项： （网络）
Bytes Total/sec
-> MS TCP Loopback inter...回环-> Add
本地主机才选回环
Packets/sec
-> MS TCP Loopback inter...回环-> Add
本地主机自己和自己通信，用回环
<4>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
磁盘读写率
Disk I/O 磁盘输入/输出 Input/Output
读 写
<5>System中有1项： （系统）
Processor Queue Length -> Add
-> OK
以上一共14项，先了解名字，后续再强化。
-> 运行场景 Start Scenario

（6）注意：
1）当场景中Duration到达指定时间时，LR会向所有VU发出退出系统指令，所有VU运行完当前Action之后，退出系统；
如果无法正常退出，和信号丢失有关，建议手工停止。
2）运行出错，进行分类，依次解决：
<1> 哪些错误不用关心？
少量的非事务错误，可以忽略；
负值分母计数器，和系统资源监控有关，可忽略；
少量事务错误（0.3以内），也可忽略。
<2> 哪些需要关心？
大量的错误，比如服务器崩溃了，大量无法连接；
大量事务错误，和脚本有关，比如逻辑结构、代码语法、参数化数据等； reg脚本重复使用数据注册会报错
事务有开始，没有结束也会在场景中报错
场景设置出现偏差，会导致一定错误。
<3> 如何解决？
提前结束场景，根据错误信息，点击Details 详细描述，查看错误的位置、原因、解决方法建议；

vuser_end.c(9): Continuing after Error -26366: "Text=Flight Selections" not found for web_reg_find
和页面标题的检查点有关，找不到

针对此次结果打开Analysis:
将结果文件保存：
C:\work\result\day05\10VU综合场景测试_r1
*.lra 结果分析文件 analysis
初步结论：目前没有发现性能瓶颈，测试通过。

重要的测试策略：并发测试、在线综合场景测试

练习：20VU在线综合场景
5VU购票 10VU查询航班 5VU查看订票结果
持续执行10分钟。提示：脚本可以复用

 

复习：
1、如何进行一次综合场景测试？（重要的性能测试策略）
1）含义：更真实模拟实际生产环境；
2）三要素：多用户、多任务（脚本）、在线执行一段时间（1h左右）-- 根据需求设计
3）VuGen录制和调试脚本：
<1> 选择合适的协议：Web[HTTP/HTML]等
<2> 设置录制方式：HTML/URL、自动页面标题检查点、字符集: UTF-8、URL地址、起始脚本位置...
<3> 根据指定业务流程完成脚本录制
<4> 脚本增强：事务、检查点、参数化、关联、流程控制、函数调用...
<5> 将事务内lr_think_time转移到事务开始之前；
<6> 确保脚本回放通过。
4）Controller设置综合场景：
<1> 场景模式：手工场景、Scenario方式共享场景设置、VU分配目前不用百分比；
<2> 脚本组：组名、脚本路径、VU数量、Load Generators
<3> VU行为：初始化、加载方式、持续时间、退出方式
<4> Run-time Settings: 迭代次数、Pacing迭代间隔、Log、Think time 步骤间隔、杂项（错误处理-错误时继续、VU模拟-线程方式、无需自动事务）、网络-最大带宽、浏览器模拟（日常测试-不用缓存，更公平；数据测试-为了促进成功，可以使用缓存Cache）、目前不用代理、超时时间-600s
<5> 系统资源监控：CPU、Memory、Disk、Network、System等十多项指标。
比如：%Processor Time CPU使用率 阈值：70%~80%
5）运行场景，出现问题及时调试
6）Analysis获取性能测试报告，便于分析。

一、脚本录制技术细节
1、选择合适的协议：
1）B/S架构：常用Web[HTTP/HTML]协议，如果项目中使用了其它技术，比如Ajax、JDBC、FTP等，就需要选择多协议；
2）C/S架构：常用Windows Sockets协议（万能协议）
Socket: 套接字 好比两端进行网络通信的电话机，需要建立连接再通信。
趋势：企业级应用常用B/S； PC端Web测试
移动互联网 App一般C/S； 移动端App测试
2、测试脚本的基本组成：4个部分
1）vuser_init 初始化：仅执行1次 登录等准备工作
2）Action 核心脚本：默认1次，可n次 可进行并发
3）vuser_end 结束脚本：仅执行1次 退出等后续操作
4）globals.h 头文件：包含LR函数的声明
建议：LR脚本中的Action越少越好，易维护、可复用；
QTP中的Action较多，因为功能多。
了解：LR可以录制多Action脚本，但不推荐使用。
3、脚本主窗体部分是代码：主要记录客户端的请求、控制函数（事务、集合点、检查点、流程控制）
面试题：LR录制脚本时使用了什么协议？举出该协议下使用的函数。 Web[HTTP/HTML]协议
1）常见请求函数：（对应每个步骤）
web_url: 向服务器发送一个URL请求，访问网页、图片、CSS等、JS等资源；
web_submit_form/web_submit_data: 提交表单数据，携带表单请求的参数数据；
web_link: 超级链接请求
2）其它控制函数：
lr_start_transaction("事务名"); 开始事务
lr_end_transaction("事务名", LR_AUTO); 结束事务
lr_think_time(秒数); 步骤等待时间
web_reg_find("Text=页面源代码文本", LAST);
reg字样，注册性函数，在相应请求之前
lr_rendezvous("集合点名"); Action中，事务开始之前

4、Http协议请求的分类：get和post ...
（Request Method 方法、方式 有多种）
1）get请求
<1> 地址栏写URL回车
<2> 点击超级链接 <a href="URL">文本或图片</a>
<3> 页面中获取图片、css、js脚本等资源
<4> 表单指定get方式提交 <form method="get"> 很少用
<5> Ajax发送异步请求，指定get方式
2）post请求
<1> 表单指定post方式提交 <form method="post"> 常用
<2> Ajax发送异步请求，指定post方式

p1.html?username=Tom&password=123
URL?参数名=参数值&参数名=参数值&... 名值对
查询字符串 Query String
可以通过请求URL携带参数和数据，提交给服务器

面试题：get和post请求有何区别？
1）get请求：
<1> 请求参数在URL地址栏后携带，信息不安全
<2> 提交的数据量有限，一般不超过2KB
2）post请求：
<1> 请求参数在请求包的主体中携带，信息相对安全
使用抓包工具Wireshark、Fiddler等能够捕捉到
建议：出于安全性考虑，密码在发送之前要加密
<2> 能够提交较大数据量，适合进行表单提交、文件上传

5、常用日志窗口
1）Replay Log: 记录脚本回放（执行）日志 （常用）
调试脚本时，观察脚本运行的轨迹、主要流程，根据错误日志定位、分析错误原因。
技巧1：调试时可以启用扩展日志，查看参数的替代信息
Run-time Settings -> Log Extended Log
技巧2：性价比非常高的调试语句--打印语句
Java: System.out.println("xxx" + 变量名);
如果未打印，说明代码未执行，可能之前出错退出；
如果打印的结果和预期不同，说明有问题。
LR: lr_output_message("Hello");

Action.c (4): illegal statement termination 非法语句结束
Action.c (4): skipping `int' 跳过 int
Action.c (4): undeclared identifier `a' 未定义标识符a
结论：当前LR的类C环境要求
C变量的定义必须在代码的最前面！为了便于统一管理

2）Recording Log: （目前用的不多）
记录LR客户端和服务器二者对话的数据包大小；
（交互的信息量）
用途：和工具统计吞吐量等有关。

3）Correlation Results 自动关联结果（基本不用）
关联 后续一般采用手动关联

4）Generation Log: 生成日志 （常用）
记录LR客户端和服务器二者之间的全部对话（请求包、应答包），录制时产生的完整日志。
用途：脚本是按照这些日志生成的；
在脚本关联技术中需要分析该日志，查看到协议的底层。

面试题：以下哪些是前端技术？哪些是后端技术？
Web服务器端技术（后端）：Server端
Java、数据库 SQL、JDBC、JSP、Servlet...
Web前端技术（客户端）：Client端
HTML、CSS 层叠样式表、JavaScript （JS）

二、理解HTTP协议的底层，使用Tree视图方式添加检查点
1、HTTP协议
1）含义：超文本传输协议，互联网最重要的协议
http://www.tedu.cn 域名
2）特点：简单的、无状态的协议
简单的：协议的结构内容较为简单；
无状态：一次请求，一次响应后，服务器默认不会记录用户之前状态的。
3）请求和响应的格式：
<1> 共同点：都分为头header 和 主体body
<2> 请求的头中，会携带客户端浏览器的信息；
比如说明是post方式请求
请求的主体中，会携带客户端请求参数信息，比如：
username=Tom&password=123
<3> 响应的头中，会携带服务器端给客户端的通知，比如：
包括响应状态码 200 或 302 或 404 或 500 ...
是否写Cookie...
响应的主体中，是向客户端返回的页面元素：
包括网页源代码、图片、css、js脚本...
4）如何解析、查看协议的数据包？
<1> 使用第三方工具：WireShark、Fiddler等抓包工具
抓包：捕捉网络通信的数据包（请求包、应答包）
<2> LR中的Tree视图：树视图 查看数据包的结构
打开day05\buy 另存为 day06\buy
练习：寻找订票成功的请求和响应数据包的对应关系
HTML View 网页视图 -- 直观，便于观察，找对应关系
HTTP View 底层协议视图 -- 底层，便于分析

5）练习：针对登录成功添加文本检查点，建议使用函数web_reg_find 效率高
之前做法：录制时添加 点击Insert text check
局限性：可能录制时不知在何处添加、添加后没有加上、添加的位置出现偏差。
录制后追加：
<1> 找到相应请求--其响应结果需要检查的请求
检查点函数带有reg字样，注册性函数放在相应请求之前
技巧：Tree视图，HTML View 确认请求和响应快照的关系
<2> 切换到Tree视图，使用HTML View
-> 选中需要检查的文本 -> 右击
-> Add a text check(web_reg_find)
-> 窗口：
文本：Welcome, <b>jojo</b>, to 页面源代码文本
区分大小写
查找范围：All 或 Body 协议的主体部分
-> OK 生成函数：
web_reg_find("Search=Body",
"Text=Welcome, <b>jojo</b>, to",
LAST);

练习：针对订票成功添加文本检查点，使用Tree视图
步骤：1）先找到相应请求
2）使用Tree视图添加
web_reg_find("Search=All",
"Text=leaves Denver for London.<br>",
LAST);

三、实验：设置10VU，分别采用进程 或 线程两种方式模拟VU，观察对测试机性能的影响。
基本思路：
1）控制台中，设置Run-time Settings
杂项 -> 选择 进程 或 线程 方式
2）打开任务管理器：查看mmdrv进程 （产生VU）
查看mmdrv进程的数量、占据系统内存的大小
规律：一般线程在50个以内，都使用1个mmdrv进程
1）线程方式：只有1个mmdrv进程，占10M内存
对测试机资源占用少（轻量级）
2）进程方式：有10个mmdrv进程，平均每个占7M内存
对测试机资源占用多（重量级）
结论：使用线程方式模拟VU更有优势，省测试机资源。
对比：JMeter 默认使用线程方式模拟VU.

四、多机联合测试（联机测试/分布式测试）
1、一台测试机（PC）只能提供有限的负载（平均2000个VU），提供负载的强弱和PC机的配置有关。
大幅度提高负载的方法：（面试题）
1）提高硬件配置；
2）联机测试：使用若干台PC联合产生更大的负载。

2、需求：要求使用联机的方式，订2张票，使用自己PC1和同事的PC2，各自分配1个VU，由PC1作为主控制台，统一向被测系统PC1中订票（WebTours）。
操作：day05\buy 打开 另存为 day06\buy1

3、查阅本机IP地址，前提：打开本地连接
右击 网上邻居 -> 属性 -> 启用本地连接
打开cmd: ipconfig
PC1: 172.166.100.212 控制台IP、SUT的IP
PC2: 172.166.4.206 负载机IP

4、将脚本中所有的localhost或127.0.0.1都替换成PC1的IP
原理：希望向哪里订票，就写哪台机票的IP，目前就是PC1作为被测系统。

5、检查网络是否可达：
打开cmd: ping 对方IP地址
ping 172.166.4.206
原理：不断向对方发送一些数据包，查看是否正常反馈
如果显示连接具体时间，表示正常；
如果显示连接超时 time out，说明网络不可达。

6、要求负载机PC2至少需要安装Load Generator，并且需要启动Agent进程（小雷达）-- 默认就绪

7、打开控制台，设置两个脚本组，都使用buy1脚本：
前提：buy1脚本编译后 -> 回放成功 再加载 最新版本
两个组：
组名 脚本路径 VU数据 Load Generators
buy1.2 day06\buy1 1 localhost
buy1.2_1 day06\buy1 1 改为负载机PC2的IP

8、使用控制台中Load Generators窗口进行检查：
控制台 -> Scenario菜单 -> Load Generators
逐个测试：点击Connect按钮 连接
结果为Ready 表示成功
为Failed 表示失败

9、准备运行：
建议清空jojo订票记录，便于观察。
默认脚本迭代1次，2个VU各自都向PC1系统中订1张票。
运行场景 -> PC1中订票2张，成功！

 

复习：
1、什么是性能测试？
比喻成：攻坚战
测试机 攻打 被测系统SUT
LR
严阵以待，想方设法，放马过去，方知厉害
1）搭建性能测试环境 -- 更真实模拟 一定比例压缩
<1> 测试机环境 模拟大量客户端
<2> 被测系统环境 模拟后台服务器
Web Server --网络-- DB Server
Web服务器 数据库服务器
2）根据需求制定性能测试计划
测试范围、测试策略（基准、并发、在线综合场景...）、
测试用例（一般一个场景为一个用例）、进度安排、提交物、
结果评定标准、风险评估...
3）使用性能测试工具执行计划，对SUT施加不同的压力
结合LR的三大组件进行协作
4）观察测试结果是否满足性能需求
关注重要的性能测试指标：
<1> 平均事务响应时间 Average Transaction Response Time
一般358原则 不超过2~3秒都不错
<2> TPS 每秒事务数 Transaction Per Second
一般几十够用，大型系统要求更高
天猫双11：峰值TPS
2016 2017 2018
12万笔交易/秒 25万 49.7万
<3> 最大并发用户数 通过严格并发测试
一般测试到50、100、150、200...500 ... 1000 2000
对比：
注册用户数 在线用户数 并发用户数
10000 条记录 2000 最多测试200并发
账户信息 在线用户数的1/10
<4> 点击率和吞吐量的关系
Hits per Second Throughput
每秒请求数 服务器处理字节数
正常是“水涨船高”的关系
<5> 常见系统资源指标 CPU、Memory、Disk、Network...
CPU: %Processor Time： CPU使用率
阈值：70%~80%
Memory: Avaliable MBytes: 可用物理内存
阈值：不少于10%~20%
Disk: 磁盘读写率 Disk I/O 磁盘输入/输出 比率
Disk Read Bytes/sec
Disk Write Bytes/sec
阈值：一般不超过 几MB/秒
系统优化思路：尽量减少Disk I/O

性能测试的难点：环境搭建、测试计划、性能分析
较为容易：使用LoadRunner、JMeter执行测试计划

 

复习：
1、脚本的组成：主要是请求函数（根据协议生成），使用Web[HTTP/HTML]，常见的分析，看懂脚本。
2、HTTP协议的组成：数据包（请求包、应答包）
都有头header和 主体body的结构，抓包工具进行分析；
3、Tree视图：录制快照、回放快照；HTML视图-直观、HTTP视图-底层协议文本；
应用：使用Tree视图添加文本检查点 web_reg_find
1) 找到相应请求 Tree视图查找
2) 针对Tree视图指定位置添加
4、常用日志：
1）Replay Log: 回放日志，每次回放后的日志，便于脚本调试；
2）Generation Log: 生成日志，记录录制时请求和应答的所有数据包，便于后续对脚本进行深入分析，比如关联技术。
5、联机测试：让多台测试机共同产生更大的负载（VU）
1）网络物理连接； 2）主控制台；
3）负载机安装Load Generator、启动Agent进程；
4）检查LG的连接
5）选择合适的脚本、分配合理的VU数
6、脚本增强技术：
1）事务：平均事务响应时间、TPS、并发的起点
2）检查点：自动检查响应结果是否正确
3）集合点：并发测试时才使用 lr_rendezvous("集合点名");
4）参数化：以不变应万变，解决业务数据多变的问题
关键：参数池 类型 + 数据 + 策略
5）关联
6）流程控制：分支、循环
平时一般不随意改变原有业务流程，为了更真实
7）函数调用：C函数/LR函数 --代码复用，复用已有的功能

一、参数化策略
1、Select next row（How? 如何取？）取值方式
选择下一行
1）Sequential：顺序的
每个VU都从第一行开始，顺序依次向下取值；
数据取完可以从头循环重复使用；
--每个VU取值序列相同
2）Unique：唯一的
从第一行，对于VU唯一依次向下取值；
如果数据不足，需要按照指定策略进行取舍；
--每个VU取值序列不相同
举例：目前有10行数据：a1 a2 a3 ... a10，2个VU，每次迭代时更新数据，一共迭代2次。
按照SE组合：顺序+每次迭代 VU1(a1, a2) VU2(a1, a2)
按照UE组合：唯一+每次迭代 VU1(a1, a2) VU2(a3, a4)
3）Random: 随机取
每个VU都随机获取参数池中数据，值可以重复；
4）Same line as xxx: 和xxx参数同行取值、策略一致
比如：password 设置为 Same line as username

2、Update value on （When? 何时取？）更新时机
何时更新能够决定每个VU需要取几次数据
1）Each Iteration: 每次迭代 （默认，最常用）
脚本Action每迭代一次，需要重新取参数的值；
2）Each Occurrence: 每次遇到 （不常用，不好控制）
脚本中参数出现一次，则算遇到一次
3）Once: 仅取一次
每个VU仅取值一次，不再改变（从一而终）

3、When out of values: 当超过值的策略
前提：使用Unique策略时才有效，考虑值不够用时的策略。
1）Abort Vuser: 放弃VU VU不再执行脚本，并且报错
（最常用）
2）以循环方式继续：循环从第一行开始继续取（重复）
3）以最后一个值继续：重复取最后一个值（重复）

二、练习（笔试题）
某参数现有备用数据a1 a2 a3 ... a30，使用VuGen完成（只有1VU），脚本迭代3次，默认迭代一次参数只出现一次，完成以下策略组合的结果：
1）顺序 + 每次迭代：a1 a2 a3
2）唯一 + 每次迭代：a1 a2 a3
3）随机 + 每次迭代：a18 a5 a26
4）顺序 + 每次遇到：a1 a2 a3
5）唯一 + 每次遇到：a1 a2 a3
6）随机 + 每次遇到：a6 a30 a8
7）顺序 + 一次：a1 a1 a1
8）唯一 + 一次：a1 a1 a1
9）随机 + 一次：a5 a5 a5

新建脚本param1，设置一些参数{name}和{pwd}，给定数据，指定不同策略进行检验：

Action.c(6): 用户名：{name}，密码：{pwd}
原样输出表示参数不认识

将param1备份为param2，外部循环Action迭代改为2次；
Action代码中增加内循环3次。 for语法
（好比迭代一次参数遇到3次）
for循环语法（Java/C/C++）:
之前语句0;
for(初始化语句1; 循环条件2; 步进语法3){
循环体4;
}
之后语句5;
执行顺序：0 1 4 3 2 4 3 2 4 3 2 5 循环3次

比如：3次循环
for(int i=0; i<3; i++){
...
}
for(int i=1; i<=3; i++){
...
}

三、练习（笔试题）
某参数现有备用数据a1 a2 a3 ... a30，使用VuGen完成（只有1VU），脚本迭代2次，迭代一次参数出现3次，完成以下策略组合的结果：
1）顺序 + 每次迭代：a1 a1 a1, a2 a2 a2
2）唯一 + 每次迭代：a1 a1 a1, a2 a2 a2
3）随机 + 每次迭代：a9 a9 a9, a16 a16 16
4）顺序 + 每次遇到：a1 a2 a3, a4 a5 a6
5）唯一 + 每次遇到：a1 a2 a3, a4 a5 a6
多用户时考虑块大小，VuGen只有1VU，块大小不起作用，象征性写1即可。
改为：外循环5次，内循环10次
使用Unique，就要考虑When out of values:
a) Abort Vuser: 放弃VU 越界会报错Action.c(5): Error
b) 循环继续取: 正常循环取值，不会报错 数据可能重复
c) 持续最后一个: 持续取值，会报错Action.c(5): Error

6）随机 + 每次遇到：a15 a1 a6, a9 a1 a19
7）顺序 + 一次：a1 a1 a1, a1 a1 a1
8）唯一 + 一次：a1 a1 a1, a1 a1 a1
9）随机 + 一次：a3 a3 a3, a3 a3 a3

Action.c(5): Error: Parameter 'name':
No more unique values for this parameter in table
没有 更多 唯一 值 针对 参数 name.dat
'name.dat' [unique range is 1-30].
VU 被放弃 根据 xxx 策略
The Vuser is aborted according to "When Out Of Values" policy.

四、多用户分块的概念 块 Block
1、使用控制台管理多用户时，使用Unique策略时，首先考虑分块的问题，分块时保证用户数据不重复的关键。
分块后，每个VU选择自己块内数据，能够保证VU之间不会重复使用数据。 分块--数据的隔离
2、测试过程中，如果参数池数据不够，场景运行会报错。
建议：使用Unique策略时，保证数据充足，允许必要的浪费。
3、块大小：分配给每个VU的数据量；
4、分块的方式：
1）自动分块：块大小根据VU的需要自动分配--按需分配
2）手动分块：块大小可以自己设置
<1> 刚好够用
<2> 有所富余--推荐使用
<3> 有所不足--参考When out of values策略
每个VU在自己的块内数据进行取舍：
a. 放弃VU;（推荐） b.循环方式继续; c.持续最后一值

五、在控制台中查看运行日志（多用户，产生多个日志文件）
1、打开控制台：加载param1脚本
指定日志输出的位置：
Controller -> Results菜单 -> Results Settings 结果设置
-> 窗口：
Result Name: res 存放日志的目录名，可以修改
Directory: C:\... 默认长路径，建议改短，自己指定
-> D:\ 新建目录 lrlog
-> 点击Browse -> 指定目录：D:\lrlog
另外，还有两个选项：
每次执行场景，产生新的日志文件；
每次执行的结果会覆盖之前的日志文件；（选择）
2、为了能够生成日志文件，需要设置Run-time Settings:
-> Log -> Always send message 总是发消息
3、其它设置：
VU数量：10
VU行为：默认初始化、同时启动、运行直到结束
运行场景，观察D:\lrlog目录
每个VU都会产生一个日志文件：
param1_1.log .... param1_10.log
组名_VU的id.log

重要提示：VuGen修改完数据和策略 -> 编译脚本
-> 控制台中及时刷新脚本 -> 才可生效

Insufficient records for parameter 'name' in table to provide the Vuser with unique data
强调：Unique策略时，数据分配必须要充足，避免报错。

五、综合练习题（笔试题）
某参数现有备用数据a1 a2 a3 ... a30，使用Controller设置3个VU运行脚本，脚本迭代4次，默认迭代一次参数只出现一次，完成以下策略组合的结果：
1）顺序 + 每次迭代：<重要>
VU1：a1 a2 a3 a4
VU2：a1 a2 a3 a4
VU3：a1 a2 a3 a4
2）唯一 + 每次迭代：<重要> 默认自动分块 块大小: 4
VU1：a1 a2 a3 a4
VU2：a5 a6 a7 a8
VU3：a9 a10 a11 a12
自动分块 块大小: 4
第一块：a1 a2 a3 a4 VU1
第二块：a5 a6 a7 a8 VU2
第三块：a9 a10 a11 a12 VU3
3）随机 + 每次迭代：<重要>
VU1：a10 a1 a6 a15
VU2：a3 a6 a12 a21
VU3：a5 a9 a1 a8
4）顺序 + 每次遇到：
VU1：a1 a2 a3 a4
VU2：a1 a2 a3 a4
VU3：a1 a2 a3 a4
如果迭代一次遇到2次：
VU1：a1 a2 a3 a4 a5 a6 a7 a8
VU2：a1 a2 a3 a4 a5 a6 a7 a8
VU3：a1 a2 a3 a4 a5 a6 a7 a8
5）唯一 + 每次遇到：<重要> 手动分块 块大小：6
VU1：a1 a2 a3 a4
VU2：a7 a8 a9 a10
VU3：a13 a14 a15 a16
手动分块 块大小：6
第一块：a1 a2 a3 a4 a5 a6 VU1
第二块：a7 a8 a9 a10 a11 a12 VU2
第三块：a13 a14 a15 a16 a17 a18 VU3
6）随机 + 每次遇到：
VU1：a6 a3 a19 a2
VU2：a22 a1 a7 a19
VU3：a5 a9 a23 a16
7）顺序 + 一次：<重要>
VU1：a1 a1 a1 a1
VU2：a1 a1 a1 a1
VU3：a1 a1 a1 a1
8）唯一 + 一次：<重要> 默认自动分块 块大小：1
VU1：a1 a1 a1 a1 满足VU之间值不重复
VU2：a2 a2 a2 a2
VU3：a3 a3 a3 a3
自动分块 块大小：1
第一块：a1 VU1
第二块：a2 VU2
第三块：a3 VU3
9）随机 + 一次：<重要>
VU1：a8 a8 a8 a8
VU2：a16 a16 a16 a16
VU3：a3 a3 a3 a3
10）唯一 + 每次迭代：<重要> 手动分块 块大小：5
VU1：a1 a2 a3 a4
VU2：a6 a7 a8 a9
VU3：a11 a12 a13 a14
手动分块 块大小：5
第一块：a1 a2 a3 a4 a5 VU1
第二块：a6 a7 a8 a9 a10 VU2
第三块：a11 a12 a13 a14 a15 VU3

查看多用户执行结果的方法2：VuGen就能模拟
打开VuGen 使用param1 -> Parameter List
-> Simulate Parameter... 模拟参数化（多用户时）
-> 窗口：
Vusers: Number of Vuser: 3
Scenario run mode: 场景运行模式
Run until completion: 运行直到结束(取决于迭代次数)
Number of iteration to run: 4 迭代4次
-> 点击Simulate 模拟

对比两种方法：
方法1：优点：通用，获取运行的日志文件
缺点：配置过程比较繁琐
方法2：优点：配置非常方便
缺点：每次遇到时无法模拟（用得不多）
无法记录日志文件

以上参数类型：File类型 使用自定义文件保存参数池数据

七、其它参数类型
1、Date/Time 日期/时间
用途：脚本中需要使用日期数据时，获取当前系统时间，使用不同日期格式表示。
to_char date -> char 提取关心的日期信息
to_date char -> date 生成date数据 入库
计算机中保存日期数据的本质：长整数-毫秒数
从1970年1月1日0点 到 某一时刻的毫秒数
128639837868
128639837869
计算机有算法（历法）将该值推算出所有的日期信息：
世纪、年、月、日、时、分、秒、毫秒

将param1另存为 param3
需求：获取以下格式的当前系统时间数据
举例 格式字符串
04/21/2017 %m/%d/%Y
20170421 %Y%m%d
2017-04-21 16:26:18 %Y-%m-%d %H:%M:%S

说明：Date/Time类型适合获取不同格式的当前系统时间；
File类型可以自己填写某个具体时间。

2、Iteration Number：迭代编号
用途：获取一组有序的递增的值
格式：%d
%01d
...
%05d 具有5位数值，不够的使用0补齐
00001 00002 ... 00100 01000 ...
3、Random Number：随机编号
用途：工具根据指定的规则、范围自动生成一组随机数
设置：Min: 1 Max: 100 %06lu
表示6位 1~100随机数 不够0填补
比如 000001 000100

UEA: 唯一+每次迭代+放弃VU
版本1：File类型，数据由自己指定
版本2：Unique Number类型，数据由工具规则产生

4、Unique Number: 唯一编号 （UEA版本2） 重点
用途：根据指定的规则自动为不同VU生成一组唯一的编号
原理：分块、块大小
具体配置：
<1> Start: 1 数据起始值 下一次：1001 2001 ...
<2> Block size per VU: 100 块大小
10VU，使用UEA版本2，脚本迭代80次
VU1: 1~100 VU2: 101~200 .. VU10: 901~1000
<3> Sample: Hello00001 数值举例
<4> Number: Hello%05d 数据格式
<5> Update value: Each iteration 更新时机 每次迭代
<6> When out of values: Abort Vuser 放弃VU

技术（技术专家） + 业务（领域专家）：
手机号：138-1181-0086
运营商 地区 不同用户

项目案例：针对某电信项目中账户注册功能进行性能测试，其中需要对脚本中的手机号进行参数化，要求手机号不能重复使用。需要1000VU在线执行注册功能，持续运行1小时，已知1个小时内平均每个VU执行437次注册，请提供参数化具体策略。手机号使用138开头。

将param3备份为testMobile
用户id: {uid} 手机号:{number}
uid的策略：Vuser ID VU的id 格式：%05s
number的策略：UEA版本2 Unique Number
具体配置：
<1> Start: 1 数据起始值 下一次：500001 1000001..
<2> Block size per VU: 500 块大小
既要让数据充足，又要便于后续的计算
VU1: 1~500 VU2: 501~1000 ....
1000个VU分配了：1000 * 500 = 500000
<3> Sample: 13800000001 数值举例
<4> Number: 138%08d 数据格式
<5> Update value: Each iteration 更新时机 每次迭代
<6> When out of values: Abort Vuser 放弃VU

将脚本载入控制台，设置场景：
1）Run-time Settings:
<1> 迭代次数：430 （不超过500）
<2> Pacing: 没有要求
<3> Log: 选择Always send message 能生成日志文件
<4> VU模拟：使用线程方式
2）Results Settings: 指定日志输出目录 D:\lrlog\res1
3）设置1000VU
4）VU行为：默认初始化、同时加载、运行直到结束
-> 运行场景

归纳最常用的策略组合： 着重说明其项目中应用场合
1）SE组合： 顺序+每次迭代 最常用
2）UEA组合：唯一+每次迭代+放弃VU 数据唯一时使用
版本1：File类型
版本2：Unique Number类型
3）RE组合：随机 + 每次迭代 用户访问具有随机性

 

复习：
1、参数化策略
1）核心思路：以不变应万变 变量名-值
2）关键：类型 + 数据 + 策略
3）类型：
* File-数据由测试工程师准备 *.dat 大量的业务数据
* Date/Time-数据由系统时间获取，指定不同格式
* Random Number-指定范围，获取随机数据
Iteration Number-迭代编号
Vuser Id-虚拟ID
* Unique Number-唯一编号
4）File类型考虑具体策略
<1> Select next row （How?如何取？）取值方式
a. 顺序的 Sequential b. 唯一的 Unique
c. 随机的 Random d.和xxx一致 Same line as xxx
<2> Update value on （When? 何时取？）更新时机
a. 每次迭代 Each Iteration
b. 每次遇到 Each Occurrence c. 仅取一次 Once
<3> When out of values （选择Unique时启用）越界处理
a. 放弃VU Abort Vuser b.循环使用 c.持续最后一值
<4> 多用户实现唯一取值的原理：分块+数据充足+自给自足
首先分块，将数据分为不同部分，分别交给不同VU使用，避免重复；每个VU分配的数据量就是块大小；自动分块（按需分配）、手动分块（刚好、富余*、不够）
5） 项目中常用的策略组合：
<1> SE组合：顺序+每次迭代 反复顺序取数据，可以重复
<2> UEA组合：唯一+每次迭代+放弃VU 比如注册时使用
版本1：File类型 数据自己准备
版本2：Unique Number类型 数据根据配置生成 无中生有
<3> RE组合：随机+每次迭代 比如随机订票等

一、脚本关联技术
引入：
打开WebTours首页，点击administration连接：
具有大量管理项，LR为了模拟一些特效设置的选项，实际项目中不存在。
-> 选择第三项：
Set LOGIN form's action tag to an error page.
-> 点击Update按钮 提交表单 生效
目的：模拟一种效果

录制脚本：day08\3login
基于HTML: Options -> HTML-base script
录制成功，回放失败！发现脚本：
"Name=userSession", "Value=120939.455164034zccAicDpccfDHDctpQDQDf"
User Session ID
用户 会话 id
凭经验：很可能脚本需要管理

HTTP协议：简单的、无状态的协议
简单：协议底层结构比较简单 头和主体
无状态：一次请求，一次响应后，服务器默认不会记录用户的状态。
但是有需求：需要记录用户的状态，比如登录在线、购物车

记录用户状态的技术： Client(浏览器) <---> Server
面试题：Session和Cookie有何区别？
1）Session技术：将用户状态保存在服务器端
定义：在服务器端保存用户状态的技术
好比：店里为每个顾客准备的会员册，为不同用户分配id
原理：用户在某一次向服务器发请求，服务器内存中为该用户创建一个Session，并为之分配一个Session id，通过响应返回给客户端；用户下一次发请求，需要携带该id，从而找到属于该用户的Session，从而记录用户的状态。

2）Cookie技术：将用户状态保存在客户端
定义：在客户端浏览器保存用户状态的技术
好比：店里为顾客发放的消费记录次卡，用户自己保存
原理：用户某一次向服务器发请求，服务器端程序可以在响应中通知客户端写Cookie（保存在客户端浏览器中的文件，形式：名称=值）；用户后续发请求，也会携带Cookie信息与服务器交互，服务器后续还可再改Cookie。

产生脚本问题的原因：
Client端 Server端
录制时正常的情况：脚本生成了
Client 请求1 ----------> 创建Session 分配uid: 123
响应1 <---------- 返回uid 123
请求2 携带uid:123 -----> 找到Session空间
响应2 <-----------------

回放时错误的情况：按照脚本回放
Client 请求1 ----------> 创建Session 分配uid: 456
响应1 <----------
请求2 携带uid: 123 ----> 找不到Session空间 出错！

脚本中出现了动态数据，导致业务的不一致。

1、产生问题的原因：录制时生成的脚本，记录了uid，是一个静态数据；而服务器端每次访问时会产生一个动态数据，脚本无法适应服务器端的变化，导致出错。
脚本如何调试：将静态数据 改为 动态数据

2、关联的概念：Correlation
将脚本中某些写死的数据（硬编码），转变为服务器所发送的、动态的、每次都可能不一样的数据。
--以不变应万变
变量名 动态数据

3、何时需要关联？
录制时成功了，但是回放失败了，排除其它原因，比如：脚本语法、逻辑关系、参数化数据、网络连接、服务器状态；
找到有力的证据：存在动态数据，就需要关联。

4、关联的一般操作步骤：
1）先找到脚本中的静态数据（需要关联、替换）
2）将动态数据存入脚本中的一个参数中（LR变量）
3）将静态数据使用该参数代替

动态数据：每次运行可能不同的数据
何时会出现不同？
1) 手工操作一变 2) 录制一遍 3) 回放一遍

操作：再录制和3login业务一样的脚本 3login1
VuGen自带文本比较器：WDiff工具
针对3login脚本的Action部分：
Tools -> Compare with Script 和3login1比较
现象：白底表示相同，黄底表示不同；
大面积的黄底，不用太关注，和脚本结构、位置有关
重点关注特别的字符串文本
找到："Name=userSession", "Value=xxx"
xxx 就是动态数据 -- 需要关联
和Session的原理有关

5、如何找到动态数据 （进行关联的前提、关键！）
1）原理：每次录制、回放都可能变动的值；
2）录制两个业务流程一样的脚本，进行比对 WDiff工具
3）哪些是？有时是一串无规律的字符串； 比如Session id
有时是一串局部业务含义的字符串；
4）哪些不是？
坐标值、think time、检查点的函数和文本、更不是整段的请求。

6、关联的类型
1）手动关联（常用）
2）自动关联（不够稳定，较少使用）

7、手动关联的具体步骤：
1）录制成功，回放失败，怀疑和动态数据有关；
2）再录制一份脚本，进行比对，确定存在动态数据；(难点)
3）找到第一次产生该动态数据的响应对应的相应请求；
4）在相应请求之前写关联函数，将动态数据自动赋值给某变量（参数）； web_reg_save_param(...) 函数
5）将静态数据替换为该参数
--以不变应万变

8、如何找到相应请求？（目的：在之前写关联函数）
1）拷贝脚本中适当长度的静态数据（太长会换行，太短造成大量重复），从Generation Log的第一行开始查找！！！
120939.45516 ctrl + f
找到第一次出现该动态数据的响应 日志中有响应id号
根据该响应找到对应的请求 -- 相应请求
2）拷贝适当长度的左右边界字符串，备用
name=userSession value=120939.455164034zccAicDpccfDHDctpQDQDf>
3）先向下慢慢翻找，找到与当前响应id相同id的请求，就是相应请求；（90%情况都在下方不远处）
4）如果找不到，则回到原处，向上找到最靠近的一条请求
；（次数id号很可能不同）
5）响应：Response
请求：Request 或 Event 事件 找寻的关键词
在日志中找到请求：
web_url( "Snapshot=t1.inf" );
由于快照名时唯一的，作为线索
找到脚本中快照为t1.inf的请求 -- 相应请求

将拷贝的左右边界文本粘贴到相应请求之前，为了写关联函数。

6）在相应请求之前，写关联函数，并将脚本中的静态数据全部都替换成函数中的参数（指代动态数据的值）。
web_reg_save_param("uid", //参数名 LR变量名 uid
"LB=左边界字符串", // Left 左边界
"RB=右边界字符串", // Right 右边界
LAST);
相应请求...

原理：运行过程中，LR会根据左右边界，自动获取动态数据的值，将值赋给uid，后续脚本中可以使用{uid}表示动态数据。"Name=userSession", "Value={uid}", ENDITEM,
编译 -> 回放 成功！ 关联完成

9、所谓相应请求：就是第一次产生动态数据响应对应的请求。目前脚本是基于HTML方式录制，结构简单、篇幅较短，目前就两个请求，第一个就是相应请求；
以后的脚本可能基于URL方式，脚本篇幅较长，更需要按照以上流程仔细查找。

10、问题：相应请求是否可能包含有动态数据？
不可能。因为只有发出了相应请求，才第一次产生含有动态数据的响应，后续请求才可能携带。

练习：脚本中打印出uid的值。 LR变量
lr_output_message("Uid是:%s", lr_eval_string("{uid}"));

Action.c(21): Uid是:{uid} 表示{uid}无效 时机不对
只有在相应请求发送之后，uid才能有值！

Uid是:120940.931551235zccAiQQpVzzzzzzHDHDcfpDQf
Uid是:120940.934062373zccAiQQpcQfiDDDDDHDcfpDQfHHf

技巧：把握好实用数据的时机；
调试时，可以启用扩展日志，或采用打印技巧查看uid的状态。

归纳：如何找到相应请求？
1）常规方法：根据静态数据信息，到Generation Log中第一行开始查找响应包的位置，根据响应id找到对应的请求（先向下，再向上），根据请求的快照名，定位出脚本中的请求。
2）凭借经验、业务熟练程度，直接从脚本中根据动态数据进行定位。

二、关联的目的：让脚本能够适应动态数据的变化。
之前设置的管理第3项，是一种特效，实际项目中不存在；
实际项目中是否需要关联取决于服务器端软件设计、开发方式。比如服务器端的Session机制决定了更换用户uid就不同。
三、去除管理第3项，录制buy脚本，进行城市参数化
去除第3项 -> Update
思路：录制两个脚本，业务流程相同，城市不同，观察脚本的不同（WDiff）。因为一旦参数化，就会改变城市，如果中出现了动态数据，就需要关联。

先录制buya脚本 从Denver到London
在录制buyb脚本 从Denver到Paris

比如：从Denver到London
"Name=outboundFlight", "Value=020;338;04/25/2017"
020;338;04/25/2017 就是动态数据
020 航班号 338 价格 04/25/2017 日期
特点：该动态数据具有一定业务含义
这串信息，由服务器端程序根据实际业务操作组织生成的。
结论：城市参数化后，脚本就需要关联。

针对buya脚本，进行城市参数化：
针对起始城市：
Denver -> {fromcity} 使用参数代替
技巧：ctrl+f搜索 F3继续搜索 都替换
打开Parameter List: 设置数据 + 策略
编辑fromcity.dat
fromcity
Denver
Paris
|
First data: 2 从第2行Paris开始取
策略：默认SE组合
编译 -> 回放，如果出错，根据错误提示进行调试：
排除其它问题，怀疑需要关联，重新录制buyb脚本，根据比对buya和buyb，找到动态数据：（难点：判断）
web_submit_form(
"Value=020;338;04/25/2017",
);
需要关联：
1）找到相应请求； -- 越固定的步骤越简单
2）写关联函数；
3）替换静态数据。

目前录制方式：单协议、基于HTML方式
录制选项 Options: 二选一
HTML-base script 或 URL-base script

四、HTML和URL录制方式的区别：
1、HTML方式：平时常用方式
1）录制的脚本比较简约，好维护；
2）原理：录制时，每打开一个页面，LR默认将页面中的内容保存在自己的缓存中，如用户名（值为空）、密码（值为空）、用户Session Id（值为空）等；
当用户提交信息时，比如登录，会比对缓存中的数据，如果有区别，就会记录下生成脚本，一般都是数据有差异的部分，不变的部分在缓存中无需生成脚本。
2、URL方式：需要时使用，比如采用了HTTPS协议时
1）录制的脚本比较完整、篇幅长，较难维护；
2）原理：LR默认缓存为空，经过比对后，都不相同，都需要记录下生成脚本；
3）用途：互联网的趋势是采用https协议（https://）
安全的http协议（多次"握手"）
BAT 全网https 在线支付 网络银行 国外政府网站
优点:安全 缺点：维护成本高、影响速度
想办法改变架构，提高整体性能
此时需要使用URL方式录制，才能全面录制需要的脚本。

练习：使用单协议、基于URL方式录制buy脚本 url_buy
对城市进行参数化 fromcity tocity
调试思路：走一步，看一步 步步为营

归纳：关联
1、关联的定义：将脚本中的静态数据使用参数代替，适应服务器端动态数据的变化。
-- 特殊的参数化 数据是由服务器端产生的
之前的参数化：数据由自己准备或规则产生
2、动态数据 -- 进行关联的重要前提
3、相应请求 -- 为了写关联函数
4、关联函数
web_reg_save_param("参数名", "LB=", "RB=", LAST);
5、思想：以不变应万变！

 

 

 

 

项目阶段基本规律：
功能:性能 大约 2:1 3:1比例
功能考虑模块比较全面，性能测试的范围较小，某些模块不需要测试性能，因为访问的压力较小。性能测试是建立在功能测试基础上，功能已经实现，后期重点关注性能指标。
性能测试的难点计划制定（设计）、环境搭建（真实模拟）、结果分析（多层面瓶颈分析、涉及面广）。

触类旁通
软件工程：
需求分析 -> 系统分析与设计 -> 开发 -> 测试 -> 实施
功能 系统架构 B/S 开发技术规范
性能 数据库设计 协议
安全 面向对象设计
--需求文档 --设计文档

CMMI：全称是Capability Maturity Model Integration，即能力成熟度模型集成（也有称为：软件能力成熟度集成模型） 最高级5级 中等企业一般3级 获得项目竞标优势
软件越规范，级别越高，流程规则越健全，规范文档越多。

性能测试项目：网站稿件发布管理系统 MMS
Manuscript Management System
信息系统的共性：针对xxx信息的CURD操作（增删查改）
Create Update Read Delete
常用的系统：大部分属于企业级应用、互联网应用
OSS 运营支撑系统
BOSS 业务运营支撑系统
CRM 客户关系管理系统
ERP 企业资源规划
OA 办公自动化

一、如何进行性能测试？ （面试题）
1、分析需求 《需求规格说明书》
1）功能需求
业务逻辑、模块划分、测试范围
2）性能需求
重点关注测试范围、
性能指标：平均事务响应时间、TPS、最大并发用户数、系统资源情况（CPU、Memory、Disk、Network、System）
3）安全：目前了解

2、制定《性能测试计划》
选择合适的测试工具 LoadRunner11
1）测试范围、模块、功能点 -- 不是所有功能都要测性能
2）项目进度安排、人员分工安排
3）测试策略：基准测试、并发测试、综合场景测试、疲劳强度测试、递增测试、数据容量测试...
4）测试用例：一般一个场景设计为一个用例
5）提交物：各种文档、脚本、场景文件、结果报告、性能测试报告... -- 工作量的体现
企业中管理代码、提交物的工具：版本控制软件
比如CVS，能管理不同员工、不同时期提交的不同版本
6）应急预案：出现常见问题的解决方法

面试题：
3、搭建性能测试环境 （模拟） --具体问题具体分析
思路：需要多部门配合完成，包括系统架构师、SA系统管理员、DBA数据库管理员、项目经理、测试经理、开发工程师、实施工程师...
既能够降低测试难度，又能够真实模拟实际生产环境，还不会对真实使用环境产生影响。
1）测试机环境 （模拟客户端）C 浏览器、App、LR、JMeter
<1> 若干台PC机 硬件 -- 和启动的负载多少有关
<2> 操作系统：Windows/Linux...
<3> 测试工具：LoadRunner11、12 认证lisence
录制脚本用12多些，支持更多协议、编程语言
运行场景时用11多些，比较稳定...
<4> 网络环境：测试机互联 内网
2）被测系统环境 （模拟服务器）S
<1> 若干台服务器主机 硬件 分布式
应用服务器、数据库服务器等分开部署 便于监控
便于让负载更均衡，发现那台服务器更容易出现性能瓶颈。
<2> 操作系统：Linux/Unix
<3> 中间件产品：
a. 应用服务器软件： 企业级应用的容器 Web App容器
Tomcat、Weblogic、WebSphere等
b. 数据库管理系统DBMS: Mysql、Oracle、DB2

<4> 在Tomcat中，部署Web应用、相关配置
<5> 数据库中准备大量业务初始数据
<6> 网络环境

目前关注的主要方面： 以LR的四大组件为主要线索
4、执行测试计划 使用工具LoadRunner11
1）VuGen: 虚拟用户脚本生成器
<1> 根据相关协议、业务流程录制脚本-模拟自动化功能
如果有UI，通过浏览器或App界面进行录制生成脚本；
如果有UI，无法正常录制生成脚本，
或没有UI，只有后台接口，需要自己根据代码规范和协议写脚本。
<2> 设置Run-time Settings，模拟1VU回放
模拟运行轨迹、频率，发现脚本本身的问题
<3> 增强脚本：为性能测试提供帮助
事务：平均事务响应时间、TPS、并发的起点
lr_start_transaction("事务名");
请求、步骤的代码...
lr_end_transaction("事务名", LR_AUTO);
检查点：自动为响应内容进行检查 文本为主
性能测试要建立在功能实现的基础上，如果测试过程中
功能出现业务问题，一定会影响性能测试结果。
web_reg_find("Text=页面源代码文本", LAST);
reg函数 注册性函数 相应请求之前
技巧：Tree视图生成
集合点：形成严格的并发测试
lr_rendezvous("集合点名");
参数化：业务数据多变、更真实 类型+数据+策略
SE UEA RE等组合
关联：让脚本适应服务器端动态数据的变化
流程控制：分支、循环
函数调用：复用已有的功能
2）Controller: 压力调度控制台
设置场景Scenario: 表示测试计划
<1> 场景模式：手工/目标、是否百分比分配VU、Scenario/Group..
<2> 脚本组：组名、脚本路径、VU数量、Load Generator的选择（可以联机）；
<3> VU的行为：初始化、加载方式、持续时间、退出方式
<4> Run-time Settings: 迭代次数、Pacing迭代间隔、Think time步骤间隔、Log日志、附加项（错误处理-错误时是否继续、线程方式模拟VU）、浏览器模拟（是否启用缓存-降低压力可以启用，促进数据测试成功率）、网络带宽、超时时间 600s
<5> 日志管理：指定输出位置、设置输出详细级别
<6> 系统资源监控：CPU、Memory、Disk、Network、System等重要资源情况
3）Analysis: 压力结果分析器
根据各种结果图表进行性能分析，编写《性能测试报告》。
说明：后续任务是性能调优，一般由测试经理、架构师参与。

被测系统环境：
启动项：
start /b mysql5\bin\mysqld 启动Mysql5服务
--defaults-file="mysql5/my.ini" 默认配置文件
set JAVA_HOME=jdk1.6.0_07 设置JDK安装路径当前1.6
bin\startup.bat 启动bin目录中的Tomcat服务启动项

启动后控制台出现问题：
***重点看每段错误、异常的第一行：
严重: Error starting endpoint
绑定异常 80端口已经被占用了
java.net.BindException: Address already in use: JVM_Bind:80
解决方法：要么改为其它端口，要么关闭占用该端口的进程。如何查？ cmd: netstat -ano
Proto Local Address Foreign Address State PID 进程号
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 232

***后续几乎不用看，都是底层程序调用的栈轨迹
at org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:501)
at org.apache.tomcat.util.net.JIoEndpoint.start(JIoEndpoint.java:515)
at org.apache.coyote.http11.Http11Protocol.start(Http11Protocol.java:203
)

分析需求：
1、环境：内网测试-规避掉网络问题
2、功能需求：通过手工操作结合说明书分析
3、性能需求：
1）主要单点操作在5秒钟内完成；
平均事务响应时间 <5s
2）系统支持50人在线；
最大在线用户数50人 考虑50VU综合场景测试
3）稿件管理的主要功能至少支持20人并发访问；
最大并发用户数 20VU 结合递增策略 10 20 VU
4）上传512K大小文档，速度达到20篇/分钟；
TPS有关 每一次事务完成一篇
数据准备
5）系统可以连续稳定运行12小时。
稳定性 疲劳强度测试 大型系统要求7*24

搭建被测系统环境：
1、主机：当前PC模拟多层架构
应用服务器：Tomcat6软件
数据库服务器：Mysql5
架构：JavaEE Web项目 B/S架构
应用程序：Liferay
2、如何部署：目前简化，直接解压
Liferay中部署好了Tomcat6、JDK1.6、Mysql5、初始数据、部署了Web应用程序（webapps目录下）

附加问题：性能测试需要做好系统备份，便于恢复环境
重点是数据库的备份，比如如何备份Mysql数据
数据的导入导出
由于当前服务占用80端口，需要提前确认环境；
当前要启动Mysql服务，需要关闭原有的Mysql服务（默认使用3306端口）；
检查方法：cmd: netstat -ano 根据pid查找任务管理器
建议：关闭引起冲突的、不需要的服务
ApacheXxx、java、oracle、mysql、sqlserver、Tomcat、TNSLSNR、杀毒进程 ...
3、如何启动：运行 startall.bat
先启动mysql、设置java_home、启动tomcat
如果需要关闭服务：stopall.bat
提示：重起服务时一定要彻底关闭，比如mysql
4、如何访问：浏览器
http://localhost/web/guest/home
账号：
用户名：test01 ~ test50
密码：1111

关注的模块和测试点：
1、登录模块： 权限、角色
用户登录与退出：user_login
2、稿件管理模块：
查询稿件：search_manuscript
两种查询方式：
1) 不带条件的查询，查询到所有的稿件，分页显示
按照稿件最后一次修改时间降序排序
分页查询的好处：
a. 让用户只关注局部有用数据，获得更好的体验；
b. 如果一次查出所有记录，大大影响系统性能；
服务器内存、网络等消耗巨大
2) 带有条件：编号 标题 版本 内容
25345 微软 1.0 2月1日
模糊匹配 模糊匹配
...
启发：后期在录制脚本后，需要对业务数据进行参数化
模拟各种条件的查询，更真实，让数据查询范围
更均衡。
启发：系统中不同功能点之间有联系，比如增加稿件后
重新查询稿件显示的内容和之前不同。
--系统中的信息在不断变化，对测试是否有影响。

增加稿件：add_manuscript
提供稿件标题、内容，增加稿件，系统自动提供id
增加的最新稿件一般排在最前面，旧的稿件往后偏移
显示稿件：show_manuscript
1) 根据具体条件查询指定稿件，再显示
2) 没有条件直接查询最新稿件，再显示
更灵活，有一定的不确定性，注意交叉业务，关注不同功能点之间的相互影响。比如其它用户增加了稿件，当前用户查询到新的信息。
3、文档上传下载模块：
查询文档：search_document
根据文档名称（无需后缀），进行查询
分为两种情况：查到、查不到 都是正常的结果
上传文档：upload_document
建议新建一个文件夹，比如dir1，要求目录名用英文，避免录制后脚本中中文编码问题；
目前业务中新建的文件夹，会分配一个唯一id，删除后重建id会不同，对脚本有影响。
建议在D:\LR_Project\file目录下，新建等待上传的文档
好比是客户端需要的测试数据：要求文件大小几十KB
day01.txt day02.txt d1.doc d2.doc p1.jpg
业务要求：
原文件名可以重复使用；
重命名不能重复；
启发：必须要参数化，数据不能重复
参数化要想好策略？UEA组合
说明部分没有要求，目前 原文件名-新文件名

诚信 创新 开放 合作
成就客户 创新为耀

大规模的批量生产讲求规范，便于管理、维护；
技术创新要求别出心裁，可违反常规。
项目规范：命名规范、术语规范（业务角度）、结构规范
稿件 ManuScript 文档 Document 用户 User
用户名 username 密码 password 内容 content
标题 title ...
登录 login 查询 search 显示 show 增加 add
上传 upload

项目工作目录规范：
建议：形成规范的目录结构，包括命名、组成，便于项目管理，因为项目是分工完成，每位测试工程师完成一部分工作，汇总在一起统一运作。
项目管理中经常版本控制软件管理提交物，比如CVS
建议创建目录：
D:\LR_Project
1) script目录 存放脚本文件 *.usr
2) scenario目录 存放场景文件 *.lrs
3) result目录 存放结构分析文件 *.lra
4) date目录 参数化的数据文件 *.dat
5) file目录 等待上传的文件 *.txt *.doc *.jpg

服务器端 Tomcat配置文件 conf\web.xml
关于Session超时时间配置 30分钟
用户登录成功后Session默认维持30分钟，超过该时间用户不发请求，自动离线。
<session-config>
<session-timeout>30</session-timeout>
</session-config>

面试题：
问题：测试机和服务器都需要进行系统资源监控吗？怎么监控？
都要监控；
对于服务器需要使用LR的Monitor进行监控，使用常用的计数器获取其趋势、最终平均效果，便于后续性能分析。
对于测试机（客户端）也要监控，只需要打开客户端的任务管理器、系统监控窗口辅助监控，保证运行平稳即可。

根据二八原则（80%的交易量发生在20%的时间段内）
80%的缺陷存在于20%的位置
80/20原则 要花80%的精力在目前20%的重点上
需求 分析设计 开发 测试 实施

需求 环境 计划 执行 分析

墨菲定律：有时越不可能发生的事情越容易发生。

常见的性能测试策略：

1）基准测试：单用户、单测试点、循环执行n次
2）并发测试：多用户、单测试点、瞬时压力
3）综合场景测试：多用户、多测试点、在线持续一段时间
（混合交易测试）
4）递增测试：结合以上进行逐步加压
5）疲劳强度测试：压力更大、时间更长的综合场景测试
6）数据容量测试：模拟海量数据重新考量之前性能
面试题：如何向系统中添加海量数据？
思路：自动化 sql 脚本 参数化 存储过程 具体算法

开始执行计划：结合测试工具LoadRunner
1、VuGen
1）业务需求：流程->用例中体现
2）合适的协议：B/S常用 Web[HTTP/HTML]协议
3）常用设置
<1> IE浏览器： Internet选项
常规 设置 每次访问此页时检查
程序 重置Web设置
高级 去除 启用第三方浏览器扩展
<2> 当前建议关闭本地连接，提高工具效率
实际项目中不能关闭，客户端需要通过网络访问服务器
<3> 关闭一些冲突的服务：java oracle 杀毒进程...
<4> 使用脚本视图，设置界面字体、回放后自动弹出测试结果
<5> 录制选项：
录制方式-默认采用基于HTML方式
必要时采用基于URL方式，比如采用https协议 设置自动页面标题检查点，辅助检查
设置录制使用的字符集：UTF-8 和当前项目一致
使用默认方式录制后脚本中文出现乱码问题
<6> 采用架构：B/S或C/S
<7> 采用协议：Web[HTTP/HTML]
<8> 指定浏览器产品：IE
<9> URL地址：http://localhost/web/guest/home
<10> 录制位置：vuser_init Action vuser_end

练习：录制并调试user_login脚本
采用的数据：test01 1111
事务名：user_login
集合点名：user_login
检查点：Welcome test01! 使用源代码

今天的重点：
1、项目简介 名称、架构、技术组成、业务范围、功能模块、业务特点、名词术语
2、分析需求：功能（业务）、性能（指标）
3、测试计划：测试范围、测试策略、测试用例..
4、测试环境搭建：测试机环境、被测系统环境
5、使用VuGen设置和录制脚本

常见性能测试面试问题：
1、手机号参数化 唯一手机号 UEA版本2
Unique Number类型 指定具体策略规则
Each Iteration 每次迭代更新
Abort Vuser 放弃VU
2、负载测试和压力测试区别
3、如何设置集合点、意义何在？如何进行并发测试？
4、性能测试基本流程？
5、性能测试的关键？需求、业务、指标、计划、协议、脚本、场景、分析

二、执行计划：录制和增强脚本
1、脚本： 脚本名、事务名、集合点名
1）用户登录：user_login
2）查询稿件：search_manuscript
3）增加稿件：add_manuscript
4）显示稿件：show_manuscript
5）上传文档：upload_document

2、提前分工完成参数化测试数据：*.dat文件
注意：和业务操作有关，要保证数据的真实、有效，保证良好的格式，确保数据使用正确。数据量根据实际需要准备。
-- 更真实模拟实际用户访问效果

3、脚本录制和调试
事务、检查点、集合点、参数化、关联、流程控制...
1）用户登录：user_login

2）查询稿件：search_manuscript
使用高级查询：
number,version,title,content
带有条件：编号 版本 标题 内容
25345 1.0 微软 2月1日

3）增加稿件：add_manuscript
录制使用的数据：
稿件标题：录制和调试脚本
稿件内容：关键在于业务和增强
点击第二个增加按钮，对标题进行检查
参数化：title,content

4）显示稿件：show_manuscript
使用模糊查询，在首页中显示某条稿件，比如第3条
目前编号：46817
原理：根据id查询员工信息的URL
http://ip地址:8080/ems/findById?id=5&...
协议名 主机名 端口号 应用名 请求路径?参数名=参数值

Referer=http://localhost/group/10779/articles
?p_p_id=15&_15_articleId=46817&_15_version=1.0
请求后携带参数 ?参数名=参数值&参数名=参数值&...