Software Engineering Testen von Software (1)

Software Engineering Testen von Software (1) Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik Hochschule Kaiserslautern, Standort Zweibrücken 1

Qualitätssicherung (engl.: quality assurance) (Vorschau auf Projektmanagement) Konstruktive Maßnahmen Z. B. Einhalten von Styleguides, Anwendung von Entwurfsprinzipien wie lose Kopplung, Nutzung von Entwurfsmustern, Analytische Maßnahmen Statisch: Z. B. Code-Reviews, automatisierte Code-Analyse, Kennzahlen (etwa zur Code-Komplexität durch tiefe Verschachtelungen), Dynamisch: Testen, d. h. Ausführen von Code mit dem Ziel, festzustellen ob er das tut was er soll und Abweichungen vom Soll-Verhalten, d. h. Fehler, zu finden 2

Was sind funktionale und nicht-funktionale Testziele eines Software Tests? Funktionalität Zuverlässigkeit Benutzbarkeit ( usability test ) Effizienz Änderbarkeit Prüfbarkeit Übertragbarkeit System-weiteTests Load (innerhalb der Spezifikation) Volumentest Stress (Toleranztest) Performance, Zeit 3

4

Teststufen Unit-Test:. Allg. Begriff für Klassentest, Modultest oder Komponententest Klassentest: Methoden einer einzelnen Klasse Kettentest: Zusammenspiel entlang von Assoziationen (über verschiedene Klassen hinweg) Module: Zusammenspiel der Klassen Komponenten: via Interfaces, API o.ä. Integrationstests Allgemein: Verbinden bereits getesteter Units zu größeren Teilsystemen, um deren Zusammenspiel zu testen Beispiel: Last-Test der Komponenten Datenhaltung und Warenabgleich Systemtest Test des Gesamtsystems (alle Komponenten, reale Daten und Anforderunge) Beispiel: funktionaler Systemtest Abnahmetest Ausführend: Kunde Grundlage für die Abnahme durch den Kunden

Fachbegriffe zu Fehler Fehlhandlung (engl. error) Beispiele: Ein Entwickler implementiert einen Algorithmus falsch Ein Anwender bedient ein System falsch Fehlerzustand (engl. fault) Beispiele: Inkorrektes Teilprogramm, das bei der Ausführung zu einer Fehlerwirkung führt Zustand einer Komponente, die unter einer hohen Belastung die Funktionsfähigkeit beeinträchtigt Fehlerwirkung (engl. failure) Wirkung eines Fehlerzustands, die nach außen in Erscheinung tritt Abweichung zwischen Sollwert und Ist-Wert Nach: Vigenschow Uwe, Testen von Software und Embedded Systems. 2. Auflage. Dpunkt 2010.

Testen mehr Fachbegriffe Verifikation Prüfung, ob das Testobjekt seine dokumentierte Spezifikation erfüllt. Insbesondere in den Stufen Unit- und Integrationstest. Validierung Prüfung, ob das Testobjekt den Kundenanforderungen tatsächlich entspricht. Insbesondere in den Stufen System- und Abnahmetest. Regressionstest Wiederholung bereits erfolgreich durchgeführter Tests nach erfolgten Änderungen. Überprüft, ob die Änderungen Fehler in den bisher bereits funktionierenden Teilen verursacht haben. Testfall Besteht aus Testablauf (beim Testen durchzuführende Schritte) und Testdaten (Eingabedaten und erwartete Resultate) 7

Man kann nicht alles testen Eine kleine Funktion: public void funktion(double a, double b, double c, double d, double e, double f, double g){ for(int i=0;!fertig && i<20; i++){ if(a>b){ //... Anweisungen1 else { if (c<d){ if(d==e){ //... Anweisungen2 else { //... Anweisungen3 else { if(g>f){ //... Anweisungen4 else { //... Anweisungen 8

Kontrollflussgraph Erstellen eines Kontrollflussgraphen: Die einzelnen Anweisungen werden als Knoten dargestellt, die entsprechend ihrer Reihenfolge unter Berücksichtigung von Verzweigungen und Schleifen verbunden werden. Aufeinanderfolgende Anweisungen ohne zwischendurch ein- oder ausgehende Kanten können zu einem Knoten zusammengefasst werden 9

Kontrollflussgraph 1 int i=0 true 2 3 if(!fertig && i<20) true if(a>b) false false Ende 4 Anweisungen1 if(c<d) true false if(d==e) true false true 7 if(g>f) false 8 Anweisungen2 9 Anweisungen3 10 Anweisungen4 11 Anweisungen 12 i++ 10

Testfallexplosion 1 2 Wie viele mögliche Pfade gibt es durch diesen Kontrollflussgraphen? Bei 1-maligem Durchlaufen der Schleife: Bei 2-maligem Durchlaufen: * Bei 20-maligem Durchlaufen: Gesamtzahl möglicher Kombinationen: 20 4 3 8 9 10 7 11 2 + + + + Ca. 100 Billarden 3 Manueller Test mit Minuten pro Testfall: ca. 1 Mrd. Jahre Automatisierter Test mit Mikrosekunden pro Testfall: 19 Jahre 20 12 11

Testfallexplosion 1 Vollständiger Test ist nicht durchführbar Da man nur einen kleinen Teil aller möglichen Fälle testen kann, sollte man die Testfälle so auswählen, dass man möglichst große Chancen hat, viele Fehler zu finden 4 2 3 8 9 10 7 11 12 12

Test Methodiken ( test design ) Interne Struktur der Methoden berücksichtigt Zusammenspiel Komponenten getestet Reine Außensicht, keine Interna berücksichtigt Quelle: Stephan Kleuker, Grundkurs Software Prof. Engineering A. Müller, mit FH UML. KL 2. Aufl. Vieweg 2011. Software Engineering 201 13

Black Box Ansatz: Äquivalenzklassenbildung Äquivalenzklasse Die Menge aller möglichen Eingabewerte wird in Äquivalenzklassen unterteilt Für Eingabewerte, die sich in einer Äquivalenzklasse befinden, müsste sich das Testobjekt gleich verhalten Es müssen daher nur einige Repräsentanten aus jeder Äquivalenzklasse getestet werden Auch Äquivalenzklassen für ungültige Eingaben Interessant: Prüfung der Grenzen von Äquivalenzklassen und Werte in Grenznähe (z. B. bei double) Auch sehr große und sehr kleine Werte testen (Wertebereichsüberschreitungen!) Beispiel: Mathematische Betragsfunktion Äquivalenzklassen: negative Werte, positive Werte, Null 14

Beispiel für Äquivalenzklassenbildung Gegeben sei der folgende Konstruktor: public Studierender(String name, int geburtsjahr, Fachbereich fachbereich) Gültigkeitsregeln: Name darf nicht leer sein Geburtsjahr zwischen 1900 und 2010 (jeweils inklusive) Fachbereich aus einer Aufzählung: IMST, BWL, AING Äquivalenzklassen Ä1) Name nicht leer (gültig) Ä2) Name leer (ungültig) Ä3) Geburtsjahr < 1900 (ungültig) Ä4) 1900 <= Geburtsjahr <= 2010 (gültig) Ä) Geburtsjahr > 2010 (ungültig) Ä) Fachbereich IMST (gültig) Ä7) Fachbereich BWL (gültig) Ä8) Fachbereich AING (gültig) Beispiel aus: Stephan Kleuker, Qualitätssicherung durch Softwaretests. Springer Vieweg 2013. 1

Beispiel für Äquivalenzklassenbildung Kombination der Parameter Ein Testfall gültiger Eingaben kann beliebige gültige Werte kombinieren Beim Test ungültiger Werte müssen die anderen Werte gültig sein Testnr 1 2 3 4 Geprüfte Äquivalenzklassen Ä1, Ä4, Ä Ä7 Ä8 Ä2 Ä3 Ä Name Meyer Schmidt Schulz Becker Maurer Geburtsjahr 1987 1989 198 1980 1892 2012 Fachbereich IMST BWL AING IMST BWL AING Ergebnis ok ok ok Abbruch Abbruch Abbruch Beispiel aus: Stephan Kleuker, Qualitätssicherung durch Softwaretests. Springer Vieweg 2013. 1

Äquivalenzklassen: Grenzwertanalyse Insbesondere bei Zahlen: Außer Werten irgendwo in der Mitte auch die Grenzen testen. Grenzen sind fehlerträchtig (z. B. < statt <= verwendet ) Hier: Jahreszahlen Obere Grenze für Ä3: 1899 Untere Grenze für Ä4: 1900 Obere Grenze für Ä4: 2010 Untere Grenze für Ä: 2011 Beispiel aus: Stephan Kleuker, Qualitätssicherung durch Softwaretests. Springer Vieweg 2013. 17

Äquivalenzklassen: Grenzwertanalyse Es ergeben sich folgende weitere Testfälle Testnr 7 8 9 10 Geprüfte Äquivalenzklassen Ä4U Ä4O Ä3O ÄU Name Meyer Schmidt Schulz Schneider Geburtsjahr 1900 2010 1899 2011 Fachbereic h IMST BWL AING IMST Ergebnis ok ok Abbruch Abbruch Beispiel aus: Stephan Kleuker, Qualitätssicherung durch Softwaretests. Springer Vieweg 2013. 18

Äquivalenzklassen Abhängigkeiten der Parameter Die Parameter können sich gegenseitig beeinflussen Die folgende Methode soll den größten der drei Werte zurückgeben Als Werte sind beliebige Integer-Werte zulässig, d. h. es gibt für jeden Parameter eigentlich nur eine Äquivalenzklasse Aber: Die Werte können sich gegenseitig beeinflussen Siehe nächste Folie Theoretisch müsste man alle unterschiedlichen Kombinationen von Werten testen, bei denen public static int max(int x, int y, int z) x=y, x>y, x<y, x=z, x<z, x>z, y=z, y>z, y<z Führt bei größeren Beispielen wiederum zu Testfall-Explosionen Beispiel aus: Stephan Kleuker, Qualitätssicherung durch Softwaretests. Springer Vieweg 2013. 19

Äquivalenzklassen Abhängigkeiten der Parameter Fehlerhafte Implementierung: Die Fehler werden nicht gefunden bei folgenden Test Aber bei: Beispiel aus: Stephan Kleuker, Qualitätssicherung durch Softwaretests. Springer Vieweg 2013. public static int max(int x, int y, int z) { int max = 0; if (x > z) max = x; if (y > x) max = y; if (z > y) max = z; return max; max(1, 2, 3) max(3, 2, 1) max(2, 3, 1) max(3, 1, 2) max(3, 3, 3) 20

Äquivalenzklassen und Objektorientierung Die Ergebnisse einer Methode hängen oft auch von Attributwerten ab. Solche Attribute sind als zusätzliche Parameter zu berücksichtigen. Beispiel: Es soll geprüft werden, ob eine Bestellung ohne weitere Liquiditätsprüfung genehmigt wird. Für geprüfte Kunden soll die Bestellung immer möglich sein, für sonstige Kunden muss eine Prüfung ab 00 erfolgen. Beim Testen der Methode einkaufssummepruefen( ) muss neben der Bestellsumme auch berücksichtigt werden, ob der Kunde geprüft ist. public class Zahlungspruefung { private boolean istgeprueft; public boolean einkaufssummepruefen(int wert){ boolean ergebnis = false; if(istgeprueft wert<00){ ergebnis = true; return ergebnis; public void setgeprueft(boolean geprueft){ this.istgeprueft = geprueft; Prof. A. Müller, FH KL Software Engineering 201 Beispiel aus: Stephan Kleuker, Qualitätssicherung durch Softwaretests. Springer Vieweg 2013 (modifiziert) 21

White-Box Ansatz: Code-Überdeckung beim Testen Beispiel: 0 public int bonus(int score, int alt) { int ergebnis 1= 0; if (score > 200) ergebnis = 20; else ergebnis 2 = ; 3 if (alt > 42 & score > 900) ergebnis += 10; return ergebnis; if (alt > 42 4 int ergebnis = 0 if (score > 200) bnis = 20 ergebnis = nis += 10 & score > 900) return ergebnis Kontrollflussgraph 01 2 3 4 int ergebnis = 0; if (score > 200) ergebnis = 20; ergebnis = ; ergebnis += 10; t t f f if (alt > 42 & score > 900) return ergebnis; Beispiel und Abbildung aus: Stephan Kleuker, Qualitätssicherung durch Softwaretests. Springer Vieweg 2013. 23

White-Box Ansatz: Anweisungsüberdeckung Jede Anweisung (jeder Knoten wird durchlaufen). Anweisungsüberdeckung (C0-Überdeckung) Anzahl der besuchten Knoten / Anzahl aller Knoten Test T1 T2 T3 T1+T3 score 201 900 200 alt 43 43 88 ergebnis 30 1 01 01 01 01 2 3 2 3 2 3 2 3 4 4 4 4 C0 / 4/ / / Quelle: Stephan Kleuker, Qualitätssicherung durch Softwaretests. Springer Vieweg 2013. 24

White-Box Ansatz: Zweigüberdeckung Zweigüberdeckung (C1-Überdeckung): Anzahl der besuchten Kanten / Anzahl aller Kanten Test T1 T2 T3 T1+T3 T1+T2 score 201 900 200 alt 43 43 88 ergebnis 30 1 01 01 01 01 01 2 3 2 3 2 3 2 3 2 3 4 4 4 4 4 C1 4/7 3/7 4/7 /7 7/7 Quelle: Stephan Kleuker, Qualitätssicherung durch Softwaretests. Springer Vieweg 2013. 2

Aufgabe Betrachtet wird noch einmal das Beispiel zur Berechnung des Maximum von drei Werten: Erstellen Sie den Kontrollflussgraphen Erstellen Sie Testfälle public static int max(int x, int y, int z) { int max = 0; if (x > z) max = x; if (y > x) max = y; if (z > y) max = z; return max; a. Mit denen Sie eine vollständige Anweisungsüberdeckung erreichen b. Mit denen Sie eine vollständige Zweigüberdeckung erreichen (jeweils nur so viele Testfälle, wie unbedingt nötig) Treten bei Ihren Testfällen die Fehler auf? Findet man die Fehler zwangsläufig mit Hilfe der vollständigen Anweisungs- oder Zweigüberdeckung? Beispiel aus: Stephan Kleuker, Qualitätssicherung durch Softwaretests. Springer Vieweg 2013. 2

Vollständige Anweisungsüberdeckung ohne Finden der Fehler 7 = max (, 7, 4) 7 = max (4,, 7) 0 max = 0 0 max = 0 max = x 2 7 max = y max = z 4 1 3 4 if (x>z) 7 if (y>x) 4 7 if (z>y) max = x max = y 7 max = z 2 4 1 3 4 7 if (x>z) 4 if (y>x) 7 if (z>y) 7 return max 7 7 return max 7 Quelle: Stephan Kleuker, Qualitätssicherung durch Softwaretests. Springer Vieweg 2013. 27

Vollständige Zweigüberdeckung ohne Finden der Fehler 7 = max (7,, 4) 7 = max (, 7, 4) 7 = max (4,, 7) 0 max = 0 0 max = 0 0 max = 0 Zweigüberdeckung ohne Finden der Fehler 7 max = x 2 max = y 4 max = z 1 3 7 7 4 if (x>z) max = x 2 7 if (y>x) 7 max = y 4 4 if (z>y) max = z return max 7 1 3 7 4 if (x>z) max = x 7 if (y>x) max = y return max 7 2 4 4 7 if (z>y) 7 max = z 1 3 7 4 7 if (x>z) 4 if (y>x) 7 if (z>y) return max 7 Quelle: Stephan Kleuker, Qualitätssicherung durch Softwaretests. Springer Vieweg 2013. 28

public int max(int x, int y, int z){ int max = 0; if (x>z) max = x; if (y>x) max = y; if (z>y) max = z; return max; 3 Pfadüberdeckung (C2) Jeder Pfad, d. h. jede mögliche Kombination (Sequenz) von Zweigen muss durchlaufen werden In diesem Beispiel gibt es 2 = 8 Pfade, allerdings sind nicht alle erreichbar max = x max = y max = z x>z T T T F T F F F y>x T T F T F T F F z>y T F T T F F T F Beispielwerte Nicht erreichb. 2 4 0 1 3 7 int max = 0 if (x>z) if (y>x) if (z>y) 7,9, 9,,7,7,9 9,7,,7,,,7,, return max Hinweis: bei Schleifen wird meist eine bestimmte Mindestzahl von Schleifendurchläufen gefordert Quelle: Stephan Kleuker, Qualitätssicherung durch Softwaretests. Springer Vieweg 2013. 29

Pfadüberdeckung (C2) Warum findet man bei Pfadüberdeckung mehr Fehler als bei Zweigüberdeckung? Beispiel: public int einemethode(int x, int y){ int a; if(x>0){ a=0; else { a=1; if (y>0){ return /a; else { return a; Mit den Testfällen (2, -1) und (-3, ) erreicht man alle Zweige, findet aber den Fehler nicht Vollständige Pfadüberdeckung ist recht aufwändig, daher in der Praxis meist nicht realisierbar 30

Bedingungsüberdeckung (C3) Durch Anweisungs- oder Zweigüberdeckung werden u. U. wichtige Situationen bzgl. der Variablenwerte übersehen Z. B. können beide Fälle der Anweisung if (a b) erreicht werden ohne dass b je true ist (indem a einmal true und einmal false gesetzt wird). Daher werden die im Programm verwendeten Bedingungen analysiert. Zusammengesetzte Bedingungen setzen sich aus atomaren Bedingungen zusammen Eine atomare Bedingung lässt sich nicht weiter zerlegen, z. B. x >=. Negierte atomare Bedingungen gelten ebenfalls als atomar, z. B.!(x>=) Dies entspricht ja x< Beispiel: Der Ausdruck ( (x==1) (x>10) ) && ( (y<) (y>=40) ) besteht aus den atomaren Ausdrücken x==1 x>10 y< y>=40 31

Einfache Bedingungsüberdeckung (C3a-Überdeckung) Jede im Programm vorkommende atomare Bedingung muss einmal wahr und einmal falsch sein (jede atomare Bedingung wird einmal mit true und false getestet). Die bereits betrachtete Methode bonus( ) enthält 3 atomare Bedingungen: score>200 alt > 42 score > 900 public int bonus(int score, int alt) { int ergebnis = 0; if (score > 200) ergebnis = 20; else ergebnis = ; if (alt > 42 & score > 900) ergebnis += 10; return ergebnis; Quelle: Stephan Kleuker, Qualitätssicherung durch Softwaretests. Springer Vieweg 2013. 32

Einfache Bedingungsüberdeckung (C3a-Überdeckung) Betrachtung einiger Testfälle: Test T1 T2 T3 T1+T2 T4 T2+T4 score 201 900 200 201 alt 43 43 88 42 ergebnis 30 1 20 score > 200 t f f t f t f t alt > 42 t t t t f t f score > 900 t f t t f t f t C2 3/ 3/ 3/ / 3/ / Die einfache Bedingungsüberdeckung garantiert nicht zugleich Anweisungs- oder Zweigüberdeckung So wird durch T2 und T4 nie die Anweisung ergebnis += 10 erreicht Quelle: Stephan Kleuker, Qualitätssicherung durch Softwaretests. Springer Vieweg 2013. 33

Minimale Mehrfachüberdeckung (C3c-Überdeckung) Hierbei werden alle Teilbedingungen betrachtet. Neben den atomaren Bedingungen sind dies alle enthaltenen zusammengesetzten Ausdrücke. Jede atomare Bedingung und die Gesamtbedingungen werden mit true und false getestet. Dabei soll jeder atomare Wert innerhalb eines Ausdrucks mindestens einmal positiv und negativ den Wert des kompletten Ausdrucks entscheidend beeinflussen. Für ( (x==1) (x>10) ) && ( (y<) (y>=40) ) sind dies: x==1 x>10 y< y>=40 (x==1) (x>10) (y<) ( y>=40) ( (x==1) (x>10) ) && ( (y<) (y>=40) ) Die minimale Mehrfachüberdeckung beinhaltet die Zweig- und damit die Anweisungsüberdeckung Quelle: Stephan Kleuker, Qualitätssicherung durch Softwaretests. Springer Vieweg 2013. 34

Minimale Mehrfachüberdeckung (C3c-Überdeckung) Teilbedingungen im Beispiel score>200 alt > 42 score > 900 alt>42 && score > 900 public int bonus(int score, int alt) { int ergebnis = 0; if (score > 200) ergebnis = 20; else ergebnis = ; if (alt > 42 & score > 900) ergebnis += 10; return ergebnis; Test T1 T2 T3 T T1+T2 T1+T score 201 900 200 900 alt 43 43 88 42 ergebnis 30 1 score > 200 t f f f t f t f alt > 42 t t t f t t f score > 900 t f t f t f t f alt > 42 t f t f t f t f && score >900 C3 4/8 4/8 4/8 4/8 7/8 8/8 Quelle: Stephan Kleuker, Qualitätssicherung durch Softwaretests. Springer Vieweg 2013. 3

Modified condition/decision coverage (C3c-Überdeckung) Every point of entry and exit in the program has been invoked at least once, every condition in a decision in the program has taken on all possible outcomes at least once, and each condition has been shown to affect that decision outcome independently. A condition is shown to affect a decision's outcome independently by varying just that condition while holding fixed all other possible conditions. The condition/decision criterion does not guarantee the coverage of all conditions in the module because in many test cases, some conditions of a decision are masked by the other conditions. Using the modified condition/decision criterion, each condition must be shown to be able to act on the decision outcome by itself, everything else being held fixed. The MC/DC criterion is thus much stronger than the condition/decision coverage. Mehr dazu: http://en.wikipedia.org/wiki/modified_condition/decision_coverage 3

Kurzname erfüllte Bedingung Durchführbarkeit Anweisungsüberdeckungstest C 0 Zweigüberdeckungstest C 1 jede Anweisung wird mindestens einmal ausgeführt jede Kante im KFG wird mindestens einmal durchlaufen relativ einfach realistische Mindestanforderung, vertretbarer Aufwand Pfadüberdeckungstest C 2 Vollständig C 2 a Alle möglichen Pfade werden durchlaufen unmöglich bei Schleifen Boundary-Interior C 2 b wie C 2 a, Schleifen werden jedoch nach speziellen Regeln durchlaufen aufwendig Strukturiert Bedingungsüberdeckungste st Einfachbedingung C 2 c C 3 C 3 a wie C 2 b, Schleifen werden jedoch genau n-mal durchlaufen jede atomare Bedingung wird einmal mit true und false getestet aufwendig Mehrfachbedingung C 3 b jede true/false Kombination der atomaren Bedingungen wird getestet sehr hoher Aufwand Minimale Mehrfachbedingung C 3 c jede atomare Bedingung und die Gesamtbedingung wird mit true und false getestet hoher Aufwand Quelle: http://de.wikipedia.org/wiki/kontrollflussorientierte_testverfahren 37

Aufgabe Gegeben ist die folgende Methode public int methode(int a, int b, int c, int d){ int x=0; if(((a>b)&&(b==c)) (d<0)) x=1; else if(d>10) x=2; return x; Geben Sie Testfälle an, um die folgenden Überdeckungen komplett zu erreichen 1. Schritt 1:Einfache Bedingungsüberdeckung 2. Schritt 2: Minimale Mehrfachbedingungsüberdeckung (jeweils nur so viele Testfälle, wie unbedingt nötig) 38

Lösungsvorschlag public int methode(int a, int b, int c, int d){ int x=0; if(((a>b)&&(b==c)) (d<0)) x=1; else if(d>10) x=2; return x; 1 2 3 4 a b c d a>b b==c d<0 d>10 (a>b)&&(b==c)) ((a>b)&&(b==c)) (d<0) T1 T2 39

Lösungsvorschlag: T1, T2 Einfache Bedingungsüberdeckung: Fälle 1-4 Min. Mehrfachbedingungsüberdeckung: Fälle 1-1 2 3 4 T1 a 10 T2 b 8 10 c 8 7 d -1 20 a>b t f b==c t f d<0 t f d>10 f t (a>b)&&(b==c)) t f ((a>b)&&(b==c)) (d<0) t f public int methode(int a, int b, int c int x=0; if(((a>b)&&(b==c)) (d<0)) x=1; else if(d>10) x=2; return x; 40

Datenflussorientierte Überdeckungen public class Problem { public static int mach(boolean a, boolean b) { int x = 0; if (a) x = 2; else x = 3; if (b) return ( / (x - 3)); else return ( / (x - 2)); public static void main(string[] args) { System.out.println(mach(true, true)); System.out.println(mach(false, false)); Die beiden Tests liefern vollständige Zweigüberdeckung und minimale Mehrfachüberdeckung, decken die Fehler aber nicht auf Zusammenhänge bzgl. der an die Variable x zugewiesenen Werte nicht berücksichtigt 41

Datenflussorientierte Überdeckungen in mach(boolean a, boolean b) Definition von a und b Nutzg. von a in Entscheidung 1 2 int x=0 if(a) Definition von x Spielt hier keine Rolle, da der Wert von x auf allen Pfaden vor der Nutzung neu definiert wird Definition von x 3 4 x=2 x=3 Definition von x Nutzung von b in Entscheidung if(b) Nutzung von x in Berechnung return (/(x-3) 7 return (/(x-2) Nutzung von x in Berechnung Verschiedene Überdeckungsmaße, z. B. Es müssen alle Pfade von einer Definition zu ihrer Nutzung in Entscheidungen getestet werden Es müssen alle Pfade von einer Definition zu ihrer Nutzung in Berechnungen getestet werden Es müssen alle Pfade von einer Definition zu ihrer Nutzung getestet werden 42

Auswahl des geeigneten Überdeckungsmaßes Je umfassender das Überdeckungsmaß und je höher der Abdeckungsgrad, desto höher die Chance, dass evtl. vorhandene Fehler gefunden werden Minimale Mehrfachüberdeckung ist besser als Zweigüberdeckung etc. 80% Abdeckung ist besser als 0% Abdeckung Andererseits steigt die Zahl der Testfälle und damit der Testaufwand an Es müssen Aufwand und Nutzen gegeneinander abgewogen werden Z. B. muss sicherheitskritischer Code möglichst vollständig getestet werden, wogegen bei unkritischem Code geringere Abdeckungen vertretbar sein können Meist ist es sinnvoll, zumindest Zweigüberdeckung anzustreben. 43