1. 性能测试概述

性能测试的好坏最终都需要通过数据来展示，通过性能指标对应的数据来判定性能的好坏。

2. 常见的性能指标

并发用户数、响应时间、事务响应时间&每秒事务通过数、点击率、吞吐量、资源利用率
TPS：每秒系统处理事务数
QPS：每秒系统查询请求数
RPS：每秒系统HTTP请求数

1. 并发用户数

并发用户会对系统造成压力。

业务层面的并发用户数：指的是同时向服务器发送请求的用户数量。

后端服务器层面的并发用户数：指的是同时向服务器发送请求的请求数量。

（并不是只要发出请求，服务器就一定会造成压力）

并发强调大量用户和同时性的操作时，才会对服务器造成压力。

2. 响应时间

响应时间分为前端展示时间和系统响应时间两部分。

前端展示时间指的是客户端收到服务器返回的数据渲染前端页面，所耗费的时间。

系统的响应时间，分为 web服务器，应用服务器，数据库服务器等各种服务器之间通信和处理请求的时间。

3. 事务响应时间& 每秒事务通过数（TPS）

比如：使用电子支付操作时，可能后台处理需要经过账务系统，支持系统，银行系统等，这就是一个关于电子支付事务中包含的操作。

对于用户来说，一般只是关注整个支付花费了多长时间。而这一整个事务的过程就叫事务的响应时间。

每秒事务通过数，通常指的是每秒成功完成的事务数，这是衡量系统处理能力的重要指标。

每秒事务通过数越高，性能越好（这个是相对的，不同的系统要求不同，有些事务比较复杂）

4. 点击率

每秒点击数代表用户向服务器提交的请求数，点击率越大，服务器的压力越大。

注意：这里的点击并不是鼠标的一次点击，一次点击可能有多个请求。

5. 吞吐量

单位时间内系统处理的客户请求数量，直接体现软件系统的性能承受能力。

吞吐量受服务器性能和网络性能的影响。单位： bytes/s

6. 资源利用率

不同系统资源的使用情况，包含 CPU、内存、硬盘、网络等。

3. 性能测试的分类

一般性能测试、负载测试、压力测试、稳定性测试

1. 一般性能测试

正常情况下和系统条件下是否满足性能指标。

2. 负载测试

验证系统在一定压力下延长系统的运行时间，直到系统出现 “拐点”

3. 压力测试

验证系统在已经处于极限负载下或者某指标已经处于饱和状态下性能的表现。

（一定要把系统搞到奔溃，从而了解系统的承受极限）

4. 稳定性测试

验证系统在连续运行情况下，查看系统的各项性能指标。

（看是否有 内存泄露）

4. loadRunner 工具的介绍

性能指标对应的数据如何计算出来，就需要使用性能测试工具。

这里具体的安装可以看这篇博客，写的很详细

(259条消息) LoadRunner安装教程（和中文版安装）_阿英-fu的博客-CSDN博客

安装好后，就有了这三个软件了。

1. Virtual User Generator （VUG）：主要用来生成性能测试脚本。
2. Controller：创建和设计测试场景，运行测试脚本，监控场景运行，收集测试过程的数据。
3. Analysis：分析性能测试结果，出测试报告和各种图表。

5. 使用 VUG

创建一个新的性能测试脚本

4.1 打开 LR 自带的 web 系统

1. 启动 webTours 服务：

2. 启动成功后，别关闭命令框，在浏览器中访问 http://127.0.0.1:1080/WebTours/

3. 查看 WebTours 系统登录账号：

Web Tours 默认提供的账号在：

这个默认账号提供的密码是：bean

4.2 编写性能测试脚本

1. 打开 WebTours 提供的函数工具库

Action()
{
// 1. 访问 http://127.0.0.1:1080/WebTours/ 首页
// 2. 输入登录的账号和密码  
	web_url("index",
		"URL=http://127.0.0.1:1080/WebTours/",
		"TargetFrame=",
		"Resource=0",
		"Referer=",
		LAST);
	web_submit_form("login",
		ITEMDATA,
		"Name=username", "Value=jojo", ENDITEM,
		"Name=password", "Value=bean", ENDITEM,
		LAST);
	return 0;
}

运行脚本

这种是最简单的性能测试脚本的写法，但是这种写法不足以让我们进行性能测试数据的收集。必须是在并发情况下，也就是大量用户同时进行的操作。

6. 性能测试脚本的增强

6.1 事务（lr_start/end_transaction）

开启事务：lr_start_transaction
结束事务：lr_end_transaction

运行程序后

6.2 集合点（lr_rendzvous）

假如后续我们创建 10W 个虚拟用户去执行编写好的性能测试脚本，不能保证所有的虚拟用户都同时的去执行每一步操作，为了能够真正意义上的实现并发，让虚拟用户执行到集合点的地方短暂的集合，在满足条件后一起执行下一个步骤。

6.3 检查点（web_reg_find）

注意：检查点必须放在请求之前

这个会提示在页面查找到 “jojo” 的文本，以及对应的查找次数。

6.4 参数化

给参数取个变量名

设置都传什么参数

6.5 日志设置

设置日志，最后按 ctrl+s 保存

Number or iterations ：修改 action 脚本执行的次数，不会影响 init 和 end 脚本。

7. 脚本录制

使用录制功能可以自动的生成性能测试脚本

注意必须使用 IE浏览器，如果使用别的浏览器（Edge），即使录制了也不会生成代码，action 文件内容始终为空的

8. Controller 工具的使用

可以直接打开 Controller 软件，

也可以针对我们已经编写好的脚本来打开 controller 工具，创建测试场景。

点击 OK 就会自动打开 Controller 软件

1. 在脚本运行之前初始化虚拟用户的策略

2. 开始虚拟用户的运行

3. 虚拟用户运行的时间

4. 结束虚拟用户

运行场景

如果想要查看在性能测试执行期间，系统资源消耗的情况，那么需要打开相关的系统设置，来允许 LR 获取对应的数据。

9. Analysis 工具的使用

当运行完 Controller 工具后，会自动打开 Analysis 工具，生成性能测试报告并进行结果分析。

1. 性能测试报告

2. 测试报表

（1）运行的虚拟用户图：Running vusers

根据显示的运行虚拟用户数量可以判断出在哪个时间段内给服务器的负载

（2）点击率图（每秒点击数）：Hits per Second

通过点击率也可以判断出某段时间内服务器的负载

（3）吞吐量图：Throughput

吞吐量图形和点击率图形有点形似，但是吞吐量图曲线稍微之后一点，因为吞吐量表示的是响应返回响应的资源数量，肯定是先有请求再有返回。

如果请求变多但是吞吐量没啥变化，可能是因为

• 服务器响应慢了，来不及响应。
• 压力没有到服务器。
• 服务器设计一定的阈值，超过多少个请求之后就不返回响应。

（4）事务图：Transaction Summary

（5）平均事务响应时间图：Average Trans…esponse Time

在这个图中分析出，虚拟用户在性能测试过程中，每秒在服务器上命中的次数，可以帮助根据命中次数评估虚拟用户生成的负载量。

如果想要查看更多的图表，右键添加即可。

1. precessor Time

   CPU 使用时间，被消耗的处理器时间数量

2. Available MBytes

   可用的物理内存，一般根据这个指标推算消耗的物理内存有多大

   已经消耗的物理内存 = 实际内存 - 可用的物理内存。