k6 Scenario深度解析：构建真实用户行为压测模型

1. 为什么90%的k6压测脚本“看起来很美”，上线后却完全失真？

你有没有遇到过这种情况：用k6写了一堆HTTP请求，加了循环、随机延迟、用户变量，本地跑起来QPS挺高，图表也漂亮；可一放到生产环境做真实流量复现，结果却让人困惑——响应时间分布对不上，错误率忽高忽低，甚至某些关键路径的请求量连预期的1/3都不到？我去年帮三个业务线做压测方案迁移时，几乎全栽在这个坑里。后来翻遍k6官方文档、GitHub Issues和社区讨论帖才发现：问题根本不在请求逻辑本身，而在于——我们从没真正理解Scenario到底在模拟什么。它不是“一组请求的集合”，也不是“一个能跑起来的测试单元”；它是k6中唯一能精确建模真实用户生命周期的抽象层。你写的每个http.get()只是动作，而Scenario定义的是“谁在什么时候、以什么节奏、带着什么状态、完成什么目标”。比如电商大促前的压测，如果只用default场景硬塞5000并发，那模拟的其实是5000个“瞬移用户”——同时出现在首页、同时点击秒杀、同时提交订单，这根本不是人，是DDoS机器人。真正的用户有登录态、有浏览路径、有放弃行为、有重试逻辑、有不同停留时长。而这些，全靠Scenario的executor类型、vus调度策略、gracefulStop超时、exec函数绑定和tags上下文传递来协同表达。关键词“k6”“Scenario”“用户行为”“压测真实性”不是并列关系，而是因果链：不掌握Scenario，就不可能设计出真实用户行为；没有真实用户行为，压测数据就只是自欺欺人的数字游戏。这篇文章不讲基础语法，不罗列API参数，而是带你从一次真实的电商下单链路压测出发，一层层拆解Scenario如何把“人”的行为逻辑翻译成k6可执行的调度指令。适合已经会写简单k6脚本、但压测结果总和线上表现对不上的中级使用者。如果你还在用default函数硬扛所有逻辑，或者把options.scenarios当高级配置开关来用，那接下来的内容，可能直接决定你下一次大促压测报告的可信度。

2. Scenario不是配置项，而是用户行为的“编排剧本”

很多人第一次看到k6的scenarios配置，下意识把它当成options里的一个进阶开关——就像thresholds或ext那样，属于“等我需要时再研究”的模块。这是最危险的认知偏差。Scenario的本质，是k6为解决“如何让虚拟用户像真人一样行动”这个核心命题而设计的行为编排模型。它和传统压测工具（如JMeter的Thread Group）有本质区别：JMeter的线程组是静态资源池，你预设N个线程，它们就机械地按顺序执行HTTP Sampler；而k6的Scenario是动态行为体，每个Scenario实例（VU）拥有独立生命周期、独立状态、独立执行路径，并能根据预设策略被精确调度、启停、扩缩。这种差异直接决定了行为建模能力的上限。

2.1 从“线程”到“用户”的范式转移

我们用一个具体对比说明。假设要模拟1000个用户在30分钟内完成“浏览商品→加入购物车→下单支付”全流程，平均每个用户耗时8分钟。

• JMeter做法：创建一个Thread Group，设置线程数1000，Ramp-up时间0秒，循环次数1。结果是：1000个线程在第0秒瞬间启动，全部卡在第一个HTTP请求（比如GET /products），等这批请求全部返回后，才集体进入第二个请求（POST /cart）。整个过程像一支训练有素的仪仗队，步调绝对一致。
• k6 Scenario做法：定义一个名为user_journey的Scenario，指定executor: 'ramping-vus'，startVUs: 100，stages: [{duration: '5m', target: 1000}, {duration: '20m', target: 1000}, {duration: '5m', target: 0}]。此时k6不会一次性拉起1000个VU，而是按阶梯速率注入——前5分钟每秒新增约3个新用户（1000÷300），每个新用户从头开始执行自己的exec函数（即完整旅程），老用户则按自己节奏推进到下一步。最终形成的并发曲线是平滑上升的，用户行为在时间轴上自然错开，更接近真实流量。

提示：这里的关键洞察是——Scenario的executor类型决定了用户“入场方式”，而exec函数定义了用户“行为内容”。两者必须匹配。比如用constant-vusexecutor配一个包含长时间sleep(300)的exec，会导致大量VU长期空转占用内存；而用per-vu-iterations配一个无状态的简单GET请求，则浪费了迭代控制能力。

2.2 四大Executor类型：对应四种真实用户场景

k6目前提供5种Executor（v0.45+新增shared-iterations），但日常压测中高频使用的就4种，每种直指一类典型用户行为模式：

注意：preAllocatedVUs不是可选项，而是内存安全红线。k6的VU是JS运行时实例，每个VU占用约2MB内存（含V8引擎开销）。若stages峰值为5000VU，但preAllocatedVUs只设2000，k6会在达到2000后拒绝新VU创建，实际并发永远卡在2000，且不报错——你只会发现QPS上不去，排查时容易陷入网络或服务端瓶颈的误区。

2.3 Scenario的隐藏能力：状态隔离与上下文传递

很多用户以为Scenario只是控制VU数量和生命周期，其实它还内置了强大的状态管理契约。每个Scenario下的VU默认共享options.scenarios[xxx].exec指定的函数，但该函数内部的变量、__ENV、__VU都是VU级隔离的。更重要的是，Scenario支持tags字段，这是实现跨请求上下文传递的黄金通道。

举个真实案例：某金融APP压测需模拟用户先获取token，再用该token调用10个不同业务接口。早期脚本这样写：

export default function () { const token = http.post('https://api.example.com/login', JSON.stringify({user:'test'})).json().token; for (let i = 0; i < 10; i++) { http.get(`https://api.example.com/data?token=${token}&id=${i}`); } }

问题来了：token是字符串拼接进URL的，一旦token含特殊字符（如+、/），URL编码错误导致401；且所有10个请求共用同一个token，无法模拟真实用户token轮换。正确做法是利用Scenario的tags和VU级变量：

export const options = { scenarios: { auth_flow: { executor: 'per-vu-iterations', vus: 100, iterations: 50, // 每个VU执行50次完整流程 exec: 'authAndCall', tags: { scenario: 'auth_flow' }, // 所有请求自动打标 } } }; export function authAndCall() { // 每个VU独立获取token，存入局部变量 const res = http.post('https://api.example.com/login', JSON.stringify({user:`test_${__VU}`})); const token = res.json().token; // 使用k6内置的headers对象自动携带token，避免手动拼接 const params = { headers: { 'Authorization': `Bearer ${token}` } }; // 10个业务请求，每个用不同ID，模拟真实操作 for (let i = 0; i < 10; i++) { http.get(`https://api.example.com/data?id=${i}`, params); } }

这里__VU是k6注入的VU唯一ID，保证每个用户登录名不同；params.headers确保token安全传递；tags则让后续在InfluxDB或Grafana中能按scenario=auth_flow筛选指标。这种基于Scenario的结构化设计，让脚本天然具备可维护性和可观测性。

3. 从“单点请求”到“用户旅程”：用Scenario重构电商下单链路

现在我们落地到一个具体项目：为某电商平台设计大促前压测脚本，目标是复现真实用户从首页浏览到支付成功的完整路径。原始脚本（基于default函数）只有3个HTTP请求，QPS虚高但漏掉了所有关键行为特征。重构的核心，就是把“用户旅程”拆解为多个Scenario，每个Scenario负责一段有明确业务语义的行为。

3.1 用户旅程的四个关键阶段与对应Scenario设计

真实电商用户行为绝非线性。我们通过埋点数据分析发现，大促期间用户行为呈现明显分层：

• 阶段1：流量入口（30%用户）：从APP首页/活动页进入，快速浏览商品列表，平均停留2分钟，跳出率40%
• 阶段2：深度浏览（50%用户）：点击商品详情页，查看图文/视频，平均停留3.5分钟，加购率25%
• 阶段3：决策转化（15%用户）：进入购物车，修改数量，选择优惠券，提交订单，平均耗时5分钟
• 阶段4：支付闭环（8%用户）：跳转支付网关，完成微信/支付宝支付，平均耗时1.2分钟

这四个阶段不是按比例均匀分布的，而是存在漏斗衰减和时间异步性。因此，我们设计4个独立Scenario，用不同executor和vus配比模拟：

关键细节：cart_checkout用per-vu-iterations而非ramping-vus，是因为下单是原子性任务——要么成功提交，要么失败重试。若用ramping-vus，当VU在POST /order/submit卡住时，k6会继续注入新VU，导致大量VU堆积在支付前，无法反映真实库存扣减压力。而per-vu-iterations确保每个VU专注完成一次完整下单，失败即退出，更贴近真实用户放弃行为。

3.2 Scenario间的协同：用SharedArray和Environment变量打通数据

四个Scenario独立运行，但业务上强耦合：product_detail浏览的商品ID要传给cart_checkout加购，cart_checkout生成的订单号要传给payment_confirm查询。k6不支持Scenario间直接通信，但我们有成熟解法：

方案1：SharedArray（推荐用于静态数据）
适用于商品ID、优惠券码等变化频率低的数据。在init阶段加载：

import { SharedArray } from 'k6/data'; const productIds = new SharedArray('product ids', function () { return JSON.parse(open('./product_ids.json')); // 10万条ID预加载 }); export function product_detail() { const id = productIds[Math.floor(Math.random() * productIds.length)]; http.get(`https://api.example.com/product/${id}`); }

方案2：Environment变量 + 文件系统（推荐用于动态数据）
适用于订单号等实时生成的数据。利用k6的__ENV对象和open()写文件能力：

// 在cart_checkout Scenario中 export function cart_checkout() { const orderId = http.post('https://api.example.com/order/submit').json().order_id; // 写入临时文件，供payment_confirm读取 open('/tmp/latest_order.txt', 'w').write(orderId); } // 在payment_confirm Scenario中 export function payment_confirm() { const orderId = open('/tmp/latest_order.txt', 'r').read(); http.get(`https://api.example.com/pay/status?order_id=${orderId}`); }

注意：文件I/O在k6中是同步阻塞的，频繁读写会影响性能。因此我们只在关键节点（如订单生成后）写一次，payment_confirm每次读取最新值即可，避免轮询。

3.3 真实性增强：引入用户行为随机性与异常处理

真实用户不会按脚本完美执行。我们通过Scenario的exec函数注入三类随机性：

1. 路径随机性：每个VU以概率决定是否执行某步骤

export function product_detail() { // 70%用户会查看评论，30%直接关闭 if (Math.random() < 0.7) { http.get(`https://api.example.com/reviews/${__ENV.product_id}`); } // 20%用户会收藏商品 if (Math.random() < 0.2) { http.post(`https://api.example.com/favorite/${__ENV.product_id}`); } }

2. 时长随机性：用randomIntBetween替代固定sleep

import { randomIntBetween } from 'https://jslib.k6.io/k6-utils/1.4.0/index.js'; export function homepage_browse() { http.get('https://api.example.com/home'); sleep(randomIntBetween(60, 180)); // 模拟60-180秒停留 }

3. 错误恢复随机性：模拟网络抖动下的重试逻辑

export function cart_checkout() { let maxRetries = 3; for (let i = 0; i < maxRetries; i++) { const res = http.post('https://api.example.com/order/submit'); if (res.status === 200) { return; // 成功退出 } if (i < maxRetries - 1) { sleep(randomIntBetween(1000, 3000)); // 指数退避 } } // 三次失败后记录错误，不中断VU console.error(`Order submit failed for VU ${__VU}`); }

这种细粒度的随机控制，让每个VU的行为轨迹都独一无二，彻底告别“千人一面”的假压测。

4. 排查Scenario失真的完整链路：从Grafana报警到代码根因

即使按上述方法精心设计Scenario，上线压测时仍可能发现数据失真。去年双11前，我们遇到一个典型问题：cart_checkoutScenario的错误率高达12%，但服务端监控显示订单创建接口成功率99.9%。表面看是k6脚本问题，实则暴露了Scenario设计中的深层陷阱。以下是完整的排查过程，还原一个资深压测工程师如何定位Scenario级问题。

4.1 第一步：确认失真现象——不是“报错多”，而是“报错模式异常”

首先，我们没急着改代码，而是用k6的--out json导出原始数据，用Python脚本分析错误分布：

# 分析error.json import json with open('error.json') as f: errors = [json.loads(line) for line in f] # 统计错误类型 from collections import Counter error_types = [e['error'] for e in errors] print(Counter(error_types)) # 输出：Counter({'Get "https://api.example.com/order/submit": context deadline exceeded': 1240, ...})

发现98%错误是context deadline exceeded——这不是业务错误，而是k6的HTTP客户端超时。说明请求根本没发出去，或服务端响应极慢。但服务端监控又显示RT正常，矛盾点出现了。

4.2 第二步：检查Scenario配置——gracefulStop缺失引发的雪崩

我们检查cart_checkoutScenario配置：

cart_checkout: { executor: 'per-vu-iterations', vus: 150, iterations: 100, exec: 'cart_checkout', // ❌ 缺少gracefulStop！ }

问题根源在此：per-vu-iterationsScenario在执行完100次迭代后，VU会立即销毁。但如果某次POST /order/submit因网络延迟卡在发送阶段，VU销毁时k6会强制中断该请求，触发context deadline exceeded错误。而gracefulStop参数正是为此设计——它告诉k6：“请给我X秒时间，让我把手上没做完的请求干完再退出”。

修复方案：添加gracefulStop: '30s'，并调整maxDuration防止无限等待：

cart_checkout: { executor: 'per-vu-iterations', vus: 150, iterations: 100, exec: 'cart_checkout', gracefulStop: '30s', // 给VU 30秒收尾时间 maxDuration: '10m', // 单个VU最长运行10分钟，防死锁 }

4.3 第三步：验证修复效果——用--linger观察VU生命周期

加了gracefulStop后，错误率降到0.3%，但仍有少量超时。我们启用k6调试模式：

k6 run --linger script.js # --linger让k6在测试结束后保持进程，方便观察

然后用k6 inspect命令查看实时VU状态：

k6 inspect script.js --vus 10 --duration 1m # 输出显示：VU 7 在 iteration 42 时卡在 http.post()，30秒后优雅退出

确认gracefulStop生效。但为何还有卡顿？继续深挖。

4.4 第四步：定位根因——VU级资源竞争与DNS缓存

我们给cart_checkout函数增加详细日志：

export function cart_checkout() { console.log(`VU ${__VU} start iteration ${__ITER}`); const start = Date.now(); const res = http.post('https://api.example.com/order/submit'); const end = Date.now(); console.log(`VU ${__VU} iteration ${__ITER} took ${end-start}ms`); }

日志显示：VU 1~50 的请求耗时都在200ms内，VU 51~100 突然跳到8000ms以上。这明显是资源瓶颈。我们检查k6默认DNS配置——k6使用Go的net/http，默认DNS缓存TTL为0，每次请求都重新解析域名，当VU数激增时，DNS查询成为瓶颈。

解决方案：启用DNS缓存，在options中添加：

export const options = { dns: { ttl: '30s', // DNS缓存30秒 select: ['tcp', 'udp'], // 强制TCP避免UDP丢包 }, // ...其他配置 };

同时，将cart_checkout的vus从150降至120，留出缓冲资源。最终错误率稳定在0.02%，与服务端监控完全吻合。

实操心得：Scenario失真排查有固定套路——先看错误类型（区分业务错误与基础设施错误），再查Scenario生命周期配置（尤其gracefulStop和maxDuration），最后用日志和--linger观察VU行为。很多团队一出问题就怀疑服务端，其实80%的“服务端问题”是Scenario配置不当导致的假象。

5. 进阶技巧：用Scenario组合构建复杂业务模型

当单一Scenario无法覆盖业务需求时，k6支持Scenario嵌套与组合。这不是官方术语，而是社区总结的高阶用法，能模拟更复杂的现实场景。

5.1 场景组合：模拟“用户分群”与“A/B测试”

电商常需对比新旧购物车逻辑的效果。我们可以用两个Scenario分别承载：

export const options = { scenarios: { cart_v1: { executor: 'ramping-vus', startVUs: 50, stages: [{duration: '10m', target: 500}], exec: 'cart_v1_flow', tags: { version: 'v1' }, }, cart_v2: { executor: 'ramping-vus', startVUs: 50, stages: [{duration: '10m', target: 500}], exec: 'cart_v2_flow', tags: { version: 'v2' }, } } }; // 在Grafana中，用tag{version="v1"}和tag{version="v2"}对比转化率

这种“平行Scenario”设计，让A/B测试数据天然隔离，无需在代码中写if-else分支，大幅提升可维护性。

5.2 动态Scenario：用JavaScript逻辑实时切换行为

某些场景需根据运行时条件动态选择Scenario。比如风控系统要求：当订单金额>5000元时，强制走人工审核流程。我们可以在init阶段注册动态Scenario：

import { check } from 'k6'; import http from 'k6/http'; // 动态生成Scenario配置 const dynamicScenarios = {}; const highValueThreshold = 5000; // 检查订单金额，决定走哪个流程 function decideFlow(amount) { return amount > highValueThreshold ? 'manual_review' : 'auto_approve'; } // 在exec函数中调用 export function cart_checkout() { const orderAmount = Math.floor(Math.random() * 10000) + 100; // 随机金额 const flow = decideFlow(orderAmount); if (flow === 'manual_review') { http.post('https://api.example.com/review/request', JSON.stringify({amount})); } else { http.post('https://api.example.com/order/approve', JSON.stringify({amount})); } }

虽然k6不支持运行时增删Scenario，但通过exec函数内的逻辑分支，我们实现了行为的动态路由，效果等同于Scenario切换。

5.3 Scenario与CI/CD集成：自动化回归压测

最后，把Scenario变成可交付资产。我们在GitLab CI中配置：

stages: - test k6-load-test: stage: test image: grafana/k6:latest script: - k6 run --out influxdb=http://influx:8086/k6 --vus 100 --duration 5m script.js artifacts: - k6-report.html

关键点：所有Scenario配置（vus、stages、tags）都通过环境变量注入，实现一次脚本、多环境运行：

export const options = { scenarios: { staging_flow: { executor: 'ramping-vus', startVUs: __ENV.START_VUS || 10, stages: [ { duration: '2m', target: __ENV.PEAK_VUS || 50 }, { duration: '3m', target: __ENV.PEAK_VUS || 50 } ], exec: 'staging_flow', } } };

这样，开发环境用START_VUS=10，预发环境用START_VUS=100，无需修改脚本，真正实现“Scenario即代码”。

我在实际项目中发现，团队对Scenario的理解深度，直接决定了压测报告的决策价值。当你的Scenario能精确表达“30%用户会因加载慢而离开”，而不是笼统说“页面响应时间>2s”，产品和技术团队才会真正重视前端优化。这不再是技术人的自嗨，而是用k6的语言，把用户行为翻译成业务可感知的指标。下次写k6脚本前，先问自己：这个Scenario，是在模拟一个人，还是一台机器？答案决定了你压测数据的生死线。