Grey-Box-Testing: entwicklungsnah testen
Im folgenden Beitrag gibt es eine Einführung ins Thema Testing , es werden die beiden etablierten Methoden des Black-Box- und White-Box-Testens und die Form des „Grey-Box-Testens“ gegenüber gestellt.
Black-Box oder White-Box?
Kritische Fehler, die erst im Rahmen des Live-Betriebs öffentlich werden, stellen nicht zuletzt eine negative Werbung für ein Produkt und die beteiligten Unternehmen dar. Um dies zu verhindern, ist das Thema „Test“ in der modernen Softwareentwicklung ein grundlegender und integraler Bestandteil.
Nur durch eine hohe Testabdeckung und der zeitnahen Rückmeldung von Ergebnissen lässt sich die Qualität und Reife des Produktes ausreichend genau nachweisen und bestätigen. Dabei werden von den Beteiligten verschiedenen Testvorgehen und Testarten eingesetzt, wie Unittests durch die Entwickler oder Abnahmetests durch die Kunden. Für die unterschiedlichen Testarten wurde bereits früh versucht, übergreifende Kategorien zu finden, wie zum Beispiel die Abgrenzung in Black-Box- und White-Box-Tests.
Laut dem German Testing Board versteht man unter Black-Box-Testen „funktionales oder nicht-funktionales Testen ohne Nutzung von Informationen über Interna eines Systems oder einer Komponente“ und unter White-Box-Testen einen „Test, der auf der Analyse der internen Struktur einer Komponente oder eines Systems basiert“.
Grey-Box-Testing
Vor ein paar Jahren ließen sich Black- und Whitebox-Testverfahren fast synonym zu zwei anderen Einteilungen benutzen: dem dynamischen Test, der „Prüfung des Testobjekts durch Ausführung auf einem Rechner“, und dem statischer Test, dem „Testen von Software-Entwicklungsartefakten, z.B. Anforderungen oder Quelltext, ohne diese auszuführen, z.B. durch Reviews oder statische Analyse“.
Heute lässt sich diese Unterscheidung nicht mehr treffen, da Unit-Tests oder Testvorgehen wie Test-Driven-Development (TDD) die eigentliche Abgrenzung zwischen White- und Blackboxtests aufgelöst haben. Dieser Bereich wird typischerweise als „Grey-Box-Test“ bezeichnet. Grey-Box-Tests versuchen, die gewünschten Vorteile von Black-Box-Tests (spezifikationsgetrieben) und White-Box-Tests (entwicklergetrieben) weitgehend miteinander zu verbinden und gleichzeitig die unerwünschten Nachteile möglichst zu eliminieren.
Der Vorteil ist, dass Teilkomponenten und Gesamtsysteme mit dem geringen organisatorischen Aufwand der White-Box-Tests geprüft werden können, ohne eventuell „um Fehler herum“ zu testen. So werden bei TDD die Komponententests anhand der Spezifikation vor der eigentlichen Entwicklung des Codes erstellt. Die Entwicklung der Komponenten wird erst abgeschlossen, wenn alle Prüfroutinen erfolgreich durchlaufen wurden.
Neben den Vorteilen gibt es aber auch ein paar wichtige Aspekte zu beachten: TDD bzw. die Grey-Box-Tests erfordern eine hohe Disziplin, um praktikabel und erfolgreich einsetzbar zu sein, und Grey-Box-Tests sollten nicht unbedacht als vollwertiger Ersatz für Black-Box-Tests gesehen werden.
Warum sollte man sich nicht auf Grey-Box-Tests verlassen?
Grey-Box-Tests verändern und beeinflussen das System, das Sie prüfen sollten. Dieser Aspekt ergibt sich aus der Natur des Tests. Denn was ist ein Test eigentlich? Er ist im Grunde ein empirischer Beweis. Wir stellen eine Hypothese auf und überprüfen diese in einem Experiment. Und in Analogie zu physikalischen Experimenten gilt auch für Softwaretests, dass je mehr ich mich dem Testobjekt nähere, das Ergebnis des Tests dadurch beeinflusst werden kann. Black-Box-Tests werden auf eigenen Testumgebungen durchgeführt, die einen ähnlichen Aufbau wie die Produktionsumgebung aufweisen sollten. Trotzdem bleibt es „ein Versuchsaufbau“. Es werden Mocks für fehlende Komponenten eingesetzt und der Log-Level erhöht, um mehr Informationen zu erhalten.
Grey-Box-Tests, also codenahe Tests, bei denen die zu testende Software ganz oder teilweise ausgeführt wird, sind nicht nur sehr nahe am Testobjekt. Sie erweitern die Codebasis um neue Bestandteile. Es werden neue Zeilen Testcode geschrieben und Testframeworks eingebunden. Die Auswirkung kann sein, dass bestimmte Fehlerwirkungen erst dadurch erzeugt oder, noch schlimmer, dadurch verschleiert werden bzw. nicht auftreten. Darum ist es wichtig, das Werkzeug und dessen Besonderheiten zu kennen sowie ein Bewusstsein für mögliche Fehlermaskierung durch die Codenähe der Tests zu haben. Dieses Risiko kann aber durch andere ergänzende Testarten minimiert werden.