Upload
conradine-hense
View
108
Download
1
Embed Size (px)
Citation preview
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20Geoinformation3
Geoinformation III
Korrektheit von Programmen –
Testen
Vorlesung 9a
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20Geoinformation3
1
• Korrektheit von Programmen• Zuverlässigkeit und Robustheit• Wie stellt man Korrektheit sicher?
– Verifikation– Testen
• Testen– Prinzipien– Auswahl der Testmenge– Überdeckung– Black-Box vs. White-Box
• Fehlerlokalisierung
Überblick
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20Geoinformation3
2
• Ein Programm heißt korrekt, wenn es sich gemäß seiner Spezifikation verhält.
• Spezifikation: das, was das Programm tun soll
Korrektheit von Programmen: Definition
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20Geoinformation3
Spezifikation
3
Bsp. Fakultät (aus Diskreter Mathe, 1. Sem.)
0n,1)!(n*n
0n1,n!
int fak(int n){ if(n==0) return 1; else if (n>0) return n * fak(n-1); else return -1;}
ProgrammInput: natürliche Zahl n (n 0)
Output:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20Geoinformation3
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
4
Bsp. Scan-Line (aus Diskreter Mathe, 2. Sem.)
Spezifikation
SeiT = Endpunkte der Segmente von S nach x-Koordinaten sortiert (Haltepunkte)L = // aktive Segmente von Swhile T do{
......}
Programm
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20Geoinformation3
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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20Geoinformation3
6
Verwandte Qualitätskriterien
• Zuverlässigkeit"man kann sich auf das Programm verlassen"
• RobustheitProgramm reagiert auch in nicht vorhergesehenen Situationen angemessen, z.B. bei falschen Eingaben, Plattencrashs, Netzwerkausfällen– nicht vorhergesehen = nicht von Spezifikation erfasst
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20Geoinformation3
7
Ist das Programm "Fakultät" korrekt?
Spezifikation
0n,1)!(n*n
0n1,n!
int fak(int n){ if(n==0) return 1; else if (n>0) return n * fak(n-1); else return -1;}
ProgrammInput: natürliche Zahl n (n 0)
Output:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20Geoinformation3
8
Ist das Programm "Fakultät" korrekt?
Spezifikation
int fak(int n){ ...}
ProgrammInput: natürliche Zahl n (n 0)
Output: ...
• 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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20Geoinformation3
Wie weist man Korrektheit nach?
1. 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)
1. Testen:Nachweis, dass P(i) = S(i) für eine endliche (praktikabel kleine) Teilmenge von I gilt Ausprobieren
9
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20Geoinformation3
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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20Geoinformation3
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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20Geoinformation3
12
Mit Tests kann man nur die Anwesenheit,
nie jedoch die Abwesenheit von Fehlern beweisen.
E. Dijkstra
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20Geoinformation3
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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20Geoinformation3
14
Testen: Vorgehen
1. Testmenge T bestimmen2. Programm P mit allen Testwerten t aus T laufen lassen3. Jedes Ergebnis P(t) mit Spezifikation S(t) vergleichen4. Falls Abweichung,
a. Fehler lokalisierenb. Fehler behebenc. Testen des korrigierten Programms (gehe zu 1.)
• Schwieriges Problem: Ermittlung der Testmenge
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20Geoinformation3
15
//Beispiel: Maximum zweier Zahlen x und yint maximum;if (x > y)
then maximum = x;else maximum = x;
A 2x
Einfluss der Größe der Testmenge
Fehler nicht aufgedeckt
Fehler aufgedeckt
Testmenge 2:x = 3 ; y = 2x = 2 ; y = 3
Testmenge 1:x = 3 ; y = 2
x = 4 ; y = 3x = 5 ; y = 1x = 6 ; y = 4
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20Geoinformation3
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]
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20Geoinformation3
17
• 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?
Ideale Testmengen
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20Geoinformation3
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)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20Geoinformation3
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:
1. Anweisungsüberdeckung 2. Kantenüberdeckung3. Bedingungsüberdeckung4. Pfadüberdeckung
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20Geoinformation3
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;
A 1x
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