Testen von Software - dawis.wiwi.uni-due.de · 2 Stefan Hanenberg, Testen von Software, SE-Vorlesung, Osnabrück, 17.11.2006 3 Testen von Software 1. Motivation und Eigenschaften

1

University of Duisburg University of Duisburg –– Essen (Germany) Essen (Germany) Institute Institute forfor Computer Science and Computer Science and Business Information SystemsBusiness Information Systems

Testen von Software

Dr. Stefan HanenbergUniversität Duisburg-Essen

Universität Osnabrück, 17.11.2006

2Stefan Hanenberg, Testen von Software, SE-Vorlesung, Osnabrück, 17.11.2006

ÜÜbersichtbersicht

1. Motivation und grundlegende EigenschaftenMotivation für SoftwaretestsVollständiges vs. unvollständiges TestenAblauf von Softwaretests

2. TestfallbestimmungBlack-Box-TestingWhite-Box-Testing

AnweisungsüberdeckungZweigüberdeckung

3. Zusammenfassung4. Literatur und weitere Referenzen

2


Testen von Software1. Motivation und Eigenschaften von

Softwaretests


Motivation fMotivation füür Softwaretestsr SoftwaretestsWichtiges Aufgabe bei der Softwareentwicklung• Durchführung eines Soll-Ist-Vergleichs, der die Anforderungen an die

Software mit der tatsächlich erstellten Software vergleicht und bewertet

Dazu zählen folgende Fragen• Wird die Software den funktionalen Anforderungen gerecht?

Fokus auf Semantik der Software

• Arbeitet das System unter einer gegebenen Last wie gewünscht?Fokus auf Performanz der Software

• Entspricht die Benutzer-Interaktion mit dem System den Anforderungen?Fokus auf Mensch-Maschine-Interaktion

Unterschiedliche Techniken zur Behandlung der Fragen• Formale Modelle und Verifikation• Inspektions- und Interviewtechniken• Softwaretests

Testen ist derzeit die am häufigsten eingesetzte Technik

1. Motivation und Grundlegende Eigenschaften

3


Einordnung in EntwicklungsprozessEinordnung in EntwicklungsprozessIn traditionellen Prozessen (Wasserfall, V-Modell, etc.)• Testen unterschiedlicher Artefakte (Anforderungen, Entwurf, etc.)• Spezifikation und Durchführung der Tests geschieht nach

Erstellung der Artefakte• Erzeugung und Durchführung von Testfällen nicht (notwendig)

durch Entwickler selbst

In neueren Ansätzen (XP, agile method, etc.)• Testen von Software (nicht weitere Artefakte)• Test-First-Mentalität: Vor Erstellung eines Stücks Software werden

dazugehörigen Testfälle erzeugt• Erzeugen von Testfällen dient der Reflektion über das Problem• Durchführung der Testfälle (primär) seitens der Entwickler

Anmerkung• Hier nur Testen von Software behandelt



Grundlegende IdeeGrundlegende Idee„Testen ist der Prozess, ein Programm mit der Absicht auszuführen, Fehler zu finden.“ [Myer79]

Softwaretests• vergleichen das Verhalten einer Software (Ist) mit dem

erwarteten Verhalten eines Systems (Soll), wobei• das Verhalten für eine (endliche) Menge von

Eingabedaten ermittelt wird, wobei • Eingabedaten nicht die Menge aller möglichen

Eingabedaten widerspiegeln, sondern nur Beispiele für Eingaben darstellen

Gründe für beispielhaftes (unvollständiges) Testen• Zeitaufwand für

Erstellung der Tests soll möglichst klein gehalten werdenTestdurchführung soll möglichst klein gehalten werden


4


VollstVollstäändiges Testenndiges TestenBeispiel• Die unten beschriebene Java-Klasse MyMathFunctions soll

hinsichtlich ihrer beiden Methoden getestet werdenpublic class MyMathFunctions {

//Fakultät der Zahl ipublic int fak(int i) {...}// Grösster gemeinsamer Teiler von i, j und kpublic int ggt(int i, int j, int k) {...}

}

• Vollständiges TestenWertebereich Integer in Java von -231 bis 231-1232 mögliche Eingaben für fak, 232 x 232 x 232 = 296 für ggt• 1,5 * 1017 s ist das geschätzte Alter der Erde

• Würde jeder Testfall für ggt 1 Nanosekunde benötigen, würde das vollständige Testen mehr als das 500-fache des Erdalters andauern

? Testen aller möglichen Eingaben nicht möglich



UnvollstUnvollstäändiges Testenndiges TestenProbleme bei unvollständigem Testen• Tests ermöglichen nur das Auffinden von Fehlern

Tests können Korrektheit nicht beweisen• Fehlerursache durch Soll-Ist Vergleich nicht zwangsläufig

erkennbar• Testfälle können selbst Fehler beinhalten (!)

Vorteile bei unvollständigem Testen• Tests können sich auf „realistische Benutzereingaben“

beziehen• Tests sind (i. d. R.) reproduzierbar• Zahlreiche Werkzeugunterstützung automatische

Testdurchführung und ProtokollierungAnmerkung• Im Folgenden impliziert die Verwendung des Terms Test immer das

unvollständige Testen


5


Ablauf von SoftwaretestsAblauf von Softwaretests

AktivitätenI. Welche Situationen und Module sollen getestet werden?II. Unter welchen Eingabedaten werden Module getestet?III. Wie werden die Tests ausgeführt?IV. Vergleich der Ergebnisse (Ist) mit den Testfällen (Soll)


I. Entwerfen der Testfälle

II. Erstellen der Testdaten

III. Ausführen des Programms mit Testdaten

IV. Vergleichder Ergebnisse mit Testfällen

Testfälle Testdaten Test-ergebnisse

Test-protokolle

Quelle: [Somm01]

= Aktivitäten= Artefakte


Fragestellungen bei TestsFragestellungen bei TestsWelche Arten von Fehlern existieren?

• Unstimmigkeiten mit Spezifikation, Kritische Fehler, etc.

Wie können Testfälle durchgeführt werden?• Automatisierte Tests, Werkzeugunterstützung, etc.

Auf welche Softwarebausteine werden Testfälle angewandt?• Granularität der getesteten Elemente

Wie werden Ein- und Ausgaben von Testfällen gewonnen?• Techniken zur Gewinnung von Testfällen

(Testfallbestimmung)? Fokus der Vorlesung


6


Testen von Software2. Testfallbestimmung


Testfallbestimmung Testfallbestimmung -- EinfEinfüührung hrung Die Testfallbestimmung befasst sich mit systematischen Techniken zur Gewinnung von TestfällenUnterschiedliche Techniken haben• Unterschiedlichen Aufwand bei Spezifikation• Unterschiedlichen Aufwand bei Durchführung der Tests• Unterschiedliche Erfolgsaussichten zur Findung von

FehlernSehr große Anzahl an Testverfahren bekannt, so dass die Vorlesung nur sehr oberflächlich in die Thematik einführen kannAbschließende Klassifizierung von Verfahren zur Testfallbestimmung nicht möglich, da noch immer Gegenstand der Forschung

2. Testfallbestimmung

7


KlassifizierungKlassifizierung2. Testfallbestimmung

Testfall-bestimmung

Black-Box-Tests

White-Box-Tests

Äquivalenz-klassenanalyse

Grenzwertanalyse

...Ablaufgraph-überdeckung

Datenflußanalyse

...

Anweisungs-überdeckung

Pfadüber-deckung

Im Folgenden näher erläutert (siehe auch [GJM02])

• Black-Box-Testing• White-Box-Testing

...Stochastische

Verfahren

vgl. [Ligg02]


BlackBlack--BoxBox--TestingTesting (1)(1)

Black-Box-Testing („spezifikationsbasiertes Testen“)• Testfall-Auswahl aufgrund der Spezifikation des

getesteten Softwareelements• Interna des Softwareelements werden nicht zur

Bestimmung der Testfälle verwendet (Interna bleiben verborgen = black box)

• Unterschiedliche Ausprägungen von Black-Box-Testing(Äquivalenzklassenanalyse, Grenzwertanalyse, etc.)

• Güte der Tests wird abgeschätzt durch Hypothesen über das zu testende System

• Beispiel (siehe Folie 7)

public class MyMathFunctions {//Fakultät der Zahl ipublic int fak(int i) {...} ...}Ableitung der Testfälle aus Spezifikation von fak

• fak(5) = 120, fak(6) = 720, fak(10) = 3628800, ...


8


BlackBlack--BoxBox--TestingTesting (2) (2) -- BeispielBeispielBeispiel

public class MyMathFunctions {//Fakultät der Zahl ipublic int fak(int i) {if (i==1) return 0 elseif (i==2) return 1 else...Ergebnisse für 3 und 4...if (i==5) return 120 elsereturn i * fak(i-1);

}}

Überlegung des Programmierers war, dass Fakultätsfunktion für „einfache“ Werte bereits Konstanten liefern kann (Optimierung)Fehler für fak(1) und fak(2) bleiben bei Black Box Tests mit den Testfällen

fak(5) = 120, fak(6) = 720, fak(10) = 3628800, etc. unerkanntProblem: „Brisanz“ der if-Ausdrücke ist dem Tester verborgen



BlackBlack--BoxBox--TestingTesting (3)(3)

Anwendung von Black-Box-Testing• Wenn Interna des getesteten Element nicht sichtbar sind

(getestetes Element liegt nicht als Quelltext vor)• Wenn Interna des Programms als „instabil“ erachtet

werden, d.h. wenn angenommen wird, dass sich Interna in naher Zukunft ändern

• Wenn Einfachheit der Testauswahl (d.h. schnelle Spezifikation der Testfälle) ein Kriterium ist

z.B. werden Black-Box-Tests in agilen Methoden genutztBeurteilung• Wenig bis kein Wissen muss über Interna (inclusive

Programmiersprache) vorliegen• Schwache Form des Testens• Prinzipielles Bewertungsproblem der Güte der Tests• Mögliche „kritische, interne Situationen“ werden nicht

erfasst


9


WhiteWhite--BoxBox--TestingTesting (1)(1)

White-Box-Testing• Auch „quelltextbasiertes Testen“ genannt• Testfall-Auswahl aufgrund der Spezifikation und

der Struktur des getesteten Softwareelements• Interna des Softwareelements werden zur

Bestimmung der Testfälle verwendet (Interna sind sichtbar = white box)

• Unterschiedliche programmiersprachlicheElemente wirken sich unterschiedlich auf erstellte Testfälle aus

• Bewertung der Güte der Testfälle stützt sich auf Programmstruktur




White-Box-Testing-Verfahren dekomponieren(zerlegen) das Programm (statisch oder dynamisch)Güte der (Menge der) Testfälle wird darin gesehen, inwieweit die Testfälle das dekomponierte Programm überdeckenUnterschiedliche Ausprägungen• Anweisungsüberdeckung• Zweigüberdeckung• Pfadüberdeckung• ....und weitere....

Beurteilung des White-Box-Testens abhängig von eingesetztem Verfahren


10


AnweisungsAnweisungsüüberdeckungberdeckung (1)(1)

Anweisungsüberdeckung (auch C0-Test genannt) stellt den einfachsten Fall der White-Box-Tests darDie Anweisungsüberdeckung zerlegt das Programm statisch in seine Anweisungen • Testfälle sind so zu wählen, dass 95%-100% aller

Anweisungen durch Testfälle überdeckt sind (C0-Kriterium), d.h. Ziel ist ein möglichst hoher Überdeckungsgrad

• je höher der durch eine Menge von Tests erzielte Deckungsgrad, desto größer die Anzahl potentiell gefundener Fehler


Überdeckungsgrad C0= ? überdeckte Anweisungen

? Anweisungen in Programm


AnweisungsAnweisungsüüberdeckungberdeckung (2) (2) –– Beispiel 1Beispiel 1

Beispiel1 public int fak(int i) {2 if (i==1) return 0 else3 if (i==2) return 1 else4+5 ...Ergebnisse für 3 und 4...6 if (i==5) return 120 else7 return i * fak(i-1);}

Die Testfallmenge M1 = {fak(5) = 120, fak(6) = 720, fak(10) =... } hat einen Überdeckungsgrad von 2/6 ~ 0,33? M1 ist als unzureichend abzulehnen (erfüllt nicht C0-Kriterium)

Anmerkung: Dadurch ist durch White-Box-Tests der Hinweis gegeben, dass die Testfallmenge, die für den Blackbox-Tests eingesetzt wurde, unzureichend ist


11


AnweisungsAnweisungsüüberdeckungberdeckung (3) (3) –– Beispiel 2Beispiel 2Beispiel

1 public int fak(int i) {2 int[] result = new int[10];3 result[0] = 1;4 result[1] = 1;5 result[2] = 1;6-12 ...entsprechend für 3-9 mit Wert 113 if (i<=10) 14 return result[i-1];15 else return i * fak(i-1);}

Die Testfallmenge M = {fak(1) = 1} hat einen Überdeckungsgrad von 13/14 ~ 0,92? M wird als hinlänglich erachtet (erfüllt C0-Kriterium)

Es wird kein Fehler erkannt und das Testen als hinlänglich erachtet, obwohl die Funktion nur für den Wert 1 den richtigen Wert liefert!



AnweisungsAnweisungsüüberdeckungberdeckung (4)(4)

Beurteilung

• Einfache Dekomposition des Basisprogramms (detaillierte Kenntnisder Semantik der Programmiersprache nicht notwendig)

• Einfache Metrik, da Summe der Anweisungen leicht bestimmt werden kann

• Einfache Werkzeugunterstützung möglich, dass lediglich Programmzeilen protokolliert werden müssen

• Vorteil gegenüber Black-Box-Verfahren demonstriert

Aber...

• Statements eher schwacher Indikator für Güte der Tests, da die kritischen Elemente einer Applikation eher die bedingten Verzweigungen sind

• Für funktionale Tests wird (gemäss [Lichter06]) durch Anweisungs-überdeckung i.d.R. nur ein Überdeckungsgrad von ~70% erreicht, d.h. Bestimmung einer hinlänglichen Testfallmenge nicht trivial


12


ZweigZweigüüberdeckung berdeckung (1)(1)

Zweigüberdeckung (auch C1-Test genannt) dekomponiert das Programm entlang der Zweige (bei bedingten Verzweigungen wie if, while, switch, etc.)• Testfälle sind so zu wählen, dass alle Pfade im

System durch Testfälle überdeckt sind (C1-Kriterium)


Überdeckungsgrad C1= ? überdeckte Zweige

? aller Zweige in Programm


ZweigZweigüüberdeckung berdeckung (2) (2) -- Beispiel 1Beispiel 1

Beispiel1 public int fak(int i) {2 int[] result = new int[10];3 result[0] = 1;4 result[1] = 1;5 result[2] = 1;6-12 ...entsprechend für 3-9 mit Wert 113 if (i<=10) 14 return result[i-1];15 else return i * fak(i-1);}

Es existieren 2 Verzweigungen im System (Zeile 14 und Zeile 15)

Die Testfallmenge M = {fak(1) = 1} hat einen Überdeckungsgrad von 1/2 = 0,5

? M ist abzulehnen (erfüllt das C1-Kriterium nicht)


13


ZweigZweigüüberdeckung berdeckung (3)(3)

Beurteilung

• Erweitertes White-Box-Testverfahren

• Vorteil gegenüber Anweisungsüberdeckung (demonstriert) Einfacher Metrik, leicht überschaubar

Aber...

• Dekomposition des Basisprogramms benötigt Detailkenntnisse über die Programmiersprache

• In objektorientierten Programmiersprachen bedingte Verzweigungen manchmal „schwer ersichtlich“, bzw. statisch nicht prüfbar (bedingt durch spätes Binden)

• Schleifen werden nicht zuverlässig getestet, da einmaliges Eintreten in Schleifenkörper bereits Körper als getestet markiert

• Für funktionale Tests wird durch Zweigüberdeckung (gemäß[Lichter06]) i.d.R. ein Überdeckungsgrad von ~80% erreicht, d.h. Bestimmung einer hinlänglichen Testfallmenge nicht trivial



Testen von Software3. Zusammenfassung

14


Zusammenfassung und Aussicht Zusammenfassung und Aussicht (1)(1)

Motivation für Softwaretests und grundlegende Überlegungen zu Softwaretests• Testen zur Erkennung von Fehlern• Diskussion von vollständigem vs.

unvollständigem Testen• Abstrakte Beschreibung des Testprozesses

Fokus auf Testfallbestimmung• Black-Box vs. White-Box Tests• White-Box-Tests

AnweisungsüberdeckungZweigüberdeckung

3. Zusammenfassung


Zusammenfassung und Aussicht Zusammenfassung und Aussicht (2)(2)

Weitere Techniken zur Testfallbestimmung in Literatur bekannt (siehe insbesondere [Ligg02]

und [GJM02])Nicht diskutiert• Weitere Formen des White-Box-Testens• Automatisierte Techniken zur Findung von

Testfällen• Diskussion der unterschiedlichen Ebenen des

Testens (Schlagworte: Integrationstests, Unittests, etc.)

• Diskussion zum Testen von Grafischen Umgebungen, Lasttests

3. Zusammenfassung

15


Literatur und weitere ReferenzenLiteratur und weitere Referenzen (1)(1)

Literatur[GJM02] Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli;

Fundamentals of Software Engineering, Prentice Hall, 2. Ausgabe, 2002

[Ligg02] Peter Liggesmeyer: Software-Qualität – Testen, Analysieren und Verifizieren von Software, Spektrum, 2002.

[Lichter06] Lichter: Systematische Softwareentwicklung, Vorlesungsskript, RWTH Aachen, Wintersemester 2006.

[Myer79] Glenford J. Myers: The Art of Software Testing, John Wiley and Sons, 1979

[Somm01] Ian Sommerville: Software Engineering, Pearson Education, 6. Auflage, 2001

4. Literatur


Literatur und weitere ReferenzenLiteratur und weitere Referenzen (2)(2)

(Kleine) Auswahl an Freien Java-WerkzeugenJUnit – Frei verfügbares Werkzeug, dass wahrscheinlich am häufigsten zu Black-box-Tests verwendet wirdhttp://www.junit.org/

Coverlipse - Frei verfügbares Werkzeug (Eclipse Plugin auf JUnitbasierend) zur Überprüfung von Anweisungsüberdeckung, leider nur bis Eclipse Version 3.2 verfügbarhttp://coverlipse.sourceforge.net/index.php

Emma - Frei verfügbares Werkzeug zur Überprüfung von Anweisungsüberdeckunghttp://emma.sourceforge.net/

4. Literatur

16

University of Duisburg University of Duisburg –– Essen (Germany) Essen (Germany) Institute Institute forfor Computer Science and Computer Science and Business Information SystemsBusiness Information Systems

Testen von Software

Dr. Stefan HanenbergUniversität Duisburg-Essen

Universität Osnabrück, 17.11.2006


AnweisungsAnweisungsüüberdeckungberdeckung (2) (2) –– Beispiel 1Beispiel 1

Programm1 public int fak(int i) {2 if (i==1) 3 return 1 4 else return i*fak(i-1);5 }

Zeilen 2-4 repräsentieren die Zerlegung des Programms (Anmerkung: weder Zeile 1 noch Zeile 5 stellen Anweisungen in Java dar)

• Testfallmenge M1 = {fak(1) = 1} hat Überdeckungsgrad von 2/3 ~ 0,66, da Zeile 3 bei keinem Durchlauf erreicht wird

? Die Testfallmenge M1 ist als unzureichend abzulehnen

• M2={fak(1) = 1, fak(1) = 2} hat Überdeckungsgrad von 1

? Die Testfallmenge M2 wird als hinlänglich erachtet


17



Beispiel: 2 Versionen der Methode fak• Version 1

public int fak(int i) {if (i==1) return 1 else return i*fak(i-1);}

• Version 2public int fak(int i) {

if (i==1) return 0 elseif (i==2) return 1 else...Ergebnisse für 3 und 4...if (i==5) return 120 elsereturn i * fak(i-1);}

• Aus Sicht des White-Box-Testings sind beide Methoden strukturell (deutlich) unterschiedlich, so dass aus beiden Methoden unterschiedliche Testfälle resultieren


Documents

Testen von Software - dawis.wiwi.uni-due.de · 2 Stefan Hanenberg, Testen von Software, SE-Vorlesung, Osnabrück, 17.11.2006 3 Testen von Software 1. Motivation und Eigenschaften