Black-Box-Test

aus Wikipedia, der freien Enzyklopädie

Black-Box-Test bezeichnet eine Methode des Software-Tests, 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 wird nur die Spezifikation (gewünschte Wirkung), 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 1 Zielsetzung 2 Vergleich mit White-Box-Tests 3 Soziale Aspekte 4 Auswahl der Testfälle 4.1 Repräsentatives Testen 4.2 Schwachstellen-orientiertes Testen 4.3 Schadensausmaß-orientiertes Testen (Risikoanalyse) 5 Siehe auch 6 Literatur

[Bearbeiten] 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 ebensowenig 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 vermeiden, 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.

[Bearbeiten] Vergleich mit White-Box-Tests

Weder sind Black-Box-Tests ein Ersatz für White-Box-Tests, noch umgekehrt. 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 als mit White-Box-Tests
• Überprüfen der Spezifikation
• Kein Testen "um Fehler herum"
• 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
• Soziale Aspekte (siehe unten)

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.

[Bearbeiten] Soziale Aspekte

In der Praxis zeigen sich leider immer wieder soziale Aspekte bei der Umsetzung von Black-Box-Tests. Black-Box-Tests liefern messbare Ergebnisse in Zahlen und Fakten, die man einfach ausgedrückt als Produkt von Testumfang und Fehlergrad betrachten kann. Besonders umfangreiche Black-Box-Tests lassen Systeme schlechter aussehen als sie sind, lückenhafte Black-Box-Tests lassen Systeme besser aussehen als sie sind.

Vergleiche zwischen verschiedenen Produkten oder verschiedenen Abteilungen werden in der Praxis dabei gewollt oder ungewollt auf eben diesen subjektiven Ergebnissen angestellt, wobei die Nichteinbeziehung weiterer zu berücksichtigender Faktoren wie unterschiedlicher Spezifikationen in Qualität und Umfang das Ergebnis in einem einseitigen Licht darstellt.

Dies führt häufig zu sozialen Spannungen zwischen Testern und Entwicklern oder Entwicklern unterschiedlicher Abteilungen. Starke soziale Spannungen dieser Art sind jedoch kein Grund, auf Black-Box-Tests zu verzichten, sondern deuten vielmehr auf ein mangelndes Verständnis für Tests und ihre Notwendigkeit, also ein mangelndes Qualitätsbewusstsein hin. Es ist ein Kennzeichen guter Führung in der Software-Entwicklung, diese Spannungen durch Motivation in Bezug auf die Softwarequalität zu reduzieren und die verbleibenden Spannungen positiv zu Gunsten aller Beteiligter zu kanalisieren.

Besonders sollte darauf geachtet werden, dass von Entwicklern gelieferte Software nicht aus Zeitgründen verfrüht und noch fehlerhaft zu den Testern gelangt, die meist am Ende des Projektes stehen und somit Projekte zeitlich gefährden, da in den meisten Planungen, zeitaufwendige Fehlersuche in Verbindung mit Entwicklern nicht einplanbar sind, da die Entwickler schon an anderen Projekten arbeiten und keine Zeit für Fehlersuche haben.

[Bearbeiten] 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 / Priorisierung der Anwendung der gewünschten Ergebnisse (Wichtige / unwichtige Funktionen)

Im Gegensatz dazu kann die Reduktion auch auf intuitive (Error Guessing) Weise durchgeführt werden. Von dieser Methode sollte allerdings Abstand genommen werden, da hier immer unbewußt Annahmen berücksichtigt werden, die sich bei der späteren Anwendung der Applikation als negativ herausstellen können. Es gibt aber auch andere erfolgreiche Test-Richtungen, die sehr erfolgreich damit sind. Vertreter sind z.B. James Bach [1] mit Rapid Testing oder Cem Kaner [2] mit Exploratory Testing (ad-hoc-Testen). Diese Testarten sind also den erfahrungsbasierten oder auch unsystematischen Techniken zuzuordnen. Dazu gehört auch schwachstellenorientiertes Testen.

[Bearbeiten] Repräsentatives Testen

Alle Funktionen werden entsprechend der Häufigkeit, mit der sie später im Einsatz sein werden, getestet.

[Bearbeiten] 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, ...).

[Bearbeiten] 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.

[Bearbeiten] Siehe auch

• Äquivalenzklassentest
• Smoketest
• Systemtest
• Testmethoden

[Bearbeiten] Literatur

• BCS SIGIST (British Computer Society Specialist Interest Group in Software Testing): Standard for Software Component Testing, Working Draft 3.4, 27. April 2001.