[特殊字符] 测开笔记：一文搞懂性能测试的核心逻辑与“黑话”

[🚀 测开笔记：一文搞懂性能测试的核心逻辑与"黑话"](#🚀 测开笔记：一文搞懂性能测试的核心逻辑与“黑话”)

[1. 什么是性能测试？（五菱与法拉利的区别）](#1. 什么是性能测试？（五菱与法拉利的区别）)

[2. 性能评估"三剑客"：并发、吞吐与响应](#2. 性能评估“三剑客”：并发、吞吐与响应)

[⚔️ 第一剑：并发数 (Concurrency)](#⚔️ 第一剑：并发数 (Concurrency))

[⚔️ 第二剑：吞吐量 (Throughput - TPS/QPS)](#⚔️ 第二剑：吞吐量 (Throughput - TPS/QPS))

[⚔️ 第三剑：响应时间 (Response Time)](#⚔️ 第三剑：响应时间 (Response Time))

[3. 性能测试四大派系：你真的分得清吗？](#3. 性能测试四大派系：你真的分得清吗？)

[1️⃣ 基准测试 (Benchmark Testing)](#1️⃣ 基准测试 (Benchmark Testing))

[2️⃣ 并发测试 (Concurrency Testing)](#2️⃣ 并发测试 (Concurrency Testing))

[3️⃣ 负载测试 (Load Testing) vs 4️⃣ 压力测试 (Stress Testing)](#3️⃣ 负载测试 (Load Testing) vs 4️⃣ 压力测试 (Stress Testing))

[💡 总结语](#💡 总结语)

🚀 测开笔记：一文搞懂性能测试的核心逻辑与"黑话"

作为测试开发，我们经常会把"功能没问题"挂在嘴边，但这真的代表系统可以完美上线了吗？对于一个系统来说，能做是一回事，做的好不好又是另一回事情。今天我们就来聊聊，怎么判断一个系统"跑得快不快、稳不稳"。

很多刚入行的同学分不清功能测试和性能测试的区别。打个最简单的比方：五菱和法拉利都是汽车，从功能上说，它们都有四个轮子一个方向盘，能遮风挡雨往前开。但从性能来说，五菱的百公里加速可能需要十几秒，而法拉利只需要几秒，这就是性能的区别。

在技术领域，性能测试就是为了发现系统性能问题或获取系统性能相关指标而进行的测试 。我们通常会在特定负载下，通过工具模拟实际运行及其操作，同时监控指标并分析结果。如果没有性能保障，双十一期间用户可能根本无法进入商品页面，或者页面加载时间过长，白白消耗用户的等待时间。

要评估系统性能的好坏，我们需要借助核心的性能指标。

并发数指的是实际使用系统的用户总数。但这里有个坑：从后端服务器层面看，它指的是 Web 服务器在一段时间内处理请求而建立的 HTTP 连接数或生成的处理线程数。

举个栗子：一个系统有 5000 名员工，最多同时有 2500 人在线。此时系统的业务并发用户数是 2500，但"实际并发用户数"仅仅是那一瞬间正在提交或查询订单的用户。

吞吐量指的是单位时间内处理的并发数，直接体现系统的负载承受能力。吞吐量越高，性能越好。

TPS (每秒处理事务数)：用于衡量系统在一定时间内能够处理的完整事务数。计算公式为：总事务数 / 总运行时间。
*

QPS (每秒查询率)：如果一个事务中只有一个接口且是查询接口，那么 QPS = TPS 。

在评估理论 TPS 时，我们经常会用到经典的二八定律（80% 的事务在 20% 的时间内完成）。例如，一天有 10 万笔交易： $TPS = \\frac{100000 \\times 0.8}{24 \\times 60 \\times 60 \\times 0.2} = 4.6$ 。

这是用户的主观感受。它指的是从请求发出开始，到接收到最后一个字节所消耗的时间。它包含了前端展现时间 （页面渲染）和系统响应时间（服务器、数据库、网络等）。

👉 避坑指南 - 寻找"拐点" ：随着并发用户增加，系统的吞吐量会呈线性增长。但到了某个点，吞吐量达到饱和（这个点就是拐点），此后响应时间会急剧变长，吞吐量反而降低，系统进入过饱和状态。找到这个拐点，正是我们性能测试的主要目的 。

测试场景怎么设计？来看看业界最常用的四种测试分类：

也就是单用户测试，目的是在较低压力下记录系统运行状况。通俗点说，这就是测"一颗白菜正常能存放多久"，为后续的多用户并发提供参考依据。

评估特定操作同时发生时的系统表现。这种测试非常容易暴露出代码底层的问题，比如内存泄漏、线程锁、以及数据库资源的争用。

这两个概念常常被混淆，但它们的逻辑完全不同：

负载测试就像举重：在系统状态正常（满足性能指标，如响应时间不超过2秒）的前提下，不断加压，直到找出系统能承受的最大重量（最大负载量）。
*

压力测试则是"搞破坏"：继续在最大负载上加压，测试系统达到极限崩溃时的状态。比如加到 3 万访问量时系统直接死机，这 3 万就是系统的极限处理能力。压力测试能发现只有在高负载下才出现的隐藏 Bug 。

此外，在摸清了系统的脾气后，我们还会进行稳定性测试，通常让系统在负载下运行 3*24 小时以上，看看它会不会偷偷崩掉。

性能测试不仅仅是压测工具（如 JMeter/LoadRunner）的无脑施压。作为性能测试人员，我们的工作重点在于场景设计、脚本开发以及缺陷的排查定位。这要求我们必须具备极其宽广的知识面（网络、存储、JVM、SQL调优等），才能在这个领域如鱼得水。

大家在日常做性能测试时，最头疼的是哪一环呢？欢迎在评论区一起交流！