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

测试媛小七

已于 2024-08-30 17:50:27 修改

阅读量869

点赞数 31

分类专栏：性能测试文章标签： linux 学习运维

于 2024-08-26 21:11:03 首次发布

本文链接：https://blog.csdn.net/weixin_47314038/article/details/141573087

版权

性能测试专栏收录该内容

4 篇文章 0 订阅

订阅专栏

性能测试环境准备

一、操作系统--生产环境常用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的主要特性和作用

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

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笔/秒。

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

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

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

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

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