优测后台测试任务管理

skill安装

1. 下载Skill，
2. 下载scripts文件https://docker-hub-1254257443.cos.ap-guangzhou.myqcloud.com/skill-cli/1.0.0/utest-task-generate-execute-skill-scripts.zip
3. 将scripts文件解压到skill文件下
4. AI工具加载skill

拼装后目录结构如下

utest-task-generate-execute-skill/
├── SKILL.md                                # 技能主文档 
├── references/                             # 参考资料目录 
│   ├── apitest-cli.md                      # API测试命令行参考 
│   ├── apitest-conversation-flow.md        # API测试对话流程 
│   ├── apitest-error-handling.md           # API测试错误处理 
│   ├── conversation-flow.md                # 对话流程参考 
│   ├── perftest-cli.md                     # 性能测试命令行参考 
│   └── perftest-config.md                  # 性能测试配置参考 
└── scripts/                                # 脚本目录 （文件解压位置）
    ├── utest-task-generate-execute-skill-files.txt    # 技能文件列表 
    ├── utest_darwin_amd64                  # macOS Intel架构二进制文件 
    ├── utest_darwin_arm64                  # macOS Apple Silicon架构二进制文件 
    ├── utest_linux_amd64                   # Linux x86_64架构二进制文件 
    ├── utest_windows_amd64.exe             # Windows x86_64架构可执行文件 
    ├── utest_skills_install.sh             # Linux/macOS安装脚本 
    └── utest_skills_install.ps1            # Windows PowerShell安装脚本 

你是什么

这是一个面向 UTest 任务编排 的 Skill。

它只做两类事情：

• perftest：压测任务的创建、修改、执行
• apitest：接口测试任务的创建、修改、查询、删除、执行、报告处理、同步提示

它不做的事情：

• 不改造 CLI 源码
• 不伪造当前 CLI 尚未提供的能力结果

统一原则：优先调用 skill 自带的 utest 可执行文件，而不是走 MCP 或伪实现。

核心执行总规则

1. 先热更新，再读任何 references/*.md。
2. 先判断子域：这是 perftest 还是 apitest。
3. 再判断动作：创建 / 修改 / 查询 / 删除 / 执行 / 同步。
4. 最后才读对应 references 并拼装 CLI。

无感知热更新（加载后第一步）

执行时机：加载本 Skill 后立即执行，且必须发生在读取任何 references/*.md 之前。

• Windows / PowerShell：
• $out = & powershell -ExecutionPolicy Bypass -File "\scripts\utest_skills_install.ps1" 2>&1; if ($LASTEXITCODE -ne 0) { $out | Out-String | Write-Host }
• Linux/macOS/Git-Bash：
• cd "" && chmod +x "scripts/utest_skills_install.sh" && out="$(/usr/bin/env bash "scripts/utest_skills_install.sh" 2>&1)"; code=$?; if [ $code -ne 0 ]; then printf '%s\n' "$out" | tail -n 80; fi; exit 0

失败处理：

• 更新成功：不向用户额外解释，直接继续。
• 更新失败：展示错误输出（至少最后 80 行），并仅提示一次：更新检查失败，将继续使用本地版本。

> 脚本会读取远端版本文件，并在本地写入 .utest-task-generate-execute-skill-version。

先做什么

每次接到用户请求，先按下面顺序执行：

1. 先执行热更新
2. 再判断子域：这是 perftest 还是 apitest
3. 再判断动作：创建 / 修改 / 查询 / 删除 / 执行 / 同步
4. 再读对应 references
5. 再拼命令并执行

不要一上来就拼 CLI。

子域识别规则

一眼判成 perftest 的关键词

遇到以下任意语义，优先进入 perftest：

• 压测
• 性能测试
• RPS
• 并发数
• 压测时长
• 压测源
• 链路追踪
• 压力配置
• 梯度增压
• 浪涌模式
• 摸高模式
• 默认配置 / 自定义配置

• perftest save
• plan uuid
• 压测任务
• 压测实时数据
• 实时报告
• 协议数据
• run-overview
• 压测 reportUuid

一眼判成 apitest 的关键词

遇到以下任意语义，优先进入 apitest：

• 接口测试任务
• 接口任务
• apitest
• task uuid
• 场景标签
• 任务列表
• 删除任务
• 执行接口测试任务

容易混淆但应优先判成 apitest 的表达

以下表达虽然口语化，但默认优先按 apitest 处理：

• "帮我建个接口任务"
• "把这些场景做成任务"
• "查一下任务列表"
• "把场景加到任务里"
• "把任务跑一下"
• "同步到已有任务"

前提是上下文没有明显压测信号。

无法直接判断时

如果用户只说"任务""执行一下""帮我建个任务"这类模糊表达，且上下文无法判断子域，只追问一次：

• "这次是 压测任务（perftest），还是 接口测试任务（apitest）？"

不要连续追问多个问题。

通用执行原则

可执行文件选择

始终从当前 skill 的 scripts/ 目录选择与操作系统匹配的二进制：

• Windows：scripts/utest_windows_amd64.exe
• macOS Intel：scripts/utest_darwin_amd64
• macOS Apple Silicon：scripts/utest_darwin_arm64
• Linux：scripts/utest_linux_amd64

命令执行位置

• 从 工作区根目录 发起命令
• 实际调用的是 skill scripts/ 目录下的二进制
• 这样可以保证认证配置和相对路径查找逻辑正常工作

平台是真实信息源

• 平台是唯一真实信息源
• 不要依赖本地缓存
• 所有查询和更新都以平台为准

先读哪些参考文件

在真正拼装命令前，按子域读取对应文档。

perftest 必读

• references/perftest-cli.md
• references/perftest-config.md
• references/conversation-flow.md

apitest 必读

• references/apitest-cli.md
• references/apitest-conversation-flow.md
• references/apitest-error-handling.md

perftest 规则

perftest 支持的用户动作

• 创建压测任务
• 修改压测任务
• 执行压测任务
• 查看并分析压测实时数据

perftest 创建 / 修改任务流程

按下面顺序处理：

1. 明确告诉用户：当前进入的是 压测任务 流程
2. 必须先问用户要选择哪一种压测模式，禁止直接生成默认配置。
3. 必须同步展示全部可选模式及其参数范围，展示方式参考 references/conversation-flow.md。
• 默认模式：用户数模式默认、RPS 模式默认（关闭手动调压）、RPS 模式默认（开启手动调压）
• 自定义模式：用户数模式自定义、RPS 模式自定义（关闭手动调压）、RPS 模式自定义（开启手动调压）
4. 如果用户还没有明确选择模式，不得生成 config.json，也不得直接代用户选默认模式。
5. 根据用户最终选择的模式收集字段：
• 默认模式：只补齐该默认模式对应的少量必填运行参数
• 自定义模式：按该模式逐项收集用户明确关心的参数
• 在确认完压测执行设置后，必须再询问是否需要压力配置，提供 4 个选项：不需要、梯度增压模式、浪涌模式、摸高模式
• 用户只选择压力配置模式时，使用默认模板；只有用户明确要求调整时，才继续询问压力配置参数细节
6. 根据 references/perftest-config.md 生成完整基础 config JSON，并将 pressure-config 作为保存压力测试任务的独立入参准备，禁止放入 config JSON

1. 优先保证以下字段正确：

• mode
• threads / qpsNum / initQpsNum / maxQpsNum
• qpsIndex
• pressureTime
• traceReport
• adjustPerf
• executionGroup
• executionGroupRatio

• validVar
• executorCount
• 默认机组必须使用 公共-广州三区（executionGroup=35）
• 只有用户明确要求 QQ 机组，或说明用例只能使用 QQ 机器时，才切换到 QQ广州1(公共)（executionGroup=39）
• validVar 与 executionGroupRatio 都是数组，可配置一个或多个压力源
• validVar 与 executionGroupRatio 本质上表示同一份压力源分配数据；应先组织一份包含 executionGroup / percent / count 的基础数组
• executionGroupRatio 直接写入这份基础数组；validVar 则在完全相同的数组顺序和相同的 executionGroup / percent / count 基础上，仅额外补 name
• count 表示分配到该压力源的执行机台数，不再固定为 1
• 所有压力源 count 的总和必须等于 executorCount；因此 validVar[].count 总和与 executionGroupRatio[].count 总和都必须等于 executorCount
• 单台执行机上限统一按 500 处理；userMode 按 threads 计算，qpsMode 必须先用最高 RPS × 系数换算 threads
• qpsMode 且 adjustPerf = "0"：threads = ceil(qpsNum * qpsIndex)
• qpsMode 且 adjustPerf = "1"：threads = ceil(maxQpsNum * qpsIndex)
• 统一使用：peakLoad = threads（userMode）或 max(targetMaxRps, threads)（qpsMode），再计算 executorCount = max(1, ceil(peakLoad / 500))
• 如果用户指定的 executorCount 或压力源 count 总和小于计算结果，必须按最小合法值修正并明确告知原因

1. 除 maxThreads 外，其余某些模式当前不关心的字段仍保留在 JSON 中

executorCount 计算补充规则

• userMode：主要看 threads，maxThreads 如无特殊要求可与 threads 保持一致
• qpsMode 且 adjustPerf = "0"：以 qpsNum 作为最大 RPS，并用 threads = ceil(qpsNum * qpsIndex) 换算并发数
• qpsMode 且 adjustPerf = "1"：以 maxQpsNum 作为最高 RPS，并用 threads = ceil(maxQpsNum * qpsIndex) 换算并发数
• 多压力源时，必须先生成一份压力源基础数组，再同时派生出 executionGroupRatio[] 和 validVar[]；两者数组顺序及 executionGroup / percent / count 必须完全一致，只有 validVar[] 额外带 name
• 当用户未显式给出 executorCount 时，必须自动计算；当用户给出但值偏小时，或各压力源 count 总和偏小时，必须自动修正后再落配置
• 只要峰值负载超过 500，或压力源分配机器总数不足，就不得继续保留过小的 executorCount

压力配置补充规则

• 保存压测任务时，pressure-config 是独立入参，必须与基础 config JSON 分开传递，禁止写进 config JSON。
• 用户不需要压力配置时，独立入参写 "pressure-config": {}，基础 config.isGradient 保持 false。

• 用户选择梯度增压模式时，基础 config.isGradient 必须置为 true，并使用默认模板写入 pressure_mode = 1。
• 用户选择浪涌模式时，基础 config.isGradient 必须置为 true，并使用默认模板写入 pressure_mode = 2。
• 用户选择摸高模式时，基础 config.isGradient 必须置为 true，并使用默认模板写入 pressure_mode = 3。
• 只有用户主动要求调整压力配置参数时，才继续收集 stressTime、initPercent、rampUpPercent、troughs_percent、troughs_time、peak_percent、peak_time、cycle_count、time_climb_peak、time_climb_troughs、ramp_time 等字段。

1. Windows 下若 JSON 很长，优先写入临时 config.json 并使用 --config-file
2. Windows 下 perftest save 如需传 --pressure-config，必须通过 cmd /d /s /c 包裹 CLI 调用，并将压力配置 JSON 写成 "{\"stressTime\":60,...}" 形式；不要在 PowerShell 中使用 $pc = '{""stressTime"":...}'，也不要直接使用 --pressure-config '{"stressTime":...}'

1. 用户提供 taskUuid 时按修改处理，否则按创建处理
2. 若同时给出 envId 与 env-file，按 CLI 实际优先级使用 envId

perftest 执行任务流程

1. 先判断用户是否提供用例 JSON 路径
2. 提供了 JSON 路径则优先使用 --file
3. 如果没有 JSON 路径但提供了 pressureTaskUuid，使用 --uuid
4. 两者都没有时，只追问一次：用户掌握的是"文件路径"还是"任务 UUID"
5. 执行后关注输出中的：
• taskUuid
• reportUuid
• reportUrl
• 压测准备进度与完成状态

perftest 实时数据分析流程

当用户要查看压测实时数据、实时报告、协议数据、报告概览，或要求分析正在运行中的压测结果时，使用 run-overview：

<utest-bin> perftest run-overview --report-uuid <压测报告UUID>

处理规则：

1. 必须提供 reportUuid / 压测报告 UUID；如果当前上下文已有刚执行返回的 reportUuid，可直接使用。
2. 如果没有 reportUuid，只追问一次："请提供压测报告 UUID（reportUuid），我会拉取实时数据并分析协议维度表现。"
3. 命令输出是压测任务的实时数据来源；不要伪造平台没有返回的指标。
4. 如果输出中包含 JSON 或结构化协议数据，先解析再分析；如果是文本输出，提取其中可识别的协议、接口、RPS、成功率、错误率、耗时、状态码、错误信息等指标。
5. 回复用户时不要只粘贴原始输出，必须给出分析结论：
• 当前压测状态与整体趋势
• 协议 / 接口维度的请求量、RPS、成功率、错误率、延迟表现
• 明显异常，例如错误率升高、耗时突增、某协议无数据、状态码异常
• 可执行建议，例如继续观察、降低/提高压力、检查异常接口、查看错误日志
6. 如果实时数据为空，说明可能是报告 UUID 不正确、压测尚未产出实时数据、任务已结束或平台暂无协议数据，并保留 reportUuid 方便用户继续排查。

perftest 硬性规则

• 不要同时传 --config 和 --config-file
• 不要缺少 --plan-uuid
• 不要缺少 --name
• 不要同时传 --file 和 --uuid
• run-overview 必须使用 --report-uuid，不要误用压力任务 UUID、场景 UUID 或接口测试报告 UUID
• 不要把 apitest 参数混入压测命令

apitest 规则

apitest 支持的用户动作

• 创建接口测试任务
• 查询接口测试任务列表
• 查看任务详情
• 修改任务（环境、名称、自动更新场景、数据驱动）
• 执行任务
• 删除任务

apitest 处理边界

负责：任务创建 / 查询 / 修改 / 删除 / 执行

不负责：生成新场景 / 单独查询执行结果 / 单独查询报告

apitest 删除任务必须提供任务标识

硬性规则：用户请求删除任务时，必须由用户提供以下至少一项：

• 任务 ID（--task-id）
• 任务名称（--name）

禁止行为：

• 禁止在用户未提供任务标识时主动查询任务列表并代为选择任务删除
• 禁止根据模糊描述（如"删掉一个任务""随便删一个"）自行挑选目标任务

缺少标识时的处理：只追问一次，要求用户提供任务 ID 或任务名称，示例：

> 删除任务需要指定目标任务，请提供任务 ID 或任务名称。

apitest CLI 命令总览

apitest 动作识别关键词

apitest 必读参考文件

做任何 apitest 操作前，必须先读取以下文件：

• references/apitest-cli.md — CLI 命令参数手册
• references/apitest-conversation-flow.md — 创建/修改任务完整流程、场景筛选路径决策、分组编排规则
• references/apitest-error-handling.md — 交互模板、歧义处理、错误处理

apitest 版本能力边界

update 不支持：添加/删除场景

run 不支持（Skill 层不透出）：--path（文件路径执行）、--execution-group-id（执行机）

推荐输出方式

执行前

在真正执行前，用一句短摘要告诉用户：

• 当前子域：perftest / apitest
• 当前动作：创建 / 修改 / 查询 / 删除 / 执行 / 查看压测实时数据
• 关键输入：planUuid / task uuid / scenario uuid / jsonPath / reportUuid
• 接下来会调用哪个 CLI 命令

执行后

执行后只总结关键结果：

• 是否成功调用 CLI
• 是否成功保存、发起任务或获取压测实时数据
• reportUuid / reportUrl 是否可用
• 如果是 run-overview，必须总结实时协议数据、异常点和建议动作
• 是否存在需要用户继续确认的下一步

全局禁止事项

• 不改造 CLI 源码
• 不混用 perftest 与 apitest 参数
• 不在能力边界之外编造平台返回
• 不在子域不明时连续追问多个问题
• 环境名称需要处理歧义选择（匹配多个时让用户选择后使用环境 ID 提交）