White-Box-Testing prüft Software von innen. Statt sich wie ein Kunde durch die Oberfläche zu klicken, studiert ein Tester den Quellcode und bestätigt, dass jede Ja-oder-Nein-Entscheidung des Programms tatsächlich ausprobiert wird. Die Methode zählt vor allem dort, wo sich Fehler vor der normalen Nutzung verstecken, etwa in Sicherheitsprüfungen, komplexen Geschäftsregeln und von KI geschriebenem Code.
Die Fehlerbehandlung ist ein typischer Fall: Die Meldung für einen Ausfall des Zahlungsanbieters wird nur ausgeführt, wenn der Anbieter tatsächlich ausfällt, meist vor echten Kunden. Black-Box-Testing dagegen beurteilt ein Produkt nach dem, was Nutzer sehen, sodass solcher Code monatelang ungetestet bleiben kann. Deshalb setzen starke Teams beide Methoden ein. Dieser Leitfaden erklärt die zentralen Techniken des White-Box-Testings verständlich und zeigt, wann Prüfungen von innen den Prüfungen von außen überlegen sind. Außerdem sehen Sie, wie ein dediziertes QA-Team diese Arbeit gemeinsam mit Ihren Entwicklern übernimmt.
Vorbereitung für White-Box-Testing: was Sie bereitstellen und was die Tester mitbringen
Ihr Teil der Vorbereitung ist der Zugang zum Code. Die Tester arbeiten im Repository, dem gemeinsamen Speicher, in dem Ihre Entwickler die Quelldateien ablegen. Bei QAwerk richten wir diesen Zugang nach Ihren Sicherheits- und Compliance-Anforderungen ein.
Das Testteam bringt alles Weitere mit:
- Programmierkenntnisse: Code zu lesen erfordert Programmier-Know-how, deshalb übernehmen Entwickler oder QA-Automatisierungsingenieure das White-Box-Testing. Zu deren täglicher Arbeit gehört es, Skripte zu schreiben, die Software prüfen.
- Coverage-Tools: Solche Werkzeuge messen, welcher Anteil der Anwendung beim Testen ausgeführt wurde, und geben das Ergebnis als Prozentwert aus, die sogenannte Codeabdeckung.
Sobald diese Vorbereitung steht, läuft der Großteil der Arbeit über Unit-Tests, kurze Codestücke, die jeweils einen Teil des Programms für sich prüfen. Ein typisches Produkt braucht Tausende davon, deshalb führt das automatisierte Testen den gesamten Satz bei jeder Änderung erneut aus. Unit-Tests bilden die Basisschicht unter umfassenderen Prüfungen wie End-to-End- und Integrationstests.
Fünf Techniken des White-Box-Testings: von der leichtesten bis zur strengsten
Die fünf folgenden Techniken messen die Abdeckung mit zunehmender Tiefe, und die strengeren prüfen den Code gründlicher. Alle verwenden dasselbe Beispiel, die Rückerstattungsregel eines Onlineshops. Der Shop erstattet einem Kunden den Kaufpreis automatisch, wenn zwei Dinge zutreffen: Der Kauf liegt weniger als 30 Tage zurück, und der Artikel ist noch ungeöffnet.
Anweisungsüberdeckung: jede Zeile mindestens einmal ausführen
Die Anweisungsüberdeckung bestätigt, dass jede Codezeile beim Testen mindestens einmal ausgeführt wird. In unserem Beispiel durchläuft ein einziger Test mit einer aktuellen, ungeöffneten Bestellung die gesamte Rückerstattungsregel, weil die Logik nur die Auszahlung abdeckt. Niemand hat jedoch geprüft, was passiert, wenn eine Anfrage abgelehnt wird, etwa ob der Kunde je erfährt, dass die Antwort Nein lautete. Deshalb eignet sich die Anweisungsüberdeckung als erster Schritt vor strengeren Techniken.
Zweigüberdeckung: jede Abzweigung in beide Richtungen nehmen
Die Zweigüberdeckung, auch Entscheidungsüberdeckung genannt, sorgt dafür, dass jede Ja-oder-Nein-Entscheidung im Code in beide Richtungen läuft. Das Beispiel braucht jetzt zwei Tests: eine berechtigte Bestellung und eine abgelehnte Anfrage. Der zweite Test zeigt, dass abgelehnte Kunden nie eine Antwort erhalten. Deshalb betrachten viele Teams die Zweigüberdeckung als praktisches Minimum.
Bedingungsüberdeckung: jede Prüfung wahr und falsch werden lassen
Unsere Regel enthält zwei getrennte Bedingungen: wie alt die Bestellung ist und ob der Artikel noch versiegelt ist. Die Bedingungsüberdeckung sorgt dafür, dass jede Bedingung in einem Test wahr und in einem anderen falsch ist. Zwei Tests erfüllen diese Anforderung: eine aktuelle Bestellung mit geöffneter Verpackung und ein versiegelter Artikel, der vor Monaten gekauft wurde. Keiner der beiden Tests löst jedoch eine Rückerstattung aus, sodass die Bedingungsüberdeckung allein genau das Ergebnis verfehlen kann, für das die Regel existiert.
MC/DC: nachweisen, dass jede Bedingung für sich zählt
Die modifizierte Bedingungs-/Entscheidungsüberdeckung, kurz MC/DC, schließt den blinden Fleck, den die Bedingungsüberdeckung lässt. Die Tests müssen zeigen, dass das Umschalten einer einzelnen Bedingung bei sonst gleichen Werten das Endergebnis ändert. Für die Rückerstattungsregel braucht es dafür drei Tests:
- Ein aktueller, versiegelter Artikel: Rückerstattung genehmigt
- Derselbe versiegelte Artikel, vor zwei Monaten gekauft: keine Rückerstattung
- Ein aktueller Artikel, der bereits geöffnet wurde: keine Rückerstattung
Sicherheitsnormen verlangen dieses Niveau für die kritischsten Systeme. So schreibt die Luftfahrtnorm DO-178C MC/DC für Code vor, dessen Versagen ein Flugzeug zum Absturz bringen könnte. Ebenso empfiehlt die Automobilnorm ISO 26262 MC/DC für Fahrzeugfunktionen der höchsten Risikoklasse. Wenn Sie für Autos entwickeln, von Fahrerassistenzsystemen bis zu Apps im Armaturenbrett, sehen Sie sich an, wie unser Testen von Automobilsoftware funktioniert.
Pfadüberdeckung: jedem Weg durch den Code folgen
Die Pfadüberdeckung testet jeden möglichen Weg durch ein Codestück, von der ersten bis zur letzten Zeile. Für die Rückerstattungsregel sind dafür nur wenige Tests nötig. Echte Software ist jedoch selten so einfach. Jede zusätzliche Entscheidung verdoppelt die Zahl der Wege, und eine Schleife, also ein Codeblock, der sich wiederholt, kann die Gesamtzahl über alles hinaustreiben, was sich testen lässt. Deshalb reservieren Teams die Pfadüberdeckung für kleine Funktionen mit hohem Risiko, etwa Zahlungsberechnungen.
So schneiden die fünf Techniken des White-Box-Testings im Vergleich ab:
Anweisungsüberdeckung
Jede Zeile läuft mindestens einmal
Was passiert, wenn die Antwort „Nein“ lautet
Luftfahrtsoftware mit schwerem Ausfallrisiko (DO-178C Level C)
Zweigüberdeckung
Jede Entscheidung läuft in beide Richtungen
Eine Bedingung, die nie für sich getestet wird
Luftfahrt Level B; das praktische Minimum für viele Teams
Bedingungsüberdeckung
Jede Bedingung ist wahr und falsch
Das Ergebnis, für das die Regel existiert
Selten allein vorgeschrieben
MC/DC
Jede Bedingung ändert das Ergebnis unabhängig
Wege, die durch Schleifen entstehen
Luftfahrt Level A; empfohlen für die höchste Sicherheitsstufe im Automobilbereich
Pfadüberdeckung
Jeder Weg vom Anfang bis zum Ende
Theoretisch nichts, aber volle Abdeckung ist meist unmöglich
Keine Norm; für kleine, kritische Funktionen genutzt
Warum das Testen jeder Codezeile keine fehlerfreie Software bedeutet
Die Codeabdeckung, also der Anteil eines Programms, der beim White-Box-Testing ausgeführt wird, ist leicht zu messen und leicht misszuverstehen. Dieser Prozentwert sagt Ihnen jedoch nicht, ob die Tests die richtigen Ergebnisse geprüft haben. Ein Test, der eine Zeile ausführt, ohne das Ergebnis zu überprüfen, zählt trotzdem zur Abdeckung. So kann ein Team 90% erreichen und dennoch eine falsche Berechnung ausliefern.
Mit Mutationstests prüfen sorgfältige Teams die Tests selbst. Ein Werkzeug baut kleine, absichtliche Fehler in den Code ein, etwa indem es „größer als“ in „kleiner als“ umkehrt, und führt dann alle Tests erneut aus. Schlägt nichts fehl, sind diese Tests zu schwach, um echte Fehler zu bemerken. Meta nutzt inzwischen KI, um Fehler einzubauen, die bestehende Prüfungen übersehen, und anschließend neue Tests zu schreiben, die sie finden. In Versuchen mit Messenger und WhatsApp prüften Ingenieure die von der KI geschriebenen Tests und behielten 73% der Vorschläge, um diese Apps künftig vor ähnlichen Fehlern zu schützen.
Ein zweites Problem sind Flaky Tests, Prüfungen, die in einem Durchlauf bestehen und im nächsten fehlschlagen, obwohl niemand den Code geändert hat. Die Ursache liegt meist außerhalb des Programms selbst, etwa beim Timing, bei langsamen Netzwerkantworten oder bei Daten, die ein früherer Test hinterlassen hat. Sobald sich ein Team daran gewöhnt, diese zufälligen Fehlschläge zu ignorieren, kann ein echter Fehler unbemerkt bleiben. Der Prozentwert sieht weiterhin gut aus, aber niemand kann echte Probleme von Fehlalarmen unterscheiden. Deshalb müssen instabile Tests behoben werden, bevor sich jemand auf einen Abdeckungsbericht verlässt.
White-Box- vs. Black-Box-Testing: zwei Sichten auf ein Produkt
White-Box- vs. Black-Box-Testing ist weniger eine Wahl als eine Aufgabenteilung: Black-Box-Prüfungen decken das fertige Produkt aus Kundensicht ab, und White-Box-Tests untersuchen den Code selbst, oft bevor eine Funktion überhaupt auf dem Bildschirm erscheint.
Jeder Ansatz findet zudem Fehler, an die der andere selten herankommt. Tests von außen entdecken einen verwirrenden Checkout oder eine Regel, die in den Anforderungen fehlt. Prüfungen auf Codeebene dagegen finden eine Zeile, die nie ausgeführt wird, oder einen Fehler, der stillschweigend ignoriert wird. Black-Box-Testing wird in einem eigenen Artikel ausführlich erklärt, auch warum viele Unternehmen diese Arbeit auslagern, ohne Code weiterzugeben.
In der Praxis teilen viele Unternehmen die Arbeit zwischen eigenen Entwicklern und einem QA-Partner auf. Bei Zazu, einer App für persönliche Finanzen, übernahmen die Ingenieure des Unternehmens alle Unit-Tests. Wir übernahmen Abnahmetests, die bestätigen, dass die App tut, was das Unternehmen verlangt hat, sowie Regressionstests, die bestehende Funktionen nach jedem Update erneut prüfen.
Wann White-Box-Testing am wichtigsten ist
Prüfungen über die Oberfläche decken ab, was Menschen normalerweise tun, doch manche Risiken stecken in Code, den Nutzer selten auslösen. White-Box-Testing ist in drei Bereichen am wertvollsten:
- Sicherheitskritischer Code: Code für Login, Zahlungen und Berechtigungen kann auf dem Bildschirm einwandfrei funktionieren und trotzdem die Prüfung der von Nutzern übermittelten Daten auslassen. Ein Angreifer kann ein solches Versäumnis ausnutzen, etwa indem er eine speziell präparierte Anfrage sendet, um das Konto einer anderen Person zu öffnen. Code, der schwer abstürzt, wenn etwas schiefgeht, ist ebenso gefährlich. 2025 nahmen die OWASP Top 10, eine weit verbreitete Rangliste der größten Risiken für Webanwendungen, eine Kategorie für Code auf, der Fehler und unerwartete Situationen falsch behandelt. APIs, die Schnittstellen, über die Ihre Apps Daten austauschen, sind beiden Problemen ausgesetzt und verdienen eigene API-Sicherheitstests. Werkzeuge für statische Analyse, oft SAST genannt, lesen den Quellcode und markieren Schwachstellen wie diese. Unsere Sicherheitstests kombinieren diese automatisierte Prüfung anschließend mit simulierten Angriffen auf das laufende Produkt.
- Komplexe Entscheidungslogik: Im Juli 2024 legte ein fehlerhaftes Update von CrowdStrike Windows-Computer weltweit lahm. Laut der Ursachenanalyse des Unternehmens erwartete die Software 21 Eingabewerte, erhielt aber nur 20. Die Abweichung blieb unter anderem deshalb unbemerkt, weil die Tests die 21. Stelle mit einem Platzhalterwert füllten, der auf alles passte. Dadurch wurde der Code, der abstürzt, wenn dieser Wert fehlt, vor der Veröffentlichung nie ausgeführt. White-Box-Testing ist genau dafür gedacht, solche Probleme zu finden, denn die Tester lesen den Quellcode und probieren jeden Wert aus, auf den sich das Programm verlässt. Zu den Korrekturen von CrowdStrike gehörten automatische Prüfungen für jeden Eingabewert.
- Von KI geschriebener Code: Bei Google werden inzwischen 75% des gesamten neuen Codes von KI generiert und von Ingenieuren freigegeben. Trotzdem führten 45% der Codebeispiele eine bekannte Sicherheitslücke ein, als Veracode mehr als 100 KI-Modelle testete. Positiv ist, dass KI auch Unit-Tests entwerfen kann, die Ingenieure dann prüfen, einer der Anwendungsfälle generativer KI im Softwaretesten mit echtem Nutzen.
Wie QAwerk White-Box-Testing parallel zu Prüfungen von außen durchführt
Projekte auf Codeebene folgen bei QAwerk meist vier Schritten:
- Zugang vereinbaren. Bevor jemand eine Datei öffnet, klären wir, wer was sehen darf und zu welchen Bedingungen.
- Den Code prüfen. Wir gehen Fehlerbehandlung, riskante Logik und schwer testbare Bereiche durch und erklären dann verständlich, was behoben werden muss.
- Lücken schließen. Automatisierungsingenieure ergänzen Tests dort, wo die Abdeckung dünn ist, beginnend mit den Teilen, die Geld, Logins und personenbezogene Daten verarbeiten.
- Wiederholungen automatisieren. Die neuen Prüfungen werden Teil Ihrer Build-Pipeline, des automatisierten Prozesses, der jede neue Version zusammensetzt, damit Probleme vor der Veröffentlichung auffallen.
Jedes Projekt sieht etwas anders aus:
- Ein Code-Review vor der Skalierung: Für Couple Up! prüfte ein erfahrener Python-Entwickler den Server des Spiels nach vier Kriterien: Codequalität, Fehlerbehandlung, Caching (Wiederverwenden gespeicherter Ergebnisse für mehr Geschwindigkeit) und Testbarkeit der Software. Die Ergebnisse empfahlen außerdem Unit- und Integrationstests.
- Tests bei jedem Commit: Für Kazidomi liefen nach jedem Commit, einer gespeicherten Änderung im GitLab-Repository des Unternehmens, 284 automatisierte Tests.
- Tests, ausgewählt anhand der Änderung: Gemeinsam mit den Ingenieuren von Granola haben wir einen KI-gestützten Ablauf gebaut, der jeden Pull Request, also eine vorgeschlagene Codeänderung, analysiert und die relevantesten Testfälle auswählt.
In jedem dieser Projekte lief die Arbeit auf Codeebene parallel zum regulären Testen der fertigen Software. Tests von außen zeigen, ob Kunden bekommen, was versprochen wurde, während die Sicht von innen belegt, dass unterwegs nichts Wichtiges ausgelassen wurde. Unsere Automatisierungsingenieure übernehmen das White-Box-Testing selbst, und manuelles Testen deckt ab, was Ihre Nutzer zuerst bemerken. Lassen Sie Ihren Code prüfen, bevor versteckte Fehler Ihre Kunden erreichen.
Häufige Fragen
Was ist White-Box-Testing?
White-Box-Testing ist eine Methode des Softwaretestens, bei der der Tester den Quellcode des Programms einsehen kann und die Prüfungen danach ausrichtet, wie die Anwendung intern funktioniert. Statt nur zu bestätigen, was auf dem Bildschirm erscheint, stellen White-Box-Tests sicher, dass jede Zeile, jede Ja-oder-Nein-Entscheidung und jeder Fehlerpfad tatsächlich ausgeführt wird. Die Methode ist auch als Glass-Box-Testing oder strukturelles Testen bekannt.
Sind Unit-Tests dasselbe wie White-Box-Testing?
Unit-Tests und White-Box-Testing überschneiden sich, aber die Begriffe beschreiben Unterschiedliches. Das Wort „Unit“ bezieht sich auf die Größe: ein kleines Stück Software, etwa eine einzelne Funktion, das isoliert geprüft wird. White-Box-Testing bezeichnet den Ansatz, Tests mit Blick auf den Quellcode zu entwerfen. Die meisten Unit-Tests entstehen auf diese Weise, doch White-Box-Methoden umfassen auch Code-Reviews, Sicherheitsscans und ganze Komponenten.
Wer führt White-Box-Testing durch?
Meist übernehmen Entwickler das White-Box-Testing, da die Arbeit das Lesen und Verstehen von Quellcode erfordert. Größere Teams ergänzen QA-Automatisierungsingenieure, oft mit dem Titel SDET, die Testcode schreiben und die Ergebnisse unabhängig von den ursprünglichen Autoren prüfen. Ein spezialisiertes QA-Unternehmen kann dieselbe Rolle übernehmen, sobald der Kunde dem Testteam Zugang zur Codebasis gewährt, also zum gesamten Quellcode des Produkts.
Was ist Codeabdeckung beim White-Box-Testing?
Die Codeabdeckung beim White-Box-Testing ist ein Prozentwert, der zeigt, wie viel einer Anwendung während des Testens ausgeführt wird. Ein Messwerkzeug erfasst jede Zeile und jede Entscheidung und meldet dann, was erreicht und was übersprungen wurde. Ein hoher Wert bedeutet, dass der Großteil des Programms ausgeführt wurde. Die Zahl allein zeigt jedoch nicht, ob jede Prüfung das richtige Ergebnis verifiziert hat, deshalb prüfen Teams auch die Qualität der Tests selbst.
Was ist Grey-Box-Testing?
Grey-Box-Testing ist ein Mittelweg zwischen White-Box- und Black-Box-Testing. Der Tester kennt einen Teil des internen Aufbaus, zum Beispiel die Datenbankstruktur oder wie Dienste Daten austauschen, arbeitet aber über die normalen Bildschirme und Funktionen des Produkts. Dieses Teilwissen hilft, Schnittstellen und Sicherheitsschwachstellen gezielt anzugehen, die ein Außenstehender erraten müsste.
Sehen Sie ein Beispiel unserer Sicherheits-Code-Review einer US-amerikanischen E-Commerce-Plattform
