- Startseite
- Skills
- Testen
- Performance-Test-Planer
Performance-Test-Planer
Lasttests und Performance-Benchmarks planen — Schwellenwerte definieren, Verkehrsmuster simulieren und Regressionen erkennen.
Das Problem
Die Anwendung funktioniert hervorragend mit 10 Benutzern. Aber was passiert bei 1.000? Oder 10.000? Performance-Probleme — langsame Datenbankabfragen, Speicherlecks, Verbindungspool-Erschoepfung — zeigen sich erst unter Last. Die meisten Teams entdecken diese Probleme in Produktion waehrend eines Traffic-Peaks statt in einer kontrollierten Testumgebung. Lasttests zu planen erfordert Verstaendnis von Verkehrsmustern, aussagekraeftige Schwellenwerte und die richtige Toolwahl — ein Spezialwissen, das den meisten Entwicklern fehlt.
Der Prompt
Erstelle einen Performance-Testplan fuer meine Anwendung. Ich muss wissen, wie sie sich unter realistischer Last verhaelt, bevor sie in Produktion geht.
ANWENDUNG:
[App beschreiben — Typ, erwarteter Traffic, Tech-Stack, Infrastruktur]
AKTUELLE METRIKEN (falls bekannt):
[z.B. "P95 Antwortzeit: 400ms, 500 RPM Durchschnitt, 2000 RPM Spitze"]
TOOL-PRAEFERENZ: [k6 / Artillery / Locust / JMeter / Gatling]
Generieren:
1. **Verkehrsmodell** — Realistische Verkehrsmuster definieren:
- Normale Last (durchgehender taeglicher Traffic)
- Spitzenlast (Marketingkampagne, Produktstart)
- Spike-Test (ploetzlicher 10-facher Traffic-Burst)
- Ausdauertest (Dauerlast ueber 4-8 Stunden zur Erkennung von Speicherlecks)
2. **Performance-Schwellenwerte** — Bestanden/Durchgefallen-Kriterien definieren:
- P95 Antwortzeit pro Endpunkt
- Fehlerrate in Prozent
- Durchsatz (Anfragen pro Sekunde)
- Ressourcenauslastungslimits (CPU, Speicher, Verbindungen)
3. **Testskripte** — Die tatsaechlichen Lasttestskripte fuer die Top-3 kritischen Endpunkte mit:
- Realistische Bedenkzeit zwischen Anfragen
- Korrekte Hoch- und Herunterfahr-Muster
- Benutzerdefinierte Metriken fuer geschaeftskritische Operationen
- Datenparametrisierung (nicht jedes Mal derselbe Benutzer/Request)
4. **CI-Integration** — Zeigen, wie Performance-Tests in CI mit automatischem Bestanden/Durchgefallen basierend auf Schwellenwerten ausgefuehrt werden.
Beispielausgabe
// k6-Lasttest fuer Checkout-API
import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
stages: [
{ duration: '2m', target: 100 }, // Hochfahren
{ duration: '5m', target: 100 }, // Halten
{ duration: '2m', target: 500 }, // Spitze
{ duration: '1m', target: 0 }, // Herunterfahren
],
thresholds: {
http_req_duration: ['p(95)<800', 'p(99)<1500'],
http_req_failed: ['rate<0.01'],
},
};
Wann verwenden
Vor einem grossen Launch, nach signifikanten Infrastrukturaenderungen oder bei Verdacht auf Performance-Regressionen. Ausdauertests vor jedem Release ausfuehren, um Speicherlecks zu finden, die erst nach Stunden unter Dauerlast auftreten. Schwellenwertbasierte Performance-Tests in CI integrieren, um Regressionen frueh zu erkennen.
Profi-Tipps
- Echtes Benutzerverhalten modellieren — KI bitten, Zugriffsprotokolle zu analysieren und ein Verkehrsmodell zu generieren, das tatsaechliche Nutzungsmuster widerspiegelt.
- Die Datenbank testen, nicht nur die API — Erkennung langsamer Abfragen und Verbindungspool-Monitoring in Performance-Tests einbeziehen.
- Mit Baselines vergleichen — Ergebnisse jedes Laufs speichern und KI bitten, Trends zu analysieren: “Steigt P95 ueber die letzten 10 Laeufe an?”
- Ausfallszenarien testen — Szenarien einbeziehen, in denen eine Abhaengigkeit langsam ist oder ausfaellt, um graceful Degradation zu verifizieren.