Der Benutzer wird am ehesten mit der Software zufrieden sein, wenn Klarheit darüber besteht, welche Erwartungen der
Benutzer hat. Diese Klarheit macht es möglich, die mögliche Erfüllung der Erwartungen zu überprüfen und zu bewerten.
Die zu prüfenden Anforderungen werden in Testfällen dargestellt. Die konkrete Überprüfung dieser Anforderungen kann
jedoch auf verschiedene Weise erfolgen und von verschiedenen Testern vorgenommen werden. Die Ausführung der Software
zur Überprüfung ihrer Funktionen und ihres Durchsatzes könnte beispielsweise ein Tester übernehmen, der zu diesem Zweck
automatisierte Testverfahren anwendet. Das Herunterfahren eines Computersystems könnte mit manuellen Tests und
Beobachtungen überprüft werden. Marktanteil und Umsatz gehören ebenfalls zu den Produktanforderungen und könnten durch
das Bewerten der Absatzzahlen und der Wettbewerbsfähigkeit des Produkts überprüft werden.
Möglicherweise sind Sie nicht in der Lage, alle Anforderungen zu überprüfen, oder nicht für die Überprüfung aller
Anforderungen zuständig. In einer solchen Situation ist es entscheidend für den Erfolg Ihres Projekts, dass Sie für
Ihre Tests die wichtigsten und geeignetsten Anforderungen auswählen. Bei dieser Auswahl gilt es Kosten, Risiken und die
Notwendigkeit für die Überprüfung bestimmter Anforderungen gegeneinander abzuwägen.
Die Festlegung der Testfälle ist aus verschiedenen Gründen sehr wichtig.
-
Testfälle bilden die Grundlage, auf der Test-Scripts entworfen und entwickelt werden.
-
Die Gründlichkeit, mit der getestet wird, ist direkt proportional zur Anzahl der Testfälle. Mit steigender Zahl von
Testfällen wächst das Vertrauen in die Zuverlässigkeit und Qualität des Produkts und des Testprozesses, denn jeder
Testfall stellt ein anderes Szenario, eine andere Bedingung oder einen anderen Ablauf dar.
-
Ein Hauptindikator für die Vollständigkeit der Tests ist die Abdeckung der Anforderungen durch eine bestimmte
Anzahl festgelegter, implementierter und/oder ausgeführter Testfälle. Eine Angabe wie "95 Prozent der kritischen
Testfälle wurden ausgeführt und überprüft" ist aussagekräftiger als "95 Prozent der Tests sind abgeschlossen".
-
Mit wachsender Anzahl von Testfällen steigt auch der Testaufwand. Durch eine umfassende Aufschlüsselung der
Testfälle kann der Zeitbedarf für die aufeinander folgenden Schritte genauer abgeschätzt werden.
-
Welche Arten des Testdesigns und der Testentwicklung zum Einsatz kommen und welche Ressourcen benötigt werden, ist
nicht unwesentlich von den Testfällen abhängig.
Testfälle werden häufig nach Testtypen oder zu testenden Anforderungen kategorisiert bzw. klassifiziert, so dass es ein
breites Spektrum von Testfällen gibt. Es hat sich bewährt, für jede zu testende Anforderung mindestens zwei Testfälle
zu entwickeln:
-
Einen Testfall, der die Erfüllung der Anforderung nachweist. Dieser Testfall wird als positiver Testfall
bezeichnet.
-
Einen anderen Testfall mit inakzeptablen, von der Norm abweichenden oder unerwarteten Bedingungen bzw. Daten, der
demonstriert, dass die Anforderung nur unter den gewünschten Bedingungen erfüllt ist. Solche Testfälle werden
negative Testfälle genannt.
Bei Einheitentests werden die interne Struktur und die Verhaltensmerkmale der Einheit getestet. Für Tests der internen
Struktur sind Kenntnisse zur Implementierung der Einheit erforderlich. Tests, die solche Kenntnisse voraussetzen, sind
so genannte Whitebox-Tests. Beim Testen der Verhaltensmerkmale einer Einheit geht es schwerpunktmäßig um das von außen
beobachtbare Verhalten der Einheit. Diese Tests können ohne Kenntnisse oder Bezug zur Implementierung der Einheit
durchgeführt werden. Auf diesem Ansatz basierende Tests werden als Blackbox-Tests bezeichnet. Nachfolgend wird die
Ableitung von Testfällen für beide Ansätze beschrieben.
Theoretisch müssten Sie jeden möglichen Pfad durch den Code testen. Dieses Ziel ist in der Praxis, von sehr einfachen
Einheiten einmal abgesehen, nur sehr schwer oder gar nicht erreichbar. Zumindest sollten Sie alle
Entscheidungspfade einmal durchgehen, damit jede Anweisung mindestens einmal ausgeführt wird. Eine Entscheidung
ist in der Regel eine Anweisung if, und ein Entscheidungspfad ist der Pfad zwischen zwei Entscheidungen.
Um diese Testabdeckung zu erreichen, sollten Sie die Testdaten so auswählen, dass jede Entscheidung unter allen
möglichen Gesichtspunkten bewertet werden kann. Die entsprechenden Testfälle müssen daher Folgendes sicherstellen:
-
Die Auswertung aller Booleschen Ausdrücke ergibt true und false. Die Auswertung des Ausdrucks
(a<3) OR (b>4) kann beispielsweise vier Kombinationen von true/false ergeben.
-
Jede Endlosschleife wird keinmal, genau einmal und mehrmals ausgeführt.
Mit Tools für Codeabdeckung können Sie den Code identifizieren, der bei Ihren Whitebox-Tests nicht ausgeführt wird.
Parallel zu Ihren Whitebox-Tests sollten Sie Zuverlässigkeitstest durchführen.
Beispiel:
Nehmen wir an, Sie wollen einen Strukturtest für die Funktion Element der Klasse Gruppe ganzer Zahlen
durchführen. Der Test überprüft mittels einer Binärsuche, ob eine bestimmte ganze Zahl in der Gruppe ganzer Zahlen
enthalten ist.
In dieser Abbildung sehen Sie die Elementfunktion und das zugehörige Ablaufdiagramm. Die gestrichelten Pfeile zeigen,
wie Sie mit zwei Testfällen alle Anweisungen mindestens einmal ausführen können.
Um eine Operation gründlich zu testen, müsste der Testfall theoretisch alle Kombinationen von Routen im Code abdecken.
Für die Elementfunktion (member) gibt es innerhalb der while-Schleife drei alternative Routen. Der
Testfall kann die Schleife mehrmals oder keinmal durchlaufen. Wenn der Testfall die Schleife keinmal durchläuft, gibt
es nur eine Route durch den Code. Durchläuft er die Schleife einmal, sind drei Routen vorhanden. Falls der Testfall die
Schleife zweimal durchläuft, gibt es sechs Routen usw. Die Gesamtanzahl der Routenkombinationen ist somit 1 + 3 + 6 +
12 + 24 + 48 +... und in der Praxis nicht zu handhaben. Sie müssen daher eine Teilmenge aus diesen Routen auswählen. Im
vorliegenden Beispiel können Sie alle Anweisungen mit zwei Testfällen ausführen. In einem Testfall können Sie folgende
Testdaten auswählen: Gruppe ganzer Zahlen = {1,5,7,8,11} und t = 3 . Für den
anderen Testfall können Sie Folgendes auswählen: Gruppe ganzer Zahlen = {1,5,7,8,11} und
t = 8 .
Weitere Informationen hierzu finden Sie im Abschnitt Verfahren:
Einheitentest.
Blackbox-Tests
Blackbox-Tests werden eingesetzt, um die spezifizierten Verhalten der Einheit zu überprüfen, ohne darauf zu achten,
wie die Einheit dieses Verhalten implementiert. Blackbox-Tests konzentrieren sich auf die Ein- und Ausgaben der
Einheit.
Äquivalenzklassenbildung ist ein Verfahren, mit dem die Anzahl der erforderlichen Tests reduziert werden kann.
Sie sollten für jede Operation die Äquivalenzklassen der Argumente und Objektzustände festlegen. Eine
Äquivalenzklasse ist eine Gruppe von Werten, bei denen sich ein Objekt gleichartig verhält. Eine Menge
kann beispielsweise die drei Äquivalenzklassen leer, einige Elemente und voll haben.
Mit Tools für Codeabdeckung können Sie den Code identifizieren, der bei Ihren Whitebox-Tests nicht ausgeführt wird.
Parallel zu Ihren Blackbox-Tests sollten Sie Zuverlässigkeitstest durchführen.
Die beiden folgenden Absätze beschreiben die Auswahl von Testdaten für spezifische Argumente zur Festlegung von
Testfällen.
Auf Eingabeargumenten basierende Testfälle
Ein Eingabeargument ist ein von einer Operation verwendetes Argument. Beim Erstellen von Testfällen sollten Sie
für alle Operationen Eingabeargumente für jede der folgenden Eingabebedingungen verwenden:
-
Normalwerte jeder Äquivalenzklasse
-
Grenzwerte jeder Äquivalenzklasse
-
Werte außerhalb der Äquivalenzklassen
-
unzulässige Werte
Vergessen Sie nicht, dass der Objektzustand auch als ein Eingabeargument anzusehen ist. Wenn Sie beispielsweise die
Operation Hinzufügen für das Objekt Menge testen möchten, müssen Sie Hinzufügen mit Werten aus
allen Äquivalenzklassen von Menge testen, also mit der vollen Menge, mit einigen Elementen in der
Menge und mit einer leeren Menge.
Auf Ausgabeargumenten basierende Testfälle
Ein Ausgabeargument ist ein Argument, das von einer Operation geändert wird. Ein Argument kann gleichzeitig
Eingabe- und Ausgabeargument sein. Wählen Sie die Eingaben so aus, dass Sie Ausgaben für alle nachfolgend
genannten Werte erhalten.
-
Normalwerte jeder Äquivalenzklasse
-
Grenzwerte jeder Äquivalenzklasse
-
Werte außerhalb der Äquivalenzklassen
-
unzulässige Werte
Vergessen Sie nicht, dass der Objektzustand auch als ein Ausgabeargument anzusehen ist. Wenn Sie beispielsweise die
Operation Entfernen für eine Liste testen möchten, müssen Sie die Eingabewerte so wählen, dass die
Liste nach Ausführung der Operation (also nach einem Test mit Werten aus allen Äquivalenzklassen) voll ist,
einige Einträge enthält oder leer ist.
Wenn es sich um ein zustandsgesteuertes Objekt handelt (ein Objekt, das je nach Zustand anders reagiert), sollten Sie
eine Zustandsmatrix wie in der folgenden Abbildung verwenden.
Zustandsmatrix für Tests. Ausgehend von dieser Matrix können Sie alle Kombinationen aus Zuständen und Stimuli testen.
Weitere Informationen hierzu finden Sie im Abschnitt Verfahren:
Einheitentest.
|