IBM ODM-Services automatisiert testen

Wissensbeitrag
Rechner mit Programmiercode

Die Relevanz von ausgiebigen Tests ist in der Softwareentwicklung unumstritten. Erst nachdem alle Funktionen der Software auf die korrekte Funktionsweise hin überprüft wurden, kann das Produkt guten Gewissens veröffentlicht werden. Der heutige Blogartikel befasst sich mit einer Möglichkeit, deployte Regelservices des IBM Operational Decision Managers automatisiert zu testen und diese Tests zu dokumentieren.

Entwicklertests

Der IBM Operational Decision Manager (kurz: ODM) bietet komfortable Möglichkeiten, die implementierten Regeln schon während der Entwicklungsphase ausgiebig zu testen. Empfehlenswert ist dabei, auf eine Kombination aus den mitgelieferten Decision Validation Services (DVS) und dem von IBM vorgestellten Ansatz DVS Made Easier zurückzugreifen.

Dazu werden sowohl mögliche Eingabewerte als auch die erwarteten Ergebnisse als Inputwerte eines ODM-Services in einer vordefinierten Excel-Datei abgelegt. Der einzige Outputwert gibt im Idealfall – also wenn alle erwarteten Ausgabewerte den berechneten Werten entsprechen – nur einen vordefinierten Text zurück, beispielsweise „Test successful“. Andernfalls enthält der Outputwert die Abweichungen zwischen den berechneten und den erwarteten Werten.

Motivation für weitere Tests

Wenn alle fachlichen Anforderungen erfüllt und durch entsprechende Entwicklertests bestätigt werden können, werden im folgenden Schritt die ODM-Regelwerke auf einen Rule Execution Server deployt, d.h. die Regelwerke sind dann als Webservice erreichbar.

Hierbei können allerdings erneut Probleme auftreten, wenn beispielsweise verschiedene Regelwerke ineinander greifen und benötigte Regelprojekte nicht oder fehlerhaft deployt wurden. Um dies auszuschließen, müssen nun also die Webservices getestet werden. Dazu bietet sich an, die bereits für den ersten Schritt erstellte Excel-Datei zu verwenden. Der Webservice selbst kann dabei über Tools wie SoapUI angesteuert werden.

SoapUI-Scripting zur Testunterstützung

Zusätzlich zur Möglichkeit, Soap-Requests mit SoapUI abzuschicken und die Antwort (Soap-Response) zu analysieren, bietet SoapUI die Fähigkeit, Groovy-Scripts auszuführen. Mit Hilfe von SoapUI, Groovy und entsprechenden Bibliotheken kann man automatisiert mehrere Soap-Requests hintereinander absetzen und dabei immer wieder auf die Daten einer Excel-Datei zugreifen.

Genau das nutzen wir, um unsere für die Entwicklertests definierten Szenarien erneut zu testen – nur diesmal nicht lokal, sondern mit dem ODM-Webservice. Dazu werden zunächst sämtliche Eingabewerte des Soap-Requests durch Variablen ersetzt. Diese Variablen können durch sogenannte Properties in Soap-UI automatisch befüllt werden.

Um nun diese Properties für jedes Szenario korrekt zu befüllen, nutzt man eine Excel-Bibliothek, die mit Hilfe von Groovy die bestehende Excel-Datei zeilenweise ausliest und jeweils die Werte in die Properties hineinschreibt. Da wir aufgrund unseres DVS Made Easier-Ansatzes immer denselben Outputwert erwarten, und dieser von SoapUI direkt überprüft werden kann, lassen sich unsere Tests nun automatisiert ausführen.

Automatisierter Test aller Szenarien

Nach einer initialen Analyse, welche Variablen benötigt werden, wird nun eine Schleife ausgeführt, bestehend aus den Schritten „nächstes Szenario aus Excel-Datei lesen“, „Properties in SoapUI setzen“, „Soap-Request absetzen“, „Soap-Response analysieren“.

Diese Schleife kann außerdem um weitere Funktionen ergänzt werden. Sinnvoll kann unter anderem sein, alle Requests und Responses in einer externen Datei abzulegen, um im Nachhinein alle durchgeführten Tests noch einmal nachvollziehen zu können. Dies lässt sich ebenfalls mit Hilfe von Groovy realisieren.

Fazit

Durch dieses Verfahren haben wir die Möglichkeit, mit wenigen Schritten ein Testverfahren zu implementieren, das die bereits bestehenden Testszenarien nutzt. So können wir im nächsten Schritt unserer ODM-Entwicklung, der Bereitstellung von Webservices, unsere Szenarien automatisiert testen. Diese Schritte lassen sich dabei so allgemein implementieren, dass neue ODM-Webservices fast ausschließlich durch Copy & Paste um ein solches Testverfahren ergänzt werden können. Die Dokumentation der Tests erfolgt dabei im gleichen Schritt, was eine enorme Aufwandsersparnis ermöglicht.

Haben Sie dazu weitere Fragen? Interessieren Sie sich für eine solche Implementierung für Ihre Regelservices? Wir beraten Sie gerne!

Autor

Maximilian Lorse
X-INTEGRATE Software & Consulting GmbHKontakt