性能测试入门指南
目录
一、什么是性能测试？
性能：是用于描述产品（如软件或硬件）除功能之外所具有的速度、效率和能力的综合评价。
功能是“能不能做”，性能是“做得好不好、快不快”。
性能测试：是对产品的性能进行定性或定量测量的评估过程。核心目的是评估软件或系统在特定条件下的表现能力。
-
定性：例如，系统运行“快”或“慢”。
-
定量：例如，系统支持1000用户并发，响应时间为200毫秒。
二、性能测试分类
性能测试主要分为以下四种类型：
（1）压力测试
逐步给系统增加压力（如逐步增加用户访问量），观察系统性能变化，直至系统资源饱和（如 CPU / 内存占满）或接近崩溃，最终确定系统能承受的最大压力上限（再增压即崩溃）。
场景：给运动员逐步增加沙袋负重（5kg→10kg→20kg→…），不限制跑完时间，观察运动员能背多少斤沙袋跑完 100 米，直至再增沙袋就跑不完，此时的沙袋重量即最大承受力，对应系统再增用户就崩溃的最大用户量。
关键特点：不要求系统 “正常服务”，仅关注 “极限承受力”，核心是找到 “崩溃临界点”。
（2）负载测试
在系统 “正常服务” 的前提下（需满足预设性能指标，如响应时间≤2 秒），逐步增加负载（用户量），最终确定系统能承担的最大正常服务用户数，并分析系统性能瓶颈。
场景：预设指标必须15秒内跑完100米（对应系统正常服务标准），给运动员逐步增加沙袋负重（5kg→10kg→15kg→…）：
-
背 15kg 时，勉勉强强 15 秒跑完（符合正常服务）；
-
背 20kg 时，需 20 秒跑完（不符合正常服务）；
-
此时 15kg 即 “满足指标的最大负重”，对应系统 “满足正常服务的最大并发用户数”。
（3）稳定性测试
给系统施加固定压力（如固定 100 个并发用户），让系统持续运行一段时间（常见 7×24 小时、24 小时），观察系统是否能稳定提供服务，是否出现长期运行导致的问题（如内存溢出）。目的是验证系统在长期运行下的可靠性。
场景：给运动员固定负重 5kg，让其持续跑步，观察能稳定跑多久：若跑 10 分钟头晕、20 分钟呕吐（身体无法稳定运转），对应系统运行 12 小时后出现内存溢出（内存占用无法释放，最终崩溃）。
（4）并发测试
模拟多用户同一时间访问系统的同一应用、模块或数据记录，验证是否存在 “并发逻辑问题”（如死锁、数据不一致）。
特点：没有标准的通过指标，主要是为了发现意外问题。
场景：售货员按库存表卖货，仓库管理员出货后需更新库存表；
-
并发问题：若 10 个用户同时买货，仓库管理员忙到没时间更新库存表，导致库存表显示有货，但仓库实际无货—— 用户付款后无法发货（数据不一致）；
-
死锁问题：若 2 个仓库管理员同时要修改库存表，A 拿了表后忘了放回（锁住数据不释放），B 一直等 A 还表才能修改 —— 最终两人都无法操作（死锁）。
三、企业级软件为什么必须做性能测试
（1）由历史事件看性能问题的严重性
通过国内外知名平台的真实事件，明确 “性能问题” 的具体表现与危害，为后续分析 “为何做性能测试” 奠定现实基础：
12306 网站：春运期间大量用户集中订票，曾频繁出现网站崩溃、页面无法打开的情况（后经优化逐步稳定），因是唯一官方购票渠道，用户只能被动等待。
淘宝平台：双十一 “整点抢购” 场景下，曾发生大面积网站崩溃；后期优化后仍出现 “部分功能失效”（如用户地址无法修改），因架构拆分后某子系统（如账户系统）承载不足。
微博平台：明星花边新闻、重大热点事件爆发时，大量用户集中访问 / 互动，曾多次引发平台崩溃；甚至有 “用‘微博是否崩溃’衡量明星热度” 的调侃，本质是高并发下的性能问题。
网络游戏：早年热门网游的高人气服务器（如新开大区），因大量用户同时登录，出现响应速度极慢、操作卡顿的情况，严重影响玩家体验。
B 站平台：热点事件相关视频上架后，大量用户集中观看 + 发送弹幕，曾导致服务器承载不足而崩溃。
钉钉平台：疫情期间承担全国学生线上上课需求，短时间内大量用户同时发起直播、参与讨论，曾出现系统崩溃。
以上事件的共性后果是影响用户体验：当网站崩溃、页面卡顿或功能失效时，用户无法完成核心操作（订票、购物、互动），最终会选择 “离开平台”。对企业而言，用户流失直接关联业务损失，因此 “解决性能问题” 是保障业务存续的关键 —— 这也是企业开展性能测试的核心初衷。
（2）企业级软件做性能测试的核心目的
性能测试的本质是 “提前规避性能风险、保障软件质量”，具体可拆解为 4 个核心目的：
-
提升软件稳定性 避免软件在用户使用过程中出现 “崩溃、功能失效” 等极端情况（如 12306 的春运崩溃、淘宝的双十一崩溃），确保软件能持续正常运行。
-
提升软件响应速度 性能问题不仅是 “崩溃”，还包括 “卡顿”—— 需通过测试优化，让软件响应更快（如页面加载、操作反馈），提升用户使用舒适度；响应速度越快，用户留存率越高。
-
验证是否存在多并发逻辑问题 多并发场景下，易出现 “数据不同步” 的逻辑漏洞，需通过性能测试提前发现。示例：某手机商家的 “售货员 - 库存管理员” 协作场景 —— 售货员依据库存表卖货，库存管理员发货后更新库存表；若库存表更新不及时，会导致 “售货员以为有货并卖出，但仓库实际无货，用户付款后无法发货”，这就是典型的多并发逻辑问题。
-
预估软件性能瓶颈与优化时间 通过测试明确软件的 “承载上限”（性能瓶颈），提前规划优化节点。 示例：当前软件可稳定承载 100 用户访问，测试发现其最大承载量为 500 用户；当业务发展至 400 用户时，即可提前启动优化，避免用户量达到 500 时出现性能问题。
四、企业性能测试流程
在公司做性能测试流程跟功能测试流程有一定差异。
第一步：性能测试准备
1、测试指定标准
功能迭代完成了，预发布完成后，功能稳定了，这是性能的准入原则；
而且是否有必要做性能测试需要进行评估。比如有些伪需求，简单的逻辑不会影响性能，不需要做性能测试；非核心模块做性能测试，投入产出比也比较低，也没有必要做。
2、性能需求分析、量化性能指标
产品的功能点很多。做哪些功能的性能测试？边界、范围要明确。讨论到底具体做哪些功能。
出性能报告的时候，性能标准是什么也要先明确，如果没有给出特殊指标值，就以行业标准来定。
行业内标准：【ART<1.5s，ERR<0.1%，服务器资源利用率<80%】
第二步：性能测试环境搭建
明确了需求后，开始搭建独立性能测试环境，性能测试环境要求：
（1）独立网络（有线、局域网）。
（2）独立服务器 （硬件配置要与生成一致、服务部署架构要与生成一致，集群大小，可以缩减。
并且要同步搭建性能测试结果监控平台：比如 prometheus，grafana，influxdb ，现在市面上很多监控都是基于prometheus+grafana的二次开发页面展示不一样的。为了方便直接对测试结果进行监控分析，我们可以提前搭建好这些监控平台。
第三步：性能测试脚本开发和执行： 脚本制作，调试和验证脚本
性能测试脚本开发和执行需要借助工具来实现，性能测试工具目前市场主流的有：
（1）Jmeter 开源免费，学习资料比较多，java开发，跨平台【win mac Linux都可以用】，推荐优先使用。
（2）Loadrunner，需要收费，市场份额相对较少； C语言开发，破解版本<11版本，12版本免费只能使用50用户数，更新很慢。破解版使用有风险。
（3）locust 需要代码基础，用的也比较少；公司自研使用。Python语言自行开发。
我们以最主流的Jmeter工具给大家讲解性能场景设计与执行，常见的测试模型有：
（1）基于并发数模型：线程数梯度增加，压出系统能承受的最大并发用户是
（2）基于TPS压测模型：目标一般是为了压出系统最大的TPS，所以会采取平缓增加TPS的模式。
这里的RPS可以等同于TPS，以下图就是5分钟内TPS从1-20，下个5分钟20-50，下个5分钟50-100，最后加到300后，持续600s，如此设计平缓递增。
第四步：性能测试结果分析和调优
性能测试最重要的部分其实就是结果分析和调优。在性能测试过程中对各种数据进行监控与收集，包括被测项目的监控（服务 + 服务器），硬件资源监控+项目服务监控等。通过对测试结果与监控数据综合分析，进行问题定位、分析、调优。
问题分析和调优的基本步骤主要可以按照如下顺序进行：
- 由外及内: 检查RT>检查tps>检查负载机资源情况>检查服务器资源情况>检查中间件、数据库配置>中间件、数据库耗时分析
- 由表及里:自身问题>服务器硬件瓶颈 > 网络瓶颈 > 服务器os瓶颈> 应用瓶颈
- 自身问题：优先找自己的问题，因为可能脚本，客户端端口不够、网络不好等问题。
- 服务器硬件瓶颈： CPU 内存 磁盘等
- 服务器os瓶颈：参数配置、数据库、web服务器
- 应用瓶颈：sql语句、数据库设计、业务逻辑、算法
- 调优后再验证测试，检查问题是否已经解决。
第五步：性能问题跟踪与报告
当以上的步骤都做完后，就可以开始整理编写性能测试报告。
性能测试报告要素
- 背景 ：为什么要做压测的目的
- 压测内容：方案里有体现，范围和场景和环境 脚本 架构图等
- 压测结果（截图）：指标项的记录，TPS，资源使用情况等，截图附上作为证据，也更加直观和后续对比分析。
- 问题和调优：通过什么现象发现是个问题，然后调优的方法；包括已解决，待解决的问题；如果没有办法避免，写到结论里。
- 压测结论&建议 ：简洁明了，接口的最大并发用户数 响应时间 资源利用率等作为一个图标展示，明确的结论：是否达标。
然后进行性能测试问题跟踪
记录需要跟踪的性能问题： 问题可能不是一时半会能修复的，也需要问题跟踪。
五、性能测试指标
性能测试指标是评估系统性能的关键量化依据，是分析和定位性能瓶颈的基础。必须准确理解每个指标的含义。
（1）并发用户数
在同一单位时间（通常默认为1秒）内，执行同一操作的用户数量。
场景举例：1 秒内有 50 个用户同时点击 “登录按钮”，则并发用户量为 50。
（2）响应时间
从客户端发起请求到完全接收到服务器响应所经历的完整时间。
场景举例：客户端发起请求（如点击 “查看购物车”）→ 服务端接收并处理请求（查询数据库、计算数据）→ 服务端返回结果 → 客户端接收结果，整个过程的耗时即为响应时间。
响应时间越短，用户感受越流畅（如响应时间≤2 秒为优秀，＞5 秒易导致用户流失）。
（3）TPS（Transaction Per Second，事务处理能力指标）
系统每秒钟能够处理的事务数量。
TPS是衡量系统处理能力的核心指标，值越高说明系统处理业务越快。
事务：一个事务通常由多个请求组成，代表一个完整的业务操作（如 “登录→查看商品→加入购物车” 为一个事务）。
（4）QPS（Queries Per Second，查询能力指标）
系统每秒能够成功处理的查询请求数量。仅针对 “查询” 这一单一动作。
TPS与QPS的区别：
| 对比项 | TPS（事务） | QPS（查询） |
| 覆盖范围 | 完整业务流程（多个步骤） | 单一查询动作（如数据库查询） |
| 场景举例 | 每秒处理 50 个 “登录→加购” 事务 | 每秒处理 200 次 “查询购物车商品” 请求 |
TPS关注业务事务的完成速度，QPS关注查询操作的执行速度。一个事务可能包含多个查询。
（5）吞吐量
单位时间内（默认 1 秒），系统成功传输的数据量。
单位：数据大小单位，如 KB/s, MB/s, GB/s。
场景举例：每秒从服务端向客户端传输 10MB 的商品图片数据。
（6）吞吐率
单位时间内（默认 1 秒），系统成功处理的请求数量。
单位：请求数量单位（req/s，requests per second）。
场景举例：每秒成功处理 80个登录请求。
吞吐率 vs 吞吐量：这是最易混淆的一对概念。吞吐率是“个数”，吞吐量是“大小”。例如，处理1000个1KB的请求，其吞吐率是1000 req/s，吞吐量大约是1000 KB/s。
更多推荐
23
0- 0
已为社区贡献2条内容
所有评论(0)