- Blackboxtest
-
Black-Box-Test bezeichnet eine Methode des Softwaretests, bei der die Tests ohne Kenntnisse über die innere Funktionsweise des zu testenden Systems entwickelt werden. Er beschränkt sich auf funktionsorientiertes Testen, d. h. für die Ermittlung der Testfälle werden nur die Anforderungen, aber nicht die Implementierung des Testobjekts herangezogen. Die genaue Beschaffenheit des Programms wird nicht betrachtet, sondern vielmehr als Black Box behandelt. Nur nach außen sichtbares Verhalten fließt in den Test ein.
Inhaltsverzeichnis
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.
Die außerdem existierenden Grey-Box-Tests sind ein Ansatz aus dem Extreme Programming, mit Hilfe testgetriebener Entwicklung die gewünschten Vorteile von Black-Box-Tests und White-Box-Tests weitgehend miteinander zu verbinden und gleichzeitig die unerwünschten Nachteile möglichst zu eliminieren.
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 Tests keine Kenntnisse über die innere Funktionsweise des zu testenden Systems haben dürfen, ist bei Black-Box-Tests praktisch ein separates Team zur Entwicklung der Tests nötig. In vielen Unternehmen sind dafür sogar spezielle Testabteilungen zuständig.
Vergleich mit White-Box-Tests
Black-Box-Tests werden 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. Dies kann durch White-Box-Tests leichter aufgedeckt werden, bei Black-Box-Tests nach der nicht auszuschließenden Korrektur nur einer der beiden Fehler jedoch als vermeintliche Regression zu Tage treten.
Im Vergleich zu White-Box-Tests sind Black-Box-Tests wesentlich aufwendiger in der Durchführung, da sie eine größere organisatorische Infrastruktur (eigenes Team) benötigen.
Die Vorteile von Black-Box-Tests gegenüber White-Box-Tests:
- bessere Verifikation des Gesamtsystems
- Testen von semantischen 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:
- größerer organisatorischer Aufwand
- 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
- 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 erfolgreiche Testrichtungen, die sehr erfolgreich damit sind. Vertreter sind z.B. James Bach [1] mit Rapid Testing oder Cem Kaner [2] mit Exploratory Testing (Ad-hoc-Test). Diese Testarten sind also 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 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, ...).
Schadensausmaß-orientiertes Testen (Risikoanalyse)
Man beschränkt sich auf intensives Testen von Funktionen, bei denen Fehler besonders gravierende Folgen haben können (z. B. Verfälschung oder Zerstörung einer umfangreichen Datei / Lebensgefahr für Personen (KFZ, Maschinensteuerungen) etc..).
Diese werden priorisiert oder klassifiziert (1,2,3,...) und dann entsprechend dieser Ordnung getestet.
Siehe auch
Literatur
- BCS SIGIST (British Computer Society Specialist Interest Group in Software Testing): Standard for Software Component Testing, Working Draft 3.4, 27. April 2001.
Wikimedia Foundation.
