aiMOOC

KI-generierten Programmcode professionell überprüfen

QR-Code

Einleitung

Ein KI-System kann in Sekunden plausibel aussehenden Programmcode erzeugen. Ob dieser Code die Anforderungen erfüllt, fremde Daten schützt und fachlich richtige Aussagen liefert, entscheidet sich jedoch erst durch nachvollziehbare Prüfung. Du lernst, einen KI-Vorschlag nicht als fertiges Ergebnis, sondern als überprüfbare Hypothese zu behandeln. Das Lernprodukt ist ein dokumentiertes Review eines absichtlich fehlerhaften Messdaten-Dashboards: Du findest einen Berechtigungsfehler, eine fehlende Eingabegrenze und eine falsche Fachannahme, ergänzt Tests und begründest eine menschliche Freigabeentscheidung.

Zielgruppe: Auszubildende im zweiten bis dritten Ausbildungsjahr. Voraussetzungen: A1 oder vergleichbare Grundlagen in Python, Dateien, Git und einfachen Tests. Aktiviere sie kurz anhand der vorhandenen Grundlage (Inhalt dieser verlinkten Seite beim Recherchezugriff nicht abrufbar). Du brauchst nur einen Texteditor und optional eine lokale Python-Installation mit Standardbibliothek; ein kostenpflichtiges KI-Konto ist nicht erforderlich.

Lernziele: Du erklärst den Reviewablauf, unterscheidest Funktion, Sicherheit und fachliche Gültigkeit, formulierst mindestens drei reproduzierbare Gegenbeispiele, ergänzt Negativtests und dokumentierst eine begründete Entscheidung. Du ordnest Code-Analyse, Tests und menschliches Fachreview als unterschiedliche Kontrollen ein.

Sicherheitsrahmen: Ausschließlich synthetische Messwerte und Simulation ohne reale Geräte, Netzwerkzugriffe oder Sicherheitsfreigaben. Alle beispielhaften Werte und Schwellen sind didaktisch erfunden und dürfen nicht auf Anlagen übertragen werden. Dies ist ein unabhängiges Bildungsangebot und keine offizielle Liebherr- oder IHK-Zertifizierung. Externe Medien sind optional; alle Lernschritte stehen als Text zur Verfügung.

Code-Review als fachliche Verantwortung

Was muss geprüft werden?

Ein Code-Review ist die systematische Betrachtung eines Änderungsvorschlags durch andere fachkundige Personen. KI-generierter Code kann syntaktisch korrekt und trotzdem falsch sein. Ein guter Review untersucht nicht nur Stil, sondern stellt fünf Fragen: Erfüllt die Änderung die Anforderung? Wer darf was lesen oder verändern? Welche Eingaben sind erlaubt? Welche Tests belegen das Verhalten? Stimmen die fachlichen Annahmen und Grenzen?

Eine Anforderung beschreibt das gewünschte Verhalten. Ein Akzeptanzkriterium nennt überprüfbare Bedingungen. Beispiel: „Nur eine autorisierte prüfende Person darf synthetische Einzelmesswerte sehen.“ Passende Gegenprobe: Eine Gastrolle muss abgewiesen werden, auch wenn sie einen direkten Funktionsaufruf versucht. Eine grüne Testanzeige ist kein fachlicher Freibrief: Tests können wichtige Fälle übersehen.

Automatisierte und menschliche Prüfung

Linting sucht Stil- und häufige Programmierfehler, statische Analyse untersucht Code ohne Ausführung, Unit-Tests prüfen isolierte Funktionen, Integrationstests das Zusammenspiel. Threat Modeling fragt nach Angriffswegen und Schutzgütern; ein fachliches Review vergleicht den Code mit realen Anforderungen und plausiblen Datenannahmen. Die Werkzeuge ergänzen einander, ersetzen aber nicht die Person, die die Freigabe verantwortet.

Medienimpuls (englische Beschriftungen): Der Git-Workflow verdeutlicht die Trennung zwischen Änderung, Rückmeldung und Zusammenführung. Bild: Antoine „hashar“ Musso nach Chad Horohoe, CC BY-SA 3.0; Dateiseite. Ohne Bild: Eine Änderung wird separat erstellt, unabhängig geprüft, verbessert und erst dann zusammengeführt.

Kleine Review-Checkliste

Kontext: Ticket, Ziele, Datenarten, betroffene Dateien und Änderungen lesen.
Risiko: Rollen, Datenabfluss, ungeprüfte Eingaben und fachliche Fehlentscheidungen priorisieren.
Beweis: Pro Verdacht eine Fundstelle, ein Gegenbeispiel und einen Test angeben.
Entscheidung: Befunde in „blockierend“, „verbessern“ oder „begründet akzeptiert“ einordnen.
Nachprüfung: Korrektur, Tests und eine zweite Sicht dokumentieren. Freigabe erfolgt durch eine berechtigte Person.

Merke: Ein höflicher Review-Kommentar beschreibt Beobachtung, Risiko und überprüfbare Änderung; er bewertet nicht die Person, die den Code geschrieben hat.

Zugriffskontrolle und Eingaben als Sicherheitsgrenzen

Authentifizierung ist nicht Autorisierung

Authentifizierung klärt eine Identität, Autorisierung prüft die konkrete Berechtigung für jede Aktion und jedes Objekt. Eine sichtbare ausgegraute Schaltfläche ist kein Zugriffsschutz. Die Prüfung muss dort stattfinden, wo Daten ausgeliefert werden, und standardmäßig ablehnen. Im Unterrichtsmodell darf ausschließlich die Rolle reviewer synthetische Einzelwerte sehen. guest und viewer erhalten keine Rohdaten. Die Rollen sind fiktiv, keine echte Benutzerverwaltung.

Die OWASP Top 10:2025 ordnen unzureichende Zugriffskontrolle als A01 ein. Für automatisierte Coding-Agenten gilt zusätzlich: Werkzeuge und Zugangsdaten so eng wie nötig freigeben, gefährliche Aktionen nicht allein aufgrund generierter Ausgaben ausführen und keine fremden Anweisungen aus ungeprüften Dateien übernehmen. Die MCP-Sicherheitsleitlinien (Spezifikation 2026-07-28) behandeln unter anderem eingeschränkte Berechtigungen, Tokenweitergabe und weitere Autorisierungsrisiken. Diese Quelle betrifft MCP-Anbindungen; sie ist keine unmittelbare Sicherheitsfreigabe für die Übungs-App.

Input-Validierung und Ressourcenlimits

Input-Validierung prüft Format, Typ, Wertebereich und Menge der Daten an einer vertrauenswürdigen Grenze. Eine vernünftige Obergrenze verhindert unter anderem übermäßigen Speicher- und Zeitverbrauch. Für dieses Unterrichtsbeispiel gilt die eigens vereinbarte Regel: pro Import mindestens ein und höchstens 500 Datensätze; Temperaturfeld temp numerisch und endlich; synthetischer Bereich minus 40 bis plus 150 Grad Celsius. Andere fachliche Kontexte benötigen andere, eigens begründete Grenzen.

Fehlerfälle gehören in Tests: leere Liste, 501 Einträge, fehlendes Feld, Text statt Zahl, NaN und unendlich große Zahlen. Python kann float("nan") verarbeiten: Ein reiner Typwechsel reicht deshalb nicht. Fail closed bedeutet, bei unsicherer Eingabe oder fehlender Berechtigung keine vertraulichen Rohdaten herauszugeben.

Medienimpuls: Black-Box-Tests prüfen beobachtbares Verhalten; White-Box-Tests nutzen zusätzlich Kenntnisse über die Implementierung. Bild: J-at-ywalters-dot-net, CC BY-SA 4.0; Dateiseite. Textalternative: Beide Sichtweisen sind nötig, damit ein aufgeräumter Quelltext nicht ungeprüft als korrekt gilt.

Rechte für Coding-Agenten

Wenn ein Agent Werkzeuge bedienen kann, steigt der Prüfumfang: Lese- und Schreibrechte trennen, sensible Pfade sperren, keine geheimen Schlüssel in Prompts kopieren, Änderungen als Diff prüfen und Ausführung nur in einer isolierten Testumgebung erlauben. Least Privilege heißt geringstmögliche Berechtigungen. Prompt Injection bezeichnet den Versuch, über ungeprüfte Inhalte das Verhalten eines Assistenzsystems umzulenken. Gegenmittel sind eine bewusste Vertrauensgrenze, explizite Werkzeugfreigaben und unabhängige Kontrollen. Für diesen Kurs werden keine externen Agenten oder echten Berechtigungen gebraucht.

Geführter Modellfall: das fehlerhafte Dashboard

Ausgangsauftrag und bewusst mangelhafter Vorschlag

Die fiktive Messdaten-App liest eine lokal bereitgestellte Liste synthetischer Werte. Der Generator hat einen zunächst plausibel wirkenden Dashboard-Auszug geliefert. Im Modellfall sollen nur autorisierte Reviewer Einzelwerte sehen; höchstens 500 Messwerte dürfen importiert werden; Aussagen zur Temperatur dürfen nur bei bekannter Einheit und nachvollziehbarer Auswertungsregel erfolgen. Betrachte den folgenden Code ausschließlich als zu untersuchenden Unterrichtsfall, nicht als Vorlage für den Betrieb:

def dashboard(rows, role, unit):
    visible = rows
    if role == "reviewer":
        visible = rows
    values = [float(row["temp"]) for row in visible]
    mean = sum(values) / len(values)
    return {
        "raw": visible,
        "mean_c": mean,
        "status": "normal" if mean < 80 else "alarm"
    }

Beobachtung A – Berechtigungsfehler: Beide Zweige verwenden dieselbe Liste. Auch guest erhält das Feld raw. Nicht die Darstellung, sondern die Datenfreigabe ist falsch. Testidee: dashboard([{"temp":20}], "guest", "C") darf nicht einfach Rohdaten zurückliefern.

Beobachtung B – Eingabegrenze: Die Funktion zählt Datensätze nicht und prüft weder leere Listen noch endliche Werte. Bei leerem Import entsteht ein Fehler durch Division durch null; mehr als 500 Einträge werden akzeptiert. Testidee: Erzeuge rein lokal 501 identische synthetische Datensätze und erwarte eine eindeutige Abweisung.

Beobachtung C – Fachannahme: mean_c behauptet Grad Celsius, obwohl unit ignoriert wird. Ein Mittelwert verdeckt Ausreißer. Bei 19 Werten von 20 °C und einem Wert von 85 °C ist der Durchschnitt 23,25 °C; das Dashboard zeigt normal. Daraus folgt weder eine sichere Anlage noch eine zulässige Alarmentscheidung. Dieser Einwand lässt sich nicht durch einen Formatierer entdecken: Der Fachbereich muss die Aussage korrigieren.

Schrittweise Verbesserung mit dokumentierten Grenzen

Ein möglicher Übungsentwurf ist eine reine Auswertungsfunktion ohne Eingriffsmöglichkeit. Der Code prüft zuerst die Rolle, dann Einheit, Anzahl und Zahlen. Die Regel ab 80 °C führt nur zum Marker needs_human_check, nicht zu einer Maschinenaktion. Ein realer Prozess braucht eigene fachlich freigegebene Kriterien.

import math

def review_dashboard(rows, role, unit):
    if role != "reviewer":
        raise PermissionError("keine Leseberechtigung")
    if unit != "C":
        raise ValueError("Einheit unklar")
    if not 1 <= len(rows) <= 500:
        raise ValueError("Datensatzanzahl unzulässig")
    values = []
    for row in rows:
        if "temp" not in row:
            raise ValueError("Messfeld fehlt")
        try:
            value = float(row["temp"])
        except (ValueError, TypeError):
            raise ValueError("Messwert keine Zahl")
        if not math.isfinite(value):
            raise ValueError("Messwert nicht endlich")
        if not -40 <= value <= 150:
            raise ValueError("Messwert außerhalb Übungsbereich")
        values.append(value)
    return {
        "mean_c": sum(values) / len(values),
        "peak_c": max(values),
        "needs_human_check": max(values) >= 80
    }

Wichtige Grenze: Diese Funktion ist ein Lernmodell. Sie verarbeitet Daten im Speicher, überprüft keine echte Identität und protokolliert keine realen Zugriffsereignisse. Die role wird im Test kontrolliert übergeben; eine produktive Anwendung müsste sie aus einer vertrauenswürdigen Authentifizierung und serverseitigen Autorisierung ableiten. Auch die Zahl 80 ist nur eine fiktive Unterrichtsschwelle. Es gibt keine Sicherheitsfreigabe.

Review-Tabelle zum Mitdenken

Prüfkriterium	Fehlernachweis im Vorschlag	Erwartete Verbesserung	Nachweis
Rollenprüfung	guest erhält Rohwerte	Nichtberechtigte vor Datenausgabe abweisen	Negativtest für guest
Eingabegrenze	501 Datensätze ohne Ablehnung	Länge vor Verarbeitung prüfen	Grenzwerttests für 500 und 501
Fachannahme	Einheit wird ignoriert; Ausreißer verschwindet im Mittelwert	Einheit prüfen, Spitzenwert separat zeigen, menschliche Einordnung	Test mit 19 normalen Werten und einem Ausreißer

Hilfestellung: Notiere im Review pro Befund den betroffenen Ausdruck, das erwartete Verhalten, den konkreten Versuch und das beobachtete Ergebnis. Vertiefung: Prüfe, welche Annahmen auch im verbesserten Code offenbleiben (beispielsweise Herkunft, Zeitstempel, doppelte Datensätze und Messunsicherheit).

Tests als Gegenbeweise formulieren

Klein anfangen: reproduzierbare Python-Tests

Ein Regressionstest hält fest, welches Verhalten nach einer Reparatur dauerhaft gelten soll. Für die neue Funktion lassen sich ohne zusätzliche Bibliothek folgende illustrative Tests ausführen. Lege die Funktion und die Tests in einer lokalen Datei ab. Es werden keine echten Personen- oder Maschinenwerte benötigt.

import unittest

class ReviewTests(unittest.TestCase):
    def test_guest_denied(self):
        with self.assertRaises(PermissionError):
            review_dashboard([{"temp": 20}], "guest", "C")

    def test_upper_limit(self):
        with self.assertRaises(ValueError):
            review_dashboard([{"temp": 20}] * 501, "reviewer", "C")

    def test_unit_rejected(self):
        with self.assertRaises(ValueError):
            review_dashboard([{"temp": 20}], "reviewer", "F")

    def test_spike_requires_review(self):
        rows = [{"temp": 20}] * 19 + [{"temp": 85}]
        result = review_dashboard(rows, "reviewer", "C")
        self.assertEqual(result["mean_c"], 23.25)
        self.assertTrue(result["needs_human_check"])

    def test_nan_rejected(self):
        with self.assertRaises(ValueError):
            review_dashboard([{"temp": float("nan")}],
                             "reviewer", "C")

if __name__ == "__main__":
    unittest.main()

Führe die Tests lokal mit python dateiname.py aus. Rot bedeutet: Ein Test weist auf eine Abweichung oder einen Testfehler hin. Grün bedeutet nur: Die tatsächlich geschriebenen Tests bestanden in dieser Umgebung. Es beweist nicht, dass alle Rollen, Formate oder Fachfälle abgedeckt sind. Ergänze selbst die Fälle 500 Werte, leere Liste, fehlendes Feld und eine andere Rolle.

Medienimpuls (englisch): Die Testpyramide illustriert verschiedene Prüfebenen, nicht eine verpflichtende Zahlenquote. Bild: Abbe98, CC BY-SA 4.0; Dateiseite. Textalternative: Eine Einheit kann lokal korrekt wirken und im Zusammenspiel mit Dateiimport oder Rechteprüfung dennoch versagen.

Vom Unit-Test zum vollständigen Import-Review

Eine getrennte Importfunktion sollte Dateigröße, Kodierung, Trennzeichen, Spaltennamen, Einheiten und Datensatzanzahl prüfen, bevor die Daten ans Dashboard gelangen. Ein Integrationstest simuliert „CSV-Datei → Parser → Validierung → Auswertung“, ohne Netzwerk oder Gerät. Der Dateiname ist kein Vertrauensbeweis; unbekannte Inhalte nie als Code ausführen. Füge zu den Akzeptanzkriterien beobachtbare Ausgaben und verständliche Fehlertexte hinzu.

Verwende für ein Review einen neuen Git-Zweig und ein kleines Diff (Unterschied zwischen Dateiversionen). Schreibe den Test, reproduziere den Befund, korrigiere den Code, lasse Tests erneut laufen und notiere verbleibende Risiken. Keine automatische Zusammenführung ohne unabhängige Freigabe.

Medienimpuls: Tests, Umsetzung und erneute Prüfung bilden einen Verbesserungszyklus. Bild: MovGP0, Lizenz und weitere Angaben auf der Commons-Dateiseite. Textalternative: Zuerst erwartetes Verhalten formulieren, dann Code ändern und erneut prüfen.

Reviewentscheidung, Transfer und menschliche Freigabe

Schweregrad und nachvollziehbare Entscheidung

Blockierend bedeutet, dass der Änderungsvorschlag so nicht zusammengeführt werden darf, etwa bei einer belegten Datenfreigabe an guest oder unklarer fachlicher Aussage. Verbesserung erforderlich bezeichnet einen Mangel mit vereinbartem Reparatur- und Testauftrag. Akzeptiert ist nur ein belegter Reviewstatus innerhalb der begrenzten Simulation, keine Bestätigung von Maschinensicherheit. Formuliere nicht „Die KI sagt, es ist sicher“, sondern „Test X zeigte Ergebnis Y unter Bedingung Z; Annahme Q blieb ungeprüft“.

Die prüfende Person muss mindestens den Befund, eine konkrete Reproduktion, die betroffene Anforderung, eine Korrektur, den erneuten Test und das Restrisiko dokumentieren. Die Entwicklerperson kann den Vorschlag überarbeiten; eine davon unabhängige, berechtigte Fachperson entscheidet über die Freigabe. Für einen realen Einsatz wären zusätzliche organisatorische, regulatorische und domänenspezifische Prüfungen notwendig.

Review-Notiz als Lernprodukt

Feld	Eigenständiger Review-Nachweis
Ticket und Scope	Synthetisches Dashboard, nur lokal; keine Gerätesteuerung
Befund und Ort	Konkreter Codeausdruck plus Art des Problems
Risiko und Gegenbeispiel	Rolle, Eingabe oder fachliche Annahme plus reproduzierbarer Versuch
Änderung und Test	Welche Regel ergänzt wurde und welches Ergebnis nachgewiesen ist
Grenze und Entscheidung	Welche Unsicherheit besteht und warum Freigabe erteilt oder verweigert wird

Transfer: Untersuche einen zweiten, ebenfalls synthetischen Dashboard-Entwurf mit Dateiupload und einer fiktiven Export-Schaltfläche. Frage insbesondere, ob nur autorisierte Daten exportiert werden, ob große Eingaben kontrolliert sind und ob Kennzahlen überhaupt die behauptete fachliche Aussage stützen.

Vertiefung zu KI:: Ein Modell kann Warnungen oder Tests vorschlagen, aber auch scheinbar überzeugende falsche Begründungen erfinden. Behandelte Risiken aus NIST AI 600-1 wie nicht verlässlich abgesicherte Behauptungen oder unzureichende Tests sind Anlass, Qualitätssicherung über die gesamte Nutzungskette zu planen. Ein Code-Scanner findet nicht automatisch, welche physikalische Interpretation eine Messgröße besitzen soll. Menschliches Fachreview ergänzt Automaten.

Optionales Medium (englisches Commons-Video): Zusammenarbeit an Open-Source-Code, GitHub OctoTales • jQuery (1:21 Minuten, GitHub, CC BY 3.0, vorab prüfen, ob die eher allgemeine Perspektive zur eigenen Review-Diskussion passt). Textalternative: Prüfe, wie eine Änderung geteilt, von anderen verstanden und diskutiert werden kann; das Video ist für die Aufgaben nicht erforderlich. Ein verlässlich abrufbarer, fachlich passender YouTube-Einzelvideonachweis ließ sich nicht herstellen; daher keine erfundene YouTube-Einbettung.

Interaktive Aufgaben

Multiple-Choice-Quiz

Beantworte jede Frage und beachte anschließend die Rückmeldung der Quizfunktion. Die Fragen folgen der Reihenfolge vom Grundverständnis bis zur Reviewentscheidung.

Was ist das Hauptziel eines professionellen Reviews von KI-Code? (Anforderungen Risiken und fachliche Annahmen anhand von Belegen prüfen) (!Nur die Einrückung aller Zeilen vereinheitlichen) (!Den Vorschlag ungeprüft übernehmen weil er ausführbar ist) (!Möglichst viele Codezeilen in kurzer Zeit erzeugen)

Wo muss ein Verbot des Lesens von Rohdaten durch Gäste wirksam geprüft werden? (An der vertrauenswürdigen Datenzugriffsgrenze) (!Allein durch das Ausblenden einer Schaltfläche) (!Nur in der README des Projekts) (!Durch den Namen des aufrufenden Dateipfads)

Welcher Fall weist im Modell die fehlende Obergrenze des Imports nach? (Eine Liste mit 501 synthetischen Datensätzen) (!Eine Liste mit genau einem korrekten Datensatz) (!Ein Rollenname mit acht Buchstaben) (!Eine Quellcodedatei mit einer kurzen Kommentarzeile)

Warum ist die reine Umwandlung eines Eingabewerts in float unzureichend? (Weil auch nicht endliche Zahlenwerte entstehen können) (!Weil float grundsätzlich keine Dezimalzahlen verarbeitet) (!Weil dann automatisch alle Rechteprüfungen verschwinden) (!Weil dadurch immer eine Datei gelöscht wird)

Welche Überprüfung widerlegt die falsche Temperaturannahme am besten? (Einheit und Ausreißer unabhängig vom Mittelwert prüfen) (!Den Variablennamen mean_c besonders kurz wählen) (!Die Tabelle alphabetisch sortieren) (!Den Status ohne Datengrundlage auf normal setzen)

Welche Aussage trifft auf bestandene Unit-Tests zu? (Sie belegen die geprüften Fälle nicht die vollständige Sicherheit) (!Sie ersetzen die fachliche Freigabe in jedem Projekt) (!Sie beweisen dass es keine Berechtigungsfehler gibt) (!Sie machen Integrationstests grundsätzlich überflüssig)

Warum soll die Gästeprüfung vor einer Rückgabe erfolgen? (Damit unberechtigte Aufrufe keine Rohdaten erhalten) (!Damit mehr Dezimalstellen angezeigt werden) (!Damit alle Daten ohne Validierung importiert werden) (!Damit nur der Titel des Dashboards geändert wird)

Was ist ein hilfreicher Review-Kommentar? (Fundstelle Gegenbeispiel Risiko und vorgeschlagene Prüfung) (!Ein pauschales Lob ohne überprüfbare Aussage) (!Eine persönliche Schuldzuweisung) (!Eine Behauptung über Sicherheit ohne Test)

Wie sollten Coding-Agenten in einem Übungsrepository berechtigt werden? (Mit minimal nötigen Rechten und kontrollierten Werkzeugaktionen) (!Mit dauerhaften uneingeschränkten Produktivzugängen) (!Mit veröffentlichten privaten Zugangsdaten) (!Mit automatischer Freigabe jeder vorgeschlagenen Änderung)

Wann ist im Modellfall ein menschlicher Review besonders wichtig? (Wenn fachliche Bedeutung und Restrisiko bewertet werden müssen) (!Nur wenn ein Dateiname einen Umlaut enthält) (!Nur wenn eine Grafik größer als die andere ist) (!Nie sobald ein Linter fehlerfrei endet)

Memory

Finde jeweils die zusammengehörenden Begriffe und Bedeutungen. Die Zuordnungen werden im Spiel geprüft.

Autorisierung	Kontrolle erlaubter Aktionen und Datenzugriffe
Negativtest	Probe einer ausdrücklich unerlaubten Situation
Regressionstest	Dauerhafter Nachweis für ein zuvor korrigiertes Verhalten
Fachannahme	Sachliche Voraussetzung hinter einer Kennzahl
Restrisiko	Nach den Kontrollen verbleibende Unsicherheit
Eingabegrenze	Höchstmenge oder erlaubter Bereich importierter Werte

Drag-and-Drop

Ordne jedem beobachteten Befund die passende Kontrollmaßnahme zu.

Passende Kontrollmaßnahme	Beobachteter Befund
Serverseitige Rollenprüfung	Gast erhält vertrauliche Einzelwerte
Datensatzlimit erzwingen	Ein Import mit 501 Datensätzen wird angenommen
Endlichkeit prüfen	Eine ungültige Zahl wird als Messwert verarbeitet
Einheitenannahme überprüfen	Fahrenheit wird als Celsius ausgegeben
Fachliches Gegenbeispiel testen	Ein einzelner Spitzenwert verschwindet im Durchschnitt

Kreuzworträtsel

Gib zu jedem Hinweis ein Fachwort ohne Leerzeichen ein.

Review	Gemeinsame fachliche Untersuchung eines Codevorschlags
Grenze	Festgelegte Höchstmenge für Datensätze
Rechte	Erlaubte Zugriffe bestimmter Rollen
Import	Übernahme von Messwerten aus einer Datei
Risiko	Möglichkeit eines unerwünschten Schadens
Freigabe	Dokumentierte Entscheidung einer berechtigten prüfenden Person

LearningApps

Nutze die thematische LearningApps-Suche für zusätzliche Übungen; einzelne fremde Anwendungen sind nicht automatisch qualitätsgeprüft. Eine Offline-Alternative ist, die fünf Zuordnungen aus der vorherigen Aufgabe auf Karteikarten zu übertragen und gegenseitig zu überprüfen.

Lückentext

Ergänze in jedem Satz genau den passenden Begriff aus dem Gelernten. Offline kannst du die Sätze mit selbst gewählten Begriffen auf Papier bearbeiten und fachlich begründen.

Ein Code-Review vergleicht Programmcode mit den vereinbarten

.

Die Prüfung einer erlaubten Aktion heißt

.

Eine Prüfung mit bewusst nicht erlaubten Eingaben ist ein

.

Vor dem Lesen einer langen Messwertliste prüft man die

.

Nicht endliche Zahlen werden beispielsweise mit math.isfinite als

erkannt.

Neben dem Durchschnitt dokumentiert die Übung den

.

Die Angabe Celsius bezeichnet im Modell die

.

Ein bestandener Test beweist nur einen überprüften

.

Die Dokumentation verbleibender Ungewissheiten benennt das

.

Die letzte Entscheidung über den Übungscode trifft ein berechtigter menschlicher

.

Offene Aufgaben

Leicht

Review vorbereiten: Erstelle eine einseitige Checkliste mit den Feldern Anforderung, Fundstelle, Gegenbeispiel, Risiko und Entscheidung; ergänze ein eigenes Beispiel.
Rollen erkennen: Zeichne eine Tabelle für guest, viewer und reviewer und beschreibe, wer im synthetischen Modell Einzelwerte sehen darf und warum.
Grenzwerte markieren: Notiere die erwarteten Reaktionen auf null, einen, 500 und 501 Datensätze und erkläre, welche Tests Grenzfalltests sind.
Werte untersuchen: Prüfe in Gedanken die Eingaben 20, fehlt und NaN; begründe die sichere Behandlung ohne echten Dateiimport.

Standard

Bug reproduzieren: Kopiere den fehlerhaften Übungscode lokal und dokumentiere für guest den tatsächlichen sowie erwarteten Rückgabewert; keine realen Daten einsetzen.
Testfälle erweitern: Implementiere Tests für die leere Liste, ein fehlendes Feld und genau 500 synthetische Werte. Erläutere jeweils, warum der Test aussagekräftig ist.
Änderung prüfen: Erstelle aus der Übungsfunktion ein kleines Git-Diff und verfasse drei höfliche Review-Kommentare mit Beobachtung, Auswirkung und gefordertem Nachweis.
Aussagen kritisch lesen: Berechne den Mittelwert aus 19 Werten von 20 und einem Wert von 85; beurteile, warum die Aussage normal fachlich nicht gesichert ist.

Schwer

Bedrohungsmodell: Analysiere für einen fiktiven CSV-Upload Schutzgüter, Rollen, Missbrauchsfälle und Kontrollen; trenne nachgewiesene Fehler von Vermutungen.
Importkette testen: Entwirf oder programmiere einen Offline-Test für eine synthetische CSV-Datei über Parser, Validierung und Dashboard; prüfe falsche Einheit und zu viele Zeilen.
Reviewprozess verbessern: Vergleiche Linter, Unit-Tests, Integrationstests und Fachreview an denselben drei Befunden; beschreibe konkret die verbleibenden Blindstellen.
Freigabe begründen: Verfasse einen Reviewbericht mit drei belegten Fehlerfällen, Korrekturmaßnahmen, Testnachweisen, Restrisiken und begründeter Ablehnung oder begrenzter Übungsfreigabe.

Lernkontrolle

Bearbeite die Lernkontrolle eigenständig ohne Lösungsschlüssel; verwende nur synthetische Beispiele und lege für jede Behauptung einen prüfbaren Nachweis vor.

Rechtefall begründen: Beschreibe, wie ein Gastzugriff auf Rohdaten trotz versteckter Schaltfläche möglich sein kann und mit welchem Negativtest du ihn nachweist.
Importgrenze spezifizieren: Formuliere Akzeptanzkriterien für eine Höchstmenge von 500 Einträgen und mindestens drei robuste Gegenbeispiele.
Fachannahme widerlegen: Zeige rechnerisch, warum ein kleiner Durchschnitt einen kritischen Einzelwert im synthetischen Fall verdecken kann; schlage eine nicht steuernde Anzeige vor.
Prüfarten vergleichen: Ordne drei Befunde statischer Analyse, Unit-Test, Integrationstest und menschlichem Fachreview zu; benenne jeweils mindestens eine Grenze.
Freigabeentscheidung treffen: Beurteile einen Änderungsvorschlag mit bestandenem Linter, aber fehlendem Gasttest und unklarer Temperatureinheit. Formuliere eine begründete Entscheidung.
Transfer: Plane den Review einer neu hinzugefügten fiktiven Exportfunktion und begründe, wie Datenrechte auch dort durchgesetzt werden müssen.

Lernnachweis

Abzugeben ist ein eigenständiges Lernprodukt aus (a) einer Übersicht von Anforderung und Scope, (b) dem bewusst fehlerhaften oder annotierten Dashboard-Diff, (c) mindestens drei reproduzierbaren Fehlernachweisen für Rolle, Eingabegrenze und Fachannahme, (d) mindestens fünf lauffähigen lokalen Tests oder gleichwertigen schriftlichen Simulationsprotokollen, (e) dem verbesserten Codekonzept, (f) einer begründeten Reviewentscheidung mit Restunsicherheiten.

Bewertungsraster (20 Punkte): je vier Punkte für korrekte und verständliche Befundbegründungen zu Zugriff, Datenlimit und Fachannahme, vier Punkte für die Nachvollziehbarkeit der Tests und vier Punkte für die begründete menschliche Freigabeentscheidung. Bestanden im Unterricht bedeutet ein nachvollziehbarer Nachweis der Lernziele, keine Produktiv-, Maschinen-, Sicherheits- oder IHK-Freigabe. Wer keine Python-Umgebung nutzt, darf Eingaben und Ausgaben als schriftliches Testprotokoll simulieren.

Selbstkontrolle: Kannst du einen Fehlerfall reproduzieren und dabei erklären, warum die Funktion im gewünschten Fachkontext falsch handelt? Wenn du nur „Der Test ist rot“ sagst, fehlt die Begründung. Dokumentiere Unsicherheit statt erfundener Gewissheit.

OER und Wikipedia

Quellenstand: 22. Oktober 2026. Dokumentation und Projekte können sich ändern; bei späterer Verwendung jeweils Version und Gültigkeit prüfen. Die Quellen stützen Kriterien und Methoden, ersetzen keine Einzelfallprüfung.

OWASP Top 10:2025, deutsche Projektübersicht, A01 Mangelhafte Zugriffskontrolle. Primärquelle für serverseitige Berechtigungsprüfung, Prüfungen und gängige Webrisiken; Version 2025.
Model Context Protocol, Security Best Practices, Dokumentationsstand Version 2026-07-28, für Berechtigungsgrenzen von MCP-Werkzeugen und Agentenanbindungen. Hinweise gelten spezifisch für die dort beschriebenen Systeme.
NIST AI 600-1, Generative Artificial Intelligence Profile, Juli 2024. Risikomanagement für generative KI; nicht als Nachweis einer bestimmten Codequalität zu verstehen.
Python-Standardbibliothek math (Dokumentation der installierten Python-Version beachten), besonders isfinite; unittest für wiederholbare Tests.
Wikipedia: Review (Softwaretest) (Weiterleitung Code-Review); Hintergrund zu Reviewarten und Teamabstimmung. Wikipedia: Softwaretest ergänzt Begriffe; Wikipedia ist ein Einstieg, keine alleinige Sicherheitsquelle.
Verknüpfte Grundlagen auf MOOCwiki, als Vorwissen empfohlen. Inhalt war beim Recherchezugriff nicht abrufbar; deshalb nicht als inhaltlich überprüft ausgegeben.

Mediennachweise und Rechte:

Medium	Verifizierte Dateiseite	Urheberschaft	Lizenz
File:GitWorkflow.svg	Commons	Antoine „hashar“ Musso nach Chad Horohoe	CC BY-SA 3.0
File:Illustration of Closed Box and Open Box Testing disciplines.png	Commons	J-at-ywalters-dot-net	CC BY-SA 4.0
File:Testing Pyramid.svg	Commons	Abbe98	CC BY-SA 4.0
File:Testgetriebener Entwicklungsprozess.svg	Commons	MovGP0	siehe aktuelle Rechteangabe auf Dateiseite
File:GitHub OctoTales • jQuery.webm	Commons	GitHub	CC BY 3.0

Die Illustrationen sind teils englisch beschriftet, ihre Textalternativen stehen direkt darunter. Das optionale Video ist auf Commons abrufbar; die jeweiligen Streamingmöglichkeiten können im Einzelfall variieren. Keine eigenen Medien erzeugt. Eine separat überprüfbare, fachlich passende YouTube-Verfügbarkeit konnte nicht bestätigt werden; deshalb keine YouTube-ID erfunden.

Wikipedia als optionale Lektüre:

Wer externe Seiten nicht nutzen kann, findet alle Anforderungen, Übungscodes, Fragen, Zuordnungskarten und Bewertungskriterien im Kurs selbst.