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