企业官网建设流程全解析

5 个高频问题带你写出第一版 k6 负载测试脚本

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

k6 是一款用 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)让每个虚拟用户每秒跑一次，否则请求会密集到压垮接口。

新手最容易踩的两个坑

1. 把http.get的返回值当字符串用。k6 的响应对象上status、timings、json()才是你需要的，没有response.body.text()这种写法。
2. 忘了导出 options。export const options少写export，命令行参数全部失效，而且不会报错，很容易发现测试时长不对才回头查。

仓库里examples/目录放了大量完整样例，比如 examples/thresholds.js，遇到不确定的写法先翻一遍样例，比查文档快。

二、📈 负载场景怎么配才能模拟真实用户

这节解决"压力怎么加"的问题：什么时候用恒定并发、什么时候该爬坡。

先用最简单的执行器起步

k6 内置了 6 种执行器（executor，控制用户数如何随时间变化的模式），新手只需要认识前两种：

1. constant-vus（恒定用户数）：N 个用户从头跑到尾，适合冒烟测试和稳定性验证。
2. 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 里，格式是指标名: ['表达式']。你几乎只需要记三个：

1. p(95) < 500：95 分位响应时间小于 500 毫秒（第 95 快的请求耗时），比平均值更能代表真实用户感受；
2. avg < 200：平均耗时，适合快速看整体水位；
3. rate < 0.01：失败请求占比小于 1%，几乎每个脚本都要配这条。

export const options = { thresholds: { http_req_duration: ['p(95)<500', 'avg<200'], http_req_failed: ['rate<0.01'], }, };

注意表达式里p(95)<500两侧不能留空格，这是新手配置后不生效的头号原因。

用标签阈值定位"到底是哪个接口慢了"

全局 p(95) 超标时，往往只是某个慢接口拖累了整体。k6 支持给阈值加标签条件：http_req_duration{name:login}: ['p(95)<300']，就能单独盯住登录接口。给请求打上业务标签后，阈值就从"全局大盘"变成了"精准探针"。

四、🧵 异步请求总超时怎么办

这节解决两个高频困惑：k6 里异步到底是怎么跑的，以及超时了怎么优雅处理。

先搞懂 k6 的异步执行模型

k6 的架构是"一个协调者（Coordinator）+ 多个代理（Agent）"，每个虚拟用户跑在独立的 JavaScript 运行上下文里，各自持有事件循环。这带来两个直接结论：

1. 每个 VU 的变量互相隔离，不要指望在模块顶层用一个对象跨用户共享状态；
2. 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适合需要自己控制"超时后做什么"的场景（比如换降级接口）。

五、🔍 脚本报错了，怎么快速定位原因

这节给你一个排查顺序，避免在错误日志里大海捞针。

先分清是"请求失败"还是"脚本错误"

1. 请求失败：接口返回 500 或网络不通，k6 会把它计入http_req_failed指标，但脚本本身继续跑——看这个指标的 rate 就知道是不是服务端的问题；
2. 脚本错误：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