Last- und Performance-Tests mit JMeter oder Gatling

Seite 2: Gatling

Inhaltsverzeichnis

Gatling entstand vor rund sechs Jahren als Testwerkzeug für Webanwendungen mit einer eigenen Domain-Specific Language (DSL) für Testszenarien. Die technische Basis dafür sind die Programmiersprache Scala, die Aktoren-Implementierung Akka und die NIO-Client-Bibliothek Netty. Dadurch arbeitet Gatling asynchron und nichtblockierend. Als Ablaufumgebung benötigt Gatling ein JDK 8. Wegen der Verwendung von Scala ist Gatling eher etwas für Programmierer als für reine Testingenieure.

Mit dem Recorder können sie, ähnlich wie bei JMeter, die Interaktion zwischen Browser und Server über einen Proxy mitschreiben. Alternativ kann man auch mit einem anderen Werkzeug erstelltes HAR-Archiv (HTTP Archive) importieren und daraus Testszenariencode generieren. Gatling erstellt daraus eine Testklasse in Scala. Diese können Entwickler dann an ihre Bedürfnisse anpassen. Ein guter Einstieg zum Lernen sind fertige Testklassen für unterschiedliche Testszenarien. Sie kann man schnell, auch ohne tiefe Kenntnisse in Scala an seine Bedürfnisse anpassen.

Gatling-Testrecorder (Abb. 3)

Der erste Aufruf von Gatling dauert etwas, da der mitgelieferte Scala-Beispielcode noch in Java-Klassen zu übersetzen ist. Die fünf Beispiele liegen im Verzeichnis user-files\simulations\computerdatabase und werden zur Auswahl angeboten, wenn man Gatling ohne Parameter startet. Wer einen einzelnen Test starten möchte, gibt die Simulationsklasse an – zum Beispiel:

gatling.bat -s computerdatabase.advanced.AdvancedSimulationStep01

Der Testbericht im HTML-Format wird dann, wenn nicht anders spezifiziert, ins Verzeichnis results abgelegt. Den interaktiven Bericht ruft man durch das Öffnen der index.html-Datei auf.

Das Prinzip ist einfach: Entwickler erstellen eine Klasse, die von der Basisklasse Simulation erbt (class BasicSimulation extends Simulation) und setzen einzelne HTTP-Requests an die Basis-URL ab, die einem Testszenario zugeordnet sind. Zum Szenario lässt sich noch angeben, wie viel parallele Benutzer-Threads verwendet werden oder ob es eine initiale Warmlaufzeit gibt. Sollte man hinter einem Proxy sitzen, ist das der Basis-URL durch .proxy(Proxy("myProxyHost", 8080) mitzuteilen.

Um das Szenario in verschiedenen Umgebungen einsetzen zu können und die Anpassbarkeit zu erhöhen, sollten Entwickler die Werte der Parametervariablen außerhalb des Skripts pflegen. Zum Beispiel können Variablen für die Parameter aus einer CSV-Datei ausgelesen (val csvFeeder = csv("foo.csv")) werden. Ein einfacher Test der Heise-Seite sieht dann wie folgt aus:

class MySimulation extends Simulation {
val httpProtocol = http
.baseURL("https://www.heise.de/")
.inferHtmlResources()
val scn = scenario("Gatling")
.exec(http("request_0")
.get("/")
.check(status.is(200)))
setUp(scn.inject(atOnceUsers(1))).protocols(httpProtocol)
}

Die Oberfläche und die dynamischen Berichte hinterlassen einen modernen Eindruck.

Gatling-Testbericht (Abb. 4)

Zum Einstieg ist es sicherlich einfacher, entweder einen der mitgelieferten Berichte an die eigenen Bedürfnisse anzupassen oder sich einen mit dem mitgelieferten Test-Recorder erstellen zu lassen. Ein Vorteil von Gatling ist die gute Integrier- und Anpassbarkeit. Dafür gibt es nur wenige zusätzliche Erweiterungen oder tiefergehende Dokumentationen. Gatling hat den Schwerpunkt auf Webtests (HTTP, WebSockets, SSE), wenn auch wenige andere Protokolle (JMS) unterstützt werden. Weitere Nachteile sind, dass nur HTML-Berichte angeboten werden und Programmierkenntnisse in Scala nötig sind. Zwischen den Major-Versionen von Gatling kam es in der Vergangenheit, nicht nur durch Scala, immer wieder zu Änderungen, sodass ältere Tests entweder anzupassen oder neu zu erstellen sind.