Dieser Vortrag zeigt die Vorteile moderner Ansätze für den Test von Java-Anwendungen auf. Die für eine erfolgreiche Testautomatisierung einzusetzenden Java-Test-Frameworks und -Werkzeuge werden exemplarisch vorgestellt (z.B. JUnit, Abbot, JETM). Die Verwaltung von Testdaten und der Einsatz von dedizierten Testdatenbanken werden behandelt. Herr Seekamp veranschaulicht den praktischen Einsatz von automatisierten Testverfahren anhand von zwei JavaEE-Projekten. Er geht außerdem auf den Begriff des Testmanagement und das Konzept der testgetriebenen Software-Entwicklung ein. Die für die Durchführung von automatisierten Software-Tests notwendigen Bausteine werden zusammengefasst. Der Ausblick benennt die Problemfelder und das Potenzial der Testautomatisierung. * Grundlagen und Ziele des Software-Tests * Manueller Software-Test und dessen Nachteile * Übergang zu automatisierten Testverfahren und deren Vorteile * Frameworks und Werkzeuge für die Testautomatisierung * Verwaltung von Testdaten und Einsatz von Testdatenbanken * Beispiele für Testautomatisierung in JavaEE-Projekten * Notwendigkeit des Testmanagement * Konzept der testgetriebenen Entwicklung und Vorteile für den Entwickler * Bausteine für automatisierte Software-Tests * Problemfelder und Potenzial der Testautomatisierung

1. Software-
Automatisierter Software-Test unter Java
Treffpunkt Semicolon, 18.09.2007
Jens Seekamp, GEDOPLAN GmbH

2. Inhalt
1. Motivation und Ziele von automatisierten Software-Tests
2. Manuelle Software-Tests und deren Nachteile
3. Grundbegriffe der Testautomatisierung
4. Bausteine für automatisierte Software-Tests
5. Anwendungsbeispiele
6. Problemfelder der Testautomatisierung und Gegenmaßnahmen
7. Potenzial von automatisierten Software-Tests
1

3. Thema
Software-
1. Motivation und Ziele von automatisierten Software-
Tests
2. Manuelle Software-Tests und deren Nachteile
3. Grundbegriffe der Testautomatisierung
4. Bausteine für automatisierte Software-Tests
5. Anwendungsbeispiele
6. Problemfelder der Testautomatisierung und Gegenmaßnahmen
7. Potenzial von automatisierten Software-Tests
2

4. Motivation für den automatisierten Software-Test
Test einer Anwendung (SUT = system under test) ist experimentelles
Verfahren mit zwei Zielsetzungen:
destruktives Testen: innerhalb des SUT möglichst viele Fehler aufdecken
demonstratives Testen: Korrektheit des SUT unter definierten
Bedingungen demonstrieren
effiziente und kostensparende Test-Durchführung:
möglichst viele Test-Aktivitäten durch Werkzeuge unterstützen
Test-Aktivitäten automatisiert ablaufen lassen
3

5. Ziele der Testautomatisierung
explizite und detaillierte Beschreibung des Testwissens: benötigte
Testdaten, notwendige Programmabläufe
effiziente Testdurchführung: Zeit für einen Testzyklus
reproduzierbare Testergebnisse: exakt gleiche Testläufe
beliebige Wiederholbarkeit von Testläufen ohne Mehraufwand: Lasttests
zu verschiedenen Tageszeiten
Erhöhung der Software-Qualität: Regressionstests
Einsparung von Personal- und Sachkosten: Fachtester, Testlabore
Zukunftsinvestition: automatisierte Testverfahren für mehrere SUT's
4

6. Thema
1. Motivation und Ziele von automatisierten Software-Tests
Software-
2. Manuelle Software-Tests und deren Nachteile
3. Grundbegriffe der Testautomatisierung
4. Bausteine für automatisierte Software-Tests
5. Anwendungsbeispiele
6. Problemfelder der Testautomatisierung und Gegenmaßnahmen
7. Potenzial von automatisierten Software-Tests
5

7. Herkömmliche, manuelle Software-Tests
Grundlage bilden nicht ausführbare Testfall-Beschreibungen (z.B.
fachlicher Testkatalog bestehend aus MS Office Excel Dateien).
Ausführung durch Test-Team, Fachtester oder "Power-User"
Testdaten werden manuell selektiert oder in den benötigten
Anfangszustand gebracht.
Spezifizierte Testfälle werden manuell auf dem SUT ausgeführt.
Durchführung der Testläufe und das Testergebnis wird manuell
protokolliert und ausgewertet.
Testprozess wird manuell koordiniert und überwacht.
6

8. Manueller Software-Test
(Dialog-Vergleichs-Test
nach einer Plattform-
Migration von UDS/Forte
nach Java)
7

9. Nachteile der manuellen Testausführung (1)
1. Nachteil:
• beansprucht viel Arbeitszeit
• wird von Menschen durchgeführt
• wird als lästig empfunden
=> seltene Durchführung, ggf. unvollständig, lange Testzyklen
2. Nachteil:
• Testdaten sind entweder vorhandene Objekte oder über SUT-Dialoge
"konfigurierte" Objekte.
• Testläufe werden nicht jedesmal exakt wiederholt.
• Ergebnisprüfung durch Datenbank-select oder Sichtprüfung von Ausgabe-
/Protokoll-Dateien
=> schlechte Reproduzierbarkeit des Teststatus
8

10. Nachteile der manuellen Testausführung (2)
3. Nachteil:
• Fach-/Anwendungswissen der Mitarbeiter fließt implizit in die Testläufe ein
• Fehlerdetails werden in der Masse der Testläufe übersehen
=> geringe Aussagekraft
4. Nachteil:
Jede Test-Wiederholung verursacht in etwa gleichbleibende Aufwände.
Fazit:
Manuelle Testausführung verursacht hohe Aufwände (Arbeitszeitkosten,
Projektlaufzeit) bei zu hinterfragender Testqualität.
9

11. Thema
1. Motivation und Ziele von automatisierten Software-Tests
2. Manuelle Software-Tests und deren Nachteile
3. Grundbegriffe der Testautomatisierung
4. Bausteine für automatisierte Software-Tests
5. Anwendungsbeispiele
6. Problemfelder der Testautomatisierung und Gegenmaßnahmen
7. Potenzial von automatisierten Software-Tests
10

12. Testfall
Testfall:
Beschreibung einer Menge von Software-Tests
Attribute einer Testfall-Beschreibung:
Identifikation, Kurzbeschreibung, Testschritte, Kritikalität, erwartetes
Ergebnis, Versionierungs-Informationen, ...
Testlauf:
• konkrete Ausführung eines Testfalles
• Anfangszustand => Programmablauf => Endzustand
• Überprüfung einer bestimmten fachlichen Funktionalität oder
technischen Eigenschaft des SUT
11

13. Kategorisierung von Testfällen
Testfälle werden anhand von zwei Dimensionen kategorisiert:
abstrakt vs. konkret
• Beschreibung von bestimmten Programmabläufen und Testdaten
Spezifikation vs. Implementierung
• Formalisierung und Ausführbarkeit
Die folgenden Ausprägungen von Testfällen sind häufig anzutreffen:
• Testszenario (z.B. Word-Dokument)
• Testfall (z.B. strukturiertes Excel-Template)
• interpretiertes Testskript (z.B. GUI-Testskript im XML-Format)
• kompiliertes Testprogramm (z.B. JUnit-Testklasse)
12

14. Testautomatisierung
Durchführung der vier Schritte eines SUT-Testlaufes
(1) Herstellen eines definierten Anfangszustandes des SUT und der Datenbasis (set
up)
(2) Ausführen der zu testenden SUT-Funktionalität (execute)
(3) Sicherstellen eines SUT-Zustands (assert) bzw. Prüfen des Testergebnisses
(check)
(4) Herstellen eines definierten Endzustandes des SUT und der Datenbasis (tear
down)
teilweise oder voll automatisiert durch Testwerkzeuge/-Frameworks.
13

15. Automatisierte Testauswertung und -protokollierung
Testergebnis: tatsächlicher Rückgabewert der ausgeführten Funktionalität bzw.
geänderter SUT-Zustand
Erwartete Ergebnis: spezifizierter Rückgabewert der ausgeführten
Funktionalität bzw. geforderter SUT-Zustand bei Korrektheit
Ergebnisprüfung: automatisierter Vergleich des Testergebnisses mit dem
erwarteten Ergebnis auf Gleichheit
Automatisierte Ermittlung und Protokollierung der möglichen Teststatus:
Fehler aufgedeckt = negative Ergebnisprüfung = "rot"
kein Fehler gefunden = positive Ergebnisprüfung = "grün"
14

16. Vorteile der automatisierten Testausführung (1)
Automatisierte Testausführung belastet die Mitarbeiter nicht und kostet
keine direkte Arbeitszeit.
Testläufe werden beschleunigt durchgeführt, wodurch sich kürzere
Testzyklen ergeben.
Auch umfangreiche Ergebnisprüfungen sind mit einem verlässlichen
Resultat möglich (z.B. Datenbank- oder Dateiinhalte).
Automatisierte Testfälle sind unabhängig vom Fach-/ Anwendungswissen
der Mitarbeiter ausführbar und somit auch langfristig wiederholbar.
15

17. Vorteile der automatisierten Testausführung (2)
Testläufe können beliebig oft wiederholt werden.
Testläufe werden bei jeder Wiederholung exakt gleich sowie vollständig
ausgeführt.
Jede Wiederholung eines automatisierten Tests verursacht nur sehr
geringe Aufwände.
Regressionstest: Nach Änderung oder Erweiterung des SUT können alle
Testfälle einfach und vollständig ausgeführt werden.
16

18. Thema
1. Motivation und Ziele von automatisierten Software-Tests
2. Manuelle Software-Tests und deren Nachteile
3. Grundbegriffe der Testautomatisierung
fü Software-
4. Bausteine für automatisierte Software-Tests
5. Anwendungsbeispiele
6. Problemfelder der Testautomatisierung und Gegenmaßnahmen
7. Potenzial von automatisierten Software-Tests
17

19. Baustein 1: Testfall-Implementierungen (1)
Begriff der Testfall-Implementierung:
Testfälle als Skript oder Java-Klasse "programmieren"
Testfälle interpretieren oder kompilieren
Testfall-Implementierungen zu Test-Bibliotheken zusammenfassen
18

20. Baustein 1: Testfall-Implementierungen (2)
Einige zu beachtende Punkte:
Auswahl von automatisierbaren Testfällen:
• fachliche Komplexität
• technische Machbarkeit
Umfang der Ergebnisprüfung:
• technische Gesamtprüfung
• fachlogische Minimumprüfung
Zeitpunkt der Ergebnisprüfung:
• dynamisch (während Testlaufzeit)
• nachgelagert (nach dem Testlauf)
"Software-Qualität":
• Abgeschlossenheit, Wiederholbarkeit, Wartbarkeit usw.
19

21. Baustein 2: dedizierte Testdatenbanken - Grundbegriffe (1)
3 Arten von Testdaten:
Ausgangsdaten, Ergebnisdaten (Ist), Vergleichsdaten (Soll)
Test-Fixture:
definierte Menge von Objekten, die als Datenbasis für die Ausführung von
Testfällen dient
=> definierter Zustand der relationalen Datenbank
Testläufe werden stets gegen eine separate Test-Datenbank ausgeführt:
• DB-Schema entspricht dem Entwicklungsstand
• DB-Ausprägung variiert nach Test-Anforderung
• Testdaten müssen als Datenbankinhalte dargestellt und manipuliert werden
können:
• Laden eines Test-Fixture beim set up
• Entfernen von neu angelegten Ergebnisdaten beim tear down
20

22. Baustein 2: dedizierte Testdatenbanken - Ausprägungen (2)
leere Testdatenbank, d.h. nur DB-Schema vorhanden:
• Test-Fixture muss für jeden Testlauf stets vollständig erzeugt werden.
Extraktions-Test-Datenbank als verkleinerte Version der SUT-Produktions-
Datenbank enthält:
• sämtliche Stammdaten
• Bewegungsdaten
• keinerlei Bewegungsdaten => müssen stets vollständig erzeugt werden
• einen definierten Stand der Bewegungsdaten => als Test-Fixture verwenden
• Extraktionsprogramm notwendig
Test-Datenbank ist eine vollständige Kopie der Produktions-Datenbank.
21

23. Baustein 2: dedizierte Testdatenbanken - Rücksetzen (3)
komplettes Rücksetzen der Test-Datenbank:
• Wiedereinspielen von DB-Abzügen
Nutzung eines Flashback-Mechanismus (z.B. bei Oracle):
• Rücksetzen der Test-Datenbank auf einen definierten Flashback-
Punkt nach jedem Testlauf
Transaktions-Steuerung:
• Testlauf innerhalb einer Transaktion durchführen
• nach einem fehlerfreien und / oder gescheiterten Testlauf
Transaktion rücksetzen
• Vorsicht: geschachtelte Transaktionen wegen SUT-eigener
Transaktionssteuerung
22

24. Baustein 3: Test-Werkzeuge / -Frameworks (1)
Einige gewünschte Funktionalitäten:
Erstellung und Wartung von Testfällen / -Implementierungen
Erfassung und Pflege von Testdaten
Automatisierte Durchführung von Testfällen
Laden / Entladen von Testdaten
Test-Durchführung wird überwacht, ausgewertet und protokolliert
Vorteile von Open Source Lösungen:
kostenneutral verfügbar
individuell anpassbar
maßgeschneidert für spezielle Test-Anforderungen
auch für geschäftskritische SUT's einsetzbar
23

25. Baustein 3: Open Source Test-Werkzeuge / -Frameworks (2)
JUnit: www.junit.org
• "Standard"-Java-Framework für den White-Box-Test von Methoden
Abbot: abbot.sourceforge.net
• Simulations-Werkzeug für den Black-Box-Test der SUT-GUI
DBUnit: www.dbunit.org
• Framework für DB-nahe Tests und Testdatenverwaltung
XMLUnit: xmlunit.sourceforge.net
• Framework für Tests bzgl. XML-Dateien
24

26. Baustein 3: Open Source Test-Werkzeuge / -Frameworks (3)
JUnitPerf: www.clarkware.com/software/JUnitPerf.html
• Framework für Performanz- und Lasttests
JETM: jetm.void.fm (Java Execution Time Measurement)
• Framework zur Laufzeitmessung
• Messpunkte können per AOP deklarativ definiert werden
AOP:aspectwerkz.codehaus.org (aspect oriented programming)
• Test-Aspekte können überall in SUT eingebaut werden
25

27. Baustein 4: Werkzeug-gestütztes Testmanagement
Management aller Tätigkeiten des Software-Testprozesses:
Strategie und Konzeption des SUT-Tests
konventionelle Projektplanung (durchzuführende Tests, Mitarbeiter, Termine)
Organisation des Software-Test (Hardware, Software, Testräume)
Test-Durchführung (Testdatenbereitstellung, Testläufe, Testprotokollierung)
Kontrolle und Steuerung des Software-Test (Test- und Fehlerstatistik, Bug-
Tracking)
ordnungsgemäßer Abschluß des Software-Test (Abnahmekriterien)
durchgängige Werkzeug-Unterstützung?
26

28. Beispiel für
einen
Testprozess:
manuell
gesteuert,
Werkzeug für
Bug-Tracking
27

29. Thema
1. Motivation und Ziele von automatisierten Software-Tests
2. Manuelle Software-Tests und deren Nachteile
3. Grundbegriffe der Testautomatisierung
4. Bausteine für automatisierte Software-Tests
5. Anwendungsbeispiele
6. Problemfelder der Testautomatisierung und Gegenmaßnahmen
7. Potenzial von automatisierten Software-Tests
28

30. (1) Automatisierter Dialog-Test eines Warenwirtschaftssystems
Rahmenbedingungen:
Test der gesamten Neuentwicklung einer Anwendung für die
Warenwirtschaft
Neuentwicklung erfolgt in mehreren Stufen, jede Stufe muss einen
Abnahmetest bestehen:
Entwicklung/Test in Mikro-Phasen
Test erfolgt als Black-Box-Test über die Dialogoberfläche:
GUI-getriebener Test
Test basiert auf Anwendungsfällen der Anwendung:
Use Case-basierter Test
Excel-Testszenarien für die Anwendungsfälle sind vorhanden
29

31. Nutzung des Java-GUI-Test-Framework Abbot für Swing/SWT
SUT-Dialogabläufe werden während ihrer Durchführung aufgenommen
("record").
Dialogabläufe werden als GUI-Testskript gespeichert (XML-Datei).
grafischer Testskript-Editor: GUI-Testskripte werden nachbearbeitet, verändert
und inkrementell weiterentwickelt.
GUI-Testskripte können zu einem späteren Zeitpunkt und beliebig oft
ausgeführt werden ("play").
GUI-Testskripte beinhalten Prüfungen auf Dialogebene ("assert").
Aus GUI-Testskripten heraus werden Java-Methoden des SUT aufgerufen:
• Testdaten verwalten
• fachliche Prüfungen durchführen
30

32. Potenzial von Abbot
Aufbau einer GUI-Testbibliothek mit mehreren hundert Testskripten
strukturierter, modularer Aufbau von Testskripten:
Unterskripte, Wiederverwendung
Entkopplung von Testskripten und verwendeten Testdaten:
Einlesen von Testdaten dynamisch zur Testlaufzeit
in den nächtlichen Build-Prozess integrierter Regressionstest
Nutzung für Performanz- und Lasttests in einer 3-tier-Testumgebung
vielfältige weitere Anwendungsmöglichkeiten:
• aus GUI-Testskripten HTML-Testbeschreibungen generieren
• GUI-Testskripte für Schulungen / Produkt-Präsentationen
31

33. (2) Automatisierter Batch-Test eines Inkassomanagementsystems
Rahmenbedingungen:
Test der Batch-Verarbeitung einer Anwendung für das
Inkassomanagement
Prüfung der Äquivalenz nach der automatischen Plattform-Migration
von UDS/Forte nach Java für > 2 Millionen LOC
keine Informationen über die interne Logik der Batch-Verarbeitung
verfügbar, d.h. Black-Box-Test unumgänglich
aufgrund des Testumfanges (90 Batch-Programme mit massiver DB-
Verarbeitung innerhalb von knapp 3 Monaten) nur automatisiert
möglich
32

34. Automatisierter
Batch-Test mit
dem Diff-Tool
33

35. Implementierung eines intelligenten DB-/File-Diff-Werkzeuges
Funktionsumfang eines Vergleichswerkzeuges für Batch-Programme:
Automatischer Abgleich der geänderten DB-Inhalte und / oder der erzeugten Ausgabedateien
auf Differenzen.
Das Werkzeug kann parametrisiert werden, z.B.:
• beim DB-Diff Beziehungen verfolgen
• beim Datei-Diff das Zeilenumbruchformat (UNIX vs. Windows) berücksichtigen
Je Testfall (= Batch) kann konfiguriert werden, z.B.:
• beim DB-Diff Spalten (Timestamp) ausblenden
• beim Datei-Diff ein Header-Kommentar ignorieren
Parametrisierung / Konfiguration über Swing-Dialog oder .properties-Datei
Aufruf manuell über Swing-Dialog oder automatisiert über Java-API
Aufwand für Realisierung: ca. 40 PT
34

36. halb-automatisierte Batch-Testläufe
Batch-Testlauf manuell vorbereiten (Eingabedateien, Datenbank).
Batch-Ausführung erfolgt durch eine JUnit-Testklasse.
Während der Batch-Ausführung werden per AOP die modifizierten DB-Tabellen
ermittelt und dieses Wissen für den DB-Diff verwendet.
Aufruf des Diff-Werkzeuges per Java-API aus der JUnit-Testklasse.
Diff-Protokoll-Dateien müssen manuell ausgewertet werden.
35

37. Thema
1. Motivation und Ziele von automatisierten Software-Tests
2. Manuelle Software-Tests und deren Nachteile
3. Grundbegriffe der Testautomatisierung
4. Bausteine für automatisierte Software-Tests
5. Anwendungsbeispiele
6. Problemfelder der Testautomatisierung und
Gegenmaß
Gegenmaßnahmen
7. Potenzial von automatisierten Software-Tests
36

38. Problemfelder der Testautomatisierung und Gegenmaßnahmen (1)
Testautomatisierung auf Open Source Basis kann ein aufwendiges Software-
Entwicklungsprojekt sein:
Mitarbeiter-Qualifikation, Entwicklungsprozess, Qualität, ...
=> Integration mit SUT-Entwicklung; testgetriebene Software-Entwicklung
Testautomatisierung verursacht zunächst nicht unerhebliche Kosten, ohne dass ein
direkter Nutzen entsteht.
=> konkrete, inkrementelle Test-Ziele; depth-first-Testansatz
Erstellung von Testfall-Implementierungen:
• kann aufwendig sein
• erfordert ein qualitativ hohes Mitarbeiter-Profil
• "bewährte" Vorgehensweisen müssen aufgebrochen werden
=> Schulung / Coaching; Benutzer-adäquate Werkzeug-Unterstützung
37

39. Problemfelder der Testautomatisierung und Gegenmaßnahmen (2)
Weiterentwicklung des SUT bedingt entsprechende Pflege der Testfall-
Implementierungen und Testdatenbanken.
=> organisierter und permanenter Prozess der Test-Wartung
Automatisierte Testfälle sind anfällig gegenüber der SUT-
Weiterentwicklung oder geänderten Testdaten.
=> Entkopplung / Abstraktion: z.B. Trennung Testfall vs. Testdaten
Automatisierte Ergebnisprüfung ist nicht-trivial:
• nicht alle möglichen Testergebnisse sind vorhersagbar
• Testergebnisse ändern sich aufgrund von SUT-Änderungen
=> Entkopplung / Abstraktion: z.B. Trennung Testfall vs. Testergebnis
38

40. Thema
1. Motivation und Ziele von automatisierten Software-Tests
2. Manuelle Software-Tests und deren Nachteile
3. Grundbegriffe der Testautomatisierung
4. Bausteine für automatisierte Software-Tests
5. Anwendungsbeispiele
6. Problemfelder der Testautomatisierung und Gegenmaßnahmen
Software-
7. Potenzial von automatisierten Software-Tests
39

41. Potenzial von automatisierten Software-Tests (1)
Übergang vom manuellen Software-Test durch qualifizierte Mitarbeiter zur
automatisierten Testausführung:
Mitarbeiter für die Erstellung automatisierbarer Testfälle verfügbar machen
Automatisierte Durchführung aller notwendigen, aber einfachen Tests:
Mitarbeiter für die fachlich komplexen, evtl. nicht sinnvoll automatisierbaren
Tests verfügbar machen
Durchführung von Tests, die eine stets exakte Wiederholung der
Programmausführung voraussetzen (z.B. definiertes Laufzeitverhalten)
40

42. Potenzial von automatisierten Software-Tests (2)
Durchführung von Regressionstests:
häufige, exakte Wiederholung
Durchführung von Lasttests:
Vielzahl von (simulierten) Benutzern greifen parallel auf das SUT zu
Reproduktion von aufwendig zu erzeugenden Laufzeitfehlern, um
Fehlerbehebung und Re-Test zu unterstützen
Beschleunigung der gesamten Testausführung
bessere Software-Qualität durch Erhöhung von Testabdeckung und
Testintensität
41

43. Vielen Dank für Ihr Interesse!
Haben Sie
Fragen
Anregungen
eigene Erfahrungen
Kritik
???
42