效能平台之AI自动化性能测试

AI 性能接入效能平台：从生成脚本到 Jenkins 执行回写，一套完整闭环实战

> 这篇不是讲“AI 能不能写 JMeter 脚本”，而是讲一个更实际的问题：AI 生成的性能测试脚本，如何进入平台资产、如何被 Jenkins 执行、如何在前端看到结果。

很多团队做 AI 测试功能，第一步都会做“生成脚本”。

但真正落地时会发现，只生成脚本还不够。

因为性能测试要跑起来，至少需要这些环节：

```text产品 / 项目性能场景脚本资产脚本版本执行配置Jenkins Job执行记录控制台日志性能报告结果回写```

这次效能平台新增的能力，就是把这些环节串成一个闭环。

---

## 一、整体思路很简单

> AI 负责提效，平台负责资产和流程，Jenkins 负责执行，前端负责持续展示结果。

---

## 二、整体链路图

这条链路里面有两个重点：

1. **AI 生成的内容必须进入脚本资产和版本管理。**

2. **Jenkins 执行结果必须能被平台主动查询和展示。**

---

## 三、第一步：性能场景先选产品，再选项目

操作流程：

保存时，页面展示名称，后端仍保存 ID。

```json{ "productId": 1, "projectId": 10, "name": "测试采购待办查询接口", "code": "purchase_todo_query", "envCode": "st", "status": 1}```

这样既保证用户体验，也不破坏原有数据模型。

---

## 四、第二步：上传脚本，先把脚本变成平台资产

性能场景页面新增了一个独立入口：

```text性能测试 -> 性能场景 -> 上传脚本```

上传弹窗需要填写：

| 字段 | 说明 |

| --- | --- |

| 产品名称 | 优先选择 |

| 项目名称 | 根据产品联动 |

| 性能场景 | 根据项目联动 |

| 工具方式 | JMeter / k6 / Locust |

| 脚本名称 | 可手填，也可由文件名回填 |

| 脚本文件 | 本地脚本文件 |

上传流程：

上传接口提交的是 `FormData`：

```textscenarioId: 性能场景 IDname: 脚本名称toolType: jmeter / k6 / locustfile: 脚本文件```

文件保存路径类似：

```textresources/performance_scripts/{scenarioId}/{scriptId}/{version}/xxx.jmx```

这里的关键不是“能上传文件”，而是脚本从此变成了可追溯资产。

---

## 五、第三步：AI 不直接生成脚本，先生成压测方案

AI 生成入口在脚本资产弹窗里。

有两个动作：

```text生成方案人工确认后生成脚本```

为什么要分两步？

因为性能测试脚本不是普通文本。并发数、持续时间、升压策略、接口地址、断言、请求头，都会影响最终压测结果。

所以第一步先让 AI 输出方案。

示例输入：

```text我要测试采购待办查询接口，目标并发 300，逐步升压，关注平均响应时间、P95、吞吐量和错误率。```

推荐的方案结构：

```json{ "target": "验证采购待办查询接口在逐步升压到 300 并发时的性能表现", "toolType": "jmeter", "concurrentUsers": 300, "rampUpSeconds": 300, "durationSeconds": 600, "metrics": ["avg_rt", "p95", "throughput", "error_rate"], "risk": ["需要确认接口路径", "需要补充认证信息"]}```

AI 生成方案时序图：

这一步的收益是：

> 让测试人员先评审测试设计，再决定是否生成脚本。

---

## 六、第四步：人工确认后生成脚本，并做 JMeter 兜底

确认方案后，再点击：

```text人工确认后生成脚本```

后端会调用大模型生成脚本，并保存到脚本资产版本中。

当前支持：

| 工具 | 文件类型 |

| --- | --- |

| JMeter | `.jmx` |

| k6 | `.js` |

| Locust | `.py` |

生成脚本时序图：

### JMeter 为什么要兜底

实际测试中遇到过一个典型问题：

```textCannotResolveClassException:kg.apc.jmeter.threads.UltimateThreadGroup```

原因是 AI 生成了 JMeter 插件类，但本地 JMeter 没装对应插件。

所以后端做了两层保护。

第一层：Prompt 禁止插件类。

```text禁止 kg.apc.*禁止 UltimateThreadGroup禁止 SteppingThreadGroup禁止 ConcurrencyThreadGroup```

第二层：后端校验失败后生成原生 JMX。

原生组件包括：

```textTestPlanThreadGroupLoopControllerHTTPSamplerProxy```

兜底流程：

这一步解决的是“AI 生成了，但 JMeter 打不开”的问题。

---

## 七、第五步：Jenkins 创建 performance-runner Job

脚本生成后，还要能执行。

平台默认调用的 Jenkins Job 是：

```textperformance-runner```

Jenkins 地址：

```texthttp://xxxx/view/xxx/```

### Jenkins 创建步骤

### Job 参数清单

`performance-runner` 必须支持参数化构建。

核心参数：

```textRUN_IDPERFORMANCE_RUN_IDSCENARIO_IDSCRIPT_IDSCRIPT_VERSION_IDEXECUTION_CONFIG_IDTOOL_TYPEENV_CODETEST_MACHINE_IDVIRTUAL_USERSDURATION_SECONDSRAMP_UP_SECONDSCALLBACK_TOKENPLATFORM_BASE_URL```

### 第一版 Pipeline：先验证联通

先不要急着执行 JMeter，先确认平台能把 Job 拉起来。

```groovypipeline { agent any parameters { string(name: 'RUN_ID', defaultValue: '', description: '平台性能执行记录ID') string(name: 'PERFORMANCE_RUN_ID', defaultValue: '', description: '兼容字段') string(name: 'SCENARIO_ID', defaultValue: '', description: '性能场景ID') string(name: 'SCRIPT_ID', defaultValue: '', description: '脚本ID') string(name: 'SCRIPT_VERSION_ID', defaultValue: '', description: '脚本版本ID') string(name: 'EXECUTION_CONFIG_ID', defaultValue: '', description: '执行配置ID') string(name: 'TOOL_TYPE', defaultValue: 'jmeter', description: '工具类型') string(name: 'ENV_CODE', defaultValue: 'st', description: '环境编码') string(name: 'TEST_MACHINE_ID', defaultValue: '', description: '测试机ID') string(name: 'VIRTUAL_USERS', defaultValue: '10', description: '并发用户数') string(name: 'DURATION_SECONDS', defaultValue: '300', description: '持续时间') string(name: 'RAMP_UP_SECONDS', defaultValue: '30', description: '爬坡时间') string(name: 'CALLBACK_TOKEN', defaultValue: '', description: '回调Token') string(name: 'PLATFORM_BASE_URL', defaultValue: '', description: '平台后端地址') } stages { stage('检查平台参数') { steps { echo "RUN_ID=${params.RUN_ID}" echo "SCENARIO_ID=${params.SCENARIO_ID}" echo "SCRIPT_VERSION_ID=${params.SCRIPT_VERSION_ID}" echo "TOOL_TYPE=${params.TOOL_TYPE}" echo "VIRTUAL_USERS=${params.VIRTUAL_USERS}" echo "DURATION_SECONDS=${params.DURATION_SECONDS}" } } stage('模拟执行') { steps { echo 'Jenkins 已接收到平台参数，联通成功。' } } }}```

验收标准：

```text平台点击确认发起后，Jenkins 出现新构建。Console Output 能看到 RUN_ID、SCENARIO_ID、TOOL_TYPE、VIRTUAL_USERS。```

---

## 八、第六步：平台点击确认发起，调用 Jenkins 执行

在平台中进入：

```text性能测试 -> 发起压测```

流程是：

```text选择场景 -> 执行配置 -> 确认执行 -> 确认发起```

点击“确认发起”后，后端会：

平台传给 Jenkins 的参数包括：

```textRUN_IDSCENARIO_IDSCRIPT_IDSCRIPT_VERSION_IDTOOL_TYPEENV_CODEVIRTUAL_USERSDURATION_SECONDSRAMP_UP_SECONDSCALLBACK_TOKENPLATFORM_BASE_URL```

这一步打通的是：

```text平台 -> Jenkins```

---

## 九、第七步：前端轮询执行记录，通过 Jenkins API 同步状态

Jenkins Job 能跑起来后，下一步是结果展示。

如果只依赖 Jenkins 回调，可能会遇到：

```textJob 已执行，但平台还显示排队中Job 失败了，但前端没有变化用户需要手动刷新页面```

所以执行记录页增加了轮询。

前端逻辑：

```text每 5 秒请求一次执行记录列表```

后端逻辑：

```text列表接口返回前，先同步 Jenkins 状态```

同步链路：

Jenkins API 查询两个阶段。

### 1. 队列阶段

```text/queue/item/{queueId}/api/json```

用于判断排队任务是否已经进入构建，并拿到 build number。

### 2. 构建阶段

```text/job/{jobName}/{buildNumber}/api/json```

用于查询：

```textbuildingresulttimestampdurationurl```

状态映射：

| Jenkins 状态 | 平台状态 || --- | --- || queue 未进入 build | 排队中 || building=true | 执行中 || result=SUCCESS | 成功 || result=FAILURE | 失败 || result=ABORTED | 已取消 |

前端展示新增：

```textJenkins 构建链接Console 日志链接报告链接开始时间结束时间```

这一步打通的是：

```textJenkins -> 平台 -> 前端```

---

## 十、完整闭环时序图

## 结尾：AI 生成脚本只是起点，执行闭环才是落地

这次性能测试功能升级，真正打通的是一条完整链路：

```text场景管理-> 脚本上传 / AI 生成-> JMeter 原生兜底-> Jenkins 执行-> 前端轮询 Jenkins API-> 执行记录与报告展示```

AI 在这里不是一个孤立按钮。

它进入了性能测试平台的工程流程，生成的内容能保存、能执行、能追踪、能复用。

这才是 AI 测试能力从“演示效果”走向“真实落地”的关键。

下面看看效能平台实际使用效果：

这里根据产品与项目新建场景，然后点击脚本资产，选择工具，有jmeter，locust，k6，然后在通过自然语言方式，点击生成方案，会给你生成最优提示词的性能脚本json，然后点击人工确认后生成脚本。然后会生成对应的脚本，也可以自己进行上传

生成脚本后，发起压测

填写机器信息，机器采用jenkins的slave方式，配置对应的slave的地址，然后点击执行压测。

然后就是

确认发起会调用jenkins详细信息，构建job，然后轮询查询对应的，更新执行记录状态，展示对应报告

---

小提问：

你们团队现在的性能测试执行，是 Jenkins 独立跑，还是已经接入平台统一管理？

如果正在做类似改造，建议优先跑通这个最小闭环：

```textAI 生成脚本 -> Jenkins 执行 -> 前端轮询结果```

跑通这个闭环后，再继续扩展报告分析、阈值门禁和趋势看板。

开源地址：

https://github.com/qiaoxinjiu/effekt

注意：下载使用时，需要换成自己的模型配置和对应的数据库，redis账号配置