Universität Stuttgart Institut für Kernenergetik und Energiesysteme Aufgaben des Testens Vergleich des Verhaltens einer Software mit den an sie gestellten

Universität Stuttgart

Institut für Kernenergetik und Energiesysteme

Aufgaben des Testens

• Vergleich des Verhaltens einer Software mit den an sie gestellten Anforderungen

– Tut die Software das, was sie tun soll?

– Tut die Software das nicht, was sie nicht tun soll?

• Wie verhält sich Software in einer konkreten Umgebung

– Betriebssystem

– Rechnerausbau

– Nutzermodell

• Wo sind die Grenzen der Software - Benchmarking

– Zahl der Nutzer

– Durchsatz

– Compabilität



Erstellung einer Anforderungsdefinition

Ziel der Definitionsphase der Softwaresystem-Entwicklung ist die Definition der Anforderungen an das zu entwickelnde System. Das Vorgehen zur Erstellung einer vollständigen, eindeutigen und konsistenten Produkt-Definition lässt sich in folgende Aktivitäten einteilen:

• Anforderungen ermitteln, festlegen und beschreiben (Lastenheft), Anforderungen bezüglich ihrer Voll-

ständigkeit, Konsistenz, Eindeutigkeit sowie Durchführbarkeit analysieren

Anforderungen verabschieden (Pflichtenheft mit Systemmodell).

Problemstellung

Produkt-beschreibung

relativ vollständiges Verständnis der Anforderungen

konsistente und vollständige Anforderungsdefinition aus derdie Testfälle für die Abnahmetests abgeleitet werden können.

Problem-analyse



Produktqualität – Prüfverfahren (Beispiele)

• Komponenten Verifizierende Verfahren

Verifikation (Konsistenz von Entwurf + Implementierung)Symbolisches Testen (statische Strukturtests)

Testende Verfahren (Einzeltests)Statisch (Inspektion, Review, Walk through) Dynamisch (Kontrollfluss, Datenfluss, Funktional)

• Systeme Integrationstest

White Box-Test der Komponenten und ihrer BeziehungenFunktionstest

Black Box-Test des Systems als GanzesVergleich mit funktionalen Anforderungen

AbnahmetestBlack Box-Test des Systems als Ganzes unter

Mitwirkung des Auftraggebers



Testgetriebene Entwicklung

• In einer testgetrieben Entwicklung schreibt der Anwender abwechselnd Tests und Anwendungscode, bis alle Tests fehlerfrei laufen.

• Grundsätzlich gilt: Alle Annahmen sind durch Tests zu verifizieren; nur was im Test steht ist zugesichertes Verhalten

• Tests tragen den Entwurf und seine Implementierung. Größere Umstellungen im Code werden mit geringerem Risiko möglich.

• Vertiefende Texte finden Sie unter

www.frankwestphal.de/TestgetriebeneEntwicklung.html



Test im Rahmen des V-Modelles

Grobentwurf

Modul /Einzeltest

System /Funktionstest

Abnahmetest

Modulimple-mentation

Feinentwurf

Anforderungs-definition

Integrations-test

Anwendungsszenarien

Testfälle

Testfälle

Testfälle



JUnit Framework



Anwendung des JUnit Frameworks zum Systemtest

Hilfsklasse Komponente

Paket

** **

Projekt

** Test Suite

11

11 **

Test

11 11

**

Abnahme- / System-tests (LM13)

Integrations-/ Funktions-tests (LM12)

Einzeltests (LM11)



Erfahrungen aus Tests komplexer Systeme

Testaufwand sollte mit mindestens 30 % in Aufwand und Kosten geplant werden.

Zu testen sind

Basisbibliotheken

Komponenten

Integration der Komponenten

Schwerpunkt des Tests

Verhalten des Systems unter Ausnahmebedingungen (Exceptions)

Reaktion auf fehlerhafte Zustände

Vermeidung von Blockaden

Merke: Testen kann

Fehler nachweisen, nicht aber die Abwesenheit von Fehlern beweisen.



Fehlerbehebungskosten

Aktivität Anforderung+ Entwurfs-Review

CodierenModultest

IntegrationSystemtest

Betatest WartungKundentest

Aufwand inh/ 100Fehler

Aufwand proFehler (h)

2 2,4 4,1 6,2 13,1

Fehlerverteilung

Ideal 16 80 4 0 0 240

Aktuell 5 40 45 5 5 387

Ziel 5 60 30 3 2 322

Quelle: NIST Studie 2002 http://nist.gov/director/prog-ofc/report02-03.pdf zitiert nach Endres Informatik Spektrum 26-1



Softwareprüfung und Fehlerbehebung

Prüfung• meint Erkennen von

unerwartetem Verhalten

• stößt Prozess der Ursachenfindung an

• resultiert in Fehlerbehebung

Fehlerbehebung• führt zur Veränderung

des Produktes• kann unerwartetes

Verhalten erzeugen

Kriterium Prüfung (Primär-Test) Fehlerbehebung

Zweck Fehlerverhalten zeigen Fehler ausmerzen

Anfangsbedingungen bekannt evtl. unbekannt

Prozess analytisch deduktiv

Vorgehen festgelegt (Methode) individuell

Planung im voraus (genau) möglich (fast) unmöglich

Dauer Zeitlich limitiert schwer abzugrenzen

Entwurfskenntnisse zum Teil nicht nötig unbedingt nötig

Planen, durchführen kann ein Outsider muss ein Insider

theoretische Grundlagen zum Teil vorhanden fehlen

Vergleich:



Wann hört man auf mit Testen

• Wenn Testbudget verbraucht bzw. Auslieferungszeitpunkt erreicht

• Die je Testfall (Zeiteinheit) gefundene Fehlerzahl sinkt unter gegebene Grenze

• n % absichtlich von einer Gruppe implantierter Fehler (seeded bugs) wurden von Testgruppe gefunden

• Aus jeder Klasse „äquivalenter“ Eingabedaten wurde ein Repräsentant getestet.

• Testfälle decken alle (relevanten) Programmverzweigungen ab

Documents

Universität Stuttgart Institut für Kernenergetik und Energiesysteme Aufgaben des Testens Vergleich des Verhaltens einer Software mit den an sie gestellten