这里，我们利用 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

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

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

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

步骤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：客户端排队的时间