Telecooperation/RBG Technische Universität Darmstadt Copyrighted material; for TUD student use only Grundlagen der Informatik 1 Thema 19: Testverfahren

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




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.}




Qualitätssicherung: Motivation

Informatik-Katastrophen

• Röntgengerät Therac-25 (`85)– Falsche Dosierung durch

selten vorkommende Bedingung (Strahlenartkorrektur) und durch Zählerüberlauf bei der Strahlenpositionierung

– Patienten wurden verletzt oder getötet

• Ariane Flug 501 (`96) – Verlust der Rakete und

Satelliten ($500.000.000)

• AT&T Telefonnetz (1990)• Airbus Crash ? (`93 und

2001)• viele, viele mehr...

4




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




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!




Wie intensiv müssen wir analysieren?

• Wie kann man gründlich suchen?• Ab wann kann man davon ausgehen, dass mit

hoher Wahrscheinlichkeit keine „Nadeln“ mehr vorhanden sind?

7

Wird´s bald?!

Habe ich jetzt alle?




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!




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




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.




Qualitätssicherungsmethoden

11

z.B. Java Compiler: analysiert, ob Variablen initialisiert sind und ob return Anweisungen vorhanden sind.




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




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)




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




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




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




Inhaltsverzeichnis

17







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.”




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




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




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




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




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;}




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;}




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!




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 dem jede Methode fertig ist wahr sein– Jede öffentliche Methode und jeder Konstruktor enthält eine

Assertion unmittelbar vor dem Rücksprung (bei jedem „Austrittspunkt“)

26




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;}




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




Design by Contract zusammengefasst

• Möglichkeiten:– Vereinfachung: Wir definieren ein Korrektheitskriterium nur

für ein 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!




Inhaltsverzeichnis

30







Testmethode

Im Allgemeinen eine systematische Methode zur Auswahl und/oder Generierung von Tests.– Strukturelle Testmethoden– Funktionale Testmethoden

31

Planmäßiges, auf ein Regelwerk aufbauendes Testverfahren.

Testverfahren sind nur mit entsprechender Werkzeugunterstützung sinnvoll anwendbar




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,– Und 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.

– Tester muss für die jeweilige Klasse einen Testrahmen programmieren, der ein interaktives Aufrufen der Operationen ermöglicht. 32




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




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!




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




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




Kontrollflussgraphen

• Kontrollflussgraph– Der Kontrollfluss wird durch einen gerichteten Graphen

dargestellt– Jeder Knoten stellt eine Anweisung dar– Die Knoten sind durch gerichtete Kanten verbunden– 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 endet37




Kontrollflussgraphen

• Kontrollflussgraphen beinhalten 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




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}




Ü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




Ü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...




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




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




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','#'>




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')




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




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




Ü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




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




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



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




Ä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




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




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




Kombinierte Strategie

• Die Nachteile von strukturellen Verfahren... – nicht implementierte Funktionen werden nicht aufgespürt– das Ziel der Überdeckung produziert oft bzgl. der Funktionalität

triviale Testfälle

• ... und die Nachteile von funktionalen Verfahren...– Basiert auf der Spezifikation, die ein höheres Abstraktionsniveau

besitzt als die Implementierung– Achillesfersen der Implementierung werden nicht herangezogen– typischerweise höchstens 70% Zweigüberdeckung

• ...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




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 / Pfade identifizieren– Gewünschte Überdeckung erzielen– (einigermaßen) Robustheit des Produkts sichergestellt

& extra Validierung der Spezifikation (zu einem gewissen Grad)

56




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




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 einem 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




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

Documents

Telecooperation/RBG Technische Universität Darmstadt Copyrighted material; for TUD student use only Grundlagen der Informatik 1 Thema 19: Testverfahren