Zum Inhalt springen

Warum Softwaretests konkrete Fehlerfälle brauchen

Tests sollen beweisen, dass etwas funktioniert. Tatsächlich beweist ein Test nur, dass er durchläuft — und das ist nicht dasselbe. Dieser Text erklärt den Unterschied und was daraus folgt.

  • Für wenAuftraggeber, Projektverantwortliche
  • NiveauVerständnis
  • Lesezeitetwa 7 Minuten
  • Stand16. Oktober 2026

Das lernen Sie

  • Was ein Test beweist und was nicht
  • Warum die Gegenprobe zum Test gehört
  • Welche Fälle sich zu testen lohnen
  • Warum eine Abdeckungszahl wenig aussagt

Ein grüner Test beweist nur sich selbst

Ein Test ist ein kleines Programm, das ein anderes Programm aufruft und das Ergebnis mit einer Erwartung vergleicht. Läuft er durch, heißt das: In diesem einen Fall kam heraus, was der Test erwartet hat.

Daraus folgt eine unangenehme Möglichkeit: Ein Test kann grün sein, weil er nichts prüft. Er ruft etwas auf, erwartet nichts Konkretes, und bleibt auch dann grün, wenn die geprüfte Stelle gar nicht mehr existiert.

PHPgeprüft mit PHP 8.3
// Beweist nichts: prueft nur, dass nichts geworfen wurde
public function testBerechnung(): void
{
    $ergebnis = $this->rechner->brutto(1000);
    self::assertNotNull($ergebnis);
}

// Beweist etwas: nennt Eingabe und erwartetes Ergebnis
public function testBruttoMitRegelsatz(): void
{
    self::assertSame(1190, $this->rechner->brutto(1000));
}

// Beweist den Fehlerfall: hier liegt der eigentliche Wert
public function testNegativerBetragWirdAbgewiesen(): void
{
    $this->expectException(InvalidArgumentException::class);
    $this->rechner->brutto(-1);
}
Der erste Test bleibt grün, wenn brutto() falsch rechnet. Der zweite nicht. Der dritte prüft den Fall, der im Betrieb tatsächlich auftritt.

Die Gegenprobe gehört dazu

Ein neuer Test für einen gefundenen Fehler ist nur dann einer, wenn er OHNE die Korrektur durchfällt. Klingt selbstverständlich, wird aber regelmäßig übersprungen — und dann hat man einen Test, der den Fehler nicht bemerkt hätte.

Wir machen das deshalb ausdrücklich: Korrektur zurücknehmen, Test laufen lassen, rot sehen, Korrektur wieder einsetzen, grün sehen. Erst dann zählt er. Dasselbe gilt für Tests mit Platzhaltern: Wenn der Platzhalter das Ergebnis vorgibt, das geprüft werden soll, prüft der Test den Platzhalter.

Welche Fälle sich lohnen

  • Fachliche Regeln mit Grenzen: der letzte gültige und der erste ungültige Wert, nicht ein beliebiger aus der Mitte.
  • Alles, was mit Geld, Rechten oder Fristen zu tun hat.
  • Jeder einmal aufgetretene Fehler — damit er nicht zurückkommt.
  • Schritte, die mehrere Datensätze zugleich ändern: Entweder alles gilt oder nichts.

Was sich selten lohnt: Tests für Code ohne Entscheidung, etwa reines Durchreichen von Werten. Dort kostet der Test Pflege und findet nichts.

Ein Beispiel aus der Praxis

Was eine Abdeckungszahl nicht sagt

„85 Prozent Testabdeckung" bedeutet: 85 Prozent der Codezeilen wurden während der Tests einmal ausgeführt. Es bedeutet nicht, dass ihr Verhalten geprüft wurde. Eine Reihe von Tests ohne echte Erwartungen erzeugt hohe Abdeckung und findet nichts.

Die bessere Frage an ein Projekt lautet deshalb nicht „wie hoch ist die Abdeckung", sondern: Gibt es für die drei Regeln, die im Betrieb am meisten weh täten, je einen Test mit Eingabe und erwartetem Ergebnis — und fallen diese Tests durch, wenn man die Regel absichtlich kaputt macht?

Häufige Missverständnisse

Sie funktioniert in den geprüften Fällen. Ob die Seite im Browser erreichbar ist und die Teile zusammenspielen, sagt ein Test im Kleinen nicht.

Sie kosten Zeit beim Bauen und sparen sie bei jeder späteren Änderung — weil man danach weiß, ob man etwas kaputt gemacht hat, statt es zu hoffen.

Welche Fälle weh tun, wissen Sie besser als jeder Entwickler. Diese Fälle zu benennen, ist der wertvollste Beitrag, den Sie leisten können.

Über den Autor

Fabian Lücker ist geschäftsführender Gesellschafter der PHP-Schmiede KG in Rheine und seit 2007 in der Softwareentwicklung tätig. Er verantwortet Entwicklung und Konzeption und schreibt hier über Entscheidungen, die in echten Projekten anfallen.