Phasen des objektorientierten Tests .1 Testplanung .1 Testplanung

Der Test eines objektorientierten Systems beginnt wie der Test aller Systeme mit einer Testplanung. Hier werden die Testziele gesetzt, die Testaktivitäten geplant, die Testergebnisse genannt und die Testressourcen zugewiesen (Abbildung 2.8).

Die Planung unterscheidet sich nur um Nuancen von der Planung konventioneller Tests. Auch die Ziele sind weitgehend identisch. Es sind hauptsächlich die Testge-genstände, die sich unterscheiden.

Test PlanungTest Planung

Duhtjrg rjtgr lkrh ruvjkg ljrtjg `rjt lrjtlkj fgtggf erttuzguug rjkflritujb ikrkg ir kk irkmkkgik Duhtjrg rjtgr lkrh ruvjkg ljrtjg `rjt lrjtlkj fgtggf erttuzguug rjkflritujb ikrkg ir kk irkmkkgik

Abbildung 2.8 Testplanungsphase

2.4 Phasen des objektorientierten Tests ____________________________________45

2.4.2 Testentwurf

In der zweiten Phase, dem Entwurf des objektorientierten Tests, hat die Verteilung der Software einen größeren Einfluss auf die Gestaltung der Testprozesse. Nicht selten werden in einem System mehrere Plattformtypen miteinander verbunden, z.B. Java-Clientprogramme mit C++-Serverprogrammen und Object-COBOL-Hostprogrammen (Abbildung 2.9). Für jede Plattform werden andere Testprozesse konzipiert. Dem Integrationstest kommt eine besondere Bedeutung zu. Daher muss das Konzept für den Test der Schnittstellen besonders sorgfältig ausgearbeitet wer-den. Für den Systemtest müssen nicht nur die Ein- und Ausgaben des zu testenden Systems, sondern auch alle Daten-Importe von und -Exporte zu fremden Systemen bedacht werden.

Klassen-testkonzept

Integrations-testkonzept

IDL IDL

System-testkonzept

Klassen-testfälle

Klassen-testfälle Integrierte

Testfälle Integrierte

Testfälle

Subsystem-testfälle

Subsystem-testfälle

Systemtest Importe

Importe ExporteExporte

Java

Java C++C++ COBOLCOBOL

Abbildung 2.9 Testentwurfsphase

2.4.3 Testfallspezifikation

Die Testfallspezifikation als dritte Phase ist auch beim Test objektorientierter Sys-teme die aufwändigste. Hier kommt es darauf an, aus allen möglichen Sichten auf das System Behauptungen bzw. Zusicherungen über das Verhalten des Systems zu formulieren. Es stellt sich immer die Frage „Was macht die Software, wenn Dies oder Das geschieht?“, d.h. es sind sämtliche Ereignisse zu identifizieren und zu jedem Ereignis die erwarteten Ergebnisse vorauszusagen.

Dazu muss der Testfallspezifizierer auf die Anwendungsfälle, die Geschäftsregeln, die Schnittstellendefinitionen und die Zustandsdiagramme der einzelnen Klassen

bzw. Objekte zurückgreifen (Abbildung 2.10). Daraus ergeben sich für komplexe verteilte Systeme mehrere hundert bzw. mehrere tausend Testfälle. Das Besondere an verteilten objektorientierten Systemen ist gerade dies, dass die Anzahl der Test-fälle sich verdreifacht, einmal wegen der Verteilung und nochmals wegen der Ob-jektorientierung.

Abbildung 2.10 Testspezifikationsphase

2.4.4 Testdurchführung

Die vierte Phase, die Testdurchführung, beinhaltet drei Unterphasen:

• Testprozedurerstellung

• Testumgebungsaufbau

• die Testausführung selbst

Die Testprozedurerstellung hängt weitgehend von den Testwerkzeugen ab, die zur Verfügung stehen (Abbildung 2.11). Mit den richtigen Werkzeugen ist es möglich, Testprozeduren bzw. Testskripte automatisch aus den Testfällen zu generieren, vorausgesetzt, die Testfälle sind formal beschrieben. In diesem Fall ist der Aufwand für die Erstellung der Testprozeduren gering. Mit anderen Werkzeugen wird es nur möglich sein, die Testskripte semiautomatisch zu produzieren, d.h. Tester oder Entwickler müssen die generierten Skripte manuell ergänzen. Ohne Werkzeuge ist diese Phase äquivalent zu der manuellen Codierung der Software. Für jede Funktion in der Software muss eine entsprechende Testprozedur geschrieben werden. Dies

2.4 Phasen des objektorientierten Tests ____________________________________47

führt zu einer Verdoppelung des Codieraufwandes. Deshalb ist eine automatische Generierung der Testprozeduren eine unbedingte Voraussetzung für den Test kom-plexer objektorientierter Software.

Beim Testaufbau ist die Systemverteilung der Hauptkostentreiber. Da es bei objekt-orientierter Software oft um verteilte Systeme geht, muss für jede betroffene Platt-formart eine eigene Testumgebung mit Testtreiber (driver), Teststellvertreter (stubs), Testdatenbanken usw. eingerichtet werden. Darüber hinaus muss es eine Testumgebung für das ganze System geben, in der alle Rechner und Betriebssyste-me miteinander gekoppelt sind bzw. in der die Middleware wie Java Beans, Object Request Broker, DCOM oder Component Broker installiert sind.

Die eigentliche Testausführung beinhaltet den Test der Klassen, Module, Kompo-nenten und Teilsysteme. Der Test der KompoKompo-nenten und Teilsysteme unterscheidet sich kaum von dem Test verteilter Systeme im Allgemeinen. Die Problematik ist die gleiche. Beim Test der Klassen und Module hat jedoch die Objektorientierung eine eigene Problematik, die den Test erschwert. Vererbung und Polymorphie ma-chen es schwer, einzelne Klassen oder Zweige einer Klassenhierarchie unabhängig zu testen. Die Verweise einer Klasse auf andere übergeordnete Klassen zwingen den Tester, diese übergeordneten Klassen mitzutesten. Die dynamisch gebundenen Operationsaufrufe zwingen den Tester, alle potenziellen Aufrufziele zu simulieren.

Somit ist auch der Unit-Test objektorientierter Software um einiges komplizierter als der Unit-Test prozeduraler Software.

SON ruvjkg ljrtjg `rjt lrjtlkj fgtggf erttuzguug rjkflritujb ikrkg ir kk irkmkkgik Duhtjrg rjtgr lkrh ruvjkg ljrtjg `rjt lrjtlkj fgtggf erttuzguug tjufgkik lrfkfgjreorutuz riiz

ritg Duhtjrg rjtgr lkrh ruvjkg ljrtjg `rjt lrjtlkj fgtggf erttuzguug rjkflritujb ikrkg ir kk irkmkkgik Duhtjrg rjtgr lkrh ruvjkg ljrtjg `rjt lrjtlkj fgtggf erttuzguug tjufgkik lrfkfgjreorutuz riiz

ritg Duhtjrg rjtgr lkrh ruvjkg ljrtjg `rjt lrjtlkj fgtggf erttuzguug rjkflritujb ikrkg ir kk irkmkkgik Duhtjrg rjtgr lkrh ruvjkg ljrtjg `rjt lrjtlkj fgtggf erttuzguug ruvjkg ljrtjg `rjt lrjtlkj fgtggf erttuzguug rjkflritujb ikrkg ir kk irkmkkgik Duhtjrg rjtgr lkrh ruvjkg ljrtjg `rjt lrjtlkj fgtggf erttuzguug ruvjkg ljrtjg `rjt lrjtlkj fgtggf erttuzguug rjkflritujb ikrkg ir kk irkmkkgik Duhtjrg rjtgr lkrh ruvjkg ljrtjg `rjt lrjtlkj fgtggf erttuzguug ruvjkg ljrtjg `rjt lrjtlkj fgtggf erttuzguug rjkflritujb ikrkg ir kk irkmkkgik Duhtjrg rjtgr lkrh ruvjkg ljrtjg `rjt lrjtlkj fgtggf erttuzguug ruvjkg ljrtjg `rjt lrjtlkj fgtggf erttuzguug rjkflritujb ikrkg ir kk irkmkkgik Duhtjrg rjtgr lkrh ruvjkg ljrtjg `rjt lrjtlkj fgtggf erttuzguug

ruvjkg ljrtjg `rjt lrjtlkj fgtggf erttuzguug rjkflritujb ikrkg ir kk irkmkkgik Duhtjrg rjtgr lkrh ruvjkg ljrtjg `rjt lrjtlkj fgtggf erttuzguug ruvjkg ljrtjg `rjt lrjtlkj fgtggf erttuzguug rjkflritujb ikrkg ir kk irkmkkgik Duhtjrg rjtgr lkrh ruvjkg ljrtjg `rjt lrjtlkj fgtggf erttuzguug

Abbildung 2.11 Werkzeuge in der Testausführung

2.4.5 Testauswertung

Auch die fünfte Phase, die Testauswertung, stellt im Falle objektorientierter Soft-ware eine größere Herausforderung dar als bei konventionellen Systemen (Abbildung 2.12). Die Dynamik der Erzeugung und Zerstörung von Objekten er-schwert das Festhalten und Kontrollieren der Zwischenzustände. Das Vorhanden-sein vieler unbenutzter Funktionen erschwert die Testüberdeckungsmessung, und die hohe Anzahl der Interaktionen zwischen Objekten bzw. die Kollaborationen erschweren die Verfolgung des Ablaufs. Hinzu kommt die Komplexität der Schnitt-stellen. Die Protokollierung der Abläufe und Zwischenergebnisse zwecks der Test-auswertung gestaltet sich also bei objektorientierter Software um einige Schwierig-keitsgrade höher als bei vergleichbarer prozeduraler Software. Ohne adäquate Werkzeuge ist sie kaum zu bewältigen [MgKo94].

Test-ablauf

Test-deckung

Test-ergebnisse

Test-anomalien

Fehler-meldungen

Fälle Pfade

Funktionen Pfade Zweige

Zustände Ausgaben

Abweichungen Assertion/

Verletzungen Abbrüche

Fehler Mängel Testprozeduren

Testprozeduren Testprozeduren

Testumgebung Testumgebung

Abbildung 2.12 Testauswertungsphase

2.4.6 Testwiederholung

Die Testwiederholung als sechste Phase ist mehr eine Aktivität, die sich immer wiederholt. Sie ist für den Softwaretest das, was die Wartung für die Softwareent-wicklung ist: eine endlose Nachbesserung. Parallel zur Nachbesserung des Kon-zepts und des Codes wird hier auch der Test nachgezogen. Jede Erweiterung oder Änderung der bestehenden Funktionalität, jede Korrektur und jede Optimierung bzw. Sanierung zieht eine entsprechende Fortschreibung des Tests mit sich. Falls die Änderung sich auf eine einzige Klasse bezieht, wird der entsprechende Klassen-test mit verändert. Wenn die Funktionalität oder die Schnittstelle einer Komponente sich ändert, wird der Komponententest angepasst. Insofern, als die

Benutzungsober-2.5 Ergebnisse des objektorientierten Tests __________________________________49

fläche, die Systemschnittstellen oder die Datenbankstrukturen verändert werden, wird der Systemtest fortgeschrieben. Testwiederholung ist somit eine Folge der Software-Weiterentwicklung und dauert so lange, wie die Software noch im Wan-del begriffen ist. Dafür sind besondere Regressionstesttechniken und vor allem spezielle Regressionstestwerkzeuge erforderlich.

Benutzeroberfläche

Abbildung 2.13 Testwiederholungsphase

2.5 Ergebnisse des objektorientierten Tests