Load and stress test scenario generation

How to Identify Performance-Critical Paths from Requirements with AI?

Performance testing without a clear list of performance-critical paths is performance theater. You run k6 against your homepage, see a 95th percentile of 120ms, declare victory, and then the checkout service falls over on launch day because nobody measured the three-step payment flow at 500 concurrent users. AI does not prevent this problem automatically — but it dramatically accelerates the analytical work required to find those paths before you write a single line of load test code.

What "performance-critical" actually means

A path is performance-critical if any one of the following is true:

1. High traffic volume: The path executes hundreds or thousands of times per minute under normal load
2. Business impact on latency: A slow response directly reduces conversion, retention, or SLA compliance
3. Resource intensity: The path performs database joins, external API calls, file I/O, or large computation
4. State mutation under concurrency: Multiple concurrent users modifying shared state (inventory, seats, account balances)
5. Downstream dependency: The path's latency determines the latency of other paths (e.g., an auth service called on every request)

A human QA engineer builds this list by reading requirements docs, talking to product managers, reviewing database query logs, and consulting developers. That synthesis typically takes half a day. AI can do a first pass in minutes — and its output gives you a structured starting point for that developer conversation instead of a blank page.

Feeding requirements to AI for critical path extraction

The key to getting useful output is giving AI the right inputs. For critical path identification, you want to combine:

• Product requirement documents (PRDs) or user stories
• OpenAPI / Swagger specs
• Architecture diagrams (described textually or as markdown)
• Any available APM data or access logs (even a sample)

Prompt template for critical path extraction from requirements:

You are a senior performance engineer analyzing requirements to identify 
performance-critical paths before load testing.

Here is the product requirements document for the {feature/system} I am 
about to performance test:

---
{PASTE PRD OR USER STORIES HERE}
---

Here is the OpenAPI spec for the relevant service:

---
{PASTE OPENAPI SPEC OR ENDPOINT LIST HERE}
---

Analyze these requirements and produce:

1. A ranked list of performance-critical API endpoints or user journeys, 
   ranked by estimated business impact of latency degradation (highest first).

2. For each critical path, explain:
   - Why it is performance-critical (traffic volume, resource intensity, 
     business impact, or concurrency risk)
   - What the likely performance bottleneck is (DB query, external API, 
     in-memory computation, etc.)
   - What SLA or threshold I should set for this path based on typical 
     industry benchmarks for this type of operation

3. Identify any paths that appear low-traffic but are high-risk under 
   concurrency (e.g., inventory reservation, seat booking, payment processing).

Format the output as a markdown table followed by a detailed analysis 
section for each critical path.

Using access log samples for data-driven path prioritization

If you have access to nginx logs, CloudWatch logs, or any request-level telemetry, paste a representative sample and ask AI to rank paths by actual traffic volume:

Here is a 10-minute sample of production access logs from our API gateway:

---
{PASTE LOG SAMPLE — even 50-100 lines is useful}
---

From this log sample:
1. Identify the top 10 endpoints by request frequency
2. Identify endpoints with high variance in response times (p50 vs p95 gap > 2x)
3. Flag any endpoints where response times exceed 500ms even at low concurrency
4. Suggest which 5 endpoints should be the primary focus of load testing 
   based on combined traffic volume and latency risk

Format as a prioritized list with rationale for each entry.

Mapping user journeys to technical paths

Requirements often describe journeys ("user adds items to cart and checks out") while load tests operate on technical endpoints. AI bridges this translation:

Given this user story:

"As a registered customer, I want to complete a purchase so that my order 
is confirmed and I receive an email receipt."

Acceptance criteria:
- User can search for products
- User can add up to 20 items to cart
- User can apply promo codes
- User can select shipping and payment
- Order confirmation email sent within 30 seconds

Map this user story to a sequence of API calls that a load test must 
simulate, including:
- The exact HTTP methods and endpoints involved
- Dependencies between steps (which calls must complete before the next)
- Data that must be created or seeded before the test
- Session state that must be maintained across the journey (cookies, tokens)
- Concurrent operations that might occur (other users modifying inventory 
  simultaneously)

Learning Tip: The most valuable thing AI produces in this step is not the list itself — it's the rationale column. When you take this list to your architect and developers, having a documented reason for each path ("inventory reservation is flagged because multiple concurrent writes to a single row under MySQL gap locks is a known contention pattern") converts a QA request into a technical conversation. Paste the AI output into your kick-off meeting doc and walk through the reasoning together.

How to Generate Realistic Load Profiles and User Journey Simulations with AI?

A load profile is the description of how users arrive and behave over time. Flat 100-user constant load is not a realistic profile. Real traffic has ramp-up periods, peak bursts, lulls, and uneven distribution across endpoints. Getting the profile right is the difference between a test that builds confidence and a test that produces results nobody trusts.

Understanding load profile components

Before you prompt AI, you need to know what elements make up a load profile so you can verify AI output:

Prompting AI to derive realistic profiles from business data

I need to design a realistic load profile for a performance test. 
Here is the business context:

- Application type: E-commerce platform
- Expected peak: Black Friday, estimated 3× normal peak load
- Current normal peak: ~200 concurrent users based on Google Analytics
- Current production p95 response time for checkout: 1.8 seconds
- Traffic pattern: Gradual ramp from 8am, peaks at noon and 7pm, 
  drops off after 9pm (US Eastern time)
- Known user behavior: Most users browse (60%), fewer add to cart (30%), 
  fewer complete purchase (10%)
- Session data: Average session ~9 minutes, ~15 page interactions per session

Design a load profile for a Black Friday simulation that includes:
1. A realistic VU (virtual user) ramp-up schedule with time breakpoints
2. Journey distribution percentages for each user type
3. Think time recommendations for each step in the purchase journey
4. The total test duration with phase breakdown
5. The target throughput in requests/second at peak

Output as a structured specification I can hand to a k6 script author.

Generating user journey simulations

Once you have a profile, you need the actual user journeys modeled in detail. Journeys are sequences of requests with realistic data, headers, and timing:

I need a user journey simulation spec for the "authenticated purchase" 
path in my e-commerce load test.

The journey steps are:
1. POST /auth/login  
2. GET /api/products?category={random_category}
3. GET /api/products/{product_id}  (pick a random product from step 2 results)
4. POST /api/cart/items
5. GET /api/cart
6. POST /api/cart/promo  (30% of users apply a promo code)
7. GET /api/shipping/options
8. POST /api/orders/checkout
9. GET /api/orders/{order_id}  (poll until status != PENDING, max 10s)

For each step, specify:
- Realistic request headers (including auth token from step 1)
- Realistic request payload examples with parameterized test data
- Expected response status codes and how to validate them
- Think time between this step and the next
- How to handle failure at this step (abort journey? retry? skip step?)
- Data dependencies (what data from previous responses must be extracted)

Format as a journey specification document with one section per step.

Learning Tip: User journey simulations fail not on the happy path but on data dependencies. The most common load test bug is failing to extract session tokens, product IDs, or order references from one step and inject them into the next. When you give AI the journey specification and ask it to flag data dependencies, it almost always catches the coupling issues that would cause your test to fail 30 minutes after you start it. Check its "data dependencies" output line by line before you write a single script.

How to Design Stress Test Scenarios — Thresholds, Ramp-Up, and Break-Point — with AI?

Stress testing answers a different question than load testing. Load testing asks "does the system perform acceptably under expected load?" Stress testing asks "where does the system break, and how does it break?" The design of a stress test requires deliberate choices about ramp strategy, threshold configuration, and what "breaking" means for your system.

Stress test design dimensions

A complete stress test design covers:

• Ramp strategy: Linear, exponential, step-function, or spike
• Break-point definition: What observable signal declares the system broken (error rate, latency threshold, resource exhaustion, process crash)
• Recovery behavior: Does the system self-heal when load drops, or does it remain degraded?
• Threshold ladder: The sequence of load levels to test (e.g., 1× → 2× → 3× → 4× normal peak)
• Observation scope: What metrics to capture at each stage (CPU, memory, DB connections, queue depth, GC pause time)

Prompting AI to design a complete stress test scenario

I need to design a stress test to find the break-point of our order 
processing service.

System context:
- Service: Node.js REST API, single instance (no auto-scaling in test env)
- Normal peak load: 150 requests/second on POST /api/orders/checkout
- Database: PostgreSQL 14, 4 vCPU, 16GB RAM, connection pool max 100
- External dependencies: Payment gateway (Stripe), inventory service 
  (internal gRPC), email service (SendGrid)
- Current known thresholds: DB CPU spikes at ~120 concurrent connections

Design a stress test scenario that:

1. Defines a ramp-up strategy to find the break-point without jumping 
   past it (I want to observe degradation, not just crash)
2. Specifies the exact load levels (requests/second) at each stage and 
   how long to hold each stage before proceeding
3. Defines break-point detection criteria: what metrics and threshold 
   values should halt the test automatically
4. Specifies what system metrics to collect at each stage (and at what 
   sampling interval)
5. Designs a recovery observation phase: after reaching break-point, 
   how should load be reduced and what recovery metrics should be tracked
6. Identifies which external dependencies to mock vs. hit for real, 
   and why

Output as a numbered stress test execution plan.

Configuring k6 thresholds based on AI-recommended SLOs

AI can help you translate business SLOs into k6 threshold syntax:

My team has agreed on the following SLOs for the checkout API:

- 99th percentile response time must be under 3 seconds
- Error rate must stay below 0.5%
- 95th percentile response time must be under 1.5 seconds
- The system must handle at least 200 concurrent VUs before any 
  threshold is breached

Translate these SLOs into k6 threshold configuration syntax. 
Also add:
- A threshold that aborts the test if error rate exceeds 5% 
  (to prevent runaway failure tests)
- Thresholds for the specific groups: "checkout flow" and 
  "product search" separately
- Explain each threshold line so a junior engineer can understand 
  what it measures

AI output you can refine:

export const options = {
  thresholds: {
    // Global HTTP error rate: must stay below 0.5%
    http_req_failed: ['rate<0.005'],

    // Global p95 response time: under 1.5 seconds
    http_req_duration: ['p(95)<1500', 'p(99)<3000'],

    // Checkout flow group: p95 under 2 seconds, p99 under 4 seconds
    'http_req_duration{group:::checkout flow}': [
      'p(95)<2000',
      'p(99)<4000',
    ],

    // Product search: p95 under 800ms (read-heavy, should be faster)
    'http_req_duration{group:::product search}': ['p(95)<800'],

    // Abort test if error rate spikes above 5% (circuit breaker)
    http_req_failed: [
      { threshold: 'rate<0.005', abortOnFail: false },
      { threshold: 'rate<0.05', abortOnFail: true, delayAbortEval: '30s' },
    ],
  },
};

Learning Tip: Stress test scenarios have two common failure modes in planning: (1) ramps that are too steep, which means you skip through degradation modes and can't tell where performance started to decline; and (2) break-point criteria that are too vague ("it felt slow"). Ask AI to give you a break-point detection checklist with specific metric values before you run the test. Then log every stage's metrics even if the system hasn't broken yet — the degradation curve leading up to break-point is often more valuable than the break-point itself.

How to Generate k6, Gatling, or Locust Scripts with AI?

This is where theory becomes executable code. AI is excellent at generating syntactically correct, well-structured load test scripts — but the quality of output varies significantly based on how much context you provide. A vague prompt produces a toy script. A detailed prompt with a journey specification, threshold config, and framework-specific conventions produces production-ready scaffolding.

Generating a complete k6 script

Provide AI with a detailed specification:

Generate a complete k6 load test script for the following scenario.

Test target: E-commerce checkout API at https://api.staging.mystore.com

User journey (authenticated purchase):
1. POST /auth/login 
   Body: { "email": "${EMAIL}", "password": "${PASSWORD}" }
   Extract: access_token from response body

2. GET /api/products?category=electronics&limit=20
   Headers: Authorization: Bearer ${access_token}
   Extract: array of product IDs from response body

3. GET /api/products/${random_product_id_from_step2}
   Extract: product_id, price, stock_status
   Validate: stock_status == "IN_STOCK"

4. POST /api/cart/items
   Body: { "product_id": "${product_id}", "quantity": 1 }
   Extract: cart_id

5. POST /api/orders/checkout
   Body: { 
     "cart_id": "${cart_id}", 
     "payment_method": "test_card",
     "shipping_address": { 
       "line1": "123 Test St", 
       "city": "Boston", 
       "zip": "02101" 
     }
   }
   Extract: order_id
   Validate: response status 201, order status "PENDING"

Load profile:
- Ramp from 0 to 50 VUs over 2 minutes
- Hold 50 VUs for 10 minutes  
- Ramp from 50 to 200 VUs over 3 minutes
- Hold 200 VUs for 5 minutes
- Ramp down to 0 over 2 minutes

Test data: 
- Load emails/passwords from a CSV file named "test_users.csv" 
  with columns: email, password
- Parameterize so each VU uses a different user row

Thresholds:
- p(95) < 2000ms overall
- p(99) < 4000ms overall  
- http_req_failed rate < 1%

Requirements:
- Use k6 groups to label each step ("login", "browse", "add_to_cart", "checkout")
- Add checks for each response (status codes, required fields in response body)
- Handle failed login gracefully (log and abort the VU iteration, don't continue)
- Add console.log summary of failures at end of test
- Use k6 environment variables for base URL so it can be run against 
  different environments

A well-prompted AI will generate a script like this (abbreviated):

import http from 'k6/http';
import { check, group, sleep } from 'k6';
import { SharedArray } from 'k6/data';
import { Counter, Rate, Trend } from 'k6/metrics';
import papaparse from 'https://jslib.k6.io/papaparse/5.1.1/index.js';

const BASE_URL = __ENV.BASE_URL || 'https://api.staging.mystore.com';

// Load test users from CSV
const users = new SharedArray('users', function () {
  return papaparse.parse(open('./test_users.csv'), { header: true }).data;
});

export const options = {
  stages: [
    { duration: '2m', target: 50 },
    { duration: '10m', target: 50 },
    { duration: '3m', target: 200 },
    { duration: '5m', target: 200 },
    { duration: '2m', target: 0 },
  ],
  thresholds: {
    http_req_duration: ['p(95)<2000', 'p(99)<4000'],
    http_req_failed: ['rate<0.01'],
  },
};

const checkoutFailures = new Counter('checkout_failures');

export default function () {
  const user = users[__VU % users.length];
  let accessToken, cartId, productId;

  // Step 1: Login
  group('login', () => {
    const loginRes = http.post(
      `${BASE_URL}/auth/login`,
      JSON.stringify({ email: user.email, password: user.password }),
      { headers: { 'Content-Type': 'application/json' } }
    );

    const loginOk = check(loginRes, {
      'login status 200': (r) => r.status === 200,
      'login returns token': (r) => r.json('access_token') !== undefined,
    });

    if (!loginOk) {
      checkoutFailures.add(1);
      return; // Abort this VU iteration
    }

    accessToken = loginRes.json('access_token');
  });

  if (!accessToken) return;

  const authHeaders = {
    headers: {
      Authorization: `Bearer ${accessToken}`,
      'Content-Type': 'application/json',
    },
  };

  // Step 2: Browse products
  group('browse', () => {
    const productsRes = http.get(
      `${BASE_URL}/api/products?category=electronics&limit=20`,
      authHeaders
    );

    check(productsRes, {
      'products status 200': (r) => r.status === 200,
      'products returns array': (r) => Array.isArray(r.json('data')),
    });

    const products = productsRes.json('data') || [];
    const inStock = products.filter((p) => p.stock_status === 'IN_STOCK');
    if (inStock.length > 0) {
      productId = inStock[Math.floor(Math.random() * inStock.length)].id;
    }
    sleep(2);
  });

  if (!productId) return;

  // Step 3: Add to cart
  group('add_to_cart', () => {
    const cartRes = http.post(
      `${BASE_URL}/api/cart/items`,
      JSON.stringify({ product_id: productId, quantity: 1 }),
      authHeaders
    );

    check(cartRes, {
      'add to cart status 201': (r) => r.status === 201,
      'cart_id returned': (r) => r.json('cart_id') !== undefined,
    });

    cartId = cartRes.json('cart_id');
    sleep(1);
  });

  if (!cartId) return;

  // Step 4: Checkout
  group('checkout', () => {
    const checkoutRes = http.post(
      `${BASE_URL}/api/orders/checkout`,
      JSON.stringify({
        cart_id: cartId,
        payment_method: 'test_card',
        shipping_address: {
          line1: '123 Test St',
          city: 'Boston',
          zip: '02101',
        },
      }),
      authHeaders
    );

    const checkoutOk = check(checkoutRes, {
      'checkout status 201': (r) => r.status === 201,
      'order status PENDING': (r) => r.json('status') === 'PENDING',
      'order_id returned': (r) => r.json('order_id') !== undefined,
    });

    if (!checkoutOk) {
      checkoutFailures.add(1);
    }
    sleep(1);
  });
}

Generating a Gatling simulation with AI

For Gatling (Scala DSL), provide the same journey spec but request Gatling syntax:

Generate a Gatling simulation in Scala for the same checkout journey 
described above.

Requirements:
- Use Gatling 3.9+ DSL
- Use feeder from CSV for test users
- Define the load profile as a rampUsers scenario
- Use checks to validate response body fields (not just status codes)
- Add a separate scenario for "browse only" users (GET /api/products only, 
  no purchase) with 60% of VUs
- Add a "purchaser" scenario with 40% of VUs that completes full checkout
- Use Gatling's throttle to cap requests/second at 500 as a safety ceiling

Generating a Locust script for Python teams

Generate a Locust load test script for the checkout journey.

Requirements:
- Use Locust's HttpUser class
- Define tasks with @task(weight) decorators:
  - browse_products: weight 6 (most common)
  - view_product_detail: weight 4
  - add_to_cart: weight 3
  - complete_checkout: weight 1
- Use Locust's on_start to authenticate each user and store the token
- Add response time tracking using Locust's events
- Make it runnable headlessly with: 
  locust -f checkout_test.py --headless -u 200 -r 10 --run-time 15m

Learning Tip: When you get AI-generated load test scripts, the first thing to do before running them is a "dry run" review with AI itself. Paste the generated script back and ask: "Review this k6 script for common load testing mistakes: data dependencies that could cause null reference errors, think times that are unrealistically short, missing error handling that would hide failures, and thresholds that might never be breached because of how checks are written." AI catches its own bugs surprisingly well when you change the review framing. This two-step generate-then-review loop produces significantly more reliable scripts than single-shot generation.