Dynamische Testverfahren Die zu betrachtende Komponente (Operation, Klasse, Paket, Gesamt-system) wird mit konkreten Eingabewerten ausgeführt und ihr Verhalten wird dabei beobachtet. Im wesentlichen lassen sich dabei folgende Alternativen unterscheiden: Strukturtest (White Box-Test): Die interne Struktur der Komponente oder ihrer UML-Spezifikation wird zur Testplanung und -Überwachung herangezogen Funktionstest (Black Box-Test): Die interne Struktur der Komponente wird nicht betrachtet; getestet wird Ein-/Ausgabeverhalten gegen Spezifikation Regressionstest: Verhalten einer Komponentenversion wird mit Verhalten anderer Komponenteversionen verglichen. Ein Testwerkzeug speichert alle durchgeführten Testfälle und erlaubt die automatische Wiederholung auch beim Kunden

Black box Tests Black-Box Testen ist ein dynamisches und funktionales Testverfahren Die Testfallermittlung erfolgt ausgehend von der Produktdefinition durch deterministische Strategien oder zufallsbasiert Einsatzbereich sind System- und Abnahmetests Wesentliche Ausprägungen sind Funktionstests sowie Leistungstests wie Massentest, Zeittest, Lasttest und Streßtest Voraussetzung für den Einsatz dynamischer Testverfahren wie dem Black Box- Testen ist die Möglichkeit, Programme oder Programmteile auszuführen. Aus dieser Forderung folgt, daß funktionale Tests vor allem gegen Ende einer Iteration die Testsuites ergänzen sollten.

Funktionstest Funktionstests prüfen die Implementierung gegen ihre Spezifikation und lassen die interne Programmstruktur unberücksichtigt: Komplementär zu bislang vorgestellten „White-Box“-Verfahren für Abnahmetest ohne Kenntnis des Quellcodes geeignet setzt (eigentlich) vollständig und widerspruchsfreie Spezifikation voraus repräsentative Eingabewerte/Szenarien müssen ausgewählt werden (man kann i.a. nicht alle Eingabekombinationen testen) Sequenzdiagramme aus Anwendungsfällen (use cases) beschreiben wichtige Testfälle man braucht Fachwissen oder „Orakel“ für Überprüfung der Korrektheit der Ausgaben ausführbare Statecharts als Orakel verwenden

Funktionale Äquivalenzklassenbildung Bei der funktionalen Äquivalenzklassenbildung werden die Definitionsbereiche der Eingabedaten und die Wertebereiche der Ausgabedaten in Äquivalenzklassen aufgeteilt. Das Verfahren basiert auf der Annahme, daß sich das Softwaresystem bei der Verarbeitung eines Wertes der Äquivalenzklasse genauso verhält, wie bei der Verarbeitung aller anderen Werte der Äquivalenzklasse. Erfolgt die Verarbeitung dieses Repräsentanten fehlerfrei, wird die Schlußfolgerung gezogen, daß auch alle anderen Werte der Äquivalenzklasse fehlerfrei verarbeitet werden. Das Verfahren ist auf die Prüfung einzelner Ein- und Ausgabedaten beschränkt, Wechselwirkungen und Beziehungen zwischen einzelnen Werten werden nicht betrachtet.

KomponentenTests Bei Komponenten sind nur Funktion und Schnittstelle, nicht aber deren Implementierung bekannt: funktionales Testverfahren Basis Lastenheft, Use Cases oder Benutzerhandbuch Testdaten durch Bildung von Äquivalenzklassen, d.h. Klassen mit gültigen bzw. ungültigen Ein- und Ausgabewerten Aus Äquivalenzklassen Ableitung von Grenzwerten: Grenzwertanalyse Aus Äquivalenzklassen Ableitung von speziellen Testdatensätzen, die fehlersensitive Testfälle repräsentieren: special value test Aus Äquivalenzklassen Ableitung von zufälligen Testdatensätzen: Zufallstests mittels Monte Carlo Verfahren

Strukturtest (White Box-Test) Zur Testplanung und -Überwachung wird die interne Struktur der Komponente oder ihrer UML-Spezifikation herangezogen. Folgende Varianten sind möglich kontrollflussorientiert: Ablaufverhalten von Operationen wird untersucht datenflussorientiert: Variablenzugriffe (setzen/lesen) stehen im Vordergrund zustandsorientiert: Zustände und Transitionen einer Klasse werden betrachtet.

Testabdeckung Beim White Box Test liegt der Programmcode offen, Kontrollfluss, Datenfluss und Verhalten unter vorgegebenen Zuständen sind angebbar. Allerdings reicht es nicht aus, nur zu fordern, dass beim Test jede einzelne Anweisung mindestens einmal durchlaufen wird. Versucht man die Kombination aller möglichen Pfade abzudecken, so ist der Testaufwand mindestens bei grösseren Programmen nicht mehr zu bewältigen. Zwischen beiden Extremen sind geeignete Kompromisse zu finden. Dazu helfen Maße der Testabdeckung

Testabdeckung auf Modulebene

Testabdeckung auf Systemebene

Regressions Test Was soll man nach Änderung in einem Programm testen a) Tests für das gesamte Programm wiederholen? b) Testfälle mit Fehlern wiederholen? Kleine Einheiten alle Tests Große Einheiten Tests mit Fehlern + Stichproben Minimierung des Risikos durch Kapselung und Anpassung des Testumfanges an Schwere der Änderung

Wann hört man auf mit Testen Wenn Testbudget verbraucht bzw. Auslieferungszeitpunkt erreicht Die je Testfall (Zeiteinheit) gefundene Fehlerzahl sinkt unter gegebene Grenze n % absichtlich von einer Gruppe implantierter Fehler (seeded bugs) wurden von Testgruppe gefunden Aus jeder Klasse „äquivalenter“ Eingabedaten wurde ein Repräsentant getestet. Testfälle decken alle (relevanten) Programmverzweigungen ab Testabdeckung C1 sollte Standard, C2 Ziel sein