Data-Driven Testing mit SoapUI und CI-Integration über Jenkins

Einführung & SoapUI Grundlagen

Dieses SoapUI Tutorial präsentiert eine Lösung, um testdatengetriebene Schnittstellentests (Data-Driven API-Testing) mit dem Tool SoapUI durchzuführen. Wichtigstes Element der Automatisierungslösung ist ein Groovy-Script, welches in der SoapUI Groovy-Konsole ausgeführt wird.

Daten und Software sind zwei Dinge, die zwangsweise miteinander verbunden sind. Ohne korrekte und vollständige Daten arbeitet keine Software zuverlässig. Diese Erfahrung werden sicherlich schon viele Softwareentwickler, Softwaretester und am Ende die Nutzer der Software gemacht haben. Umso wichtiger ist es, ein Tool zu haben, das den Entwicklungsprozess begleiten kann und eventuellen Abweichungen schnell ans Tageslicht bringt.

Doch bevor die technischen Details erläutert werden, folgt ein kurzer Exkurs zu Erklärung von „Datengetriebenen Tests“ (Data-Driven Testing) und „SoapUI“.

Schnittstelle in SoapUI hinzufügen

Die ersten Schritte für einen Test mit einer REST-Schnittstelle sind einfach. Nach der Installation wird eine WADL-Datei in SoapUI importiert. Aus dieser Datei werden die Schnittstelleninformationen geladen. Falls der Test mit einer SOAP-Schnittstelle erfolgen soll, einfach „New SOAP Project“ auswählen.

© -

„File >> New REST Project“ der Pfad zu einer WADL-Datei angeben

Der Pfad zur WADL-Datei kann per URL oder lokal erfolgen. In dem Beispiel wird eine lokale WADL-Datei verwendet. Über den Button „Import WADL“ kann der lokale Pfad angegeben werden.

© -

Pfad eintragen >> OK

Ist die WADL-Datei geladen erstellt SoapUI ein neues Projekt.

Aufgebaut ist das Projekt wie folgt:

1. Projekt
2. Service Properties
3. Resource Properties
4. Methode Properties
5. Request Properties

In der untersten Ebene „Request Properties“ findet die Testausführung statt.

In den übergeordneten Ebenen werden die Parameter konfiguriert.

© -

Klick auf Request (multiOperator)

Der erste REST Request mit SoapUI

Ist ein Schnittstellen-Request geöffnet, wird in dem oberen Bereich Method, Endpoint und Resource angezeigt. Nach diesen Werten sortiert SoapUI die Requests (Tests) in die Ebenen ein. Der Endpoint wird in der ebene „Service Properties“ verwaltet.

Die Parameter für den Request stammen in der Regel aus der WADL-Datei.

Um einen Request auszuführen, müssen alle notwendigen Parameter an die Schnittstelle übergeben werden. Diese dienen als Grundlage der Datenverarbeitung. (Bezug Testdaten)

In dem Beispiel wird eine Rechenoperation durchgeführt. Dazu werden drei Parameter (A; B; „operator“) übergeben. Der „operator“ beinhaltet z.B. das Subtraktionszeichen. In den Parameter A, B werden Zahlen angegeben.

Die Ausführung des Request wird mit dem „Play-Button“ gestartet.

© -

Klick Play-Button

Ist die Schnittstelle erreichbar, wird in dem rechten Bereich der Response angezeigt.

Der Response liefert immer das Testergebnis, welches für die Validierung (Wahr/Falsch) herangezogen wird.

© -

Response aus Schnittstelle

SoapUI Tests anlegen & parametrisieren

Nachdem im vorherigen Teil ein Request in den Service Properties (Eigenschaften) erfolgreich ausgeführt wurde, wird im nächsten Schritt ein TestCase (Testfall) bzw. ein Positivtestfall angelegt. Hintergrund dieses Vorgehens ist, dass ein TestCase mehrere Requests einbinden kann. Somit ist es möglich, dass in einem TestCase ein Usecase (Anwendungsfall / Szenario) abgebildet wird. Requests innerhalb eines TestCases werden in SoapUI als TestRequests (Testschritt) bezeichnet.

In dem folgenden Beispiel wird ein TestCase angelegt mit zwei TestRequests, die auf einen Request referenzieren. Die beiden TestRequests verwenden unterschiedliche Testdaten.

Von dem vorhandenen Request wird über „Add TestCase“ ein neuer TestCase erstellt.

© -

Beim Generieren eines TestCases legt SoapUI eine separate Baumstruktur an. Die TestCases werden innerhalb einer Testsuite einsortiert. Es besteht die Möglichkeit später mehrere Testsuites anzulegen und so die Testfälle thematisch zu ordnen.

SoapUI legt die Ebenen TestSuite, TestCase und TestRequest an. Dafür muss in den Popups jeweils ein Name vergeben werden.

© -

Eingabe eines beliebigen Namens >> Klick OK

© -

Eingabe eines beliebigen Namens >> OK

Im letzten Schritt legt SoapUI den Request für den TestCase an. Dieser Request ist identisch mit dem bereits angelegtem Request aus den Properties (siehe Punkt 1)

© -

Eingabe eines beliebigen Namens >> Klick OK

SoapUI hat eine neue Ebene unterhalb dem Projektordner angelegt. Jetzt ist eine TestSuite mit einem TestCase und einem TestRequest angelegt.

In dieser Ebene erfolgt das Design der Tests.

© -

Klick Play-Button

Für die Benutzung dieser Schnittstelle „Operator_minus“ ist ein JSON-Request notwendig. In diesem sind Testdaten definiert durch welche der Test ausgeführt wird. Um nicht für jeden TestRequest Werte zu definieren, können in SoapUI definierte Variablen – sogenannte „Custom Properties“ – angelegt und in mehreren TestRequests angewandt werden. Dies erfolgt in den Ebenen TestCase, Testsuite und Project. Aus mehreren TestRequests kann auf die Customer Properties referenziert werden.

In diesem Beispiel werden die Testdaten auf der Ebene TestCase gespeichert.

© -

Klick auf TestCase >> Custom Properties >> Grünes Plus >> Eingabe eines Namens für die Testdaten

In dem Request wird auf die Custom Properties aus dem TestCase verwiesen.

© -

Eingabe von „${#TestCase#<<meinWert>>}“

Prüfungen der Responses (Testergebnisse)

Für eine gute Automatisierung ist es wichtig, dass für jeden angelegten TestRequest eine Prüfung des Responses (Testergebnis) erfolgt.

SoapUI bietet die Möglichkeit für jeden Response individuelle Assertions (Überprüfungen) zu definieren. Assertions können definiert werden als Contains, Matches, Counts oder HTTP Status Codes.

In dem Beispiel wird geprüft das der Status „true“ ist.

© -

Klick auf Assertions >> Grünes Plus >> Contains

© -

In das Feld „Contains“ das erwartet Ergebnis eingetragen

Nach jeder Ausführung des Request werden die Assertions geprüft. War der Test erfolgreich, färbt sich das Symbol vor dem TestRequest (Icon) sowie der Contains Eintrag grün.

© -

Der erste Testschritt ist fertig. Damit ist er parametrisiert und hat eine Assertion Prüfung. Um die Tests schnell zu erweitern ist der einfachste Weg den vorhanden TestRequest zu klonen.

© -

Klick rechte Maustaste auf TestRequest >> Clone TestStep

SoapUI verwendet in dem Menü den generischen Namen TestStep. TestStep kann in SoapUI mehrere Bedeutungen haben z.B.: TestRequest, Properties, Groovy-Script usw..

Beim Kopieren muss ein neuer Name für den TestRequest angegeben werden. Des Weiteren kann über die Dropdown-Felder der TestRequest in andere Projekte oder TestSuiten gespeichert werden.

© -

Der neu angelegte TestRequest wird inhaltlich angepasst. In dem Beispiel wird als Operator die Addition verwendet.

© -

Beide TestRequest können jetzt ausgeführt werden, um dies nicht einzeln vornehmen zu müssen, kann eine Ebene höher der TestCase gestartet werden.

In dem unteren Bereich werden die Daten zur Testausführung angezeigt.

© -

Klick auf TestCase >> Play-Button

In dem bisherigen Beispiel wurde ein positiver Test erstellt. Um zu sehen wie die Software bei Fehl- und Negativeingaben reagiert, benötigen wir einen Negativtest.

Prüfungen eines Negativtests in SoapUI

Wie folgt wird ein Positivtest in ein Negativtest umgestellt.

© -

Klick mit der rechten Maustaste auf die TestSuite >> New TestCase >> vergebe einen Namen

Jetzt hat SoapUI einen neuen, zweiten Testfall angelegt. In dem Beispiel gibt es einen Positivtestfall (TF1) und einen Negativtestfall (TF2). Über die TestSuite können zukünftig beide Testfälle sequenziell ausgeführt werden. Im nächsten Schritt wird ein TestRequest aus dem Positivtestfall in den Negativtestfall kopiert.

© -

Klick mit der rechten Maustaste auf TestRequest >> Clone TestStep

Ändern des Namens und anpassen des TestCase‘s in dem Negativtestfall via Dropdown

SoapUI fragt in dem neu geöffneten Fenster nach einem Namen für den neuen TestRequest sowie nach dessen Position in dem Projekt.

Nach dem der neue TestRequest angelegt wurde, ist es erforderlich einen Fehler darin zu erzeugen. Bei der Erzeugung von Fehlern kann der Tester kreativ werden. In dem Beispiel wird der „operator“ auf „null“ gesetzt. Die Erwartungshaltung an die Software ist, dass eine definierte Fehlermeldung über den Response angezeigt wird.

Nicht auftreten darf ein unkontrollierbares Verhalten, welches womöglich Produktivdaten preisgibt oder den Zugriff ermöglicht.

© -

Öffnen TestRequest und Zeile „operator“ ändern auf „null“

Über den Play-Button kann ein erster Test erfolgen. In der Beispielanwendung wird eine akzeptable Fehlermeldung angezeigt.

Der Status hat sich von „true“ auf „false“ geändert.

© -

Der Test ist in SoapUI wie erwartet „rot“. In den Assertions erwartet SoapUI innerhalb der TestResponse ein „true“. Damit der Negativtest  „grün“ wird, ist es erforderlich in den Assertions ein „false“ einzugeben.

© -

Klick auf „Contains“ >> ändere Contains auf „false“

Nach der Änderung wird der Negativtest „grün“, d.h. das erwartete Negativverhalten ist eingetroffen.

© -

Über die Ebene TestSuite können die beiden Testfälle ausgeführt werden.

Nach der Ausführung wird im TestSuite Log eine Liste mit den Testergebnissen angezeigt. Jeder TestRequest bzw. TestStep wird mit dem jeweiligen Status gekennzeichnet.

© -

Klick auf „TestSuite“ >> Klick Play-Button

Das Problem? Alle Testdaten sind fest in den Skripten bzw. in SoapUI selbst implementiert.

In dem gezeigten Beispiel ist es mit überschaubarem Aufwand möglich, Positiv sowie Negativtestfälle für Schnittstellentests zu erstellen. Die verwendeten Testdaten sind immer dem TestRequest oder einer anderen Ebene im Projekt gespeichert. Jeder TestRequest hat seinen  Testdatensatz bisher hard-coded in SoapUI selbst und nicht komfortabel in externen Dateien, wie z.B. CSV-files.

Bei Änderungen an den Testdaten muss somit immer eine manuelle Anpassung in SoapUI erfolgen (außer bei Verwendung der SoapUI Pro-Version, da eine automatische Importfunktion vorhanden ist).

Im Idealfall ist in den Tests eine hohe breite in der Testabdeckung anzustreben, das bedeutet alle Schnittstellen und relevanten Umsysteme eingebunden sind. Zudem ist eine angemessen hohe Tiefe in der Testabdeckung sinnvoll, mit der möglichst viele, sinnvolle Wertekombinationen getestet werden.

Die Lösung: Logische SoapUI Testfälle über Groovy Skript mit Testdaten befüllen

Um logische Testfälle mit Testdaten in SoapUI auszuführen bedarf es eines Groovy-Scripts. Eine Groovy Konsole ist in jeder SoapUI Installation vorhanden.

Der Script hat die folgende Vorgehensweise:

1. Die TestRequests sind alle mit den Eingabewerten parametrisiert
2. Auslesen einer Konfigurationsdatei in der sich die Testdaten befinden
3. Testdaten den TestRequests zur Verfügung stellen
4. TestRequests nach Vorgabe (Businesslogik) ausführen
5. TestResponses auswerten und in einen Log schreiben

Als Vorbereitung ist es notwendig die TestRequests zu parametrisieren und eine Konfigurationsdatei zu erstellen.

Das Format der Konfigurationsdatei ist immer CSV, dies hat sich aus unterschiedlichsten Gründen in den vergangenen Projekten bewährt. Um Kundenspezifischen Anforderungen gerecht zu werden, ist es möglich den Aufbau der Konfigurationsdatei anzupassen.

In der ersten Zeile „Steps“ werden die Testschritte mit einem eindeutigen Namen gekennzeichnet. Zur Vereinfachung lautet die Bezeichnung „Step<ID>“. Eine andere Bezeichnung kann ebenfalls vergeben werden. In der zweiten Excel-Zeile „API“ sind die Schnittstellennamen aus den SoapUI Request eingetragen. Schnittstellen können mehrfach aufgerufen werden. Müssen jedoch immer eine eindeutige Step-Bezeichnung haben.

© -

Beispiel: Es wird zweimal die Schnittstelle „multiOperator“ aufgerufen

Ab der dritten Zeile beginnt die eigentliche Tabelle für das Testdesign. In den ersten drei Spalten werden die Metadaten für den Testfall gespeichert. Über die Spalte „Active“ kann mit Ja/Nein definiert werden, ob der Testfall auszuführen ist. In der Spalte „Description“ können Notizen erfasst werden.

© -

Beispiel: Definition von TF1_multiOperator_vaild

Nach den Metadaten wird die Testreihenfolge sowie die Testdaten definiert. In der dritten Zeile wird zunächst sequenziell der Step angegeben. Der Step wird mit TD oder mit CV angereichert. TD steht für Test-Data und CV steht für Check-Value. Sind Testdaten (TD) zu definiert, ist ein Variablenname festzulegen. Dieser wird später im TestRequest verwendet. Das Groovy-Script stellt anhand des Namens eine Beziehung her.

© -

Beispiel: Pro Schnittstelle werden 3 Parameter plus eine Prüfung verwendet, ergibt bei 2 TestRequests (oder ‘s) 8 Spaten

Die Konfiguration für den ersten Step im Detail. Wie aus dem verwendeten Beispiel bekannt, sind drei Variablen notwendig. Die Variablen „operator“, „a“ und „b“ werden mit konkreten Daten befüllt. In der Spalte „CV“ besteht die Möglichkeit mehrere Prüfkriterien für den einzelnen TestRequest zu definieren. Es können der HTTP-Status-Code, der komplette Response oder ein bestimmter Wert geprüft werden. Die Prüfkriterien entsprechen immer dem erwarteten Ergebnis und können mit Operatoren wie größer, kleiner, größer-gleich, etc. geprüft werden. Alle Prüfkriterien werden mit einem „&&“ getrennt.

© -

Beispiel: Es soll gerechnet werden 5*5, als Ergebnis wird erwartet, http-Status 200 und das JSON-Objekt „result“ soll gleich 25 sein

Die Arbeiten an der Konfigurationsdatei sind für das erste abgeschlossen. In den nächsten Schritten wird in SoapUI eine neue TestSuite angelegt. Darin befindet sich die Testautomatisierungslösung. Dieser Schritt ist notwendig, damit die manuellen Tests von den automatisierten Tests abgegrenzt werden. Auch denkbar ist eine Aufteilung der TestSuiten nach Teststufen. Als Basis für die Testautomatisierung dient der Request „multiOperator“. Dieser wird kopiert und in einem neuen Testsuite Verzeichnis gespeichert.

© -

Klick rechte Maustaste „Request1“ >> „Add to TestCase“ >> „Create new TestSuite“ >> OK

SoapUI legt jetzt in der Baumstruktur die Ebenen TestSuite, TestCase und Request an und fragt nach dessen Namen.

© -

Eingabe von Namen für Testsuite, TestCase und Request

SoapUI hat die neuen Verzeichnisse erfolgreich angelegt.

Der Request wurde mit den JSON-Daten kopiert. Das Groovy-Script wird an dieser Stelle die Testdaten automatisch eintragen und die Testausführung starten.

© -

Erläuterung des data-driven Groovy-Script-Ablaufs in SoapUI

Das Groovy-Script wird als zusätzlichen TestStep mit in den TestCase hinzugefügt. Wird das Groovy-Script manuell oder über den TestRunner gestartet, steuert das Script selbständig wie in der Konfigurationsdatei vorgegeben den Aufruf der Schnittstellen.

Das Groovy-Script hat folgendes Vorgehen bei der Ausführung eines Tests:

1. Bericht anlegen

Jeder Testlauf wird mit einem Bericht dokumentiert. Darin sind alle relevanten Informationen zum Test aufgelistet z.B. Datum, Uhrzeit, Aufgerufene Schnittstellen, Request, Response, erwartete Ergebnisse. In dem Beispiel wird der Bericht als CSV-Datei erzeugt. Alternativ kann der Bericht als Excel, HTML oder PDF-Datei erstellt werden.

2. Konfigurationsdatei einlesen

Die CSV-Konfigurationsdatei wird vollständig ausgelesen und in Maps gespeichert. Aus den Maps werden die Daten für die Testdurchführung aufbereitet und in Custom-Properties gespeichert.

3. Start Test Run

Das Groovy-Script konfiguriert vor dem Start des Tests die TestRequest. Die Testdaten werden aus den Custom-Properties bereit gestellt. Dies geschieht vor jedem Aufruf eines TestRequests. Nur so ist gewährleistet, dass für jeden neuen TestStep eine individuelle Konfiguration geladen werden kann.

4. Auswertung Testergebnisse

Ist der Aufruf der TestRequests abgeschlossen erfolgt die Auswertung. In dem Beispiel liefert die Schnittstelle ein JSON Response. Dieser wird in einzelne Objekte zerlegt, welche mit dem erwartetem Ergebnis aus der Konfigurationsdatei (CV = CheckValue) geprüft werden. Daraus ergibt sich eine n-Anzahl von Prüfkriterien, die in Summe zu einem Testergebnis zusammen gefasst wird.

5. Schreiben Log

Optional ist es möglich jeden Request / Response in einem Log-Verzeichnis zu speichern. Die Logs beinhalten immer Rohdaten (JSON-Files) aus der Schnittstelle.

Einbinden des Groovy-Skripts in SoapUI

Das Groovy Skript selbst ist als Beispiel-Skript weiter unten in diesem SoapUI-Tutorial als Download zu finden.

© -

Klick rechte Maustaste „Test Steps“ >> „Add Step“ > „Groovy Script“

© -

Ausführung des Groovy-Skripts aus SoapUI

Ist in der Groovy-Konsole der Pfad zu der Auslagerungsdatei angegeben, kann durch Play das eigentliche Scripte in der Auslagerungsdatei ausgeführt werden.

© -

Klick Play-Button

Zur Ausführung des Scriptes wird ein Konsolen-Log angezeigt. Informationen zu einzelnen Programmschritten werden darin sichtbar.

© -

Da das Groovy-Script den Start der einzelnen TestSteps übernimmt, müssen diese für die manuelle Ausführung deaktiviert werden.

© -

Klick rechte Maustaste TestRequest >> Disable TestStep

Sind alle TestSteps deaktiviert, kann ein TestCase oder eine TestSuite gestartet werden. Die in der CSV-Konfigurationsdatei angegebenen TestSteps (Step 1 & Step 2) werden mit dem jeweiligen Status in dem TestCase Log angezeigt.

© -

Klick auf TestCase >> Play-Button

Um detaillierte Informationen über den Teststatus zu bekommen, generiert das Groovy-Script einen Bericht (in dem Beispiel in Form einer CSV-Datei), in dem alle für die Testausführung relevanten Werte aufgeführt sind. Die Berichte können auch in anderen Formaten generiert werden, z.B. in Excel, HTML oder PDF. Der Bericht baut sich wie folgt auf. In dem oberen Bereich werden Metainformationen wie Testsuite, Datum, Uhrzeit und User angezeigt. Unter den Metainformationen beginnt der Tabellenbereich mit TestCases und TestSteps.

In dem Tabellenbereich sind die Teststeps auf mehrere Zeilen verteilt. Für jeden Teststep werden Endpoints, Schnittstellen, Requests, usw. angezeigt. In dem rechten Tabellenbereich werden die Testergebnisse zu den erwarteten Ergebnissen dargestellt. In der Spalte Result befinden sich mehrere Objekte, die einzeln validiert werden. Der gesamte Teststatus für die Testsuite wird am Ende der Tabelle rechts angezeigt.

© -

In dem vorangegangenen Beispiel wurden zwei Schnittstellen mit jeweils 3 Testdaten in dem Test verwendet. Des Weiteren wurden pro Schnittstelle 2 Prüfwerte definiert. Dies war ein relativ einfaches Beispiel mit simpler Komplexität.

SoapUI Continuous-Integration mittels Jenkins

Nachdem die SoapUI Tests erfolgreich implementiert wurden, ist die Testausführung aus SoapUI heraus nun möglich.

Da in modernen Softwareentwicklungsprojekten angestrebt wird agil zu arbeiten, ist ein manueller Start der Testausführung aus einem Tool heraus sehr aufwendig oder nicht ohne weiteres möglich (z.B. Nightly-Builds). Es bietet sich der Einsatz von Continuous Integration (CI) Tools an. Neben dem Builderstellung können diese Tools auch Tests starten.

In dem Beispiel wird als Continuous Integration Tool Jenkins verwendet. Für Jenkins ist als Erweiterung das SoapUI Maven Plugin vorhanden. Damit können SoapUI-Test über Jenkins gestartet werden.

In dem folgenden Beispiel wird nicht das SoapUI Maven Plugin verwendet, sondern ein Pipline Script.

Um den Test aus dem Beispiel „mathREST“ auf den Jenkins zu starten, müssen ein paar Dinge vorbereitet werden.

In Jenkins muss als Erstes ein neues Element „Pipeline“ angelegt werden.

© -

In Jenkins „Element anlegen >> Namen Eintragen >> Pipeline >> OK

In der Konfiguration unter „Pipeline“ muss in dem Dropdown-Menü der Eintrag „Pipeline script“ ausgewählt werden. In dem Script wird ein Node definiert mit der Pfadangabe zum dem SoapUI Projekt. Bei mehreren Tests können entsprechend der Anzahl mehrere Nodes definiert werden.

© -

Pipeline script >> Node angeben >> Speichern

Bevor die Tests in Jenkins gestartet werden, müssen in dem SoapUI Projekt die angegebenen Pfade zu der Import-Datei sowie der Testresult-Datei geändert werden. In der Regel lautete der Pfad „/var/lib/jenkins/workspace/<Projekt Name>“. Im nächsten Schritt sind die Dateien in dem Jenkins Workspace zu kopieren. Zum Beispiel ist dies per WinSCP möglich.

© -

Sind die Dateien vorhanden kann der Test gestartet werden.

© -

Klick auf Jetzt bauen

Ist der Test erfolgreich wird ein blauer Kreis angezeigt.

© -

Bei der Testausführung hat SoapUI alle entstandenen Daten wie z.B. Berichte oder Logs in dem Jenkins Workspace Ordner abgelegt. Neben den SoapUI eigenen Logs wurden auch Groovy-Script internen Logs und Testprotokollierungen gespeichert. In der Jenkins Pipeline wird immer der gesamt Teststatus angezeigt. Die Übersicht über den Teststatus pro Schnittstelle ist in dem Testbericht zu finden.

© -

Klick auf Testergebnisse.csv

Groovy Skript für SoapUI Data-driven Testing als Download

Wie folgt findet ihr das in diesem Artikel beschriebene Groovy Skript als Download. Das Skript soll euch eine Hilfestellung geben, es ist weder fertige Software noch ist es in dem Zustand komplett vollständig bzw. absolut fehlerfrei. Dennoch soll euch das Skript den Einstieg in das Thema stark erleichtern. Das gleiche Skript ist auch für die Beispiele aus diesem Tutorial genutzt worden.

SoapUI_DataDriven_Tutorial_GroovyCode

Abschluss & Ausblick

Bei Fragen nutzt gerne die Kommentarfunktion unter dem Artikel. Auch Wünsche zu weiteren Erläuterungen dieses SoapUI-Tutorials oder Kritik können sehr gerne genannt werden.

Ich freue mich auf euer Feedback!