Abstract
Die Verschlechterung der Performance einer Webanwendung kann sich sowohl auf das aktuelle als auch auf das zukünftige Verhalten von Nutzer negativ auswirken. Dies wurde in der Vergangenheit in zahlreichen Studien und Experimenten nachgewiesen. Daher ist es notwendig, zusätzlich zu den funktionalen Tests auch nicht-funktionale Tests wie Lasttests durchzuführen, um die Qualität einer Webanwendung zu gewährleisten. Eine bedeutende Rolle in der Qualitätssicherung stellt das frühzeitige Erkennen von Performance Regression dar. In Zukunft soll die Qualitätssicherung der Webanwendung von einem Unternehmen über automatisierte, tägliche Performance Regressions Tests mit einem Lasttest Tool verbessert werden.
Diese Arbeit ordnet die Themen Lasttest und Performance Regression in den Bereich des nicht-funktionalen Testens ein. Insbesondere gibt sie einen tieferen Einblick in verschiedene Methoden und Vorgehensweisen der drei wichtigsten Phasen eines Lasttests: Design der Lasten, Durchführung des Lasttests und Analyse der Ergebnisse. Eine ausgiebige Marktanalyse bewertet 26 ausgewählte Lasttest Tools unter verschiedenen Themengebieten und verschafft ein Überblick über die aktuellen Funktionen von Lasttest Tool. Die 26 Lasttest Tools umfassen ein breites Spektrum an Lösungsansätze, von kleinen Frameworks und Open Source Programmen über proprietäre, cloudbasierte Angebote bis hin zu firmeninternen Lasttest Tools. Ein Großteil der Marktanalyse ist öffentlich über GitHub einsehbar und kann als erste Orientierung für die eigene Recherche dienen.
In Absprache mit einem externen Industriepartner wird ein firmeninternes Lasttest Tool für die Realisierung automatisierter Performance Regressions Tests eingesetzt. Auf Basis der gewonnenen Erkenntnisse wird ein Konzept einwickelt und implementiert. Dieses Konzept erweitert das Lasttest Tool um ein optionales Modul für die Performance Regressions Analyse. Im Anschluss bewertet eine ausgiebige Evaluation das implementierte Konzept unter Verwendung einer Testumgebung. Anhand von vielseitigen Szenarien wird gezeigt, dass die implementierte Performance Regressions Analyse eine erste einsetzbare Problemlösung darstellt.
Ausgangslage und Forschungsfrage
Wer eine Webanwendung kontinuierlich weiterentwickelt, kennt das Problem: Funktional ist alles grün, aber die Antwortzeiten werden schleichend schlechter. Solche Performance-Regressionen fallen oft erst auf, wenn Nutzer bereits betroffen sind.
Warum das relevant ist, zeigen Untersuchungen sehr konkret: In Experimenten wurden bei künstlich hinzugefügten Verzögerungen (z. B. 400 ms) messbare Änderungen im Nutzungsverhalten beobachtet. [1] [2] Auch eine Verlangsamung im Bereich von 100 ms kann bereits spürbar sein, und längere Ladezeiten erhöhen die Wahrscheinlichkeit, dass Nutzer abbrechen. [3]
Genau deshalb ist Performance-Qualitätssicherung mehr als ein einzelner Lasttest kurz vor dem Go-live. In der Praxis entstehen Regressionen oft durch kleine Änderungen an scheinbar harmlosen Stellen: ein neues Logging, ein zusätzlicher Call, ein ungünstiger Cache-Miss. Wenn Releases häufig sind, ist es im Nachhinein schwer zu rekonstruieren, ab wann die Performance wirklich gekippt ist.
Die Arbeit, auf der dieser Beitrag basiert, setzt genau hier an. Sie fragt nicht nur: "Wie misst man Performance?" Sondern vor allem: Wie schafft man einen Ablauf, der regelmäßig läuft, Vergleichbarkeit herstellt und früh warnt, wenn ein Release die Anwendung spürbar langsamer macht?
Im Kern geht es damit um zwei praktische Leitfragen:
- Wie lassen sich Lasttests so definieren, dass sie realistische Belastungen abbilden und gleichzeitig reproduzierbar bleiben?
- Wie kann man die Ergebnisse automatisiert vergleichen, um Performance-Regressionen zuverlässig zu erkennen, ohne unnötige Abhängigkeiten mitzubelasten?