4 Objektorientierter Testentwurf
4.2 Testanforderungen an objektorientierte Systeme
4.2.2 GUI-Testanforderungen
Neue objektorientierte Anwendungen haben meistens eine graphische Benutzungs-oberfläche (graphical user interface, GUI) Die heutigen WIMP-Oberflächen (win-dows, icons, menus, pointing device) sind sehr komplex und bieten viele Möglich-keiten der Bedienung an. Oft kann jeder Endbenutzer seine Oberfläche individuell anpassen, zumindest was Farben, Schriftgrößen und Layout anbelangt. Er kann auch wahlweise mit der Maus oder mit der Tastatur arbeiten, um mit der Maschine
zu kommunizieren. Daraus ergeben sich hohe Anforderungen an den Test, denn die vielen Bedienungsmöglichkeiten müssen getestet werden (Abbildung 4.3). Jede Oberfläche hat eine Reihe von Ein- und Ausgabemöglichkeiten. Beim alten 3270-Terminal mit seinen festformatierten Masken waren diese Möglichkeiten be-schränkt. Ein Großteil der Felder war geschützt. Der andere Teil ließ nur bestimmte Eingaben zu. Das einzige Eingabemedium war die Tastatur. Der höchste Komfort war die Nutzung von Funktionstasten. Moderne graphische Oberflächen sind min-destens dreimal so komplex. Neben der Tastatur und den Funktionstasten kommt die Maus als Eingabemedium und Ikonen bzw. Bilder als Ausgabemedium hinzu.
Es können zur gleichen Zeit mehrere Masken aktiv sein, sodass der Benutzer gleichzeitig mehrere Transaktionen bearbeiten kann. Er kann mit dem Tabulator oder mit der Maus positionieren, und er kann die Reihenfolge der Eingabesignale beliebig kombinieren [Tro95].
Pulldown-Menü
Tabelle Text Box ABCDEFGHIJK Numerischer Wert
9999999.99
Ö
Option Option Option
KZ1 KZ2 KZ3 KZ4 KZ5 Schlüssel-verzeichnis Auswahl
Alle Kombinationen
Grenzwertanalyse
Repräsentative Werte
Ursache / Wirkung Analyse Gültig, ungültig,
Werte
Ö
Abbildung 4.3 Test der Benutzungsoberfläche
All dies hat seinen Preis im Test. Die zugelassenen wie die nicht zugelassenen Be-dienungsmöglichkeiten müssen alle erprobt und bestätigt werden. Die ersten, um zu beweisen, dass sie funktionieren, und die letzten, um zu beweisen, dass sie abge-fangen werden. Deshalb hat der Test von GUIs zu einer anspruchsvollen eigenen Disziplin mit zahlreichen Hilfsmitteln geführt. Die automatische Aufzeichnung von Eingabesignalen und deren Rückspulung sowie die flächendeckende Bombardie-rung der Oberfläche mit Mausklicken und die Simulation möglicher Tastenkombi-nationen sind alle nur Versuche, den Anforderungen eines GUI-Tests gerecht zu werden.
Die Mindestleistung ist die Dokumentation der GUI-Testanforderungen in Form von Checklisten, die darauf hinweisen, was alles zu testen wäre. Auch wenn diese
4.2 Testanforderungen an objektorientierte Systeme ___________________________93
Anforderungen aus Zeit- und Kapazitätsgründen nicht alle erfüllbar sind, dienen sie trotzdem als Richtlinie für den Oberflächentest [Sch95].
4.2.3 Datenbanktestanforderungen
In der Praxis benutzen die wenigsten objektorientierten Anwendungen auch objekt-orientierte Datenbanken. Wenn dies so wäre, könnte man die Datenhaltung bzw.
die Objektaufbewahrung als verlängerte Form der persistenten Objektverwaltung testen, d.h. der Datenbanktest wäre Bestandteil des Objekttests. Zur Zeit sind die meisten objektorientierten Anwendungen in der Regel mit relationalen Datenban-ken kombiniert. Die Objekte werden erst zur Laufzeit nach Bedarf dynamisch aus den Relationen bzw. aus den Sichten auf die Relationen gebildet und nachher wie-der in Relationen aufgelöst. Diese dynamische Objektbildung ist nicht unproblema-tisch. Hinzu kommt, dass relationale Datenbanken eigene Testanforderungen stel-len, vor allem was die Datenkonsistenz, die Datenkorrektheit, die Datensicherheit und die Performanz anbetrifft [Koe95].
Relationale Datenbanken sind komplexe Strukturen mit vielen verschleierten Ab-hängigkeiten. Eine besonders mächtige, aber auch gefährliche Abhängigkeit ist die referenzielle Integrität, wobei die Existenz einer Relation von der Existenz anderer Relationen in anderen Tabellen abhängt. Falls die Basisrelation gelöscht wird, wer-den die anderen abhängigen Relationen automatisch mit gelöscht. Auch Änderun-gen können die Abhängigkeitskette durchbrechen und zu Datenbankabbrüchen führen. Insofern kann eine einzige SQL-Operation eine größere Datenmenge zerstö-ren. Delete- und Modify-Operationen müssen daher in allen Ausprägungen sorg-fältig getestet werden.
Datenbankabfragen können zu unterschiedlichen Ergebnissen führen, je nachdem, welche Datenkonstellation zur Zeit der Abfrage vorherrscht. Besonders fehleranfäl-lig ist die Vereinigung verteilter Tabellen durch eine Join-Operation. Die geringste Abweichung in einer der betroffenen Tabellen kann das Ergebnis beeinflussen, erst recht, wenn die Joins verschachtelt sind. Daher ist es für den Test der Datenbank-zugriffe erforderlich, Datenbankzustände einzufrieren und zu archivieren, um den-selben Test wiederholen zu können. Dies erfordert wiederum eine große Speicher-kapazität und eine systematische Testdatenverwaltung. Die Testdatenbanken müs-sen ebenso versioniert und verwaltet werden wie die Programme.
Moderne relationale Datenbanken haben zahlreiche mächtige Eigenschaften, um den Umgang mit ihnen zu erleichtern, aber diese Eigenschaften müssen alle getestet werden (Abbildung 4.4). Dazu gehören u.a.
• Stored Procedures,
• Triggers,
• Rules und
• Constraints [Hal94].
Stored Procedures müssen wie andere Programme Schritt für Schritt getestet wer-den, um sicher zu sein, ob alle logischen Ausgänge korrekte Ergebnisse liefern.
Stored Procedures sind nicht nur mächtige Automaten, die wichtige Funktionen auf den Daten ausführen, sie sind auch mächtige Fehlerquellen. Am besten ist es, wenn sie instrumentiert werden, um ihr Verhalten zu analysieren.
Triggers sind eine besondere Art von Stored Procedures, die eigenmächtig in Akti-on treten, wenn ein bestimmter Zustand auftritt, z.B. wenn eine vorgegebene Zeit erreicht ist, oder wenn eine bestimmte Datenrelation geändert wird. Um sie zu tes-ten, muss ihr Auslöser manipuliert werden, d.h. die Systemuhr setzen, oder den auslösenden Zustand künstlich hervorrufen. Dafür braucht man besondere Testfälle.
Rules sollten verhindern, dass die Datenbank in einen logisch inkonsistenten Zu-stand gerät. Zu diesem Zweck prüfen sie die Eingabedaten, ehe sie in die Tabellen einfließen, und kontrollieren die Tabelleninhalte in regelmäßigen Intervallen. Wenn Regeln verletzt werden, wird eine Ausnahmebedingung erhoben. Z.B. dürfen Kon-tobestände die spezifizierte Kreditgrenze nicht unterschreiten. Wenn sie dies tun, wird das Konto automatisch gesperrt. Um solche Regeln zu testen, müssen Testfälle aus der Regelspezifikation abgeleitet werden.
Constraints sind Regeln, die bestimmte unerwünschte Datenkombinationen verhin-dern. Fremdschlüssel-Constraints verhindern z.B., dass nur Werte in einer als Fremdschlüssel bestimmten Spalte vorkommen, die auch in der anderen Tabelle als Primärschlüssel vorkommen. Der Test von Constraints verlangt Testfälle, die diese Einschränkungsregel verletzen. Der Tester muss versuchen, Relationen einzufügen, die nicht zulässig sind, oder Relationen zu löschen, die nicht änderbar sind. Aus den Einschränkungen ergeben sich reichlich Testfälle.
All dies zeigt, wie umfangreich der Test relationaler Datenbanken werden kann.
Hinzu kommen die ganzen Ausnahmesituationen wie Deadlocks, Speicherfehler, Timeouts und Überläufe. Es wird kaum möglich sein, alle potenziellen Probleme im Test hervorzurufen. Dennoch ist es nützlich, eine Checkliste zu führen, zumindest als Erinnerung an all das, was man noch nicht getestet hat. Dies gilt übrigens auch für die anderen Testanforderungen.
Zum Schluss gibt es besondere Testanforderungen für Systeme, die eine gekapselte Datenbank als zentrale Objektrepository benutzen. Die Daten für die Bildung der Objekte auf dem Server werden aus der zentralen Datenbank, z.B. IMS/DB oder DB/2, genommen und per Datenfernübertragung auf den Server übertragen. Danach werden die betroffenen Segmente oder Tabellen wieder freigegeben. Nachdem die Objekte auf dem Server verarbeitet wurden, kommen die Daten wieder zurück zum Host. Bis dahin könnte es gut sein, dass die Segmente oder Tabellen, aus denen die Daten gewonnen wurden, durch andere Hosttransaktionen verändert worden sind.
Dies ist ein typischer Fall, der unbedingt getestet werden muss, auch wenn der
4.2 Testanforderungen an objektorientierte Systeme ___________________________95
Testaufwand erheblich ist. Daran kann man sehen, welche Probleme verteilte Daten mit sich bringen [PBR90].
Alle ausführen
Alle auslösen
Alle bestätigen
Alle erproben
Index
Primary Keys
Foreign Keys Relationale Tabellen
Alle Zugriffspfade testen Alle Zugriffspfade testen
Stored Procedures
Stored
Procedures TriggersTriggers RulesRules ConstraintsConstraints
Abbildung 4.4 Test der Datenbanken
4.2.4 Objekttestanforderungen
Zu den Anforderungen für den Test der verteilten Verarbeitung der graphischen Oberfläche und der relationalen Datenbanken kommen die Anforderungen für den Test verteilter Objekte noch hinzu (Abbildung 4.5). In gewissem Sinne sind verteil-te Objekverteil-te eine Varianverteil-te der ververteil-teilverteil-ten Verarbeitung. Es geht um die Abarbeitung von Transaktionen über mehrere Netzknoten hinweg. Sowohl die Daten als auch die Funktionalität sind auf verschiedenen Rechnern verteilt. In einer nicht-objekt-orientierten Applikation sind jedoch die Teilprogramme statisch gebunden. Der wiederanlauffähige Code (reentrant) für die Verarbeitung einer Transaktionsart bleibt unverändert. Nur die Daten ändern sich. Beim Test solcher Systeme kommt es darauf an, alle relevanten Pfade durch den Code zu durchlaufen. Damit ist auto-matisch der Test aller relevanten Datenkonstellationen verknüpft.
Im Falle der verteilten Objekte wird der Code vervielfältigt. Für eine Transaktions-art gibt es nicht eine einzige Codeeinheit mit mehreren Datenbereichen, sondern mehrere Codeeinheiten, jede mit eigenem Datenbereich. Sie werden dynamisch erzeugt und sollten nach ihrer Nutzung wieder freigegeben werden. Die Pfade durch die Objekte sind auch nicht deterministisch wie bei den Prozeduren. Ein- und die-selbe Transaktion kann einmal so und einmal anders ablaufen, je nachdem, welche Objekte geladen und welche Ressourcen vorhanden sind. Insofern ist eine genaue
Voraussage eines Ablaufpfades nicht möglich, ebensowenig der Abgleich von Soll- und Istpfad.
Getestet werden hier nicht nur die Schnittstellen und der Datenaustausch zwischen Teilen eines einzelnen Programms, sondern auch die Schnittstellen und der Daten-austausch zwischen allen Ausprägungen bzw. Instanzen eines Programms. Statt auf Pfade durch den Code zielen Testfälle auf Ausprägungen des Codes und auf Pfade durch die Ausprägungen. Die Anzahl der Testfälle ist nicht gleich der Anzahl der Pfade, sondern gleich der Anzahl der Instanzen mal der Anzahl der Pfade. Damit steigt die Testfallanzahl multiplikativ im Verhältnis zur Anzahl möglicher Instan-zen.
System-test
Subsystem-test
Komponententest
Klassenhierarchietest
Klassentest
Klasse Operation Klasse Operation
Bottom Up
Inkrementieller, deduktiver Testansatz von den
Anwendungs-fällen aus
Top Down Inkrementieller,
induktiver Testansatz von den Objekten
aus
Abbildung 4.5 Testobjekthierarchie
Die Herausforderung an den Test verteilter Objekte ist somit hauptsächlich ein Mengenproblem – wie testet man alle Kombinationen aller Objekte mit allen poten-ziellen Interaktionen. Diese Testanforderung ist im Falle komplexer Systeme nur über die Definition einer praxisrelevanten Untermenge zu erfüllen, d.h. über ein operationales Profil des Systems unter Test. Es kommt deswegen hier darauf an, folgende Objekttestanforderungen zu spezifizieren:
• welche Transaktionsarten sind zu testen;
• welche Klassen sind durch diese Transaktionen betroffen;
• welche stellvertretenden Objekte werden aus diesen Klassen erzeugt;
• welche Funktionen führen die stellvertretenden Objekte aus;
• welche relevanten Zustände können die stellvertretenden Objekte annehmen und