k6 性能测试完全指南：从第一条脚本到 CI 门禁的避坑教程

k6 性能测试完全指南从第一条脚本到 CI 门禁的避坑教程【免费下载链接】k6A modern load testing tool, using Go and JavaScript项目地址: https://gitcode.com/GitHub_Trending/k6/k6k6 性能测试把压测做成了代码脚本用 JavaScript 写直接进 Git在 CI 里和单元测试一样跑。读完这篇 k6 入门教程你能独立装好工具、写出带阶梯负载和阈值断言的脚本并把压测接进流水线。k6 是什么先回答三个问题是什么一句话定位——把写单元测试的体验搬到性能测试上的现代压测工具脚本本身就是测试用例。和传统工具差在哪JMeter 这类工具要么靠图形界面拼场景、要么维护独立工程文件review 和回归都麻烦k6 的脚本就是一个可 diff、可 review、可跑 CI 的 JS 文件天然测试即代码。适合谁用会写 JavaScript 的人——前端、后端、SRE、测试都行不需要会操作专门的 QA 工具对比 Python 系脚本工具k6 用 Go 引擎执行单台机器能撑住更多虚拟用户。5 分钟跑通第一条测试环境Linux / macOS / Windows 均可一个能跑命令行的终端就够。安装包管理器直接装brew install k6或对应发行版的官方包也可从 release 页取单个二进制文件装完k6 version验证。最小可用脚本存成first.jsimport http from k6/http; export const options { stages: [ { duration: 10s, target: 10 }, { duration: 5s, target: 10 }, { duration: 10s, target: 0 }, ], }; export default function () { http.get(https://httpbin.org/get); }k6 run first.js25 秒后终端会打出彩色汇总表格——恭喜你的第一条 k6 压力测试跑通了。核心能力拆解阶梯负载用 stages 控制压力曲线能力一句话让虚拟用户数VU随时间平滑爬坡而不是瞬间拉满。关键配置项options.stages每项是{ duration, target }例如 30 秒内升到 15 个 VU、保持 1 分钟、再 20 秒降回 0。适用场景识别不同负载水位下的表现避免对服务造成突然冲击。一个坑别把target写进default function里动态改——stages 在启动时就已定死想动态调载要用 ramping-vus 这类执行器。一次真实压测运行的终端效果阈值断言用 thresholds 给结果判生死能力一句话声明式写下什么算合格测试结束自动判定通过或失败。关键配置项options.thresholds如http_req_duration: [p(99) 800]、http_req_failed: [rate 0.01]。适用场景把 SLA如 P99 响应时间、错误率直接写进脚本作为验收标准。一个坑阈值挂掉时进程返回退出码 99但测试本身照样跑完——CI 里必须检查退出码否则绿灯假通过。响应校验用 check 区分请求挂了和逻辑错了能力一句话对每个响应做业务级断言而不只是看状态码。关键配置项check(res, { status 200: (r) r.status 200, body 含 token: ... })结果汇入checks指标也能进 thresholds。适用场景电商下单、登录、支付这类200 但返回内容不对就是 bug 的业务。一个坑check 失败默认只计数不中断需要错了立刻停时得配合abortOnFail选项默认行为和你以为的不一样。多协议HTTP、WebSocket、gRPC 一套脚本通吃能力一句话同一套 JS API 覆盖主流协议实时业务压测不用换工具。关键配置项k6/http、k6/ws、k6/grpc各自独立的模块导入按协议拆场景。适用场景直播间、在线课堂、聊天等 WebSocket 长连接业务的并发稳定性验证。一个坑gRPC 需要先生成 proto 的 JS 绑定文件第一次上手别跳过这步报错信息不会替你解释。实战一条完整的压测流程选一个你没在别处见过的场景——内容站大促开抢场景大促开抢前 1 小时首页 抢购接口承受峰值要求 200 并发下体验不崩。负载设计用 ramping-vus 执行器做三段式——5 分钟爬到 200 VU、保持 10 分钟、3 分钟降回 0用 setup / teardown 准备和清理测试账号与数据。阈值判定p(99) 800http_req_failed: rate 0.01双指标任一挂掉退出码 99。结果解读盯 P95 / P99 的拐点而非平均值把拐点时间和资源监控对齐拐点出现在哪条阶段之后扩容决策点就在哪。新手最容易踩的 3 个坑坑 1脚本里忘了 sleep。现象——QPS 高得离谱结果不可信。原因——VU 空转循环把流量放大到真实用户的好几倍。解决——每个 VU 迭代间加sleep(1)左右按真实用户节奏走。坑 2把跑完当通过。现象——终端显示测试完成业务却已超时。原因——只看输出表格没看退出码。解决——CI 里用退出码 99阈值失败作为红线判断。坑 3把 URL、Token 写死在脚本里。现象——换一套环境就全挂。原因——配置和业务逻辑混在一起。解决——用__ENV环境变量注入脚本只读变量。进阶接入 CI 与监控CIk6 run一条命令即可阈值失败退出码 99流水线自动红灯压测从此是每次发布的门禁而非季度动作。监控内置 OTel / Prometheus 输出指标导出到 Grafana 持续看曲线比每次盯着终端汇总强得多。把 k6 性能测试当成持续回归来做性能回归就会和代码回归一样自然。 仓库内examples/目录有大量官方示例脚本可直接拿来改release notes/里的版本说明也能帮你快速对齐新特性。【免费下载链接】k6A modern load testing tool, using Go and JavaScript项目地址: https://gitcode.com/GitHub_Trending/k6/k6创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考