mindflux/src/main/resources/static/finalflux/ap2-fiae/testverfahren.html

<!DOCTYPE html>
<html lang="de" data-theme="dark">
<head>
  <meta charset="UTF-8">
  <title>Testverfahren - FinalProtocol AP2</title>
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <link rel="stylesheet" href="/css/style.css">
  <link rel="stylesheet" href="/css/theme.css?v=4">
  <link rel="stylesheet" href="/css/finalflux.css">
  <script src="/js/theme.js?v=5"></script>
</head>
<body class="finalflux-page">
<div class="mf-theme-float"><button class="mf-theme"></button></div>
<main>
  <a href="/finalflux" class="back-link">Zurück zu FinalProtocol</a>
  <h1>Testverfahren</h1>

  <section>
    <h2>Lernfokus</h2>
    <p>AP2 Anwendungsentwicklung: Testfälle systematisch entwerfen, Tests auf der richtigen Ebene einordnen und Schnittstellen mit passenden HTTP-Statuscodes und Datenformaten prüfen.</p>
    <ul class="key-list">
      <li>Blackbox- und Whitebox-Test sicher voneinander unterscheiden.</li>
      <li>Äquivalenzklassen bilden und mit der Grenzwertanalyse ergänzen.</li>
      <li>Testebenen, Testarten und REST-Grundlagen einordnen.</li>
    </ul>
  </section>

  <section>
    <h2>Blackbox &amp; Whitebox</h2>
    <p>Beide Verfahren unterscheiden sich vor allem darin, ob der Tester den inneren Quellcode kennt.</p>
    <ul class="key-list">
      <li><strong>Blackbox:</strong> ohne Kenntnis des Codes – getestet wird über Eingabe und Ausgabe gegen die Spezifikation (z. B. Äquivalenzklassen, Grenzwerte).</li>
      <li><strong>Whitebox:</strong> mit Kenntnis des Codes – gezielte Abdeckung von Anweisungen, Zweigen und Pfaden im Programmablauf.</li>
      <li><strong>Grenze:</strong> nur Whitebox findet nie durchlaufenen oder toten Code, nur Blackbox denkt konsequent aus Nutzersicht.</li>
    </ul>
    <p class="merksatz"><strong>Merksatz:</strong> Blackbox schaut auf das Verhalten, Whitebox in den Code.</p>
  </section>

  <section>
    <h2>Äquivalenzklassen &amp; Grenzwerte</h2>
    <p>Statt jeden Wert einzeln zu testen, fasst man Eingaben zu Klassen zusammen und prüft je einen Repräsentanten.</p>
    <ul class="key-list">
      <li><strong>Gültige und ungültige Klassen:</strong> zu jedem Wertebereich gehören mindestens eine gültige Klasse und die ungültigen Bereiche darunter und darüber.</li>
      <li><strong>Grenzwertanalyse:</strong> prüft die Ränder und ihre direkten Nachbarn – bei 1 bis 100 also 0, 1, 100 und 101.</li>
      <li><strong>Warum:</strong> typische Fehler wie <code>&lt;</code> statt <code>&lt;=</code> zeigen sich genau an den Grenzen.</li>
    </ul>
    <p class="merksatz"><strong>Merksatz:</strong> Ein Repräsentant je Klasse plus die Werte direkt an den Rändern.</p>
  </section>

  <section>
    <h2>Testebenen</h2>
    <p>Tests bauen von der kleinsten Einheit bis zum Gesamtsystem aufeinander auf.</p>
    <ul class="key-list">
      <li><strong>Unit-Test:</strong> einzelne Klasse oder Methode isoliert, oft mit Mocks.</li>
      <li><strong>Integrationstest:</strong> Zusammenspiel mehrerer Module über ihre Schnittstellen.</li>
      <li><strong>Systemtest:</strong> vollständig integriertes System in produktionsnaher Umgebung.</li>
      <li><strong>Abnahmetest:</strong> Auftraggeber prüft gegen die vereinbarten Anforderungen und gibt frei.</li>
    </ul>
    <p class="merksatz"><strong>Merksatz:</strong> Unit klein, Integration zwischen den Teilen, System als Ganzes, Abnahme für den Kunden.</p>
  </section>

  <section>
    <h2>Testarten &amp; Schnittstellen</h2>
    <p>Neben den Ebenen zählen das Vorgehen und die geprüften Schnittstellen.</p>
    <ul class="key-list">
      <li><strong>Regressionstest:</strong> stellt sicher, dass Bestehendes nach einer Änderung weiter funktioniert – ideal automatisiert für Continuous Integration.</li>
      <li><strong>TDD:</strong> Red-Green-Refactor – erst der fehlschlagende Test, dann der Code, dann das Aufräumen.</li>
      <li><strong>REST-Statuscodes:</strong> 200 OK, 201 Created (nach POST), 400 Bad Request, 404 Not Found, 500 Internal Server Error.</li>
      <li><strong>JSON vs. XML:</strong> beide textbasiert und maschinenlesbar; JSON meist kompakter, XML mit Attributen, Namespaces und Schema.</li>
    </ul>
    <p class="merksatz"><strong>Merksatz:</strong> Ein bestandener Test beweist keine Fehlerfreiheit, nur die Abwesenheit der geprüften Fehler.</p>
  </section>

  <section>
    <h2>Prüfungsmodus</h2>
    <p>Dieser ProtocolCheck führt dich durch die wichtigsten AP2-Aspekte dieses Themas. Du kannst Antworten prüfen, Fragen überspringen und bekommst am Ende eine Auswertung nach Kategorie.</p>
  </section>

  <section class="finalflux-test" data-finalflux-test aria-live="polite">
    <div class="test-meta">
      <span data-question-counter>Frage 1</span>
      <span data-score-counter>0 richtig</span>
    </div>
    <div class="category-block">
      <p class="eyebrow">Kategorie</p>
      <h2 data-category-title>Testverfahren</h2>
      <p data-category-hint>AP2-Training</p>
    </div>
    <div class="question-card">
      <h3 data-question-text></h3>
      <div data-answer-options class="answer-options"></div>
      <div data-answer-feedback class="fluxcheck-result"></div>
    </div>
    <div class="test-actions">
      <button type="button" data-check-answer>Antwort prüfen</button>
      <button type="button" data-skip-question class="secondary">Überspringen</button>
      <button type="button" data-next-question class="secondary" disabled>Weiter</button>
    </div>
  </section>

  <section data-test-result class="finalflux-panel" hidden>
    <h2>Auswertung</h2>
    <p data-result-summary></p>
    <ul data-category-summary class="key-list"></ul>
    <div class="finalflux-actions">
      <button type="button" data-restart-test>Test neu starten</button>
      <a href="/finalflux">Zurück zur Übersicht</a>
    </div>
  </section>
</main>

<script src="/js/finalflux-test.js" data-questions-src="/finalflux/questions/ap2_fiae_testverfahren.json" defer></script>
</body>
</html>