Black Box Testverfahren

Äquivalenzklassenbildung teilt Daten so in Äquivalenzklassen auf, dass alle Elemente einer vorgegebenen Äquivalenzklasse erwartungsgemäß in derselben Art und Weise verarbeitet werden. Es gibt Äquivalenzklassen für gültige und ungültige Werte.

Um mit diesem Verfahren eine 100%ige Überdeckung zu erzielen, müssen die Testfälle alle festgelegten Klassen (auch ungültige Klassen) abdecken, indem sie mindestens einen Wert aus jeder Klasse nutzen. Die Überdeckung wird gemessen durch die Anzahl der Äquivalenzklassen, die durch mindestens einen Wert getestet wurden, dividiert durch die Gesamtzahl der identifizierten Äquivalenzklassen, üblicherweise in Prozent ausgedrückt. Äquivalenzklassenbildung kann auf allen Teststufen angewendet werden.

Beispiele finden Sie in den Folien zur ForTeQ-Keynote "Kombinatorik II – Grenzwertanalyse und Bildung von Äquivalenzklassen".

Die Grenzwertanalyse ist eine Erweiterung der Äquivalenzklassenbildung, aber sie kann nur dann genutzt werden, wenn die Klasse geordnet ist und aus numerischen oder sequenziellen Daten besteht. Die Minimum- und Maximum-Werte (oder erste und letzte Werte) einer Klasse sind ihre Grenzwerte.

Beispiel: Ein Eingabefeld akzeptiert einen einstelligen Integer-Wert als Eingabe und nutzt eine Zifferntaste zur Einschränkung der Eingabe, damit nur Integer-Werte als Eingabe möglich sind. Der gültige Bereich reicht von 1 bis einschließlich 5.

Es gibt also drei Äquivalenzklassen: ungültig (zu niedrig), gültig, ungültig (zu hoch).

Für die gültige Äquivalenzklasse sind die Grenzwerte 1 und 5. Für die ungültige (zu hohe) Klasse ist der Grenzwert 6. Für die ungültige (zu niedrige) Klasse gibt es nur einen Grenzwert, 0, da dies eine Klasse mit nur einem Wert ist.

Im obigen Beispiel wurden zwei Grenzwerte pro Grenze identifiziert. Die Grenze zwischen ungültig (zu niedrig) und gültig ergibt die Testwerte 0 und 1. Die Grenze zwischen gültig und ungültig (zu hoch) ergibt die Testwerte 5 und 6. Einige Varianten dieses Verfahrens identifizieren drei Grenzwerte pro Grenze: die Werte vor, auf und gerade über der Grenze. Im vorigen Beispiel würde die Nutzung von drei Grenzwerten zu den niedrigen Testwerten 0, 1 und 2 und zu den höheren Testwerten 4, 5 und 6 führen.

Das Verhalten an den Grenzen der Äquivalenzklasse ist wahrscheinlich eher nicht so korrekt wie das Verhalten innerhalb der Klassen. Es ist wichtig, sich zu vergegenwärtigen, dass sowohl die spezifizierten als auch die implementierten Grenzen über oder unterhalb ihrer eigentlich vorzusehenden Position verschoben, ganz ausgelassen oder mit unerwünschten zusätzlichen Grenzen ergänzt sein können. Grenzwertanalysen und -tests decken fast alle diese Fehlerzustände auf, indem sie die Software provozieren, ein anderes Verhalten zu zeigen, als es für die Klasse zu erwarten wäre, zu der die Grenzwerte gehören.

Grenzwertanalysen können auf allen Teststufen angewandt werden. Dieses Verfahren wird üblicherweise dazu genutzt, Anforderungen zu testen, die eine Reihe von Zahlen (einschließlich Datum und Zeit) enthalten. Grenzwertüberdeckung für eine Klasse wird gemessen als die Anzahl der getesteten Grenzwerte dividiert durch die Gesamtzahl der identifizierten Grenzwerte – meist ausgedrückt als Prozentzahl.

Beispiele finden Sie in den Folien zur ForTeQ-Keynote "Kombinatorik II – Grenzwertanalyse und Bildung von Äquivalenzklassen".

Komponenten oder Systeme können unterschiedlich auf ein Ereignis reagieren, abhängig vom gegenwärtigen Zustand oder von Abläufen in der Vergangenheit (z.B. den Vorgängen, die seit Inbetriebnahme des Systems stattgefunden haben). Die Abläufe in der Vergangenheit können durch das Modell von Zuständen abgebildet werden. Ein Zustandsübergangsdiagramm zeigt zum einen alle möglichen Softwarezustände selbst und dann auch, wie die Software in diesen Zustand eintritt, austritt und zwischen den Zuständen wechselt. Ein Übergang wird durch ein Ereignis hervorgerufen (z.B. Benutzereingabe eines Werts in ein Feld). Das Ereignis führt zu einem Übergang. Das gleiche Ereignis kann zu zwei oder mehreren Übergängen aus dem gleichen Zustand heraus führen. Die Zustandsänderung kann häufig Reaktionen der Software zur Folge haben (z.B. Ausgabe einer Berechnung oder einer Fehlermeldung).

Eine Zustandsübergangstabelle zeigt alle gültigen Übergänge und auch alle ungültigen, aber möglichen Übergänge zwischen Zuständen auf. Außerdem enthält sie alle Ereignisse und zu erwartende Reaktionen der Software für gültige Übergänge. Zustandsübergangsdiagramme zeigen üblicherweise nur die gültigen Übergänge und schließen ungültigen Übergänge aus.

Es werden Tests entworfen, um eine übliche Sequenz von Zuständen abzubilden, um alle Zustände herbeizuführen, um jeden Übergang auszuführen, um spezifische Sequenzen von Übergängen auszuführen oder schließlich um ungültige Übergänge zu testen.

Zustandsübergangstests werden für menügeführte Anwendungen genutzt und häufig in der Softwarebranche für eingebettete Systeme (embedded systems) eingesetzt. Das Verfahren ist auch gut für die Modellerstellung eines Geschäftsszenarios mit spezifischen Zuständen geeignet oder für das Testen der Bildschirmnavigation. Das Konzept eines Zustands ist abstrakt – es kann sich dabei um einige Zeilen Code oder gar um einen gesamten Geschäftsprozess handeln.

Entscheidungstabellen sind sinnvoll, um komplexe Regeln in Geschäftsprozessen zu erfassen, die ein System umzusetzen hat. Bei der Erstellung der Entscheidungstabellen identifiziert der Tester Bedingungen (zumeist Eingaben) und die daraus folgenden Aktionen (zumeist Ausgaben) des Systems. Diese bilden die Zeilen einer Tabelle, üblicherweise dann auch mit den Bedingungen oben und den Aktionen unten. Jede Spalte bezieht sich auf eine Entscheidungsregel, bestehend aus einer spezifischen Kombination von Bedingungen und den damit verbundenen Aktionen. Die Werte der Bedingungen und Aktionen werden üblicherweise als boolesche Werte dargestellt (wahr oder falsch) oder als eigenständige Werte (z.B. rot, grün, blau), können aber auch Zahlen oder Zahlenreihen sein. Derlei unterschiedliche Arten von Bedingungen und Aktionen können auch zusammen in der gleichen Tabelle auftreten.

Die gängige Notation in Entscheidungstabellen sieht wie folgt aus:

Für Bedingungen:

Für Aktionen:

Eine vollständige Entscheidungstabelle hat genau so viele Spalten (Testfälle), dass jede Kombination von Bedingungen abgedeckt ist. Durch das Löschen von Spalten mit Bedingungskombinationen, die das Ergebnis nicht beeinflussen, kann sich die Anzahl der Testfälle erheblich verringern. Zum Beispiel durch das Entfernen von unmöglichen Kombinationen von Bedingungen.

Der übliche Mindestüberdeckungsstandard für Entscheidungstabellentests besteht darin, pro Entscheidungsregel der Tabelle mindestens einen Testfall zu haben. Das beinhaltet üblicherweise das Abdecken aller Kombinationen von Bedingungen. Die Überdeckung wird gemessen als die Anzahl der Entscheidungsregeln, die durch wenigstens einen Testfall getestet wurden, dividiert durch die Gesamtzahl der Entscheidungsregeln – üblicherweise als Prozentzahl dargestellt.

Die Stärke von Entscheidungstabellentests besteht darin, dass sie dabei helfen, alle wichtigen Kombinationen von Bedingungen zu identifizieren, die ansonsten leicht übersehen werden könnten. Sie helfen auch, Lücken in den Anforderungen zu finden. Sie können in jeder Teststufe auf alle Situationen angewendet werden, in denen das Verhalten der Software von einer Kombination von Bedingungen abhängt.

Anwendungsfälle (Use Cases) sind eine spezielle Form, um Interaktionen mit Softwareelementen darzustellen. Sie enthalten Anforderungen an die Softwarefunktionalität. Anwendungsfälle haben Akteure (menschliche Benutzer, externe Hardware oder andere Komponenten oder Systeme) und Objekte (eine Komponente oder das System, auf das der Anwendungsfall angewendet wird).

Jeder Anwendungsfall definiert ein bestimmtes Verhalten, das ein Objekt in Zusammenarbeit mit einem oder mehreren Akteuren ausführen kann. Ein Anwendungsfall kann durch Interaktionen und Aktivitäten sowie durch Vorbedingungen, Nachbedingungen und falls angemessen auch in natürlicher Sprache beschrieben werden. Interaktionen zwischen den Akteuren und dem Objekt können zu Veränderungen des Objektzustands führen. Interaktionen können grafisch durch Workflows, Aktivitätsdiagramme oder Geschäftsprozessmodelle dargestellt werden.

Ein Anwendungsfall besteht aus mehreren möglichen Varianten seines grundlegenden Verhaltens, was u.a. Sonder- und Fehlerbehandlungen einschließt (Antwort- und Wiederherstellungsmechanismen des Systems nach Programmier-, Anwendungs- und Kommunikationsfehler, die z.B. zu Fehlermeldungen führen). Tests werden entworfen, um das definierte Verhalten nachzuweisen (grundlegendes, außergewöhnliches oder alternatives Verhalten und die Fehlerbehandlungsroutinen). Die Überdeckung kann durch den Anteil der getesteten Anwendungsfallvarianten bezogen auf die Gesamtzahl der Anwendungsfallvarianten gemessen werden – und wird üblicherweise als Prozentsatz dargestellt.