Apache JMeter ist eine in Java geschriebene Open Source Software zum Verwalten und Ausführen von Stress- bzw. Lasttests in Client/Server-Anwendungen und bietet dafür eine übersichtliche und einfach zu bedienende Benutzeroberfläche.
Es kann genau festgelegt werden, welche Teile der Anwendungen getestet werden sollen um konkrete Ergebnisse über das Antwortzeitverhalten zu erhalten.

Was wir über JMeter lernen

Dieser Blogartikel soll ein paar grundlegende Funktionen von JMeter vermitteln. Er zeigt anhand eines konkreten Beispiels, wie man in Apache JMeter einen Testplan für eine Website erstellt. Dabei werden wir anhand von http-Requests parallel eine Vielzahl an Benutzerzugriffen simulieren und danach die Testergebnisse analysieren.
Dieses Tutorial wurde unter der Verwendung von Windows und JMeter4 verfasst. Beim Benutzen eines anderen Betriebssystems oder einer anderen Version von JMeter können sich etwaige Abweichungen (speziell bei der Installation) ergeben. Darüber hinaus wurde die deutschsprachige Version von JMeter verwendet. Ich entschuldige mich im Voraus, wenn die eine oder andere Übersetzung etwas verwirrend ist.

Vorbereitungen

Java installieren

Um die aktuelle Version von JMeter verwenden zu können, benötigen wir Java mindestens in der Version 8. Um herauszufinden welche Version auf unserem Rechner installiert ist, öffnen wir die Kommandozeile und geben den Befehl „java –version“ ein. Ist Java auf deinem Rechner nicht installiert, oder liegt lediglich eine veraltete Version vor, kannst Du die aktuelle Version von  oracle.com herunterladen.

JMeter installieren und starten

Als nächstes benötigen wird JMeter. Auf jmeter.apache.org steht es kostenlos zum Download bereit. Schließlich entpacken wir das Zip-File und speichern den Inhalt an einem beliebigen Ort. Nun ist alles vorbereitet und wir können direkt im Programm loslegen. Um dieses zu starten, öffnen wir zunächst das JMeter-Verzeichnis und den Ordner „bin“. Darin befindet sich die Datei jmeter vom Typ „Jar-File“ welche wir nun ausführen.

Grundlagen

Zunächst sehen wir uns die Programmoberfläche und ihre Komponenten etwas genauer an. Im linken Frame oben gibt es den Abschnitt „Testplan“ der mit einem Glasbehälter gekennzeichnet ist. Ein Testplan ist nichts anderes als ein Container der alle nötigen Testelemente beinhaltet. Im rechten Frame befindet sich unser eigentlicher Arbeitsbereich der uns auch Detailinformationen über die links ausgewählten Komponenten bietet.

Testkomponenten

Vor der Testplanerstellung muss Klarheit darüber herrschen, welche Komponenten für den Test benötigt werden. Die wichtigsten werden im Folgenden vorgestellt:

Thread Group

Wie es der Name schon sagt, steuert die Thread-Group die Anzahl der Threads, die JMeter zur Ausführung eines Tests verwendet. Es wird also festgelegt, wie viele virtuelle Benutzer parallel von JMeter simuliert werden sollen und wie viele Requests diese in Serie ausführen.

Sampler-Komponente

Hier handelt es sich um die eigentliche Kernfunktion von JMeter. Der Sampler simuliert Zugriffe auf verschiedenen Services. Das heißt, JMeter verschickt damit verschiedene Requests an den Server und wartet dann auf deren Antwort. Dabei muss es sich nicht zwingend um http-Requests handeln. Man kann auch FTP-Anfragen und E-Mails verschicken, Datenbanken testen, u.v.m.

Listener

Ein Listener ist eine Komponente, welche die Resultate eines Samples graphisch darstellt. Er dient zur besseren Veranschaulichung der Testergebnisse. Die Daten werden beispielsweise anhand eines Baumes, einer Tabelle, einer Grafik und dgl. visualisiert und in einer Protokolldatei gespeichert.

Assertions

Mit Assertions lässt sich herausfinden, ob jene Daten die der Server nach einem Request zurückliefert, auch wirklich mit den erwarteten Ergebnissen übereinstimmen oder nicht.

Pre-Prozessoren

Mit Pre-Prozessoren werden die Requests die man an den Server schickt, angepasst, um beispielsweise bestimmte Parameter für ein Benutzer-Login und dgl. mitzuschicken. Ein Post-Prozessor führt eine Aktion nach dem Sampler aus und verarbeitet/ extrahiert die vom Server zurückgelieferten Daten.

Timer

Ein Timer wird verwendet, um eine Wartezeit, also einen Delay zwischen zwei Samples herbeizuführen. Dies ist vor allem dann sinnvoll wenn eine Überlastung des Servers vermieden werden soll.

Controllers

Logic-Controller bestimmen die Reihenfolge in der die Sampler verarbeitet werden. Allgemein gesagt, legen diese fest, wann und wie oft JMeter etwas machen soll. Es gibt verschiedene Formen von Logic-Controllers. Der OnceOnly-Controller bewirkt die einmalige Ausführung  Der Loop-Controller führt die darin gespeicherten Samplers als Schleife mit der Anzahl der festgelegten Wiederholungen aus. Mit dem Include-Controller können externe Testpläne importiert werden.

Erstellen eines Testplans

Wir beginnen den Testplan mit der Erstellung einer Thread-Group. Mit Rechtsklick auf „Testplan / Hinzufügen / Threads / Thread Group“ fügen wir nun eine Thread Group hinzu. Die Standardeinstellungen werden wir vorerst nicht verändern.
Nun erstellen wir einen http-Request in Form eines Samplers. Dafür klicken wir rechts auf die soeben erstelle Thread-Group und wählen: „Hinzufügen / Sampler / http-Request“ aus. Als Name vergeben wir nun „MyHomePage“. Als nächstes benötigen wir die IP-Adresse oder den Link der zu testenden Seite. In diesem Tutorial testen wir die Website der Mobilen Forschungsgruppe der FH St. Pölten und beginnen dabei mit der Startseite (https://mfg.fhstp.ac.at). Wir fügen also den Link im Feld „Server-Name oder IP-Adresse“ ein, wobei das http:// zu Beginn weggelassen wird. Alle anderen Felder bleiben vorerst leer. Das Resultat sollte nun wie folgt aussehen:

Nun erstellen wir noch einen zweiten http-Request für die Unterseite „Forschung“ (https://mfg.fhstp.ac.at/category/forschung). Dabei geben wir wieder die Top-Level-Domain im Feld „Server Name oder IP“ ein. Der zweite Teil des Lins (/category/forschung) kommt in das Feld „Pfad“.

Auf dieselbe Art und Weise füge ich jetzt noch zwei weitere Requests für verschiedene Unterseiten hinzu.

Um unsere Testergebnisse grafisch zu visualisieren, benötigen wir noch einen Listener. Mit Rechtsklick auf die Threadgroup / Hinzufügen / Listeners fügen wir nun einen View-Result-Tree und eine „Result-Table“ (die Übersetzung in’s Deutsche ist hier etwas verwirrend) hinzu. Nun sollte unser Testplan in etwa so aussehen, wie auf der Abbildung unterhalb.

Somit ist unser erster kleiner Testplan vorerst fertig. Bevor wir nun in die Praxis übergehen, werden wir noch die Einstellungen in der Thread-Gruppe anpassen und übernehmen die Einstellungen wie folgt:

• Wir setzen die Anzahl der Threads auf 50. Das heißt, es werden 50 Benutzer(zugriffe) simuliert.
• Die Ramp-Up-Period stellen wir auf 100. Das ist jene Zeit, in der die volle Auslastung an Threads erreicht wird. In unserem Fall kommt also alle 2 Sekunden ein neuer Benutzer hinzu.
• Weiteres sollten zehn Wiederholungen (Loops) vorerst reichen.

Nun sind wir fertig und starten den Test per Klick auf den grünen Playbutton in der Toolbar. Nun wird der graue Button rechts oben grün. Ist der Test fertig abgearbeitet, wird er wieder grau – das kann eine Weile (~ 1 Minute) dauern.

Zusätzlich sehen wir auch die Anzahl der Benutzer die aktuell simuliert werden, sowie die Anzahl der aufgetretenen Fehler und die bisherige Laufzeit.

Betrachten der Ergebnisse

Wenn wir nun in der linken Spalte die beiden Listeners auswählen, können wir die Testergebnisse im Detail betrachten:

View Results Tree

In der nachstehenden Abbildung sehen wir in der linken Spalte die abgearbeiteten Requests und ihren Status. In unserem Fall haben alle Requests funktioniert. Das erkennen wir am grünen Icon. Im rechten Teil des Result Trees sehen wir detaillierte Informationen über die jeweiligen Requests und die Antwort des Servers, wie beispielsweise die Ladezeit, Verbindungszeit, Latenzzeit, Größe des Headers und des Bodys, http-Status, zahlreiche Metadaten u.v.m.

Im Reiter „Repsonse data“ lässt sich im Falle einer http-Anfrage sogar der gesamte Sourcecode einsehen.

Ergebnisse in der Tabelle

Deutlich weniger detailiert, dafür etwas übersichtlicher ist die Tabellenansicht.

Hinzufügen von Assertions (Überprüfungen)

Assertions gewährleisten die Korrektheit der überprüften Daten. Dies wird beispielsweise anhand von regulären Ausdrücken oder einer limitierten Antwortzeit sichergestellt. Wird die Antwortzeit überschritten, so gilt die Assertion als nicht erfüllt.

Response Assertion (Versicherte Antwort)

Um eine Assertion hinzuzufügen, klicken wir mit der rechten Maustaste auf unsere Thread Gruppe „Hinzufügen / Überprüfungen / Versicherte Antwort“. Solltest Du eine englischsprachige Version von JMeter installiert haben, so wirst du unter „Response Assertion“ fündig werden.

Wie wir im Kontextmenü sehen, gibt es noch eine Vielzahl anderer Formen von Überprüfungen.

Bei der Response Assertion liegen nun folgende Einstellungsmöglichkeiten vor.

• Mit Apply-To definieren wir den Geltungsbereich der Assertion. Die gebräuchliche Einstellung ist „Main sample only“. So wird die Assertion nur auf die Antwort des Samplers angewendet – nicht jedoch auf die Subsamples. Im Falle von http-Anfraagen beziehen sich Subsamples auf die eingebetteten Ressourcen.
• Beim Punkt „Zu testendes Antwort-Feld (Response Feld)“ legen wir fest, welchen Bereich der Antwort wir überprüfen wollen.  Hier wählen wir „Antwort-Codes“ (Response Code) aus. Wir wollen damit sicherstellen, dass die zu testenden Seiten, auch tatsächlich vorhanden sind und geliefert werden. Darum geben wir im Feld „Zu testendes Muster“ den http-Status-Code 200 ein.
• In der dritten Option wählen wir „gleich“ damit ein direkter Vergleich zwischen der Serverantwort und des eingegebenen Musters stattfindet.

Wenn wir den Test erneut ausführen, sollte sich in den Resultaten nichts ändern, da alle Seiten stets erreichbar sind.

Duration Assertion (Aufrechterhaltungs-Dauer)

Nun fügen wir eine Duration Assertion unserem Testplan hinzu. Damit bestimmen wir die maximale Antwortzeit (in Millisekunden) einer Ressource. Wird dieses Limit überschritten, so wird die Antwort als fehlgeschlagen markiert. Wir stellen die Aufrechterhaltungsdauer auf 30 Millisekunden.

Size Assertion (Größen Versicherung)

Die Size Assertion prüft die Größe der zurückgelieferten Daten. Wir fügen eine Size-Assertion hinzu, und stellen den Wert „Größe in Byte“ auf 1500. Im Bereich „Apply to“ markieren wir wieder die Radiobox „Main Sample only“ und bei „Response-Size-Field to test“ entscheiden wir uns für „Full Response“ um die gesamte Antwort zu prüfen.

Nun führen wir den Testplan erneut aus und betrachten das Ergebnis im Result-Tree. Wenn Du sie selben Ressourcen verwendet hast wie ich, sollten ebenso alle Samplers einen Fehler werfen. Wie wir aus den Testergebnissen entnehmen, hat keine einzige der vier getesteten Seiten den „Größen-Test“ da sie alle größer sind, als 1.5MB. Die Homepage selbst ist auch an der Ladezeit gescheitert.

Ich hoffe, ich konnte Dir mit diesem Tutorial einen kurzen praktischen Einblick geben und zeigen, wie man JMeter zum Testen von Webanwendungen verwendet. Du hast nun die wichtigsten Grundlagen gelernt und bist jetzt selbst in der Lage, einfache Testpläne für Websites oder -anwendungen zu schreiben.

Weiter zu Teil 2: DB, Web-Services und FTP

Weiterführende Links
https://jmeter.apache.org/usermanual/index.html