Einordnung: Diese Seite ordnet die Testverfahren aus CTFL Kap. 4 den Hausaufgaben (HA) des Curriculums zu. Pro Verfahren: Kapitel, Kategorie, Testmodell, Ergebnis der Testanalyse, HA-Referenz, Werkzeuge in der Praxis und Kontext. Die Farben kennzeichnen Black-Box (4.2), White-Box (4.3) und kollaborative Ansätze (4.5).
Zuordnung Testverfahren ↔ Hausaufgaben
| Kapitel | Kategorie | Testverfahren | Testmodell | Ergebnis der Testanalyse | HA | Werkzeuge in der Praxis | Kontext & Einbettung |
|---|---|---|---|---|---|---|---|
| 4.2.1 | Black-Box | Equivalence Partitioning Äquivalenzklassenbildung | Partitionierung des Eingaberaums in gültige & ungültige Klassen | Äquivalenzklassentabelle | HA 1 T1 | Excel / Google Sheets TestRail Jira + Xray Azure DevOps | Grundlage jedes funktionalen Tests. Rückverfolgbarkeit zur Anforderung (Testbasis) notwendig. In agilen Teams oft direkt aus Akzeptanzkriterien abgeleitet. |
| 4.2.2 | Black-Box | Boundary Value Analysis Grenzwertanalyse | Intervalle & Grenzwerte (2-wertig oder 3-wertig) | Grenzwerttabelle (Testfallspezifikation) | HA 1 T2/T3 | Excel / Google Sheets TestRail Jira + Xray | Ergänzt immer die Äquivalenzklassenbildung. 2-wertig (FL-Standard); 3-wertig für höhere Überdeckung. Besonders relevant bei numerischen Eingabefeldern & Formularvalidierungen. |
| 4.2.3 | Black-Box | Decision Table Testing Entscheidungstabellentest | Kombination aller Bedingungen & Aktionen | Entscheidungstabelle | HA 2 | Excel / Confluence TestRail Jira + Xray | Ideal für Geschäftsregeln mit mehreren Bedingungen. In regulierten Branchen (Banken, Versicherungen) häufig Pflicht. Reduziert Kombinationsexplosion systematisch. |
| 4.2.4 | Black-Box | State Transition Testing Zustandsübergangstest | Zustandsübergangsdiagramm (gerichteter Graph) | Zustandsübergangstabelle | HA 3 T1 | draw.io / Lucidchart UML-Tools Confluence TestRail | Für zustandsabhängige Systeme: Login-Flows, Bestellprozesse, Automaten. Diagramm als Kommunikationsmittel mit Entwicklung & Produktmanagement. |
| 4.3.1 | White-Box | Statement Testing Anweisungstest | Kontrollflussgraph (KFG) | Überdeckungsanalyse (Anweisungsüberdeckung) | HA 3 T2 | SonarQube JaCoCo (Java) Coverage.py Istanbul / nyc (JS) | Wird oft durch CI/CD-Pipelines automatisch gemessen. Schwellenwert (z.B. 80 % Überdeckung) als Quality Gate. Schwächstes White-Box-Kriterium — notwendig, aber nicht hinreichend. |
| 4.3.2 | White-Box | Branch Testing Zweigtest | Kontrollflussgraph (KFG) | Überdeckungsanalyse (Zweigüberdeckung) | HA 3 T2 | SonarQube JaCoCo (Java) Coverage.py Istanbul / nyc (JS) | Stärker als Anweisungstest: jeder Entscheidungspfad wird geprüft. Zweigüberdeckung schließt Anweisungsüberdeckung ein. Standard in professionellen Projekten & regulierten Umgebungen. |
| 4.2.2 + 4.5.3 | BB + Kollab. | BVA in ATDD context Grenzwertanalyse im ATDD-Ansatz | User Story + Grenzwerte (Intervallpartition) | Testfälle aus Akzeptanzkriterien + BVA | HA 1 T4 | Jira + Confluence Cucumber / Gherkin Excel | Einzige HA, die zwei Verfahren kombiniert. BVA (4.2.2) wird auf eine User Story angewendet — eingebettet in den ATDD-Ansatz (4.5.3). Zeigt wie Grenzwertanalyse direkt aus Akzeptanzkriterien abgeleitet wird. Shift-Left in der Praxis: Testfalldenken beginnt bei der Anforderung. |
| 4.5.3 | Kollaborativ | ATDD Abnahmetestgetriebene Entwicklung | User Stories + Akzeptanzkriterien | Testfallspezifikation (aus Akzeptanzkriterien) | HA 4 | Cucumber / Gherkin SpecFlow (.NET) Jira + Confluence Notion | Neu in CTFL 4.0. Testen beginnt bei der Anforderung — nicht beim Code. Verzahnt Product Owner, Entwicklung & Test von Beginn an. Shift-Left-Prinzip in der Praxis. Gherkin-Syntax (Given / When / Then) als Industriestandard. |