一、脚本关联技术
引入：
打开WebTours首页，点击administration连接：
具有大量管理项，LR为了模拟一些特效设置的选项，实际项目中不存在。
-> 选择第三项：
Set LOGIN form's action tag to an error page.
-> 点击Update按钮 提交表单 生效
目的：模拟一种效果
录制脚本：day083login
基于HTML: Options -> HTML-base script
录制成功，回放失败！发现脚本：
"Name=userSession", "Value=120939.455164034zccAicDpccfDHDctpQDQDf"
User Session ID
用户 会话 id
凭经验：很可能脚本需要关联
HTTP协议：简单的、无状态的协议
简单：协议底层结构比较简单 头和主体
header body
无状态：一次请求，一次响应后，服务器默认不会记录用户的状态。
但是有需求：需要记录用户的状态，比如登录在线、购物车
记录用户状态的技术： Client(浏览器) <---> Server
客户端 Web服务器
Http Request ---->
Http Response <----
Session和Cookie有何区别？（Web开发规范）
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
有时是一串局部业务含义的字符串；
比如日期、订单号、价格...
123102.056379101zDDcAzcpAcfDHQQcpDHcVf
123102.417901985zDDcAiApzcAiDDDDDHQQcptiDHcf
4）哪些不是？
坐标值、think time、检查点的函数和文本、更不是整段的请求。
6、关联的类型
1）手动关联（常用）
2）自动关联（不够稳定，较少使用）
7、手动关联的具体步骤：
1）录制成功，回放失败，怀疑和动态数据有关；
2）再录制一份脚本，进行比对，确定存在动态数据；(难点)
3）找到第一次产生该动态数据的响应对应的相应请求；
4）在相应请求之前写关联函数，将动态数据自动赋值给某变量（参数）； web_reg_save_param(...) 函数
reg 注册性函数 相应请求之前！
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变量名
"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
策略 随机购票 RE组合
fromcity.dat
fromcity,tocity
Denver,London
Denver,Paris
Paris,London
脚本增强技术：事务、检查点、（集合点-并发时）、参数化、关联...
调试思路：走一步，看一步 步步为营
归纳：关联
1、关联的定义：将脚本中的静态数据使用参数代替，适应服务器端动态数据的变化。
-- 特殊的参数化 数据是由服务器端产生的
之前的参数化：数据由自己准备或规则产生
2、动态数据 -- 进行关联的重要前提
3、相应请求 -- 为了写关联函数
4、关联函数
web_reg_save_param("参数名", "LB=", "RB=", LAST);
5、思想：以不变应万变！
性能测试重点：
1、什么是性能测试？
需求、计划*、测试环境*、执行计划、测试工具、结果分析*
2、LoadRunner工作原理
1）VuGen 脚本技术 1VU 录制、回放
增强：事务、检查点、参数化、集合点、关联、
流程控制、函数调用...
2）Controller 场景 Scenario (测试计划)
模式、组设置、用户行为、Run-time Settings、日志获取、系统资源监控（十多个计数器）
3）Analysis
常见指标：平均事务响应时间、TPS、点击率、吞吐量
最大并发用户数、系统资源特性
图表：根据不同指标打开查看，必要时可以合并比较
-- 作为依据编写《性能测试报告》
4）Load Generator
必要时可以采用联机测试
3、掌握常用测试策略：
1）基准测试：单用户、单测试点、执行n次
2）并发测试：多用户、单测试点 瞬时并发执行1次
3）在线综合场景测试：多用户、多测试点，在线执行1h左右
4）递增测试：逐步加压 VU的增加、请求数的增加
5）疲劳强度测试：压力更大的综合场景
6）数据容量测试：大数据量测试