• IT-Karriere:
  • Services:

White-Box-Tests zur Verbesserung der Testabdeckung

Eine kurze Einführung:

Stellenmarkt
  1. Metabowerke GmbH, Nürtingen
  2. MorphoSys AG, Planegg

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:

  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.  


Anzeige
Spiele-Angebote
  1. 14,99€
  2. 26,99€
  3. 7,99€

xUser 20. Feb 2021 / Themenstart

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

NoGoodNicks 13. Feb 2021 / Themenstart

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

freebyte 09. Feb 2021 / Themenstart

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

Steffo 09. Feb 2021 / Themenstart

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

Netzweltler 09. Feb 2021 / Themenstart

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

Kommentieren


Folgen Sie uns
       


Radeon RX 6800 (XT) im Test mit Benchmarks

Lange hatte AMD bei Highend-Grafikkarten nichts zu melden, mit den Radeon RX 6800 (XT) kehrt die Gaming-Konkurrenz zurück.

Radeon RX 6800 (XT) im Test mit Benchmarks Video aufrufen
    •  /