Software-Test. Tests im Softwareentwicklungsprozess. Motivation. Literatur. schon gesehen: testgetrieben. traditionell

Größe: px

Ab Seite anzeigen:

Download "Software-Test. Tests im Softwareentwicklungsprozess. Motivation. Literatur. schon gesehen: testgetrieben. traditionell"

Hermann Dunkle
vor 8 Jahren
Abrufe

1 Tests im Softwareentwicklungsprozess traditionell test-getrieben: Geschäftsprozessmodellierung Requirements Engineering Analyse Design Implementierung Tests Testen 1 Tests vor Implementierung und Design inkrementell testgetrieben Software-Test schon gesehen: Testen 2 möglichst früh Testfälle definieren: Akzeptanztests Komponententests Tests automatisieren: FIT(NESSE) xunit hier: Testen allgemein Testen von OO-Systemen Testautomatisierung Zuordnung zu Prozess-Phasen Testgetriebenes Vorgehen -> siehe OOS Literatur Uwe Vigenschow: Objektorientiertes Testen und Testautomatisierung in der Praxis; dpunkt-verlag. Testen 3 Johannes Link: Softwaretests mit JUnit Techniken der testgetriebenen Entwicklung ; dpunkt-verlag. Andreas Spillner & Tilo Linz: Basiswissen Softwaretest Aus- und Weiterbildung zum Certified Tester (Foundation Level); dpunkt-verlag. Robert V. Binder: Testing Object-Oriented Systems Models, Patterns, and Tools; Addison-Wesley. Erich Gamma & Kent Beck: JUnit Framework; Frank Westphal: Testgetriebene Entwicklung mit JUnit & FIT; dpunkt-verlag Motivation jedes Programm fehlerhaft! positiv: Testen 4 über Fehler kritische Bereiche identifizieren & analysieren Fehlersuche jederzeit in Entwicklungsprozess -> besseres Verständnis -> bessere Qualität teure Fehler durch Schwächen in Programmiersprachen 1962: Trägerrakete der Venussonde 290 Sekunden nach Start kontrolliert zerstört FORTRAN 1996: Jungfernflug der Ariane 5 Fehler wegen stärkeren Schubs als Ariane 4 Ada oft Schluss: strenge Typisierung -> keine Fehler falsch!!!! 1

allgemein Testen von OO-Systemen Testautomatisierung Zuordnung zu Prozess-Phasen Testgetriebenes Vorgehen -> siehe OOS Literatur Uwe Vigenschow: Objektorientiertes Testen und Testautomatisierung in

2 Fehler Abweichung vom erwarteten Verhalten grundsätzliche Kategorien: Inkonsistente Benutzerschnittstellen Unerfüllte Erwartungen Schlechte Performance Fehlerverhalten Abstürze und/oder Datenverluste führen zu: mangelnde Kundenakzeptanz Nichtbenutzung der Programme Testen 5 Test Definition aus Andreas Spillner & Tilo Linz: Testen 6 Test ist die stichprobenartige Ausführung eines Testobjekts, die zu dessen Überprüfung dienen soll. Dazu müssen die Randbedingungen für die Ausführung des Tests festgelegt sein. Über einen Vergleich zwischen Soll- und Ist- Verhalten wird bestimmt, ob das Testobjekt die geforderten Eigenschaften erfüllt. Testverfahren White-Box-Test Struktureller Test Black-Box-Test Grey-Box-Test Entwicklertests Testfall & Testdaten Testfall besteht aus: Testablauf Testen 7 welche Schritte in welcher Reihenfolge ausgeführt kann für verschiedene Testdaten durchgeführt werden Testdaten Beschreibung aller Eingaben erwartete Resultate Automatisierung automatische oder manuelle Erzeugung der Testdaten automatische Überprüfung der Resultate Unit-Tests Unit isolierte Klasse Testen 8 durch Assoziation verbundene Kette benachbarter Klassen ganzes Modul von Klassen Klassentest inkrementeller Test einer Methode nach der anderen jede Methode isoliert jede Folge abhängiger Methoden innerhalb der Klasse Kettentest kleiner, lokaler Klassen-Integrationstest Modultest (Komponententests pro Entwickler) -> Pflichtenheft Komponentenschnittstellentest bzgl. spezifizierter Funktionalität 2

zu dessen Überprüfung dienen soll. Dazu müssen die Randbedingungen für die Ausführung des Tests festgelegt sein.

3 richtige Testdaten finden Testen 9 Grenz- und Extremwerte (inkl. Negativtests) Werte am Rand eines Eigenschaftsbereiches potenzielle Fehlerdaten Fehlersensibilität Eignung von Testdaten zur Aufdeckung von Fehlern Äquivalenzklassen enthält Testdaten, die alle die gleichen Fehler aufdecken Bildung erfolgt heuristisch nach Erfahrung und Intuition Überdeckungen vereinfachte Pfadüberdeckung für Schleifen Termüberdeckungen für Bedingungen Ablaufgraph Knoten: Anweisungen Kanten: Wege z.b.: Anw1 while.. do Anw2 Testen 10 Anw1 if..then.. else Anw2 Anw3 gesucht: Testfälle, so dass alle Pfade überdeckt kombinatorische Explosion -> Annäherungen vereinfachte Schleifenüberdeckung reduziere Schleifentests auf: kein Eintritt in die Schleife genau ein Durchlauf durch Schleife genau zwei Durchläufe durch Schleife Testen 11 typische Anzahl von Durchläufen durch Schleife maximale Anzahl von Durchläufen durch Schleife Ordnung der Tests: k Schleifenverschachtelungstiefe testgetrieben -> wartbare Schleifenschachtelung Termüberdeckung Bedingungen: fehleranfällig bilden fachliche Regeln ab Testen 12 Bsp.: (nr>1 &&!hasfailed()) newcustomer() Term: nicht mehr teilbare logische Einheit entspricht Variablen (atomaren Formeln) in Aussagenlogik Bsp.: nr>1 hasfailed() newcustomer() n unabhängige Terme -> n+1 Testfälle heißt auch: minimale Mehrfachbedingungsüberdeckung stelle Werte so ein, dass für Gesamtwert jeweils nur ein Term verantwortlich 3

gleichen Fehler aufdecken Bildung erfolgt heuristisch nach Erfahrung und Intuition Überdeckungen vereinfachte Pfadüberdeckung für Schleifen Termüberdeckungen für Bedingungen Ablaufgraph Knoten:

4 Error Guessing & laterale Tests nutze Erfahrung beim Fehlerfinden und folgende Tipps: Testen 13 welche Quellen haben hohe Versionsnummern welche Quellen in Methodenzahl weg vom Durchschnitt welche Methoden überdurchschnittlich lang wo überdurchschnittlich viele Kommentare laterale Tests: freie Tests nicht automatisiert dienen zum besseren Verständnis findet auch Fehler, nach denen gar nicht gesucht lerne von Erfahrung anderer Rekursion & Nebenläufigkeit Rekursion: analog zu Schleifen testen zusätzliche Fehler durch Nebenläufigkeit: Testen 14 Fehler durch Prozesskommunikation & -synchronisation Wartefehler Verhungern, Starvation: unendliches Warten eines Prozesses Verklemmung, Deadlock: Gesamtsystem blockiert Nichtdeterminismus: gleiche Eing. gemeinsam genutzte Variablen -> verschiedene Ausg -> viele Tests shared Variables Unterschied: Ein-Prozessor/Mehr-Prozessor-Systeme allgemein bei Nichtdeterminismus: Tests nicht reproduzierbar möglichst alle Situationen simulieren oder auf repräsentative deterministische Fälle beschränken Test von OO-Software Testen 15 bisher: unabhängig von Realisierungsstil bei oo: zusätzlich Vererbung und Überlagerung Testaufbau parallel zur Entwicklung: Methoden Klassen White-Box-Tests Klassenmengen Komponenten oder Subsysteme Applikation oder System Grey-Box-Tests Black-Box-Tests White-Box-Tests: top-down entlang der Vererbungshierarchie vertikal entlang der Assoziationsketten (wie bisher) horizontal Testen bei Vererbung zuerst Oberklassen, dann Unterklassen Testen 16 Oberklassen nicht als Black-Box betrachten Problem: Wenn aus Bibliothek ohne Source-Code unterscheiden zwei Arten von Vererbung: strikt: nur Erweiterungen, keine Überlagerung für geerbte Methoden gleiche Tests wie in Oberklasse für neue Methoden neue Tests entwickeln nicht-strikt: auch Überlagerungen neue Testfälle auch für überlagerte Methoden neue Testfälle für Methoden, die überlagerte verwenden 4

gesucht lerne von Erfahrung anderer Rekursion & Nebenläufigkeit Rekursion: analog zu Schleifen testen zusätzliche Fehler durch Nebenläufigkeit: Testen 14 Fehler durch Prozesskommunikation &

5 Assoziationen & Vererbungen starte ganz oben in Vererbungshierarchie teste Assoziationen für Superklasse solange es noch Unterklassen gibt: gehe in Vererbungshierarchie eine Stufe tiefer teste Assoziationen aller Klassen dieser Stufe Testen 17 Testreihenfolge <-> sinnvoller Programmierreihenfolge -> testgetriebenes Vorgehen unterstützt Vorgehen in Entwicklung Testreihenfolge für Methoden Testen 18 Testreihenfolge <-> Implementierungsreihenfolge: Konstruktoren get-methoden boolsche Methoden is...() set-methoden Iteratoren komplexe Berechnungsmethoden nach Sichtbarkeit private protected public (nicht-) modale Methoden nicht-modale Methoden können jederzeit aufgerufen werden Testen 19 Tests mit verschiedenen Aufrufreihenfolgen Tests mit wiederholten Aufrufen derselben Methode modale Methoden setzen bestimmte Aufrufreihenfolge voraus Tests in geforderter Reihenfolge funktioniert alles wie spezifiziert? nur korrekte Zustände erreicht? Tests jeder falschen Reihenfolge lehnen Methoden Aufruf in falschem Zustand ab? bleibt Klasse in stabilen, korrekten Zustand? Testmuster in [Binder] 37 Testmuster typische Fehlersituationen dazu notwendige Tests Bsp.: nicht-modaler, polymorpher Server Testen 20 Oberklasse liefert Basisfunktionalität für viele Unterklassen Bsp.: GeomFigur (verwendet von ZeichenFläche)enthält: anzeigen(), verstecken() in jeder Ableitung Tests (Substitutionsprinzip): jede in konkreten Unterklassen überschriebene Methode diese müssen Einschränkungen aus Oberklassen einhalten jede Methode im Klassenumfeld & in allen Client- Unterklassen 5

Testen 18 Testreihenfolge <-> Implementierungsreihenfolge: Konstruktoren get-methoden boolsche Methoden is.

Ähnliche Dokumente

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008 Konzeption und Implementierung einer automatisierten Testumgebung, 10. Dezember 2008 1 Gliederung Einleitung Softwaretests Beispiel Konzeption Zusammenfassung 2 Einleitung Komplexität von Softwaresystemen