LoadRunner——LR的六大组件小结（十二）

{LR的六大组件小结}

一、第一大组件VuGen: 虚拟用户脚本生成器

1）根据相关协议、业务流程录制脚本-模拟自动化功能

如果有UI，通过浏览器或App界面进行录制生成脚本；

如果有UI，无法正常录制生成脚本，或没有UI，只有后台接口，

需要自己根据代码规范和协议写脚本，

或者借助抓包工具获取请求和响应包生成脚本。

相关协议：选择合适的协议

B/S架构，常用Web[HTTP/HTML]协议

App也可以选择：Mobie App(HTTP/HTML)协议 (WinPcap_4_1_3.exe)

2）业务需求：流程->用例中体现

3）常用设置

<1> IE浏览器： Internet选项

常规设置每次访问此页时检查

程序重置Web设置

高级去除启用第三方浏览器扩展

<2> 当前建议关闭本地连接，提高工具效率

实际项目中不能关闭，客户端需要通过网络访问服务器

<3> 关闭一些冲突的服务：java oracle 杀毒进程...

<4> 使用脚本视图，设置界面字体、回放后自动弹出测试结果

<5> 录制选项：

录制方式-默认采用基于HTML方式

必要时采用基于URL方式，比如采用https协议设置自动页面标题检查点，辅助检查

设置录制使用的字符集：UTF-8 和当前项目一致

使用默认方式录制后脚本中文出现乱码问题

<6> 采用架构：B/S或C/S

<7> 采用协议：Web[HTTP/HTML]

<8> 指定浏览器产品：IE

<9> URL地址：http://localhost/web/guest/home

<10> 录制位置：vuser_init Action vuser_end

<2> 设置Run-time Settings，模拟1VU回放

模拟运行轨迹、频率，发现脚本本身的问题

<3> 增强脚本：为性能测试提供帮助

事务：平均事务响应时间、TPS、并发的起点

lr_start_transaction("事务名");

请求、步骤的代码...

lr_end_transaction("事务名", LR_AUTO);

检查点：自动为响应内容进行检查文本为主

性能测试要建立在功能实现的基础上，如果测试过程中

功能出现业务问题，一定会影响性能测试结果。

web_reg_find("Text=页面源代码文本", LAST);

reg函数注册性函数相应请求之前

技巧：Tree视图生成

集合点：

适合场景：并发测试，关注大用户量并发：所有人同时发请求

形成相对严格的并发。

函数：lr_rendezvous("集合点名称");

位置：在事务之前

集合策略：

参数化：业务数据多变、更真实类型+数据+策略

SE UEA RE等组合

关联：让脚本适应服务器端动态数据的变化,关联函数

流程控制：分支、循环

函数调用：复用已有的功能

二、第二大组件Controller: 压力调度控制台

设置场景Scenario: 表示测试计划

<1> 场景类型：手工，取消使用百分比模式分配用户，比较灵活。(推荐）

目标，按照既定目标去创建场景

添加脚本到场景中（browser）。

<2> 脚本组：组名、脚本路径、VU数量、Load Generator的选择（联机测试）；

<3> VU的行为：初始化、加载方式、持续时间、退出方式

<4> Run-time Settings: 迭代次数、Pacing迭代间隔、Think time步骤间隔、Log日志、其他（错误处理-错误时是否继续、线程方式模拟VU）、浏览器模拟（是否启用缓存-降低压力可以启用，促进数据测试成功率）、网络带宽、超时时间 600s

<5> 日志管理：指定输出位置、设置输出详细级别

<6> Monitor系统资源监控：CPU、Memory、Disk、Network、System等重要资源情况

<7>Load generator负载生成器(加压机)：生成更多用户来测试，配置、连接、添加

<8>Agent 代理程序，需要启动，相当于通讯兵。

<9>ip欺骗，设置静态ip，ip设置：A\B\C类，启用ip欺骗以及验证

{常见的性能测试策略小结}

1）基准测试：单用户、单测试点、循环执行n次

2）并发测试：多用户、单测试点、瞬时压力，属于压力测试一个子集

3）压力测试：在超出范围后，考验系统最大承受点。使劲折腾

4）负载测试：在范围之内，检验系统能否承受指定的指标。见好就收

5）综合场景测试：多用户、多测试点、在线持续一段时间

（混合交易测试），较为真实模拟用户实际环境

6）递增测试：进行逐步加压，用户的加载方式

7）疲劳强度测试：压力更大、时间更长的综合场景测试

8）数据容量测试：模拟海量数据重新考量之前的性能

三、第三大组件分析器Analysis

【功能】收集场景运行后的各项测试结果，生成数据图表供分析，通过分析来定位性能瓶颈，最后形成性能测试报告。

说明：后续任务是性能调优，一般由测试经理、架构师参与。

【设置】

1、运行场景的测试结果收集方式设置：

在controller中，results->auto collate results默认是被选中的

（场景运行后，自动整理合并结果）

2、运行场景的测试结果存放路径设置：

在controller中，results->results setting

a.每执行一次场景都生成一份结果文件，结果文件的命名方式为res后接一个序号（如res0），每执行一次序号依次加1；

b.每执行一次场景，将执行后的结果覆盖以前的结果。（为了防止意外发生，一般会选择第一种结果保存方式）。

3、分析器收集测试结果设置：

在Analysis中，Tools->options->Result Collection

data source：数据来源

A. 表示仅生成摘要数据

B. 表示仅生成经过处理的完整数据

C. 表示在生成处理过的完整数据时，显示摘要数据。

data aggregation：数据聚合

a.表示使用内置数据聚合公式聚合数据，以优化性能

b.表示使用内置数据聚合公式仅仅聚合与web相关的数据

c.表示用户自定义来设置聚合数据，如右图所示：

aggregate data (available only for complete data)：用于设置聚合数据的类型，这里只适用于完整数据，可以选择需要聚合数据的图的类型，这样可以减小数据库的容量。

A. 选择聚合的数据类型

B. 选择聚合的图属性。

web data aggregation only：表示仅聚合web的数据，在这里可以设置聚合的粒度。

4、测量分析图设置

选中分析图，View->configure measurements

1、给测量更换颜色

2、选择显示比例(可以调整大小)

a.手动设置一个比例值； b.使用优化的自动比例来显示图中每个度量；

c.将图中所有度量比例都设置为1； d.查看所有度量的趋势。

默认值为1，即按原始比例进行显示，有时波形显示的幅值太小，就需要适当地调整放大比例。

5、设置筛选条件

在录制测试脚本过程中，如果执行脚本时没有忽略think time时间，那么analysis分析器在统计分析结果时会把think time包含进去，这样当think time存在于用户事务的开始与结束之间时，相关事务统计情况会受到影响。因此，很多时候需要过滤用户的思考时间，在下拉框中删除include think time选项即可，分析结果中就会自动滤掉思考时间。