k6 性能测试 Skill：从负载模型到性能阈值验证

6 分钟阅读 PolyForm Noncommercial 1.0.0

AI 测试Agent Skillsk6 性能测试

性能脚本如果只制造请求量，却没有代表真实用户节奏和业务比例，得到的数字很可能无法支持容量决定。k6 场景要先回答“谁在做什么、以多快的频率”。

k6 性能测试 Skill 围绕工作负载假设建模到达率、阈值和遥测，使压测结果能支撑工程决策。

本文通过具体场景说明如何收集、连接和解释证据，让结论能够服务下一步的工程或业务决定。

这篇文章只讨论 k6：它用 JavaScript 场景描述到达率、事务标签和阈值，适合把负载假设直接放进版本库。

先看源 Skill

k6 的主 Prompt 重点是到达率、场景比例、阈值和数据隔离。先确认这些输入，再决定脚本怎么写；没有业务节奏时，虚拟用户数没有解释力。

源目录现有 1 份示例、2 份参考、6 个脚本入口。可以先看 秒杀场景环境变量示例、框架使用说明、测试配置脚本。

相关 Skill

k6 负责把到达率、场景比例和阈值写进 JavaScript。以下 Skill 帮你补齐运行前后的判断：

Skill什么时候接上它补什么
性能负载建模需要把业务流量换成 arrival rate 和场景比例时明确开放模型、用户行为、峰值和数据假设
性能结果分析k6 summary、趋势和资源指标已经生成时解释 p95、错误率、标签维度与环境条件
性能回归分析需要比较基线与候选版本时固定负载和统计口径，判断差异是否可归因

从材料到可运行入口

这次任务是：用 k6 建模结账负载，设置延迟与错误率阈值，并关联服务端指标。

给 Skill 的输入可以很短，但不能含糊。

业务链路：登录 → 创建订单 → 支付 → 查询结果
环境：staging
已有材料：接口定义、测试账号、CI 运行方式
交付：load/checkout.js，附本地命令和失败证据

Skill 应先确认版本、认证方式和数据清理策略，再生成文件。示例输出片段如下，它展示结构，不代表代码已经运行。

tool: k6
entry: load/checkout.js
checks: p95 延迟、错误率、吞吐量和资源曲线
run_evidence: pending

run_evidence 只在拿到 k6 summary、阈值结果和同窗口服务指标后更新。缺少其中任何一项，都不能说压测结论成立。

把示例补成项目骨架

代码片段只有放回目录和命令里才有用。下面这份骨架够小，适合先接通一条链路。

load/checkout.js
├── 场景与断言
├── 数据或 feeder
├── 环境配置
└── 失败证据输出到 artifacts/

本地或 CI 的第一条命令可以写成：

k6 run --summary-export=artifacts/summary.json load/checkout.js

通过 thresholds 写清门禁，用 tags 标记业务事务，方便把失败请求和服务指标对上。

怎么算接入完成

检查项最低要求不满足时怎么处理
可重复执行连续运行不依赖上一次残留数据重做数据创建与清理
失败可定位负载模型、阈值结果、服务端资源曲线、错误样本 能回到同一次运行给产物加 run ID 和构建号
CI 可判定进程退出码与质量门禁一致修正 reporter 或 threshold 配置
维护成本定位、认证或公共请求只有一个修改点提取场景函数、阈值配置或数据生成器

先只接一条关键链路。它在本地和 CI 都稳定以后，再扩到异常、边界和并发场景。

一段可以直接改的调用词

把下面的方括号换成项目内容。材料越具体，Skill 越少猜。

请使用 performance-test-k6 Skill。

任务：用 k6 建模结账负载，设置延迟与错误率阈值，并关联服务端指标
版本与环境：[需求版本 / 构建号 / 环境]
输入材料：[文件路径或链接]
范围：[本次包含与排除的业务链路]
限制：[账号、数据、时间、合规要求]

先确认 k6 版本、场景类型、到达率、事务标签和阈值。生成 JavaScript 入口、`--summary-export` 命令与指标对齐清单；脚本未运行时，把结果标成待验证。
最后列出待确认问题，不要补写材料里没有的事实。

第一次调用先看结构和缺口。补齐材料后再生成正式产物，能省掉不少来回修改。

k6 要把用户节奏写成到达率，而不是只堆虚拟用户

k6 的场景先定义到达率、持续时间和业务比例。结账每分钟 600 次，并不等于 10 个 VU 循环 60 次；前者描述外部压力，后者会被响应时间反向影响。把登录、浏览、结账拆成带 tag 的事务，阈值直接绑定 p95、错误率和关键业务检查。

脚本输出只在同一时间窗口内才有意义。将 summary、服务端 CPU、数据库连接数和错误样本写进同一个 run ID；当阈值失败时，先看是哪一个 tag 触发，再决定是容量问题、数据问题还是脚本问题。

这类工具最容易踩的坑

  1. 把 VU 数当作生产流量，忽略到达率会随响应时间变化。
  2. 只看全局 p95，不给事务加 tag，慢请求无法定位到业务路径。
  3. 阈值失败后立刻调大资源，没有先排除脚本、数据和依赖波动。
  4. 保存 summary 却不保存时间窗口和构建号，后续无法对比基线。

交付前复核：把判断落到证据

Skill 输出拿到手后，先核对四件事：输入版本是否明确，范围是否完整，每条结论能否回到证据，下一步由谁执行。少一项，报告就容易变成漂亮的猜测。

项目需要留下缺失时
输入边界版本、环境、时间窗口和本次范围标记假设，不写成事实
证据索引日志、报告、Trace、截图或命令输出标记 evidence_pending
结论状态verified、assumption、blocked 或 pending停止扩大结论
后续动作最小验证命令、负责人和截止时间交付为待办，不进入门禁
source_version: [版本或提交]
scope: [本次包含和排除的对象]
evidence: [日志、报告、Trace 或命令输出]
status: pending
owner: [负责人]
next_action: [最小验证动作]

分析类 Skill 要保留查询条件和时间窗口；执行类 Skill 要保留命令、退出码和失败产物。人工修改也要记录，下一次复核才知道结论从哪里变化。

安装与调用

安装单个 Skill 就够了。项目总览里的安装说明不再在每篇重复。

npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/performance-test-k6 -g

调用时直接写“请使用 performance-test-k6 Skill”，然后附上真实材料。

常见问题

k6 性能测试 会直接给我一个能跑的项目吗？

有完整定义、版本、目录和依赖时，它可以生成很接近可运行的入口。最终仍要在你的仓库里安装依赖、执行命令并修正环境差异。

什么时候应该停下来补信息？

认证方式、测试数据或目标版本缺失时先停。继续生成只会得到一份看起来完整的猜测。

代码生成后先检查哪一处？

先看入口命令能否发现并运行目标文件，再看失败产物是否写到约定目录。连入口都没接通时，先别扩用例。

可以直接放进发布门禁吗？

等本地和 CI 使用同一命令、数据可重置、失败证据可追踪以后再放。

先拿一份真实材料跑 k6 性能测试，保留输入、输出和复核意见。文章里的片段只能帮你搭起结构，项目证据还得在项目里产生。

参考

安全测试白盒测试背靠背测试本地化测试边界测试
分享