Was ist Soak Testing?

Was ist Soak Testing?

Soak Testing, auch Dauertest oder Endurance Testing genannt, hält eine realistische, gleichbleibende Last über Stunden statt Minuten auf einem System. Die Frage lautet nicht, wie viel Last das System aushält, sondern ob es gesund bleibt, wenn es diese Last lange trägt. Es findet Fehler, die Stunden brauchen, um sich aufzubauen: Memory Leaks, erschöpfte Connection Pools und volllaufende Festplatten.

Beide Begriffe meinen dasselbe Vorgehen. Wie lange ein Test laufen sollte und wie man den Verlauf liest, steht im ausführlichen Leitfaden Endurance Testing (Soak Testing) im LoadFocus-Blog.

So funktioniert ein Soak Test

• Ausgangspunkt ist das Skript für die durchschnittliche Last aus Ihrem Load Test. Ein Soak Test verwendet es weiter und ändert nur die Dauer des Plateaus.
• Fahren Sie auf eine normale, erwartete Last hoch und halten Sie sie. Die k6-Dokumentation beschreibt die Last als durchschnittlich, mit Laufzeiten wie 3, 4, 8, 12, 24 oder 48 bis 72 Stunden.
• Zeichnen Sie den Verlauf auf, nicht nur die Zusammenfassung: Antwortzeit, Fehlerrate, Durchsatz, Speicher, Auslastung des Connection Pools und Festplatte, am besten auf dem Server und im Testwerkzeug.
• Vergleichen Sie die erste mit der letzten Stunde. Jede Steigung, die nicht aufhört, ist der Befund.

In k6 passt der gesamte Ablauf in wenige Zeilen:

export const options = {
  stages: [
    { duration: '5m', target: 100 },
    { duration: '8h', target: 100 },
    { duration: '5m', target: 0 },
  ],
};

Stellen Sie sich einen Dienst mit Datenbank-Connection-Pool vor. HikariCP, ein verbreiteter Java-Pool, hat standardmäßig 10 Verbindungen, und wenn keine frei ist, wartet ein Aufrufer bis zu 30 Sekunden und erhält dann eine SQLException. Gibt ein Codepfad alle paar tausend Requests eine Verbindung nicht zurück, bemerkt ein 20-Minuten-Test nichts. Acht Stunden gleichmäßige Last leeren den Pool, Requests stauen sich und schlagen dann fehl.

Was ein Soak Test findet

• Memory Leaks. Speicher, der reserviert und nie freigegeben wird, wächst, bis der Prozess beendet wird. Im Diagramm ist es eine Linie, die nie ein Plateau erreicht.
• Verbindungslecks. Datenbank- oder HTTP-Verbindungen, die geöffnet und nicht zurückgegeben werden, wie im Pool-Beispiel oben.
• Wachsende Festplatten- und Logdaten. Logs, temporäre Dateien oder Audit-Zeilen füllen ein Volume, das für einen langen Lauf nie dimensioniert wurde.
• Cache-Verschlechterung. Ein Cache, der ohne Eviction wächst oder dessen Trefferquote sinkt, wenn sich das Working Set verschiebt.
• Ablaufende Zugangsdaten. Ein gecachtes Token oder Zertifikat, das nicht korrekt erneuert wird, lässt nach dem Ablauf jeden Request scheitern.
• Geplante Jobs treffen auf Traffic. Backups und Aufräumjobs, die einmal am Tag laufen und nie unter Last beobachtet wurden.

Häufige Fehler

• Test bei Spitzenlast. Ein langer Lauf mit unrealistischer Last ist ein anderer Test. Mehr als den normalen Traffic zu fahren ist Stress- oder Kapazitätstest, und die Mischung macht das Ergebnis schwer erklärbar.
• Zu früh aufhören. Der Lauf muss mindestens einen natürlichen Zyklus des Systems umfassen, etwa einen stündlichen Batch-Job oder das nächtliche Backup.
• Nur die Zusammenfassung lesen. Ein Durchschnitt über acht Stunden verbirgt einen langsamen Anstieg. Schauen Sie auf den Verlauf über die Zeit.
• Nur die Clientseite beobachten. Das Testwerkzeug sieht langsamere Antworten. Speicher, Verbindungen und Festplatte auf dem Server zeigen die Ursache.
• Testdaten gehen aus. Wiederholen sich dieselben wenigen Nutzer und Datensätze, bleiben Caches warm und das System wirkt gesünder, als es ist.
• Jede Stufe für ein Leck halten. Ein plötzlicher Sprung passt meist zu einem Ereignis. Gleichen Sie den Zeitpunkt zuerst mit Deployments, Jobs und Log-Rotation ab.

Soak Testing im Vergleich zu verwandten Tests

• Load Testing prüft das Verhalten bei erwarteter Spitzenlast über begrenzte Zeit.
• Capacity Testing sucht die höchste Last, die das System dauerhaft trägt.
• Spike Testing trifft das System mit einem plötzlichen Ansturm und beobachtet die Erholung.
• Soak Testing ist der einzige dieser Tests, bei dem es um Zeit statt um Größe geht.

Soak Test mit LoadFocus ausführen

Schreiben Sie das Szenario in JMeter oder k6 und stellen Sie virtuelle Nutzer und Dauer im Browser auf LoadFocus ein. Die maximale Testdauer hängt vom Tarif ab: bis zu 20 Minuten bei Starter, 1 Stunde bei Basic und 5 Stunden ab Essential (loadfocus.com/pricing, Oktober 2026). Das reicht für einen kurzen Soak. Für einen Lauf über 24 oder 72 Stunden führen Sie dasselbe Skript auf eigener Infrastruktur aus und beobachten die Server-Diagramme, denn der Verlauf von Speicher, Verbindungen und Festplatte ist das Ergebnis. Die Diagnose von Memory Leaks behandelt Memory Leaks im Lasttest erkennen und beheben.

Häufige Fragen zum Soak Testing

Wie lange sollte ein Soak Test laufen?

Lange genug, um mindestens einen natürlichen Zyklus Ihres Systems zu überspannen, zum Beispiel einen stündlichen Batch-Job oder ein nächtliches Backup. Die k6-Dokumentation nennt Laufzeiten von 3 bis zu 72 Stunden. Acht Stunden sind ein üblicher erster Lauf, weil sie einen Arbeitstag abdecken.

Ist Soak Testing dasselbe wie Endurance Testing?

Ja. Beide Begriffe beschreiben, eine realistische Last lange zu halten, um Verschlechterungen zu finden, die nur mit der Zeit auftreten. Nehmen Sie den Begriff, den Ihr Team ohnehin verwendet.

Welche Last sollte ein Soak Test verwenden?

Normale, erwartete Last, nicht die Spitze. Es geht darum, was die Zeit mit dem System macht, also muss die Last etwas sein, das es tragen kann. Alles darüber ist Stresstest.

Wie sieht ein Memory Leak in einem Soak Test aus?

Der Speicher steigt den ganzen Lauf über und flacht nie ab, oft mit Antwortzeiten, die langsam schlechter werden, weil die Garbage Collection mehr arbeitet. Ein gesundes System erreicht ein Plateau.

Kann LoadFocus einen 24-Stunden-Soak-Test ausführen?

Nicht in einem einzelnen Lauf. Die längste Testdauer beträgt 5 Stunden, ab Essential. Einen längeren Soak führen Sie mit demselben JMeter- oder k6-Skript auf eigener Infrastruktur aus.