1. 为什么非要把Jmeter和Jenkins搭在一起先说个真实场景。刚接触接口压力测试那会儿我都是本地开着Jmeter手动点“启动”按钮盯着聚合报告看数字测完手动截图、手动整理结果发给群里。一次两次还能忍等接口越来越多、版本迭代越来越快这套流程就完全顶不住了。每次发版前要回归压测夜里跑完还得早起看结果漏跑一次线上就出事故。后来把Jmeter脚本塞进Jenkins让压测变成流水线里的一个普通环节定时跑、自动出报告、失败了自动报警这才算是把这块补上了。这个组合的核心价值其实就一句话把“一次性的人工压测”变成“可重复、可追踪、自动触发的持续压测”。Jmeter负责把接口的并发压力模拟出来Jenkins负责调度、触发、收集结果、分发报告。两者一组合你就不再需要一个人守着电脑等结果而是让压测这件事融入日常研发流程每次代码提交、每晚定时巡检、每次发版前回归都能自动跑一遍。这篇文章面向的读者我按经验分一下一是已经在用Jmeter做单接口压测、想往自动化方向走的人二是团队想搭持续集成但不知道从哪下手的测试开发三是被领导安排“做个压测平台”但实际只需要一个轻量方案的运维或后端同学。不管你是哪一类照着下面的步骤走一遍基本就能把这条链路跑通。组合方案的另一个隐性收益是沉淀标准。脚本进了代码库、构建过程进了Jenkins、结果进了历史记录那么“压测到底怎么测”“用什么并发量”“通过标准是什么”就不再是某个人脑子里的经验而是团队可以对齐、可以评审的资产。后面新同事接手打开Jenkins任务看一眼参数和历史报告马上就能上手这比任何培训文档都管用。2. 环境准备与工具选型2.1 版本怎么选Jmeter和Jenkins的版本坑我踩过不少。先说Jmeter线上环境如果没特殊要求我建议用5.x的稳定版比如5.6.3这类别追最新。因为Jmeter的插件生态对新版本适配有滞后性你用到一半发现某个插件不兼容再回退版本更折腾。最新热词里有人搜“jmeter 5.6.3生成测试报告”说明这个版本已经在大量使用相关的踩坑资料也齐全遇到问题好查。Jenkins这边选择更看重的是你已有的运行环境。最省事的方式是用官方提供的war包直接跑或者用docker部署。我团队里用的是Windows服务器上直接跑jenkins.war简单直接java -jar jenkins.war --httpPort8080如果机器资源紧张或者想快速体验docker方式更干净docker run -d --name jenkins -p 8080:8080 -p 50000:50000 -v jenkins_home:/var/jenkins_home jenkins/jenkins:lts注意这里必须挂载数据卷否则容器一删所有任务配置和构建历史全没了。这个坑我亲眼见过同事踩整个人是懵的。Jmeter的运行环境有一点必须提醒它依赖JDK版本要对得上。Jmeter 5.x要求JDK 8以上JDK 11或17都行。但Jenkins的新版本2.3xx之后对JDK的版本也有要求如果Jenkins和Jmeter跑在同一台机器的同一个用户下建议直接把JDK 11或17配成系统默认避免两个工具各自需要不同JDK版本导致来回切。JDK装好后配置JAVA_HOMEWindows和Linux都一样我就不展开了网上教程一大把。2.2 必要插件清单Jenkins装完先别急着建任务有些插件是必须的。我按用途列个清单插件名称用途说明Performance Plugin解析Jmeter的jtl结果文件直接在构建界面展示吞吐量、响应时间曲线HTML Publisher Plugin展示Jmeter生成的HTML报告构建后能在Jenkins页面点开详细报告Email Extension Plugin邮件通知失败时给指定人发邮件带报告附件或链接Build Timestamp Plugin给构建时间打标记生成带时间戳的测试报告目录名避免覆盖Timestamper构建日志显示时间排查问题时能看清每步执行耗时插件装好后记得重启Jenkins有些插件不重启不生效。另外国内网络环境装插件经常慢到怀疑人生别硬等可以在插件管理的高级页里换个镜像源这一步能省大量时间。Jmeter本身也有个Ant插件可以用来集成但我后来放弃了因为配置太绕。反而是直接用命令行跑Jmeter再用Shell或批处理处理结果效率和可控性都更高这也是社区里主流做法。后面第4部分我会给出完整的命令示例。3. Jmeter压测脚本的设计与编写3.1 脚本结构怎么搭脚本是整套系统里的“测试用例”建议直接放在代码仓库里管理跟项目代码一起走版本。我的标准目录结构是这样jmeter-scripts/ ├── jmx/ # 脚本文件 │ ├── login.jmx │ └── order_create.jmx ├── csv/ # 参数化数据 │ ├── users.csv │ └── skus.csv ├── lib/ # 额外jar包 └── README.md # 脚本说明脚本里的结构我习惯分三块HTTP请求默认值、线程组、监听器。HTTP请求默认值里配好协议、域名、端口和公共的请求头这样每个请求不用重复填这些信息改环境时也只需要改一处。线程组里定义并发数和循环次数。监听器按需配置最常用的是聚合报告和查看结果树但放在JMX里的话压测结束后会消耗资源所以一般只留必要的。接口压测脚本我一般会手动维护不建议用Jmeter的录制功能。录制功能容易录进大量静态资源请求图片、CSS、JS这些请求会干扰压测结果。接口压测要的是精确控制每个接口的权重和参数手写脚本反而更快。不过有个例外如果遇到非常复杂的登录流程、多个接口之间有复杂的依赖关系可以先录制再清理作为起点可以省不少抓包时间。3.2 参数化和关联是脚本的灵魂脚本写好后压测能不能真实模拟业务关键看参数化和关联做没做好。参数化的意思是让每次请求的数据都不一样最常用的方式是CSV数据文件。比如登录接口不能所有用户都用同一个账号否则并发一上去服务端就针对一个账号做缓存压出来的结果完全失真。配置方式很简单在“CSV数据文件设置”里指向你的数据文件设置变量名如username,password在请求里用${username}引用就行。注意设置“线程共享模式”为“当前线程组”否则多个线程可能读到同一行数据。关联解决的是接口之间的依赖最典型的就是登录后拿token。A接口登录返回的tokenB接口要用在Jmeter里通过“JSON提取器”或者“正则表达式提取器”把token取出来存成变量在登录请求下添加“后置处理器 → JSON提取器”设置变量名tokenJSONPath表达式填$.data.token按实际返回结构写后续请求的请求头里用${token}引用这个环节最容易踩的坑是提取顺序。JSON提取器作用域只对同级的后续请求生效如果你把B请求放到了和A请求并列的位置token变量就取不到。务必记住后置处理器的作用域是“同级的后续节点”不是全局。登录请求放在线程组第一层B接口请求放在登录请求的下级“逻辑控制器”里或者确保B请求在线程组中的执行顺序在登录请求之后。3.3 Beanshell断言怎么写热词里专门有“jmeter beanshell断言”说明问的人不少。断言的作用是判断接口返回是否符合预期但Jmeter自带的“响应断言”比较死板只能做文本匹配。遇到需要判断“返回的code是0且data里的订单号以某个前缀开头”这种复杂规则就得用Beanshell。这里要强调一点Beanshell在Jmeter里的运行效率不高如果压测并发特别高建议改用JSR223Groovy性能差距能到十倍以上。Beanshell适合断言这种低频操作不适合在请求体里做高频的复杂计算。我常用的一个Beanshell断言示例String response prev.getResponseDataAsString(); // 解析JSON这里简单用字符串判断 if (response.contains(\code\:0)) { // 把业务状态码取出来 String[] parts response.split(\code\:); String codeStr parts[1].substring(0, parts[1].indexOf(,)); if (codeStr.trim().equals(0)) { prev.setSuccessful(true); Failure false; } else { prev.setSuccessful(false); Failure true; String msg 业务code错误: codeStr; FailureMessage msg; log.info(msg); } } else { prev.setSuccessful(false); Failure true; FailureMessage 响应中未找到code字段; }注意在脚本里用log.info()输出日志方便在查看结果树里排查。prev对象是“上一采样结果”的引用这是Beanshell断言的基础所有断言都要围绕它操作。3.4 压测参数怎么定压测参数不是拍脑袋定的我是按下面这套思路来的先确认业务目标这个接口线上峰值QPS大概多少需要支撑多少并发用户如果不知道就去翻线上监控。没有监控的问运维要nginx访问日志的统计或者自己写脚本数一下。压测环境要跟生产对齐如果只是拿测试环境压数据量差很多结果只能做相对参考不能当绝对值。所以接口压力测试的结论一定要标注环境避免后续被当成生产数据误读。从低到高逐步加压先50并发跑5分钟看响应时间拐点和错误率再往100、200、500爬找到系统的性能拐点。这个过程需要反复试不是一次就能跑出结果。压测时长不要低于5分钟我见过很多只压30秒的数据完全没参考价值。线程启动阶段和运行稳定阶段的数据差异很大压5分钟以上才能拿到稳定期的数据。脚本调试的小技巧正式纳入Jenkins之前脚本一定要先在本地跑通。我的调试顺序是单线程跑一次开“查看结果树”确认响应内容符合预期断言没报错把线程数调到10循环次数改成2看聚合报告的吞吐量和错误率确认脚本本身没有逻辑问题用命令行跑一遍确认命令行模式下结果文件能正常生成命令行跑的命令要记住Jenkins里用的就是它jmeter -n -t login.jmx -l result.jtl -e -o report_html-n是非GUI模式-t指定脚本-l输出原始结果文件jtl格式-e生成HTML报告-o指定报告输出目录。最后两个参数配套用生成的HTML报告可以直接在浏览器里打开也可以挂到Jenkins上展示。4. Jenkins持续集成链路搭建4.1 创建自由风格任务Jenkins任务的类型强烈建议选自由风格项目。流水线Pipeline功能确实更强大但如果你是第一次搭这套链路自由风格把每一步都图形化展示出来排查问题更直观。流水线的Groovy脚本一旦写错报错信息对新手极不友好。等链路跑通、理解了整个流程之后再迁移到流水线不迟。任务创建步骤如下新建任务 → 自由风格项目填好名字“General”里勾选“丢弃旧的构建”保留最近10次构建或30天防止磁盘被构建记录塞满“源码管理”里选Git填脚本仓库地址分支填main“构建触发器”里根据需求选定时构建或轮询“构建环境”里勾选“Add timestamps to the Console Output”“构建”步骤里添加“Execute Windows batch command”或“Execute shell”“构建后操作”里加Performance插件和HTML Publisher插件4.2 核心构建命令构建步骤是整个任务的灵魂Windows环境和Linux环境命令不同。Windows环境下我的批处理脚本是这样的echo off set WORKSPACE%WORKSPACE% set JMETER_HOMEC:\apache-jmeter-5.6.3 set SCRIPT_DIR%WORKSPACE%\jmeter-scripts\jmx set REPORT_BASE%WORKSPACE%\reports set CURRENT_TIME%date:~0,4%%date:~5,2%%date:~8,2%_%time:~0,2%%time:~3,2%%time:~6,2% set CURRENT_TIME%CURRENT_TIME: 0% echo 开始清理历史报告 if exist %REPORT_BASE% rd /s /q %REPORT_BASE% mkdir %REPORT_BASE% echo 开始执行压测 call %JMETER_HOME%\bin\jmeter.bat -n -t %SCRIPT_DIR%\login.jmx -l %REPORT_BASE%\result.jtl -e -o %REPORT_BASE%\html echo 压测执行完成 exit /b 0注意几点%date%和%time%的结果带有空格要去掉否则文件夹名会有空格导致路径解析出错。call关键字很重要不能直接执行jmeter.bat否则批处理会在Jmeter执行完后直接退出后面的命令都不执行。如果Jenkins和Jmeter在同一台机器上记得统一用户的环境变量我遇到过Jenkins服务用System账户跑找不到Jmeter路径的情况最后改成在批处理里显式指定JMETER_HOME才解决。Linux环境下对应的命令#!/bin/bash export JMETER_HOME/opt/apache-jmeter-5.6.3 SCRIPT_DIR${WORKSPACE}/jmeter-scripts/jmx REPORT_BASE${WORKSPACE}/reports CURRENT_TIME$(date %Y%m%d_%H%M%S) echo 开始清理历史报告 rm -rf ${REPORT_BASE} mkdir -p ${REPORT_BASE} echo 开始执行压测 ${JMETER_HOME}/bin/jmeter -n -t ${SCRIPT_DIR}/login.jmx -l ${REPORT_BASE}/result.jtl -e -o ${REPORT_BASE}/html echo 压测执行完成 exit 0如果你的压测脚本有好几个可以在批处理里循环执行也可以放在同一个线程组里串联执行我更推荐后者因为一个任务只有一个结果文件Performance插件解析起来也方便。4.3 报告展示与结果归档构建执行完接下来要让人“看得到”结果。Performance插件和HTML Publisher的配置要点如下Performance插件构建后操作里选择“Publish Performance Test Result Report”数据文件类型选“JMeter”填result.jtl的相对路径。它会解析出吞吐量和响应时间的变化趋势图每次构建生成一条曲线多次构建下来就能看到性能趋势。HTML Publisher构建后操作加“Publish HTML report”HTML目录填reports/html索引页填index.html。这里有个常见坑Jenkins默认开启CSRF保护HTML报告里的图片和CSS会加载不出来。解决方案是到“系统管理 → 脚本控制台”里跑一段命令放开目录限制或者更简单的办法是把报告放到Jenkins的userContent目录下。我实际用下来放开限制比较省事System.setProperty(hudson.model.DirectoryBrowserSupport.CSP, default-src *; style-src unsafe-inline; script-src unsafe-inline unsafe-eval; img-src * data:;)执行完重启Jenkins生效。这样HTML报告里的图表、样式都能正常显示。构建归档在“构建后操作”里加“Archive the artifacts”填reports/**把报告归档到构建记录里这样每次构建的产物都归档在构建历史中随时可以翻出一个月前的报告对比。4.4 参数化构建与定时触发压测常常需要临时调整并发量如果每次改并发都要去改JMX文件再提交代码效率太低。解决办法是参数化构建。在“General”里勾选“参数化构建过程”添加两个字符串参数比如THREADS默认值50表示并发线程数LOOPS默认值10表示循环次数然后在JMX文件里把线程数改成${__P(THREADS,50)}循环次数改成${__P(LOOPS,10)}。这样命令行执行时可以通过-JTHREADS100传参Jenkins构建时也能在界面上直接填值不用改脚本。命令行示例jmeter -n -t login.jmx -JTHREADS100 -JLOOPS10 -l result.jtl -e -o html触发方式我用两种一是定时构建每天凌晨2点跑一次二是上游任务触发部署任务成功后自动跑。定时构建的cron写法H 2 * * *每天的凌晨2点跑H代表哈希分散避免高峰期所有任务挤在一起。如果你想在代码有变更时触发可以配置Webhook让Git提交后自动触发压测这适合对接单测和Code Review流程。邮件通知这边Email Extension插件配好后可以在“可编辑邮件通知”里加默认收件人勾选“每次构建都发送”邮件里带上构建日志的超链接和Performance趋势图。我习惯只开“失败时发送”白天跑全量压测会影响线上业务都是挑凌晨跑第二天早上看邮件就行。4.5 构建节点与资源规划压测本身很吃资源如果Jenkins就在生产或测试服务器上压测时Jmeter开几百个线程会造成CPU飙升影响同机器上的其他服务。我建议有条件的话把Jmeter独立部署到一台专门的压测机上Jenkins通过SSH远程执行。这涉及SSH插件配置或者用“节点”功能我这里不展开但给出一个关键提示如果压测机和Jenkins不是同一台机器JMX里的脚本路径必须以压测机上的绝对路径为准Jenkins侧的工作区路径只在Jenkins所在机器上有效。很多新手配置SSH远程构建时脚本路径全部按Jenkins机器填结果压测机找不到文件报Could not open file这个错我专门在下一部分列出来。5. 常见问题与排查技巧实录5.1 高频问题速查表下面这些问题是我在实际落地过程中遇到的真实问题每一个都排查过直接整理成表格问题现象排查思路解决方案Jmeter报错Could not open file确认Jenkins的执行工作目录和脚本实际路径用绝对路径或在命令行里先cd到脚本目录压测结果全部是错误响应可能是线程数过大导致服务端拒绝连接先小并发验证脚本逻辑再逐步加压Jenkins构建显示成功但没生成报告检查构建日志里的Jmeter执行返回码确认-o目录没有残留旧文件构建前先清理报告目录BeanShell断言取不到变量值看变量作用域和提取器的执行顺序把提取器放到对应的HTTP请求下用Debug sampler验证变量HTML报告图片不显示Jenkins的CSP安全策略限制了静态资源用前面提到的Groovy脚本放开CSP限制性能插件提示无数据文件.jtl格式需要Performance插件能识别的列在Jmeter的user.properties里配置jmeter.save.saveservice.output_formatcsv任务构建历史过多撑满磁盘没有配置丢弃旧构建在“General”里勾选“丢弃旧的构建”设置保留天数Jmeter命令行压测时日志刷屏默认INFO日志太详细添加-q参数指定日志级别或重定向log文件5.2 关于接口幂等性的一点提醒压测过程中我遇到过一个很隐蔽的问题接口实现了幂等连续压了几轮数据没有异常但一旦加了并发就会出现重复数据。原因是幂等性只按请求体里的唯一键判断而压测脚本的CSV参数化如果配置了循环复用同一个请求参数会在多个线程里重复出现被服务端判定为重复请求而直接拒绝。这个现象有时候会被误判为“接口bug”其实是压测数据没构造好。处理办法很简单CSV数据文件的行数要大于并发数×循环次数或者把“循环读取”关掉让每个线程只用自己的数据。如果实在没有足够多的真实数据可以用Jmeter的__Random函数和__counter函数动态生成参数这样至少能保证每个请求的参数唯一。5.3 排查问题的通用方法遇到问题先别急着改代码我总结了一个通用排查顺序看构建日志Jenkins控制台输出里每一步都有时间戳先确认是脚本没跑到、还是脚本跑挂了。看Jmeter日志在构建命令里加-j参数指定日志路径Jmeter自己的日志更详细能定位到具体是断言失败还是网络异常。看原始结果用查看结果树在本地跑一遍同样的脚本对比响应内容。这个操作能快速区分“脚本问题”还是“环境问题”。看服务端日志如果脚本没问题去压测目标服务上看日志确认请求有没有到达服务端服务端处理有没有报错。这个顺序从“有没有跑”到“跑到哪了”到“服务端什么反应”基本能覆盖90%的问题场景。再补一个技巧Jmeter命令行模式下加-l参数生成的jtl文件用文本编辑器打开每一行是一个采样结果。如果某个请求返回了错误这一行里会有false标志和响应码。在几十万行结果里搜false比等聚合报告快得多排查问题时我经常这么做。另外提一句经常被忽略的细节压测脚本里的HTTP请求一定要显式设置连接超时和响应超时。不设置的话默认超时时间可能很长一个挂掉的接口会导致整个压测线程长时间卡住后续请求全部排队最终报告里的响应时间数据严重失真。我一般在“HTTP请求默认值”里把Connect Timeout设为5000msResponse Timeout设为10000ms这个配置在引入Jenkins自动跑之后尤为重要因为没人盯着看脚本不能因为单个请求卡住而拖垮整个压测。5.4 压测结果怎么分析才不踩坑报告看多了就会发现Jmeter聚合报告里有几个指标特别容易误导人。平均响应时间是个陷阱。假设100个请求里99个响应时间是50ms1个是5秒平均值就是99ms看起来还行但实际有1%的请求已经超时了。所以我分析结果时必看两个指标90%响应时间或95%、99% Line和错误率。90% Line才是“大多数用户的实际体验”Avg只是自我安慰。吞吐量要结合并发数看。吞吐量TPS翻了倍不一定代表性能变好可能只是并发翻倍了。真正要关注的是“在满足响应时间指标的前提下系统能承载的最大TPS”。如果响应时间已经超了指标TPS再高也没用。压测结果一定要记录环境信息。脚本参数、并发数、压测机配置、目标服务配置、数据量这些信息不全的结果就是一堆没有意义的数字。我每次压测完都会在报告目录下放一个environment.txt把环境信息写清楚这个习惯让我后来对比历史数据时省了很多事。前面说了这么多最后把这条链路最简单的版本总结一下写好JMX脚本放进Git仓库Jenkins里建一个自由风格任务构建步骤里用一条命令跑Jmeter并生成HTML报告插件负责展示结果、发邮件。跑通了这一版后面再往里头加参数化构建、流水线、远程节点都是水到渠成的事。这套东西不神秘也不高大上但实实在在解决了“压测不可重复、结果不可追溯、执行靠人肉”这三个问题。我个人实操中的体会是工具链的价值不在于用了多新的版本、多高级的功能而在于把流程固定下来让团队每个人都能一键复现同一套压测。先跑通再优化这个顺序比什么都重要。
