Software testen, Fehler aufspüren

Die menschliche Weise, logisch zu denken, funktioniert nachweislich gut[1]. Nur zum Programmieren eignet sie sich offenbar nicht besonders. Auch sehr erfahrene Entwickler machen wieder und wieder die gleichen Fehler. Rund 30 Prozent des Gesamtaufwands eines typischen Softwareprojekts entfallen darum auf Fehlersuche und Tests.

Einfache Fehler sind auch einfach zu finden

Die simplen Missgeschicke - Syntaxfehler, vertippte Variablennamen oder nicht eingebundene Bibliotheken - finden schon Compiler und Linker. Von einer schlecht gedachten Schleifenbedingung oder einem unerwarteten Rückgabewert einer Funktion erfährt der Programmierer so jedoch nichts. In ganz einfachen Fällen behilft er sich mit zusätzlich eingebauten Statusmeldungen, die beispielsweise Variableninhalte über die Konsole ausgeben.

Fehler in der Zeigerarithmetik oder ähnlich vertrackte Dinge sind so nicht zu finden - ein Debugger wie der Klassiker GDB (siehe Workshop ab Seite 28) oder der bedienerfreundliche DDD (Seite 36) müssen her. Eine sündteure Tool-Suite wie Purify Plus ist für die brettharten Fälle genau richtig.

Prävention statt Absturz

Test-getriebene Entwicklung [2] soll grobe Programmierfehler vorab vermeiden und damit den Einsatz des Debuggers seltener machen. Bei diesem Modell überprüfen Unit-Tests die Funktion kleiner, überschaubarer Programmeinheiten. Die Tests schreibt der Programmierer am Anfang seiner Arbeit und gibt damit den Entwicklungsweg des Produktionscode vor. Der Artikel auf Seite 50 gibt Einblick in diese Methode und zeigt einige Tests in der leicht verständlichen Skriptsprache Ruby.

Komplexere Testsituationen mit vielen Programmmodulen lassen sich aber nur mit viel Aufwand als Unit-Test nachstellen. Mock-Objekte, die so tun, als wären sie echte Objekte aus dem Produktionscode, können helfen - etwa das Mockpp-Paket unter C++ (Seite 44). Die Komplexität dieser Lösung zeigt auch, wie schnell der Programmieraufwand für die Testumgebung steigt - oft ist sie aufwändiger als der Produktionscode. Entsprechend vergrößert sich das Fehlerpotenzial der Tests selbst.

Letztlich gilt es, die Balance zwischen dem Aufwand für die Tests und ihrem Nutzen zu finden. Das Maß richtet sich dabei stark nach dem Anwendungsfeld. Wer eine Textverarbeitung programmiert, wird - die Endanwender mögen das verzeihen - weniger Aufwand in komplexe Tests stecken, als es der Entwickler einer kritischeren Anwendung tun muss.

Ein plastisches Beispiel unterlassener Test- und Debugging-Leistung lieferte am 4. Juni 1996 die Ariane-5-Rakete infolge eines unentdeckten Programmierfehlers in einem ihrer Bordcomputer [3]. Außerhalb der Reichweite jedes Debuggers und unbeeindruckt von menschlicher Logik explodierte der Stolz europäischer Raumfahrt in 3700 Meter Höhe.