In diesem Blog möchte ich über eine Lehre aus einem meiner vergangenen Mandate berichten. Ich habe einen Kunden beim Last- und Performancetesting seiner Anwendung unterstützt. Der Kundenwunsch war es, möglichst einen verteilten Lasttest von unterschiedlichen Zugangspunkten innerhalb der Schweiz mit einer mittleren vierstelligen Anzahl Nutzer zu fahren.
Einfaches Setup eines verteilten Lasttests mit JMeter und Docker
Das Setup war recht schnell geschaffen. Als Testtool haben wir JMeter ausgewählt. Bei einem Cloudanbieter wurden mehrere virtuelle Maschinen reserviert und mittels Docker als Worker- bzw. Masternodes konfiguriert. Für den Aufbau der Infrastruktur konnte man dabei auf bereits existierende Open-Source-Docker-Images für verteilte Tests mit JMeter zurückgreifen. Die Testskripte waren auch schnell erstellt. Um ein möglichst realistisches Szenario zu testen, wurden die Skripte parametrisiert, sodass nicht einfach nur ein Request hochskaliert wurde, sondern zwischen den virtuellen Usern auch eine gewisse Varianz entsteht. Dabei wurden beispielsweise einzelne Felder im Requestbody dynamisch ersetzt, um Problemen hinsichtlich Caching und ähnlichem aus dem Weg zu gehen.
Die Testausführung zu einer Randzeit des Systems
Da der Kunde die Tests gegen seine Produktivumgebung laufen lassen wollte, wurde ein Ausführungstermin um 6:00 Uhr morgens ausgemacht. Der Kunde befürchtete, dass möglicherweise Effekte auf Produktivnutzer auftreten könnten. Diese Fehler hätte man am Morgen noch fixen könnte, bevor die ersten Kunden das System wieder nutzen wollen.
Da ich ein Typ bin, der prinzipiell erst einmal kein Vertrauen in Software hat, bis ich sie über Tests validiert habe, habe ich auch für die Lasttest-Skripte einige Tests laufen lassen. Dabei habe ich vor allem mit einer reduzierten Last von ca. 25% der zu testenden Last geprüft, dass die Skripte korrekt funktionieren und die Ersetzungen innerhalb der Requests korrekt durchgeführt werden. Da diese Tests keinerlei Anhaltspunkte für Probleme lieferten, war ich recht zuversichtlich, dass den Lasttests um 6:00 morgens nichts im Wege stehen würde.
Testbedingungen waren nicht die Realbedingungen
Am vereinbarten Termin waren dann alle Seiten in aller Frühe aufgestanden und erschienen: Sowohl ich als Tester als auch verschiedene Vertreter vonseiten des Kunden. Nach einer kurzen Einführung startete ich die Tests und es passierte … nichts. Normalerweise erscheint bei der Lasttestausführung mit JMeter auf der Kommandozeile ein fortlaufender Statusbericht mit den wichtigsten Kennzahlen. Doch dieses Mal passierte dort nichts. Nach fünf Minuten des Wartens entschloss ich mich den Run abzubrechen. Ein Blick auf die Workernodes offenbarte dann die Ursache: die Dockercontainer sind unter der zu erzeugenden Last gestorben, da die JVM nicht ausreichend Speicher zu Verfügung hatte. Nach einer Neukonfiguration des Loadgenerator-Clusters, bei dem den Dockercontainern deutlich mehr Speicher zugewiesen wurde, konnte der Test erneut gestartet werden. Und siehe da: Die Last wurde erzeugt und JMeter verhielt sich wieder wie erwartet. Der weiteren Testausführung stand also nichts mehr im Wege.
Auch bei Testskripten sollten funktionale sowie nicht-funktionale Anforderungen berücksichtigt werden
Aus dieser Episode habe ich eine Lehre gezogen: Es reicht nicht aus, nur die funktionale Korrektheit der Lasttestskripte zu prüfen, sondern man sollte auch prüfen, ob die zu generierende Last auch wirklich erzeugt werden kann. Denn nichts ist unangenehmer, als wenn man morgens um 6:00 den Kunden mitteilen muss, dass man dort wohl noch etwas übersehen hat. Damit ist dieses Learning stellvertretend für Softwareengineering im Allgemeinen: Nur funktionale Korrektheit zu prüfen reicht selten aus, auch nicht-funktionale Anforderungen sollten frühzeitig geprüft werden.
Falls Sie planen oder bereits konkreten Bedarf an Last- und Performancetesting in Ihrer Software-Entwicklung haben, dann zögern Sie nicht uns zu kontaktieren. Wir helfen Ihnen gern weiter!
In diesem Sinne: Happy Testing!
