Was ist Soak Testing?

Was ist Soak Testing?

Soak Testing (auch Endurance Testing genannt) lässt moderate, anhaltende Last gegen ein System für viele Stunden oder Tage laufen, weit länger als ein typischer Load Test. Das Ziel ist nicht, die Kapazitätsobergrenze zu finden oder das System stress-zubrechen. Es geht darum, langsam entwickelnde Probleme aufzudecken, die sich erst nach Stunden Betrieb zeigen: Memory Leaks, Connection-Pool-Drift, Log-Disk-Fill, Zertifikatsablauf, Datenbankverbindungs-Thrashing, langsame Cache-Eviction-Patterns.

Soak Testing vs Load Testing

Ein Load Test läuft bei erwartetem Peak für 15 Minuten bis ein paar Stunden. Lange genug, dass Caches warm werden und kurzfristiges Verhalten sich stabilisiert. Ein Soak Test läuft bei vielleicht 40-60% des Peaks für 8-72 Stunden. Lange genug, dass sich allmählich anhäufende Probleme sichtbar werden.

Die Fragen, die jeder beantwortet, unterscheiden sich:

• Load Test: Kann mein System SLOs bei erwartetem Peak für eine oder zwei Stunden erfüllen?
• Soak Test: Wenn ich mein System bei moderater Last kontinuierlich für zwei Tage laufen lasse, bleibt die Performance stabil oder degradiert sie langsam?

Soak Tests laufen absichtlich unter dem Peak, um akkumulierende Probleme aufzudecken. Um die maximale aufrechterhaltbare Last selbst zu finden, siehe Capacity Testing.

Was Soak Tests finden

Dinge, die kurze Load Tests verpassen:

• Memory Leaks. Ein Objekt, das nie garbage-collected wird, ein Buffer, der nie freigegeben wird, ein Cache, der unbegrenzt wächst. Der Heap wächst über Stunden, bis die JVM (oder Node, Go, Python) ein Limit erreicht und der Prozess stirbt.
• Connection-Pool-Drift. Datenbank- oder HTTP-Client-Verbindungspools, die eine Verbindung pro N Requests lecken, schließlich verfügbare Slots erschöpfen.
• Log-Disk-Fill. Verbose Logging frisst Disk; Produktion läuft nach Stunden aus Platz.
• Zertifikats- oder Token-Ablauf. Ein OAuth-Token, gecached für 1 Stunde; wenn nicht korrekt erneuert, scheitern alle Requests nach der Stunde.
• Langsame Cache-Eviction. Cache-Hits bleiben eine Weile hoch, fallen dann, wenn das Working Set rotiert; Performance degradiert still.
• Akkumulierende Ressourcenerschöpfung. Datenbank-Temp-Tabellen, Message-Queue-Backlogs, File Descriptors.

Wann einen Soak Test ausführen

• Pre-Major-Release. Ein neuer persistenter Service, Framework-Upgrade oder Datenbankmigration führt unbekanntes Langzeit-Verhalten ein.
• Nach Architekturänderungen. Neue Caching-Schicht, neue Message-Queue, neuer Datenbanktreiber, neuer Service-Mesh-Sidecar.
• Vierteljährlich, als Regression Check. Die meisten Teams führen Soak Tests weniger oft aus als Load Tests; vierteljährlich fängt langsame Drift zwischen Releases.
• Post-Incident. Wenn ein Ausfall durch ein langsames Leck verursacht wurde, bestätigt ein Soak Test gegen den Fix, dass das Leck weg ist.

Wichtige Soak-Test-Metriken

1. Memory-Usage-Trend über die Zeit. Heap sollte plateauisieren, nicht linear klettern. Kletternde Memory = Leak.
2. Response-Time-Perzentil-Drift. p95 bei Stunde 24 sollte p95 bei Stunde 1 entsprechen.
3. Ressourcenpool-Auslastung. DB Connection Pool, HTTP Client Pool, Thread Pool. Sollte flach bleiben, nicht klettern.
4. Fehlerrate über die Zeit. Sollte konstant bleiben. Plötzlicher Anstieg bei Stunde N = ein akkumulierendes Problem hat gerade einen Schwellenwert überschritten.

Wie einen Soak Test ausführen

Gleiche Skripte wie Load Testing, längere Dauer. In JMeter setzen Sie die Thread-Group-Dauer auf viele Stunden (24-72). In k6 konfigurieren Sie ein constant-vus-Szenario mit einer langen duration-Einstellung.

Für mehrtägige Soak Tests, bei denen das Test-Harness selbst nicht kontinuierlich auf einem Laptop laufen kann, führen Sie von LoadFocus aus. Die Cloud-Infrastruktur handhabt die langlaufende Session ohne lokale Maschinen-Beschränkungen.

Wenn Ihr Team keine Zeit hat, mehrtägige Soak-Runs einzurichten und zu überwachen, bietet LoadFocus Load Testing Services, wo Ingenieure den Soak ausführen, die Metriken überwachen und einen Bericht liefern.