IM6 - Debugging – Fehler finden
IM6 - Debugging – Fehler finden
Einleitung
Beim Programmieren klappt selten alles sofort. Ein Spiel startet nicht, eine Figur läuft in die falsche Richtung, ein Punktestand verhält sich merkwürdig oder eine Schleife wird viel öfter ausgeführt als geplant. Genau dann brauchst Du Debugging: eine systematische Fehlersuche in Programmen.
In diesem aiMOOC lernst Du nicht einfach nur, einen Fehler „irgendwie“ zu beheben. Du trainierst vier wichtige Denkweisen:
- Erwartung formulieren: Was soll das Programm tun?
- Ablauf nachvollziehen: Was passiert Schritt für Schritt?
- Fehler lokalisieren: An welcher Stelle weicht das Programm vom Soll ab?
- Testen: Funktioniert die Änderung wirklich – auch in mehreren Situationen?
Die Beispiele sind an blockbasiertes Programmieren wie Scratch angelehnt. Die Programme werden teilweise absichtlich als fehlerhafter Pseudocode gezeigt. Du sollst also nicht nur lesen, sondern wie eine Debugging-Detektivin oder ein Debugging-Detektiv denken.
Scratch ist eine blockbasierte Programmierumgebung, die besonders für Kinder und Jugendliche entwickelt wurde. Gerade bei Spielen kannst Du Fehler gut beobachten: Figuren bewegen sich sichtbar, Kollisionen lassen sich testen und Wiederholungen können gezählt werden.
Beim Video kannst Du bewusst mitdenken: Welche Blöcke bestimmen den Start? Wo wird eine Figur bewegt? Welche Schleifen oder Bedingungen müssten bei einem Fehler überprüft werden?
Was bedeutet Debugging?
Ein Bug ist ein Fehler in einem Programm oder Computersystem. Debugging bedeutet, die Ursache eines Fehlers zu suchen, einzugrenzen und zu beheben. Ein wichtiger Unterschied ist:
Testen zeigt Dir, dass etwas nicht wie erwartet funktioniert. Debugging hilft Dir herauszufinden, warum es nicht funktioniert.
Ein hilfreicher Ablauf lautet:
ERWARTUNG festlegen
↓
PROGRAMM ausführen
↓
BEOBACHTUNG notieren
↓
SCHRITT FÜR SCHRITT nachvollziehen
↓
FEHLERSTELLE eingrenzen
↓
EINE Änderung durchführen
↓
ERNEUT testen
Debugging ist also kein wildes Ausprobieren. Gute Fehlersuche folgt einer Spur.
Woher kommt das Wort Bug?
Das englische Wort bug wurde schon vor der Computerzeit für technische Störungen verwendet. Berühmt wurde eine Geschichte aus dem Jahr 1947: In einem Relais des Rechners Harvard Mark II wurde tatsächlich eine Motte gefunden und in das Logbuch geklebt. Das war ein scherzhafter „echter Bug“ – aber nicht der Ursprung des Wortes.
Die Geschichte ist trotzdem ein gutes Bild für Debugging: Ein Problem wird beobachtet, die Ursache wird gefunden und anschließend wird überprüft, ob das System wieder funktioniert.
Das wichtigste Debugging-Werkzeug: SOLL und IST
Bevor Du Code änderst, solltest Du zwei Dinge klar formulieren.
| Frage | Beispiel |
|---|---|
| SOLL | Nach dem Drücken der rechten Pfeiltaste bewegt sich die Figur 10 Schritte nach rechts. |
| IST | Nach dem Drücken der rechten Pfeiltaste bewegt sich die Figur 10 Schritte nach links. |
Schon dieser Vergleich hilft: Das Spiel reagiert auf die richtige Taste. Der Start und das Tastaturereignis funktionieren also wahrscheinlich. Der Fehler liegt eher bei der Richtung oder beim Vorzeichen der Bewegung.
Das ist ein wichtiges Prinzip: Nutze jede Beobachtung, um mögliche Fehlerstellen auszuschließen.
Debugging-Protokoll
Ein einfaches Debugging-Protokoll kann so aussehen:
| Schritt | Leitfrage | Beispiel |
|---|---|---|
| 1 | Was erwarte ich? | Figur bewegt sich nach rechts. |
| 2 | Was beobachte ich? | Figur bewegt sich nach links. |
| 3 | Wo könnte die Ursache liegen? | Im Bewegungsbefehl. |
| 4 | Wie teste ich die Vermutung? | Vorzeichen der x-Änderung prüfen. |
| 5 | Was ändere ich? | -10 durch +10 ersetzen. |
| 6 | Wie prüfe ich die Lösung? | Taste mehrfach drücken und Position beobachten. |
Dieses Protokoll trainiert Dich darin, nicht sofort irgendeinen Block zu verschieben, sondern eine begründete Vermutung zu testen.
Programme Schritt für Schritt lesen
Computer führen Anweisungen in einer festgelegten Reihenfolge aus. Beim Debugging hilft es, den Ablauf langsam nachzuspielen. Das nennt man oft Tracing oder Ablaufverfolgung.
Ein Programmablaufplan oder Flussdiagramm stellt einen Algorithmus grafisch dar. Typische Elemente sind Start und Ende, Anweisungen, Entscheidungen und Pfeile für die Reihenfolge.
Mini-Tracing: Wo ist die Figur?
Gegeben ist dieses Programm:
SETZE x AUF 0 ÄNDERE x UM 10 ÄNDERE x UM 10 ÄNDERE x UM -5
Verfolge den Wert von x:
| Schritt | Befehl | x vorher | x nachher |
|---|---|---|---|
| 1 | SETZE x AUF 0 | unbekannt | 0 |
| 2 | ÄNDERE x UM 10 | 0 | 10 |
| 3 | ÄNDERE x UM 10 | 10 | 20 |
| 4 | ÄNDERE x UM -5 | 20 | 15 |
Wenn das Programm am Ende x = 25 liefern sollte, erkennst Du beim Tracing genau, ab welchem Schritt die Werte nicht mehr zur Erwartung passen.
Debugging-Strategie für Klasse 6
Merke Dir die Kurzform E-A-F-T:
- Erwarten: Beschreibe genau, was passieren soll.
- Ablaufen: Gehe das Programm Schritt für Schritt durch.
- Fehler finden: Suche die erste Stelle, an der SOLL und IST auseinandergehen.
- Testen: Ändere möglichst nur eine Sache und prüfe erneut.
Wenn Du gleichzeitig fünf Blöcke änderst und das Programm danach funktioniert, weißt Du nicht, welche Änderung den Fehler behoben hat. Deshalb gilt:
Eine Vermutung – eine Änderung – ein Test.
Use-Case 1: Das Spiel funktioniert nicht
Stell Dir ein Fangspiel vor. Nach dem Klick auf die grüne Flagge soll die Spielfigur in der Mitte starten und der Punktestand soll auf 0 gesetzt werden. Doch es passiert gar nichts.
Fehlerhaftes Programm A: falscher Start
WENN TASTE LEERTASTE GEDRÜCKT SETZE x AUF 0 SETZE y AUF 0 SETZE PUNKTE AUF 0 STARTE SPIEL
Erwartung: Das Spiel startet beim Klick auf die grüne Flagge. Beobachtung: Beim Klick auf die grüne Flagge passiert nichts.
Die Zeilen im Programm können korrekt sein, aber das Ereignis am Anfang ist falsch. Das Programm wartet auf die Leertaste.
Eine mögliche Korrektur ist:
WENN GRÜNE FLAGGE ANGEKLICKT SETZE x AUF 0 SETZE y AUF 0 SETZE PUNKTE AUF 0 STARTE SPIEL
Debugging-Lektion: Wenn ein Programm gar nicht beginnt, prüfe zuerst das Startereignis.
Fehlerhaftes Programm B: Startsignal erreicht die Spielfigur nicht
BÜHNE: WENN GRÜNE FLAGGE ANGEKLICKT SENDE "START" FIGUR: WENN ICH "LOS" EMPFANGE GEHE ZU x:0 y:0 ZEIGE DICH
Die Bühne sendet START, die Figur wartet aber auf LOS. Beide Namen müssen zusammenpassen.
Testidee: Füge vorübergehend einen sichtbaren Hinweis ein:
WENN ICH "START" EMPFANGE SAGE "Startsignal angekommen" FÜR 1 SEKUNDE
Wenn der Text erscheint, weißt Du: Das Signal kommt an. Danach kannst Du die nächsten Blöcke prüfen.
Ablaufdiagramm zum Startfehler
[Start: grüne Flagge]
|
v
[Signal START senden]
|
v
<Empfängt Figur START?>
/ \
ja nein
| |
v v
[Figur [Fehler bei
initialisieren] Signalname /
| Empfänger]
v
[Spiel läuft]
Dieses Diagramm hilft Dir beim Eingrenzen. Wenn die Figur kein Startsignal empfängt, musst Du noch nicht über Bewegung oder Kollision nachdenken.
Use-Case 2: Die Figur bewegt sich falsch
Die Figur soll sich mit den Pfeiltasten bewegen. Rechts soll wirklich rechts sein, links soll links sein.
Fehlerhaftes Programm C: falsches Vorzeichen
WENN TASTE RECHTSPFEIL GEDRÜCKT ÄNDERE x UM -10
SOLL: x wird größer. IST: x wird kleiner.
Die Korrektur lautet:
WENN TASTE RECHTSPFEIL GEDRÜCKT ÄNDERE x UM 10
Debugging-Test: Starte bei x = 0. Drücke die rechte Pfeiltaste genau dreimal. Danach sollte x = 30 sein.
Fehlerhaftes Programm D: falsche Achse
WENN TASTE PFEIL NACH OBEN GEDRÜCKT ÄNDERE x UM 10
Die Figur bewegt sich nach rechts statt nach oben. Für die Bewegung nach oben muss die y-Koordinate verändert werden:
WENN TASTE PFEIL NACH OBEN GEDRÜCKT ÄNDERE y UM 10
Merksatz: x steuert links und rechts, y steuert unten und oben.
Fehlerhaftes Programm E: Bewegung wird sofort zurückgesetzt
WIEDERHOLE FORTLAUFEND
SETZE x AUF 0
WENN TASTE RECHTSPFEIL GEDRÜCKT
ÄNDERE x UM 10
Die Figur kann kurz nach rechts springen, wird aber im nächsten Schleifendurchlauf wieder auf x = 0 gesetzt.
Eine bessere Struktur ist:
SETZE x AUF 0
WIEDERHOLE FORTLAUFEND
WENN TASTE RECHTSPFEIL GEDRÜCKT
ÄNDERE x UM 10
Debugging-Lektion: Prüfe nicht nur einzelne Blöcke, sondern auch, wie oft sie ausgeführt werden.
Ablaufdiagramm zur Bewegung
[Spiel läuft]
|
v
<Taste rechts gedrückt?>
/ \
nein ja
| |
| v
| [x um +10 ändern]
| |
+------------+
|
v
[nächste Prüfung]
Der entscheidende Testpunkt ist: Wird bei „ja“ wirklich die richtige Variable mit dem richtigen Vorzeichen verändert?
Use-Case 3: Die Schleife läuft zu oft
Schleifen wiederholen Befehle. Genau deshalb können kleine Fehler große Auswirkungen haben.
Fehlerhaftes Programm F: falsche Wiederholungszahl
Die Figur soll genau drei Sterne erzeugen.
WIEDERHOLE 30 MAL ERZEUGE STERN
Das Programm läuft technisch korrekt, aber die Zahl ist falsch.
Korrektur:
WIEDERHOLE 3 MAL ERZEUGE STERN
Wichtig: Nicht jeder Bug führt zu einem Absturz. Ein Programm kann vollständig laufen und trotzdem das falsche Ergebnis liefern.
Fehlerhaftes Programm G: Zähler wird nicht verändert
Die Schleife soll enden, wenn der Zähler 5 erreicht.
SETZE ZÄHLER AUF 0 WIEDERHOLE BIS ZÄHLER = 5 SAGE "Runde"
Der Zähler bleibt immer 0. Die Bedingung wird deshalb nie wahr.
Korrektur:
SETZE ZÄHLER AUF 0 WIEDERHOLE BIS ZÄHLER = 5 SAGE "Runde" ÄNDERE ZÄHLER UM 1
Beim Debugging kannst Du die Zählerwerte sichtbar machen:
SETZE ZÄHLER AUF 0 WIEDERHOLE BIS ZÄHLER = 5 SAGE ZÄHLER ÄNDERE ZÄHLER UM 1
So siehst Du die Folge 0, 1, 2, 3, 4 und kannst überprüfen, ob die Schleife passend endet.
Fehlerhaftes Programm H: Bedingung falsch herum
SETZE ZÄHLER AUF 0 WIEDERHOLE BIS ZÄHLER < 5 ÄNDERE ZÄHLER UM 1
Da 0 bereits kleiner als 5 ist, kann die Schleife sofort enden. Gemeint war etwa:
SETZE ZÄHLER AUF 0 WIEDERHOLE BIS ZÄHLER = 5 ÄNDERE ZÄHLER UM 1
Debugging-Frage: Ist die Abbruchbedingung am Anfang schon wahr? Dann startet die Wiederholung möglicherweise gar nicht.
Ablaufdiagramm für eine Zählschleife
[Zähler = 0]
|
v
<Zähler = 5?>
/ \
ja nein
| |
v v
[Ende] [Aktion]
|
v
[Zähler + 1]
|
+------ zurück zur Prüfung
Weitere typische Bugs in Spielen
Fehlerhaftes Programm I: Punktestand wird ständig gelöscht
WIEDERHOLE FORTLAUFEND
SETZE PUNKTE AUF 0
WENN FIGUR BERÜHRT MÜNZE
ÄNDERE PUNKTE UM 1
Der Punktestand wird in jedem Schleifendurchlauf wieder auf 0 gesetzt.
Besser:
SETZE PUNKTE AUF 0
WIEDERHOLE FORTLAUFEND
WENN FIGUR BERÜHRT MÜNZE
ÄNDERE PUNKTE UM 1
Debugging-Lektion: Initialisierung gehört meist vor die Hauptschleife.
Fehlerhaftes Programm J: Punkte steigen zu schnell
WIEDERHOLE FORTLAUFEND
WENN FIGUR BERÜHRT MÜNZE
ÄNDERE PUNKTE UM 1
Wenn die Figur die Münze mehrere Schleifendurchläufe lang berührt, können in sehr kurzer Zeit viele Punkte entstehen.
Eine mögliche Lösung:
WIEDERHOLE FORTLAUFEND
WENN FIGUR BERÜHRT MÜNZE
ÄNDERE PUNKTE UM 1
VERSTECKE MÜNZE
WARTE 1 SEKUNDE
SETZE MÜNZE AN NEUE POSITION
ZEIGE MÜNZE
Jetzt sorgt die Änderung dafür, dass eine Berührung nicht dauerhaft weitergezählt wird.
Fehlerhaftes Programm K: Springen in die falsche Richtung
WENN TASTE LEERTASTE GEDRÜCKT
WIEDERHOLE 5 MAL
ÄNDERE y UM -10
Die Figur soll nach oben springen, bewegt sich aber nach unten. Prüfe das Vorzeichen. Für den Aufstieg muss y zunächst größer werden.
Eine einfache Sprungidee:
WENN TASTE LEERTASTE GEDRÜCKT
WIEDERHOLE 5 MAL
ÄNDERE y UM 10
WIEDERHOLE 5 MAL
ÄNDERE y UM -10
Fehlerhaftes Programm L: Die Figur läuft durch die Wand
WENN TASTE RECHTSPFEIL GEDRÜCKT ÄNDERE x UM 10 WENN FIGUR BERÜHRT WAND SAGE "Aua!"
Das Programm erkennt zwar die Wand, korrigiert aber die Position nicht. Eine mögliche Verbesserung:
WENN TASTE RECHTSPFEIL GEDRÜCKT
ÄNDERE x UM 10
WENN FIGUR BERÜHRT WAND
ÄNDERE x UM -10
Damit wird die letzte Bewegung zurückgenommen.
Debugging mit Erwartungen
Eine starke Debugging-Technik besteht darin, vor jedem wichtigen Schritt vorherzusagen, was passieren müsste.
Beispiel:
SETZE PUNKTE AUF 0 WIEDERHOLE 3 MAL ÄNDERE PUNKTE UM 2
Vorhersage:
Start: 0 nach Runde 1: 2 nach Runde 2: 4 nach Runde 3: 6
Wenn Du beim tatsächlichen Test die Werte 0, 2, 4, 6 beobachtest, stimmt der Ablauf. Wenn Du 0, 2, 2, 2 siehst, kannst Du gezielt fragen: Warum wird nach der ersten Runde nicht weiter erhöht?
Trace-Tabelle als Fehlerlupe
Für dieses fehlerhafte Programm:
SETZE LEBEN AUF 3 WIEDERHOLE 4 MAL ÄNDERE LEBEN UM -1
ergibt sich:
| Zeitpunkt | Leben | Erwartung bei maximal drei Treffern |
|---|---|---|
| Start | 3 | 3 |
| nach Runde 1 | 2 | 2 |
| nach Runde 2 | 1 | 1 |
| nach Runde 3 | 0 | 0 |
| nach Runde 4 | -1 | Spiel sollte bereits beendet sein |
Die erste auffällige Stelle ist Runde 4. Genau dort solltest Du die Schleife oder Abbruchbedingung untersuchen.
Fehler eingrenzen statt raten
Wenn ein Spiel aus vielen Teilen besteht, solltest Du den Fehlerbereich verkleinern.
Beispiel: Die Spielfigur sammelt keine Münzen.
- Prüfe zuerst: Kann sich die Figur bewegen?
- Prüfe dann: Berührt die Figur die Münze wirklich?
- Prüfe dann: Wird die Kollisionsbedingung wahr?
- Prüfe dann: Wird der Punktestand verändert?
- Prüfe zuletzt: Wird der Punktestand vielleicht direkt wieder zurückgesetzt?
So teilst Du ein großes Problem in kleine prüfbare Fragen.
Sichtbare Testausgaben
Eine einfache Debugging-Hilfe ist eine zusätzliche Ausgabe:
WENN FIGUR BERÜHRT MÜNZE SAGE "Kollision erkannt" ÄNDERE PUNKTE UM 1
Wenn „Kollision erkannt“ erscheint, aber die Punkte nicht steigen, liegt der Fehler wahrscheinlich nach der Kollisionsprüfung.
Wenn der Text nicht erscheint, liegt der Fehler wahrscheinlich vor oder in der Kollisionsprüfung.
Testfälle planen
Ein guter Test besteht nicht nur aus „einmal klicken“. Überlege verschiedene Situationen.
| Testfall | Eingabe oder Situation | Erwartetes Ergebnis |
|---|---|---|
| Start | Grüne Flagge | Figur startet in der Mitte, Punkte = 0 |
| Bewegung rechts | Rechtspfeil einmal | x wird um 10 größer |
| Bewegung links | Linkspfeil einmal | x wird um 10 kleiner |
| Münze | Figur berührt Münze | Punkte steigen genau um 1 |
| Wand | Figur berührt rechte Wand | Figur bleibt im Spielfeld |
| Schleife | Runde startet | Genau 3 Gegner erscheinen |
Mit solchen Testfällen überprüfst Du nicht nur den Bugfix, sondern auch, ob durch die Änderung etwas anderes kaputtgegangen ist.
Debugging mit Ablaufdiagrammen
Ablaufdiagramme sind besonders hilfreich, wenn Du bei Bedingungen und Schleifen den Überblick verlierst.
Ablaufdiagramm: Münze einsammeln
[Spiel läuft]
|
v
<Berührt Figur Münze?>
/ \
nein ja
| |
| v
| [Punkte + 1]
| |
| v
| [Münze neu setzen]
| |
+-------------+
|
v
[erneut prüfen]
Debugging-Frage: Wenn die Punkte zu schnell steigen, fehlt vielleicht der Schritt „Münze neu setzen“ oder die Figur bleibt zu lange im Berührungszustand.
Ablaufdiagramm: Spielende
[Start mit 3 Leben]
|
v
[Spiel läuft]
|
v
<Spieler getroffen?>
/ \
nein ja
| |
| v
| [Leben - 1]
| |
| v
| <Leben = 0?>
| / \
| nein ja
| | |
+--------+ v
[Spielende]
Ein Fehler kann entstehen, wenn die Prüfung „Leben = 0?“ fehlt oder an der falschen Stelle steht.
Debugging-Regeln für gute Fehlersucherinnen und Fehlersucher
- Ändere nicht sofort den Code, sondern beschreibe zuerst den Fehler.
- Schreibe SOLL und IST auf.
- Reproduziere den Fehler: Kannst Du ihn erneut auslösen?
- Prüfe den Ablauf in kleinen Schritten.
- Beobachte Variablenwerte und Zähler.
- Ändere möglichst nur eine Sache auf einmal.
- Teste danach nicht nur den alten Fehlerfall, sondern auch andere wichtige Fälle.
- Bewahre funktionierende Zwischenschritte auf.
Vom Spiel zum echten Programmieren
Die gleichen Denkweisen gelten auch außerhalb von Scratch. In textbasierten Programmiersprachen kann ein Debugger Programme Schritt für Schritt ausführen, Variablen anzeigen und an Haltepunkten anhalten. Für Dich ist zunächst vor allem die Denkweise wichtig: Erwartung – Beobachtung – Eingrenzung – Test.
Beim Betrachten eines Spiel-Tutorials kannst Du selbst eine Debugging-Challenge daraus machen: Stoppe vor einem Programmschritt und sage voraus, wie sich die Figur, der Punktestand oder eine Schleife verhalten müsste.
Interaktive Aufgaben
Quiz: Teste Dein Wissen
Was ist der erste sinnvolle Schritt beim Debugging? (Genau beschreiben was das Programm tun soll) (!Mehrere Blöcke gleichzeitig ändern) (!Das ganze Programm löschen) (!Nur auf gut Glück testen)
Eine Figur soll nach rechts laufen bewegt sich aber nach links. Was prüfst Du zuerst? (Das Vorzeichen der Änderung von x) (!Die Lautstärke) (!Die Hintergrundfarbe) (!Den Namen des Projekts)
Was zeigt eine Trace-Tabelle? (Werte und Zustände Schritt für Schritt) (!Nur die Farbe der Spielfigur) (!Nur den fertigen Programmcode) (!Die Internetgeschwindigkeit)
Eine Schleife soll fünfmal laufen läuft aber endlos. Was ist eine typische Ursache? (Der Zähler wird nicht verändert) (!Die Figur hat ein Kostüm) (!Der Bildschirm ist zu groß) (!Die Maus wurde bewegt)
Warum sollte man beim Debugging möglichst nur eine Sache gleichzeitig ändern? (Damit man erkennt welche Änderung den Fehler beeinflusst hat) (!Damit das Programm langsamer wird) (!Damit weniger Variablen existieren) (!Damit alle Schleifen verschwinden)
Was bedeutet SOLL beim Debugging? (Das erwartete Verhalten) (!Das beobachtete Verhalten) (!Der Dateiname) (!Die Anzahl der Figuren)
Warum ist ein Testfall nützlich? (Er legt Eingabe und erwartetes Ergebnis fest) (!Er ersetzt das Programm) (!Er verhindert jede Schleife) (!Er ändert automatisch alle Fehler)
Eine Figur reagiert gar nicht auf den Start. Was solltest Du früh prüfen? (Das Startereignis) (!Nur die Punktzahl) (!Nur die Kostümfarbe) (!Nur die Größe der Bühne)
Wann ist eine Debugging-Vermutung besonders gut? (Wenn sie mit einem gezielten Test überprüft werden kann) (!Wenn sie möglichst kompliziert klingt) (!Wenn sie ohne Beobachtung entsteht) (!Wenn gleichzeitig viele Stellen geändert werden)
Was solltest Du nach einem Bugfix tun? (Das Programm erneut mit mehreren passenden Testfällen prüfen) (!Sofort alle Tests löschen) (!Alle Variablen umbenennen) (!Das Programm nicht mehr starten)
Memory
| Debugging | systematische Fehlersuche |
| SOLL | erwartetes Verhalten |
| IST | beobachtetes Verhalten |
| Trace | schrittweises Nachvollziehen |
| Bug | Programmfehler |
| Testfall | Eingabe mit erwartetem Ergebnis |
| Schleife | wiederholte Ausführung |
| Bedingung | Entscheidung im Programm |
Drag and Drop
| Ordne die richtigen Begriffe zu. | Thema |
|---|---|
| Startereignis prüfen | Spiel reagiert beim Start überhaupt nicht |
| Vorzeichen prüfen | Figur läuft nach links statt nach rechts |
| Achse prüfen | Figur läuft seitwärts statt nach oben |
| Zähler prüfen | Schleife läuft zu oft oder endlos |
| Initialisierung prüfen | Punktestand springt immer wieder auf null |
| Kollisionsbedingung prüfen | Münze wird berührt aber nicht erkannt |
| Abbruchbedingung prüfen | Spiel endet trotz null Leben nicht |
Debugging-Drag-and-Drop: Schrittfolge
| Ordne die richtigen Begriffe zu. | Debugging-Schritt |
|---|---|
| Erwartung formulieren | Was soll passieren |
| Beobachtung notieren | Was passiert tatsächlich |
| Ablauf verfolgen | Werte und Befehle Schritt für Schritt prüfen |
| Fehlerstelle eingrenzen | Erste Abweichung zwischen Soll und Ist suchen |
| Vermutung testen | Eine gezielte Änderung ausprobieren |
| Ergebnis prüfen | Mehrere passende Testfälle erneut durchführen |
Interaktive Debugging-Aufgabe: Drei Spielefehler
| Ordne die passende Korrektur zu. | Fehlerbild |
|---|---|
| x um 10 ändern | Rechtspfeil bewegt Figur nach links weil x um minus 10 geändert wird |
| y um 10 ändern | Pfeil nach oben bewegt Figur seitwärts |
| Wiederhole 3 mal | Es erscheinen 30 statt 3 Gegner |
| Zähler um 1 erhöhen | Wiederhole-bis-Schleife endet nie |
| Punkte vor der Schleife auf null setzen | Punktestand wird ständig gelöscht |
Kreuzworträtsel
| Debugging | Wie nennt man die systematische Suche nach Programmfehlern? |
| Schleife | Wie heißt eine Programmstruktur für Wiederholungen? |
| Variable | Wo kann ein Programm veränderliche Werte speichern? |
| Testfall | Wie nennt man eine festgelegte Prüfsituation mit erwartetem Ergebnis? |
| Bedingung | Wie heißt eine Prüfung die über einen weiteren Ablauf entscheidet? |
| Ablaufplan | Wie kann ein Algorithmus grafisch mit Pfeilen und Symbolen dargestellt werden? |
LearningApps
Lückentext
Offene Aufgaben
Leicht
- SOLL-IST-Protokoll: Nimm ein kleines Spiel und beschreibe für drei Aktionen jeweils SOLL und IST.
- Bewegungsfehler: Erstelle absichtlich ein Programm, bei dem die rechte Pfeiltaste die Figur nach links bewegt. Tausche mit einer Partnerperson und lasse den Fehler finden.
- Trace-Tabelle: Erfinde ein Programm mit vier Änderungen an einer Variablen und erstelle dazu eine Tabelle mit den Werten nach jedem Schritt.
- Schleifenbeobachtung: Baue eine Schleife, die genau fünf sichtbare Aktionen ausführt, und dokumentiere, wie Du überprüfst, dass es wirklich fünf sind.
Standard
- Debugging-Spiel: Programmiere ein Minispiel mit drei absichtlich eingebauten Fehlern. Erstelle Hinweise, damit andere die Fehler systematisch finden können.
- Ablaufdiagramm: Zeichne ein Ablaufdiagramm für „Figur sammelt Münze und erhält einen Punkt“. Baue danach absichtlich einen Fehler in das Diagramm ein und lasse ihn korrigieren.
- Testplan: Entwickle mindestens sechs Testfälle für ein Spiel mit Bewegung, Punkten und Spielende.
- Fehlerinterview: Befrage eine Mitschülerin oder einen Mitschüler beim Debugging. Notiere, welche Vermutungen zuerst aufgestellt und wie sie getestet wurden.
Schwer
- Fehlerbibliothek: Sammle fünf unterschiedliche Bug-Arten aus eigenen Programmen und ordne jedem Bug ein Symptom, eine Ursache, eine Korrektur und einen Test zu.
- Debugging-Challenge: Erstelle ein Spiel, bei dem ein Fehler nur unter einer bestimmten Bedingung auftritt. Beschreibe, wie man ihn reproduzieren kann.
- Vergleich von Strategien: Löse denselben Fehler einmal durch zufälliges Ausprobieren und einmal mit SOLL-IST, Trace und Testfällen. Vergleiche Zeit, Übersicht und Sicherheit der Lösung.
- Debugging-Tutorial: Produziere ein kurzes Erklärvideo, in dem Du an einem fehlerhaften Programm Erwartung, schrittweises Nachvollziehen, Fehlerlokalisierung und erneutes Testen demonstrierst.
|
|
Lernkontrolle
- Fehlerursache begründen: Eine Figur bewegt sich nach dem Rechtspfeil nach links. Erkläre zwei mögliche Ursachen und entwirf für jede Ursache einen Test, mit dem Du sie unterscheiden kannst.
- Schleife analysieren: Ein Programm erzeugt mehr Gegner als geplant. Beschreibe, welche Informationen Du beobachten möchtest, bevor Du den Code änderst, und begründe Deine Auswahl.
- Testfälle entwickeln: Für ein Spiel mit drei Leben soll das Spiel bei null Leben enden. Entwickle Testfälle, die nicht nur den Normalfall, sondern auch Grenzfälle prüfen.
- Ablauf rekonstruieren: Du beobachtest die Variablenfolge 0, 1, 2, 3, 4, 5, 6 obwohl die Schleife bei 5 enden sollte. Erkläre, an welchen Stellen Du nach dem Fehler suchen würdest.
- Bugfix bewerten: Eine Person behebt einen Fehler, indem sie gleichzeitig fünf Blöcke verändert. Erkläre, warum diese Methode problematisch ist, obwohl das Spiel danach funktioniert.
- Transferaufgabe Debugging: Übertrage die Debugging-Schritte auf einen Alltagsfehler, zum Beispiel eine Lampe, die nicht leuchtet. Zeige Gemeinsamkeiten zwischen technischer Fehlersuche und Programmdiagnose.
Lernnachweis
Für einen Lernnachweis zu diesem Thema ist wichtig, dass Du nicht nur einen fertigen Bugfix zeigst, sondern Deinen Denkweg nachvollziehbar machst.
- Du formulierst das erwartete Verhalten als klares SOLL.
- Du beschreibst die tatsächliche Beobachtung als IST.
- Du kannst einen Programmablauf Schritt für Schritt nachvollziehen.
- Du erkennst typische Fehler bei Ereignissen, Bewegungsrichtungen, Achsen, Variablen, Bedingungen und Schleifen.
- Du grenzt eine Fehlerstelle mit Beobachtungen oder Testausgaben ein.
- Du formulierst eine überprüfbare Vermutung zur Ursache.
- Du veränderst gezielt eine passende Programmstelle.
- Du verwendest mehrere Testfälle, um die Korrektur zu prüfen.
- Du kannst erklären, warum Deine Änderung den Fehler behebt.
- Du dokumentierst mindestens einen Debugging-Prozess vollständig von der Erwartung bis zum abschließenden Test.
OERs zum Thema
Verknüpfte Lernbereiche