k6 负载测试完整指南：从第一个脚本到多机分布式压测-编程实验室

k6 负载测试完整指南：从第一个脚本到多机分布式压测

【免费下载链接】k6A modern load testing tool, using Go and JavaScript项目地址: https://gitcode.com/GitHub_Trending/k6/k6

k6 是一款用 Go 和 JavaScript 编写的负载测试工具，适合需要在发版前把接口压测、下单全链路、前端交互验证真正跑起来的团队：测试脚本进代码仓库，CI 每次提交都压一遍，多机分段分担负载，指标直接灌进监控系统。

🎯 你正被哪类压测问题卡住

假设你手上有一个订单服务要上线：/api/checkout 这个接口能不能扛住 100 个并发用户、p99 延迟稳不稳在 2 秒内，现在没人敢打包票。更麻烦的是，登录、加购、支付这一整条链路串起来跑通了吗？前端页面的交互瓶颈到底在前端还是在后端接口？这三个问题对应三类不同的压测方式——划及格线、压完整业务流、模拟真实页面操作。下面按这个顺序，陪你把每种都跑起来。

为什么是 k6

一句话定位：k6 让你把压测脚本写成 JavaScript，而不是在图形界面里拖配置。和传统压测工具比，它有几个明显的不同：

脚本是代码：能进 Git 做版本管理和 code review，git diff能直接看出这次压测方案改了什么；
交付是二进制的：一个 Go 编译的可执行文件就能跑，k6 run的退出码可以直接告诉 CI 管道"这次压测过没过"；
协议面宽：HTTP/1.1、HTTP/2、WebSocket、gRPC 都有对应模块（internal/js/modules/k6/），浏览器交互还能驱动真实 Chromium 页面（examples/browser/）；
负载模型多：固定并发、阶梯爬坡、按到达速率压，都是内置执行器，不用自己算。

🚀 5 行代码跑通第一个测试

先把 k6 装好（从源码构建的话，仓库地址是 https://gitcode.com/GitHub_Trending/k6/k6），然后写一个最小脚本 first.js：

import http from 'k6/http'; export default function () { http.get('https://quickpizza.grafana.com'); }

执行：

k6 run first.js

这能验证什么：服务可用性。跑完看终端报告，重点盯四个数：checks的成功率（应为 100%）、http_req_duration的 p(95)/p(99)（别只看 avg，均值会把长尾平均掉）、请求总数是否和预期一致。如果默认报告缺了你想要的分位数，加--summary-trend-stats参数调整。看到结果了，再往下写更复杂的场景。

🧪 按你想验证的东西写脚本

给核心接口划一条及格线

把阈值写进options.thresholds，指标越线时k6 run直接以非零退出码结束——CI 就能靠它卡门禁。examples/thresholds.js 展示了更细的写法：

export const options = { thresholds: { http_req_duration: ['p(99)<2000'], // 99% 请求响应低于 2 秒 'http_req_duration{name:/api/checkout}': ['p(95)<800'], }, stages: [ { duration: '30s', target: 15 }, // 30s 从 0 爬到 15 个并发用户 { duration: '1m', target: 15 }, // 保持 1 分钟 { duration: '20s', target: 0 }, // 20s 收尾 ], };

这能验证什么：接口在爬坡和平台期能否守住 99% < 2s，且可以只对 /api/checkout 这一个接口单独划 95% < 800ms 的更严线。

压一整条业务流

把接口串成流程：登录拿 token，下单时带上 token。步骤之间用返回值传数据，每一步都用check断言：

import http from 'k6/http'; import { check } from 'k6'; export default function () { const login = http.post('https://test.k6.io/login_get', { username: 'admin', password: 'password' }); const token = JSON.parse(login.body).token; check(login, { 'login ok': (r) => r.status === 200 && token }); const order = http.post('https://test.k6.io/create_order', { product: '2' }, { headers: { Authorization: `Bearer ${token}` } }); check(order, { 'order created': (r) => r.status === 200 }); }

这能验证什么：登录→下单这条链路端到端能不能走通，以及哪一步先出问题。

模拟真实用户点页面

只测 API 测不出前端的问题。浏览器模块驱动真实 Chromium，能点按钮、填表单、等导航：

import { browser } from 'k6/browser'; import { check } from 'k6'; export default async function () { const page = await browser.newPage(); try { await page.goto('https://test.k6.io/', { waitUntil: 'networkidle' }); await page.locator('input[name="login"]').type('admin'); await Promise.all([ page.waitForNavigation(), page.getByRole('button', { name: 'Go!' }).click(), ]); await check(page.locator('h2'), { '欢迎标题出现': async (el) => (await el.textContent()) === 'Welcome, admin!', }); } finally { await page.close(); } }

这能验证什么：表单提交后页面是否真的跳转、登录后的状态（比如欢迎标题）有没有出现。注意浏览器模块仍属实验特性，需要用带 Chromium 的 k6 构建（如 grafana/k6 的 browser 镜像）才能运行；examples/browser/fillform.js 是一个含会话 cookie 断言的完整版本。

🌐 单机压不动时：把负载摊到多台机器

一台机器受 CPU、网卡和文件描述符限制，并发再往上堆，瓶颈会先出现在压测机自己身上。k6 的解法是 execution segment：把整个测试区间 0–1 切成若干不重叠的小段，每个实例只认领自己那一段，各自只初始化该跑的那部分 VU，同时开始、同时结束。只要所有段的并集覆盖 0–1，总负载和"一台大机器跑完整测试"的行为一致。4 台机器分担 1 个测试的写法：

k6 run --execution-segment=0:1/4 --execution-segment-sequence=0,1/4,1/2,3/4,1 test.js k6 run --execution-segment=1/4:1/2 --execution-segment-sequence=0,1/4,1/2,3/4,1 test.js # 第 3 台 1/2:3/4，第 4 台 3/4:1

跑起来之后绕开三个老问题：不再受单机硬件上限约束；测试可以完全留在内网，流量不必出到第三方云服务；负载来源天然分散，不同机房/区域的机器各跑一段，就能模拟更接近真实分布的用户来源。指标汇总、阈值判定这类"全局计算"要集中处理，docs/design/020-distributed-execution-and-test-suites.md 完整记录了分段执行的架构设计与已知缺口，建议动手前先读一遍。

📦 把压测变成团队的日常

散落在个人电脑上的脚本撑不起团队。推荐这样的目录组织：

tests/ ├── api/ # 接口压测脚本 ├── browser/ # 页面交互脚本 ├── common/ # 登录等公共函数 └── scenarios/ # 完整业务流场景

公共逻辑抽出来复用，examples/es6sample.js 演示了 ES module 的写法。CI 里用官方镜像跑，退出码直接卡管道：

performance-test: stage: test image: grafana/k6:latest script: - k6 run tests/api/checkout.js only: - main - /^release/

最后把结果接进监控，指标别让它留在终端里：

# 流式写入 InfluxDB，配 Grafana 实时看压测曲线 k6 run --out influxdb=http://influx:8086/k6 tests/api/checkout.js # 或用 OpenTelemetry 走 OTLP 通道 k6 run --out otlp=http://collector:4318 tests/api/checkout.js

对应的输出实现分别在 internal/output/influxdb/ 和 internal/output/opentelemetry/，接上之后，P95/P99、成功率这些曲线就和日常监控长在一个面板里了。