IBM ODM-Services automatisiert testen

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.

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.

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.

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.

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!