Telecooperation/RBG
Technische Universität Darmstadt
Copyrighted material; for TUD student use only
Grundlagen der Informatik 1Thema 19: Testverfahren
Prof. Dr. Max MühlhäuserDr. Guido Rößling
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Inhaltsverzeichnis
2
• Einführung in die Qualitätssicherung
• Design by Contract
• Strukturelle und funktionale Testmethoden
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Qualitätssicherung: MotivationDieser Code in java.util.Arrays hatte 9 Jahre einen
Bug:
3
public static int binarySearch(int[] a, int key) { int low = 0; int high = a.length - 1; while (low <= high) { int mid = (low + high) / 2; int midVal = a[mid]; if (midVal < key) low = mid + 1; else if (midVal > key) high = mid - 1; else return mid; // key found } return -(low + 1); // key not found.}
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Qualitätssicherung: Motivation
Informatik-Katastrophen• Röntgengerät Therac-25 (1985-
1987)– Inkorrekte Dosierung, unklare
Fehlermeldung und manuelle Kontrollmöglichkeit („manual override“)
– Mehrere Patienten wurden verletzt oder starben
• Ariane Flug 501 (1996, $500.000.000) – Verlust von Rakete und Satellit– Überlauf beim Konvertieren
einer double nach short• Die „Rakete war zu schnell“
• AT&T Telefonnetz (1990)– Kettenreaktion durch zu schnelles „ping“
nach Neustart von Switches• Airbus Crash 1993
– Bodenkontakt bei Landung von Software nicht erkannt, daher zu spätes Bremsen
• viele, viele mehr...4
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Qualitätssicherung
Zwei komplementäre Ansätze
• Konstruktiver Ansatz– Ziel: fehlerfrei durch Konstruktion
• z.B. Funktionskomposition
• Analytischer Ansatz– Ziel: Fehlerfreiheit nachweisen
bzw. vorhandene Fehler finden– Überprüfen des Produkts, z.B. mit
• Konsistenzchecks• Vergleich mit der Spezifikation• Validierung durch den Kunden
5
ok
ok
ok
Definition
Design
Implemen-tierung
En
tfern
un
g v
on
Feh
lern
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Warum wir analysieren müssen...
• Solange Software von Menschen erstellt wird, wird sie auch fehlerhaft sein. – Fehler zu machen ist menschlich…
• Fehler müssen gefunden werden, bevor sie Folgen haben
6
Wo sind meine Krawattennade
ln?Hunger!
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Wie intensiv müssen wir analysieren?
• Wie kann man gründlich suchen?• Ab wann kann man davon ausgehen, dass mit
hoher Wahrscheinlichkeit keine Fehler mehr vorhanden sind?
7
Wird´s bald?!
Habe ich jetzt alle?
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Was ist die Aufgabe der Analyse?
• Nur das Aufspüren von Fehlern!• Die Ursachenforschung und die letztendliche
Beseitigung (Debugging) ist eine andere Disziplin.
8
Und jetzt?
Irgendwo ist noch
eine!
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Spektrum der Fehler & Analyseansätze• Mögliches Spektrum der Fehler
– nicht dramatisch: Klienten sind an niedrige Qualität gewöhnt
– ungewollt: Klienten können verloren gehen– nicht tolerierbar: können Schaden anrichten
• Abhängig von der Notwendigkeit Fehler zu vermeiden werden verschiedene Qualitätssicherheitsmethoden eingesetzt.– Formale– Empirische
9
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Verschiedene Ansätze
• Mathematiker: 3 OK, 5 OK, 7 OK; über Induktion folgt, dass alle ungerade Zahlen prim sind.
• Physiker: 3 OK, 5 OK, 7 OK, 9 Messfehler, 11 OK, 13 OK, …
• Ingenieur: 3 ist eine Primzahl, 5 ist eine Primzahl, 7 ist eine Primzahl, 9 ist eine Primzahl, 11 ist eine Primzahl, …
• Informatiker: 112 ist eine Primzahl, 1012 ist eine Primzahl, 1112 ist eine Primzahl, …
10
Hypothese
"Alle ungeraden Zahlen größer 1 sind Primzahlen"
Vorsicht!Dies ist nur Satire.
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
analytische Qualitätskontrolle
Testverfahren
dynamische Tests
Strukturelles Testen
Funktionales Testen
Analysemethoden
Verifikation
statische Analyse
Review(z.B.,
Inspektion)
Qualitätssicherungsmethoden
11
z.B. Java Compiler: analysiert, ob Variablen initialisiert sind und ob return Anweisungen vorhanden sind.
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Qualitätssicherungsbegriffe
• Verifikation: „Bauen wir die Software richtig?“– Beweis, dass ein Produkt im Sinne der
Spezifikation korrekt ist(funktionaler Test als grobe Annäherung)
• Validierung: „Bauen wir die richtige Software?“– Nachweis, dass ein Produkt in einer bestimmten
Zielumgebung lauffähig ist und das tut, was der Benutzer wünscht
12
• Ein verifiziertes Programm muss nicht den Wünschen entsprechen • Ein validiertes Programm muss nicht korrekt im Sinn der
Spezifikation sein
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Das Analysedilemma
Ansätze in umgekehrter Reihenfolge der Strenge• Nicht systematische „Methoden" sind nicht akzeptabel• „Überprüfen hier und da" (ad-hoc testing) ist nicht
geeignet, um genügend Zuversicht zu gewinnen. • Systematisches Testen (coverage testing) könnte
ausreichend sein, kann aber die Abwesenheit von Schlupflöchern nicht garantieren.
• Formale Verifikation (formal verification) könnte die absolute Korrektheit garantieren, aber…
13
Beware of bugs in the above code; I have only proved it correct, not actually tried it. (Donald Knuth)
Testen kann nur die Gegenwart von Fehlern zeigen, aber niemals deren Abwesenheit. (Dijkstras Gesetz)
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Das Analysedilemma
14
If something can go wrong, it will— at the worst possible moment. If nothing can go wrong, it still will. If nothing has gone wrong, you have overlooked something.
Blinn‘s These: Jedes funktionierende Computergrafik-programm enthält eine gerade Anzahl von Vorzeichenfehlern
Murphy‘s Law
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Wert & Kosten des Testens
15
• Entdeckungsrate• Aufspüren von Fehlern wird
immer schwieriger mit der Zeit
• Tests / Gefundene Fehler • Testen immer aufwändiger
• Fehlerqualität• Fehler immer hartnäckiger
• Kombination • Kosten pro gefundenen
Fehler steigen überproportional
• Aufhören, wenn es zu schwierig/ teuer wird, weitere Fehler zu finden?
Zeit
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Notwendigkeit einer Systematik
• In der Praxis gibt es folgende (nicht zufrieden stellende) Gründe mit dem Testen aufzuhören:– Zeit aufgebraucht – der Kunde möchte das
Produkt– Alle vorhandenen Tests werden bestanden
• Wir brauchen objektive Kriterien, ob noch zusätzliche Testfälle benötigt werden Testmethoden
• Das praktische Testen mit JUnit haben wir schon betrachtet
16
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Inhaltsverzeichnis
17
• Einführung in die Qualitätssicherung
• Design by Contract
• Strukturelle und funktionale Testmethoden
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Design by Contract (Entwurf gemäß Vertrag)
Wir erinnern uns: • Wir hatten Kontrakte schon bei Scheme benutzt• Definieren einen Kontrakt für jede Funktion oder
bzw. hier Operation• Teilnehmer des Kontrakts: aufrufende und
aufgerufene Klasse
• Kontrakt bedeutet Vorteile und Verpflichtungen für beide Seiten
18
“Wenn du mir versprichst, op mit erfüllter vorbed aufzurufen, dann verspreche ich im Gegenzug einen
Endzustand zurückzuliefern, in dem nachbed erfüllt ist.”
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Design by Contract• Ein Kontrakt besteht aus:
– Vorbedingung: vor der Ausführung eine bestimmten Operation
– Nachbedingung: nach dem Ausführen einer bestimmten Operation
– Interne Invarianten: in einem Bereich (in einer Methode) – Kontrollflussinvarianten: ein bestimmter Kontrollfluss
muss / darf nicht betreten werden– Klasseninvarianten: immer wahr vor und nach jeder
Operation• Aber nicht unbedingt während sich das Objekt in Transition
befindet– Effektbeschreibung: Beschreibt die Semantik der
Operation und ihre (Seiten-)Effekte
19
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Design by Contract• Vergleich Scheme und Java
– In Scheme mussten wir Argumenttypen überprüfen– In Java müssen wir Argumenttypen nur in wenigen Fällen
prüfen• z.B. ein Object[]-Feld, in dem nur bestimmte Subtypen von Object in dem Feld erwartet werden
• Design-by-Contract und OOP– Die Methoden von Subtypen erben die Kontrakte der
Methode des Supertyps.– Haben gleiche Vor- und Nachbedingungen
• Können stärkere Vor- und Nachbedingungen haben– Werfen die selben Ausnahmen
• Können weiter spezialisierte Ausnahmen werfen
20
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Assertions (Zusicherungen)• Das assert Schlüsselwort ist eine einfache Sprachunterstützung für
Design by Contract in Java seit Java 1.4– Wir können Assertions verwenden, um
• die Benutzung der Objektschnittstelle einzuschränken• Den inneren Zustand eines Objekts einzuschränken
• Assertions haben folgende Form:assert booleanExpression [: Expression];
– Wenn booleanExpression true ist, wird das Programm normal weiter ausgeführt. Andernfalls wird ein AssertionError geworfen.
– Expression ist ein optionaler Ausdruck, der zur Laufzeit ausgewertet und mit der Fehlernachricht zusammen ausgegeben wird.
– Die AssertionError Klasse ist ein Subtyp der Error Klasse. Ähnlich der RuntimeException muss diese nicht gefangen und auch nicht deklariert werden.
• Im Normalfall sind Assertions deaktiviert, man kann sie aktivieren über: > java –ea <classfile name>
21
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Assertions verwenden• assert wird benutzt, um folgendes auszudrücken:
– Vor- und Nachbedingungen, – Interne Invarianten,– Kontrollflussinvarianten, – Klasseninvarianten
• In folgenden Fällen ist Vorsicht geboten:– Verwenden Sie keine Assertions für das Prüfen von Argumenten
in öffentlichen Methoden– Verwenden Sie keine Assertions, um bestimmte Aufgaben
durchzuführen, die das Programm für eine korrekte Ausführung benötigt
• Die Zusicherung wird nur ausgewertet, falls sie aktiviert ist!– Assertions sollten keine Seiteneffekte auf die normale
Programmausführung haben
22
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Assertions für Vorbedingungen verwenden
• Eine Ausnahme bei den Vorbedingungen für öffentliche Methoden:
– Verwenden Sie keine Assertions für das Prüfen von Argumenten in öffentlichen Methoden Die veröffentlichte Spezifikation (oder Kontrakt) muss immer eingehalten werden Die allgemeingültige Konvention ist, eine entsprechende Laufzeit-Ausnahme zu verwenden:
meist eine IllegalArgumentException
• Vorbedingungen für private Methoden:
23
public void setAttr(int attr) { if (attr <= 0 || attr > MAX_VALUE) throw new IllegalArgumentException("illegal value:"+attr); attribute = attr;}
private void setAttr(int attr) { assert attr > 0 && attr <= MAX_VALUE: "value for attr is not in interval:"+attr; attribute = attr;}
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Assertions für Nachbedingungen verwenden
• Nachbedingungen sowohl für private als auch für öffentliche Methoden:
24
public String reverse(String oldStr) { String newStr = "";
// verschiebe in umgekehrter Reihenfolge // jeden char des alten in den neuen String
assert oldStr.equals("") : "oldStr must be empty"; return newStr;}
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Assertions verwenden
• Aussagen über interne Invarianten:
• Aussagen über Kontrollflussinvarianten:
25
if (i % 3 == 0) { ... } else if (i % 3 == 1) { ... } else { assert i % 3 == 2 : i; ... }
void foo() { for (...) { if (...) return; // sollte irgendwann zutreffen } assert false : "Execution should never reach this point!"}
Muss nur im else-Block erfüllt sein
Schlägt immer fehl, wenn erreicht!
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Assertions für Klasseninvarianten/Effektbeschreibungen verwenden
• Eine Klasseninvariante ist eine besondere Aussage, die für jede Instanz der Klasse zu jeder Zeit gilt– Außer die Instanz befindet sich gerade in Überführung von
einem konsistenten Zustand zum nächsten– Beziehung über mehrere Attribute– Sollte vor und nach jedem Methodenaufruf wahr sein– Jede öffentliche Methode und jeder Konstruktor enthält eine
Assertion unmittelbar vor dem Rücksprung (bei jedem „Austrittspunkt“)
26
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Assertions für Klasseninvarianten/Effektbeschreibungen verwenden
• In Java benutzen wir JavaDoc, um Effekte zu beschreiben:
27
/** * Erhöht den counter Feld um den Wert des step-Parameters. * <p>Effekte: der counter wird geändert.</p> * @param step Wert, um den der Zähler erhöht werden soll. * @return Gibt den aktuellen Wert der counter-Variable zurück. */public int inc(int step) { counter += step; return counter;}
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Komplexe Assertions
• Wir verwenden innere Klassen für komplexe Assertions:
28
void foo(final int[] array) { // Innere Klasse sichert den Zustand und fuehrt endgueltige // Konsistenzpruefung durch class DataCopy { private int[] arrayCopy; DataCopy() { arrayCopy = (int[]) array.clone(); }
boolean isConsistent() { return Arrays.equals(array, arrayCopy); } }
DataCopy copy = null;
// Immer erfuellt; speichert als Seiteneffekt eine Kopie des Felds assert ((copy = new DataCopy()) != null); ... // Manipulieren des Felds
// Stellt sicher, dass das Feld immer noch gleich aussieht assert copy.isConsistent(); }
Die Kopie wird nur durchgeführt, wenn
Assertions aktiviert sind
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Design by Contract zusammengefasst
• Möglichkeiten:– Vereinfachung: Wir definieren ein Korrektheitskriterium nur
für einen bestimmten Teil des Programms.– Erwartung: Solange alle Teile des Programm die Kontrakte
erfüllen, wird das Programm (fast) korrekt funktionieren. – Hoffnung: Wenn ein Fehler auftritt, dann können wir diesen
durch eine Verletzung eines Kontrakts aufspüren.
• Einschränkungen:– Auch wenn jeder Kontrakt erfüllt ist, kann es sein, dass das
Programm nicht richtig funktioniert• Ein Kontrakt kann semantisch falsch sein• Wir haben vergessen, eine bestimmte Bedingung im
Kontrakt anzugeben.
29
Wir brauchen andere Herangehensweisen, um diese Fälle abzufangen!
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Inhaltsverzeichnis
30
• Einführung in die Qualitätssicherung
• Design by Contract
• Strukturelle und funktionale Testmethoden
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Testmethode
Im Allgemeinen eine systematische Methode zur Auswahl und/oder Generierung von Tests.– Strukturelle Testmethoden– Funktionale Testmethoden
31
Planmäßiges, auf einem Regelwerk aufbauendes Testverfahren.
Testverfahren sind nur mit entsprechender Werkzeugunterstützung sinnvoll anwendbar.
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Grundbegriffe
• Testdatum – Eingabewert, der einen Eingabeparameter oder eine
Eingabevariable des Testobjekts mit einem Datum versorgt.
• Testfall– Ein Satz von Testdaten, der die vollständige
Ausführung eines zu testenden Programms bewirkt– sowie das Sollresultat.
• Testsuite– Eine nicht-leere Menge von Testfällen, die nach einem
bestimmten Kriterium ausgewählt wurden.
• Testtreiber– Handelt es sich bei dem Prüfling um eine Operation in
einer Klasse, dann kann sie nicht direkt getestet werden.
– Der Tester muss für die jeweilige Klasse einen Testrahmen programmieren, der ein interaktives Aufrufen der Operationen ermöglicht. 32
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Grundbegriffe: Instrumentierung• Schlägt ein Testfall fehl, muss man nachvollziehen,
welche Anweisungen des Testobjekts mit dem Testfall durchgeführt wurden Fehler lokalisieren
• Werkzeugunterstütztes Mitprotokollieren, welche Teile des Prüflings bei der Ausführung durchlaufen wurden
• Nach dem Testlauf werden die Zählerstände ausgewertet.
33
int maximum(int a, int b) { if (a > b) { thenBranch = true; return a; } else { elseBranch = true; return b; }}
In den Quellcode eingefügte Zähler
In den Quellcode eingefügte Zähler
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Grundbegriffe: Testabdeckung
• Testabdeckung: Verhältnis zwischen tatsächlich ausgeführten Testfällen und theoretisch existierenden Testfällen ausgeführte Testfälle
existierende Testfälle
• Bei einer Testabdeckung von 100% spricht man von einem erschöpfendem Test– Erschöpfendes Testen ist meist weder praktikabel noch
sinnvoll
• Testende-Kriterium– legt fest, welches Minimalziel durch die Testfälle
erreicht werden soll
34
TAB =
Kriterium für die Auswahl von Testfällen!
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Testmethoden
• Strukturelle Testmethoden: basieren auf der Programmstruktur (White-Box Tests)– Testfälle werden nur aus der Programmstruktur
abgeleitet– Die Vollständigkeit der Prüfung wird anhand von
Strukturelementen (Anweisungen, Zweige, Daten) des Prüfgegenstands bewertet
– Die Spezifikation des Prüfgegenstands wird bei der Beurteilung der Vollständigkeit der Tests nicht beachtet
• Funktionale Methoden: Basieren auf den Anforderungen (Black Box Tests)– Im Idealfall werden die Anforderungen in einer formellen
Spezifikation ausgedrückt– Testfälle und Testdaten werden aus der funktionalen
Spezifikation des Prüfgegenstands abgeleitet– Vollständigkeit der Prüfung wird anhand der Spezifikation
bewertet – Struktur des Prüfgegenstands wird nicht ausgewertet
35
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Testmethoden Überblick
36
Black BoxBlack Box
Grey BoxGrey Box
White BoxWhite BoxstrukturellesTesten
funktionalesTesten
Grenzwert-analyse
kontrollfluss-orientierte
Testverfahren
Äquivalenz-klassenbildung
Benutzungs-fälle überprüfen
Zufallstest
datenfluss-orientierte
Testverfahren
Theoretisch reine „BlackBox“ Verfahren. In
der Praxis auch Heranziehen der Struktur.
Klassifikation nach benötigter Information
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Kontrollflussgraphen• Kontrollflussgraph wird durch einen gerichteten Graphen
dargestellt– Jeder Knoten stellt eine Anweisung dar– Die Knoten sind durch gerichtete Kanten verbunden
• Die Anzahl ausgehender Kanten eines Knotens heißt Ausgangsgrad
• Kantenfolgen beschreiben einen möglichen Kontrollfluss von Knoten i zu Knoten j
• Zweige– Gerichtete Kanten
• Pfad– Folge von Knoten und Kanten, die mit dem Startknoten
beginnt und mit einem Endknoten endet
37
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Kontrollflussgraphen
• Kontrollflussgraphen besitzen grundsätzlich einen Start- und einen Endknoten
• Der Endknoten hat den Ausgangsgrad 0
• Jeder normale Knoten liegt auf einem Pfad vom Startknoten zum Endknoten
• Knoten mit Ausgangsgrad 1 heißen Anweisungsknoten
• Alle anderen Knoten außer dem Endknoten heißen Prädikatknoten
38
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Kontrollflussgraphen (Beispiel)
39
nende
n6
nstart
n2n2
n3
n4
n5
c = System.in.read(); // n1
while (c >= 'A' && c <= 'Z' && totalNumber<5) { // n2 totalNumber = totalNumber + 1; // n3 if (c=='A'||c=='E'||c=='I'||c=='O'||c=='U') { // n4 vowelNumber = vowelNumber + 1; // n5 } c = System.in.read(); // n6}
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Überdeckungstestverfahren
• Strukturelemente wie Anweisungen, Zweige oder Bedingungen werden genutzt, um Testziele zu definieren– Beispiel: Das
Anweisungsüberdeckungstestverfahren hat als Ziel, Testdaten so zu wählen, dass alle Anweisungen im Programm ausgeführt werden
• Realisierung von Überdeckungstests– Quellcode wird instrumentiert– Bei der Ausführung erzeugen die Trace Statements
ein Logbuch– Auswertung des Logbuchs zur Erstellung eines
Überdeckungsberichts
40
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Überdeckungstests
41
AnweisungsüberdeckungAnweisungsüberdeckung
PfadüberdeckungPfadüberdeckung
ZweigüberdeckungZweigüberdeckung Bedingungsüberdeckungeinfach
Bedingungsüberdeckungeinfach
Bedingungsüberdeckungmehrfach
Bedingungsüberdeckungmehrfach
A B A impliziert B
Übersicht...
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Anweisungsüberdeckung (C0)
• Ziel: Mit einer Anzahl von Testfällen alle vorhandenen Anweisungen auszuführen
• Beispiel eines Testfalls, der das Kriterium erfüllt– Eingabe: <'A', '#'>
• Hilft, toten Code zu finden• Ist notwendig aber nicht
ausreichend• Besitzt wenig praktische Relevanz
42
n1
n2
n3
n4
n5
n6
n1
n2
n3
n4
n6
nstart
nende
n5
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Zweigüberdeckung (C1-Test)
43
• Ziel: Die Ausführung aller Zweige, d.h. aller Kanten des Kontrollflussgraphen– Wird auch Entscheidungsüberdeckung
genannt: Jede Entscheidung muss mindestens einmal die Wahrheitswerte wahr und falsch annehmen.
• Metrik:
• Hilft, nicht erreichbare Verzweigungen zu finden • Anweisungsüberdeckung vollständig enthalten• Betrachtet weder Kombination von Verzweigungen
noch komplexe Bedingungen• Gilt als das minimale Testkriterium
Czweig =Anzahl der ausgeführten Zweige
Anzahl der vorhandenen Zweige
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Zweigüberdeckung (C1): Beispiel
44
n1
n2
n3
n4
n6
nstart
nend
n5
n
n
n
n
n1
n2
n3
n4
n6
nstart
nend
n5
<'B','#'>
<'A','#'>
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Einfache Bedingungsüberdeckung (C2)
45
n1
n2
n3
n4
n5
n6
n1
n2
n3
n4
n6
nstart
nende
n5
alle atomaren Bedingungen mind. einmal
true & false
Der „else“ Zweig wird nie
beschritten
• Testfälle– <'A', 'E', 'I', 'O', 'U', '@'> <'€‘>
• Enthält weder Anweisungs- noch Zweigüberdeckung
• Da beides minimale Testkriterien sind, ist eine alleinige einfache Bedingungsüberdeckung nicht ausreichend
if (c=='A' || c=='E' || c=='I' || c=='O' || c=='U')
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Mehrfache Bedingungsüberdeckung
46
n1
n2
n3
n4
n5
n6
n1
n2
n3
n4
n6
nstart
nende
n5
• Testfälle• <'A', 'E', 'I', 'O', 'U', '@'>
<'A', 'E', 'I', 'O', 'U', '€'><'A', 'E', 'I', 'O', 'U', 'A'><'A', '@'>, <'A', '€'>
• Zweigüberdeckung enthalten
• Kombinationsexplosion: N atomare Bedingungen 2N Möglichkeiten
• Kombinationen teilweise unmöglich!– Auswertung wird eventuell abgebrochen
(Lazy-Evaluation = nicht-strikte Auswertung)
Alle Kombinationen von atomaren Bedingungen
abdecken
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Pfadüberdeckung (C7)
47
n1
n2
n3
n4
n5
n6
n1
n2
n3
n4
n6
nstart
nende
n5
• Testfälle– <'#'>, <'B', '#'>, <'A', '#'>
<'A', 'B', 'B', 'B', 'B'><'B', 'A', 'B', 'B', 'B'>, …
• Zweigüberdeckung enthalten• Schleifen führen praktisch zu
unendlichen vielen Testfällen• Höchste Erfolgsaussichten, aber
völlig unpraktikabel
Alle Kombinationen von Zweigen abdecken
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Überdeckungstests
Vorteile• Defizite in der Teststrategie aufdecken• Nicht erreichbaren Code entdecken• Anhaltspunkt für den Testfortschritt
Nachteile• 100% Abdeckung nicht praktikabel• Codeabdeckung ist kein Kriterium für
vollständiges Testen• Fehlende Funktionalität wird nicht erkannt
48
Produkt wird gegen sich selbst geprüft
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Funktionales Testen
• Motivation: Es ist unzureichend, ein Programm lediglich gegen sich selbst zu testen Testfälle aus Programmspezifikation ableiten– Programmstruktur wird nicht betrachtet
Ziel Möglichst umfassende, aber redundanzarme
Prüfung der spezifizierten Funktionalität Überprüfung aller Programmfunktionen
(Funktionsüberdeckung)
49
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Funktionales Testen
• Hauptschwierigkeiten– Ableitung der geeigneten Testfälle– Vollständiger Funktionstest ist im allgemeinen
nicht durchführbar
• Ziel der Testplanung – Testfälle so auswählen, dass die
Wahrscheinlichkeit groß ist, Fehler zu finden
• Testfallbestimmung– Funktionale Äquivalenzklassenbildung– Grenzwertanalyse
50
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
51
Black BoxBlack Box
Grey BoxGrey Box
White BoxWhite BoxstrukturellesTesten
funktionalesTesten
Grenzwert-analyse
kontrollfluss-orientierter Test
Äquivalenz-klassenbildung
Benutzungs-fälle überprüfen
Zufallstest
datenfluss-orientierter Test
Testklassifizierung nach benötigter Information
Testmethoden im Überblick
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Äquivalenzklassenbildung• Motivation: Die Anzahl von Testfällen wird sinnvoll
eingeschränkt, indem die Testdaten in Äquivalenzklassen zerlegt werden
• Annahme: Für jeden Repräsentanten aus einer Äquivalenzklasse reagiert das Programm auf die gleiche Weise
• Beispiele– Klassen: Vokal Konsonant kein
Buchstabe– Repräs.: E T %
– Klassen: x<0 0x5 x>5– Repräs.: -5 3 9
52
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Grenzwertanalyse
• Motivation: Fehler treten typischerweise bei Extremwerten bzw. an den „Rändern“ von Äquivalenzklassen auf.
• Annahme: Die „extremen“ Repräsentanten sind nicht nur ebenso wirksam wie „normale“ Repräsentanten, sondern darüber hinaus besonders geeignet.
• Beispiele– Klassen: x<0 0x5
x>5– Repräs.: -1 0 und 5 6
53
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Testmethoden: Zusammengefasst
• Strukturelles Testen– Findet: Abbruchfehler, unerreichbare
Zweige, Endlosschleifen, inkonsistente Bedingungen Prüfung gegen sich selbst
• Funktionales Testen– Findet: Falsche Antworten
Prüfung gegen Spezifikation
54
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Kombinierte Strategie• Strukturelle Verfahren haben einige Nachteile
– Nicht implementierte Funktionen werden nicht aufgespürt
– Das Ziel der Überdeckung produziert oft bzgl. der Funktionalität triviale Testfälle
• Auch funktionale Verfahren haben einige Nachteile– Basieren auf der Spezifikation, die ein höheres
Abstraktionsniveau besitzt als die Implementierung– Achillesfersen der Implementierung werden nicht
herangezogen– Typischerweise höchstens 70% Zweigüberdeckung
• Die Verfahren ergänzen sich gegenseitig!• Die Vorteile des einen Ansatzes können benutzt werden,
um die Nachteile des anderen Ansatzes abzudecken Verwenden eines kombinierten Ansatzes
55
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Kombinierte Strategie
• Zunächst Funktionstest...– Anhand der Spezifikation Äquivalenzklassen bilden– Grenzwerte ermitteln– Testfälle erstellen Funktionsumfang systematisch geprüft
• ...anschließend Strukturtest– Oben erzielte Überdeckung analysieren– Nicht benutzte Bedingungen oder Pfade identifizieren– Gewünschte Überdeckung erzielen– (einigermaßen) Robustheit des Produkts sichergestellt
& extra Validierung der Spezifikation (zu einem gewissen Grad)
56
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Testen von Klassen und Unterklassen
• Die kleinste, unabhängige prüfbare Einheit objektorientierter Systeme ist die Klasse
• Da die Operationen einer Klasse stark voneinander abhängen, ist es nicht sinnvoll, sie einzeln zu testen.
• Der Test hängt davon ab, welche Art von Klasse vorliegt:– Normale Klasse– Abstrakte Klasse
57
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Test normaler Klassen
1. Erzeugung eines instrumentierten Objekts der zu testenden Klasse
2. Nacheinander Überprüfung jeder einzelnen Operation für sich. Zuerst sollen diejenigen Operationen überprüft werden, die nicht zustandsverändernd sind. Dann werden die zustandsverändernden Operationen getestet.a. Durch Äquivalenzklassenbildung und Grenzwertanalyse
werden aus den Parametern Testfälle abgeleitet• Das Objekt muss vorher in einen für diesen Testfall
zulässigen Zustand versetzt werden– durch vorhergehende Testfälle oder eine gezielte
Initialisierung vor jedem Testfall
b. Nach jeder Operationsausführung muss der neue Objektzustand geprüft und der oder die Ergebnisparameter mit den Sollwerten abgeglichen werden.
58
Dr. G. RößlingProf. Dr. M. Mühlhäuser
RBG / Telekooperation©
Grundlagen der Informatik I: T19
Test normaler Klassen
3. Test jeder Folge abhängiger Operationen in der gleichen Klasse
– Dabei ist sicherzustellen, dass jede Objektausprägung simuliert wird
– Alle potentiellen Verwendungen einer Operation sollten unter allen praktisch relevanten Bedingungen ausprobiert werden
4. Anhand der Instrumentierung ist zu überprüfen, wie die Testüberdeckung aussieht
– Fehlende Überdeckungen sollten durch zusätzliche Testfälle abgedeckt werden.
59
Top Related