性能测试

字数

10872 字

阅读时间

43 分钟

一、基本概念

1. 性能

吞吐量TPS：服务器每秒处理的业务请求个数
响应时间：从客户端发送请求，到客户端接收到响应的总时间
错误率：错误的请求样本数在总请求样本数中的占比（即：错误请求样本数/总请求样本数）

性能：就是软件质量模型中的“"特性
效率特性：
- 时间特性：表示系统处理用户请求的响应时间
- 资源特性：表示系统运行过程中，系统资源的消耗情况，如：CPU、内存、磁盘等

2. 性能测试

性能测试：使用工具，模拟，对软件的进行测试和评估
- 自动化工具：JMeter、Locust
- 不同场景：如用户长时间使用、超大量用户同时在线、大量用户同时使用
- 软件各项性能指标：时间、资源

3. 性能测试的作用

系统上线后，评估系统能力
系统上线后，寻找性能瓶颈，优化性能（找bug，一般是易用性差，如抢票系统在大量用户同时购票抢票时会出现系统繁忙导致部分用户买不到票）
评估软件能否满足未来的需要

4. 性能测试与功能测试的区别与联系

功能测试：验证软件系统操作功能是否符合产品，主要焦点在功能（）
性能测试：验证软件系统是否满足，主要焦点是业务场景的满足（）
- 性能测试只测正向功能，不测逆向功能

一般项目中，先通过后，再进行

5. 性能测试业务场景介绍

单业务场景：此场景单独测试每一个业务/接口，各业务/接口 单独 进行压测，判断性能是否满足需求
- 压测：压力测试
- 例如：（1）登录（2）搜索（3）下订单，三个业务/接口 单独 进行性能压测
混合业务场景：测试系统中的多个业务/接口，按照业务比例，对多个接口 同时 进行压测，判断是否有性能问题
- 一般情况下，仅当单业务场景测试完毕后，再进行混合业务场景测试
峰值场景：此场景要验证系统在某段时间内或请求量波动较大的情况下，系统能否正常稳定的提供服务
- 例如：电商双11场景；限时秒杀场景
稳定性测试场景：主要测试系统在一定压力下，长时间运行 能否保持稳定运行
- 例如：电商系统，同时进行登录、搜索、下订单、发货、退货、退款等业务操作，运行7*24小时，看看系统能否稳定运行
- 一般仅当前面几个测试场景都测试完毕后，才考虑进行稳定性测试
异常场景：主要测试系统在出现故障/异常后，验证业务是否受到影响，以及受影响的时间（多久能恢复）
- 例如：
  - 社媒类软件出现热点话题，用户同时访问量远大于压测最大值，出现预期外的错误；
  - 服务器集群中有部分服务器出现down机（无法访问），导致剩余的正常服务器承担所有的业务量，可能会承受不住

6. JMeter 与其他工具的区别

工具	脚本形式	GUI 角色
JMeter	XML 脚本（.jmx）	可视化编辑器（拖拽组件） + 执行器
Postman	JSON 脚本（Collection）	接口调试 + 脚本管理
Python + requests	Python 代码	纯代码，无专属 GUI（需借助 IDE）
LoadRunner	C/Vuser 脚本	类似 IDE 的专业脚本编辑器

JMeter 的独特之处在于：即使完全不懂 XML，也能通过 GUI 完成复杂的压测脚本编写。

7. JMeter介绍

结构如下：
测试计划
   ---线程组A
   ---线程组B

测试计划中的线程组之间：默认是并行的。
- 若勾选测试计划界面下方的 “独立运行每个线程组”。JMeter 会按顺序执行测试计划中的线程组：先启动线程组 A，等 A 中所有线程（无论设置了多少循环）都完全停止后，再启动线程组 B。
单个线程组内的请求之间：默认是串行的。JMeter 会按顺序从上到下执行同一个线程组里的请求。
配置元件是在测试启动时全局加载的，它们的作用域由其所在的“树形结构”位置决定，与线程组之间的执行顺序（串行/并行）没有直接关系。

8. 性能测试策略

一般性能测试的顺序是：基准测试 --> 负载测试 --> 稳定性测试 --> 压力测试

1）基准测试

定义
- 狭义上讲，就是。测试环境确定后，对业务模型中的重要业务作单独测试，获取单用户运行时的各项性能指标。是由单用户进行大量循环测试得到的数据的平均分析。
- 广义上讲，就是确定一个。当系统的之后再进行一次基准测试以确定变化对性能的影响
作用
1. 为多用户并发测试和综合场景测试等提供参考依据
2. 为系统优化前后的性能提升/下降提供参考指标

2）负载测试（相对并发）

定义：通过，确定在的情况下，找出系统能够承受的的测试
示例
- 先筛选出运行时间符合性能指标的测试数据，随后再找最大负载量

3）稳定性测试

一般在负载测试后，才进行稳定性测试，目的是为了测试系统在该边界值内长时间运行是否会出现BUG

定义：在服务器（满足用户要求的正常的业务负载下）的情况下进行（1天 - 1周等），并最终保证服务器能满足线上业务需求
- 稳定性测试的负载量以甲方要求的用户正常的负载量为准。例如：
  - 情况1：一个电梯系统实际最大负载为13人，但甲方要求负载为15人，这属于BUG，不能进行稳定性测试，应该先修复BUG并通过负载测试
  - 情况2：一个电梯系统实际最大负载为13人，但甲方要求负载为10人，这时候进行稳定性测试就按甲方的标准来，以10人为负载量进行稳定性测试

4）压力测试

定义：在强负载下的测试，查看系统在是否存在功能隐患、系统是否具备良好的和
作用：预防软件在实际使用过程中，出现用户量超过预期（系统最大负载量）的情况
测试场景/适用场景
- 极限负载情况下（远超负载测试中的最大负载量）导致系统崩溃的破坏性压力测试，并测试系统在回到正常负载范围后多久能恢复正常

5）并发测试（绝对并发）

负载测试是相对并发，是负载量巨大，但同一时刻并发的线程数可能较少，是以秒级为精度的。而并发测试是绝对并发，以毫秒甚至微秒为时间精度，要求所有请求必须在同一时刻同时触发，同一时刻并发的线程数多。

定义：在，发送，来验证服务器对并发的处理能力
适用场景：抢红包、秒杀、抢购等

9. 性能测试指标

响应时间：指用户，到，这整个过程所耗费的时间。（注意，只包含后端请求的时间，这里不包含返回结果在前端渲染显示出来所花费的时间）
并发数：同时向服务器发送请求的用户数/线程数
吞吐量：指的是处理的客户端，直接体现软件系统的性能承载能力
1. QPS（每秒查询数）：控制服务器处理的指定的数量（不同请求的QPS可能不同）
2. TPS（每秒事务数）：控制服务器处理的的数量
  - 事务：即业务，一个事务可能对应一个或多个请求
  - 一个事务对应一个请求时：QPS=TPS
  - 一个事务对应多个请求时：QPS=n*TPS
点击数：客户端向服务端发送请求时，所有的（如图片、链接、框架css、js等）的请求总数量
- 该指标只有web项目才有。且该指标指的不是点击网页的次数，而是点击网页后发起的请求的总数量，一次点击可能会发起多次请求
错误率：系统在下，失败业务的概率。错误率 =（失败业务数/业务总数）*100%
- 错误率是一个性能指标，不是功能上的随机BUG。大多数系统一般都会要求错误率无限接近于0
- 例如：在一百万个用户同时进行下单支付时，有3个用户下单失败，那么错误率就是百万分之三
资源利用率：系统各种资源的使用情况，一般用“”形成资源利用率的数据。

二、JMeter基本介绍

1. JMeter文件目录结构介绍

bin目录：存放可执行文件和配置文件
docs目录：是JMeter的API文档，用于开发扩展组件，学习阶段用不到
printable_docs目录：，几乎任何问题都能在这里找到
lib目录：存放JMeter依赖的jar包和用户扩展所依赖的jar包

2. JMeter默认配置修改 --> 修改bin目录下的.properties文件

将JMeter修改为：打开后默认中文界面

找到并打开apache-jmeter/bin/jmeter.properties
找到第37行，修改为"language=zh_CN"
重启JMeter

3. 🌟🌟🌟JMeter基本元件和组件介绍

组件与元件之间是类与方法的关系；元件是一整个大容器，组件是元件中的特定功能

1）元件介绍

元件：多个类似功能组件的（类似于类）
- 取样器：发送请求
- 逻辑控制器：控制语句的执行顺序
- 前置处理器：对请求参数进行预处理
- 后置处理器：对响应结果进行提取
- 断言：检查接口的返回结果是否与预期一致
- 定时器：设置等待时间
- 测试片段：封装一段代码，供其他脚本调用
- 配置元件：测试数据的初始化配置（参考Python的__init__函数）
- 监听器：查看JMeter脚本的运行结果

2）组件介绍

组件：实现独立的某个功能（类似于类中的方法）
示例：HTTP请求就是一个组件，它隶属于取样器这一元件

3）接口自动化脚本实现过程

4）🌟JMeter元件的作用域和执行顺序

作用域

元件的作用域：靠测试计划的树形结构中元件的来确定的
具体元件的作用域：
- 取样器（如HTTP请求）：核心，
- 逻辑控制器（如if控制器）：只对其子节点中的取样器和逻辑控制器起作用
- 🌟其他元件（如固定定时器）：
  - 如果是某个取样器的子节点，则该元件只对其父节点起作用
  - 如果父节点不是取样器，则其作用域是该元件（包括子节点，子节点的子节点等）
    - 这里的意思是，父节点的所有后代节点在执行时，都必须要执行该元件，或采用该元件的配置。
      - 例如：上图中，固定定时器1 的父节点不是取样器，所以它会对所有父节点的后代节点起作用，即：固定定时器1 会对都起作用
      - 该元件如果是断言：每个后代取样器执行后，都会触发这个断言检查一次
      - 如果是前置处理器：每个后代取样器执行前，都会触发一次
      - 如果是定时器：每个后代取样器执行前，都会等待一次
      - 如果是配置元件：每个后代取样器执行时，都会应用这个配置

执行顺序

同一作用域下的不同类型元件执行顺序如下：
1. 配置元件
2. 前置处理器
3. 定时器
4. 取样器
5. 后置处理器
6. 断言
7. 监听器
同一作用域下的相同类型元件执行顺序：按照在测试计划中从上到下的顺序执行

三、具体场景分析

以下的场景分析使用的例子均为BMS系统（包含登录、进入首页、获取用户信息、退出四个业务功能）

TPS（吞吐量）：每秒处理的请求数量

1. 单业务场景

单业务可能是单个接口，也可能是多个接口

Q：为什么要进行单业务测试？ A：要验证系统能支持的单业务/接口的最大负载量，能否满足系统业务需求，单业务测试达标后才能进行混合业务测试

以登录为例，假设某BMS系统目标登录TPS为30，进行如下步骤的性能测试：
1. 模拟单个用户，发送请求，收集基准性能数据（TPS和响应时间） ----
2. 逐步增加用户量，发送请求，收集性能测试数据 ----
3. 将系统能支持的最大TPS，与需求进行对比，达标则测试通过

例如： case1：模拟1个用户，发送登录请求，记录TPS和响应时间 case2：模拟10个用户，发送登录请求，记录TPS和响应时间 case3：模拟20个用户，发送登录请求，记录TPS和响应时间 case4：模拟30个用户，发送登录请求，记录TPS和响应时间 case5：模拟40个用户，发送登录请求，记录TPS和响应时间 ...... 假设结果：

关键点

设置性能测试场景（即：按照用例要求模拟大量用户发送请求）
- 通过JMeter的 线程组 配置（线程组就是用户数，一个线程代表一个虚拟用户）
收集性能测试数据（即：记录TPS和响应时间）
- 通过 聚合报告 收集
分析性能测试结果
- 找出系统的最大TPS，与需求进行对比，达标则通过

a. 聚合报告（收集其父节点下的所有同级和后代取样器的数据）

作用：收集性能测试结束后系统的各项性能指标。如：响应时间、吞吐量（TPS）、错误率等。
位置：测试计划 -> 右键 -> 监听器 -> 聚合报告
参数：
- 响应时间：单位 ms

c. 分析性能测试结果

将聚合报告统计结果记录到表格中

3）如何进行性能测试

打开JMeter，新建测试计划 -> 新建线程组 -> 在线程组内新建HTTP请求查看结果树用于查看测试脚本是否成功运行
在项目jar包所在目录运行命令java -jar bms2-1.0-SNAPSHOT.jar，开始在本地运行项目
设定线程组
- Same User on each iteration选项：
  - 勾选：适合模拟有状态的业务场景（用户持续操作多轮）
  - 不勾选：适合模拟无状态的压测（每次循环都是全新用户）
根据BMS系统接口文档设定HTTP请求（更推荐使用Postman来测试接口是否能正常使用，使用Postman测试接口就不需要结果树了，直接跳转至第六步）（本地部署，则IP替换为127.0.0.1）
编写完成后记得先保存再运行，运行后查看结果树，运行成功则说明没有问题，可以继续进行压测，必须先调通脚本再测试
为线程组添加聚合报告，随后启动JMeter脚本，聚合报告会自动获取该线程组的数据
根据聚合报告数据，使用Excel表格记录性能测试数据
更改线程组的线程数，启动JMeter脚本，重复7~8步

2. 混合业务场景

负载测试：验证系统在预期负载下是否满足性能要求
压力测试（压测）：找到系统的极限上限和崩溃点

混合业务场景测试分析：所有业务/接口按比例 发送请求（因为用户常用的业务就几种，其余业务用的少，比例就少）
测试步骤：
1. 进行基准测试
2. 再进行负载测试
3. 将系统能支持的最大TPS，与需求进行对比，所有业务 达标则测试通过

关键点

设置性能测试场景（即：模拟多用户 + 按照比例发送请求）
- 通过 吞吐量控制器 配置
收集性能测试数据（即：记录TPS和响应时间）
- 通过聚合报告实现
分析性能测试结果
- 找出系统的总计最大TPS，与需求总计TPS进行对比，达标则通过
  - 因为业务请求数是按比例分配的，其TPS也是按比例分配的，总TPS达标，对应每个业务的TPS也应该是达标的

吞吐量控制器（作为指定HTTP请求的父节点）

作用：控制其下的子节点的执行次数与负载比例分配参数：与单业务场景不同，混合业务场景需要先在线程组下添加吞吐量控制器，再在吞吐量控制器下添加HTTP请求，以确保HTTP请求按照吞吐量控制器的配置执行

例如：BMS系统有登录、访问首页、获取用户信息、退出这四项业务功能，它们的TPS要求分别是30、20、10、20，则配置吞吐量控制器，为这四项业务分配的吞吐量比例分别为37.5、25、12.5、25，最后根据聚合报告得到的数据也可验证是否按业务比例分配请求数：可以通过验算样本数占比或吞吐量（TPS）占比来判断是否成功按照业务比例分配请求数

3. 峰值场景测试性能分析（并发测试）

我们指的峰值场景一般指的是决対并发场景

Q：什么是峰值场景测试？ A：在内，发送，验证服务器对并发的处理能力

示例：

项目背景：BMS系统每日9点签到，会有50个用户陆续上线，其中40个用户在9点整同时登陆系统进行签到
性能需求分析：
- 有50个用户陆续上线，表示：有50个用户发送登录请求 ----
- 有40个用户在9点整同时登录系统，表示：有40个用户同一时刻发送登录请求 ----
目标：
- 首先关注错误率，最好为0
- 其次关注吞吐量/响应时间，响应时间可能会上升，但峰值结束后能慢慢恢复即可

操作步骤：

添加线程组，设置线程数50
添加HTTP请求 -- 登录
添加同步定时器，并发数设置40，超时时间为5000 ms
添加监听器 -- 聚合报告

关键点

有50用户陆续上线（相对并发）
- 线程组，设置线程数
有40用户在9点整同时登录系统（绝对并发）
- 同步定时器

同步定时器（作为指定HTTP请求的子节点）

作用：阻塞线程（累积一定的请求），当在规定的时间内到达一定的线程数量，这些线程会在同一个时间点一起释放，瞬间产生很大的压力
- 想象一下，同步定时器其实是一个"集合点"，它的作用是让线程都在某一时刻停在"集合点"等待其他线程到达（阻塞），一定时间内"集合点"中的线程数达到一定程度，这些就会从"集合点"一起出发（释放）
位置：测试计划 --> 线程组 --> HTTP请求 --> （右键添加）定时器 --> Synchronizing Timer
参数：
- Number of Simulated Users to Group by: 模拟用户的数量，即指定。
  - 若设置为0，等于设置为线程组中的线程数量
- Timeout in milliseconds: 超时时间，即指定的线程数；
  - 如果设置为0，该定时器将会等待线程数达到了设置的线程数才释放，若没有达到设置的线程数会一直死等。
  - 如果大于0，那么如果超过Timeout in milliseconds中设置的最大等待时间后还没达到设置的线程数，Timer将不再等待，释放已到达的线程。默认为0

4. 稳定性测试场景性能分析

混合业务场景负载测试 和 峰值场景并发测试，都是验证 短时间内的系统处理能力 能否支持高负载
不同于以上两者，稳定性场景测试主要是发现 长时间运行 时（系统的使用和释放），系统能否稳定提供服务

Q：什么是稳定性场景测试？ A：在服务器的情况下进行，并最终保证服务器能满足线上业务需求

什么是用户正常的业务负载？
- 系统日常运行时，用户所进行的主要业务操作
  - 解释：系统日常运行时，一定是多种业务共存，因此需要使用 混合业务场景 下的压力
- 系统日常运行时，每种业务操作的并发/负载量
  - 解释：系统日常运行时，并不会永远保持高峰期的压力/负载量，因此压力可以比 高峰期混合业务场景 的压力低一些（例如：CPU使用率在70%时对应的并发数）
测试时长一般是 1天 ~ 1周
示例：
- 项目背景：BMS系统日常业务（登录/进入首页/获取用户信息/退出），保证系统在日常情况下连续不间断运行
- 性能分析：
  1. 模拟用户正常业务负载量：
    - 系统日常使用时，一般为混合业务场景（登录/进入首页/获取用户信息/退出）
    - 稳定性运行TPS比之前混合场景测试时的最大TPS低一些（具体参照混合业务场景测试时记录的数据）
  2. 不间断运行一段时间（一般是 1天 ~ 1周）
  3. 观察性能指标
- 关注的指标：
  - 首先关注错误率，最好为0
  - 其次关注吞吐量/响应时间，响应时间（不会明显上升）和吞吐量（不会明显下降）长期处于稳定的范围内
- 操作步骤：
  1. 添加线程组，设置线程数和运行时间（24 * 3600）
    - 线程数：参考混合业务场景测试数据，比最高TPS低一些
    - 运行时间：24 * 3600 （因为在JMeter中，运行时间是以秒为单位计数的）
  2. 添加吞吐量控制器和HTTP请求，设置吞吐量比例
  3. 添加监听器 - 聚合报告
  4. 使用命令行运行JMeter脚本，生成HTML测试报告（GUI图形界面不能生成HTML测试报告）（需要在JMeter的bin目录下使用cmd命令行）
    - HTML测试报告的作用：可以从测试计划中获取图表和统计数据信息
    - cmd命令：jmeter -n -t [jmx file] -l [result file] -e -o [html report folder]
    - eg：jmeter -n -t hello.jmx -l result.jtl -e -o ./report
      - 参数描述： -n: 非GUI模式执行Jmeter（不使用图形界面操作，即使用命令行方式运行） -t [jmx file]: 测试计划保存的路径及.jmx文件名，路径可以是相对路径也可以是绝对路径 -l [result file]: 保存生成测试结果的文件，jtl文件格式（这是一个中间文件，报告是由该文件生成的，命名不太重要） -e: 测试结束后，生成测试报告 -o [html report folder]: 存放生成测试报告的路径，路径可以是相对路径也可以是绝对路径

关键点

设置性能测试场景（即：混合业务场景 + 长时间运行）
- 通过 吞吐量控制器 + 线程组 配置
收集性能测试数据（即：记录错误率、TPS和响应时间）
- 通过 聚合报告 收集（平均值）
- 通过收集（过程数据，查看是否处于稳定的范围内）
分析性能测试结果
- 错误率为0
- 吞吐量/响应时间处于稳定的范围内

四、性能测试实战

1. 性能测试的步骤/流程

各典型性能场景都会按照以下步骤分析执行

性能需求分析
1. 明确被测系统
  1. 熟悉被测系统的
  2. 熟悉被测系统的
2. 明确测试内容
  - 业务角度：用户使用频率较高的关键业务功能
  - 技术角度：逻辑复杂的业务、数据量大的业务
3. 明确测试策略（负载测试、稳定性测试、并发测试等，根据实际情况选择）
4. 明确测试指标
  - 有明确的需求指标：执行结果与预期指标进行对比
  - 无明确的需求指标（分析指标）：查找资料、类似的系统对比、对未来流量的预估
性能测试计划及方案
1. 测什么（项目背景、测试目的、测试范围）
2. 谁来测（进度与分工、交付清单）
3. 怎么测（测试策略）
性能测试用例设计
- 模板：
- 用例要素参考功能测试的测试用例八大要素：编号、标题、模块、优先级、前置条件、测试数据、测试步骤、预期结果
性能测试执行
1. 建立测试环境
2. 编写测试脚本
3. 性能测试监控（配置各项性能的监控指标，如：响应时间、TPS、错误率等）
4. 执行测试脚本（执行前需要先确保脚本调试通过）
性能分析调优（测试人员了解即可）
1. 性能测试人员经过对结果的分析以后，如果不符合性能需求，则会提出性能bug，然后由开发人员进行后续的调优
2. 性能问题回归验证
性能测试总结报告
1. 测试工作的经过回顾
2. 缺陷分析和调优
3. 风险评估
4. 性能测试结果
5. 测试工作总结与改进

2. 提取性能测试业务

1）性能测试与功能测试的区别

功能测试：覆盖所有功能（正向、逆向） ---- 侧重：全面
性能测试：覆盖主流的业务场景（正向） ---- 侧重：精准
- 性能测试的用例数大概为功能测试的1%（数量少）

2）如何精准提取性能测试的业务

从以下两方面考虑：

业务（用户角度思考）
- 最简单的判断方法：从冒烟测试的业务中挑选，非冒烟测试业务不考虑
- 用户频繁使用的业务
- 非常关键的业务
技术（开发角度思考，公司里可以直接问开发哪些业务资源占用率高，就去测那些业务）
- 资源占用高的业务功能

3）JMeter常用测试元件

取样器-HTTP请求 --> 发送HTTP请求
配置元件-HTTP请求默认值 --> 设置HTTP请求中的默认（固定）部分
配置元件-用户定义的变量 --> 定义全局变量
后置处理器-JSON提取器 --> 提取JSON响应结果中的数据
断言-响应断言 --> 对任何响应结果中的数据进行检查
断言-JSON断言 --> 对JSON响应结果中的数据进行检查
监听器-察看结果树 --> 查看脚本执行后的HTTP请求和响应内容
监听器-聚合报告 --> 查看性能测试的指标数据

五、具体组件介绍

1. 线程组

作用：线程组就是控制JMeter用于执行测试的一组用户
位置："测试计划" --> "添加" --> "线程（用户）" --> "线程组"
特点：
- 可以模拟多人操作
- 线程组可以添加多个，多个线程组可以串行或并行执行
  - 线程组的并行：哪个线程组先跑出结果，就先返回哪个
  - 线程组串行：串行是按照从上往下的顺序来执行的
- 取样器（请求）和逻辑控制器必须依赖线程组才能使用
- 线程组下可以添加其他元件下的组件

1）线程组分类

线程组可分为以下三类：
- 线程组：普通的常用线程组，可以看作一个虚拟用户组，线程组中的每一个线程都可以理解为一个虚拟的用户
- setUp线程组（前置）：可以用于预测测试操作
- tearDown线程组（后置）：可以用于执行测试后的操作

2）线程组参数详解

一图流：
如果线程数设置为100，Rame-Up设置为5秒，那么每秒就会有100/5=20个用户启动（如果设置了启动延迟且有效，那么会在启动延迟后再每秒分批次均匀启动用户）
循环次数是每个虚拟用户（即每个线程）循环执行测试计划的次数
🌟循环次数设置为"永远"，一般配合调度器使用（即：调度器也要同步勾选使用），随后可以设置调度器配置
- 持续时间：该线程组脚本会运行多久
- 启动延迟：启动脚本后要等待指定时间后，才会开始运行线程组脚本
  - 仅当启动延迟结束后才会开始持续时间的计时
  - 启动延迟的核心用途是解决施压策略和环境准备问题
  - 启动延迟适用于处理多个业务之间有先后关系的场景
理解启动延迟：
- 错峰启动（阶梯式压测）：比如你有3个线程组（分别模拟不同接口），设置启动延迟分别为 0秒、10秒、20秒，让负载分波次打到服务器上，避免所有用户在同一瞬间发起请求造成尖峰冲击。
- 预热等待：测试刚启动时，应用可能正在加载缓存或初始化连接池。设置一个启动延迟（如30秒），让服务器先“热热身”，再正式开始施压，这样测出的性能数据更准确。

3）案例分析

使用1个线程组，添加HTTP请求，命名为：HTTP请求-百度，设置GET方法访问www.baidu.com
- 配置线程数为2，循环次数为3时，运行观察结果
- 配置线程数为3，循环次数为2时，运行观察结果
对比不同分析：
- 线程数代表虚拟用户数，用户数越多，负载越大
- 循环次数代表运行时间，次数越多，运行时间越长

所以说，这两种配置除了运行时间上差不多，其他方面是完全不同的概念，线程数更多的脚本负载越大，越占用性能

2. HTTP请求（最重要的取样器组件）

作用：向服务器发送HTTP请求
位置："线程组" --> "取样器" --> "HTTP请求"
一图流：
get和post下写的两种传参方法，只要选其中一个就可以了
如果端口号是协议的默认端口号，可以不写

3. 查看结果树

如果请求体/响应体出现乱码，则修改.properties文件中的encoding编码方法为UTF-8

查看HTTP消息请求和响应内容：
- 查看消息请求：Request Body（其中包含了请求行+请求体）
- 查看响应数据：Response Body（响应体）

六、JMeter参数化

定义：把测试数据组织起来，用调用
- 参数化的是（用户定义的变量也属于参数化范畴）
常见的参数化实现方式：
- 用户定义的变量 -- 全局变量
- 用户参数 -- 为每个用户分配不同的参数值
- CSV数据文件设置 -- 文件方式参数化
- 函数 -- 随机数据

1. 用户定义的变量（全局变量）

作用：定义全局变量
位置：测试计划/线程组 --> 配置元件 --> 用户定义的变量
示例：使用“用户定义的变量”配置被测系统的协议、域名和端口，请求地址与端口为https://www.baidu.com:443
1. 设置"用户定义的变量"参数：
2. 在同一线程组下的其他组件中使用，使用形式为：${变量名称}
3. 启动脚本，查看“查看结果树”中返回的结果
4. 请求成功，这就是参数化的具体体现，如果有其他数据要传入，只需要修改变量的值即可

2. 用户参数

作用：针对同一组参数/变量，当不同的用户来访问时，可以获取到不同的值
位置：测试计划/线程组 --> 前置处理器 --> 用户参数
参数：
示例：
1. 以www.baidu.com为例，在参数列表中传递参数，引用“用户参数”中定义的变量，引用形式为：${变量名称}
2. 设置线程数为2，启动运行脚本，观察“查看结果树”返回的运行结果

3. CSV数据文件设置

作用：让不同用户，或同一用户在多次循环时，都可以取到不同的值
- 用户更换，值会变；不同循环中，值也会变
位置：测试计划/线程组 --> 配置元件 --> CSV数据文件设置
参数：
使用方法：同样的，也是在需要用到参数值的地方，填入${变量名称}

4. 函数（__counter）

作用：计数函数，一般做执行次数统计使用
- 常用作以下场景：大量用户，每个用户在每次循环时都可以使用不同的值
位置：系统菜单 --> 工具 --> 函数助手对话框
使用：
案例：
- HTTP请求：访问http://www.baidu.com/S?num=1
- 要求：每个用户每次循环执行该脚本时使用的num值都不同
- 操作步骤：
  1. 添加线程组
  2. 生成__counter函数
  3. 添加HTTP请求，使用__counter函数
  4. 在“查看结果树”中确定结果

为什么查看结果树中的每个HTTP请求下有两个子节点

问题描述：当发送www.baidu.com的http请求时，查看结果树看到的发送消息和HTTP请求取样器中的配置信息不完全一样
原因分析：
- 查看结果树中最外层HTTP请求的请求信息和响应信息，应与子节点中最后一个HTTP请求的请求信息和相应信息一致
- 配置的HTTP请求，应与"查看结果树"中第一个子节点的内容信息相同
JMeter可以自动处理判断状态码。例如这里就是遇到了重定向状态码302，所以出现了子节点请求0（出现重定向问题）和子节点请求1（重定向后的HTTP请求信息）

七、JMeter断言

断言：让程序预期结果和实际

提示：
- JMeter在请求的返回层面有个自动判断机制（能够自动判断处理响应状态码）
- 请求成功了，并不一定代表结果正确，因此需要检测机制来提高测试准确性，也就是断言
  - 例如：请求成功，获取到了数据，但获得的数据不一定是正确的，所以要进行断言
JMeter常用断言：
- 响应断言
- JSON断言
- 持续时间断言（Duration Assertion）

贡献者

freeway348

文件历史

最后编辑于 4 分钟前查看完整历史

最长上升子序列(LIS)

数字三角形

RAG+Agent

1.第一章

第二章

1. 第一章

2. 第二章

2.1 数制与编码

2.2 逻辑运算

2.3 浮点数的表示与运算

3. 第三章 存储系统

4. 第四章 指令系统

5. 第五章 中央处理器

0.零基础

1.函数极限与连续

10. 一元函数积分学的应用（一）---几何应用

11. 一元函数积分学的应用---积分等式与积分不等式

12.一元函数的物理应用

13. 多元函数微分学

14. 二重积分

15 微分方程

2. 导数

4.一元函数微分

5. 一元函数微分学的几何应用

6. 中值定理

7. 一元微分学的物理应用

8. 一元函数积分学的基本概念

9. 一元函数积分学的计算

做题技巧

强化篇

性能测试 ​

一、基本概念 ​

1. 性能 ​

2. 性能测试 ​

3. 性能测试的作用 ​

4. 性能测试与功能测试的区别与联系 ​

5. 性能测试业务场景介绍 ​

6. JMeter 与其他工具的区别 ​

7. JMeter介绍 ​

8. 性能测试策略 ​

1） 基准测试 ​

2）负载测试（相对并发） ​

3）稳定性测试 ​

4）压力测试 ​

5）并发测试（绝对并发） ​

9. 性能测试指标 ​

二、JMeter基本介绍 ​

1. JMeter文件目录结构介绍 ​

2. JMeter默认配置修改 --> 修改bin目录下的.properties文件 ​

3. 🌟🌟🌟JMeter基本元件和组件介绍 ​

1）元件介绍 ​

3. 第三章存储系统

4. 第四章指令系统

5. 第五章中央处理器