Korrektheit von Programmen – Testen Geoinformation III Vorlesung 9a Korrektheit von Programmen – Testen

Überblick Korrektheit von Programmen Zuverlässigkeit und Robustheit 1 Überblick Korrektheit von Programmen Zuverlässigkeit und Robustheit Wie stellt man Korrektheit sicher? Verifikation Testen Prinzipien Auswahl der Testmenge Überdeckung Black-Box vs. White-Box Fehlerlokalisierung

Korrektheit von Programmen: Definition 2 Korrektheit von Programmen: Definition Ein Programm heißt korrekt, wenn es sich gemäß seiner Spezifikation verhält. Spezifikation: das, was das Programm tun soll

Input: natürliche Zahl n (n  0) 3 Bsp. Fakultät (aus Diskreter Mathe, 1. Sem.) Spezifikation Programm Input: natürliche Zahl n (n  0) Output: int fak(int n) { if(n==0) return 1; else if (n>0) return n * fak(n-1); else return -1; }

Bsp. Scan-Line (aus Diskreter Mathe, 2. Sem.) 4 Bsp. Scan-Line (aus Diskreter Mathe, 2. Sem.) Spezifikation Programm Input: Eine Menge S von Segmenten im 2D mit folgenden Einschränkungen: 2 Segmente schneiden sich höchstens in einem Punkt in keinem Punkt schneiden sich mehr als 2 Segmente die x-Koordinaten aller Segmente sind paarweise verschieden kein Segment ist vertikal ....... Output: die Schnittpunkte der Segmente in S Sei T = Endpunkte der Segmente von S nach x-Koordinaten sortiert (Haltepunkte) L =  // aktive Segmente von S while T   do { ...... }

Korrektheit: Formalisierung 5 Korrektheit: Formalisierung zu lösendes Problem mit Inputmenge I Spezifikation S: I  O ordnet jedem Input i  I den Output o = S(i)  O zu Programm P: I  O ordnet jedem Input i  I den Output o = P(i)  O zu P ist korrekt, wenn S(i) = P(i) für alle i  I gilt

Verwandte Qualitätskriterien 6 Verwandte Qualitätskriterien Zuverlässigkeit "man kann sich auf das Programm verlassen" Robustheit Programm reagiert auch in nicht vorhergesehenen Situationen angemessen, z.B. bei falschen Eingaben, Plattencrashs, Netzwerkausfällen nicht vorhergesehen = nicht von Spezifikation erfasst

Input: natürliche Zahl n (n  0) 7 Ist das Programm "Fakultät" korrekt? Spezifikation Programm Input: natürliche Zahl n (n  0) Output: int fak(int n) { if(n==0) return 1; else if (n>0) return n * fak(n-1); else return -1; }

Input: natürliche Zahl n (n  0) 8 Ist das Programm "Fakultät" korrekt? Spezifikation Programm Input: natürliche Zahl n (n  0) Output: ... int fak(int n) { ...} n kann beliebig groß werden "Unendlichkeit der Mathematik" n maximal 231 (int in Java) Endlichkeit der Zahlendarstellung Input: nat. Zahl n (0  n  231)? n! > 231 für n = 231 Input: nat. Zahl n mit n!  231? In Zwischenschritt der Berechnung könnte Zahl > 231 auftreten

Wie weist man Korrektheit nach? 9 Wie weist man Korrektheit nach? Verifikation: Formaler Beweis, dass P(i) = S(i) für alle i  I gilt (d.h. dass das Programm P seine Spezifikation S für jeden erlaubten Input i erfüllt) Testen: Nachweis, dass P(i) = S(i) für eine endliche (praktikabel kleine) Teilmenge von I gilt  Ausprobieren

10 Verifikation I Mathematischer Beweis der Äquivalenz von Programm und Spezifikation Vorgehen: Verwendung von Invarianten und Hoare-Tripeln (vgl. Vorlesung Nr. 6 über UML/OCL): {Vorbedingung} , {Prozedur} , {Nachbedingung} Schrittweises Herleiten der Gültigkeit der Nachbedingung aus Gültigkeit der Vorbedingung und Axiomatisierung der Prozedur bis Gültigkeit der Spezifikation gezeigt ist

Verifikation II Voraussetzungen: 11 Verifikation II Voraussetzungen: Spezifikation muss formalisiert vorliegen Semantik von Programmkonstrukten der Sprache muss definiert sein Probleme: Semantik von Sprachen bisher nicht ausreichen definiert formale Beweise sind bereits bei kleinen Programmen lang und kompliziert (d.h. unübersichtlich und fehleranfällig) für größere Programme bisher nicht möglich nicht praktikabel

nie jedoch die Abwesenheit 12 Mit Tests kann man nur die Anwesenheit, nie jedoch die Abwesenheit von Fehlern beweisen. E. Dijkstra

13 Testen Zum Vorgehen gibt es kein allgemeines Verfahren, nur empirische Regeln und Prinzipien ("Man sollte ...", "Es empfiehlt sich ....") kreative Tätigkeit sehr zeitaufwendig: ca. 40% der Programmentwicklungszeit wird zum Testen verwendet

Testen: Vorgehen Testmenge T bestimmen 14 Testen: Vorgehen Testmenge T bestimmen Programm P mit allen Testwerten t aus T laufen lassen Jedes Ergebnis P(t) mit Spezifikation S(t) vergleichen Falls Abweichung, Fehler lokalisieren Fehler beheben Testen des korrigierten Programms (gehe zu 1.) Schwieriges Problem: Ermittlung der Testmenge

Einfluss der Größe der Testmenge 15 Einfluss der Größe der Testmenge //Beispiel: Maximum zweier Zahlen x und y int maximum; if (x > y) then maximum = x; else maximum = x; Fehler nicht aufgedeckt Fehler aufgedeckt Testmenge 1: x = 3 ; y = 2 x = 4 ; y = 3 x = 5 ; y = 1 x = 6 ; y = 4 Testmenge 2: x = 3 ; y = 2 x = 2 ; y = 3 A 2x

Prinzipien bei Auswahl der Testmenge 16 Prinzipien bei Auswahl der Testmenge sowohl typische als auch untypische Werte, Rand- und Grenzwerte, Extremwerte: z.B. beim Zugriff auf Arrays: Test der unteren und oberen Arraygrenze, leeres Array z.B. beim Sortieren einer Liste: aufsteigend sortierte Liste [1,2,7,9,11] absteigend sortierte Liste [11,9,7,2,1] leere Liste [ ] Liste mit einem Element [5] Liste mit identischen Elementen [66,66,66,66]

17 Ideale Testmengen eine Testmenge T zu einem Programm P mit Spezifikation S heißt ideal, wenn gilt: P ist korrekt bzgl. S genau dann, wenn P für alle Elemente aus T korrekte Ergebnisse liefert. Zu jedem Programm P gibt es eine ideale Testmenge Wie findet man diese?

Prinzip der totalen Überdeckung 18 Prinzip der totalen Überdeckung Gesucht: Möglichst ideale Testmenge Eingabemenge des Programms zerfällt in disjunkte Klassen, die sich jeweils ähnlich verhalten Testmenge soll genau einen Repräsentanten jeder Klasse enthalten Beispiel: Programm "Maximum": maximum(x,y) {if (x  y) then max = x; else max = y;} Klasse 1: x  y, Repräsentant: (x = 5 ; y = 4) Klasse 2: x < y, Repräsentant: (x = 3 ; y = 6)

Empirisches Test-Prinzip "Überdeckung" 19 Empirisches Test-Prinzip "Überdeckung" Ziel: Approximation der totalen Überdeckung wähle Testmenge so, dass "möglichst alle" Teile des Programms durchlaufen werden Motivation: wenn Teile nicht durchlaufen werden, dann wird der Fehler dort bestimmt nicht gefunden Vier Arten: Anweisungsüberdeckung Kantenüberdeckung Bedingungsüberdeckung Pfadüberdeckung

1. Anweisungsüberdeckung 20 1. Anweisungsüberdeckung wähle Testmenge so, dass jede Anweisung mindestens einmal durchlaufen wird Beispiel: GGT(x,y) while x  y { if (x > y) then x = x - y; else y = y - x; } return x; wird nicht erreicht (x=3;y=4), (x=4;y=3) erfüllt Kriterium (x=3;y=3), (x=3;y=4) erfüllt Kriterium nicht A 1x