Qualitätssicherung

Auf die Plätze, fertig. Los!

Nicht nur bei Laufveranstaltungen ist racemap aktiv.

So sieht der racemap-Testplan in Apache JMeter aus.

Heute erläutern wir die Vorbereitungen zum Lasttest der racemap-App und klären die Frage: Open Source- oder Enterprise-Testwerkzeug?

Im vorherigen Beitrag haben wir euch erzählt, warum wir das junge Dresdner Startup Racemap bei der Qualitätssicherung ihrer Live-Tracking App unterstützen. In diesem Artikel werden nun die Testaktivitäten näher beleuchtet.

Wie funktioniert Racemap?
Die Racemap Tracking App ist eine Lösung zur Echtzeit-Visualisierung von Sport-Events für Zuschauer, Sportler und Veranstalter. Der Veranstalter erstellt ein Event auf der Racemap Webseite. Die Sportler melden sich mit der Smartphone App selbständig beim Event an und senden in kurzen Intervallen ihre GPS-Koordinaten an Racemap. Der Zuschauer verfolgt den Event live per Smartphone App oder am PC auf der Racemap Webseite. Im Webplayer werden die aktuellen Positionen der Sportler auf einer Karte dargestellt.

Racemap ist eine typische Client-Server-Anwendung. Es besteht also aus einem Frontend – die App bzw. der Webplayer im Browser – und einem Backend – der Webserver mit der Datenbank, wo die GPS-Daten empfangen, verwaltet und an den Webplayer versendet werden.

Was sind die Testziele und Anforderungen?
Im Dialog mit dem Racemap-Team haben wir zunächst die Ziele des Lasttests herausgearbeitet: Es geht um Performance ;-) Konkret: Wie entwickelt sich die Serverauslastung

  • bezogen auf die Anzahl der Sportler bei konstanter Zuschauerzahl und
  • bezogen auf die Zuschauerzahl bei konstanter Anzahl der Sportler?

Wir wollen also folgende Performance-Werte des Systems protokollieren und analysieren: CPU-, RAM- und Netzwerkauslastung sowie Netzwerkzugriffe und Antwortzeitverhalten. Schnelle Antwortzeiten sind essentiell für die Benutzerfreundlichkeit einer Webanwendung. Das Entwicklungsziel von Racemap ist z.B. beim Senden der GPS-Daten mit den Antwortzeiten unterhalb von 1.000 ms zu bleiben.

Testentwurf anhand eines Use Cases
Unser Lasttest soll ein reales Nutzungsverhalten von Sportlern und Zuschauern widerspiegeln. Aus den bisherigen Erfahrungen des Racemap-Teams haben wir folgenden Use Case abgeleitet:

  • Es sollen drei Events stattfinden. Ein Event läuft 24 Stunden, die beiden anderen Events laufen je 6 Stunden. Sie starten ca. 8 Stunden nachdem der 24-Stunden-Event angefangen hat, so dass für die folgenden 6 Stunden alle 3 Events parallel laufen. Dann ist die maximale Last zu erwarten.
  • An dem 24-Stunden-Event nehmen 1000 Sportler teil; 2000 Zuschauer verfolgen den Event am Webplayer.
  • An den 6-Stunden-Events nehmen jeweils 250 Sportler teil und jeweils 250 Zuschauer verfolgen die Events.

Im nächsten Schritt ist zu entscheiden, mit welchem Werkzeug die Lasttests durchgeführt werden sollen. Unsere erste Wahl im Bereich Last- und Performance-Test ist üblicher Weise HP Loadrunner. Racemap ist zwar ein aufstrebendes Startup, aber (noch) kein IT-Schwergewicht, das über die finanziellen Ressourcen verfügt, die entsprechenden Lizenzen für die benötigte Anzahl simulierter Benutzer zu erwerben. Mit der kostenlos nutzbaren Community-Edition lassen sich zwar auch sehr viele – auch proprietäre Protokolle – simulieren, aber leider nur mit bis zu 50 parallelen Nutzern. Zu wenige für das angestrebte Testszenario. Stattdessen haben wir uns für Apache JMeter entschieden, ein in Java geschriebenes Performancemessungs-Tool. Es ist freie Software, d.h. die Dokumentation sowie der Quellcode werden der Öffentlichkeit zur Verfügung gestellt, so dass jeder das Tool entsprechend seiner Anforderungen anpassen kann. Zudem müssen wir zum Testen der Racemap Lösung nur Standard Web Anfragen simulieren. Ein Protokoll das auch JMeter unterstützt.

Unsere Wahl: Apache JMeter
Ähnlich wie HP Loadrunner bietet Apache JMeter die Möglichkeit, die von einem Nutzer auf einer Webseite oder in einer Webapplikation ausgelösten Transaktionen in einem sogenannten Testplan aufzuzeichnen. Dabei ist ein Testplan nichts Anderes als ein Container, welcher alle Komponenten des Testplans beinhaltet. Weil auch mehrere Komponenten wieder Container für andere Elemente sein können entsteht daraus eine hierarchische Struktur. Ein Testplan besteht zunächst aus einer oder mehreren Thread-Gruppen, die die Benutzer simulieren. In der Thread-Gruppe lassen sich Anlauf-, Lauf- und Endphase der simulierten Benutzer anpassen. Über eine Vielzahl von Konfigurations- und Steuerungselementen lassen sich innerhalb einer Thread-Gruppe:

  • die Abarbeitung einzelner Teile eines Testplans steuern,
  • die zu testenden Objekte mit Parametern, Variablen und Funktionen versehen,
  • Timer für Pausen und Modifier zum Parsen nach Links und Formularfelder einbauen,
  • sowie eine inhaltliche Überprüfung der getesteten Objekte durchführen.

Zur Ausgabe von Ergebnissen existieren sogenannte Listener, die die Ergebnisse, die beim Testen ermittelt werden, verarbeiten und visualisieren. Darüber hinaus existiert eine Vielzahl von Plugins, mit denen sich die Standardfunktionalitäten von JMeter erheblich erweitern lassen.

In Teil 3 unserer Serie geht es ans Eingemachte und wir erläutern euch, wie die Tests ausgefallen sind, warum wir zwei Mal loslegen mussten und welche Überraschungen wir dabei erlebt haben.

Autor

Jan Sickmann IT-Consultant
Dr. Jan Sickmann