性能测试详解：从基本概念到实战指南

性能测试详解：从基本概念到实战指南

引用

CSDN

1.

https://blog.csdn.net/woshihlf/article/details/145841308

性能测试是软件测试领域的重要组成部分，主要用于评估系统在特定负载下的表现。本文将详细介绍性能测试的基本概念、常用指标、测试类型、用例选取原则、测试流程、常见问题及解决方案等，帮助读者全面了解性能测试的相关知识。

性能测试详解

基本概念

请求（Request）

客户端通过网络发送请求，服务端接收并处理请求，生成结果后返回给客户端。

事务（Transaction）

事务由一个或多个请求组成，通常用于表示一个完整的业务操作（如用户下单需要多个请求完成）。

常用性能指标

请求响应时间（RT）

从客户端发起请求到接收到响应结果的时间。

• min：最小响应时间。
• avg：平均响应时间。
• tp99：99%的请求在该时间内完成。
• tp999：99.9%的请求在该时间内完成。
• max：最大响应时间。

成功率与失败率

• 成功率= 请求成功数 / 请求总数 * 100%。
• 失败率= 请求失败数 / 请求总数 * 100%。

吞吐量与吞吐率

• 吞吐量：性能测试中网络传输的数据总量。
• 吞吐率= 吞吐量 / 传输时间。

并发用户数

同一时刻与服务器交互的虚拟用户数，反映系统的并发处理能力。

TPS（Transactions Per Second）

每秒钟系统处理的请求或事务数量，是衡量系统处理能力的重要指标。

资源利用率

服务器资源的使用程度，包括：

• CPU使用率：一般达到70%以上时，服务接近饱和。
• 内存使用率：需关注内存变化，防止内存泄漏。
• 磁盘繁忙度：磁盘的繁忙程度。
• 磁盘I/O：物理磁盘的读写速度。
• 网络流入/流出量：千兆网卡最大速率为125MB/s，万兆网卡为1250MB/s。
• 负载：由CPU、内存、I/O消耗构成，任意一项过高都会导致负载攀升。

性能测试类型

性能测试（狭义）

验证系统在资源可接受范围内是否能达到预期性能。

负载测试

评估系统在超出日常访问压力下的性能表现，找到性能拐点。

压力测试

测试系统在接近崩溃的最大访问负载下的表现，定位系统缺陷和性能瓶颈。

稳定性测试

在一定压力下连续运行较长时间，验证系统的稳定性，常用于发现JVM内存回收问题。

配置测试

调整系统参数（如线程池大小、JVM内存配置等），找到最佳配置以提高系统处理能力。

性能测试用例选取原则

性能测试用例的选取应遵循以下原则：

• 核心业务模块：测试系统中最关键的业务功能。
• 高频使用模块：测试日常使用频率高、容易产生大并发量的功能。
• 大数据量操作模块：测试涉及大数据量操作的功能。
• 用户关注性能的模块：测试用户对响应时间等性能指标特别关注的功能。
• 代表性模块：排除业务逻辑近似的模块，选取最具代表性的功能。
• 资源争用模块：测试存在资源争用的业务场景。
• 混合场景：模拟真实系统运行的多业务混合场景。

性能测试的需求

业务根据系统在的阶段和系统特点，把压测需求主要分以下五大类，而根据具体情况实现的场景也不一样：

• 验证业务处理能力：在给定的软硬件条件下，系统能否具有预期的能力表现，比如新系统上线前性能评估
• 规划容量：关注在预期容量下需要多少软硬件资源来支撑，常见的是大促备战
• 瓶颈定位&性能调优：主要用于对系统性能进行调优，比如统上线运行一段时间后响应速度越来越慢，比如线下压测问题复现调优；
• 性能基准比较：常用于敏捷开发过程中，敏捷开发流程的特点是小步快走，快速试错，迭代周期短，需求变化频繁。很难定义完善的性能测试目标，也没有时间在每个迭代开展详细的性能测试，可以通过建立性能基线，通过比较每次迭代中的性能表现变化，判断迭代是否达到了目标
• 其它： 比如高可以用性、线下压测等

性能测试流程

需求调研

需求调研是性能测试的基础，目的是明确测试目标、业务场景和系统架构。

分析业务场景

• 场景特点：明确测试的业务场景（如秒杀、下单等），了解用户行为和操作流程。
• 场景流程：梳理业务流程（如从购物车到下单的完整流程）。
• 场景依赖：识别业务依赖的接口或系统，评估是否存在性能瓶颈，是否需要Mock。
• 入参特性：分析传入参数的特点（如参数大小、分布、是否重复使用等）。

分析系统架构

• 系统协议：明确系统交互协议（如HTTP、JSF等）。
• 存储架构：了解存储方式（如缓存、数据库分库分表等）。
• 网络架构：确认网络环境（如内网、外网、CDN等）。
• 集群架构：分析应用和缓存的集群架构（如分布式集群、负载均衡等）。
• 软件硬件情况：了解线上环境的软件版本、硬件配置和Docker设置。

分析数据架构

• 基准数据：确定测试场景的基础数据量。
• 参数化数据：根据业务场景设置压测参数，尽量接近真实情况。

调研输出

• 测试计划：明确测试周期和人力投入。
• 测试方案：包括业务场景、系统架构、数据架构、压测工具选择和测试场景建模。

测试准备

测试准备阶段是为性能测试搭建环境和准备数据。

环境准备

• 选择合适的发压机和服务器，避免影响正常的业务。
• 要保证发压机和服务器在同机房。
• 搭建与线上环境一致的测试环境，包括JDK版本、数据库、缓存、容器配置等。
• 如果使用线上环境，需与开发沟通压测服务器范围，并做好数据隔离和清理准备。
• 可以关注一下服务器的日志等级，这个对服务器性能有较大影响。

监控环境准备

• 配置监控工具（如UMP、MDC、秒级监控、Redis监控、数据库监控等）。
• 编写必要的监控脚本，确保详细监控数据的收集。

数据准备

• 准备基准数据（如1亿条查询数据）。
• 准备测试数据（如符合查询条件的参数）。

脚本及场景准备

• 编写测试脚本。
• 设置测试场景（如混合场景、负载测试、压力测试或稳定性测试）。

执行分析

执行分析阶段是实际进行压测并分析结果。

场景压测执行

• 先执行单个用例，然后压测少量数据，随后逐渐增大数据量。
• 先单个场景分别压测，后根据线上业务的场景比例，混合多场景进行压测。

压测数据收集

• 客户端：TPS、响应时间、成功率、失败率。
• 服务端：CPU、内存、网络、磁盘I/O、Load等。
• 应用性能：接口性能、JVM状态、Redis分片、数据库连接池等。

压测数据分析

• 分析压测结果
• 如果满足需求，评估是否存在优化空间或潜在风险。
• 如果不满足需求，根据监控数据定位问题（如JVM线程、Redis分片、数据库SQL等），进行调优后重新压测。

常见需求指标

• 请求服务器的TPS达到一定数值。
• 在规定响应时间内，TPS达到一定数值。

测试总结

测试总结阶段是对压测结果进行总结和评估。

搜集压测数据形成报表
制作通俗易懂的压测数据报表，便于项目相关人员理解。

基于压测数据给出性能测试结论

• 评估是否满足性能需求，如果不满足，分析原因并给出建议。
• 评估未来数据增长是否会影响系统性能。

基于数据给出风险点建议

• 识别性能压测中的风险点（如依赖接口性能较差时的影响）。

基于数据给出容量规划评估

• 根据压测数据和线上情况，评估满足业务需求的容量规划。

性能测试常见问题

压测线上环境时的注意事项

逐步增加压力

• 先跑1条数据查看系统响应。
• 再跑少量数据验证系统稳定性。
• 逐步增加压力，避免一次性高并发导致系统崩溃。

应用服务器CPU瓶颈排查

CPU消耗高的方法

• 检查是否有方法消耗大量CPU资源，尝试优化代码。

TPS压不上去

• 如果应用服务器无瓶颈，排查线程是否处于等待状态。
• 检查是否有线程锁、内存溢出等问题。

后端数据库问题

慢查询

• 检查数据库表是否有慢查询，如无索引导致响应慢。

数据库资源瓶颈

• 监控数据库的CPU和I/O使用情况，排查是否达到瓶颈。

后端缓存服务器问题

缓存瓶颈

• 检查缓存服务器是否达到性能瓶颈。

缓存失效

• 如果TPS规律性抖动，检查缓存失效时间或定时任务。

方法执行慢

序列化、解析XML等

• 检查是否有方法执行较慢，如序列化、解析XML等，尝试优化。

静态页面服务器问题

CPU瓶颈

• 如果静态页面服务器（非CDN）CPU有瓶颈，会影响整个页面的响应时间。

TPS不稳定

FGC（Full GC）

• 检查是否有频繁的Full GC，影响系统性能。

YGC（Young GC）

• 频繁的Young GC也会影响系统性能。

IO高峰

• 检查是否有IO高峰导致TPS不稳定。

TPS逐渐下降

线程锁

• 检查是否有线程锁导致性能下降。

内存溢出

• 检查应用是否有内存溢出问题。

缓存未命中

• 如果数据未走缓存，直接查询数据库，可能导致连接不释放。

日志级别与输出方式

日志级别

• Info和Error级别对TPS影响较大，适当调整日志级别。

日志输出方式

• 日志按大小分割等输出方式可能会影响TPS。

请求失败排查

常见失败原因

• 入参错误、JSF线程池耗尽、端口限制、应用线程池满、数据库线程池满等。

查看日志定位具体失败原因

服务器CPU使用不均衡

负载策略问题

• 检查负载均衡策略是否导致CPU使用不均衡。

系统特殊限制

CPU限制

• 部分系统可能在CPU超过80%时不再接受请求。

线程数限制

• 检查是否有请求线程数限制。

性能测试注意点

压测风险

• 线上限制：由于线上环境的某些限制（如第三方接口依赖、网络带宽等），可能无法达到预期的压测目标，导致压测结果不准确。
• 发压机与测试机的可控性：发压机和测试机应处于可控环境中，避免对集团业务造成影响，尤其是发压机的可靠性往往被忽略。需评估网络风险，确保压测不会对整体业务产生负面影响。
• 压测目标不明确：压测的目标可能是容量测试、技术分析或性能瓶颈点排查，需明确目标以制定合理的压测策略。

压测场景与业务相关性

• 业务场景分析：压测需基于实际业务场景，分析用户行为和使用路径，确保压测场景与业务需求高度相关。比如根据真实业务场景合理规划混合压测的场景比例。
• 全链路压测：针对全链路压测，需关注业务流量的分布和关键节点，确保压测覆盖所有关键业务场景。

压测工具与技术栈

• 工具选择：不同技术栈（如Linux、K8s、JCQ等）需使用对应的专业压测工具，而非通用工具（如JMeter）。网络测试、IO测试、磁盘的测试都有各自的工具，要善于利用。
• 官方测试框架：对于开源或云原生组件，应参考官方提供的性能测试框架和工具，确保压测的准确性和有效性。

压测结果分析

• 资源利用率：压测过程中需关注CPU、内存、I/O等资源的使用率，通常达到70%左右时，系统可能接近性能上限，继续加压可能导致系统不稳定。
• 性能瓶颈排查：通过压测结果分析，识别系统瓶颈（如消息队列中消息积压、消费能力不足等），并进行针对性优化。
• 架构问题：如果资源利用率未达到预期水平，可能表明系统架构或设计存在问题，需进一步排查和优化。

压测策略与优化

• 逐步排查与调优：压测是一个逐步排查瓶颈、优化配置的过程，需多轮调整以达到最佳性能状态。
• 容量测试：通过压测评估系统在当前资源配置下能支撑的最大业务量，并为未来的资源扩容提供依据。
• 压测模型：基于线上数据分析，构建漏斗模型，合理分配压测流量，确保压测场景与实际业务流量分布一致。

压测的最终目标

• 性能优化：压测的核心目标是发现并解决性能问题，而非单纯使用压测工具。需通过压测找到性能瓶颈，优化系统配置和资源分配。
• 容量规划：通过压测演练，评估系统在不同业务量下的表现，为线上资源的投入和扩容提供数据支持。