Was ist das Ziel bei der Auswahl von Testfällen? (S.6)
Möglichst viele Fehler mit möglichst wenigen Testfällen zu finden.
Welche Eigenschaften hat ein idealer Testfall? (S.6)
Repräsentativ/ Fehler-sensitiv/ frei von Redundanz.
Welche Aspekte sind beim Entwurf von Testfällen zu beachten? (S.7)
Äquivalenzklassen/ Extremfälle/ Randfälle.
Was ist eine Äquivalenzklasse im Testing? (S.8)
Gruppe von Eingaben, die dasselbe Verhalten im SuT (System under Test) auslösen und daher durch einen repräsentativen Testfall abgedeckt werden.
Warum wählt man pro Äquivalenzklasse nur einen Repräsentanten? (S.8)
Weil alle Eingaben der Klasse voraussichtlich dieselben Fehler aufdecken würden.
Was sind Extremfälle? (S.9)
Testen mit extrem großen oder extrem kleinen Eingabewerten, da hier oft Fehler auftreten.
Was sind Randfälle? (S.9)
Testen an den spezifizierten Grenzen von Eingaben, inkl. einem Wert darunter und einem darüber.
Welche Regel gilt bei Randfalltests? (S.9)
Immer Grenzwert selbst/ Grenzwert-1/ Grenzwert+1 testen.
Warum sind Extrem- und Randfälle wichtig? (S.9)
Viele Fehler treten genau an Grenzen oder bei unerwartet großen/kleinen Eingaben auf.
Übung: Was sollte man bei einem fehlgeschlagenen Reproduktionsversuch analysieren? (S.13)
Einflussfaktoren identifizieren/ fehlende Informationen der Entwickler benennen/ beobachtete Abweichungen und Fehler dokumentieren.
Was ist Black-Box-Testing? (S.15)
Testen ohne Einsicht in den Code, nur basierend auf Anforderungen und Spezifikationen.
Wann kann man Black-Box-Tests entwerfen? (S.15)
Sobald eine (annähernd fertige) Spezifikation (SRS) vorliegt.
Was sind die Ziele von Black-Box-Testing? (S.16)
Alle Funktionen ausführen/ alle Eingabeklassen prüfen/ alle spezifizierten Reaktionen und Fehlerbehandlungen auslösen/ System bis an die spezifizierten Grenzen belasten.
Wie werden Testfälle aus Use Cases abgeleitet? (S.17)
Use Cases liefern abstraktes Verhalten/ daraus werden konkrete Eingaben, Ausgaben und Alternativszenarien zu Testfällen gemacht.
Warum sollen Testfälle nicht nur Normalfälle abdecken? (S.17)
Auch Alternativabläufe und Fehlersituationen müssen geprüft werden.
Wie werden Testfälle aus Systemzuständen abgeleitet? (S.18)
Zustandsautomat erstellen/ jeden Zustand erreichen/ Übergänge testen/ Bedingungen für Zustandswechsel prüfen.
Übung: Was sind die Anforderungen für ein Airbag-System im Black-Box-Test? (S.19)
Airbag nur bei >15 km/h/ nur wenn Geschwindigkeitsdifferenz >12 km/h/ Fehlerhafte Daten → Fehlermeldung/ Reaktionszeit <0.23s.
Was ist Glass-Box-Testing? (S.21)
Testen mit Einsicht in den Code – alle Anweisungen, Zweige, Methoden und Terme sollen durchlaufen werden.
Was ist das Ziel von Glass-Box-Testing? (S.21)
Vollständige Abdeckung von Codepfaden, Zweigen und Bedingungen.
Was versteht man unter Test-Coverage? (S.22)
Prozentsatz, wie viel des definierten Testkriteriums (Code, Zustände, Use Cases, Eingaben) durch Tests abgedeckt ist.
Welche Coverage-Kriterien gibt es? (S.22)
Use Cases → abgedeckte Use Cases
Zustände → getestete Zustände & Transitionen
Black-Box → getestete Eingabedaten
Glass-Box → ausgeführte Statements, Zweige, Funktionen, Terme.
Was ist Statement Coverage? (S.24)
Prozentsatz der tatsächlich ausgeführten Codezeilen.
Was ist Branch Coverage? (S.24)
Prozentsatz der getesteten Verzweigungen (if/else, Schleifen).
Welches Tool misst Coverage in C oder Java? (S.25)
Spezielle Coverage-Tools für C/ für Java z. B. Jacoco.
Übung: Was ist die Aufgabe im Glass-Box-Testing zur Airbag-Software? (S.26)
Quellcode analysieren und zusätzliche Testfälle vorschlagen, um maximale Coverage zu erreichen.
Wiederholung: Was drückt die Testabdeckung aus? (S.28)
Welcher Anteil eines gewählten Testkriteriums (Code, Zustände, Use Cases etc.) durch die Tests geprüft wurde.
Wiederholung: Gegeben drei Testfälle mit 30%, 40% und 25% Statement Coverage – was ist die beste und schlechteste Gesamt-Coverage? (S.28)
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.
Zuletzt geändertvor 2 Monaten
