Continuous Delivery mit dem richtigen Testing Tool: Unit-, Akzeptanz- und Last-/Performance-Tests

Praktiziert man Continuous Delivery, so ist es entscheidend, bei jedem neuen Build alle Softwarekomponenten vollautomatisiert zu testen. Nur so werden fehlerhafte Deployments vermieden. Für jede Testkategorie gibt es ein passendes Testing Tool.

Automatisierte Testverfahren im Umfeld von Continuous Delivery

Bei der Umsetzung von Continuous Delivery ist es wichtig, alle Komponenten bei jedem neuen Build vollautomatisiert zu testen. Dies gewährleistet einen hohen Grad an Sicherheit, so dass keine fehlerhafte Anwendung deployed wird. Dazu gibt es eine Reihe von Tools und Frameworks, die in einer Continuous-Delivery-Pipeline eingesetzt werden können. Generell lassen sich diese Tests in folgende Kategorien unterteilen: Unit-Tests, Akzeptanz-Tests, Smoke-Tests und Last-/Performance-Tests.

Die Umsetzung der Tests sollte nach dem Prinzip “Fail Fast” erfolgen. Nach jedem neuen Sourcecode-Checkin wird der gesamte Code kompiliert, und es werden alle Tests ausgeführt. Sollte die Build-Pipeline erfolgreich durchlaufen, ist somit sichergestellt, dass die fertigen Software-Artefakte vollständig getestet wurden. Dieser Vorgang läuft vollautomatisch auf einem Continuous-Integration-Server, wodurch die Hardware-Ressourcen der Entwickler-PCs geschont werden.

Folgendes Vorgehen hat sich in der Vergangenheit bewährt: In der Build-Pipeline werden Unit Tests im ersten Schritt ausgeführt, gleich nachdem die Software gebaut wurde. Sollte ein Softwaremodul Fehler aufweisen, würde der Build sofort abbrechen und einen Fehler an das Entwicklerteam melden. Für Unit Tests haben sich JUnit und TestNG im Java-Umfeld etabliert. Im zweiten Schritt wird die Anwendung auf einer Akzeptanz-Testumgebung deployed.

Bei Web-Applikationen kann mit einfachen HTTP-Requests geprüft werden, ob die Anwendung erfolgreich deployed wurde. Für solche Smoke-Tests bieten sich Scripting-Sprachen wie Perl, Shell, Groovy und Ruby an.

Im nächsten Build-Schritt werden alle Akzeptanz-Tests, die während der Anforderungsanalyse mithilfe des jeweiligen Fachbereichs dokumentiert und später vom Entwickler umgesetzt wurde, ausgeführt. Cucumber, JBehave und das Robot-Framework sind drei weit verbreitete Akzeptanz-Test-Frameworks. Als letzten Testschritt sollte auch immer sichergestellt werden, dass neue Features die Performance einer Anwendung nicht negativ beeinträchtigen. Dazu werden auch Last-/Performance-Tests duchgeführt. Durch das Definieren von Schwellwerten können Probleme bei der Performance schnell erkannt und frühzeitig von den Entwicklern behoben werden.

Continuous-Delivery-Pipeline

Commit Stage

Unit Tests

  • JUnit
  • TestNG

Acceptance Stage

Smoke-Tests

  • Shell
  • Perl
  • Ruby
  • Groovy

Acceptance Test

Akzeptanz-Tests

  • jBehave
  • Fitness
  • Selenium
  • Robot
  • Cucumber
  • Concordion

Performance Test

Performance-Tests

  • JMeter
  • loadUI

Deployment UAT

Smoke-Tests
Manuelle Tests

Deployment PROD

Smoke-Tests

Unit Tests mit jUnit

JUnit, eines der bekanntesten Unit-Test-Frameworks für Java, wurde von Kent Beck und Erich Gamma entwickelt. Mit Unit Tests werden einzelne Klassen oder Schnittstellen isoliert getestet. Abhängigkeiten zu anderen Klassen werden z. B. durch Mocks ersetzt. Dadurch sind sie robust und können schnell ausgeführt werden. Unit Tests sind zudem eine gute Dokumentation für Entwickler, um einen Einstieg in den Sourcecode zu erhalten. Wie Sie Unit Tests erstellen und einsetzen lesen Sie hier:

Akzeptanz-Tests mit JBehave

JBehave-Tests werden in Story-Dateien geschrieben. Dabei sollte eine JBehave-Story einer User Story zugeordnet werden können. Zum einen wird ein Szenario beschrieben und in der Form “Given, When, Then” formuliert (“Gegeben, Wenn, Dann”). Danach werden in einer Tabelle Testdaten hinterlegt, die beim Ausführen von JBehave verwendet werden. Durch die einfache Lesbarkeit der Akzeptanz-Tests soll es auch Nicht-Entwicklern ermöglicht werden, die Tests zu verstehen oder mit weiteren Testdaten zu erweitern.

Im Continuous Integration Server werden dann alle Statistiken zu den jBehave Tests gesammelt, siehe Abbildung:

jbehave Story Reports

Weitere Informationen zu jBehave finden Sie hier:

Smoke-Tests

Smoke-Tests sind einfache Tests zur Prüfung der Erreichbarkeit einer Anwendung, z. B. nachdem sie auf einem Server deployed wurde. Dabei werden nur rein technische Anforderungen getestet: z. B. ist der Web Server erreichbar, ist die Datenbank erreichbar usw. Dazu bieten sich Scripting-Sprachen wie Groovy, Ruby, Shell und Perl sehr gut an. Hier können mit wenig Aufwand einfache Tests geschrieben werden.

Beispiel: Das folgende Skript prüft, ob eine Webanwendung unter einer bestimmten URL aufgerufen werden kann.

httpstatus=`curl -sL -w "%{http_code} \\n"  http://<server>:8080/<web-app>/ -o /dev/null`
if [$httpstatus” == “200]
  then
        echo “Alles erfolgreich”;
  else 
	echo “Der Server ist nicht erreichbar. HTTP Status=”$httpstatus;
	exit 1;    # lässt den CI Build fehlschlagen
fi

Performance-Tests mit Apache JMeter

Mit Apache JMeter können Testpläne erstellt werden, mit denen verschiedenste Komponenten einer Applikation auf die Performance hin getestet werden können. JMeter unterstützt dazu verschiedene Protokolle, die für die Aufrufe verwendet werden können, z. B. HTTP, HTTPS, SOAP, IMAP, POP, JDBC, LDAP, usw. Bei jedem Aufruf protokolliert JMeter die Anfrage-/Antwortzeiten. Zudem ist es möglich, mehrere JMeter-Clients koordiniert zu starten, damit eine größere Last auf den Test-Servern erzeugt wird. In der folgenden Abbildung können sie die zusammengefassten Testergebnisse sehen. Sollten definierte Schwellwerte erreicht werden oder Fehler bei den Anfragen auftreten, würde der Build fehlschlagen.

Responding time jMeter Grafik   Percentage of errors jMeter Grafik

 

Weitere Informationen zu JMeter finden sie hier:

Nehmen Sie Kontakt mit uns auf.

Jetzt informieren!