Kämpfen Sie mit versteckten Fehlern, die die Leistung Ihrer Software beeinträchtigen? White-Box-Testing ist der Schlüssel, um diese Probleme aufzudecken, indem die innere Funktionsweise Ihres Codes untersucht wird. Aber wie unterscheidet es sich von Grey-Box- oder Black-Box-Testing? Warum sollten Sie sich für White-Box-Testing entscheiden? Dieser Leitfaden beantwortet diese Fragen und zeigt, warum White-Box-Testing für eine robuste Software-Qualitätssicherung unverzichtbar sein könnte.
Hier ist alles, was Ihr Team braucht, um White-Box-Testing zu verstehen und effektiv anzuwenden 👇
White-Box-Testing gibt Testern vollständige Einblicke in den Code und ermöglicht es Ihrem Team, Logik, Datenfluss und Sicherheit auf einer Ebene zu überprüfen, die Black-Box-Testing nicht erreichen kann.Die wichtigste Voraussetzung für diese Art von Tests ist, dass Sie über umfassende Kenntnisse des Quellcodes verfügen müssen. Außerdem müssen Sie sich eingehend mit der Software, den Netzwerken, den Anwendungen und dem Systemzugang im Allgemeinen befassen.
Sie sollten White-Box-Tests zunächst auf Entwickler ausrichten – sie kennen die Codebasis wie ihre Westentasche. Aber hier ist, was viele Teams übersehen: erfahrene QS-Tester können ebenfalls unterstützen, besonders wenn sie die Architektur verstehen. Erstellen Sie zunächst eine Übersicht Ihrer kritischen Codepfade, bevor Sie überhaupt Testfälle schreiben. Dadurch lassen sich bis zu 40% mehr Logikfehler im Vorfeld abfangen. Ihr Hauptziel ist es sicherzustellen, dass Daten korrekt durch jede Funktion fließen und dass Ihre gewählten Datenstrukturen tatsächlich unter Druck funktionieren.
Lassen Sie Entwickler die QS zunächst durch die komplexesten Module führen. Dies verhindert den häufigen Fehler, oberflächliche Funktionalität zu testen, während tiefere architektonische Schwächen übersehen werden.
Mit der White-Box-Methode können die nächsten Themen in der Software hervorgehoben werden:
Alle diese Themen helfen Ihnen, die Infrastruktur von Softwarelösungen und die interne Codierung zu testen. Glass-Box-Testing, Clear-Box-Testing, Transparent-Box-Testing, Open-Box-Testing oder Code-basiertes Testen – all das sind nur andere Namen für die White-Box-Testing-Technik.
Stellen Sie sich vor, ein Kunde hat Sie eingeladen, seine Galerie zu testen. Sie kommen in einen gut beleuchteten Raum mit vielen Gemälden; man sagt Ihnen, wo Sie das Licht aus- und einschalten sollen, wo der Eingang ist, wo der Kunde sein Geld aufbewahrt oder sogar, wie seine Rohrsysteme aussehen. Sie geben Ihnen ein vollständiges Bild, bevor Sie mit dem Schreiben Ihres Testfalls beginnen können.
Sie sehen sich um und stellen fest, dass eines der Rohre undicht ist, es tropft auf eines der Gemälde, und es besteht die Möglichkeit, dass dies einen Kurzschluss verursacht. Also informieren Sie den Kunden über diese Probleme, um mögliche Probleme vor der Eröffnung der Galerie zu vermeiden. Dies ist die Schlüsselfunktion der White-Box-Tests.
Es handelt sich jedoch nicht nur um eine einzige Software-Testmethode. So gibt es beispielsweise eine gegenteilige Testmethode – das Black-Box-Testing. Der Grundgedanke dieser Tests besteht darin, reale Bedrohungen und Risiken zu simulieren, aber Sie dürfen nur bestimmte Teile testen, zu denen Sie Zugang haben.
Wenn wir von Black-Box-Tests sprechen, können Sie Ihre Daten in das System oder dessen Teil eingeben, ohne dessen interne Struktur und Mechanismen zu kennen, und durch Beobachtung der Ausgabe entscheiden Sie, ob alles korrekt funktioniert oder nicht.
Kommen wir zurück zu unserem Galerie-Beispiel und wie Black-Box-Tests dort funktionieren würden. Sie stellen sich direkt an den Eingang und schalten Licht, Gas und Wasser ein. Sie verbringen 30 Minuten darin, und wenn Sie kein Gasleck riechen können, keinen Rauch aus der Eingangstür kommen sehen und der Boden noch trocken ist, können Sie davon ausgehen, dass die Systeme einwandfrei funktionieren.
Man kann also das Innenleben der Software oder der Softwareanwendung nicht sehen. Keine der internen Komponenten oder Teile der internen Strukturen sind bekannt, die Kodierungsprozesse sind verborgen. In dieser Situation geht es bei diesem Ansatz darum, die Erfahrung des Endbenutzers zu testen, während man in der Lage ist, alle oder bestimmte Teile des Anwendungscodes, des Systems oder seiner Einheit zu testen. Dies kann durch Hinzufügen einer Eingabe und Beobachten der Ausgabe geschehen.
Es gibt noch einen dritten Ansatz beim Testen – das Grey-Box-Testen. Dabei handelt es sich um eine Kombination der beiden anderen Methoden – sowohl Black-Box-Tests als auch White-Box-Tests -, bei denen der QS-Tester über einige Kenntnisse des internen Systems verfügt. Sie wissen zum Beispiel, dass Wasser auf das Gemälde tropft, aber Sie wissen nicht, wie das Rohrleitungssystem konfiguriert ist.
Nachdem wir nun die verschiedenen Testmethoden kennen, wollen wir uns nun ausführlich mit dem White-Box-Testing befassen. Warum ist es so beliebt, und was beinhaltet es?
White-Box-Testing bietet eine tiefere Abdeckung als die meisten anderen Methoden und bringt gleichzeitig Kompromisse mit sich, die Ihr Team abwägen sollte, bevor es sich dafür entscheidet.
Erfolgreiche Vorbeugung hängt davon ab, wo Sie sich als Tester engagieren. Wenn Sie in der Lage sind, neue Systeme, Anwendungen, Netzwerke oder Infrastrukturen während der Entwicklungs- und der ersten Einführungsphase oder sogar direkt nach der Einführung zu testen, haben Sie immer noch die Möglichkeit, Ihr Team vor potenziellen Risiken zu warnen.
Technisches Fachwissen spielt beim White-Box-Testing eine große Rolle, aber selbst wenn Sie über keine technischen Kenntnisse verfügen, wird Sie das nicht davon abhalten, so viele Fehler wie möglich zu finden.
Sie können auch Fehler im verborgenen Code aufspüren, was bei Blackbox-Tests eine Herausforderung darstellt. Und je früher man sie im Lebenszyklus der Softwareentwicklung findet, desto schneller können die Softwareentwickler verhindern, dass diese Fehler in die Produktion einfließen.
Jeder, der White-Box-Tests verwendet, weiß, wie umfangreich sie sind. Sie können das Gesamtbild von Anfang an sehen und die anfälligsten Teile auf Fehler überprüfen. Sie brauchen nicht zu warten, bis die Designer mit der grafischen Benutzeroberfläche fertig sind. Sie können den Entwicklern helfen, die Anzahl der Codezeilen in ihrer Anwendung oder Software im Allgemeinen zu reduzieren, und diese Art von Tests lässt sich leicht automatisieren.
Auch wenn die Nachteile von White-Box-Tests nicht allzu kritisch sind, können sie dennoch dazu führen, dass Sie Ihre Meinung zugunsten einer anderen Methode wie Black-Box-Tests oder Grey-Box-Tests ändern.
Hier sind einige Nachteile, die Sie ebenfalls berücksichtigen sollten.
White-Box-Tests sind oft eine zeitaufwändige Methode. Die Anzahl der möglichen Szenarien, der Codezeilen, aller Pfade usw. kann den Testprozess um Tage, Wochen oder sogar Monate verlängern.
Man muss gründlich sein und jeden Teil einer Anwendung oder einer internen Struktur überprüfen, dies mit den Entwicklern verifizieren und das Produkt aus verschiedenen Perspektiven betrachten, bis alle davon überzeugt sind, dass der Testprozess korrekt abgeschlossen wurde.
Im April 2020 fand der indische Sicherheitsforscher Bhavuk Jain eine kritische Schwachstelle in der Apple-Software, und zwar bei „Sign in with Apple“. Dieser übersehene Fehler könnte es jemandem ermöglichen, mit nur einer E-Mail auf ein Konto oder das System zuzugreifen. Diese Schwachstelle war die ganze Zeit an der Oberfläche, aber sie war kritisch genug. Deshalb musste Apple dem Mann, der diese Schwachstelle entdeckt hatte, 100.000 Dollar zahlen.
Natürlich könnte das Unternehmen dieses Geld sparen, wenn ein QS-Tester kleinere Dinge vor der Markteinführung überprüfen würde. Dies ist ein hervorragendes Beispiel dafür, was passieren kann, wenn wir „einfache“ Fehler nicht im Auge behalten. Und dies ist einer der Nachteile von White-Box-Tests. Diese Methode kann das Auftreten kleinerer Fehler begünstigen, da sie hauptsächlich auf menschlicher Basis durchgeführt wird. Die Tester konzentrieren sich darauf, wie das Produkt im Allgemeinen funktioniert, und achten nicht auf die kleinsten Details.
White-Box-Tests sind eine teure und komplexe Methode. Die hohen Kosten sind durch die hohe Bezahlung der QS-Tester gerechtfertigt, die mehrere Programmiersprachen beherrschen und über die nötige Erfahrung für diese Art von Tests verfügen. Hinzu kommen noch die Kosten für die Zeit, die die Tester dafür aufwenden müssen.
Wenn die Nachteile von White Box Testing Sie nicht abschrecken und Sie immer noch bereit sind, mit ihm zu gehen, lassen Sie uns sehen, welche Arten von dieser Methode gibt es.
White-Box-Testing ist am wertvollsten, wenn Ihr Team Zugang zum Code hat und Verhalten überprüfen muss, das externe Tests nicht erreichen können.
White-Box-Testing ist nicht für jede Situation geeignet. Es erzeugt Overhead für Teams ohne Code-Zugang und ist weniger nützlich, wenn die primäre Sorge die Benutzererfahrung ist.
Bevor wir uns mit White-Box-Tests befassen, sollten Sie wissen, dass dies nur eine von vielen Methoden zur Validierung Ihrer Software ist. Wir haben 20 Jahre QS-Erfahrung in einer Teststrategievorlage zusammengefasst, die sowohl das Wissen als auch die Formatierung enthält, um Ihre Testverfahren zu gestalten.
Holen Sie sich eine Vorlage für eine Teststrategie, die es uns ermöglicht, Software 2 Mal so schnell zu veröffentlichen
Die wichtigsten Arten von White-Box-Tests entsprechen bestimmten Phasen Ihres Entwicklungszyklus, und die Wahl des richtigen Zeitpunkts bestimmt, wie viel Abdeckung Ihr Team tatsächlich erreicht. Beginnen Sie mit Unit-Tests – durchleuchten Sie einzelne Funktionen, um Fehler früh zu erkennen. Dies spart später fast dreimal mehr Debugging-Zeit. Dann gehen Sie zu Integrationstests über, wo Sie überprüfen, dass Ihre Module tatsächlich ordnungsgemäß miteinander kommunizieren – ein häufiger Fehler ist anzunehmen, dass sie es ohne Tests tun werden. Schließlich führen Sie Regressionstests durch, wann immer Sie Änderungen vornehmen.
Wählen Sie eine kritische Funktion in Ihrem aktuellen Projekt aus und schreiben Sie einen einfachen Test, der ihre internen Logikpfade untersucht. Verfolgen Sie, wie viele Grenzfälle Sie aufdecken. Unit-Tests sind die erste und wichtigste Phase, die von den Entwicklern durchgeführt wird. Obwohl auch andere Arten wichtig sind, kommen sie immer erst danach.
Unit-Tests stellen sicher, dass der Quellcode die Qualitätskriterien erfüllt, bevor er veröffentlicht wird, und schaffen so eine zuverlässige Softwareentwicklungsumgebung für alle Entwickler. Das Ergebnis sind mehr Effizienz und Optimierung, besserer Code und weniger verschwendete Zeit und Geld.
Diese Art von Test wird in der Regel nach den Einheitstests durchgeführt. Integrationstests dienen dazu, Fehler zu finden, die bei der Verbindung der verschiedenen Schnittstellen miteinander auftreten können.
Um diesen Testtyp auszuführen, sollten Sie die Quellcode-Komponenten der Anwendung als Ganzes testen.
Bei Regressionstests muss überprüft werden, ob die jüngsten Änderungen im Quellcode der Anwendung keine Nebenwirkungen auf die während der Entwicklungsphase geänderten Funktionen haben. Damit soll sichergestellt werden, dass der alte Code mit den neu implementierten Funktionen und den behobenen Fehlern noch einwandfrei funktioniert.
Zu diesem Zweck sollten Sie den bereits abgeschlossenen Test erneut durchführen und vergleichen, wie die Anwendung funktioniert.
White-Box-Testing ist ein sehr spezifisches Werkzeug, das in ganz bestimmten Situationen nützlich ist. Wenn Sie einen bestimmten Algorithmus testen, etwas sicherheitskritisches, etwas mit spezifischen Leistungsanforderungen oder etwas, das sehr sicher sein muss, ist es sehr hilfreich, die Implementierung zu kennen, um alle Grenzfälle zu finden.
Der Mutationstests verdienen besondere Aufmerksamkeit. Dieser Ansatz wird in der Regel als letzter Schritt betrachtet, um festzustellen, ob der gesamte Test erfolgreich durchgeführt wurde.
Tester ändern bestimmte Komponenten des Quellcodes einer Anwendung, um zu überprüfen, ob alle Bedingungen erfüllt sind, und Softwaretests können alle durchgeführten Änderungen erkennen. Diese in der Software implementierten Änderungen sollen Fehler im Programm hervorrufen.
aqua AI Copilot generiert Testfälle automatisch aus Ihren Anforderungen.
Testabdeckung ist die Grundlage jeder White-Box-Testing-Technik, und die gewählte Methode bestimmt, wie gründlich jeder Entscheidungspunkt im Code überprüft wird. Mit dieser Technik wird ermittelt, ob Ihre Testfälle den Quellcode der Anwendung abdecken und welches Codevolumen bei der Ausführung dieser Testfälle ausgeübt wird.
Das Gute an den Abdeckungstechniken ist, dass man einige von ihnen mit Formeln bewerten kann, die auch als QS-Metriken bezeichnet werden. Hier sind Beispiele für solche Abdeckungen und Formeln:
Das Hauptziel dieser Technik ist es, sicherzustellen, dass alle Zeilen des Codes getestet wurden, und eventuelle Fehler oder versteckte Fehler im gesamten Code zu entdecken.
Anweisungsabdeckung = (Anzahl der ausgeführten Anweisungen / Gesamtzahl der ausführbaren Anweisungen) x 100 %
Mit dieser Technik wird die Genauigkeit des möglichen Pfads oder Entscheidungspunkts einer Softwareanwendung untersucht.
Verzweigungsabdeckung = (Anzahl der getesteten Entscheidungsergebnisse / Gesamtzahl der Entscheidungsergebnisse) x 100 %
Zusammen mit der Anweisungsabdeckung hilft sie, die Anzahl der implementierten Funktionen zu bestimmen.
Funktionsabdeckung = (Anzahl der ausgeführten Funktionen / Gesamtzahl der Funktionen) * 100
Es gibt noch eine andere Art der Abdeckung – die Pfadabdeckung – die die Aufmerksamkeit der QS-Tester verdient, weil sie komplizierte Builds von Softwareanwendungen überprüft, auch wenn wir keine Formel dafür bereitstellen.
Die Pfadabdeckung prüft alle Pfade, unabhängig davon, ob sie gekreuzt werden oder nicht, und es ist wichtiger, die Abdeckung von Pfaden als von Zweigen zu prüfen.
Für White-Box-Tests werden verschiedene Testtechniken verwendet, um neben der Funktions- oder Verzweigungsabdeckung auch die Abdeckung des Softwaresystems zu überprüfen: Bedingungsabdeckung (auch Prädikatsabdeckung genannt), Basispfadtests, Flussdiagrammnotation, Schleifentests, Mehrfachbedingungsabdeckung, Abdeckung von endlichen Zustandsmaschinen, Kontrollflusstests, Datenflusstests und viele andere, Strukturtests, Funktionstests und viele andere.
Einfache Anweisungs- und Zweigabdeckung reicht für Teams, die an komplexen oder sicherheitskritischen Systemen arbeiten, nicht mehr aus. Klar, Sie haben Ihre grundlegende Statement- und Branch-Coverage, aber das kratzt heutzutage nur an der Oberfläche. Sie müssen Condition Coverage und Multiple Condition Coverage mit reinbringen, um sicherzustellen, dass jeder einzelne Entscheidungspunkt richtig unter die Lupe genommen wird.
Arbeiten Sie an etwas Kritischem? MCDC (Modified Condition/Decision Coverage) wird Ihr bester Freund – es überprüft, ob jede Bedingung tatsächlich das Verhalten Ihres Programms alleine ändern kann.
Aber hier wird’s richtig interessant: Mutation Testing. Teams zerstören absichtlich kleine Teile ihres Codes, um zu schauen, ob ihre Tests scharf genug sind, um die Probleme zu erwischen. Fangen Sie erst mit automatisierten Coverage-Tools an, dann schichten Sie Mutation Testing dazu, sobald Sie 85% Coverage erreichen. Ihre CI-Pipeline wird Ihnen dankbar sein, und Sie entdecken diese hinterhältigen Edge Cases, bevor sie zu Production-Albträumen werden.
Die Vorbereitung auf White-Box-Testing beginnt damit, die Codebasis Ihres Teams zu verstehen, nicht mit dem Erlernen von Tool-Konfigurationen. Das White-Box-Testing-Center basiert auf dem Quellcode der Anwendung, und das Verständnis dieses Codes ist entscheidend für effiziente Ergebnisse der durchgeführten Tests. Das bedeutet, dass Sie mindestens eine Software-Programmiersprache beherrschen müssen (je mehr, desto besser), vor allem die Sprache, in der dieser Code geschrieben wurde.
Dies kann Ihnen auch dabei helfen, sich auf Sicherheitstests vorzubereiten und zu verhindern, dass der Code bösartige Codezeilen aus externen Quellen einschleust oder andere Sicherheitsbedrohungen aufdeckt.
Zweitens müssen Sie den korrekten Fluss des Quellcodes überprüfen und sicherstellen, dass alles gut strukturiert ist. Wie macht man das? Auch hier gilt: Lernen Sie Programmiersprachen. Es könnte Ihnen helfen, zusätzlichen Code zu schreiben, um den Hauptcode zu testen. So verbringen Sie weniger Zeit mit dem manuellen Testen.
Lassen Sie uns also sehen, wie Sie diese Tests mit dem Online-Testmanagement-Tool aqua durchführen können.
White Box Testing hat sich zu einem echten Kraftpaket für Automatisierung und Sicherheit entwickelt, und Sie nutzen wahrscheinlich schon einige dieser Tools, ohne ihr volles Potenzial zu erkennen. Moderne Entwicklerteams lassen automatisierte Unit Tests und Code Coverage Analysis als Teil ihres täglichen Arbeitsablaufs laufen, mit Tools wie SonarQube und Veracode, die Probleme abfangen, bevor sie in die Produktion gelangen.
Aber hier wird’s interessant: Sicherheitsfokussiertes White Box Testing erwischt jetzt Schwachstellen, die traditionelles Testing komplett übersieht. Ihre Tests können automatisch nach SQL-Injection-Risiken, schwachen Authentifizierungsmustern und unsauberer Datenverarbeitung scannen. Unternehmen, die diese Ansätze nutzen, berichten von fast 60% weniger Sicherheitsvorfällen in der Produktion.
Sicherheitsscans nur am Ende der Entwicklungszyklen zu fahren ist ein riesiger Fehler. Stattdessen integrieren Sie SAST-Tools in Ihre täglichen Commits und Sie fangen Authentifizierungsschwächen und Injection-Schwachstellen ab, während der Code noch frisch in Ihrem Kopf ist. Kombinieren Sie das mit regelmäßigen Code-Überprüfungen und Bedrohungsmodellierungssitzungen, und Sie haben ein robustes Verteidigungssystem, das mit Ihren Projekten mitwächst.
Das aqua kann ein perfektes agiles Testmanagement-Tool sein und auch bei der Organisation von White-Box-Tests helfen, da es im Grunde eine „One-Box-Testing-Lösung“ ist.
Verwenden Sie diese Checkliste vor, während und nach jedem White-Box-Testing-Zyklus.
Vor dem Testing:
Während des Testings:
Nach dem Testing:
White-Box-Tests sind nach wie vor einer der besten Ansätze, um die Funktionalität des Systems zu überprüfen und die meisten Fehler zu identifizieren, obwohl es meist unmöglich ist, jedes einzelne Detail des Codes nur mit menschlicher Beteiligung zu testen und eine 100%ige Genauigkeit zu erzielen.
Künstliche Intelligenz ist eine hervorragende Möglichkeit, die Testabdeckung mit weniger Aufwand zu erhöhen. Sie können damit auch Grenzfälle berücksichtigen, die sonst nicht getestet werden könnten. Der KI-Copilot von aqua kann Ihre Testsuite analysieren, um ganze Testfälle zu erstellen oder Ihre Entwürfe zu vervollständigen.
Machen Sie Ihre White-Box-Tests umfassender als je zuvor
White-Box-Tests beziehen sich auf Tests, bei denen die QS-Spezialisten wissen, wie die Software entwickelt wurde.
White-Box-Tests sind ein gültiger Ansatz für alle Arten von Tests vor der Freigabe. Technisch gesehen verwenden Entwickler White-Box-Tests, wenn sie Unit-Tests erstellen und ausführen, die noch vor der Übergabe des Codes an die Qualitätssicherung ausgeführt werden.
White-Box-Tests werden meist von Qualitätssicherungsspezialisten durchgeführt. Technisch gesehen verwenden Entwickler auch White-Box-Tests, wenn sie Unit-Tests erstellen und ausführen, die noch vor der Übergabe des Codes an die Qualitätssicherung durchgeführt werden.
Unit-Testing ist eine der Arten von White-Box-Tests, keine separate Methode. White-Box-Testing ist der übergeordnete Ansatz, der alle Tests umfasst, die Code-Zugang erfordern, einschließlich Unit-, Integrations- und Regressionstests. Ein White-Box-Testing-Beispiel wie Login-Authentifizierung kann Unit-Tests für die Verschlüsselungsfunktion und Integrationstests für den gesamten Authentifizierungsflow umfassen, beides unter dem White-Box-Ansatz durchgeführt.
Die meisten White-Box-Testing-Techniken können automatisiert werden, und für große Codebasen ist Automatisierung der einzig realistische Weg, eine sinnvolle Abdeckung aufrechtzuerhalten. Tools wie JUnit, Pytest, SonarQube und EclEmma automatisieren Anweisungs-, Zweig- und Funktionsabdeckungsprüfungen. KI-gestützte Plattformen wie aqua gehen noch weiter, indem sie Testfälle automatisch aus Anforderungen generieren und so den manuellen Aufwand für die Pflege einer großen White-Box-Testsuite reduzieren.
