第一次拿到 Web 性能测试赛项的题目我盯着那张只有几行需求的纸坐了大概十分钟脑子里想的不是怎么压而是它到底想让我交出什么东西。全国大学生软件测试大赛里的 Web 性能测试方向和平时做功能测试、写几个用例跑一跑的感觉完全不一样——它考的是你能不能把一套负载模型搭起来、把数据读明白、把结论说清楚。这篇就当是我自己的一次完整复盘从环境准备、脚本开发、场景设计一直写到结果分析和报告收尾重点放在一个完整实例上而不是零散的知识点罗列。不管你是第一次报名、还在纠结 JMeter 装哪个版本还是已经能跑通脚本但报告写不出结论我想这些内容都能对上你的需求。软件测试这个行当里性能测试一直是面试高频区八股文背得再熟真到压一个系统的时候能不能讲清楚并发数怎么算出来的TPS 掉在哪个环节才是分水岭。1. 赛项拆解Web 性能测试到底在考什么1.1 从任务书倒推考点分布我习惯拿到题目先做一件事把任务书里的动词圈出来。通常会出现设计执行分析提交这几个词它们其实对应了四个完全不同的评分维度。设计对应测试计划的结构是否合理执行对应脚本能否稳定跑完、数据是否可信分析对应你能不能从聚合报告里挑出真正的瓶颈提交对应报告有没有把结论讲清楚。很多同学栽在执行上觉得脚本能跑通就万事大吉结果跑到一半冒出几百个错误最后交上去的数据自己都不敢信。也有人脚本写得漂亮报告里只有一句系统性能良好评委看完完全不知道他测了什么。所以真正的考点不是工具会不会用而是闭环能力需求到模型模型到脚本脚本到数据数据到结论。还有一点容易被忽略题目里给的业务场景通常只有一两个页面比如登录加查询看起来特别简单。但越是简单的场景越考验你对参数化、关联、事务边界的处理是否规范。因为场景简单评委的注意力就全落在细节上。1.2 为什么 JMeter 是事实标准这几年赛项里能用的工具其实不止一个LoadRunner、Locust、k6 都有人用但 JMeter 依然是绝大多数人的选择原因很实在。第一它是纯 Java 的跨平台Windows 和 Linux 上跑起来行为一致第二命令行模式加 HTML 报告的组合天然适合跑完就出报告的比赛节奏第三插件生态成熟阶梯加压、每秒事务数曲线这些都有现成组件。我用 Locust 也做过几轮压测Python 写脚本确实舒服但在比赛这种时间紧、要反复调参的场景下JMeter 的图形化元件树对排查问题的帮助更大——你能一眼看出哪个元件顺序放错了。Locust 一旦脚本里有个协程阻塞排查起来就很费劲。注意工具选型不要临时改。见过有人前两天用 JMeter 写了一版第三天觉得 k6 更酷结果两边都半吊子。选定一个就深挖到底。顺带说一句性能测试相关岗位的面试题里你为什么选 JMeter 而不是 LoadRunner出现的频率非常高答案不是因为免费而是要说清楚协议支持范围、扩展方式、报告能力这几个维度的取舍。这段话你写进比赛报告里也是加分的。2. 环境搭建与工程目录规划2.1 版本匹配这件小事的杀伤力JMeter 对 JDK 版本有要求新版一般要求 JDK 8 以上某些版本在 JDK 17 上会有模块访问告警。我踩过的坑是本机装了 JDK 17JMeter 启动正常但一挂上某些老插件就报反射相关的异常。后来统一换成 JDK 8 或者 JDK 11问题就消失了。具体做法是给 JMeter 单独指定 JDK不去动系统的 JAVA_HOME。在jmeter.bat同目录下改环境变量或者直接在命令行里临时设置export JAVA_HOME/opt/jdk-11 export PATH$JAVA_HOME/bin:$PATH ./jmeter -vWindows 下同理用set JAVA_HOME...临时覆盖。这样做的理由是避免污染系统环境比赛机器往往是公用的动全局变量容易出乱子。内存参数也必须调。默认堆只有 1G压测时如果开了聚合报告这种内存大户很容易 OOM。在jmeter.bat或jmeter脚本里找到 HEAP 那一行改成HEAP-Xms2g -Xmx4g -XX:MaxMetaspaceSize256mXms 和 Xmx 设成一样可以避免堆在运行中反复扩容带来的抖动这个细节在长时间稳态压测里影响不小。2.2 目录结构决定你能不能在 5 分钟内重跑我见过太多人把所有文件丢在桌面result.jtl和plan.jmx混在一起第二次跑的时候覆盖了第一次的数据急得拍桌子。一个干净的结构应该是这样目录用途说明plan/存放.jmx脚本按场景命名如login_query.jmxdata/CSV 参数文件账号、关键词等result/jtl 与 HTML 报告每次执行建一个带时间戳的子目录conf/自定义 properties覆盖jmeter.properties里的关键项执行的时候用绝对路径或者-p指定配置文件避免在我机器上能跑的尴尬。jmeter.properties里我必改的几项顺便解释下为什么jmeter.save.saveservice.output_formatcsv jmeter.save.saveservice.thread_countstrue sampleresult.default.encodingUTF-8 CookieManager.save.cookiestrue httpsampler.max_redirects20thread_countstrue会在结果文件里记录当时的线程数后面画 TPS 与并发的关系曲线就靠它不打开的话你根本不知道某个时间点压了多少并发。CookieManager.save.cookiestrue是把 Cookie 里的 JSESSIONID 之类当变量存下来后面做关联判断时很方便。提示改 properties 之前先备份原文件。比赛现场如果要换机器把conf/整个目录拷过去就能复现环境比重新配一遍省十几分钟。3. 脚本开发实战从录制到参数化关联3.1 录制还是手写别纠结太久录制能省时间但录出来的脚本通常是一坨——一堆自动命名的事务控制器、一堆用不上的监听器、固定的 Cookie 和 token。我的做法是折中用浏览器代理或者 BlazeMeter 插件录一遍只保留请求本身然后手工重建元件树。重建的时候按这个顺序往下摆测试计划线程组HTTP 请求默认值填服务器、端口、协议、内容编码 UTF-8HTTP Cookie 管理器HTTP 信息头管理器事务控制器包住一个完整业务取样器 提取器 断言顺序不是随便排的。HTTP 请求默认值要放在线程组下面、取样器上面这样同级的取样器才继承得到。Cookie 管理器和信息头管理器是并列关系谁先谁后不影响但都必须在取样器之前。事务控制器有一个选项叫Generate parent sample勾上之后聚合报告里只显示事务控制器这一条的统计子请求被折叠进去。这样做的好处是报告干净你一眼能看出一个完整的登录业务平均耗时多少坏处是你看不到单个请求的耗时定位问题时要临时取消勾选。我在比赛里的做法是调脚本阶段不勾出报告阶段勾上。3.2 参数化CSV Data Set Config 的几个开关参数化是为了让不同虚拟用户用不同数据避免缓存命中导致数据虚高。CSV 数据文件集配置里参数含义要搞清楚参数取值建议原因Filename用相对路径data/accounts.csv换机器不用改路径Variable Namesusername,password与请求体里的占位符对应Delimiter逗号数据里别混入逗号Recycle on EOF视情况数据够用就设 FalseStop thread on EOF视情况数据不够时避免线程空转Sharing modeAll threads多线程下各取一行不重复Sharing mode这个选项特别容易忘默认就是 All threads如果误改成 Current thread每个线程都会从头读文件参数化就白做了。还有一个隐藏坑CSV 文件如果带 BOM 头第一行的变量名会带着不可见字符导致取值失败。用记事本另存的时候选UTF-8 无 BOM或者干脆用 VS Code 检查一遍。3.3 关联正则和 JSON 提取器怎么选关联的本质是把上一个请求的响应内容取出来喂给下一个请求。接口返回 JSON 就用 JSON 提取器返回 HTML 或者混合文本才用正则提取器。选错的代价是表达式又长又容易断。JSON 提取器的配置很直观Names of created variables写变量名JSON Path expressions写$.data.token这样的路径Match No.填 0 或 1Default Values一定要填一个兜底值。注意Default Values 千万别留空。留空的话一旦提取失败后续请求会带着空值发出去服务端返回 401你在聚合报告里看到的是大面积错误但要排查半天才知道根因是提取器没配好。正则提取器的模板务必写$1$匹配数字写 1默认值同样要填。调试关联有个笨办法但很好用加一个 Debug Sampler 加一个察看结果树跑一次单线程看看变量到底有没有取到。别一次开一百个线程去猜。3.4 断言与事务边界的配合断言是保证数据可信的底线。响应断言里我一般同时检查响应码和一段关键文本。只检查响应码有个问题有些系统出错时也返回 200但页面内容是系统繁忙。只检查文本又可能因为文案微调而误报。两个一起上稳。持续时间断言也值得加比如要求接口 500ms 内返回就设Duration in milliseconds为 500。这样超时的请求会被标记为失败你就能算出响应时间达标率这个指标比单纯看平均值有说服力得多。事务的边界要想清楚。我见过有人把一次页面加载拆成十几个请求每个都单独算事务报告里几十行数据评委根本找不到重点。合理的做法是一个完整的用户操作 一个事务。登录、查询列表、提交表单各算一个。4. 场景设计与负载模型4.1 并发数、RPS、TPS 到底怎么换算这是整个比赛里我最想强调的一段因为太多人凭感觉填数字。三者关系用利特尔法则就能说清楚并发数 TPS × 平均响应时间秒举个例子。题目要求系统支撑每秒 100 笔业务你测出来平均响应时间是 200 毫秒那么需要维持的并发就是 100 × 0.2 20 个线程。如果响应时间涨到 800 毫秒同样 100 TPS 就需要 80 个并发——这就是为什么响应时间一恶化系统就雪崩。反过来说如果你填了 100 个线程测出来 TPS 只有 50平均响应时间 2 秒套公式一算 100 × 2 200 ≠ 50说明什么说明有大量请求在排队或者失败系统已经过载了。把这段计算过程写进报告比任何形容词都有分量。4.2 阶梯加压与稳态保持不要一上来就拉到最大并发。正确做法是阶梯加压观察曲线拐点。用 Custom Thread Groups 插件里的 Stepping Thread Group配置大概是初始并发 10每 30 秒加 10 个线程加到 100 停止加压稳态保持 5 分钟然后线性降下来为什么要保持至少 5 分钟因为系统在头一两分钟里有缓存预热、连接池填充、JIT 编译这些过程数据不稳定。稳态期的数据才是可信的。降速阶段也别省有些系统在压力撤掉之后会有资源回收的抖动这属于观察项。如果比赛环境不让装插件就用普通线程组配合Ramp-up Period比如 100 个线程、ramp-up 写 200 秒也勉强能模拟线性加压只是看不出稳态平台。4.3 思考时间和吞吐量控制器思考时间决定负载的真实性。真实用户在两秒内连点五次和每两秒点一次给系统的压力完全不同。用 Constant Timer 或 Gaussian Random Timer 模拟一般设在 1 到 3 秒之间。如果题目直接给了目标吞吐量那就用 Constant Throughput Timer。有个坑必须说这个元件的单位是每分钟不是每秒。要跑 120 TPS得填 7200。我第一次用的时候填了 120跑出来 2 TPS还以为是系统扛不住白白排查了半小时。同时要注意Calculate Throughput based on这个选项默认是this thread only意思是每个线程各自限速多线程下总吞吐会被放大。想做全局限速得选all active threads。5. 执行与结果分析把数据读成结论5.1 命令行执行与 HTML 报告正式压测一定用命令行GUI 模式只用来调脚本。GUI 开着跑压测JMeter 自己的界面渲染会吃掉大量 CPU数据完全不可信。而且启动时会弹那句经典提示。命令大概长这样rm -rf result/run_01 ./jmeter -n \ -t plan/login_query.jmx \ -l result/run_01/result.jtl \ -e -o result/run_01/html \ -Jthreads100 -Jduration300-J传的是自定义属性在脚本里用${__P(threads)}引用这样同一份脚本改参数就能跑不同场景不用重新打开 GUI。有个细节-e -o生成 HTML 报告需要 jtl 里有足够的数据数据量太少或者时间跨度太短官方建议 30 秒以上会直接报错不生成。所以哪怕只是试跑也让它跑够一分钟。5.2 聚合报告里真正该看的几列聚合报告列很多但重点就几个指标含义怎么用Average平均响应时间容易被极值拉偏参考即可90% Line90% 请求的响应时间比平均值更能反映用户体验99% Line长尾请求判断是否有慢请求拖后腿Error %错误率超过 1% 就要警惕Throughput吞吐量默认按秒与目标 TPS 对比Received KB/sec网络吞吐判断是否受带宽限制如果平均值和 90% 线差距巨大比如平均 300ms 但 90% 线是 2s说明有一小撮请求特别慢可能是慢 SQL 或者锁竞争这时候要去响应时间分布图里看。5.3 从曲线里找拐点用 TPS 图加响应时间图叠着看你会看到一个典型的形态并发增加TPS 线性上升响应时间基本平稳过了某个点TPS 不再涨甚至下降响应时间开始陡增。这个点就是系统的最大处理能力。我在一次练习里测出来并发从 10 加到 60 的时候TPS 从 50 稳定涨到 280响应时间一直是 200ms 上下到 80 并发时 TPS 反而掉到 260响应时间跳到 600ms。结论就很明确这台环境在 60 到 80 并发之间存在性能拐点推荐工作负载不超过 60 并发。这个结论比系统性能良好有用一百倍。6. 常见问题排查与独家避坑清单6.1 中文乱码与编码乱码的根源永远是编码不一致。按这个顺序检查CSV 文件是不是 UTF-8 无 BOMHTTP 请求默认值里的Content encoding有没有写 UTF-8jmeter.properties里sampleresult.default.encoding是不是 UTF-8。三处都对上基本就不乱码了。还有一种乱码只在察看结果树里出现但断言能过那通常是响应头的 Content-Type 没带 charsetJMeter 按默认编码解析了。这种情况不影响压测结果可以忽略但如果要写进报告最好说明一下。6.2 连接类报错速查报错信息常见原因处理方式ConnectException目标端口未监听或防火墙拦截先用 curl 从压测机验证连通性SocketException: Too many open files文件描述符耗尽调大ulimit -n同步调优内核参数BindException: Address already in use本地端口耗尽缩短连接复用时间或开启端口复用Read timed out服务端处理超时确认超时阈值区分是网络还是业务慢Non HTTP response code非 HTTP 协议返回检查是否被重定向到登录页最后一行那个特别常见压测跑着跑着一部分请求被重定向到登录页返回的是 HTML 而不是 JSON。原因是会话过期或者 Cookie 没保持住。解决办法是把登录做成一次性前置用setUp Thread Group单独跑把 token 提取到全局属性里后面所有线程引用同一个 token。6.3 压测机自己成为瓶颈的识别这是最阴的一类问题你以为是服务端不行其实是压测机扛不住。判断方法看两个地方。一是看压测机的 CPU 和内存。如果压测过程中压测机 CPU 跑到 90% 以上那数据基本不可信。二是看错误类型。如果错误集中在连接建立阶段ConnectException、BindException且数量随并发线性增长八成是压测机的端口或者文件句柄到上限了。我遇到过最典型的一次800 并发的时候错误率突然跳到 15%怎么调服务端参数都没用。后来在压测机上执行ulimit -n显示 1024。改成 65535 之后错误率直接归零。这个坑我记了很久。提示分布式压测能缓解压测机瓶颈但会引入时钟同步、结果合并的问题。比赛时间紧的话先把单机调明白。7. 测试报告撰写与提分细节7.1 一份能被评委读完的报告骨架报告不用写得像论文但要有一条清晰的主线。我的结构是测试目标与范围、测试环境含压测机与被测机配置、业务模型与负载模型含并发数推算过程、测试执行记录、结果数据与分析、结论与建议、附录脚本与原始数据。其中并发数推算过程和结论与建议是拉开差距的两节。前者证明你不是拍脑袋填数字后者证明你真的读懂了数据。数据部分只放关键图表聚合报告截图、TPS 曲线、响应时间曲线各一张就够剩下丢附录。我见过报告里贴了二十张图正文一句话没有的那种很难拿高分。7.2 评委真正关心的三件事第一你的测试是不是可复现。脚本、数据文件、执行命令、参数配置都在别人照着能跑出差不多的结果。第二你的结论有没有数据支撑。说系统存在性能瓶颈就要指出在多少并发、哪个事务、响应时间涨了多少。第三你有没有边界意识。比如说明白这次测试只覆盖了登录和查询两个事务不涉及文件上传和批量导出测试结果不能外推到整个系统。这种自我设限反而是专业的表现。还有个小细节报告里的时间、版本号、环境参数要前后一致。前面写的是 JDK 11后面截图里显示 JDK 17评委会觉得你不严谨。我个人在几次练习和比赛里最大的体会是性能测试的胜负手不在工具而在想清楚。动手之前先花十分钟把负载模型算出来、把事务边界画出来后面能省下几个小时反复调脚本的时间。另一个小技巧是每次压测都把命令行参数完整记在一张便签或者 README 里包括那次改了哪个配置、为什么改——过两天回头看数据你会感谢当时的自己。这套流程跑顺之后你会发现它不只是应付比赛日常做接口压测、上线前评估容量用的都是同一套路子。