Stress Test in der Mobile-Entwicklung: Was es ist, Ziele und wie es durchgeführt wird

Was ist Stress Test?

Stress Test (Stresstest) ist ein Prozess zur Bewertung der Fähigkeit des Systems, unter Bedingungen zu arbeiten, die die Designspezifikationen überschreiten. Für eine mobile Anwendung könnte dies 10.000 gleichzeitige Push-Benachrichtigungen bei einer Norm von 1.000 bedeuten; für ein Backend 50.000 RPS bei erwarteten 5.000. Der Hauptunterschied zwischen Stress Test und Load Test besteht darin, dass das Ziel nicht die Bestätigung der Leistung ist, sondern die Untersuchung des Systemverhaltens über seine Auslegungskapazität hinaus. Netflix Engineering (2024) definiert Stress Test als einen Test der Hypothese, dass das System vorhersagbar ausfallen wird.

Der Stresstest umfasst zwei obligatorische Phasen: Belastung bis zum Ausfall und Beobachtung der Wiederherstellung. Wiederherstellung ist die Fähigkeit des Systems, nach dem Entfernen der Überlast zum normalen Betrieb zurückzukehren. Ein System, das sich ohne Neustart nicht erholt, gilt als zerbrechlich, selbst wenn es kurzzeitige Überlast aushält. Laut AWS Well-Architected Framework (2024) sollte die Wiederherstellungszeit nach einem Stress Test 5 Minuten nicht überschreiten.

Für mobile Clients umfasst der Stress Test die Überprüfung des Verhaltens bei erzwungener Prozessbeendigung, Netzwerktrennung und RAM-Erschöpfung. Android Low Memory Killer kann einen Hintergrundprozess bei unzureichendem RAM beenden — der Stresstest sollte überprüfen, ob die Anwendung den Zustand nach einer solchen Beendigung korrekt wiederherstellt. Apple UIKit (2024) empfiehlt, Speicherwarnszenarien auf jedem Bildschirm der Anwendung zu testen.

Ziele des Stresstests

Bestimmung des Bruchpunkts

Das erste Ziel des Stress Tests ist die Bestimmung des Bruchpunkts. Dies ist der Moment, in dem einer der wichtigsten Leistungsindikatoren einen kritischen Schwellenwert überschreitet: die p95-Antwortzeit über 10 Sekunden, die HTTP-5XX-Fehlerrate über 5% oder der Durchsatz unter 50% des Basisliniwerts. Die Aufzeichnung des Bruchpunkts ermöglicht es dem Team, die Skalierungsgrenze des Systems im Voraus zu kennen. Kapazitätsplanung stützt sich speziell auf Stress-Test-Daten, nicht auf Load-Test-Daten, da der Load Test keine Grenzbedingungen überprüft.

Überprüfung der Wiederherstellungsmechanismen

Das zweite Ziel ist die Überprüfung der Wiederherstellungsmechanismen. Nachdem die Last auf normale Werte gesunken ist, sollte das System zu den Basisindikatoren zurückkehren. Wenn der Datenbankverbindungspool nicht freigegeben wird oder der Cache nicht ungültig gemacht wird, zeigt der Stress Test dieses Problem auf. Der Unterbrechungsschalter (Hystrix, Resilience4j) sollte bei Überlast auslösen und die Verbindung nach der Stabilisierung automatisch wiederherstellen. Health-Check-Endpunkte helfen, den Zustand jedes Dienstes während des Tests zu überwachen.

Validierung der automatischen Skalierung

Das dritte Ziel ist die Validierung der automatischen Skalierung. Wenn die Infrastruktur Kubernetes oder AWS Auto Scaling verwendet, überprüft der Stress Test, ob neue Pods oder Instanzen schnell genug erstellt werden. Laut Google Kubernetes Engine (2024) sollte die Bereitstellungszeit eines neuen Pods 30 Sekunden ab dem Zeitpunkt des Auslösens der HPA-Metrik (Horizontal Pod Autoscaler) nicht überschreiten. HPA sollte auf der Grundlage von CPU, Speicher und benutzerdefinierten Metriken skalieren. Der Cluster Autoscaler fügt neue Knoten hinzu, wenn die aktuellen Knoten keine Pods aufnehmen können.

Stress Test Methodik

Allmähliche Laststeigerung (Ramp-up Stress Test) ist das häufigste Szenario. Die anfängliche Last wird auf 50% der erwarteten Last eingestellt und dann alle 2 Minuten um 10% erhöht, bis das System ausfällt. Dieses Szenario ermöglicht es, die genaue Stabilitätsgrenze zu finden. Grafana Cloud k6 (2025) empfiehlt eine Erhöhung von nicht mehr als 10% für einen glatten Antwortzeitgraphen.

Plötzlicher Lastanstieg (Spike Stress Test) — die Last steigt innerhalb von 10–30 Sekunden von 10% auf 500%. Dieses Szenario simuliert Situationen wie die virale Verbreitung von Inhalten oder DDoS-Angriffe. Der Spike Stress Test testet weniger die Leistung als vielmehr die Überlebensfähigkeit des Systems: die Fähigkeit, nicht vollständig auszufallen und nach der Stabilisierung wieder zu arbeiten. API Gateway sollte eine Ratenbegrenzung konfigurieren, um das Backend vor plötzlichen Anstiegen zu schützen.

Anhaltende Überlast (Sustained Stress Test) — das System wird für 30–60 Minuten in einem überlasteten Zustand gehalten. Dieses Szenario deckt Ressourcenlecks auf, die bei kurzen Tests nicht auftreten. Speicherlecks in Java-/Kotlin-Anwendungen sammeln sich über 20–40 Minuten intensiver Arbeit an, und nur der Sustained Stress Test erkennt sie.

Analyse des Bruchpunkts und der Wiederherstellung

Der Bruchpunkt wird anhand von drei Kriterien bestimmt: Antwortzeit, Fehlerquote und Durchsatz. Der Antwortzeitschwellenwert wird in der Regel zuerst überschritten — Anfragen beginnen länger als die festgelegte Grenze zu dauern. Dann steigt die Fehlerrate: Der Server kann die Anfragen nicht mehr bewältigen und gibt 503 zurück. Schließlich fällt der Durchsatz — das System kann nicht einmal mehr die minimale Last bewältigen. Die Bruchpunktmetrik wird im Lastprofil für die Kapazitätsplanung aufgezeichnet.

Die Wiederherstellungsanalyse umfasst drei Phasen: Sofortreaktion (erste 30 Sekunden nach Lastentfernung), Stabilisierung (1–5 Minuten) und vollständige Wiederherstellung (5–30 Minuten). In der Sofortreaktionsphase sollte die Antwortzeit unter die Baseline fallen — das System räumt die Warteschlangen. Wenn dies nicht geschieht, liegt das Problem nicht an der Last, sondern am angesammelten Zustand. Graceful Degradation — die Fähigkeit des Systems, bei Überlast Teilfunktionalität aufrechtzuerhalten — ist ein Schlüsselindikator für die architektonische Reife.

Chaos Engineering ergänzt den Stress Test durch absichtliches Einführen von Störungen: Abschalten des Datenbankservers, Netzwerkverzögerung, Anhalten eines Microservices. Chaos Monkey von Netflix (2024) beendet zufällig Prozesse in der Produktion und testet so die Belastbarkeit des Systems. Für mobile Anwendungen bedeutet Chaos Engineering das Testen von Szenarien: kein Netzwerk, API nicht verfügbar, leere Serverantwort.

Werkzeuge für Stress Test

k6 mit ramping-arrival-rate

k6 unterstützt Stress Test über das Modul `execution` mit der Konfiguration ramping-arrival-rate. Dieser Modus erhöht die Anzahl der Anfragen pro Sekunde unabhängig von der Ausführungszeit jeder Anfrage. Im Vergleich zum Load Test erfordert der Stress Test in k6 die Konfiguration aggressiverer Schwellenwerte und die Deaktivierung von gracefull-stop, um einen plötzlichen Ausfall zu simulieren. Grafana Cloud erkennt den Bruchpunkt automatisch anhand der Knickstelle im Antwortzeitgraphen. k6-operator für Kubernetes ermöglicht die Ausführung verteilter Stress Tests aus dem Cluster heraus.

JMeter mit Ultimate Thread Group

JMeter ermöglicht die Konfiguration von Stress Test über Ultimate Thread Group — ein Plugin, das das Lastprofil als Tabelle definiert: Anzahl der Threads, Aufwärmzeit, Haltezeit, Abklingzeit. Ultimate Thread Group ist praktisch für komplexe mehrphasige Szenarien. JMeter Backend Listener sendet Metriken an InfluxDB zur Darstellung des Bruchpunkts. Für den Stress Test empfiehlt JMeter, Verbindungszeitouts zu deaktivieren, um das Verhalten unter Überlast genauer zu messen.

Gremlin für Chaos Engineering

Gremlin ist eine Chaos-Engineering-Plattform für Infrastruktur-Stresstests. Gremlin ermöglicht das Abschalten des Netzwerks, das Belasten der CPU, das Füllen der Festplatte und das Beenden von Prozessen auf der Ebene einzelner Kubernetes-Pods. SRE-Teams verwenden Gremlin zusammen mit k6 für umfassende Stresstests: k6 erzeugt Last, Gremlin führt Störungen ein. Game Day — regelmäßige Stress-Test-Sitzungen mit Gremlin, die in einem Chaosbericht zur Analyse der Systembelastbarkeit dokumentiert werden.

Stress Test Beispiel mit k6

Das folgende k6-Skript demonstriert einen Stress Test mit allmählicher Laststeigerung bis zum Ausfall. Ramping-arrival-rate erhöht die Anzahl der Anfragen pro Sekunde unabhängig von der Ausführungszeit. Die Schwellenwerte sind für eine aggressive Erkennung von Verschlechterungen konfiguriert: p95 nicht mehr als 2000 ms, Fehlerrate nicht mehr als 5%. Bei Überschreitung der Schwellenwerte beendet k6 mit einem Fehlercode, wodurch der Stress Test in die CI/CD-Pipeline integriert werden kann.

import http from 'k6/http'
import check from 'k6'

export const options = {
    scenarios: {
        stress: {
            executor: 'ramping-arrival-rate',
            startRate: 50,
            timeUnit: '1s',
            stages: [
                { duration: '2m', target: 200 },
                { duration: '5m', target: 500 },
                { duration: '2m', target: 1000 },
            ],
            preAllocatedVUs: 50,
            maxVUs: 200,
        },
    },
    thresholds: {
        http_req_duration: ['p(95)<2000'],
        http_req_failed: ['rate<0.05'],
    },
}

export default function() {
    const res = http.get('https://api.example.com/health')
    check(res, {
        'status is 200': (r) => r.status === 200,
    })
}

Bewährte Praktiken für Stresstests

Beginnen Sie Stress Test auf der Staging-Umgebung — Produktions-Stresstests erfordern erweitertes Monitoring und einen Rollback-Plan. Google SRE (2024) empfiehlt, Stress Test in einer 100% isolierten Umgebung durchzuführen, die die Produktion in Architektur und Kapazität nachbildet. Nach einem erfolgreichen Test auf der Staging-Umgebung kann unter SRE-Überwachung in die Produktion gewechselt werden. Feature Flag zur Deaktivierung von Funktionalitäten bei Überlast ist obligatorisch.

Automatisieren Sie Stress Test in CI/CD für die Regressionsanalyse des Bruchpunkts. Wenn eine neue Anwendungsversion einen um 20% niedrigeren Bruchpunkt als die vorherige aufweist, handelt es sich um eine Regression, die vor der Veröffentlichung behoben werden muss. Baseline-Bruchpunkt wird in Metriken gespeichert und automatisch mit jedem Stress-Test-Ergebnis verglichen. Ein Alarm wird ausgelöst, wenn der Bruchpunkt um 10% fällt.

Dokumentieren Sie jeden Stress Test: Lastprofil, Bruchpunkt, Wiederherstellungsverhalten und Liste der entdeckten Probleme. Netflix Engineering (2024) führt Game Days durch — regelmäßige Stress-Test-Sitzungen, deren Ergebnisse in einem Chaosbericht dokumentiert werden. Der Bericht über den Stresstest sollte ein RPS-Antwortzeit-Diagramm mit markiertem Bruchpunkt enthalten.