5 个高频问题带你写出第一版 k6 负载测试脚本【免费下载链接】k6A modern load testing tool, using Go and JavaScript项目地址: https://gitcode.com/GitHub_Trending/k6/k6k6 是一款用 Go 和 JavaScript 编写的现代化负载测试工具load testing tool。这篇实操指南按新手最常卡住的 5 个问题组织内容从第一版能跑通的脚本到场景配置、阈值判定、异步超时排查每个问题都给出可直接照抄的解法。一、 第一个 k6 脚本怎么写不报错读完这节你手里会有一个跑起来不报错的最小脚本并避开新手 80% 的语法坑。最小可运行的三件套想象一下你要压测的目标一个 API 接口模拟 10 个用户每人每秒请求一次。k6 脚本只需要三部分——导入模块、配置选项、默认导出函数import http from k6/http; import { check, sleep } from k6; export const options { vus: 10, duration: 30s }; export default function () { const res http.get(https://test-api.k6.io/get); check(res, { status is 200: (r) r.status 200 }); sleep(1); }vus是虚拟用户数virtual users可以理解成并发线程duration是测试时长。sleep(1)让每个虚拟用户每秒跑一次否则请求会密集到压垮接口。新手最容易踩的两个坑把http.get的返回值当字符串用。k6 的响应对象上status、timings、json()才是你需要的没有response.body.text()这种写法。忘了导出 options。export const options少写export命令行参数全部失效而且不会报错很容易发现测试时长不对才回头查。仓库里examples/目录放了大量完整样例比如 examples/thresholds.js遇到不确定的写法先翻一遍样例比查文档快。二、 负载场景怎么配才能模拟真实用户这节解决压力怎么加的问题什么时候用恒定并发、什么时候该爬坡。先用最简单的执行器起步k6 内置了 6 种执行器executor控制用户数如何随时间变化的模式新手只需要认识前两种constant-vus恒定用户数N 个用户从头跑到尾适合冒烟测试和稳定性验证。ramping-vus阶梯用户数用户数按阶段爬坡或回落适合找到系统的性能拐点。一个爬坡-保持-回落的完整场景实际跑起来你会发现直接拉满并发经常看不到真实瓶颈——系统需要一点时间吃满。经典的三段式配置是10 秒爬到 100 个用户保持 1 分钟10 秒撤下来export const options { scenarios: { ramp: { executor: ramping-vus, startVUs: 0, stages: [ { duration: 10s, target: 100 }, { duration: 1m, target: 100 }, { duration: 10s, target: 0 }, ], }, }, };如果你还想让不同场景执行不同的业务流程可以给场景加exec: functionName指定导出函数并用startTime: 30s让第二个场景延迟启动实现先预热、再压主流程的效果。三、⏱️ 响应时间超标了阈值thresholds怎么设这节教你把性能达标从口头承诺变成可执行的判定条件测试结束自动告诉你过没过。三个最常用的聚合表达式阈值配置写在 options 里格式是指标名: [表达式]。你几乎只需要记三个p(95) 50095 分位响应时间小于 500 毫秒第 95 快的请求耗时比平均值更能代表真实用户感受avg 200平均耗时适合快速看整体水位rate 0.01失败请求占比小于 1%几乎每个脚本都要配这条。export const options { thresholds: { http_req_duration: [p(95)500, avg200], http_req_failed: [rate0.01], }, };注意表达式里p(95)500两侧不能留空格这是新手配置后不生效的头号原因。用标签阈值定位到底是哪个接口慢了全局 p(95) 超标时往往只是某个慢接口拖累了整体。k6 支持给阈值加标签条件http_req_duration{name:login}: [p(95)300]就能单独盯住登录接口。给请求打上业务标签后阈值就从全局大盘变成了精准探针。四、 异步请求总超时怎么办这节解决两个高频困惑k6 里异步到底是怎么跑的以及超时了怎么优雅处理。先搞懂 k6 的异步执行模型k6 的架构是一个协调者Coordinator 多个代理Agent每个虚拟用户跑在独立的 JavaScript 运行上下文里各自持有事件循环。这带来两个直接结论每个 VU 的变量互相隔离不要指望在模块顶层用一个对象跨用户共享状态await 会挂起当前 VU而不阻塞其他用户所以可以放心用 async/await 写串行流程。超时控制与重试给关键请求套一个超时包裹失败时指数退避重试比裸调http.get健壮得多export default async function () { const res await Promise.race([ http.get(https://test-api.k6.io/get, { timeout: 3s }), new Promise((_, r) setTimeout(() r(new Error(timeout)), 3000)), ]); if (!res) { console.log(请求超时放弃本次); return; } console.log(status:, res.status); }params.timeout其实已经能限制单次请求耗时Promise.race适合需要自己控制超时后做什么的场景比如换降级接口。五、 脚本报错了怎么快速定位原因这节给你一个排查顺序避免在错误日志里大海捞针。先分清是请求失败还是脚本错误请求失败接口返回 500 或网络不通k6 会把它计入http_req_failed指标但脚本本身继续跑——看这个指标的 rate 就知道是不是服务端的问题脚本错误JavaScript 抛异常比如res.json()解析失败k6 计入iterations的失败控制台会打印完整堆栈问题在脚本里。用 group 和 check 给输出分段日志一多console.log就看不清了。group(登录流程, () {...})能把一组请求归到同一个命名组下报告里按组聚合check的结果也带 check 名称。两者配合失败信息从某个请求 500变成登录流程 / 状态码 200 校验失败定位时间能砍一半。写在最后回到开头的 5 个问题收束成三句起步导入k6/http、导出options、默认函数里发请求就能跑通第一版脚本施压先 constant-vus 冒烟再 ramping-vus 爬坡找拐点判定p(95)加http_req_failed两条阈值是性价比最高的达标标准。按这个顺序练完一轮你就能独立接手一个完整的 k6 负载测试了。【免费下载链接】k6A modern load testing tool, using Go and JavaScript项目地址: https://gitcode.com/GitHub_Trending/k6/k6创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考