Continuous Testing – Testautomatisierung mit soapUI und Jenkins

21.06.2013

Programmiercode - Continuous TestingAutomatisiertes Testen ist für die Entwicklung von Softwarelösungen zu einer wichtigen und effektiven Möglichkeit geworden, zielstrebig Anforderungen umzusetzen. So können bspw. durch nächtliche Tests Fehler direkt aufgedeckt werden, die es dem Entwicklerteam anhand eines Fehlerberichts am darauffolgenden Tag ermöglichen, entsprechend reagieren zu können. Das automatisierte Testen ermöglicht so eine gravierende Zeitersparnis und hilft auch Projektmanagern dabei, einen stetigen Überblick zu behalten. Ein Erfahrungsbericht aus einem Kundenprojekt soll einen kleinen Überblick darüber verschaffen, wie wichtig automatisiertes Testen für die Entwicklung einer Softwarelösung geworden ist und welche Tools dafür in der Praxis benötigt werden.

Problemstellung

Im Rahmen eines Kundenprojekts aus dem Bereich Elektromobilität musste eine Backendlandschaft mit einer Vielzahl von internen und externen Schnittstellen abgesichert werden. Das bedeutet, dass sichergestellt wird, dass die Schnittstellen gemäß ihrer Spezifikation funktionieren und etwaige Abweichungen davon frühzeitig erkannt und behoben werden können.

Das Backend besteht aus mehreren Systemen und hat externe Schnittstellen auf Client-Seite zum Benutzer (User), der über mehrere Kanäle auf das Backend zugreifen kann. Zusätzlich existieren weitere Backendschnittstellen zu den einzelnen Inhalte-Anbietern (Content Providern), die über Webservices Daten liefern. Ein Inhalte-Anbieter deckt dabei ein bestimmtes Land oder eine Region ab (z.B. Europa, USA, China oder Japan). Dadurch ist die Anzahl der Inhalte-Anbieter, die abgesichert werden müssen sehr hoch.

Folgende Abbildung zeigt eine schematische Darstellung der verschiedenen Systeme:


continuous-testing_verschiedene_systeme

Bei der Mehrzahl der Backendschnittstellen handelt es sich um SOAP- oder REST-Schnittstellen. Als Datenformate werden hauptsächlich XML und JSON verwendet.

Automatisiertes Testen

Aufgrund der großen Anzahl von Schnittstellen war es aus Kosten- und Ressourcengründen nicht möglich, alle Schnittstellen manuell zu testen. Deshalb wurde die Entscheidung getroffen, die Testdurchführung automatisiert vorzunehmen. Ein Vorteil des automatisierten Testens ist die fortlaufende Auswertung der Softwarequalität. Nebeneffekte bei der Weiterentwicklung werden aufgedeckt und eine direkte Rückmeldung an die Entwickler ist dadurch möglich.

Zudem stellen die automatisch generierten Berichte einen wichtigen Input für die Projektverantwortlichen dar, die so beispielsweise bei Abweichungen vom Projektplan oder bezüglich der erwarteten Fehlerfreiheit frühzeitig informiert werden und somit rechtzeitig gegensteuern können.

Die automatisierte Testumgebung erfolgt durch ein Zusammenspiel der folgenden Werkzeuge:

  • soapUI (Tool zum Testen von SOAP- und REST-Services)
  • Subversion (Versionsverwaltung)
  • Maven (Build-Management)
  • Jenkins (Continuous Integration)

Die verwendeten Tools und deren Konfiguration werden im Folgenden näher beschrieben.

soapUI

Da es sich bei den zu testenden Backendsystem größtenteils um SOAP- und REST-Schnittstellen handelt, hat man sich für soapUI als Absicherungstool entschieden. SoapUI ist laut eigener Aussage die weltweit führende Open Source Software für das funktionale Testen von Webservices. Neben der Open Source Version gibt es auch eine stark erweiterte Pro-Version, die von der Firma SmartBear entwickelt wird. Wegen der zusätzlichen Funktionen kam bei uns die Pro-Version zum Einsatz.

soapUI Übersicht

Die Pro-Version unterstützt z.B. sogenannte Environments. Durch das Definieren mehrerer Environments lassen sich die Tests komfortabel mit anderen Endpunkten und Einstellungen ausführen. So haben wir für die verschiedenen Umgebungen Test (TEST), Integration (INT) und Produktion (PROD) eigene Environments definiert.

Auch für die verschiedenen Inhalte-Anbieter verwenden wir, sofern sie die gleiche Schnittstelle implementieren, separate Environments. Wenn man nun die Tests gegen eine andere Umgebung oder einen anderen Inhalte-Anbieter ausführen will, muss man nur an einer Stelle die Environment in soapUI ändern.

Versionsverwaltung

Da mehrere Personen an der Testentwicklung der soapUI Tests arbeiten, gab es die Anforderung, ein Versionsverwaltungssytem für die Projektdateien einzusetzen. Zu diesem Zweck wurde ein Subversion (SVN)-Repository aufgesetzt. Dadurch ist ein konfliktfreies Arbeiten möglich. Zudem lassen sich die einzelnen Änderungen der Teammitglieder leichter nachvollziehen. Der Continuous Integration Server Jenkins greift ebenfalls auf das zentrale Repository zu.

Maven soapUI Plugin

Um die soapUI Tests über eine Shell aufzurufen haben wir uns für die Verwendung des Maven soapUI Plugins entschieden. Dazu wird im Stammverzeichnis der soapUI Projekte eine pom.xml Datei erstellt, in dem die Konfiguration des Plugins erfolgt.

Um das soapUI-Plugin in Maven einbinden zu können, muss zunächst das entsprechende Plugin-Repository in die pom.xml aufgenommen werden:

<pluginRepositories>
   <pluginRepository>
      <id>eviwarePluginRepository</id>
      <url>http://www.soapui.org/repository/maven2</url>
   </pluginRepository>
</pluginRepositories>
...

Die Konfiguration des Plugins haben wir wie folgt vorgenommen:

<build>
   <plugins>
      <plugin>
         <groupId>eviware</groupId>
         <artifactId>maven-soapui-pro-plugin</artifactId>
         <version>4.5.1</version>
         <configuration>
            <projectFile>${projectFile}</projectFile>
            <testSuite>${testSuite}</testSuite>
            <testCase>${testCase}</testCase>
            <endpoint>${endpoint}</endpoint>
            <environment>${environment}</environment>
            <settingsFile>${settingsFile}</settingsFile>
            <settingsPassword>${settingsPassword}</settingsPassword>
            <printReport>true</printReport>
            <outputFolder>${basedir}/target</outputFolder>
            <junitReport>true</junitReport>
            <exportAll>true</exportAll>
            <testFailIgnore>true</testFailIgnore>
         </configuration>
         <executions>
            <execution>
               <phase>test</phase>
               <goals>
                  <goal>test</goal>
               </goals>
            </execution>
         </executions>
      </plugin>
   </plugins>
</build>

Die Parameter für das Plugin können dann bei Bedarf beim Aufruf von Maven gesetzt werden, bzw. leer gelassen werden, wenn sie nicht benötigt werden. Der Aufruf zum Ausführen der soapUI Tests mit Maven sieht dann beispielsweise so aus:

mvn -DprojectFile="MeinProjekt-soapui-project" -Denvironment="INT" clean test

Jenkins CI-Server

Jenkins ist ein System zur kontinuierlichen Integration von Softwareprojekten. Das bedeutet, dass bei Änderungen der Codebasis z.B. JUnit-Tests aufgeführt werden um die Softwarequalität einer Anwendung festzustellen. Das regelmäßige Ausführen der Tests führt so auch zu einer hohen Regressionssicherheit.

Statusreport Jenkins

Bei uns im Projekt wird der Jenkins zum Ausführen der soapUI-Tests verwendet. Dabei haben wir für jedes soapUI-Projekt und die verschiedenen Environment jeweils separate Jenkins Jobs angelegt. Auf der Statusreport-Seite für solch einen Job sieht man die Anzahl der fehlgeschlagenen Tests als Größe für die aktuelle Software-Qualität, sowie einen Trend der Testergebnisse über einen Verlauf von mehreren Tagen.

Die Tests werden nachts automatisiert ausgeführt (Nightly Builds). Dadurch werden Einflüsse z.B. durch Wartungsarbeiten an den Backend-Systemen, die normalerweise tagsüber erfolgen, minimiert. Ein weiterer Vorteil der nächtlichen Testausführung ist, dass die Entwickler und Projektleiter jeden Morgen einen aktuellen Statusreport über die Systeme vorliegen haben.

Jenkins Konfiguration

Im Grunde unterscheidet sich die Konfiguration eines soapUI Projekts auf dem Jenkins nicht besonders von einem normalen Softwareprojekt. Wir verwenden dabei sogenannte „Free Style“ Softwareprojekte. Diese Art von Jenkins-Projekten lässt sich am flexibelsten einsetzen und kann neben Softwareprojekten auch für andere Anwendungsgebiete, wie unsere soapUI Tests eingesetzt werden.

Im Abschnitt „Source-Code-Management“ wird das SVN-Repository konfiguriert, auf dem die soapUI-Projekte liegen. Neben Subversion werden auch andere Versionsverwaltungssysteme unterstützt. Unter „Build-Auslöser“ kann die Uhrzeit angegeben werden, wann der Build zeitgesteuert gestartet werden soll. Die Angabe erfolgt dabei in der Cronjob-Syntax.

Der wichtigste Punkt der Konfiguration erfolgt unter „Buildverfahren“. Hier werden die Maven Goals und die Parameter angegeben, die dem Maven soapUI Plugin beim Aufruf übergeben werden sollen.

E-Mail Reports

Für den Jenkins gibt es das email-ext Plugin mit dem beliebig konfigurierbare E-Mail Reports verschickt werden können. Dadurch erhalten sowohl die Test-Entwickler als auch die Projektmanager eine direkte Rückmeldung über den aktuellen Stand der Softwarequalität und der Backend-Systeme.

Auch in den E-Mails sieht man einen Trend der Testergebnisse ähnlich der Darstellung in der Jenkins-Benutzeroberfläche (siehe oben).

Fazit

Ohne die Möglichkeiten des Automatisierten Testens wäre die Durchführung unseres Softwareprojekts in diesem Rahmen nicht erfolgreich möglich gewesen. Die Unterstützung durch soapUI und Jenkins führte zu einer stetig verbesserten Softwarequalität im Projekt. Der Kunde hat diese Vorteile erkannt und will die Kombination aus soapUI und Jenkins nun in weiteren hausinternen Projekten einsetzen.

 

doubleSlash-Teaser-Blog_Programmierung

Zurück zur Übersicht

Ein Kommentar zur “Continuous Testing – Testautomatisierung mit soapUI und Jenkins

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

*Pflichtfelder

*