SoapUI Tutorial 1: SoapUI-Grundlagen und Data-Driven-Testing

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“.

 

Datengetriebene Tests (Data-Driven Testing)

Datengetriebene Tests sind ein essenzieller Bestandteil bei der Entwicklung von komplexen Softwareentwicklungsprojekten. Ziel ist es einen automatisierten, logischen Testfall immer wieder mit unterschiedlichen Eingabewerten (Testdaten) als konkrete Testfälle auszuführen und anschließend die Testergebnisse mit den zu erwartenden Ergebnissen zu vergleichen. Mit data-driven Tests kann eine sehr hohe Tiefe in der Testabdeckung erreicht werden.

SoapUI

Um datengetriebene Schnittstellentests durchführen zu können, ist es notwendig ein Tool einzusetzen, das die Daten an einem Server oder Client sendet. Der anschließende Response (Rückmeldung bei synchronen Schnittstellen) wird für die Validierung des Testergebnisses verwendet.

In diesem Beispiel wird zum Testen der funktionalen Testautomatisierung das Tool SoapUI verwendet. SoapUI ist eins der meist verwendeten API Testwerkzeugen mit dem eine Vielzahl von Protokollen wie z.B.: SOAP, REST, HTTP(S) JDBC, JMS und AMF getestet werden kann. Der US-Amerikanische Hersteller Smartbear bewirbt seine Software gern als „The Swiss Army Knife of Testing“.

SoapUI ist eine plattform-übergreifende Anwendung, die als kostenlose Open Source Software und als Pro-Version Angeboten wird. Die Pro-Version ist kostenpflichtig und bietet zahlreiche Erweiterungen und Assistenten. Zum Beispiel ist es in der Pro-Version möglich Datenquellen anzugeben und diese für den Test zu verwenden. In den folgenden SoapUI Tutorial wird die kostenlose Open-Source SoapUI Version genutzt. Sie ist vom Funktionsumfang ausreichend.

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.

New REST Project

© -

„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.

New WADL Project

© -

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.

Request Öffnen

© -

Klick auf Request (multiOperator)

 

Wie ist die Beispiel-API aufgebaut?

In dem Beispiel geht vorrangig darum, einfache Rechenoperationen über eine REST-Schnittstelle durchzuführen.

Es kann in der Schnittstelle „multiOperator“ ein Operator (Mathematisches Zeichen z.B.: Addition, Subtraktion, Multiplikation, Division) mit jeweils zwei Zahlen bestimmt werden. Mit den Parametern wird eine Rechenoperation auf dem Server durchgeführt.

Zusätzlich gibt es eine zweite Schnittstelle „management“ mit der das Ergebnis in der Schnittstelle „multiOperator“ formatiert wird. Mit dieser Schnittstelle können Werte in einer Datenbank mittels drei Methoden angelegt, geprüft und gelöscht werden.

Mit zwei Parameter kann gesteuert werden, ob als Trennzeichen ein Punkt oder ein Komma verwendet wird und wie viele Nachkommastellen anzuzeigen sind. Ziel ist es mit dem Beispiel einen einfach zu verstehenden Testaufbau zu realisieren. Folgender Usecase (Anwendungsfall) ist möglich:

  1. Formatierung vorgeben – Berechnung durchführen (Ergebnis anhand der Formatierung validieren) – Formatierung löschen
  2. Vorhandene Formatierung prüfen – Berechnung durchführen (Ergebnis anhand der Formatierung validieren)

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.

Request geöffnet, Method, Endpoint, Recource

 

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.

Test Starten

© -

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 ansehen

© -

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.

Add TestCase

© -

 

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.

Custom TestCase

© -

Eingabe eines beliebigen Namens >> Klick OK

 

Create TestCase

© -

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)

Add Request to TestCase

© -

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.

Start Testausführung

© -

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.

Custom Properties anlegen

© -

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.

Parameter definieren

© -

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.

Add Assertions

© -

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

 

Contains Assertions

© -

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.

 

Prüfung Testergebnis anschauen

© -

 

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.

Clone TestStep

© -

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.

TestStep Name anlegen

© -

 

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

operator "+"

© -

 

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.

Start Testausführung

© -

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.

New TestCase

© -

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.

Clone TestStep

© -

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.

Ändern Variable

© -

Ö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.

 

 

Teststatus Rot

© -

 

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.

Contains „false“

© -

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

 

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

Status Grün

© -

 

Ü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.

Start Testausführung

© -

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.

Exkurs zur „sinnvollen Testabdeckung: Zur Testfallerstellung und Ermittlung der Testdaten sind Testfall-Entwurfsverfahren wie Äquivalenzklassenbildung, Grenzwertanalyse und Entscheidungstabellen sinnvoll. Damit es nicht zu einer Testfall-Expulsion kommt. Jeder Testfall und damit jeder Testdatensatz soll eine nötige Daseinsberechtigung haben und etwas abdecken, was noch kein anderer Test abdeckt.

In Projekten mit sehr vielen Schnittstellen und Testdaten wird die Handhabung der Testfälle sowie der Kombinatorik mit den Testdaten schnell sehr aufwendig.

 

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.

Ansicht Excel Tabelle

© -

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.

Ansicht Excel Tabelle

© -

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.

Ansicht Excel Tabelle

© -

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.

Ansicht Excel Tabelle

© -

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.

Select TestCase

© -

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.

Create TestSuite

© -

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.

Ansicht Testdaten

© -

 

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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

Anzeige Groovy Script

© -

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

 

Tip Groovy-Code in einem Editor bearbeiten:

Bei der täglichen Arbeit mit Groovy in SoapUI, kommt früher oder später der Wunsch nach ein paar Komfortfunktionen durch einen Editor auf. Zur Nutzung z.B. von Visual Studio Code ist die Auslagerung des Groovy-Code in eine groovy-Datei möglich. Der Pfad zu der Auslagerungsdatei wird in der SoapUI Groovy-Console angegeben.

 

Anzeige 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.

Start Testausführung

© -

Klick Play-Button

 

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

Groovy Script

© -

 

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

Disable TestStep

© -

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.

Teststatus anzeigen

© -

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.

Anzeige Excel Tabelle

© -

 

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.

Jenkins Pipeline

© -

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.

 

Jenkins Pipeline Script

© -

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.

WinSCP

© -

Sind die Dateien vorhanden kann der Test gestartet werden.

Jenkins Pipeline

© -

Klick auf Jetzt bauen

 

Ist der Test erfolgreich wird ein blauer Kreis angezeigt.

Jenkins Pipeline

© -

 

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.

WinSCP

© -

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!

 

 

 

Fanden Sie den Artikel hilfreich?
[Gesamt: 1 Durchschnitt: 5] -
Share it,
if you like it

Leave a Reply