Warum Schnittstellentests notwendig sind: Case Study über SOAP UI

Warum Schnittstellentests notwendig sind!

In modernen IT-Landschaften gibt es immer mehr Anwendungen, die miteinander kommunizieren. Dabei spielt es keine Rolle, ob die Anwendungen neu entwickelt oder alte Anwendungen durch Neuentwicklungen ersetzt werden. Um die Qualität der Anwendungen und die Kommunikation mit anderen Applikationen sicher zu stellen, ist es notwendig Softwaretests frühzeitig durchzuführen. Die Kommunikation zwischen den Anwendungen findet häufig über Schnittstellen/Webservices, sogenannten API‘s, statt. Diese bieten eine hervorragende Plattform für verschiedene Tests.
Dieser Artikel soll einen Einblick geben, wie automatisierte funktionale Schnittstellentests mit SOAP UI durchgeführt werden und welchen Mehrwert diese liefern.

Vorstellung SOAP UI

Die amerikanische Firma „Smartbear“ bietet mit SOAP UI ein sehr umfangreiches API-Testwerkzeug an, mit dem eine Vielzahl von Protokollen wie z. B.: SOAP, REST, HTTP(S) JDBC, JMS und AMF getestet werden kann.

Der Hersteller bewirbt dieses Tool gern als „The Swiss Army Knife of Testing“.

SOAP UI wird in zwei Ausführungen angeboten. In der Basis-Version als Open Source Software und als Pro-Version mit zahlreichen Erweiterungen, Assistenten und Supportvertrag. Wer die Pro-Version einsetzen möchte, muss Lizenz- und Wartungskosten in sein Budget einplanen.

SOAP UI arbeitet plattformunabhängig. Als Technologie wird vollständig Java und als grafische Oberfläche (GUI) Swing eingesetzt. Neben der GUI ist es auch möglich, die Testausführung per Kommandozeile zu starten. Dies ist besonders praktisch, wenn Tests zyklisch per Scheduler gestartet werden sollen.

In der Basis-Version ist SOAP UI ein erstklassiges Tool, um schnell Testergebnisse zu erzielen.
Die ersten Schritte fallen recht leicht. Nach dem Import einer WSDL legt SOAP UI auf Wunsch gleich einen Testfall für die Schnittstellen an. Es muss nur noch ein Endpunkt, d.h. eine Adresse von dem Webservice angegeben werden und mit dem Testen kann sofort gestartet werden. SOAP UI ist so aufgebaut, dass die Testfälle (Testcases) in einer Baumstruktur eingebettet sind. Jede Ebene in der Baumstruktur hat einen spezifischen Namen. Die oberste Ebene nennt sich „Project“ danach folgenden „Testsuite“, „TestCase“, „TestSteps“ und „TestRequest“.

Auf der Ebene „TestRequest“ ist es möglich, eine Vielzahl von Aktionen, wie z.B. einen einfachen REST-Request in den Test einzubinden. Neben einen REST-Request besteht die Möglichkeit, weitere Aktionen hinzuzufügen:

• SOAP Request
• HTTP Request
• AMF Request
• JDBC Request
• Groovy Script

Groovy

Das Groovy-Projekt wurde von James Strachan und Bob McWriter 2003 geründet. Ziel war es, die Konzeption von Ruby in die Java-Umgebung zu heben. Groovy ist eine Programmiersprache und Skriptsprache, die dynamische und statische Typisierung unterstützt. Sie zählt zu den Sprachen, die auf der Java Virtual Machine (JVM) ausgeführt werden. Insofern JVM verfügbar ist, kann Grovvy auf vielen Plattformen wie z.B. Linux, Mac OS X und Windows eingesetzt werden. Groovy besitzt einige Fähigkeiten, die in Java nicht vorhanden sind. Native Syntax für Maps, Listen und Reguläre Ausdrücke.

SOAP UI Erweiterung Framework

Durch die intuitiv zu bedienende Oberfläche und die schlanke Architektur ist es unkompliziert möglich einen Test zu erstellen und durchzuführen.
Im Projektalltag liegen die Anforderungen an die Software jedoch deutlich höher. Das Tool muss schnell Daten importieren können, Testrequests mappen oder asynchrone Schnittstellen bedienen. Um diese Anforderungen zu erfüllen, kann SOAP UI erweitert werden. Durch das Einbinden von Groovy-Scripten entsteht die Möglichkeit, verschiedene wiederkehrende Testabläufe zu automatisieren und z.B. Import/Export-Funktionen einzubinden. Komfort und Funktion werden damit wesentlich erweitert.

Um vorhandene Lösungen wieder verwendbar zu machen, ist die Idee entstanden, die Lösungen zu modularisieren und in einen Baukasten zusammenzufassen. Damit ist es möglich, Testfälle oder Testsuiten aufzubauen und schnell Testergebnisse zu generieren. Das bedeutet im Konkreten:

1. Versionierung der Scripte
2. Parametrisierung von Eingabe-, Ausgabewerten sowie Prüfobjekten
3. Thematisches Zusammenfassen von Testdaten
4. Logische Verknüpfung von den Testobjekten (Schnittstelle)

Wie in der Automobilindustrie ist es mit dem Baukasten-Prinzip möglich, eine schnelle Wiederverwendbarkeit zu schaffen. Ein weiterer Vorteil ist, dass die einzelnen Module effizient miteinander kombiniert werden können. Jedes einzelne Modul stellt immer eine eigene Funktion zur Verfügung. Je nach Anforderungen, ist es möglich, die einzelnen Module für Projekte anzupassen.

In der folgenden Grafik (Bild1) ist die Modullandschaft dargestellt.

Bild 1 Case Study SOAP UI:Modullandschaft | Bildnachweis: profi.com AG business solutions

Die drei großen grauen Pfeile im Hintergrund stellen die reguläre Testausführung in SOAP UI dar. Regulär wird über die SOAP UI-Oberfläche (GUI SOAP UI) die Testausführung mit einem Request (Anforderung) an den Webservice gestartet. Anschließend liefert die Schnittstelle/Webservice eine Antwort, die in der SOAP UI-GUI angezeigt wird.

Die um diesen Ablauf gruppierten gelben Kästchen stellen die Module dar, mit denen der Testprozess erweitert werden kann.

In den nachfolgenden Beispielen wird beschrieben, wie die Verwendung der einzelnen Module praktisch erfolgen kann.

Use Case 1: Datadriven Tests

Wir stellen uns die folgende Ausgangssituation vor: In einem Projekt sollen mehrere Schnittstellen mit einer hohen Testabdeckung geprüft werden. Der Fachbereich könnte ca. 2.000 Datensätze liefern. Diese enthalten alle möglichen Kunden- und Produktkombinationen. Für den Softwaretest werden von dem Projekt keine Tools vorgeschrieben. Die Testausführung soll einmal in der Woche automatisiert erfolgen. Die ermittelten Testergebnisse sollen in einer Excel-Tabelle an das Testmanagement per E-Mail übermittelt werden.

Bild 2 Use Case 1: Relevante Module | Bildnachweis: profi.com AG business solutions

Um die Testaktivitäten durchzuführen, werden die hier in Bild 2 gelb hervorgehobenen Module „Import Testdaten“, „Datadriven“ und „Export“ verwendet.
Mit dem Ausführen des Testcases über die SOAP UI GUI erfolgt der Start der Testausführung und aller Scripte. Weitere Aktivitäten sind nicht notwendig, die Testergebnisse werden lokal gespeichert. Optional könnten die Testcases auch von einem Jenkins gestartet werden.

Bild 3 Use Case 1: Ausführung Testset | Bildnachweis: profi.com AG business solutions

Das Modul „Import Testdaten“ liest die bereitgestellten Datensätze aus einer Excel-Datei aus. Die Datensätze werden iterativ in SOAP UI Properties gespeichert.

Bild 4 Use Case 1: Excel Import Testdaten mit erwarteten Ergebnis | Bildnachweis: profi.com AG business solutions

Im Modul „Datadriven“ werden die Testdaten der Schnittstelle zugeführt. Datensatz für Datensatz wird an den Webservice übergeben. Dieser liefert die Response an das Script zurück. Die Testergebnisse werden nach Validierungsregeln geprüft. Die Validierungsregeln befinden sich, wie in Bild 4 zusehen, in der Importdatei.
Wie in dem Beispiel auf Bild 5 zu sehen ist, können für jeden Testschritt eine oder mehrere Regeln definiert werden. Optional können die Validierungsregeln auch in einer separaten Datei gespeichert werden. In dem Modul „Export“ werden die Testergebnisse aufbereitet und mit allen relevanten Informationen wie z. B. Ausführungszeitpunkt, Dauer oder Fehlerhäufigkeit gespeichert. Die Testergebnisse können in beliebigen Formaten abgespeichert werden, in Excel sind auch Formatierungen möglich.

Bild 5 Use Case 1: Excel Exportdatei | Bildnachweis: profi.com AG business solutions

Use Case 2: Der Test asynchroner Schnittstellen

In der Basisversion von SOAP UI ist das Testen von asynchronen Schnittstellen nicht möglich.
Bevor auf die technische Lösung eingegangen wird, soll erklärt werden, was der Unterschied zwischen synchronen und asynchronen Schnittstellen ist. Am häufigsten werden synchrone Schnittstellen verwendet und getestet. Dabei wird von dem User ein Request an eine Anwendung/Service übermittelt. Diese Anwendung verarbeitet den Request und gibt eine Response innerhalb kurzer Zeit an den User zurück.
Bei den asynchronen Schnittstellen erfolgt von dem Tester kein Request bzw. Aktion. Die Anwendung sendet dem Tester selbständig eine Response. Wann eine Response erfolgt, obliegt der Anwendung, z. B. wenn eine Bestellung in ein Warenwirtschaftssystem eintrifft.
Damit ein oder mehrere Responses empfangen werden können, muss in SOAP UI ein Mock-Service konfiguriert werden. Über den Mock kann SOAP UI aus dem Netzwerk Nachrichten empfangen.

Die URL könnte wie folgt aussehen:
http://nameTestPC:8088/getNameSchnittstelle

In der zu testenden Anwendung, dem Testobjekt, muss diese URL dem Endpunkt zugeordnet werden. Die Anwendung sendet die Antwort jetzt an den PC auf dem SOAP UI läuft.

Bild 6 Use Case 2: Mock mit Message Log | Bildnachweis: profi.com AG business solutions

Um die Response zu validieren, kommt ein Groovy-Script zum Einsatz. Dieses besteht aus zwei Teilen.
Der erste Teil validiert die Response nach definierten Regeln. Bei Bedarf können Teile der Response-Parametern zugeordnet werden, mit denen anschließend weiter getestet wird.
In dem zweiten Teil des Scripts wird der Anwendung eine Response zurückgesendet. Der Inhalt dieser Nachricht ist frei definierbar.

Bild 7 Use Case 2: Relevante Module | Bildnachweis: profi.com AG business solutions

In einer Logdatei können die Testergebnisse geprüft werden, welche Responses verarbeitet wurden. Die Logdatei wird immer lokal vom Script abgespeichert. Optional ist es möglich, die Testergebnisse in einer Excel darzustellen.

Bild 8 Use Case 2: Testergebnis-Log | Bildnachweis: profi.com AG business solutions

Use Case 3: Mock

Bei der Testausführung in heterogenen Testumgebungen kommt es vor, dass einzelne Anwendungen/Services nicht verfügbar sind. Gründe könnten sein, dass parallel zur Testausführung Wartungsarbeiten oder Deployments durchgeführt werden. In diesem Zeitraum ist ein Test eines z.B. End-to-End-Testfalles nicht möglich.

Bild 9 Use Case 3: Relevante Module für Modul Mock | Bildnachweis: profi.com AG business solutions

Um dennoch Testaktivitäten durchführen und zu steuern, besteht die Möglichkeit, einen Mock temporär zu verwenden. Dieses Modul arbeitet nach dem folgenden Prinzip.
Bei jeder erfolgreichen Testdurchführung schreibt das Script die Responses für den jeweiligen Testfall in eine Logdatei. Dies erfolgt immer permanent im Hintergrund bei der Testdurchführung.
Ist aus definierten Gründen die Schnittstelle nicht erreichbar, startet das Script einen Mock in SOAP UI. Anschließend wird für den Testfall der Endpunkt auf den Mock eingestellt und der Testfall wird erneut ausgeführt. Der Mock prüft in der Logdatei, ob für die Request-Parameter eine passende Response gespeichert ist.
Ist dies der Fall, sendet der Mock diesen eineindeutigen Response mit aktuellen Parametern (z.B. Datum und Uhrzeit) der Anwendung zu. Um zu verifizieren, dass es sich bei der Antwort um die des Mocks handelt, besteht die Möglichkeit z.B. den Namespace zu verändern.

Bild 10 Use Case 3: Nachricht über Start von Mock | Bildnachweis: profi.com AG business solutions

Die Testausführung kann dann weitergeführt werden. Parameter, die für den nächsten Schritt notwendig sind, können aus der Mock-Response bezogen werden.
Mit den gewonnenen Testergebnissen kann anschließend weitergetestet oder ein Export der Testergebnisse erstellt werden.

Fazit

SOAP UI bietet durch die modulare Erweiterung Vorteile bei der Erstellung der Testcases und bei der Testdurchführung. Mit dem Einsatz von Modulen ist ein kürzerer Aufbau und eine schnelle Erweiterung möglich. Des Weiteren ist eine Wiederverwendung bestehender Module gegeben. Bei optimalen Einsatz kann die Softwarequalität stetig verbessert werden.

Mit der Verwendung von einer Modullösung fallen auch ein paar Nachteile auf. Man sollte auf jeden Fall einen gewissen regelmäßigen Pflegeaufwand einkalkulieren. Bei Änderungen von Schnittstellen, Definitionen oder bei Updates von Software (Betriebssystem, Java, SOAP UI) kann es zu großflächigen Fehlern in den Testsuiten kommen.

Diese Case Study wurde durch das IT-Dienstleistungsunternehmen Proficom AG business solutions aus Dresden zur Verfügung gestellt.
Quellen: Wikipedia, Smartbear

Tobias Auerswald

Tobias Auerswald ist seit 2014 IT-Consultant bei der Proficom AG business solution, einem IT-Dienstleister im Bereich IT Qualitätsmanagement in Dresden.