aiMOOC

IT-Service Projekte und Automatisierung – Build- und Testabläufe automatisieren

QR-Code

IT-Service Projekte und Automatisierung – Build- und Testabläufe automatisieren

Kurzbeschreibung: Reproduzierbare Qualitätssicherung

Zielgruppe: Ausbildung im IT-Bereich, insbesondere Fachinformatiker/-innen für Anwendungsentwicklung und Systemintegration.

Niveau: Grundlagen bis berufliche Anwendung

Umfang: 7 kurze Lernstationen mit praktischen Übungen, interaktiven Aufgaben und Lernnachweis.

Lernziel: Du kannst einen einfachen Build- und Testablauf automatisieren, Fehler erkennen, Testergebnisse auswerten und reproduzierbare Softwarepakete erzeugen.

Sicherheitsregel: Arbeite ausschließlich in einem eigenen, lokalen Übungsordner mit fiktiven Daten. Verwende keine echten Tickets, Kundendaten, Zugangsdaten, Produktivsysteme oder fremden Netzwerke. Die bereitgestellten Python-Programme benötigen keine Netzwerkverbindung.

Einleitung

Stell Dir vor, Du arbeitest in der IT-Abteilung eines Ausbildungsbetriebs. Eine kleine Software zur Bearbeitung von Service-Tickets wird regelmäßig verändert. Nach jeder Änderung soll automatisch geprüft werden, ob sie weiterhin richtig funktioniert.

Dafür nutzt Du eine Build- und Testpipeline.

Quellcode	Syntaxprüfung	Automatische Tests	Build	Ergebnis
📝	🔍	🧪	📦	✅ oder ❌
Änderung	Ist der Code gültig?	Funktioniert er?	ZIP erzeugen	Freigeben oder stoppen

Abbildung: Continuous-Integration-Ablauf, Pratik89Roy, CC BY-SA 4.0. Quelle und Lizenz

Video: Was ist Continuous Integration? – IBM Technology.

Beobachtungsauftrag: Achte darauf, warum häufige kleine Änderungen und automatisierte Tests die Fehlersuche erleichtern.

Dein Ausbildungsauftrag

Ein fiktiver Ausbildungsbetrieb verwendet eine kleine Funktion zur Priorisierung von IT-Service-Tickets.

Die Funktion verarbeitet ausschließlich zwei Zahlen:

Auswirkung: Wie stark ist ein fiktives Problem?
Dringlichkeit: Wie schnell sollte das fiktive Problem bearbeitet werden?

Beide Werte liegen zwischen 1 und 3. Die folgende Bewertung ist eine frei erfundene Laborregel und kein allgemein gültiges ITIL- oder SLA-Verfahren.

Auswirkung	Dringlichkeit	Punktzahl	Priorität
1	1	1	niedrig
2	2	4	mittel
3	2	6	hoch
3	3	9	hoch

Regel: Multipliziere Auswirkung und Dringlichkeit. Ab 6 Punkten gilt die Priorität als hoch, ab 3 Punkten als mittel und darunter als niedrig.

Deine Mission: Entwickle eine kleine Prüfpipeline, die falsche Änderungen erkennt und nur nach erfolgreichen Tests ein neues Softwarepaket erstellt.

Lernstation 1 – Build, Test und Qualität verstehen

Dauer: ca. 10 Minuten

Ein Build erstellt aus Quellcode ein nutzbares Ergebnis, beispielsweise ein Softwarepaket. Ein Softwaretest überprüft festgelegte Erwartungen an das Programm.

Eine CI-Pipeline führt solche Prüfungen regelmäßig und möglichst automatisch aus. Unsere Ausbildungspipeline wird zunächst bewusst nur lokal gestartet.

Abbildung: Testpyramide, Abbe98, CC BY-SA 4.0. Quelle und Lizenz

Testebene	Was wird überprüft?	Beispiel im Ausbildungsfall
Modultest	Einzelne Funktion	Die Prioritätsberechnung
Integrationstest	Zusammenarbeit mehrerer Bestandteile	Spätere Verbindung mit einem fiktiven Ticketspeicher
Systemtest	Gesamtes System	Eine vollständig isolierte Demo-Anwendung

Merke: Viele schnelle Modultests helfen bei der Fehlersuche. Sie ersetzen jedoch keine Integrations-, Sicherheits- oder Systemtests.

Abbildung: Software Testing Life Cycle, Perfect Happiness, CC BY-SA 4.0. Quelle und Lizenz

Mini-Auftrag: Erkläre einer anderen lernenden Person den Unterschied zwischen einem Test und einem Build in zwei Sätzen.

Begründetes Feedback: Deine Erklärung ist richtig, wenn der Test ein Verhalten prüft und der Build ein Ergebnis erzeugt. Ein erfolgreich erzeugtes Paket beweist noch nicht, dass seine Funktionen korrekt sind.

Lernstation 2 – Eine lokale Testumgebung vorbereiten

Dauer: ca. 10 Minuten

Du benötigst Python 3.10 oder neuer, einen Texteditor und ein lokales Terminal. Zusätzliche Python-Pakete oder Internetzugänge sind nicht erforderlich.

Erstelle einen neuen Ordner mit dem Namen ticket-labor. Darin legst Du die folgenden Dateien an:

ticket-labor/
    service.py
    test_service.py
    build.py
    pipeline.py
    spielplatz.py
    dist/                (entsteht automatisch)

Linux und macOS:

python3 -m venv --without-pip .venv
.venv/bin/python pipeline.py

Windows:

py -3 -m venv --without-pip .venv
.\.venv\Scripts\python.exe pipeline.py

Führe den zweiten Befehl erst aus, nachdem Du die Dateien der folgenden Lernstationen angelegt hast.

Eine virtuelle Python-Umgebung trennt Projektbibliotheken von anderen Python-Installationen. Sie ist keine Sicherheits-Sandbox und sperrt weder Dateisystem noch Netzwerk. Verwende deshalb ausschließlich den hier gezeigten, vertrauenswürdigen Übungscode. Für unbekannten Code wäre zusätzlich eine ausdrücklich freigegebene, netzwerkisolierte VM erforderlich.

Selbstcheck: Die Python-Version lässt sich mit python3 --version oder unter Windows mit py -3 --version prüfen.

Lernstation 3 – Modultests automatisieren

Dauer: ca. 20 Minuten

Schritt 1: Die Funktion erstellen

Speichere folgenden Code als service.py:

def prioritaet(auswirkung: int, dringlichkeit: int) -> str:
    """Fiktive Prioritaetsregel fuer ein Ausbildungslabor."""
    for wert in (auswirkung, dringlichkeit):
        if type(wert) is not int or wert not in (1, 2, 3):
            raise ValueError("Nur ganze Zahlen von 1 bis 3")

    punkte = auswirkung * dringlichkeit

    if punkte >= 6:
        return "hoch"
    if punkte >= 3:
        return "mittel"
    return "niedrig"

Die Funktion berechnet eine Priorität und weist ungültige Eingaben zurück.

Schritt 2: Sechs Tests erstellen

Speichere folgenden Code als test_service.py:

import unittest
from service import prioritaet


class PrioritaetTests(unittest.TestCase):

    def test_hoch(self):
        self.assertEqual(prioritaet(3, 2), "hoch")

    def test_mittel(self):
        self.assertEqual(prioritaet(2, 2), "mittel")

    def test_niedrig(self):
        self.assertEqual(prioritaet(1, 1), "niedrig")

    def test_grenzwert(self):
        self.assertEqual(prioritaet(1, 3), "mittel")

    def test_ungueltiger_wert(self):
        with self.assertRaises(ValueError):
            prioritaet(4, 1)

    def test_bool_ungueltig(self):
        with self.assertRaises(ValueError):
            prioritaet(True, 1)

Der Test prüft die erwarteten Ergebnisse der Funktion. Das Python-Modul unittest vergleicht Ist- und Sollwerte automatisch.

Video: Unit Testing mit Python – Corey Schafer, englisch.

Lernauftrag: Suche im Video die Verwendung von assertEqual und vergleiche sie mit unserem Ausbildungsbeispiel.

Schritt 3: Tests lokal starten

Linux und macOS:

.venv/bin/python -m unittest discover -v

Windows:

.\.venv\Scripts\python.exe -m unittest discover -v

Erwartetes Ergebnis: Bei korrekt übernommenem Code werden sechs Tests ausgeführt und alle bestehen.

Begründetes Feedback: Sind alle Tests erfolgreich, stimmen die sechs überprüften Fälle mit den erwarteten Ergebnissen überein. Das bedeutet nicht, dass alle möglichen Fehler ausgeschlossen sind.

Lernstation 4 – Ein reproduzierbares Softwarepaket bauen

Dauer: ca. 15 Minuten

Ein reproduzierbarer Build soll bei unveränderten Eingaben unter entsprechend kontrollierten Bedingungen bytegleiche Ergebnisse erzeugen.

Bei ZIP-Archiven können beispielsweise unterschiedliche Zeitstempel und Dateiattribute dieses Ziel verhindern.

Abbildung: Continuous Delivery Process, Grégoire Détrez nach Jez Humble, CC BY-SA 4.0. Quelle und Lizenz. Die Abbildung zeigt einen erweiterten Softwareprozess; in unserem Labor findet keine Auslieferung statt.

Schritt 1: Den Build programmieren

Speichere folgenden Code als build.py:

from hashlib import sha256
from pathlib import Path
from zipfile import ZIP_STORED, ZipFile, ZipInfo


def baue():
    basis = Path(__file__).resolve().parent
    quelle = basis / "service.py"
    ziel = basis / "dist" / "servicepaket.zip"
    ziel.parent.mkdir(exist_ok=True)

    info = ZipInfo(
        "service.py",
        date_time=(2020, 1, 1, 0, 0, 0)
    )
    info.compress_type = ZIP_STORED
    info.create_system = 3
    info.external_attr = 0o644 << 16

    with ZipFile(ziel, "w") as archiv:
        archiv.writestr(info, quelle.read_bytes())

    print(
        "SHA-256:",
        sha256(ziel.read_bytes()).hexdigest()
    )


if __name__ == "__main__":
    baue()

Das passiert:

ZIP: Die Datei service.py wird lokal verpackt.
Metadaten: Ein fester Archivzeitstempel und feste Dateiattribute werden gesetzt.
Prüfsumme: SHA-256 berechnet einen Fingerabdruck des ZIP-Pakets.

Der Build verwendet ZIP_STORED, also keine Kompression. Dadurch ist das einfache Ausbildungsbeispiel unabhängig von möglichen Unterschieden bei der ZIP-Kompression.

Schritt 2: Reproduzierbarkeit prüfen

Führe den Build zweimal aus:

python build.py
python build.py

Verwende dabei die Python-Installation der virtuellen Umgebung, wenn Du diese eingerichtet hast.

Soll-Beobachtung: Bei unveränderter Quelldatei sind beide ausgegebenen SHA-256-Werte identisch.

Wichtig: Der Vergleich gilt bei identischen Eingabebytes und den festgelegten Archivparametern. Änderungen des Quelltexts, einschließlich unterschiedlicher Zeilenenden, können den Hash verändern.

Eine gleiche Prüfsumme zeigt die Übereinstimmung der erzeugten Bytes mit sehr hoher Sicherheit an. Sie beweist weder Fehlerfreiheit noch die Vertrauenswürdigkeit des Inhalts.

Lernstation 5 – Die Pipeline automatisieren

Dauer: ca. 20 Minuten

Jetzt verbindest Du Syntaxprüfung, Tests und Build.

Abbildung: Beispiel eines CI-Workflows aus der Wikimedia-Infrastruktur, Hashar/Wikimedia Foundation, CC BY-SA 3.0. Quelle und Lizenz. Der dargestellte ältere Workflow ist umfangreicher als unser lokales Labor.

Schritt 1: pipeline.py erstellen

import py_compile
import unittest
from pathlib import Path
from build import baue


basis = Path(__file__).resolve().parent

print("1/3 Syntax pruefen")
try:
    py_compile.compile(
        str(basis / "service.py"),
        doraise=True
    )
except py_compile.PyCompileError as fehler:
    raise SystemExit("STOP: Syntaxfehler") from fehler

print("2/3 Tests ausfuehren")
suite = unittest.defaultTestLoader.discover(
    str(basis), pattern="test_*.py"
)
resultat = unittest.TextTestRunner(
    verbosity=2
).run(suite)

fehlgeschlagen = (
    len(resultat.failures) + len(resultat.errors)
)
bestanden = (
    resultat.testsRun
    - fehlgeschlagen
    - len(resultat.skipped)
)

print("Bestanden:", "█" * bestanden, bestanden)
print("Fehler:  ", "█" * fehlgeschlagen, fehlgeschlagen)

if not resultat.wasSuccessful() or resultat.testsRun == 0:
    raise SystemExit("STOP: kein neues Paket")

print("3/3 Paket bauen")
baue()

Schritt 2: Pipeline starten

Linux und macOS:

.venv/bin/python pipeline.py

Windows:

.\.venv\Scripts\python.exe pipeline.py

Die Pipeline startet immer mit der Syntaxprüfung. Nur wenn die Tests erfolgreich sind, wird der Build aufgerufen.

Wichtig: Ein bereits vorhandenes altes ZIP-Paket wird bei einem späteren Testfehler nicht automatisch gelöscht. Es darf deshalb nur zusammen mit einem erfolgreichen, aktuellen Pipelineprotokoll als gültiges Ergebnis betrachtet werden.

Testdaten sichtbar auswerten

Das folgende Diagramm zeigt die erwarteten Testzahlen unseres Ausbildungsbeispiels. Die Pipeline erzeugt ihre eigenen Balken aus den tatsächlich ausgeführten Tests.

Durchlauf	Bestanden	Fehler	Neuer Build
Unveränderter Code	██████ 6	0	✅
Absichtlich veränderte Grenze	█████ 5	█ 1	❌
Fehler korrigiert	██████ 6	0	✅

Auswertung: Die Werte 6–0, 5–1 und 6–0 sind erwartete Laborergebnisse für die nachfolgende gezielte Änderung. Sie sind keine Messwerte eines fremden Systems.

Feedback: Wenn die Pipeline trotz eines fehlerhaften Tests ein neues Paket baut, fehlt eine wirksame Qualitätskontrolle. Ein korrekter Ablauf muss die weitere Verarbeitung stoppen.

Lernstation 6 – Fehler erkennen und interaktiv testen

Dauer: ca. 15 Minuten

Experiment: Rot – Grün

Fehler beim Erstellen des Vorschaubildes:

Abbildung: Testgetriebene Entwicklung, Excirial/Jarozwj, CC BY-SA 3.0. Quelle und Lizenz

Ändere in service.py zu Testzwecken:

if punkte >= 6:

in:

if punkte > 6:

Starte jetzt pipeline.py erneut.

Erwartung: Der Test test_hoch schlägt fehl. Der Wert 6 wird fälschlich nicht mehr als hohe Priorität eingestuft. Die Pipeline stoppt vor dem Build.

Stelle anschließend die ursprüngliche Bedingung punkte >= 6 wieder her und starte die Pipeline erneut.

Begründetes Feedback: Die Änderung verschiebt die Entscheidungsschwelle. Genau deshalb ist ein Grenzwerttest wichtig: Er erkennt Fehler, die bei weit entfernten Testwerten möglicherweise unbemerkt bleiben.

Lokaler interaktiver Testspielplatz

Erstelle die Datei spielplatz.py.

from service import prioritaet

print("Nur fiktive Daten!")
print("Auswirkung und Dringlichkeit: je 1 bis 3.")

while True:
    eingabe = input(
        "Zwei Werte (z.B. 3,2) oder ende: "
    ).strip()

    if eingabe.lower() == "ende":
        break

    try:
        teile = eingabe.split(",")
        if len(teile) != 2:
            raise ValueError
        werte = [int(teil) for teil in teile]
        print("Prioritaet:", prioritaet(*werte))
    except ValueError:
        print("Bitte zwei ganze Zahlen von 1 bis 3 eingeben.")

Starte das Programm mit dem Python-Interpreter Deines lokalen Labors, beispielsweise unter Linux oder macOS:

.venv/bin/python spielplatz.py

Probiere folgende fiktive Eingaben aus:

Eingabe	Erwartung	Begründung
3,2	hoch	Sechs Punkte erreichen die obere Schwelle.
2,2	mittel	Vier Punkte liegen im mittleren Bereich.
1,1	niedrig	Ein Punkt erreicht keine höhere Schwelle.
4,1	Fehlermeldung	Vier liegt außerhalb des erlaubten Wertebereichs.

Sicherheit: Der Spielplatz verarbeitet nur die von Dir eingegebenen fiktiven Werte. Er enthält keine Netzwerkbefehle, Datenbankzugriffe oder Schnittstellen zu fremden Diensten.

Gestufte Hilfen zur Fehlersuche

Hilfestufe	Hinweis
Hilfe 1 – Orientierung	Prüfe zuerst, ob die Fehlermeldung aus der Syntaxprüfung oder aus einem Test stammt.
Hilfe 2 – Eingrenzung	Lies den Namen des fehlgeschlagenen Tests. Vergleiche Eingabe, erwartetes Ergebnis und tatsächliches Ergebnis.
Hilfe 3 – Lösungspfad	Bei `test_hoch` kontrolliere den Vergleichsoperator und die Grenze von sechs Punkten. Stelle die korrekte Bedingung wieder her.

Automatisches Feedback verstehen

Meldung	Bedeutung	Sinnvolle Reaktion
OK	Die ausgeführten Tests stimmen mit den Erwartungen überein.	Zusätzliche Grenzfälle prüfen.
FAIL	Ein erwartetes Ergebnis wurde nicht erreicht.	Soll- und Istwert vergleichen.
ERROR	Beim Test trat ein unerwarteter Fehler auf.	Fehlermeldung und Aufrufstelle untersuchen.
STOP	Die Pipeline verweigert den nächsten Arbeitsschritt.	Ursache beheben und erneut testen.
Gleicher SHA-256-Wert	Die Archivbytes sind bei unveränderten Eingaben reproduziert worden.	Eingaben und Buildbedingungen dokumentieren.

Lernstation 7 – Von der lokalen Pipeline zur professionellen Qualitätssicherung

Dauer: ca. 10 Minuten

In Ausbildungs- und Unternehmensprojekten werden solche Schritte häufig durch CI-Systeme automatisiert angestoßen, beispielsweise bei einer Änderung in einer Versionsverwaltung.

Continuous Integration bedeutet regelmäßige Integration mit automatisierten Prüfungen.

Continuous Delivery erweitert den Prozess um die Bereitstellung eines grundsätzlich auslieferbaren Stands.

Continuous Deployment bezeichnet eine noch weitergehende automatische Veröffentlichung nach definierten Prüfungen.

Im vorliegenden Ausbildungsprojekt findet keine automatische Veröffentlichung, kein Deployment und keine Verbindung zu einem fremden Repository statt.

Vertiefungsvideo: GitHub Actions und CI/CD – TechWorld with Nana. Für diesen Kurs ist besonders der konzeptionelle Abschnitt von 00:00 bis 09:50 geeignet. Cloud-Anmeldungen, Docker-Pushs und Deployments aus dem Video werden nicht nachgebaut.

Transferfrage: Warum reichen sechs erfolgreiche Modultests allein noch nicht für die Freigabe eines echten IT-Service-Produkts?

Feedback: Weil das Verhalten weiterer Komponenten, Sicherheit, Rechte, Datenschutz, Performance und reale Betriebsbedingungen noch nicht ausreichend geprüft wurden.

Interaktive Aufgaben

Quiz: Teste Dein Wissen

Was ist das Hauptziel einer automatisierten Testpipeline? (Änderungen anhand festgelegter Prüfungen kontrollieren) (!Beliebigen Quellcode automatisch fehlerfrei machen) (!Alle manuellen Prüfungen grundsätzlich abschaffen) (!Kundendaten automatisch veröffentlichen)

Welche Aufgabe übernimmt ein Modultest? (Das Verhalten einer einzelnen Funktion überprüfen) (!Das gesamte Unternehmensnetzwerk überprüfen) (!Eine Software automatisch an Kunden versenden) (!Zugangsdaten für einen Server erzeugen)

Was sollte nach einem fehlgeschlagenen Test passieren? (Der Build wird gestoppt) (!Das neue Paket wird trotzdem freigegeben) (!Der Test wird automatisch als erfolgreich bewertet) (!Die Fehlermeldung wird grundsätzlich gelöscht)

Welcher Python-Bestandteil führt unsere Modultests aus? (unittest) (!zipfile) (!hashlib) (!pathlib)

Wozu dient eine Prüfsumme im Buildprozess? (Zum Vergleichen erzeugter Dateiinhalte) (!Zum automatischen Beheben aller Programmfehler) (!Zum Verhindern aller Sicherheitslücken) (!Zum Erstellen von Benutzerkonten)

Welcher Faktor kann die Reproduzierbarkeit eines ZIP-Pakets beeinflussen? (Unterschiedliche Archivzeitstempel) (!Der Name des verwendeten Texteditors allein) (!Die Farbe des Terminalfensters) (!Die Bildschirmauflösung)

Warum ist ein Grenzwerttest sinnvoll? (Er prüft das Verhalten direkt an einer Entscheidungsschwelle) (!Er verhindert die Erstellung von Quellcode) (!Er ersetzt grundsätzlich jeden Integrationstest) (!Er garantiert fehlerfreie Produktivsysteme)

Was bedeutet ein grünes Testergebnis? (Die ausgeführten Tests haben ihre Erwartungen erfüllt) (!Alle möglichen Fehler sind ausgeschlossen) (!Das Programm wurde bereits sicher veröffentlicht) (!Jede Sicherheitsanforderung wurde geprüft)

Welche Umgebung wird für das Ausbildungsprojekt verwendet? (Ein lokaler Übungsordner mit fiktiven Daten) (!Eine fremde Produktionsdatenbank) (!Ein öffentlich erreichbarer Kundenserver) (!Ein Unternehmensnetz ohne Genehmigung)

Was beschreibt Continuous Integration am besten? (Änderungen regelmäßig zusammenführen und automatisiert prüfen) (!Software ohne Prüfungen direkt veröffentlichen) (!Programme ausschließlich manuell installieren) (!Alle Projektdateien täglich löschen)

Memory

Modultest	Prüft eine einzelne Funktion
Build	Erstellt ein Softwarepaket
Pipeline	Verbindet automatisierte Arbeitsschritte
SHA-256	Berechnet einen Dateifingerabdruck
Grenzwert	Markiert eine Entscheidungsschwelle
Artefakt	Bezeichnet ein erzeugtes Buildprodukt
Syntaxprüfung	Kontrolliert die formale Codegültigkeit

Drag and Drop

Ordne jedem Schritt seine Funktion zu.

Ordne die richtigen Begriffe zu.	Funktion im Projekt
Syntaxprüfung	Quellcode auf formale Fehler untersuchen
Modultest	Erwartete Funktionsausgaben vergleichen
Buildprozess	Quellcode zu einem ZIP-Paket bündeln
Prüfsummenberechnung	Den Fingerabdruck eines Pakets erzeugen
Fehleranalyse	Abweichungen zwischen Soll und Ist untersuchen
Qualitätsfreigabe	Erfolgreiche Prüfergebnisse als Entscheidungsvoraussetzung verwenden

Kreuzworträtsel

Pipeline	Wie heißt eine festgelegte Folge automatisierter Verarbeitungsschritte?
Modultest	Wie nennt man eine Prüfung für eine einzelne Softwarefunktion?
Artefakt	Wie heißt ein bei einem Build erzeugtes Produkt?
Pruefsumme	Wie heißt ein berechneter Fingerabdruck einer Datei?
Isolierung	Wie nennt man die Trennung einer Testumgebung von anderen Umgebungen?
Grenzwert	Wie heißt ein Wert direkt an einer Entscheidungsschwelle?

LearningApps

Optional: Weitere interaktive Übungen zum Thema suchen. LearningApps ist ein externer Anbieter; verwende dort keine personenbezogenen Daten und beachte die Datenschutzregeln Deiner Bildungseinrichtung.

Lückentext

Die automatisierte Verarbeitung mehrerer Prüfschritte heißt

.

Im Ausbildungsprojekt werden ausschließlich

Servicedaten verwendet.

Ein Test einer einzelnen Programmfunktion heißt

.

Das Python-Modul für unsere automatisierten Tests heißt

.

Die Priorität wird aus Auswirkung und

berechnet.

Bei sechs Punkten erhält unser Beispiel die Priorität

.

Ein erfolgreich erstelltes ZIP-Paket ist ein

.

Feste Archivzeitstempel unterstützen die

.

Die Berechnung eines Dateifingerabdrucks erfolgt mit

.

Bei einem Testfehler muss die Pipeline vor dem Build

.

Eine virtuelle Python-Umgebung wird mit dem Modul

erstellt.

Ein Test direkt an einer Entscheidungsschwelle heißt

.

Offene Aufgaben

Die Aufgaben sind nach Schwierigkeit geordnet. Verwende ausschließlich Deine lokalen Kursdateien. Jede Aufgabe enthält ein überprüfbares Feedback-Kriterium.

Leicht – Basisaufgaben

Pipeline-Skizze: Zeichne die fünf Stationen vom Quellcode bis zur Qualitätsentscheidung und beschrifte die Verbindungen. Feedback: Deine Skizze ist schlüssig, wenn ein Fehler vor dem Paketbau zum Stopp führt, denn dadurch wird ein fehlerhafter Stand nicht neu verpackt.
Testfälle verstehen: Erstelle eine Tabelle mit mindestens vier fiktiven Kombinationen von Auswirkung und Dringlichkeit samt erwarteter Priorität. Feedback: Die Ergebnisse sind korrekt, wenn sie aus der festgelegten Punktregel folgen und mindestens ein Grenzwert enthalten.
Begriffe erklären: Erstelle drei digitale Lernkarten zu Test, Build und Artefakt. Feedback: Die Begriffe sind richtig abgegrenzt, wenn Prüfung, Erstellung und Ergebnis nicht miteinander verwechselt werden.
Fehlermeldung dokumentieren: Starte den absichtlich fehlerhaften Grenzwertfall und schreibe einen kurzen Fehlerbericht mit Sollwert, Istwert und Ursache. Feedback: Der Bericht ist nachvollziehbar, wenn eine andere Person die Abweichung mit dem fiktiven Testfall reproduzieren kann.

Standard – Anwendungsaufgaben

Zusätzlichen Test programmieren: Ergänze einen Test für die Eingabe 3 und 3. Feedback: Der Test sollte die Priorität hoch erwarten, weil die Punktzahl neun beträgt und damit die obere Schwelle erreicht.
Ungültige Eingaben prüfen: Ergänze Tests für negative Zahlen, Zeichenketten oder Dezimalzahlen. Feedback: Eine geeignete Lösung erwartet jeweils einen ValueError, weil die Funktion nur ganze Zahlen von eins bis drei zulässt.
Zwei Builds vergleichen: Starte zwei unveränderte Builds und dokumentiere beide Prüfsummen. Verändere danach einen Kommentar in service.py und prüfe erneut. Feedback: Unveränderte Eingabebytes müssen gleiche Paketbytes erzeugen; ein Kommentar verändert die Quelldatei und damit die Prüfsumme.
Ergebnisse visualisieren: Gestalte ein Balkendiagramm für die erfolgreichen, fehlerhaften und korrigierten Testläufe. Feedback: Das Diagramm ist aussagekräftig, wenn es die tatsächlich beobachteten Testzahlen enthält und seine Datenquelle nennt.

Schwer – Transferaufgaben

Prüfstrategie entwerfen: Plane zusätzliche Tests für eine spätere lokale Demo-Oberfläche, die die Prioritätsfunktion verwendet. Unterscheide Modul-, Integrations- und Systemtests. Feedback: Die Planung ist überzeugend, wenn sie zeigt, welche Fehler auf welcher Ebene erkannt werden können.
Pipeline erweitern: Entwirf eine lokale Erweiterung, die vor dem Build einen formalen Qualitätsbericht erzeugt. Das Programm darf ausschließlich Dateien im eigenen Labor verwenden. Feedback: Eine sinnvolle Erweiterung protokolliert Testergebnisse reproduzierbar und stoppt weiterhin bei fehlgeschlagenen Prüfungen.
Sicherheitskonzept entwickeln: Erstelle ein Freigabekonzept für ein späteres Ausbildungsprojekt mit mehreren Beteiligten. Berücksichtige Rollen, Testdaten, Dateizugriffe und Netzwerkgrenzen. Feedback: Das Konzept ist tragfähig, wenn es Rechte begrenzt, echte Kundendaten ausschließt und Änderungen erst nach dokumentierter Freigabe zulässt.
Reproduzierbarkeit bewerten: Untersuche, warum zwei Builds trotz gleicher Programmfunktion unterschiedliche Prüfsummen haben können. Betrachte Quellbytes, Dateireihenfolge, Zeitstempel und Umgebung. Feedback: Eine fundierte Analyse unterscheidet funktionale Gleichheit von byteidentischen Artefakten und benennt kontrollierbare Einflussgrößen.

Lernkontrolle

Bearbeite die folgenden Aufgaben anhand des lokalen Ausbildungsfalls. Begründe Deine Entscheidungen; reine Definitionen reichen nicht aus.

Fehler trotz grüner Pipeline: Alle sechs Modultests bestehen. Eine neu geplante Benutzeroberfläche verarbeitet Eingaben jedoch falsch. Erkläre, warum das möglich ist, und entwickle eine zusätzliche Teststrategie.
Fehlerhafter Ablauf: Ein Team erstellt das ZIP-Paket bereits vor der Ausführung der Tests. Bewerte die Risiken und entwirf eine verbesserte Reihenfolge mit nachvollziehbarer Freigabeentscheidung.
Unterschiedliche Prüfsummen: Zwei Lernende erzeugen mit scheinbar identischem Code unterschiedliche ZIP-Dateien. Entwickle einen Untersuchungsplan, mit dem die Ursache eingegrenzt werden kann.
Neue Anforderung: Die fiktive Prioritätsregel soll bei zusätzlichen Sonderfällen anders entscheiden. Erkläre, welche bestehenden Tests angepasst werden müssen, welche neuen Tests erforderlich sind und warum die fachliche Regel vorher geklärt werden muss.
Sicherer Transfer: Die Schulleitung möchte das Labor später im Ausbildungsnetz verwenden. Entwirf ein Stufenkonzept von der lokalen Übung zur autorisierten Integration, einschließlich Testdaten, Verantwortlichkeiten, Sicherheitsprüfungen und Freigabe.

Bewertungsmaßstab: Gute Antworten verbinden eine fachlich richtige Begründung mit einem überprüfbaren Vorschlag. Besonders wichtig sind sichere Grenzen, nachvollziehbare Qualitätskriterien, realistische Fehlerannahmen und eine klare Trennung zwischen Labor und Produktivbetrieb.

Lernnachweis

Für Deinen Lernnachweis erstellst Du eine kompakte Dokumentation Deines eigenen lokalen Ausbildungsprojekts.

Ausgangslage: Beschreibe den fiktiven Auftrag und die Prioritätsregel.
Quellcode: Reiche die fünf selbst angelegten Python-Dateien ein.
Automatische Tests: Dokumentiere einen erfolgreichen Durchlauf mit sechs Tests.
Fehlernachweis: Zeige einen absichtlich fehlgeschlagenen Grenzwerttest und erläutere die Ursache.
Korrektur: Dokumentiere den anschließend wieder erfolgreichen Testlauf.
Build-Ergebnis: Weise nach, dass zwei unveränderte Builds dieselbe SHA-256-Prüfsumme besitzen.
Datenvisualisierung: Stelle die drei Testläufe grafisch dar.
Sicherheitsreflexion: Erkläre, warum die lokale Übungsumgebung keine Freigabe für Tests an fremden oder produktiven Systemen darstellt.
Transfer: Begründe, welche weiteren Prüfungen für eine echte Softwarefreigabe erforderlich wären.

Abschlusskriterium: Der Lernnachweis ist vollständig, wenn der Code lokal ausführbar ist, die Testergebnisse überprüft werden können, die Fehlerbehandlung funktioniert und die Entscheidungen fachlich begründet werden.

OERs zum Thema

Wikipedia: Kontinuierliche Integration

Weitere fachliche Grundlagen:

Wikipedia: CI/CD – Begriffe und Abgrenzung.
Wikipedia: Modultest – Grundlagen isolierter Funktionstests.
Python-Dokumentation: unittest – Testfälle, Assertions und automatische Testerkennung.
Python-Dokumentation: venv – Virtuelle Python-Umgebungen.
Python-Dokumentation: py_compile – Syntaxprüfung und Python-Bytecode.
Python-Dokumentation: zipfile – ZIP-Archive und Archivmetadaten.
Python-Dokumentation: hashlib – SHA-256 und andere Hashverfahren.
Reproducible Builds: Timestamps – Zeitstempel als Ursache nicht reproduzierbarer Builds.
Reproducible Builds: Archive Metadata – Ordnung, Rechte und Metadaten in Archiven.

Medienrechte und Nutzungshinweise

Die eingebundenen Wikimedia-Commons-Abbildungen besitzen auf ihren jeweils verlinkten Beschreibungsseiten ausgewiesene Creative-Commons-Lizenzen. Urheber und Lizenzversion sind direkt unter den Bildern angegeben. Bei Weiterverwendung musst Du die jeweiligen Bedingungen zu Namensnennung, Lizenzlink und gegebenenfalls Weitergabe unter gleichen Bedingungen beachten.

Die drei eingebundenen YouTube-Videos wurden als existierende Fachvideos geprüft. Eine freie Nachnutzungslizenz wird für diese Videos hier nicht zugesichert. Deshalb dienen sie nur als eingebettete Lernmedien; sie dürfen nicht ohne entsprechende Rechte kopiert, verändert oder neu veröffentlicht werden.

Datenschutzhinweis: YouTube, Wikipedia und LearningApps sind externe Angebote. Beim Laden eingebetteter Medien oder iFrames können technische Verbindungsdaten an deren Anbieter übertragen werden. Beachte die Datenschutzvorgaben Deiner Bildungseinrichtung. Für einen vollständig netzwerkfreien Unterricht verwende ausschließlich die lokalen Python-Beispiele und ersetze externe Einbettungen durch von der Bildungseinrichtung freigegebene Materialien.

Alle dargestellten Test- und Ticketdaten sind fiktiv. Die Python-Programme verwenden ausschließlich lokale Dateien und benötigen weder Cloud-Konten noch fremde Dienste.