สถานการณ์ผู้ใช้เสมือน (VUs)

When performance testing, a simple 'run 10 VUs for 30 seconds' might not capture real user behavior. Real users often have different patterns: some log in, some browse, some make purchases. This is where k6 scenarios come in!

Scenarios allow you to define complex load profiles and simulate diverse user groups, each with its own specific behavior and load pattern, all within a single test script.

In k6, you define scenarios within the options object of your test script. The scenarios block is a JavaScript object where each key represents a unique scenario name.

Each scenario specifies an executor, which dictates how virtual users (VUs) and iterations are managed. It also links to a specific function in your script that defines what those VUs will do.

The default k6 executor, shared-iterations, distributes a fixed number of iterations among a pool of VUs. Each VU will execute as many iterations as it can until the total specified iterations are complete or the test duration ends.

It's good for tests where you want to complete a specific amount of work.

The constant-VUs executor maintains a fixed number of virtual users throughout the test's duration. VUs are started at the beginning and kept active until the duration is met.

This is useful for simulating a steady, continuous load on your system.

The ramping-VUs executor allows you to gradually increase or decrease the number of virtual users over time. This simulates a more realistic load curve, like users slowly joining a website or leaving it.

It uses stages to define these changes in VU count.

Within ramping-VUs, stages are an array of objects, each with a duration and a target VU count.

• duration: How long this stage lasts (e.g., '1m', '30s').
• target: The number of VUs to reach by the end of this stage. k6 will linearly ramp VUs from the current stage's end target to the next stage's target.

Stages are powerful for modeling complex load patterns like peak hours or sudden traffic spikes.

Unlike VU-based executors, ramping-arrival-rate is an open model executor. It controls the rate at which new iterations (or 'arrivals') are started, rather than the number of VUs.

This is ideal for testing systems where you care about requests per second (RPS) or transactions per second (TPS).

You can define multiple, independent scenarios within a single k6 script. Each scenario can have its own executor, VUs, duration, and even call a different function that defines its specific user journey.

This allows you to simulate a mix of user types (e.g., admin users, regular users, guests) in one comprehensive test.

Beyond basic executor settings, scenarios offer additional options for precise control:

• startTime: Delay the start of a specific scenario (e.g., '10s' after test start). Useful for staggered tests.
• gracefulStop: How long k6 should wait for active VUs to finish their current iteration before forcefully stopping them (e.g., '5s').
• env: Environment variables specific to this scenario.

These options help orchestrate complex test flows.

You need to simulate a load test where:

• 5 virtual users (VUs) constantly browse the homepage for 1 minute.
• At the same time, another group of users gradually ramps up from 0 to 10 VUs over 30 seconds, then holds at 10 VUs for 30 seconds, performing a login action.

Which two k6 executors would be most appropriate for these two distinct user behaviors?

In this lesson, you've learned how k6 scenarios enable you to model diverse and realistic load patterns. We explored key executors:

• shared-iterations for fixed work.
• constant-VUs for steady load.
• ramping-VUs for gradual load changes with stages.
• ramping-arrival-rate for open-model testing based on request rate.

You also saw how to combine multiple scenarios and use options like startTime for advanced control. Mastering scenarios is crucial for sophisticated performance testing!