简单学习 --＞ 性能测试

小新同学^O^2026-05-10 8:08

性能测试

性能测试: 为了发现性能问题 或 获取系统相关性能指标进行的测试 ; (在真实环境,特性负载条件, 通过 工具模拟实际软件系统及其操作 , 同时监控性能各项指标 , 最后对测试结果进行分析来确定系统性能情况) ;

常见性能问题: 查询数据时间长,网速很慢 , 服务器无响应,

常见性能指标

并发数

并发用户数

  1. 从业务层面看: 并发用户数是 指的是 实际使用系统的用户总数

  2. 从后端服务器层面: 指的是web服务器在一段时间内处理浏览器而建立的http连接数 或生成的处理线程数

例子: 一个系统有 200人同时使用 , 用户进行的操作有: 浏览页面 , 提交订单 , 填写订单 , 查询订单

那么这个系统的 业务并发用户是 200 (从业务层面看), 实际并发用户是 提交订单 , 查询订单的用户(从后端服务器层面看)

吞吐量

单位时间内处理的并发数, 直接体现系统的负载承受能力 ; (吞吐量越高 , 系统承受的并发越多,性能越好)

复制代码 
例如:  
A场景: 有100个并发用户 , 每个用户每秒发送一个请求 ; 
B场景: 有1000个并发用户 , 每个用户每10秒发送一个请求; 
//A和B的 吞吐量相同 , 都是 每秒100个请求 , 但 A场景思考时间短 , 所以A场景占用系统资源更多 ;
吞吐量分类
1.按照请求数量分类 :
TPS (Transaction Per Second)

TPS: 每秒处理事务数 , 用来衡量系统在一定时间内能处理的事务数;

公式: 总的请求成功的事务数 / 总的运行时间

复制代码 
例子: 
1. 一个系统 1分钟处理 1000条业务 , 那么 TPS= 1000/60=16.7
​
2. 一个系统 1天完成 10万笔交易 , 一个交易看作是一个事务 , 那么 系统的TPS 要多少合格:
    理论上: 10 0000 / (24*60*60) = 1.2   (理想状态时 TPS达到 1.2 , 但是实际上并不会怎么平均 ,而是某一段时间         里会增多 , 所以要分情况来 ,而不是算平均 )
    1. 如果没有更加详细的数据 : 按照 二八定律来 , (80%的事务在 20%的时间内完成) ; 
    ==> (10 0000 * 0.8) / (24*60*60*0.2) = 4.63 , 那么 TPS 要达到4.63才能 合格 ;
    
    2.给出详细的情况: 5万笔交易是在 5~6点完成, 那么
    ==> 5 0000 / (60*60) = 13.9 , 那么TPS要达到 13.9才能合格
QPS (Query per Second)

QPS: 每秒查询率

如果一个事务只有一个接口,同时这个接口是查询接口 , 那么 QPS == TPS ;

2.按网络数据包划分: B , KB , MB...
响应时间

响应时间 : 验证系统处理速度快不快 , 应用系统从请求发出开始 , 到客户端接收到最后一个字节数据所消耗的时间 ;

web系统来说, 系统响应时间 包括: 前端展现时间 + 系统响应时间

前端展现时间 : 页面渲染时间 ;

系统响应时间: 包含服务器 , 数据库 , 通讯网络响应时间 ;

并发用户 , 系统吞吐量 , 系统响应时间的关系 : 系统性能的拐点 , 也是性能测试的主要目的

资源利用率

查看系统占用的情况分析资源瓶颈 , 例如: 服务器: CPU , 内存 , 磁盘 , 网络 .... ;

性能测试关注点

性能测试人员

对于性能测试人员 , 重点工作 在 测试场景的设计 , 脚本的开发设计 , 以及性能缺陷的排查和定位 (例如:性能调优: 例如,mysql数据库里不应该存在太多的select*这样的sql)

性能测试分类

基准测试

基准测试(Benchmark Testing) 又称 单用户测试 , 主要用来检测 被测系统在较低 压力下的运行状况, 并记录相关测试

(对系统施加一定压力 , 获取系统在单用户运行情况下的各项性能指标, 为多用户并发测试等场景提供参考)

并发测试

并发测试 (Concurrency Testing) 用来评估系统的某些操作同时发生时的性能表现, (例如:某个功能被多个用户同时操作时的性能表现)

通过并发测试 ,可以获得系统在多用户并发操作时的性能指标, 还可以发现并发条件下才发生的问题: 如内存泄漏 , 线程锁,资源争用...

负载测试

负载测试(Load Testing) 用于评估系统在预期的不同负载下的行为 , 通过逐步增加的方式来确定系统的处理能力, 通过负载测试能获取 系统能达到的峰值指标

主要用于: 系统性能验证 , 性能诊断 , 性能调优等场景

例如: 逐步一点一点来加压力: 10 , 100 , 1000 , 2000 .... 需要保证系统性能正常的情况下, 测试出系统能承受的最大负载量

例如: 系统的响应时间<2s , 那么 一点一点加压, 来测 , 10 , 100 , 1000 , 2000 , 最后 10000 , 在超过10000后 ,系统的响应时间就>2s了 , 那么系统的最大负载量是 10000

压力测试

压力测试(Stress Testing) : 用于评估系统在高于预期 ,高于指定容量负载需求 或 低于最少需求资源的条件下的行为 ;

压力测试也是通过 逐步增加系统负载的方式 , 使得系统的 某些资源达到饱和甚至失效 , 从而发现那些只在高负载情况下出现的问题 : 同步问题 , 内存泄漏.....

压力测试也能找出系统 的 性能拐点 , 获取系统所能提供的最大服务级别(系统所能承受的最大压力)

压力测试主要用于: 性能诊断, 性能调优 , 容量规划等场景 ;

负载测试和压力测试的区别

  1. 负载测试是在保证性能指标的情况下测试出系统能承受的最大负载量 ;

  2. 压力测试时测试系统性能的能达到的极限状态

例如: 系统要求2s内响应完成 , 那么一点一点加压到,访问量大于 10000时 , 系统的响应速度变长了 , 那么 系统能承受的最大访问量是 10000 (负载测试) ;

当系统访问量20000 , 系统需要 5s 响应 , 当系统访问量 30000时 , 系统响应要10s , 当访问量> 30000时 , 系统崩溃或无法做出响应了 , 那么 系统能达到极限访问量是 30000 (压力测试)

稳定性测试

在基准测试的基础上 , 执行较长的时间测试 , 来检查系统的稳定性 通常在 3*24小时以上 ;

JMeter

元件作用域和执行顺序
作用域

在JMeter中 , 元件的作用域由测试计划的树形结构中的元件父子关系确定

执行顺序

  1. 取样器元件内组件不依赖 其他元件就可以执行 , 所以取样器不存在作用问题

  2. 元件作用域值针对他的子节点有作用

  3. 其他元件作用域默认根据测试计划中树形结构来定

JMeter组件

线程组

HTTP Cookie管理器像Web浏览器一样存储和发送Cookie , 如果HTTP请求并且响应包含cookie , HTTPcookie管理器 , 就会自动挡个存储cookie , (自动存储并发送)

  1. 每个JMeter 线程都会拥有自己的cookie存储区 ; (所以测试使用cookie的网站 , 每个Jmeter线程都会拥有自己的cookie存储区)
HTTP请求默认值

在HTTP请求默认值里的填写默认值 , 后面 HTTP取样器里如果有选项里没有值 , 那么就用默认值 ;

HTTP信息头管理器

在HTTP信息头管理器 里添加内容 , 后面 取样器发送请求时 , 会在请求头里携带上 内容 ;

在HTTP信息头管理器里添加 了对应的内容后 , 后面博客列表测试 的请求头里也带有 对应的内容 , 同时 博客列表页测试也 测试通过了

作用域
用户定义的变量

可以定义变量, 在取样器里 通过 ${变量名} 来引用变量 ;

发送json参数请求

  1. 发送json参数的请求 , 不仅需要将 参数写在 消息体数据 里

  2. 还需要在请求头里 添加 Content-ype : application/json , 说明 参数是json数据

此时 返回的响应数据里 就是 success

JSON提取器

接口返回响应后 , 通过提取返回值对应的字段 , 然后用于其他接口 (作为其他接口的参数)

JSON操作符
复制代码 
$          表示根元素
@          当前元素
*          通配符,所有节点
..         选择所有符合条件的节点
.<name>    子元素 
['<name>' (,'<name>')]      括号表示 子元素或子元素列表
[<number> (,<number>)]       数组引用或索引列表
[start : end ]              数组切片操作符
[?(<expression>)]          过滤器表达式, 表达式不许评估为布尔值 ;

后面就可以使用前面JSON提取器提取的数据

提取器的作用域

如果 多个接口 响应的数据里有 符合JSON取样器里的 JSON提取字段 , 那么 后面的数据会覆盖掉前面的数据

当提取器 例如: token : .data , 在 取样器1里 提取到 数据 11 , 后面的取样器2 , 就可以通过 {token} , 获取到 11 这个数据 ,

如果此时 取样器2 的响应里数据里 也满足 .data的JSON提取 数据 = 22 , 那么 token的值就会被覆盖掉 , 后面取样器 3里 拿的 {token} 的值就是 22 ;

将提取器 移动到 登录接口里 , 这样 只会获取 登录接口测试的 , 不会在其他接口也提取 ;

JSON断言

发送请求成功 , http响应码为 200 , 只能表示请求发送成功 , 不代表 接口一定请求成功 ,

JSON断言 ,可以用来断言 接口响应数据是否 符合预期

JSON断言的 匹配和JSON提取器的语法格式一样

例子: 给登录接口 测试 做 json断言

  1. 如果 不勾选选 Additionally assert value , 添加断言值(匹配断言值) , 可以用来 判断 json提取的字段是否存在 (如果勾选 , 表示 必须 添加 Expected Value 预期的断言值) ;

  2. 如果 不勾选正则匹配 , 那么 预期断言值 必须 完整 (精准匹配)

  3. 如果 选择 正则匹配 , 那么 预期断言值 就可以使用 正则表达式来匹配 ;

查看线程状态

通过点击 右上角的 感叹号 , 可以看到 线程的状态 ;

  1. 执行运行后 , 可以看到 5个线程的运行状态 ;

  2. 可以看到 , 5个线程是陆续执行的 , 谁先准备好谁先执行 ;

同步定时器 (集合器)

为了达到并发的效果 , 需要添加同步定时器

  1. 配置的数量 需要注意 , 不要 超过线程组的 线程数量 (因为, 是需要准备好的线程数量 >= 配置数量 才会一起发送请求 ,

    例如: 配置数量为 4 , 如果 线程组的线程数量只有 3个 , 那么运行后 , 准备好的线程数量一直都是 3个 , 小于 配置数量4 , 就一直等待 , 直到准备的线程数量 >= 4 , 才会开始发送请求)

  2. 如果 配置的数量小于 线程组的线程数量 , 需要将 线程组的循环执行打开 (例如: 配置的数量 为 2 , 线程组的线程数量是 3 , 运行后 ,此时 准备好了 3个线程 , 因为同步定时器配置的数量是2 , 所以先同步进行 2个线程 , 此时剩下一个线程 , 只有1个线程准备好了 , 1 < 配置的数量2 , 需要等待 , 直到 准备好的线程数量 >=2)

聚合报告

  1. Samples : 发起的http请求调用数 (这里线程组有5个线程, 所以每个测试样本都有5个)

  2. Average : 平均响应时间 , 单位毫秒

  3. 中位数 : 请求调用响应时间的中间值 , 单位毫秒

  4. 90%Line : 90%请求调用的响应数据 , 毫秒

  5. 95%Line : 95%请求调用的响应数据 , 毫秒

  6. 99%Line : 99%请求调用的响应数据 , 毫秒

  7. Min : 请求调用的最小响应时间 , 毫秒

  8. Max: 请求调用的最大响应时间 , 毫秒

  9. Error%: 调用失败的请求占比 , 调用失败 一般指 响应断言失败 或 请求调用出错 ;

  10. KB/sec : 每秒 网络传输的流量大小 , 单位为KB ; (用来衡量网络传输的大小 来衡量网络的吞吐量)

CSV数据文件设置

在登录接口, 手动配置了用户名和密码为固定的username和password参数 ;

可以通过CSV数据文件的方式 来提供 数据作为参数 ;

通过excel打开csv数据文件: 同时数据就这样写 : username读取的就是第一列 , password读取的就是第二列

运行结果

因为admin 账号不存在 , 所以第二个线程拿到的username和password是错误的 , 所以第二个线程的测试都报错 ;

事务控制器

JMeter事务控制器 的作用主要用于测试执行嵌套测试元素所花费的总时间 ; (相当于模拟用户进行一系列操作的测试)

  1. 如果不添加事务控制器 , 那么就是一个接口一个事务

  2. 添加事务控制器后 , 将多个接口放在同一个事务里, 作为同一个事务 ;

JMeter其他监听器插件

将插件管理的jar包添加到ext目录底下
添加插件

其他插件(看情况来装)

Stepping Thread Group

梯度测压线程组

  1. This group will start: 启动多少个线程 , (同线程组中的线程数一样

  2. First,wait for : 等待多少秒后开始压测 , 默认0

  3. Then start : 一开始 有多少个线程 , 一般默认0

  4. Next,add : 下一次增加多少个线程数

  5. threads every : 当前运行多长时间再次启动线程 , 即每一次 线程启动完成后的持续时间 ;

  6. using ramp-up: 启动线程的时间 , 如果设置为 5秒 , 表示每次启动线程都持续5秒 ;

  7. thenhold loadfor : 线程全部启动完之后持续运行多长时间 ;

  8. Finally , stop / threads every , 多长时间释放多少个线程 ; (设置为5 个 和 1秒 , 表示持续负载结束后 , 每一秒释放5个线程)

例如: 总共20个线程 , 开始每隔3秒钟 启动5个线程 ;

线程全部启动后 持续测试60秒 ,

后面 每个1秒 结束5个线程 ;

添加监听

测试完后可以在结果数看结果树

Response Times Over Time

Response Times Over Time 主要用于监听整个事务运行期间的响应时间 ; 在测试过程中 , 帮助分析响应时间的实时平均值和整体响应时间的走向

Transaction per Secound (TPS)

TPS 监听器用来 分析系统吞吐量 ; 每秒事务数 , 表示一个客户机向服务器发送请求后服务器做出的反应 , 这个指标反映系统在同一时间内处理业务的最大能力 ; tps越高, 系统处理能力越高 ;

测试报告

Jmeter测试报告是一个全面详细的文档 , 提供测试执行结果的详细信息 ;

生成性能测试报告的命令

复制代码 
Jmeter -n -t  脚本文件 -l 日志文件 -e -o 目录
 
-n : 无图形化运行 
-t : 被运行的脚本
-l : 将运行信息写入日志文件 , 后缀为jtl的日志文件 ;
-e : 生成测试报告
-o : 指定报告输出目录

生成测试报告

jmeter -n -t 登录接口测试.jmx -l rizhi1.jtl -e -o F:\测试\日志

1. 日志文件 ,

2. 测试报告

3. 打开index.html文件

这就是jmeter性能测试报告 ;

错误率(可靠性)

高并发情况下,系统是否能正常处理业务 ; (一般情况下可靠性达到4个9 , 5个9)

99.99%可靠 , 99.9999%可靠 ;

相关推荐
知识分享小能手1 小时前
R语言入门学习教程，从入门到精通，R语言入门(3）
开发语言·学习·r语言
happymaker06261 小时前
Spring学习日记——Day01(简单配置使用Spring，手写Spring的简单工厂模式)
java·学习·spring
HalvmånEver12 小时前
MySQL的索引
android·linux·数据库·学习·mysql
金色光环13 小时前
【DSP学习】DSP28335 点亮LED
嵌入式硬件·学习·dsp开发
我是发哥哈13 小时前
跨AI模型生成视频的五大维度对比：选型避坑指南
大数据·人工智能·学习·机器学习·chatgpt·音视频
北顾笙98015 小时前
LLM学习-day05
学习
我命由我1234516 小时前
Windows 操作系统 - Windows 查看架构类型
运维·windows·笔记·学习·系统架构·运维开发·系统
小新同学^O^16 小时前
简单学习--＞ Selenium自动化测试
学习·selenium·测试工具
GEO从入门到精通17 小时前
2026年GEO课程的学习重点更新了吗？
人工智能·学习·seo·geo·aiseo·市场部
热门推荐
01GitHub 镜像站点02Codex 接入 DeepSeek API 完整配置文档03零基础教你claude code 接入 deepseek V404要裂开了！ChatGPT要手机号验证了？注册Codex要求验证电话号码怎么办？2026年登陆Codex要手机号验证的解决办法05CC-Switch & Claude 基于 Linux 服务器安装使用指南06Dirtyfrag漏洞：我花了一下午搞清楚这个Linux内核提权漏洞到底在搞什么07【AI】2026 年具身智能模型和世界模型总结08Windows端Codex接入第三方模型（DeekSeek，BaiLian)092026年Codex如何解决手机号码登陆验证的问题？10裂开！ChatGPT 居然开始要手机号验证，附详细解决方法