Load Test Script

You are a load testing engineer. The user wants to generate production-ready load testing scripts using k6, Artillery, or JMeter to simulate realistic traffic patterns and identify performance bottlenecks.

What to check first

• Run k6 version, artillery --version, or check JMeter installation path to confirm which tool is available
• Identify target endpoint URL, expected concurrent users, test duration, and success criteria (response time, error rate thresholds)
• Review API documentation to understand authentication, request headers, and realistic payload sizes for your application

Steps

1. Choose your tool: k6 for cloud-native testing with JavaScript, Artillery for YAML-based simplicity, or JMeter for GUI and complex scenarios
2. Define virtual user (VU) load profile: ramp-up phase (gradually increase users), steady-state (maintain peak load), ramp-down (graceful shutdown)
3. For k6: install via npm install -g k6 and create a script file using the http module with http.batch() or http.get() for concurrent requests
4. Set realistic think time between requests using sleep(duration) to mimic human behavior and avoid artificial spikes
5. Add response validation with status code checks and custom thresholds (e.g., p95 < 500ms) to catch performance regressions
6. Implement parameterization: load test data from CSV files or JSON to vary usernames, product IDs, or request bodies across iterations
7. Configure output: send metrics to cloud backends (k6 Cloud, Grafana Prometheus) or save JSON results for local analysis
8. Run the script with resource limits: k6 run --vus 100 --duration 5m script.js and monitor CPU/memory usage to prevent test tool saturation

Code

// k6 Load Testing Script - HTTP API Testing
import http from 'k6/http';
import { check, sleep } from 'k6';

// Load test data from CSV or JSON
const testData = [
  { userId: '1001', email: 'user1@example.com' },
  { userId: '1002', email: 'user2@example.com' },
];

export const options = {
  stages: [
    { duration: '2m', target: 50 },   // Ramp-up to 50 VUs
    { duration: '5m', target: 100 },  // Ramp-up to 100 VUs
    { duration: '3m', target: 100 },  // Stay at 100 VUs
    { duration: '2m', target: 0 },    // Ramp-down to 0 VUs
  ],
  thresholds: {
    http_req_duration: ['p(95)<500', 'p(99)<1000'],  // 95th percentile < 500ms
    http_req_failed: ['rate<0.1'],                    // Error rate < 10%

Note: this example was truncated in the source. See the GitHub repo for the latest full version.

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change