转载声明：文章来源https://blog.csdn.net/weixin_43431593/article/details/121939314

一、入门知识

1、先抛出个问题：需求文档中，有一个性能测试需求，你怎么入手？

（1）怀疑需求，通常提需求的人是产品经理，假设他不懂性能测试，那么这个需求很可能就是拍脑袋；

（2）确认需求，通常需要根据实际数据来分析，这些数据通常是运维的数据，得找他们拿，来判断产品需求的准确性；

（3）掌握概念，通常需要根据实际数据分析出具体要测试的对象，当然，前提是掌握性能测试概念，并通过概念去明确测试点；

（4）脚本设计，通常需要先分析用户的行为，并设计一个符合用户使用的场景，这些信息都是通过运维数据展现出来的；

（5）搭建环境，环境包括代码运行环境、指标监控环境，且必须是一个独立的环境；

（6）性能分析，首先是执行测试，过程中遇到的问题需要分析调优。

2、性能概念

（1）IT中的性能概念，最明显的感受是响应时间，稳定性，同时支持多少人使用

（2）那么性能是什么？

性能是用不同的角度，来衡量被测对象，给出一些数据，并通过这个数据判断性能好坏。

（3）如何连接服务器？

接口采用协议，传递数据到我们的服务器，收到响应

（4）性能测试是什么？

他是通过工具，找出或获得系统不同情况下的性能指标值

（5）为什么要通过工具？

服务器端性能测试，是要用多用户发起请求，通过工具才能更好地实现多用户请求（模拟）

（6）常用工具

jmeter(线程)、loadrunner(线程或进程)、ngrinder(进程+线程)、locust(协程)

（7）找出或获得什么？

第一次做性能测试，得到数据，找出性能数据（如用户数据）

不是第一次性能测试，获取新的性能测试数据（如模块的请求数据）

（8）数据

从不同的角度衡量服务器的性能数据

时间：平均响应时间数据

同一时间有多少并发用户数请求：并发用户数数据

服务器每秒能处理多少个事物：TPS数据

服务器在一段时间中，资源使用情况：资源利用率数据

网络：吞吐量、吞吐率

总之，性能测试完成，得到一批性能指标数据

二、常见问题

1、对用户的理解

（1）多少在线用户：在线，但是不请求；在线，同时有请求

行业中，一般用在线用户的5%-10%作为并发用户数；而二八法则（80%的请求发生在20%的时间里，可粗略估算并发量）来自于前端性能测试，调用前端接口请求服务器，如loadrunner的录制脚本，但一般不采用这种方式；

（2）多少在线使用用户：在线，同时有请求

2、如果没有互踢机制，一个用户请求100次和100个用户请求一次有区别么？

有。影响因素可能有2个，一是身份信息，二是用户锁。

3、并发和并行的区别

并发指的是同一个时间点有多少个请求，而并行指的是同时在做（可以是不同线程处理，即不同通道）

三、性能测试相关概念

1、负载测试

通过逐步增加并发用户数，来找出我们最大并发用户数区间

常用于第一次性能测试的时候，找出的用户数据；因为这个时候并不知道系统的最大支持多少并发用户数；然后可通过工具来模拟这些数据，来进行性能测试，再继续找出新的性能测试数据，如性能指标值

怎么判断是最大并发用户数区间？

（1）、看请求的结果是否有连续性的报错出现，错误<=0.1%；

（2）、平均响应时间（在当前并发用户数时的平均响应时间）不超过1.5秒（行业对接口的默认标准，而且仅限于http的后端接口，可理解为用户满意、用户能接受的响应时间）；并发用户数指的是在一段时间发多少请求，与频率有关系；总的请求数=并发用户数*频率*时间

（3）、tps（服务器每秒处理的事物数）趋势，有明显下降 （用区间下沿与区间上沿在设计一个负载场景，如可能之前用步长10找到的去区间20到30的时候有明显下降（表示为[10，100，10]），这个时候可以设计负载场景的步长为1，这样在某个值出现明显下降后，则可确认具体值为前一个，表示为[20，30，1]）

上述三者任意一个出现，则找出了最大可接受的并发用户数.

一般而言，你们的产品如果日均访问量大概在百万级别，实际的接口并发可能只是几十到小几百的并发用户数。

负载测试中，每一段并发用户数，持续运行时间，一般只要几十秒到几分钟就可以了。

2、压力测试

使用一定量的并发用户数（产品最大可接受的并发用户数，为20%、80%的用户数都是可以的），持续运行一段时间（一般以小时为单位，以前以天为单位），看服务器稳定性

那么稳定性测试与压力测试有什么区别？稳定性测试其实是压力测试的一种，它的一个子集。压力测试可选多种百分比情况来测试，而稳定性测试选择一种即可（如直接指定80%）。

现在压力测试时间，一般用小时为单位。

3、性能测试

广义的性能测试，是包括我们性能的所有概念。

（1）性能测试前提

核心系统或核心功能增加

某接口的用户使用量变多

架构调整

重大缺陷修复

涉及生命财产

业务剧增

性能指标量化

产品出现需求，不一定专业

需求性能指标一定要量化为数字

多少并发用户数、

平均响应时间多少以内、

错误率多少以内、

资源利用率多少以内、

tps要达到多少

（2）性能测试要求

需要独立性能测试环境、独立性能测试网络（交换机分开）、要掌握环境搭建

（3）性能测试时间

使用的并发用户数，来做性能测试，只需要执行几分钟到小几十分钟

4、容量测试

数据库的数量级别，在数据表数据量在万级 十万级 百万级区别很大，因为数据库有索引关系。性能测试的时候，性能测试环境用的数据库表的数量级别，最好与生产数据量级别保持一致或更高。

5、稳定性测试

详见“2、压力测试”

6、压测

企业中说，要你做一个压测，其实指的是负载测试、性能测试和压力测试。

首先，你知道用多少并发用户数么？ --负载测试

然后，最大可接受的并发用户数做性能测试 -- 性能测试

但是，如果领导说环境有宕机情况，需要你去做一个压测，看是什么问题。（这种情况压测就是负载测试、性能测试和压力测试）

四、性能指标

1、相关概念小结与扩展

（1）并发：后端性能测试中，多用户并发，发起方是多个用户一起做某件事情

它的源动力是并发用户（人）

（2）并行：同时处理什么事情（服务器）我们可以同时处理多个接口请求

（3）并发用户：人 做性能测试的源动力， 后端服务器的性能测试。都是要使用多个并发用户同时发起某个请求

Jmeter中，就是用 线程数 来模拟 并发用户数

在线用户数：在线，但是不发起请求； 在线，同时发起请求。

所以，在线用户数，不能直接当作并发用户数。行业中，大概在线用户的5%-10% 作为 并发用户数

系统用户数：

注册用户，有可能此时登录在系统中，也有可能，注册了之后，再也不使用；

匿名访问，也是有一个唯一身份信息；

而我们性能测试中，并发用户数，是需要通过负载测试来找出最大并发用户数区间，然后缩小这个区间，找到最大并发用户数。

（4）事务

可以是一个接口请求1次， jemeter中，默认1个接口完成1次请求，当做1个事务

也可以是多个接口请求，完成一个业务或一个功能。事务控制器，就可以把多个接口合并成1个接口，统计响应时间

jmeter中的事务，可以是1个接口的1次请求，也可以是多个接口合并在一起的请求。

举例： 下单接口进行性能测试，用100个并发用户数

登录接口 + 下单接口 == 如果设计场景 100个并发用户数，这个时候我们服务器收到100个并发用户数发起的登录接口请求和100个并发用户数发起的下单接口请求，这样不符合我们的需求，可以采用这个场景设计：100个并发用户数==得到100个用户身份（登录接口只需要登录100次即可，即在登录接口上面，挂一个 仅一次控制器，就会使每个并发用户不管运行多长时间都只会运行1次，每一百个用户必须使用100个账号来得到100个身份信息，jmeter里可能需要100个变量来接收这个身份信息来避免覆盖）

2、性能指标

（1）响应时间 一个非常重要的指标

从发起请求，经过网络传输到被测服务器，服务器内部处理，经过网络传输给发起方，整个过程所消耗的时间。

这个里面。没有包括前端（用户端）处理时间

我们真实期望的响应时间 = 服务器内部处理时间，所以，我们应该无限减少网络时间

怎么减少？尽可能使用局域网（网络拓扑图尽量简单，请使用有线网络，必须是公司企业级的网络）

测试脚本，绝对不能放在被测服务器上

（2）TPS 服务器最主要的指标，相关概念如下：

tps 事务每秒 服务器每秒能处理多少事务数（要么1个接口，要么多个接口的合并）

qps 每秒查询率 服务器每秒查询多少次

查询，可以是数据库的查询，也可以是文件的查询，其实也不局限于上述两种。云服务器资源提供商，一般都会提供监控平台，看到的数据，更多的是qps。所以很多企业说qps要达到多少。

rps 每秒请求率 发起方每秒发起多少请求

1个rps 可能对应 n个qps，那么1次请求 一定等于 1个事务吗？ 关系不确定，仅仅局限于一个请求就是1个接口，才会是1个事务。

1个rps = 1个tps， 其实也代表1个rps可能跟qps存在n倍关系。可以推导出QPS大，TPS也大，所以在企业中会把qps当作tps来说。

hps 每秒点击率 发起方，而且是在前端性能测试中才有的概念

（3）吞吐量 网络最重要指标

网络中能传输多少个事务，在企业中，也会和 tps 一起讲，因为当网络没有瓶颈，服务器的处理能力，就可以通过网络的事务数来展示出来。此时，数值上，tps数值=吞吐量数值。有网络瓶颈，吞吐量数值不等于tps数值，并发用户数改变时，吞吐量数值也不等于tps数值。

（4）资源利用率

服务器的使用情况

一般cpu、内存资源利用率 一般小于80%（整体）

需要监控