mindflux/src/main/resources/static/finalflux/questions/ap2_fiae_testverfahren.json

{
  "title": "Testverfahren",
  "questions": [
    {
      "category": "Blackbox vs. Whitebox",
      "hint": "Ohne Blick in den Code.",
      "text": "Aus welcher Perspektive betrachtest du das Testobjekt beim Blackbox-Test?",
      "answers": [
        "Nur über Eingaben und erwartete Ausgaben, ohne den internen Quellcode zu kennen.",
        "Anhand des internen Quellcodes, um jeden Programmpfad gezielt abzudecken.",
        "Ausschließlich über die Analyse der Datenbankstruktur im Hintergrund."
      ],
      "correct": 0,
      "explanation": "Der Blackbox-Test prüft das Verhalten allein über die Schnittstelle: Eingabe rein, Ausgabe mit der Spezifikation vergleichen, ohne die innere Struktur zu kennen. Das gezielte Abdecken von Programmpfaden anhand des Quellcodes ist der Whitebox-Ansatz, und die Datenbankstruktur allein ist kein Kriterium des Verfahrens."
    },
    {
      "category": "Blackbox vs. Whitebox",
      "hint": "Kenntnis des Codes nutzen.",
      "text": "Welche Technik ist typisch für den Whitebox-Test?",
      "answers": [
        "Grenzwertanalyse rein anhand der fachlichen Spezifikation.",
        "Zweig- und Pfadabdeckung anhand des Programmablaufs im Quellcode.",
        "Abnahme durch den Kunden anhand der vereinbarten Anforderungen."
      ],
      "correct": 1,
      "explanation": "Whitebox nutzt die Kenntnis des Codes, um den Kontrollfluss abzudecken, etwa über Anweisungs-, Zweig- und Pfadüberdeckung. Die Grenzwertanalyse aus der Spezifikation gehört zum Blackbox-Test, und die Kundenabnahme ist eine Testebene und kein Verfahren der Codeüberdeckung."
    },
    {
      "category": "Blackbox vs. Whitebox",
      "hint": "Nicht erreichter Code.",
      "text": "Warum kann ein reiner Blackbox-Test bestimmte Fehler übersehen?",
      "answers": [
        "Weil er den kompletten Quellcode Zeile für Zeile prüft und dabei ermüdet.",
        "Weil er ausschließlich die Datenbank und nie die Programmlogik testet.",
        "Weil nicht durchlaufener oder toter Code ohne Blick in die Struktur unentdeckt bleiben kann."
      ],
      "correct": 2,
      "explanation": "Ohne Kenntnis der inneren Struktur erkennt der Blackbox-Test nicht, ob es nie erreichten oder toten Code gibt; solche Lücken deckt erst eine Codeüberdeckung per Whitebox auf. Der Blackbox-Test liest den Quellcode gerade nicht und beschränkt sich auch nicht auf die Datenbank."
    },
    {
      "category": "Blackbox vs. Whitebox",
      "hint": "Nur die Spezifikation liegt vor.",
      "text": "Ein Tester kennt nur die Anforderungsspezifikation, nicht die Implementierung, und leitet daraus die Testfälle ab. Um welches Verfahren handelt es sich?",
      "answers": [
        "Blackbox-Test.",
        "Whitebox-Test.",
        "Anweisungsüberdeckung."
      ],
      "correct": 0,
      "explanation": "Testfälle allein aus der Spezifikation ohne Blick in die Implementierung kennzeichnen den Blackbox-Test. Whitebox setzt gerade die Codekenntnis voraus, und die Anweisungsüberdeckung ist eine konkrete Whitebox-Metrik, die den Quellcode benötigt."
    },
    {
      "category": "Äquivalenzklassen & Grenzwerte",
      "hint": "Repräsentant je Klasse.",
      "text": "Was ist die Grundidee der Äquivalenzklassenbildung?",
      "answers": [
        "Für jeden einzelnen möglichen Eingabewert genau einen Testfall zu schreiben.",
        "Eingaben in Klassen zusammenzufassen, die vermutlich gleich behandelt werden, und je Klasse einen Repräsentanten zu testen.",
        "Nur ungültige Eingaben zu testen, weil gültige ohnehin funktionieren."
      ],
      "correct": 1,
      "explanation": "Äquivalenzklassen fassen Eingaben zusammen, die das Programm voraussichtlich gleich verarbeitet; getestet wird ein Repräsentant je Klasse, was die Zahl der Testfälle stark senkt. Jeden Wert einzeln zu prüfen wäre unpraktikabel, und gültige Klassen müssen ebenso getestet werden wie ungültige."
    },
    {
      "category": "Äquivalenzklassen & Grenzwerte",
      "hint": "Gültige und ungültige Bereiche.",
      "text": "Für ein Alter-Feld gilt: gültig ist 18 bis 65. Welche Aufteilung in Äquivalenzklassen ist korrekt?",
      "answers": [
        "Nur eine gültige Klasse von 18 bis 65, ungültige Werte sind irrelevant.",
        "Drei gültige Klassen und gar keine ungültige Klasse.",
        "Eine gültige Klasse 18 bis 65 sowie zwei ungültige Klassen: kleiner als 18 und größer als 65."
      ],
      "correct": 2,
      "explanation": "Neben der gültigen Klasse von 18 bis 65 gehören auch die ungültigen Bereiche darunter und darüber getestet, denn gerade dort treten Fehler auf. Die ungültigen Eingaben zu ignorieren würde das fehlerhafte Verhalten ungeprüft lassen."
    },
    {
      "category": "Äquivalenzklassen & Grenzwerte",
      "hint": "Direkt an den Rändern.",
      "text": "Gültig ist ein Wert von 1 bis 100. Welche Werte prüft die Grenzwertanalyse besonders?",
      "answers": [
        "Die Ränder und ihre direkten Nachbarn, also 0, 1, 100 und 101.",
        "Nur den Mittelwert 50, weil er die Klasse repräsentiert.",
        "Ausschließlich weit entfernte Werte wie -1000 und 1000."
      ],
      "correct": 0,
      "explanation": "Fehler treten häufig an den Klassengrenzen auf, deshalb prüft die Grenzwertanalyse die Randwerte und ihre direkten Nachbarn, hier 0, 1, 100 und 101. Ein Wert aus der Mitte deckt typische Off-by-one-Fehler nicht ab, und sehr weit entfernte Werte liegen tief in der ungültigen Klasse statt an der Grenze."
    },
    {
      "category": "Äquivalenzklassen & Grenzwerte",
      "hint": "Off-by-one an den Rändern.",
      "text": "Warum ergänzt man die Äquivalenzklassen sinnvollerweise um eine Grenzwertanalyse?",
      "answers": [
        "Weil die Grenzwertanalyse die Äquivalenzklassen vollständig ersetzt.",
        "Weil Fehler besonders oft an den Klassengrenzen entstehen, etwa durch < statt <=.",
        "Weil dadurch jeder einzelne Wert des gesamten Wertebereichs getestet wird."
      ],
      "correct": 1,
      "explanation": "Verwechslungen wie < statt <= führen zu typischen Fehlern genau an den Rändern, die ein Repräsentant aus der Klassenmitte übersieht; deshalb ergänzen Grenzwerte die Klassenbildung. Sie ersetzen die Klassen nicht und prüfen auch nicht jeden Einzelwert des Bereichs."
    },
    {
      "category": "Testebenen",
      "hint": "Kleinste Einheit isoliert.",
      "text": "Welche Testebene prüft eine einzelne Klasse oder Methode isoliert?",
      "answers": [
        "Der Systemtest.",
        "Der Abnahmetest.",
        "Der Unit-Test (Modul- bzw. Komponententest)."
      ],
      "correct": 2,
      "explanation": "Der Unit-Test prüft die kleinste Einheit, also eine Methode oder Klasse, isoliert und ersetzt Abhängigkeiten oft durch Mocks. Der Systemtest betrachtet das Gesamtsystem, und der Abnahmetest richtet sich nach der Erfüllung der Kundenanforderungen."
    },
    {
      "category": "Testebenen",
      "hint": "Zusammenspiel über Schnittstellen.",
      "text": "Worauf zielt der Integrationstest ab?",
      "answers": [
        "Auf das korrekte Zusammenspiel mehrerer Module über ihre Schnittstellen.",
        "Auf die interne Verzweigungslogik einer einzelnen Methode.",
        "Auf die formale Abnahme durch den Auftraggeber."
      ],
      "correct": 0,
      "explanation": "Der Integrationstest prüft, ob zuvor einzeln getestete Module über ihre Schnittstellen korrekt zusammenarbeiten. Die interne Logik einer einzelnen Methode ist Sache des Unit-Tests, und die formale Abnahme gehört zum Abnahmetest."
    },
    {
      "category": "Testebenen",
      "hint": "Vollständig integriert, produktionsnah.",
      "text": "In welcher Umgebung wird der Systemtest typischerweise durchgeführt?",
      "answers": [
        "In der Entwicklungsumgebung gegen einzelne Klassen.",
        "In einer produktionsnahen Umgebung gegen das vollständig integrierte Gesamtsystem.",
        "Direkt auf dem Produktivsystem der Kunden ohne jede Testdaten."
      ],
      "correct": 1,
      "explanation": "Der Systemtest prüft das vollständig integrierte System gegen die Anforderungen, möglichst in einer produktionsähnlichen Umgebung mit realistischen Testdaten. Einzelne Klassen sind Gegenstand des Unit-Tests, und ungeprüft auf dem Produktivsystem zu testen wäre riskant und untypisch."
    },
    {
      "category": "Testebenen",
      "hint": "Sicht des Auftraggebers.",
      "text": "Wer führt den Abnahmetest primär durch und wogegen wird geprüft?",
      "answers": [
        "Die Entwickler, gegen die interne Codestruktur.",
        "Ein Automatisierungsserver, gegen die erreichte Testabdeckung.",
        "Der Auftraggeber bzw. Fachbereich, gegen die vertraglich vereinbarten Anforderungen."
      ],
      "correct": 2,
      "explanation": "Der Abnahmetest wird aus Sicht des Auftraggebers gegen die vereinbarten Anforderungen durchgeführt und entscheidet über die Freigabe. Die interne Codestruktur prüfen Whitebox-Verfahren, und eine Kennzahl wie die Testabdeckung ist kein fachliches Abnahmekriterium."
    },
    {
      "category": "Testarten & Vorgehen",
      "hint": "Nach Änderung nichts kaputt?",
      "text": "Was ist das Ziel eines Regressionstests?",
      "answers": [
        "Sicherzustellen, dass bereits funktionierende Features nach einer Änderung weiterhin korrekt arbeiten.",
        "Ausschließlich neu geschriebene Funktionen zum ersten Mal zu testen.",
        "Die Ausführungsgeschwindigkeit des Systems unter hoher Last zu messen."
      ],
      "correct": 0,
      "explanation": "Der Regressionstest wiederholt bestehende Testfälle nach Änderungen, um zu erkennen, ob zuvor korrekte Funktionen ungewollt beschädigt wurden. Das erstmalige Prüfen neuer Funktionen ist nicht sein Ziel, und die Messung von Geschwindigkeit unter Last ist ein eigener Last-/Performancetest."
    },
    {
      "category": "Testarten & Vorgehen",
      "hint": "Red, Green, Refactor.",
      "text": "Welche Reihenfolge beschreibt Test-Driven Development (TDD) korrekt?",
      "answers": [
        "Erst die Funktion vollständig implementieren und ganz am Ende die Tests schreiben.",
        "Erst einen fehlschlagenden Test schreiben, dann den Code bis zum grünen Test implementieren, danach refactoren.",
        "Auf Tests verzichten und die Anwendung nur manuell durchklicken."
      ],
      "correct": 1,
      "explanation": "TDD folgt dem Zyklus Red-Green-Refactor: zuerst ein Test, der fehlschlägt, dann minimaler Code, der ihn erfüllt, danach das Aufräumen bei weiterhin grünen Tests. Tests erst nachträglich oder gar nicht zu schreiben widerspricht dem testgetriebenen Ansatz."
    },
    {
      "category": "Testarten & Vorgehen",
      "hint": "Ohne Soll kein Urteil.",
      "text": "Was gehört zu einem vollständig beschriebenen Testfall zwingend dazu?",
      "answers": [
        "Nur eine kurze Beschreibung, was ungefähr getestet werden soll.",
        "Ausschließlich die konkreten Eingabewerte.",
        "Vorbedingung, Eingabe bzw. Aktion, erwartetes Ergebnis und der Vergleich mit dem Ist-Ergebnis."
      ],
      "correct": 2,
      "explanation": "Ein aussagekräftiger Testfall nennt die Vorbedingungen, die konkrete Eingabe oder Aktion und vor allem das erwartete Ergebnis, gegen das das tatsächliche Ergebnis geprüft wird. Ohne definiertes Soll-Ergebnis lässt sich nicht objektiv über Bestehen oder Fehlschlag entscheiden."
    },
    {
      "category": "Testarten & Vorgehen",
      "hint": "Schnell und reproduzierbar.",
      "text": "Welcher Vorteil spricht besonders für automatisierte Tests?",
      "answers": [
        "Sie lassen sich schnell und reproduzierbar beliebig oft wiederholen, ideal für Regression und Continuous Integration.",
        "Sie machen den fachlichen Testfallentwurf und das Nachdenken über Testfälle überflüssig.",
        "Sie garantieren mathematisch, dass überhaupt keine Fehler mehr vorhanden sind."
      ],
      "correct": 0,
      "explanation": "Automatisierte Tests laufen schnell und immer gleich, sodass sie sich für häufige Regressionsläufe und Continuous Integration eignen. Sie ersetzen aber nicht den fachlichen Testentwurf und können Fehlerfreiheit nicht beweisen, denn ein bestandener Test zeigt nur die Abwesenheit der geprüften Fehler."
    },
    {
      "category": "Schnittstellen & Datenformate",
      "hint": "Neue Ressource erzeugen.",
      "text": "Welche HTTP-Methode ist bei REST für das Anlegen einer neuen Ressource üblich?",
      "answers": [
        "GET",
        "POST",
        "DELETE"
      ],
      "correct": 1,
      "explanation": "POST legt bei REST typischerweise eine neue Ressource an und wird meist mit dem Statuscode 201 Created bestätigt. GET liest nur ohne Seiteneffekt, und DELETE entfernt eine bestehende Ressource."
    },
    {
      "category": "Schnittstellen & Datenformate",
      "hint": "Ressource existiert nicht.",
      "text": "Ein REST-Client fragt eine Ressource ab, die es nicht gibt. Welcher HTTP-Statuscode ist korrekt?",
      "answers": [
        "200 OK",
        "500 Internal Server Error",
        "404 Not Found"
      ],
      "correct": 2,
      "explanation": "Der Code 404 Not Found signalisiert, dass die angeforderte Ressource nicht existiert. Der Code 200 OK meldet dagegen Erfolg, und 500 steht für einen unerwarteten Serverfehler und nicht für eine schlicht fehlende Ressource."
    },
    {
      "category": "Schnittstellen & Datenformate",
      "hint": "Ohne gespeicherten Sitzungszustand.",
      "text": "Welche Aussage beschreibt ein zentrales REST-Prinzip korrekt?",
      "answers": [
        "Die Kommunikation ist zustandslos: jede Anfrage enthält alle nötigen Informationen, der Server hält keinen Sitzungszustand.",
        "Der Server merkt sich zwischen den Anfragen automatisch den kompletten Zustand des Clients.",
        "Jede Operation muss zwingend über die Methode GET laufen."
      ],
      "correct": 0,
      "explanation": "REST ist zustandslos: jede Anfrage trägt alle Informationen, die der Server zur Bearbeitung braucht, ohne gespeicherten Sitzungszustand. Serverseitig gehaltener Sitzungszustand widerspricht dem Prinzip, und je nach Operation kommen unterschiedliche Methoden wie GET, POST, PUT oder DELETE zum Einsatz."
    },
    {
      "category": "Schnittstellen & Datenformate",
      "hint": "Beide textbasiert.",
      "text": "Worin unterscheiden sich JSON und XML als Datenformat?",
      "answers": [
        "JSON ist ein Bildformat, während XML ein reines Textformat ist.",
        "Beide sind textbasiert; JSON ist meist kompakter, XML unterstützt zusätzlich Attribute, Namespaces und Schema-Validierung.",
        "Nur XML ist maschinenlesbar, JSON kann ausschließlich ein Mensch lesen."
      ],
      "correct": 1,
      "explanation": "JSON und XML sind beide textbasiert und maschinenlesbar; JSON ist in der Regel kompakter und in Web-APIs verbreitet, während XML mit Attributen, Namespaces und Schemata wie XSD mehr Struktur bietet. JSON ist kein Bildformat, und maschinenlesbar sind beide Formate."
    }
  ]
}