Automatisierter Software-Test unter Java

Automatisierter SoftwareAutomatisierter SoftwareAutomatisierter SoftwareAutomatisierter Software----Test unter JavaTest unter JavaTest unter JavaTest unter Java

Treffpunkt Semicolon, 18.09.2007

Jens Seekamp, GEDOPLAN GmbH

1

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

2

Thema

1.1.1.1. Motivation und Ziele von automatisierten SoftwareMotivation und Ziele von automatisierten SoftwareMotivation und Ziele von automatisierten SoftwareMotivation und Ziele von automatisierten Software----TestsTestsTestsTests







3

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

4

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

5

Thema


2.2.2.2. Manuelle SoftwareManuelle SoftwareManuelle SoftwareManuelle Software----Tests und deren NachteileTests und deren NachteileTests und deren NachteileTests und deren Nachteile3. Grundbegriffe der Testautomatisierung





6

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.

7

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

8

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

9

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.

10

Thema



3.3.3.3. Grundbegriffe der TestautomatisierungGrundbegriffe der TestautomatisierungGrundbegriffe der TestautomatisierungGrundbegriffe der Testautomatisierung4. Bausteine für automatisierte Software-Tests




11

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

12

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)

13

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.

14

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"

15

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.

16

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.

17

Thema




4.4.4.4. Bausteine fBausteine fBausteine fBausteine füüüür automatisierte Softwarer automatisierte Softwarer automatisierte Softwarer automatisierte Software----TestsTestsTestsTests5. Anwendungsbeispiele



18

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

19

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.

20

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

21

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.

22

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

23

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

24

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

25

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

26

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?

27

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

28

Thema





5.5.5.5. AnwendungsbeispieleAnwendungsbeispieleAnwendungsbeispieleAnwendungsbeispiele6. Problemfelder der Testautomatisierung und Gegenmaßnahmen


29

(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 einenAbnahmetest 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

30

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

31

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

32

(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

33

Automatisierter Batch-Test mit dem Diff-Tool

34

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

35

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.

36

Thema






6.6.6.6. Problemfelder der Testautomatisierung und Problemfelder der Testautomatisierung und Problemfelder der Testautomatisierung und Problemfelder der Testautomatisierung und GegenmaGegenmaGegenmaGegenmaßßßßnahmennahmennahmennahmen


37

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

38

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

39

Thema







7.7.7.7. Potenzial von automatisierten SoftwarePotenzial von automatisierten SoftwarePotenzial von automatisierten SoftwarePotenzial von automatisierten Software----TestsTestsTestsTests

40

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 automatisierbarenTests verfügbar machen

Durchführung von Tests, die eine stets exakte Wiederholung der Programmausführung voraussetzen (z.B. definiertes Laufzeitverhalten)

41

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

42

Vielen Dank für Ihr Interesse!

Haben Sie

Fragen

Anregungen

eigene Erfahrungen

Kritik

???

Automatisierter Software-Test unter Java

Technology

Transcript of Automatisierter Software-Test unter Java