12-Blackbox-Test, Glass-Box-Test

Möglichst viele Fehler mit möglichst wenigen Testfällen zu finden.

Repräsentativ/ Fehler-sensitiv/ frei von Redundanz.

Äquivalenzklassen/ Extremfälle/ Randfälle.

Gruppe von Eingaben, die dasselbe Verhalten im SuT (System under Test) auslösen und daher durch einen repräsentativen Testfall abgedeckt werden.

Weil alle Eingaben der Klasse voraussichtlich dieselben Fehler aufdecken würden.

Testen mit extrem großen oder extrem kleinen Eingabewerten, da hier oft Fehler auftreten.

Testen an den spezifizierten Grenzen von Eingaben, inkl. einem Wert darunter und einem darüber.

Immer Grenzwert selbst/ Grenzwert-1/ Grenzwert+1 testen.

Viele Fehler treten genau an Grenzen oder bei unerwartet großen/kleinen Eingaben auf.

Einflussfaktoren identifizieren/ fehlende Informationen der Entwickler benennen/ beobachtete Abweichungen und Fehler dokumentieren.

Testen ohne Einsicht in den Code, nur basierend auf Anforderungen und Spezifikationen.

Sobald eine (annähernd fertige) Spezifikation (SRS) vorliegt.

Alle Funktionen ausführen/ alle Eingabeklassen prüfen/ alle spezifizierten Reaktionen und Fehlerbehandlungen auslösen/ System bis an die spezifizierten Grenzen belasten.

Use Cases liefern abstraktes Verhalten/ daraus werden konkrete Eingaben, Ausgaben und Alternativszenarien zu Testfällen gemacht.

Auch Alternativabläufe und Fehlersituationen müssen geprüft werden.

Zustandsautomat erstellen/ jeden Zustand erreichen/ Übergänge testen/ Bedingungen für Zustandswechsel prüfen.

Airbag nur bei >15 km/h/ nur wenn Geschwindigkeitsdifferenz >12 km/h/ Fehlerhafte Daten → Fehlermeldung/ Reaktionszeit <0.23s.

Testen mit Einsicht in den Code – alle Anweisungen, Zweige, Methoden und Terme sollen durchlaufen werden.

Vollständige Abdeckung von Codepfaden, Zweigen und Bedingungen.

Prozentsatz, wie viel des definierten Testkriteriums (Code, Zustände, Use Cases, Eingaben) durch Tests abgedeckt ist.

Use Cases → abgedeckte Use Cases

Zustände → getestete Zustände & Transitionen

Black-Box → getestete Eingabedaten

Glass-Box → ausgeführte Statements, Zweige, Funktionen, Terme.

Prozentsatz der tatsächlich ausgeführten Codezeilen.

Prozentsatz der getesteten Verzweigungen (if/else, Schleifen).

Spezielle Coverage-Tools für C/ für Java z. B. Jacoco.

Quellcode analysieren und zusätzliche Testfälle vorschlagen, um maximale Coverage zu erreichen.

Welcher Anteil eines gewählten Testkriteriums (Code, Zustände, Use Cases etc.) durch die Tests geprüft wurde.

Beste: maximal 95%, falls sie disjunkte Bereiche abdecken/ Schlechteste: 40%, wenn alle dieselben Stellen abdecken.

Prüfen, ob die Randbedingungen exakt dieselben sind (Hardware, OS, Input-Daten)/ Prüfen, ob Testschritte korrekt dokumentiert wurden/ Einflussfaktoren wie Timing oder externe Systeme analysieren/ Feedback an Entwickler mit exakter Beschreibung von Abweichungen geben.

Airbag darf sich nur öffnen, wenn Geschwindigkeit >15 km/h UND Differenz zwischen zwei Messungen >12 km/h/ Bei fehlerhaften oder widersprüchlichen Sensordaten → Fehlermeldung statt Auslösung/ Maximale Auslösezeit 0.23s/ Tests müssen Normalfall, Grenzwerte (z. B. 14 km/h, 15 km/h, 16 km/h) und fehlerhafte Daten abdecken.

Quellcode untersuchen, ob alle Bedingungen und Zweige abgedeckt sind/ Zusätzliche Testfälle für „Grenze = genau 15 km/h“ und „Differenz = genau 12 km/h“ entwickeln/ Negativtests entwerfen (falsche Sensorwerte, Nullwerte)/ Prüfen, ob auch else-Zweige und Ausnahmebehandlungen im Code getestet werden.