LoadRunner 的基本原理
后端性能测试工具通过虚拟用户脚本生成器生成基于协议的虚拟用户脚本，然后根据性能测试场景设计的要求，通过压力控制器控制协调各个压力产生器以并发的方式执行虚拟用户脚本，并且在测试执行过程中，通过系统监控器手机各种性能指标以及系统资源占用率，最后通过测试结果分析器展示结果数据。
在 LoadRunner 中，Virtual UserGenerator 对应的是虚拟用户脚本生成器，Controller 对应的是压力控制器和系统监控器，Load Generator 对应的就是压力产生器，Analysis 对应的是测试结果分析器。
以下我们把 LoadRunner 每个模块类比手工操作放大理解工作过程：
首先，我们需要一批测试机器，每台测试机器雇佣一个测试人员；
然后，一个调度员来统一控制，比如 “1-10 号测试人员开始执行登录操作，10-20 号测试人员 5 分钟之后执行搜索操作”，同时调度员还会要求每个测试人员记录操作花费的时间；
测试完成后，调度员会要求性能工程师分析测试中记录的数据。
通过类比：
· 测试调度员以及完成数据记录的部分就是 Controller
· 大量的测试机器以及操作这些机器的人就是 Load Generator
· 操作这些机器的人的行为就是 Virtual User Generator 产生的虚拟用户脚本
· 对测试数据的分析就是 Analysis 模块
LoadRunner 的主要模块
Virtual User Generator
用于生成模拟用户行为的测试脚本，生成的手段主要是基于协议的录制，也就是由性能测试脚本开发人员在通过 GUI 执行业务操作的同时，录制客户端和服务器之间的通信协议，并最终转化为代码化的 LoadRunner 的虚拟用户脚本。
这样转化得到的虚拟脚本还需要经历数据参数化（Parameterization）、关联建立（Correlation），以及运行时设置（Run Time Settings）等操作，然后才能用于性能测试场景中。
LoadRunner Controller
Controller 相当于性能测试执行的控制管理中心，负责控制 Load Generator 产生测试负载，以执行预先设定好的性能测试场景；同时，还负责收集各类监控数据。
在实际执行性能测试时，Controller 是和性能工程师打交道最多的模块，性能工程师会在 Controller 的 UI 界面上完成性能测试场景的设计、运行时的实时监控、测试负载的开始与结束等操作。
LoadRunner Analysis
Analysis 是 LoadRUnner 中一个清大的分析插件。不仅能图形化展示测试过程中收集的数据，还能对国歌指标做关联分析，找出他们的因果关系。它最根本的目的就是：分析出系统可能的性能瓶颈点以及潜在的性能问题。
如何基于 LoadRunner 性能测试
从宏观角度讲可以分为五个阶段：
· 性能需求收集及负载计划制定
· 录制并增强虚拟用户脚本
· 创建并定义性能测试场景
· 执行性能测试场景
· 分析测试报告
我觉得在性能测试中获取这些测试需求和测试结果分析与性能问题定位是比较难得两个点。而类似于性能测试脚本开发、场景设计等偏向于机械性地重复工作。
这 5 个阶段先后顺序及各个模块作用：
性能需求收集及负载计划制定
其实无论什么类型测试，第一步都要根据测试目的明确测试具体需求。常需要包括以下内容：
系统整体的并发用户数比如，高峰时段会有 10 万用户同时在线。
并发用户业务操作的分布情况比如，20%的用户做登录操作，30%用户做订单操作，其他50%用户做搜索。
单一业务操作的用户行为模式比如，两个操作之间的典型停留时间，完成统一业务的不同操作路径等。
并发用户高峰期的时间分布规律比如，早上8点有大量用户登录，晚上 6 点后用户主键退出。
达到最高峰负载的时间长度比如，并发用户从0到10万花费的总时间。
等等~~
前面说获取测试需求是比较难做的，因为绝大多数情况下没人会明确告诉你具体的性能需求。好比功能测试，如果需求不明确可以求助产品经理。而性能测试产品通常无法准确告诉各个业务所占的百分比，也无法说出准确的用户行为模型。往往只能获取一些定性描述，然后自己去计算或根据过往经验得到具体定量需求。
测试目的不同，采用方法也不同，如何获取明确性能需求？这里提供测试需求的思考方式：
在性能测试指标中提到的体检例子，比如产品经理对体检的性能要求是“每天支持完成 8000 个体检”，这个需求看似具体，但还可以细化在很多方面。
首先，要明确这里的“每天”是否指的是 24 小时这取决于产品本身的属性。比如，产品是为单一时区的用户提供服务，还是要面向全球所有时区的用户。那么，根据体检中心的属性，可以确定“每天”一定是指 8 小时的工作时间。因为，体检中心是在一个确定的时区，并且不会 24 小时营业。
然后，你明确了这个 8 小时后，那么原始需求是不是可以转化为“每小时支持完成 1000 个体检”？**若照这个套路设计后续的性能测试，会发现即使测试顺利完成，且各项性能指标都达标，可一旦上线后，系统还是很有可能被压垮。因为实际情况是，验血往往需要空腹，所以上午往往是体检中心的高峰时段，体检者会在上午集中涌入体检中心。也就是说，这 8000 个体检并不是平均分布在 8 小时内完成的，而是有明显的高峰时段。
最后，你可以采用 80/20 原则对高峰时段的用户负载进行建模比如 80% 的体检（6400 个）是发生在上午 20% 的时间（96 分钟）里。为了使模型更接近真实的情况，还应该分析历史数据，然后对该模型做进一步的修正。
另外，在得到了负载模型后，往往还会在此基础上加入一定的负载冗余，比如在峰值的基础上再额外放大 20%，以增强系统上线后稳定运行的信心。
录制并增强虚拟用户脚本
从整体角度看，用 LoadRunner 开发虚拟用户脚本主要包括下面四步骤：
· 识别测试应用使用的协议
· 录制脚本
· 完善录制得到的脚本
· 验证脚本的正确性
识别被测应用使用的协议
如果明确知道了被测系统所采用的协议，可以跳过这一步。如果还不知道可以使用 Virtual User Generator 模块自带的 Protocol Advisor 识别被测应用使用的协议，具体的操作方法：
1.在 Virtual User Generator 中依次点击 File、Protocol、AdvisorAnalyze、Application，展开这些菜单。
2.在打开的界面上按要求填写被测应用的信息。
3.Protocol Advisor 会自动运行被测系统。如果是网页应用，就会打开浏览器。
4.在页面上执行典型业务操作，完成业务操作后点击 “Stop Analyzing” 按钮停止录制。
5.Protocol Advisor 会根据刚才录制的内容自动分析被测应用使用的协议，并给出最终的建议。
接下来，就可以使用 Protocol Advisor 建议的录制协议开始脚本录制工作了。如图就是 Protocol Advisor 给出的建议录制协议界面。
录制脚本
基本原理是，通过 GUI 界面对被测系统进行业务操作，Virtual User Generator 模块在后台捕获 GUI 操作所触发的客户端与服务器端的所有交互，并生产基于 C 语言的虚拟用户脚本文件。
即录制脚本的过程需要通过 GUI 实际执行业务操作，所以在开始录制脚本前，可以先多次演练需要这些 GUI 操作步骤，并明确知道哪些操作步骤会对服务器端发起请求。
要知道哪些操作步骤会对服务器发起请求的原因是，要将这些操作步骤在虚拟用户脚本中封装成“事务”（Transaction）。封装为“事务”的目的是统计响应时间，因为 LoadRunner 中的响应时间都是以“事务”为单位的。
具体的录制步骤包括下面三步：
1.选择 Create/Edit Scripts 进入 Virtual User Generator 创建脚本的协议选择界面。
2.选择正确的协议后进入 Start Recording 界面，选择需要录制的应用类型，填写应用的详细信息。如果是 Web 应用，Application type 就应该选择 Internet Application，然后选择浏览器并填写这个 Web 应用的 URL，完成后自动打开浏览器。
3.在该浏览器中执行业务操作，Virtual User Generator 模块会记录所有的业务操作，并生成脚本。
由于 LoadRunner 脚本的可读性并不好，在录制完的脚本中添加事务定义的难度大。所以在录制脚本的过程中，最好直接对发起后端调用的操作添加事务定义，而不要脚本生成后添加。
在录制过程中，直接添加事务操作也很简单，主要包括如下三步：
1.在开始执行 GUI 操作前，点击下图的“事务开始”并填写事务名称。
2.执行 GUI 操作。
3.操作完成后，点击下图的“事务结束”。
这样刚才执行 GUI 操作的脚本就会被 lr_start_transaction(“事务名称”) 和 lr_end_transaction(“事务名称”，LR_AUTO) 包围起来，也就完成了添加事务的定义。
完善录制得到的脚本
Virtual User Generator 模块录制的脚本不能直接使用，我们还需要对录制的脚本做以下处理：
· 两个事务之间加入思考时间（Think Time）
· 对界面输入的数据参数化（Parameterization）操作
· 完成脚本的关联（Correlation）操作
· 加入检查点（Check Point）
这 4 步处理操作是虚拟用户脚本开发中最关键的地方，不仅需要知道为什么要进行这些处理，更要能够完成这些处理，否则录制的脚本无法成功回放。
第一，在两个事务之间加入思考时间
思考时间是用户在实际使用系统时，并不会连续不断地向后端服务器发起请求，在两次发起请求之间往往会有一个时间的间隔，这个时间间隔主要来自于两个方面：
· 用户操作的人为等待时间，因为用户不可能像机器人那样快速地执行操作。
· 用户可能需要先在页面上填写很多信息后之后，才能提交操作，那么填写这些信息就需要花费一定的时间。
为了让虚拟用户脚本能够更真实地模拟实际用户的行为，就需要在两个事务之间加入一定的等待时间。即 LoadRunner 中的思考时间。
只需直接调用 LoadRunner 提供的 lr_think_time() 函数，就可以在两个事务之间加入思考时间。但是，这个思考时间到底设置为多少，并没有那么容易知道。思考时间往往会涉及多方面的因素，严格计算的话会非常复杂。
在实际项目中，可先粗略估计一个值（比如 15 s），然后在实际执行负载场景的过程中，再根据系统吞吐量调整。
后续调整思考时间时，无需逐行修改虚拟用户脚本代码，可以在 Run-time Settings（运行时设置）中很方便地完成。如图，Run-time Settings 中支持多种方式调整思考时间。
· As recorded，代表的是直接使用 lr_think_time() 函数中指定的时间。
· Mutiply recorded think time by，代表的是在 lr_think_time() 函数中指定的时间基础上乘以一个数字。比如这个数字是 2，那么所有的思考时间都会翻倍。
· Use random percentage of recorded think time，指的是使用指定思考时间范围内的随机值。例如，如果 lr_think_time() 函数中指定的时间是 2 s，并且指定最小值为 50%，最大值为 200%，则实际的思考时间会取最小值 1 s（2 s50%）和最大值 4 s（2 s200%）之间的随机值。
· Limit think time to，指的是为思考时间设置一个上限值，只要 lr_think_time() 函数中指定的时间没有超过这个上限值，就按照 lr_think_time() 函数指定的值，如果超过了就取这个上限值作为思考时间。
第二，对界面输入的数据做参数化操作
假设，录制的虚拟用户脚本完成的是用户登录操作，那么由于脚本回放时需要支持多用户的并发，所以必须要把脚本中的用户名和密码独立出来，放入专门的数据文件中，然后在这个文件中提供所有可能被用到的用户名和密码。
以下是参数化配置的界面截图，LoadRunner 支持的参数化的数据源很丰富，既可以是 excel 文件，也可以是数据库中的表等。
凡参数文件中使用的测试数据，都需要在执行性能测试前在被测系统中准备好。以用户登录的脚本为例，假定你的参数文件中提供了 5000 个用于并发执行的用户信息，那么这 5000 个用户必须是已经实际存在于系统中的，这就要求你要在开始测试前事先准备好这 5000 个用户。
所以，参数化操作其实由两部分组成：
· 性能测试脚本和测试数据的分离。
· 事先建立性能测试的数据。
第三，完成脚本的关联操作
关联操作直接关系到脚本是否可以回放成功。主要作用是取出前序调用返回结果中的某些动态值，传递给后续的调用。
举个例子：
假设，每次客户端连接服务器端时，服务器端都会用当前的时间戳（Time Stamp）计算 CheckSum，然后将 Time Stamp 和 CheckSum 返回给客户端。然后，客户端就把 Time Stamp + CheckSum 的组合作为唯一标识客户端的 Session ID。录制脚本时，录制得到的一定是硬编码（hardcode）的 Time Stamp 值和 CheckSum 值。
下图是交互过程，录制得到 Time Stamp 的值是 TS，而 CheckSum 的值是 CS。
采用 Time Stamp + CheckSum 的组合作为 Session ID 的方式，在回放这个脚本的时候就有问题了。因为回放时，这段硬编码已经有了新的 Time Stamp 值和 CheckSum 值，并且显然与之前的值不同，所以服务器无法完成 Session ID 的验证，也就导致了脚本回放失败。
解决方法就是，在脚本回放的过程中，实时抓取 Time Stamp 值和 CheckSum 值，然后用实时抓取到的值替换后续需要使用这两个值的地方。这个过程就是“关联”
如下图，关联就是解析服务器端的返回结果，抓取新的 Time Stamp 值和 CheckSum 值，然后后续的操作都使用新抓取的值，这样脚本就能回放成功了。
理解了关联操作，在脚本中处理关联就比较简单了，LoadRunner 提供了功能强大的关联函数 web_reg_save_param()。这个关联函数支持多种动态值的获取方式，用得最多的是基于“前序字符串匹配”加上“后续字符串匹配”的方式。其中，字符串匹配，支持正则表达式。
看个具体的例子:
假设，服务器端返回的结果是“LB=name=timestamp value=8888.LB=name=CheckSum”，那么为了能够获取到“8888”这个动态值，我们就可以用“前序字符串 =LB=name=timestamp value=”和“后续字符 =.LB=name=CheckSum”来“框出” 8888”这个动态值。
另外，需要特别注意的是 web_reg_save_param() 函数是注册型函数，必须放在获取动态值所属的请求前面，相当于先声明，后调用。更多的关联函数用法，你可以参考 LoadRunner 官方文档
第四，加入检查点
检查点，类似于功能测试中的断言。但是，性能测试脚本，不像功能测试脚本那样需要加入很多的断言，往往只在一些关键步骤后加入很少量的检查点即可。这些检查点的主要作用是，保证脚本按照原本设计的路径执行。
最常用的检查点函数是 web_reg_find()，作用是通过指定左右边界的方式“在页面中查找相应的内容”。这里需要注意的是，这个函数也是注册型函数，即需要放在所检查的页面之前，否则会检查失败。更多的检查点函数以及用法也可参考 LoadRunner 官方文档。
验证脚本的正确性
可以以下顺序检查脚本的准确性：
1.以单用户的方式，在有思考时间的情况下执行脚本，确保脚本能够顺利执行，并且验证脚本行为以及执行结果是否正确。
2.以单用户的方式，在思考时间为零的情况下执行脚本，确保脚本能够顺利执行，并且验证脚本行为以及执行结果是否正确。
3.以并发用户的方式，在有思考时间的情况下执行脚本，确保脚本能够顺利执行，并且验证脚本行为以及执行结果是否正确。
4.以并发用户的方式，在思考时间为零的情况下执行脚本，确保脚本能够顺利执行，并且验证脚本行为以及执行结果是否正确。
上述四个测试全部通过，就可以拿到虚拟用户脚本。
创建并定义性能测试场景
就是在 LoadRunner Controller 中设置性能测试场景。目的是要描述性能测试过程中所有与测试负载以及监控相关的内容。通常来讲，性能测试场景设计主要会涉及以下部分：
· 并发用户数是多少。
· 测试刚开始时，以什么样的速率来添加并发用户？比如，每秒增加 5 个并发用户。
· 达到最大并发用户数后持续多长时间。
· 测试结束时，以什么样的速率来减少并发用户？比如，每秒减少 5 个并发用户。
· 需要包含哪些业务操作，各个业务操作的占比是多少？比如，10% 的用户在做登录操作，70% 的用户在做查询操作，其他 20% 的用户在做订单操作。
· 一轮虚拟用户脚本执行结束后，需要等待多长时间开始下一次执行。
· 同一虚拟用户脚本中，各个操作之间的等待时间是多少。
· 需要监控哪些被测服务器的哪些指标。
· 脚本出错时的处理方式是什么？比如，错误率达到 10% 时，自动停止该脚本。
· 需要使用多少台压力产生器。
执行性能测试场景
一般是在 LoadRunner Controller 中完成。你可以通过 Controller 发起测试、停止测试、调整性能测试场景的各种参数，还可以监控测试的执行过程。
分析测试报告
执行完性能测试后，LoadRunner 会根据自己的标准并结合性能测试场景中定义的系统监控器指标，生成完整的测试报告。在 Analysis 中，不仅可以以图形化的方式显示单个指标，也可以将多个指标关联在一起进行比较分析。
下图展示了使用 LoadRunner Analysis 展示事务平均响应时间的界面，我们可以看到图片右下角各个事务的最小响应时间、最大响应时间和平均响应时间。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
