Debugging: Fehler systematisch finden und beheben

Ein Programm kann Fehler haben, sogenannte Bugs. Zwei Tätigkeiten helfen dir dabei: Testen und Debuggen.

Beim Testen prüft und bewertet man ein Programm. Man vergleicht das Ist-Ergebnis mit dem Soll-Ergebnis. Das Ist-Ergebnis ist das, was das Programm wirklich liefert. Das Soll-Ergebnis ist das, was herauskommen soll. Danach steht fest: ok oder Fehler. Ein Test zeigt dir also, dass etwas nicht stimmt.

Beim Debuggen geht es um den nächsten Schritt. Man diagnostiziert den Fehler oder das unerwartete Verhalten, man sucht also die Ursache, und man behebt den Fehler. Das deutsche Wort dafür ist „entwanzen“. Beides gehört zusammen: Ein Test zeigt eine Abweichung, dann wird debuggt, danach wird wieder getestet.

Es gibt drei Arten von Fehlern.

Ein Syntaxfehler verstößt gegen die grammatischen Regeln der Programmiersprache, zum Beispiel durch eine fehlende Klammer oder ein fehlendes Semikolon. Ein Übersetzungsprogramm (Compiler) oder ein Interpreter weist ein solches Programm zurück. In der Regel entsteht dann kein ausführbarer Code, das Programm kann also nicht laufen. Die Zeilennummer in der Fehlermeldung zeigt oft den ungefähren Ort.

Ein Laufzeitfehler tritt auf, während das Programm läuft. Typische Beispiele sind Division durch Null oder eine fehlende Datei, aus der das Programm Daten holen soll. Das Programm kann dabei abstürzen, falsche Ergebnisse liefern oder sich nicht vorhersehbar verhalten. Auch ein „korrektes“ Programm kann bei der Ausführung zu Fehlern führen.

Bei einem Logikfehler läuft das Programm vollständig, aber die Ausgabe oder das Verhalten entspricht nicht den Erwartungen des Programmierers. Beispiele sind plus statt minus oder kleiner statt kleiner/gleich. Diese Art von Fehlern ist schwerer zu finden und zu beheben.

Achtung: Manche Autoren nennen auch logische Fehler, die zur Laufzeit ohne Abbruch auftreten, Laufzeitfehler. Hier gilt: Läuft das Programm vollständig und nur das Ergebnis stimmt nicht, sprechen wir von einem Logikfehler.

In der Regel ist der erste Schritt beim Debuggen, das unerwünschte Verhalten nachzustellen. Das Fachwort dafür ist „reproduzieren“. Das ist nicht immer leicht. Ein Bericht wie „das blöde Programm funktioniert nicht!“ ist viel zu allgemein. Auch „ich kann mich nicht mehr an die Fehlermeldung erinnern“ hilft kaum. Manche Fehler lassen sich nur schwer oder gar nicht zuverlässig nachstellen. Wiederholst du den Vorgang unter scheinbar gleichen Bedingungen, kann der Fehler ausbleiben.

Danach grenzt du den Fehler ein. Dafür gibt es drei Wege.

Zwischenausgaben: Du fügst Programmzeilen hinzu, die Zwischenergebnisse ausgeben, auf den Bildschirm oder in eine Logdatei (eine Datei, in die das Programm Meldungen schreibt). So findest du heraus, in welchem Schritt einer Berechnung ein Problem auftaucht oder wo das Programm unerwartet abbricht. Dabei kannst du den Bereich Schritt für Schritt kleiner machen, zum Beispiel erst in der Mitte des Programms nachsehen. Diese einfache Methode funktioniert nur bei „klassischen“ Bugs: Das Ergebnis ist offensichtlich falsch, oder das Programm stürzt bei einer bestimmten Eingabe reproduzierbar ab.

Haltepunkte: Ein Debugger ist ein Werkzeug zum Finden von Fehlern. Oft ist er Teil der Entwicklungsumgebung, in der man programmiert. Du setzt einen Haltepunkt (englisch Breakpoint) im Programmtext. Dort unterbricht das Programm. Dann kannst du den Zustand prüfen und Variablen ansehen. Ein bedingter Haltepunkt unterbricht nur dann, wenn die Zeile erreicht wird und eine von dir angegebene Bedingung wahr ist.

Schrittweise Ausführung: Du lässt das Programm Zeile für Zeile laufen, um schnell unerwartete Sprünge zu finden.

Ein Testfall beschreibt einen elementaren Test. Zu seiner Beschreibung gehören zum Beispiel die Eingabedaten und die erwarteten Ergebnisse. Außerdem gehören Vorbedingungen dazu, die vor dem Test hergestellt werden müssen. Weichen die Ausgaben von den erwarteten Werten ab, liegt eine Anomalie vor. Das kann ein Fehler sein, der behoben werden muss. Danach folgt in der Regel eine Testwiederholung.

Warum wiederholt man Tests nach einer Änderung? Wenn du einen Fehler behebst, können andere Funktionen plötzlich nicht mehr funktionieren. Es ist etwa möglich, dass einige Programmteile nur deshalb richtig funktionieren, weil der Fehler vorhanden ist. Ein Regressionsbug (Regression heißt „Rückschritt“) ist ein Fehler, der erst in einer späteren Programmversion auftaucht. Das sind häufig unerkannte Nebeneffekte von Fehlerbehebungen oder Änderungen an anderer Stelle. Solche Test-Wiederholungen nennt man auch Regressionstest.

Warum können Tests nicht beweisen, dass ein Programm fehlerfrei ist? Ein Test stellt nur fest, dass bestimmte Testfälle erfolgreich waren. Um Fehlerfreiheit zu belegen, müssten alle Funktionen und alle möglichen Eingabewerte in allen Kombinationen getestet werden. Das ist, außer bei sehr einfachen Testobjekten, praktisch nicht möglich. Tests sind immer nur Stichproben. Selbst teure oder vielfach getestete Software enthält Programmierfehler.