LoadRunner（8）

一、脚本关联技术 
　　引入：
　　　　打开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协议：简单的、无状态的协议
　　简单：协议底层结构比较简单 头和主体
　　　　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）数据容量测试：大数据量测试