wordpress网站重新安装,网页设计素材景区结束,企业专业网站建设的必要性,网络和网站的区别5、录制并增强虚拟用户脚本
从整体角度看#xff0c;用LoadRunner 开发虚拟用户脚本主要包括下面四步骤#xff1a;
识别测试应用使用的协议
录制脚本
完善录制得到的脚本
验证脚本的正确性
识别被测应用使用的协议
如果明确知道了被测系统所采用的协议#xff0c;可…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()。这个关联函数支持多种动态值的获取方式用得最多的是基于“前序字符串匹配”加上“后续字符串匹配”的方式。其中字符串匹配支持正则表达式。
看个具体的例子:
假设服务器端返回的结果是
“LBnametimestamp value8888.LBnameCheckSum”
那么为了能够获取到“8888”这个动态值我们就可以用“前序字符串 LBnametimestamp value”和“后续字符 .LBnameCheckSum”来“框出” 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 展示事务平均响应时间的界面我们可以看到图片右下角各个事务的最小响应时间、最大响应时间和平均响应时间。 文章来源网络 版权归原作者所有
上文内容不用于商业目的如涉及知识产权问题请权利人联系小编我们将立即处理
