Nicht nur schwarz und weiß

Grey-Box-Testing: entwicklungsnah testen

Kay Grebenstein

In seiner diesjährigen W-JAX-Session stellt Kay Grebenstein (Saxonia Systems AG) Testwerkzeuge für JavaFX vor und bewertet diese aus Sicht von Entwicklern und Testern. Im folgenden Beitrag gibt er eine Einführung ins Thema und stellt den beiden etablierten Methoden des Black-Box- und White-Box-Testens die Form des „Grey-Box-Testens“ gegenüber.

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. Ich bezeichne den neuen Bereich als „Grey-Box-Test“. 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.

Testen auf der W-JAX

In meinem W-JAX-Vortrag „Testwerkzeuge für JavaFX“ stelle ich verschiedene Testwerkzeuge zur Testautomatisierung für JavaFX vor und vergleiche diese anhand von Kriterien aus der Sicht von Entwicklern als auch Testern. Dabei geht es neben der reinen Unterstützung der Technologie auch um die Erlernbarkeit, die Testauswertung oder die Frage des Supports.

Testwerkzeuge für JavaFX
Mittwoch, November 4, 2015 – 17:45 bis 18:45Softwareentwicklungsprojekte leben vom Einsatz von modernen Werkzeugen, die die Projektbeteiligten bei ihrer Arbeit unterstützen. JavaFX-Entwicklungsprojekte haben hier eine besondere Herausforderung. Die „neue“ Technologie stellt eine Herausforderung an die Testwerkzeuge, speziell an die Werkzeuge zur Testautomatisierung. Viele Hersteller werben mit JavaFX-Unterstützung, aber nicht immer wird JavaFX vollständig unterstützt. Der Vortrag geht den Fragen nach: Welche Kategorien von Testwerkzeugen für JavaFX gibt es? Welche Unterschiede gibt es zwischen den Testwerkzeugen? Wie werden die Testwerkzeuge in meine Toolkette eingebunden?
Geschrieben von
Kay Grebenstein
Kay Grebenstein
Kay Grebenstein arbeitet als Testmanager und Gruppenleiter für die Saxiona Systems AG, Dresden. Er hat in den letzten Jahren in Projekten unterschiedlicher fachlicher Domänen (Telekommunikation, Industrie, Versandhandel, Energie, …) Qualität gesichert und Software getestet.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: