8 Softwareprüfung - Universität Stuttgart

ias.uni.stuttgart.de

8 Softwareprüfung - Universität Stuttgart

Softwaretechnik I

ST I

§ 8 Softwareprüfung

Lernziele

– Wissen, was man unter statischer und dynamischer Analyse versteht

– Verstehen, wozu man Reviews braucht

– Die unterschiedlichen Testformen verstehen

– Verstehen, wie ein Test geplant und durchgeführt wird

– Wissen, wie Testsysteme aufgebaut sind

© 2013 IAS, Universität Stuttgart 331


Softwaretechnik I

ST I

§ 8 Softwareprüfung

8.1 Grundlagen

8.2 Statische Verfahren

8.3 Dynamische Verfahren

8.4 Testplanung und -ausführung

8.5 Zusammenfassung

© 2013 IAS, Universität Stuttgart 332


8.1 Grundlagen

ST I

Einordnung in den Entwicklungsprozess

Problem

Requirements

Engineering

Anforderungsdefinition

(Lastenheft / Pflichtenheft)

Systemanalyse

Systemmodell

Softwareentwurf

Systemarchitektur

Implementierung

Programm

Test

© 2013 IAS, Universität Stuttgart 333


8.1 Grundlagen

ST I

Software-Qualitätssicherung

SW-Qualitätssicherung

Organisatorische

Maßnahmen

– Verantwortung

– Richtlinien

– Audits

– ...

Konstruktive

Maßnahmen

– Vorgehensmodelle

– Information Hiding

– ...

Analytische

Maßnahmen

– Softwareprüfung

– Metriken

– ...

Kontrolle organisieren

Fehler vermeiden

Fehler finden

© 2013 IAS, Universität Stuttgart 334


8.1 Grundlagen

ST I

Softwareprüfung

Statische Verfahren:

– Analyse und Prüfung der Systembeschreibungen (z. B. Anforderungen,

Entwurfsdiagramme, Quellcode, ...)

– Ausführung des Systems nicht erforderlich

– Unterschiedliche statische Verfahren

Review (Inspektion, Walkthrough)

Statische Analyse

Korrektheitsbeweis (formale Verifikation)

Dynamische Verfahren:

– Prüfen und Überwachen des Systemverhaltens gegenüber dem spezifizierten

Verhalten

– System wird mit Testdaten ausgeführt und sein Verhalten beobachtet.

– Unterschiedliche dynamische Verfahren

Testen

Simulieren

© 2013 IAS, Universität Stuttgart 335


8.1 Grundlagen

ST I

Validierung und Verifikation

Definition:

Validierung ist der Prozess der Beurteilung eines Systems mit dem Ziel

festzustellen, ob die spezifizierten Anforderungen erfüllt sind.

[IEEE 610.12]

Definition:

Verifikation ist der Prozess der Beurteilung eines Systems (bzw. Teilsystems)

mit dem Ziel festzustellen, ob die Resultate einer gegebenen

Entwicklungsphase den Vorgaben für diese Phase entsprechen.

[IEEE 610.12]

Validierung: "Erstellen wir das richtige Produkt?"

Verifikation: "Erstellen wir das Produkt richtig?"

© 2013 IAS, Universität Stuttgart 336


8.1 Grundlagen

ST I

Grundsätze der Softwareprüfung

– Softwareprüfung kann nur gegen Vorgaben (Anforderungen oder

Vergleichsresultate) erfolgen

– Prüfverfahren müssen definiert sein und reproduzierbare Ergebnisse

liefern

– Prüfergebnisse müssen dokumentiert werden

– Erkannte Fehler müssen anschließend korrigiert werden, indem die

Fehlerursachen erkannt und behoben werden

– Systematisch prüfen

Prüfung planen

Prüfungen nach Vorschriften durchführen

© 2013 IAS, Universität Stuttgart 337


8.1 Grundlagen

ST I

Planung der Softwareprüfung

– Sorgfältige Planung ist sowohl für einen guten Testprozess als auch für

einen guten Reviewprozess notwendig

– Planungen der Softwareprüfung früh im Entwicklungsprozess beginnen

– Einhaltung der Balance zwischen statischen und dynamischen Verfahren

– Testplanung definiert Aufgaben, Ziele und Strategien für die

Testausführung

Video: Softwareprüfung

© 2013 IAS, Universität Stuttgart 338


Fragen zur Vorlesung

ST I

Frage zu § 8.1

Welchen Aussagen stimmen Sie zu?

Aufgabe der Softwareprüfung ist die Lokalisierung von Fehlern

f Dynamische Verfahren können auch in sehr frühen Entwicklungsphasen

eingesetzt werden

f


Durch Verifikation kann geprüft werden, ob das Produkt den Erwartungen

des Kunden entspricht


Die Prüfdokumentation ist mindestens genauso wichtig, wie

die Prüfung selbst.

© 2013 IAS, Universität Stuttgart 339


Softwaretechnik I

ST I

§ 8 Softwareprüfung

8.1 Grundlagen

8.2 Statische Verfahren

8.3 Dynamische Verfahren

8.4 Testplanung und -ausführung

8.5 Zusammenfassung

© 2013 IAS, Universität Stuttgart 340


8.2 Statische Verfahren

ST I

Arten von statischen Verfahren

– Review

Überprüfung schriftlicher Dokumente durch Gutachter

– Code-Inspektion

Diskussion von Source-Code durch Softwareentwickler

– Statische Analyse

Werkzeuggestütztes Auffinden von Fehlern ohne direkte Ausführung

des Systems

© 2013 IAS, Universität Stuttgart 341


8.2 Statische Verfahren

ST I

Review (1)

Definition:

Ein Review ist ein mehr oder weniger formalisierter Prozess zur Überprüfung

von schriftlichen Dokumenten durch Gutachter, um Stärken und Schwächen

des Dokuments festzustellen.

[Balzert, Lehrbuch der Softwaretechnik]

Ziel der Überprüfung

– Feststellung von Mängeln, Fehler, Inkonsistenzen, Unvollständigkeiten,

Verstößen gegen Vorgaben, Richtlinien, Standards, Pläne.

– Formale Planung und Strukturierung der Bewertungsprozesse und formale

Abnahme des Prüfobjekts

© 2013 IAS, Universität Stuttgart 342


8.2 Statische Verfahren

ST I

Review (2)

Review-Arten

– Entwurfs- oder Programmreviews

Aufdeckung von Fehlern im Entwurf oder Programm

Überprüfung, ob Standards eingehalten wurden

Durchführung anhand von Checklisten

– Fortschrittsreview

Bereitstellung von Informationen über den Fortschritt des kompletten

Projekts für das Management

Prozess- und Produktreview gleichzeitig

Betrifft Kosten und Termine

– Qualitätsreview

Technische Analyse der Produktkomponenten und

Produktdokumentation

Aufdeckung von Fehlern oder Inkonsistenzen zwischen

Systemspezifikation, Entwurf, Programm und Dokumentation

© 2013 IAS, Universität Stuttgart 343


8.2 Statische Verfahren

ST I

Code-Inspektion

– Idee: der Autor eines Programms diskutiert Schritt für Schritt sein

Programm mit anderen Softwareentwicklern

– Teamstruktur

erfahrener Entwickler als Moderator

Autor des Programms

für den Test zuständige Mitarbeiter

Mitarbeiter der Qualitätssicherung

– Aufgabe des Inspektionsteams ist das Aufdecken von Fehlern, nicht die

Korrektur von Fehlern

© 2013 IAS, Universität Stuttgart 344


8.2 Statische Verfahren

ST I

Beispiel einer Checkliste für die Code-Inspektion

Zu überprüfende Punkte

Punkte werden einzeln

kommentiert und ggf. als

erledigt gekennzeichnet

Prüf- und Abnahmedaten

© 2013 IAS, Universität Stuttgart 345


8.2 Statische Verfahren

ST I

Statische Analyse (1)

– Werkzeuggestütztes Auffinden von Fehlern ohne

direkte Ausführung des Systems

syntaktische Analyse

strukturelle Analyse

semantische Analyse

– Ziel: Lokalisierung fehlerverdächtiger Stellen des Systems

– Tätigkeiten der statischen Programmanalyse

Komplexitätsanalyse

Strukturanalyse

Datenflussanalyse

© 2013 IAS, Universität Stuttgart 346


8.2 Statische Verfahren

ST I

Statische Analyse (2)

Komplexitätsanalyse

– Ermittlung von Maßzahlen für die Komplexität eines Programms

Schachtelungstiefen von Schleifen

Länge von Prozeduren und Modulen

Modulkonnektivitäten

– Lokalisierung fehlerträchtiger Stellen

– Komplexitätsmaßzahlen sind schwer objektiv zu beurteilen

© 2013 IAS, Universität Stuttgart 347


8.2 Statische Verfahren

ST I

Statische Analyse (3)

Strukturanalyse

– Aufdecken von Strukturanomalien

– Sind alle Anweisungen eines Programms vom Programmanfang

erreichbar?

– Ist das Programmende erreichbar?

– Sprünge in Schleifen

– Verwendung unerlaubter Sprachelemente

Datenflussanalyse

– Aufdecken von Datenflussanomalien

Initialisierung von Datenobjekten

Verwendung eines Datenobjekts nach einer Wertezuweisung

© 2013 IAS, Universität Stuttgart 348


Fragen zur Vorlesung

ST I

Frage zu § 8.2

Welchen Aussagen stimmen Sie zu?



Eine statische Analyse wird verwendet, um Probleme zu identifizieren.

Programmreviews werden zur Verbesserung der Programmqualität

eingesetzt.

f Programmreviews werden vom Entwickler durchgeführt.


Mit einer Strukturanalyse wird überprüft, ob es "Dead-Code" gibt.

© 2013 IAS, Universität Stuttgart 349


Softwaretechnik I

ST I

§ 8 Softwareprüfung

8.1 Grundlagen

8.2 Statische Verfahren

8.3 Dynamische Verfahren

8.4 Testplanung und -ausführung

8.5 Zusammenfassung

© 2013 IAS, Universität Stuttgart 350


8.3 Dynamische Verfahren

ST I

Live-Mitschrieb

Dijkstra:

Program testing can be a very effective way to

show the presence of bugs, but it is hopeless

inadequate for showing their absence.

Wahrscheinlichkeit der

Existenz zusätzlicher Fehler

je mehr Fehler gefunden werden,

umso höher ist die

Wahrscheinlichkeit

für weitere Fehler

Anzahl der bisher

gefundenen Fehler

© 2013 IAS, Universität Stuttgart 351


8.3 Dynamische Verfahren

ST I

Was ist Testen?

Definition:

Test ist der Prozess, ein Programm mit der Absicht auszuführen, Fehler zu

finden.

[Myers, 1979]

– Nach sorgfältigem Testen eines Programms steigt die Wahrscheinlichkeit,

dass das Programm sich auch in nicht getesteten Fällen wunschgemäß

verhält.

– Durch das Testen kann die Korrektheit eines Programms nicht bewiesen

werden (Ausnahme: triviale Programme).

© 2013 IAS, Universität Stuttgart 352


8.3 Dynamische Verfahren

ST I

Tests im Softwareentwicklungsprozess (1)

– Tests werden auf unterschiedlichen Ebenen durchgeführt

Kundenerwartungen

Abnahmetest

Abnahme

Anforderungsdefinition

Systemtest

Systemintegration

Grobentwurf

Integrationstest

Modulintegration

Feinentwurf

Modultest

Modulimplementierung

© 2013 IAS, Universität Stuttgart 353


8.3 Dynamische Verfahren

ST I

Tests im Softwareentwicklungsprozess (2)

Modultest

– Ziel:

Aufdeckung aller Abweichungen der Implementierung von der

Modulspezifikation

Modul

– Prüfen der Einzelfunktionen und zwar isoliert von anderen Modulen des

Systems

– Klare Zuordnung der Fehlerursachen zu den getesteten Modulen

– Aufbau einer geeigneten einfachen Testumgebung

Integrationstest

– Ziel:

Aufdeckung von Fehlern in Schnittstellen und im Zusammenspiel

zwischen integrierten Modulen

– Prüfen des Zusammenwirkens der Module

Modul 1 Modul 2

© 2013 IAS, Universität Stuttgart 354


8.3 Dynamische Verfahren

ST I

Tests im Softwareentwicklungsprozess (3)

Systemtest

– Test der Integration aller Subsysteme

System

Modul 1 Modul 2

– Aufdeckung aller Abweichungen des Systemverhaltens in Bezug auf das in

der Anforderungsdefinition spezifizierte Systemverhalten

– Überprüfung der vollständigen Erfüllung der Benutzeranforderungen

– Überprüfung der Korrektheit der Ergebnisse

– Überprüfung der Robustheit gegen fehlerhafte Eingabedaten

– Überprüfung von nichtfunktionalen Anforderungen

– Testaufwand abhängig von möglichen Folgeschäden

Prüfspezifikation

© 2013 IAS, Universität Stuttgart 355


8.3 Dynamische Verfahren

ST I

Tests im Softwareentwicklungsprozess (4)

Abnahmetest

– Test der Akzeptanz durch den Benutzer

System

Modul 1 Modul 2

– Test des Systems mit realen Daten unter realen Einsatzbedingungen

– Aufdecken aller Fehler, die beruhen auf

Missverständnissen bei Absprachen zwischen Benutzer und

Entwickler

falschen Schätzungen anwendungsbedingter Datenmengen

unrealistischen Annahmen bezüglich der realen Systemumgebung

– Test gegen Abnahmekriterien, die in der Anforderungsdefinition festgelegt

wurden

© 2013 IAS, Universität Stuttgart 356


8.3 Dynamische Verfahren

ST I

Vorgehensweise beim Testen

– Testobjekte werden ausgeführt oder simuliert

– Aktivitäten beim Testen

Vorbereitung des Testobjekts

Bereitstellung einer Testumgebung

Auswahl geeigneter Testfälle und Testdaten

Testausführung

Testauswertung

– Jede Prozedur, jedes Modul, jede Klasse muss dynamisch getestet

werden

© 2013 IAS, Universität Stuttgart 357


8.3 Dynamische Verfahren

ST I

Testumgebung (1)

Aufgabe: Simulation der realen Einsatzbedingungen für ein Testobjekt

Funktionen der Testumgebung

– (wiederholter) Aufruf des Testobjekts

– Bereitstellung von Eingabedaten

– Simulation benötigter, aber noch nicht vorhandener Ressourcen

(importierte Module, Betriebssystemkomponenten ....) und deren

Ergebnisse (Werte, Interrupts...)

– Anzeige und Ausgabe der Ergebnisse einer Testausführung

Prinzip:

so einfach wie möglich

© 2013 IAS, Universität Stuttgart 358


8.3 Dynamische Verfahren

ST I

Testumgebung (2)

– Testobjekt muss in Testumgebung eingebettet sein, um ein ablauffähiges

Programm zu erhalten

Testtreiber

Testfall 1 Testfall 2 Testfall n

Testergebnisse

Testobjekt

(Modul oder Subsystem)

Dummy-

Voreinstellung

Dummies

Dummy 1 Dummy 2

Dummy k

© 2013 IAS, Universität Stuttgart 359


8.3 Dynamische Verfahren

ST I

Testfallauswahl

– Auswahl der Testfälle ist eine zentrale Aufgabe des Testens

– Vollständiges Testen ist in der Regel unmöglich stichprobenartig prüfen

Richtige Auswahl von Testfällen ist sehr wichtig

– Ziel: Mit möglichst wenig Testfällen möglichst viele Fehler finden

Verfahren zur Testfallermittlung

Äquivalenzklassenbildung

Black-Box-

Ansatz

Grenzwertanalyse

Ursachen-Wirkungsanalyse

Testfallermittlung

Error Guessing

Anweisungsüberdeckung

White-Box-

Ansatz

Ablaufgraphenüberdeckung

Datenflussanalyse

Symbolischer Test

Zweigüberdeckung

Pfadüberdeckung

© 2013 IAS, Universität Stuttgart 360


8.3 Dynamische Verfahren

ST I

Verfahren zur Testfallermittlung

– Funktionsorientierter Test (Black-Box-Test)

Testfallauswahl aufgrund der Modulspezifikation

Interne Struktur kann unbekannt sein

Eingabe

Ausgabe

– Strukturorientierter Test (White-Box-Test)

Testfallauswahl aufgrund der internen Struktur

Modulspezifikation muss ebenfalls bekannt sein (erwartete Resultate)

Eingabe

Ausgabe

© 2013 IAS, Universität Stuttgart 361


8.3 Dynamische Verfahren

ST I

Funktionsorientierter Test (Black-Box-Test)

– Aufdeckung der Abweichung eines Testobjekts von seiner Spezifikation

– Auswahl der Testfälle ohne Kenntnis der inneren Struktur

– Überprüfung des Verhaltens des Testobjekts bei fehlerhaften

Eingabedaten

– Ziel: Umfassende Prüfung der spezifizierten Funktionalität

– Verfahren zur Testfallermittlung

Äquivalenzklassenbildung

Grenzwertanalyse

Ursachen-Wirkungsanalyse

Error Guessing

© 2013 IAS, Universität Stuttgart 362


8.3 Dynamische Verfahren

ST I

Testfallermittlung bei funktionsorientierten Tests (1)

Äquivalenzklassenbildung

– Gleichartige Eingabedaten werden zu Klassen zusammengefasst und aus

jeder Klasse wird ein Repräsentant ausgewählt.

– Bestimmung von

gültigen Äquivalenzklassen (Normalfall)

ungültige Äquivalenzklassen (Sonderfall)

– Beispiel: Multiplikation zweier ganzer Zahlen (X * Y)

Mögliche Äquivalenzklassen:

X und Y sind positiv

X ist positiv und Y ist negativ

X ist negativ und Y ist positiv

X und Y sind negativ

© 2013 IAS, Universität Stuttgart 363


8.3 Dynamische Verfahren

ST I

Testfallermittlung bei funktionsorientierten Tests (2)

Grenzwertanalyse

– Häufige Fehlerquelle: Grenzen zulässiger Datenbereiche

– Auswahl von Testfälle für solche Grenzfälle

– Beispiel: Multiplikation zweier ganzer Zahlen (X * Y)

Mögliche Grenzfälle:

X ist null

Y ist null

X und Y sind beide null

© 2013 IAS, Universität Stuttgart 364


8.3 Dynamische Verfahren

ST I

Testfallermittlung bei funktionsorientierten Tests (3)

Ursachen-Wirkungsanalyse

– Systematische Auswahl von Eingabedaten, die ein gewünschtes Ergebnis

bewirken.

– Ursachen-Wirkungsgraph (UWA) ist Hilfsmittel

– Ursachen-Wirkungsgraph entspricht Logik-Schaltung auf Basis von AND,

OR und NOT

Beispiel: Code-Fragment soll Ausnahme erzeugen

if(bottleEmpty OR (refill < minLevel)) {

for(i:=0; i= 500 && valveClosed) throw new overflowException()

...

...

bottleEmpty

oder

refill < minLevel

nMax ≥ 500

i ≥ 500

und

valveClosed

throw overflowException

© 2013 IAS, Universität Stuttgart 365


8.3 Dynamische Verfahren

ST I

Testfallermittlung bei funktionsorientierten Tests (4)

Error Guessing

– Intuitive Auswahl des Testfälle aufgrund von Erfahrung

– Kein systematisches Verfahren

– Ergänzt die Methoden zur Testfallbestimmung

© 2013 IAS, Universität Stuttgart 366


8.3 Dynamische Verfahren

ST I

Strukturorientierter Test (White-Box-Test)

– Betrachtung des Ein-/Ausgabeverhaltens und der inneren Struktur

des Testobjekts

– Ziel: Für jeden möglichen Pfad durch das Testobjekt soll das Verhalten

des Testobjekts in Abhängigkeit von den Eingabedaten festgestellt werden

– Auswahl der Testfälle aufgrund der Kenntnis der Ablaufstrukturen

des Testobjekts

– Wahl der Testfälle:

Jedes Modul und jede Funktion des Testobjekts wird mindestens

einmal aufgerufen

Jeder Zweig wird mindestens einmal durchlaufen

Möglichst viele Pfade werden durchlaufen

– Informationen, ob alle Funktionen des Testobjekts auch benötigt werden

Test der Realisierung

© 2013 IAS, Universität Stuttgart 367


8.3 Dynamische Verfahren

ST I

Testfallermittlung bei strukturorientierten Tests (1)

– Kontrollflussgraph (Ablaufgraph) Anweisungen 4

Zweige

Pfade

5


?

?

?

? ?

bei nur 10 Schleifendurchläufen gibt es 9.765.625 Pfade

© 2013 IAS, Universität Stuttgart 368


8.3 Dynamische Verfahren

ST I

Testfallermittlung bei strukturorientierten Tests (2)

Überdeckungsmessungen

– Anweisungsüberdeckung C0

– Zweigüberdeckung C1

– Pfadüberdeckung C2

Beispiel x = a;

if (p)

{

x = x + 1;

}

printf(x);

x = a

p

printf(x)

x = x+1

1 Testfall für 100% C0-Überdeckung

2 Testfälle für 100% C1-Überdeckung

2 Testfälle für 100% C2-Überdeckung

© 2013 IAS, Universität Stuttgart 369


8.3 Dynamische Verfahren

ST I

Testfallermittlung bei strukturorientierten Tests (3)

C1-Überdeckungsmessung

(a) Programmstruktur

(C1-instrumentiert)

S; . . . S; C1(7);

if P then S; . . .S; C1(8);

else S; . . S; C1(9);

if Q then S; . . .S; C1(10);

else C1(11);

end if;

S; . . . S;

end if;

if R then C1(12); goto weiter; end if;

C1(13);

while L loop

do S; . . .S; C1(14);

end loop;

S; . . .S;

case F is

when f1 => S; . . .S; C1(15);

when f2 => S; . . .S; C1(16);

when f3 => S; . . .S; C1(17);

end case;

weiter:

.

.

.

© 2013 IAS, Universität Stuttgart 370


8.3 Dynamische Verfahren

ST I

Testfallermittlung bei strukturorientierten Tests (4)

C1-Überdeckungsmessung

(b) Graph-Struktur

(c)

Ergebnis

7

C1-Messpunkt

Anzahl Durchläufe

P

9

8

12

10

R

13

Q

9

11

... ...

7 151

8 69

9 82

10 0! C1-Überdeckung 73%

11 82

... ...

L

14

13

F

15

16

17

© 2013 IAS, Universität Stuttgart 371


8.3 Dynamische Verfahren

ST I

Datenflussanalyse mit def-use-Ketten

def:

Variablen-Definition (Schreibzugriff)

use:

Variablen-Nutzung (Lesezugriff)

def-use-Kette: Pfad der def und use abdeckt

Datenflussanalyse: Alle def-use-Ketten werden mindestens einmal durchlaufen

Beispiel: def-use-Ketten für Variable x in folgendem Code-Abschnitt

Code-Abschnitt

def-use-Ketten

def-use-Überdeckung

1: if(y > 0)

2: x = 1;

3: else

4: x = 2;

5: if(y < 5)

6: y = x;

7: else

8: y = -x;

Triple [Variable; def; use] für alle

Kombinationen von def und use

[x; x = 1; y = x]

[x; x = 1; y = -x]

[x; x = 2; y = x]

[x; x = 2; y = -x]

Pfad A

Pfad C

1

4 2

5

6 8

Pfad B

Pfad D

Hier: def-use-Überdeckung mit 4 Pfaden möglich

Aber: Pfad A nicht ausführbar (wegen gleichzeitigen Bedingungen y > 0 und y < 5)

Hinweis auf mögliches Problem!

© 2013 IAS, Universität Stuttgart 372


8.3 Dynamische Verfahren

ST I

Symbolischer Test

• Test wird mit symbolischen Werten durchgeführt

• Die sich ergebende Nachbedingung dient zur Überprüfung der Spezifikation

Beispiel: Funktion zur Zuweisung von Minimal- Maximalwert

Funktions-Code

1: void MinMax(int &min, int &max)

2: {

2: int temp ;

3:

4: if (min > max)

5: {

6: temp = min ;

7: min = max ;

8: max = temp ;

9: }

10: }

Symbolische Ausführung:

min = MIN; max = MAX

Bei 4: ergeben sich 2 Pfade:

- für MIN > MAX (1.Pfad) ergibt sich:

MIN > MAX UND min = MIN UND max = MAX

MIN > MAX UND min = MAX UND max = MIN

- für min ≤ max (2.Pfad) ergibt sich:

MIN ≤ MAX UND min = MIN UND max = MAX

Nach Einsetzen der Endwerte ergibt sich:

aus 1.Pfad: max > min UND min = MAX UND max = MIN

aus 2.Pfad: min ≤ max UND min = MIN UND max = MAX

Disjunkte Verknüpfung der Pfade ergibt die Nachbedingung (= wahr für alle Werte von MIN und MAX):

min ≤ max UND ((min = MIN UND max = MAX) ODER (min = MAX UND max = MIN))

© 2013 IAS, Universität Stuttgart 373


8.3 Dynamische Verfahren

ST I

Top-Down-Test und Bottom-Up-Test (1)

Top-Down-Test

– Testreihenfolge

1. Integration von Bausteinen

2. elementare Bausteine

Aufrufhierarchie

– Steuermodul wird zuerst implementiert

und getestet

– Importierte Module werden durch

Ersatzmodule vertreten, die dieselbe

Schnittstelle haben und E/A-Verhalten simulieren

– Test erfolgt schrittweise mit Implementierung

– kein Integrationstest von Subsystemen

© 2013 IAS, Universität Stuttgart 374


8.3 Dynamische Verfahren

ST I

Top-Down-Test und Bottom-Up-Test (2)

Top-Down-Test

Vorteile

– Fehler werden früh erkannt

– einfache Überprüfung des Entwicklungsstands und der Akzeptanz durch

den Benutzer

– reale Prüffälle ohne teure Testumgebung

Nachteile

– Konstruktion von Ersatzmodulen ist kompliziert

– in komplexen Systemen findet E/A-Verhalten in tieferen Schichten statt

– Fehler schwer lokalisierbar, da von Anfang an viele Module beteiligt sind

– Test der unteren Schichten erfordert gesamtes Programmsystem

© 2013 IAS, Universität Stuttgart 375


8.3 Dynamische Verfahren

ST I

Top-Down-Test und Bottom-Up-Test (3)

Bottom-Up-Test

– Testreihenfolge

1. elementare Bausteine

2. Integration von Bausteinen

Aufrufhierarchie

– Funktionen, die keine anderen

Programmbausteine benötigen,

werden als erstes getestet,

dann die Integration zu einem Modul,

usw.

© 2013 IAS, Universität Stuttgart 376


8.3 Dynamische Verfahren

ST I

Top-Down-Test und Bottom-Up-Test (4)

Bottom-Up-Test

Vorteile

– Bottom-up-Testmethode ist solide und bewährt

– relevante Testfälle und Testdaten sind einfach zu definieren

Nachteile

– Eigenschaften des fertigen Produkts sind erst nach Abschluss aller

Implementierungen und Tests bekannt

– Entwurfsfehler werden erst sehr spät erkannt

– hohe Kosten für die Bereitstellung von geeigneten Testumgebungen

© 2013 IAS, Universität Stuttgart 377


Fragen zur Vorlesung

ST I

Frage zu § 8.3

Für den folgenden Abschnitt eines Programms soll eine C1-

Überdeckungsmessung durchgeführt werden:

Anweisung_A;

if (x > 0)

{

Anweisung_B;

while (y != x)

{

Anweisung_C;

}

Anweisung_D;

}

else

{

Anweisung_E;

}

Instrumentieren Sie das Programm für den C1-Zweigüberdeckungstest und

erstellen Sie den zugehörigen Kontrollflussgraphen. Wie viele Testfälle

werden für eine Zweigüberdeckung von 100% benötigt?

© 2013 IAS, Universität Stuttgart 378


Fragen zur Vorlesung

ST I

Antwort

Anweisung_A;

if (x>0)

{

Anweisung_B;

while (y != x)

{

Anweisung_C;

}

Anweisung_D;

}

else

{

Anweisung_E;

}

C1(1);

C1(2);

C1(3);

C1(5);

C1(4);

4

1

x>0

2

y!=x

3

Testfälle:

5

1. Testfall

2. Testfall

© 2013 IAS, Universität Stuttgart 379


Softwaretechnik I

ST I

§ 8 Softwareprüfung

8.1 Grundlagen

8.2 Statische Verfahren

8.3 Dynamische Verfahren

8.4 Testplanung und -ausführung

8.5 Zusammenfassung

© 2013 IAS, Universität Stuttgart 380


8.4 Testplanung und -ausführung

ST I

Testprozess

Testvorbereitung

Testmanagement

• Ermittlung von Testfällen

• Spezifikation von

Testfällen

Testdurchführung

• Ausführung der Testfälle

• Protokollierung der

Ausführung

TV

TD

TM

• Planung des

Testprozesses

• Steuerung des

Testprozesses

• Kontrolle des

Testprozesses

Testnachbereitung

• Aufbereitung der

Testergebnisse

• Bewertung der

Testergebnisse

TN

© 2013 IAS, Universität Stuttgart 381


8.4 Testplanung und -ausführung

ST I

Testplanung

– Festlegung der Aufgaben, Ziele und Strategien für die Testausführung

Testmethode

Testdokumentation

Testobjekte und Qualitätsanforderungen, die an sie zu stellen sind

Testkriterien, die erfüllt werden müssen

Anzahl der Testfälle

Prozentsatz der zu testenden Programmpfade

Art der Abnahmetests für die einzelnen Testobjekte

Testpersonen

einzusetzende Testwerkzeuge (Beispiele: SilkCentral Test Manager

von Borland, ClearQuest von IBM / Rational, Testbench von Imbus)

– Testplan ist Grundlage für die Qualitätssicherung und Voraussetzung für

die Überwachung und Steuerung der Testausführung durch den

Projektleiter

© 2013 IAS, Universität Stuttgart 382


8.4 Testplanung und -ausführung

ST I

Hinweise zur Fehlerbeseitigung

– Modularer Aufbau des Testobjekts mit eindeutig definierten Schnittstellen

erleichtert Fehlerlokalisierung

– Fehlerkorrektur sorgfältig

– Wahrscheinlichkeit für richtige Korrektur beim 1. Versuch < 50 %

– Vermeidung der Einschleusung neuer Fehler

– Wiederholung der zugehörigen Testfälle

– Typische Fehler

– Nichtberücksichtigung von Sonderfällen (z. B. Division durch Null)

– Fehlende Behandlung von Grenzwerten

– Überschreitung von Feldgrenzen

– Endlosschleifen

– Nichtinitialisierung von Variablen

– falsche logische Operationen (Negationen)

– falsche Parameterübergabe (Typ, Anzahl)

– unerlaubte Benutzung gemeinsamer Daten

© 2013 IAS, Universität Stuttgart 383

a

b


8.4 Testplanung und -ausführung

ST I

Techniken zur Fehlerlokalisierung

– Verfolgung des Ablaufs eines Testobjekts und die Verfolgung und

Überwachung des Zustands an bestimmten Stellen

– Ein- und ausschaltbare Anweisungen zur Programmablauf- und

Zustandsverfolgung und Überwachung (Implementierung)

– Programmablaufverfolgung

Ansprung von Marken

Durchlauf von Schleifen

Protokollierung der Ausführung bestimmter Anweisungsfolgen

– Zustandsverfolgung

Protokollierung wichtiger Zustandsgrößen

Protokollierung des Minimal- und Maximalwerts von Zustandsgrößen

– Zustandsüberwachung

Grenzwertüberwachung von Zustandsgrößen

Indexüberschreitung

Nichteinhaltung von Bedingungen

© 2013 IAS, Universität Stuttgart 384


8.4 Testplanung und -ausführung

ST I

Testdokumentation

Wichtig für

– wirtschaftliche Durchführung

– Qualitätskontrolle

– Wartungsphase

– Material für Statistiken zur Planung neuer Projekte

Inhalt der Testdokumentation

– Testplan

– Spezifikation der Testfälle

– Angaben zu den verwendeten Testumgebungen

– Testergebnisse der einzelnen Testläufe

– Zahl und Art der aufgedeckten Fehler

– Beschreibung von Maßnahmen zur Fehlerkorrektur

– Angaben über die Anzahl der benötigten Testläufe für jedes Testobjekt

© 2013 IAS, Universität Stuttgart 385


Fragen zur Vorlesung

ST I

Frage zu § 8.4

Welchen Aussagen stimmen Sie zu?

f


Beim dynamischen Testen müssen die Testobjekte ausgeführt werden


Vollständiges Testen ist nicht möglich


Auswahl der Testfälle ist entscheidend für den Erfolg eines Tests

Beim Integrationstest werden die Programmbausteine als Whitebox

betrachtet


Testdokumentation ist wichtig für die Softwareentwicklung

© 2013 IAS, Universität Stuttgart 386


Softwaretechnik I

ST I

§ 8 Softwareprüfung

8.1 Grundlagen

8.2 Statische Verfahren

8.3 Dynamische Verfahren

8.4 Testplanung und -ausführung

8.5 Zusammenfassung

© 2013 IAS, Universität Stuttgart 387


8.5 Zusammenfassung

ST I

Tipps und Tricks

– Beziehung zwischen Testfällen und Anforderungen

Welche Anforderungen werden durch welche Tests überprüft?

Gibt es Anforderungen, die nicht überprüft werden?

– Testplanung parallel zur Softwareentwicklung

– unabhängige Testpersonen

zur Aufstellung von Testplänen

zur Durchführung von Testläufen

– ein erfolgreicher Test findet Fehler

– 15% aller Module enthalten 50% aller Fehler

– 80% aller Fehler sind in 50% der Module

– gute Instrumentierung von Programmen bei der Implementierung

– Fehler sind nicht persönlich zu nehmen

© 2013 IAS, Universität Stuttgart 388


8.5 Zusammenfassung

ST I

Vorbereitungsfragen zu § 8

Frage 1: Testarten (WS 07/08)

Erklären Sie den Unterschied zwischen einem Black-Box- und einem White-Box-Test.

Welche Gründe sprechen für den Einsatz eines White-Box-Tests, welche für den Einsatz

eines Black-Box-Tests? Nennen Sie jeweils 2 Gründe.

Frage 2: Softwarefehler (SS 07)

a) Warum sind Softwarefehler, die in späteren Phasen der Entwicklung gefunden werden,

teurer als solche, die bereits frühzeitig entdeckt werden?

b) Während der Testphase eines Softwareproduktes stellen Sie fest, dass nach einer

gewissen Zeit die Anzahl der gefunden Fehler rapide abnimmt. Welche Folgerungen

können daraus gezogen werden? Geben Sie zwei unterschiedliche Folgerungen an.

Frage 3: Test (SS 04)

Ein Entwickler behauptet, sein Programm verhalte sich der Spezifikation entsprechend,

da es ausreichend getestet sei und bereits eine große Anzahl an Fehlern entdeckt sei.

Bewerten Sie diese Aussage.

© 2013 IAS, Universität Stuttgart 389

Weitere Magazine dieses Users
Ähnliche Magazine