简介：《Web性能测试--基础概念》是一份面向初级测试人员与开发者的入门讲义，围绕Web性能测试的核心概念与实施流程展开，帮助读者建立从指标理解到测试落地的整体认知框架。内容由虫师整理，重点讲解压力、负载、稳定性等测试分类，并发用户与“理发店模式”、吞吐量、响应时间等关键指标，并梳理需求确认、系统架构分析、测试点选取、工具选型、计划编写、环境搭建、测试实施、性能调优与报告输出的完整链路。资源包共1个PDF文件，约531KB，篇幅精炼，适合作为培训提纲或自学索引，按章节快速查阅概念与流程要点。目前已有465人学习，便于初学者在动手实践前补齐术语基础，理解性能测试各阶段的目标与衔接关系，也可为后续工具实操和调优排查提供参照。

1. 从一次“网页一直转圈”说起：Web 性能测试到底在测什么

你一定遇到过这种场面：点了登录按钮，页面转圈转了七八秒，最后弹出一句“系统繁忙，请稍后再试”。作为普通用户，你骂一句网速差就关掉了；可如果这个系统归你负责，问题就来了：到底是用户网络差，还是服务器扛不住？是代码写得太慢，还是数据库查询拖了后腿？Web 性能测试就是专门回答这类问题的一套方法：在系统正式对外之前，用工具模拟几十、几百甚至上千个用户同时来访问，看它会不会变慢、会不会报错、到底能扛住多少人。它跟功能测试关心的东西不一样，功能测试问“点下去有没有反应”，性能测试问“一千个人一起点，它还反应得过来吗”。这份入门资料，就是给第一次接触性能测试、连名词都还分不清的人准备的。

2. 先把四种测试分清楚：负载、压力、并发、稳定性到底差在哪

新手看性能测试的资料，最先卡住的地方往往不是技术，而是名词。性能测试、负载测试、压力测试、并发测试、稳定性测试，这几个词在很多团队里是混着用的，开会时有人说“做个压力测试”，有人说“跑个并发”，说的是不是一回事，谁也说不准。这一章先把这几个词的位置摆正，你后面看资料、听需求才不会一头雾水。

2.1 用举重选手和马拉松选手理解“爆发力”和“耐力”

有个比喻挺好用。中学体育课上，教练评价一个运动员，说到底就看两件事：爆发力和耐力。举重选手比的是爆发力，你只要能把这个重量举起来撑住三秒，就算成功，重点是你最多能举多重；马拉松选手比的是耐力，你百米跑得再快也没用，四十公里路谁先到终点谁赢。

回到系统上，爆发力就是它能承受的最大压力——也许它能扛住很大的并发，但撑半个小时就挂了；耐力就是它长时间处在压力下的稳定性——有的系统跑几个月不用重启，这就是耐力好。还有第三件事容易被忽略：整体协调性。教练看运动员，除了看成绩，还要看身体有没有短板，比如一个人四肢练得很壮，但右臂先天萎缩，跑步时其他部位都在替他分担，成绩看着还行，其实体能全浪费在补窟窿上了。对应到系统，就是有没有性能瓶颈，以及要不要针对这个短板做调优。

有了这三把尺子，那些让人头晕的名词就有了落点：压力测试量的是爆发力上限，稳定性测试量的是耐力，瓶颈分析看的是协调性。你不需要背定义，只要问自己一句“我这次到底想量哪一项”，名词自然就分清了。

2.2 四种测试对号入座：每种分别在验证什么

把这几个高频名词摊开看，它们的差别其实在“加压方式”和“要看的结果”上。

这张表不用背，用的时候回来查就行。真正要理解的是两件事：第一，狭义性能测试是有前提的，它要求你事先已经知道系统的经典场景、有明确的性能目标、在确定的环境下跑，本质是“验收”而不是“探索”；第二，负载测试和压力测试最容易混，区别在于负载测试是往上加、找天花板，压力测试是已经压到很高、看它会不会崩。

还有一种叫可靠性测试，或者叫失效性测试，关注的是系统局部出问题时，其他模块还能不能正常工作。这种场景不常见，新手阶段先放一放，知道有这么回事就够了。

2.3 零基础第一次动手，为什么建议从负载测试开始

如果你是自己学着玩，或者领导扔给你一句“你去测测咱们系统性能”，我建议第一个动手的是负载测试，而不是听起来更刺激的压力测试。

原因很实在。负载测试的做法是阶梯式加压，比如先 10 个人跑 5 分钟，再 20 个人跑 5 分钟，一路加到 100 个人，每一步都记录响应时间和错误率。这个过程你能看到一条曲线怎么慢慢弯下去，能直观感受到“原来人一多，响应时间就上去了”。它给你的是连续的、可解释的数据，而不是一个突兀的崩溃现场。

压力测试则要求你先把系统压到资源饱和，这对环境、监控、判断力都有要求，新手很容易压出一个“系统挂了”的结果，却说不清是压测机先撑不住还是被测系统先撑不住，最后变成一场玄学。

我第一次正经跑负载的时候，用的还是一台和别人共用的测试机，跑到一半响应时间突然飙到十几秒，我以为发现了大瓶颈，兴奋了半天，后来才发现是同事在同一台机器上跑编译。这个坑后面第 5 章还会专门讲。

2.4 名词混着用没关系，但每次都要写清三个要素

现实里团队内部名词混用是常态，你纠正别人也未必有用。与其纠结叫法，不如养成一个习惯：每次测试前，把这三个要素写在纸上。

第一是并发数，也就是同时有多少个虚拟用户在操作，10 个还是 500 个，差别是天壤之别。第二是持续时间，跑 3 分钟和跑 3 小时，暴露的问题完全不同，前者看爆发，后者看稳定。第三是通过标准，也就是什么结果算合格，比如“平均响应时间 2 秒以内、95% 的请求 5 秒以内、错误率低于 0.1%”。

这三样写清楚，你管它叫负载测试还是压力测试，别人都能听懂你要干什么；反过来，如果这三样没写，就算名词用得再标准，测出来的结果也没法用。新手最容易犯的错就是上来就问“用哪个工具”，其实工具是最不重要的环节，先把这三个要素想明白，用什么工具都能出结果。

3. 盯住三个数字：并发用户、吞吐量、响应时间

性能测试说到底是在看几个数字，而这些数字最麻烦的地方在于，同一个词在不同人嘴里含义不一样。业务方说“我们有二十万用户”，运维说“同时在线两万”，测试说“并发五百”，三个人说的都不是一回事。这一章把三个核心指标一个一个拆开，每个都配一个生活里的例子，最后给你一段能直接跑的代码，把这三个数字真实量出来。

3.1 并发用户：用一家理发店讲透“最佳”和“最大”

先说清楚并发到底有几种。一种是严格并发，所有用户在同一时刻做同一件事，比如同一秒钟所有人一起点登录；另一种是广义并发，同一时刻有人在登录、有人在提交表单、有人在翻页，请求内容不一样，但时间上重叠。做业务测试时我们通常说的是后者，因为真实用户就是这么七零八落地来的。

然后要区分三个容易打架的概念。系统用户数是注册用户总数，比如二十万；同时在线人数是某个时刻浏览器还开着这个站的人，比如两万；并发用户数是同一时刻真正向服务器发出请求的人，这个数往往远小于前两个。二十万注册、两万在线，实际压在服务器上的并发可能只有几百，因为大部分在线用户这会儿正在发呆、看别的页面、或者去接水了。真正的并发量级一般要靠分析服务器日志和业务模式估算，不能想当然。

理发店的例子能把“最佳”和“最大”讲明白。假设一家店有三位师傅，每位服务一位客人要一小时，客人从进门起最多愿意等三小时（等待加服务总计）。

最佳用户数就是三位。这时候师傅一刻不闲，收入最高；客人随到随剪，不用等，满意度最高。系统里对应的就是那台机器刚好被充分利用、又没有任何人排队的甜蜜点。

最大用户数需要算一下。一开门涌进来一群人，A、B、C 先剪；D、E、F 得等一小时；G、H、I 得等两小时；再往后的 J、K、L 已经等了三小时还没轮上，超过了忍耐极限，扭头走了。所以这个时间点上，店里能留住的用户是九个：三个在剪、三个等一小时、三个等两小时。后面那些等了三小时还没被服务的人，不能算进最大用户数里，因为他们实际上已经流失了。

还有一个细节：如果店面很小，最多只能站六个人，那么第七个人虽然只需要等两小时、也在他愿意等的范围内，但门都进不来，只能改天再来。对应到系统上，这就是连接数、线程池、队列长度这类容量限制在起作用，它可能比服务能力更早成为瓶颈。

把这两个数放到系统里看，最佳用户数告诉你“跑得最舒服是多少人”，最大用户数告诉你“最多能接多少人而不把人赶走”。做容量规划时，你需要让系统的工作区间落在这两个数之间，而不是贴着最大值硬撑。

3.2 吞吐量和吞吐率：一个水龙头和十个水龙头的故事

生活里我们不太关心自来水厂一天供多少水，但对水厂来说这是命根子。同理，普通用户不关心一个系统吞吐量多大，但对系统来说这是关键指标。

吞吐量指的是一次测试过程中网络上传输的数据总量。它反映服务器承受的压力，在容量规划里是重点，在调优时也有价值。但单看吞吐量会得出荒谬结论：一个水龙头开 24 小时流出 10 吨水，十个水龙头开 1 秒流出 0.1 吨水，你能说一个水龙头的出水能力远超十个水龙头吗？显然不能，因为你没算时间。

所以必须加上时间单位，这就引出了吞吐率：单位时间内传输的数据量，或者单位时间内处理的请求数。常用“字节数每秒”衡量，也可以用“请求数每秒”“页面数每秒”；从业务视角看，还能用“业务笔数每小时”“访问人数每小时”。比如一个审批类系统，用“千件每小时”来描述处理能力就很自然。

从这里延伸出两个词，新手经常绕不清。事务，指用户一段有完整意义的操作集合，一次登录、一次下单支付、一次表单提交都算一个事务。TPS 就是每秒能处理多少个这样的事务，它是衡量系统处理能力的核心指标。

点击率，指每秒用户向 Web 服务器提交的 HTTP 请求数。Web 应用是请求-响应模式，用户发一次、服务器处理一次，所以点击是 Web 应用能处理的最小交易单位。如果把每次点击都当成一个事务，那点击率和 TPS 就是一回事。要注意这里的“点击”不等于鼠标点一下——你点一次按钮，页面可能同时发出五六个请求，加载图片、样式、接口数据，这些都算点击。

吞吐量这个指标有两个实际用途。一是帮你设计测试场景：先估算业务峰值时每秒会发生多少事务，再换算成测试脚本里的事务频率和循环次数，场景就有了依据；测完之后拿实际吞吐量对照预期，就知道有没有达标。二是帮你定位瓶颈：吞吐量上不去本身就是瓶颈的一种表现形式，有针对性地围绕吞吐量设计测试，能更快找到问题出在哪一段。

有个经验性的方法叫快速瓶颈识别，它基于三个观察：多数系统的性能瓶颈都和吞吐量受制约有关；并发用户数和吞吐量瓶颈之间存在关联；用吞吐量测试能更快定位问题。做法就是一边加并发一边看吞吐量，然后从网络、数据库、应用服务器、代码这四个环节逐个排查。

3.3 响应时间：一封寄给远方朋友的信

站在用户角度，软件性能就等于响应时间。从你点下按钮那一刻，到结果以你能看懂的方式显示出来，中间耗掉的每一毫秒都算。

这段时间可以拆成三段。第一段是呈现时间，浏览器拿到数据后渲染展示的过程。同一台电脑同一个网站，换个浏览器打开速度可能就不一样，这部分还跟操作系统、CPU、内存有关，配置低的机器多开几个页面就卡住了。

第二段是数据传输时间。你给远方的朋友寄信，影响他收到时间的既不是你写信的速度，也不是他读信的速度，而是路上运信的时间。系统里也一样，请求发出去要时间，结果传回来还要时间。很多新手喜欢拿工具去压公网上的网站，甚至以为能靠这个把人家压垮，这就有点想多了：你的带宽多大？互联网上从 A 到 B 可能走完全不同的线路，延迟多少你根本控制不了。就算请求都发出去了，到达服务器时早就不是“同时”了。所以正经的性能测试一般要求在局域网内做，就是为了把传输时间这个变量摁住。

第三段是系统处理时间，服务器拿到请求、处理、返回结果的时间。前两段你控制不了——用户的电脑配置千差万别，网络状况千差万别——你唯一能压缩的就是这一段。所以性能测试工具通常会屏蔽页面渲染过程，只模拟并发请求、记录拿到响应的时间，不会把每个响应都真正渲染出来。局域网环境下带宽不构成限制，传输时间基本可以忽略，测出来的就接近系统处理时间。

理解了这三段，你就明白为什么同一个系统在不同人电脑上“感觉快慢不一样”——那多半不是系统的问题，而是呈现和传输在捣鬼。

3.4 第一个小例子：用二十几行代码把三个数字量出来

概念讲完，得动手。这里不用任何商业工具，用 Python 标准库写一个最小可跑的并发请求脚本，把并发数、响应时间、吞吐率三个数字打出来。你需要先有一个可以访问的接口地址，本地起一个测试服务最合适。

import time import statistics import urllib.request from concurrent.futures import ThreadPoolExecutor TARGET = "http://127.0.0.1:8000/api/login" # 被测接口，换成本地地址 CONCURRENCY = 20 # 并发用户数：同时发请求的线程数 ROUNDS = 5 # 每个用户连续发几次请求 TIMEOUT = 10 # 单次请求超时秒数，防止卡死 def one_user(uid): """模拟一个虚拟用户：连续发 ROUNDS 次请求，记录每次耗时""" records = [] for i in range(ROUNDS): start = time.perf_counter() ok = True try: with urllib.request.urlopen(TARGET, timeout=TIMEOUT) as resp: resp.read() # 必须读完响应体，否则计时会偏小 except Exception: ok = False # 超时或报错都记一次失败 records.append((time.perf_counter() - start, ok)) return records start_all = time.perf_counter() with ThreadPoolExecutor(max_workers=CONCURRENCY) as pool: results = list(pool.map(one_user, range(CONCURRENCY))) total_seconds = time.perf_counter() - start_all flat = [item for user in results for item in user] costs = [c[0] for c in flat] ok_count = sum(1 for c in flat if c[1]) costs_sorted = sorted(costs) print(f"总请求数: {len(flat)}") print(f"成功数: {ok_count} 错误率: {(1 - ok_count / len(flat)) * 100:.1f}%") print(f"平均响应时间: {statistics.mean(costs) * 1000:.0f} ms") print(f"95% 响应时间: {costs_sorted[int(len(costs_sorted) * 0.95) - 1] * 1000:.0f} ms") print(f"吞吐率: {len(flat) / total_seconds:.1f} 请求/秒")

这段代码干的事很朴素：开 20 个线程，每个线程像一个用户那样连续请求 5 次，总共 100 次请求，全程计时。跑完打印五个数字。

几个参数值得说清楚。CONCURRENCY 就是并发用户数，改成 50 就是 50 个并发，但注意线程数不等于真实用户数，线程开太多反而会被你自己的机器拖累，笔记本上一般 100 以内比较稳。ROUNDS 决定每个用户重复几次，次数太少样本不够，平均值容易被偶然一次抖动带偏。TIMEOUT 一定要设，否则一个卡住的请求会让整个脚本挂在那里等。

输出里最该看的是 95% 响应时间，而不是平均值。平均值会把少数极慢的请求藏起来——比如 100 次里有 5 次花了 8 秒，平均值可能还是 1 秒出头，看着很漂亮，但那 5 个用户已经骂人了。95% 分位的含义是“有 95% 的请求比这个值更快”，它更接近真实体感。

吞吐率是用总请求数除以总耗时得到的，单位是请求每秒。这个数会随着并发数上升先涨后平，涨到某个点就不动了，那个拐点附近就是你这套环境的处理能力上限。你可以把 CONCURRENCY 依次改成 5、10、20、50 各跑一遍，把结果记在表格里，就能画出自己那条曲线。

提示：跑之前先确认被测服务是你自己的或者你有权测试的，对不属于自己的系统施压既没有意义也不合适。

4. 接到任务别懵：一份能照着走的流程

假设你刚入职，早会上领导说“这个新系统上线前你测一下性能”，然后散会了。这时候大部分人脑子里是一片空白。其实性能测试有一套通用流程，照着走一遍，即便你是新手，做出来的东西也不会跑偏。这一章按顺序拆成五步。

4.1 第一步 问清需求：四种目的对应四种做法

拿到任务，第一件事不是打开工具，是问清楚“为什么测”。按目的分，常见的有四种。

第一种是新系统能力验证。系统刚开发完，上线前想看看它行不行。这种情况你自由度最大，环境、压力点、工具都能自己挑，策略也灵活，只要结果没有明显短板，一般不需要调优。

第二种是客户有明确要求。这是最省事的，客户直接给了指标，比如“支持 100 个用户同时登录，平均登录时间不超过 5 秒”。你要做的就是设计一次测试来验证能不能达到。至于是靠优化代码还是加机器达标，那不属于测试要回答的问题。

第三种是找瓶颈。目的很明确，就是找出系统哪里拖后腿，为调优或扩容提供依据。这时候重点不在跑多大的压力，而在架构分析和业务分析上，你得知道数据从哪来到哪去。

第四种是稳定性验证。系统上线后会长期被人访问，一些平时不冒头的问题会慢慢浮出来，典型的就是内存泄漏。这类测试在策略上必须拉长运行时间，跑 8 小时、12 小时甚至更久。

问需求还有一层好处：从对方的措辞里你能判断出这次测试受重视的程度，是要一份正式报告，还是只要一句“没问题”。这决定了你后面投入多少精力。

4.2 第二步 摸清架构：三层结构五分钟看懂

新手听到“系统架构”四个字容易发怵，其实大多数 Web 系统的骨架就三层。

表示层是用户看到的那一层，浏览器靠前端技术把功能和数据展示出来，通过 HTTP 之类的协议跟后面通信，发请求、收响应。业务逻辑层在中间，应用服务器上跑着中间件，中间件像个容器，把各种应用装在里面，前台请求进来后由应用程序处理，处理过程中去数据层取数据，再把结果原路返回。数据层在数据库主机上，负责存数据和提供查询，应用程序通过数据库连接跟它打交道。

大型系统会在这三层的基础上加东西。业务层可能被拆成交易服务、查询服务等好几个模块；前面加负载均衡，把请求分散到多台机器上；数据层用数据库集群来撑更大的数据量。

常见的组合无非这几种：Linux 配 Apache、PHP 加 MySQL；Linux 配 Nginx、缓存服务、PHP 加 MySQL；Linux 配 Tomcat、Java 加商用数据库；Windows 服务器配 IIS、.NET 加数据库；也有 Linux 配 Python 应用服务器、Nginx 加 MySQL 的。你不用会写这些技术，但必须知道被测系统用了哪一套，因为环境搭建阶段要照着部署，性能分析阶段要按这套结构去找短板。

4.3 第三步 挑测试点：三个“最”字和一个“准”字

系统功能几十上百个，不可能全测，得挑。挑的原则有三个。

发生频率最高的优先。比如一个邮件类系统里，登录和收发邮件占每天业务总量的九成以上，那它们就是核心测试点。关键程度最高的优先，产品负责人认为绝对不能出问题的功能，哪怕调用量不大也要测，登录是典型。资源占用最严重的优先，比如某个提交操作要往几十张表里写数据，或者某个查询一次要捞出几万条记录，这类操作对磁盘和数据库的压力极大。

挑完还要把需求描述清楚，这里有三个要求。准确，比如“系统必须在 10 秒内处理 20 起登录任务”，数字要明明白白。一致，用户和测试对术语的理解要统一，并发用户数、在线用户数、注册用户数不能各说各话。有条件，一条完整的性能需求一定带着前提，比如“后台关键业务数据 10G、操作数据量 20K、1500 个用户、500 个并发、连续运行 12 小时”这样一个组合。

举几个常见的需求写法给你找感觉：首页打开 5 秒以内、登录 15 秒以内；邮件服务支持 50 万在线用户；计费话单成功率 99.999% 以上；100 个并发用户的高峰期，基本功能处理能力至少 10 TPS；系统在高于实际压力一倍的条件下稳定运行 12 小时；系统能支撑每天 200 万人次登录。

4.4 第四步 选工具和写计划：把需求翻译成场景

工具分三类，各有各的脾气。

商业工具功能全、协议支持广、有现成的报表和售后，代价是授权费用高，不是每个项目都批得下来。开源工具数量多、体积小、免费，覆盖大部分常见场景，缺点是功能相对简陋，遇到特殊需求可能要几款配合着用，或者自己改源码——这对使用者的要求就高了，得看得懂工具的原理。自研工具适合需求特别特殊、市面上找不到合适方案、或者有长期规划的团队，一次开发长期使用，但后续的维护升级跑不掉。

怎么选？先看能不能满足需求，协议不支持、脚本建不起来、模拟用户数上不去，再便宜也白搭，直接排除。再看成本，在够用的前提下一切从简。最后看学习成本，这一条最现实：你花半年才能上手一款工具，项目早就结束了。所以实用的建议是，手上至少熟练一款商业工具、一款开源工具，再会一门写脚本的语言，这样什么场合都能应付。

工具定了就写计划。一份计划书不用写得多华丽，但几块内容不能少：项目背景和这次测试的原因；被测对象和压力点，也就是 4.3 挑出来的那些；测试环境，包括软硬件和网络，最好是一个独立环境，别和别人的测试挤在一起；测试场景，每个场景的并发数、持续时长、通过标准；还有时间安排和人员分工。

写到场景这一节时，你会发现前面做的事全串起来了——需求给了指标，架构决定了要监控哪些机器，测试点决定了脚本要覆盖哪些操作，工具决定了脚本怎么写。

4.5 第五步 搭环境、跑起来、看数据、找瓶颈

环境搭建要尽量贴近生产，但不必一模一样，关键是让结果有可比性。软件环境指操作系统、中间件、数据库的版本和配置；硬件环境包括 CPU、内存、磁盘、网卡，连传输介质和路由器也该考虑进去；网络环境要求测试机和被测服务器在同一个局域网内，并且这个网络最好别被别人占用。

执行阶段要注意的是记录。跑的时候不光看工具报出来的响应时间，还要同步采集服务器的 CPU、内存、磁盘 IO、网络流量。工具那边是“用户感受”，服务器这边是“系统体征”，两边对不上就要警惕。

跑完就是分析。先看指标达没达标，再看曲线形状，最后定位瓶颈在哪一段。瓶颈无非四个环节：网络、数据库、应用服务器、代码本身。一个实用的做法是围绕吞吐量做文章，一边加并发一边观察吞吐量什么时候不再上涨，然后在这四个环节里逐个排除。

找到瓶颈之后才是调优。调优不是瞎改，一次只动一个变量，改完重测，对比数据。同时改三个参数，性能上去了你也不知道是谁的功劳，性能下去了更不知道该回退哪个。

5. 新手最容易翻车的五个地方

这一章把常见坑集中列一下，每条按“看到什么现象—为什么会这样—怎么处理”来说。

第一个坑：在公网上压测，结果全是玄学。

现象是同一份脚本，今天跑出来平均 800 毫秒，明天跑出来 3 秒，波动大得没法解释。原因是你的请求要经过公网，走哪条线路、中间堵不堵、带宽够不够，全都不受控，而且请求到达服务器时早就不是同时的了。解决办法很干脆：把压测机和被测系统放进同一个局域网，公网压测只适合做连通性和大致的体感验证，不能用来下结论。

第二个坑：把“同时在线人数”直接当成并发用户数。

现象是照着两万在线用户去设计场景，压测机自己先崩了，或者压出来的结果惨不忍睹，业务方以为系统完蛋了。原因是同时在线只表示浏览器还开着，大部分人这会儿没发请求。解决办法是先用日志和业务模型估算真实的请求密度：两万在线里，每秒真正发请求的可能只有几百。算清楚再设计场景，别拿注册用户数、在线用户数直接当并发数用。

第三个坑：只看平均响应时间，不看分位和错误率。

现象是报告上写着平均 1.2 秒，看着挺漂亮，结果上线后用户投诉一片。原因是平均值把少数极慢的请求稀释掉了，而且错误率如果没统计，失败的那部分直接被忽略。解决办法是至少同时看三样：平均响应时间、95% 或 99% 分位响应时间、错误率。分位值更接近真实体感，错误率决定这份数据有没有意义。

第四个坑：脚本里没有思考时间，压力严重失真。

现象是脚本跑出来的 TPS 高得离谱，跟真实业务量完全对不上。原因是脚本一秒钟能发几十个请求，而真实用户点一下要停几秒看看页面、填填表单，工具把人变成了不知疲倦的机器。解决办法是在脚本里加思考时间，模拟用户操作之间的间隔，间隔大小按真实业务的操作节奏来估。另外，需要“同一时刻一起冲”的场景（比如抢购），要单独配置集合点，让虚拟用户攒够了再一起发，这跟普通场景是两种写法。

第五个坑：一次改好几个参数，出了问题没有后悔药。

现象是调优之后性能确实涨了，过两天又慢回去了，谁也说不清是哪次改动起了作用。原因就是同时动了应用配置、数据库参数和 JVM 参数，变量之间互相影响。解决办法是老规矩，一次只改一项，改完立刻重测并记录，把每次的配置和结果都留档。这份记录在半年后别人接手时价值极高。

注意：压测前一定要确认被测系统归属，并且避开业务高峰期，测试环境和生产环境不要共用同一套资源。

6. 下一步学什么：给零基础的三个月上手路线

概念和流程都过了一遍，接下来最怕的是“看懂了但不会做”。这里给一条可以照着走的路线，三个月为一个周期，每周投入十小时左右就够。

几个技巧能让你少走弯路。

第一，先手工算一遍再动手。比如要测一个下单接口，先估算峰值每秒多少单、每单涉及几个请求、要压几分钟。算完你会发现很多参数根本不用试，纸上就有答案了。我第一次做的时候直接开跑，跑完面对一堆数字不知道算好还是算坏，因为没有预期值可对比。

第二，每次测试都留一份“环境快照”，把机器配置、软件版本、部署方式、当天有没有别人用这几台机器全记下来。过一周你回头看数据，如果没有这份记录，那些数字就变成了黑匣子，谁也不知道当时是什么条件。

第三，报告里永远先写结论再写数据。别人要的是“能不能上线”，不是“我们跑了 37 分钟”。结论、关键指标、瓶颈位置、建议，四段话说完，剩下的数据放附录。

第四，养成看分位值的习惯。平均值用来汇报，分位值用来判断，两个都得看。

最后说个我自己的教训。刚开始学那阵子，我特别喜欢直接开压，觉得跑起来才算学。有一次压出来一个特别漂亮的数字，兴冲冲写进报告，结果被问了一句“你这个环境跟生产一样吗”，当场卡住——我压的是自己笔记本上跑的简化版，数据库还是内存模式的。从那以后我每次开压之前，都会强制走一遍“三问”：这次测的目的是什么、环境跟目标环境差在哪、什么结果算通过。这三问写在纸上花不了三分钟，但能省掉后面所有的返工。

这份资料的好处是它把概念和流程放在了一起，你可以在读第 1 章时先把三个核心指标弄明白，再顺着第 2 章的思路走一遍完整流程，边看边在自己的机器上跑一遍第 3 章那段小脚本。下载之后建议先翻目录，从性能测试分类和并发用户那两节读起，那是最容易建立手感的地方。希望帮到你。

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