性能测试（一）—— 概述、策略、指标、流程_性能测试-策略理解-优快云博客

本文详细介绍了性能测试的各个方面，包括为何进行性能测试、性能测试的定义及其目的，区分了性能测试与功能测试的关系。接着，阐述了基准测试、负载测试和稳定性测试等策略，并列举了响应时间、并发数、吞吐量等关键性能指标。此外，文章还梳理了性能测试的完整流程，从需求分析到测试报告总结，每个步骤都详尽无遗。通过对性能测试的深入理解，有助于提升系统性能并确保其在高负载下的稳定运行。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一、性能测试概述

1、为什么要进行性能测试？

在真实项目商用时，需要大量的用户进行使用，因此需要模拟大量用户的使用场景
可以提升薪资

2、性能测试的概念

2.1 什么是性能？

性能：就是软件质量属性中的“效率”特性

效率特性：

时间特性：指系统处理用户请求的响应时间
资源特性：指系统在运行过程中，系统资源的消耗情况
CPU
内存
磁盘IO（磁盘的写入Input和读取Output，简称IO）

2.2 什么是性能测试？

概念：使用自动化工具，模拟不同的场景，对软件各项性能指标进行测试和评估的过程就是性能测试。

1. 后台处理程序的性能（代码性能）
2. 中间件、数据库、架构设计等是否存在瓶颈
3. 服务器资源消耗（CPU、内存、磁盘、网络）

中间件：是提供系统软件和应用软件之间连接的软件。如： Tomcat、 Apache...

2.3 性能测试目的

评估当前系统能力
- 例如：验收第三方提供的软件
- 例如：获取关键的性能指标，与其他类似产品进行比较
寻找性能瓶颈，优化性能
评估软件是否能够满足未来的需要

3、性能测试与功能测试

3.1 焦点不一样

功能测试：验证软件系统操作功能是否符合产品功能需求规格，主要焦点在功能（正向、逆向）；
性能测试：验证软件系统是否满足业务需求场景，主要焦点是业务场景的满足(时间、资源)；

3.2 关系

功能测试和性能测试是相辅相成的，对于一款优秀的软件产品来讲，它们是不可减少的2个重要测试环节；
注意：一般新项目中，先功能测试通过后，再进行性能测试。

二、性能测试策略

1、性能测试策略

1.1 基准测试

基准测试：

狭义上讲：也是单用户测试，测试环境确定以后，对业务模型中的重要业务做单独的测试，获取单用户运行时的各项性能指标。（进行基础的数据采集）
广义上讲：是一种测量和评估软件性能指标的活动。你可以在某个时刻通过基准测试建立一个已知的性能水平（称为基准线），当系统的软硬件环境发生变化之后再进行一次基准测试以确定那些变化对性能的影响。

基准测试数据的用途：
1. 为多用户并发测试和综合场景测试等性能分析提供参考依据
2. 识别系统或环境的配置变更对性能响应带来的影响
3. 为系统优化前后的性能提升/下降提供参考指标

1.2 负载测试

说明：通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足系统的性能指标情况下，系统所能够承受的最大负载量的测试。

负载：指向服务器发送的请求数量，请求越多，负载越高

注意：负载测试关注的重点是逐步增加压力

1.3 稳定性测试

说明：稳定性测试是指，在服务器稳定运行（用户正常的业务负载下）的情况下进行长时间测试，并最终保证服务器能满足线上业务需求。时长一般为1天、一周等。

1.4 其他测试策略

性能测试中，测试策略其实有很多种，但是掌握基础的用法后，其他不同名称的测试策略只是基础用法的一个变形用法。

并发测试：并发测试是指在极短的时间内，发送多个请求，来验证服务器对并发的处理能力。如：抢红包、抢购、秒杀活动等。
压力测试：压力测试是在强负载（大数据量、大量并发用户等）下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。
容量测试：关注软件的极限压力下的各个极限参数值，例如：最大TPS，最大连接数，最大并发数，最多数据条数等。

三、性能测试指标

1、性能测试指标介绍

1.1 什么是指标

说明：一些经过运算得出的结果，来衡量某种操作性能统称；比如：错误率 0.5%

1.2 性能指标

1. 响应时间
2. 并发数
3. 吞吐量
4. 点击数
5. 错误率
6. 资源利用率
7. PV和UV

2、常用性能指标

2.1 响应时间

说明：响应时间指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的结果，整个过程所耗费的时间。
组成：响应时间 = 网络时间 + 应用程序处理时间

2.2 并发数

说明：并发测试的用户数
扩展：

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

2.3 吞吐量

说明：吞吐量（Throughput）指的是单位时间内处理的客户端请求数量，直接体现软件系统的性能承载能力
注意：
        1. 从业务角度来看，吞吐量也可以用“业务数/小时”、 “业务数/天”、 “访问人数/天”、 “页面访问量/天”来衡量
        2. 从网络角度来看，还可以用“字节数/小时”、 “字节数/天”等来衡量网络的流量
        3. 从技术指标来看，可以用每秒事务数（TPS）和每秒查询数（QPS）来衡量服务器具体性能处理能力

TPS
说明： Transactions Per Second，每秒事务数 (单位时间内系统处理的客户端请求的事务次数)
计算： TPS = 并发数/平均响应时间
事务：就是业务请求，对应一个或者多个操作。如支付请求，包括服务器查询用户余额，支付安全校验等多个操作。一个业务请
求发送给服务器后，最终会定位到服务器对应的业务请求的代码，既有可能是一段代码也有可能是多段代码。

QPS
说明： QPS(Query Per Second)每秒查询数
应用：控制服务器每秒处理指定请求数（如：控制服务器达到每秒60QPS，服务器的性能各项性能指标是否正常）。（衡量web服务器处理能力一个重要指标）

2.4 点击数

说明：点击数是衡量Web服务器处理能力的一个重要指标。
提示：
1. 点击数不是通常一般人认为的访问一个页面就是１次点击数，点击数是该页面包含的元素（图片、链接、框架等）向Web服
务器发出的请求数量。
2. 通常我们也用每秒点击次数（Hits per Second）指标来衡量Web服务器的处理能力。
注意：只有web项目才有此指标。

2.5 错误率

说明：错误率指系统在负载情况下，失败业务的概率。错误率＝(失败业务数/业务总数)*100%。
提示：
1. 不同系统对错误率要求不同，但一般不超过千分之五；
2. 稳定性较好的系统，其错误率应该由超时引起，即为超时率。

2.6 资源利用率

说明：是指系统各种资源的使用情况，一般用“资源的使用量/总的资源可用量×100%”形成资源利用率的数据。
提示：通常，没有特殊需求的话
        1). 建议CPU不高于80%(±5)
        2). 内存不高于80%
        3). 磁盘不高于90%
        4). 网络不高于80%

四、性能测试流程

1、性能测试流程

1. 性能测试需求分析
2. 性能测试计划及方案
3. 性能测试用例
4. 测试脚本编写/录制
5. 建立测试环境
6. 执行测试脚本
7. 性能测试监控
8. 性能分析和调优
9. 性能测试报告总结

提示：使用不同的性能测试工具时，主要流程是不变的。

1.1 性能需求分析

说明：性能需求分析是整个性能测试工作开展的基础，性能需求分析做的好不好直接影响到性能测试的结果。

性能需求分析的目标：
1. 熟悉被测系统

熟悉被测系统的业务功能
熟悉被测系统的技术架构

2. 明确性能测试内容

从业务角度明确测试内容
确定关键业务。即：用户使用频率较高的业务功能
从技术角度明确测试内容
如：通常逻辑复杂度较高的业务也是CPU密集运算较大的地方，考量服务器CPU在预定性能指标下是否达标
如：通常数据量较大的业务很占用系统内存，考量服务器内存在预定性能指标下是否达标

3. 明确性能测试策略

负载测试
稳定性测试
并发测试

4. 明确性能测试的指标

无明确需求指标
通过查找相关资料，和类似的系统对比，以及对未来流量的预估，确定性能测试需求的指标
有明确需求指标
例如，类似如下指标
下订单业务并发20个用户
平均响应时间要小于等于3s
事务成功率为100%
CPU使用率小于等于85%
只需要根据执行分析结果与预期指标做对比，如果有不满足的，就需要分析问题所在

1.2 性能测试计划及方案

说明：性能测试实施第一份文档，也是最重要的一份文档。
主要内容：
        1. 项目背景
        2. 测试目的
        3. 测试范围
        4. 测试策略
        5. 风险控制
        6. 交付清单
        7. 进度与分工

1.3 性能测试用例

1.4 测试脚本编写/录制

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

1.5 建立测试环境

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

1.6 执行测试脚本

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

1.7 性能测试监控

性能监控就是监控服务器的各项性能指标。例如：监控CPU、内存、网络、 TPS、磁盘IO等

1.8 性能分析和调优

说明：性能测试分析人员经过对结果的分析以后，有可能提出系统存在性能瓶颈。
提示：
        1. 调优人员(开发人员、数据库管理员、系统管理员、网络管理员、性能测试分析人员)相关人员对系统进行调整;

        2. 验证-性能测试人员继续进行第二轮、第三轮……的测试，与以前的测试结果进行对比，从而确定经过调整以后系统的性能是否有提升。

注意:
系统调优由易到难的先后顺序如下：
        1. 硬件问题
        2. 网络问题
        3. 应用服务器、数据库等配置问题
        4. 源代码、数据库脚本问题
        5. 系统构架问题