Antwort.

Historisch wurde die Performance von Software nach dem Hauptfunktionsteil getestet – Entwickler führten entweder Skripte manuell aus oder sammelten Ergebnisse mit Tools wie JMeter. Mit dem massiven Übergang zu DevOps und CI/CD entstand der Bedarf, diese Prozesse zu automatisieren und Metriken in jeder Phase der Bereitstellung zu erhalten.

Das Problem wird dadurch erschwert, dass die Automatisierung von Lasttests nicht einfach das Ausführen fertiger Testfälle ist, sondern eine feine Abstimmung von Lastszenarien, die Wiederholbarkeit von Benutzerprofilen, die Emulation realer Netzwerke, die Berücksichtigung von Latenzzeiten und die Limitierung der Testhardware erfordert.

Die moderne Lösung besteht in der Einführung spezialisierter Werkzeuge (z. B. Gatling, Locust, k6), der Erstellung von Szenarien mit Parametrisierung von Benutzerprofilen, der Integration von Performance-Tests in CI-Pipelines, der Automatisierung der Sammlung und Analyse von Metriken sowie Alarme bei Verschlechterung der Performance.

Wichtige Merkmale:

Korrekte Anpassung von Lastszenarien (Wiederholbarkeit und näher an der Realität).
Analyse von Metriken (Trennung von Benchmarking, Stress- und Langzeitintervallen) und Automatisierung ihrer Sammlung.
Bewertung der Auswirkungen von Testergebnissen auf die Gesamtqualität der Bereitstellung und die Einhaltung von SLA.

Fragen mit einem Haken.

Ist es richtig, dass die Automatisierung von "Lasttests" nur in der Produktion zulässig ist?

Nein. Automatisierte Performance- und Stresstests können auf einer dedizierten Stage-Anwendung/Testumgebung durchgeführt werden, um die SLA nicht zu verletzen. Die Automatisierung dieser Tests ist im Gegenteil vorzuziehen, bevor sie in die Produktion gehen.

Wenn Lastautotests bestanden werden, kann man sich dann auf das reale Benutzererlebnis verlassen?

Nein – Autotests geben nur ein durchschnittliches Bild. Das Verhalten realer Benutzer kann aufgrund von Netzwerkbedingungen, verwendeten Plattformen und anderen Faktoren, die schwer eins zu eins zu emulieren sind, abweichen.

Sollte man sich nur auf die Durchschnittswerte der Antwortzeiten (Response-Zeit) konzentrieren?

Nein. Es ist extrem wichtig, Perzentile (z. B. 95., 99.) zu berücksichtigen, da Durchschnitte durch Ausreißer verzerrt sein können und gerade die Extremwerte oft den UX beeinflussen.

Typische Fehler und Anti-Patterns

Fokus nur auf einfachen Szenarien "Anmeldung/Abmeldung" ohne Emulation von Geschäftsoperationen.
Ignorieren der Analyse der schlechtesten Szenarien (Tail-Latenz).
Unzureichende Analyse von Abhängigkeiten (z. B. nicht deaktivierte externe Dienste und Rate Limits).

Beispiel aus dem Leben

Negativer Fall

Ein Unternehmen implementierte Performance-Autotests nur für den Systemzugang: Skripte führten 1000 Anmeldungen aus, analysierten die durchschnittliche Antwortzeit und glaubten, das Problem sei gelöst. Bei der ersten realen Ausführung gab es massenhaft Timeouts – es stellte sich heraus, dass parallele "schwere" Geschäftsoperationen nicht berücksichtigt wurden, die API fiel unter der Last.

Vorteile:

Schnelle Bestätigung der Funktionsfähigkeit banaler Szenarien.

Nachteile:

Ignorieren der wichtigsten Benutzerketten führte zu einem Vorfall.
Falsches Gefühl der Stabilität.

Positiver Fall

In einem anderen Team wurde das gesamte Lastprofil basierend auf der Überwachung der Produktion erstellt, einzelne Skripte emulierten die Spitzenaktivität von verschiedenen Geräten und Netzwerken. Alle Ergebnisse wurden automatisch mit einem Referenzwert verglichen, Abweichungen über 5% lösten einen Alarm aus und führten zu einer Aussetzung des Releases.