Continuous Performance Testing in DevOps (JMeter, GitHub Actions, AWS)

Continuous Performance Testing (CPT) ist eine Methode des Performance Tests, bei der die Leistung von neu entwickelten Anwendungen oder Systemen automatisch und kontinuierlich überwacht und überprüft wird. CPT ermöglicht frühzeitige Erkennung von Leistungsproblemen, automatisiert Lasttests und gibt Einblick in die Leistung Ihrer Applikation oder des Systems. Um erfolgreich CPT durchzuführen, ist es wichtig, die richtigen Prozesse und Tools einzusetzen und Kenntnisse von CI/CD, DevOps und Performance Tests zu haben. Mit diesem Artikel möchte ich auch aufzeigen, wie Performance Testing sinnvoll als Teil einer CI/CD integriert werden kann und so den DevOps Ansatz unterstützt. Dazu gehe ich auch auf die Herausforderungen ein und möchte Ansätze aufzeigen, wie diese gelöst werden können.

Allgemeines zu CI/CD und DevOps

Continuous Integration und Continuous Delivery (CI/CD) sind inzwischen nichts Neues mehr. Durch die immer schneller stattfindenden Produkt-Release-Zyklen gehört es schon zum guten Ton, in einem Projekt eine CI/CD Build Pipeline zu erstellen. Denn nicht nur das reine Kompilieren des Quellcodes wird dabei durchgeführt, sondern es finden auch statische Codeanalysen und Ausführung von Unit Tests statt. Zusätzlich zu diesen entwicklungsnahen Tätigkeiten sollten jedoch auch die Qualitätssicherungsmaßnahmen ausgeführt werden, die gewöhnlich funktionale und nicht funktionale Tests umfassen. Somit kommen neben API Tests und UI Tests in einer Testautomatisierung auch nicht funktionale Testarten wie Penetration und Performance Tests immer größere Bedeutung. Denn im Idealfall können mit einer Delivery Pipeline alle notwendigen Aktivitäten bis zur Auslieferung automatisiert und gute Aussagen über die Qualität der Anwendung oder des Systems getroffen werden.

Warum soll die Performance der Anwendung regelmäßig überprüft werden?

Als Testmanager, Projektmanager oder Verantwortlicher des Produktes eines Unternehmens ist es wichtig, sicherzustellen, dass die Anwendungen, die Sie entwickeln und betreiben, zu jeder Zeit optimal funktionieren. In DevOps sind nicht nur operative Überwachungen der Anwendungen durch ein Application Performance Monitoring (APM) wichtig, sondern auch im Entwicklungszyklus in der CI/CD Pipeline müssen Maßnahmen ergriffen werden, die vor der Inbetriebnahme die Leistungsfähigkeit der Anwendung bewerten. Eine sehr sinnige Maßnahme ist deswegen, Performance Tests in die Pipeline zu integrieren. Im Gegensatz zu traditionellen Performance Tests, die nur gelegentlich durchgeführt werden, ermöglicht CPT somit die frühzeitige Erkennung von Leistungsproblemen und die Möglichkeit, schnell auf sie zu reagieren, um sie zu beheben.

Reicht es nicht aus, die Anwendungen und Systeme in Produktion zu überwachen?

Immer wieder werden wir gefragt, ob nicht das Monitoring, genauer gesagt das APM ausreicht, um genügend Informationen über die Leistungsfähigkeit zu erhalten und durch intelligente Algorithmen sogar Vorhersagen von Lastgrenzen oder Überlast zu gewinnen. Hier bin ich der Meinung, dass dies zu wenig ist, um dem Risiko langsamer Applikationen oder Systemen zu begegnen. Denn APM kann nur relativ spät - also in Produktion - die schlechten Performance Werte ermitteln. Dann kann das Kind schon in den Brunnen gefallen sein.

Unzureichende Performance kann dazu führen, dass Leistungen teuer dazugekauft werden oder gar Rollback und Backups durchgeführt werden müssen, die Ausfallzeiten und extrem hohe Kosten bedeuten. Sichern Sie sich hier besser ab und leisten Sie sich Performance Tests, die Sie in Ihre CI/CD Pipeline integrieren.

Welche Performance Testarten sind sinnvoll in einer CI/CD Pipeline?

Nicht jede Performance Testart kann sinnvoll in einer Pipeline integriert werden. Es müssen Laufzeit und Ziele passen und die Ergebnisse müssen automatisch ausgewertet werden können, damit die Pipeline einen gesicherten Status erreicht. Denn es kann nur ein Erfolgreich oder Nicht Erfolgreich für eine Pipeline geben, um diese integrierbar zu machen. Lange Auswertungen und Interpretationen sind hier nicht möglich.

Wenn ich nach ISTQB gehe, gibt es unterschiedliche Performance Testarten. Meiner Meinung nach eignen sich davon nur Lasttests und Nebenläufigkeitstest. Lasttests erzeugen die realistisch zu erwartende Last durch eine kontrollierte Anzahl von Benutzern, während Nebenläufigkeitstest gleichzeitig stattfindende Aktionen simulieren, die sich untereinander beeinflussen können. Beide Testarten können gut in einem definierten Rahmen und in einer kurzen Zeit ausgeführt werden. Andere Performance Tests wie Stresstests und Dauertests lassen sich eher nicht sinnvoll in einer CI/CD integrieren.

Image

Umsetzung im Detail

Für eine Demo setzten wir eine Pipeline mit GitHub Actions um. Hierfür war der große Vorteil für uns, dass wir durch die Nutzung der Cloud-Services keine eigene Infrastruktur bereitstellen mussten. Dennoch ist die Lösung nicht nur auf GitHub Actions beschränkt, sondern kann auch auf andere Build-Piplines bzw. Build-Tools übertragen werden, wie GitLab CI/CD, Bamboo, CruiseControl, Azure DevOps oder Jenkins.

Da die Lösung nicht ganz ohne Infrastruktur auskommt, starten wir in der Pipeline einen Docker Container auf dem die benötigten Tools, auf dem Java JVM und JMeter installiert werden. Als nächste Aktion wird ein Copy-Deployment eines vorab erstellten JMeter Projekts und der dazugehörenden Ressourcen durchgeführt. Besondere Erwähnung soll hier finden, dass wir Logindaten und Steuerungsmöglichkeiten in die GitHub Actions Secrets ausgelagert haben. Somit sind wir trotz eines vorgefertigten Szenarios imstande, die Anzahl der Threads, Laufzeit der Durchführung und weitere Parameter dem JMeter-Projekt von außen erst zur Laufzeit mitzugeben.Nun startet der eigentliche Test. Auf dem bereitgestellten Docker Container kommt das JMeter-Projekt zur Ausführung. Dieses wird in diesem Beispiel 4 Minuten ausgeführt und durchläuft das geskriptete Szenario. Dabei werden Requests gegen eine URL abgegeben und die Responses ausgewertet. JMeter selbst läuft wie gewohnt ab und sammelt alle Informationen zu den Requests in den eigenen JTL-Logs. Nach der Durchführung wird zusätzlich automatisch der JMeter HTML Report erzeugt, in dem detaillierte Graphen der Durchführung enthalten sind.
 

Image

Unterschied zu einem gewöhnlichen Performance Test

Bis hierhin unterscheiden wir uns nicht viel von einem klassischen Performance Test. Lediglich die Bereitstellung der Infrastruktur und die Ausführung wurden automatisiert. Nur wie erreichen wir das für die Pipeline notwendige Ergebnis, ob der Test ein Erfolg oder ein Fehlschlag war?

Hierzu haben wir eine ganz spezielle Assertion (Prüfung) entwickelt. Die darin enthaltene Logik analysiert den Testlauf dahingehend, ob technische Fehler bei der Ausführung vorkamen oder ob sich vorgegebene Performanz-Werte im erlaubten Bereich befanden. Die technischen Fehler sind zum einen Fehler-Requests, die aus der Applikation entstehen, z.B. unerwartet HTTP/S-Statuscodes, aber auch Informationen über die Funktionsfähigkeit des Lastagenten mit JMeter. Teilweise könnten einige Informationen direkt innerhalb von JMeter ausgewertet werden. Nur führen Probleme bei der Ausführung dazu, dass JMeter abbricht und wir keine JTL-Logs erhalten, die die bis dahin stattgefundenen Requests und Responses enthalten. Zusätzlich zu den technisch bedingten Fehlern werden in der Assertion vorgegebene Performance-Counter abgefragt, die von Außen steuerbar unterschiedliche Performanzwerte (SLAs) prüfen, beispielsweise die maximale Antwortzeit eines Requests. Hier können so ziemlich alle als Performanz-kritisch eingestuften Messwerte ausgewertet werden.
 

Image

Fazit und Zusammenfassung

In der Anwendungsentwicklung erreichen wir mit agilen Ansätzen und Continuous Delivery ungeahnte Geschwindigkeiten beim Erstellen von Funktionen und Services. Dies bedarf einer immer höheren Automatisierung, die von Quellcodeerzeugung bis zur Auslieferung in wenigen Momenten Ergebnisse liefern muss. Gerade hier müssen alle möglichen Qualitätssicherungsmaßnahmen, von funktionalen bis nicht funktionalen Tests, mit in diese schnelle Auslieferungspipeline aufgenommen werden, damit wir ein Höchstmaß an Qualität liefern können. Werden diese Tests nicht unternommen, dann hindert diese mindere Qualität den Anwender in der Anwendung oder lässt Services inkorrekt ablaufen. Dies kann nicht nur viel Geld kosten, da die Fehler in Produktion am teuersten sind, sondern auch Verlust an Reputation bedeuten und somit einen Umsatzverlust bringen. Deshalb wäre mein Rat: Lassen Sie es nicht so weit kommen. Entwickeln Sie Ihr Deployment weiter und achten Sie darauf, auch die Qualitätssicherung in Ihrer Pipeline entsprechende Mittel zukommen zu lassen, sodass Sie Risiken minimieren und finanziellen Schaden von sich fernhalten.

Wenn Sie einen besseren Einblick in eine mögliche Umsetzung erhalten möchten, sehen Sie sich einfach unser aufgezeichnetes Webinar zu diesem Thema an:

Gerne beantworten wir Ihnen Fragen und beraten Sie genauer zur Testautomatisierung in Ihrem Projekt. Kontaktieren Sie uns hierfür einfach oder vereinbaren Sie direkt einen kostenlosen Testautomatisierungs-Workshop mit unseren Qytera-Testexperten. Wir wünschen Ihnen viel Erfolg bei Ihrer Testautomatisierung!

Image