DevOps / Software-Test / Testautomatisierung

Mit Service Virtualisierung Grenzen durchbrechen

In Zeiten von Continuous Delivery und DevOps ist der Softwaretestbereich besonders gefordert. Tester und Testautomatisierer stoßen dabei schnell an, im ersten Augenblick, unüberwindbar scheinende Grenzen. Ich spreche aus Erfahrung. Rasch kommt bei Problemen mit Testdaten, Systemkonfigurationen, Systemverfügbarkeiten, Testumgebungen – um nur einige zu nennen – Frust auf. Ein kritischer Blick zeigt, dass es gar nicht so weit kommen muss. Für viele Hindernisse im Test gibt es eine einfache Lösung: die „Service Virtualisierung“.

Titelbild Grenzen durchbrechen mit Service Virtualisierung

Ziel des Blog-Beitrags ist nicht die Erklärung der Service Virtualisierung – das hat mein Kollege Ernst Binder bereits in seinen beiden Blogartikeln „Service Virtualisierung: Keine Macht der Abhängigkeit!“ sowie „Service Virtualisierung: Ich sehe was, was du nicht siehst“ sehr gut getan. Vielmehr zeige ich an Hand von Beispielen aus der Praxis, wie der Einsatz der Service Virtualisierung Grenzen durchbricht. Vielleicht finden Sie sich in der einen oder anderen Situation wieder und mein Erfahrungsbericht bringt Ihnen den entscheidenden Lösungsansatz.

 

Testdatenaufbereitung ist Schnee von gestern

Datenbanken durchsuchen, Datensätze manipulieren, ewig langes Eintippen von Testwerten und die Nachbildung von bestimmten Geschäftsfällen, sind jedem Tester bekannt und sehr oft ein Dorn im Auge. Ein viel zu großer Anteil der Testzeit wird mit solchen Tätigkeiten verbraucht, ohne einen einzigen Testfall auszuführen. Und wenn endlich ein valider, im Test verwendbarer Datensatz vorhanden ist, so wird dieser beim Testdurchlauf verändert, gelöscht oder auf andere Weise unbrauchbar gemacht. Die Aufbereitung beginnt von vorne und das für jeden Testdurchlauf.

In Services, die mit dem zu testenden System kommunizieren, werden Daten empfangen, auf diese entsprechend reagiert und schließlich mit Daten geantwortet. Mit dem Einsatz der Service Virtualisierung wird dieses Anfrage-Antwort-Verhalten simuliert, Testdaten können bereitgestellt und auch fiktiv manipuliert werden, ohne den, in der Virtualisierung berücksichtigten Datensatz real zu verändern. Damit ist eine Wiederverwendung jederzeit möglich.

Ein vereinfachtes Beispiel:

Eine Service Virtualisierung wird so erstellt, dass sie einen Kundendatensatz simuliert anlegen, sowie den gesamten Datensatz fiktiv löschen kann. Für beide Aufgaben gibt es im realen Service zwei Operationen:

  • CreateCustomer
  • DeleteCustomer

Verwendet das Testsystem im Test die Operationen in genau dieser Reihenfolge, bestehen im ersten Moment keine Probleme, wenn gegen das Echtsystem getestet wird. Wird hingegen zum Beispiel versucht über das Testsystem nur die Operation DeleteCustomer aufzurufen, so muss davor, über das Testsystem, im realen Service der Kunde erstellt werden. Dies kann sehr aufwendig sein, nur um den Kunden danach zu löschen.

Für unser System, welches wir testen, ist es im Komponententest nicht von Bedeutung ob der Kunde durch den Service wirklich gelöscht wird. Die Service Virtualisierung bietet hier eine Möglichkeit zur Simulation dieses Verhaltens. Das Testsystem kann damit DeleteCustomer aufrufen und das simulierte Service liefert die “erfolgreich gelöscht” Nachricht zurück. Diese Operation kann nun, unabhängig von anderen, beliebig oft hintereinander angesprochen werden, ohne sein Verhalten zu ändern und ohne, dass der Datensatz unbrauchbar wird. Somit bietet die Service Virtualisierung vorbereitete Testdaten gekoppelt mit einem bestimmten Verhalten.

 

Der Weg in die Freiheit

In vielen Testumgebungen werden Services eingebunden, auf die ich als Tester keinen Einfluss habe. Somit müsste ich damit leben, dass mir ein Service Owner, das Service zum Beispiel wegen Wartung deaktiviert, eine instabile Version auf meine Testumgebung einspielt oder den Service noch gar nicht (vollständig) zur Verfügung gestellt hat. All diese Abhängigkeiten kann Service Virtualisierung auflösen.

Die durch Service Virtualisierung erstellte Simulation gibt das Verhalten des Services wieder und steht für mich als Tester jederzeit zur Verfügung. Den gewünschten Zustand und die definierte Version des simulierten Services bestimme ich dabei selbst. Weiters ermöglicht die Flexibilität des dynamischen Verhaltens der Simulation, dass jeder Zeit neue Verhaltensmuster erzeugt werden, ohne zusätzlichen Aufwand auf der Service Owner-Seite. Dieser muss das echte Service nicht extra anpassen und selbst nicht speziell Rücksicht auf den Testbetrieb nehmen.

Ein vereinfachtes Beispiel:

Das zu testende System kommuniziert mit einem externen Zahlungsanbieter. Dieser hat ein Testservice, welches angesprochen werden kann. Auf Grund häufiger Ausfälle und stundenlanger Wartungsfenster ist die Benutzung stark eingeschränkt oder nicht möglich. Die Simulation dieses Services stellt die ständige, unabhängige Nutzbarkeit sicher. Zusätzlich wird die Simulation auf den speziellen Einsatz hin optimiert. Es werden Testdaten benutzt, die der Zahlungsanbieter überhaupt nicht oder nur mit großem Aufwand zur Verfügung stellt. Zusätzlich spart die Service Virtualisierung Kosten, sofern der Zahlungsanbieter die Nutzung seines Testservices pro Transaktion in Rechnung stellt.

 

Das Untestbare testen

Oft kommt es vor, dass Fehler im Produktivsystem auftreten, die in den Testumgebungen kaum oder gar nicht nachstellbar sind. Für eine solche Reproduktion der Fehlerzustände müsste die gesamte Testumgebung umgestellt, vielleicht sogar lahmgelegt werden. Die Erstellung einer Service Virtualisierung auf Basis von Service-Logs aus dem Produktivsystems, ermöglicht es, die Konstellation, die zum Fehler führt, ohne großen Aufwand als Simulation zur Verfügung zu stellen. So ist die Testumgebung weiterhin für alle Tester nutzbar und der komplexe Fehlerzustand jeder Zeit abrufbar.

Ein vereinfachtes Beispiel:

Mittels Service Virtualisierung werden die komplexen Fehlerzustände eines Produktivfehlers in den Services simuliert und für alle in den Testumgebungen zur Verfügung gestellt. Dabei wurde darauf geachtet, dass die Simulationen nur beim Kunden “Kurt Komplexerfehler” die Fehlerkonstellation erzeugen. Ein Tester, der mit der Kundin “Johanna Standardtest” testet, erhält weiterhin das fehlerfreie Standardverhalten.
Zusätzlich ist es möglich, den komplexen Fehler in automatisierten Regressionstests zu berücksichtigen und folglich den schwerwiegenden Produktivfehler bei jeder Regression abzudecken.

 

Das unbeschwerte Testen

Service Virtualisierung bietet somit eine vielseitige und nachhaltige Lösung vieler komplexer Probleme im Test- und Testautomatisierungsbereich. Simulationen durch Service Virtualisierung erzielen besonders in der Test Automation einen enormen Mehrwert, da nun viel mehr automatisierte Testszenarien und Testabläufe möglich werden, welche zuvor undenkbar waren.

Durch den Einsatz von Service Virtualisierung in weiteren Bereichen, wie Testumgebungsmanagement und Testdatenmanagement, ermöglicht eine solche Lösung nicht nur unbeschwertes Testen, sondern erleichtert auch den Weg zu ausgereiften Continuous Delivery und in weiterer Folge DevOps-Prozessen.

 

 

Passende Artikel

Kommentare gesperrt.