© Excellent backgrounds/Shutterstock.com
Realistische Belastungsprofile für Webapplikationen

Lasttests mit Selenium


Häufig werden Lasttests so verstanden, dass eine Vielzahl unterschiedlicher Anfragen unkoordiniert an einen Server gesendet wird. In diesem Zustand kann beobachtet werden, wie sich ein System während einer Extremauslastung verhält und wo dessen Grenzen liegen. Wenn ein System asynchrone Vorgänge startet, die einen erheblichen Teil der Systemauslastung ausmachen, können Kennzahlen aus solchen Lasttests nur wenige Erkenntnisse enthalten. In diesem Fall ist es interessant, wie sich ein System unter hoher, aber realistischer Belastung verhält. Der folgende Artikel berichtet über die Erfahrungen aus einem Projekt, das dieser Frage nachgegangen ist.

In unserer Abteilung wurde in den letzten Monaten eine Webapplikation zur Modernisierung eines etablierten Softwaresystems für den Datentransport entwickelt. Das vorhandene System basiert auf einer Rich-Client-/Server-Architektur mit zwei Serverkomponenten. Neben einem Applikationsserver existiert ein eigener Dateiserver, der eine verteilte Persistierung von Dateien ermöglicht. Der Zugriff auf beide Server erfolgt mit einem proprietären HTTP-basierten Protokoll. Die Webapplikation ist mit Googles JavaScript-Framework AngularJS implementiert. Zwischen der Webapplikation und dem bestehenden Applikationsserver vermittelt ein Apache Tomcat, der sich um TLS, WebSocket, Authentifizierung und das Session Handling kümmert. Er nimmt die Anfragen der Webapplikation an, reicht sie – soweit autorisiert – an den Applikationsserver weiter und vermittelt die Antwort.

Es liegt in der Natur einer Single Page Application (SPA), dass keine großen HTML-Seiten auf einem Server erstellt werden. Stattdessen werden genau die Daten nachgeladen, die der Benutzer gerade sehen möchte. Es werden Templates/Scripts nachgeladen und zyklische Aktualisierungen durchgeführt. Gleichzeitig findet die Kommunikation mit den bestehenden Rich Clients statt. Ein Teil der Anfragen kann z. B. durch Minifizierung und Einbettung von Templates verhindert werden. Das Grundproblem jedoch bleibt: Das Belastungsprofil der bestehenden Systeme ändert sich erheblich, und diese Auswirkungen sollten in einem Lasttest untersucht werden.

Klassische Belastungstests

Für einen klassischen Belastungstest werden unterschiedliche Anfragen zusammengestellt, die in hoher Frequenz an einen Server gesendet werden. Bei diesen Anfragen handelt es sich um API-Aufrufe auf der Serverseite, die im normalen Betrieb von einem Client (in unserem Fall die SPA) aufgerufen werden. Sinnvollerweise werden die Antwort und die Antwortzeit gegen einen definierten Toleranzbereich geprüft. Warum kann mit diesem Vorgehen kein realistisches Belastungsprofil generiert werden?

  • Das Verhalten einer SPA in einem Browsers muss nachgebildet werden: Zunächst lädt der Browser die SPA (statische Dateien), anschließend lädt diese selbst Dateien nach und beginnt, mit dem Server zu kommunizieren. Hier müssen Reihenfolgen und zeitliche Faktoren berücksichtigt werden.

  • Die Verweildauer eines echten Benutzers variiert.

  • Der Browser wird bei erneuten Besuchen statische Dateien aus dem Cache laden oder lediglich HEAD-Anfragen senden, um den Cache-Inhalt zu validieren.

  • Zur Simulation von Szenarien und mehreren Benutzern müssen Sessions verwaltet werden.

  • Falls das zu testende System asynchrone Vorgänge startet, müssen diese so ausgelöst werden, wie es im echten Betrieb der Fall wäre.

  • Änderungen des Server-API müssen sich in den Testfällen widerspiegeln.

Die Schwierigkeiten mit diesem Vorgehen können auf zwei Ursachen zurückgeführt werden: Es muss das Verhalten des Benutzers (Verweilzeiten, Sessions, asynchrone Vorgänge) und des Browsers (Ladereihenfolgen, Cache) nachgebildet werden. Es wird deutlich, dass es nahezu unmöglich ist, ein realistisches Belastungsprofil mit diesem Vorgehen zu generieren. Aus diesem Grund habe ich ein anderes Vorgehen gewählt, mit dem zusätzlich das GUI in den Test einbezogen wird.

Selenium und Protractor

Selenium ist ein Werkzeug für die Browserautomatisierung. Da e...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang