Testverfahren für Client/Server-Systeme .1 Problematik des verteilten Tests .1 Problematik des verteilten Tests

Client/Server-Systeme sind verteilte Systeme, und verteilte Systeme bedingen einen verteilten Test. In einem verteilten Testverfahren gibt es zwar die gleichen Phasen wie in einem zentralen Testverfahren, aber die Phasen laufen etwas anders ab, mehr parallel. Sie haben eine größere Überlappung, und dem Integrationstest kommt eine stärkere Bedeutung zu [MiKo98].

Beim konventionellen Test auf dem Mainframe hat der Integrationstest oft völlig gefehlt. Die Module wurden vielleicht getestet, dann alle zusammengebunden, und was folgte, war ein Funktionstest auf Systemebene. Diese Vorgehensweise war dadurch begünstigt, dass alles miteinander eng zusammenhing – der TP-Monitor, das Datenbanksystem und das Anwenderprogramm. Die einzige klare Trennung gab es zwischen dem Batch- und dem Onlinebetrieb, was dazu führte, dass diese beiden Teilsysteme getrennt getestet wurden.

In einem Client/Server-Umfeld ist die Software verteilt (Abbildung 2.3). Auf den Clientrechnern befinden sich ein oder mehrere Teilsysteme für die Präsentationslo-gik. Beim Serverrechner kann es mehrere Teilsysteme für die Geschäftslogik geben.

Schließlich kann es auch mehrere Datenhaltungssysteme in der Zugriffsschicht geben, d.h. wir haben es hier mit wesentlich mehr Teilsystemen zu tun. Demzufolge wächst der Integrationsaufwand und damit die Bedeutung des Integrationstests [Spi90].

Die Tatsache, dass mehrere Rechnerarten und eventuell mehrere Betriebssysteme in einem Client/Server-System beteiligt sind, bleibt nicht ohne Einfluss auf das Test-verfahren. Es wird mehr Testpersonal benötigt, und dieses Personal muss gleichzei-tig dasselbe Ziel, aber von verschiedenen Richtungen aus anstreben. Ihre Koordi-nierung erfordert eine straffere Planung und eine rechtzeitige Abstimmung der Testaktivitäten. Ein detaillierter Entwurf der Testszenarien wird unentbehrlich.

Wegen der unterschiedlichen Hardware und Software wird auch der Testaufwand viel größer. Es muss eine Testumgebung eingerichtet werden, die der endgültigen Produktionsumgebung gleichkommt.

2.2 Testverfahren für Client/Server-Systeme _________________________________39

Abbildung 2.3 Test verteilter Systeme (RNETS)

2.2.2 Ansätze zum Test verteilter Systeme

Der Test verteilter Client/Server-Systeme wird in der Fachliteratur als eine neue Problematik behandelt, die auch neue Lösungsansätze bedingt. Kelly Bourne be-schreibt in ihrem Buch „Testing Client/Server Systems“, warum Client/Server-Systeme anders getestet werden müssen [Bou97] und schlägt dafür fünf Teststufen vor:

• Unit-Test, wobei eine Unit ein Windows-Control, eine Geschäftsfunktion, ein Bericht oder eine gespeicherte Prozedur sein kann;

• Integrationstest, wobei es darum geht, die Interaktion zwischen verteilten Kom-ponenten zu bestätigen;

• Systemtest, um das System in seiner Gesamtheit zu testen;

• Installationstest, wobei es darauf ankommt, das System auf allen vorgesehenen Plattformen zu testen;

• Performanztest, um schließlich die Belastbarkeit und Robustheit des Systems unter einer schweren Transaktionslast mit einer großen Datenmenge zu prüfen.

Bourne empfiehlt weiter, Client/Server-Systeme inkrementell zu entwickeln und zu testen, d.h. in regelmäßigen Abständen Komponenten neu zusammenzustellen (Builds) und neu zu testen. Natürlich müsste es eine eigene Testgruppe geben, die für alle Testaktivitäten nach dem Unit-Test verantwortlich ist. Bis zum Integrations-test ist der Test im privaten Zuständigkeitsbereich des Entwicklers. Ab dem Integra-tionstest ist der Test im öffentlichen Zuständigkeitsbereich des Testers. Hier werden alle Fehler offiziell gemeldet und verfolgt. Die Verteilung der Software verlangt

nach einer Verteilung der Testaktivitäten und einer Verteilung des Fehlermeldesys-tems.

In einem anderen Buch mit dem Titel „Testing Client/Server Applications“ [Gog93]

beschreibt Patricia Goglia vier Phasen für den Test:

• die Planungsphase,

• die Entwurfsphase,

• die Ausführungsphase und

• die Wartungsphase.

In der Planungsphase werden Testaufgaben und Testergebnisse identifiziert, die Testressourcen zugeteilt, die Testwerkzeuge bereitgestellt, die Testziele gesetzt und die Verantwortlichkeiten festgelegt.

In der Entwurfsphase werden die Testzyklen bestimmt, die Testfälle spezifiziert, die Testprozeduren implementiert und die Testdaten generiert. Für den Test der Ge-schäftslogik empfiehlt Goglia die Entscheidungstabellentechnik zur Ermittlung der Testfälle. Für die Implementierung der Testprozeduren werden Testfall/Modul-Matrizen empfohlen, und für die Generierung der Datenbanken schlägt die Autorin eine Testfall/Datenbankmatrix vor. Schließlich wird im Hinblick auf die Verteilung eine Matrix der Netzknoten und Testprozesse erarbeitet. Auf diese Testentwurfs-techniken wird später bei den Methoden eingegangen. Hier soll nur darauf hinge-wiesen werden, dass der Testentwurf für Client/Server-Systeme viel systematischer und detaillierter sein muss als der Testentwurf monolithischer Systeme.

In der Ausführungsphase werden die Testumgebung aufgebaut, die Testprozesse gestartet, die Testabläufe verfolgt, die Testzustände registriert, die Testergebnisse validiert und Fehlverhalten protokolliert. Die Autorin legt besonderen Wert auf den Paralleltest multipler Pfade, um die Synchronisierung der Pfade zu prüfen. Hier komme es darauf an, die vielen Ausnahmefälle einer Client/Server-Architektur auszulösen, denn wenn auf die Ausnahmefälle gezielt wird, ergeben sich die Nor-malfälle von selbst.

In der Wartungsphase geht es hauptsächlich um den Regressionstest. Da Goglia für eine inkrementelle Entwicklung plädiert, beginnt die Wartung bereits in der Ent-wicklung. Immer wenn neue Inkremente geliefert werden, müssen die alten wieder bestätigt werden. Um nicht alles völlig neu testen zu müssen, empfiehlt die Autorin eine Impaktanalyse. Diese soll zeigen, welche bestehenden Daten und Funktionen von den neu hinzugekommenen Funktionen betroffen sind. Hier sei von den Modul- und Komponentenschnittstellen auszugehen. Die inkrementelle Entwicklung hat zwar ihre Vorteile, aber für den Test stellt sie eine neue Herausforderung dar.

Client/Server-Systeme haben also ähnliche Testphasen wie monolithische Systeme, man kann sogar die ANSI-Norm als groben Rahmen übernehmen (Abbildung 2.4).

Dennoch, wie die beiden zitierten Bücher zum Ausdruck bringen, gibt es innerhalb