Web性能测试入门：负载压力分类、并发用户与吞吐量指标

简介：《Web性能测试--基础概念》是一份面向刚接触性能测试的开发者与测试人员的入门PDF，围绕性能测试分类、并发用户、吞吐量与响应时间等核心概念展开，并梳理从需求确认、系统架构了解、测试点分析、工具选型、计划编写、环境搭建、实施到调优与报告的完整流程。资源包共1个文件，为531KB的PDF，内容按章节组织，便于集中阅读和按知识点查阅；其中对压力测试、负载测试、稳定性测试及理发店模式等内容的讲解，有助于理解并发用户的实际含义与系统处理能力的衡量方式，目录从基础概念延伸到测试思路，能帮助读者建立测试实施的整体流程框架与性能调优意识。已有465人学习，适合作为性能测试入门学习、课程预习及后续工具实践前的概念铺垫。

1. Web性能测试到底在测什么：从一次页面等待说起

Web性能测试这个词，第一次听像一门很专业的课，其实它对应的场景很日常：你点开一个页面，转圈两秒还是十秒，背后就是系统在多人同时使用时的表现。如果把系统比作一家餐厅，性能测试不是看厨师会不会做菜，而是看饭点同时来一百桌时，上菜还稳不稳、会不会漏单、后厨会不会乱。很多性能问题最怕变成黑匣子：用户只觉得慢，团队却说不清慢在哪。基础概念没理清，后面测出来的数字就容易变成玄学。这份资料的价值，正是把分类、并发、吞吐量、响应时间这些词先讲明白，再带到测试实施的整体流程和性能调优里去。

2. 为什么性能测试要分类型：负载、压力、并发不是同义词

很多人第一次接触性能测试分类，会觉得这是一场名词游戏：性能测试、负载测试、压力测试、并发测试、配置测试、可靠性测试，听起来都在“给系统加压”，为什么还要分这么细？原因不复杂。分类不是为了背名词，而是为了先回答两个问题：你打算用什么样的方式加压，以及你主要想观察什么结果。加压方式不同，观察目标不同，测试场景、监控指标和结论都会跟着变。把负载测试叫成压力测试，把并发测试叫成性能测试，短期看似不影响干活，长期会让测试报告里的结论失去边界。

可以用一张表先把几个常见类型摆在一起看。注意，这里的“性能测试”有时是狭义用法，指在既定环境下验证系统是否达到宣称的处理能力；而日常口语里的“性能测试”又常被当成一个大类。正因为存在这种大小名混用，初学者更容易糊涂。

这张表不是让人死记，而是提醒一件事：同样叫“压测”，你是在找上限、找错误、找并发问题，还是在找资源配比，结论写法完全不同。下面把最容易混的几类拆开讲。

2.1 负载测试：持续加压找到处理能力的边界

负载测试的关键动作是“逐步加压”。它不是一上来就把系统压到崩溃，而是一档一档增加并发用户数或请求频率，观察响应时间、吞吐量、资源使用率怎么变化。比如某审批类业务系统，平时大约一百人同时操作，团队想了解它能撑到多少。测试时可以从一百个并发用户开始，逐步加到两百、四百、八百，每档稳定运行一段时间，记录响应时间从一秒变到三秒、五秒、八秒的拐点，同时看应用服务器和数据库主机的资源曲线。

为什么需要这种测试？因为系统容量不能靠猜。线上真实流量一上来，团队最怕的问题是“到底能撑多少”。负载测试给出的不是一个孤立的数字，而是一条变化曲线：在哪个压力区间，响应时间还平稳；过了哪个点，响应时间开始明显上扬；再往上，是资源先饱和，还是错误率先升高。它常用于容量规划，也常配合性能调优使用，先找到边界，再谈优化。

这里有个容易踩坑的地方：负载测试要尽量贴近业务场景。只给登录接口加压，和模拟“登录、查询、提交、退出”的混合业务，结果不一样。资料里强调要考虑业务压力量和典型场景，就是为了让测试结果具有业务意义。否则数字很漂亮，却回答不了真实问题。

2.2 压力测试与稳定性测试：饱和状态下看系统会不会出错

压力测试关注的是系统在高压甚至饱和状态下的表现。它和负载测试的区别，可以这样理解：负载测试更像慢慢加重量，看运动员最多能举多重；压力测试更像把重量加到接近极限，观察动作会不会变形、会不会受伤、受伤后能不能恢复。压力测试常通过模拟负载让资源使用达到较高水平，观察系统还能否处理会话、是否出现错误、错误后是否可恢复。

稳定性测试则换了一个观察角度。它不一定追求特别高的瞬时压力，而是让系统在一定业务压力下持续运行一段时间，看它能不能长期稳定。很多问题在短时间高压下不一定暴露，比如内存慢慢涨、连接数慢慢堆积、日志越写越大、临时数据没有及时清理。这类问题在几分钟的测试里看不出来，跑上几个小时甚至更久才露头。资料里把可靠性测试描述为在压力下持续运行、关注系统运行状况，这个“持续”就是重点。

为什么要把压力测试和稳定性测试分开？因为短时高压和长期中压发现的是不同类别的问题。短时高压容易暴露处理能力不足、错误处理不完善、资源瞬间打满；长期运行更容易暴露泄漏和积累型问题。测试计划里的运行时长、监控频率、日志采集方式，都应该围绕目的来定，而不是随便跑十分钟就下结论。

注意：压力测试不是“把系统压死”才算成功。真正有价值的是记录它在什么压力下开始异常、异常表现是什么、压力退去后能不能恢复。

2.3 并发测试和配置测试：一个盯同时访问，一个盯资源分配

并发测试的关键词是“同时”。多用户并发访问同一个应用、同一个模块或者同一条数据记录时，系统可能出现单用户测试发现不了的问题，比如死锁、线程锁、资源争用，甚至内存泄漏。它不一定是长时间高压，也不一定追求最大吞吐量，而是专门制造“多人同时做同一类操作”的场景。比如多个用户同时提交同一类表单、同时抢同一个资源、同时触发同一段业务逻辑。开发阶段也可以做并发测试，前提是有合适的工具配合。

配置测试的关键词是“调整”。它通过改变软硬件环境，了解不同配置对性能的影响程度，从而找到更合适的资源分配原则。比如同样是某跨平台系统，应用容器线程数调大一点、数据库连接池调大一点、缓存策略换一换，性能可能变化明显；但盲目调大也可能带来上下文切换、连接争用等新问题。配置测试一般在对系统性能有初步了解之后做，因为它回答的是“怎么分配更合适”，不是“系统能不能撑住”。

这两个类型容易混，是因为它们都带一点“调”的味道。区分方法看目标：并发测试主要找并发访问引发的代码层、锁层、资源争用问题；配置测试主要找资源配置与性能之间的对应关系。一个更像排查“同时来会不会乱”，一个更像排查“资源怎么分更顺手”。

3. 并发用户到底怎么算：理发店模式把同时在线讲透

性能测试经常被叫作并发测试，因为最常见的做法就是用工具模拟多用户同时对系统操作，对系统造成压力。这里有两个关键词：多用户、同时。听起来简单，真到算并发用户数时，很多人会翻车。有人把注册用户数当并发数，有人把同时在线人数当并发数，还有人以为工具能制造出绝对的“同一瞬间请求”。这些理解如果不校准，后面的场景设计就会偏。

3.1 严格并发与广义并发：同一时刻做同一件事和同时各做各的

并发有两种常见理解。一种是严格意义上的并发：所有用户在同一时间点做同一件事或同一类操作，比如同一时刻集中登录、同一时刻集中提交表单。另一种是广义范围的并发：多个用户在同一时间段内对系统发出请求或进行操作，但这些请求可以相同，也可以不同，比如同一时刻有人在登录，有人在查询，有人在提交。

从业务视角看，性能测试通常更接近广义并发，因为真实用户不会整齐划一地做同一个动作。但从问题排查视角看，严格并发也有价值，它能集中暴露某个功能点在同时访问下的问题。资料里还提到从服务器角度看并发：把系统运行过程划分成离散时间点，每个点上都有一个“同时向服务端发送请求的用户数”，这就是服务器承受的并发访问数。这个视角很关键，因为客户端认为的“同时”，到服务器端往往已经被网络传输、请求排队和处理顺序拆开了。

真正意义上的绝对同时并不存在。测试工具可以在很短时间里模拟成千上万个请求，但请求产生有先后，网络传输有延迟，服务器处理也要排队。服务器处理单个请求的时间极短，每秒可以处理很多次请求，所以更常见的说法是“每秒多少次”的并发处理能力，而不是一个绝对同时的瞬间。理解这一点，就不会把工具里的并发数直接等同于服务器某一毫秒同时处理的请求数。

3.2 系统用户数、同时在线人数、并发用户数：三个数别混着用

假设某系统有二十万注册用户，这二十万就是系统用户数，表示有这么多账号可以使用系统功能。系统还有在线统计，某天最高同时在线人数是两万，这表示最高峰时有两万个用户用浏览器打开着系统。那系统的并发用户数就是两万吗？不一定。

同时在线人数只说明“还开着页面”的人多，不代表这些人每一秒都在发请求。有人打开页面后在看内容，有人在填表单但还没提交，有人挂着页面去忙别的事。服务器实际承受的压力，取决于这些在线用户在某个时间点发出了多少请求，以及请求集中在哪些业务上。所以并发用户数要结合业务访问模式来看，通常可以通过服务器日志分析、业务统计和场景建模去估算。把在线人数直接当并发数，是初学者很容易踩的坑。

这三个数的关系可以粗略记成：系统用户数是“有多少账号可能来”，同时在线人数是“最高峰有多少人挂着”，并发用户数是“某一时间点有多少人真正向服务器发请求”。三者可以有关系，但不能画等号。

3.3 理发店模式：最佳用户数与最大用户数的边界

资料里用理发店模式解释并发处理，很值得慢慢拆。假设一家理发店有三位理发师傅，每位师傅服务一位顾客需要一小时，顾客从进店起最多只能等待三小时，等待时间加被服务时间不能超过这个极限。先看最佳用户数：三位师傅都在理发，没有空闲，顾客一来就能接受服务、不用等待，这时店里服务的顾客数是三。对系统来说，这就是比较理想的状态：资源不闲着，请求也不用排长队。

再看最大用户数。假如早上一开门来了一群顾客，A、B、C 三位先理发，D、E、F 需要等一小时，G、H、I 需要等两小时，后面的 J、K、L 等顾客已经等了三小时还没轮到，达到等待极限后离开。对一个时间点来说，理发店能服务的最大用户数是九：三位正在接受服务，三位等待一小时，三位等待两小时。这里有两个注意点：第一，店里空间可能很大，能容纳超过九位顾客，但那些等了三小时还没被服务而离开的人，不应算进最大用户数；第二，如果店很小，最多只能容纳六位顾客，第七位顾客虽然理论上等两小时就能被服务，但因为没有容量，也只能改天再来。

把这个模式映射到系统：理发师傅类似服务资源，顾客类似请求，等待极限类似用户或业务能容忍的响应时间，店面容量类似连接数、线程数、队列长度等限制。最佳用户数帮助我们理解资源刚好被充分利用的状态，最大用户数帮助我们理解在可接受等待范围内系统最多能接住多少请求。两者都不是拍脑袋来的，而是由服务能力、等待容忍度和容量边界共同决定。

提示：算最大用户数时，不要把“已经等到极限而离开”的请求算进去，也不要把“理论上能等但系统容量装不下”的请求算进去。这个边界不清，容量结论就会虚高。

4. 吞吐量、吞吐率、TPS与点击率：一串容易串味的指标

性能测试里的指标名很像一串近义词：吞吐量、吞吐率、TPS、点击率。它们都和“单位时间处理了多少”有关，但观察角度不同。有人把吞吐量直接说成每秒请求数，有人把点击率当成鼠标单击次数，最后报告里数字一大堆，却说不清每个数字代表什么。先把这几个词拆开，后面的测试实施和性能调优才有共同语言。

4.1 吞吐量为什么必须加时间单位：水龙头与十个水龙头的比喻

吞吐量指在一次性能测试过程中网络上传输的数据量总和。它反映服务器承受的压力，在容量规划里是重点指标，因为能说明系统级别的负载能力；在性能调优里也有价值，因为吞吐量受限往往是瓶颈的一种表现。但只用“总量”衡量输出能力很不准确。资料里的水龙头例子很直观：一个水龙头开二十四小时，流出十吨水；十个水龙头开一秒，流出零点一吨水。单看总量，当然是一个水龙头大，但你能说一个水龙头的出水能力远超十个水龙头吗？不能，因为时间条件不同。

所以要说清吞吐能力，必须加单位时间限制，这就引出吞吐率：单位时间内网络上传输的数据量，或者单位时间内处理的客户请求数量。它可以用字节数每秒衡量，也可以用请求数每秒、页面数每秒衡量。从业务角度看，还可以用业务数每小时、访问人数每小时、页面访问量每小时来衡量。比如某审批类业务系统，可以用“千件每小时”描述业务处理能力。单位不同不代表概念乱，而是观察层次不同：底层看数据量，中层看请求，业务层看事务或业务件数。

这也解释了一个常见误区：吞吐量大不等于系统强。必须结合时间窗口、业务含义和资源使用率一起看。一个系统在十分钟里传了很多数据，可能只是文件下载场景；另一个系统每秒处理很多小请求，可能才是交互式业务更关心的能力。

4.2 从页面请求到事务：TPS怎么理解

用户的一次操作，往往不是一次孤立请求。点一次提交，可能先发一个请求校验，再发一个请求保存，再跳转结果页；一次登录也可能包含多个请求。为了从业务角度衡量处理能力，资料引入了“事务”：用户某一步或几步操作的集合，但要保证有完整意义。对某个页面的一次请求、对某系统的一次登录、对商品的一次确认支付过程，都可以看作一个事务。

TPS 指每秒钟系统能够处理事务或交易的数量，是衡量系统处理能力的重要指标。它比单纯数请求更贴近业务，因为一个事务对应一件用户认为完整的事。比如某交易类业务，用户从确认到支付完成算一个事务；某审批类业务，一次表单提交并进入待审状态算一个事务。用 TPS 描述处理能力时，必须把事务定义写清楚，否则两个人说的 TPS 可能不是一回事。

这里要注意，事务不是越大越好。把一整套流程都塞进一个事务，数字看起来完整，但排查问题时很难定位是哪一步拖慢；事务切得太碎，又可能失去业务意义。比较稳妥的做法是围绕关键业务动作定义事务，并保证每次测试的事务边界一致。

4.3 点击率不是鼠标单击次数：HTTP请求视角

点击率可以看作 TPS 的一种特定情况。它指每秒钟用户向 Web 服务器提交的 HTTP 请求数，是 Web 应用里特有的指标。Web 应用是“请求—响应”模式，用户发一个请求，服务器处理一次，所以点击是 Web 应用能够处理的交易的最小单位。如果把每次点击定义为一个交易，点击率和 TPS 在概念上就很接近。

但点击率里的“点击”不能简单理解为鼠标的一次单击操作。一次单击可能触发多个 HTTP 请求，比如页面加载时同时请求样式、脚本、数据接口等。点击率越大，对服务器的压力通常也越大，但它只是一个性能参考指标，重要的是分析点击时产生的影响：这些请求落在哪些接口、是否集中打向同一个资源、是否引发数据库查询高峰。

点击率更能体现用户端对服务器的压力，TPS 更能体现服务器对客户请求的处理能力。一个偏“请求数量”，一个偏“完整事务处理”。两者不能互相替代，也不建议在报告里混着写而不解释。

4.4 吞吐量指标有什么用：设计场景与定位瓶颈

吞吐量指标的第一个用途，是协助设计性能测试场景，并衡量场景是否达到预期目标。设计场景时，可以根据估算的吞吐量数据，对应到测试场景里的事务发生频率、事务发生次数；测试完成后，再用实际吞吐量衡量是否达到预期。比如某业务预计高峰期每小时处理多少件审批，就可以把业务量换算成测试中的事务频率，而不是凭感觉设一个并发数。

第二个用途，是协助分析性能瓶颈。吞吐量受限是性能瓶颈的重要表现形式，有针对性地围绕吞吐量设计测试，可以更快定位瓶颈位置。资料里提到一种快速识别瓶颈的思路：大量系统性能瓶颈与吞吐量制约有关，并发用户数和吞吐量瓶颈之间存在关联，可以通过不断增加并发用户数和吞吐量观察系统表现，再从网络、数据库、应用服务器和代码四个环节去找原因。这个思路的价值在于，它让“系统慢”变成可分层排查的问题，而不是一上来就猜代码。

需要提醒的是，吞吐量指标要结合响应时间和错误率看。只追求吞吐量上去，可能响应时间已经不可接受；只看响应时间，又可能忽略了系统其实没处理多少事务。指标之间要互相校验。

5. 常见误区与易混概念：响应时间、并发与吞吐量的边界

性能测试的概念不难背，难的是在真实场景里保持边界。很多争论不是因为谁不努力，而是因为同一个词在不同人嘴里含义不同。下面挑出五组最容易混的概念，按“易混点、为什么混、怎么区分”拆开说。

5.1 响应时间不是服务器处理时间

易混点：很多人把工具上显示的响应时间，直接当成服务器处理请求的时间。为什么混：用户感受到的是一个总等待时间，工具也常常只给一个总数，看起来就是一个数。怎么区分：响应时间可以拆成呈现时间、数据传输时间和系统处理时间。呈现时间主要是客户端接收到数据后的展示过程，和客户端设备、浏览器、系统环境有关；数据传输时间受网络带宽、延迟、链路影响；系统处理时间是服务器收到请求后处理并返回结果的时间。性能测试主要能控制的是系统处理时间，所以通常会在相对独立的局域网环境里做，减少传输干扰，工具也会屏蔽响应呈现过程，只模拟并发请求并计算得到响应的时间。报告里写“响应时间”时，最好说明是端到端观测还是服务器处理时间，否则很容易各说各话。

5.2 并发用户数不是同时在线人数

易混点：看到在线统计里有两万人，就认为系统并发用户数是两万。为什么混：两个词都带“同时”，而且在线人数看起来很有冲击力。怎么区分：同时在线只表示用户还打开着系统，不代表每一刻都在发请求；并发用户数看的是某一时间点真正向服务器发送请求的用户数。它取决于业务访问模式，可以通过日志分析、业务统计和场景建模估算。系统用户数、同时在线人数、并发用户数分别对应“可能来”“挂着”“正在发请求”，不能画等号。

5.3 吞吐量不是吞吐率

易混点：把一次测试传输的数据总量，直接说成系统每秒处理能力。为什么混：两个词只差一个字，日常交流常被省略。怎么区分：吞吐量是一次测试过程中网络上传输的数据量总和；吞吐率是单位时间内传输的数据量或处理的请求数量。前者必须结合测试时长才有比较意义，后者天然带时间单位。水龙头例子说得很清楚：只看总流出量，长时间小水流可能赢过短时间大水流；加上单位时间，才能比较出水能力。

5.4 TPS不是点击率

易混点：把每秒 HTTP 请求数直接当成每秒事务数。为什么混：如果一次点击只产生一个请求，且把一个点击定义为一个事务，两者数字可能一样。怎么区分：TPS 看的是每秒处理的事务数量，事务要有完整业务意义；点击率看的是每秒 HTTP 请求数，一次单击可能产生多个请求。点击率更偏用户端对服务器产生的请求压力，TPS 更偏服务器对完整事务的处理能力。报告里要写清事务怎么定义、请求怎么计数。

5.5 压力测试不是负载测试

易混点：只要给系统加压力，就都叫压力测试。为什么混：两者都涉及“压”，而且常常在同一个项目里连续做。怎么区分：负载测试侧重逐步加压找处理能力边界，观察指标拐点；压力测试侧重让系统处于饱和或超预期状态，观察是否出错、是否崩溃、能否恢复。一个更像找上限，一个更像看高压下的表现。目的不同，场景设计、运行时长和结论写法都不同。

6. 什么时候该做Web性能测试：从需求到调优的边界判断

Web性能测试值得做，但不是什么阶段都适合立刻上工具。比较稳妥的判断是：先问目的，再看环境，最后决定压不压。新系统上线前要做能力验证；客户给出了明确的并发数和响应时间要求；系统经常在高峰变慢，需要找瓶颈做性能调优；系统要长期运行，担心里面有内存或连接泄漏；关键业务发生频率高、资源占用重，这些都属于值得做的场景。反过来，需求目标还没说清、测试环境和生产环境差太远、只想在远端网络里证明服务器最大处理能力、或者把性能测试当成功能测试的替代品，就先别急着压，否则数字很容易变成无效结论。

A同学第一次接性能任务时，最容易犯的错是拿到工具就开始录脚本，跑完拿一个平均数交差。后来他养成了一个习惯：每次先写三行——这次要回答什么问题、在什么环境里回答、看哪几个指标回答。三行写不出来，就说明还没到压的时候。那份基础概念资料把分类、并发用户、吞吐量、响应时间，以及从需求、架构分析、测试点选择、工具选型、计划编写、环境搭建、测试实施到性能调优的整体流程串在一起，适合在名词卡壳时翻一翻。需要获取这份资料，按页面提示拿即可。从那以后我每次接性能任务都先强制走一遍这三行，再决定压不压。希望帮到你。

本文还有配套的精品资源，点击获取