Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "Telecooperation/RBG Technische Universität Darmstadt Copyrighted material; for TUD student use only Grundlagen der Informatik 1 Thema 19: Testverfahren."—  Präsentation transkript:

1

2 Telecooperation/RBG Technische Universität Darmstadt Copyrighted material; for TUD student use only Grundlagen der Informatik 1 Thema 19: Testverfahren Prof. Dr. Max Mühlhäuser Dr. Guido Rößling

3 Dr. G. Rößling Prof. 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

4 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T19 Qualitätssicherung: Motivation Dieser 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. }

5 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T19 Qualitätssicherung: Motivation Informatik-Katastrophen Röntgengerät Therac-25 ( ) –Inkorrekte Dosierung, unklare Fehlermeldung und manuelle Kontrollmöglichkeit (manual override) –Mehrere Patienten wurden verletzt oder starben Ariane Flug 501 (1996, $ ) –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

6 Dr. G. Rößling Prof. 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 Definition Design Implemen- tierung Entfernung von Fehlern

7 Dr. G. Rößling Prof. 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 Krawattennadeln? Hunger!

8 Dr. G. Rößling Prof. 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?

9 Dr. G. Rößling Prof. 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!

10 Dr. G. Rößling Prof. 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

11 Dr. G. Rößling Prof. 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: 11 2 ist eine Primzahl, ist eine Primzahl, ist eine Primzahl, … 10 Hypothese "Alle ungeraden Zahlen größer 1 sind Primzahlen" Vorsicht! Dies ist nur Satire.

12 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T19 analytische Qualitätskontrolle Testverfahren dynamische Tests Strukturelles Testen Funktionales Testen Analysemethoden Verifikationstatische Analyse Review (z.B., Inspektion) Qualitätssicherungsmethoden 11 z.B. Java Compiler: analysiert, ob Variablen initialisiert sind und ob return Anweisungen vorhanden sind.

13 Dr. G. Rößling Prof. 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

14 Dr. G. Rößling Prof. 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)

15 Dr. G. Rößling Prof. 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. Blinns These: Jedes funktionierende Computergrafik- programm enthält eine gerade Anzahl von Vorzeichenfehlern Murphys Law

16 Dr. G. Rößling Prof. 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

17 Dr. G. Rößling Prof. 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

18 Dr. G. Rößling Prof. 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

19 Dr. G. Rößling Prof. 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.

20 Dr. G. Rößling Prof. 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

21 Dr. G. Rößling Prof. 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

22 Dr. G. Rößling Prof. 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 21

23 Dr. G. Rößling Prof. 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

24 Dr. G. Rößling Prof. 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 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; }

25 Dr. G. Rößling Prof. 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; }

26 Dr. G. Rößling Prof. 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!

27 Dr. G. Rößling Prof. 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

28 Dr. G. Rößling Prof. 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. * Effekte: der counter wird geändert. 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; }

29 Dr. G. Rößling Prof. 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

30 Dr. G. Rößling Prof. 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!

31 Dr. G. Rößling Prof. 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

32 Dr. G. Rößling Prof. 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.

33 Dr. G. Rößling Prof. 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

34 Dr. G. Rößling Prof. 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

35 Dr. G. Rößling Prof. 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!

36 Dr. G. Rößling Prof. 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

37 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T19 Testmethoden Überblick 36 Black Box Grey Box White Box strukturelles Testen funktionales Testen 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

38 Dr. G. Rößling Prof. 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

39 Dr. G. Rößling Prof. 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

40 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T19 Kontrollflussgraphen (Beispiel) 39 n ende n6 n start n2n2 n2 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 }

41 Dr. G. Rößling Prof. 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

42 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T19 Überdeckungstests 41 Anweisungsüberdeckung Pfadüberdeckung Zweigüberdeckung Bedingungsüberdeckung einfach Bedingungsüberdeckung mehrfach A B A impliziert B Übersicht...

43 Dr. G. Rößling Prof. 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: Hilft, toten Code zu finden Ist notwendig aber nicht ausreichend Besitzt wenig praktische Relevanz 42 n1n1 n2n2 n3n3 n4n4 n5n5 n6n6 n1 n2 n3 n4 n6 n start n ende n5

44 Dr. G. Rößling Prof. 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 C zweig = Anzahl der ausgeführten Zweige Anzahl der vorhandenen Zweige

45 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T19 Zweigüberdeckung (C1): Beispiel 44 n1 n2 n3 n4 n6 n start n end n5 n n n n n1 n2 n3 n4 n6 n start n end n5

46 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T19 Einfache Bedingungsüberdeckung (C2) 45 n1n1 n2n2 n3n3 n4n4 n5n5 n6n6 n1 n2 n3 n4 n6 n start n ende n5 alle atomaren Bedingungen mind. einmal true & false Der else Zweig wird nie beschritten Testfälle – 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')

47 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T19 Mehrfache Bedingungsüberdeckung 46 n1n1 n2n2 n3n3 n4n4 n5n5 n6n6 n1 n2 n3 n4 n6 n start n ende n5 Testfälle, Zweigüberdeckung enthalten Kombinationsexplosion: N atomare Bedingungen 2 N Möglichkeiten Kombinationen teilweise unmöglich! –Auswertung wird eventuell abgebrochen (Lazy-Evaluation = nicht-strikte Auswertung) Alle Kombinationen von atomaren Bedingungen abdecken

48 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T19 Pfadüberdeckung (C7) 47 n1n1 n2n2 n3n3 n4n4 n5n5 n6n6 n1 n2 n3 n4 n6 n start n ende n5 Testfälle –,,, … Zweigüberdeckung enthalten Schleifen führen praktisch zu unendlichen vielen Testfällen Höchste Erfolgsaussichten, aber völlig unpraktikabel Alle Kombinationen von Zweigen abdecken

49 Dr. G. Rößling Prof. 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

50 Dr. G. Rößling Prof. 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

51 Dr. G. Rößling Prof. 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

52 Dr. G. Rößling Prof. Dr. M. Mühlhäuser RBG / Telekooperation © Grundlagen der Informatik I: T19 51 Black Box Grey Box White Box strukturelles Testen funktionales Testen Grenzwert- analyse kontrollfluss- orientierter Test Äquivalenz- klassenbildung Benutzungs- fälle überprüfen Zufallstest datenfluss- orientierter Test Testklassifizierung nach benötigter Information Testmethoden im Überblick

53 Dr. G. Rößling Prof. 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:VokalKonsonantkein Buchstabe –Repräs.: E T % –Klassen: x 5 –Repräs.:

54 Dr. G. Rößling Prof. 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 5 –Repräs.: -1 0 und

55 Dr. G. Rößling Prof. 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

56 Dr. G. Rößling Prof. 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

57 Dr. G. Rößling Prof. 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

58 Dr. G. Rößling Prof. 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

59 Dr. G. Rößling Prof. 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

60 Dr. G. Rößling Prof. 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


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

Ähnliche Präsentationen


Google-Anzeigen