5、录制并增强虚拟用户脚本
从整体角度看，用 LoadRunner 开发虚拟用户脚本主要包括下面四步骤：
识别测试应用使用的协议
录制脚本
完善录制得到的脚本
验证脚本的正确性
识别被测应用使用的协议
如果明确知道了被测系统所采用的协议，可以跳过这一步。如果还不知道可以使用 Virtual User Generator 模块自带的 Protocol Advisor 识别被测应用使用的协议，具体的操作方法：
在 Virtual User Generator 中依次点击 File、Protocol、AdvisorAnalyze、Application，展开这些菜单
在打开的界面上按要求填写被测应用的信息
Protocol Advisor 会自动运行被测系统。如果是网页应用，就会打开浏览器
在页面上执行典型业务操作，完成业务操作后点击 “Stop Analyzing” 按钮停止录制
Protocol Advisor 会根据刚才录制的内容自动分析被测应用使用的协议，并给出最终的建议
接下来，就可以使用 Protocol Advisor 建议的录制协议开始脚本录制工作了。如图就是 Protocol Advisor 给出的建议录制协议界面。
1）录制脚本
基本原理是，通过 GUI 界面对被测系统进行业务操作，Virtual User Generator 模块在后台捕获 GUI 操作所触发的客户端与服务器端的所有交互，并生产基于 C 语言的虚拟用户脚本文件。
即录制脚本的过程需要通过 GUI 实际执行业务操作，所以在开始录制脚本前，可以先多次演练需要这些 GUI 操作步骤，并明确知道哪些操作步骤会对服务器端发起请求。
要知道哪些操作步骤会对服务器发起请求的原因是，要将这些操作步骤在虚拟用户脚本中封装成“事务”（Transaction）。封装为“事务”的目的是统计响应时间，因为 LoadRunner 中的响应时间都是以“事务”为单位的。
具体的录制步骤包括下面三步：
选择 Create/Edit Scripts 进入 Virtual User Generator 创建脚本的协议选择界面。
选择正确的协议后进入 Start Recording 界面，选择需要录制的应用类型，填写应用的详细信息。如果是 Web 应用，Application type 就应该选择Internet Application，然后选择浏览器并填写这个 Web 应用的 URL，完成后自动打开浏览器。
在该浏览器中执行业务操作，Virtual User Generator 模块会记录所有的业务操作，并生成脚本。
由于 LoadRunner 脚本的可读性并不好，在录制完的脚本中添加事务定义的难度大。所以在录制脚本的过程中，最好直接对发起后端调用的操作添加事务定义，而不要脚本生成后添加。
在录制过程中，直接添加事务操作也很简单，主要包括如下三步：
在开始执行 GUI 操作前，点击下图的“事务开始”并填写事务名称
执行 GUI 操作
操作完成后，点击下图的“事务结束”
这样刚才执行 GUI 操作的脚本就会被 lr_start_transaction(“事务名称”) 和 lr_end_transaction(“事务名称”，LR_AUTO) 包围起来，也就完成了添加事务的定义。
2）完善录制得到的脚本
Virtual User Generator 模块录制的脚本不能直接使用，我们还需要对录制的脚本做以下处理：
两个事务之间加入思考时间（Think Time）
对界面输入的数据参数化（Parameterization）操作
完成脚本的关联（Correlation）操作
加入检查点（Check Point）
这 4 步处理操作是虚拟用户脚本开发中最关键的地方，不仅需要知道为什么要进行这些处理，更要能够完成这些处理，否则录制的脚本无法成功回放。
第一，在两个事务之间加入思考时间
思考时间是用户在实际使用系统时，并不会连续不断地向后端服务器发起请求，在两次发起请求之间往往会有一个时间的间隔，这个时间间隔主要来自于两个方面：
用户操作的人为等待时间，因为用户不可能像机器人那样快速地执行操作
用户可能需要先在页面上填写很多信息后之后，才能提交操作，那么填写这些信息就需要花费一定的时间
为了让虚拟用户脚本能够更真实地模拟实际用户的行为，就需要在两个事务之间加入一定的等待时间。即 LoadRunner 中的思考时间。
只需直接调用 LoadRunner 提供的 lr_think_time() 函数，就可以在两个事务之间加入思考时间。但是，这个思考时间到底设置为多少，并没有那么容易知道。思考时间往往会涉及多方面的因素，严格计算的话会非常复杂。
在实际项目中，可先粗略估计一个值（比如 15 s），然后在实际执行负载场景的过程中，再根据系统吞吐量调整。
后续调整思考时间时，无需逐行修改虚拟用户脚本代码，可以在 Run-time Settings（运行时设置）中很方便地完成。如图，Run-time Settings 中支持多种方式调整思考时间。
第二，对界面输入的数据做参数化操作
假设，录制的虚拟用户脚本完成的是用户登录操作，那么由于脚本回放时需要支持多用户的并发，所以必须要把脚本中的用户名和密码独立出来，放入专门的数据文件中，然后在这个文件中提供所有可能被用到的用户名和密码。
以下是参数化配置的界面截图，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 官方文档
3）验证脚本的正确性
可以以下顺序检查脚本的准确性：
以单用户的方式，在有思考时间的情况下执行脚本，确保脚本能够顺利执行，并且验证脚本行为以及执行结果是否正确；
以单用户的方式，在思考时间为零的情况下执行脚本，确保脚本能够顺利执行，并且验证脚本行为以及执行结果是否正确；
以并发用户的方式，在有思考时间的情况下执行脚本，确保脚本能够顺利执行，并且验证脚本行为以及执行结果是否正确；
以并发用户的方式，在思考时间为零的情况下执行脚本，确保脚本能够顺利执行，并且验证脚本行为以及执行结果是否正确；
上述四个测试全部通过，就可以拿到虚拟用户脚本。
6、创建并定义性能测试场景
就是在 LoadRunner Controller 中设置性能测试场景。目的是要描述性能测试过程中所有与测试负载以及监控相关的内容。通常来讲，性能测试场景设计主要会涉及以下部分：
并发用户数是多少；
测试刚开始时，以什么样的速率来添加并发用户？比如，每秒增加 5 个并发用户；
达到最大并发用户数后持续多长时间；
测试结束时，以什么样的速率来减少并发用户？比如，每秒减少 5 个并发用户；
需要包含哪些业务操作，各个业务操作的占比是多少？比如，10% 的用户在做登录操作，70% 的用户在做查询操作，其他 20% 的用户在做订单操作；
一轮虚拟用户脚本执行结束后，需要等待多长时间开始下一次执行；
同一虚拟用户脚本中，各个操作之间的等待时间是多少；
需要监控哪些被测服务器的哪些指标；
脚本出错时的处理方式是什么？比如，错误率达到 10% 时，自动停止该脚本；
需要使用多少台压力产生器；
7、执行性能测试场景
一般是在 LoadRunner Controller 中完成。你可以通过 Controller 发起测试、停止测试、调整性能测试场景的各种参数，还可以监控测试的执行过程
8、分析测试报告
执行完性能测试后，LoadRunner 会根据自己的标准并结合性能测试场景中定义的系统监控器指标，生成完整的测试报告。在 Analysis 中，不仅可以以图形化的方式显示单个指标，也可以将多个指标关联在一起进行比较分析。
下图展示了使用 LoadRunner Analysis 展示事务平均响应时间的界面，我们可以看到图片右下角各个事务的最小响应时间、最大响应时间和平均响应时间。
文章来源：网络 版权归原作者所有
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系小编，我们将立即处