简介：《Web性能测试--基础概念》是一份面向刚接触性能测试的入门PDF讲义，围绕高负载场景下的系统稳定性评估，梳理并发用户、吞吐量、响应时间等核心指标，并给出从需求澄清到报告输出的完整实施脉络。内容分为基础概念与测试思路两章：前者讲解压力测试、负载测试、稳定性测试等分类，借“理发店模式”说明并发用户状态；后者按了解系统架构、分析测试点、选择工具、编写计划、搭建环境、实施测试、性能调优、形成报告逐步展开，目录层次清晰，便于按章节系统学习或查阅。资源包为单个PDF文件，约531KB，轻量易读，已有465人学习。对初级测试人员而言，可借此建立性能测试的基础概念框架和流程认知，并了解常见工具选型与调优思路，作为后续实战前的知识铺垫。

1. 先别被术语吓住：Web性能测试到底在测什么

刚接触Web性能测试的人，常把“并发”“吞吐量”“TPS”当成一堆玄学名词，工具一打开就不知道先点哪里。其实它做的事很朴素：在上线前模拟一群人同时登录、查询、提交表单，看系统会不会变慢、报错甚至崩掉。这份《Web性能测试--基础概念》把入门要用的概念和测试实施的整体流程串成了一条线，适合零基础、准备第一次接性能任务的新手。你不需要先会写压测脚本，先弄懂“系统在多大压力下还能稳住”这个问题，后面的工具和指标才有地方落脚。

2. 为什么要学：性能问题不是上线后才补的“黑匣子”

很多新手觉得功能测试点完按钮就结束了，性能是运维或者老员工的事。真到上线高峰，系统变慢、登录排队、提交表单转圈，大家才发现性能问题像一个黑匣子：平时看不见，一出现就很难临时找后悔药。学性能测试不是为了背名词，而是为了接任务时知道先问什么、先测什么、结果怎么解释。这份材料把性能测试分类和测试思路放在前面，就是在帮零基础的人建立第一张地图，避免一上来就调线程数。

2.1 四种常见分类：负载、压力、并发、稳定性到底差在哪

分类名字混用很常见，甚至一些做测试的人也会把压力测试和并发测试混着叫。区分它们的关键不是工具，而是“这次想让系统回答什么问题”。材料里把性能测试、负载测试、压力测试、并发测试、配置测试、可靠性测试分开讲，我用一张表先帮你把常见几类摆在一起看。

负载测试像给系统逐步加重量，看它最多能举起多少；压力测试更像让系统在接近饱和的状态下持续工作，观察它会不会出错、会不会不稳。并发测试关注的是“多个人同时做同一件事”时，系统内部会不会出现互相卡住的问题，比如同一张数据记录被同时修改、同一个模块被同时提交。可靠性测试则把时间拉长，压力不一定最大，但要看系统能不能长期稳住。材料里用运动员的爆发力、耐力、整体协调性来类比，这个说法很适合入门：爆发力对应系统能承受的最大压力，耐力对应长时间压力下的稳定性，整体协调性对应系统有没有短板和瓶颈。分类清楚了，你才知道这次该定多长时长、看哪些指标、要不要调优，而不是把所有测试都叫“压一下看看”。

2.2 从目的反推做法：先问“这次测试到底要回答什么”

材料里把性能测试目的分成几类：新系统能力验证、客户有明确要求、找出系统性能瓶颈、稳定性验证。这个分法很实用，因为目的不同，测试策略完全不一样。新系统上线前验证，环境、压力点、工具选择都相对自由；客户有明确指标，重点是把指标翻译成可执行的场景；找瓶颈，重点在架构分析和业务分析；稳定性验证，重点在运行时长和长时间资源变化。新手最容易犯的错，是领导说“做个性能测试”，就直接打开工具开跑，跑完拿一堆曲线图不知道说明什么。

我建议你拿一张纸，先写一句“验收句”。模板可以是这样：

在【测试环境】下，用【并发数】模拟【业务场景】持续【时长】，要求【指标】不超过【阈值】，错误率低于【阈值】。

比如写成：在独立测试环境下，用20个并发用户模拟登录场景持续5分钟，要求平均响应时间不超过3秒，错误率低于1%。这句话里每个空都要能解释：环境是不是独立、并发数怎么来的、场景是不是高频业务、时长够不够观察、指标是平均还是90%分位、错误率怎么统计。写不出来，说明需求还没问清。跟做一步：把你手头任务里的“系统要快”改写成一句带数字的验收句，写不出数字就先去找需求方确认。

提示：验收句不是写给领导看的，是写给你自己看的。后面选工具、搭环境、写报告，都围绕这句话展开。

2.3 八步流程地图：入门不用一次全懂

这份材料后半部分给了一个通用测试思路：问清性能测试需求、了解系统架构、分析性能测试点、测试工具选型、编写测试计划、搭建测试环境、测试实施、性能调优，最后落到报告。零基础第一次看会觉得步骤多，其实可以把它当成一张地图，不用一次全懂。第一次做小压测，至少走前六步：知道目的、知道系统大概怎么部署、知道测哪个功能、选一个能上手的工具、写一页计划、搭一个独立环境。第七步实施时先单用户调通脚本，再逐步加并发。第八步调优不急着做，先把结果记录清楚。这样走一遍，你就能把“基础概念”和“测试实施的整体流程”对上号，而不是概念是概念、工具是工具。

3. 三个核心指标先吃透：并发用户、吞吐量、响应时间怎么理解

性能测试绕不开三个词：并发用户、吞吐量、响应时间。很多新手背了定义还是不会用，因为这三个词分别回答不同问题：有多少人同时在用、系统单位时间能处理多少、用户等多久。把这三个问题分开，再看它们之间的关系，入门就不会乱。

3.1 并发用户：在线人数和并发数不是一回事

材料里先讲了并发的两种情况。一种是严格意义上的并发，所有用户在同一时间点做同一件事，比如同一时刻一起登录、一起提交表单。另一种是广义并发，同一时刻有人登录、有人查询、有人提交，请求可以不同。从用户业务角度看，性能测试经常用广义并发来模拟真实场景；从服务器角度看，系统运行过程可以切成很多离散时间点，每个点上“同时向服务端发送请求的用户数”才是服务器承受的并发访问数。真正意义上的绝对同时并不存在，工具发出的请求有先后，网络传输有延迟，服务器处理也要排队，所以服务器能力常用“每秒多少次”来描述。

新手最容易混淆的是系统用户数、同时在线人数和并发用户数。材料里举了一个例子：某网站有20万注册用户，这是系统用户数；在线统计最高2万人，这是同时在线人数；但这2万人不代表服务器每秒要处理2万个请求。因为这2万人里，有人打开页面后在看内容，有人挂着不动，有人刚登录，真正在某个时间点发出请求的人数会缩水。服务器承受的最大并发访问数，取决于业务并发用户数和业务场景，一般要结合服务器日志和业务分析来估算。

理发店模式很适合把这事讲明白。假设理发店有3位师傅，每位师傅服务1位顾客需要1小时，顾客从进店起最多等待3小时，等待加服务超过3小时就会离开。最佳用户数是3：3位师傅都在忙，顾客不用等，收入最多、满意度最高。最大用户数是9：3位正在接受服务，3位等待1小时，3位等待2小时，再往后排队的人等满3小时就会离开，不纳入最大用户数。如果理发店很小只能容纳6位顾客，那第7位顾客虽然等2小时就能轮到，也可能因为容量限制进不来。把这个类比换到系统上，理发师傅像应用线程或处理能力，顾客像请求，等待区像队列，最佳用户数和最大用户数就是衡量系统处理能力的两种视角。入门时先记住一句话：在线人数是“打开着页面的人”，并发数是“在某个时间点真正给服务器发请求的人”，两者不能直接画等号。

3.2 吞吐量与TPS：为什么只说“总量”会翻车

材料里用自来水厂和水龙头做类比：你可能不关心自来水厂供应多少水，但供应量对水厂很重要；你可能不关心系统吞吐量，但吞吐量对系统很重要。吞吐量指在一次性能测试过程中网络上传输的数据量的总和。注意，它是“总量”，不是“速度”。如果只看总量，很容易翻车。一个水龙头开24小时流出10吨水，10个水龙头开1秒流出0.1吨水，单看总量当然是一个水龙头多，但你不能说一个水龙头的出水能力远超10个水龙头。所以要看单位时间，这就引出吞吐率：单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量。常用“字节数/秒”衡量，也可以用“请求数/秒”“页面数/秒”，业务角度还能用“业务数/小时”“访问人数/小时”。

再往下是TPS，也就是每秒系统能够处理的事务或交易数量。事务是用户某一步或几步操作的集合，但要保证完整意义，比如一次登录、一次表单提交、一次确认支付。点击率可以看成TPS的一种特定情况，更体现用户端对服务器的压力，TPS更体现服务器对客户请求的处理能力。这里要特别注意：点击不是简单的鼠标单击，一次单击可能让客户端向服务器发出多个HTTP请求。入门计算可以先从简单例子开始：某次压测10分钟完成6000个登录事务，TPS就是6000除以600秒，等于10。这个数字要连同并发数、响应时间、错误率一起看，单独一个TPS说明不了太多。

吞吐量指标的作用，材料里讲了两点：协助设计性能测试场景，以及协助分析性能瓶颈。设计场景时，可以根据估算的吞吐量对应到事务发生频率和次数；测试完成后，用实际吞吐量衡量是否达到预期。分析瓶颈时，吞吐量限制是性能瓶颈的重要表现形式。材料还提到一种快速识别瓶颈的思路：大部分性能瓶颈由吞吐量制约，并发用户数和吞吐量瓶颈之间存在关联，可以不断增加并发用户数和吞吐量观察系统表现，再从网络、数据库、应用服务器和代码本身几个环节定位。新手不用一上来就做复杂瓶颈分析，但要知道吞吐量不能只看总量，要看单位时间，并且要和业务事务对上。

3.3 响应时间拆三段：用户等的那几秒到底花在哪

站在用户角度，性能就是单击一个按钮或链接后，从单击开始到系统把结果展示出来所消耗的时间。材料把响应时间拆成三段：呈现时间、数据传输时间、系统处理时间。呈现时间主要是浏览器收到数据后的处理和展示过程，和浏览器、操作系统、电脑硬件都有关系；数据传输时间是从客户端发请求到服务器、服务器返回结果到客户端的网络过程，可以用寄信类比，写信和读信不是最花时间的，送信过程才是；系统处理时间是服务器拿到请求后处理并返回结果的时间。对性能测试来说，前两段受用户电脑、浏览器、网络状况影响很大，唯一能重点控制的是系统处理时间。

入门做拆解可以按这个顺序：先记录用户从点击到看到结果的总时间；再用测试工具看服务器响应时间；两者差值可以帮你估算网络传输和页面呈现的大致影响；最后在局域网内复测，减少网络带宽和延迟的干扰。材料强调一般性能测试要在局域网中进行，因为公网带宽、延迟、路由都不稳定，你在公网上压测，请求发出去时可能已经不能叫并发了，更不能拿这个结果去推断服务器端的最大处理能力。新手喜欢拿工具去压互联网上的网站，甚至以为能把对方压宕机，这种想法很危险也不专业。入门阶段老老实实搭独立测试环境，把系统处理时间先看清楚，再谈其他。

注意：平均响应时间好看不代表用户不卡。后面做小压测时，除了平均值，还要看错误率和长尾请求，别让少数慢请求被平均数藏起来。

4. 新手避坑清单：5个高频翻车现场与排查顺序

第一次做性能测试，工具能跑起来不等于结果可信。下面5个坑很常见，每个都按“现象→原因→解决”拆开讲，你可以当成压测前的检查表。

4.1 五个高频翻车现场与处理

坑一：脚本没调通就开并发。现象是错误率很高，报告里一片红色，新手第一反应是“系统不行”。原因往往是登录参数写死、会话失效、断言写错、请求地址填成测试环境之外的地址。解决方法是先用一个虚拟用户跑一次，确认请求成功、断言通过、返回内容里有业务成功标识，再逐步加并发。单用户跑通这一步不能省，省了后面所有数据都不可信。

坑二：把在线人数直接当并发数。现象是压测结果和线上表现对不上，要么压得太轻，要么压得太重。原因是把系统用户数、同时在线人数、并发用户数混成一个概念。解决方法是回到业务场景，结合服务器日志估算单位时间真正发请求的用户数，再用理发店模式理解最佳用户数和最大用户数的区别。压测报告里写清楚“本次并发数是怎么来的”，比写一堆曲线更有说服力。

坑三：只看平均响应时间。现象是平均值很漂亮，但用户实际使用还是卡。原因是少数慢请求被大量快请求平均掉了，平均值掩盖了长尾。解决方法是同时看90%或95%响应时间、最大响应时间、错误率，以及不同事务分开统计。入门小压测至少记录平均响应时间、90%响应时间、TPS、错误率四项，别只截一张平均值的图。

坑四：在生产环境直接压测。现象是真实用户变慢、订单受影响，甚至引发事故。原因是为了省事，觉得“生产环境最真实”。解决方法是尽量在独立测试环境进行，环境尽量接近生产配置，但不要拿真实用户做实验。材料里也强调性能测试最好在独立环境内进行，避免外界干扰，保证数据独立有效。没有独立环境时，至少要和相关方确认时间窗口、限流措施和回滚方案，不能把“后悔药”留到出事之后。

坑五：压测机自己先成为瓶颈。现象是服务器CPU、内存都不高，但TPS上不去，响应时间越来越长。原因是发压的机器CPU、内存、网络带宽、连接数先到极限，请求根本发不出去。解决方法是监控压测机自身资源，减少不必要的日志和断言，必要时用多台压测机分担，但入门阶段先把并发数降下来，确认压测机没有跑满。压测机和被测系统抢资源，也是常见翻车点。

4.2 排查顺序与上线前自检清单

出问题时不要东看西看，按顺序排查更稳：先确认脚本单用户能跑通，再看断言和错误信息，接着看错误率集中在哪些请求，然后看响应时间分布，再看被测服务器CPU、内存、磁盘、数据库连接数，最后看网络和压测机自身。这个顺序的好处是先排除“测试脚本的问题”，再怀疑“系统的问题”。很多新手一上来就看服务器监控，结果折腾半天发现是登录接口的验证码没处理。

上线前自检可以按下面清单走一遍：

1. 验收句写清楚了吗？环境、并发数、场景、时长、指标、错误率都有具体值吗？
2. 测试环境独立吗？会不会有其他人同时在使用？
3. 脚本单用户跑通过吗？断言能识别业务成功和失败吗？
4. 测试数据准备了吗？账号、参数、数据量是否接近目标场景？
5. 压测机资源监控了吗？CPU、内存、网络有没有先跑满？
6. 被测服务器资源监控了吗？应用、数据库、中间件日志放在哪里？
7. 结果里记录了平均响应时间、90%响应时间、TPS、错误率吗？
8. 失败请求有样本吗？能复现吗？
9. 测试时长够不够观察稳定性？有没有记录开始和结束时间？
10. 报告里写清楚“这次测了什么、没测什么、结论依据是什么”了吗？

提示：排查时先问“这个错误是脚本造成的还是系统造成的”，比直接下结论更省时间。

5. 从零走一遍测试实施流程：需求、架构、测试点、工具、计划、环境

假设你接到一个任务：给一个内部内容管理站点做上线前性能验证。别急着打开工具，按“需求、架构、测试点、工具、计划、环境、实施”的顺序走一遍。下面用模拟项目X来演示，不涉及真实系统，你把自己的项目代进去就行。

5.1 问清需求并写成验收句

先问这次测试要回答什么。是新系统能力验证，还是客户有明确指标，还是找瓶颈，还是稳定性验证？目的不同，后面做法不同。问完目的，写验收句。模板还是那句：在【测试环境】下，用【并发数】模拟【业务场景】持续【时长】，要求【指标】不超过【阈值】，错误率低于【阈值】。以模拟项目X为例，可以写成：在独立测试环境下，用20个并发用户模拟登录场景持续5分钟，要求平均响应时间不超过3秒，90%响应时间不超过5秒，错误率低于1%。这句话写出来，你就知道要准备登录账号、要跑5分钟、要看两个响应时间指标和错误率。跟做一步：把你的任务写成一句，然后把每个数字的来源标注在括号里，比如“20个并发来自业务方给出的高峰预估”。

5.2 画一张最小架构图：浏览器、应用、数据库三段就够

了解系统架构对新手来说最难，但入门不需要一开始就看懂所有细节。材料把系统分成表示层、业务逻辑层、数据层。表示层是浏览器，用前端技术展示功能和数据，和用户交互，通过HTTP协议和业务层通信；业务逻辑层是中间层，应用服务器运行中间件，中间件作为容器运行应用软件，应用处理请求时调用数据层；数据层运行数据库服务，负责存储和查询。大型系统会拆分应用服务、用负载均衡分散请求、用数据库集群支撑更大访问量。入门先画三段：浏览器发请求到应用服务器，应用服务器查数据库，数据库返回结果，应用服务器再把结果返回浏览器。把这三段画出来，你至少知道压测时该看哪几台机器、日志去哪里找、数据库连接数在哪里看。

5.3 选测试点：从高频、关键、重资源里挑

性能测试点不用把所有功能都测一遍。材料给了三个选取原则：发生频率非常高的、关键程度非常高的、资源占用非常严重的。以模拟项目X为例，登录几乎每天都要用，是关键入口；列表查询频率高，可能消耗数据库资源；附件上传可能占用磁盘I/O；修改昵称频率低、资源占用小，可以先不测；导出报表如果一次查大量数据，就属于资源占用严重的点。你可以列一个表，给每个功能按频率、关键度、资源消耗打高、中、低，先选两个高频和一个重资源功能做第一轮。

5.4 写测试计划与搭环境：先写“不做什么”

测试计划不用写成厚文档，入门一页纸也能写清楚：简介、测试需求、测试环境、测试场景、指标、风险。简介写背景和范围；测试需求写验收句；测试环境写软件硬件网络；测试场景写登录、查询分别怎么压；指标写响应时间、TPS、错误率；风险写清楚这次不测什么，比如不测支付、不测第三方接口、不测公网网络。把“不做什么”写下来，能避免报告被追问时说不清。环境尽量独立，软件环境记录操作系统、Web服务器、应用服务器、数据库的大致类型和配置，硬件环境记录CPU、内存、磁盘、网络，网络环境尽量保证测试机和被测服务器在同一个局域网内，避免其他人同时占用带宽。

5.5 第一个入门例子：10个虚拟用户压登录

现在跑第一个小例子。目标不是压出系统极限，而是走通流程、看懂数据。步骤如下：

1. 在测试环境准备一个可登录账号，确认登录接口地址、请求方法、参数和成功返回标识。
2. 打开一款轻量压测工具，新建线程组，线程数填10，Ramp-up填10秒，循环次数填3。线程数是虚拟用户数，Ramp-up是逐步启动时间，循环次数是每个用户重复执行次数。
3. 添加HTTP请求，填协议、域名或IP、路径、方法、参数。参数里如果有会话标识，要确认每次请求能正确带上。
4. 添加响应断言，至少判断状态码成功，并判断返回内容里有登录成功标识。只判断状态码不够，有的系统失败也返回200。
5. 添加聚合报告或结果监听器，用来记录平均响应时间、90%响应时间、TPS、错误率。
6. 先把线程数改成1、循环1次，跑一次调试。确认请求成功、断言通过、报告里没有异常。
7. 正式跑10个用户、10秒Ramp-up、循环3次，记录平均响应时间、90%响应时间、TPS、错误率。
8. 同时记录被测服务器CPU、内存、数据库连接数，以及压测机自身CPU和网络。
9. 保存结果，写一句结论，比如“在10个虚拟用户、持续约30秒的登录场景下，错误率为0，平均响应时间X秒，TPS为Y，未观察到服务器资源打满”。

这个例子里，10个用户不是同一毫秒一起发请求，Ramp-up会让请求逐步上来，更接近真实用户陆续进入。先单用户调通再跑并发，是为了避免脚本错误被当成系统错误。跑完不要只截一张图，把参数、环境、结果、结论写在一起，后面加并发或换场景时才有对比基础。

注意：这个例子只适合在你有权限的测试环境做。公网压测不能代表服务器处理能力，也容易影响无关系统。

6. 下一步学什么：从基础概念走到第一次性能调优尝试

看懂概念之后，下一步不是马上啃调优大全，而是把这份材料里的流程练成一次能交付的小压测。我建议按三条线走。第一条线是复述指标：合上材料，用自己的话讲清楚并发用户、吞吐量、TPS、响应时间三段分别是什么，再举一个理发店例子。讲不顺的地方回去看对应章节，直到能对着一个完全不懂的人说明白。第二条线是算一次TPS：找一份测试环境的请求日志，按时间窗口数一下完成的事务数，除以秒数，算出来的数字和压测报告对一对，看看差异在哪里。第三条线是做一次10到20个并发的小压测，按第5章的步骤走完，写一页报告，包含验收句、环境、场景、结果、结论和“这次没测什么”。

性能调优入门也别一上来就改代码。先学会看现象：错误率升高是脚本问题还是系统问题，响应时间变长是应用处理慢还是数据库查询慢，TPS上不去是服务器资源满了还是压测机先满了。把第4章的排查顺序走熟，比背一堆调优参数有用。材料里提到的配置测试和可靠性测试，可以等你完成两三次小压测后再碰，那时你对基线、环境、指标都有感觉了。

我第一次学的时候，一上来就调线程数，脚本里登录参数写死了，错误率飙到一半，还以为是系统扛不住，后来单用户一跑才发现是脚本没通。血泪经验就是：先单用户调通，再看错误率，再看响应时间分布，最后才加并发。从那以后我每次压测都强制走一遍“单用户调通、记录基线、逐步加压、保存证据”的习惯，不再一上来就追求大数字。这份《Web性能测试--基础概念》适合放在手边当第一张地图，先看概念，再照着第5章的流程做一次小练习，你会比只看不练更快入门。希望帮到你。

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