注：二八定律：80%员工在20%时间登录；80%员工在使用20%的功能
一、什么是性能测试
概念：性能测试是模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
说明：
1). 峰值：客户指定指标数值或场景需求数值，如：CPU80%以内、登录3秒、内存空间40%...
2). 负载：用户(一个、多个)向服务器发送请求...
功能测试：验证软件系统操作功能是否符合产品功能需求规格，主要焦点在功能（正向、逆向）；
性能测试：验证软件系统是否满足业务需求场景，主要焦点是业务场景的满足(时间、空间)；
说明：
时间（对于应用服务器而言）：软件的响应时间...
空间（对于硬件服务器而言）：服务器的磁盘使用率、CPU使用率、内存空闲率...
二、性能测试常用分类
提示：性能测试分类还有其他类型比如：配置测试、容量测试等
1. 负载测试
概念：通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足系统的性能指标情况下，系统所能够承受的最大负载量的测试。 (负载：向服务器发送请求)
提示:负载测试是通过逐步加压的方式来确定系统的处理能力、确定系统能够承受的各项阀值。例如：逐步加压，从而得到“响应时间不超过3秒”、“服务器平均CPU利用率低于80%”等指标的阀值。
2. 压力测试
概念：通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于【失效】状态。
提示：
1）. 压力测试：是逐步增加负载，使系统某些资源达到饱和甚至失效。
(如：测试系统最多支持同时处理多少请求，超过此数数量系统瘫痪)
2）. 负载测试：是逐步增加负载，确定在满足性能指标情况下，系统能承受的最大负载测试。
(如：登录3秒内，最多支持多少用户同时登录；如超出此数量，可能需要5秒钟或更多时间才能登录成功)
3. 并发测试
概念：并发测试就是【多用户】同时访问【同一个应用】
目的：测试应用服务器 指定功能 的同时访问数是否达到预期结果
提示： 并发测试需要配合集合点来使用
4. 稳定性测试
概念：通过给系统加载一定的业务压力（理解为不断向系统发送请求）（如CPU资源在70%～90%的使用率）的情况下，运行一段时间，检查系统是否稳定
提示：通常稳定性测试，我们测试一段时间即可；(分阶段测试如：24小时、时间充裕的时候再测3×24小时，时间还是充裕的时候再测7×24小时来模拟长时间运行)
三、性能测试常用 指标
1. 吞吐量（Throughput）
说明：指的是单位时间内处理的客户端请求数量，直接体现软件系统的性能承载能力。通常情况下，吞吐量用“请求数/秒”或者“页面数/秒”来衡量。
提示：
1）. 从业务角度来看，吞吐量也可以用“业务数/小时”、“业务数/天”、“访问人数/天”、“页面访问量/天”来衡量。
2）. 从网络角度来看，还可以用“字节数/小时”、“字节数/天”等来衡量网络的流量。
2. 并发数（Concurrency）
说明：并发：它最简单的描述就是指多个同时发生的业务操作。（例如，100个用户同时单击登录页面的“登录”按钮操作。）
提示：并发性测试描述的是多个客户端同时向服务器发出请求，考察服务器端承受能力的一种性能测试方式。
3. 响应时间
说明：响应时间指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回结果（返回的是一堆代码，正常说的响应时间不含浏览器解析接收到的代码的时间，但对客户而言是要包含浏览器解析时间的）整个过程所耗费的时间
4. 点击数（只有web项目才有点击数）
说明：点击数是衡量Web服务器处理能力的一个重要指标。它的统计是客户端向Web服务器发了多少次HTTP请求计算的。
提示：
1）. 点击数不是通常一般人认为的访问一个页面就是１次点击数，点击数是该页面包含的元素（如：图片、链接、框架等）向Web服务器发出的请求数数量，由服务器的响应状态码（200）来统计。
2）. 通常我们也用每秒点击次数（Hits per Second）指标来衡量Web服务器的处理能力。
5. 资源利用率（指的是硬件资源）
说明：是指系统各种资源的使用情况，一般用“资源的使用量/总的资源可用量×100%”形成资源利用率的数据。
通常，没有特殊需求的话
1). 建议CPU不高于80%；
2). 内存不高于80±5%；可使用内存至少20%
3). 磁盘不高于90%；
6. 错误率
说明：错误率指系统在负载情况下，失败交易的概率。错误率＝(失败交易数/交易总数)*100%。
提示：
1）. 不同系统对错误率要求不同，但一般不超过千分之五=0.5%；
2）. 稳定性较好的系统，其错误率应该由超时引起，即为超时率。
四、Jmeter and LoadRunenr
提示：
1. Jmeter： 接口测试及接口性能压测首选
说明：Apche公司使用Java平台开发的一款测试工具
作用：性能测试、接口测试、Web测试(无Gui)
优点：免费、开源、小巧
2. LoadRunner： Web性能测试首选
说明：HP公司使用C语言开发的一款性能负载测试工具
作用：模拟高并发负载测试、测试场景搭建、运行、监控 、结果分析
优点：支持多协议、自带强大的图表功能、可根据需求合并需要的图表
缺点：收费
五、性能测试步骤
1. 性能测试需求分析
说明：需求分析就是把真正需求搞清楚；
例如：以下都不是真正的需求
1). 我们需要贵单位对所有的功能都进行性能测试;
2). 系统用户登录响应时间小于3秒钟;
3). 系统支持20万用户并发访问; （根据二八定律来分析得出真正的需求）
80%用户=160000
20%时间=1.6小时
每小时最高登录100000
100000/3600=28人/秒
2. 性能测试计划
说明：
1). 性能测试计划是对性能测试的重要过程。
2). 在对需求文档经过认真分析后，作为性能测试管理人员，需要编写的第一份文档就是性能测试计划;
3). 性能测试计划中，需要阐述产品、项目的背景，将前期的需要测试性能需求明确，并落实到文档中。还有测试进度，测试计划。
3. 性能测试用例
说明：性能测试需求最终要体现在性能测试用例设计中，性能测试用例应结合用户应用系统的场景，设计出相应的性能测试用例，用例应能覆盖到测试需求。
提示：
1). 明确那些业务功能使用频繁；
2). 明确系统预期的用户规模、并发用户数、在线用户数；
3). 明确系统业务的处理能力要求，如：TPS、响应时间、系统资源利用率等；
TPS ：(Transaction per second)事务数/秒
4. 测试脚本编写
说明：性能测试用例编写完成以后，接下来就需要结合用例的需要，进行测试脚本的编写工作。
提示：
1). 协议的正确选用;
2). 脚本保证其正确性，去除冗余代码;
3). 注重编码的规范和代码的编写质量；
5. 测试场景设计
说明：测试场景的设计一个重要的原则就是依据测试用例，把测试用例设计的场景展现出来。
提示：
1). 虚拟用户数量及启动虚拟用户方式
2). 场景的相关设置(如：集合点)
3). 脚本是否存在依赖关系(登录与注册)
6. 测试场景运行
说明：测试场景运行是关系到测试结果是否准确的一个重要过程。
注意事项：
1). 负载的测试机不能够运行设定的虚拟用户数；
2). 不能没有“预热”过程；先跑一遍
3). 不能没有模拟用户的真实环境；
4). 不能性能用例运行次数过少
7. 场景运行监控
说明：场景运行监控，可以在场景运行时决定要监控那些数据，便于后期分析性能测试结果。
提示：
1). 应用性能测试工具的重要目的就是可以提取到本次测试关心的数据指标内容;
2). 性能测试工具利用应用服务器取得在负载过程中相关计数器的性能指标。
(计数器：计算、统计性能指标的工具)
注意：
1). 负载机的时钟要一致，保证在监控过程中的数据是同步的；
2). 尽量搜集与系统测试目标相关信息，无关内容不必进行监控；
3). 要以管理员的身份登录后（指的是负载机）
8. 运行结果分析
说明：性能测试执行过程中，性能测试工具搜集相关性能测试数据，待执行完成后，这些数据会存储到数据表或者其他文件中,为了定位系统性能问题，我们需要系统分析这些性能测试结果。
提示：
1). 一般使用“拐点分析”方法，利用性能计数器曲线图上的拐点进行分析的方法。
（基本思想就是性能产生瓶颈的主要原因就是因为某个资源的使用达到了极限，此时表现为随着压力的增大，系统性能却出现急剧下降，就产生了“拐点”现象。）
9. 系统性能调优
说明：性能测试分析人员经过对结果的分析以后，有可能提出系统存在性能瓶颈。
提示：
1). 调优人员(开发人员、数据库管理员、系统管理员、网络管理员、性能测试分析人员)相关人员对系统进行调整;
2). 验证-性能测试人员继续进行第二轮、第三轮……的测试，与以前的测试结果进行对比，从而确定经过调整以后系统的性能是否有提升。
注意: 系统调优由易到难的先后顺序如下：
1）. 硬件问题；
2）. 网络问题；
3）. 应用服务器、数据库等配置问题；
4）. 源代码、数据库脚本问题；
5）. 系统构架问题。
10. 性能测试总结
-----------------------------------------------------------------------------------------------------------------------------------
注意事项： LoadRunner VuGen录制的浏览器只能选择32位(IE)
一、LoadRunner 简介
说明：
1). HP LoadRunner是一种工业级标准性能测试负载工具，可以模拟上千万用户实施测试，并在测试时可实时检测应用服务器及服务器硬件各种数据，来确认和查找存在的瓶颈；
2). 支持多协议：Web(HTTP/HTML)、Windows Sockets（win32的协议）、FTP、ODBC（数据库协议）、MS SQL Server等协议
组成：
1）. Virtual User Generator（VuGen）：脚本生成器-脚本录制、编辑
2）. Controller：控制器-设计场景、运行、监控
3）. Analysis：测试结果分析
VuGen介绍：录制客户端和服务器之间的相关交互活动，它将自动生成相关模拟实际情况的API函数。
LR录制脚本功能由于兼容性问题，非常不好使，我们平时在工作中也不使用录制方式，在这里我们了解下它的录制过程；由于兼容性和录制多余操作，一般手写脚本。
二、 VuGen录制设置
1. option选项
1）. HTML-based script: 所有请求放到一个函数内，每个操作放在一个函数内
2）. URL-based script: 每个请求放到一个函数（一个操作可以有很多请求）
提示：
1). 基于浏览器的应用程序推荐使用HTML-based Script
2). 不是基于浏览器的应用程序推荐使用URL-based Script。
3). 基于浏览器的应用程序中使用了HTTPS 安全协议，使用URL-based 方式录制
2. HTML Advanced选项
1）. web_submit_form: 依赖上下文才能提交
2）. web_submit_data: 不依赖上下文，每个函数都指定了具体的url地址，可以直接提交成功【推荐】
三、VuGen运行（回放）设置
Run-time Settings (菜单-Vuser->Run-time Settings) 快捷键F4
1.Run-time Settings
1）. Run Logic 脚本运行迭代次数：迭代就是脚本要执行的次数，Init与End迭代次数不生效，只会运行一次
2）. Think Time 运行时思考时间处理方：模拟真实场景下，两个用户点击间延迟；但做性能压测的时候，一般会把这个时间忽略，因为太占时间了，在Run-time Settings——Think Time——ignore think time设置
- Ignore think time 默认(忽略思考时间)
- Replay think time (播放思考时间)
1). As recorded (录制多少秒，就等待多少秒)
2). MuItiply recorded think time by (录制时间的倍数)
3). Use random percentage of recorded think time
( Min(录制时间的最小百分比) Max(录制时间的最大百分比))
4). Limit think time to( 限制最高时间)
2. 常用函数：
1）. lr_output_message() // 如：lr_output_message("hello Action")，参数: 要输出的文本信息，输出到运行日志的函数 类似 Python print
2）. lr_think_time() // 思考时间函数，最大可能模仿用户真实操作 如：lr_think_time(4)
参数：停顿多少秒，类似 python sleep;
示例脚本：
Action()
{
lr_output_message("Action被执行");
lr_think_time(6)
return 0;
}Action2()
{
lr_output_message("Action2被执行");
return 0;
}
提示：
1）. C语言语法:必须以分号(;)作为行结束标记
2）. return 0:结束本次迭代，进入下一迭代；如果是return -1，就不会进入下次迭代
四、扩展 - 编译（compile）
C语言是高级语言，需要编译成汇编语言才能被计算机识别
1. shift+F5，可以不运行直接编译，看脚本会不会返回错误信息
五、脚本注释
1. //：单行注释 如：//登录
2. /**/：多行注释 如：/*多行 注释*/
六、手动编写脚本时常用函数
1. web_url：GET请求使用时使用
语法：web_url("request name","URL=http://***",LAST);
1). request name:标记请求名称，比如：首页
2). URL=http://***:URL=为固定格式；http://***为GET请求地址
3). LAST结束标志；
2. web_submit_data：POST请求专用
语法：web_submit_data( StepName, Action=http://***, <List of Attributes>, ITEMDATA,<List of data>, LAST );
1). StepName：标记请求名称， 比如：登录
2). Action=http://***：Action=固定格式；http://***：提交地址
3). List of Attributes:其他属性 如："Method=POST"
4). List of data:其他参数 如："username=jojo"
5). LAST：结束符
提示：
1）. POST提交参数比较多，我们不用一个个记，使用插入函数方法，在函数对话框内输入；在需要插入这个函数的地方右键-insert-new step-搜索“submit data”-在GUI中设置
2）. 录制HTML页面时，Mode推荐使用HTML；
3. web_custom_request：定制请求（GET\POST\PUT\DELETE）等，接口请求使用此函数
语法：web_custom_request( RequestName, <List of Attributes>,LAST );
1). RequestName：请求名称
2). List of Attributes：属性列表，如："Method=POST"
3). LAST：结束符
七、参数化
概念：根据需求动态的获取数据的过程
1. 参数化操作
1）打开参数化菜单：选中要参数化的文本->鼠标右键->Replace with a Parameter
或者 菜单【Insert】>【New Parameter...】
2）Replace with a Parameter 打开的窗口：Parameter name:参数化引用名称（参数化时使用），Parameter type:File 【推荐-File】，Properties:属性-点击此按钮，可直接设置参数化引用名称对应的值；【点击】
提示：点击OK；参数化引用名称具体的值，需要再次设置；
3）Properties 设置面板：. Parameter type: 参数类型 File 【重点】，File：参数保存的文件类型及位置，一般为txt;选定以后要点create table才能在相应的目录下创建一个对应的txt文件；在txt文件中最后一行的数据后面要多一个回车【推荐】，Add Row:添加行，在当前表格编辑数据；【可选】， Edit with Notepad:在记事本内编辑数据；【推荐】，Select next row:运行或迭代时对行的选择方式，Update value on:运行或迭代时对值的选取方式
2. 函数：lr_save_string() 和 lr_eval_string()
lr_save_string()
说明：把字符串保存到指定的参数中
格式：lr_save_string("字符串","参数名")
示例：lr_save_string("北京","city")
lr_eval_string()
功能：读取变量的值，并以Char类型返回
示例：lr_eval_string("{parameter}")
提示：
1). 参数名称使用花括号{}包括
2). 参数使用双引号包括
Action()
{
lr_output_message("我要去%s",lr_eval_string("{NewParam}"));
return 0;
}
3. Select next row与Update value on
Select next row
说明：读取参数文件行的方式
方式：
1）. Sequential：顺序，按照行的顺序读取数据，如果迭代次数大于行数，再次从第一行开始读取
2）. Random：随机，随机读取行
3）. Unique：唯一，每次读取唯一行，不重复；如果行数读完，立即停止迭代；
4）.Same line as：取参数同行（需要两个以上参数，才能显示和使用）
Update value on
说明：参数值更新的方式
方式：
1）. Each iteration：每次迭代以后更新
2）. Each occurrence：每次出现参数时更新
3）. Once：每出现一个虚拟用户(线程)更新一次
组合
1）. 行顺序+每次迭代更新值 Sequential + Each iteration
2）. 行顺序+每次参数出现更新值 Sequential + Each occurrence
3）. 行顺序+更新一次(单用户) Sequential + Once
说明：
1）. 组合我们在这里就不穷举了，以行的顺序配合值的3种更新方式做演示
2）. 因为组合内含occurrence，所以必须要两个Action，我们新增两个（Action、Action2）两个代码相同
代码
Action()
{
lr_output_message("我要去%s",lr_eval_string("{NewParam}"));
return 0;
}Action2()
{
lr_output_message("我要去%s",lr_eval_string("{NewParam}"));
return 0;
}
Sequential + Each iteration
说明：行为顺序，值为迭代更新一次；
预期：
1）. 第一次迭代：Action:北京；Action2:北京
2）. 第二次迭代：Action:上海；Action2:上海
3）. 第三次迭代：Action:广州；Action2:广州
4）. 第四次迭代：Action:深圳；Action2:深圳
Sequential + Each occurrence
说明：行为顺序，值为出现一次更新一次
预期：
1）. 第一次迭代：Action:北京；Action2:上海
2）. 第二次迭代：Action:广州；Action2:深圳
3）. 第三次迭代：Action:北京；Action2:上海
4）. 第四次迭代：Action:广州；Action2:深圳
Sequential + Once
说明：行为顺序，值为单用户只更新一次
预期：
1）. 第一次迭代：Action:北京；Action2:北京
2）. 第二次迭代：Action:北京；Action2:北京
3）. 第三次迭代：Action:北京；Action2:北京
4）. 第四次迭代：Action:北京；Action2:北京
4. 扩展 批量获取参数时，如果保证参数不重复？
思路：添加时间戳
说明：web_save_timestamp_param("time_stamp",LAST) 为时间戳函数，返回：1970到现在的毫秒数；(time_stamp：参数为获取值后保存的参数名称，被引用时使用)
示例：
Action()
{
web_save_timestamp_param("time_stamp",LAST);
lr_output_message("我要去%s",lr_eval_string("{NewParam}_{time_stamp}"));
return 0;
}
5. 其他常用参数类型parameter type
parameter type：Date/Time，Random Number，Unique Number
提示：Unique需要配合Controller的虚拟用户使用
-----------------------------------------------------------------------------------------------------------------------------------
一、关联
1.1 什么是关联(correlation)？
说明：动态获取指定的数据，把获取的数据通过参数化方式在另一处引用
1.2 为什么要学习关联？
1. 获取动态加载的数据，Session ID
2. 测试的时候需要获取页面上指定的数据，注意是获取，而不是查找；
说明：Session ID：客户端与服务器交互时，服务器生成的一个唯一标识码; (通过标识码服务器可以区分多次交互对象是否同一客户端，浏览器只要不关闭标识码就不变；)
1.3 关联方式：
1. 自动关联 【不推荐】
说明：LoadRunner11.0的VuGen利用自带的一些关联规则，使用关联函数对需要进行的关联数据进行数据关联；启用
提示：
1. 自动关联LoadRunner提供两种方式：
1). 启用录制脚本能自动关联-在录制的时候如果有符合关联规则的就直接进行关联； (注意：此种方式依赖于LR自带的规则或新建的规则)
启动自动关联位置：工具菜单(Tool)->Recording Option
2). 脚本录制完成并且运行完一次后，打开扫描工具，进行扫描需要关联的数据；(注意：利用工具必须先运行一遍脚本)
-. 启动：打开扫描工具-Ctrl+F8 或者菜单栏(Vuser)->Scan Script for Correlations
-. 扫描：扫描之前先运行一遍脚本
-. 关联：图中个第二步Correlation Results内进行关联
2. 自动关联调用的是关联函数 web_reg_save_param_ex()；
(web_reg_save_param_ex与web_reg_save_param功能大致相同，它可以使用正则表达式和过滤器)
总结：
自动关联-启用自动关联设置：采用自带或设定的规则在录制脚本的时候自动关联
自动关联-扫描工具：前后运行两次，搜索两次不同之处为需要关联的数据，进行确认关联
自动关联无论那种方式，都是采用调用关联函数的方法，工具智能人更智能建议掌握接下来关联函数的使用
2. 手动关联-函数 【推荐】
手动关联就是直接调用关联函数
1.4 关联函数 web_reg_save_param()
说明：
1). 执行顺序：LR中函数内含reg为注册函数，注册函数是在下一个Action Function完成时执行。
2). 函数位置：注册函数【必须】放到下一个Action Function(要进行关联数据所在的函数)函数之前；
3). 如果关联的参数值超过256个字符，需要调用 web_set_max_html_param_len("1024")改变参数长度；
案例示范：
使用web_reg_save_param()函数把WebTours首页部分内容关联给Welcome参数操作分析
1. 在Web_url函数之前插入关联函数 web_reg_save_param()
2. 调用lr_eval_string()来读取关联函数的参数引用名称，并通过lr_output_message()函数输出到日志函数参数设置
1). Parameter Name:参数名称（被引用时使用）
2). Left Boundary(LB):左边界
3). Right Boundary(RB):右边界
4). Not Found:关联失败时，处理方式
5). Search in:匹配搜索响应代码范围
注意：单引号(')、双引号(")、反斜杠(\)、回车换行等需要转译字符，加上转移字符[\]
如何查看页面元素响应代码？
1. 通过lr查看响应代码
结构为Tree
url：为WebTours
页面为/WebTours/home.html
2. 通过页面查看源代码：地址：http://127.0.0.1:1080/WebTours/home.html
最终代码：
Action2()
{
web_reg_save_param("Webcome",
"LB=</H1>\n",
"RB=\n"
"<br>",
"NotFound=ERROR",
"Search=All",
LAST);web_url("WebTours",
"URL=http://127.0.0.1:1080/WebTours/",
"TargetFrame=",
"Resource=0",
"RecContentType=text/html",
"Referer=",
"Snapshot=t1.inf",
"Mode=HTML",
LAST);lr_output_message("Webcome值为：%s",lr_eval_string("{Webcome}"));
return 0;
}
二、检查点
说明：检查点是在回放脚本期间搜索指定的文本或图片，从而验证服务器响应数据的正确性；
提示：
1). LR中的检查点推荐使用web_reg_find()函数，注册函数从缓存中查找
2). 在LR中使用检查点的时候必须开启 Enable Image and text check(启用图片和文本检查)，Run-Time Settings - Preferences - Enable Image and text check
3). 要使用检查点录制模式必须是HTML-based mode 且为 web_submit_form模式
1. web_reg_find() 查找文本 【掌握】
说明：web_reg_find为LR检查点函数；
参数：
1. Text:要检查的文本内容【必填】
2. Search：搜索响应数据范围- ALL、Body、Header【选填】
3. Fail：失败条件-NotFound/Found 【选填】
4. SaveCount：匹配结果数量且返回到参数中【选填】
注意：
1. 函数包含reg为注册函数，注册函数必须放到依赖执行函数之前(依赖：函数运行后的数据给注册函数使用)
参数：
1. Search for specific Text:搜索特定文本
2. Search in:搜范范围
1). All ：搜索Body+Headers
2). Body：只搜索Body
3). Headers：只搜索Headers
3. Save count:搜索满足条件的数量，并保存在指定的参数名中
4. Fail if:检查失败的条件
1). NotFound 没有找到检查失败 -推荐
2). Found 找到了检查失败
2. web_find() 查找文本 【了解】
web_find() 普通查找函数（在当前页面查找指定内容），所以一般放在action函数后面，等页面加载出来了之后才能去查找
3. web_image_check() 查找图片 【了解】
也是一般放在action函数后面，等页面加载出来了之后才能去查找，使用src属性+相对路径去查找（这些信息可以在网页的源码中找到），也可以使用alt属性查找
三、事务（Transaction）
3.1 什么是事务？
概念：事务（Transaction）是用户在应用软件上操作的一个业务或多种业务集合(actions)的统称；
作用：
1）. 通过事务可标记业务开始和结束，并且可统计相应业务的操作时间(事务时间)【重点】
2）. 通过事务状态机制，可判断相应业务执行的成功与失败；【了解】
3）. 通过事务来衡量服务器性能；
3.2 添加事务的方式
说明：LR添加事务有两种方式：
1). 录制脚本的时候添加【了解】
2). 运行脚本的时候添加【推荐】
提示：
1. 插入事务开始 lr_start_transaction("Name")
1. 插入方式：
1). Ctrl+T
2). 鼠标右键Insert->Start Transaction
3). 工具栏菜单(Insert)->Start Transaction
2. 参数：Name:事务名称
2. 插入事务结束 lr_end_transaction("Name", "status")
1. 插入方式：Ctril+D，参考插入事务开始
2. 参数
Name:事务名称和开始事务名相同；
status:标志事务状态
1). LR_AUTO: 自动-由LR判断 【推荐】
2). LR_PASS：通过
3). LR_FAIL: 失败
4). LR_STOP: 停止
注意：
1. 插入事务时，不要包含lr_think_time()函数
2. 事务名称(中文、英文)，建议英文；
3. 事务名称开始和结束必须相同 如：登录(Login)
4. 事务必须成对出现 lr_start_transaction("登录"); ... lr_end_transaction("登录", LR_AUTO);
3.3.事务时间：
1). 一个事务的时间是指事务持续时间(Duration Time)从事务的开始到结束；
2). 事务时间包含：
1). 响应时间：客户端浏览器解析渲染响应数据不算响应时间
2). 浪费时间(Wasted Time)：LR自动会把一些函数执行的时间统计为浪费时间，比如（关联、检查点）等函数
3). 思考时间(Think Time)：lr_think_time()函数
4). 事务自身执行时间：lr_start_transaction("")和lr_end_transaction("", LR_FAIL)这两句代码执行的时间；
3). 在运行脚本后，运行日志内有事务时间、Wasted Time时间，单位为秒；
总结：
1. 站在代码角度，事务的开始与结束，其实就是指定一段代码为一个事务；
2. 而代码段内可以包含思考时间、业务代码、事务函数，所以说事务时间包含响应(业务)，时间、思考时间、事务自身、其他函数(浪费时间)
3. 事务时间=响应时间+浪费时间+思考时间+事务自身执行时间
3.4 补充：strcmp函数
说明：比较两个字符串(匹配大小写)是否相等，并返回int型数值；
用法：result = strcmp( string1, string2);
result:
1). <0 string1小于string2;
2). 0 string等于string2;
3). >0 strring大于string2;
提示：如果要忽略大小写请使用 stricmp函数，用法参考strcmp
案例示范：
1. 在登录函数之前插入开始事务
2. 获取登录后的用户名
3. 判断登录用户名是否为jojo，如果是
插入结束事务并且事务状态为：LR_PASS，
否则
插入结束事务，事务状态为：LR_FAIL；
问题：如何判断登录名是否为jojo？代码：
Action2()
{
# 定义int变量 ，接受字符串对比结果值
# C语言中，定义变量必须要在开头
int result;
web_url("WebTours",
"URL=http://127.0.0.1:1080/WebTours/",
"Resource=0",
"RecContentType=text/html",
"Referer=",
"Snapshot=t1.inf",
"Mode=HTML",
LAST);lr_think_time(8);
# 登录事务开始...
lr_start_transaction("Login");# 使用关联函数获取登录信息
web_reg_save_param("username",
"LB=Welcome, <b>",
"RB=</b>, to",
"NotFound=ERROR",
"Search=All",
LAST);web_submit_form("login.pl",
"Snapshot=t2.inf",
ITEMDATA,
"Name=username", "Value=jojo", ENDITEM,
"Name=password", "Value=bean", ENDITEM,
"Name=login.x", "Value=68", ENDITEM,
"Name=login.y", "Value=12", ENDITEM,
LAST);# 调用字符串对比函数判断获取登录用户是否为jojo
result = strcmp(lr_eval_string("{username}"),"jojo");/*以下两行为测试调试代码 */
# 查看对比结果是否相等，相等为0
lr_output_message("result参数值为：%d",result);# 查看关联获去的参数值
lr_output_message("username值为：%s",lr_eval_string("{username}"));# 判断对比结果是否相等
if (result==0) {
# 相等插入通过状态事务
lr_end_transaction("Login", LR_PASS);
lr_output_message("事务通过！");
}else{
# 不相等插入失败状态事务
lr_end_transaction("Login", LR_FAIL);
lr_output_message("事务失败！");
}lr_think_time(19);
web_image("SignOff Button",
"Alt=SignOff Button",
"Snapshot=t3.inf",
LAST);return 0;
}
四、集合点(rendezvous)
概念：集合点(rendezvous)，在指定的地点集合指定虚拟用户(Vuser)，条件满足时集合的虚拟用户，同时去操作同一事务；
4.1 集合点 创建
方式：
1. 指定插入位置，鼠标右键->Insert->Rendezvous 【推荐】
2. 工具栏菜单(Insert)->Rendezvous
参数：lr_rendezvous("Name")--->Name：集合点名称；在Controller场景运行时使用 如：Login
提示：
1. 集合点创建，相当于找好集合的地方，那么到底应该那些用户及集合多少用户需要单独设置
2. 集合点要设置和运行，必须在Controller工具内完成；
4.2 集合点设置
1). 基于当前脚本 创建Controller场景
菜单工具(Tools)->Create Controller Scenario(基于当前脚本直接创建场景)
2). 选择场景模式及虚拟用户数
1. 场景模式：Manual Scenario(手工场景)
2. Numberof Vusers：虚拟用户数
提示：
场景模式：我们还没了解，在这里暂时使用下手工场景
虚拟用户数：为并发用户数，我们这里以需求10个并发登录为例
3) Controller工具内设置集合策略
Controller工具-菜单(Scenario)->Rendezvous
说明：
1. 创建场景时10个用户，默认10个用户都参与集合点
2. 可指定用户不参与集合点 选择用户-单击Disable VUser按钮
3. Policy：设置集合用户策略
集合策略：
1). 当所有虚拟用户中的x % 到达集合点进释放;
2). 当所有正在运行的虚拟用户中的x %到达集合点时释放;
3). 当x 个虚拟用户到达集合点时释放; 【推荐】
时间：
Timeout between Vusers:默认30秒-当指定时间内还未达到以上集合策略用户数量时,释放已集合用户去执行；
4）. 集合点设置 注意事项
1）. 集合点只能在手工场景模式内使用
2）. 多个脚本需要同步并发，可以在不同脚本内设置相同集合点，在一个场景内搭建这些脚本；
3）. 如果脚本内没有设置集合点，在Controller内集合点策略设置功能不生效
4）. 集合点只能在Action部分添加，init、end无法添加
-----------------------------------------------------------------------------------------------------------------------------------
一、Controller 简介
1.1 为什么要学习 Controller？
集合点需要在Controller场景中运行；
性能测试就是模拟应用程序在【真实环境】中运行的情况;(真实环境:就是需要模拟搭建各种业务场景，各种应用场景的搭建就需要Controller工具)
1.2 Controller运行方式
1. 从VuGen脚本直接启动Controller【已讲解】
2. 直接运行Controller 【推荐】：开始菜单->HP LoadRunner->Applications->Controller 【建议发送桌面快捷方式】
3. 通过LR工具管理器运行： 开始程序->HP LoadRunner->LoadRunner，点击 Run Load Tests
二、运行Controller后，提示先选择场景 ，什么是场景？
说明：一个应用程序，有不同的操作功能且支持多用户同时应用，【模拟不同的用户进行不同的操作】，就是场景；(比如：机票网站，5个用户在进行注册业务，20个用户在进行订票操作，5个注册+20订票=场景）
三、Controller场景模式
模式：
1. Goal-Oriented Scenario(目标场景)【了解】
2. Manual Scenario(手工场景)【重点】
三、Goal-Oriented Scenario(目标场景)
说明：目标场景设计就是定义要实现的【测试目标】，LR会根据根据这些目标自动构建场景。
(测试目标：LR提供了5种目标-虚拟用户数、每秒单击次数、每秒事务数、每分钟页面数、事务响应时间) 提示：每秒单击次数、每分钟页面数只适合Web项目；
3.1 如何选择启动 目标场景
1) 创建目标场景
1. 启动Controller
2. Select Scenario Type:选择Goal-Oriented Scenario
3. 根据测试用例给目标场景添加相应业务(单一业务或混合业务),双击(Available)有效脚本，或选中点击Add ==>>按钮
注：
1). 单一业务：单个业务脚本
2). 混合业务：多个业务脚本【重点】
3.2 目标场景 计划与编辑
1) 启动编辑场景
1. 场景默认数据：为Controller默认创建目标场景时设计的数据
2. Edit Scenario Goal:编辑目标场景-修改目标场景数据
2）编辑场景
标注1：新建场景、修改现有场景名称、设置场景启动时间
1. Scenario Start Time:设计完场景后，场景启动时间；一般默认即可
1). Without delay：立即运行场景 （默认）
2). With a delay of HH:MM:SS:等待指定时间运行场景
3). At HH:MM:SS on Y/M/D：指定X年X月X日X时X分X秒运行场景
2. New:创建一个新的计划场景
标注2：设置目标场景的测试目标类型及目标范围【相对目标场景 重点】
Goal Type:本次性能测试的测试目标
标注3：场景运行时间及策略设计
说明：
1. 标示1(Run time)：场景达到目标后，继续运行多长时间；一般10-30分钟
2. 标示2(If target cannot be reached): 如果达不到设定目标时处理方式
1). Stop scenario and save results 停止并保存运行结果【推荐】
2). Continue Scenario without reaching 继续执行场景直到达到目标为止 【默认】
提示：以上选项如没有特殊业务需求，默认即可；
标注4：虚拟用户加载策略
1. Automatic:系统自动加载虚拟用户 【默认】
2. Reach target number of virtual users after 00:02:00 设定10分钟后达到指定的目标虚拟用户数
3. Step up by 20 virtual users every 00:02:00 表示以每2分钟加载20个虚拟用户的方式加载虚拟用户
提示：以上选项根据实际业务场景来选择和设定
3.3 目标场景5种 测试目标（每秒点击率&每秒事务数 在性能测试中用得比较多，直接体现服务器的负载能力）
1. Virtual users (虚拟用户)：测试应用程序（选定的脚本）是否可以同时运行指定数量的虚拟用户数；
2. Hits per Second(每秒点击率)：
-. Hits per Second目标：测试服务器每秒点击率(每秒点击数)(指定每秒点击数目标以及达到这一目标的最小用户数和最大用户数，如果最小用户数没有达到这个目标会自动加载用户)
-. 虚拟用户加载策略（Load Behavior）应选择 自动加载(Automatic)
-. Hits per Second只适合Web项目【注意】
3. Transactions per Second(每秒事务数)
-. Transactions per Second目标：测试服务器每秒事务数(指定事务) (指定每秒完成事务数目标以及达到这一目标的最小用户数和最大用户数)
-. 在VuGen必须插入相应事务
4. Transaction Response time(事务响应时间)
-. Transaction Response Time目标：测试在不超过预期事务响应时间(目标)的情况下可以运行多少个用户，必须指定预期时间、最少用户、最大用户 (例如：需求100个人使用支付软件付款，在3秒钟内完成；预期目标时间为3秒，最少用户80，最多用户180)
5. Pages per Minute(每分钟页面数)
-. Pages per Minute目标：测试服务器每分钟页面数 (指定每分钟完成页面数目标以及达到这一目标的最小用户数和最大用户数)
-. Pages per Minute只适合Web项目【注意】
提示：
1. 目标场景主要采用内在工具来最大限度完成测试目标，工具很智能，人更智能。
在实际工作场景中使用最多的还是手工场景；
2. 目标场景和手工场景都只是测试场景的搭建模式，场景的运行和监控都是一样；
四、Manual Scenario(手工场景)
4.1 为什么要学习手工场景？
说明：在手工场景模式内可以最大程度模拟业务场景(虚拟用户的增加、减少、虚拟用户对混合场景的应用)
4.2 手工场景的创建
1) 启动 选择手工场景
1. 启动：
1). 启动Controller工具
2). Select Scenario Type:Manual Scenario(手工场景)
2. 说明：
1). Use the Percentage Mode...选项：为(百分比模式)暂不用理会
2). 场景添加脚本参考-目标场景添加脚本
2) 手工场景界面
说明：
1. 标1：手工场景的基础计划(脚本名称为Group Name（一个组就是一个脚本，一个业务）、虚拟用户数量默认为10)；
2. 标2：标1基础计划的默认计划选项(计划方式：场景模式、运行模式：实际计划)
3. 标3：标1计划运行模式(虚拟用户初始化方式、虚拟用户启动加载方式、计划持续运行时间方式、计划完成用户退出方式)
4. 标4：标3计划运行策略直观图
4.3 案例示范（场景中的用户组都是同时进行的）
说明：
1. 我们知道场景搭建是模拟真实应用场景，而真实场景一般都为混合模式(多个业务)
2. 我们结合LR自带机票网站，模拟真实场景来学习混合场景的搭建场景：
1. 根据需求分析WebTours订票网站高峰期时25人访问，其中80%用户在使用订票业务，20%用户使用注册业务，统计事务响应时间
2. 混合场景=注册业务(5)+订票业务(20)需求：在Controller的场景中，运行完脚本以后查看事务时间
1. 登录业务时间小于5秒
2.订票业务小于10秒提示：
1. 注册业务：录制/手写注册脚本，脚本内记得插入注册事务
2. 订票业务：录制/手写注册脚本，脚本内记得插入订票事务难点分析：
1. 注册20个账户，使用20个新注册账户订票
2. 订票脚本依赖注册脚本（Schedule by：Group）
3. 注册脚本参数化 行的选择和更新值方式（Unique + Each iteration + Abort Vuser）（Abort Vuser ：当没有唯一行时处理方式，终止用户）
4. 购票脚本参数化，行的选择和更新值方式（Squential + Once）
1、案例1 需求操作
- 注册业务、订票业务脚本
-. 创建手工场景，添加（注册业务、订票业务）脚本
-. 修改脚本虚拟用户数(注册5、订票20)-计划设计
说明： 1. LR默认手工场景虚拟用户为10，我们需要修改虚拟用户数(注册20%、订票80%) 2. LR手工场景中默认把每个脚本作为一个用户组；
问题：虚拟用户数不能直接修改；解决：在编辑/创建计划内 更换运行模式：Basic schedule就可以直接编辑
编辑/创建计划：1. Schedule by-计划方式2. Run Mode-运行模式
a) Schedule by(计划方式)
说明：
1. Scenario(场景)：以场景计划为单位，Controller同时运行所有参与场景的Vuser组；(定义的场景运行计划同时会应用于所有Vuser组) 【常用】
2. Group(组)：以Vuser组为单位，参与场景计划的Vuser组，每个组都按其自己的单独计划运行； (每个Vuer组(脚本)都要设置单独的运行计划策略)
提示：
1. 计划方式一般情况下选择Scenario(场景)，这样面对混合场景时，计划运行策略只需要设置一次；
2. Group(组)：场景中如果存在业务依赖关系时，必须使用Group组，详情请看Group(组)应用图
依赖关系：两个业务脚本有先后执行之序； (假设模拟订票业务20并发，前提必须先注册20个用户(注册业务)执行20次，再使用新注册用户去订票)；
b) Run Mode-模式
说明：
1. Real-world schedule(实际计划)：场景根据模拟用户实际计划操作来运行【推荐】 (可以通过添加用户组的Action来改变组的虚拟用户策略)
2. Basic schedule(基本计划)：和实际计划相同，不同之处，基本计划只能设置虚拟用户在场景一次的启动和停止策略-. 设计全局计划运行策略
说明： 1. 计划运行策略是根据Schedule by(计划方式)与Run Mode-模式的组合而产生不同的策略 2. 全局计划策略、计划改变模式改变、都会影响计划图的改变
1) 全局计划 场景+真实计划(Scenario + Real-world schedule)
-. Initialize(虚拟用户初始化策略)
1.数字：
1). 1：Controller运行Vuser之前对所有Vuser同时进行初始化
2). 2：Controller在运行指定数目的Vuser之前，根据指定时间间隔对Vuser逐渐进行初始化
3). 3：Controller在每个Vuser开始运行之前对其进行初始化【推荐默认】
2. 提示：
1). Controller运行虚拟用户(线程)之前必须初始化
2). 一般采取默认，运行每个Vuser之前对其初始化
-. Start Vusers(虚拟用户启动策略) 【重点】
1. 说明：
1). 1:要启动的虚拟用户数；默认为场景内各个Vuser组的Vuser用户总和；
2). 2:同步启动1设定的虚拟用户数；
3). 3:逐渐运行1设定的虚拟用户数；默认15秒启动给个虚拟用户；【推荐】
-. Duration(持续运行) 【重点】
1. 说明：
1). Run until Completion：脚本执行一次，如果有迭代，那么执行到迭代次数完成
2). 2：当前场景运行指定时长 (注意：如果选择此项，那么脚本内如果设置有迭代次数，迭代次数设置将失去作用)
2. 提示：
1). 持续运行策略需要根据场景需求来选择，如：持续压测5分钟，就选第二条 2). 如果脚本有迭代次数，需要迭代完毕就停止场景的话，就选择第一条
-. Stop Vuser(虚拟用户停止策略)
1. 说明：
1). 1:停止的虚拟用户数，默认All(所有用户)，或指定用户数；
2). 2:同步停止1设定的用户数
3). 3:逐渐停止1设定的用户数，默认：30秒停止5个虚拟用户；
2) 全局计划 用户组+真实计划(Group + Real-world schedule)
1. 说明：
1). Start when group ...... finishes:指定某一用户组(脚本)执行完毕后，执行当前组(脚本)； (脚本有依赖关系时使用，比如：必须先注册在登录)
2). 其他选项参考(Scenario + Real-world schedule)说明
