1. Motivation 2. Begriffsklärung 3. Komponententests 4. Integrationstests 5. Integrationsstrategien 6. Zusammenfassung

Größe: px

Ab Seite anzeigen:

Download "1. Motivation 2. Begriffsklärung 3. Komponententests 4. Integrationstests 5. Integrationsstrategien 6. Zusammenfassung"

Dörte Beckenbauer
vor 8 Jahren
Abrufe

1 Übersicht s s Gregoire Kemgne 1

2 Motivation Problem: Software wird immer größer und komplexer, dadurch ist diese immer schwerer zu überschauen Ein Projekt benötigt mehr Zeit und/oder Entwickler. Lösung: Einbindung von bereits existierenden Software-Bausteinen (sog. Komponenten), die eine gewisse Funktion liefern Gregoire Kemgne 2

3 Motivation (2) Vorteile: Selbst zu implementierender Teil des Systems wird geringer Kostbare Entwicklungszeit wird eingespart Die vorhandenen Komponenten wurden nicht nur getestet, sondern haben sich evtl. auch schon in anderen Systemen bewährt. Qualitätssicherung (-steigerung) Gregoire Kemgne 3

Komponenten wurden nicht nur getestet, sondern haben sich evtl.

4 Komponenten Stück Software, das eine Menge wohl definierter Schnittstellen implementiert Beispiel : Enterprise Java Bean Kann auch als Modul bezeichnet werden Damit ist ein abgeschlossener Teil eines Programms gemeint. Beispiel : Java Klassen Gregoire Kemgne 4

Kann auch als Modul bezeichnet werden Damit ist ein

5 Komponenten Bezeichnet eine isolierbare Einheit, die in verschiedenen Kontexten einsetzbar ist. Sind Artefakte, sind Software Bestandteile, die eine Bestimmte sinnvolle Funktionalität zur Verfügung stellen Besitzen standardisierte Schnittstellen, so dass sie mit anderen Komponenten zusammenarbeiten können Gregoire Kemgne 5

Sind Artefakte, sind Software Bestandteile, die eine Bestimmte sinnvolle

6 Komponententest Test der einzelnen implementierten Komponente Testziele: Test auf Funktionserfüllung (laut Spezifikation) Test auf Robustheit (Negativfälle) Test auf Effizienz Test auf Wartbarkeit Gregoire Kemgne 6

(laut Spezifikation) Test auf Robustheit

7 Komponententest Charakteristik des Komponententests: Test durch die Entwickler selbst Komponenten-Testtreiber mit Platzhaltern (Stubs und Mock-Objekte) für noch fehlende Komponenten Test-driven development Automatisiertes Testen mit JUnit Gregoire Kemgne 7

(Stubs und Mock-Objekte) für noch fehlende Komponenten

8 Komponentenbeispiel Gregoire Kemgne 8

9 Komponentenarten Abstrakte klassen Generische Klassen Frameworks Eine Komponente kann auch andere Komponenten enthalten (auch Hardware) Andere Bezeichnungen: Unit, Modul Gregoire Kemgne 9

10 Abstrakte Klassen Basisklasse exportiert nicht implementierte (abstrakte) Methoden Fehlerarten: Gewöhnliche und Designfehler Direktes Testen nicht möglich Erstellung einer Instanz notwendig 1. Möglichkeit: Direkter Test Test von Basisklasse ableiten Implementierung jeder abstrakten Methode Test für jede abstrakte Methode 2. Möglichkeit: Indirekter Test Basisklasse und abgeleitetes Objekt gemeinsam testen Minimaltest: Jede Funktion mind. einmal testen Gregoire Kemgne 10

Möglichkeit: Direkter Test Test von Basisklasse ableiten Implementierung jeder abstrakten Methode Test für jede

11 Abstrakte Klasse - Beispiel abstrakt class GeomFigur { int x, y ; boolean istsichtbar; } void Figur (int x, int y, boolean sicht) { this.x = x; this.y = y; this. istsichtbar = sicht; } abstract void setposition(); abstract void anzeigen(); abstract double anzeigen(); Gregoire Kemgne 11

12 Abstrakte Klasse - Beispiel Gregoire Kemgne 12

13 Generische Klassen Erstellung einer Testinstanz notwendig Testarten So viele Kombinationen testen, wie es die Zeit zulässt Mind. jede Methode mit den am häufigsten benutzten Instanzen testen Gregoire Kemgne 13

14 Generische Klassen Template bzw. Schablone für Benutzertypen Deklaration erfordert mindestens einen Typ als Argument Typparameter werden statisch überprüft und gebunden Klassen benutzen verschiedene Ausprägungen von Parametern Fehlerarten - Typabhängig - Typspezifisch - Mehrtypfehler Gregoire Kemgne 14

Argument Typparameter werden statisch überprüft und gebunden Klassen

15 Generische Klassen - Beispiel class Box<T> { private T val; void setvalue( T val ) { } this.val = val; } T getvalue() { } return val; Gregoire Kemgne 15

16 Frameworks Sammlung von Komponenten Spezielles Framework Generalisiertes Framework Fehlerarten - Spezielles Framework Fehler - Generalisiertes Framework Fehler Gregoire Kemgne 16

17 Frameworks Erstellung einer Instanz notwendig (Prototyp) Use Cases bilden Grundlage für durchzuführende Tests Mind. gebräuchliche Use Cases und Assoziationen testen Erfolgreiche Komponententests sind Voraussetzung Lebenszyklus aller Objekte testen Gregoire Kemgne 17

gebräuchliche Use Cases und Assoziationen testen Erfolgreiche

18 Werkzeuge für Komponententests JUnit JUnit ist ein Testtool, mit dem Testfälle in der SpracheJava erstellt und automatisiert durchgeführt werdenkönnen DBUnit DBUnit ist ein JUnit-Derivat, mit dem eine Datenbank vor Ablauf eines Tests in einen definierten Stand zurückgesetzt werden kann HttpUnit Web-Anwendungen von Junit aus ansprechbar Gregoire Kemgne 18

org DBUnit DBUnit ist ein JUnit-Derivat, mit dem eine Datenbank vor Ablauf eines Tests in einen definierten

19 Integrationstest Begleitung der Integration von Modulen durch Qualitätssicherungsmaßnahmen Wichtig bei dieser Art zu Testen: Testreihenfolge Teile des Gesamtsystems werden isoliert gestestet (Komponenten + Schnittstellen) 19

Art zu Testen: Testreihenfolge Teile des Gesamtsystems

20 Integrationstest Grundlegende Voraussetzungen: Erfolgreicher Komponententest der einzelnen Module Erkennung von Abhängigkeiten zwischen Modulen => Erstellung eines Abhängigkeitsbaums Wahl der richtigen Integrationsstrategie Verwendung von Treibern und Platzhaltern 20

zwischen Modulen => Erstellung eines Abhängigkeitsbaums Wahl der

21 Abhängigkeitsgraph Architekturebenen 21

22 Treiber (Driver) Steuert den Test eines Moduls Versendet Nachrichten und wertet Interaktionen aus Beinhaltet Implementierung von Testmethoden zur Steuerung und Analyse des Moduls Bewertung des Testlaufs Symbol: 22

23 Platzhalter (Stub) Problem bei Isolierung von Komponenten: Keine Interaktion mit anderen Komponenten Fehlende Daten oder Services Lösung: Simulation durch Platzhalter Ähnliche Implementierung wie die ersetzte Komponente (gleicher Name und Signatur) Symbol: 23

24 Platzhalter (Stub) Vorteile: Bessere Kontrolle der zu testenden Komponente Ermöglichung einer parallelen Entwicklung Keine externen Services zum Entwicklungszeitpunkt Nachteile: Entwicklungsaufwand für Platzhalter-Methode Platzhalter müssen oft angepasst werden Neuer Testlauf nach Ersetzung des Platzhalters durch Original Vergessene Platzhalter nach Fertigstellung des Systems 24

25 Integrationsstrategien Big Bang Bottom-up Top-down Collaboration Backbone Layer Client/Server Distributed Services High-frequency 25

26 Big Bang Treiber Komponente im Test Schnittstelle im Test 26

27 Big Bang Nachteile: Chance ziemlich klein, das das System gleich fehlerfrei ist Lokalisierung der Fehler sehr schwer Vorteile: Geringer Aufwand, wenn es nur kleine Änderungen gegeben hat, die getestet werden sollen Mögliche Strategie für sehr kleine und überschaubare Systeme Strategie für Systeme, bei denen keine Modularisierung erkennbar ist (z. B. hardwarenahe Implementierung) 27

28 Bottom-up Treiber Komponente im Test 28

29 Bottom-up Treiber Komponente im Test Getestete Komponente Schnittstelle im Test 29

30 Bottom-up Treiber Komponente im Test Getestete Komponente Schnittstelle im Test 30

31 Bottom-up Treiber Komponente im Test Getestete Komponente Schnittstelle im Test 31

32 Bottom-up Nachteile: Großer Aufwand für die Entwicklung der vielen Treiber => Treiber sollten auf niedrigeren Ebenen wieder verwendet werden können Schnittstellenfehler werden vielleicht erst bei ihrer Verwendung in der nächsten Ebene erkannt (späte Erkennung) Vorteile: Es werden fast keine Platzhalter benötigt (nur für erzwungenen Ebenenwechsel) Parallele Entwicklung der Module möglich 32

33 Top-down Treiber Komponente im Test Schnittstelle im Test Platzhalter 33

34 Top-down Treiber Komponente im Test Getestete Komponente Schnittstelle im Test Platzhalter 34

35 Top-down Treiber Komponente im Test Getestete Komponente Schnittstelle im Test Platzhalter 35

36 Top-down Driver Komponente im Test Getestete Komponente 36

37 Top-down Nachteile: Relativ hoher Aufwand für Platzhalter (Entwicklung + Wartung) Bei Änderungen in einer unteren Ebene (näher der Wurzel) müssen die Tests wiederholt werden Je weiter entfernt die getesteten Schnittstellen vom Treiber, desto weniger Kontrolle über die Tests Vorteile: Nur ein Treiber notwendig (Entwicklung + Wartung) Anfangs Parallele Entwicklung auf verschiedenen Architekturebenen möglich Frühzeitige Erkennung von unstabilen Schnittstellen 37

38 Collaboration Integration von Modulen, die unter Zusammenarbeit eine bestimmte Aufgabe erfüllen => Test einer speziellen Funktion des Systems Umfassender Test: Betrachtung aller möglichen Modul- Kollaborationen notwendig Reihenfolge: simple komplexe Kollaboration 38

39 Collaboration Treiber Komponente im Test Schnittstelle im Test Platzhalter 39

40 Zusammenfassung Viele mögliche Strategien für Integrationstests Auswahlkriterien: Möglichst parallele Entwicklung, um Aufwand zu sparen Gute Kontrollmöglichkeit für die Tests Strategie richtet sich stark nach dem Entwicklungsprozess Gregoire Kemgne 40

41 Literatur [1] Robert V. Binder: Testing Object-Oriented Sytems, Addison Wesley 2000 [2] Peter Liggesmeyer: Software-Qualität, Spektrum Akademischer Verlag 2002 [3] Peter Liggesmeyer: Modultests und Mudulverifikation, Wissensverlag 1990 [4] P. Wegner: Towards Component-based Softwaretechnology, Technischer Bericht, Brown University 1993 [5] diverse Artikel, u.a. White Paper Vielen Dank für Eure Aufmerksamkeit und Frohe Weihnachten! Gregoire Kemgne Quelle: klab.caltech.edu 41

Ähnliche Dokumente

Programmiertechnik II

Programmiertechnik II Modultests Ziele Überprüfung der Korrektheit eines Moduls Korrektheit: Übereinstimmung mit (informaler) Spezifikation Modul: kleine testbare Einheit (Funktion, Klasse) Engl.: unit test White box testing