Defekt | Nicht korrekter Code Beispiel: Schreibfehler in Formel Hinweis: Muss nicht immer zu einem Fehlzustand führen. |
Fehlzustand | Nicht korrekter Zustand (während der Laufzeit) Beispiel: Falsche Berechnung des Ergebnisses Voraussetzung: Defekt(e) |
Fehlfunktion | Nicht korrektes Verhalten (während der Laufzeit) Beispiel: Ausgabe von falschen Werten |
Fehler | Abweichung von Forderung gemäß Qualitätsmerkmalen? |
Testen | Existenz von Fehlern beweisen (nicht deren Abwesenheit). Genauer: Systematisch Fehlfunktionen heraufinden. |
formaler Beweis (Mathematik) | Zeigt Abwesenheit von Fehlern |
Testfall | Prüft mögliche Eingabe(n) |
Test-First-Ansatz | Erst die Tests entwickeln, dann das Programm schreiben |
Testsuite | Set aus vorgefertigten Programmtests |
weitergehende Analyse des ges. Programms (Dokumentation, Struktur, Quellcode etc.)
Kann etwas fehlendes nicht finden
Ziel: Endlosschleifen, falsche Variablen, Standardverletzungen etc. aufdecken
Beispiele: Audit, Review, Checklistenverfahren…
Programm wird während der Ausführung getestet.
Sog. Entwicklertest, die Datenstruktur wird angeschaut
Ablauf eines Programms (basierend auf Fällen) darstellen
Ziele für Zeile durchgehen (aufsteigend nummerieren + Start- und Endknoten festlegen), Knoten und Kanten (alle Möglichgkeiten abbilden).
ähnlich dem Aktivitätsdiagramm (dies ist nicht immer umfassend und hat mehr Beschreibungen). Wird oft als das selbe bezeichnet.
Einmal alle Knoten ablaufen.
Schwierigkeit: Geht Programm in alle Bedingungen (IF) rein?
Beginn bei Start, möglichst alle Bedingungen abdecken. Reicht meist nicht als einziger Test aus.
Alle Wege (Zweige/Kanten) gehen.
Ist detaillierter -> geht öfters alles durch um alle Wege zu zu “decken”
geht nicht immer (z. B. wenn Dinge immer true sind)
Alle Möglichkeiten gehen, um zum Ziel zu kommen (es müssen nicht alle Elemente abgelaufen werden).
Ist am umfangreichsten, enthält Zweigüberdeckung.
geht nicht immer (z. B. wenn Dinge immer true sind) -> In Praxis werden nur Teile getestet
Sog. Anwendertest
Testen ohne den Quellcode einsehen zu können. Benötigt eine lauffähige Implementation des Programmes
Test der einzelnen Softwareteile, welche erst später zusammengeführt werden. Möglichst kleine Ausschnitte wählen (einzelne Methoden etc.).
Wird vom Entwickler selbst (teilw. automatisch) durchgeführt. Am besten regelmäßig (z. B. vor jedem Einchecken).
Alleiniger Test des Moduls (ohne Interaktion mit anderen Bestandteilen). Andere, notwendige Teile werden simuliert (gemockt, Mock-Objekte).
Andere Module sollten auch Fehlerhaft gemockt werden, um Verhalten des Programms bei Fehlern zu testen.
Erneutes Testen nach einer Programmcode-Änderung. Nur relevante Tests werden durchgeführt. Jede Programmfunktion sollte einen eigenen Testfall haben.
Hinweis: Eventuell ergeben sich durch die Programmänderung neue Testfälle!
Fault-Revealing Testfall | deckt Fehler auf (der Test erzeugte eine inkorrekte Ausgabe) |
Modification Revealing | deckt andere Ausgabe von zwei (eigentlich identischen) Programmen auf |
Modification Traversing | deckt anderes Verhalten von zwei (eigentlich identischen) Programmen auf |
Treten auf bei:
Anhand eines Datenflussgraphens kann bestimmt werden, welche Testfälle eine Änderung betreffen.