k6 性能测试可视化完整指南如何把压测数字变成发布决策【免费下载链接】k6A modern load testing tool, using Go and JavaScript项目地址: https://gitcode.com/GitHub_Trending/k6/k6你有没有经历过这种时刻压测跑了半小时屏幕刷完滚走一大片数字最后只剩一行http_req_duration p(95): 487.2ms。然后老板问能不能发你盯着那个数字说不出能还是不能。问题不在测试本身而在于数据没被看见。k6 是一个用 Go 写内核、用 JavaScript 写脚本的现代负载测试工具它的性能测试可视化能力就是把这些数字变成你眼前能对比、能告警、能拍板的图表。这篇文章带你从零走到能指导发布决策。先跑起来装好 k6 并跑一次 30 秒的压测安装很简单。macOS 上用brew install k6Linux 上可以从官方 release 里直接拿二进制如果你愿意从源码构建克隆仓库后执行make build即可。装好后建一个script.js这就是一个能跑的最小脚本import http from k6/http; import { check, sleep } from k6; export const options { vus: 10, // 模拟 10 个并发虚拟用户 duration: 30s, }; export default function () { const res http.get(https://test-api.k6.io/); check(res, { 状态码是 200: (r) r.status 200 }); sleep(1); }这个脚本让 10 个虚拟用户持续 30 秒每秒请求一次接口并检查返回状态码是不是 200。然后执行k6 run script.js。测试过程中终端会滚动显示实时的 VU 数、请求速率和响应时间分布跑完后自动打印一份统计摘要。看到终端里滚动的实时曲线说明整个链路已经通了。接下来是重点怎么把这些数字读懂、展示出去。看懂数据内置指标和自定义指标分别看什么跑完的摘要里有一堆指标名先认这四个就够用了http_req_duration每个请求的响应时间摘要里给的是 avg、min、max 和 p(90)、p(95)、p(99) 这些百分位数p(95) 意思是95% 的请求都比这个值快。看性能先看它。http_reqs请求总量除以时长就是吞吐量。http_req_failed失败请求的占比超过 0 就要警惕。checks你脚本里check()断言的通过率。内置指标不需要声明k6 自动采集。但接口通了不等于业务对了——比如从下单到扣库存花了多久这种业务耗时得自己加。k6 提供四种自定义指标写在脚本里即可Trend记录耗时自动算百分位、Counter累计次数比如加购了多少次、Rate事件发生率比如支付失败占比、Gauge记录瞬时值比如队列长度。用new Trend(order_duration)创建再用orderDuration.add(res.timings.duration)上报摘要里就会多出order_duration一行。自定义指标会同时进入后面所有输出通道等于你业务视角的仪表针。展示结果从终端到 Grafana 的几条可视化路线同样一份数据k6 支持多种出口按投入从低到高排给你1. 终端摘要默认。零配置跑完就有。适合单人、单次测试缺点是历史数据不留存没法对比上周和这周。2. 摘要导出文件。加一个--summary-exportresults.json参数把摘要存成 JSON。配合 CI 每次构建都生成一份脚本比较两次结果就能做版本间对比。3. 内置 Web 仪表板。执行k6 run --out web-dashboard script.jsk6 会在本地起一个 Web 页面默认地址见 dashboard 模块测试期间在浏览器里看实时曲线。不用装任何东西适合想在本地盯着测试跑的场景。4. InfluxDB Grafana专业方案。执行k6 run --out influxdbhttp://localhost:8086/k6 script.js数据进时序数据库再在 Grafana 里打开仓库自带的 Grafana 仪表板模板请求速率、响应时间分位数、错误率一屏看全还能叠加历史趋势。适合团队长期做性能回归。5. JSON / CSV / OpenTelemetry 输出。--out jsonresults.json、--out csvresults.csv拿到逐条样本自己用 Python 或电子表格分析已有 Prometheus 监控体系的话可以用--out experimental-prometheus-rw直接灌进去OpenTelemetry 输出也已内置。怎么选个人调试用 1 和 3团队例行压测用 2要给别人看、要留历史用 4。更进一步阈值、性能基线与发布决策怎么做光看图还是人肉判断真正让结果能拍板的是阈值thresholds。在脚本的options里写thresholds: { http_req_duration: [p(95)500], http_req_failed: [rate0.01] }意思是p(95) 必须低于 500ms失败率必须低于 1%。写个具体例子可以参考 examples/thresholds.js它还演示了按 URL 标签只对某个接口设阈值。只要任何一条被突破k6 退出码就是 99——这是写进 CI 的关键流水线看到非零退出码直接判定本次性能不达标发不发版由机器说了算不靠感觉。有了阈值再往前一步就是基线第一次在稳定版本上跑出 p(95) 480ms就把它记为基线。之后每个版本压测和基线比而不是和目标值比——p(95) 从 480ms 涨到 560ms 虽然没破 1000ms 的绝对线但回归了 17%同样值得查。做法上--summary-export出的 JSON 里把关键字段p(95)、p(99)、req/s、failed rate抽出来存一行到表格或数据库版本对比就是一张两列的表。常见坑与优化清单别只看 avg。平均值会被大量快请求拉低掩盖尾部延迟。盯 p(95)/p(99)那才是慢用户体验到的数字。压测机别和业务同机。k6 本身要吃 CPU 和内存小 VU 数问题不大VU 上千时请单独准备执行机否则指标失真。先跑短基线再跑长测试。用 10 秒的冒烟跑确认脚本、输出通道都正常再放 10 分钟的正式跑省得发现配置错了浪费半小时。百分位数可自定义。摘要默认只显示部分分位加--summary-trend-statsavg,p(90),p(95),p(99),max可以按你的关注点定制避免被默认值带偏。写在最后走到这里你已经有了完整闭环k6 采集数据阈值给出机器可判的成败标准终端、JSON 或 Grafana 把结果摆到眼前退出码接入 CI 让发布决策有据可依。性能测试的价值不在跑完那一刻而在每次对比里发现的差异。挑一个你最关心的接口按上面的步骤跑一个 30 秒的测试看看你的 p(95) 现在是多少——那就是你的第一条基线。【免费下载链接】k6A modern load testing tool, using Go and JavaScript项目地址: https://gitcode.com/GitHub_Trending/k6/k6创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考