Qualit¨atssicherung in der Softwareentwicklung VU 2 DI Dr. Bernhard K. Aichernig

(1)

Herausforderung Software Testen Spezifikationen Invarianten

Qualit¨ atssicherung in der Softwareentwicklung

VU 2

DI Dr. Bernhard K. Aichernig

Institut f¨ur Softwaretechnologie (IST) TU Graz

Sommersemester 2012

(2)

Ubersicht der Vorlesung ¨

1 Herausforderung Software Testen

2 Spezifikationen Beispiel

Eigenschaften von Spezifikationen Java Modeling Language

3 Invarianten

(3)

Herausforderung Software Testen

Korrektheit Anforderungen Entwicklungsprozeß

(4)

Testen und Korrektheit

“Testing can only demonstrate the presence of errors, not their absence” (E. Dijkstra, 1972)

Grund: diskrete Natur von Software

Testen mit allen möglichen Eingaben wäre notwendig Exhaustive testing ist nicht durchführbar

Repräsentative Testfälle müssen ausgewählt werden (Teststrategie)

(5)

Testen und Anforderungen

Qualität des Testens hängt stark von Qualität der Anforderungsdokumente ab.

Anforderungen, die nicht dokumentiert sind, k¨onnen nicht systematisch getestet werden.

60 % aller Fehler in der Anforderungsphase, sind durch fehlende Anforderungen verursacht.

Anforderungen in nat¨urlicher Sprache geschrieben sind oft unvollst¨andig

mehrdeutig widerspr¨uchlich

formale Spezifikationen (Modelle)!

(6)

Testen im Entwicklungsprozeß

Im klassischen Wasserfallmodell ist das Testen die letzte Phase.

Gefahr: Wenn sich Projekte verz¨ogern, wird oft die Testphase verk¨urzt.

Dramatisch: die meisten großen SW-Projekte ¨uberziehen ihren Zeitplan!

Konsequenz: die Testfälle müssen so früh wie möglich

entworfen werden, sobald die SW-Anforderungen bekannt sind.

das f¨uhrte zuAgilen Software-Prozessen

Hoher Testaufwand! 1/3 – 1/2 der Resourcen in großen Projekten

(7)

Selbsttest

Write a set of test cases that you feel would adequately test this program (Myers, The Art of Software Testing):

The program reads three integer values from an input stream.

The three values are interpreted as representing the lengths of the sides of a triangle.

The program prints a message that states whether the triangle is scalene, isosceles, or equilateral.

(8)

Selbsttest: Fragen

Do you have ...

1 a test case that represents a validscalene triangle? Test cases (1,2,3) and (2,5,10) are not valid.

2 a test case that represents a valid equilateral triangle?

3 a test case that represents a valid isosceles triangle?

4 at least three test cases that represent valid isosceles triangles such that you have tried all three permutations of two equal sides (e.g., (3,3,4), (3,4,3), and (4,3,3))?

5 a test case in which one side has a zero value?

6 a test case in which one side has a negative value?

7 a test case with three integers greater than zero such that the sum of two of the numbers is equal to the third?

(9)

Selbsttest: Fragen (cont.)

8 at least three test cases in Category 7 such that you have tried all three permutations where the length of one side is equal to the sum of the lengths of the other two sides (e.g., (1,2,3), (1,3,2), and (3,1,2))?

9 a test case with three integers greater than zero such that the sum of two of the numbers is less than the third (e.g.,

(1,2,4))

10 at least three test cases in Category 9 such that you have tried all three permutations (e.g., (1,2,4), (1,4,2), and (4,1,2))?

11 a test case in which all sides are zero?

12 at least one test case specifying noninteger values?

13 at least one test case specifying the wrong number of values?

14 for each test case the expected outputs specified?

(10)

Beispiel

Spezifikationen

Spezifikationen legen die Kriterien fest, unter denen ein Programm akzeptiert wird.

Grundlage eines Vertrages zw. HerstellerundAuftraggeber größtmögliche Freiheit für den Hersteller

Es wird festgelegt was erreicht werden soll aber nichtwie Programme eignen sich nicht als Spezifikationen

(11)

Beispiel

Spezifikation — Implementierung

Spezifikation vs. Implementierung

abstrakt konkret

was wie

(12)

Beispiel

Spezifikation — Implementierung (cont.)

1 Die Spezifikation dient als Ausgangspunkt zum Entwurf der Implementierung.

2 Die Spezifikation dient als Basis der Verifikation:

1 zum Nachweis, daß eine Implementierung die Spezifikation erf¨ullt,

2 zur Ableitung von Testf¨allen.

(13)

Beispiel

Programm als Spezifikation?

public static double P (double tFactorial) { double x1=0;

double x0=tFactorial/2;

double a=tFactorial;

boolean finished=false;

while (finished==false) {

x1=(x0+(a/x0))/2;

if (x1>x0){

if ((x1-x0)<0.00005){

finished=true;}

}

else if (x0>x1){

if ((x0-x1)<0.00005){

finished=true;}

} x0=x1;

}

return x1;

}

(14)

Beispiel

Spezifikation Vers. 1

Example (Nachbedingung)

Nachbedingung (postcondition):

post_P(in,out), out² =in

(15)

Beispiel

Spezifikation Vers. 2

Nicht alle Eingaben sind g¨ultig!

Example (Vor-Nachbedingung) Nachbedingung (postcondition):

post_P(in,out), out² =in Vorbedingung (precondition):

pre_P(in), in≥0

(16)

Beispiel

Spezifikation Vers. 3

Wir sind nur an positiven Ergebnissen interessiert!

post_P(in,out), out²=in ∧ out≥0 Vorbedingung (precondition):

pre_P(in), in≥0

(17)

Beispiel

Spezifikation Vers. 4

Das Ergebnis soll eine Approximation sein!

post_P(in,out), abs(in−out²)≤∗in ∧ out≥0 Vorbedingung (precondition):

pre_P(in), in≥0 . . . Fehlerkonstante

abs. . . Absolutbetrag

(18)

Beispiel

L¨ osungen

Um sinnvoll zu sein, muß es zu einer Spezifikation mindestens eine L¨osunggeben.

D.h. es muß mindestens ein Programm/Systemgeben, das die Spezifikation erf¨ullt.

Es muß ein (semantisches) Modellder Spezifikation geben.

Anders formuliert: das spezifizierte System muß realisierbar sein.

(19)

Beispiel

Abstraktion

Spezifikationen sollen abstrakt sein.

Spezifikationen m¨ussen nicht immer eindeutige L¨osungen verlangen.

z.B. Flugreservierungssystem Compiler

Mehrere Ergebnisse sind m¨oglich.

wird auchUnterspezifikationgenannt (eine Form von Abstraktion).

(20)

Beispiel

Genauigkeit

Eine Spezifikation muß genau sein.

D.h. es muß die Menge der zugelassenen L¨osungen (Modelle) festgelegt sein.

Daß eine Spezifikation keine eindeutige L¨osung bestimmen muß, bedeutet keineswegs, daß wir ungenaue Spezifikationen zulassen.

Es muß sorgf¨altig zwischen den Attributenungenau und abstrakt unterschieden werden.

(21)

Beispiel

Design by Contract

Eine Methode der Software-Entwicklung.

Vor- und Nachbedingungen als Kontrakt zwischen Klassen und Benutzern (Clients).

Vor- und Nachbedingungen sind ausf¨uhrbar.

Geschichte: Hoare-Logik (1969), VDM (70-iger), Eiffel (1992), JML(1999)

(22)

Beispiel

Java Modeling Language (JML)

Example (sqrt)

public final static double eps = 0.0001;

//@ requires x >= 0.0;

//@ ensures JMLDouble.approximatelyEqualTo(x, \result * \result, eps);

public static double sqrt(double x) { return Math.sqrt(x);

}

Vorbedingung:requires

(normale) Nachbedingung: ensures

(23)

Beispiel

Vorteile von JML

zur Dokumentation (Spezifikation) von Java Klassen und Interfaces

Kontrakt abstrakterals Code (kein Algorithmus!)

Kontrakt kann maschinell gepr¨uftwerden (im Gegensatz zu informalen Kommentaren)

Fehlersuche (debugging) Wartung

Schuldzuweisung bei Fehlern: Client vs. Class

Effizienz: Keine ineffizienten defensiven ¨Uberpr¨ufungen (checks) im Code

(24)

Beispiel

Beispiel Effizienz

Example (Bin¨arsuche)

/*@ requires a != null

@ && (\forall int i;

@ 0 < i && i < a.length;

@ a[i-1] <= a[i]);

@*/

int binarySearch(int[] a, int x) { // ...

}

All-quantor (∀):\forall

Endliche Bereichsangabe f¨ur imacht den Ausdruck ausf¨uhrbar.

Eine alternative Pr¨ufschleife im Endprogramm w¨are ineffizient:

Laufzeit:logarithmisch⇒linear

(25)

Beispiel

Modularit¨ at des Programmverstehens

Wie kann man solchen Code verstehen?

Example (Typischer OO Code)

...

source.close();

target.close();

getFile.setLastModified(

loc.modTime().getTime());

return modTime();

M¨oglichkeit 1:Lesen des Codes aller Methoden, lesen des Codes aller Methoden in den Methoden, lesen des. . .

Erschwernis: Subtypen polymorphismus (dynamische Bindung) M¨oglichkeit 2:Lesen der Kontrakte aller Methoden

(26)

Beispiel

JML Features

Ausdrucksst¨arke und Formalit¨at von modellbasierten Spezifikationssprachen: VDM-SL, Z, B, RSL. . .

Java-Syntax um Pr¨adikate zu schreiben plus Erweiterungen (Quantoren)

Tools:

Runtime-Assertion Checking Discovery of Invariants Static checking Testen

Formale Verifikation mit Beweisern (theorem provers) www.jmlspecs.org

(27)

Invarianten

Definition (Klasseninvariante, allgemein)

Eine Klasseninvariante ist eine Eigenschaft des Klassenzustandes (Variablen, Felder), die immer

nach Ausf¨uhren eines jeden Konstruktors, sowie vor und nach Ausf¨uhren einer jeden Methode gelten muß.

auch Dateninvariante oder kurz Invariante genannt.

(28)

Rolle von Invarianten

Typeninvariante: schr¨ankt einen Datentyp ein (z.B. Nat¨urliche Zahlen)

Repr¨asentationsinvariante:dokumentiert Designentscheidung der Datenrepr¨asentation (z.B. Sortierung einer Liste)

Dokumentieren Beziehungen zwischen Variablen (Feldern).

Invarianten werden durch Kapselung gesch¨utzt.

(Repr¨asentations-)invarianten sind oft f¨ur die Korrektheit eines Algorithmus notwendig.

(29)

JML Beispiel

Personpackage org.jmlspecs.samples.jmltutorial

(30)

Invarianten in JML

Definition (Klasseninvariante, JML)

Invarianten sind Eigenschaften die in allensichtbaren Zust¨anden gelten m¨ussen.

Invarianten werden vererbt.

(31)

Sichtbare Zust¨ ande

Definition (Sichtbarer Zustand eines JML Objektes)

Ein Zustand ist sichtbar f¨ur ein Objekto, in einem der folgenden Augenblicke:

am Ende eines Konstruktoraufrufs der o initialisiert,

am Beginn eines Destruktoraufrufs (Finalizer) der o beendet.

am Beginn und am Ende einer nicht-statischen Methode mito als Empf¨anger.

am Beginn und am Ende einer statischen Methode in der Klasse oder einer Superklasse von o

wenn keine der oben genannten Kon-, Destruktoren und Methoden mit o als Empf¨anger in Bearbeitung sind.

Beginn und Ende von Hilfsmethoden (helper-Deklaration) sind keine sichtbaren Zust¨ande.

(32)

Literatur

Gary T. Leavens and Yoonsik Cheon. Design by Contract with JML, Tutorial, January 2006.

http://www.jmlspecs.org/jmldbc.pdf