Testen bei MigrationsprojektenMigrationsszenarien und relevante Testtypen

Softwaresysteme altern über die Zeit. Dieser Prozess ist dadurch gekennzeichnet, dass sich die Kluft zwischen den wachsendenAnforderungen an die Systeme und deren tatsächliche Leistungsfähigkeit immer weiter vergrößert. Oftmals erfolgt eine Erhaltungund Weiterentwicklung der Systeme, um der Alterung entgegenzuwirken. Über die Zeit geht dies jedoch mit einer verringertenQualität der Software und einer steigenden Wartungskomplexität einher (vgl. [Par94]). Der Umfang der Änderungsmöglichkeitendurch eine Weiterentwicklung ist zudem begrenzt, weil Einschränkungen der zugrunde liegenden Technologie dazu führen kön-nen, dass nicht alle Anforderungen umsetzbar sind. Ein Ausweg ist die Migration des Systems in eine neue Umgebung. Dies istjedoch nur dann erfolgreich, wenn das migrierte System die funktionalen und nichtfunktionalen Anforderungen weiterhin erfüllt,was durch Testen geprüft werden muss. In diesem Artikel erläutern wir, worauf es dabei je nach Art der Migration ankommt.

Migration von

Altsystemen

Eine Softwaremigration bezeichnet dietechnische Überführung eines Software -systems in eine andere Umgebung, wobeidie eigentliche Funktionalität erhaltenbleibt (vgl. [Sne10]). Um die darauserwachsenden Herausforderungen für dieQualitätssicherung zu beschreiben, sollenzunächst zwei entscheidende Charakteris ti -ken für Migrationsprojekte erläutert wer-den: die beabsichtigte Umgebungsänderungsowie die Art der Migration.

soll sicherstellen, dass kein Teil der migrier-ten Software ungetestet bleibt. Die Effi -zienz kann zum einen durch eine Wieder -ver wendung der Testfälle des Altsystemsund zum anderen durch einen möglichsthohen Grad an Testautomatisierung sicher-gestellt werden. In diesem Artikel beschrei-ben wir unsere Sicht auf unterschiedlicheArten der Migration und darauf, wie Testerbei Migrationsprojekten systematisch vor-gehen und die passenden Testtechniken fürdie jeweilige Migrationsart einsetzen kön-nen.

Die Qualitätssicherung (QS) bei der Migra -tion wird hauptsächlich anhand der Re -gres sionstests des Altsystems sowie derneuen Tests des Zielsystems durchgeführt.Dabei muss die korrekte Repräsentationder Features des Altsystems durch die altenund neuen Testfälle sichergestellt werden.Mehr als die Hälfte der Migrationsauf -wände werden für das Testen aufgebracht(vgl. [Sne10], [Fle08]). Um eine effektiveQS zu betreiben und die Aufwände zu opti-mieren, sind systematische und effizienteTesttechniken notwendig. Die Systematik

der au tor

1 www.objektspektrum.de

advertorial

Marvin Grieger

(mgrieger@s-lab.upb.de)ist Researcher im s-lab – Software Quality Lab derUniversität Paderborn. Sein Forschungsschwer -punkt liegt auf dem Gebiet der modellgetriebenenSoftwaremodernisierung.

Baris Güldali

(bguldali@s-lab.upb.de)ist Researcher im s-lab – Software Quality Lab derUniversität Paderborn. Seine Arbeitsschwerpunktesind modellbasiertes Testen und Testautomati -sierung. Er ist aktives Mitglied des ArbeitskreisesTOOP/MBT in der Gesellschaft für Informatik (GI).

Dr. Michael Mlynarski

(michael.mlynarski@qualityminds.de)ist Geschäftsführer und Senior Test Consultant fürdas Thema Softwaretesten bei der QualityMindsGmbH. Seine Forschungsbereiche sind modellba-siertes und agiles Testen sowie Testmanagement.

Torsten Grünen

(torsten.gruenen@qualityminds.de)ist Principal Consultant für das Thema IT-Architek -turen bei der QualityMinds GmbH. Seine Schwer -punkte liegen im Bereich der Qualitätssicherungvon SOA- sowie großen Migrationsprojekten.

Dr. Stefan Sauer

(sauer@s-lab.upb.de)ist Senior Researcher und Geschäftsführer des s-lab – Software Quality Lab der Universität Pader -born. In seiner Forschung beschäftigt er sichschwer punktmäßig mit der systematischen Ent -wick lung situativer, modellbasierter Softwareent -wicklungs- und Qualitätssicherungsmethoden.

Auslöser einer Migration kann eineVerän derung der gesetzlichen oder markt-getriebenen Rahmenbedingungen sein.Daraus erfolgt eine Umgebungsänderung,die sich auf eingesetzten Softwareprodukte,-komponenten oder -technologien bezieht.Der Wechsel eines Betriebssystems, einesEnt wick lungsframeworks oder der einge-bundenen 3rd Party-Systeme sind typischeUmgebungsänderungen. Die von dieserÄnderung betroffenen Bestandteile einerSoftware müssen migriert werden.

Die Motivation, eine Migration anstelleeiner Neuentwicklung durchzuführen, be -steht in dem Ziel, Teile des bestehendenSoftwaresystems wiederzuverwenden. Umdies zu realisieren, müssen die von derUmgebungsänderung betroffenen Aspektedes Systems systematisch in die neue Umge -bung überführt werden. Dabei haben sich,wie in Abbildung 1 symbolisch dargestellt,vier Arten der Migration in der Praxisbewährt (vgl. [SNE10]).

Eine Konversion entspricht einer Überset-zung zwischen der bestehenden und der neu-en Umgebung, die oftmals automatisiertdurchgeführt wird. Ein Beispiel wäre eineSprachkonversion, durch welche Co bol-Code automatisiert in Java-Code übersetztwird. Dabei existiert eine formale Vorschrift,welche die Abbildung von Aus prägungender Quellumgebung auf Aus prä gungen derZielumgebung beschreibt. Im Falle einerSprachkonversion entspricht dies einerAbbildung zwischen den vorhandenenSprach konstrukten. Falls eine direkte Kon -version zu komplex ist oder qualitativ nichtden geforderten Anforderungen entspricht,kann stattdessen eine Kapselung erfolgen.Dabei werden zunächst abgrenzbare Teiledes bestehenden Software systems identifi-ziert, welche erhalten werden sollen. In der

neuen Umgebung wird dann zusätzlich eineKapselungskompo nente eingeführt, wo -durch eine direkte Einbindung ermöglichtwird. In einem Migrationsprojekt kann aucheine 1:1-Wiederverwendung von Bestandtei -len des Softwaresystems stattfinden, die vonder Umgebungsänderung nicht betroffensind. Als letzte Alternative kann eine Re -imple men tierung in Betracht gezogen wer-den. Dabei findet eine manuelle Implemen -tierung der vorhandenen Funktionalität inder neuen Umgebung statt.

Zur Veranschaulichung der vorgestelltenMigrationsarten wird nachfolgend einBeispiel für eine Migration angeführt. InAbbildung 2 ist dazu eine architektonische

Sicht auf ein Altsystem dargestellt. DasSystem besteht aus drei Komponenten, wel-che über Schnittstellen miteinander verbun-den sind. Neben der Datenbank existierteine Komponente, welche die Querschnitts -funktionalität für Logging bereitstellt. Diefachliche Funktionalität wird durchKomponenteA realisiert. Diese beinhaltetdazu mehrere Klassen, stellt Benutzungs -schnittstellen bereit und greift auf dieFunktionalität der anderen Komponentenzu. In dem Beispiel soll nun ein Wechsel derzu Grunde liegenden Plattform stattfinden.Neben dem Wechsel der Programmier -sprache macht diese Umgebungsänderungin unserem Beispiel auch eine architektoni-sche Veränderung erforderlich, da dasmono lithisch aufgebaute System nungemäß dem Konzept der Zielplattform ineine mehrschichtige Architektur überführtwerden muss. Die Abbildung zeigt auchTestartefakte, die zur Qualitätssicherungdes Altsystems benutzt wurden. Dabei wur-den je nach Komponente und Granularitätfolgende Typen von Testfällen verwendet:Datenbank-, Klassen-, Schnittstellen- undGUI-Tests.

Die in der Zielumgebung resultierendeApplikation und die Wiederverwendungder Testfälle zur Qualitätssicherung desmigrierten Systems sind in Abbildung 3dargestellt. Die Komponente Datenbankwurde im Rahmen dieser Migration nicht

2Online-Themenspecial Testing 2013

Online-Themenspecial Testing 2013 advertorial

Abb. 1: Abstrakte Darstellung der Migrationsarten.

Abb. 2: Komponenten und Testfälle des Altsystems.

bank in der Abbildung 3) bereits imEinsatz war und qualitätsgesichert seinsollte, ist das primäre Ziel des Testens,nach der Migration zu prüfen, ob dieSchnittstellen und die Protokolle mitanderen Komponenten korrekt funk-tionieren. Dabei kann es vorkommen,dass die aufrufenden Komponentensyntaktisch falsche oder unvollständigeParameter übergeben oder syntaktischunterschiedliche Rückgabewerte erwar-ten. Die Alt-Testfälle können Testlogikund Testdaten liefern sowie bei derWeiterentwicklung des Zielsystemszum Regressionstest verwendet wer-den. Datenbanktestfälle sind typischeTesttypen, die bei dieser Migrationsartoft vorkommen.

■ Konversion: Die Konversion einerKomponente des Altsystems in eine

einen Testfall zu ändern oder weitereTestdaten einzubeziehen. Alt-Testfällekönnen wegfallen, wenn die betroffe-nen Komponenten im Zielsystem weg-gefallen oder durch Änderungen imZielsystem obsolet geworden sind.

■ Neu-Testfälle: Menge an Testfällen, dieerstellt werden, um die Aspekte desersten Releases des Zielsystems zu prü-fen, die von den Alt-Testfällen nichtabgedeckt werden. Neu-Testfälle kön-nen auch auf Alt-Testfällen basieren,sich dann aber deutlich im Testablaufund in den Testdaten unterscheiden.

Die Auswahl der Migrationsart hat folgen-de Konsequenzen für den Testprozess:

■ 1:1-Wiederverwendung: Da die wieder-verwendete Komponente (z. B. Daten -

verändert (1:1-Wiederverwendung). Fürdie Überführung der Logging-Komponentewurde die Migrationsart Kapselung ge -wählt. Dazu wurde ein Wrapper einge-führt, welcher eine Einbindung der beste-henden Komponente in das Zielsystemermöglicht. Die Elemente der KomponenteKomponenteA wurden gemäß der gefor-derten Schichtenarchitektur auf zweiKompo nenten aufgeteilt. Die KlassenKlasse2 und Klasse3 wurden dabei auto-matisch konvertiert. Die Klasse1 konntekeiner Schicht eindeutig zugeordnet wer-den, sodass die enthaltene Funktionalität inverschiedenen Klassen manuell reimple-mentiert wurde. Im Anschluss an die Über-führung stellt sich nun die Frage nach derQualitätssicherung, d. h., ob die migrierteSoftware die funktionalen und nichtfunk-tionalen Anforderungen erfüllt. Wie diessichergestellt werden kann, erläutern wirim nächsten Abschnitt.

Qualitätssicherung

Um die Erfüllung der Anforderungen durchdas Zielsystem prüfen zu können, müssendie Tester den Testprozess an die Charak -teristiken des Migrationsprozesses anpassen.Dabei muss geklärt werden, ob die Testbasisgleich bleibt oder fachliche Änderungen inden Testfällen notwendig sind, ob Testdatenweiterhin konsistent und vollständig sindund ob technische Anpas sungen inTestskripten oder Testtreibern durchgeführtwerden müssen. Auch wenn sich die im letz-ten Abschnitt beschriebenen vier Migra -tionsarten im Vorgehen unterscheiden, ist esein Ziel der Qualitäts sicherung, vorhandeneTestartefakte nach Möglichkeit wiederzu-verwenden (siehe Ab bil dung 3). DieWiederverwendung hat den Vorteil, dasseinerseits der Aufwand für das Testen redu-ziert und andererseits die Testlogik in denTestfällen zur Sicher stellung der gleichblei-benden Anwendungs logik im Zielsystemverwendet werden kann.

Bevor wir den Einfluss der gewähltenMigrationsarten auf den Testprozess vor-stellen, ist die Definition von zwei wesent-lichen Testfallarten im Migrationskontextnotwendig:

■ Alt-Testfälle: Menge an Testfällen, diefür die Tests (funktional, nichtfunktio-nal) im Sinne einer Regression zum letz-ten Release des Altsystems verwendetwurden. Um diese für einen Test desZielsystems nutzen zu können kann eserforderlich sein, die Testdaten für

advertorial

3 www.objektspektrum.de

Abb. 3: Komponenten und Testfälle des Zielsystems.

neue Komponente des Zielsystemskann Änderungen in den Schnittstellenoder der Struktur implizieren, z. B.durch eine Verteilung der bisherigenFunktionalität auf mehrere Kompo -nenten (siehe Klasse2 und Klasse3 inAbbildung 3). Im Falle einer Konver -sion ist zu prüfen, ob das Ver halten derneuen Komponente nach außen demder gesamten Komponente des Alt -systems entspricht. Dabei sind oft Än -derungen an den Alt-Testfällen notwen-dig. Für das Szenario in Abbildung 3kann die Modularisierung der altenKlassentestfälle helfen, die Testlogikauf die neuen Komponenten zu vertei-len. Außerdem müssen neue Schnitt -stellentests sicherstellen, dass derAustausch zwischen den verteiltenKomponenten korrekt funktioniert.Die vorhandenen GUI-Tests und Re -gres sionstests können dazu verwendetwerden, um zu prüfen, ob die Migra -tion Änderungen in der Funktionalitätoder der Nutzbarkeit verursacht hat.

■ Kapselung: Bei der Wiederverwendungvon Komponenten durch Kapselung(z. B. Logging in Abbildung 3) ist derfunktionale Test der gekapseltenKompo nente ebenfalls nicht notwen-dig. Vielmehr müssen Schnittstellen -tests zur Prüfung der Korrektheit undVollständigkeit der vom Wrapperweiter geleiteten Daten durchgeführtwerden. Dafür können die Alt-Testfälleunter Anpassung an die Wrapper-Schnittstelle und durch eventuell erfor-derliche Erweiterungen wiederverwen-det werden. Zusätzlich müssennicht funktionale Neu-Testfälle sicher-stellen, ob das Zeitverhalten oder dieEreignisbehandlung im Zusammenspielmit dem Wrapper akzeptabel bleibt.

■ Reimplementierung: Der größte Test -aufwand bei Migrationsprojekten ent-steht bei einer Reimplementierung. DerTest soll nicht nur die fachliche Kor -rektheit der Reimplementierung (z. B.die Klassen Klasse1_1 und Klasse1_2 inAbbildung 3) sicherstellen, sondern auchihre Integration mit den restlichenKomponenten. Falls die Reimplemen -tierung innerhalb einer Blackboxgeschieht, können die Alt-Testfälle zurSicherstellung des korrekten Verhaltensnach außen wiederverwendet werden.Falls aber die Reimplementierung aucheine Verteilung der Anwendungslogikbedeutet, sind Neu-Testfälle zu erstellen.

Fallbeispiel

In den bisherigen Abschnitten haben wirdie unterschiedlichen Arten der Migrationsowie Rolle und Szenarien der Qualitäts -sicherung vorgestellt. An einem Fallbeispielmöchten wir die Konsequenzen einerMigrationsart für den Testprozess in einemrealen Migrationsprojekt erläutern.

In dem Projekt wurde ein Wechsel desBetriebssystems von Solaris/Sparc aufLinux/x86 durchgeführt. Diese Umge -bungs än derung bedingte einen Wechsel desbestehenden Oracle-11g-Datenbank -systems und damit eine Migration der ent-haltenen Datensätze. Für diese wurde dieMigrationsart Konversion angewendet,wobei die vom Datenbankhersteller ange-botenen Konversionswerkzeuge genutztwurden. In diesem Migrationsprojekt, dasim Auftrag des öffentlichen Dienstes durch-geführt wurde, wurden innerhalb von mehrals 12 Monaten eine Vielzahl von Daten -banken migriert sowie ca. 170 000 Clientsangepasst.

Es wurden Tests auf Datenbankebenedurchgeführt. Als Grundlage diente dieRegressionstestsuite (inkl. Testfällen,Testdaten sowie Testskripten) des derMigration vorhergehenden Releases. Eswurden keine neuen Testfälle für dieMigration erstellt. Neben den funktionalenTests wurden zahlreiche Regressions-, Last-/Performance- sowie Stresstests durchge-führt. Als Basis für diese Tests dientenbereits vorhandene Testskripte sowieQuali tätsanforderungen des vorangegange-nen Releases. Dabei wurde das QS-Vor -gehen in folgende Schritte aufgeteilt:

1) Zuerst wurde die x86-Plattform mitLinux (Ablösung Solaris/Sparc) tech-nisch evaluiert. Hierbei waren verglei-chende Last-/Performancetests imDaten bankumfeld nötig.

2) Nach erfolgreicher Prototypenanalyseerfolgte eine Meilensteinplanung fürdie abhängigen Projekte.

3) Anschließend wurde die neue Plattformaufgebaut und die Datenbanken wurdenschrittweise migriert. Hierbei wurde zumStichtag ein Datenbankabzug auf Solarisangefertigt, aber der Produktivbetriebauf der Solaris-Seite gelassen.

4) Von diesem Zeitpunkt an wurde stän-dig eine Synchronisation von Solarisauf Linux durchgeführt.

5) Zu einem definierten Zeitpunkt wurdedann die alte Datenbank deaktiviertund es erfolgte eine finale Synchro -nisation der Linux-Umgebung mitSolaris.

Bei dieser umfangreichen Migration wur-den keine fachlichen Fehler durch die funk-tionalen Regressionstests identifiziert. Beiden nichtfunktionalen Tests wurde insge-samt eine Verbesserung der Performanceund der Robustheit des Systems festgestellt.

Fazit

Die richtige Migrationsart zu wählen, er -fordert sowohl eine ganzheitliche Unter -neh mens- als auch projektspezifische Betrach tung. Unabhängig von der Mi gra -tionsart ist es die Aufgabe der Tester, dieErfüllung der funktionalen und nichtfunk-tionalen Eigenschaften zu prüfen, und dasmöglichst effektiv und mit wenig Aufwand.Dabei ist ein systematisches Vorgehengenauso wichtig wie die Wiederverwen -dung von alten Testfällen. Während diesbei einigen Migrationsarten möglich ist,sind bei anderen Migrationsarten oftAnalysen zur Restrukturierung und Vertei -lung der alten Testfälle notwendig.Zusätzlich zu den funktionalen Tests müs-sen auch Schnittstellentests und nichtfunk-tionale Tests durchgeführt werden, um dasharmonische Zusammenspiel der migrier-ten Komponenten sicherzustellen. ■

4Online-Themenspecial Testing 2013

Online-Themenspecial Testing 2013 advertorial

Referenzen

[Fle08] F. Fleurey, B. Baudry, A. Nicolas, E.

Breton, J. M. Jézéquel, Generating regression

tests for software migration, Technical Report,

RR-6971, Inria, 2008.

[Par94] D. L. Parnas, Software aging, present-

ed at the Software Engineering in Proc. of 16th

ICSE, pp. 279–287, 1994.

[Sne10] H. M. Sneed, E. Wolf, H. Heilmann,

Software-Migration in der Praxis, Übertragung

alter Softwaresysteme in eine moderne Umge -

bung, dpunkt.Verlag, 2010.

[Spi10] A. Spillner, T. Linz, Basiswissen Soft -

waretest, Ausgabe 4, dpunkt.Verlag, 2010.