性能测试教程3：性能测试执行教程从数据准备到压测执行

标签：教程 请求 Thread -- 性能 并发 线程 测试

性能测试环境准备

一、操作系统--生产环境常用Linux

前置--学习《Linux计算机操作系统基础知识》

Linux_测试媛小七的博客-CSDN博客

没有合适资料的同学可以跟着我的linux专栏内容学习

1、Centos7

2、非Linux-可以安装虚拟机

二、性能测试环境：服务器配置

1、硬件型号测试环境于生产环境应当尽量一致

2、服务器数量

基准测试：同理可得，以此类推

例如：当我们在生产环境中有100台服务器，但测试环境只有1台服务器，如果测试环境可以承载1000/s并发，那么100台差不多能100000/s并发。

实际应用并没有严格要求性能测试环境服务器数量

三、数据准备

比如：在性能测试中庞大的数据量如何准备？

1、纯数据库SQL 存储过程 无法实现复杂的数据生成

2、用代码去生成 导入数据的SQL语句(常用) 

3、用代码去调用接口/UI自动化 生成

4、造数据技巧：

（1）衍生-->基于已有的数据

（2）随机生成

5、注意事项

注意数据的状态分布

比如：造订单数据-多种状态（尽量贴合生产环境的分布情况）

你的数据分布，决定你数据库层面执行性能。

四、服务器分布情况

测试测试执行脚本机器--应用服务器--数据库服务器

Jmeter性能压测线程模型

前置知识：Jmeter接口测试项目实战

一、性能测试执行工具（Jmeter）

1、注意：Jmeter不同版本对java环境要求不同，请按照要求安装

2、第三方插件使用

下载后解压缩放在Jmeter：apache-jmeter-5.4.1\lib\ext ，重启Jmeter后可用

4、线程模型

多线程 并行

线程数--同时多少个虚拟用户在干活，干活的内容就是线程组里面的东西

多个线程会同时开始

同一个线程去执行线程组内的任务，是有序的

5、汇总报告

• Label：执行样本的标签，如http请求的名称

• 样本：执行的，具有相同标签的样本值

• 平均值：一组样本的平均响应时间 ms

• 标准偏差：响应时间幅度大不大

• 异常%：执行失败的请求占一组样本的百分比

• 吞吐量：每秒完成的请求数 （业务吞吐量）

在Jmeter中吞吐量不分TPS/QPS

TPS-数据变更场景

QPS-数据查询场景

• 接受/sec、发送/sec：网络接受/发送速度（网络吞吐量）

缺点：只能看到最终结果，无法看到过程。无法分析出 哪一个阶段，系统达到了性能拐点。

6、事务控制器

使用场景：测试的场景中，包含多个接口的时候，需要做整体的数据统计。

添加--逻辑控制器--事务控制器

事务控制器可以将当前线程下的请求组合成一个事务（适合业务逻辑问题的压测），在聚合报告中会单独存在

事务控制器只聚合数据，并不是将请求合并起来再请求一次。

事务控制器下多个请求，有一个请求失败，即视为整个事务该条处理失败。

（1）1秒启动N个线程

1秒启动2个线程

（2）Ramp-up 1 线程2 循环1000

两个线程各循环1000次，循环完停止。 实际1000/4.多秒

（3）Ramp-up 1 线程2 循环1000 持续时间2S

循环2S ，请求能跑多少跑多少。

实际2S跑了三百多请求。

7、梯度线程组（Stepping Thread Group）

Stepping Thread Group的特性 有预览图显示估计的负载 可延迟启动线程组 可持续增加线程负载 可设置最大负载的持续运行时间

Stepping Thread Group的作用 减少服务器的瞬时压力，做性能测试应该逐步增加压力，而不是瞬时加压 逐步增压越平缓越好，更容易从结果看到多少压力值下，有性能瓶颈

8、Active Threads Over Time（图像可视化的响应时间）

监听单位时间内活动的线程数。其中横坐标是单位时间（单位是毫秒），纵坐标是活动线程数（也就是并发数）

9、Transaction per Seconds（TPS 吞吐量）

Transactions per Second 也就是每秒事务数，在性能测试中非常重要的一个指标，我们在聚合报告里面能看到最后的测试结果TPS值。 如果我们想查看更详细的报告，查看压测过程中不同时间段的每秒事务数，可以使用 Transactions per Second 插件来查看。

二、用例执行的过程

1、性能基准测试结果分析与作用说明

场景1：线上服务器资源规划，买多少服务器？

性能基准：用极少的并发，去测试每一次用户操作 需要占用的资源，以及性能的表现

基准测试，手机系统在极低并发场景中的性能基线

（1）服务器带宽不能支持每秒传输3M左右的数据，则服务器无法实现40/S的吞吐量

（2）1个线程模拟40/s并发，生产环境面临4000/s的并发量，理论上需要达到100个线程并发。

2、用例执行过程 - 负载测试

场景1：线上预计会达到4000/s的并发，系统能不能抗住

不断增加系统并发压力，直到系统达不到性能要求(响应时间、负载量、资源占用)

梯度压测-手法

（1）插件使用--Stepping Thread Group

JMeter中的Stepping Thread Group（阶梯加压线程组）是一个用于执行复杂性能测试场景的自定义线程组。它允许用户按照预定的规则逐步增加并发线程数，以模拟实际用户逐渐增加对系统的访问压力。这种逐步加压的方式有助于更平滑地增加系统负载，从而更容易识别出系统在不同压力下的性能瓶颈。

Stepping Thread Group的主要特性和作用

1. 特性：
   • 预览图显示估计的负载：配置完成后，Stepping Thread Group会提供一个预览图，显示预期的负载变化。
   • 可延迟启动线程组：可以设置从测试开始到线程组启动之间的延迟时间。
   • 可持续增加线程负载：根据设定的规则，逐步增加并发线程数。
   • 可设置最大负载的持续运行时间：在达到最大线程数后，可以设置持续运行一段时间以观察系统表现。
   • 逐步释放线程：测试结束后，可以逐步释放线程，以模拟用户逐渐离开系统的场景。
2. 作用：
   • 减少服务器的瞬时压力：通过逐步增加压力，而不是瞬时加压，可以避免对系统造成过大的冲击。
   • 更容易识别性能瓶颈：逐步增压的方式使得性能瓶颈的识别更加直观和准确。

Stepping Thread Group的参数详解

• This group will start：总共要启动的线程数。
• First, wait for：从测试开始到线程组启动之间的延迟时间。
• Then start：测试开始时立即启动的线程数。
• Next add：之后每次增加的线程数。
• Threads every：每次增加线程后的持续运行时间。
• Using ramp-up：每次增加线程所用的时间（类似于基础线程组的Ramp-Up时间）。
• Then hold load for：所有线程启动完成后持续运行的时间。
• Finally, stop/threads every：测试结束时，逐步释放线程的规则（如每多少秒释放多少个线程）。

使用场景

Stepping Thread Group特别适用于需要模拟用户逐渐增加对系统访问压力的场景，如在线购物网站在促销活动期间的性能测试。通过逐步增加并发用户数，可以更真实地模拟实际用户行为，并帮助测试团队识别出系统在不同压力下的性能表现。

注意事项

• 在使用Stepping Thread Group时，需要结合实际的测试需求和系统特性来设置参数，以确保测试的准确性和有效性。
• 也可以尝试用Concurrency Thread Group替代使用。

选项--Plugins Manager--Custom Thread Groups勾选

新建线程--Stepping Thread Group （梯度压测）

请在Jmeter提前安装Stepping Thread Group插件才可使用，方法：新增线程组找到Stepping Thread Group。

（2）注意事项

当我们的负载测试的结果和预估的结果有出入，需要调整线程数

并发量是否达到？样本数？吞吐量？

出现这种情况的原因？

举例：第一种可能

假定有一个银行系统，它配备了10个服务处理器（类似于柜员窗口），每个处理器每秒能处理一笔业务。系统的容量上限是同时处理10笔业务，这对应于系统能同时支持的最大并发用户数。

1. 初始状态：系统空闲，没有任何用户请求。

2. 第一次请求：一个用户提交了业务请求，系统立即处理，此时的吞吐量为1笔/秒。

3. 第二次请求：五个用户几乎同时提交了业务请求。由于系统有10个处理器，它可以同时处理这些请求，但此时只处理五个，吞吐量仍记为当前正在处理的数量，即5笔/秒（假设处理器完全独立且无延迟）。

4. 第三次请求：随后，又有八个用户提交了业务请求。系统继续处理，此时正在处理的业务数增加到8笔/秒，仍未达到系统最大容量。

5. 第四次请求：十个用户同时到达，系统满负荷运转，此时吞吐量为10笔/秒，每个处理器都在处理一个业务。

6. 第五次请求：又有十二个用户尝试提交业务，但此时系统已经满负荷，因此新到的用户请求被放入等待队列中。系统吞吐量仍保持在10笔/秒，因为这是系统在当前配置下的最大处理能力。

7. 资源瓶颈和崩溃：随着等待队列的增长，系统开始面临资源瓶颈，如内存不足、CPU过载或数据库锁竞争等。虽然系统未直接“崩溃”，但性能可能严重下降，用户体验受到严重影响。此时，系统管理员需要介入，通过增加处理器数量、优化业务处理逻辑或限制新的请求进入来应对这一情况。

系统资源是有限的

举例：第二种可能

人达到一定数量，银行保安直接关门，不允许继续进入

系统资源是有限的

（3）预期现象

第一阶段：并发量增加--吞吐量增加

第二阶段：并发量增加--吞吐量持平不会增加，响应时间变长（不会无限延长，空间有限，等待的请求挤压到一定程度系统会崩溃）

第三阶段：崩溃--并发增加--吞吐量下降（系统不断挤压请求，资源不够用），请求错误率提高（请求超时/系统拒绝新请求）

（4）插件使用--Response Times Over Time

可以查阅随线程数增加响应时间的变化，配置简单可自行尝试。

（5）插件使用--Transactions per Second

超过以后响应时间增加，直到达不到性能需求/报错过多结束测试，配置简单可自行尝试。

三、性能测试领域-细分概念

答疑：什么是静态请求与动态请求？

什么是静态请求与动态请求: 静态请求指对静态资源的请求,包括图片,视频等,简而言之就是请求实实在在的二级存储的路径 在url上,以http1.0为例,就是不带参数的get方法动 2. 动态请求指请求的不是一个具体的资源存储路径,而是一个虚拟的资源,经过程序处理后返回想要的资源.

1、基准测试

性能基准：用极少的并发，去测试每一次用户操作 需要占用的资源，以及性能的表现

基准测试线程数要求：系统100%能够承载的情况下，1是最小单位，也可以是5，10等。

2、性能负载测试

负载测试：目的是为了发现程序系统的实际处理能力

负载测试--线程数量-->根据基准测试里面每个线程能够在每秒模拟多少次并发

例如：基准测试中 1个线程能够模拟40/s并发

目标：测试系统是否能够承载4000/s

初步线程数量 = 目标并发/单线程模拟并发数量

如果将线程比作一个梯形，承载量可能在梯形第一个拐点，崩溃点在提醒第二个拐点。

标签：教程,请求,Thread,--,性能,并发,线程,测试
From： https://blog.csdn.net/weixin_47314038/article/details/141573087