Testfälle als regelbasierte Programme Spezifikation der Testfälle
5 Spezifikation objektorientierter Testfälle
5.1 Testfälle als regelbasierte Programme
In der ANSI/IEEE-Norm 829 [IEEE829] wird ein Testfall als eine einmalige Zu-sammenstellung von Datenwerten und deklarativen Anweisungen definiert, die darauf zielt, eine bestimmte Funktion oder einen bestimmten Pfad durch ein Pro-gramm auszuführen bzw. eine spezifische Anforderung zu bestätigen. Demnach ist ein Testfall so etwas wie ein Miniprogramm, allerdings ein deklaratives, denn ein prozeduraler Testfall wäre ein Widerspruch in sich. So wie z.B. die Sprachen PROLOG und SQL Ergebnisse aus verschachtelten Regeln oder Relationen zwi-schen vorhandenen Argumenten und Zwizwi-schenergebnissen ableiten, definieren Testfälle Ergebnisse im Bezug zu einzelnen Argumenten und Prädikaten. Somit ist Testfallspezifikation eine typische Anwendung der regelbasierten Programmierung [How80].
In der einfachsten Form reduziert sich ein Testfall auf die Funktionsvereinbarung bzw. den „Zustandsübergang“ (Abbildung 5.1)
x = f (y)
wobei x das Ergebnis, y das Argument und f: Y → X die Funktion ist. X ist hier stellvertretend für den gültigen Ausgabewertebereich und Y für den erwarteten Eingabewertebereich [Zel90]. Es gilt, einen Eingabewert y ∈ Y zu generieren und den Ausgabewert x ∈ X zu validieren. Die Funktion f ist der Softwarebaustein unter Test, d.h. der Testgegenstand. Der Testgegenstand könnte eine Methode, eine Klas-se, eine Klassengruppe, eine Komponente, ein Teilsystem oder ein ganzes System sein, je nachdem, auf welcher Granularitätsstufe getestet wird.
Regelbereich
Zustandsübergang (1:n)
Y(1) = 2 Y(2) = 4 Y(3) = 8 Y(4) = 16
X(1:n) X(1) = 4 X(2) = 16 X(3) = 64 X(4) = 256 Funktion
X = F (Y) F { Y*Y }
Eingabebereich Ausgabebereich
Vorzustand Nachzustand
Abbildung 5.1 Testfälle als Zustandsübergänge
Am einfachsten ist der Testfall auf der kleinsten Granularitätsstufe zu verstehen und zu formulieren. Hier ist y in der Regel eine Reihe von Parameterwerten und x eine Reihe von Rückgabewerten so wie im Beispiel
x = Mittelwert(10, 20, 30);
Die Funktion Mittelwert() müsste das Ergebnis 20 zurückgeben. Wenn dies so ist, ist der Testfall eine Behauptung über die Funktion in Bezug auf die Vor- und Nachzustände [Hay86].
Mittelwert:
Assert post x = 20;
if pre y (1:3) = 10, 20, 30;
Dabei ist es unwichtig zu wissen, wie die Mittelwertfunktion implementiert ist.
Wichtig ist nur zu wissen, was rein und raus geht.
Testfälle auf einer höheren Granularitätsstufe sind prinzipiell ähnlich zu formulie-ren, nur besitzen sie wesentlich mehr Argumente und Ergebnisse. Um zu testen, ob eine bestimmte Transaktion für eine Banküberweisung korrekt funktioniert, müsste man die erwartete Überweisung mit allen Attributen beschreiben, so z.B.:
testcase ueberweisung_01:
Assert post
Empfängerkonto.Saldo = Saldo@pre + 600,00, if pre Sendername = „Sneed, Harry“,
Senderkonto = „19404712“, Überweisungsbetrag = 600,00, Empfängername = „Sneed, Stephan“, Empfängerkonto = „19774711“, Empfängerbank = „KSK_Miesbach“, Empfänger_blz = „71152570“,;
Daraus wird ersichtlich, dass Testfälle grundsätzlich Relationen zwischen Ein-gangs- und Ausgangsdaten darstellen und so eine bestimmte Funktionalität
be-5.1 Testfälle als regelbasierte Programme __________________________________125
schreiben. Je nachdem, auf welcher Granularitätsstufe getestet wird, könnte diese abstrakt beschriebene Funktionalität
• eine Operation,
• eine Reihe von Operationen,
• eine Schnittstelle,
• eine Komponente oder
• eine Systemtransaktion bzw. ein Anwendungsfall sein [Yam98].
Demzufolge lassen sich Testfälle nach der Art des Testobjekts wie in Abbildung 5.2 dargestellt klassifizieren in
• Klassentestfälle,
• Integrationstestfälle und
• Systemtestfälle [Sie96].
System, Teilsysteme
System-testfälle System-testfälle
Komponente
Klasse
Integrations-testfälle
Integrations-testfälle
Klassen-testfälle Klassen-testfälle
erben von
erben von
Abbildung 5.2 Testfallhierarchie
5.1.1 Klassentestfälle
Auf der Klassenebene ist ein Testfall ein Methoden- bzw. Operationsaufruf, und Testdaten stellen konkrete Werte für die Ein-, Aus- und Zustandsvariablen dar, die für die betrachtete Operation relevant sind. Möglicherweise verursacht dieser Ope-rationsaufruf den Aufruf weiterer Operationen, d.h. es wird eine Operationskette ausgelöst. Wichtig für den Klassentest ist, dass die aufgerufenen Operationen in der Klasse unter Test definiert sind. Entweder gehören sie zur Klasse selbst – in der Klasse neu definierte Operationen (member functions) – oder sie gehören zu einer
Oberklasse – geerbte Operationen (inherited functions). Operationen in fremden Klassen dürfen nicht betroffen werden. Wie das zu verhindern ist, ist Sache des Klassentestrahmens.
Die Argumente eines Klassentestfalls sind die Eingangsparameter der aufgerufenen Operationen, der Attribute des Zielobjekts und die Zustände der geerbten Attribute.
Die Ergebnisse sind die veränderten Attribute des Zielobjekts und die Rückgabe-werte bzw. Ausgangsparameter. Insofern, als die Klasse unter Test nicht auf eine Datenbank zugreift, sind alle Argumente im Hauptspeicher. Sie müssen dort auch versorgt werden. Das Gleiche trifft für die Ergebnisse zu. Sie bleiben unsichtbar im Hauptspeicher und müssen dort kontrolliert werden, entweder durch eine visuelle Anzeige, eine Protokollierung oder einen internen Abgleich.
Vor dem Methodenaufruf werden die Attribute initialisiert und die Eingangspara-meter gesetzt. Während der Methodenausführung werden die Ergebnisse fremder Methoden künstlich erzeugt, um den Test auf die eine Klasse zu beschränken. Nach dem Methodenaufruf werden die veränderten Objektzustände abgeglichen und die Ausgangsparameter auf ihre Übereinstimmung mit den erwarteten Ergebnissen kontrolliert. Also muss der Klassentestfall
• die Methode identifizieren, die anzustoßen ist;
• die betroffenen Objektzustände initialisieren;
• die Eingangsparameter setzen;
• die Ergebnisse fremder Methoden vorgeben;
• die veränderten Objektzustände voraussagen und
• die Ausgangsparameter bestimmen [HaWi93].
Normalerweise werden die Klassentestfälle in einer Klassentestprozedur bzw. ei-nem Testskript zusammengefasst, denn eine Klasse hat mehrere Methoden und jede Methode wird mehrere Testfälle haben. So betrachtet ist die Klassentestprozedur ein Baum der Klassentestfälle mit der Struktur:
Klasse {Objekt1-n[Methode1-n(Testfall1-n)]}
Die Beschreibung der Klassentestfälle sollte möglichst an die Zielsprache, z.B.
C++, Java oder Objekt-COBOL angelehnt sein, damit beide Sprachen – Programmiersprache und Testsprache – möglichst kompatibel und die Entwickler nicht gezwungen sind, mit zwei völlig unterschiedlichen Sprachen umzugehen. Die Anzahl der Klassentestfälle kann leicht mehrere hundert pro Klasse betragen, wenn es darum geht, alle Logikzweige in allen Methoden für alle Objektausprägungen auszuprobieren [MTW94]. Die Spezifikation der Klassentestfälle kommt einem zweiten Programm gleich. Dieses zweite Gegenprogramm lässt sich leichter formu-lieren, wenn es in Syntax und Semantik dem ersten Programm ähnelt.
5.1 Testfälle als regelbasierte Programme __________________________________127
5.1.2 Integrationstestfälle
Auf der Stufe des Integrationstests sind Testfälle in der Regel Nachrichten von einer Klasse bzw. Komponente an eine andere. Auch hier werden bestimmte Me-thoden angesteuert, aber die angesteuerten MeMe-thoden gehören nicht nur einer Klasse an. Sie sind verteilt auf mehrere Klassen einer Komponente. Somit ist der Wir-kungsbereich eines Integrationstestfalls größer als der eines Klassentests.
Der Integrationstestfall baut auf einer Schnittstelle auf und zielt auf eine Klassen-menge bzw. eine Komponente. Die Argumente sind die Parameter in der Schnitt-stelle, die globalen Daten bzw. die persistenten Objekte und nicht zuletzt die Inhalte der Datenbanken, auf welche die Komponente zugreift. Simuliert wird nur die Schnittstelle zu der Zielkomponente [NaSa92].
Integrationstestfälle müssen aufeinander aufbauen, um die Initialisierung der inter-nen Datenzustände einer Kompointer-nente bei jedem Testfall zu vermeiden. Denn hier handelt es sich bereits um mehrere hundert Objektattribute zuzüglich der Parame-ter-Werte als Argumente. Das Gleiche trifft für die Ergebnisse zu. Hunderte von Objekten können durch einen einzigen Testfall verändert werden. Es wird kaum möglich sein, alle veränderten Zustände zu kontrollieren. Deshalb beschränkt sich der Integrationstestfall auf die Prüfung der Rückgabewerte.
Im Gegensatz zu den Klassentestfällen, die oft in beliebiger Reihenfolge ausgeführt werden können, müssen die Integrationstestfälle meistens in einer bestimmten Rei-henfolge erfolgen. Z.B. muss ein Konto zuerst eröffnet werden, ehe der erste Betrag eingezahlt wird, und der erste Betrag muss eingezahlt werden, ehe ausgezahlt wird.
Auf diese Weise baut die Komponente ihre eigenen internen Zustände auf. Falls jedoch die Komponente auf bestehende Datenbanken zugreift, sind die Inhalte jener Datenbanken Argumente für die Komponente und müssen vorher generiert werden.
Es kann also vorkommen, dass der Integrationstestfall auch Datenbankattribute betrifft, so wie im folgenden Beispiel:
testcase ueberweisung_04:
Assert post
Überweisung.Empfängername = „Sneed, Stephan“, Überweisung.Empfängerkonto = „10774711“, Überweisung.Empfängerbank = „KSK_Miesbach“, Überweisung.Datum = heutiges Datum,
Überweisung.Betrag = 620,00
if pre Schnittstelle.Sendername = „Sneed, Harry“, Schnittstelle.Senderkonto = 19404712“, Schnittstelle.Senderblz = „71152570“, Schnittstelle.Betrag = 620,00,
Datenbank.Senderbank = KSK_Miesbach, Datenbank.Kontobetrag > 620,00;
Datenbank.Kontotyp = Giro;
Daran ist zu erkennen, dass sich ein Teil der Argumente in der Schnittstelle und ein anderer Teil in der Datenbank befindet. Beide Teile müssen vorbelegt werden, um die erwartete Überweisung zu produzieren.
5.1.3 Systemtestfälle
Klassen- und Integrationstestfälle sind interne Testfälle, die sich auf die Software-Konstruktion beziehen. Daher setzen sie gewisse Kenntnisse der Implementierung, im Fall der Klassentestfälle Kenntnisse der Klassenkonstruktion, im Fall der Integ-rationstestfälle Kenntnisse der Komponentenschnittstellen voraus. Systemtestfälle sind hingegen externe Testfälle, bei denen das System von außen über die Benut-zungsschnittstelle betrachtet wird. Die Argumente sind im Falle von Dialog-Transaktionen die Kontrolltasten, Mausklicks und Textfelder, die der Benutzer eingibt. Die Ergebnisse sind die Textfelder, die angezeigt werden, die Ereignisse, die ausgelöst werden, und die Veränderungen zu den Datenbanken. Bei Batch-Transaktionen sind die Argumente die Bewegungsdaten, die über eine Systemein-gabeschnittstelle einlaufen und eventuell die Parameter, die von irgendeinem Gerät gelesen werden. Die Ergebnisse sind die Exportdateien, die erzeugten Berichte und die veränderten Datenbanken [Bei95].
Systemtestfälle sind auf der einen Seite sehr komplex, weil sie viele Daten in vielen verschiedenen Bereichen betreffen – die Benutzungsoberfläche, die internen Schnittstellen, die persistenten Objekte, die Datenbanken, die Import/Export-Dateien und nicht zuletzt die Berichte. Auf der anderen Seite sind sie einfacher zu formulieren, weil ihre Daten sichtbar sind. Im Gegensatz zum Klassentest kann der Tester sehen, was in das System hineingeht und was herauskommt.
Systemtestfälle beschreiben, welche Ausgaben zu erwarten sind, wenn gewisse Eingaben getätigt werden. Sie stellen eine Beziehung her zwischen dem, was der Benutzer des Systems eingibt, was in der Datenbank vorgespeichert ist und was das System ausgibt bzw. macht. Sie werden in einem Testskript erfasst, das zur Laufzeit entweder von einem menschlichen Tester oder von einem Testautomaten interpre-tiert wird. Von einem solchen Systemtestfall können zahlreiche Einzelfunktionen und etliche hundert Einzeldaten betroffen werden. Daher kommt es darauf an, nur jene Ergebnisse zu kontrollieren, die Aufschluss über die Korrektheit der Transakti-on geben, z.B. die Rückmeldungen am Bildschirm, oder die TransaktiTransakti-onsprotokolle.