最后更新：2026-09-04 01:19

实验17 性能测试需求分析¶

难度：★☆☆　|　预估时长：__ 分钟

17.1 实验目的¶

知识目标：理解性能测试需求分析的重要性与目标，理解需求分析五步流程、六种性能测试方法、六大常用指标、五大应用领域的概念与含义。
技能目标：能对照实际系统按"系统调研→业务调研→性能评估→确定测试点→确定指标"五步开展需求分析，能区分不同测试方法、不同指标的适用场景。
素养目标：养成"先分析需求、再谈工具"的工程思维，避免一上来就盲目拿工具加压。

17.2 实验环境¶

操作系统：Windows 10 / Windows 11；
理论知识任务（为实验18~22 的 JMeter / LoadRunner 实操做理论铺垫）。

17.3 实验重难点¶

重点：需求分析五步流程；六种测试方法的适用场景与目的；常用指标的含义与取值。

难点：业务并发用户数 vs 服务端最大并发访问数的区别；响应时间 2/5/10 秒标准与主观性；压力测试与负载测试的区别。

17.4 实验内容¶

17.4.1 性能测试需求分析概述¶

1. 任务描述 理解为什么"一上来就拿工具加压"是错误做法。

需求分析像什么？

性能需求分析就像盖房子前的"勘探与设计"——你不先量好地、画好图就直接砌砖，房子迟早歪。性能测试也是，不先分析需求就加压，等于盲打，跑出来的数据说明不了任何问题。

2. 实验步骤

步骤 1：记住核心观点：

会使用性能测试工具 不等于 会性能测试。工具使用只是性能测试过程中很小的一部分，需求分析才是第一步。
步骤 2：性能需求分析要得出 7 个结论：
1. 明确性能测试的必要性和目的；
2. 明确被测系统的架构、平台、协议等技术信息；
3. 明确被测系统的基本业务、关键业务、用户行为；
4. 明确性能测试点；
5. 明确系统未来的业务拓展规划与性能需求；
6. 明确性能测试策略；
7. 明确性能测试的指标。
步骤 3：需求分析从 5 方面入手：

系统信息调研（全面了解被测系统——性能分析与调优的前提）；
业务信息调研（分析业务，方便确定场景与指标）；
性能需求评估（判断是否需要进行性能测试）；
确定性能测试点；
确定性能指标。

常见错误与排错

若把"会用 JMeter"当成"会性能测试"：工具只是手段，需求分析 7 个结论缺一不可，尤其要先明确被测系统架构与关键业务，否则后面场景设计会跑偏；
若需求分析 5 方面只做了 1~2 项：系统/业务调研没做全，后续指标与测试点会漏，务必 5 项都过一遍。

17.4.2 性能需求评估（要不要做性能测试？）¶

1. 任务描述 从业务角度和系统角度判断是否需要性能测试。

性能需求评估像什么？

性能需求评估就像体检前先问"要不要做这项检查"——小公司内部系统用的人少，做并发测试意义不大；证券类对响应时间敏感的系统才必须做。先判断"该不该测"，再决定"怎么测"。

2. 实验步骤

步骤 1：业务角度：
- 系统是公司内部使用还是对外？使用人数多少？
- 若上线后使用人数很少，并发性能测试一般没必要（功能阶段发现明显性能问题除外）。
步骤 2：系统角度： | 角度 | 判断要点 | | --- | --- | | 数据库要求 | 大数据量并发改库时，瓶颈常在连接池数量，可结合 DBA 建议决定 | | 系统特殊要求 | 对响应时间要求高的系统（如证券），有必要做并发测试 | | 系统架构 | 老框架已验证可不测；新框架可以考虑测 | | 大数据上传下载 | 需确定系统最大处理容量，防止内存溢出崩溃 |

常见错误与排错

别"为了测而测"：上线后用的人很少、功能阶段又没发现明显性能问题的系统，一般不必做并发性能测试；
若拿不准：从"系统特殊要求"（是否对响应时间敏感）和"大数据上传下载"两项切入判断，最稳妥。

17.4.3 确定性能测试点¶

1. 任务描述 确定哪些业务功能需要做性能测试。

确定测试点像什么？

确定测试点就像考试划重点——不是整本书都考，只挑"交易相关、逻辑复杂、请求量大、有推广活动"的关键业务重点测，把有限的测试力气花在刀刃上。

2. 实验步骤

步骤 1：按以下 4 个维度筛选：
1. 关键业务：是否与交易相关（转账、扣款等接口）；
2. 逻辑复杂度：日请求量不高但逻辑复杂——分布式调用中一个环节慢可能引发"雪崩效应"，要测；
3. 日请求量：日请求量高、系统压力大且是关键业务 → 确定为性能点；
4. 运营推广活动：系统不仅要满足当前压力，还要满足未来压力（按 PV/UV、访问量预估）。

常见错误与排错

别把"日请求量不高但逻辑简单"的页面当性能点：重点看"逻辑复杂"的接口（分布式调用一个环节慢会引发雪崩）；
别漏掉推广活动场景：大促/活动期间压力远超日常，要按未来访问量预估，否则活动时系统会崩。

17.4.4 性能测试方法（六种）¶

1. 任务描述 掌握六种性能测试方法的定义、目的与特点。

2. 实验步骤

步骤 1：验收测试：模拟生产业务压力，验证系统是否达到宣称的能力。目标描述如"100 个并发用户做 A 业务，响应时间不超过 5s"。
步骤 2：负载测试：不断增加压力直到性能指标超标或资源饱和，找到系统处理极限（也称容量测试），为调优提供数据。
步骤 3：压力测试：在系统资源饱和（如 CPU>75%、内存>70%）情况下，测试系统的会话处理能力、有无错误，一般用于稳定性测试。
步骤 4：并发测试：模拟多用户并发访问同一应用/模块/数据，检查是否有死锁、内存泄漏、资源争用。
步骤 5：配置测试：调整软硬件环境，比较各次测试结果，找出对性能影响最大的因素，用于调优和规划。
步骤 6：可靠性测试：给系统加载一定业务压力（资源使用率 70%~90%），让应用持续运行一段时间（非关键应用一般 2~3 天），验证长期稳定运行。

负载 vs 压力，别再混了

负载测试：压力"一点点加"，直到找到极限（正常到峰值）；
压力测试：压力"直接拉满到饱和"（超过峰值），看系统崩不崩、有没有错。
一句话：负载找"极限"，压力找"崩溃"。

常见错误与排错

别把负载测试当压力测试：负载是逐步加压找极限，压力是直接拉满看崩溃，报告结论写法完全不同；
别把配置测试与可靠性测试混为一谈：配置测试比"哪种配置影响最大"，可靠性测试看"长时间压着稳不稳"。

17.4.5 性能测试常用指标¶

1. 任务描述 掌握六个核心性能指标的含义。

2. 实验步骤

步骤 1：并发用户数——两个概念要分清：
- 业务并发用户数：同一时间段内访问系统的用户数量（业务视角）；
- 服务端最大并发访问数：同一时刻向服务端发请求的客户端数量（压力视角）。
举例：OA 系统 2000 个系统用户，最高峰 500 人同时在线。若其中只有 20% 真正对服务器构成压力，则实际压力用户约 100 人。服务器实际压力 = 业务并发用户数 × 业务场景。
步骤 2：响应时间——对请求做出响应所需要的时间 = 网络传输时间 + 应用延迟时间（含数据库延迟）。
- 常见标准：2/5/10 秒——2 秒内"非常有吸引力"，5 秒"比较不错"，10 秒是上限；
- 注意：响应时间是否可接受是主观的（如税务系统提交 20 分钟才出结果也可接受），取决于实际用户需求。
步骤 3：吞吐量——单位时间内系统处理的请求数。可用请求数/秒、页数/秒、人数/天等衡量。公式：F = VU × R / T（F 吞吐量，VU 虚拟用户数，R 每用户请求数，T 测试时间）。
步骤 4：TPS（Transactions Per Second）——每秒钟系统处理事务/交易的数量，是衡量系统处理能力的重要指标（如一次登录、一次确认支付都是一个事务）。
步骤 5：点击率——每秒用户向 Web 服务器提交的 HTTP 请求数。Web 特有的指标；注意"一次鼠标单击"可能发出多个 HTTP 请求。
步骤 6：资源利用率——对不同系统资源的使用程度： | 资源 | 说明 / 可接受上限 | | --- | --- | | CPU 使用率 | 长期可接受上限一般不超过 85% | | 内存利用率 | (1-空闲内存/总内存)×100%，使用率上限 85%，至少留 10% 可用 | | 磁盘 I/O | %Disk Time 度量读写性能 | | 网络带宽 | Bytes Total/sec 度量，与带宽比较判断是否瓶颈 |

两个'并发'别弄混

并发用户数有两个"并发"——业务并发（同一时段在线人数）≠ 服务端最大并发访问数（同一时刻发请求的人数）。就像 100 人在商场，但同一秒按电梯的只有 10 人；在线 100 人，真正给服务器加压的可能只是其中一部分。

常见错误与排错

别把"业务并发用户数"直接当"加压线程数"：服务器实际压力 = 业务并发 × 业务场景占比，在线 500 人不一定 500 线程；
响应时间 2/5/10 秒是参考线不是铁律：税务、报表类系统慢也合理，取决于真实用户需求，别死套标准。

17.4.6 性能测试应用领域¶

1. 任务描述 了解五大性能测试应用领域。

2. 实验步骤

步骤 1：能力验证——最常用最简单。问的是"某系统能否在 A 条件下具有 B 能力"（如上线验收）。
步骤 2：规划能力——问的是"应该如何使系统具有要求的性能能力"或"能否支持未来用户增长"，是探索性测试。
步骤 3：性能调优——遵循"测试→调优→测试"循环，调优要一次只调一个参数，否则无法判断哪个调整有效。
步骤 4：缺陷发现——通过性能测试发现并发引起的线程锁、资源竞争、内存问题。
步骤 5：性能基准比较——敏捷开发中用，不设明确目标，通过比较每次迭代的性能表现判断是否变差。

性能调优像什么？

性能调优就像调空调——"试开→调温度→再试开"循环，而且一次只动一个旋钮（温度/风速），否则你不知道到底是哪次调让屋里舒服了。

常见错误与排错

性能调优必须"一次只调一个参数"：同时改多个参数，出了效果也不知道是哪个生效，出了更差也说不清原因；
别把能力验证当成规划能力：前者回答"能不能"，后者回答"怎么才能"和未来增长，目标不同。

17.4.7 性能测试准备¶

1. 任务描述 了解性能测试实施前的准备工作。

2. 实验步骤

步骤 1：确认时机：系统基础功能测试验证完成、系统趋于稳定后再做性能测试（对"半成品"测试没有意义）。
步骤 2：组建测试团队（6 个角色）：
1. 项目测试经理（负责整个项目进度）；
2. 测试设计（设计方案和用例、分析典型场景）；
3. 测试开发（编写维护脚本、确定监控指标）；
4. 测试执行（组织执行脚本、记录结果）；
5. 测试分析（对照目标分析数据、得出结论）；
6. 支持角色（系统/网络/数据库工程师）。
步骤 3：引入测试工具：根据被测系统和测试过程给出工具功能列表，选择合适的工具（如 JMeter / LoadRunner）并规范使用。

性能测试时机像什么？

性能测试时机就像等菜炒熟再尝咸淡——系统基础功能没验证完、还不稳，做性能测试没意义，半成品测出来的数据既不能信也不能交。

常见错误与排错

别在系统还不稳定时做性能测试：功能都没跑通就压，出的结果说明不了性能问题；
工具要在设计阶段就按功能列表选定，别等到脚本开发时才临时找工具，容易与场景设计脱节。

17.4.8 性能测试计划设计¶

1. 任务描述 了解性能测试计划设计的核心活动。

2. 实验步骤

步骤 1：性能测试领域分析——先根据目的确定应用领域（能力验证/规划能力/性能调优/缺陷发现）。
步骤 2：用户活动剖析与业务建模——找用户的关键性能关注点：
- 系统日志分析：分析用户最关注、最常用的业务及操作路径；
- 用户调查分析：无日志时用问卷/同类系统对比估算。
步骤 3：确定性能目标——结合需求 + 用户活动分析结果：
- 能力验证：如"1s 最大响应时间处理 200 并发，峰值 400 用户响应时间可延至 3s"；
- 完整目标还可加上资源限制：如"CPU 占用不超过 75%，内存使用率不超过 70%"。
步骤 4：指定测试时间计划——为各测试活动估算起止时间，形成时间计划。

性能目标像什么？

性能目标就像跑步的"达标线"——先定"1 秒处理 200 并发、峰值 400 时响应≤3 秒"，再据此安排训练计划（时间计划）。没目标的测试，等于不知道自己跑没跑赢。

常见错误与排错

确定性能目标要结合需求 + 用户活动分析，别拍脑袋定；
完整目标要把资源限制（CPU≤75%、内存≤70%）写进去，别只写响应时间，否则服务器压崩了也不算不达标。

17.5 实验总结¶

本次实验掌握了以下要点：

一是需求分析五步流程、六种测试方法（验收/负载/压力/并发/配置/可靠性）、六大核心指标（并发用户数、响应时间、吞吐量、TPS、点击率、资源利用率）和五大应用领域，以及团队组建、工具引入、计划设计等准备工作（对应知识目标）；
二是能对照实际系统按"系统调研→业务调研→性能评估→确定测试点→确定指标"五步开展需求分析，能区分不同测试方法、不同指标的适用场景（对应技能目标）；
三是树立了"先分析需求、再谈工具"的工程思维，避免一上来就盲目拿工具加压——这是实验18~22 用 JMeter / LoadRunner 实操的"思想指导"（对应素养目标）。

17.6 作业提交¶

提交地点：吾爱作业网
提交资料：
- 完成课后思考：举例说明"负载测试与压力测试的区别"（结合双十一电商场景）；
- 提交文字/截图形式答案。
- 不会做时填写"心得感悟"（1~50 字）。

17.7 知识检测¶

[ ] （填空）性能测试"需求分析"五步流程中，第一步是____调研。（系统信息）
[ ] （填空）"一点点加压直到找到系统处理极限"的测试方法叫____测试。（负载）
[ ] （选择）下列指标中衡量系统每秒处理事务数量的是（）。
- A. 点击率　B. TPS　C. 吞吐量　D. 响应时间

查看解析

正确答案：B。TPS = Transactions Per Second，即每秒事务数，是衡量系统处理能力的重要指标。

[ ] （选择）下列关于"并发用户数"的说法正确的是（）。
- A. 业务并发用户数 = 服务端最大并发访问数
- B. 服务器实际压力 = 业务并发用户数 × 业务场景
- C. 在线 500 人就必须用 500 个线程加压
- D. 并发用户数只有一个含义

查看解析

正确答案：B。业务并发（同一时段在线）与服务端最大并发访问（同一时刻发请求）是两个概念，实际压力 = 业务并发 × 业务场景占比。

本课相关资源¶

序号	资源名称	类型	说明
1	任务1.1 性能需求分析.pptx	课件	需求分析概述、方法、指标、应用领域
2	任务1.2 性能测试准备.pptx	课件	时机、团队、工具引入
3	任务1.3 性能测试计划设计.pptx	课件	领域分析、业务建模、目标、时间计划

实验素材下载

点击下方链接获取本节课全部资源（含课件、任务清单、安装包等）： 🔗 夸克网盘