aiMOOC

Informatik - Korrekturen und Regressionen dokumentieren

QR-Code

Informatik – Korrekturen und Regressionen dokumentieren

Dieser aiMOOC richtet sich an Lernende ab Klasse 5/6. Du lernst, wie man einen beobachteten Fehler nachvollziehbar festhält, eine gezielte Korrektur beschreibt und danach prüft, ob der Fehlerfall wirklich behoben wurde und ob zuvor bestandene Fälle weiterhin funktionieren. Dieses erneute Prüfen bereits bekannter Testfälle gehört zum Gedanken des Regressionstests.

Wichtig: Ein bestandener Test beweist nur etwas über die tatsächlich geprüften Fälle und Bedingungen. Er ist keine Garantie dafür, dass ein Programm in allen möglichen Situationen fehlerfrei ist.

Mediennachweis: „SDLC - Software Development Life Cycle.jpg“, Urheber: Cliffydcw, 22.03.2012, Wikimedia Commons, Lizenz CC BY-SA 3.0. Das Bild zeigt einen vereinfachten Software-Lebenszyklus und macht sichtbar, dass Testen und Weiterentwicklung zusammengehören. Quelle und Lizenz: https://commons.wikimedia.org/wiki/File:SDLC_-_Software_Development_Life_Cycle.jpg. Alternativtext: Kreisdiagramm eines Software-Lebenszyklus mit Anforderungsanalyse, Entwurf, Implementierung, Testen und Weiterentwicklung.

Einleitung

Programme werden von Menschen entwickelt. Dabei können Fehler entstehen. Beim Testen wird ein Programm mit ausgewählten Eingaben ausgeführt und sein beobachtetes Ergebnis mit einem vorher festgelegten erwarteten Ergebnis verglichen. Wird ein Fehler entdeckt und der Programmcode geändert, reicht es nicht, nur zu sagen: „Jetzt geht es.“ Eine gute Dokumentation hält fest, was beobachtet wurde, welche Regel gelten sollte, was geändert wurde, welche Fälle erneut geprüft wurden und welche Bewertung daraus zulässig ist.

Für diesen Kurs brauchst Du keinen Computer. Alle Kernaufgaben lassen sich auf Papier durchführen. Die Beispiele verwenden einfache Entscheidungsregeln, Tabellen und Pseudocode.

Sicher und datensparsam arbeiten

Für die Übungen werden keine privaten oder personenbezogenen Daten benötigt. Verwende erfundene Zahlen und neutrale Beispieldaten. Es sind keine gefährlichen Versuche, keine externen KI-Aufrufe und keine individuellen Rechts- oder Gesundheitsempfehlungen vorgesehen. Externe Medien sind nur Ergänzungen; die Lernaufgaben sind ohne Anmeldung und ohne das Hochladen eigener Daten lösbar.

Lernziele

Nach dem Kurs kannst Du:

Testfälle mit Eingabe, Soll, Ist und Ergebnis dokumentieren.
einen Fehlerfall von einer bloßen Vermutung unterscheiden.
eine gezielte Korrektur so beschreiben, dass eine andere Person sie nachvollziehen kann.
nach einer Korrektur den Fehlerfall erneut prüfen und zusätzlich passende zuvor bestandene Fälle wiederholen.
zwischen Beobachtung, Regelanwendung und Bewertung unterscheiden.
ein vorsichtiges Fazit formulieren, das nur für die tatsächlich geprüften Fälle gilt.
in der Vertiefung Bestätigungstest und Regressionstest auseinanderhalten.

Grundlagen

Vier Felder eines einfachen Testfalls

Ein kleiner Testfall lässt sich für den Einstieg mit vier Feldern dokumentieren:

Feld	Bedeutung	Leitfrage
Eingabe	Der Wert oder die Situation, mit der Du das Programm prüfst.	Was geben wir vor?
Soll	Das Ergebnis, das laut Regel erwartet wird.	Was müsste richtig herauskommen?
Ist	Das tatsächlich beobachtete Ergebnis.	Was kam wirklich heraus?
Ergebnis	Vergleich von Soll und Ist.	Bestanden oder nicht bestanden?

Wenn Soll = Ist gilt, ist dieser Testfall bestanden. Wenn Soll ≠ Ist gilt, zeigt der Testfall eine Abweichung. Die Abweichung muss dokumentiert und untersucht werden.

Beobachtung, Regelanwendung und Bewertung trennen

Eine saubere Dokumentation trennt drei Denk-Schritte:

Schritt	Was Du festhältst	Beispiel
Beobachtung	Nur das, was beim Test tatsächlich passiert ist.	„Bei Eingabe 6 gibt das Programm frei aus.“
Regelanwendung	Vergleich mit der vorher festgelegten Regel.	„Die Regel verlangt für 6 die Ausgabe Kind.“
Bewertung	Schluss nur aus den vorhandenen Prüfergebnissen.	„Dieser Testfall ist nicht bestanden.“

Die Bewertung darf nicht weiter reichen als die Beobachtung. Aus vier bestandenen Fällen darfst Du also nicht schließen, dass alle denkbaren Eingaben korrekt funktionieren.

Was gehört in eine gute Korrekturdokumentation?

Eine einfache schulische Dokumentation kann enthalten:

Baustein	Inhalt
Kennung	Eine kurze ID wie F-01 oder T-03.
Datum	Wann wurde beobachtet oder erneut getestet?
Ausgangsregel	Welche fachliche Regel soll das Programm umsetzen?
Fehlerfall	Eingabe, Soll, Ist und Ergebnis.
Reproduktionsschritt	Wie lässt sich die Abweichung erneut auslösen?
gezielte Korrektur	Welche kleine Änderung wurde vorgenommen?
erneute Prüfung	Fehlerfall plus passende vorher bestandene Fälle.
Fazit	Nur Aussage über die tatsächlich geprüften Fälle.

Eine solche Struktur ähnelt professionellen Fehlerberichten: Offizielle GitHub-Dokumentation nennt für Bug Reports unter anderem reproduzierbare Schritte sowie erwartetes und tatsächliches Ergebnis; der ISTQB-Lehrplan nennt ebenfalls erwartete und tatsächliche Ergebnisse sowie Schritte zur Reproduktion als typische Bestandteile eines Defect Reports.

Durchgerechnetes Beispiel: Altersklasse

Wir prüfen ein sehr kleines Programm für eine fiktive Eintrittsregel. Die Regel lautet:

Für ein Alter unter 6 lautet die Ausgabe frei.
Für ein Alter von 6 bis einschließlich 14 lautet die Ausgabe Kind.
Für ein Alter ab 15 lautet die Ausgabe Erwachsen.

Der fehlerhafte Pseudocode lautet:

WENN alter <= 6
    AUSGABE "frei"
SONST WENN alter <= 14
    AUSGABE "Kind"
SONST
    AUSGABE "Erwachsen"

Testfallmatrix vor der Korrektur

Testfall	Eingabe	Soll	Ist	Ergebnis
T1	5	frei	frei	bestanden
T2	6	Kind	frei	nicht bestanden
T3	14	Kind	Kind	bestanden
T4	15	Erwachsen	Erwachsen	bestanden

Beobachtung: Bei Eingabe 6 erscheint „frei“.

Regelanwendung: Laut Vorgabe gehört 6 bereits zur Gruppe „Kind“.

Bewertung: Testfall T2 ist nicht bestanden. Die drei anderen dokumentierten Testfälle sind in diesem Durchlauf bestanden.

Gezielte Korrektur

Die fehlerhafte Grenze steckt in der ersten Bedingung. Statt „alter <= 6“ muss dort „alter < 6“ stehen. Nur diese Stelle wird gezielt geändert:

WENN alter < 6
    AUSGABE "frei"
SONST WENN alter <= 14
    AUSGABE "Kind"
SONST
    AUSGABE "Erwachsen"

Diese Korrektur ist begründet, weil die Regel ausdrücklich „unter 6“ verlangt. Das Zeichen „<“ passt genau zu dieser Aussage.

Papierdurchlauf nach der Korrektur

Jetzt führen wir den ursprünglichen Fehlerfall und passende zuvor bestandene Fälle erneut aus. Auf Papier gehst Du bei jeder Eingabe die Bedingungen der Reihe nach durch.

Testfall	Eingabe	Gedanklicher Durchlauf nach der Korrektur	Soll	Ist	Ergebnis
T2	6	6 < 6 ist falsch; 6 <= 14 ist wahr; Ausgabe Kind	Kind	Kind	bestanden
T1	5	5 < 6 ist wahr; Ausgabe frei	frei	frei	bestanden
T3	14	14 < 6 ist falsch; 14 <= 14 ist wahr; Ausgabe Kind	Kind	Kind	bestanden
T4	15	15 < 6 ist falsch; 15 <= 14 ist falsch; Ausgabe Erwachsen	Erwachsen	Erwachsen	bestanden

Beobachtung: In diesem Papierdurchlauf stimmen bei T1, T2, T3 und T4 Soll und Ist überein.

Regelanwendung: Der frühere Fehlerfall T2 wurde erneut geprüft. Zusätzlich wurden die vorher bestandenen Fälle T1, T3 und T4 wiederholt, damit sichtbar wird, ob die Änderung an der Grenze unerwünschte Nebenwirkungen in diesen bekannten Fällen erzeugt.

Bewertung: Die Korrektur hat sich in den vier geprüften Fällen bewährt. Mehr darf aus diesem Test nicht geschlossen werden. Nicht geprüft wurden zum Beispiel negative Eingaben, sehr große Zahlen, Texteingaben oder andere Bedingungen, die in der Aufgabenbeschreibung gar nicht definiert sind.

Vertiefung: Bestätigungstest und Regressionstest

VERTIEFUNG: In professioneller Testterminologie werden zwei Ziele unterschieden. Ein Bestätigungstest prüft gezielt, ob eine Korrektur den gemeldeten Fehler tatsächlich beseitigt hat. Ein Regressionstest prüft nach einer Änderung zusätzlich, ob in anderen, zuvor funktionierenden Bereichen neue Probleme entstanden oder sichtbar geworden sind.

Im Beispiel ist T2 der zentrale Bestätigungstest. T1, T3 und T4 dienen als kleine Regressionstestsammlung. In großen Softwareprojekten kann eine Regressionstestsammlung sehr viel umfangreicher sein.

Der ISTQB Foundation Level Syllabus v4.0.1 trennt Testen und Debugging: Beim Debugging werden Ursachen gesucht und beseitigt; danach prüft ein Bestätigungstest die Korrektur, und Regressionstests können kontrollieren, ob die Änderung andere Teile beeinträchtigt.

Mediennachweis: „Debuggerfirefox95.png“, Urheber: Cedric Demian R. Moreno, 21.12.2021, Wikimedia Commons, Lizenz CC BY-SA 4.0. Das Bild veranschaulicht einen echten Debugger; der Kurs verlangt jedoch keine Nutzung eines solchen Werkzeugs. Quelle und Lizenz: https://commons.wikimedia.org/wiki/File:Debuggerfirefox95.png. Alternativtext: Screenshot der Firefox-Entwicklerwerkzeuge mit geöffnetem Debugger zur schrittweisen Untersuchung eines Programms.

Vertiefungsmedium: Schrittweises Debugging

Das folgende Video gehört zu CS50 OpenCourseWare der Harvard University und zeigt schrittweises Debugging. Der Kurs ist auf der offiziellen CS50-Lizenzseite unter CC BY-NC-SA 4.0 veröffentlicht. Die Einbettung ist eine ergänzende Vertiefung; alle wesentlichen Lerninhalte dieses aiMOOCs stehen auch als eigener Text zur Verfügung.

Quelle: CS50x 2024, „Debugging (“Step through”)“, Harvard University. Offizielle Kursseite: https://cs50.harvard.edu/x/2024/shorts/debugging_step_through/; Lizenzseite: https://cs50.harvard.edu/x/2024/license/. Alternativtext: Lehrvideo, in dem ein Programm mit einem Debugger schrittweise ausgeführt wird, um Programmzustände zu beobachten und einen Fehler einzugrenzen.

Vertiefung: Warum Testen keine Universalgarantie liefert

Der ISTQB Foundation Level Syllabus nennt zwei wichtige Testprinzipien: Testen kann vorhandene Fehler sichtbar machen, aber nicht beweisen, dass überhaupt keine Fehler mehr existieren. Außerdem ist vollständiges Testen aller Möglichkeiten außer in sehr einfachen Fällen nicht praktikabel. Für unsere Dokumentation folgt daraus: Ein Fazit muss genau benennen, welche Fälle und Bedingungen geprüft wurden.

Ein gutes Fazit lautet zum Beispiel:

„Nach der Korrektur stimmen bei den geprüften Eingaben 5, 6, 14 und 15 die beobachteten Ergebnisse mit den Soll-Ergebnissen überein.“

Ein ungeeignetes Fazit wäre:

„Das Programm ist jetzt vollständig fehlerfrei.“

Korrekturen dokumentieren: Vorlage

Diese Vorlage kannst Du für eigene Übungen übernehmen:

Feld	Eintrag
Fehler-ID
Datum
Regel oder Anforderung
Eingabe des Fehlerfalls
Soll
Ist
Beobachtung
vermutete Fehlerstelle
gezielte Korrektur
erneut geprüfter Fehlerfall
erneut geprüfte zuvor bestandene Fälle
Bewertung mit klarer Aussagegrenze

Übungsaufgaben mit gestuften Hinweisen und Lösungen

Die folgenden vier Aufgaben sind eigenständig. Jede hat genau eine richtige Auswahl. Arbeite zuerst ohne Hinweise, dann mit Hinweis 1, dann bei Bedarf mit Hinweis 2 und 3. Die Lösungen erklären den Denkweg. Diese Aufgaben dienen der Selbstkontrolle und erzeugen keine automatische Note.

Aufgabe 1: Testfall erkennen

Für eine Regel gilt: „Bei Zahl kleiner als 10 soll klein erscheinen, sonst gross.“ Ein Programm gibt bei Eingabe 10 „klein“ aus. Welche Dokumentation ist korrekt?

A: Eingabe 10; Soll gross; Ist klein; Ergebnis nicht bestanden B: Eingabe 10; Soll klein; Ist klein; Ergebnis bestanden C: Eingabe 9; Soll gross; Ist klein; Ergebnis nicht bestanden D: Eingabe 10; Soll gross; Ist gross; Ergebnis bestanden

Hinweis 1: Prüfe zuerst die Bedeutung von „kleiner als 10“.

Hinweis 2: 10 ist nicht kleiner als 10.

Hinweis 3: Soll und Ist sind hier verschieden.

Lösung: A ist richtig. Nach der Regel gehört 10 zum Sonst-Fall, also ist „gross“ das Soll. Beobachtet wurde „klein“, daher ist der Test nicht bestanden.

Aufgabe 2: Was wird nach der Korrektur wiederholt?

Ein Fehler trat bei Eingabe 6 auf. Die Fälle 5, 14 und 15 waren vorher bestanden. Was ist für einen kleinen Papier-Regressionscheck am sinnvollsten?

A: Den Fehlerfall 6 und passende zuvor bestandene Fälle 5, 14 und 15 erneut prüfen B: Nur Fall 6 erneut prüfen und danach „alles fehlerfrei“ schreiben C: Nur Fall 5 erneut prüfen, weil er vorher bestanden war D: Keine Fälle wiederholen, weil der Code bereits geändert wurde

Hinweis 1: Eine Korrektur kann Nebenwirkungen haben.

Hinweis 2: Der alte Fehlerfall zeigt, ob die Korrektur wirkt.

Hinweis 3: Bereits bestandene Fälle zeigen, ob Bekanntes weiterhin funktioniert.

Lösung: A ist richtig. Der Fehlerfall dient zur Bestätigung der Korrektur; die zuvor bestandenen Fälle prüfen auf bekannte mögliche Regressionen.

Aufgabe 3: Beobachtung oder Bewertung?

Welche Aussage ist eine reine Beobachtung?

A: „Bei Eingabe 100 zeigt das Programm 14 Tage an.“ B: „Das Programm ist vollständig korrekt.“ C: „Die Änderung war auf jeden Fall die beste Lösung.“ D: „Alle möglichen Eingaben funktionieren.“

Hinweis 1: Eine Beobachtung beschreibt nur, was tatsächlich gesehen wurde.

Hinweis 2: Wörter wie „vollständig“ und „alle“ gehen über einen einzelnen Messwert hinaus.

Hinweis 3: Suche den Satz ohne allgemeines Urteil.

Lösung: A ist richtig. Der Satz beschreibt nur ein beobachtetes Ergebnis für eine konkrete Eingabe.

Aufgabe 4: Zulässiges Fazit

Nach einer Korrektur wurden die Eingaben 2, 3, 4 und 10 getestet. Alle vier Fälle stimmen mit dem Soll überein. Welches Fazit ist sachlich korrekt?

A: „Bei den geprüften Eingaben 2, 3, 4 und 10 stimmen Soll und Ist überein.“ B: „Das Programm enthält garantiert keinen Fehler mehr.“ C: „Jede mögliche Eingabe wurde erfolgreich geprüft.“ D: „Weitere Tests können nichts Neues mehr zeigen.“

Hinweis 1: Das Fazit darf nicht größer sein als die Testmenge.

Hinweis 2: Vier geprüfte Eingaben sind nicht automatisch alle Eingaben.

Hinweis 3: Suche die Aussage, die genau die vier Fälle nennt.

Lösung: A ist richtig. Diese Formulierung trennt Beobachtung und Bewertung und enthält keine Universalgarantie.

Transferwerkstatt

In der Transferwerkstatt arbeitest Du mit einem neuen kleinen Programm oder mit Pseudocode aus dem Unterricht. Du sollst nicht nur einen Fehler finden, sondern die gesamte Kette nachvollziehbar dokumentieren.

Modell: O–R–B

Buchstabe	Bedeutung	Frage
O	Beobachtung	Was ist bei welchem Testfall tatsächlich passiert?
R	Regelanwendung	Welche vorher festgelegte Regel entscheidet über das Soll?
B	Bewertung	Was darf ich aus den geprüften Fällen schließen – und was nicht?

Arbeitsauftrag: Erstelle für ein kleines Entscheidungsprogramm mindestens vier Testfälle, darunter einen Grenzfall. Dokumentiere eine Abweichung, formuliere eine gezielte Korrektur, führe den Fehlerfall und mindestens zwei zuvor bestandene Fälle erneut auf Papier aus und schreibe ein begrenztes Fazit.

Selbstprüfkriterien:

Ich habe für jeden Testfall Eingabe, Soll, Ist und Ergebnis festgehalten.
Ich habe Beobachtung, Regelanwendung und Bewertung sprachlich getrennt.
Meine Korrektur verändert gezielt die begründete Fehlerstelle und nicht wahllos mehrere Dinge zugleich.
Nach der Korrektur habe ich den früheren Fehlerfall und passende zuvor bestandene Fälle erneut geprüft.
Mein Fazit nennt nur die geprüften Fälle und behauptet keine vollständige Fehlerfreiheit.

Quellen, Herkunft, Datum und Aussagegrenzen

Prüfdatum der folgenden Onlinequellen: 04.10.2026. Die fachlichen Aussagen wurden für Klasse 5/6 vereinfacht, ohne die Kernaussagen der Quellen zu verändern.

Quelle	Herkunft und Datum	Verwendete Aussage	Aussagegrenze
ISTQB Certified Tester Foundation Level Syllabus v4.0.1	International Software Testing Qualifications Board; Version 4.0.1; 15.09.2024	Testen und Debugging sind getrennte Tätigkeiten; nach einer Korrektur kann Bestätigungstest und anschließend Regressionstest erfolgen. Testen zeigt Fehler, beweist aber nicht ihre vollständige Abwesenheit; vollständiges Testen ist meist nicht möglich.	Professioneller Lehrplan für Softwaretests; die schulischen Beispiele hier sind bewusst stark vereinfacht.
ISTQB Glossary	Offizielle ISTQB-Terminologie; online geprüft am 04.10.2026	Regressionstests sind änderungsbezogene Tests, mit denen geprüft wird, ob Änderungen Fehler in unveränderten Bereichen eingeführt oder sichtbar gemacht haben.	Begriffe stammen aus professioneller Qualitätssicherung; Umfang und Auswahl konkreter Regressionstests hängen vom Kontext ab.
GitHub Docs: Quickstart for GitHub Issues	GitHub-Dokumentation; online geprüft am 04.10.2026	Ein Bug Report sollte reproduzierbare Schritte sowie erwartetes und tatsächliches Ergebnis enthalten.	Produktdokumentation für GitHub Issues; als Beispiel für nachvollziehbare Fehlerdokumentation genutzt, nicht als allgemeiner Standard für jedes Projekt.
Python-Dokumentation: unittest	Python Software Foundation; Dokumentation online geprüft am 04.10.2026	Ein Testfall prüft eine bestimmte Reaktion auf bestimmte Eingaben; Tests lassen sich zu Sammlungen zusammenfassen und automatisieren.	Bezieht sich auf Python und das Framework unittest; der Grundgedanke des Testfalls wird hier nur didaktisch übertragen.
Wikimedia Commons: SDLC - Software Development Life Cycle.jpg	Cliffydcw; 22.03.2012; CC BY-SA 3.0	Veranschaulichung, dass Testen und Weiterentwicklung Teile eines Software-Lebenszyklus sind.	Vereinfachte Grafik; kein verbindliches Prozessmodell für jedes Softwareprojekt.
Wikimedia Commons: Debuggerfirefox95.png	Cedric Demian R. Moreno; 21.12.2021; CC BY-SA 4.0	Beispielansicht eines realen Debuggers.	Screenshot einer bestimmten Firefox-Version; Bedienoberflächen ändern sich und sind nicht Lernvoraussetzung dieses Kurses.
CS50x 2024: Debugging Step through	Harvard University, CS50 OpenCourseWare, Kursjahr 2024	Vertiefung zum schrittweisen Debugging.	Fortgeschrittener als der Grundkurs; nur ergänzend. Die Kurslizenz ist laut offizieller Lizenzseite CC BY-NC-SA 4.0.

Interaktive Aufgaben

Quiz: Teste Dein Wissen

Wozu dient das Feld Soll in einem Testfall? (Es beschreibt das vorher erwartete richtige Ergebnis) (!Es beschreibt immer den Programmcode) (!Es enthält nur das Testdatum) (!Es ersetzt die Eingabe)

Wann ist ein einfacher Testfall bestanden? (Wenn Soll und Ist übereinstimmen) (!Wenn die Eingabe besonders groß ist) (!Wenn das Programm geändert wurde) (!Wenn kein Soll festgelegt wurde)

Was sollte nach einer gezielten Korrektur zuerst erneut geprüft werden? (Der zuvor fehlgeschlagene Fehlerfall) (!Nur ein völlig neuer zufälliger Fall) (!Gar kein Fall) (!Nur die Programmlänge)

Warum werden zusätzlich zuvor bestandene Fälle wiederholt? (Um bekannte Funktionen auf mögliche Regressionen zu prüfen) (!Um eine automatische Note zu berechnen) (!Um jede denkbare Eingabe vollständig abzudecken) (!Um die ursprüngliche Regel zu löschen)

Welche Aussage ist eine Beobachtung? (Bei Eingabe 6 erscheint die Ausgabe frei) (!Das Programm ist jetzt perfekt) (!Alle Eingaben sind korrekt) (!Der Test beweist vollständige Fehlerfreiheit)

Was ist eine gezielte Korrektur im Beispiel mit der Altersgrenze? (Die Bedingung alter kleiner gleich 6 wird zu alter kleiner 6) (!Alle Bedingungen werden gelöscht) (!Jede Zahl wird zu 0 geändert) (!Die Sollwerte werden an das fehlerhafte Programm angepasst)

Was beschreibt ein Bestätigungstest? (Er prüft gezielt ob die Korrektur den gemeldeten Fehler beseitigt) (!Er bewertet automatisch die Schulnote) (!Er ersetzt jede Dokumentation) (!Er prüft nur das Design einer Webseite)

Was beschreibt ein Regressionstest in diesem Kurs? (Er wiederholt passende bekannte Tests nach einer Änderung) (!Er beweist dass niemals ein Fehler auftreten kann) (!Er ist nur ein anderes Wort für Programmieren) (!Er bedeutet dass alle alten Tests gelöscht werden)

Welches Fazit ist nach vier bestandenen Testfällen zulässig? (Die vier geprüften Fälle stimmen mit den Sollwerten überein) (!Das Programm ist garantiert überall fehlerfrei) (!Jede denkbare Eingabe wurde geprüft) (!Weitere Tests sind grundsätzlich unnötig)

Welche Reihenfolge trennt das Denken sauber? (Beobachtung Regelanwendung Bewertung) (!Bewertung Vermutung Lob) (!Note Code Zufall) (!Korrektur Garantie Abschluss)

Memory

Testfall	konkrete Prüfung mit festgelegter Eingabe und Erwartung
Sollwert	vorher erwartetes Ergebnis
Istwert	tatsächlich beobachtetes Ergebnis
Korrektur	gezielte Änderung an einer begründeten Fehlerstelle
Bestätigungstest	erneute Prüfung des früheren Fehlerfalls
Regressionstest	Wiederholung passender bekannter Tests nach einer Änderung

Drag and Drop

Ordne die richtigen Begriffe zu.	Thema
Beobachtung	Tatsächlich sichtbares Ergebnis eines Testlaufs
Regelanwendung	Vergleich des Ergebnisses mit der festgelegten Vorgabe
Bewertung	begrenzte Schlussfolgerung aus den geprüften Fällen
Bestätigungstest	erneute Ausführung des ursprünglichen Fehlerfalls
Regressionstest	erneute Ausführung passender zuvor bestandener Fälle

Kreuzworträtsel

Regression	Wie heißt eine unerwünschte Verschlechterung nach einer Änderung?
Testfall	Wie heißt eine konkrete Prüfung mit Eingabe und Erwartung?
Sollwert	Wie heißt das erwartete Ergebnis?
Istwert	Wie heißt das tatsächlich beobachtete Ergebnis?
Korrektur	Wie heißt eine gezielte Änderung zur Behebung eines Fehlers?
Debugger	Wie heißt ein Werkzeug zum schrittweisen Untersuchen eines Programms?

LearningApps

Lückentext

Ein Testfall besitzt eine festgelegte

und ein erwartetes Ergebnis. Das erwartete Ergebnis nennen wir

. Das tatsächlich beobachtete Ergebnis nennen wir

. Stimmen beide überein, ist der geprüfte Testfall

. Nach einer gezielten Korrektur wird der frühere Fehlerfall als

erneut ausgeführt. Zusätzlich können passende zuvor bestandene Fälle als

wiederholt werden. Eine reine

beschreibt nur, was tatsächlich passiert ist. Das abschließende

darf nur so weit reichen wie die tatsächlich geprüften Fälle.

Offene Aufgaben

Leicht

Testfallmatrix: Erstelle für eine einfache Regel mit zwei Ausgaben vier Testfälle und trage Eingabe, Soll, Ist und Ergebnis ein.
Beobachtung: Formuliere zu einem absichtlich fehlerhaften Papierbeispiel drei reine Beobachtungssätze ohne Bewertung.
Soll-Ist-Vergleich: Erfinde zwei bestandene und einen nicht bestandenen Testfall und tausche Deine Tabelle mit einer anderen Person zur Kontrolle.
Fehlerbericht: Schreibe zu einem kleinen Grenzfehler einen kurzen Fehlerbericht mit Titel, Eingabe, Soll, Ist und Reproduktionsschritt.

Standard

Korrektur: Entwickle zu einem gegebenen Pseudocode eine gezielte Ein-Zeilen-Korrektur und begründe genau, warum sie zur Regel passt.
Regressionstest: Wähle nach einer Korrektur drei zuvor bestandene Fälle aus, die Du erneut prüfen würdest, und begründe Deine Auswahl.
Grenzwertanalyse: Erstelle für eine Regel mit einer Grenze passende Testfälle direkt unter, auf und über der Grenze.
Testprotokoll: Dokumentiere zwei Testdurchläufe vor und nach einer Korrektur so, dass eine andere Person den Ablauf ohne Rückfrage nachvollziehen kann.

Schwer

Teststrategie: Entwirf für ein Programm mit zwei aufeinanderfolgenden Bedingungen eine kleine Regressionstestsammlung und begründe, welche Risiken sie abdeckt und welche nicht.
Fehleranalyse: Vergleiche zwei mögliche Korrekturen desselben Fehlers und entscheide anhand der Regel, welche gezielter ist.
Qualitätssicherung: Entwickle ein Formular, das Beobachtung, Regelanwendung und Bewertung konsequent trennt, und erprobe es an zwei Beispielen.
Transfer: Nimm ein neues Unterrichtsbeispiel, finde einen überprüfbaren Grenzfall, dokumentiere eine Korrektur, führe Bestätigungs- und Regressionstests auf Papier durch und formuliere ein begrenztes Fazit.

Lernkontrolle

Fehlerfall analysieren: Du erhältst eine Testmatrix mit einem fehlgeschlagenen Grenzfall. Erkläre, welche konkrete Regel verletzt wurde und welche Information noch fehlt, bevor Du eine Korrektur bewerten kannst.
Korrektur begründen: Zwei verschiedene Codeänderungen beseitigen denselben sichtbaren Fehler. Entscheide anhand der Spezifikation, welche Änderung gezielter ist, und begründe Deine Entscheidung.
Regression auswählen: Wähle aus acht vorhandenen Testfällen vier aus, die nach einer Grenzänderung besonders sinnvoll erneut geprüft werden sollten. Begründe jede Auswahl.
Aussagegrenze formulieren: Schreibe zu einer gegebenen Testtabelle ein Fazit, das genau die geprüften Fälle nennt und keine Universalgarantie enthält.
Dokumentation prüfen: Finde in einem fehlerhaften Testbericht mindestens drei Stellen, an denen Beobachtung und Bewertung vermischt wurden, und formuliere sie sauber um.
Transferleistung: Übertrage das Schema Eingabe–Soll–Ist–Ergebnis auf einen neuen Pseudocode mit einer anderen Regel und zeige, wie Du nach der Korrektur den alten Fehlerfall und passende bestandene Fälle erneut prüfst.

Lernnachweis

Für einen Lernnachweis zu diesem Thema ist wichtig:

Du kannst eine Testfallmatrix mit Eingabe, Soll, Ist und Ergebnis korrekt führen.
Du kannst einen beobachteten Fehler reproduzierbar beschreiben.
Du kannst eine gezielte Korrektur aus einer festgelegten Regel begründen.
Du kannst den Fehlerfall nach der Korrektur erneut durchführen.
Du kannst passende zuvor bestandene Fälle für einen kleinen Regressionstest auswählen und begründen.
Du kannst Beobachtung, Regelanwendung und Bewertung sprachlich trennen.
Du kannst ein Fazit mit klarer Aussagegrenze formulieren.
Du kannst die Methode auf ein neues Material übertragen.

Hinweis: Diese Kriterien beschreiben nachweisbare Lernleistungen. Aus ihnen wird in diesem aiMOOC keine automatische Note erzeugt.

Abschlussanwendung auf neues Material

Zum Abschluss wendest Du die Methode auf ein neues Beispiel an. Eine fiktive Schulbibliothek legt die Leihdauer nach Seitenzahl fest:

Bücher mit höchstens 100 Seiten dürfen 7 Tage ausgeliehen werden.
Bücher mit 101 bis 300 Seiten dürfen 14 Tage ausgeliehen werden.
Bücher mit mehr als 300 Seiten dürfen 21 Tage ausgeliehen werden.

Gegeben ist dieser fehlerhafte Pseudocode:

WENN seiten < 100
    AUSGABE 7
SONST WENN seiten <= 300
    AUSGABE 14
SONST
    AUSGABE 21

Dein überprüfbarer Auftrag: Fülle die Matrix für 99, 100, 300 und 301 Seiten aus. Markiere den Fehlerfall. Begründe eine gezielte Korrektur. Führe danach den Fehlerfall und die drei zuvor bestandenen Fälle erneut auf Papier aus. Formuliere zum Schluss einen Satz, der nur für diese vier geprüften Fälle gilt.

Eingabe Seiten	Soll Tage	Ist vor Korrektur	Ergebnis vor Korrektur	Ist nach Korrektur	Ergebnis nach Korrektur
99
100
300
301

Kontrollschlüssel: Vor der Korrektur ergeben sich 99 → 7 Tage, 100 → 14 Tage, 300 → 14 Tage und 301 → 21 Tage. Nur der Fall 100 verletzt die Regel, weil „höchstens 100“ auch 100 einschließt. Die gezielte Korrektur lautet deshalb „seiten <= 100“. Danach ergeben die vier Papierdurchläufe 99 → 7, 100 → 7, 300 → 14 und 301 → 21 Tage. Ein korrekt begrenztes Fazit wäre: „Bei den geprüften Eingaben 99, 100, 300 und 301 stimmen Soll und Ist nach der Korrektur überein.“

OERs zum Thema

Verknüpfte Lernbereiche

Informatik - Korrekturen und Regressionen dokumentieren

aiMOOC-Projekte

Inhalte werden geladen ...

Mediathek wird aus dem Wiki geladen ...

Frag mich zum aktuellen Lerninhalt oder wähle eine kurze Hilfe.

Textmodus bereit

Sprache