Black-Box-Test
Black-Box-Test bezeichnet eine Methode des Softwaretests. Hierbei werden Tests anhand der Spezifikation/Anforderung entwickelt. Dies bedeutet, dass Tests ohne Kenntnisse über die innere Funktionsweise/Implementierung des zu testenden Systems entwickelt werden. Das zu testende Programm wird also als Black Box behandelt. Nur nach außen sichtbares Verhalten fließt in den Test ein. Im Gegensatz dazu werden White-Box-Tests mit Blick auf den implementierten Algorithmus entwickelt.
Zielsetzung
Ziel ist es, die Übereinstimmung eines Softwaresystems mit seiner Spezifikation zu überprüfen. Ausgehend von formalen oder informalen Spezifikationen werden Testfälle erarbeitet, die sicherstellen, dass der geforderte Funktionsumfang eingehalten wird. Das zu testende System wird dabei als Ganzes betrachtet, nur sein Außenverhalten wird bei der Bewertung der Testergebnisse herangezogen.
Testfälle aus einer informalen Spezifikation abzuleiten, ist vergleichsweise aufwändig und je nach Präzisionsgrad der Spezifikation u. U. nicht möglich. Oft ist daher ein vollständiger Black-Box-Test ebenso wenig wirtschaftlich wie ein vollständiger White-Box-Test.
Auch ist ein erfolgreicher Black-Box-Test keine Garantie für die Fehlerfreiheit der Software, da in frühen Phasen des Softwareentwurfs erstellte Spezifikationen spätere Detail- und Implementationsentscheidungen nicht abdecken.
Black-Box-Tests verhindern, dass Programmierer Tests „um ihre eigenen Fehler herum“ entwickeln und somit Lücken in der Implementierung übersehen. Ein Entwickler, der Kenntnisse über die innere Funktionsweise eines Systems besitzt, könnte unabsichtlich durch gewisse zusätzliche Annahmen, die außerhalb der Spezifikation liegen, einige Dinge in den Tests vergessen oder anders als die Spezifikation sehen. Als weitere nützliche Eigenschaft eignen sich Black-Box-Tests auch als zusätzliche Stütze zum Überprüfen der Spezifikation auf Vollständigkeit, da eine unvollständige Spezifikation häufig Fragen bei der Entwicklung der Tests aufwirft.
Weil die Entwickler der Black-Box-Tests idealerweise keine Kenntnisse über die innere Funktionsweise des zu testenden Systems haben dürfen, sollten Black-Box-Tests durch andere Personen entwickelt werden, als der Code. Das kann durch andere Entwickler durch explizite Tester im selben Team oder sogar spezielle Testabteilungen gemacht werden.
Vergleich mit White-Box-Tests
Black-Box-Tests werden beispielsweise eingesetzt um Fehler gegenüber der Spezifikation aufzudecken, sind aber kaum geeignet, um Fehler in bestimmten Komponenten oder gar die fehlerauslösende Komponente selbst zu identifizieren. Für letzteres benötigt man White-Box-Tests. Zu bedenken ist auch, dass zwei Fehler in zwei Komponenten sich zu einem vorübergehend scheinbar korrekten Gesamtsystem aufheben könnten.
Die Vorteile von Black-Box-Tests gegenüber White-Box-Tests:
- bessere Verifikation des Gesamtsystems
- Testen von bedeutungsmäßigen Eigenschaften bei geeigneter Spezifikation
- Portabilität von systematisch erstellten Testsequenzen auf plattformunabhängige Implementierungen
Die Nachteile von Black-Box-Tests gegenüber White-Box-Tests:
- zusätzlich eingefügte Funktionen bei der Implementierung werden nur durch Zufall getestet
- Testsequenzen einer unzureichenden Spezifikation sind unbrauchbar
Zudem sei genannt, dass die Unterscheidung Black-Box-Test vs. White-Box-Test teilweise von der Perspektive abhängt. Das Testen einer Teilkomponente ist aus Sicht des Gesamtsystems ein White-Box-Test, da für das Gesamtsystem aus der Außenperspektive keine Kenntnisse über den Systemaufbau und damit die vorhandenen Teilkomponenten vorliegen. Aus Sicht der Teilkomponente wiederum kann derselbe Test unter Umständen als Black-Box-Test betrachtet werden, wenn er ohne Kenntnisse über die Interna der Teilkomponente entwickelt und durchgeführt wird.
Auswahl der Testfälle
Die Anzahl der Testfälle einer systematisch erstellten Testsequenz, auf Basis einer geeigneten Spezifikation, ist in fast allen Anwendungen für die Praxis zu hoch. Es gibt z. B. folgende Möglichkeiten, diese systematisch zu verringern:
- Grenzwerte und spezielle Werte,
- Äquivalenzklassenmethode, Klassifikationsbaum-Methode,
- (simplifizierte) Entscheidungstabellen
- zustandsbezogene Tests,
- use case Tests,
- Ursache- und Wirkungsgrad
- Auffinden von Robustheits- und Sicherheitsproblemen Fuzzing
- Risikoanalyse bzw. Priorisierung der Anwendung der gewünschten Ergebnisse (wichtige bzw. unwichtige Funktionen).
Im Gegensatz dazu kann die Reduktion auch auf intuitive Weise (Error Guessing) durchgeführt werden. Von dieser Methode sollte allerdings Abstand genommen werden, da hier immer unbewusst Annahmen berücksichtigt werden, die sich bei der späteren Anwendung der Applikation als negativ herausstellen können. Es gibt aber auch andere Testrichtungen, die sehr erfolgreich damit sind. Vertreter sind z. B. James Bach mit Rapid Testing[1] oder Cem Kaner mit explorativem Testen. Diese Testarten sind den erfahrungsbasierten oder auch unsystematischen Techniken zuzuordnen. Dazu gehört auch schwachstellenorientiertes Testen.
Repräsentatives Testen
Alle Funktionen werden entsprechend der Häufigkeit, mit der sie später im Einsatz sein werden, getestet.
Schwachstellen-orientiertes Testen
Man beschränkt sich häufig nur auf intensives Testen jener Funktionen, bei denen die Wahrscheinlichkeit eines Auftretens von Fehlern hoch ist (komplexe Algorithmen, Teile mit ungenügender Spezifikation, Teile von unerfahrenen Programmierern …). Intensivere Tests können mit Fuzzing-Werkzeugen durchgeführt werden, da diese eine weitestgehende Automatisierung der Robustheits- und Schwachstellen-Tests erlauben. Die Ergebnisse dieser Tests sind dann Informationen über Datenpakete, die das SUT (System under Test) kompromittieren können. Schwachstellen-Tests können z. B. durch Vulnerability Scanner oder Fuzzer durchgeführt werden.
Risikoanalyse
Das am Risiko basierte (Schadenausmaß-orientierte) Testen beschränkt sich auf einen eingehenden Test von Funktionen, wo Fehler besonders gravierende Folgen haben können. Beispiele hierfür sind die Verfälschung wie Zerstörung einer umfangreichen Datei sowie Systemanwendungen auf Leben (Medizin, Kraftfahrzeuge oder Maschinensteuerung) oder Tod (Verteidigung). Diese werden nach Prioritäten oder Klassen (1, 2, 3 …) gereiht und dieser Ordnung folgend getestet.
Siehe auch
Literatur
- BCS SIGIST (British Computer Society Specialist Interest Group in Software Testing): Standard for Software Component Testing (ZIP; 340 kB), Working Draft 3.4, 27. April 2001.
- Harry M. Sneed, Manfred Baumgartner, Richard Seidl: Der Systemtest. Von den Anforderungen zum Qualitätsnachweis. 3., aktualisierte und erweiterte Auflage. Carl Hanser, München 2012, ISBN 978-3-446-42692-4.
Einzelnachweise
- Erika Bach Good: James Bach - Satisfice, Inc. Abgerufen am 24. Juni 2018.