靠 AI 生成性能测试脚本最近成了不少团队的捷径输入接口文档几分钟拿到一段 JMeter 脚本表面效率提升好几倍。但真正跑过大并发压测的人都知道AI 把线程数拉满很容易让输出结果能回答“系统瓶颈在哪里”很难。这里想聊的不是怎么让 AI 写脚本而是用 Skill 驱动的方式把性能测试全链路经验固化下来让 AI 在受控约束下完成需求澄清、场景设计、脚本生成、结果分析和瓶颈定位。这套思路适合正在做性能测试、又希望引入 AI 辅助的测试开发、后端开发和平台工程团队落地。1. 先想清楚AI 做性能测试为什么容易跑偏1.1 表面问题是脚本生成深层次问题是需求理解让 AI 生成 JMeter 脚本现在基本没有门槛。你把接口地址、请求参数、Header 丢给大模型它能在几秒内返回一个可打开的.jmx。问题在于这段脚本通常长这样线程数默认 1000循环次数默认 100断言只检查 HTTP 200数据完全没有参数化。这种脚本能跑但跑出来的数据没有参考价值。性能测试不是把请求打出去而是要验证“系统在某个业务模型下能不能稳定达到目标容量”。如果你问 AI 要的是“订单查询接口压测脚本”它默认理解成“帮我造一堆请求发过去”这其实只是做了一次冒烟压测离全链路性能测试还很远。真正的需求理解至少包括压测目标是什么是验证 2000 QPS还是验证 500 万日活用户的峰值容量。接口背后的业务成功标准是什么是返回 HTTP 200还是业务码为 0。压测数据该怎么组织是真实用户纬度还是单账号反复请求。结果如何解读TPS 没到目标时瓶颈在网关、应用、数据库还是网络。这些上下文不确认AI 生成的脚本再规范也只是在错误方向上做得更精细。1.2 没有经验约束的脚本压出来的结果不具参考价值性能测试完整链路可以从左到右拆成几个环节业务模型 - 场景模型 - 脚本模型 - 压测执行 - 监控采集 - 结果分析 - 瓶颈定位脚本模型只是中间产物它由场景模型推导而来场景模型又由业务模型决定。业务模型问的是“用户真实会怎么用这个系统”场景模型回答“要模拟多少并发、持续多久、用什么参数分布”。如果前面两步没有梳理直接在脚本层让 AI 自由发挥后面所有结论都不可信。举一个最常见的错误压测登录接口时AI 生成了 100 个线程但所有线程都使用同一个账号和密码。这样跑出来的 TPS 可能很高但这个结果没有任何生产参考价值。因为真实场景里 100 个用户不会共享一个账号数据库的行锁、鉴权服务的缓存、验证码校验都会被完全测错。再比如断言只检查 HTTP 200。网关层只要收到请求就会返回 200但业务层面可能因为参数非法返回了业务错误码。结果报告显示错误率为 0实际请求几乎没有一次是业务成功的。这类问题不是 AI 独有的但 AI 会把你给出的含糊指令包装成看起来非常完整的方案让人更容易跳过审查。1.3 Skill 的作用把专家经验变成可复用的 AI 操作手册所以核心不是“让 AI 别写脚本”而是给 AI 一套经验约束。这就是 Skill 驱动的基本思路。Skill 可以理解成一个结构化的技能包。相比普通 Prompt它包含更明确的文件结构、使用流程、强制约束、参考文档和可执行校验脚本。当 AI 被挂载了某个 Skill 时它的行为不再是一问一答而是按技能包定义的流程推进。做一个类比Prompt 像是你口头告诉新人“帮我测一下这个接口”Skill 更像是你给新人一本书里面写了第一步做什么、必须收集哪些输入、哪些配置禁止默认、输出结果要过长什么样、常见问题去哪里查。AI 的性能测试产出是否可靠很大程度取决于它遵循的是口头指令还是标准化操作手册。2. 把性能测试经验设计成 Skill 文件2.1 Skill 的典型文件结构目前主流 AI Agent、编程助手和平台都在做类似的能力扩展机制不同框架对 Skill 的命名和加载方式可能不同但核心结构基本一致。一个可复用的技能包通常包含三部分jmeter-fullchain-pressure-test/ ├── SKILL.md ├── references/ │ ├── baseline.md │ ├── scenario-constraints.md │ └── troubleshooting.md └── scripts/ ├── validate_jmx.py └── parse_aggregate.pySKILL.md是入口文件负责说明技能目标、使用流程和强制约束。AI Agent 通常会在匹配技能后优先读取这个文件。references目录放参考材料比如性能基线和错误排查手册。scripts目录放可执行脚本用于校验 JMX 结构、解析聚合报告等。不要把这个结构理解得太死板重点在于“说明、参考、工具”三层分离。没有说明AI 不知道该怎么启动流程没有参考AI 遇到异常只能靠模型记忆没有工具很多约束只能靠口头约束无法真正落地。2.2 一个面向 JMeter 压测的 Skill 设计针对 JMeter 全链路性能测试可以设计一个名为jmeter-fullchain-pressure-test的 Skill。它的定位不是“生成 JMeter 脚本”而是“在 JMeter 中完成从需求澄清到瓶颈定位的全链路工作”。SKILL.md可以写成这样--- name: jmeter-fullchain-pressure-test description: 在 JMeter 中完成需求澄清、场景设计、脚本生成、执行和结果分析的全链路性能测试。 --- # 使用流程 1. 需求澄清先收集压测目标、接口信息、数据约束和验收指标不要直接生成脚本。 2. 场景设计根据目标 QPS 和响应时间指标反推线程数、压测时长和用户数据量。 3. 脚本生成在场景模型确认后生成 JMeter 测试计划。 4. 脚本校验检查参数化、断言、线程配置是否满足强制约束。 5. 执行与监控使用 CLI 模式执行压测同时采集应用、数据库、中间件监控数据。 6. 结果分析输出 TPS、响应时间分布、错误率和瓶颈定位建议。 # 强制约束 - 必须先得到用户确认的压测目标未确认前禁止生成脚本。 - 必须对请求参数做参数化禁止多线程复用同一份凭证或业务数据。 - 断言必须包含业务成功语义禁止只检查 HTTP 200。 - 生成脚本时禁止硬编码 IP、端口和密钥统一使用变量。 - 禁止将生产环境真实数据传给外部 AI 服务。这里每一项约束背后都有真实踩坑经验。第一条约束解决“AI 上来就写脚本”的问题第二条约束解决参数化缺失第三条约束解决断言失真第四条约束解决脚本不可移植第五条约束是数据安全和合规底线。2.3 Skill 中的约束条件要怎么写大多数人写约束容易写成口号比如“请规范生成脚本”“请保证压测结果准确”。这类约束 AI 无法自我检查等于没有约束。写约束要遵循“可判定”原则。也就是说AI 或后续脚本能够明确判断这条约束是否被满足。推荐使用“必须、禁止、除非”三种表达- 必须: 先输出需求澄清清单等待用户确认后再开始场景设计 - 必须: 每个请求的 userId 来自 CSV 文件的独立数据行 - 禁止: 使用固定 token 作为所有线程的公共 Header - 禁止: 断言只检查 HTTP 状态码 - 除非: 用户明确告知该接口不需要鉴权否则必须先设计 token 获取或关联方案 - 禁止: 将真实用户手机号、身份证号等敏感信息写入脚本或报告可判定约束的好处是后续可以用脚本解析 JMX检查 CSV Data Set Config 是否存在、断言是否包含业务字段、线程数是否来自用户确认。这样 Skill 就不再只是文本建议而变成可执行的工程规范。3. Skill 驱动全链路实战从接口分析到瓶颈调优3.1 场景一需求澄清先确认基准指标用一个具体案例来演示。假设压测对象是电商平台的订单查询接口POST /api/v1/orders/query请求体包含userId、pageNum、pageSize、startTime、endTime。业务目标是支撑大促峰值 2000 QPSP95 响应时间小于 500ms错误率小于 0.1%。没有 Skill 的 AI拿到这段描述后大概率直接生成脚本。而在 Skill 约束下AI 的第一步是输出需求澄清清单澄清项默认值是否必须确认压测目标峰值 QPS、并发用户数必须响应时间目标P95、P99必须错误率上限0.1%必须接口协议和请求方式HTTP/HTTPS、POST必须业务成功标准业务码、返回字段必须测试数据来源CSV 文件字段、用户数量必须压测时长持续时长、预压时长建议执行窗口是否允许现网压测必须例如AI 可以输出这样的澄清询问在生成 JMeter 脚本之前需要确认以下信息 1. 压测目标 QPS 是 2000还是并发用户数 2000 2. 2000 QPS 是峰值瞬时值还是持续 15 分钟的平均值 3. 订单查询接口的成功判定是返回 code0还是需要校验订单列表非空 4. 测试数据准备了多少个 userId这些 userId 的 token 有效期是多少 5. 压测环境是否与生产环境隔离是否可以执行 15 分钟稳定压测这些问题是性能测试专家的基本功。Skill 的价值就是让 AI 在动手前先把这些信息补齐而不是把假设当事实写进脚本。3.2 场景二AI 生成符合规律的 JMeter 脚本当需求澄清完成假设用户确认目标如下目标 TPS2000平均响应时间预估100msP95 目标500ms持续时长15 分钟测试用户数1 万业务成功码code0AI 应该先做简单的并发估算而不是随便填线程数。计算公式可以这样理解单线程 TPS ≈ 1000 / 平均响应时间(ms) 假设平均响应时间为 100ms 单线程 TPS ≈ 1000 / 100 10 目标 TPS 2000需要的理论并发数 2000 / 10 200 考虑到启动重建连接、网络波动和错误重试通常再加 20%~50% 的冗余 推荐并发数 200 * 1.25 250这个估算不是精确容量计算但能避免线程数选择完全拍脑袋。AI 生成的 JMX 关键结构如下?xml version1.0 encodingUTF-8? jmeterTestPlan version1.2 properties5.0 jmeter5.6.3 hashTree TestPlan guiclassTestPlanGui testclassTestPlan testnameorder-query-performance-test elementProp nameTestPlan.user_defined_variables elementTypeArguments guiclassArgumentsPanel testclassArguments testname用户定义变量 collectionProp nameArguments.arguments elementProp nameBASE_URL elementTypeArgument stringProp nameArgument.nameBASE_URL/stringProp stringProp nameArgument.valuehttps://gateway.example.com/stringProp /elementProp /collectionProp /elementProp /TestPlan hashTree ThreadGroup guiclassThreadGroupGui testclassThreadGroup testnameorder-query-scenario stringProp nameThreadGroup.num_threads250/stringProp stringProp nameThreadGroup.ramp_time60/stringProp stringProp nameThreadGroup.duration900/stringProp stringProp nameThreadGroup.schedulertrue/stringProp elementProp nameThreadGroup.main_controller elementTypeLoopController guiclassLoopControlPanel testclassLoopController testname循环控制器 boolProp nameLoopController.continue_foreverfalse/boolProp stringProp nameLoopController.loops1/stringProp /elementProp /ThreadGroup hashTree CSVDataSet guiclassTestBeanGUI testclassCSVDataSet testname测试用户数据 stringProp namefilename/data/perf/users.csv/stringProp stringProp namevariableNamesuserId,userToken/stringProp stringProp namedelimiter,/stringProp stringProp namequotedDatafalse/stringProp stringProp namerecycletrue/stringProp stringProp namestopThreadfalse/stringProp /CSVDataSet HTTPSamplerProxy guiclassHttpTestSampleGui testclassHTTPSamplerProxy testname查询订单 stringProp nameHTTPSampler.domain${BASE_URL}/stringProp stringProp nameHTTPSampler.path/api/v1/orders/query/stringProp stringProp nameHTTPSampler.methodPOST/stringProp stringProp nameHTTPSampler.postBodyRawtrue/stringProp elementProp nameHTTPsampler.Arguments elementTypeArguments collectionProp nameArguments.arguments elementProp namebody elementTypeArgument stringProp nameArgument.value{userId:${userId},pageNum:1,pageSize:10,startTime:2025-01-01 00:00:00,endTime:2025-01-01 23:59:59}/stringProp /elementProp /collectionProp /elementProp /HTTPSamplerProxy ResponseAssertion testname业务成功断言 collectionProp nameAssertion.test_strings stringProp nameAssertion.test_stringcode:0/stringProp /collectionProp stringProp nameAssertion.test_fieldAssertion.response_data/stringProp /ResponseAssertion /hashTree /hashTree /hashTree /jmeterTestPlan这一段 JSON 请求体生成时AI 必须把userId替换成${userId}把域名替换成${BASE_URL}。如果它把测试环境的 IP 写死脚本换到预发环境就没有任何复用价值。3.3 场景三参数化与断言不能交给 AI 自由发挥参数化是性能测试脚本里最容易出错、也最容易被 AI 忽略的一环。正确的参数化数据文件长这样10001,eyJhbGciOiJIUzI1NiJ9.xxxx.yyyy 10002,eyJhbGciOiJIUzI1NiJ9.xxxx.yyyy 10003,eyJhbGciOiJIUzI1NiJ9.xxxx.yyyyCSV 文件不包含表头列顺序与variableNames中的userId,userToken一一对应。1 万个 userId 就准备 1 万行独立 token。这里有三点需要重点说明第一token 不能是同一个。如果所有线程使用同一个 token压测的是鉴权服务的缓存热点不是真实业务能力。第二token 有效期要覆盖压测时长。如果 token 有效期是 30 分钟而压测时长是 15 分钟理论上够用但要预留启动预热和排队时长。更稳妥的做法是准备可刷新的 token在线程组里增加一个“获取 token”的 setUp Thread Group但这样脚本复杂度会明显上升。第三CSV 数据的recycle参数要结合实际设置。如果允许数据循环复用长时间压测时会出现同一账号反复请求如果禁止复用数据耗尽后线程会停止导致 TPS 断崖下跌。对于 15 分钟的稳定压测数据量建议覆盖目标请求量的 10% 到 20%并设置recycletrue同时明确这段数据会重复使用。断言问题同样典型。错误的断言是这样写的断言类型响应文本 匹配规则包含 测试字段HTTP 200这种断言只会验证网络层请求成功。如果系统返回的是{code:50010,message:userId is empty,data:null}HTTP 状态码可能仍然是 200断言也会通过。正确做法是断言业务成功码断言类型响应文本 匹配规则包含 测试字段code:0如果接口返回的是一个业务字段比如success: true就断言该字段。不要嫌断言麻烦错误率这个指标如果没有业务断言配合基本没有解释力。3.4 场景四结果分析与瓶颈定位压测跑完后AI 需要输出聚合报告解读而不是只贴一张截图。JMeter 聚合报告里常用指标如下指标含义压测中重点看什么Samples总请求数是否达到目标请求量级Average平均响应时间与 P95、P99 配合看整体趋势Min / Max最短/最长响应时间Max 较大说明存在尾部延迟Std.Dev响应时间标准差越大表示越不稳定Error%错误率必须与业务断言结合判断Throughput吞吐量即 TPS/RPS核心容量指标Received KB/sec接收速率帮助判断是否达到带宽瓶颈瓶颈定位按层排查是最稳妥的顺序先看压测机资源压测机 CPU 打满时TPS 上不去不是被测系统的瓶颈。再看被测应用CPU、内存、JVM GC、线程池活跃线程数。然后看数据库慢 SQL、连接池使用率、锁等待。最后看中间件和网络网关、Redis、MQ 消费积压、带宽。实际排查时常用命令示例如下# 查看 Java 进程线程与 CPU 占用 top -Hp pid # 查看 JVM GC 状态每 5 秒输出一次 jstat -gcutil pid 5000 # 查看数据库当前线程执行情况 SELECT * FROM information_schema.processlist WHERE command ! Sleep;AI 在这里的角色不是替代运维排查而是根据聚合报告、监控曲线和日志关键字把可疑方向收敛到一两个再让工程师去做最终判断。Skill 的 references 目录里可以在troubleshooting.md中沉淀这类排查路径让 AI 每次遇到相似现象时都能按同样的顺序检查。4. 运行与验证把 AI 生成的脚本真正跑起来4.1 本地学习环境快速跑通压测环境用 CLI 模式学习阶段打开 JMeter GUI加载 AI 生成的 JMX先确认“测试计划”“线程组”“HTTP 请求”“CSV 数据”“断言”五个节点都存在。如果文件路径是 AI 生成的先检查 CSV 路径是否存在这是本地跑通最容易卡住的地方。真正执行压测时不建议用 GUI。GUI 会占用 JMeter 所在机器的 CPU 和内存影响压测准确性。推荐使用 CLI 模式export JVM_ARGS-Xms2g -Xmx2g jmeter -n -t order-query.jmx -l results/order-query.jtl -e -o reports/order-query -j logs/jmeter.log命令参数含义如下参数作用-n非 GUI 模式运行-t指定测试计划文件-l输出采样结果文件-e测试结束后生成 HTML 报告-o指定 HTML 报告输出目录-j指定 JMeter 自身运行日志文件JVM_ARGS设置堆内存。JMeter 默认堆内存可能无法支撑大并发模式尤其是需要生成 HTML 报告时。但堆内存也不是越大越好压测机内存要结合线程数和结果数据量调整。4.2 用指标验证表确认压测是否达标为了不让压测结果只停留在“脚本能跑”建议每次都输出一张指标验证表。以上面的订单查询接口为例判断维度目标值实际采样结论TPS 2000实测值通过 / 不通过P95 响应时间 500ms实测值通过 / 不通过错误率 0.1%实测值通过 / 不通过压测机 CPU 80%压测机监控值通过 / 不通过后端应用 CPU 80%应用监控值通过 / 不通过数据库连接池未打满连接池监控值通过 / 不通过这张表的价值在于它强制把压测结论从“跑完了”变成“达标了”或“没达标”。如果目标 TPS 是 2000实际只有 1000AI 要做的不只是输出这个数字还要继续回答“是脚本设计问题还是系统容量问题。”4.3 常见压测问题与排查路径结合日常性能测试经历把最常遇到的几个问题整理成一张排查表问题现象常见原因检查方式处理建议大量 401/403token 缺失、过期或没有关联查看响应体检查 CSV 中的 token 是否有效使用覆盖压测时长的 token或增加登录关联逻辑TPS 上不去但响应时间很低并发线程数不够或压测机自身性能不足查看压测机 CPU、网络连接数增加线程数或改用分布式压测响应时间逐渐升高数据库连接池耗尽、GC 频繁、慢 SQL 增多jstat -gcutil连接池监控慢 SQL 日志调大连接池参数或优化 SQL检查缓存是否失效Error% 突然上升参数化数据耗尽、触发限流或后端报错检查 CSV 是否循环查看后端错误日志增加测试数据量确认限流阈值最大响应时间极大网络抖动、Full GC、冷启动结合监控时间轴定位区分是否为首次请求必要时设置预热阶段脚本报文件不存在CSV 路径错误或文件名大小写不一致打印采样结果或查看 JMeter 日志使用绝对路径并在执行前确认文件存在排查时注意一个顺序原则先查脚本本身再查环境资源最后查被测系统。实际案例里很多“系统性能不行”的判断最后查下来是压测机 CPU 打满或者 CSV 数据配错导致的。5. 生产落地Skill 驱动后的工程化边界5.1 技能包和压测产物要分开管理Skill 本身应该纳入版本管理比如放到 Git 仓库每次更新约束、模板、排查手册都记录变更。不要直接在线上环境下修改 Skill也不要让压测脚本回写 Skill 目录。一个可落地的项目结构如下perf-project/ ├── skill/ # 引用的 Skill 或子模块 ├── plans/ # 测试计划 jmx ├── data/ # 参数化数据 csv ├── reports/ # HTML 报告 ├── results/ # jtl 原始结果 └── README.md # 本项目压测说明Skill 放的是通用经验plans 和 data 放的是某个具体压测项目的输入和输出。两者分开的好处是同一个 Skill 可以复用到多个压测项目而各项目的数据不会污染技能包。5.2 与 CI/CD 集成前要过的检查清单把 AI 生成的脚本接入流水线之前不要直接让脚本自动执行。建议先完成这份检查清单[ ] 压测目标接口、路径、请求体已经与业务方确认。[ ] 测试环境与生产环境隔离压测不会影响真实用户流量。[ ] 参数化数据量充足并确认是否允许循环复用。[ ] 断言包含业务成功语义而不是只检查 HTTP 200。[ ] 目标指标TPS、P95、错误率已经写入项目 README。[ ] 监控系统已准备在压测开始前采集数据。[ ] 压测机资源有足够余量单机不足时已规划分布式压测。[ ] 结果报告和 jtl 文件会自动归档不会覆盖历史结果。[ ] 已经定义终止条件如错误率超过 5% 立即停止压测。这些条目不是形式化要求。任何一条缺失都可能让自动化压测变成“自动执行错误”。5.3 人工审查边界哪些环节必须人来兜底Skill 驱动并不等于 AI 完全接管性能测试。AI 适合做的是生成脚本、检查约束、整理报告、发现明显异常。真正需要工程师拍板的决策包括压测目标是否来自业务诉求而不是某个开发随口说的数字。测试数据是否遵守数据合规要求是否对手机号、身份证号等敏感信息做了脱敏。生产环境是否真的允许执行压测压测窗口是否会影响在线业务。调优建议是否需要改动代码结构而不是只调参数。如果团队基于 Spring AI 或类似的 Agent 框架搭建性能测试助手Skill 更合理的定位是“领域经验层”。AI Agent 负责把 Skill 转成可执行流程工程师负责最终验收。不要上来就追求无人值守先把人机协作的边界划清楚再逐步扩大自动化的范围。6. 结尾性能测试的价值在场景设计和结果解读AI 生成 JMeter 脚本的能力已经足够强但这个能力并没有解决性能测试真正的难点。难点在于把业务目标翻译成场景模型把场景模型固化成可执行的脚本约束再从压测结果倒推出系统瓶颈。Skill 驱动的全链路实战本质是把这些专家经验从个人脑中搬进可版本化、可复现、可审查的技能包。下一步建议分三个方向扩展第一把历史压测基线、常见错误案例、调优案例不断回填进 Skill 的 references 目录第二结合 Agent 框架让多个 Skill 协作比如容量评估 Skill、性能基线 Skill、瓶颈排查 Skill 组合使用第三新人要先把 JMeter 手工完整跑通一遍再依赖 Skill 和 AI先建立“哪一步是坑”的判断力再谈效率提升。先跑通一次最小闭环再谈自动化放在 AI 辅助时代同样成立。