White-Box-Tests zur Verbesserung der Testabdeckung

Eine kurze Einführung:

Stellenmarkt
  1. Ingenieur (m/w/d) Vernetzung Automotive
    STAR ELECTRONICS GmbH, Sindelfingen (Home-Office möglich)
  2. Softwareentwickler (m/w/d) Frontend / Backend / Fullstack
    AUSY Technologies Germany AG, verschiedene Standorte
Detailsuche

Black-Box-Tests: Testen einer Methode rein auf Basis ihrer Spezifikation, ohne Rücksicht auf die konkrete Implementierung.

White-Box-Tests: die Verwendung der spezifischen Implementierungsdetails, um die Testprioritäten festzulegen.

White-Box-Tests können, wenn sie richtig durchgeführt werden, die Testabdeckung erheblich verbessern, indem sie besser auf korrektes Verhalten in wichtigen Sonderfällen testen. Nehmen Sie zum Beispiel an, Sie testen die folgende Klasse:

Golem Akademie
  1. Netzwerktechnik Kompaktkurs
    8.-12. November 2021, online
  2. Advanced Python - Fortgeschrittene Programmierthemen
    27.-28. Januar 2022, online
  3. Python kompakt - Einführung für Softwareentwickler
    28.-29. Oktober 2021, online
Weitere IT-Trainings

  1. public class MyCustomSet <T> implements Set <T> { … }

Reines Black-Box-Testen: Ich werde versuchen, verschiedene Elemente hinzuzufügen und zu entfernen, und dabei sicherstellen, dass diese Operationen alle verschiedenen Anforderungen des Set-Interface abdecken, unabhängig von der spezifischen Implementierung.

Besseres White-Box-Testing: Ich weiß, dass die Implementierung Hashing und Lineare Sondierung verwendet, um die gewünschte Funktionalität zu erreichen. Die kniffligsten Sonderfälle treten auf, wenn zwei verschiedene Elemente am gleichen Array-Offset kollidieren, und vor allem, wenn eines dieser zuvor eingefügten Elemente später wieder entfernt wird, wodurch ein Tombstone-Eintrag entsteht. Daher werde ich zusätzlich zu den obigen Black-Box-Tests spezifische Tests mit spezifischen Eingaben schreiben, die diese kniffligen Sonderfälle auslösen.

Der erste Ansatz kann angemessen sein, wenn eine ausreichend große Testsuite verwendet wird. Mit dem zweiten Ansatz ist es jedoch wahrscheinlicher, dass Bugs mit einer viel kleineren Testsuite gefunden werden, indem die spezifischen Sonderfälle, die am wahrscheinlichsten auftreten, identifiziert und ausgelöst werden.

Besonders umstritten sind White-Box-Tests, wenn sie dazu verwendet werden, die Testsuite zu schwächen, anstatt sie zu stärken. Am häufigsten werden Sie so etwas wie dies hören: "Ich weiß, dass die Implementierung die Funktionalität XYZ mit der Implementierung ABC erreicht, und wenn man sich die Implementierung ABC ansieht, ist es offensichtlich, dass sie wie beabsichtigt funktioniert. Daher müssen wir uns nicht darum kümmern, Tests zu schreiben, die die Funktionalität XYZ abdecken."

Typischerweise wird in solchen Fällen davon ausgegangen, dass ABC sicher ist, entweder weil es sehr einfach ist oder weil es zuverlässige Bibliotheken verwendet. Wenn es richtig gemacht wird, kann es dabei helfen, Bereiche mit höherem/niedrigerem Risiko zu identifizieren und entsprechend zu priorisieren. Wenn es falsch gemacht wird, kann das zu gefährlichen Löchern in Ihrer Testabdeckung führen. Denn es besteht immer das Risiko, dass Sie etwas übersehen haben oder dass jemand den Code später in einer Art und Weise umschreibt, die Ihre Annahmen über den Haufen wirft.

White-Box-Tests als Rechtfertigung für die Vernachlässigung bestimmter Sonderfälle zu verwenden, hat zwei Seiten. Es kann ein notwendiges Übel sein, wenn die Zeit knapp ist (aber es ist besser, sich nicht zu sehr darauf zu verlassen). Auf der anderen Seite können White-Box-Tests Ihre Testsuite enorm verbessern und Ihre Codebasis wirklich sicher machen.

Integrationstests sind Gold wert

"Kennen Sie den Unterschied zwischen Theorie und Praxis? In der Theorie gibt es das nicht. In der Praxis schon." Dieser Spruch passt genau auf Unit- und Integrationstests: In der Theorie können Unit-Tests genau die gleiche Abdeckung liefern, die Sie mit Integrationstests haben. In der Praxis tun sie das aber nicht.

Hardware-Teams haben das im Laufe der Jahre schmerzlich gelernt, deshalb wird bei keinem Hardwareprojekt an den Integrationstests gespart. Egal wie gründlich Sie in Ihren Unit-Tests sind, Sie werden Fehler finden, wenn Sie Integrationstests durchführen.

Viele Softwareentwickler, vor allem die klügeren, haben das noch nicht akzeptiert. "Wenn wir nur einen wirklich guten Job bei den Unit-Tests machen, werden wir keine Integrationstests brauchen!", sagen sie. Ich sage: leider nein. Bei jedem Projekt mit hoher Komplexität werden Sie nie gut genug sein können.

Handbuch für Softwareentwickler: Das Standardwerk für professionelles Software Engineering

Sie werden immer wieder Fakes bauen, die sich von der echten Komponente unterscheiden, auf eine Art, die sich als subtil, aber entscheidend herausstellen wird. Sie werden es immer wieder versäumen, das katastrophale Verhalten vorherzusehen, das aus scheinbar harmlosen Änderungen resultieren kann.

Ich war einmal in einem Team mit brillanten und sehr fähigen Entwicklern, die sich voll und ganz auf Unit-Tests konzentrierten und Integrationstests buchstäblich untersagten. Wir hatten nahezu perfekte Testabdeckungsmetriken, aber irgendwie funktionierte in der Produktion immer wieder mal etwas nicht - und zwar mitunter auf eine ziemlich desaströse Art und Weise.

Wir wurden immer paranoider, machten viele "unnötige" Änderungen und verbrachten immer mehr Zeit mit manuellen Tests. Nichts schien zu funktionieren. Erst als wir eine End-to-End-Testsuite zusammenstellten, wurde es endlich besser. In der Folge fügten wir alle möglichen neuen Funktionen und Codeänderungen ein und unsere Testsuite ließ uns nie im Stich.

Das ist nur ein Beispiel, aber nicht das einzige. So gibt es etwa einen großartigen Artikel von den Entwicklern des Rust-Compilers darüber, wie sie es schafften, alle sechs Wochen eine neue stabile Version zu produzieren, obwohl die meisten anderen Compiler viel längere Release-Zyklen haben.

Sie schreiben einen großen Teil ihres Erfolges den End-to-End-Tests zu. Sie hatten eine solide Suite von Unit-Tests aufgebaut und dennoch traten einige größere Fehler auf, die nur durch End-to-End-Tests gefunden wurden. Durch die Verbesserung der Effektivität ihrer Testsuite waren sie in der Lage, sowohl größere Produktionsfehler zu verhindern als auch ihre Entwicklungszyklen zu beschleunigen - eine echte Win-Win-Lösung, die wir alle anstreben sollten.

Stärken und Beschränkungen

Ironischerweise werden Sie trotz meiner obigen Bekehrungsversuche feststellen, dass die meisten Hardwaretests auf der Ebene der Units (Cluster) durchgeführt werden. Warum ist das so? Bestätigt das nicht den vorherrschenden Ansatz der Softwareindustrie, ebenfalls Unit-Tests vorzuziehen?

Der Kontext ist hier entscheidend. Bei Hardware kann ein Unit-Test (Cluster) in 5 bis 15 Minuten abgeschlossen sein, während Integrationstests (Full-Chip) viele Stunden, manchmal sogar Tage dauern. Aus diesem Grund werden die meisten Hardwaretests auf Unit-Ebene durchgeführt.

Bei Software kann eine ganze Suite von End-to-End-Tests in etwa 30 Sekunden ausgeführt werden und die gesamte, projektweite Suite in fünf Minuten - kaum genug Zeit für einen Entwickler, sich einen Kaffee zu holen, und der Traum eines jeden Hardwaretesters. "Sie wollen mir sagen, dass ich in 30 Sekunden eine ganze Sammlung von End-to-End-Tests ausführen kann, ohne viel Zeit und Mühe in das Schreiben von Tests für jede einzelne Unterkomponente und in das Erstellen/Einrichten/Debuggen von Mocks und Fakes zu investieren, die die Feinheiten des echten Geräts nur unzureichend nachahmen?"

Unit-Tests haben sicher ihre Berechtigung in einer Testsuite. Vor allem wenn es darum geht, obskure Fehlerzustände (zum Beispiel Netzwerk-Timeouts) und andere seltene Fälle zu reproduzieren, die in einem realen System nur schwer zu erzeugen sind.

Das A und O Ihrer Testsuite sollten jedoch Integrationstests sein. Sie können nicht nur Ihre gesamte Codebasis mit einer weitaus kleineren und einfacheren Testsuite abdecken, sondern auch eine grundsolide Abdeckung der komplexen Interaktionen zwischen verschiedenen Komponenten erreichen. Interaktionen, die wir auf der Unit-Ebene viel zu leicht übersehen. ''Schreiben Sie Tests. Nicht zu viele. Hauptsächlich Integration.''

Bitte aktivieren Sie Javascript.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
  • ohne Werbung
  • mit ausgeschaltetem Javascript
  • mit RSS-Volltext-Feed
 Das 0. Gesetz des Testens: Nur die Paranoiden überlebenZufallstests: Was die Amateure von den Profis unterscheidet 
  1.  
  2. 1
  3. 2
  4. 3
  5. 4
  6. 5
  7.  


xUser 20. Feb 2021

UI Tests sind prinzipbedingt langsam. Außerdem sind ihre Failures eher unspezifisch zum...

NoGoodNicks 13. Feb 2021

Korrekt. Und wenn es nicht der Tester ist, dann ist es der Integrator. Der braucht immer...

freebyte 09. Feb 2021

Dann muss sich in den letzten Monaten etwas geändert haben, was ich nicht mitbekommen...

Steffo 09. Feb 2021

Kann mich dem nur anschließen. Ich teste auch ziemlich ausführlich und bin für jeden...

Netzweltler 09. Feb 2021

Daher wird man auch in Zukunft Tests der Software so weit wie möglich beschränken. Daher...



Aktuell auf der Startseite von Golem.de
Waffensystem Spur
Menschen töten, so einfach wie Atmen

Soldaten müssen bald nicht mehr um ihr Leben fürchten. Wozu auch, wenn sie aus sicherer Entfernung Roboter in den Krieg schicken können.
Ein IMHO von Oliver Nickel

Waffensystem Spur: Menschen töten, so einfach wie Atmen
Artikel
  1. Wochenrückblick: Moderne Lösungen
    Wochenrückblick
    Moderne Lösungen

    Golem.de-Wochenrückblick Eine Anzeige gegen einen Programmierer und eine neue Switch: die Woche im Video.

  2. Pornoplattform: Journalisten wollen Xhamster-Eigentümer gefunden haben
    Pornoplattform
    Journalisten wollen Xhamster-Eigentümer gefunden haben

    Xhamster ist und bleibt Heimat für zahlreiche rechtswidrige Inhalte. Doch ohne zu wissen, wer profitiert, wusste man bisher auch nicht, wer verantwortlich ist.

  3. OpenBSD, TSMC, Deathloop: Halbleiterwerk für Automotive-Chips in Japan bestätigt
    OpenBSD, TSMC, Deathloop
    Halbleiterwerk für Automotive-Chips in Japan bestätigt

    Sonst noch was? Was am 15. Oktober 2021 neben den großen Meldungen sonst noch passiert ist, in aller Kürze.

Du willst dich mit Golem.de beruflich verändern oder weiterbilden?
Zum Stellenmarkt
Zur Akademie
Zum Coaching
  • Schnäppchen, Rabatte und Top-Angebote
    Die besten Deals des Tages
    Daily Deals • Cyber Week: Bis zu 40€ Rabatt auf Samsung-SSDs • Crucial 16GB Kit 3600 69,99€ • Razer Huntsman Mini 79,99€ • Gaming-Möbel günstiger (u. a. DX Racer 1 Chair 201,20€) • Alternate-Deals (u. a. Razer Gaming-Maus 19,99€) • Gamesplanet Anniversary Sale Classic & Retro [Werbung]
    •  /