LoadRunner 压测场景制定以及报告分析

这里，我们利用 LoadRunner 来制定场景，且以测试 tps 值为导向，主要介绍手工场景

　　单服务器的业务请求处理能力 tps 值在 10~200 是合理的；如果是访问单接口不走关系型数据库的，访问的是 redis （内存里面读）那么 tps 在 1000~2000 左右是合理的

　　单负载机的最大并发多少？不管是 LR 和 JMeter，10~4000 是合理的

如果要测试响应时间或者是说并发，是要有前提条件的：比如说并发为 100 的响应时间为 XX，响应时间为 1 s 支持的最大并发量为 XX。所以说 tps 值是一个最普遍的值，1s 处理的事务数。

前提：准备好没问题的脚本以及数据，负载机等

进入压测场景的方式有两种，这里，我们示范两种方式的进入手工设定场景
1、直接进入 Run Load Tests

2、从脚本显示页进入

Controller-Scenario

性能测试有三个场景需要测试：单场景，混合场景，稳定性测试场景

Design

Scenario Groups 基本设置

　　这一部分主要的功能是选择进行压测的脚本

  1. Group Name　　## 脚本名称
  2. Script Path　　## 脚本路径
  3. Quantity　　## 最大 Vu 数
  4. Load Generators　　## 脚本压测选择的负载机

如果我们这里只选择一个脚本，那么就是单场景压测，如果需要跑混合场景，那么就得增加 Group

修改页面如下：Group Name不重要，可以手动修改，执行的是 Script Path 内的脚本

如果我们选择 1 个以上的脚本进行并发，那么就是混合场景：

修改脚本的 Quantity

Quatity这里比较特殊，不能直接修改，我们需要选中脚本，点击 "Virtual Users" ，再去选择添加的虚拟户数

并且可以针对每个 Vu ，选择不同的负载机

分布式负载设置

那么，怎么添加负载机，做分布式负载呢？（两种方式）

添加好负载机还得将脚本连接好负载机：

　　负载机不需要安装完整的 LoadRunner，只需要安装 LoadRunner 的 Generator 模块，并且正在运行

连接好负载机后，如果负载机在 Windows 上，会有个小云朵的图标，代表连接上了该负载机

压测内修改脚本以及更新 Run-time Settngs

并且可以修改 RunTime-Setting / Scripts：修改完脚本或者 RunTime-Setting 需要点击 "Refresh"，选择更新脚本或者是 setting

这样第一部分的 Senario Group 就基本设置完成。

Scenario Schedule

A.   定义方案schedule

在 Scenario Schedule面板中,选择一个方案schedule,或通过点击New Schedule定义一个新的方案

 

group：多个脚本之间按照独立设置模式跑，各个脚本可以单独设置虚拟用户、运行时间等
scenario：多个脚本之间按照相同的模式跑，将总的虚拟用户数按照一定的比例分配给各个脚本

定义schedule:

  • 新建schedule：点击新建按钮(可选)
  • 重命名schedule:在 Schedule Name 输入新的名字并点击Save New Name(可选).
  • 选择schedule类型,Schedule by: Scenario 或 Group.
  • 选择运行模式Run mode: Real-world 或Basic

说明:

　　1．对所有schedule默认的运行模式都是Real-word.你可以改变缺省模式为Basic。Tools > Options > Execution tab

2. Schedule by Scenario和Group的区别

Real-world Schedule和Basic schedule的区别：根据官方文档，这两种模式下，场景中的每个虚拟用户组(可看成是每个脚本)都会按照它们自己的Run-Time settings中的设置运行。区别在于可模拟的操作不一样：

Schedule by:Scenario

Basic Schedule：可以定义每次运行多少用户，场景持续运行多久

Real-world Schedule:同Basic schedule，除此之外，还可以设置每次停止多少个用户。

 

Schedule by:Group(该设置在百分比模式下不可见)

Basic schedule：可以定义什么时候开始运行虚拟用户组(Group和Scenario的主要区别)，每次运行多少个虚拟用户，场景持续运行多久

Real-world Schedule:同Basic Schedule，除此之外，还可以设置每次停止多少个虚拟用户。

 

双击Group Schedule下的Start Group Action，打开Start Group策略，设置脚本在手工场景下的Group模式中如何开始运行

B.   为schedule定义action(Global schedule)

Actions表格展示了默认的与步骤2选择的shedule对应的actions。

 

Schedule Actions.

一个场景schedule包含了一系列actions，指导场景什么时候运行Vuser group，怎么初始化虚拟用户，合适开始和停止虚拟用户，及运行一个action要花的时间。

 

注意:脚本中带集合点会妨碍场景方案的运行。如果有包含集合点，场景可能不会按照你设定的方案运行。

说明：

1)   Start Group

　　定义何时开始运行Vuser Group

1、Start immediately after the scenario begins(缺省)

　　LoadRunner在场景一运行就开始运行Vuser Group

2、Start <00:00:00> (HH:MM:SS) after the scenario begins

　　场景运行后，LoadRunner等待指定的时间后开始运行Vuser group.

3、Start when group finishes

　　指定Vuser group运行完成后，LoadRunner马上开始运行该Vuser group.

注意:Start Group仅在group schedule类型中可用，而且总是作为第一个action出现.

2)   Initialize

　　指导LoadRunner准备Vusers，以便于他们处于准备运行状态.

1、Initialize all Vusers simultaneously

　　在LoadRunner在运行vuser前初始化所有Vusers.

注意：选择该设置可能会导致运行出错：error-27796 failed to connect to server

2、Initialize XX Vusers every <00:00:00> (HH:MM:SS)

　　LoadRunner在运行vuser前，根据指定的时间间隔，逐渐初始指定数量的Vuser,

3、Initialize each Vuser just before it runs(Default)

　　LoadRunner在运行它们前初始化每一个Vuser

注意：当Wait for all groups to initialize选项被选中时，必须等所有的Vuser group完成对虚拟用户的初始化后才运行

该选项对于group scenario不可用

 

3)   Start Vusers

指示loadRunner开始运行Vusers。

1、Start XX Vusers: Simultaneously(Default)

　　指定LoadRunner运行场景的虚拟用户总数

2、Start XX Vusers: YY Vusers every <00:00:00> (HH:MM:SS)

　　LoadRunner按指定的时间间隔，逐步运行指定数量XX个Vusers，也就是说LoadRunner运行指定数量的一组Vusers,并且等待指定时间后运行指定下一组Vuser.

3、点击Previous 或Next可切换其它要编辑的action.

 

注意:

1.当且仅当Vuser处于Ready状态时，LoadRunner才开始运行Vuser.

2.Basic运行模式下默认运行所有用户

 

4)   Duration

持续时间

Real-world schedule

Basic schedule

1、Run until completion

　　按Controller中Run-time settings -> logic中的迭代次数进行迭代，迭代完成则停止运行。

2、Run for x days and xx:xx:xx

　　忽略Run-time settings -> logic中设置的迭代次数，重复迭代运行脚本的action，直到时间结束为止， 也就是说，此处设置的持续时间的优先级高，

也就是说：

  1. 即使你指定了迭代次数，但是运行时间没有结束之前，还是会一直迭代，所以实际迭代次数可能大于你设置的迭代次数；
  2. 还有一种情况是，迭代次数还没完，但是运行时间已经到了，此时会将当前执行的Action执行完，停止迭代，此种情况下实际迭代次数小于你设置的迭代次数。

3、Run indefinitely

　　无限运行

C.   从Actions表格中添加一个action到schedule

步骤1：打开添加Action对话框

方法1、在指定action后插入一个action，选择这个action并点击Add Action After

loadrunner <wbr>场景设计-手工场景方案(Schedule)设计 <wbr>Part <wbr>1

 

方法2、在最后一个action后添加一个action，在Action表格中双击最后一行

loadrunner <wbr>场景设计-手工场景方案(Schedule)设计 <wbr>Part <wbr>1

步骤2：在Add Action对话框中，定义新的action

loadrunner <wbr>场景设计-手工场景方案(Schedule)设计 <wbr>Part <wbr>1

注意：这里的Start Vuser数量的设置，会改变上方的组或脚本的虚拟用户数量Quatity

loadrunner <wbr>场景设计-手工场景方案(Schedule)设计 <wbr>Part <wbr>1

 

步骤3：点击Apply.

 

步骤4：继续添加另一个action，点击Add Another Action并重复步骤2，3

 

Schedule by：Scenario

　　如果是测试 tps ，Start Vu 和 Stop Vu直接选 "Simultaneously" 即可，因为测试 tps 是先看 1 个 Vu，是多少；2 个 Vu，是多少……等到 tps 上升值很小，就可以考虑用热启动方式去验证一下，顺便截图写报告

 1、Initialize

　　初始化：把用户的进程或者是线程准备好，但是并不运行

　　我们这里可以极端点，直接选第一个

2、Start Vuers——设置启动用户

　　这里可以设置 Vu ，指的是这个压测场景所有的用户，比如说我们设置 100，上面的也会被更改掉

　　如果选择 "Simultaneously"，代表所有的 Vu 同时启动，效果如图示（冷启动）

　　如果 Vu 太多，建议还是这种方式直接起来，时间太宝贵，等？谁等？

 

　　我们也可以选择让 Vu 阶段性上升，同时设置其上升的时间，比如说，每 3 min 增加 5 个 Vu ，效果如图（热启动）

3、Duration——持续时间

　　很容易理解，就是指到达最大 Vu ，继续保持的时间多长，我们如果测试 tps ，这里设置 10~15 min就行

4、Stop Vusers

　　和 Start Vuers 一样，代表关闭的线程/Vu，这里直接 Simultaneously 就好了，直接退

Schedule by：Group

　　Group 模式，我们加进一个其他脚本，我们发现 Group 相对于 Scenario 多了一个：Start Group

　　这个代表可以多场景分组运行

例如，我们让两个场景排顺序进行：

而且，Group 模式下，每个脚本的 Vu 是可以自己设定的：

Global-Oriented Scenario——面向目标的场景设计

不同的是，面向目标的负载机需要手动添加，即使是本机的

重点说下下面的区别：

 我们进入 "Edit Scenario Global" 看看，可以看到目标分为五种

目标可以分为五种

  1. VUser
  2. pages per minute
  3. transaction per second
  4. hits per second
  5. trasaction response time

Virtual Users Goal:

　　如果需要测试多少人可以同时运行Web应用，那么推荐定义Virtual Users Goal. 运行定义该目标类型的场景和运行Manual 类型的场景类似。

Hits per Second:

　　如果想测试Web Server的真正实力，推荐定义目标类型为：Hits per Second,Pages per Minute 或者Transactions per Second,这些类型都需要制定一个虚拟用户的最大值和最小值的范围

Transactions Response Time

　　如果想知道在多少用户并发访问网站时，事务的响应时间达到性能指标说明书中规定响应时间的最大值，那么推荐使用Transactions Response Time类型，指定需要测试的事务的名称，虚拟用户数量的最大值和最小值，还有预先定义好的事务的响应时间。

我们这里主要看俩：Transaction Per Second & Transactions Response Time

这里，我们用 tps 为例，解释下参数，但是目标为 tps 很少

目标为响应时间支持的用户数，是我们的一个指标。比如我们设置响应时间为 2 s，用户数在 1~150 之间进行尝试，尝试时间为 30 min

Run

 Scenario Groups

这里的状态指的是各 Vu 的状态，Vu 其实对应的就是负载机的进程/线程

Vu 状态：

  • Down:没有运行
  • Pending:挂起
  • Init:初始化
  • Ready:准备就绪
  • Run:正在运行
  • Rendezvous:正在集结
  • Passed:运行通过
  • Failed:运行失败
  • Error:出现故障
  • Gradual Exting:逐一退出
  • Exiting:退出
  • Stopped:停止运行

场景控制：

  • Star Scenario:运行场景
  • Stop:强制停止运行场景
  • Rest:将所有选项恢复到默认值
  • Vuses:管理虚拟用户
  • Run/Stop/ Vuses:启动和停止部分虚拟用户

场景状态：

  • Runing Vuses:正在运行的用户数
  • Elapsed Time:场景已经运行的时间
  • Hits/second:每秒钟点击数
  • Passed Transactions:通过的事务数（总事务）
  • Failed Transactions:未通过的事务数
  • Errors:出现的错误数（失败率不能大于 1%，视公司标准而定。只能将服务器的错误计算进去，不能将负载机的错误计算进去）

注意：Failed Transactions指的是由于事务本身没有缺陷，但由于并发数较多等原因没有连通，而Errors是指事务运行期间产生的缺陷，一般比较严重

接下来是几个视图：常用的视图如下

  1. Runtime Graphs(运行时图表)： 显示运行的虚拟用户、运行时发生的错误、用户自定义数据点信息。
  2. Transaction Graphs(交易情况图表): 显示交易响应时间以及每秒成功交易的数量、百分比等。
  3. Web Resource Graphse(网络资源情况图表): 显示每少点击量、吞吐量、每少连接数量等。
  4. System Resource Graphs(系统资源情况图表)：显示Windows、UNIX等不同系统的资源情况等。
  5. Network Graphs(网络情况图表)：显示网络延迟信息。
  6. Firewalls(防火墙情况图表)： 目前只支持某品牌防火墙信息，一般场景基本不会用到。
  7. Web server Resource Graphs(网络服务器情况图表): 显示多种网站服务器的性能信息，如apache.
  8. Web application server Graphs(网络应用服务器情况图表)：显示多种应用服务器的性能信息，如Weblogic。
  9. Databases server resource graphs(数据库情况图表): 显示4种主流数据库的性能信息，如DB2、Oracle、SQLServr等，不支持mysql。
  10. Streaming Media（流媒体情况图表）：显示windows media server和Real server以及相应客户端的性能信息。
  11. 其他类型图表:中间件、CRM/ERP等。

问题：不光是出现了脚本内的事务，还出现了两个无关事务。

解决：把定义每个 action 为事务的选项取消勾选

这里要注意，标准方差不要太大，稳定的话，取这里的平均值就好，如果标准方差 > 8 的话，就看 Analysis 视图内的 90% percent 的响应时间

tps 的 max ，min，Std 都为 NA？这个是正常的，只统计 avg 和 last

Analysis

打开方式：

Summary Report

还可以加 Graph，例如我们加一个 tps 的

Merge：

LoadRunner 的分析页面，图标是可以合并的，假设我们把 RT 和 Vu 表进行合并，就可以知道在哪个用户节点对应的 RT 是多少，更直观地分析性能拐点

操作：

结果：

另外可以截取时间段的结果视图：

对分析有帮助的：

Web Page Diagnostics 模块，但是我这里不知道为啥没有显示

但是我是打开了该功能的：

这玩意的有一个试图叫：Page Download Time Breakdown 是用来分析，我们的时间是花在哪儿了

有以下几个玩意：

DNS Resolution Time ：DNS 的解析时间，一般在毫秒级

Connection Time：客户端与服务器进行 tcp/ip 连接所花费的时间，这个长有可能是 tcp/ip 连接数满了，或者说是网络慢

SSL Handshake Time ：SSL 建立安全协议的时间，一般在毫秒级

FTP时间

First Buffer Time：服务器处理这个请求以及开始发送第一帧数据的时间，可以理解为服务器的真正业务处理的时间

Receive Time：服务器向客户端发送数据，接收所花费的时间

Client Time：客户端排队的时间

 一、启用网页细分图
首先在Controller场景设计运行之前，需要在菜单栏中设置Diagnostics->Configuration->-->Web PageDiagnostics中置为Enabled,即该项前打对钩。如果不选中，则场景跑完后，分析结果中网页细分图没有数据。如图：

场景运行完后，会分析结果，在HP LoadRunner Analysis 中点击Graph -->Add NewGraph 打开一个新曲线图，open a new Graph ;首先将该曲线图中的右上角的Display only graphscontaining data不选中，然后点击Web Page Diagnostics前的+号，选中Web PageDiagnostics，点击曲线图下方的按钮Open Graph即可以将网页细分图调出。

二、网页细分图介绍

Web Page Diagnostics （以下简称WPD），这是LR Analysis中非常重要的一块，搞清楚这部分的内容会让你少走很多弯路，很多环境问题都可以通过它来定位，比如客户端，网络。通过它可以你可以比较好的来定位是环境的问题还是应用本身的问题，当然更重要的是Web页面本身的问题。

Web Page Diagnostics：页面诊断图，也叫页面分解总图

“页面分解”显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。

此视图下面的文件结构大体上与scripts中actions/transaction/web_url(or submit_form_request)等一系列客户端请求 这三层体系结构类似。
 
Transactions是组成Web Page Diagnostics视图最基本的单元。用户可以通过右键选中Transaction，然后进入Web Page Diagnostics for Transaction界面，对此事务下面的页面进行分析。在这里有二点需要说明：
1） 如果Transaction结构多于一个层次，比如Action/Load_home_page,则用户只允许进入到子级目录Load_home_page，即使用户选中Action系统也会自动跳转到下级目录。
2） 对于事务下面的页面请求，LR提供的操作是Break down, 也可以进行View page in Browser.
 

Web Page Diagnostics视图可以按下面四种方式进行进一步细分：

  • Download Time Breaddown（下载时间细分）
  • Component Breakdown(Over Time)（组件细分(随时间变化)）
  • Download Time Breakdown(Over Time)（下载时间细分(随时间变化)）
  • Time to First Buffer Breakdown(Over Time)（第一次缓冲时间细分(随时间变化)）

下面分别说下网页细分图各图表的功能：

网页细分图，总共有8个图表，分别为：

  1. 页面分解图总（web page Diagnostics）、
  2. 页面组件细分图（page comporment breakdown）、
  3. 页面组件细分图（随时间变化）（page comportment breakdown over time）、
  4. 页面下载时间细分图（page download time breakdown）、
  5. 页面下载时间细分图（随时间变化）（page download time breakdown over time）、
  6. 第一次缓冲时间细分图（time to first buffer breakdown）、
  7. 第一次缓冲时间细分图（随时间变化）（time to first buffer breaddown over time）、
  8. 已下载组件大小图（Downloaded Component Size）[KB]。

Web Page Diagnostics总图以transaction分析为主，兼顾页面的初步分析。

1、 页面组件细分图（page comporment breakdown）：显示每个网页及其组件的平均下载时间（以秒为单位），查看所选择页面中哪个元素所占的平均下载时间最长。

2、 页面组件细分图（随时间变化）（page comportment breakdown over time）：此图适合在客户端下载组件较多时的页面分析，通过分析下载时间发现哪些组件不稳定或比较耗时，它是随整个场景运行的时间来变化的。

3、 页面下载时间细分图（page download time breakdown）：页面下载时间细分图根据DNS解析时间、连接时间、第一次缓冲时间、SSL握手时间、接收时间、FTP验证时间、客户端时间和错误时间对每个组件进行分析的。它可以确认在网页下载时期，响应时间缓慢是由网络错误引起，还是由服务器错误引起。

4、页面下载时间细分图（随时间变化）（page download time breakdown over time）：显示选定网页下载时间细分，从中能看到页面各个元素在压力测试过程中的下载情况。如果某个页面打开速度慢，通过对此图分析，可以清楚地看到打开该页面的时间主要在什么地方，针对此问题进行优化。

5、 第一次缓冲时间细分图（time to first buffer breakdown）：指成功收到从web服务器返回的第一次缓冲之前的这一段时间内，每个页面组件的相关服务器和网络时间（以秒为单位）；

      此图对分析页面的时间很重要，不仅能分析出哪个页面耗费时间较长，而且能分析出之所以耗时是网络问题还是服务器问题。若server time明显大于net work time,并且是其几倍，此时服务器性能是问题关键。

       First Buffer Time时间分割为Network Time和Server Time。其中，网络时间（network time）为从客户端发送第一个HTTP请求那一刻直到收到服务端的应答报文（ACK）确认为止所经过的平均时间。服务器时间（server time）是指客户端从收到初始HTTP请求确认直到成功收到来自web服务器的第一次缓冲为止所经过的平均时间。  （后面详细介绍网络时间和服务器时间）

6、 第一次缓冲时间细分图（随时间变化）（time to first buffer breaddown over time）：不同页面在任一时间点的Network TIme 和Server Timef分布曲线图；第一次缓冲时间是在客户端与服务器建立连接后，从服务器发送第一个数据包开始计时，数据经过网络传送到客户端后，再到浏览器收到第一个缓冲数据所用的时间。（图中，用两种颜色来区分服务器和网络各自所用的时间，以确认是服务器问题还是网络问题，此图非常有用！）

7、已下载组件大小图（Downloaded Component Size）[KB]：页面中每个元素的大小（KB）

三、页面细分图分析

这里只对页面细分图进一步分析的思路进行梳理，有些图只是拿来参考，并不需要进一步分析的。

1、 首先打开页面分解总图（Web Page Diagnostics），在左边Breakdown Tree下，列出了脚本中添加的所有事务名称，通常来说，我们主要关注需要并发的系统业务部分，来看login部分，下载时间（Download Time）中，主要由两个页面导致，其中Receive部分占用的时间最长。（Component部分不在这里看，因为在这里看不够直观）

2、接着打开页面组件细分图（Page Component Breakdown），找出所选择页面中哪个元素所占的平均下载时间较多，其实就上面的两个，只不过这里是用饼图来展示比较直观。

3、 然后打开页面下载时间细分图（page Download Time Breakdown），根据DNS解析时间、连接时间、第一次缓冲时间、SSL握手时间、接收时间、FTP验证时间、客户端时间和错误时间的组成在所选择的页面上的分布情况，确定这个页面下载时间较长的响应时间是由网络错误引起，还是服务器错误引起的，如图1，Receive Time时间最长，初始判断是网络问题引起的，但也有可能是浏览器请求的问题，再看页面下载细分随时间分布图2，在整个login场景中该页面元素一直在下载？这极有可能是网络问题了。另外一点，若页面缓存做得好，是不会一直下载的吧。

很多时候，你可以根据DNS,Connection,Receive来看出是否存在网络问题，根据Client来判断是否存在客户端问题。

图1

图2

4、 最后打开一个非常重要的图，即第一次缓冲时间细分图（Time to First Buffer Breakdown），第一次缓冲时间细分图进行对比结果是否一致，因为第一次缓冲时间细分图也是可以确定该页面的响应时间是由网络错误引起，还是服务器错误引起。由此图，可以看到，大部分的时间在Network Time。

注意;当网络状况不好的时候，server time很可能包括网络时间，因为很多页面元素比较小（小于4k的样子），在First Buffer就完成传输，所以一定要注意分析。

【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/xiaowenshu/p/10354868.html