Migrationstest: Das neue System muss tun, was das alte tat

Wie testet man eine Legacy-System-Migration?

Ein Migrationstest prüft, ob das migrierte System genau das tut, was vorher das Altsystem getan hat. Eine Anforderungsspezifikation oder ein Designmodell als Testgrundlage gibt es bei einer Softwaremigration im Regelfall nicht, deshalb passen anforderungs- und modellbasierte Testansätze hier nicht. An ihre Stelle tritt das Altsystem als Testorakel: Was es mit einer bestimmten Eingabe macht, ist das erwartete Ergebnis. Als Testkriterium gilt die vollständige funktionale Gleichheit von Alt- und migriertem System.

Praktisch heißt das: Die Tester zeichnen auf, wie sich das alte System in der Produktion verhält, spielen dieselben Transaktionen gegen das neue System ab und vergleichen die Ausgaben automatisch, Bildschirm für Bildschirm, Tabelle für Tabelle, Report für Report. Die Codeabdeckung zeigt, wann genug getestet ist. Wandert zusätzlich ein Datenbestand mit, werden auch die betroffenen Datenstrukturen gemessen und die Inhalte der alten und neuen Datenbanken verglichen.

Ich habe diese Methode 2010 gemeinsam mit Harry Sneed beschrieben, ausgehend von Projekten, in denen Altsysteme in Sprachen wie COBOL oder PL/1 auf neue Plattformen umzogen. Die genannten Werkzeuge gehören in diese Zeit, das Prinzip des Altsystems als Testorakel hängt an keinem von ihnen.

Warum das Altsystem die Spezifikation ersetzt

Bei manchen Projektarten lassen sich Testaufwand und Testdauer vorab berechnen, sodass der Kunde für den Test einen Fixpreis bekommen kann. Das klappt, wenn das Produkt gegen eine Anforderungsspezifikation getestet werden kann, also in einem sauber spezifizierten, stabilen Entwicklungsprojekt. Die Anforderungsdokumente lassen sich dann für die Aufwands- und Kostenschätzung von Hand analysieren, oder ein Textanalyse-Werkzeug zieht Kennzahlen wie Function Points oder Test Points heraus.

Wartungs- und Reengineering-Projekte funktionieren anders. Dort ändert sich die Software selbst nur leicht, und der Testaufwand lässt sich aus der Differenz zwischen Original- und geänderter Version schätzen.

Migrationsprojekte sind ein dritter Typ. Hier wird das ganze System gegen das Altsystem getestet, und Grundlage der Aufwandsschätzung ist der Quellcode des Vorgängersystems. Weil keine Spezifikation beschreibt, was das System tun soll, übernimmt das Verhalten des Altsystems diese Rolle. Detaillierte Testfälle entstehen aus dem, was das alte System im Betrieb tut, meist aus Online-Transaktionen und Batchprozessen. Jede Abweichung des neuen Systems davon wird als Nicht-Übereinstimmung festgehalten.

Der Migrationstest in sieben Schritten

Migrationstests lassen sich am besten schrittweise aufbauen, jeder Schritt baut auf dem vorigen auf.

1. Code messen. Die Messung des Quellcodes, der migriert werden soll, zeigt, was getestet werden muss und mit welchem Aufwand.
2. Test planen. Die Planung legt Budget und Zeitrahmen fest und definiert die einzelnen Arbeitsschritte und die erwarteten Ergebnisse.
3. Test entwerfen. Jedes Testobjekt, das das System verwendet, muss identifiziert werden: Benutzerschnittstellen, Datenbanktabellen, Systemschnittstellen und Berichte. Der Entwurf legt auch die Testschritte und ihre Reihenfolge fest.
4. Testdaten gewinnen. Das Altsystem läuft in einer kontrollierten Umgebung, Eingaben, Ausgaben und die aktuellen Datenbankzustände werden aufgezeichnet. Produktionsdaten werden anonymisiert.
5. Migrationstest durchführen. Testfälle werden aus den Online-Transaktionen und Batchprozessen abgeleitet und automatisiert gegen das migrierte System gefahren.
6. Ergebnisse auswerten. Der Vergleich der Ergebnisse beider Systeme zeigt, ob das migrierte System dieselbe Funktionalität und Performance liefert wie das Altsystem. Jede Abweichung wird als Nicht-Übereinstimmung festgehalten.
7. Abdeckung messen. Die Testabdeckung wird gegen die Ziele aus dem Testkonzept gemessen. Diese Ziele (Abdeckung von Transaktionen, Code, Daten etc.) bilden die Basis der Testservice-Vereinbarung (TSA, Test Service Agreement).

Den Code messen, bevor man plant

“Man kann nicht kontrollieren, was man nicht messen kann.” Nach diesem Satz von Tom DeMarco beginnt die Planung eines Migrationstests mit der Messung dessen, was migriert wird: des Codes. Denn der Code ist es, der bei einer Migration in eine andere Form überführt wird. Wird zusätzlich ein Datenbestand migriert, müssen auch die betroffenen Datenstrukturen gemessen werden.

Am Code lässt sich vieles messen: die Komplexität des Kontrollflusses, die Datenverwendung, die Modulinteraktionen, Wiederverwendbarkeit, Wartbarkeit, Konformität und weitere Größen. Was davon gemessen wird, hängt davon ab, welche Information die Messung liefern soll. Für den Test zählen vor allem die Anzahl der Code-Einheiten, Datenbanktabellen und Datenschnittstellen, denn sie alle muss der Test abdecken, um den funktionalen Anforderungen gerecht zu werden.

Die nötigen Metriken liefert die statische Analyse aus dem Quellcode, den Datenbankschemata, den Definitionen der Benutzeroberfläche und den Systemschnittstellen. Die Ergebnisse zeigen, wie viele Datenschnittstellen mit wie vielen Datenbanktabellen nötig sind, um jede definierte Komponente zu testen. Ein statisches Analysewerkzeug, das die Testbarkeit des Systems auf einer Skala von 0 bis 1 errechnet, hilft dabei.

In vergangenen Projekten dauerte die Messung des Quellcodes im Regelfall nicht länger als eine Woche, sofern geeignete Messwerkzeuge im Einsatz waren. Es gibt Werkzeuge, die neue wie alte Programmiersprachen beherrschen. Das ist wichtig, denn in den meisten Migrationsprojekten ist das Vorgängersystem in einer alten Sprache wie PL/1, COBOL oder C geschrieben.

Wie schätzt man den Testaufwand im Migrationsprojekt?

Der Testaufwand bemisst sich an der Anzahl der auszuführenden Testfälle und der zu validierenden Testobjekte. Ein Testfall lässt sich aus dem Nutzungsprofil der Produktionsumgebung ableiten und kann eine einzelne Online-Transaktion sein, aber auch ein Ereignis, ein Vorgang oder ein Batchprozess. Ein Testobjekt wiederum entsteht aus den Produktionsdaten und kann eine Benutzeroberfläche sein, eine Datei, eine Datenbanktabelle, eine Systemschnittstelle oder ein erzeugter Report.

Testfälle und Testobjekte zusammen ergeben den Testumfang. Richtet man diesen Umfang an der Testproduktivität vergangener Projekte aus, entsteht eine Grobschätzung für den aktuellen Migrationstest. Verfeinern lässt sie sich über den Produkttyp, die Testbarkeitskennzahl des Produkts, die Einflussfaktoren des Projekts und den Testwiederholungsfaktor.

Die Testplanung umfasst außerdem die Testziele und die Bereitstellung der Ressourcen. Ihr Ergebnis ist ein Testkonzept nach ISO/IEC/IEEE 29119-3, dem Nachfolger von IEEE 829, und eine Schätzung des Testaufwands samt Testdauer. Mit diesen beiden Größen kann ein Preisangebot für den Migrationstest an den Auftraggeber gehen.

Besonderes Augenmerk verdienen darin die Testziele und die Endekriterien. Nur wenn beide erfüllt sind, kann der Kunde den Test am Ende abnehmen. Deshalb gehören sie in einfach messbarer Form ins Testkonzept, zum Beispiel als Kennzahlen über die durchgeführten Testfälle und die validierten Testobjekte.

Wie entwirft man den Test, wenn die Dokumentation fehlt?

Einen Migrationstest zu entwerfen heißt festzulegen, was und wie getestet wird. Das “Was” beschreiben Testfälle und Testobjekte, die aus einer Analyse des aktuellen Produktionsprozesses stammen. Schon jede relevante Variante einer bestehenden Transaktion ist ein möglicher Testfall.

Auf die Dokumentation des Altsystems ist dabei kein Verlass. Sie ist selten aktuell und fehlt oft ganz. Dem Tester bleibt nur, sich mit den Endbenutzern zusammenzusetzen und aufzuzeichnen, wie sie das System heute bedienen. Heraus kommt eine nachträgliche Dokumentation der betrieblichen Nutzung. Diese schriftliche Aufzeichnung macht auch einen Großteil des Aufwands für die Regressionstests aus.

Testobjekte sind leichter zu identifizieren, weil man sie beobachten und messen kann. Am wichtigsten ist die Anzahl der Datenelemente je Datenobjekt: Felder, Spalten, Tags (Zeichen zur Strukturierung von Daten oder Text) und Widgets (Bausteine einer grafischen Benutzeroberfläche). Ebenso zählen die Wertebereiche dieser Elemente, die sich aus der Produktionsumgebung ablesen lassen.

Der Testentwurf muss klären, woher die Testobjekte kommen und womit sich die Testfälle aufzeichnen lassen. Er sollte in einem strukturierten, semiformalen Format vorliegen, etwa als Tabelle, in einem grafischen Werkzeug oder als XML-Dokument.

Woher kommen die Testdaten für eine Migration?

Die Testdaten für ein Migrationsprojekt kommen aus der Produktion. Anders als in einem Entwicklungsprojekt muss man keine eigenen Testdaten erzeugen. Die gesamte Produktionsumgebung zu kopieren, ist allerdings meist viel zu aufwändig. Im Testentwurf wurden bereits einzelne Transaktionen, Ereignisse und Batchläufe als repräsentativ identifiziert, und genau die laufen jetzt auf dem bestehenden System in einer kontrollierten Umgebung.

Vor jedem Test werden Abbilder des Bedienfelds, der Eingabedateien und des Datenbankinhalts archiviert. Nach jedem Test werden neue Abbilder derselben Objekte in gleicher Form festgehalten, dazu die gesendeten Ausgabemeldungen und die gedruckten Reports. Personenbezogene Daten, etwa Kundendaten, werden anonymisiert, um den Datenschutz zu wahren.

So entsteht eine große Menge an Testdaten, die sich in manchen früheren Projekten nur mit einem eigenen Server bewältigen ließ. Testwerkzeuge helfen auf zwei Arten:

• um Benutzeroberflächen aufzuzeichnen
• um die vielen alten und neuen Datenabbilder zu verwalten, die aufbewahrt werden müssen

Ein Capture-Replay-Tool ist eine weitere Möglichkeit. Wo keines zur Verfügung stand, haben Tester die Benutzeroberfläche der Produktionsumgebung einfach per Screenshot festgehalten und als Spezifikation für den Test des migrierten Systems verwendet. Ob mit oder ohne Werkzeug: Die Datenbeschaffung im Migrationstest ist vor allem die Verwaltung großer Mengen aufgezeichneter Daten.

Warum die Testdurchführung automatisiert laufen muss

Migrationsprojekte fallen durch ihren hohen Testanteil auf. Neue Systeme werden über lange Zeit Modul für Modul, Komponente für Komponente, System für System getestet. Weil Entwurf, Codierung und Test eng verwoben sind, ist nicht gleich sichtbar, wie viel Testaufwand insgesamt anfällt. Nur der Systemtest am Projektende hebt sich als reine Testaktivität ab.

In einem Migrationsprojekt werden dagegen ganze Systeme gleichzeitig getestet. Die Code-Überführung läuft meist automatisiert und wird von Personen durchgeführt, die die Funktionalität des Systems nicht kennen. Wo Fehler auftreten werden, lässt sich deshalb nicht vorhersagen, und falsch transformierten Code bemerken diese Personen in der Regel gar nicht. Umso mehr ist es Aufgabe der Tester, die Korrektheit des migrierten Systems nachzuweisen und Transformationsfehler aufzuspüren. In den Projekten, aus denen die Methode stammt, entfielen 60 bis 80 Prozent des Gesamtaufwands auf den Test.

Die Menge an Eingabedaten für die Testfälle ist beachtlich und von Hand kaum zu spezifizieren, ebenso die Zahl der Testfälle im Regressionstest. Ohne Automatisierung ist der Migrationstest in einem vernünftigen Zeitrahmen nicht zu schaffen.

Damit sich später feststellen lässt, welcher Teil des migrierten Codes getestet wurde, kommen vor dem Teststart Messfühler in jeden Zweig, mindestens aber in jede Methode oder jeden Codeblock. Das übernehmen Automatisierungswerkzeuge. Bei Testbeginn wird das migrierte System dann Schritt für Schritt mit den Daten der alten Transaktionen beschickt, Testtreiber simulieren dabei den menschlichen Benutzer. Schlägt eine Transaktion fehl, startet trotzdem die nächste. Nach jeder Transaktion und jedem Batchprozess werden die Inhalte der Ausgabefelder, die Ausgabemeldungen und der neue Zustand der betroffenen Datenbank für die spätere Auswertung aufgezeichnet.

All das schon während des Testlaufs zu validieren, würde viel zu lange dauern. Fehlt ein automatisches Aufzeichnungswerkzeug, sollten die Ausgabebildschirme zumindest von Hand als Screenshot gesichert werden. In dieser Phase zählt ein möglichst unterbrechungsfreier Testlauf, Auffälligkeiten werden für die spätere Prüfung notiert. Für kreatives Testen ist im Migrationstest kein Platz.

Bildschirme, Datenbanken und Reports vergleichen

Erst wenn der Migrationstest durchgelaufen ist, werden seine Ergebnisse validiert. Bildschirminhalte, Schnittstellendaten und Datenbanktabellen des migrierten Systems werden automatisch und nacheinander mit den Aufzeichnungen vom Altsystem verglichen. Weichen die Formate voneinander ab, werden sie vorher in ein gemeinsames Format umgewandelt.

Dafür gibt es eigene Umwandlungs- und Vergleichswerkzeuge. Benutzeroberflächen, die früher Großrechner-Speicherabbilder oder UNIX-Bildschirme waren, werden in XML-Dokumente überführt. Die neuen Oberflächen, etwa Webseiten oder Mashups, die bestehende Inhalte neu kombinieren, werden in ähnliche XML-Dokumente umgewandelt. So lassen sich einzelne Datenelemente gezielt vergleichen, egal wo und wie sie auf dem Bildschirm stehen.

Mit den Datenbanken geht man genauso vor. Die Inhalte der alten Datenbanken (IMS, IDMS, IDS, ADABAS, DB2, VSAM, sequenzielle Dateien etc.) werden wie die der neuen relationalen Datenbanken heruntergeladen und in CSV-Dateien umgewandelt. Anschließend werden die beiden Dateien Spalte für Spalte verglichen. Unterschiedliche Formate oder berechnete Werte werden über definierte Regeln geprüft.

Dieser Datenbankvergleich ist der Teil, den Datenmigrationstests für sich allein abdecken: Sie prüfen, ob die Daten vollständig und korrekt angekommen sind. Der Migrationstest geht weiter, weil er auch den überführten Code testet. Der ISTQB-Lehrplan Foundation Level nennt Migrationen als Auslöser für Wartungstests und führt Tests der Datenkonvertierung für den Fall an, dass Daten aus einer anderen Anwendung in das System migriert werden.

Reports und Systemschnittstellen können in einem völlig anderen Format vorliegen als die alten Versionen. Die Werte der einzelnen Datenelemente müssen trotzdem identisch sein. War der alte Rechnungsbetrag “EUR 19,99”, muss der neue genau diesen Wert zeigen, auch wenn er auf dem neuen Bildschirm oder Ausdruck an ganz anderer Stelle steht. Werkzeuge lösen das, indem sie einzelne Datenelemente aus beliebigen Ausdrucken, Bildschirmen oder Textdateien herausziehen und in eine XML-Datei schreiben, mit einem XSD-Schema als Vergleichsgrundlage. So lassen sich Daten aus einer alten Großrechner-Liste (einem Programmausdruck) mit Daten im XML- oder WSDL-Format vergleichen.

Der Vergleich auf der Ebene dieser elementaren Einheiten deckt selbst kleinste Unterschiede auf, etwa ein falsch gesetztes Dezimalkomma. Wenn Millionen von Datenausgaben zu vergleichen sind, ist der automatisierte Vergleich der beste Weg, Fehler im migrierten Code zu finden. Die Alternative ist, die Ausführungspfade durch den Code gegenüberzustellen, was eine Verfolgung der getesteten Transaktionen voraussetzt. Auch dafür gibt es geeignete Werkzeuge wie TestDoc. Es zeichnet nicht nur die durchlaufenen Pfade auf, sondern auch, wie oft jede Methode oder Prozedur ausgeführt wurde.

Wann ist der Test einer Migration abgeschlossen?

Der Migrationstest kann enden, wenn die gemessene Abdeckung die Ziele aus dem Testkonzept erreicht. Weil der Code überführt wird und nicht die Funktionalität an sich, wird der Code gemessen. Vor der Testausführung werden automatisch Messfühler oder Verfolgungspunkte in den Code eingesetzt. Jeder durchlaufene Messfühler landet in einer Log-Datei, und nach dem Testlauf zeigen diese Log-Dateien, wie wirksam der Test tatsächlich war. Reicht die Abdeckung nicht, geht der Test weiter, bis die Ziele erreicht sind.

Reports halten unterschiedliche Informationen fest. Einer zeigt den Abdeckungsgrad als Prozentsatz der durchlaufenen Messfühler und vergleicht ihn mit dem Abdeckungsziel aus dem Dienstleistungsvertrag. Ein anderer dokumentiert den Pfad jeder Testtransaktion, sodass er sich mit dem Pfad im Originalsystem vergleichen lässt und sichtbar wird, wo im neuen System etwas schiefgelaufen ist. Ein dritter listet die Codeeinheiten, auf die bestimmte Transaktionen wirken. Braucht eine Methode oder Prozedur eine Fehlerbehebung, zeigt dieser Report, welche Testfälle wiederholt werden müssen.

Ein Migrationstest bringt andere Fehlertypen zutage als der Test eines neu entwickelten Systems. Bei einer Neuentwicklung fehlen vielleicht Funktionen, Datentypen sind falsch definiert, Geschäftsregeln falsch interpretiert, Ergebnisse falsch berechnet. In einem migrierten System sind die Fehler subtiler: Nachkommastellen gehen verloren, Datensätze werden zerstört, Daten landen an einem anderen Ort, Bedingungen kehren sich um. Die Ergebnisse wirken richtig, sind es aber nicht. Weil niemand wissen kann, welche Anweisung falsch konvertiert wurde, muss jede Anweisung getestet werden, und das heißt: den Test wiederholt ausführen.

Neben der Abdeckung zählen für das Testende die Richtigkeit der Ausgabedaten und der Anteil der tatsächlich gefundenen an den vorausgesagten Fehlern. Die Planziele dafür wurden vor Projektstart in der Testvereinbarung festgelegt.

Was ein Migrationstest vom Team verlangt

Ein migriertes System zu testen, ist viel näher an der Massenproduktion als ein klassischer Systemtest: Eine enorme Menge an überführtem Code und an Daten muss in begrenzter Zeit quasi blind getestet werden. Um die funktionale Gleichheit nachzuweisen, wird idealerweise fast jedes überführte Code-Element mit einer großen Datenstichprobe aus der Produktion getestet. Diese Datenmenge und die vielen Transaktionen, die immer wieder laufen müssen, sprechen klar für Testautomatisierung.

Die Erfahrung aus Migrationsprojekten zeigt, dass der Migrationstest hochspezialisierte Tester und ausgereifte Testwerkzeuge braucht. Der Automatisierungsgrad zählt mehr als die Zahl der Tester. Ebenso wichtig ist die Testorganisation, denn ein Migrationstest muss bis ins kleinste Detail geplant werden, und dafür braucht es erfahrene Testmanager. Die gibt es nur in wenigen Organisationen.

Häufig gestellte Fragen

Was sind Datenmigrationstests?

Datenmigrationstests prüfen, ob Daten aus einem alten System vollständig und korrekt im neuen ankommen. Die Inhalte der alten und neuen Datenbanken werden exportiert, in CSV-Dateien umgewandelt und Spalte für Spalte verglichen, unterschiedliche Formate und berechnete Werte über definierte Regeln. Der Migrationstest geht weiter und testet auch den überführten Code.

Was unterscheidet ein Migrationsprojekt im Test von einer Neuentwicklung?

Im Migrationsprojekt fehlt meist eine Spezifikation, deshalb dient das Altsystem als Testorakel. Ganze Systeme werden gleichzeitig getestet. In den Projekten, aus denen die Methode stammt, entfielen auf den Test 60 bis 80 Prozent des Gesamtaufwands. Auch die Fehler sind andere: Statt fehlender Funktionen oder falsch interpretierter Geschäftsregeln treten verlorene Nachkommastellen, zerstörte Datensätze oder umgekehrte Bedingungen auf.

Welche Werkzeuge braucht ein Migrationstest?

Fast jeder Schritt stützt sich auf Werkzeuge. Statische Analysewerkzeuge messen den Code und die Testbarkeit des Altsystems. Aufzeichnungs- und Capture-Replay-Tools halten Benutzeroberflächen und Datenabbilder fest, Testtreiber spielen die alten Transaktionen ab, Umwandlungs- und Vergleichswerkzeuge prüfen Bildschirme, Datenbanken und Reports. Tracing-Werkzeuge zeichnen die Ausführungspfade auf.