超全汇总，性能测试常用指标大全（重要）_性能测试指标

---

前言

两种性能指标

业务指标；
技术指标；

通常我们会从两个层面定义性能场景的需求指标，它们有映射关系，技术指标不能脱离业务指标

1、并发

狭义：
指同一个时间点执行相同的操作（如：秒杀）
广义：
同一时间点，向服务器发起的请求（可能是不同的请求）
只要向服务器发起请求，那么服务器在这一时间点内都会收到请求（不管是不是同一个请求）

场景类比
高速公路上，同时有多少辆车经过同一个关卡，但不一定是同一个牌子的汽车

并发用户数（重点）

同一时间点，发出请求的用户数，一个用户可以发出多个请求；
场景不一定是同一个；
和 CPU、响应时间有关系；

和并发的关系
假设有 10 个用户数，每个用户同一时间点内发起 2 个请求，那么服务器收到的请求并发数就是 20。

性能测试场景1
不同身份的用户，访问不同的页面或发起不同的请求（广义的并发）；
观察 CPU 使用率和响应时间；

性能测试场景2
所有用户，同一个时间点发送同一个请求（狭义的并发）；
观察 CPU 使用率和响应时间；

系统用户数
系统累计注册用户数，不一定在线；
注册之后也可以一直不在线；
因为用户信息是存在数据库的，而数据库数据就是存在磁盘中，所以系统用户数和磁盘空间有关系；

性能测试场景
写一个脚本添加很多条用户信息插入到数据库；
目的：测试系统容量，方便了解系统的最大容量；
实际项目中，当系统容量接近最大容量时，系统需要进行容量扩容（加磁盘空间），否则就会爆掉；

在线用户数
在线用户可能是正常发起请求，也可能只是挂机啥操作都没有，不一定同时做某一件事情；
在线用户可能是游客（未注册的用户），也可能是系统用户（已注册的用户）；
在线用户数≠并发用户数；
和内存有关系

性能测试场景
使用 Jmeter 让不同的用户不断上线，且不下线和发起其他请求，看看内存使用情况；
实际场景：12306 以前很多用户在线，响应时间会拉的很长；

线程数
在 jmeter 中，线程数和并发用户数等价【和CPU、响应时间有关系】

2、事务

客户端向服务器发送请求，然后服务器做出响应的过程；
登录、注册、下单等功能都属于一个事务；
一个事务可能会发起多个请求；

jmeter 相关
jmerter 中，默认一个接口请求，就是一个事务；
但也支持多个接口整合成一个事务；

注意点
若一个业务或事务有多个接口，那么多个单接口的性能指标值相加 ≠ 业务或事务的性能指标值

3、响应时间

响应时间对于性能测试来说
从发起请求到收到请求响应的时间；
包含了：Request Time 和 Response Time；
等价于：发起请求网络传输时间 + 服务器处理时间 + 数据库系统处理时间 + 返回响应网络传输时间；

对用户所感知的响应时间包括
用户客户端渲染时间（多了这个）；
请求/响应数据网络传输时间；
应用服务器处理时间；
数据库系统处理时间；

重点
在做性能测试时，要尽可能的降低网络传输时间，这样最终得出的 RT 会无限接近服务器处理时间，所以我们要把网络环境搞好

事务请求响应时间
完成单个事务所用的时间，可能包含了多个请求

假如用户说应用很慢，要怎么分析？（仅供参考）
单个用户慢？还是多个用户慢？手上只有我们自己的应用慢？还是所有应用都这么慢？
网络问题的话，带宽是用哪家营业商？不同营业商是不是都卡？还是只有用户所在的营业商卡？
…等等等

响应时间多少合理？
标准是：2、5、8
2秒：很好
5秒：可以接受
8秒：不能接受

4、TPS（最主要的指标）

服务器每秒处理事务数，衡量服务器处理能力的最主要指标

知道 T 是如何定义的
在不同的行业、业务中，TPS 定义的颗粒度可能是不同的；
所以不管什么情况下，需要做性能测试的业务的相关方都要知道你的 T 是如何定义的 ；

定义 TPS 的粒度
一般会根据场景的目的来定义 TPS 的粒度；
接口层性能测试：T 可以定义为接口级；
业务级性能测试：T 可以定义为每个业务步骤和完整的业务流；

如果要单独测试接口 1、2、3，那么 T 就是接口级

如果从用户角度下订单，那 1、2、3 都在一个 T 中，就是业务级

结合实际业务设计，库存服务一定是同步，而积分服务可以是异步，所以这个下单业务，可以只看作由 1、2 这两个接口组成，但是 3 接口还是要监控分析的

所以，性能中 TPS 中 T 的定义取决于场景的目标和 T 的作用

接口级脚本
——事务 start（接口 1）
接口 1 脚本
——事务 end（接口 1）
——事务 start（接口 2）
接口 2 脚本
——事务 end（接口 2）
——事务 start（接口 3）
接口 3 脚本
——事务 end（接口 3）

业务级接口层脚本（就是用接口拼接出一个完整的业务流）
——事务 start（业务 A）
接口 1 脚本 - 接口 2（同步调用）
接口 1 脚本 - 接口 3（异步调用）
——事务 end（业务 A）

用户级脚本
——事务 start（业务 A）
点击 0 - 接口 1 脚本 - 接口 2（同步调用）
点击 0 - 接口 1 脚本 - 接口 3（异步调用）
——事务 end（业务 A）

一般情况下，我们会按从上到下的顺序一一来测试，这样路径清晰地执行，容易定位问题

5、QPS

每秒查询率，在数据库中每秒执行 SQL 数量
一个请求可能会执行多条 SQL
某些企业可能会用QPS代替TPS
也是衡量服务端处理能力的一个指标，但不建议使用

RPS
简单理解：每秒请求数，用户从客户端发起的请求数

深入挖掘：对于请求数来说，也要看是哪个层面的请求

如果一个用户点击了一次，发出来 3 个 HTTP Request，调用了 2 次订单服务，调用了 2 次库存服务，调用了 1 次积分服务

问：Request 数量如何计算
答：3+2+2+1 = 8？
不， 应该是 3，因为发出了 3 个 Request，而调用服务会有单独的描述，以便做性能统计

6、HPS

点击率，每秒点击数
可直接理解为用户在界面上的点击次数
一般在性能测试中，都用来描述 HTTP Request，那它代表每秒发送 HTTP 请求的数量，和 RPS 概念完全一样
HPS 越大对 Server 的压力越大

7、CPS/CPM
每秒/每分钟调用次数
通常用来描述 Service 层的单位时间内被其他服务调用的次数

TPS、QPS、RPS、HPS、CPS 的总结
有很多维度可以衡量一个系统的性能能力，但是如果把五个指标同时都拿来描述系统性能能力的话，未必太混乱了

可以这样做
用 TPS 来统一形容系统的性能能力，其他的都在各层面加上限制条件来描述。

比如说：接口调用 1000 Calls/s
在团队中要定义清楚术语的使用场景，还有含义

吞吐量（Throughput）
单位时间内，网络处理的请求数量（事务/s）
网络没有瓶颈时，吞吐量≈TPS

吞吐率
单位时间内，在网络传输的数据量的平均速率（kB/s）

资源利用率
服务器资源的使用程度，比如服务器（应用、服务器）的CPU利用率，内存利用率，磁盘利用率，网络带宽利用率
一般不超过80%

Think Time 思考时间
从业务角度看
它指的是用户进行操作时，每个请求之间的时间间隔
比如：加入购物车后，多久之后会点击下单？浏览一个商品多久会加入购物车

从性能测试角度看
为了模拟用户两次操作之间的时间间隔，才有 Think Time，更加真实的模拟用户的真实操作
它和用户行为有关系，所以应该分析的是用户行为而非用户数

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

只要你有梦想，就一定要去追求它。不要停下脚步，不要放弃努力，因为只有坚持不懈的奋斗，才能成就伟大的人生。让自己的每一天都充满热情和动力，向着目标勇往直前！

每一次的努力，都是为了成就更好的自己；每一天的拼搏，都是在追逐更美好的未来。没有放弃，就有希望；没有停留，就有可能。让我们积极向前，永不言败！

生活无需匆忙，但必须坚定前行；成功不是偶然，而是付出的结果；失败并不可怕，只要勇于再次尝试；每一天都是新的开始，让自己成为更好的版本。