WRITE WHAT YOU WILL PROVE

LPT Documentation
& Test Concepts

Professionelle Performance-Dokumentation macht Annahmen sichtbar, verbindet Testaufbau mit Geschäftsrisiken und erlaubt einem zweiten Team, den Lauf zu wiederholen. Dieser Leitfaden liefert ein ausführliches Lasttestkonzept, eine präzise Testspezifikation und Formulierungen für adressatengerechtes Reporting.

02HAUPTTEMPLATES

04TEXTBAUSTEINE

✓REVIEW READY

FIELDNOTES / LPT DOCSFORMAT MARKDOWN · VERSIONIERBAR · PRÜFBAR

01 — DOCUMENT DESIGN

Dokumentation als Testvertrag

Ein gutes Dokument beantwortet vor dem Lauf: Warum testen wir, was genau wird getestet, welche Last repräsentiert die Nutzung, wie erkennen wir Erfolg und wer entscheidet bei einem Risiko?

Für mehrere Leser:innen schreiben

Management benötigt Ergebnis, Nutzerwirkung und Entscheidung. Engineering benötigt Messgrenzen, Workload, Metrikquellen und Reproduktionsschritte. Betrieb benötigt Zeitfenster, Abbruchweg, Ansprechpartner und Cleanup. Ein Management Summary steht deshalb vorne; Details und Rohdaten bleiben auffindbar, aber nachgeordnet.

Traceability und Versionierung

Jede Anforderung erhält eine Kennung, ein messbares Ziel und einen oder mehrere Testfälle. Verknüpfe Konzept, Spezifikation, Skript-Commit, Build, Testdatenversion, Ergebnis und Befund-ID. Änderungen an SLOs oder Workload-Profilen brauchen Owner, Datum und Begründung.

Leserschaft und gewünschte Entscheidung benanntDas Dokument ist auf Management, Engineering und Betrieb abgestimmt. Anforderungen, Testfälle und Befunde verknüpftIDs bleiben über Konzept, Run, Skriptversion und Bericht nachvollziehbar. Annahmen, Grenzen und offene Punkte sichtbarUnbestätigte Daten, Umgebungsabweichungen und Ausschlüsse sind explizit.

02 — LOAD TEST CONCEPT

Template: Lasttestkonzept

Das Konzept legt Ziele, Systemgrenzen, Workload, Testarten, Risiken, Messung und Abnahme fest. Vor dem ersten repräsentativen Lauf mit Fachbereich, Entwicklung, Betrieb und Datenschutz abstimmen.

Management Summary

Ausgangslage, Geschäftsziel, Teststufe, wichtigste Erfolgskennzahl, Zeitfenster und gewünschte Freigabe kurz zusammenfassen.

System under Test (SuT)

Entry Points, eingeschlossene Services, Datenbank/Cache/Queue, Versionen, Umgebungen, externe Abhängigkeiten und Ausschlüsse beschreiben.

Workload-Modell

Transaktionsmix, Arrival Rate, Gleichzeitigkeit, Think Time, Payload, Datensatzverteilung, Ramp-up und Peak-Fenster aus belastbaren Quellen herleiten.

Testarten und Messplan

Load, Spike und Endurance mit Hypothese, Laufzeit, Lastverlauf, Telemetrie, Abbruchregeln und Artefakten festlegen.

Risiko- und Betriebsbewertung

Seiteneffekte, Datenverlust, Provider-Quoten, Sicherheits- und Datenschutzrisiken mit Eintritt, Auswirkung und Mitigation bewerten.

MODEL

Beispiel: Workload-Matrix

Beispielwerte sind Startpunkte, keine universellen Ziele. An Produktionsbeobachtung, Prognose und SLO anpassen.

JOURNEY / SZENARIO	MIX	RATE	THINK TIME / DATEN	MESSZIEL
Login	10 %	12 Aktionen/s	1–3 s; eindeutige Nutzer	P95 ≤ 250 ms
Katalogsuche	55 %	66 Aktionen/s	2–5 s; Begriffe nach Häufigkeit	P95 ≤ 350 ms; Fehler < 0,5 %
Checkout	25 %	30 Aktionen/s	3–8 s; eindeutige Warenkörbe	P95 ≤ 500 ms; fachlicher Erfolg
Bestellstatus	10 %	12 Aktionen/s	5–15 s; verteilte Bestell-IDs	P99 ≤ 900 ms

120 Aktionen/s über 10 Minuten entsprechen 72.000 Aufrufen. Wenn nur jede zehnte Katalogsuche in einen Checkout mündet, darf der Journey-Mix diese Abhängigkeit nicht als unabhängige Zufallsaktion modellieren.

TEST TYPES

Load, Spike und Endurance klar abgrenzen

Jede Testart braucht eigene Hypothese, Lastkurve und Pass/Fail-Regel.

TESTART	LASTVERLAUF	FRAGE	WESENTLICHE GRENZE
Load	Repräsentative Zielrate mit Warm-up und stabilem Fenster	Erfüllt das System NFRs bei erwarteter Spitzenlast?	SLI-Ziele bei Mindestdurchsatz und Fehlerbudget
Spike	Abrupter Sprung von Basis- auf Spitzenrate	Hält das System Lastsprung und Erholung aus?	Queue-Aufbau, Fehler und Erholungszeit
Endurance / Soak	Stundenlange stabile oder tagesprofilartige Last	Entstehen Leaks, Bloat oder Drift-Probleme?	Heap, Queue, Latenz und Durchsatz über Zeit

RISK

Risikobewertung mit Trigger und Owner

„Wird beobachtet“ ist keine Mitigation.

RISIKO	WAHRSCHEINLICHKEIT / AUSWIRKUNG	MITIGATION / TRIGGER	OWNER
Shared Environment	Mittel / hoch	Dediziertes Zeitfenster; Abbruch bei fremdem Traffic	Test Lead + Betrieb
Testdaten-Leakage	Niedrig / hoch	Synthetische Konten, Zugriff begrenzen, Cleanup	Data Owner
Generator-Sättigung	Mittel / hoch	CPU/Netzwerk/VUs überwachen; dropped iterations ungültig	Performance Engineer
Provider-Rate-Limit	Mittel / mittel	Sandbox oder Mock; Quote vorab freigeben	Service Owner

Vollständiges Markdown-Template: Lasttestkonzept

Platzhalter ersetzen, Belege verlinken und nicht anwendbare Abschnitte nur mit Begründung entfernen.

MD load-test-concept.md

# Lasttestkonzept: [Projekt / Release]
## Dokumentensteuerung
- Owner / Reviewer / Freigabe:
- Version / Datum / Änderung:
- Verknüpfte Anforderungen und Tickets:
## 1. Management Summary
- Geschäftsziel und Anlass:
- Umfang / bewusste Ausschlüsse:
- Zielrate und wichtigste SLOs:
- Testfenster, Status und benötigte Entscheidung:
## 2. System under Test (SuT)
- Entry Points, Protokolle und Versionen:
- Services, Datenbanken, Caches und Queues im Umfang:
- Externe Abhängigkeiten / Mocks / Sandboxes:
- Architekturdiagramm und Trace-Beispiele:
- Umgebung und relevante Produktionsabweichungen:
## 3. Ziele und Abnahmekriterien
| ID | SLI / Messgrenze | Ziel | Last / Zeitfenster | Quelle |
|----|------------------|------|-------------------|--------|
| NFR-01 | [Client-P95 je Journey] | [< 400 ms] | [120/s, 20 min] | [Dashboard] |
- Fehlerbudget, Mindestdurchsatz und Generator-Gesundheit:
## 4. Workload-Modell
| Journey | Mix | Rate | Think Time | Datenprofil |
|---------|-----|------|------------|-------------|
| [Search] | [55 %] | [66/s] | [2–5 s] | [synthetische Begriffe] |
- Quelle / Zeitraum / Anonymisierung:
- Ramp-up, Steady State, Ramp-down und Peak-Profil:
- Cache warm/kalt, Concurrency und Wiederholungslogik:
## 5. Testarten und Ablauf
- Load: [Hypothese, Rate, Dauer, Gate]
- Spike: [Sprung, Haltezeit, Erholungsziel]
- Endurance: [Dauer, Drift-Metriken, Abbruch]
- Warm-up, Reset, Reihenfolge und Wiederholungen:
## 6. Testdaten und Umgebung
- Seed, Datenvolumen, Reset und Cleanup:
- Konten / Secrets / Berechtigungen:
- Generator-Topologie und Dimensionierung:
- Build, Konfiguration, Limits und Feature Flags:
## 7. Observability und Artefakte
- RED / USE Dashboards, Run-ID und Annotation:
- Logs, Traces, JTL/JSON, Screenshots und Aufbewahrung:
- Zeitquelle, Metriklabels und Datenzugriff:
## 8. Risiken, Abbruch und Kommunikation
| Risiko | Wahrscheinlichkeit | Auswirkung | Mitigation | Owner |
|--------|--------------------|------------|------------|-------|
| [Shared env] | [mittel] | [hoch] | [Testfenster + Stop] | [Name] |
- Abbruch bei: [Fehlerquote / Sättigung / Seiteneffekt]
- Eskalationskanal und erreichbare Verantwortliche:
## 9. Ergebnis und Freigabe
- PASS / PASS WITH FINDINGS / FAIL:
- Findings, Restrisiko und Entscheidung:
- Freigabe durch Fachbereich / Engineering / Betrieb:

03 — TEST SPECIFICATION

Template: Testspezifikation

Die Spezifikation zerlegt das freigegebene Konzept in ausführbare Einzelfälle. Eine Person, die den Test nicht entworfen hat, muss Ablauf, Parameter und erwartetes Ergebnis ohne Zusatzannahmen nachvollziehen können.

Testfall mit vollständigem Vertrag

Jeder Fall enthält ID, Ziel, verknüpfte NFR, Vorbedingungen, Testdaten, Schrittfolge, fachliches Ergebnis, Lastprofil, Assertions, Abbruchkriterien und Artefakt-Links. Transaktionsnamen in Skript, Dashboard und Bericht identisch halten.

User Journey als Sequenz

Schritte und Denkpausen realistisch beschreiben: Session aufbauen, Aktion senden, Antwort prüfen, Folgeaktion abhängig vom Resultat wählen. Think Time ist Nutzerverhalten, kein Ersatz für Server-Wartezeit. Retry-Verhalten explizit festlegen.

PARAMETER	BEISPIEL / QUELLE	KARDINALITÄT	LEBENSZYKLUS / SCHUTZ
base_url	CI-Variable je Umgebung	1 pro Lauf	Vor Start validieren; nicht im Skript fixieren
user_id	Anonymisierte CSV-Zeile	1 je virtuellem Nutzer	Eindeutig zuweisen; keine PII
sku / search_term	Versionierter Datenkatalog	Verteilung gemäß Workload	Seed und Bestand vor Lauf prüfen
access_token	CI Secret Store	Kurze Gültigkeit pro Run	Nicht loggen oder als Metriklabel verwenden

Testfall-ID und NFR-Verknüpfung gesetztBefunde sind bis zur freigegebenen Anforderung rückverfolgbar. User Journey mit Datenabhängigkeiten beschriebenReihenfolge, Think Time, Erfolgspfad, Fehlerpfad und Labels sind explizit. Abbruchkriterien, Owner und Cleanup freigegebenEin Run kann sicher angehalten und ohne manuelle Datenreste beendet werden.

Kopierbares Template: Testspezifikation und Testfälle

MD test-specification.md

# Testspezifikation: [Suite / Release]
## Laufkontext
- Konzept / Version / Freigabe:
- Build / Umgebung / Run-ID:
- Testdaten-Seed / Generator / Zeitfenster:
## Testfall [TC-001]: [fachlicher Name]
- Ziel / zugehörige NFR / Priorität / Owner:
- Vorbedingungen und Health Checks:
- Testdaten: Quelle, Verteilung, Eindeutigkeit, Reset:
- Parameter: Name, Wertquelle, Default, Validierung:
### User Journey
| Schritt | Aktion / Endpoint | Daten | Assertion / Ergebnis |
|---------|-------------------|-------|----------------------|
| 1 | [POST /session] | [CSV user] | [HTTP 200, token gesetzt] |
| 2 | [GET /catalog] | [search_term] | [Treffer vorhanden] |
| 3 | [POST /checkout] | [cart_id] | [HTTP 201, order_id] |
### Lastprofil
- Modell: [Arrival Rate / VUs]
- Mix, Zielrate, Concurrency, Think Time:
- Warm-up / Ramp-up / Steady State / Ramp-down:
- Laufzeit und Wiederholungen:
### Erwartung und Gate
- Fachliche Assertions:
- SLI-Grenzen (P95/P99, Fehlerquote, Mindestdurchsatz):
- Generator-Grenzen (dropped iterations, CPU, Netzwerk):
### Abbruch und Wiederanlauf
- Sofortiger Abbruch bei:
- Anhaltende Grenzwertverletzung über [Dauer/Fenster]:
- Entscheidung durch / Eskalation an:
- Reset / Cleanup / Wiederanlaufbedingungen:
### Belege
- JTL/JSON, Dashboard, Logs, Traces:
- Ergebnis / Abweichung / Ticket:

04 — REPORTING

Befunde verständlich berichten

Gutes Reporting führt mit Entscheidung und Nutzerwirkung. Es nennt Messfenster, Last, Population und Unsicherheit, bevor aus einer Korrelation eine Ursache gemacht wird.

P95-Latenz managementgerecht formulieren

Perzentil erklären, Lastbedingung angeben und Auswirkungen einordnen; Mittelwert oder Einzelmaximum nicht als Ersatz verwenden.

↗

BEISPIELTEXT · PERFORMANCE

Vom Messwert zur Entscheidung

„Unter der vereinbarten Spitzenlast von 120 Checkout-Transaktionen pro Sekunde lag die P95-Antwortzeit bei 620 ms gegenüber dem Ziel von 400 ms. Damit überschritten 5 % der erfolgreichen Anfragen 620 ms; die Fehlerquote blieb bei 0,2 %. Das Latenzziel wurde verfehlt, obwohl die Fehlerrate im Budget lag. Vor dem Release empfehlen wir, den Datenbankpfad zu untersuchen und denselben Workload erneut zu messen.“

Beobachtung, Interpretation, Empfehlung

Der Beispieltext benennt Journey, Rate, Perzentil, Fehlerquote und Entscheidung. Ergänze Zeitraum, Stichprobengröße, Client-/Server-Messgrenze, Vergleichsbasis und Einschränkungen. „Die Messung zeigt“ passt zu einer Beobachtung; eine konkrete Ursache braucht kontrollierte Gegenproben.

Unsicherheit kenntlich machen

Bei kleiner Stichprobe, geteilter Umgebung oder starkem Rauschen den Befund als Hinweis kennzeichnen. Ein nicht signifikanter Unterschied belegt keine Gleichwertigkeit und ein bestandener Test gilt nur für die getestete Rate, Dauer und Umgebung.

Textbaustein: Query-Plan und Datenbank-Bottleneck

TXT database-finding.md

BEOBACHTUNG
Unter [Rate] stieg die P95-Latenz von [Baseline] auf [Messwert];
[Anteil] der Serverzeit entfiel auf Datenbankzugriffe.

BELEG
Query [Fingerprint/Name] lief [n] Mal mit Median [x ms].
EXPLAIN (ANALYZE, BUFFERS) zeigte [Scan/Sort/Lock],
[geschätzte] gegenüber [tatsächlichen] Zeilen und [Buffer] Reads.

EINORDNUNG
Die Daten sprechen für [wahrscheinlichen Engpass]. Der Befund ist
[bestätigt / plausibel / noch nicht isoliert], weil [Begründung].

EMPFEHLUNG / GEGENPROBE
[Index / Query / Pool] kontrolliert ändern; gleiche Parameter,
Daten und Last erneut messen. Erfolg: [messbare Zielwerte].
Risiko: [Write-Amplification / Speicher / Locking / Rollback-Plan].

Formulierungen für typische Ergebnisse

BEFUND	PRÄZISE FORMULIERUNG	VERMEIDEN
P99 überschritten	„Bei 120 Requests/s lag P99 für Search bei 1,4 s; 1 % der Requests war langsamer. Die Abweichung trat in 3 von 3 Läufen auf.“	„Die App ist langsam.“
DB wartet	„Während der Latenzspitze stieg Pool-Wartezeit parallel zu aktiven DB-Verbindungen; CPU blieb unter 60 %. Das spricht für Pool-/DB-Konkurrenz, noch nicht für eine einzelne Query als Ursache.“	„Die Datenbank ist überlastet.“
Kein Regressionseffekt	„Innerhalb der getesteten Rate und Umgebung lag die Änderung unter der Nachweisgrenze; dies belegt keine Kapazität oberhalb von 150/s.“	„Es gibt keine Performance-Auswirkung.“

Kopierbarer Management-Summary-Baustein

TXT management-summary.txt

ERGEBNIS: [PASS / PASS WITH FINDINGS / FAIL]
UNTERSUCHTER NUTZERPFAD: [Journey] bei [Rate] über [Dauer]
NUTZERWIRKUNG: [P95/P99, Fehlerquote, erfolgreiche Rate]
WICHTIGSTER BEFUND: [Beobachtung + Beleg, keine unbewiesene Ursache]
RISIKO / LIMITIERUNG: [Umgebung, Stichprobe, Abhängigkeit]
ENTSCHEIDUNG: [Freigabe / Bedingung / erneuter Lauf]
NÄCHSTER SCHRITT: [Owner] bis [Datum] mit Erfolgskriterium [Messwert]

05 — REVIEW

Vorlage freigeben

Ein Dokument ist bereit, wenn ein anderes Teammitglied den Lauf daraus sicher ausführen und das Ergebnis anhand vorher bekannter Kriterien bewerten kann.

Management Summary nennt Ziel und gewünschte EntscheidungGeschäftskontext, Nutzerwirkung und Status sind schnell verständlich. SuT, Systemgrenzen und Abhängigkeiten sind eindeutigVersionen, Datenbank, Cache, Provider und Ausschlüsse sind auffindbar. Workload-Mix und Testarten sind begründetQuellen, Raten, Dauer, Rampen, Datenprofil und Testtyp passen zur Frage. SLIs, Pass/Fail- und Abbruchkriterien sind messbarFehlerbudget, Mindestdurchsatz, Stichprobe und Generator-Health berücksichtigt. Risiken, Owner, Freigaben und Cleanup sind benanntDatenschutz, Testfenster, Stop-Kontakt und Artefakt-Aufbewahrung sind geklärt. Ein unabhängiger Reviewer kann Test und Report reproduzierenScript-Version, Parameter, Run-ID, Dashboards und Vorlagen sind verknüpft.

↗

DER PRAKTISCHE STANDARD

Jede Aussage hat eine Messgrenze. Jeder Test hat ein Gate.

Nutze das Konzept für Ziele und Risiken, die Spezifikation für ausführbare Fälle und den Report für Befund und Entscheidung. Zusammen bilden sie den nachvollziehbaren Vertrag zwischen Auftrag, Testlauf und Release-Entscheidung.