Load-Testing-Skripte mit Claude entwickeln: k6, realistische Lastprofile und Perzentile

1. Warum Load-Tests oft die falsche Frage beantworten

Viele Load-Tests entstehen unter Zeitdruck kurz vor einem großen Launch und bestehen im Kern aus einer Schleife, die denselben Endpunkt mit konstanter Rate anfragt. Das Ergebnis sieht beruhigend aus, sagt über das tatsächliche Verhalten unter echter Nutzerlast aber wenig aus, weil reale Nutzer nicht gleichmäßig auf einen einzelnen Endpunkt zugreifen, sondern in unregelmäßigen Sitzungen durch mehrere Seiten navigieren, Formulare ausfüllen und dabei Denkpausen einlegen.

Claude eignet sich gut, um diesen Aufwand zu senken: aus einer Beschreibung typischer Nutzerpfade lassen sich vollständige k6-Skripte mit realistischen Übergängen und Wartezeiten generieren, bestehende Skripte lassen sich auf synthetische Verzerrungen prüfen, und die am Ende erzeugten JSON-Ergebnisse lassen sich gezielt interpretieren, ohne jede Kennzahl von Hand nachrechnen zu müssen.

2. Ein k6-Skript aus einer Nutzerpfad-Beschreibung generieren lassen

Der schnellste Einstieg ist, Claude den typischen Ablauf einer Nutzersitzung in Prosa zu beschreiben, etwa Produktseite aufrufen, in den Warenkorb legen, sich einloggen und zur Kasse gehen, und daraus ein vollständiges k6-Skript in JavaScript generieren zu lassen. Wichtig ist, konkrete Endpunkte, erwartete Statuscodes und benötigte Payload-Strukturen mitzugeben, damit das Skript nicht nur syntaktisch korrekt ist, sondern auch tatsächlich gegen die eigene API funktioniert.

Besonders hilfreich ist Claude bei der Umsetzung von Checks und Custom-Metriken, die über die Standardausgabe von k6 hinausgehen, etwa eine eigene Trend-Metrik für die Zeit bis zur ersten sichtbaren Antwort im Checkout-Flow. Diese Feinheiten werden beim manuellen Schreiben oft ausgelassen, weil sie zusätzlichen Code erfordern, den man beim Generieren einfach mit anfordern kann.

import http from 'k6/http';
import { check, sleep } from 'k6';
import { Trend } from 'k6/metrics';

const checkoutDuration = new Trend('checkout_duration');

export const options = {
  scenarios: {
    checkout_flow: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '2m', target: 50 },
        { duration: '5m', target: 50 },
        { duration: '2m', target: 0 },
      ],
    },
  },
};

export default function () {
  const product = http.get('https://shop.example.com/api/products/42');
  check(product, { 'Produktseite 200': (r) => r.status === 200 });
  sleep(Math.random() * 3 + 1);

  const start = Date.now();
  const order = http.post('https://shop.example.com/api/checkout', JSON.stringify({ productId: 42 }));
  checkoutDuration.add(Date.now() - start);
  check(order, { 'Checkout 201': (r) => r.status === 201 });
  sleep(Math.random() * 2 + 1);
}

3. Realistische Lastprofile statt gleichmäßiger Dauerlast

Ein häufiger Anfängerfehler ist die konstante Anzahl virtueller Nutzer über die gesamte Testdauer, während reale Systeme typischerweise über Minuten oder Stunden hinweg an- und abschwellende Lastspitzen erleben, etwa zur Mittagszeit oder nach einer Marketing-Kampagne. Claude hilft, aus einer groben Beschreibung des erwarteten Verkehrsmusters, etwa langsamer Anstieg über zehn Minuten, Plateau während einer Stunde, dann abrupter Rückgang, ein passendes stages-Array für k6 abzuleiten, das dieses Verhalten realistisch nachbildet.

Ebenso wichtig ist die Denkpause zwischen einzelnen Aktionen, das sogenannte Think-Time. Ohne realistische Sleep-Aufrufe zwischen den Requests erzeugt ein Skript eine künstlich hohe Anfragerate pro Nutzer, die kein echter Mensch je erzeugen würde, wodurch der Test das System in einem Lastregime testet, das in der Praxis so nie auftritt. Claude kann anhand typischer Interaktionsmuster realistische Wertebereiche für Sleep-Aufrufe vorschlagen, statt pauschal eine feste Sekunde zu verwenden.

4. Zwischen JMeter und k6 wechseln und Skripte konvertieren lassen

Viele etablierte Teams besitzen eine gewachsene JMeter-Testsammlung im XML-Format, während neue Kolleginnen und Kollegen häufig lieber in k6 mit JavaScript arbeiten, weil sich die Skripte einfacher versionieren und in CI/CD-Pipelines integrieren lassen. Claude kann bestehende JMX-Dateien einlesen und daraus ein funktional äquivalentes k6-Skript ableiten, wobei insbesondere Extraktoren, Parameterisierung über CSV-Dateien und Assertions sorgfältig übertragen werden müssen, da diese in beiden Werkzeugen unterschiedlich modelliert sind.

In die andere Richtung ist Claude ebenfalls nützlich, etwa wenn ein bestehendes JMeter-Setup aus Compliance-Gründen weiterhin verpflichtend ist, aber ein neues k6-Skript als Referenz für das gewünschte Lastprofil existiert. In diesem Fall lässt sich die Logik erklären und in eine JMeter-Testplan-Struktur mit Thread-Groups und Timern übersetzen, ohne dass jemand im Team beide Werkzeuge gleich gut beherrschen muss.

5. Warum Perzentile statt Durchschnitt die eigentliche Wahrheit zeigen

Der Durchschnitt einer Latenzverteilung ist eine der irreführendsten Kennzahlen im Performance-Testing, weil ein einzelner sehr schneller Ausreißer eine Vielzahl langsamer Anfragen rechnerisch kaschieren kann. Ein System mit einer durchschnittlichen Antwortzeit von 150 Millisekunden kann trotzdem für 5 Prozent der Nutzer über 3 Sekunden brauchen, ein Erlebnis, das im Durchschnitt komplett untergeht, aber für genau diese Nutzer den Unterschied zwischen Kauf und Kaufabbruch ausmacht.

Claude lässt sich gut nutzen, um k6-Zusammenfassungen oder JMeter-Reports gezielt nach Perzentilen statt nach Durchschnittswerten aufzubereiten und auf Auffälligkeiten hinzuweisen, etwa eine große Lücke zwischen p95 und p99, die auf ein einzelnes langsames Backend-System oder eine schlecht indexierte Datenbankabfrage hindeuten kann. Diese Art der Mustererkennung in tabellarischen Ergebnisdaten ist eine der Stärken, bei denen Claude schneller ist als das manuelle Durchsuchen langer Report-Dateien.

# k6 mit JSON-Zusammenfassung ausführen
k6 run --summary-export=summary.json checkout.js

# Relevante Kennzahlen für Claude aufbereiten
jq '.metrics.http_req_duration' summary.json

6. k6-Ergebnisse mit Claude interpretieren statt nur ablesen

Wenn man die exportierte JSON-Zusammenfassung eines Testlaufs direkt in Claude einfügt, lässt sich neben den reinen Zahlen auch nach einer fachlichen Einschätzung fragen: Steigt die Latenz proportional zur Anzahl virtueller Nutzer oder gibt es einen erkennbaren Knick, ab dem das System deutlich stärker verlangsamt, was typischerweise auf einen erreichten Kapazitätsengpass hindeutet. Solche Knickpunkte von Hand aus einer Tabelle mit Dutzenden Zeilen herauszulesen, ist mühsam und fehleranfällig, während Claude Trends in strukturierten Daten zuverlässig erkennt.

Ebenso lässt sich die Fehlerquote im Kontext der Lastphasen einordnen: Fehler, die erst ab einer bestimmten Anzahl gleichzeitiger virtueller Nutzer auftreten, deuten auf ein Ressourcenlimit hin, etwa einen erschöpften Datenbank-Connection-Pool, während Fehler, die von Beginn an konstant auftreten, eher auf einen funktionalen Bug im Testskript selbst oder in der getesteten Anwendung hindeuten. Diese Unterscheidung hilft, die Ursachenanalyse in die richtige Richtung zu lenken, bevor unnötig Zeit in die falsche Spur investiert wird.

7. Typische Fehler bei synthetischer Lasterzeugung, die Claude im Review findet

Ein wiederkehrendes Problem ist die sogenannte Thundering-Herd-Situation, bei der alle virtuellen Nutzer eines Testlaufs exakt zur selben Sekunde starten und dieselbe erste Anfrage senden, wodurch eine künstliche Anfangsspitze entsteht, die kein reales Nutzerverhalten widerspiegelt. Ein zweites häufiges Muster ist ein einzelner, geteilter Authentifizierungs-Token für alle virtuellen Nutzer, wodurch nicht die Login-Infrastruktur getestet wird, sondern nur ein einziger, künstlich bevorzugter Pfad, während das reale System unter Last mit tausenden individuellen Token-Validierungen ganz anders reagieren würde.

Ein drittes, subtileres Problem ist DNS- und Verbindungs-Caching auf Ebene des Lastgenerators selbst, wodurch wiederholte Requests unrealistisch schnell erscheinen, weil TCP-Verbindungen wiederverwendet werden, während echte Nutzer aus dem Internet über sehr unterschiedliche Netzwerkpfade und häufig neue Verbindungen kommen. Claude erkennt solche Muster zuverlässig beim Code-Review eines Skripts, wenn man explizit nach Verzerrungsquellen fragt, statt sich nur auf eine allgemeine Prüfung auf Syntaxfehler zu beschränken.

// Problematisch: alle VUs starten synchron, ein Token für alle
export const options = { vus: 200, duration: '5m' };
const TOKEN = 'shared-static-token';

// Besser: gestaffelter Start, individuelle Tokens pro VU
export const options = {
  scenarios: {
    default: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [{ duration: '3m', target: 200 }],
    },
  },
};
export function setup() {
  return { tokens: fetchTokensForEachVirtualUser() };
}

8. Load-Tests mit Claude-generierten Schwellenwerten in CI/CD einbinden

Damit ein Load-Test nicht nur einmalig vor einem Launch, sondern dauerhaft als Regressionsschutz dient, gehört er als eigener Schritt in die CI/CD-Pipeline, mit klar definierten k6-thresholds, die den Build fehlschlagen lassen, sobald die Performance unter einen definierten Wert fällt. Claude hilft dabei, aus den Ergebnissen vorheriger Testläufe sinnvolle Threshold-Werte abzuleiten, etwa dass p95 unter 800 Millisekunden bleiben muss und die Fehlerquote 1 Prozent nicht überschreiten darf.

Wichtig ist, den Load-Test bewusst schlanker zu gestalten als den vollen Test vor einem Major-Release, damit die Pipeline nicht durch eine zehnminütige Lastphase blockiert wird. Claude kann helfen, ein reduziertes CI-Profil mit kürzeren Phasen und weniger virtuellen Nutzern aus dem vollständigen Lastprofil abzuleiten, das dennoch aussagekräftig genug bleibt, um echte Regressionen zuverlässig zu erkennen.

export const options = {
  thresholds: {
    http_req_duration: ['p(95)<800'],
    http_req_failed: ['rate<0.01'],
  },
  scenarios: {
    ci_smoke: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [{ duration: '1m', target: 20 }, { duration: '2m', target: 20 }],
    },
  },
};

9. Grenzen: synthetische Last ist nicht die Wahrheit

So gut Claude beim Erstellen und Review von Load-Testing-Skripten hilft, bleibt jeder synthetische Test eine Näherung an echtes Nutzerverhalten und ersetzt keine kontinuierliche Produktionsbeobachtung. Claude kennt die tatsächliche Verteilung eurer echten Nutzerpfade nicht automatisch, sie muss aus realen Analytics-Daten oder Access-Logs abgeleitet und explizit als Kontext mitgegeben werden, sonst basiert das gesamte Lastprofil auf einer plausiblen, aber letztlich geratenen Annahme.

Ebenso wichtig ist, dass ein bestandener Load-Test in einer isolierten Staging-Umgebung nicht automatisch bedeutet, dass das System in Produktion mit denselben externen Abhängigkeiten, Netzwerkbedingungen und Datenmengen gleich reagiert. Claude liefert einen soliden Ausgangspunkt für Skripte, Lastprofile und Auswertung, die endgültige Validierung gegen die reale Produktionslast bleibt jedoch Aufgabe des Teams, idealerweise ergänzt durch echtes Produktions-Monitoring während und nach einem Launch.

10. Zusammenfassung

11. FAQ: Load-Testing mit Claude: Häufige Fragen