课程：B站大学
记录软件测试-性能测试学习历程、掌握前端性能测试、后端性能测试、服务端性能测试的你才是一个专业的软件测试工程师

---

# 基准测试 建立系统性能的基线数据，用于后续优化或版本对比。 关键特点​​：

​​标准化场景​​：在固定硬件、软件配置和测试条件下运行。
​​量化指标​​：测量响应时间、吞吐量、CPU/内存占用等。
​​对比性​​：常用于比较不同版本、配置或竞品的性能差异。
​​典型场景​​：

数据库查询速度对比（如MySQL vs PostgreSQL）。
新版本API接口的响应时间是否优于旧版本。
硬件选型时测试不同服务器的处理能力。
​​工具举例​​：

​​Sysbench​​（数据库基准测试）
​​Geekbench​​（CPU/GPU性能测试）
​​JMeter​​（HTTP请求基准测试）

负载测试

评估系统在预期或更高负载下的性能表现，识别瓶颈。
关键特点​​：
​​模拟真实用户​​：逐步增加并发用户数或请求量。
​​关注阈值​​：测试系统在峰值负载下的表现（如最大支持1000并发用户）。
​​性能指标​​：TPS（每秒事务数）、错误率、资源利用率等。
​​典型场景​​：
电商网站在促销期间能否承受10万用户同时访问。
API服务在每秒5000请求时的延迟是否达标。
数据库在大量写入操作时的吞吐量极限。
​​工具举例​​：
​​JMeter​​、​​Locust​​（模拟用户负载）
​​Gatling​​（高并发测试）
​​k6​​（云原生负载测试）

稳定性测试

验证系统在长时间运行下的可靠性，发现内存泄漏、资源耗尽等问题。
关键特点​​：
​​长时间运行​​：持续施压数小时甚至数天。
​​监控异常​​：关注内存增长、线程阻塞、日志错误等。
​​恢复能力​​：测试故障后是否自动恢复。
​​典型场景​​：
服务器连续运行7天后是否出现内存泄漏。
数据库在持续写入后是否因连接池耗尽崩溃。
微服务在长时间高负载下是否产生未处理的异常。
​​工具举例​​：
​​JMeter​​（长时间压力测试）
​​Prometheus + Grafana​​（监控资源泄漏）
​​Chaos Mesh​​（注入故障测试恢复能力）

维度	基准测试	负载测试	稳定性测试
目标	建立性能基线	找出系统负载极限	验证长期可靠性
测试时长	短（分钟级）	中（小时级）	长（天级）
关键指标	响应时间、吞吐量	最大并发数、错误率	内存/资源泄漏、错误累积
适用阶段	开发早期/版本迭代	上线前性能验证	上线前/运维期

负载测试曲线图

• ​​横轴（X轴）​​：​​并发用户数​​（负载量），从低到高递增。
• ​​纵轴（Y轴）​​：
• ​​Utilization (U)​​：系统资源利用率（如CPU、内存），绿色曲线。
• ​​Throughput (X)​​：系统吞吐量（每秒处理请求数），紫色曲线。
• ​​Response Time ®​​：请求响应时间，红色曲线。

区域	特征	性能表现
轻载区	并发用户数较少（左侧）	- 资源利用率（U）线性增长 - 吞吐量（X）快速上升 - 响应时间（R）稳定低位
最佳并发点	The Optimum Number of Concurrent Users（图中标注点）	- 吞吐量（X）达到理想值 - 响应时间（R）仍可控 - 资源利用率（U）未饱和
重载区	并发用户数超过最佳点（Heavy Load）	- 资源利用率（U）接近瓶颈 - 吞吐量（X）增速放缓 - 响应时间（R）明显上升
最大并发点	The Maximum Number of Concurrent Users（图中临界点）	- 吞吐量（X）达到峰值 - 响应时间（R）陡增 - 资源利用率（U）饱和（100%或更高）
瓶颈区	超过最大并发点（右侧Buckle Zone）	- 资源饱和：系统过载 - 吞吐量下降：请求堆积/超时 - 用户体验恶化：高延迟或错误
​​故障表现​​：
超过最大并发点后，系统可能出现：

1. 错误率上升（如HTTP 503）
2. 资源耗尽（数据库连接池满、线程阻塞）
3. 响应时间不可接受（用户流失）。

测试策略：

1. 通过逐步增加并发用户数，定位图中的​​最佳点​​和​​最大点​​。

​​监控指标​​：

1. 重点关注吞吐量拐点和响应时间突变位置。

其他测试策略

并发测试

验证系统在​​多用户同时操作​​时的功能正确性和资源竞争问题（如死锁、数据脏读）。
关键特点​​
​​模拟真实并发​​：多个线程/用户同时执行相同或不同操作。
​​关注点​​：
数据一致性（如库存超卖）
资源竞争（如数据库连接池耗尽）
线程安全（如全局变量冲突）
​​测试场景​​：
100个用户同时提交订单
多线程并发修改同一数据库记录
​​工具示例​​
​​JMeter​​（线程组模拟并发用户）
​​LoadRunner​​（虚拟用户并发控制）
​​Gatling​​（高并发场景设计）

压力测试

评估系统在​​超过正常负载​​时的表现，定位崩溃临界点及恢复能力。
​​关键特点​​
​​极端条件​​：持续施压直至系统崩溃（如CPU 100%、内存耗尽）。
​​关注点​​：
系统崩溃阈值（如最大支持5000并发）
错误处理机制（如熔断降级）
故障恢复时间（如自动重启后恢复速度）
​​测试场景​​：
短时间内涌入10倍正常流量
强制关闭服务后验证自愈能力
​​工具示例​​
​​JMeter​​（阶梯式加压）
​​k6​​（混沌工程压力注入）
​​Chaos Mesh​​（模拟网络中断、资源枯竭）

容量测试

确定系统在​​长期运行​​下的最大承载能力，为扩容提供数据支撑。
关键特点​​
​​可持续负载​​：长时间维持高负载（如24小时80%资源占用）。
​​关注点​​：
资源泄漏（如内存泄漏、线程堆积）
性能衰减（如数据库查询变慢）
扩展性建议（需增加多少服务器）
​​测试场景​​：
持续7天模拟2000并发用户
数据库每日写入100万条记录后的性能变化
​​工具示例​​
​​Locust​​（长时间稳定负载模拟）
​​Prometheus + Grafana​​（监控资源泄漏）
​​阿里云PTS​​（云环境容量规划）

性能指标的介绍

响应时间

定义：
响应时间指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的结果，整个过程所耗费的时间。

【组成】：
响应时间 = 网络时间 + 应用程序处理时间

并发用户数据

并发测试的用户数（并发：同时运行请求）

• 系统用户数​​：系统注册的总用户数据
• 在线用户数​​：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求
• 并发用户数​​：某一物理时刻同时向系统提交请求的用户数

吞吐量

定义：吞吐量（Throughput）指的是单位时间内处理的客户端请求数量，直接体现软件系统的性能承载能力。

1. 从业务角度来看，吞吐量也可以用“业务数/小时”、“业务数/天”、“访问人数/天”、“页面访问量/天”来衡量。
2. 从网络角度来看，还可以用“字节数/小时”、“字节数/天”等来衡量网络的流量。
3. 从技术指标来看，可以用每秒事务数（TPS）和每秒查询数（QPS）来衡量服务器具体性能处理能力。

吞吐量TPS

TPS:每秒事务数：单位时间内系统处理的客户端请求的事务次数
计算​​：
TPS = 并发数 / 平均响应时间
​​事务​​：
事务即业务请求，对应界面上一个或多个操作。以支付请求为例：

• 包含服务器查询用户余额
• 支付安全校验等多个请求
• 最终定位到服务器对应的业务请求代码（可能为单段或多段代码）
  在jmeter中可以用事务控制器组合一系列接口请求为一个事务，子事务上有父事务等。
  jmeter示例：
  测试计划
  └── 事务控制器（名称：完整下单事务）
  ├── HTTP请求 1 (登录接口)
  ├── HTTP请求 2 (添加购物车)
  └── HTTP请求 3 (提交订单)

吞吐量QPS

TPS:每秒查询数：一个QPS是一个接口请求
应用场景：
控制服务器每秒处理指定请求数。如：控制服务器达到每秒60QPS，服务器的性能各项性能指标是否正常（服务器处理能力一个重要指标）。

点击数

定义：点击数是衡量Web服务器处理能力的一个重要指标。
​​提示​​

• 点击数不是通常认为的访问一个页面就是1次点击数，而是该页面包含的元素（图片、链接等）向服务器发出的请求数量。
• 通常用每秒点击次数（Hits per Second）指标来衡量Web服务器的处理能力。
  大白话：静态资源请求数量==点击数
  ​​注意​​
  只有Web项目才有此指标。
  主要用于衡量web服务器： Apache HTTP Server​，Nginx​，LiteSpeed​，Caddy​， Tomcat (Apache Tomcat)​
  目前主流的有老项目：Tomcat，新项目专用：Nginx。

错误率（异常率）

定义：错误率指系统在负载情况下，失败业务的概率。
计算公式为：
​​错误率 = (失败业务数 / 业务总数) × 100%​​
​​提示​​
不同系统对错误率要求不同，但一般不超过千分之五（≤0.5%）；
稳定性较好的系统中，错误率应由超时引起（即表现为超时率）。
错误率大多数是超时，资源耗光导致，所以有资源，扩容，搭建好的集群环境非常重要。

资源利用率

定义：是指系统各种资源的使用情况，一般用“资源的使用量/总的资源可用量×100%”形成资源利用率的数据。
大多数情况下：一个服务器上的基准
通常，没有特殊需求的话：
建议CPU不高于80%（±5）；
内存不高于80%；
磁盘不高于90%；
网络不高于80%。
若高于以上数值，则可能存在问题

性能测试流程

• 性能测试需求分析
• 性能测试计划及方案
• 性能测试用例
• 测试脚本编写/录制
• 建立测试环境
• 执行测试脚本
• 性能测试监控
• 性能分析和调优
• 性能测试报告总结
  性能测试流程：无他，唯手熟尔

性能测试需求分析

第一要点：
● 熟悉被测系统
○ 熟悉系统的业务功能
○ 熟悉系统的技术架构
第二要点
● 明确性能测试内容
○ 从业务角度，挑选核心业务进行测试
○ 从技术角度，挑选逻辑复杂度高、数据量大的业务进行测试
第三要点
● 确定测试策略
○ 负载测试、稳定性等
第四要点
● 确定性能测试指标
○ 有需求：按照需求来测试
○ 没有需求：同类型软件对比，对未来数据进行预估

性能测试计划及方案

性能测试实施文档也是一份重要的文档
主要内容：

• 项目背景 – 简介
• 测试目的
• 测试范围 – 对于需求分析中的性能测试内容
• 测试策略–对应需求分析中的测试策略
• 风险控制–技术风险
• 交付清单
• 进度与分工

性能测试用例

要素：用例标题、用例编号、用例预制条件、用例步骤、用例预期结果、用例实际结果

测试脚本编写/录制

1、测试脚本编写/录制​​
说明：性能测试用例编写完成以后，接下来就需要结合用例的需要，进行测试脚本的编写工作。
提示：录制或编写，根据不同的工具要注意代码冗余。

​2、建立测试环境​​
说明：在进行性能测试之前，需要先完成性能测试环境的搭建工作，测试环境一般包括硬件环境、软件环境及网络环境。
提示：一般情况下可以要求运维和开发工程师协助完成。

​​3、 执行测试脚本​​
说明：先保证脚本调试通过之后，才能进入正式压测阶段。
执行测试脚本时，要先进行性能运行场景的设置，再运行脚本。

性能测试报告

报告无需多说，文档，但也很重要，做为性能最终结果也是优化的重要依据

性能测试类型：

总结下性能测试理论知识:

• 响应实践：从客户端发送请求到服务器响应的全部时间=应用程序处理时间和网络事件之和=
• 并发数：同一时刻在向服务器发送请求的用户数
• 吞吐量：单位时间内服务器处理请求的数量
• QPS:每秒查询数（每秒请求数）
• TPS：每秒事务数，TPS=并发数（在同一秒内发送的请求数）/响应时间（所有请求的平均响应时间）
• 错误率：超时，资源耗尽导致的500请求（性能负载的场景下，失败事务数占总的事务数的比例）
• 点击数：web项目，静态资源请求web服务器(nginx、tomact)的次数等
• 资源利用率：主要是指CPU均值，磁盘IOPS峰值，内存增长值

实践是检验真理的唯一标准