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