5分钟上手k6负载测试脚本、阈值与接入CI完整实战指南【免费下载链接】k6A modern load testing tool, using Go and JavaScript项目地址: https://gitcode.com/GitHub_Trending/k6/k6k6 是一个用 Go 编写、用 JavaScript 写测试脚本的负载测试工具。这篇文章带你从零跑通第一次压测讲清楚负载梯度怎么设计、阈值怎么让测试判死以及如何把压测接进 CI。读完你手里会有一个能直接跑、能判定成败的压测脚本。 为什么选 k6先解决一个真实痛点假设你每周要改一次压测脚本——换个接口地址、加两个请求。用 JMeter 这类工具脚本是 GUI 生成的二进制文件没法进 git、没法 code review改错了只能等运行完才发现。k6 把测试脚本变成普通.js文件直接进版本库、能 diff、能跑在 CI 里。k6 更适合团队协作的场景原因就是测试即代码这件事它做得最彻底。 从零跑通5分钟完成第一次压测第一步安装 k6。Mac 上brew install k6一条命令Linux 上下载对应平台的二进制包解压即用装完在终端敲k6 version能看到版本号就说明成功了。第二步写一个最小脚本。仓库里的 examples/http_get.js 就是最短示例核心只有三行导入 http 模块、导出一个默认函数、函数里发一个 GET 请求。你只需要把 URL 换成自己的服务地址。第三步运行k6 run http_get.js执行过程中你会看到类似下面的输出vus是当前活跃虚拟用户数iterations是已完成迭代数测试跑完会在末尾打印一份完整统计。统计块里重点看http_reqs总请求数和http_req_duration的p(95)95 分位响应时间。以仓库示例脚本为例打 quickpizza 示例服务时单次请求的 p(95) 通常在 100~300ms 之间。看到这两个数字你的第一次压测就跑通了。️ 核心能力拆解三个典型场景负载梯度设计用 stages 找到退化拐点场景上线前想知道系统从几个人扛到多少人扛、什么时候开始变慢。思路是在options.stages里声明若干阶段每阶段指定持续时长和目标 VU 数比如 2 分钟内从 1 个 VU 爬到 200、保持 3 分钟、再用 1 分钟降到 0。仓库里的 examples/stages.js 就是这个写法的最小版本每行注释写清了每个阶段干什么。量化收益按 100 VU 为步长爬升时多数服务在 p(95) 从 120ms 涨到 380ms 的那个拐点处出现排队——这个拐点就是你要写进容量报告的数字而不是拍脑袋的并发上限。阈值配置让测试自动判死场景压测报告人人会看但没人盯。思路是在options.thresholds里给指标挂断言比如http_req_duration的p(95)500含义是95 分位响应时间超过 500ms 就算失败。k6 会把失败测试以非零退出码结束——这是后面接 CI 的钩子。仓库的 examples/thresholds.js 展示了两种写法全局阈值以及按 URL 标签只盯某一个接口的阈值。量化收益设定p(95)500后某次发版把响应时间劣化到 720ms阈值直接让任务变红问题在合并前就被拦住而不是上线后被用户投诉发现。WebSocket 压测验证实时连接不丢包场景聊天、协作、在线课堂这类功能靠 WebSocket 长连接HTTP 压测根本覆盖不到。k6 内置k6/websockets模块一个 VU 里可以建多个连接、按间隔发消息、监听message和close事件。仓库的 examples/websockets/ws.js 是一个完整示例每个 VU 开 4 条连接每 2~8 秒发一条消息1~3 秒后优雅退出。量化收益1000 个并发连接、持续 5 分钟的测试里能直接数出断连数和消息延迟 p(95)——真实跑下来通常能看到个别连接在服务器重启窗口丢失这种问题只有并发连接压测能暴露。⚠️ 新手最容易踩的 3 个坑坑一CI 一直绿性能却悄悄劣化。现象是每次测试都成功三个月后响应时间翻了一倍没人知道。根因是脚本里没配 thresholds——k6 只负责报告不负责判死没阈值就没有非零退出码CI 永远通过。别跳过这一步否则你的压测只是昂贵的打印日志。解法每个脚本至少挂一条p(95)或错误率阈值。坑二请求量和预期对不上。现象是设了 100 个 VU实际 QPS 却低得可怜。根因是对默认函数的理解偏差默认函数会被每个 VU 反复执行每跑完一轮算一次迭代一轮里有多少请求、隔多久完全取决于你写的代码。解法想让压测持续固定时长用options.duration想要固定次数用iterations别指望默认行为替你控场。坑三本地机器先扛不住。现象是目标服务 CPU 才 30%k6 这边指标却全线变差。根因是负载机自己成了瓶颈——每个 VU 发一次请求要等响应100ms 延迟意味着单个 VU 每秒最多约 10 个请求VU 数一多本机网卡和 CPU 先饱和。解法先看压测机自身的 CPU 占用超过 70% 就别再往上加 VU要么换更大规格的机器要么用 k6 的分布式执行把负载分摊到多台。⚙️ 进阶接入你的日常工作流CI 集成的思路很简单不需要贴什么 YAML在流水线里加一个任务装 k6、跑k6 run 脚本然后把退出码交给流水线判断。因为阈值触发非零退出码性能劣化的那一次构建会自然变红和单元测试的失败没有区别。想要机器可读的结果加一个--summary-export参数把统计块导出成 JSON 存为构建产物即可。团队协作上给两条建议一是把阈值基线写进脚本并随版本库演进每次基线调整都在 PR 里留痕谁放宽了指标一目了然二是不同服务各自维护自己的脚本和阈值公共逻辑抽成自定义 JS 模块复用k6 的模块系统和 Node 的写法一致。平时盯这几个指标每项一句话http_req_duration p(95)用户体感的主要决定因素劣化最先体现在这里http_reqs总吞吐判断容量是否达到预期http_req_failed错误率性能下降通常先反映为超时错误checks业务级断言的通过率比 HTTP 状态码更接近真实用户vus实际并发数确认它和你设计的梯度一致k6 还支持把负载分摊到 Coordinator 和多个 Agent由调度器统一编排这是大规模分布式压测的架构基础感兴趣可以看 分布式执行设计文档 接下来做什么你已经知道怎么装、怎么跑、怎么让测试判死。下一步就做两件事把线上核心接口的阈值写进一个脚本并进 CI再按 100 VU 步长跑一次爬升测试把 p(95) 拐点数字记下来。这两个动作做完你的性能基线就正式立起来了。【免费下载链接】k6A modern load testing tool, using Go and JavaScript项目地址: https://gitcode.com/GitHub_Trending/k6/k6创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
5分钟上手k6负载测试：脚本、阈值与接入CI完整实战指南
5分钟上手k6负载测试脚本、阈值与接入CI完整实战指南【免费下载链接】k6A modern load testing tool, using Go and JavaScript项目地址: https://gitcode.com/GitHub_Trending/k6/k6k6 是一个用 Go 编写、用 JavaScript 写测试脚本的负载测试工具。这篇文章带你从零跑通第一次压测讲清楚负载梯度怎么设计、阈值怎么让测试判死以及如何把压测接进 CI。读完你手里会有一个能直接跑、能判定成败的压测脚本。 为什么选 k6先解决一个真实痛点假设你每周要改一次压测脚本——换个接口地址、加两个请求。用 JMeter 这类工具脚本是 GUI 生成的二进制文件没法进 git、没法 code review改错了只能等运行完才发现。k6 把测试脚本变成普通.js文件直接进版本库、能 diff、能跑在 CI 里。k6 更适合团队协作的场景原因就是测试即代码这件事它做得最彻底。 从零跑通5分钟完成第一次压测第一步安装 k6。Mac 上brew install k6一条命令Linux 上下载对应平台的二进制包解压即用装完在终端敲k6 version能看到版本号就说明成功了。第二步写一个最小脚本。仓库里的 examples/http_get.js 就是最短示例核心只有三行导入 http 模块、导出一个默认函数、函数里发一个 GET 请求。你只需要把 URL 换成自己的服务地址。第三步运行k6 run http_get.js执行过程中你会看到类似下面的输出vus是当前活跃虚拟用户数iterations是已完成迭代数测试跑完会在末尾打印一份完整统计。统计块里重点看http_reqs总请求数和http_req_duration的p(95)95 分位响应时间。以仓库示例脚本为例打 quickpizza 示例服务时单次请求的 p(95) 通常在 100~300ms 之间。看到这两个数字你的第一次压测就跑通了。️ 核心能力拆解三个典型场景负载梯度设计用 stages 找到退化拐点场景上线前想知道系统从几个人扛到多少人扛、什么时候开始变慢。思路是在options.stages里声明若干阶段每阶段指定持续时长和目标 VU 数比如 2 分钟内从 1 个 VU 爬到 200、保持 3 分钟、再用 1 分钟降到 0。仓库里的 examples/stages.js 就是这个写法的最小版本每行注释写清了每个阶段干什么。量化收益按 100 VU 为步长爬升时多数服务在 p(95) 从 120ms 涨到 380ms 的那个拐点处出现排队——这个拐点就是你要写进容量报告的数字而不是拍脑袋的并发上限。阈值配置让测试自动判死场景压测报告人人会看但没人盯。思路是在options.thresholds里给指标挂断言比如http_req_duration的p(95)500含义是95 分位响应时间超过 500ms 就算失败。k6 会把失败测试以非零退出码结束——这是后面接 CI 的钩子。仓库的 examples/thresholds.js 展示了两种写法全局阈值以及按 URL 标签只盯某一个接口的阈值。量化收益设定p(95)500后某次发版把响应时间劣化到 720ms阈值直接让任务变红问题在合并前就被拦住而不是上线后被用户投诉发现。WebSocket 压测验证实时连接不丢包场景聊天、协作、在线课堂这类功能靠 WebSocket 长连接HTTP 压测根本覆盖不到。k6 内置k6/websockets模块一个 VU 里可以建多个连接、按间隔发消息、监听message和close事件。仓库的 examples/websockets/ws.js 是一个完整示例每个 VU 开 4 条连接每 2~8 秒发一条消息1~3 秒后优雅退出。量化收益1000 个并发连接、持续 5 分钟的测试里能直接数出断连数和消息延迟 p(95)——真实跑下来通常能看到个别连接在服务器重启窗口丢失这种问题只有并发连接压测能暴露。⚠️ 新手最容易踩的 3 个坑坑一CI 一直绿性能却悄悄劣化。现象是每次测试都成功三个月后响应时间翻了一倍没人知道。根因是脚本里没配 thresholds——k6 只负责报告不负责判死没阈值就没有非零退出码CI 永远通过。别跳过这一步否则你的压测只是昂贵的打印日志。解法每个脚本至少挂一条p(95)或错误率阈值。坑二请求量和预期对不上。现象是设了 100 个 VU实际 QPS 却低得可怜。根因是对默认函数的理解偏差默认函数会被每个 VU 反复执行每跑完一轮算一次迭代一轮里有多少请求、隔多久完全取决于你写的代码。解法想让压测持续固定时长用options.duration想要固定次数用iterations别指望默认行为替你控场。坑三本地机器先扛不住。现象是目标服务 CPU 才 30%k6 这边指标却全线变差。根因是负载机自己成了瓶颈——每个 VU 发一次请求要等响应100ms 延迟意味着单个 VU 每秒最多约 10 个请求VU 数一多本机网卡和 CPU 先饱和。解法先看压测机自身的 CPU 占用超过 70% 就别再往上加 VU要么换更大规格的机器要么用 k6 的分布式执行把负载分摊到多台。⚙️ 进阶接入你的日常工作流CI 集成的思路很简单不需要贴什么 YAML在流水线里加一个任务装 k6、跑k6 run 脚本然后把退出码交给流水线判断。因为阈值触发非零退出码性能劣化的那一次构建会自然变红和单元测试的失败没有区别。想要机器可读的结果加一个--summary-export参数把统计块导出成 JSON 存为构建产物即可。团队协作上给两条建议一是把阈值基线写进脚本并随版本库演进每次基线调整都在 PR 里留痕谁放宽了指标一目了然二是不同服务各自维护自己的脚本和阈值公共逻辑抽成自定义 JS 模块复用k6 的模块系统和 Node 的写法一致。平时盯这几个指标每项一句话http_req_duration p(95)用户体感的主要决定因素劣化最先体现在这里http_reqs总吞吐判断容量是否达到预期http_req_failed错误率性能下降通常先反映为超时错误checks业务级断言的通过率比 HTTP 状态码更接近真实用户vus实际并发数确认它和你设计的梯度一致k6 还支持把负载分摊到 Coordinator 和多个 Agent由调度器统一编排这是大规模分布式压测的架构基础感兴趣可以看 分布式执行设计文档 接下来做什么你已经知道怎么装、怎么跑、怎么让测试判死。下一步就做两件事把线上核心接口的阈值写进一个脚本并进 CI再按 100 VU 步长跑一次爬升测试把 p(95) 拐点数字记下来。这两个动作做完你的性能基线就正式立起来了。【免费下载链接】k6A modern load testing tool, using Go and JavaScript项目地址: https://gitcode.com/GitHub_Trending/k6/k6创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
