Testen von Software. Dr. Stefan Hanenberg Universität Duisburg-Essen. Universität Osnabrück, Motivation und grundlegende Eigenschaften

Transkript

1 University of Duisburg Essen (Germany) Institute for Computer Science and Business Information Systems Testen von Software Dr. Stefan Hanenberg Universität Duisburg-Essen Universität Osnabrück, Übersicht 1. Motivation und grundlegende Eigenschaften Motivation für Softwaretests Vollständiges vs. unvollständiges Testen Ablauf von Softwaretests Black-Box-Testing White-Box-Testing Anweisungsüberdeckung Zweigüberdeckung 3. Zusammenfassung 4. Literatur und weitere Referenzen 2

2 Testen von Software 1. Motivation und Eigenschaften von Softwaretests 3 Motivation für f r Softwaretests Wichtiges 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 1. Motivation und Grundlegende Eigenschaften 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 4

3 Einordnung in Entwicklungsprozess In 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 1. Motivation und Grundlegende Eigenschaften 5 Grundlegende Idee 1. Motivation und Grundlegende Eigenschaften 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 werden Testdurchführung soll möglichst klein gehalten werden 6

4 Vollständiges Testen Beispiel Die unten beschriebene Java-Klasse MyMathFunctions soll hinsichtlich ihrer beiden Methoden getestet werden public class MyMathFunctions { //Fakultät der Zahl i public int fak(int i) {...} // Grösster gemeinsamer Teiler von i, j und k public int ggt(int i, int j, int k) {...} } Vollständiges Testen Wertebereich Integer in Java von bis mögliche Eingaben für fak, 2 32 x 2 32 x 2 32 = 2 96 für ggt 1,5 * 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 1. Motivation und Grundlegende Eigenschaften 7 Unvollständiges ndiges Testen 1. Motivation und Grundlegende Eigenschaften Probleme 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 Protokollierung Anmerkung Im Folgenden impliziert die Verwendung des Terms Test immer das unvollständige Testen 8

5 Ablauf von Softwaretests 1. Motivation und Grundlegende Eigenschaften Quelle: [Somm01] Testfälle Testdaten Testergebnisse Testprotokolle I. Entwerfen der Testfälle II. Erstellen der Testdaten III. Ausführen des Programms mit Testdaten IV. Vergleich der Ergebnisse mit Testfällen Aktivitäten = Artefakte = Aktivitäten I. 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) 9 Fragestellungen bei Tests Welche Arten von Fehlern existieren? 1. Motivation und Grundlegende Eigenschaften 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 10

6 Testen von Software 11 Testfallbestimmung - Einführung Die Testfallbestimmung befasst sich mit systematischen Techniken zur Gewinnung von Testfällen Unterschiedliche Techniken haben Unterschiedlichen Aufwand bei Spezifikation Unterschiedlichen Aufwand bei Durchführung der Tests Unterschiedliche Erfolgsaussichten zur Findung von Fehlern Sehr große Anzahl an Testverfahren bekannt, so dass die Vorlesung nur sehr oberflächlich in die Thematik einführen kann Abschließende Klassifizierung von Verfahren zur Testfallbestimmung nicht möglich, da noch immer Gegenstand der Forschung 12

7 Klassifizierung Äquivalenzklassenanalyse vgl. [Ligg02] Testfallbestimmung Black-Box- Tests White-Box- Tests Stochastische Verfahren Grenzwertanalyse... Datenflußanalyse... Ablaufgraphüberdeckung Anweisungsüberdeckung Pfadüberdeckung... Im Folgenden näher erläutert (siehe auch [GJM02]) Black-Box-Testing White-Box-Testing 13 Black-Box Box-Testing (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 i public int fak(int i) {...}...} Ableitung der Testfälle aus Spezifikation von fak fak(5) = 120, fak(6) = 720, fak(10) = ,... 14

8 Black-Box Box-Testing (2) - Beispiel Beispiel public class MyMathFunctions { //Fakultät der Zahl i public int fak(int i) { if (i==1) return 0 else if (i==2) return 1 else...ergebnisse für 3 und 4... if (i==5) return 120 else return 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) = , etc. unerkannt Problem: Brisanz der if-ausdrücke ist dem Tester verborgen 15 Black-Box Box-Testing (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 genutzt Beurteilung 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 16

9 White-Box Box-Testing (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 programmiersprachliche Elemente wirken sich unterschiedlich auf erstellte Testfälle aus Bewertung der Güte der Testfälle stützt sich auf Programmstruktur 17 White-Box Box-Testing (2) 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 überdecken Unterschiedliche Ausprägungen Anweisungsüberdeckung Zweigüberdeckung Pfadüberdeckung...und weitere... Beurteilung des White-Box-Testens abhängig von eingesetztem Verfahren 18

10 Anweisungsüberdeckung (1) Anweisungsüberdeckung (auch C 0 -Test genannt) stellt den einfachsten Fall der White-Box-Tests dar Die 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 (C 0 -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 C 0 =? überdeckte Anweisungen? Anweisungen in Programm 19 Anweisungsüberdeckung (2) Beispiel 1 Beispiel 1 public int fak(int i) { 2 if (i==1) return 0 else 3 if (i==2) return 1 else Ergebnisse für 3 und if (i==5) return 120 else 7 return i * fak(i-1);} Die Testfallmenge M 1 = {fak(5) = 120, fak(6) = 720, fak(10) =... } hat einen Überdeckungsgrad von 2/6 ~ 0,33? M 1 ist als unzureichend abzulehnen (erfüllt nicht C 0 -Kriterium) Anmerkung: Dadurch ist durch White-Box-Tests der Hinweis gegeben, dass die Testfallmenge, die für den Blackbox-Tests eingesetzt wurde, unzureichend ist 20

11 Anweisungsüberdeckung (3) Beispiel 2 Beispiel 1 public int fak(int i) { 2 int[] result = new int[10]; 3 result[0] = 1; 4 result[1] = 1; 5 result[2] = 1; entsprechend für 3-9 mit Wert 1 13 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 C 0 -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! 21 Anweisungsüberdeckung (4) Beurteilung Einfache Dekomposition des Basisprogramms (detaillierte Kenntnis der 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 22

12 Zweigüberdeckung (1) Zweigüberdeckung (auch C 1 -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 (C 1 - Kriterium) Überdeckungsgrad C 1 =? überdeckte Zweige? aller Zweige in Programm 23 Zweigüberdeckung (2) - Beispiel 1 Beispiel 1 public int fak(int i) { 2 int[] result = new int[10]; 3 result[0] = 1; 4 result[1] = 1; 5 result[2] = 1; entsprechend für 3-9 mit Wert 1 13 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 C 1 -Kriterium nicht) 24

13 Zweigüberdeckung (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 25 Testen von Software 3. Zusammenfassung 26

14 Zusammenfassung und Aussicht (1) 3. Zusammenfassung 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überdeckung Zweigüberdeckung 27 Zusammenfassung und Aussicht (2) 3. Zusammenfassung 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 28

15 Literatur und weitere Referenzen (1) Literatur [GJM02] [Ligg02] 4. Literatur Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli; Fundamentals of Software Engineering, Prentice Hall, 2. Ausgabe, 2002 Peter Liggesmeyer: Software-Qualität Testen, Analysieren und Verifizieren von Software, Spektrum, [Lichter06] Lichter: Systematische Softwareentwicklung, Vorlesungsskript, RWTH Aachen, Wintersemester [Myer79] Glenford J. Myers: The Art of Software Testing, John Wiley and Sons, 1979 [Somm01] Ian Sommerville: Software Engineering, Pearson Education, 6. Auflage, Literatur und weitere Referenzen (2) (Kleine) Auswahl an Freien Java-Werkzeugen JUnit Frei verfügbares Werkzeug, dass wahrscheinlich am häufigsten zu Black-box-Tests verwendet wird Coverlipse - Frei verfügbares Werkzeug (Eclipse Plugin auf JUnit basierend) zur Überprüfung von Anweisungsüberdeckung, leider nur bis Eclipse Version 3.2 verfügbar Emma - Frei verfügbares Werkzeug zur Überprüfung von Anweisungsüberdeckung 4. Literatur 30

16 University of Duisburg Essen (Germany) Institute for Computer Science and Business Information Systems Testen von Software Dr. Stefan Hanenberg Universität Duisburg-Essen Universität Osnabrück, Anweisungsüberdeckung (2) Beispiel 1 Programm 1 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 M 1 = {fak(1) = 1} hat Überdeckungsgrad von 2/3 ~ 0,66, da Zeile 3 bei keinem Durchlauf erreicht wird? Die Testfallmenge M 1 ist als unzureichend abzulehnen M 2 ={fak(1) = 1, fak(1) = 2} hat Überdeckungsgrad von 1? Die Testfallmenge M 2 wird als hinlänglich erachtet 32

17 White-Box Box-Testing (2) 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 2 public int fak(int i) { if (i==1) return 0 else if (i==2) return 1 else...ergebnisse für 3 und 4... if (i==5) return 120 else return 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 33