User manual | Entwurf und Implementierung einer Web-Test Anwendung

Technische Universität Darmstadt
Fachbereich Informatik
Fachgebiet: Theoretische Informatik
Prof. Dr. Johannes Buchmann
Entwurf und Implementierung
einer Web-Test Anwendung
und
Integrierung in die Eclipse IDE
Diplomarbeit
Tekla Kiss und Alexander Grahl
Betreuer: Markus Ruppert
25. Juni 2004
Vorwort
Testen ist eine Last! Das behaupten zumindest die Meisten, die mit
Softwareentwicklung zu tun haben. Testen wird häufig als wenig kreativ empfunden,
es kostet Zeit, Nachdenken und damit zusätzlich auch noch Geld! Fast alle in der
Softwarebranche wissen zwar, wie wichtig Testen ist, versuchen aber dennoch,
diesem Problem aus dem Wege zu gehen.
Manager, Projektleiter, etc. planen aus Kostengründen oft gar keine oder nur sehr
wenig Zeit für das Testen ein. Dieses Vorgehen schlägt in den meisten Fällen zurück,
weil durch fehlendes Testen nur mehr Kosten entstehen (z.B. in Form der
Wartungskosten).
Programmierer stehen ständig unter Zeitdruck und finden kaum die Zeit dafür, sind
manchmal zu desinteressiert oder auch zu stolz, um ihre selbsterstellte Software zu
testen.
In dieser Diplomarbeit wird zwar das Problem „Testen“ nicht gelöst, vielmehr wird
eine Automatisierung der „black box“ Testfälle für Webanwendungen ermöglicht. Für
die Entwicklung heißt das, dass Tests komfortabel über eine Benutzeroberfläche
erstellt, verwaltet und ausgeführt werden können. Programmierer, Tester, bzw.
Qualitätsmanager müssen den Testablauf immer noch planen. Diese Tests müssen
aber nicht von Hand ausgeführt werden und stehen zur erneuten Ausführung sowie
Korrektur immer zur Verfügung. Ein weiterer wichtiger Punkt ist, dass die
Testabläufe und Testergebnisse mitdokumentiert werden. So wird eine bessere
Nachvollziehbarkeit der Fehler ermöglicht und damit auch eine schnellere,
effizientere Korrektur.
An dieser Stelle möchten wir Herrn Markus Ruppert für die eröffneten Möglichkeiten
und seine Unterstützung bei dieser Arbeit danken. Er hat viele neue Impulse gegeben,
dennoch aber gezielt vermieden, uns in der selbstständigen Arbeit einzuschränken.
-i-
Inhaltsverzeichnis
1 Einleitung...........................................................................................................................................2
1.1 Aufgabenbeschreibung...............................................................................................................2
1.2 Aufbau des Dokuments..............................................................................................................3
2 Einführung ins Testen........................................................................................................................4
2.1 Definitionen...............................................................................................................................4
2.2 White- box Testen......................................................................................................................5
2.2.1 Anweisungsüberdeckungstest............................................................................................6
2.2.2 Zweigüberdeckungstest......................................................................................................8
2.2.3 Pfadüberdeckungstest.........................................................................................................8
2.2.4 Bedingungsüberdeckungstest.............................................................................................9
2.2.5 Zusammenfassung............................................................................................................11
2.3 Black- box Testen....................................................................................................................11
2.3.1 Funktionsabdeckung.........................................................................................................12
2.3.2 Funktionale Äquivalenzklassenbildung...........................................................................13
2.3.3 Grenzwertanalyse.............................................................................................................13
2.3.4 Ursache- Wirkungsgraph..................................................................................................14
2.3.5 Zufallstest.........................................................................................................................15
2.3.6 Fehlererwartung...............................................................................................................16
2.3.7 Zusammenfassung............................................................................................................16
2.4 Tests im Software-Entwicklungsprozess.................................................................................16
2.4.1 Modultest..........................................................................................................................16
2.4.2 Integrationstest.................................................................................................................17
2.4.3 Systemtest.........................................................................................................................17
2.4.4 Abnahmetest.....................................................................................................................19
2.4.5 Zusammenfassung............................................................................................................20
3 Einführung Software Komponenten................................................................................................21
3.1 Definition.................................................................................................................................21
3.2 Verwendung.............................................................................................................................22
3.2.1 Vorteile.............................................................................................................................22
3.2.2 Nachteile..........................................................................................................................23
3.3 Zusammenfassung....................................................................................................................24
4 Einführung Plugins..........................................................................................................................25
4.1 Definition.................................................................................................................................25
4.2 Eclipse......................................................................................................................................26
4.2.1 Architektur.......................................................................................................................26
4.2.2 Plugin-Model....................................................................................................................31
4.3 Vorteile....................................................................................................................................34
4.4 Nachteile..................................................................................................................................34
4.5 Zusammenfassung....................................................................................................................35
5 Planung Testausführer.....................................................................................................................36
5.1 Vorüberlegungen......................................................................................................................36
5.1.1 HTML...............................................................................................................................36
5.1.2 XML.................................................................................................................................37
5.2 Simulation des Browserzugriffs...............................................................................................38
5.2.1 HttpUnit............................................................................................................................39
5.2.2 HtmlUnit..........................................................................................................................40
5.2.3 JwebUnit..........................................................................................................................41
5.3 Anwendungsbereich.................................................................................................................42
5.4 Anforderungen.........................................................................................................................43
- ii -
5.5 Teststruktur..............................................................................................................................44
6 Planung Plugin.................................................................................................................................47
6.1 Vorüberlegung.........................................................................................................................47
6.1.1 XML Unterstützung.........................................................................................................48
6.1.2 Editoren............................................................................................................................49
6.1.3 Navigation und Ansichten................................................................................................50
6.1.4 Darstellung der Testergebnisse........................................................................................51
6.1.5 Hilfe..................................................................................................................................52
6.1.6 Refactoring.......................................................................................................................53
6.1.7 Andere Werkzeuge...........................................................................................................54
6.1.8 Zusammenfassung............................................................................................................54
7 Umsetzung Testausführer................................................................................................................56
7.1 Architektur...............................................................................................................................56
7.1.1 Konfiguration...................................................................................................................57
7.1.2 Steuerung..........................................................................................................................57
7.1.3 HTML Elemente..............................................................................................................58
7.1.4 Fehler................................................................................................................................59
7.2 Testsammlungsdatei.................................................................................................................60
7.2.1 Definition.........................................................................................................................60
7.2.2 Ausführung.......................................................................................................................60
7.2.3 Fehlerbehandlung.............................................................................................................60
7.2.4 Beispiel.............................................................................................................................61
7.3 Testdatei...................................................................................................................................62
7.3.1 Definition.........................................................................................................................62
7.3.2 Ausführung.......................................................................................................................62
7.3.3 Fehlerbehandlung.............................................................................................................63
7.3.4 Beispiel.............................................................................................................................64
7.4 Moduldatei...............................................................................................................................65
7.4.1 Definition.........................................................................................................................65
7.4.2 Ausführung.......................................................................................................................65
7.4.3 Fehlerbehandlung.............................................................................................................66
7.4.4 Beispiel.............................................................................................................................66
7.5 Schnittstellen............................................................................................................................66
7.5.1 Assert................................................................................................................................66
7.5.2 Massentest........................................................................................................................69
7.5.3 Logger..............................................................................................................................72
8 Umsetzung Plugin............................................................................................................................74
8.1 Architektur...............................................................................................................................74
8.2 Plugin Struktur.........................................................................................................................75
8.2.1 Feature..............................................................................................................................75
8.2.2 Kern..................................................................................................................................76
8.2.3 Allgemeine Oberfläche....................................................................................................80
8.2.4 Editoren............................................................................................................................85
8.2.5 Hilfe..................................................................................................................................91
8.2.6 Update Site.......................................................................................................................93
9 Anwendungsbeispiel........................................................................................................................94
9.1 Testumgebung..........................................................................................................................94
9.2 Teststruktur..............................................................................................................................94
9.3 Testergebnis.............................................................................................................................95
10 Ausblick.........................................................................................................................................96
- iii -
Abbildungsverzeichnis
Abbildung 1 Programmgraph...............................................................................................................6
Abbildung 2 Programmgraph für Fakultätsberechnung.......................................................................7
Abbildung 3 Kategorien des "white- box Testens"............................................................................11
Abbildung 4 Funktionale Testfallmatrix............................................................................................13
Abbildung 5 Ursache- Wirkungsgraph...............................................................................................15
Abbildung 6 Entscheidungstabelle zum Ursache- Wirkungsgraph....................................................15
Abbildung 7 Kategorien von Testaufgaben........................................................................................20
Abbildung: 8 Eclipse Plattform Architekur........................................................................................27
Abbildung: 9 Workspace Resourcemapping......................................................................................28
Abbildung: 10 Model-View-Controller..............................................................................................30
Abbildung 11 Anwendbarkeit von "black-box" Tests........................................................................42
Abbildung 12 XML Struktur des Entwicklungsprozesses..................................................................45
Abbildung 13 Eclipse: Model-View-Controller.................................................................................48
Abbildung 14 Digester XML- / Objektstruktur..................................................................................49
Abbildung 15 Eclipse: PDE Editor.....................................................................................................49
Abbildung 16 Eclipse: PDE Editor Registerkarten............................................................................50
Abbildung 17 Eclipse: Navigator für Resourcen................................................................................51
Abbildung 18 Eclipse: Ansicht der Eigenschaften.............................................................................51
Abbildung 19 Eclipse: Anischt JUnit.................................................................................................52
Abbildung 20 Eclipse: Kontexthilfe...................................................................................................52
Abbildung 21 Eclipse: Onlinehilfe.....................................................................................................53
Abbildung 22 Eclipse: Java Rename Dialog......................................................................................54
Abbildung 23 Architektur des Testausführers....................................................................................56
Abbildung 24 Architektur WebTest Plugin........................................................................................74
Abbildung 25 Verwendung von Features...........................................................................................76
Abbildung 26 WebTest initial Perspektive.........................................................................................81
Abbildung 27 UI Plugin: Präferenzseite.............................................................................................82
Abbildung 28 Verwendung von Actions............................................................................................83
Abbildung 29 Verwendung von Natures............................................................................................84
Abbildung 30 Ansicht WebTest Navigator........................................................................................85
Abbildung 31 Editor: Testsammlung.................................................................................................86
Abbildung 32 Editor: Testsammlung Quellkode................................................................................87
Abbildung 33 Editor: Kodevervollständigung....................................................................................88
Abbildung 34 Editor: Übersichtsregisterkarte....................................................................................88
Abbildung 35 Eigenschaftsanzeige.....................................................................................................89
Abbildung 36 Eigenschaftsanzeige: Listenfeld..................................................................................90
Abbildung 37 WebTest Hilfe.............................................................................................................91
Abbildung 38 Kontexthilfe im Editor.................................................................................................92
Abbildung 39 Installation: Update Manager öffnen.............................................................................4
Abbildung 40 Installation: Site Bookmark erstellen............................................................................5
- iv -
Abbildung 41 Installation: Feature auswählen.....................................................................................5
Abbildung 42 Installation: Feature Dialog...........................................................................................6
Abbildung 43 Struktur der HTML Testverfolgung ...........................................................................11
-v-
Literaturverzeichnis
[Bal89] Helmut Balzert, Die Entwicklung von Software-Systemen: Prinizpien - Methoden Sprachen - Werkzeuge, 1989, Wissentschaftsverlag, ISBN 3411016183
[Bal98] Helmut Balzert, Lehrbuch der Software- Technik: Software- Management, SoftwareQualitätssicherung, Unternehmensmodellierung, 1998, Spektrum Akademischer Verlag, ISBN
3827400651
[Bol03] Azad Bolour, Notes on the Eclipse Plug-in Architecture, 2003,
http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html
[Dig04] Apache Software Foundations, Commons Digester, 2004,
http://jakarta.apache.org/commons/digester/
[Ecl03a]
Object Technology International, Inc., Eclipse PlatformTechnical Overview, 2001, -,
http://www.eclipse.org/whitepapers/eclipse-overview.pdf
[Ecl04] Eclipse.org, Eclipse, 2004, http://www.eclipse.org/
[Equi04]
Eclipse.org, equinox, 2004, http://www.eclipse.org/equinox/index.html
[FlexSec04] FlexSecure, Bausteine für Public-Key-Infrastrukturen, 2004,
http://www.flexsecure.de/ojava/home.html
[Gam95]
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns:
Elements of Reusable Object-Oriented Software, 1995, Addison-Wesley, ISBN 0201633612
[Html01]
Stefan Münz, SELFHTML, 2001, http://de.selfhtml.org
[Java04]
Sun Microsystems, Java, 2004, http://java.sun.com/
[Junit04]
Junit.org, Junit, 2004, http://www.junit.org/index.htm
[Kun98]
Kuno Dünhölter, Das Web automatisieren mit XML, 1998,
http://members.aol.com/xmldoku/
[Link02]
Johannes Link, Unit Tests mit Java, 2002, dpunkt.verlag, ISBN 3898641503
[Log4j04]
Apache Software Foundations, Logging services, 2004, http://logging.apache.org
[Mmv03]
Klaus Marquardt, Markus Völter, Plug-Ins - applikationsspezifische Komponenten,
2003, JavaSpektrum, [Mye95]
ISBN -
Glenford J. Myers, Methodisches Testen von Programmen, 1995, Oldenburg Verlag,
[Sam97]
Johannes Sametinger, Software Engineering with Reusable Components, 1997,
Springer, ISBN 3540626956
[Sch03] Jörn Schumacher, Eine Plugin-Architektur für Renew - Konzepte, Methoden, Umsetzung,
Universität Hamburg, Fachbereich Informatik, Arbeisgebiet TGI, 2003
[Sha03]
Sherry Shavor, Jim D´Anjou, Scott Fairbrother, Dan Kehn, John Kellerman, Pa, The
Java Developer´s Guide to Eclipse, 2003, Addison-Wesley, ISBN 0321159640
[Sin01] Vipan Singla, Don't Use System.out.println!Use Log4j, 2001, -,
http://logging.apache.org/log4j/docs/documentation.html
[Som98]
Alan Sommerer, The Java Archive (JAR) File Format, 1998,
http://java.sun.com/developer/Books/javaprogramming/JAR/
- vi -
[Wal90]
Ernest Wallmüller, Software- Qualitätssicherung, 1990, Carl Hanser Verlag, ISBN
3446158464
[Wiki04]
Wikipedia, Wikipedia die freie Enzyklopädie, 2004,
http://de.wikipedia.org/wiki/Metasprache
- vii -
Ehrenwörtliche Erklärung
Hiermit versichern wir, die vorliegende Diplomarbeit ohne Hilfe Dritter und nur mit den
angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus den Quellen
entnommen wurden, sind als solche kenntlich gemacht worden. Diese Arbeit hat in gleicher oder
ähnlicher Form noch keiner Prüfungsbehörde vorgelegen.
Darmstadt, Juni 2004
___________________
Tekla Kiss
__________________
Alexander Grahl
-1-
Kapitel 1 : Einleitung
1 Einleitung
Das Motiv für die Wahl dieses Themas war die Arbeit. Immer wieder war zu erkennen, dass
Webanwendungen gar nicht oder nur „per Hand“ getestet wurden. Dieses „per Hand“ Testverfahren
ist allerdings aus mehreren Gründen sehr unbefriedigend:
1. Geringe Motivation des Testers, da es eine monotone, uninteressante Arbeit darstellt, nämlich:“
Webseite aufmachen, ausfüllen, abschicken, Ergebnis prüfen“....und das 1000 mal am Tag!
2. Es ist unzuverlässig. Menschen machen Fehler, bemerken kleine Änderungen nicht immer,
bekommen die internen Fehler oft nicht in der Oberfläche zu sehen!
3. Es werden oft keine aussagekräftigen Protokolle über Testausführung, Testablauf und Erfolg oder
Misserfolg des Testens geführt!
4. Fehler können oft nicht von den Entwicklern nachvollzogen werden und sind dadurch nicht
reproduzierbar.
5. Der Testablauf geht nach der Ausführung verloren; er steht danach nicht nochmals einzeln oder
zusammen zur Verfügung.
6. Tests sind insgesamt sehr zeitaufwändig durchzuführen, insbesondere Massentests.
Man kann also zusammenfassen, dass diese intuitive Art des Testens sicher noch einiger
Verbesserungen bedarf.
1.1 Aufgabenbeschreibung
Nachdem wir uns auf dem Markt umgesehen hatten, fanden wir heraus, dass die vorhandenen
Werkzeuge zum Testen von Webanwendungen nicht unseren Vorstellungen entsprachen. Sie boten
häufig nicht genügend Flexibilität und Funktionen oder waren einfach nicht komfortabel zu
bedienen. Es kam auch vor, dass für die Verwendung der Software hohe Preise verlangt wurden und
dadurch der Einsatz in kleineren Projekten verhindert wurde.
Als Konsequenz daraus wollen wir ein Werkzeug erstellen, das die zuvor aufgeführten Mängel nicht
hat und in einem breiten Spektrum von Webanwendungen zum Testen eingesetzt werden kann.
Folgende Ansprüche setzen wir an unsere Anwendung:
1. Ohne großen Aufwand, schnell einfache Testfälle erstellen.
2. Hohe Flexibilität beim Strukturieren der Testfälle.
3. Breites Angebot zur Verwendung von Schnittstellen zum Einbinden eigener
Überprüfungsmethoden, Massendaten und Loggern.
4. Unterstützung beim Erstellen der Tests durch eine graphische Oberfläche.
5. Aussagekräftige Fehlerprotokolle über Ablauf und Ergebnis.
Bei der Konzeptierung der Software sollte so weit wie möglich auf vorhandene Implementationen
zurückgegriffen werden, um schnell einen Prototyp zu entwickeln. Nur an Stellen, wo vorhandene
Werkzeuge oder Bibliotheken keine ausreichende Unterstützung bieten, muss eine eigene
Implementation erfolgen.
Die Software wird sich dabei in drei Teile gliedern:
-2-
Kapitel 1 : Einleitung
1. Definition von Testabläufen und deren Speicherformat.
2. Programm zum Ausführen der Tests.
3. Oberfläche zum Erstellen und Bearbeiten der Tests.
Die Punkte zwei und drei werden von verschiedenen Personen entwickelt. Der Datenaustausch
zwischen den verschiedenen Anwendungen wird in Punkt >1< durch die festgelegten Definitionen
und Speicherformate ermöglicht. Die Entwicklung dieser Schnittstelle muss gemeinsam erfolgen.
1.2 Aufbau des Dokuments
Dieses Kapitel (1 Einleitung Seite 2) beschreibt die Motivation und Aufgabenstellung dieser
Diplomarbeit.
Um das Verständnis der eigentlichen Arbeit zu erleichtern, wird eine kurze theoretische Einführung
in die Materie des Testens (Kapitel 2 Einführung ins Testen Seite 4) und der Verwendung von
Komponenten und Plugins (Kapitel 3 Einführung Software Komponenten Seite 21 und Kapitel 4
Einführung Plugins Seite 25) gegeben.
Zum Einen gibt es eine Einführung, warum Testen eine so wichtige Rolle zugeordnet werden sollte,
zum Anderen werden verschiedene Testarten beleuchtet und deren Vor- bzw. Nachteile aufgeführt.
Bei der Einführung in Komponenten und Plugins soll dann ein Grundverständnis geschaffen werden,
was eine Komponente bzw. Plugin ist und welche Vor- oder Nachteile bei ihrer Verwendung
entstehen.
Es folgt dann die Planungsphase unseres Werkzeuges (Kapitel 5 und 6). Die theoretischen
Grundlagen der vorherigen Kapitel bilden hier die Basis für bestimmte Designentscheidungen.
In den Kapiteln der Umsetzung (Kapitel 7 und 8) geht es dann um die Implementierung unseres
Konzeptes. Der in der Planung festgelegte Aufbau und die definierten Ziele werden in konkrete
Implementationen umgesetzt. Dabei werden auch Schwierigkeiten bei der Umsetzung und deren
Lösung aufgezeigt.
Im Anwendungsbeispiel (Kapitel 9) wird unser Prototyp zum Testen der FlexiTrust Webschnittstelle
verwendet. Es soll dabei die Funktion und Tauglichkeit unserer Software zum Testen demonstriert
werden.
Im letzten Kapitel (Kapitel 10) geben wir eine kurze Zusammenfassung unserer Ergebnisse. Dabei
geht es darum, in wie weit wir unsere Ziele erreicht haben und wo noch Verbesserungen statt zu
finden haben. Es soll auch betrachtet werden, wo die Entwicklung noch hingehen könnte.
Da die Diplomarbeit von zwei Personen erstellt wurde, finden sie im Anhang eine Übersicht der von
den Personen bearbeiteten Kapitel.
-3-
Kapitel 2 : Einführung ins Testen
2 Einführung ins Testen
In diesem Kapitel wird eine kleine Einführung ins Testen gegeben. Diese fängt mit der
Begriffsklärung an. Hier werden die Definitionen für wichtige Begriffe, wie Testen, Fehler, Testfall
etc. angegeben und die Ziele des Testens diskutiert. Dem folgen die Beschreibungen von den zwei
Hauptkategorien des Testens: „white- box“ Testen und „black-box“ Testen. Schließlich wird ein
Einblick in verschiedenen Testarten im Rahmen des Software- Entwicklungsprozesses gewährt.
2.1 Definitionen
Um von Testen reden zu können, müssen wir erst definieren, was „Testen“ ist. Ein allgemeiner
Irrtum unter Entwicklern und Managern ist es oft, dass Testen zeigen soll, dass die Software
funktioniert. Das ist aber nicht das Ziel des Testens!
„Testen ist der Prozeß, ein Programm mit der Absicht auszuführen, Fehler zu
finden!“[Mye95]
Wie man leicht erkennen kann, ist Testen ein kontraproduktiver Prozess zur Entwicklung. Dies ist
wohl der Grund dafür, dass Entwickler ungern und nicht ausreichend gut ihre Code testen wollen,
bzw. können.
Testen allgemein sollte im Idealfall folgende Ziele verfolgen:[Wal90]
•
Mit jedem Test müssen sinnvolle, vordefinierte Ziele erreicht werden. Testen ohne Plan ist eine
Vergeudung von Zeit und Geld.
•
Testziele müssen erreichbar und messbar definiert sein.
•
Für jeden Test muss ein Endekriterium vorgesehen werden.
•
Jedes Testergebnis muss kontrolliert werden.
Was sind aber eigentlich die Fehler, um dessen Auffindung es geht?
„Ein Fehler ist...
•
•
eine Abweichung zwischen Ist-Verhalten ( im Testlauf festgestellt) und Soll-Verhalten
( in der Spezifikation gefordert).
nicht erfülltes, vom Kunden vorausgesetztes, Qualitätskriterium“[Bal98].
Jetzt bleibt noch die Frage, wie ein Test erstellt, bzw. wie er beschrieben werden kann, damit er
ausführbar wird? Die Beschreibung des Tests heißt Testfall und wird folgendermaßen definiert.
„Ein Testfall ist:
Ein Satz von Testdaten, der die vollständige Ausführung des zu testenden Programmes
verursacht.“[Bal98].
„Ein Testdatum ist:
-4-
Kapitel 2 : Einführung ins Testen
Ein Satz von Eingabe-und Zustandswerten für einen Softwareobjekt mit zugehörigen
Ausgabe- Sollwerten.“[Bal98].
Die einfachste Art des Testens ist, die Software mit Zufallseingaben zu versorgen und so
auszuführen. Diese Testart lässt allerdings viel zu wünschen übrig. Wie schon erwähnt wurde, geht
es bei der Auswahl der Testfälle darum, möglichst viele Fehler aufzudecken. Laut Erfahrung wird
aber mit Zufallseingaben nur ein sehr geringer Anteil der Fehler aufgedeckt.
Es werden also Vorgehensweisen gebraucht, die eine systematische Wahl der Testfälle erlauben, so
dass die gewählten Testfälle mit hoher Wahrscheinlichkeit Fehler finden.
Nach der Methode der Testfallunterscheidung werden zwei Hauptkategorien des Testens
unterschieden:
•
White-box Testen (Code ist bekannt!)
•
Black-box Testen (Code ist unbekannt!)
2.2 White- box Testen
Beim „white- box Test“ steht dem Tester der gesamte Quellcode zur Verfügung. Mit Hilfe dieser
Kenntnisse werden die Testfälle erstellt. Es wird also die interne Umsetzung der Spezifikation, die
korrekte Implementierung der einzelnen Methoden, bzw. Einheiten getestet. Ein großer Nachteil
dieses Testens ist, dass die Spezifikation an sich nicht geprüft wird.
Erwartete Kenntnisse des Testers:
•
technische Umsetzung der Anwendung
•
Programmiersprach-, Programmierkentnisse
•
Fehleranalyse
Um das Testen sinnvoll unterstützen zu können, wird die Programmstruktur als Programmgraph
dargestellt.
„Ein Programmgraph ist ein gerichteter Graph. Jede Anweisung wird als Knoten im
Graph dargestellt. Jeder mögliche Kontrollfluss von einer Anweisung zur Nächsten wird
durch eine Kante dargestellt.“ [Bal89]
•
Beispiel: Ein einfacher Programmgraph mit 220 Pfaden
-5-
Kapitel 2 : Einführung ins Testen
Abbildung 1 Programmgraph
Um alle Fehler in der Implementierung aufzudecken, wäre ein erschöpfender Pfadtest notwendig.
Dieser schreibt vor, dass im Programm alle möglichen logischen Pfade getestet werden sollen. Da die
Anzahl der logischen Pfade sehr schnell zu hoch wird, ist ein solcher Test aus finanziellen, aber auch
zeitlichen Gründen nicht realisierbar. So wird nach anderen Strategien gesucht, um ein möglichst
überdeckendes, aber auch machbares Testen zu ermöglichen. [Bal98]
2.2.1 Anweisungsüberdeckungstest
Der Anweisungsüberdeckungstest fordert, dass jede Anweisung des Programms mindestens einmal
ausgeführt wird. Dabei werden Sprünge, Entscheidungen, und Schleifen außer Acht gelassen.
-6-
Kapitel 2 : Einführung ins Testen
Start
ja
(a)
nein
N<0
ja
FAK=-1
(c)
(d)
(b)
FAK=1
nein
N=0
ja
(f)
(g)
nein
N=1
(h)
FAK=N
K=N-1
(i)
(k)
(e)
ja
(j)
FAK=FAK*K
K=K-1
FAKULTAET=FAK
K<>0
nein
(l)
Ende
Abbildung 2 Programmgraph für Fakultätsberechnung
Für den Programmgraphen heißt es, dass alle Knoten außer den Entscheidungsknoten (Knoten mit
mehreren Ausgangspfeilen) mindestens einmal ausgeführt werden müssen.
•
Beispiel: Fakultät berechnen Abbildung 1 Programmgraph
Testfälle:
•
N= -1 => Sollergebnis= -1,
Pfad: a, b (hellgraue Kasten)
•
N= 0 => Sollergebnis= 1,
Pfad: c, d, e (mittelgraue Kasten)
•
N= 2 => Sollergebnis= 2,
Pfad: c, g, h, i, j, k, l (dunkelgraue Kasten)
Der Anweisungsüberdeckungstest stellt nur sicher, dass keine Anweisungen existieren, die nie
-7-
Kapitel 2 : Einführung ins Testen
ausgeführt werden und hat damit eine sehr geringe Fehleridentifizierungsquote. So ist dieser Test ein
notwendiges, aber nicht ausreichendes Testkriterium.
2.2.2 Zweigüberdeckungstest
Dieser Test erfasst alle Sprünge und Entscheidungen im Programm. Das entspricht mindestens einer
Ausführung aller Kanten, sprich aller Pfeile im Programmgraph.
•
Beispiel: Fakultät berechnen Abbildung 1 Programmgraph
Testfälle:
•
N= -1 => Sollergebnis= -1,
Pfad: a, b (hellgraue Pfeile)
•
N= 0 => Sollergebnis= 1,
Pfad: c, d, e (mittelgraue Pfeile)
•
N= 2 => Sollergebnis= 2,
Pfad: c, g, h, i, j, k, l (dunkelgraue Pfeile)
•
N= 1 => Sollergebnis= 1,
Pfad: c, g, f, e (restliche Pfeile)
Dieser Test stellt sicher, dass keine Zweige existieren, die nie ausgeführt wurden. Kombinationen
von Zweigen und komplexere Bedingungen werden nicht berücksichtigt. Schleifen werden nicht
ausreichend getestet. Der Zweigsüberdeckungstest enthält vollständig den
Anweisungsüberdeckungstest und gilt als das minimale Testkriterium.
2.2.3 Pfadüberdeckungstest
Der Pfadüberdeckungstest deckt alle Pfade zwischen Ausgangspunkt und Endpunkt ab. Das bedeutet,
dass hier auch alle Schleifen beachtet werden. Zwei Pfade gelten als gleich, wenn die Anweisungen
paarweise identisch und die Länge des Pfades gleich ist.
•
Beispiel: Fakultät berechnen Abbildung 1 Programmgraph
Testfälle:
•
N= -1 => Sollergebnis= -1,
Pfad: a, b
•
N= 0 => Sollergebnis= 1,
Pfad: c, d, e
•
N= 1 => Sollergebnis= 1,
Pfad: c, g, f, e
•
N= 2 => Sollergebnis= 2,
Pfad: c, g, h, i, j, k, l
•
N=3 => Sollergebnis= 6,
-8-
Kapitel 2 : Einführung ins Testen
Pfad: c, g, h, i, j, k, j, k, l
•
N=4 ...
•
....
Dieses ist das mächtigste der beschriebenen Testverfahren, er enthält vollständig den zuvor
beschriebenen Zweigüberdeckungstest. Er ist leider nicht praktikabel; insbesondere auf Grund der
entstehenden Testfallanzahl. Die Anzahl der Pfade expandiert bei verschiedenen Bedingungen
innerhalb des Schleifenkörpers exponentiell. Es ist daher oft nicht möglich, alle entstehende Testfälle
auszuführen. Um dieses Problem zu lösen, wurden zwei Unterarten dieses Tests definiert. Das Ziel
dabei ist, Schleifen ausreichend, aber nicht vollständig (mit allen möglichen Pfaden) zu testen.
2.2.3.1 Boundary-interior Pfadtest
Dieser ist eine eingeschränkte, schwächere Variante des Pfadüberdeckungstests. Beim Testen der
Schleifen wird auf die Überprüfung der Pfade verzichtet, die durch mehr als einmalige
Schleifenwiederholung entstehen.
Für jede Schleife entstehen dabei zwei Gruppen von Pfaden:
1. Grenztest (boundary test)
Hier werden alle Pfade ausgeführt, die die Schleife zwar betreten, sie aber nicht wiederholen.
2. Test des Schleifeninneren (innerior test)
Hier werden alle Pfade ausgeführt, die genau eine Wiederholung der Schleife enthalten.
2.2.3.2 Strukturierter Pfadtest
Dieser Test ist eine Verallgemeinerung des boundary-interior Tests. Hierbei werden alle Pfade der
innersten Schleife nicht häufiger, als k- mal ausgeführt.
1. Der Grenztest findet wie beschrieben statt.
2. Beim Test des Schleifeninneren werden alle Pfade ausgeführt, die höchstens k Wiederholungen
der Schleife enthalten.
2.2.4 Bedingungsüberdeckungstest
Im Bedingungsüberdeckungstest werden die Bedingungen in den Wiederholungs- und
Auswahlstrukturen zur Definition der Testfälle herangezogen. Bei der Testdefinition spielt die
Definition der atomaren Bedingung eine große, wichtige Rolle. [Bal98]
„Eine atomare Bedingung ist eine Bedingung, die keine untergeordneten Bedingungen
enthält.“ [Bal98]
Dieser Testart hat drei Ausprägungen, die im Folgenden beschrieben werden.
2.2.4.1 Einfacher Bedingungsüberdeckungstest
Alle atomaren Bedingungen müssen mindestens einmal den Wahrheitswert true und einmal den Wert
false annehmen.
•
Beispiel 1: Aufteilung der Bedingung in atomaren Bedingungen von ( ((a<5) ODER (a>12)) UND
-9-
Kapitel 2 : Einführung ins Testen
(b<=3) )
Die atomaren Bedingungen hier wären (a<5), (a>12) und (b<=3).
•
Beispiel 2: Bestimmen der Testfälle für die Bedingung ( (a>5) UND (b= =1) ).
Die atomaren Bedingungen wären (a>5) und (b= =1). Damit würden die folgenden zwei Testfälle
ausreichen:
•
a=5 (false), b=1 (true) => Gesamtbedingung false
•
a=6 (true), b=0 (false) => Gesamtbedingung false
Wie am Beispiel 2 leicht erkennbar ist, enthält diese Testart nicht den Zweigsüberdeckungstest (da
nicht beide Pfade false und true abgedeckt wurden) und reicht damit nicht als minimales
Testkriterium aus.
2.2.4.2 Mehrfacher Bedingungsüberdeckungstest
Bei dieser Testart werden alle Variationen aus den atomaren Bedingungen gebildet. Bei n atomaren
Bedingungen ergibt das eine Testanzahl von 2n.
•
Beispiel:Bestimmen der Testfälle für die Bedingung ( (a>5) UND (b= =1) ).
Die atomaren Bedingungen seien (a>5) und (b= =1). Damit würden sich 22= 4 Tesfälle ergeben.
Diese könnten die Folgenden sein:
•
a=5 (false), b=0 (false) => Gesamtbedingung false
•
a=5 (false), b=1 (true) => Gesamtbedingung false
•
a=6 (true), b=0 (false) => Gesamtbedingung false
•
a=6 (true), b=1 (true) => Gesamtbedingung true
Diese Testart enthält den Zweigsüberdeckungstest und kann so als minimales Testkriterium benutzt
werden. Sie ist aufwendig zu realisieren und setzt die Identifikation von nicht möglichen
Bedingungskombinationen heraus. Da fehlende Kombinationen nicht unbedingt als Fehler im
Programm zu verstehen sind, ist die Testbeurteilung dieser Methode schwierig.
2.2.4.3 Minimal mehrfacher Bedingungsüberdeckungstest
Jede Bedingung (ob atomar oder nicht) muss mindestens einmal den Wahrheitswert true und einmal
den Wert false annehmen.
•
Beispiel: Bestimmen der Testfälle für die Bedingung ( (a>5) UND (b= =1) )
Die atomare Bedingungen wären (a>5) und (b= =1). Damit würden die folgenden zwei Testfälle
ausreichen:
•
a=5 (false), b=0 (false) => Gesamtbedingung false
•
a=6 (true), b=1 (true) => Gesamtbedingung true
Dieser Test enthält den Zweigsüberdeckungstest, und deckt damit auch das minimale Testkriterium
ab. Er ist eine sinnvolle Erweiterung des Zweigsüberdeckungstests, da durch diese Testart mehr
Fehler aufgedeckt werden können.
- 10 -
Kapitel 2 : Einführung ins Testen
2.2.5 Zusammenfassung
Es wurden viele Verfahren entwickelt um „white- box Testen“ anwendbar und finanzierbar zu
machen. Eine Übersicht dafür bietet Abbildung 3 Kategorien des "white- box Testens".
Abbildung 3 Kategorien des "white- box Testens"
Auf dieser Abbildung ist leicht zu erkennen, welche Testverfahren welche Mächtigkeit aufweisen.
Um mindestens das minimale Testkriterium zu erreichen, muss ein Testverfahren gewählt werden,
das über dem Zweigsüberdeckungstest liegt (bzw. den Zweigüberdeckungstest erhält).
Es ist dabei weiterhin zu beachten, dass auch der mächtigste Test, der Pfadüberdeckungstest, keine
Fehlerfreiheit garantiert.
Gründe dafür können sein: [Wal90]
•
Das Programm entspricht nicht der Spezifikation.
•
Fehlende Pfade im Programm.
2.3 Black- box Testen
Beim „black- box“ Testen steht dem Tester nur die Spezifikation der Anwendung zur Verfügung.
Aus der Spezifikation werden die Testfälle generiert bzw. abgeleitet. Den Code kennt der Tester
nicht oder vorhandene Codekenntnisse werden nicht benutzt. Das heißt also, dass nur die äußere
Struktur getestet wird und nicht die interne Umsetzung. [Bal98]
Um alle Fehler zu finden, sollte man einen vollständigen Eingabetest durchführen. Diese Testart
verlangt, dass das Programm mit allen möglichen (insbesondere auch mit ungültigen Eingaben)
getestet wird.
•
Beispiel: Multiplikation von zwei ganzen Zahlwerten
- 11 -
Kapitel 2 : Einführung ins Testen
Hier hätte man die Testfälle:
•
Ganze Zahl, Ganze Zahl => gültige Eingabe
•
Integer, Kommazahl => ungültige Eingabe
•
Kommazahl, Kommazahl => ungültige Eingabe
•
Zeichenkette, Zahl => ungültige Eingabe
•
...
Es ist leicht einzusehen, dass diese Methode schon bei einfachen Programmen einen zu großen
Zeitaufwand verlangt und dadurch natürlich sehr hohe Kosten verursacht. Es werden also
Mechanismen gebraucht, um eine „sinnvolle“ Menge der Testfälle auszuwählen. Als „sinnvollen“
Testfall werden die Testabläufe angesehen, die mit großer Wahrscheinlichkeit einen Fehler
aufdecken könnten.
Erwartete Kenntnisse des Testers:
•
Spezifikation der Anwendung
•
möglichst keine Programmiersprache-, Programmierkentnisse
•
Fehleranalyse
•
Benutzbarkeits-, Ablauf-, Menschenfehleranalyse
•
Kundenerwartung
2.3.1 Funktionsabdeckung
Bei dieser Testart werden die Funktionen auf ihr Vorhandensein und Funktionalität geprüft. Es wird
dabei auf das Normalverhalten des Testobjekts getestet. Keine spezielle Werte, Ausnahmefälle, etc.
[Wal90]
Allgemeine Vorgehensweise:
1. Anhand konkreter Anwendungsfälle die Funktionen des Testobjekts identifizieren.
2. Für jede Funktion eine Ein- und Ausgabespezifikation erstellen.
3. Testfälle definieren, so dass jede Funktion mindestens einmal abgedeckt wird.
Um diese Testfallerzeugung zu veranschaulichen, wird als Hilfsmittel die sogenannte funktionale
Testfallmatrix erzeugt. Die einzelnen Zeilen geben die Funktionen zum Testen an, die Spalten die
auszuführenden Testfälle. Sie kann helfen die Testfallanzahl zu minimieren.
- 12 -
Kapitel 2 : Einführung ins Testen
Funktion
Testfälle
1
Kundenstamm
initialisieren
2
3
x
x
4
5
6
x
Kundenstamm
aktualisieren
x
Kundenstamm
ausgeben
Kundenstamm
löschen
x
x
x
x
x
x
Abbildung 4 Funktionale Testfallmatrix
•
Beispiel: Minimierung der Testfälle Abbildung 4 Funktionale Testfallmatrix
Anhand der Testfallmatrix muss pro Zeile nur ein „x“ erscheinen.
=> beim Weglassen der Testfälle 4, 5, 6 ist dieses Kriterium immer noch erfüllt.
2.3.2 Funktionale Äquivalenzklassenbildung
Hier werden Definitionsbereich, Wertebereich in Äquivalenzklassen zerlegt. Dabei wird
angenommen, dass Elemente in einer Äquivalenzklasse gleich reagieren. Es sollte nach der
Zerlegung aus jeder Klasse ein beliebiger Testfall getestet werden.
Allgemeine Vorgehensweise:
1. Bestimmung der Äquivalenzklassen (sowohl für den Definitions- als auch für den Wertebereich)
2. Bestimmung der Testfälle (Wahl eines Vertreters aus jeder Äquivalenzklasse.)
3. Prüfung auf Vollständigkeit von den Äquivalenzklassen (Die Äquivalenzklassen dürfen sich auch
überschneiden, sind also nicht im strengen, mathematischen Sinne zu verstehen.)
Die Äquivalenzklassenbildung ist ein geeignetes Verfahren um aus Spezifikationen geeignete
Testfälle abzuleiten. Es werden nur einzelne Eingaben oder Ausgaben betrachtet.
Wechselbeziehungen und Abhängigkeiten zwischen den Werten werden nicht kontrolliert.
•
Beispiel: Fakultät von einer ganzen Zahl zwischen 0 und 10
Hier hätte man die Äquivalenzklassen und damit Testfälle:
•
0 <= Zahl <= 10 (z.B. 6) => gültige Eingabe
•
Zahl < 0 (z.B. -4) => ungültige Eingabe
•
Zahl > 10 (z.B. 13) => ungültige Eingabe
2.3.3 Grenzwertanalyse
Grenzwertanalyse ist eine Erweiterung der funktionalen Äquivalenzbildung. Hier werden
Definitionsbereich und Wertebereich auch in Äquivalenzklassen aufgeteilt. Die Auswahl der
- 13 -
Kapitel 2 : Einführung ins Testen
Testfälle ist nicht beliebig, wie bei der funktionalen Äquivalenzbildung, es werden stattdessen die
Grenzen der Äquivalenzklassen getestet.
Dieses Verfahren beruht auf der Erkenntnis, dass an den Grenzen häufiger Fehler auftreten, als bei
„normalen“ Werten.
Allgemeine Vorgehensweise:
1. Bestimmung der Äquivalenzklassen (sowohl für den Definitions- als auch für den Wertebereich)
2. Bestimmung der Testfälle (Nehmen der Grenzwerte in jede Äquivalenzklasse.)
3. Prüfung auf Vollständigkeit der Äquivalenzklassen
Die Grenzwertanalyse ist nur dann sinnvoll, wenn die Elemente auf eine natürliche Weise geordnet
werden können. Anders formuliert heißt das, dass die Grenzen der Äquivalenzklassen feststellbar
sind.
•
Beispiel: Fakultät von einer ganzen Zahl zwischen 0 und 10
Hier hätte man die Äquivalenzklassen und damit Testfälle:
•
0 <= Zahl <= 10 (0 und 10) => gültige Eingabe
•
Zahl < 0 (-1) => ungültige Eingabe
•
Zahl > 10 (11) => ungültige Eingabe
2.3.4 Ursache- Wirkungsgraph
Ursache- Wirkungsgraph ist eine Methode, die sich nicht nur auf Ein- und Ausgaben konzentriert,
wie Äquivalenzklassenbildung oder Grenzwertanalyse.
„Ursache- Wirkungsgraph ist ein ungerichteter Graph. Die Knoten bezeichnen die
Ursachen und Wirkungen, wobei eine Ursache mit deren Wirkung durch eine Kante
verbunden wird. Die Markierungen der Kanten stammen aus der Boole´schen Algebra.“
[Bal98]
Hier sind noch ein paar Ergänzungen zu dieser Definition nötig.
Eine Ursache ist: eine Eingabebedingung oder eine Äquivalenzklasse von Eingabebedingungen.
Eine Wirkung ist: eine Ausgabebedingung, eine Äquivalenzklasse von Ausgabebedingungen, ein
Zustandsübergang oder ein Ereignis.
Die Markierungen der Kanten können folgende Zeichen sein: Identität, Oder, Und, Negation.
Allgemeine Vorgehensweise:
1. Spezifikation wird in einen Graph übersetzt.
2. Der Graph wird in eine Entscheidungstabelle übertragen.
3. Jede Spalte der Tabelle definiert einen Testfall.
Ein Vorteil dieser Methode ist , dass eine Kombination von Eingabewerten betrachtet wird. Der
Nachteil ist, dass für komplexe Spezifikationen ein Graph schwierig zu erstellen und dadurch sehr
fehleranfällig ist.
- 14 -
Kapitel 2 : Einführung ins Testen
•
Beispiel: Eine einfache Transaktion
Die Eingabemaske der Transaktion besitzt zwei Eingabewerte. Die Spezifikation der Transaktion:
•
1. Wert = A oder B und 2. Wert = Ziffer => Update einer Datei
•
1. Wert nicht korrekt => Fehlermeldung E12
•
2.Wert kein Ziffer => Fehlermeldung E13
Diese Spezifikation kann den folgenden Graph übersetzen. Siehe Abbildung 5 UrsacheWirkungsgraph.
Abbildung 5 Ursache- Wirkungsgraph
Aus dem Graphen wird nun die Entscheidungstabelle abgeleitet. Da das Nichterfüllen der OderBindung von den Ursachen 1.Wert=A, 1.Wert= B die gleiche Wirkung aufweist können diese in der
Tabelle zusammengezogen werden. Siehe Abbildung 6 Entscheidungstabelle zum UrsacheWirkungsgraph.
Testfall 1
Testfall 2
Testfall 3
Testfall 4
0
0
1
1
2.Wert=Ziffer
0
1
0
1
Update
-
-
-
x
E12
x
x
-
-
E13
x
-
x
-
1.Wert=A
Ursachen
Wirkungen
1.Wert=B
Abbildung 6 Entscheidungstabelle zum Ursache- Wirkungsgraph
2.3.5 Zufallstest
Beim Zufallstest werden die Eingabedaten per Zufallsgenerator erzeugt und mit den so erzeugten
Werten getestet.
•
Beispiel: Fakultät von einer ganzen Zahl zwischen 0 und 10
Generierte Tests wären zum Beispiel:
•
Wert = 4 =>gültige Eingabe
- 15 -
Kapitel 2 : Einführung ins Testen
•
Wert = 7 =>gültige Eingabe
•
Wert = -4 , => ungültige Eingabe
•
...
Obwohl Zufallstests keinen sehr großen Wirkungsgrad aufweisen, sind sie doch ein sehr wichtiger
Zusatz zu der Teststrategie. Die Gründe dafür sind psychologisch bedingt. Wenn ein Programmierer
seine Arbeit testet oder die Tester im selben Team arbeiten, sind sie eher motiviert zu zeigen, dass
die Software funktioniert. Dieses Phänomen bewirkt, dass sie unterbewusst Tests definieren, die mit
großer Wahrscheinlichkeit erfolgreich ablaufen und daher eher keine Fehler aufdecken.
2.3.6 Fehlererwartung
Dieses Verfahren beruht allein und einzig auf den Erfahrungen und der Intuition des Testers. Er weiß
schon aus früheren Erfahrungen bzw. aus Kenntnissen von ähnlichen Modulen bzw. Anwendungen,
wo mit größter Wahrscheinlichkeit Fehler auftreten können. Es können zwar mit diesem
Testverfahren viele der Probleme aufgedeckt werden (je nach Erfahrungsgrad), man sollte es aber mit
anderen Verfahren kombinieren.
•
Beispiel: Fakultät von einer ganzen Zahl zwischen 0 und 10
Intuitive Tests wären zum Beispiel:
•
Wert = 0, da es oft ein Problemfall ist =>gültige Eingabe
•
Wert = 1, da es oft ein Problemfall ist =>gültige Eingabe
•
Wert = -1, da negative Zahlen auch oft problematisch sind => ungültige Eingabe
2.3.7 Zusammenfassung
Es ist erkennbar, dass die Güte des „black- box“ Testen von der Güte der Spezifikation und einer
sorgfältigen Testfallauswahl abhängt. Beim „black-box“ Testen können fehlende Funktionen
aufgedeckt werden. Auch bei guter Kombinationen der vorgestellten „black-box“ Testmethoden kann
keine Fehlerfreiheit erreicht werden.
Gründe dafür können sein: [Bal89]
•
Wenig Vertrauen in die Bestimmung von Äquivalenzklassen (bei der funktionalen
Äquivalenzbildung bzw. Grenzwertanalyse).
•
Hohe Anforderungen an die Qualifikation des Tester (siehe z.B. Ursache-Wirkungsgraph).
2.4 Tests im Software-Entwicklungsprozess
Da sowohl die „black-box“ Tests als auch die „white-box“ Tests ihre Vor- und Nachteile haben,
sollten beide Kategorien gemischt und miteinander ergänzt angewandt werden ,um ein möglichst
optimales Ergebnis zu erreichen. Außerdem sollte Testen nicht nur am Ende des SoftwareEntwicklungsprozesses eingeplant werden, sondern ein projektbegleitendes Ereignis sein. Wie das in
der Praxis aussieht, soll in den nächsten Kapiteln erklärt werden.
2.4.1 Modultest
Unter Modultest wird der Test der kleinsten Programmiereinheiten, der Module verstanden. Das
- 16 -
Kapitel 2 : Einführung ins Testen
Testen der Module wird im Allgemeinen von seinen Entwicklern durchgeführt, andere, unabhängige
Tester sind meist nicht vertreten.
Voraussetzung(en):
•
Modulspezifikation (Was- Beschreibung) => „black-box Testen“
•
Feinentwurf (Wie- Beschreibung) => „white-box Testen“
Typische Fehler, die entdeckt werden:
•
fehlende Pfade
•
Berechnungsfehler
•
Domain Fehler (Fehler, die dadurch entstehen, dass falsche Pfade durchlaufen werden.)
2.4.2 Integrationstest
Der Integrationstest prüft die fehlerfreie Zusammenarbeit von Systemkomponenten. Es wird dabei
mit wenigen Modulen angefangen. Wenn die Tests dafür funktioniert haben, werden neue Module
hinzugefügt bis das System komplettiert ist. Diese Testart wird meistens auch von den Entwicklern
der Komponenten durchgeführt. Allerdings ist hier schon eine engere Zusammenarbeit der Tester
erwünscht als beim Modultest.
Voraussetzung(en):
•
erfolgreicher Modultest von einbezogenen Komponenten
•
Schnittstellenspezifikation zwischen Komponenten (Was- Beschreibung) => „black-box Testen“
•
Feinentwuf (Wie- Beschreibung) => „white-box Testen“
Typische Fehler, die entdeckt werden:
•
interne / externe Schnittstellenfehler
2.4.3 Systemtest
Beim Systemtesten geht es darum, das Gesamtsystem einerseits auf seine funktionalen Leistungen,
andererseits auf seine Leistungsfähigkeit zu testen. Systemtests sollten von einer unabhängigen
Testgruppe (nicht von den Entwicklern) durchgeführt werden. Dieser Test soll intern in der
Entwicklerfirma für die Qualitätsprüfung und Akzeptanz der Gesamtsoftware sorgen. Die Kunden
bzw. Auftragsgeber sind typischerweise bei dieser Prüfungsart nicht dabei.
Voraussetzung(en):
•
erfolgreicher Modultests und Integrationstest
•
Spezifikation des Systems (Was- Beschreibung) => „black-box Testen“
Typische Fehler, die entdeckt werden:
•
fehlende Funktionalität
•
nicht erfüllte Qualitätsziele (Performance, ...)
Beim Systemtest sind folgende Testarten zu unterscheiden:
- 17 -
Kapitel 2 : Einführung ins Testen
2.4.3.1 Funktionstest
Die Testfälle werden vollständig aus dem Pflichtenheft abgeleitet. Es wird geprüft, ob die
geforderten Funktionen vorhanden sind und ob sie korrekt umgesetzt wurden. Dazu gehört unter
Anderem auch das Testen der Benutzeroberfläche.
2.4.3.2 Leistungstest
Leistungstests sollen die Leistungsfähigkeit des Systems zeigen. Es gibt folgende vier Unterarten:
•
Massentest
Bei Massentests wird das System mit Daten bis zur Leistungsgrenze gefüllt. Dabei wird geprüft, ob
die Anwendung eine große Menge Daten mit vordefinierten Werten richtig verarbeiten kann. Diese
Testart ist z.B. sehr wichtig für Datenbanken.
•
Zeittest
Bei Zeittests wird die Einhaltung von zeitlichen Restriktionen getestet. Die speziellen
Zeitanforderungen können im Pflichtenheft oder in den Spezifikationen beschrieben sein. Diese
Testart wird oft mit dem Massentest kombiniert und spielt bei Anwendungen mit einer
Datenbankanbindung eine große Rolle.
•
Lasttest
Der Lasttest geht noch weiter. Es wird geprüft, wie das System auf Ausfall von Software- ,
Hardwarekomponenten, Betrieb mit maximaler Benutzeranzahl oder Eintreffen ungewöhnlicher,
widersprüchlicher Daten reagiert.
•
Stresstest
Der Stresstest ist die härteste Variante des Leistungstests. Hier werden die vordefinierten Grenzen
des Systems bewußt überschritten. Das kann man z.B. durch Ressourcenentzug ( z.B. weniger
Arbeitsspeicher) erreichen. Es soll überprüft werden, wie sich das System bei Überschreitung der
Grenzen verhält, und ob es nach Rückgang der Last in den Normalzustand zurückkehrt.
2.4.3.3 Benutzbarkeitstest
Bei diesem Testart wird nachgeprüft, ob die Software die Anforderungen der Benutzerschnittstellen
erfüllt. Diese könnten beispielsweise sein, ob die Bedienbarkeit der Oberfläche stimmt, die
Fehlermeldungen aussagekräftig sind, die Hilfen gut erreichbar und leicht nutzbar sind.
Insgesamt soll damit also ein bessere Akzeptanz beim Kunden für die Software geschaffen werden.
2.4.3.4 Sicherheitstest
Die Sicherheitstests sollten auch schon während der Entwicklung ausgeführt werden. Diese Tests
sollen die Sicherheit des Systems laut Spezifikation, bzw. Pflichtenheft erfüllen. Typischerweise
gehören dazu, Sicherung und Übertragung von Passworten, schützen der Datenbank, Zugriffsrechte
auf verschiedenen Ebenen.
2.4.3.5 Interoperabilitätstest
Da heutzutage kaum noch ein System alleinstehend (standalone) ist, muss auch die Kommunikation
und Datenübertragung zu anderen Systemen getestet werden.
- 18 -
Kapitel 2 : Einführung ins Testen
2.4.3.6 Regressionstest
Regressionstest kann ein Beliebiger der vorher beschriebenen Testarten sein. Er hat die zusätzlichen
Eigenschaft, dass die Testausführung gespeichert wird und daher jederzeit erneut ausgeführt werden
kann.
•
Automatisierte Regressionstests
Automatisiertes Testen wird gebraucht, damit das Testen der Software nicht die Überhand im Projekt
gewinnt. Es macht die Software nicht sicherer, hat jedoch trotzdem einige Vorteile gegenüber
manuellem Testen.
Vorteile:
•
existierendes Programm erneut testen ist schnell, mit gar keinen oder nur wenigen Änderungen an
den Testfällen verbunden
•
mehr Tests und häufiger ausführbar, als ohne Automatisierung möglich wäre
•
Last / Stresstest leicht machbar
•
ermüdende Dateneingaben entfallen
•
verschiedene Systeme, Systemkonfigurationen sind kein Problem mehr
•
Zeitspanne für Testphase wird verkleinert
Nachteile:
•
Automatisierung macht wenig Sinn, sofern keine Testphase üblich ist oder kein Testen eingeplant
wurde
•
löst nicht alle Probleme der Software
•
man wägt sich oft in falscher Sicherheit
•
es werden im Schnitt nicht mehr Fehler gefunden als ohne Automatisierung
•
Ablauf des Testens ist zwar automatisiert, aber die Ergebnisse müssen immer noch manuell
überprüft werden
•
Entwurf der Testfälle bleibt weiterhin manuell
2.4.4 Abnahmetest
Das Ziel beim Abnahmetesten besteht darin, dass das Vertrauen in das Produkt beim Kunden oder
Auftraggeber gestärkt wird. Es soll also dem Kunden zeigen, dass das Produkt seinen Anforderungen
entspricht. Es wird dabei hauptsächlich eine Mischung aus den Testarten Leistungstest, Funktionstest
und Benutzbarkeitstest angewandt. Der Auftragsgeber ist beim Testen dabei, bzw. er selbst führt
diese Tests durch.
Voraussetzung(en):
•
erfolgreiche Modultests, Integrationstests und Systemtest
•
Spezifikation des Systems, insbesondere Benutzerschnittstellen (Was- Beschreibung) => „blackbox Testen“
•
Anforderungsspezifikation (beschreibt welche Qualitätsstandards die Software erfüllen soll) =>
- 19 -
Kapitel 2 : Einführung ins Testen
„black-box Testen“
Typische Fehler, die entdeckt werden:
•
Fehler im Zusammenhang mit den normalen Betriebsbedingungen (Betriebssystem, Betriebsort,
Betriebshardware, ...)
2.4.5 Zusammenfassung
Abbildung 7 Kategorien von Testaufgaben
Die im vorherigen Kapitel beschriebenen Testarten sind ein wichtiger Aspekt zum Organisieren des
Testens. Um dafür nochmals einen Überblick zu geben wird auf Abbildung 7 Kategorien von
Testaufgaben hingewiesen.
Es sollte nicht vergessen werden, dass Testen nicht nur aus der Auswahl der Testfälle besteht,
sondern einer viel größeren Organisation bedarf. Diese Organisation sollte idealerweise aus 50-60%
Testplanphase bestehen. Der Testplan legt fest, was wann, wieviel und wie genau getestet werden
soll. Daher spielt er eine zentrale Rolle im Testprozess. Wie die genaue Planung des Testprozesses
erfolgen sollte, wird im [Wal90] beschrieben.
- 20 -
Kapitel 3 : Einführung Software Komponenten
3 Einführung Software Komponenten
Um ein besseres Verständnis für Plugins zu bekommen, müssen wir zuerst klären, was eine
Komponente ist. Zu diesem Zweck werden wir in diesem Kapitel versuchen eine Definition von
Komponenten zu geben. Danach werden wir die Vorteile bzw. Nachteile, die bei der Verwendung
von Komponenten auftreten kurz beleuchten. Nachdem wir dann die Begriffe geklärt haben, werden
wir im nächsten Kapitel dann genauer auf die spezielle Komponente, das Plugin, eingehen.
3.1 Definition
Eine sehr kurze und vereinfachte Definition gibt Sametinger in [Sam97]:
„Components are artifacts that we clearly identify in our software system. They have an
interface, encapsulated internal details and are documented separately.“
Das grundlegende Ziel von Komponenten ist es, sie zu nehmen und in ein Software System zu
integrieren ohne sie neu implementieren zu müssen. Dies unterscheidet Komponenten von z.B.
Algorithmen, beschrieben in einem Buch. Wir können diese Algorithmen nicht einfach in unser
Softwaresystem integrieren. Wir müssen sie erst noch implementieren. Gleiches gilt auch für Design
Patterns. Diese beschreiben, wie man bestimmte Probleme lösen kann. Sie sind also in dieser Art mit
Algorithmen vergleichbar, aber sie müssen erst noch implementiert werden. Einen Schritt weiter
gehen dann schon Anwendungs-Frameworks. Das Framework ist nicht eine einzige Komponente,
sondern besteht aus vielen einzelnen Komponenten, die von uns bei der Implementierung verwendet
werden können. Als Ganzes folgt das Anwendungs-Framework einem oder mehreren Designpatterns.
Es ist nicht direkt eine Komponente, sondern eher ein Vorgehensmodell mit konkreter
Teilimplementation. Durch Benutzen der vom Framework zu Verfügung gestellten Klassen, werden
die Designpatterns in die neue Anwendung übernommen.
Damit wir Komponenten eindeutiger identifizieren können, gibt Sametinger noch eine präzisere
Definition an.
„Reusable software components are self-contained, clearly identifiable artefacts that
describe and/or perform specific functions and have a clear interface, appropriate
documentation and a defined reuse status.“
Im Detail soll dies bedeuten.
•
Unabhängigkeit von Anderen (self-containedness)
Die Komponente sollte bei ihrer Verwendung unabhängig von anderen Komponenten sein. Ist sie
abhängig von anderen Komponenten, so muss die Sammlung der ganzen Komponenten als eine
Komponente angesehen werden, wobei die eine Komponente als Schnittstelle nach Außen dient.
•
Identifizierung (identification)
Die Komponente muss eindeutig identifizierbar sein. Sie sollte nicht verteilt über mehrere Stellen
und nicht vermischt mit anderen Teilen von Software und Dokumentation sein.
•
Funktionalität (functionality)
Sie beschreiben und führen eine bestimmte Funktion aus. Diese Funktionalität ist eindeutig.
•
Schnittstelle (interface)
Die Komponenten besitzen eine klare Schnittstelle nach Außen. Diese Schnittstelle versteckt alle
- 21 -
Kapitel 3 : Einführung Software Komponenten
internen Details, die für die Wiederverwendung nicht wichtig sind.
•
Dokumentation (documentation)
Eine Komponente muss gut dokumentiert sein. Die beste Komponente nutzt nichts, wenn sie nicht
ausreichend dokumentiert wurde. Aus der Dokumentation muss ersichtlich sein, für welche
Probleme man diese Komponente verwenden kann, wie sie angepasst und in die neue Umgebung
integriert wird.
•
Wiederverwendungs Status (reuse status)
Unter dem Wiederverwendungsstatus werden Informationen verstanden, wie z.B. wem gehört die
Komponente und wer pflegt sie; wen kann man bei Problemen ansprechen und wie ist die Qualität
der Komponente. Dies ist besonders wichtig, wenn Komponenten z.B. über Firmen- oder
Abteilungsgrenzen hinweg genutzt werden.
Nach dieser allgemeinen Definition können wir eine große Anzahl an Komponenten haben, wie z.B.
Funktionen, Klassen, Anwendungen und vieles mehr und auch als Komponente identifizieren.
3.2 Verwendung
Da wir nun ein grobes Bild von Komponenten haben, wollen wir klären, warum wir solche
verwenden wollen und welche Vor- bzw. Nachteile uns dadurch entstehen.
Durch die Verwendung von Komponenten können nicht alle Probleme in der Entwicklung von
Software gelöst werden, es entstehen aber positive Effekte, was die Kosten, Produktivität,
Funktionalität, Qualität, Zuverlässigkeit, Portabilität, Effizienz und Wartbarkeit der Software angeht.
Ein Nachteil, gerade bei kleineren Projekten, ist der größere Overhead, der durch die Verwendung
entsteht.
3.2.1 Vorteile
Eine ausführliche Übersicht der Vorteile, die bei der Verwendung von Komponenten enstehen, zählt
Sametinger in [Sam97] auf. Wir werden hier versuchen auf die unserer Meinung nach Wichtigsten
genauer einzugehen. Sametinger teilt dabei die Vorteile in drei Kategorien ein:
Qualitätsverbesserungen, Aufwandsverringerung und andere Vorteile.
3.2.1.1 Qualitätsverbesserung
•
Qualität
Wird eine Komponente häufiger verwendet, werden Fehler eher gefunden und können behoben
werden. Die Komponente kann dadurch qualitativ besser werden. Dies setzt jedoch die
Verwaltung und Wartung der Komponente voraus und wird nicht durch einfaches Benutzen der
Komponente erreicht.
•
Produktivität
Es gibt eine Steigerung der Produktivität, da weniger Funktionalität entwickelt und getestet
werden muss. Dies ist allerdings nicht der Fall, wenn es um die Erstentwicklung von neuen
Komponenten geht, da hier erst mehr Zeit investiert werden muss. Dort macht sich die Steigerung
der Produktivität erst zu einem späteren Zeitraum bemerkbar.
•
Zuverlässigkeit
Werden gut getestete Komponenten bei der Entwicklung von Software verwendet, so wird die
- 22 -
Kapitel 3 : Einführung Software Komponenten
Zuverlässigkeit der Software gesteigert.
3.2.1.2 Auffwandsverringerung
•
Reduzierung von redundanter Arbeit und Entwicklungszeit
Durch die Verwendung von Komponenten kann die redundante Entwicklung von Teilen der
Software verhindert werden. Dazu zählen z.B. Oberflächenschnittstellen, Kommunikation oder
grundlegende Algorithmen. Wenn solche Teile als Komponenten vorliegen, reduziert sich die
Entwicklung, die verwendete Zeit und die Kosten.
•
Wartungskosten
Werden bewährte Komponenten verwendet, können weniger Fehler in der Software erwartet
werden. Daraus resultiert, dass ein geringerer Teil der Software auch gewartet werden muss.
Allerdings sollten die Komponenten von einer Gruppe gewartet werden und nicht in jedem
Softwaresystem getrennt.
•
Einarbeitungszeit
Die Einarbeitungszeit von Entwicklern, die neu in ein Projekt kommen, verringert sich, da sie nur
noch die verwendeten Schnittstellen der Komponenten verstehen müssen. Desweiteren lernen sie
mit der Zeit die Komponenten für ihre Entwicklungszwecke kennen und können so schneller ein
neues Softwaresystem auf Basis dieser Komponenten erstellen.
3.2.1.3 Andere Vorteile
•
Schnelle Prototypentwicklung
Mit Komponenten können schneller Prototypen erstellt werden. Dies ermöglicht es schon früh in
der Entwicklung, Rückmeldung vom Kunden zu bekommen und versteckte Anforderungen zu
entdecken.
•
Erfahrungsaustausch und -weitergabe
Entwickler, die gut konstruierte Komponenten verwenden, können vom verwendeten Design
lernen und dies beim Entwurf ihres Softwaresystems berücksichtigen. Dazu müssen sie nicht
unbedingt die interne Struktur der Komponente kennenlernen; oft reicht es schon aus, die
Schnittstelle zu verstehen.
3.2.2 Nachteile
Den bisher aufgezählten Vorteilen stehen natürlich auch Nachteile gegenüber. Auf einige dieser
Nachteile soll in diesem Abschnitt etwas genauer eingegangen werden. Auch hier sei angemerkt, das
es in [Sam97] ausführlichere Aufzählung und Erläuterung gibt. Sametinger teilt die Nachteile, die bei
der Verwendung von Komponenten auftreten, in drei Kategorien ein.
3.2.2.1 Leitende und organisatorische
Es reicht nicht einfach aus, Komponenten bei der Softwareentwicklung zu benutzen, es muss auch
vom Management unterstützt werden. Ohne die Unterstützung durch höhere Positionen wird sich die
Verwendung von Komponenten nicht durchsetzen. Gleiches gilt auch für das Projektmanagement;
wenn hier nicht gleich von Beginn an an die Wiederverwendbarkeit gedacht wird, wird sie nicht
stattfinden. Es müssten z.B. Strukturen geschaffen werden, die die erstellten Komponenten verwalten
und warten.
- 23 -
Kapitel 3 : Einführung Software Komponenten
3.2.2.2 Wirtschaftliche
Um wiederverwendbare Komponenten zu erstellen, müssen gerade am Anfang höhere Kosten in
Kauf genommen werden. Dazu zählen Kosten, wie z.B. eine Komponente wiederverwendbar zu
machen, sie wiederzuverwenden und einen Prozess zu definieren bzw. zu implementieren, der die
Wiederverwendung umsetzt. Diese Kosten amortisieren sich meist erst Jahre später und lohnen sich
nicht für Komponenten, die nur einmal Verwendung finden.
3.2.2.3 Konzeptuelle und technische
Es ist ein großes Problem, Komponenten für die Wiederverwendung zu finden, wenn nicht z.B. eine
Verwaltungsinstanz existiert, die es ermöglicht, gezielt zu suchen. Auch wenn man Zugriff auf viel
Software hat, bedeutet dies leider nicht, dass diese auch wiederverwendbar ist. Selten ist Software so
geschrieben, das Andere diese wiederverwenden können. Häufig ist es dann sogar teurer diese
Software an eigene Bedürfnisse anzupassen, als sie neu zu entwickeln. Ein großes Problem ist auch
die Qualität der Komponenten. Stimmt diese nicht, wird auch das daraus entstandene System nicht
qualitativ hochwertig sein. Es ist deswegen wichtig, die Qualität und Funktion einer Komponente
genau zu bestimmen, um dann zu entscheiden, ob diese wirklich Verwendung finden soll.
3.3 Zusammenfassung
Die Verwendung von Komponenten ermöglicht es, neue Software auf Basis Bestehender zu
entwickeln. Allerdings ist dies nur durchführbar, wenn es schon von Anfang an in der Planung
berücksichtigt wird. Wie gezeigt wurde, ist das auch mit höheren Initialkosten verbunden, welche
sich erst sehr viel später bezahlt machen. Wird jedoch der Prozess der Wiederverwendbarkeit richtig
umgesetzt, so wird dies vor allem die Qualität und Robustheit der Software steigern. Es wurde auch
ersichtlich, das nur die Wiederverwendung von Software nicht automatisch ausreicht um gute neue
Systeme zu erstellen. Es müssen auch die entsprechenden organisatorischen Strukturen für
komponentenbasiertes Entwickeln geschaffen werden.
- 24 -
Kapitel 4 : Einführung Plugins
4 Einführung Plugins
Im vorherigen Kapitel haben wir uns mit der Komponente als Allgemeines beschäftigt und Begriffe
und Definitionen geklärt. Wir haben die Vor- bzw. Nachteile beleuchtet, die bei der Verwendung
entstehen können.
In diesem Kapitel wollen wir nun auf eine spezielle Art von Komponente eingehen, das Plugin.
Dabei besteht die Aufgabe eines Plugins darin, die Funktionalität einer bestehenden Software bzw.
Komponente zu erweitern oder zu verändern. Wir werden als Erstes versuchen, eine genauere
Definition des Begriffes Plugin zu geben. Im Anschluß daran wollen wir das verwendete
Pluginkonzept von Eclipse näher erläutern, welches dann auch im erstellten Prototyp Verwendung
findet.
4.1 Definition
In der heutigen Zeit gibt es viele Anwendungen die angeben „pluginfähig“ zu sein. Dabei gibt es
keine genauere Definition des Begriffes. Die Hersteller der Software gehen davon aus, dass der
bildliche Vergleich mit dem „Hereinstecken von Software (to plug in) ausreicht und eine genaue
Definition des Begriffes überflüssig macht.
Eine Definition von Plugin bietet [Mmv03]:
„Plugins sind Ergänzungen zu einer Applikation, die von dieser vorgesehen sind, die sie
aber nicht selbst mitbringen kann oder will. Ein Plugin deckt dabei eine fachliche
Funktion so vollständig ab, dass keine andere Komponente des Systems irgendetwas
spezifisches darüber wissen müsste. Für die dazu nötigen Schnittstellen ist die
Applikation verantwortlich.“
Plugins sind also Komponenten, die ein schon bestehendes Softwaresystem erweitern und dazu die
von der Anwendung zur Verfügung gestellten Schnittstellen verwenden. Diese Schnittstellen dienen
als Vertrag zwischen Anwendung und Plugin. Diese Definition erklärt uns aber noch nicht wann eine
Komponente ein Plugin ist, da jede Komponente ein System erweitert. In [Sch03] wird eine
zusätzliche Defninition gegeben.
„Plugins sind Komponenten die das Verhalten einer oder mehrerer anderer
Komponenten im System verändern. Dies geschieht über die von diesem zur Verfügung
gestellten Schnittstellen.“
Ein Plugin erweitert also nicht nur das Gesamtsystem an sich, sondern kann auch noch über die
Schnittstellen das Verhalten oder die Funktion von anderen Plugins erweitern und verändern. Damit
werden Plugins immer von der Komponente abhängig sein, die sie erweitern. Um eine
Implementierung von Plugins zu ermöglichen, müssen die Schnittstellen der entsprechenden
Komponenten freigelegt und beschrieben sein.
Ein weiteres Kriterium besteht darin, dass Komponenten eine grundlegende Funktion anbieten und
nicht in anderen Komponenten bekannt sind. Die Kommunikation der Komponenten untereinander
wird durch die Plattform geregelt, auf der sie laufen. Ein Plugin dagegen wird von einem
Komponentensystem verwaltet. Dieses regelt das Registrieren, Laden und Entfernen von
Komponenten. Da das Plugin in den Komponenten bekannt ist, die es erweitert, können diese auch
direkt mit diesem Nachrichten austauschen, ohne den Umweg über die Kommunikation der Plattform
- 25 -
Kapitel 4 : Einführung Plugins
zu nehmen.
Je nach System kann es sich dabei um eine dynamisches oder statisches Komponentensystem
handeln. Der grundlegende Unterschied liegt im Verwalten der Komponenten. Bei einem
dynamischen System können Plugins auch während der Laufzeit hinzugefügt bzw. entfernt werden.
Dies schließt jedoch gegenseitige Abhängigkeiten von Plugins aus. Bei einem statischen System
werden die Plugins beim Start registriert und je nach Mechanismus schon initialisiert und geladen.
Ein Plugin ist also eine spezialisierte Form einer Komponente, die ein System um eine sehr
spezialisierte Funktion erweitert. Dabei erweitert es nicht nur das System an sich, sondern auch die
darin schon befindlichen anderen Komponenten.
Im nächsten Abschnitt werden wir uns näher mit dem statischen Pluginsystem Eclipse beschäftigen.
Dabei werden wir uns genauer die zugrundeliegende Architektur anschauen sowie die Mechanismen
die verwendet werden, um Plugins zu verwalten und zu laden.
4.2 Eclipse
Eclipse ist eine Plattform zur Entwicklung von Integrated Development Enviroments (IDE). Sie wird
seit November 2001 über [Ecl04] vertrieben. Entwickelt und unterstützt wird sie von einem losen
Konsortium von großen und kleinen Firmen wie IBM, Borland, Sybase, RedHat, SuSE und vielen
mehr. Sie wird unter einer Common Public Licens (CPL) vertrieben und kann frei benutzt werden.
Zur Zeit ist sie in der Version 2.1.3 erhältlich. Version 3.0 ist gegenwärtig nur als Betaversion
vorhanden.
Bei Eclipse handelt es sich um ein statisches Plugin-Verwaltungssystem. Es bietet an sich nur eine
kleine Grundfunktionalität und Mechanismen zum Verwalten und Laden von Plugins an. In den
folgenden Abschnitten wollen wir näher auf die Architektur von Eclipse eingehen und den
Pluginmechanismus ausführlicher erläutern.
4.2.1 Architektur
Die Plattform an sich besteht nur aus einem sehr kleinen Kern, der sogenannten „Plattform
Runtime“. Sie stellt Mechanismen zum Laden und Verwalten der Plugins zur Verfügung. Auch legt
sie Regeln fest, wie Plugins miteinander kommunizieren und sich gegenseitig erweitern können.
Andere Funktionalität, wie z.B. eine IDE zum Bearbeiten von Java, müssen erst durch Andere
implementiert werden. Wir betrachten nun im Folgenden die einzelnen Plattformkomponenten etwas
genauer. Zur Übersicht sei auf Abbildung 8 verwiesen, die eine grobe bildliche Verdeutlichung der
Architektur von Eclipse darstellt. Eine sehr ausführliche Beschreibung der einzelnen Bestandteile ist
auch in [Ecl03a] zu finden.
- 26 -
Kapitel 4 : Einführung Plugins
Eclipse Plattform
New Tool
Workbench
Help
JFace
SWT
New Tool
Team
Workspace
New Tool
Platform Runtime
Abbildung: 8 Eclipse Plattform Architekur
4.2.1.1 Plattform Runtime
Dies ist der Kern von Eclipse. Er stellt die Funktionalität zum Verwalten der Plugins zur Verfügung.
Plugins können über diesen Kern auf eine Fülle von Informationen zugreifen, die sie für ihren
Ausführungskontext benötigen. Um ein schnelles Laden der Umgebung zu ermöglichen, werden zum
Beginn nicht alle Plugins automatisch gestartet. Allerdings werden ihre Metabeschreibungen beim
Hochfahren eingelesen, um ihre Schnittstellen auch Anderen bekannt geben zu können. Erst wenn
die Funktionalität eines Plugins direkt gefordert wird, wird dessen Code auch ausgeführt. Dies
vermeidet einen Overhead beim Laden und Ausführen der Umgebung.
Alle weiteren Teile der Plattform sind als Plugins konzipiert und bieten über wohldefinierte
Schnittstellen die Möglichkeit für Erweiterungen durch andere Plugins an. Sie gehören aber noch
direkt zur Plattform, da sie die Grundfunktionalität der Umgebung realisieren.
4.2.1.2 Workspace
Der Workspace ist die abstrakte Form der Datenablage im Dateisystem des darunterliegenden
Operationsystems. Dabei besteht der Workspace aus einem oder mehreren Projekten, die jeweils auf
ein spezifisches Verzeichnis im Dateisystem verweisen. Die Verzeichnisse können überall im
Dateisystem sitzen, wobei standardmäßig ein sogenanntes Workspace Root-Verzeichnis existiert.
Abbildung 9 soll dies verdeutlichen.
- 27 -
Kapitel 4 : Einführung Plugins
IWorkspace
IProject (Porjekt1)
IFolder
IFile
IFile
IProject (Projekt2)
c:/workspace/projekt1
c:/workspace/projekt1/folder
c:/workspace/projekt1/folder/file2.txt
c:/workspace/projekt1/file1.txt
c:/myProject
IFile
c:/myProject/file1.txt
IFile
c:/myProject/file2.txt
Abbildung: 9 Workspace Resourcemapping
Die in einem Projekt enthaltenen Dateien sind über die definierten Schnittstellen des Workspaces für
Plugins zugänglich. Plugins greifen dabei über sogenannte Resources auf die darunterliegenden
Objekte zu und können deren Verhalten erweitern.
Über den „Project Nature Mechanismus“ können Plugins Projekte personalisieren. Man könnte auch
sagen, das Projekt wird einer Kategorie zugeordnet, die einen bestimmten Aufbau erwartet oder ein
bestimmtes Verhalten voraussetzt. Durch das Anhängen einer „Nature“ an einem Projekt kann
gekennzeichnet werden, das es sich um ein HTML Projekt handelt, das statische Seiten einer
Webpräsenz enthält. Ein Projekt kann dabei mehrere Natures besitzen. Dies ermöglicht es, Projekte
mit mehreren Plugins bzw. Tools zu benutzen, ohne dass diese voneinander Bescheid wissen müssen.
4.2.1.3 Workbench
Die Workbench stellt die Oberfläche von Eclipse dar. Sie bietet Schnittstellen zum einfachen
Erweitern der Oberfläche an. Die Schnittstellen zum Darstellen der Oberfläche sind dabei in zwei
Teile gegliedert, welche das Erstellen von Oberflächenelementen ermöglichen. Desweiteren stellt sie
die Grundoberfläche von Eclipse dar. In diese werden die Oberflächenerweiterungen der Plugin
hineingesetzt. Die wichtigsten Erweiterungspunkte stellen dabei die Viewer und Editoren dar.
Editoren ermöglichen das Öffnen, Ändern und Speichern von Daten. Viewer zeigen Informationen
über die Objekte an, die momentan vom Benutzer bearbeitet werden. Sie dienen also z.B. als
Unterstützung von Editoren, um eine weitere Sicht auf die Daten zu haben. Eine etwas kurze
Übersicht der wichtigsten möglichen Erweiterungspunkte sehen sie in Tabelle 1 oder ausführlicher in
[Sha03].
- 28 -
Kapitel 4 : Einführung Plugins
Zweck
Erweiterungspunkt
Workbench Menü und Toolbar
org.eclipse.ui.actionSet
Editor Menü und Toolbar
org.eclipse.ui.editorActions
Wizards für File -> New Menü
org.eclipse.ui.newWizards
Eigenschaftsseiten für Objekte
org.eclipse.ui.propertyPages
Neue Editoren für bestimmte Objekte
org.eclipse.ui.editors
Hilfe unter Menü Help -> Help Contents
org.eclipse.ui.help
Neue Views
org.eclipse.ui.views
Tabelle: 1 Erweiterungspunkte von Eclipse
SWT (Standard Widget Toolkit)
Das SWT bietet eine vom Betriebssystem unabhängige Schnittstelle an. Diese ermöglicht es auf die
nativen Grafikelemente des darunterliegenden Oberflächensystems zu zugreifen. Für Elemente, die
eine Implementierung im Grafiksystem des Betriebssystems besitzen, wird diese Implementierung
genutzt. Erst wenn es keine Implementierung gibt, wird diese anderweitig emuliert. Als Beispiel gibt
es z.B. die Werkzeugleiste. Diese benutzt unter Windows die native Implementation, unter Motif
wird eine Emulation des Toolbars realisiert. Dadurch kann eine Reihe von Windowselementen zur
Verfügung gestellt werden und nicht wie beim AWT nur der kleinste gemeinsame Nenner. Auch
wird dadurch auf den entsprechenden Plattformen ein Plattformtypisches Aussehen erreicht.
JFace
JFace bietet eine plattformunabhängige Schnittstelle für allgemeine Aufgaben, die die Oberflächen
betreffen. Die zwei wichtigsten sind Actions und Viewer.
Actions: Diese enthalten Kommandos zur Ausführung, ohne genau zu spezifizieren, wo sie in der
Oberfläche aufgerufen werden können. Dabei kennt jede Aktion ihre Oberflächeneigenschaften.
Dazu gehören z.B. Label, Icon und ToolTip. Dadurch wird es möglich, die gleiche Aktion an
mehreren Stellen einfach zu benutzen.
Viewers: Diese stellen eine höhere Abstraktionsebene zu Standard-Oberflächenelementen, wie z.B.
Listen und Bäumen dar. Sie ermöglichen das einfache Benutzen dieser Elemente, ohne einen großen
Programmieraufwand zu betreiben. Viewers werden dabei durch einen sogenannten Content
Provider und Label Provider konfiguriert. Der Content Provider weiß dabei, wie die Modellelemente
in Beziehung zu den entsprechenden Viewerelmenten stehen und reagiert auf Änderungen im
Modell. Der Label Provider weiß, wie die Elemente im Viewer grafisch dargestellt werden müssen.
Zusätzlich können auch noch Filter und Sortierer angegeben werden. Werden Elemente im Viewer
ausgewählt, so werden die interessierten Klienten entsprechend benachrichtigt. Die Abhängigkeiten
sind in Abbildung 10 nochmals verdeutlicht.
- 29 -
Kapitel 4 : Einführung Plugins
Sorter
Content Provider
Filter
Viewer
Label Provider
Model
Abbildung: 10 Model-View-Controller
4.2.1.4 Team
Eclipse bietet eine einheitliche Schnittstelle, um neue Team Repository Provider in die IDE zu
integrieren. Dabei werden sowohl pessimistische wie auch optimistische Modelle von Repositories
unterstützt. Damit sich Anwender nicht in jede Team Repository Software neu einarbeiten müssen,
gibt es Platzhalter für bestimmte Aktionen, Ansichten, usw, die vom repository Provider nur noch
implementiert werden müssen. Dies ermöglicht ein ungefähr gleiches Aussehen und eine leichtere
Verwendung von verschiedener Repository Software für Anwender.
In der Eclipse Standardversion gibt es schon eine standardmäßige Unterstützung für CVS. Dabei
kann auf ein CVS sowohl per psserver oder ssh Protokoll zugegriffen werden.
4.2.1.5 Help
Das in Eclipse integrierte Hilfekonzept ermöglicht es, dem Anwender zu jedem Plugin eine
strukturierte Hilfe anzubieten. Dabei wird die Hilfe in zwei Bereiche geteilt. Zum einen eine XMLStruktur, die eine Navigation in der Hilfe ermöglicht, zum anderen die Hilfedateien selbst im HTML
Format. Dieses Konzept hat den Vorteil, dass schon bestehende Hilfen leicht in Eclipse integriert
werden können und nicht neu geschrieben werden müssen. Die Navigation in der Hilfe ist durch die
Baumansicht auch für den Anwender leicht verständlich und verwendbar.
Um auch in der Oberfläche schnell kontextabhängig Hilfe anbieten zu können, kann für jedes
Oberflächenelement eine Kontexthilfe angeboten werden, die beim Drücken von F1 erscheint. Diese
wird auch in einer XML Datei definiert und gibt kurze Tips und verweist auf entsprechende Kapitel
oder Seiten in der Hilfe.
- 30 -
Kapitel 4 : Einführung Plugins
Durch dieses Konzept kann leicht eine durchgängige Hilfe angeboten werden. Da jedes Plugin seine
Hilfe in eine bestehende Hilfe integrieren kann, ist sie leicht wartbar und erweiterbar.
4.2.2 Plugin-Model
In den vorherigen Abschnitten haben wir geklärt, was ein Plugin ist und welche grobe Architektur
Eclipse besitzt. In diesem Abschnitt werden wir uns etwas näher das Plugin Konzept und die
technische Umsetzung in Eclipse anschauen. Dabei werden wir auf die Struktur des Plugins eingehen
und einige einfache Beispiele geben. Für eine ausführlichere Information zu diesem Thema sei auf
[Bol03] und [Ecl03a] verwiesen.
Da es sich bei Eclipse um ein statisches Pluginsystem handelt, stehen nur Plugins zur Verfügung, die
vor dem Start in einem dafür vorgesehen Verzeichnis abgelegt wurden. Es gibt zwar Bestrebungen
auch das dynamische Laden von Plugins zu ermöglichen, diese sind aber noch nicht fertig. Genaueres
ist unter [Equi04] nachzulesen.
Ein Plugin ist eine Einheit, die eine bestimmte Funktionalität der Umgebung hinzufügt. Es kann
dabei gänzlich neue Funktionalität hinzufügen oder bereits Vorhandene erweitern. Es wird im
Pluginverzeichnis unter einem eindeutigen Namen, der auch als Referenzierung dient, installiert.
Jedes Plugin besitzt dabei einen Erben der Pluginklasse von Eclipse
(org.eclipse.core.runtime.Plugin). Dabei müssen alle Plugins von dieser Klasse abgeleitet werden.
Diese Pluginklasse ist für die Konfiguration und Steuerung des Plugins verantwortlich. Zusätzlich
zur Pluginklasse gibt es die Datei plugin.xml, welche Metainformationen enthält, die Eclipse
zum Starten des Plugins benötigt. Der minimale Aufbau dieser Datei ist in Listing 1 zu erkennen.
<?xml version="1.0" encoding="UTF-8"?>
<plugin
name="JUnit Testing Framework"
id="org.junit"
version="3.7"
provider-name="Eclipse.org">
<runtime>
<library name="junit.jar">
<export name="*"/>
</library>
</runtime>
</plugin>
Listing: 1 Minimale plugin.xml
Durch diese Manifestdatei ist es Eclipse möglich das Plugin zu laden und seine Informationen in der
Pluginregistry verfügbar zu machen. Wir werden nun nicht näher auf die Teile dieser Datei eingehen,
für Interessierte sei auf [Bol03] verwiesen. Mit Hilfe dieser Informationen ist es nun Eclipse möglich,
bei Bedarf, eine Instanz des Plugins zu erzeugen. Wichtig dabei ist noch, dass nur Eclipse Instanzen
von Plugins erzeugen darf.
Bisher unterscheiden sich die Plugins von Eclipse nicht wesentlich von der Definition von
Komponenten. Eclipse bietet jedoch einen Mechanismus, der es Komponenten erlaubt, sich
gegenseitig zu erweitern. Diese Eigenschaft macht die Komponenten von Eclipse zu Plugins. In
- 31 -
Kapitel 4 : Einführung Plugins
diesem Modell kann ein Plugin in zwei verschiedenen Verhältnissen zu einem Anderen stehen.
•
Abhängigkeit: Es gibt dabei die Rollen des abhängigen Plugins und des erforderlichen Plugins.
Dabei unterstützt das erforderliche Plugin die Funktionen des abhängigen Plugins
•
Erweiterung: Dort gibt es die Rollen des Host-Plugin und des Erweiterungs-Plugins. Dabei wird
die Funktionalität des Host-Plugins durch das Erweiterungs-Plugins erweitert.
Diese zwei Beziehungstypen werden wir nun etwas genauer betrachten.
4.2.2.1 Abhängigkeiten
Ist ein Plugin von einem anderen Plugin abhängig, so wird dies in der Manifestdatei festgehalten.
Diese Abhängigkeit gilt dann sowohl für Kompilierzeiten, als auch für die Ausführungszeit. Eclipse
stellt dabei sicher und überprüft, ob alle erforderlichen Plugins vorhanden sind, die für die
Ausführung benötigt werden. Während der Kompilierung wird der Klassenpfad von Eclipse so
erweitert, das alle benötigten Bibliotheken zur Verfügung stehen und das Plugin kompiliert werden
kann. Ein Beispiel für eine Abhängigkeit sehen sie in Listing 2.
<?xml version="1.0" encoding="UTF-8"?>
<plugin
id="com.webtest.ui"
name="WebTest UI"
version="1.0.0">
<runtime>
<library name="webtestui.jar"/>
</runtime>
<requires>
<import plugin="org.eclipse.ui"/>
</requires>
</plugin>
Listing: 2 Plugin Abhängigkeit
Abhängigkeiten werden durch das <requires>-Element angegeben. Dadurch wird kenntlich gemacht,
dass das Plugin in Abhängigkeit zum org.eclipse.ui basis Plugin steht. Während der Lauf- und
Kompilierungzeit wird dann von Eclipse sichergestellt, dass die Dateien bzw. Bibliotheken des
Plugins vorhanden sind.
4.2.2.2 Erweiterungen
Durch den Erweiterungsmechanismus in Eclipse ist es möglich vorhandene Plugins mit zusätzlicher
Funktionalität anzureichern. Das zu erweiternde Plugin beschreibt dabei seine Erweiterungspunkte in
einem XML-Schema. In diesem wird beschrieben, welche Informationen für die Erweiterung
benötigt werden. Ein Verweis auf dieses Schema wird dann in der plugin.xml eingetragen. Im
Listing 3 sehen wir, wie das org.eclipse.ui Plugin einen Erweiterungspunkt für Menüeinträge
definiert.
Das Plugin, welches nun neue Menüeinträge in die Menüleiste von Eclipse eintragen möchte, muss
diesen Erweiterungspunkt benutzen. Dazu verweist es in seiner plugin.xml auf diesen
Erweiterungspunkt und gibt die im Schema benötigten und optional definierten Informationen an.
- 32 -
Kapitel 4 : Einführung Plugins
<?xml version="1.0" encoding="UTF-8"?>
<plugin
id="org.eclipse.ui"
name="Eclipse UI"
version="2.1.0"
provider-name="Eclipse.org"
class="org.eclipse.ui.internal.UIPlugin">
<extension-point id="actionSets" name="Action Sets"
schema="schema/actionSets.exsd"/>
<!-- Other specifications omitted. -->
</plugin>
Listing: 3 Einbindung Erweiterungsschema
Bei den meisten Erweiterungspunkten muss auch noch zusätzlich eine Klasse angegeben werden,
welche die Funktionalität der Erweiterung kapselt. Dabei ist häufig eine vorgegebene Schnittstelle zu
<plugin
id="org.eclipse.help.ui"
name="Help System UI"
version="2.1.0"
provider-name="Eclipse.org"
class="org.eclipse.help.ui.internal.WorkbenchHelpPlugin">
<!-- ... -->
<!-- Action Sets -->
<extension
point="org.eclipse.ui.actionSets">
<actionSet
label="Help"
visible="true"
id="org.eclipse.help.internal.ui.HelpActionSet">
<action
label="&Help Contents"
icon="icons/view.gif"
helpContextId="org.eclipse.help.ui.helpContentsMenu"
tooltip="Open Help Contents"
class="org.eclipse.help.ui.internal.HelpContentsAction"
menubarPath="help/helpEnd"
id="org.eclipse.help.internal.ui.HelpAction">
</action>
<!-- ... other actionSet elements -->
</actionSet>
</extension>
<!-- ... -->
</plugin>
Listing: 4 Erweiterung verwenden
- 33 -
Kapitel 4 : Einführung Plugins
verwenden oder von einer abstrakten Klasse zu erben. In Listing 4 sehen wir, wie das Plugin
org.eclipse.help.ui einen Erweiterungspunkt verwendet. Es verweist dabei auf den
Erweiterungspunkt des org.eclipse.ui Plugins und gibt die im Schema definierten
Informationen an. Diese Erweiterung sieht vor, dass ein neuer Menüeintrag im Menü Help
angeboten wird. Die auszuführende Funktion wird dabei in der Klasse HelpContentActions
definiert. Diese implementiert die vom Plugin geforderte Schnittstelle für diese Erweiterung.
Das Schema und die Schnittstelle bzw. Klasse dienen als Vertrag zwischen dem erweiternden Plugin
und dem Plugin, das erweitert wird. Sie stellen sicher, dass die geforderten Informationen vorhanden
sind und die festgelegten Schnittstellen bedient werden.
4.2.2.3 Spätes Laden
In diesem Abschnitt wollen wir kurz auf einen wichtigen Aspekt beim Laden von Plugins eingehen.
Es handelt sich dabei um das verzögerte Laden von Plugins. Wird die Funktionalität eines Plugins
benötigt, so wird nur der momentan erforderliche Code geladen. An die Stellen, wo dieses Plugin
von anderen Plugins erweitert wird, werden erst einmal sogenannte Proxy- oder Platzhalter Objekte
gesetzt. Diese besitzen keine Funktionalität und sind somit klein in ihrem Speicher- und
Rechenbedarf. Erst wenn die Funktionalität vom Anwender gefordert wird, wird an die Stelle des
Proxy-Objektes der richtige Code bzw. das Objekt gesetzt, das die Funktion ausführt. Eine genauere
Erklärung des Proxy-Musters ist in [Gam95] zu finden. Mit Hilfe dieses Mechanismus soll eine
Überlastung des Systems vermieden und schnellere Ladezeiten der Plugins erreicht werden.
Ein gutes Beispiel für die Verwendung von Proxy-Objekten sind z.B. die Menüeinträge der
Menüleiste. Diese Menüs werden zuerst nur mit Hilfe von Proxy-Objekten erstellt. Erst wenn der
Anwender konkret einen Menüpunkt auswählt, wird die dafür angegebene konkrete Klasse geladen
und ausgeführt. Das Proxy-Objekt an sich enthält nur Beschriftungstext, Icon, etc., also alle Daten die
für eine Darstellung im Menü benötigt werden. Diese Menge an Daten kann schnell geladen und
auch leicht im Speicher gehalten werden.
4.3 Vorteile
Durch Eclipse ist es leicht möglich, eigene Entwicklungsumgebungen zu erstellen bzw. durch den
bereitgestellten Pluginmechanismus vorhandene zu erweitern und damit an die eigenen Bedürfnisse
anzupassen. Mit dem in Eclipse verwendete Designkonzept für die Oberfläche wird dabei ein
einheitliches Look&Feel erreicht, das es dem Anwender erleichtert sich in den neuen Werkzeugen
zurechtzufinden. Die Interaktion bzw. Kooperation der verschiedenen Werkzeuge wird durch das
Pluginsystem vereinfacht und erleichtert. Diese Zusammenarbeit mit getrennten Anwendungen zu
realisieren, wäre nur sehr umständlich bis gar nicht möglich.
4.4 Nachteile
Die Nachteile lassen sich dabei in folgenden Punkten beschreiben.
•
Keine Unterstützung von dynamischen Komponenten
In der Eclipse Plattform können nur statische Plugins verwendet werden. Dies bedeutet, während
der Laufzeit können keine Plugins hinzu geladen oder entfernt werden. Hierzu muss die
Umgebung erst beendet und neu gestartet werden. Mit dem equinox-Projekt wird zwar an einer
dynamischen Lösung gearbeitet, diese ist aber noch nicht in Eclipse integriert.
- 34 -
Kapitel 4 : Einführung Plugins
•
Größerer Entwicklungsaufwand
Bei kleinen Erweiterungen der Eclipse-Plattform ist der Entwicklungsaufwand relativ groß, da
sich erst in die Dokumentation eingearbeitet werden muss und viele Dateien für ein Plugin
existieren müssen. Dem entgegen zu wirken versucht aber die in Eclipse existierende Plugin
Development Environment PDE, welche mit Werkzeugen das Erstellen von Plugins erleichtert.
•
Neues Window-Toolkit
Die Entwickler müssen sich in ein neues Window-Toolkit einarbeiten, da Eclipse intern mit dem
SWT arbeitet (s. Seite 29: SWT (Standard Widget Toolkit)). Dieses unterscheidet sich in der
Verwendung von den bekannten Window-Toolkits in Java wie AWT und Swing. Zwar können
diese auch in Eclipse verwendet werden, die damit erzeugten Werkzeuge integrieren sich aber
nicht so gut in die Umgebung.
•
Geschwindigkeit
Das starten der Eclipse Umgebung kann bei der Verwendung von vielen Plugins relativ lange
dauern, da bei jedem Start erst alle Plugins registriert werden müssen. Dazu werden alle PluginManifestdateien in den einzelnen Pluginverzeichnissen eingelesen. Dies kann dazu führen, dass
ein Start länger als 30 Sekunden dauert. Des Weiteren wird relativ viel Speicher für die
Verwaltung der Plugins benötigt. Zusätzlich können schlecht programmierte Plugins, welche die
Ressourcen nicht wieder freigeben, die Laufzeit noch weiter verschlechtern. Die im Abschnitt
„Spätes Laden„ auf Seite 34 beschriebene Methode, soll diesem schlechten Laufzeitverhalten
entgegen wirken.
4.5 Zusammenfassung
Trotz der zuvor genannten Nachteile, eignet sich Eclipse sehr gut dafür, neue Werkzeuge zu
entwickeln bzw. Vorhandene zu erweitern. Dies wird insbesondere durch das sehr gute Konzept des
Plugin-Mechanismus ermöglicht. Desweiteren wird durch das Oberflächenkonzept eine sehr
einheitliche Oberfläche der verschiedenen Werkzeuge, was Aussehen und Funktionalität angeht,
erreicht. Der Anwender kann somit schneller mit den verschiedenen Werkzeugen produktiv arbeiten,
da sich der Einarbeitungsaufwand verringert.
Durch das große Konsortium von Firmen die die Entwicklergemeinde von Eclipse unterstützen, ist
die Weiterentwicklung von Eclipse gut gesichert und es stellt kein Problem dar, Hilfe bzw. Support
für die Plattform zu bekommen. Auch gibt es schon ein reichhaltiges Angebot von freien und
kostenpflichtigen Plugins, die es einem ermöglichen sich Eclipse an die eigenen Bedürfnisse
anzupassen.
- 35 -
Kapitel 5 : Planung Testausführer
5 Planung Testausführer
In diesem Kapitel werden die Vorüberlegungen zur Entwicklung des Testausführers beschrieben. Es
wurden erst Begriffe, wie Webanwendung, HTML und XML definiert. Diese Definitionen sind nötig
um ein Basis für die Begründung unserer Teststruktur zu geben. Da die Simulation des Browsers eine
zentrale Rolle in der Planung spielt, wird diese gesondert diskutiert. Als Nächstes wird erläutert, in
welchem Bereich die geplante Software zur Anwendung kommt und nach welchen Kriterien sie
entwickelt wurde. Dem folgt schließlich die Beschreibung der Teststruktur, auf die die Anwendung
ausgelegt wurde. Diese Struktur kommt in beiden Teilen der Diplomarbeit zum Tragen.
5.1 Vorüberlegungen
Es sollte ein Testwerkzeug zum „black-box“ Regressionstesten von Webanwendungen entwickelt
werden.
Was ist aber überhaupt eine Webanwendung? Webanwendung wird im Wikipedia [Wiki04] so
definiert:
„Eine Webanwendung ist eine Anwendung, die auf einem Webserver ausgeführt und
dann in einem Browser dargestellt wird.“
Dabei kann der Browser (Benutzeroberfäche einer Webanwendung) irgendwo aus dem Netzwerk
heraus, die Webanwendung aufrufen. Die Sprache für die Oberfläche, die in dem Browser angezeigt
wird, ist hauptsächlich HTML (Hypertext Markup Language). Die Webanwendungen werden im
Browser über eine URL aufgerufen.
Um so eine Anwendung „black-box“ Testen zu können, muss natürlich die Möglichkeit gegeben
sein, die Testfälle dafür zu beschreiben. Beim „black-box“ Testen besteht diese Beschreibung
typischerweise aus Ein- Ausgabe Wertepaaren. Da jede Webanwendung eine Browserdarstellung hat,
liegt es nahe, dass die Definition der Testfälle auch darauf basieren soll. Die Darstellung im Browser
wird normalerweise über die Sprache HTML beschrieben. Wir können also die Testfallbeschreibung
auch an die Sprache HTML anlehnen.
Im Weiteren soll auf die Wiederholbarkeit des Tests großen Wert gelegt werden. Das Hauptproblem
ist also, Tests so zu speichern, dass sie jederzeit wieder ausführbar sind. Die Lösung dafür ist XML
(Extensible Markup Language).
5.1.1 HTML
Um in einer Weboberfläche, genannt Browser irgendetwas darzustellen, wird HTML (Hypertext
Markup Language) [Html01] benutzt. Die Definition von HTML ist:
„HTML ist eine Auszeichnungssprache (Markup Language), die die logischen
Bestandteile eines textorientierten Dokuments beschreibt.“
Als Auszeichnungssprache bietet HTML die Möglichkeit, typische Elemente eines textorientierten
Dokuments, wie Überschriften, Textabsätze, Listen, Tabellen oder Grafikreferenzen, als solche
auszuzeichnen. Diese Auszeichnung erfolgt im Rahmen von sogenannten Elementtypdefinitionen.
Ein Element hat die folgende Gestalt:
- 36 -
Kapitel 5 : Planung Testausführer
<tagname attributename=“attributevalue“>tagcontent</tagname>
Allgemeine Definition von einem Element:
1. Start Tag: entspricht dem Muster <tagname>.
2. Attribute mit entsprechenden Werten: entspricht dem Muster attributename=“attributvalue“. Die
Attribute müssen im Start Tag enthalten sein.
3. Inhalt des Elements: Entspricht dem Muster eines beliebigen Textes zwischen Start Tag und End
Tag. Der Inhalt muss sich zwischen Start Tag und End Tag befinden.
4. End Tag: entspricht dem Muster </tagname>.
Der Elementtyp ist der Text zwischen den spitzen Klammern (in dem Fall also „tagname“).
In HTML sind die Elementtypen fest vorgeschrieben. Es ist nicht möglich, bei Bedarf weitere
Elementtypen zu definieren. Die Verschachtelung ist auch festgelegt und nicht änderbar.
5.1.2 XML
Da wir in dem Dokument sehr oft den Begriff XML benutzen, soll hier definiert und erklärt werden,
was XML überhaupt ist. XML Definition von [Kun98]:
„XML ist ein Metasprache für Definieren von Dokumententypen.“
Als Nächtes stellt sich natürlich die Frage, was überhaupt eine Metasprache bzw. ein Dokumententyp
ist. Die Metasprache kann man auch als Beschreibungssprache bezeichnen. Das heißt für die
Definition, dass XML eine Sprache ist, die das Definieren von Dokumententypen beschreibt.
Um Dokumententypen erklären zu können, muss erst der Begriff Elemententyp erklärt werden. Die
Erklärung für den Elemententyp, findet man in dem Kapitel HTML.
Ein Dokumenttyp kann man nun folgenderweise definieren:
„Der Dokumenttyp zeigt an, welche Elemententypen in welcher Weise ineinander
verschachtelt sind.“
Nachdem nun alle Begriffe erklärt wurden, kann man die Definition von XML zusammenfassen:
„XML beschreibt, welche Elemententypen in welcher Struktur in dem Dokument
vorkommen dürfen.“
In XML dürfen also die Elemententypen und ihre Struktur untereinander definiert werden. Es ist
daher leicht einzusehen, dass HTML ein spezieller XML Dokumententyp ist, denn:
„HTML beschreibt, welche Elemententypen in welcher Struktur in dem HTML Dokument
vorkommen dürfen.“
Die Entscheidung für XML ist aus den folgenden Gründen sinnvoll:
•
XML ist konform zu HTML.
•
Tests sollen ohne Programmierkenntnisse oder speziellen Softwarekenntnisse erstellt werden
können.
- 37 -
Kapitel 5 : Planung Testausführer
•
Tests sollen auch von Menschen lesbar sein.
•
Die Testbeschreibung muss gut strukturiert und maschinell verarbeitbar sein.
•
Es existiert eine große Anzahl Werkzeuge für XML Verarbeitung, wie
•
Erstellen, Editieren von XML Dateien
•
Validieren von XML Dateien
Gewählte Werkzeuge zum XML Verarbeiten
•
Commons Digester (Apache Software Foundations)
•
Xerces (Apache Software Foundations)
5.2 Simulation des Browserzugriffs
Da es um automatisiertes Testen einer Webanwendung geht, steht die Simulation des Browsers an
zentraler Stelle. Wie soll es möglich sein auf eine Weboberfläche zu zugreifen, wenn sie nicht „per
Hand“ gesteuert werden soll? Die Antwort ist natürlich: durch eine Programmiersprache.
Es gibt eine große Auswahl von Werkzeugen, mit deren Hilfe auf Weboberflächen per
Programmiersprache (Java) zugegriffen werden kann. Diese Werkzeuge modellieren und simulieren
den Ablauf in einem Webbrowser.
Die Entwicklung wurde mit dem Werkzeug HttpUnit angefangen, wir mussten aber später auf
HtmlUnit umsteigen. Der Grund dafür war die fehlende Funktionalität und schwierige
Erweiterungsmöglichkeit (bedingt durch die interne Klassenstruktur) von HttpUnit. So ist also
HtmlUnit bei uns zum Einsatz gekommen.
Junit wird hier nur diskutiert, weil einige der zunächst beschriebenen Anwendungen Junit, oder Teile
davon, als Basis benutzen. Typischerweise kann die Fehlerbehandlung von Junit überall benutzt
werden.
Junit
Junit [Link02] ist ein kleines, mächtiges „open source“ Framework zur Automatisierung von Java
Unit Tests. Geschrieben wurde er in der Programmiersprache Java.
Vorteile:
•
Programmiersprache ist gleich Testsprache, dies erleichtert das Schreiben der Tests.
•
Trennung von Anwendungs- und Testcode. Testfälle stehen in eigener Hierarchie, nicht gemischt
mit dem tatsächlichen Code.
•
Unabhängigkeit der Testfälle voneinander. Für jede Testmethode (Testfall) wird eine
Vorkonfiguration (setUp()- Methode) und Nachkonfiguration (tearDown()- Methode)
vorgenommen.
•
Tesfälle können beliebig in Testsuites (Testsammlungen) zusammengefasst werden.
•
Erkennen des Testergebnisses mit einem Blick. Dazu dienen die Assert – Methoden, die eine
eindeutige Überprüfung des Soll- Istwertes bewerkstelligt.
•
Es gibt viele Erweiterungen, die weitere Funktionalität zur Verfügung stellen. Siehe dafür
- 38 -
Kapitel 5 : Planung Testausführer
[Junit04].
Nachteile:
•
Es müssen zusätzliche Methoden für das Testen geschrieben werden. Durch mehr Code entstehen
mehr Fehlermöglichkeiten.
•
Nur für Modultest gut geeignet.
•
Keine Möglichkeit andere Testarten, als Unit Tests auszuführen.
5.2.1 HttpUnit
Erweiterung vom Testframework Junit. HttpUnit stellt Werkzeuge zum Zugreifen verschiedenster
Elemente auf einer Weboberfläche zur Verfügung. Es basiert auf dem „Request- Response“ (FrageAntwort) Verfahren.
•
Beispiel: Testprogramm „x“
1. Google Seite aufmachen.
2. Schreibe in dem Textfeld mit dem Namen „q“ den Wert „HttpUnit“.
3. Drücke Knopf mit den Namen „btnG“.
4. Suche den Verweis mit dem Namen „HttpUnit“.
5. Klicke den gefundenen Verweis an.
6. Überprüfe ob der Titel „HttpUnit“ ist.
7. Suche Verweis mit dem Namen „User's Manual“.
import
import
import
import
import
junit.framework.TestCase;
com.meterware.httpunit.WebResponse;
com.meterware.httpunit.WebConversation;
com.meterware.httpunit.WebForm;
com.meterware.httpunit.WebRequest;
public class SearchExample extends TestCase {
public void testSearch() throws Exception {
WebConversation wc = new WebConversation();
WebResponse resp = wc.getResponse
( "http://www.google.com");
WebForm form = resp.getForms()[0];
form.setParameter("q", "HttpUnit");
WebRequest req = form.getRequest("btnG");
resp = wc.getResponse(req);
assertNotNull(resp.getLinkWith("HttpUnit"));
resp = resp.getLinkWith("HttpUnit").click();
assertEquals(resp.getTitle(), "HttpUnit");
assertNotNull(resp.getLinkWith("User's Manual"));
}
- 39 -
Kapitel 5 : Planung Testausführer
}
Vorteile:
•
ausgereiftes, länger existierendes Testframework
•
bei „standard“-Anwendung sehr gut brauchbar (kein Automatisierungswunsch)
•
gute Frameunterstützung
•
ausgereifte JavaScript Unterstütztung
Nachteile:
•
keine direkte Möglichkeit HTML Elemente durch ein beliebiges Attribut zu finden
•
keine oder kaum Unterscheidung in der Behandlungsweise zwischen verschiedenen HTML
Elementen
•
keine gute Unterstützung vom HTML Element „checkbox“
•
schlecht erweiterbar, da zu viele „private class“, „inner class“ vorhanden
•
viele Klassen wurden nicht oder nicht genügend dokumentiert
5.2.2 HtmlUnit
Ähnlich, wie HttpUnit erlaubt HtmlUnit auch das Zugreifen auf Webseiten auf HTML Basis. Sie
basiert aber auf der Behandlung von HTML Seiten.
•
Beispiel: Testprogramm „x“ (siehe auch HttpUnit Beispiel)
import
import
import
import
import
import
import
import
java.net.URL;
junit.framework.TestCase;
com.gargoylesoftware.htmlunit.WebClient;
com.gargoylesoftware.htmlunit.HtmlAnchor;
com.gargoylesoftware.htmlunit.HtmlForm;
com.gargoylesoftware.htmlunit.HtmlPage;
com.gargoylesoftware.htmlunit.HtmlSubmitInput;
com.gargoylesoftware.htmlunit.HtmlTextInput;
public class SearchExample extends TestCase {
public void testSearch() throws Exception {
WebClient wc = new WebClient();
URL url = new URL("http://www.google.com");
HtmlPage page = (HtmlPage) wc.getPage(url);
HtmlForm form = (HtmlForm) page.getAllForms().get(0);
HtmlTextInput text = (HtmlTextInput)
form.getInputByName("q");
text.setValueAttribute("HttpUnit");
HtmlSubmitInput button = (HtmlSubmitInput)
form.getButtonsByName("btnG");
page = (HtmlPage) button.click();
assertNotNull(page.getAnchorByName("HttpUnit"));
- 40 -
Kapitel 5 : Planung Testausführer
HtmlAnchor link = page.getAnchorByName("HttpUnit");
page = (HtmlPage) link.click();
assertEquals(page.getTitleText(),"HttpUnit");
assertNotNull(page.getAnchorByName("User's Manual"));
}
}
Vorteile:
•
Innerer Aufbau gut strukturiert, daher leicht erweiterbar
•
Möglichkeit, verschiedene Browser (Stöberer) Versionen anzugeben
•
HTML Elemente werden auch intern unterschieden => Möglichkeit zur verschiedenen
Behandlung
Nachteile:
•
relativ unbekannt in Fachkreisen
•
keine Dokumentation vorhanden, außer der Projektseite
•
schlechtere Frameunterstützung
•
JavaScript Unterstützung sehr rudimentär
5.2.3 JwebUnit
Erweiterung von Junit und HttpUnit. JwebUnit vereinfacht die Testdefinition von HttpUnit und führt
neue Assert- Methoden ein.
•
Beispiel: Testprogramm „x“
import net.sourceforge.jwebunit.WebTestCase;
public class JWebUnitSearchExample extends WebTestCase {
public JWebUnitSearchExample(String name) {
super(name);
}
public void setUp() {
getTestContext().setBaseUrl("http://www.google.com");
}
public void testSearch() {
beginAt("/");
setFormElement("q", "httpunit");
submit("btnG");
clickLinkWithText("HttpUnit");
assertTitleEquals("HttpUnit");
assertLinkPresentWithText("User's Manual");
}
- 41 -
Kapitel 5 : Planung Testausführer
}
Vorteile:
•
sehr klein => sehr gut überschaubar
•
sehr leicht benutzbar
•
Zugriffsmöglichkeit auf die HttpUnit Schnittstelle für erweiterte Funktionalität
Nachteile:
•
basiert auf HttpUnit, daher dieselben Nachteile vorhanden
5.3 Anwendungsbereich
Das zu implementierende Testwerkzeug soll im „black- box“ Testbereich Anwendung finden. Diese
Testart kann in jedem Schritt des Software- Entwicklungsprozesses herangezogen werden. Siehe
Abbildung 11 Anwendbarkeit von "black-box" Tests. „white- box“ Testen ist mit dem Testwerkzeug
Anforderungen
spezifizieren
„black-box“
Abnahmetest
System
spezifizieren
„black-box“
(Sub)System
entwerfen
„white-box“
„black-box“
Integrationstest
Modul
entwerfen
„white-box“
„black-box“
Modultest
Systemtest
Kodieren
Abbildung 11 Anwendbarkeit von "black-box" Tests
nicht möglich.
Das Hauptaugenmerk liegt auf Regressionstests von Webanwendungen. Diese Testart ermöglicht es,
nach Änderungen bzw. Korrekturen der Webanwendung zu prüfen, ob weiterhin die vorher
spezifizierte Funktionalität gegeben ist.
Wir haben uns dabei auf zwei Testarten spezialisiert.
•
Funktionstest
•
Massentest
Bedingt ausführbar sind die Testarten:
•
Zeittest
- 42 -
Kapitel 5 : Planung Testausführer
•
Interoperabilitätstest
•
Benutzbarkeitstest
•
Lasttest
Welche Testfälle angewandt werden und wie die Testdaten dazu erzeugt werden, bleibt weiterhin die
Aufgabe des Testers. Die Methoden, wie die Testfälle systematisch ausgewählt werden können,
wurde in dem Kapitel „Black-box Testen“ beschrieben. Die intuitivste Möglichkeit zur Auswahl der
Testfälle für Funktionstest wäre die Funktionsabdeckung.
Die wichtigste Bedingung und Einschränkung bei jedem Test ist, dass das Testwerkzeug die
Webanwendung nur auf HTML (Hyper Text Markup Language) Ebene testen kann. Diese Ebene
beinhaltet alles, was in der Oberfläche der Anwendung erscheint bzw. die internen Zustände, die in
der HTML Seite gehalten werden (z.B. Informationen in cookies, header). Zusammenfassend kann
man also sagen:
„Es kann alles mit dem Testwerkzeug getestet werden, was man sieht!“
5.4 Anforderungen
Bei der Konzeption des Testwerkzeugs werden die folgenden Kriterien an die Software gesetzt.
•
Wiederverwendbarkeit von Testdefinitionen.
Die auszuführenden bzw. bereits ausgeführten Tests müssen gespeichert werden und ohne
zusätzlichen Aufwand wieder ausführbar sein.
•
Möglichkeit Module zu definieren.
Module sind Testablaufausschnitte, die beliebig oft in beliebig viele Tests eingebunden werden
können. In dem Modul können statt fester Testwerte auch Variablen vorhanden sein, diese sollten
beim Einbinden in den entsprechenden Testablauf angegeben werden. Sehr gut geeignet z.B. für den
Login-Vorgang.
•
Möglichkeit zur Testdatengenerierung.
Es soll eine Schnittstelle definiert werden die es ermöglicht, Testdaten mit den vorgegebenen,
erlaubten Inhalten zu definieren.
•
Unterscheidung von Fehlertypen und Konzept zur Behandlung.
Es sollen verschiedene Fehlertypen definiert werden und ihre Rolle und Behandlung während (z.B.
Abbrechen des Testfalls) und nach Ablauf des Tests (z.B. Weiterreichung der Fehler an den
Entwicklern) festgelegt werden.
•
Tests müssen leicht definierbar sein.
Die Tests müssen leicht und ohne Programmierkenntnisse definierbar sein.
•
Graphische Benutzeroberfläche soll vorhanden sein.
Die graphische Benutzeroberfläche soll das Arbeiten mit dem Testwerkzeug erleichtern. Sie soll
Unterstützung und Hilfe leisten bei der Definition von verschiedenen Testarten, Modulen,
Testzusammenfassung etc. Die Auswertung von Fehlern soll vereinfacht werden.
•
Loggen des Testablaufs.
- 43 -
Kapitel 5 : Planung Testausführer
Es soll eine Schnittstelle definiert werden, die es erlaubt eigene Logger einzubinden. Diese wird
benötigt, damit beispielsweise Loggen direkt in die entsprechende Datenbank möglich wird.
•
Extrahieren von fehlgelaufenen Tests.
Die fehlerhaften Tests sollten extrahiert werden, damit sie direkt an den verantwortlichen Entwickler
zur Korrektur weitergereicht werden können.
•
Möglichkeit Tests zusammenzufassen.
Diese Möglichkeit soll gegeben sein, damit nicht alle Tests einzeln gestartet werden müssen. So wird
es beispielweise ermöglicht, die Tests nachts ablaufen zu lassen.
5.5 Teststruktur
Da unsere Anwendung XML (Extensible Markup Language)– basiert sein soll, wurde als erstes die
Struktur dafür festgelegt.
Dabei hat sich die folgende Struktur ergeben:
•
Es gibt drei Arten von XML Dateien.
•
XML Datei für die Zusammenfassung von Tests, wird in späterer Testsammlung genannt.
•
XML Datei für die Testdefinition, wird im späteren Test genannt.
•
XML Datei für ein Modul, wird im späteren Modul genannt.
•
Testsammlung dient zur Konfiguration des Testablaufs und zum Zusammenfassen von
Testdateien. Bei der Konfiguration können die Attribute, wie Hostadresse, Logger, HTML
Ablaufschreiber und einzubindende eigene JAR (Java Archive) [Som98] Dateien angegeben
werden. Bei der Zusammenfassung kann man in die Testsammlung sowohl andere
Testsammlungen, als auch Tests einfügen.
•
Test dient zur Definition eines Testablaufs. Hier wird angegeben, an welcher genauen Adresse der
Test gestartet werden soll und welche HTML Elemente in welcher Reihenfolge bearbeitet werden
sollen. Das Bearbeiten der HTML Elemente umfasst in erster Linie die Funktionen wie
Vorhandensein, Nichtvorhandensein des Elements, Drücken des Elements, Setzen des Elements,
Überprüfen des Elementenstatus. Ein Test kann Module erhalten.
•
Modul erhält die Definition eines Moduls. Dieses erlaubt, dass ein Teil des Testablaufs in eine
neue XML Datei ausgelagert wird. In dem Modul können dabei für die Werte Platzhalter
(Variablen) eingebunden werden. Der Wert dieser Platzhalter wird erst beim Einbinden in den
entsprechenden Tests angegeben. Im Modul werden keine weiteren XML Dateien eingebunden.
Zusammenfassend entsteht also eine hierarchische Struktur von XML Dateien, die folgenden Regeln
genügt:
Testsammlung:: ( Testsammlung| Test)*
Test:: (Module)*
•
Beispiel: Abbildung 12 XML Struktur des Entwicklungsprozesses
- 44 -
Kapitel 5 : Planung Testausführer
Abbildung 12 XML Struktur des Entwicklungsprozesses
Bei der Abbildung 12 XML Struktur des Entwicklungsprozesses entsprechen die Knoten einzelnen
XML Dateien. Der Pfeil zeigt an, dass die Datei (am Ende des Pfeiles) in die Datei (am Anfang des
Pfeiles) per Referenz eingebunden wurde.
Bei der Erstellung solcher XML Hierarchien sollte eine Voraussetzung besonders beachtet werden.
„Der entstehende Graph darf nicht zyklisch sein!“
Die Abarbeitung dieser XML Struktur läuft folgendermaßen ab (angefangen beim „root“- Knoten):
•
Ausführung eines Testsammlungsknotens
1. Laden der Testsammlungsdatei.
2. Konfigurieren der Testsammlung.
3. Ausführen des Sammlungsteils (Kinderelemente werden der Reihe nach abgearbeitet).
•
Ausführung eines Testknotens
Die Testdatei wird geladen und Schritt für Schritt ausgeführt. Falls Module erhalten sind, werden sie
im Test geladen und mit ausgeführt.
•
Ausführung eines Modulknotens:
Die Moduledatei wird geladen und, in den Testablauf eingebunden, ausgeführt.
- 45 -
Kapitel 5 : Planung Testausführer
➔
Testsammlung (System)
➔ Testsammlung (Schnittstellen)
➔ Testsammlung (Module)
➔ Test 2
➔ Test 3
➔ Test 4
➔ Modul 1
➔ Testsammlung (Abnahme)
➔ Testsammlung (Schnittstellen)
➔ Testsammlung (Module)
➔ Test 2
➔ Test 3
➔ Test 4
➔ Modul 1
➔ Test 5
➔ Modul 1
➔ Test 6
➔ Modul 1
➔ Test 1
Nach diesen Regelwerk wird die Abarbeitungsreihenfolge in der Abbildung 12 XML Struktur des
Entwicklungsprozesses gezeigt.
- 46 -
Kapitel 6 : Planung Plugin
6 Planung Plugin
In diesem Abschnitt sollen die Vorüberlegungen zur Planung des Plugins und die Entscheidungen
verdeutlicht werden. Dazu werden wir erst die Vorüberlegungen bzw. Ansprüche die wir an das
Plugin haben aufzählen. Danach gehen wir kurz auf die Planung in der Zusammenarbeit mit dem
Testausführer ein.
6.1 Vorüberlegung
Das beste Werkzeug zum Ausführen automatisierter Tests nutzt nichts, wenn eine geeignete
Oberfläche zum Bearbeiten der Tests fehlt. Es war deshalb von Anfang an unser Ziel und Bestreben,
dem Anwender ein Werkzeug in die Hände zu geben, mit dem er die Testfälle leicht und einfach
Erzeugen, Verwalten und Bearbeiten kann. Wie im vorherigen Abschnitt erläutert, werden wir XML
zum Speichern der Testfälle benutzen. Dies hat zwar den Vorteil, das die Testfälle auch vom
Anwender direkt ohne Werkzeugunterstützung gelesen werden können, aber gerade bei sehr großen
und vielen Dateien verliert man dabei schnell den Überblick. Deswegen ist eine abstraktere Sicht auf
die Daten nötig, welche durch unser Plugin realisiert werden soll. Folgende Punkte sollen dabei
berücksichtigt werden:
1. In den unterschiedlichen Sichten soll weiterhin direkt auf der XML Struktur gearbeitet werden.
2. Ein direktes bearbeiten der XML Struktur soll weiterhin möglich sein, aber auch dabei soll der
Anwender mit Hilfen unterstützt werden (z.B. durch Code Completion).
3. Der Anwender soll in allen Ansichten Hilfen zum momentanen Problem einfach erreichen
können.
4. Die vorhandene Hilfe sollte übersichtlich und durchsuchbar sein.
5. Das Werkzeug soll ihm ein einfaches Navigieren in den Testfällen ermöglichen und die
Abhängigkeiten der Testfälle untereinander leicht erkennen lassen.
6. Es sollte eine Unterstützung zum Refactoring geben. Dies bedeutet z.B. nach dem Verschieben
oder Umbenennen von Testfällen, sollte dies automatisch in allen abhängigen Testfällen vom
Werkzeug erledigt werden.
7. Das Ausführen der Testfälle soll schnell und einfach sein.
8. Die Darstellung der Testergebnisse soll übersichtlich und das Auffinden von fehlgeschlagenen
Tests schnell sein.
9. Ein Extrahieren von fehlgeschlagenen Testfällen sollte möglich sein, damit diese an Entwickler
weitergegeben werden können.
10.Das Verwenden von anderen Werkzeugen sollte möglich bzw. schon vorgesehen sein.
Da wir schon häufiger mit der Eclipse IDE gearbeitet hatten, wussten wir, das diese für viele der
oben genannten Punkte Unterstützung bietet. Deshalb haben wir uns entschieden, das Werkzeug zum
Bearbeiten der Testfälle als Eclipse Plugin zu schreiben. Zwar hätte man auch eine komplett eigene
Anwendung schreiben können, dies würde aber einen viel größeren Entwicklungsaufwand bedeuten.
Zum anderen wäre die Zusammenarbeit mit anderen Werkzeugen erschwert worden.
Im dem folgenden Abschnitt wollen wir kurz beleuchten, in wie fern Eclipse die zuvor genannten
Anforderungen unterstützt oder auf andere bzw. selbst zu entwickelnde Werkzeuge zurückgegriffen
- 47 -
Kapitel 6 : Planung Plugin
werden muss.
6.1.1 XML Unterstützung
Eclipse selbst bietet nicht direkt eine Unterstützung zum internen Gebrauch von XML-Strukturen an.
Diese kann aber durch die Verwendung diverser Werkzeuge bzw. Bibliotheken ausgeglichen werden.
Da in Eclipse selbst das Model-View-Controller Konzept zum Tragen kommt, ist es auch nicht
schwierig diesen Punkt umzusetzen. Bei Texteditoren kommt eine Erweiterung dieses Musters zum
Einsatz. Dabei wird ein sogenannter Dokumentverwalter zwischen dem Editor und dem
Dokumentenmodell gesetzt. Dieser regelt dann die Zugriffe auf das Modell bzw. meldet Änderungen
zwischen Editor und Dokument weiter. An das Modell des Dokumentes wird noch ein Partitionierer
gehängt. Dieser teilt automatisch bei jeder Änderung des Modells das Dokument in nicht
überlappende Partitionen auf. Dafür wird ein Textscanner verwendet, der mit entsprechenden Regeln
Controller
View
AbstractTextEditor
StyledText
Model
Document
DocumentProvider
RuleBasedPartitioner
Rule
Rule
Rule
Abbildung 13 Eclipse: Model-View-Controller
bestückt ist. Eine Übersicht der Abhängigkeiten sehen sie in Abbildung 13.
Zum Abbilden der XML Struktur auf ein internes Objektmodell sollen der XML Parser Xerces,
sowie Digester zum Einsatz kommen.
Bei Xerces handelt es sich um einen von der Apache Software Foundation entwickelten XML Parser.
Wir werden die SAX-Variante des Parser zum Einlesen der Struktur und für das Validieren der
Dokumente gegen eine DTD (Document Type Definition) verwenden.
Digester ist ein von der Apache Software Foundation entwickelter Aufsatz für SAX-Parser, der es
vereinfacht XML-Elemente auf Javaobjekte abzubilden. Dabei wird der Digester mit Regeln
konfiguriert, die festlegen, wie XML-Elemente auf Objekte abgebildet werden. Die fertige
Objektstruktur besteht dann schon aus den von uns benötigten Objekten und muss nicht erst noch
umständlich z.B. aus der DOM-Struktur erstellt werden. Eine Beispiel für eine Abbildung der
- 48 -
Kapitel 6 : Planung Plugin
Objektstruktur
XML-Dokument
Root
Element1
Element3
Digester
Element2
Text = ...
...
<root>
<element1/>
<element2>
<element3>...</element3>
</element2>
<element1/>
</root>
Element1
Abbildung 14 Digester XML- / Objektstruktur
Objektstruktur zeigen wir in der Abbildung 49.
Für das Verarbeiten der DTD kommt ein DTD Parser zum Einsatz. Dieser überführt die DTD in eine
interne Objektstruktur, die dann zum Erhalten von Informationen über die DTD befragt werden kann.
Dazu gehört z.B. welche Elmente als Kindelemente in einem Elternelement erlaubt sind. Diese
Information wird für die Codevervollständigung im Texteditor benötigt.
6.1.2 Editoren
Die Editoren zum Bearbeiten der Tests und Testsammlungen sollen eine abstraktere Sicht auf die
Daten bieten. Es soll dem Anwender aber weiterhin möglich sein, auch die XML Daten direkt zu
bearbeiten. Dies kann in Eclipse mit den sogenannten Multipage Editoren erreicht werden. Multipage
Editoren sind Editoren die aus mehreren Seiten bestehen, die auf verschiedenen Registerkarten
angeordnet sind. Ein Beispiel hierfür, ist der Plugin Editor im PDE (siehe auch Abbildung 15 und
Abbildung 16). Der Plugin Editor bietet eine strukturierte Ansicht der XML Daten verteilt auf
Abbildung 15 Eclipse: PDE Editor
mehrere Registerkarten. Diese Sicht vereinfacht das Bearbeiten der Daten und bietet die Möglichkeit,
Hilfen direkt durch selbsterklärende Feldnamen oder entsprechend aufzurufende Dialoge anzubieten.
- 49 -
Kapitel 6 : Planung Plugin
Gerade bei sehr komplexen XML Daten sind solche Darstellungen für den Anwender hilfreich.
Abbildung 16 Eclipse: PDE Editor Registerkarten
Damit weiterhin eine direkte Bearbeitung der XML Daten möglich bleibt, wird im PDE Editor die
Registerkarte Source angeboten (siehe auch Abbildung 16). Hier steht dem Anwender ein einfacher
XML-Editor zur Verfügung. Da die Dateien mit jedem gewöhnlichen Texteditor oder XML-Editor
bearbeitet werden können, ist diese Ansicht auch nötig, wenn die Daten nicht mehr der DTD
entsprechen und deshalb nicht in ein internes Modell überführt werden können. Dann kann nur noch
der Texteditor angezeigt werden. Dem Anwender werden durch entsprechende Marker gezeigt, wo es
Probleme gibt, um ein schnelles Beheben der Fehler zu ermöglichen.
Diese Art von Editoren wird durch das Eclipse Framework unterstützt. Es gibt entsprechende
Schnittstellen, die ein implementieren von Multipage Editoren vorsehen.
6.1.3 Navigation und Ansichten
Die Daten, die zu einem Test gehören (dazu gehören Testdefinitionen, Testsammlungen, Module,
usw.), sollen dem Anwender in einer übersichtlichen und leicht verständlichen Darstellung angezeigt
werden, die ihm ein einfaches Navigieren erlauben. Die von Eclipse verwendete Strukturierung der
Daten soll dabei übernommen werden. Dazu sollen alle zusammengehörigen Daten in ein Projekt als
Dateien abgelegt werden. Dies ermöglicht das Verwenden der schon in Eclipse enthaltenen
Ansichten zum Navigieren auf den Daten, wie den Navigator oder den Package Explorer.
Des Weiteren können diese Ansichten durch den Pluginmechanismus auch leicht mit zusätzlicher
Funktionalität erweitert werden.
Die Verwendung von schon vorhandenen bzw. bekannten Ansichten erleichtert den Anwendern das
Benutzen des Werkeuges. Dies gilt insbesondere für Anwender, die schon vorher Eclipse für andere
Zwecke benutzt haben. Es verringert auch den Implementierungsaufwand, der betrieben werden
muss, um diese Ansichten zu erstellen.
Um eigene Implementierungen so klein wie möglich zu halten, sollen die schon vorhandenen
Ansichten nur erweitert werden. Dies betrifft hauptsächlich die Ansichten der Navigatoren und
Eigenschaften.
6.1.3.1 Navigatoren
Die Navigatoren stellen die Projektstruktur dar. Die neuen Datenobjekte, wie Testdefinition oder
Testsammlung, müssen in dem Navigator gekennzeichnet werden. D.h. sie haben eindeutige Icons,
welche erkennen lassen, um was es sich handelt. Des Weiteren müssen die Kontextmenüs in den
Navigatoren auf diesen Objekten, um die Aktionen erweitert werden, die auf ihnen ausführbar sind.
Dazu gehört z.B. das Starten eines Tests. Ein Beispiel für einen schon in der Eclipse
Standardinstallation vorhanden Navigator sehen wir in Abbildung 17. In ihm werden die vorhanden
Ressourcen im Workspace angezeigt.
Der Pluginmechanismus in Eclipse erleichtert die zuvor aufgeführten Änderungen bzw.
Erweiterungen. Von einer Implementierung eigener Navigatoren kann vorerst abgesehen werden, da
die Funktionalität der Vorhandenen ausreicht.
- 50 -
Kapitel 6 : Planung Plugin
Abbildung 17 Eclipse: Navigator für
Resourcen
6.1.3.2 Ansicht der Eigenschaften
Die Ansicht der Eigenschaften erlaubt es Informationen über bestimmte Objekte darzustellen und zu
bearbeiten. Ein Beispiel für Eigenschaften eines Dateiobjektes sehen sie in Abbildung 18. Dort
werden die Eigenschaften eines Dateiobjektes dargestellt, das in der Navigatoransicht ausgewählt
Abbildung 18 Eclipse: Ansicht der Eigenschaften
wurde. Für unser Werkzeug wollen wir die Eigenschaftenansicht dazu verwenden, dem Anwender
das schnelle und übersichtliche Bearbeiten bzw. Ansehen von Objekteigenschaften zu ermöglichen.
Dies wird durch die in Eclipse bereitgestellte Schnittstelle begünstigt, die es erlaubt für alle Objekte
die über die Oberfläche selektierbar sind, Eigenschaften zu definieren.
6.1.4 Darstellung der Testergebnisse
Die Darstellung der Testergebnisse eines Laufes wird durch den verwendeten Logger geregelt. Als
Logger setzen wir dafür Log4j ein und ermöglichen es dem Anwender selbst anzugeben, was, wie
und wohin geloggt werden soll. Wir haben deswegen nicht direkt einen Einfluß auf die Darstellung
- 51 -
Kapitel 6 : Planung Plugin
der Loggergebnisse. Die Ergebnisse könnten z.B. in eine HTML- oder XML-Datei geschrieben
werden, welche dann zur weiteren Auswertung genutzt werden kann.
Abbildung 19 Eclipse: Anischt JUnit
Allerdings wollen wir eine Ansicht implementieren, die nach einem Testlauf alle aufgetretenen
Fehlermeldungen anzeigt und ein schnelles Auffinden der entsprechenden Testfälle ermöglicht, in
denen diese aufgetreten sind. Das Aussehen der Ansicht soll sich dabei an die in Eclipse enthaltene
Ansicht von Junit, wie in Abbildung 19 zu sehen, anlehnen.
6.1.5 Hilfe
Um dem Anwender das Verwenden des Werkzeuges zu erleichtern, muss ihm in allen Bereichen eine
Hilfe zu Verfügung stehen. Diese sollte ihn mit kurzen Erläuterungen bzw. mit Verweisen auf nähere
Erklärungen unterstützen. Das Navigieren in dieser Hilfe sollte übersichtlich und einfach sein.
Diese Voraussetzungen werden bestens von der Eclipse Plattform erfüllt. Sie enthält ein integriertes
Hilfesystem, das erlaubt, in allen graphischen Oberflächenelemten eine kontextsensitive Hilfe
Abbildung 20 Eclipse: Kontexthilfe
anzubieten. Der Anwender kann diese jederzeit mit Drücken von F1 aufrufen. Es erscheint dann eine
- 52 -
Kapitel 6 : Planung Plugin
Kontexthilfe, die eine kurze Erklärung beinhalten kann oder noch Verweise auf ausführlichere
Themen besitzt. Ein Beispiel dafür sehen sie in der Abbildung 20. Dieses Beispiel zeigt die
Kontexthilfe in der Eigenschaftenansicht an. Sie gibt eine kurze Erläuterung der Funktion der
Ansicht und verweist auf Kapitel in der Onlinehilfe. Dieses Kapitel kann der Anwender durch
Anklicken der Links direkt öffnen.
Abbildung 21 Eclipse: Onlinehilfe
Die Onlinehilfe von Eclipse wird in sogenannte Bücher (Books) unterteilt. Dabei ist es meist so, dass
ein Buch zu einem Werkzeug oder Plugin von Eclipse gehört. Die Bücher sind dann in entsprechende
Sektionen unterteilt. Diese sind praktisch Verweise auf entsprechende Dateien, in denen die Hilfe
gespeichert ist. Als Beispiel zeigen wir in Abbildung 21 die allgemeine Hilfe für das Verwenden von
Eclipse.
Neben dem Darstellen der Onlinehilfe, bietet Eclipse auch gleich eine Funktion zum Durchsuchen
nach Schlagwörtern. Dazu kommt eine in Eclipse vorhandene Suchmaschine zum Einsatz, die alle
Dokumente nach den Schlagwörtern durchsucht und nach Relevanz sortiert.
Eclipse bietet also reichhaltige Unterstützung was das Erstellen und Verwenden von Hilfe angeht
und es muss nicht auf Werkzeuge von Dritten oder auf eigene Implementierungen zurückgegriffen
werden.
6.1.6 Refactoring
Eine direkte Unterstützung für Refactoring gibt es in Eclipse nicht. Allerdings können die Aktionen
leicht in die schon vorhandenen Menüs eingepflegt werden. Ein Überschreiben von Aktionen für
bestimmte Objekttypen ist auch leicht möglich. So könnten z.B. beim Umbenennen oder Verschieben
von Testfällen automatisch alle Referenzen in den Testsammlungen auch angepasst werden. Als
Beispiel soll hier einmal das Refactoring des Java Plugins genannt sein, welches den in Abbildung 22
gezeigten Dialog beim Umbennen von Klassen anbietet.
- 53 -
Kapitel 6 : Planung Plugin
Abbildung 22 Eclipse: Java Rename Dialog
6.1.7 Andere Werkzeuge
Durch den Pluginmechanismus von Eclipse steht dem Verwenden von anderen Werkzeugen nichts
im Wege. Gibt es entsprechende Plugins, können diese einfach integriert werden und stehen ab sofort
dem Anwender zur Verfügung.
Schon in der Standardinstallation enthält Eclipse nützliche Plugins, wie z.B. das CVS Plugin. Mit
diesem ist es möglich, jegliche Art von Projekt in einem CVS zu führen, ohne auf zusätzliche
Werkzeuge außerhalb von Eclipse angewiesen zu sein. Zum anderen hat das den Vorteil, dass auf
jeder Plattform, auf der Eclipse läuft, die Umgebung und Werkzeuge gleich bedient werden. Die
Verwendung von verschiedenen Werkzeugen entfällt somit, wie z.B. bei allein stehenden CVS
Klienten auf Unix und Windows.
Das Angebot an Plugins für diverse Anwendungsbereiche ist groß. Es reicht von klompletten IDEs
für andere Programmiersprachen (z.B. Java, Perl oder C/C++), über Datenbankverwaltungen (z.B.
für MySQL, Oracle, usw.), UML-Werkzeugen, HTML- und XML-Editoren und vieles mehr. Eine
genaue Aufzählung würde den Rahmen sprengen, es sei aber auf die [Ecl04] Literatur verwiesen.
Dort stehen mehrere Links auf Seiten, die Plugins anbieten.
Durch die Eclipse-Plattform ist es dem Entwickler möglich alle seine benötigten Werkzeuge unter
einem Dach zu haben. Ein Wechseln zwischen vielen verschiedenen Werkzeugen entfällt. Zum
Anderen ist der Aufbau und die Verwendung der Werkzeuge häufig gleich oder zumindest sehr
ähnlich, da versucht wird, bei der Entwicklung der Plugins sich an die von Eclipse vorgegebenen
Designregeln zu halten. Dies verringert den Einarbeitungsaufwand und erhöht die Produktivität des
Anwenders bei der Verwendung der Werkzeuge.
6.1.8 Zusammenfassung
Viele der in der Vorüberlegung genannten Ansprüche bzw. Vorgaben können wir mit Hilfe der
Eclipse Plattform abdecken. Diese beinhaltet entweder schon fertige Werkzeuge oder bietet
Schnittstellen und Frameworks an, die ein einfaches Implementieren der benötigten Funktion
- 54 -
Kapitel 6 : Planung Plugin
ermöglichen.
Bei der Verarbeitung von XML und DTD müssen wir auf andere Werkzeuge und Bibliotheken
ausweichen. Für die Erstellung des Prototypen werden hierfür hauptsächlich Produkte der Apache
Software Foundation Verwendung finden, da diese frei zugänglich sind und häufig auch genügend
Dokumentation im Internet zu finden ist.
Andere Werkzeuge, die auch noch zum Bearbeiten verwendet werden könnten (z.B. zum Auswerten
von Log4J Daten), können durch Plugins von Dritten durch den Anwender nachträglich, je nach
Bedarf, installiert werden.
- 55 -
Kapitel 7 : Umsetzung Testausführer
7 Umsetzung Testausführer
Dieses Kapitel beinhaltet die Umsetzung des Testausführers. Es wird als Erstes die Architektur
behandelt, dann auf die einzelnen Komponenten dieser eingegangen. Dabei wird erklärt, welche
Komponente welche Aufgabe und Rolle in der Anwendung hat. Nachher werden die Strukturen der
einzelnen XML Dateien im Detail erläutert. Da in dem Testausführer von Anfang an Möglichkeiten
zur Erweiterung der Funktionalität eingeplant (und auch implementiert) wurden, werden diese im
abschließenden Teil des Kapitels unter dem Titel „Schnittstellen“ beschrieben.
7.1 Architektur
Hier wird nur die Architektur des Testausführers ( englisch: TestRunner) erklärt. Diese wurde in im
Kasten dargestellt. Die Pfeile zeigen den Informationsfluss zu und von dieser Komponente.
Eclipse Oberfläche
Testausführer
Steuerung
Konfiguration
Fehler
HTML Elemente
HTML
<html>
HTML
fjk kf<html>
ff fd
fd
HTML
fff fjk
ghfn
<html>
kf hgk
ff fdofd
u iz
f adsgf
fjk
kfhgk
ff fd
fffzfghfn
o fd
hgk o
u</html>
izfffzfghfn
f adsgf
u iz zf f adsgf
</html>
</html>
LOG
dfgr f r r dfgrt
gtg rstg <rs
dfgdfb erdber
erdrd erhz g
rerere dds e
Abbildung 23 Architektur des Testausführers
Wie schon erwähnt wurde, werden die Definitionen der Testsammlungen, Tests und Module im
Dateiformat XML gehalten. Der Testausführer kann nur mit einer Testsammlung aufgerufen werden.
Der Ablauf sieht so aus:
1. Der Testausführer wird aufgerufen. Dieser Aufruf kann, muss aber nicht von der Eclipse
Oberfläche her erfolgen. Es müssen dabei die folgenden Parameter übergeben werden:
•
Arbeitsverzeichnis: Dieser ist ein absoluter Pfad, der ein Arbeitsverzeichnis für die
Testsammlung definiert. Gedacht ist er dafür, dass alle weiteren Pfadangaben in dieser
Testsammlung relativ zu diesem Arbeitsverzeichnis angegeben werden können.
•
Pfad zur ersten Testsammlung: Dieser Pfad gibt an, wo die Testsammlung, die ausgeführt
werden soll, sich befindet. Die Angabe kann absolut oder relativ zu dem Arbeitsverzeichnis
erfolgen.
2. Testausführer führt die übergebene XML Struktur aus.
- 56 -
Kapitel 7 : Umsetzung Testausführer
3. Falls angegeben, werden die Dateien für die HTML Testverfolgung und die Log- Datei
geschrieben.
4. Die während der Ausführung gesammelten Fehler werden als Liste an den Aufrufer
zurückgeliefert.
7.1.1 Konfiguration
Diese Komponente ist verantwortlich für die richtige Konfiguration bei der Ausführung von Tests.
Die Konfiguration hat zwei Hauptteile:
7.1.1.1 Konfiguration des Parsers
Dieser Teil der Konfiguration wird in sogenannten DTD (Document Type Definition) Dateien
festgelegt. In den DTD Dateien wird angeben, welche Kombinationen von Tags in den XML Dateien
erlaubt werden. Diese Struktur wird vor dem Parsen überprüft. Den Vorgang der Überprüfung nennt
man „validieren“. Die Konfiguration der Dateistruktur kann nicht vom Benutzer angegeben werden,
sie ist für alle Testabläufe gleich.
7.1.1.2 Konfiguration der Testsammlung
Die Konfiguration der Testsammlung wird in der XML Definitionsdatei der entsprechenden
Testsammlung festgelegt. Sie kann, vielmehr muss, von dem Benutzer definiert sein. Hier kann man
Optionen festlegen, wie etwa, ob geloggt werden soll und, falls ja, mit welchem Logger der Vorgang
beschrieben werden soll. Eine nähere Beschreibung der Konfiguration erfolgt in der Beschreibung
der Testsammlungsdatei. Die Ausführung der Konfiguration passiert direkt nach dem erfolgreichen
Parsen der Testsammlungsdatei.
7.1.2 Steuerung
Wie schon der Name sagt, ist diese Komponente verantwortlich für die Steuerung des Ablaufs in
dem Testausführer. Dieser umfaßt die Steuerung aller Abläufe, wie Laden, Validieren, Parsen,
Ausführen von XML Dateien, Schreiben von Ausgabedateien etc.. Wie man vielleicht hier schon
erkennen kann, spielen bei der Steuerung die XML Dateien eine zentrale Rolle. Sie geben an, was,
wann und wie ausgeführt werden soll. Insgesamt ist also festzustellen:
„Ausgeführt wird nur das, was in den XML Dateien definiert wurde. Nicht mehr und
nicht weniger.“
Beiläufig sei erwähnt, dass die Ausführung der XML Dateien immer dieses ungefähre Schema
verfolgt:
1. Laden: Erfolgt immer erst, wenn die entsprechende Datei gebraucht wird. Das hat den Vorteil,
dass Arbeitsspeicher gespart wird, da nie mehr im Arbeitsspeicher gehalten wird, als nötig.
Nachteil des Verfahrens ist, dass dieselbe Datei evtl. mehrmals geladen wird. Es kann also eine
längere Ausführungszeit bedingen.
2. Validieren: Nach dem erfolgreichen Ladevorgang, wird die XML Datei gegen ihre DTD validiert.
Das heißt, es wird überprüft, ob alle in der DTD definierten Regeln in der XML Datei erfüllt sind.
3. Parsen: Dach einem gelungenen Validieren (sprich: tatsächlich alle Regeln erfüllt), wird die Datei
geparst und auf der vordefinierten internen Klassen- bzw. Objektstruktur abgebildet. Zum Parsen
- 57 -
Kapitel 7 : Umsetzung Testausführer
und Abbilden wird Commons Digester von Apache Foundations verwendet. Für jeden
verschiedenen Tag in den XML Dateien ist eine eigene Klasse verantwortlich. Diese Klasse stellt
die Methoden zum erfolgreichen Parsen und Ausführen der XML Struktur zur Verfügung.
4. Ausführen: Falls das Parsen auch richtig verlaufen ist, wird die XML Datei ausgeführt. Dazu
werden die geparsten Informationen aus den XML Dateien benutzt. Falls diese Information fehlt
oder falsche Daten enthält, wird typischerweise die Ausführung der Datei (und der ganzen
Hierarchie darunter) abgebrochen und ein Fehler geworfen. Ein Ausnahme dabei ist die
Konfiguration der Testsammlung. In diesem Fall wird der Fehler nur abgefangen, in die
Fehlerliste geschoben und dann mit der Ausführung fortgefahren.
7.1.3 HTML Elemente
In dieser Komponente sind die Klassen zusammengefasst, an denen die einzelnen HTML Elemente
abgebildet wurden. Dabei steht jedem unterstützten HTML Tag eine eigene Klasse zur Verfügung.
Die implementierten HTML Tags sind:
•
<a> Verweis; mit Hilfe dieses Elements ist ein Sprung von einer Stelle der Anwendung zur einer
Anderen möglich. Der Sprung kann innerhalb der selben Seite, Anwendung oder außerhalb der
Anwendung erfolgen. Die Sprungadresse kann sowohl relativ (zur Seitenadresse), als auch absolut
angegeben werden.
•
<button> Klickknopf ist ein Knopf, der mit bestimmten Aktionen verbunden werden kann; z.B.
Abschicken eines Formulars, Sprung usw.... Dieser Knopf ist flexibler als herkömmliche Knöpfe,
denn er darf auch einen definierten Inhalt haben, etwa eine Grafik. Der Nachteil ist, dass diese
Sorte Knopf nur von neueren Browsern unterstützt wird.
•
<form> Formular definiert einen Bereich der HTML Seite, der zum Weiterbearbeiten mit den
ausgefüllten Daten verschickt werden kann.
•
<frame> Frame definiert ein Ansichtfenster in der Seite. Es werden typischerweise mehrere
Frames in einer Seite definiert.
•
<input> Jegliche Art von (Eingabe-) Felder.
•
type=“button“ Klickknopf ist ein Knopf, der mit bestimmten Aktionen verbunden werden
kann; z.B. Abschicken eines Formulars, Sprung usw....; Dieser ist die ältere Variante des
Klickknopfes. Sein Vorteil liegt darin, dass er auch mit älteren Browser nutzbar ist.
•
type=“checkbox“ Mehrfachauswahl ist eine Gruppe von ankreuzbaren Quadraten, bei denen
der Anwender keines, eines oder mehrere auswählen kann. Die Werte von ausgewählten
Checkboxen werden beim Absenden des Formulars mit übertragen.
•
type=“file“ Datei aufladen. Diese Sorte Formularelement erlaubt dem Anwender, eine Datei
von seinem lokalen Rechner zusammen mit dem Formular zu übertragen. Wenn ein CGI-Script
die ankommenden Formulardaten auf dem Server-Rechner verarbeitet, ist es dadurch möglich,
dem Anwender das Uploaden (Hochladen) von Dateien auf den Server-Rechner zu
ermöglichen.
•
type=“image“ Optischer Klickknopf, mit Hilfe dieses Elements ist es möglich, innerhalb von
Formularen eine Grafik als Absendeknopf zu definieren.
•
type=“password“ Passwort Feld, ist das Feld für die Eingabe eines Passworts. Der Unterschied
- 58 -
Kapitel 7 : Umsetzung Testausführer
zu normalen Eingaben ist , dass auf der Oberfläche nur Sternchen statt der Einträge erscheinen.
•
type=“radio“ Einfachauswahl ist eine Gruppe von beschrifteten Knöpfen, von denen der
Anwender einen auswählen kann. Es kann immer nur einer der Knöpfe ausgewählt sein. Der
Wert des ausgewählten Knopfes wird beim Absenden des Formulars mit übertragen.
•
type=“reset“ Zurücksetzen-Knopf erlaubt es, ein teils oder voll ausgefülltes Formular auf seine
Anfangswerte zurückzusetzen. Die Anfangswerte entsprechen typischerweise den in der HTML
Seite definierten Defaultwerten.
•
type=“submit“ Abschicken-Knopf ist ein Knopf mit dessen Hilfe ein ausgefülltes Formular
zum Weiterverarbeiten abgeschickt werden kann.
•
type=“text“ Texteingabefeld erlaubt die Eingabe von beliebigen Zeichen in beliebiger Länge,
falls nicht anders definiert.
•
<select> Auswahlbox erlaubt es dem Anwender eine Liste mit festen Einträgen anzubieten, aus
der er einen oder mehrere Einträge auswählen kann. Der Text des ausgewählten Eintrags wird
übertragen, wenn der Anwender das Formular abschickt.
•
<textarea> Textbox dient als mehrzeiliges Eingabefeld zur Aufnahme von Kommentaren,
Nachrichten usw..
Es ist im Weiteren auch möglich, einen beliebigen Text anzugeben, der in der Seite gesucht werden
soll. So ist beispielsweise ein Auffinden der Titel etc. auch kein Problem.
Die Klassen haben in der Testausführung mehrere Rollen. Jede Klasse stellt die Methoden zum
Parsen, Ausführen und Ausgabe des bestimmten HTML Elements zur Verfügung.
7.1.4 Fehler
Diese Komponente definiert verschiedene Fehlertypen und sammelt sie während der Testausführung.
Die Sammlung erfolgt an einer zentralen Stelle der Anwendung. Beim Beenden der Ausführung wird
die Fehlersammlung an den Aufrufer zurückgeliefert. Dieser kann sie dann weiterbearbeiten. Wenn
der Aufrufer die Eclipse- Anwendung ist, werden sie aufbereitet und an den entsprechenden Stellen
in den XML Dateien markiert.
Es werden grundsätzlich drei Fehlerarten unterschieden:
7.1.4.1 Abgleichfehler im Testablauf
Diese Fehlerart taucht dann und nur dann auf, wenn ein in einer XML Datei definierter SOLLZustand nicht dem tatsächlichen aus der HTML Seite ausgelesenen IST- Zustand entspricht. Dieser
kann sein:
•
Gesuchtes HTML Element ist nicht vorhanden.
•
Wert des HTML Elements ist falsch.
Dabei wird typischerweise der Vergleichsoperator „ist gleich“ benutzt.
7.1.4.2 Fehler im Testablauf
Diese Fehlerart umfasst alle Fehler des Testablaufs, die nicht in die Kategorie des Abgleichfehlers
fallen. Dies sind meistens Fehler, die beim Validieren, Parsen der Testdatei entstehen, aber auch
- 59 -
Kapitel 7 : Umsetzung Testausführer
eventuelle unerwartete Fehler.
7.1.4.3 Fehler im Testsammlungsablauf
Diese Fehlerart ist verantwortlich für alle Fehler, die während der Ausführung einer Testsammlung
passieren. Das sind meistens Konfigurationsfehler, Fehler beim Validieren, Parsen der
Testsammlungsdatei und auch unerwartete Fehler.
7.2 Testsammlungsdatei
7.2.1 Definition
Die XML Datei Testsammlung definiert die Konfiguration und die Reihenfolge der zu ausführenden
Tests bzw. anderer Testsammlungen.
Diese Art der XML Datei ist die Einzige, die direkt zum Ausführen aufgerufen werden kann, ohne
eine Einbettung in eine andere Datei. Sie ist also sozusagen die Startdatei für die auszuführenden
Testfälle.
7.2.2 Ausführung
Bei der Ausführung muss man unterscheiden zwischen der Ausführung der ersten Testsammlung
(Root Knoten) und anderer Testsammlungen (Zwischen-, Endknoten). Siehe: Kapitel „Planung des
Testausführers“.
Um die erste Testsammlung auszuführen, muss die Methode runTestCollection() in der Klasse
TestCollectionRunner.java aufgerufen werden. Diese Methode veranlaßt dann die
Testsammlungsdatei und alle anderen im <collection> Teil eingefügten weiteren Dateien
(Testsammlungsdateien, Testdateien) auszuführen.
Die Methode runTestCollection() hat zwei Parameter:
1. testcollectionPath: Ist vom Typ String, der den Pfad zur ersten Testsammlungsdatei angibt. Die
Pfadangabe kann absolut oder relativ zum Arbeitsverzeichnis erfolgen. Das Arbeitsverzeichnis
wird in dem folgenden Parameter gesetzt werden.
2. workingDirectory: Dieser Parameter ist auch vom Typ String, der den Pfad zu dem
Arbeitsverzeichnis der aktuellen Testsammlung angibt. Dieser Pfad muss absolut sein.
Ab diesem Punkt ist der Ablauf bei jeder Testsammlung identisch.
1. Testsammlungsdatei wird gegen ihre DTD validiert.
2. Testsammlung wird geparst.
3. Testsammlung wird ausgeführt.
1. Konfigurationen <configuration> werden gesetzt.
2. Sammlung <collection> wird der Reihe nach abgearbeitet.
7.2.3 Fehlerbehandlung
Bei der Ausführung einer Testsammlung gibt es nur einen Fehlertyp. Intern werden aber zwei Arten
von Fehlern unterschieden:
- 60 -
Kapitel 7 : Umsetzung Testausführer
7.2.3.1 Konfigurationsfehler
Diese sind, wie schon der Name sagt, Fehler die während der Konfiguration der Testsammlung
auftreten können. Dieses betrifft die Konfiguration des Loggers (Tag <loggerentry>), der HTML
Testverfolgung (Tag <htmltrace>) und die Einbindung von JAR Dateien (Tag <library>). Es gilt
nicht für die Definition der Hostadresse (Tag <host>).
Beim Vorkommen solcher Fehler wird die Ausführung der Testsammlung fortgesetzt. Das ist nötig,
damit die Testsammlungsdatei bei Konfigurationen, die nicht dringend erforderlich sind, trotzdem
ordnungsgemäß ausgeführt werden kann (bis auf den Teil, der von der Konfiguration betroffen wird).
Durch die Behandlung dieser Fehler kann passieren, dass:
•
nicht oder nur teils mitgeloggt wird (<loggerentry>)
•
keine HTML Testverfolgung mitgeschrieben wird (<htmltrace>)
•
bestimmte Testdateien nicht ausgeführt werden können; auf Grund fehlender Klassendateien
(<library>)
Generell soll dadurch verhindert werden, dass große Teile der Testhierarchie wegen eines
Konfigurationsfehlers nicht ausgeführt werden.
7.2.3.2 Sonstige Fehler
Das sind alle anderen Fehler, bei denen die Ausführung der Testsammlung abgebrochen wird. In
diesem Fall wird die gesammte Testhierarchie unterhalb dieses Knotens nicht ausgeführt. Dies
entspricht also einem Fehler, bei dessen Auftritt keine (richtige) Ausführung der Testsammlung
garantiert werden kann.
•
SAXParseException => XML Moduldatei ist invalid (entspricht nicht der Definition der DTD),
XML Testdatei ist invalid
•
NullPointerException => unbekannte Ursache (entweder Fehler in der Testsoftware oder nicht
abgefangene Ausnahmesituation)
7.2.4 Beispiel
In diesem Beispiel wird eine mögliche Definition für eine Testsammlungsdatei gegeben.
Im Konfigurationsteil wurden folgende Einstellungen für die Testsammlung gesetzt:
•
Hostadresse: „http://localhost:8080/“
•
Loggen: ja, mit der Konfiguration in der „htmlLogger.properties“ Datei
•
HTML Testverfolgung: ja, unter dem Ordner „c:/test0/test/“
•
JAR Datei „test.jar“ wurde in die Anwendung geladen
Dabei wurden die folgenden Dateien in der Testsammlung zusammengefasst:
•
„testInputCheckbox.xml“ Testdatei mit relativer Pfadangabe
•
„testcollection1.xml“ Testsammlungsdatei mit relativer Pfadangabe
•
„testSelectOne.xml“ Testdatei mit absoluter Pfadangabe
- 61 -
Kapitel 7 : Umsetzung Testausführer
•
„testSelectMultiple.xml“ Testdatei mit absoluter Pfadangabe
•
„testcollection2.xml“ Testsammlungsdatei mit absoluter Pfadangabe
<?xml version="1.0"?>
<!DOCTYPE testcollection PUBLIC "-//WebTest//DTD Collection 1.0//EN"
"Collection.dtd">
<testcollection>
<configuration>
<host address="http://localhost:8080/"/>
<loggerentry
path="/logger/properties/htmlLogger.properties"
enabled="on" />
<htmltrace
path="c:/test0/test/"
enabled="on"/>
<library path="c:/test0/test.jar"/>
</configuration>
<collection>
<testentry path="/tests/testInputCheckbox.xml"/>
<collectionentry path="/testcollection/testcollection1.xml"/>
<testentry path="c:/test0/tests/testSelectOne.xml"/>
<testentry path="c:/test0/tests/testSelectMultiple.xml"/>
<collectionentry path="c:/test0/testcollection/testcollection2.xml"/>
</collection>
</testcollection>
7.3 Testdatei
7.3.1 Definition
Die Testdatei beschreibt den Testablauf eines Testfalls.
Sie kann nicht selbständig ausgeführt werden. Sie muss eingebettet in den <collection> Teil einer
Testsammlungsdatei eingebunden sein.
Es können zwei Arten von Testdateien definiert werden:
•
einfacher Funktionstest
•
Massentest
7.3.2 Ausführung
Eine Testdatei kann immer nur in Verbindung mit einer Testsammlungsdatei ausgeführt werden. Der
Ablauf sieht so aus:
1. Beim Auffinden eines <testentry> Tags, wird unter dem Attribut „path“ angegebenen Pfad die
Testdatei gegen seine DTD validiert.
2. Nach erfolgreichem Validieren wird die Datei geparst und auf die Objektstruktur abgebildet.
- 62 -
Kapitel 7 : Umsetzung Testausführer
3. Wenn die Testdatei erfolgreich eingelesen wurde, wird mit der eigentlichen Ausführung
begonnen.
•
Testdatei wird Schritt für Schritt ausgeführt. Dabei entspricht ein Schritt einem <step> Tag.
•
Ein Schritt besteht aus:
1. Aufmachen der entsprechenden HTML Seite.
2. Ausführen des <input> Teils. Dieser Teil dient in erster Linie dem Bearbeiten der HTML
Seite. Erst wird dabei das Vorhandensein des Feldes geprüft, dann werden die Elemente der
Reihe nach abgearbeitet. Das Bearbeiten der HTML Elemente umfasst typischerweise
Setzen eines Wertes, Klicken eines Feldes. Zusammenfassend kann man das als die
Veränderung des internen Zustands der HTML Seite nennen.
3. Ausführen des <output> Teils. Dieser Teil dient zur Kontrolle der erwarteten Ergebnisse.
Diese Kontrolle besteht erstmal aus der Kontrolle, ob das entsprechende Element in der
Ergebnisseite erschienen ist oder nicht. Des Weiteren wird der interne Zustand des Elements
kontrolliert. Dabei wird der interne IST- Wert des Feldes durch „ist gleich“ Operator mit
dem SOLL- Wert verglichen. Der IST- Wert entspricht dem Wert in der HTML Seite, der
SOLL- Wert wurde in der Testdatei definiert.
7.3.3 Fehlerbehandlung
Es gibt zwei Arten von Fehlern, die während der Ausführung einer Testdatei auftreten können. Bei
einem Fehlerfall ist es aus drei verschiedenen Quellen möglich, die Stelle zu lokalisieren:
•
Liste der Fehler (Rückgabewert an den Testaufrufer)
•
Logger Ausgabe (Datei, Konsole, etc., je nach Definition)
•
HTML Testverfolgung
7.3.3.1 Abgleichfehler
Diese Fehlerart bestimmt, ob der vordefinierte Testablauf das gewünschte, vordefinierte Ergebnis
geliefert hat oder nicht.
Dieser Fehler kann ausschließlich in der Ausführung des <output> Teils der Testdatei, bei der
Kontrolle der gelieferten Werte, auftreten. Bei einem erfolgreichen Test darf kein solcher Fehler
zurückgeliefert werden.
Im Fehlerfall wird die Ausführung der Testdatei gestoppt.
Um diesen Fehler beheben zu können, gibt es zwei Möglichkeiten:
•
Testdatei wurde falsch definiert => Korrektur der Testdefinition
•
Testdatei wurde richtig definiert => Korrektur der Anwendung
7.3.3.2 Sonstige Fehler
Diese Fehlerart umfasst alle anderen Fehler, die während der Ausführung der Testdatei passieren. Im
Fehlerfall wird auch hier die Ausführung der gesamten Testdatei angehalten.
Da der Fehler viele Ursachen haben kann, ist es auch schwieriger, herauszufinden woran es lag und
- 63 -
Kapitel 7 : Umsetzung Testausführer
dementsprechend eine Korrektur vorzunehmen. Es wird hier versucht eine Hilfestellung für Beheben
solcher Fehler zu geben.
•
UnknownHostException => Hostadresse ist falsch in der Testsammlungsdatei, URL ist falsch in
der Testdatei, keine Internetanbindung vorhanden
•
SAXParseException => XML Moduldatei ist invalid (entspricht nicht der Definition der DTD),
XML Testdatei ist invalid
•
NullPointerException => unbekannte Ursache (entweder Fehler in der Testsoftware oder nicht
abgefangene Ausnahmesituation)
7.3.4 Beispiel
Das Beispiel beschreibt den folgenden einfachen Testfall:
1. Einloggen mit dem Login „test“ und Passwort „test“. Überprüfen, ob der Login- Vorgang
erfolgreich verlaufen ist.
2. Drücken des Verweises „Weiter!“ um an die Übersichtsseite zu kommen. Kontrolle, ob die
Übersichtsseite geöffnet wurde.
3. Drücken des Verweises „anlegen“, damit ein neuer Kunde angelegt werden kann; Kontrolle, ob
die Seite mit dem Titel „Neuer Kunde anlegen“ geöffnet wurde.
4. Anlegen eines neuen Kunden mit dem Vornamen „Tekla“, Nachnamen „Kiss“ und Bemerkung
„Testkunde“. Kontrolle ob die Daten an die Datenverarbeitungsseite mit dem Titel „Neuer Kunde
Daten“ weitergeleitet wurden.
5. Zurück zur Übersichtsseite mit dem Verweis „Zurück zur Übersicht!“.
<?xml version="1.0"?>
<!DOCTYPE test PUBLIC "-//WebTest//DTD Test 1.0//EN" "Test.dtd">
<test id="0" name="test1"
url="regressionstest/index.html">
<step id="0">
<input>
<form/>
<inputText name="Login" value="test"/>
<inputPassword name="Passwort" value="test"/>
<inputSubmit value="Absenden"/>
</input>
<output>
<message>Login erfolgreich!</message>
<a>Weiter!</a>
</output>
</step>
<step id="1">
<input>
<a>Weiter!</a>
</input>
<output>
- 64 -
Kapitel 7 : Umsetzung Testausführer
<message>Übersicht</message>
</output>
</step>
<step id="2">
<input>
<a>anlegen</a>
</input>
<output>
<message>Neuer Kunde anlegen</message>
</output>
</step>
<step id="3">
<input>
<form/>
<inputText name="Vorname" value="Kiss"/>
<inputText name="Zuname" value="Tekla"/>
<textarea name="Text">Testkunde</textarea>
<inputSubmit value="Absenden"/>
</input>
<output>
<message>Neuer Kunde Daten</message>
</output>
</step>
<step id="4">
<input>
<a>Zurück zur Übersicht!</a>
</input>
<output>
</output>
</step>
</test>
7.4 Moduldatei
7.4.1 Definition
Eine Moduldatei definiert einen Ausschnitt aus einem Testablauf, wo einige der Werte nicht fest,
sondern variabel angegeben werden. Dies ermöglicht es, denselben Ablauf in mehrere Testdateien
einzubinden, also eine Auslagerung von häufig benutzten Sequenzen.
Die Wertvergabe an den Variablen in dem Modul erfolgt beim Einbinden in der entsprechenden
Testdatei.
7.4.2 Ausführung
Die Ausführung folgt dem Schema:
1. Beim Auffinden eines <moduleentry> Tags in einer Testdatei, wird die Moduldatei unter dem im
Attribut „path“ angegebenen Pfad gegen ihre DTD validiert.
- 65 -
Kapitel 7 : Umsetzung Testausführer
2. Nach anschließendem Validieren wird die Moduldatei geparst und auf die Objektstruktur
abgebildet.
3. Wenn die Moduldatei erfolgreich eingelesen wurde, werden die <variable> Tags des
<moduleentry> Tags (Variablen der Moduldatei) eingelesen und an einer zentralen Stelle
hinterlegt.
4. Nun wird die Moduldatei Schritt <step> für Schritt ausgeführt, wie eine normale Testdatei. Beim
Benutzen der Werte wird immer erst nachgeschaut, ob es sich um eine Variable handelt. Falls es
eine ist, wird der entsprechender Wert gesetzt.
7.4.3 Fehlerbehandlung
Die Moduldateien haben kein eigenes Fehlerbehandlungsprinzip. Wenn bei der Ausführung des
Moduls etwas schiefläuft, wird dieser Fehler an den Test, der das Modul aufgerufen hat,
zurückgeliefert. Die weitere Vorgehensweise gleicht der, als ob dieser Fehler direkt während der
Ausführung der Testdatei vorgekommen wäre.
7.4.4 Beispiel
In dem Beispiel wird ein Formular mit Vor- und Nachnamen ausgeführt. Dann wird es mit dem
Abschickknopf mit dem id submit verschickt. Anschließend wird in der nächsten Seite kontrolliert,
ob die Daten richtig übernommen wurden.
<?xml version="1.0"?>
<!DOCTYPE module PUBLIC "-//WebTest//DTD Module 1.0//EN" "Module.dtd">
<module>
<step id="1">
<input>
<form/>
<inputText name="Vorname" value="$vorname"/>
<inputText name="Zuname" value="$zuname"/>
<inputSubmit id="submit"/>
</input>
<output>
<message>$vorname</message>
<message>$zuname</message>
</output>
</step>
</module>
7.5 Schnittstellen
Es gibt in der Anwendung momentan drei Schnittstellen, die das Einfügen eigener Programmcodes
bzw. Konfigurationen in das Programm erlauben.
7.5.1 Assert
Diese Schnittstelle erlaubt es, eigene Kontrollmethoden für das Abgleichen zwischen SOLLElement (Element definiert in einer XML Datei) und IST- Element (Element aus der HTML Datei)
- 66 -
Kapitel 7 : Umsetzung Testausführer
zu implementieren. Mit Hilfe der Schnittstelle können von den Elementen beliebige Attribute und der
Wert ausgelesen und bearbeitet werden. Es wäre also beispielweise möglich, die Adresse eines
Verweises zu überprüfen. Um so eine Methode selbst zu schreiben, muss man die
AssertInterface.java implementieren.
Das vordefinierte Abgleichen ist das Abgleichen auf Gleichheit von Elementwerten. Falls es sich um
ein HTML Element handelt das keinen Wert besitzt, wird im Normalfall keine Kontrolle ausgeführt.
7.5.1.1 Technische Beschreibung
Name der Schnittstelle:
public interface AssertInterface
Methode(n):
public void controlHtmlElement(AssertObject currentObject, A
AssertObject expectedObject, Hashtable args) throws Exception;
Die Methode hat drei Argumente:
•
currentObject: hier wird das IST Objekt aus der HTML Seite an die Methode übergeben.
•
expectedObject: dieses ist das SOLL Objekt, das in der XML Datei definiert wurde.
•
args: sind weitere Argumente, die beim Abgleichen übergeben werden können. Diese können
auch in der XML Datei gesetzt werden in Form von <argument> Tags.
Die Klasse AssertObject gehört zur Assertschnittstelle und dient der Vereinfachung des Abfragens
der Elementwerte und Attributwerte.
Name der Klasse:
public class AssertObject
Methode(n):
public String getAttributeValue(String attributeName);
Die Methode getAttributeValue() sorgt dafür, dass der Wert von einem beliebigen Attribut abgefragt
werden kann. Falls das Attribut nicht existiert, wird eine leere Zeichenkette zurückgeliefert. Beispiel:
<a href=“www.irgendwo.com“></a>
public String getText();
Die Methode getText() ermöglicht es, den Wert eines Elements abzufragen. Der Wert ist der Text
zwischen den schließenden und öffnenden Klammern des selben Elements. Beispiel: <a>Link</a>
public Vector getOptions();
Die Methode gibt alle Optionen zum Elementtyp namens <select> zurück. Die Optionen werden in
einem Vektor gesammelt. Ihre Werte können dann völlig normal über die zwei vorher vorgestellten
- 67 -
Kapitel 7 : Umsetzung Testausführer
Methoden abgefragt werden.
7.5.1.2 Beispiel
In dem Beispiel wird überprüft, ob es sich um eine gültige deutsche Postleitzahl handelt. Die Zahl
wurde dabei in einem Textfeld namens plz angegeben.
Die Postleitzahl wird hierbei als gültig definiert, falls:
1. Sie fünfstellig ist.
2. Sie nur die Ziffern 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 enthält.
Ausschnitt aus der XML Definition:
<assert classname="parser.allocator.assert.AssertIstGueltigPLZ">
<argument name=“land“>DE</argument>
<inputText name=“plz“/>
</assert>
Die implementierende Klasse:
package parser.allocator.assert;
import java.util.Hashtable;
import junit.framework.TestCase;
public class AssertIstGueltigPLZ implements AssertInterface {
public void controlHtmlElement(AssertObject currentObject, AssertObject
expectedObject, Hashtable args) throws Exception {
String currentPLZ= currentObject.getAttributeValue("value");
String land = (String)args.get("land");
if(land.equalsIgnoreCase("DE")){
pruefeDeutschePLZ(currentPLZ);
}
}
private void pruefeDeutschePLZ(String currentPLZ) {
String plzZeichen = "0123456789";
// PLZ ist fünfstellig
if(currentPLZ.length()!=5){
TestCase.fail("PLZ muss fuenfstellig sein.");
}
// PLZ erhält nur die Ziffern 0,1,2,3,4,5,6,7,8,9
for(int i=0; i<currentPLZ.length(); i++){
String aktuellerZiffer = currentPLZ.substring(i,i+1);
int index = plzZeichen.indexOf(aktuellerZiffer);
- 68 -
Kapitel 7 : Umsetzung Testausführer
if(index<0){
TestCase.fail("PLZ darf nur Zahlen erhalten.");
}
}
}
}
7.5.2 Massentest
Die Schnittstelle Massentest erlaubt es, eigene Eingabequellen mit eigenen Formaten für die
Ausführung von Massendaten zu haben. Diese Eingabequelle kann eine beliebige Datei beispielweise
XML, HTML, TEXT usw. sein, aber auch Datenbanken, Tabellen oder ein Zufallsgenerator etc. Es
wäre also möglich, die Daten für die Massentests direkt aus der Spezifikation bzw. aus der
Datenbank zu lesen.
Nötig dafür ist lediglich das Implementieren der Schnittstelle RepeatInterface, das diese
Eingabequelle für den internen Ablauf datensatzweise weitergibt.
7.5.2.1 Technische Beschreibung
Name der Schnittstelle:
public interface RepeatInterface
Methode(n):
public void setUp(Hashtable args) throws Exception;
Die Methode setUp() ist eine allgemeine Methode, die es ermöglicht ein Initalisieren durchzuführen,
ehe der erste Datensatz gelesen wird. Beispielsweise kann man hier die Verbindung zur Datenbank
herstellen oder die Datei öffnen, aus der die Daten gelesen werden sollen.
public boolean hasNext() throws Exception;
Die Methode hasNext() zeigt an, ob noch weitere Datensätze zum Lesen und Weiterreichen für den
Testausführer da sind. Sie dient also zur Steuerung des Lese- und Weiterreichungsvorgangs.
Falls true, wird der nächste Datensatz mit der Methode next() gelesen und weitergereicht.
Falls false, wird das Massentest beendet, und die Methode tearDown() aufgerufen.
public Hashtable next() throws Exception;
Die Methode next() ist verantwortlich für das Lesen und die entspechende Konvertierung des
nächsten Datensatzes.
public void tearDown() throws Exception;
Die Methode tearDown() ist das Gegenstück zur setUp() Methode. Diese wird ausgeführt nachdem
alle Datensätze gelesen und weitergereicht wurden. Eine mögliche Anwendung der Methode wäre
zum Beispiel das Schließen der Datenbankverbindung bzw. der Datei.
- 69 -
Kapitel 7 : Umsetzung Testausführer
7.5.2.2 Beispiel
In diesem Beispiel werden die Massendaten in einer Textdatei gehalten. Der Pfad zu dieser Datei
wird als Argument mit den Namen filename übergeben. Das Format der Datei muss folgende
Konventionen haben:
$Variablenname0=Variablenwert0; $Variablenname1=Variablenwert1; usw.
•
Die Textdatei:
$vorname=Tekla; $zuname=Kiss; $text=Wie geht es denn so ?????
$vorname=Alexander; $zuname=Grahl; $text=Danke, danke, ...
•
Ausschnitt aus der XML Definition:
<repeat classname="parser.allocator.masstest.MyRepeat">
<argument name="filename">C:/tekla/test/MyFile.txt</argument>
<step id="1">
<input>
<form/>
<inputText name="vorname" value="$vorname"/>
<inputText name="zuname" value="$zuname"/>
<textarea name="Text">$text</textarea>
<inputSubmit id="submit"/>
</input>
<output>
<message>JSP</message>
</output>
</step>
<prepare>
<step>
<input>
<a>Startseite</a>
</input>
<output>
<a>InputResetSubmit</a>
</output>
</step>
<step>
<input>
<a>InputResetSubmit</a>
</input>
<output>
</output>
</step>
</prepare>
</repeat>
•
Die implementierende Klasse:
- 70 -
Kapitel 7 : Umsetzung Testausführer
import
import
import
import
import
java.io.BufferedReader;
java.io.File;
java.io.FileReader;
java.io.IOException;
java.util.Hashtable;
public class MyRepeat implements RepeatInterface {
private String line = "___";
private BufferedReader fin = null;
private int i=0;
public void setUp(Hashtable args) throws Exception {
String filename = (String) args.get("filename");
File file = new File(filename);
System.out.println("file: "+file);
FileReader reader = new FileReader(file);
System.out.println("Reader erstellt!");
fin = new BufferedReader(reader);
line = fin.readLine();
}
public boolean hasNext() {
boolean res = false;
if(line!=null){
res = true;
}
return res;
}
public Hashtable next() throws IOException{
System.out.println("File String at "+i+" !\n"+line);
Hashtable hash = new Hashtable();
createVariables(line,hash);
i++;
line = fin.readLine();
return hash;
}
private void createVariables(String line, Hashtable hash) {
if(line!=null && !line.trim().equals("")){
if(line.indexOf("$")>=0){
- 71 -
Kapitel 7 : Umsetzung Testausführer
int indexEqual = line.indexOf("=");
String variableName = line.substring(0,indexEqual).trim
();
int indexEnd = line.indexOf(";");
if(indexEnd<0){
String variableValue = line.substring
(indexEqual+1).trim();
hash.put(variableName,variableValue);
createVariables("",hash);
}
else{
String variableValue = line.substring
(indexEqual+1,indexEnd).trim();
hash.put(variableName,variableValue);
String recLine = line.substring(indexEnd+1);
createVariables(recLine,hash);
}
}
}
}
public void tearDown() throws IOException {
fin.close();
fin = null;
}
}
7.5.3 Logger
Diese Schnittstelle wird nicht mit Java Programmen angesteuert, wie die zwei davor diskutierten. Bei
der Software wurde das Loggen mit LOG4J realisiert [Log4j04]. Hier wird die Möglichkeit geboten,
eigene Logger für den Testausführer in Form von Java Properties Dateien zu definieren.
7.5.3.1 Technische Beschreibung
Eine Beschreibung dafür, wie Logger in so einer Form beschrieben werden können, findet man in
[Sin01].
7.5.3.2 Beispiel
Ein Logger, der alles in ein HTML Dokument schreibt unter den Pfad c:/tekla/test/test.html.
Ausgegeben werden nur die Logeinträge, die mindestens auf der Stufe INFO stehen.
•
Der HTML Logger, als .properties Datei
log4j.logger.htmlLogger= INFO, htmlLoggerAppender
log4j.appender.htmlLoggerAppender=org.apache.log4j.RollingFileAppender
log4j.appender.htmlLoggerAppender.layout=org.apache.log4j.HTMLLayout
log4j.appender.htmlLoggerAppender.Append=false
- 72 -
Kapitel 7 : Umsetzung Testausführer
log4j.appender.htmlLoggerAppender.File=C:/tekla/test/test.html
- 73 -
Kapitel 8 : Umsetzung Plugin
8 Umsetzung Plugin
In diesem Kapitel wollen wir uns näher mit der Umsetzung des Plugins beschäftigen. Dazu werden
wir zuerst einen Überblick über die grobe Gesamtarchitektur des Plugins geben und das
Zusammenspiel der einzelnen Komponenten betrachten. Dabei werden wir auch genauer auf den
internen Aufbau der einzelnen Plugins eingehen. Kurz werden wir auch auf die Funktion von
"Features" und die "Update Site" eingehen, da sie es vereinfachen, Plugins bereitzustellen und zu
installieren.
8.1 Architektur
Wir wollen nun auf die grobe Architektur des Plugins eingehen. Eine visuelle Übersicht des Aufbaus
des Plugins ist in Abbildung 24 zu sehen. Ein wichtiger Aspekt der Architektur des Plugins ist, dass
es völlig getrennt vom Testausführer ist. Dies ermöglicht auch ohne das Plugin Tests auszuführen.
Eclipse
WebTest Feature
Help Plugin
UI Plugin
Editor Plugin
Core Plugin
Testausführer
Abbildung 24 Architektur WebTest Plugin
Der Testausführer bietet hierfür eine Schnittstelle die auch vom Plugin genutzt wird. Somit könnte
der Testausführer auch in anderen Umgebungen genutzt werden.
Das Plugin an sich kann nur in der Eclipse Umgebung ausgeführt werden. Es wurde hierzu in einem
- 74 -
Kapitel 8 : Umsetzung Plugin
sogenannten Feature zusammengefasst. Dieses bündelt die einzelnen Plugin-Teile und lässt sie nach
außen als ein Plugin erscheinen. Eine genauere Erklärung wird im folgenden Abschnitt gegeben.
Das Plugin an sich wurde zwecks besserer Übersicht und Wartbarkeit in vier Pluginteile gegliedert.
Die einzelnen Teile stehen dabei in einer gewissen Abhängigkeit, wie Abbildung 24 zeigen soll.
Das Core Plugin stellt gewisse Grundfunktionalitäten zur Verfügung, die von den darüberliegenden
Plugins, dem UI Plugin und dem Editor Plugin, genutzt werden. Das UI Plugin realisiert allgemeine
Oberflächenelemente und Funktionen. Dazu gehören z.B. Navigatorenansichten oder Menüeinträge
zum Ausfühen der Tests. Das Editor Plugin beinhaltet alles, was zur Oberfläche und Funktionalität
der Editoren gebraucht wird. Das sind die Editoren an sich, aber auch z.B. Seiten zum Konfigurieren
der Editoren oder zum Darstellen der Eigenschaften von selektierten Elementen in den Editoren.
Das Help Plugin beinhaltet alle Hilfe-Dateien und stellt diese dem UI Plugin und dem Editor Plugin
zur Verfügung. Diese Plugins verweisen dann über die Kontexthilfe auf die entsprechenden Kapitel,
welche dann im Helpbrowser von Eclipse geöffnet werden. Da alle Hilfedateien an einem Ort
gebündelt liegen, ist ein einfaches Bearbeiten und Pflegen dieser möglich. Zusätzlich wird dadurch
auch die Übersetzung der Hilfedateien in mehrere Sprachen und das Bereitstellen von
Mehrsprachlichkeit in der Anwendung erleichtert.
8.2 Plugin Struktur
Nachdem wir nun einen groben Überblick über die Struktur des Plugins haben, wollen wir im
folgenden Abschnitt näher auf die einzelnen Plugin-Teile eingehen. Dabei werden wir am Ende des
Abschnittes auch kurz den Installationsprozess des Plugins in Eclipse über eine Update Site
betrachten.
Die Trennung der Plugin-Teile wurde durch ihre Funktion bestimmt. Dadurch soll eine bessere
Übersicht im Code erreicht und die Wartbarkeit bzw. Programmierung vereinfacht werden.
Zusätzlich wird es ermöglicht, auch im Funktionsumfang eingeschränkte Versionen des Plugins
bereitzustellen. Dies könnte z.B. eine Version sein, die nur das Ausführen und Auswerten der Tests
über Eclipse zuläßt. Des Weiteren können so leicht zusätzliche Funktionen in eigenständigen Plugins
hinzugefügt werden. Ein zusätzliches Plugin könnte z.B. die Testgenerierung an der vorhandenen
Webanwendung realisieren. Die nachträgliche Installation solch eines Plugins ist durch die Eclipse
Umgebung leicht möglich.
8.2.1 Feature
Bevor wir auf die einzelnen Plugin-Teile eingehen, wollen wir kurz die Funktion und den Aufbau des
Features erläutern. Der Feature-Mechanismus in Eclipse soll dabei primär drei Funktionen erfüllen.
1. Neue Funktionalität in Eclipse installieren
2. Das Aktualisieren von bereits vorhandenen Plugins
3. Kontrollieren, welche Plugins beim Start von Eclipse vorhanden sind
Es wäre zwar möglich die Plugins dem Anwender als ZIP-Archive bereitzustellen, welche er in das
Plugin-Verzeichnis von Eclipse entpacken müsste; durch den Feature Mechanismus kann aber eine
kontrolliertere Installation erfolgen. Der Update-Manager in Eclipse verwendet Feature
Beschreibungen z.B. um festzustellen, dass alle benötigten Plugins vorhanden sind. Nur wenn die
definierten Vorbedingungen erfüllt sind, lässt er eine Installation zu. Auch das nachträgliche
- 75 -
Kapitel 8 : Umsetzung Plugin
Installieren von zusätzlichen Plugins bzw. von Aktualisierungen wird durch Features und den Update
Manager vereinfacht; gerade dadurch können Fehlerkorrekturen schnell und effektiv verteilt werden.
Bei uns wird das Feature momentan nur zum Bündeln der Plugins und zum vereinfachten Installieren
in Eclipse verwendet (s.a. Abbildung 25). Dabei stellt es sicher, dass bei der Installation alle
benötigten Plugins der Eclipse Plattform vorhanden sind. Nur dann wird eine Installation unserer
Anwendung zugelassen. Bei der Installation werden alle Plugin-Teile unserer Anwendung
Bisher
Feature
Nächste Version
Feature (primär)
Core
UI
Editor
Help
Core
UI
Help
Feature (optional)
Editor
Help
Feature (optional)
Online
Help
Abbildung 25 Verwendung von Features
heruntergeladen und automatisch im Plugin-Verzeichnis von Eclipse intalliert.
Bei späteren Versionen unserer Anwendung kann über eine feinere Gliederung des Features
nachgedacht werden. So könnte man bestimmte Teile in Unter-Features gruppieren und dann
optional installierbar machen. Dies würde es dem Anwender ermöglichen, nur die Teile installieren
zu lassen, die er momentan für seine Arbeit benötigt. Damit könnte einem Überladen der Anwendung
mit Funktionalität, wie man sie von anderen Softwareprodukten her kennt, entgegengewirkt werden.
Die Übersicht in Abbildung 25 soll hierbei als Beispiel für eine mögliche Aufteilung dienen.
8.2.2 Kern
Das Kern Plugin stellt Grundfunktionalität zum Verarbeiten von XML zur Verfügung. Er bietet eine
an die Bedürfnisse unserer Anwendung angepasste, vereinfachte Schnittstelle an, die es den anderen
Plugin-Teilen ermöglicht, schnell und effektiv auf XML zu arbeiten. Zusätzlich beinhaltet es zur Zeit
alle Bibliotheken, die von den anderen Plugins benötigt werden. Im Folgenden werden wir nun näher
die angebotene Funktionalität betrachten und die verwendeten Bibliotheken auflisten.
8.2.2.1 Modell
Das Modell stellt Klassen zur internen Verarbeitung zur Verfügung. Die Elemente der XML Dateien
werden dabei auf diese Klassen abgebildet. Die daraus erzeugte Struktur ermöglicht ein schnelles und
- 76 -
Kapitel 8 : Umsetzung Plugin
einfaches Navigieren auf den Elementen. Die Methoden getElementPath und
getElementByPath unterstützen dabei das Auffinden von bestimmten Elementen. Ersteres gibt
dabei den Pfad des Elementes vom Wurzelelement zurück, Letzteres ermöglicht es, ein Element
durch einen Pfad zu finden.
Zusätzlich stellt es Mechanismen bereit, die Änderungen an der Struktur jedem angemeldeten
Interessenten meldet. Dabei wird zwecks differenzierter Verarbeitung zwischen vier verschiedenen
Ereignissen unterschieden:
1. Attribut-Ereignisse, wenn sich der Wert eines Attributes geändert oder gelöscht wurde.
2. Kind-Ereignisse, wenn ein Kindelement entfernt oder hinzugefügt wurde.
3. Inhalt-Ereignisse, wenn sich der Inhalt eines Elementes ändert.
4. Modell-Ereignisse, wenn sich das Wurzelelement des Modells ändert.
Alle Interessenten melden sich dabei nicht direkt beim Element als Zuhörer an, sondern beim
Modell. Dieses erhält alle Nachrichten seiner Elemente und leitet sie an die Zuhörer weiter. Werden
neue Elemente in die Struktur eingefügt, melden sie sich automatisch am Modell an. Gleiches gilt
auch für das Löschen von Elementen; sie werden automatisch am Modell abgemeldet. Dies
vereinfacht es den Interessenten auf Änderungen zu reagieren, da sie sich nur am Modell anmelden
müssen. Ab da werden ihnen alle Änderungen mitgeteilt. Ein häufiges An- und Abmelden entfällt bei
ihnen. Durch die im Ereignis enthaltenen Informationen können die Interessenten dann feststellen, ob
dieses Ereignis für sie wichtig ist.
8.2.2.2 Parser
Der Parser stellt Klassen zum Überführen der XML Struktur in die zuvor genannte Objektstruktur
bereit. Dafür wird eine Instanz von Digester verwendet, die über entsprechende Regeln konfiguriert
wird. Die Regeln werden dabei dynamisch aus der DTD durch den RulesConfigurator
generiert und der Digester Instanz übergeben. Eine genauere Beschreibung des Regelmechanismus
von Digester ist unter [Dig04] zu finden.
Diese Vorgehensweise hat den Vorteil, dass kein Code angepasst werden muss, sollten sich
Änderungen an der DTD ergeben. Dies vereinfacht die Wartbarkeit der Anwendung und erleichtert
das spätere Einpflegen von Erweiterungen.
8.2.2.3 XML
In diesem Paket werden Klassen bereitgestellt die das einfache Validieren von XML Dateien gegen
DTDs ermöglichen. Dabei wird die interne Konfiguration des XML Parsers, die zum Validieren
nötig ist, nach außen versteckt. Anwendungen können so einfach und schnell überprüfen lassen, ob
der momentane XML Text den DTDs der Anwendung gerecht wird und auf Fehlermeldungen durch
das Validieren entsprechend reagieren.
Als XML Parser wird hierfür der SAX Parser des Xerces von Apache verwendet, da dieser auch von
Digester benötigt wird. Da wir in unserer Anwendung keine parallelen Abläufe haben, was das
Verarbeiten von XML Strukturen angeht, brauchen wir nur eine Instanz des Parsers zu erzeugen. Ein
Verwalter regelt dabei das Erzeugen und Verteilen der Instanz in der Anwendung. Wird die Instanz
nicht mehr gebraucht, wird sie automatisch durch den Verwalter entsorgt. Dies verringert den
Speicheraufwand und verbessert die Geschwindigkeit unserer Anwendung.
- 77 -
Kapitel 8 : Umsetzung Plugin
8.2.2.4 DTD
Hier befinden sich die DTDs, welche die Struktur unserer XML Dateien beschreiben. Zusätzlich gibt
es Klassen, die das Verarbeiten der DTDs vereinfachen und so die Informationen, die in ihnen
enthalten sind, bereitstellen. Diese Informationen werden z.B. vom Parser zum Generieren der
Regeln benötigt. Auch die Quellcode-Editoren benötigen diese Informationen zum Bereitstellen der
Codevervollständigung und Kontexthilfe.
<!-- #host Host address of the server, where your webapplication
is running. Has to be set in every collection. Yet the
parent value is not accessible. -->
<!ELEMENT host EMPTY>
<!-- #[email protected] Networkaddress of the server. Example:
"http://www.myserver.com" If your server is running on a different
port than the default port, attach the port to the address with ":".
Example: "http://www.myserver.com:8080". -->
<!ATTLIST host
address CDATA #REQUIRED>
Listing 5 DTD Kommentar Beispiel
Die Texte der Kontexthilfe für die einzelnen Elemente und deren Attribute wurden von uns direkt,
als besonders gekennzeichnete Kommentare, in die einzelnen DTDs eingepflegt (ähnlich wie
JavaDoc Kommentare). Einen Auszug aus einer DTD mit enthaltenen Kommentaren sehen sie in
Listing 5. Dadurch wird die Pflege der Kontexthilfe vereinfacht, da bei Änderungen von Elementen
diese gleich mit angepasst werden kann. Ein Arbeiten über mehrere Dateien entfällt. Die
Kommentare werden vom DTD Parser extrahiert und den entsprechenden Elementen und Attributen
zugeordnet. Sie können dann leicht abgefragt und für Hilfen herangezogen werden.
Aus diesen Kommentaren könnte die DTD Dokumentation auch direkt erzeugt werden. Die dazu
nötigen Programme müssten allerdings noch implementiert werden.
8.2.2.5 Bibliotheken
In diesem Abschnitt wollen wir kurz klären, welche fremden Bibliotheken zu welchem Zweck bei
unserem Plugin eingesetzt werden.
Digester
Digester wird benutzt, um die XML Elemente auf entsprechende Klassen abzubilden. Dabei werden
folgende Bibliotheken verwendet:
Hauptbibliothek
org.apache.commons.digester
Ermöglicht das einfache Abbilden von XML Elementen und Attributen auf Java Klassen; wird über
Regeln konfiguriert. Intern wird eine native SAX Implementation zum Parsen von XML benötigt.
Bei uns wird zu diesem Zweck Xerces verwendet.
- 78 -
Kapitel 8 : Umsetzung Plugin
Zusätzliche Bibliotheken
org.apache.commons.beanutils
Stellt Methoden und Klassen bereit zum vereinfachten Holen und Setzen von Eigenschaftswerten auf
Java Klassen die der JavaBean Spezifikation entprechen; sowie zum dynamischen Definieren und
Zugreifen von Bean Eigenschaften.
org.apache.commons.collection
Verschiedene Klassen, die das Java Collection Framework erweitern.
org.apache.commons.logging
Einheitliche Schnittstelle zum Verwenden von verschiedenen Logging Implementationen.
Xerces
Xerces wird zum Validieren unserer XML Dokumente gegen die definierten DTDs verwendet. Des
Weiteren ist er der interne XML Parser, der vom Digester zum Verarbeiten der XML Dateien
benötigt wird.
Hauptbibliothek
org.apache.xerces
Stellt konkrete Implementationen von SAX und DOM Parser zu Verfügung. Diese können über die
allgemeinen SAX und DOM Schnittstellen angesprochen werden. Es können aber auch die
erweiterten Schnittstellen von Xerces verwendet werden. Das bietet sich vor allem dann an, wenn
eine genauere Konfiguration des Parsers nötig ist.
DTD Parser
Zum Verarbeiteten der DTD Informationen wird ein DTD Parser verwendet. Dieser überführt die
Informationen der DTD in eine interne Objektstruktur. Wir verwenden diese Struktur, um unser
eigenes Objektmodell der DTD zu erstellen. Von diesem können dann über eine einfache
Schnittstelle Informationen über die Elemente und ihre Abhängigkeiten abgefragt werden. Zusätzlich
stellt es die Dokumentation der Elemente, die im Abschnitt "DTD" S. 78 eingeführt wurde, zur
Verfügung.
Hauptbibliothek
com.wutka.dtd
Erzeugt aus einer DTD eine interne Objektstruktur. Über eine Schnittstelle können Informationen
über den Aufbau abgefragt werden. Ein Bearbeiten der internen Objektstruktur ist auch möglich. Die
geänderte Struktur kann wieder als DTD ausgeschrieben werden.
Log4j
Wird vom Plugin momentan nur zum Unterdrücken der Konsolen Logging Einträge von Digester
und anderen Bibliotheken genutzt. Dazu wird der Logger einmalig durch eine Properties Datei
konfiguriert. Die Datei ist unter com.webtest.core.log4j.properties zu finden. In ihr
werden alle Logger deaktiviert.
- 79 -
Kapitel 8 : Umsetzung Plugin
Hauptbibliothek
org.apache.log4j
Stellt eine Schnittstelle zum einfachen Integrieren von Logging in eine Anwendung zur Verfügung.
Die Ausgaben des Loggers können dabei priorisiert und in beliebige Ausgabemedien gelenkt werden.
Für zusätzliche Literatur siehe [Log4j04].
8.2.3 Allgemeine Oberfläche
Mit dem UI Plugin (s.a. Abbildung 24 Seite 74) werden alle allgemeinen Oberflächenelemente in
Eclipse realisiert, die nichts direkt mit den Editoren zu tun haben. Dazu gehören Dialoge zum
Einstellen von Konfigurationen, Menüeinträge zum Starten des Testausführers oder auch angepasste
Ansichten zum Navigieren. Eine genauere Übersicht über alle Teile geben wir in den folgenden
Abschnitten. Da die einzelnen Elemente unseres Plugins auf Erweiterungspunkte von Eclipse
aufbauen, werden wir auch die dazugehörigen Erweiterungspunkte kurz näher erklären.
8.2.3.1 Perspektiven
Eine Perspektive ermöglicht das Zusammenfassen mehrer Ansichten im Eclipse Hauptfenster.
Dadurch kann der Anwender schnell zwischen z.B. einer Java Perspektive zum Bearbeiten der JavaKlassen und der Debug Perspektive zum Ausführen der Programme hin- und herschalten. Ein
Überladen des Sichtbereiches mit Fenstern wird hierdurch vermieden und zusammengehörige
Ansichten können so leicht gruppiert werden. Zusätzlich lassen sich auch einzelne Menüs in der
Hauptmenüleiste und den Kontextmenüs individuell anpassen. So kann erreicht werden, dass im
Menüpunkt "New" z.B. nur Datei- und Projektwizards angeboten werden, die zum momentanen
Arbeitsfeld passen. Dem Benutzer ist es jedoch immer erlaubt die Perspektiven nach seinen
persönlichen Wünschen anzupassen.
Zum Einbringen unserer eigenen Perspektive nutzen wir den Erweiterungspunkt
org.eclipse.ui.perspectives. Durch die vom Erweiterungspunkt benötigte Klasse können
wir dann das initial Layout unsere Perspektive festlegen. Bei uns ist dies die Klasse
com.webtest.ui.perspective.PerspectiveFactory. Sie legt das in Abbildung 26 zu
sehende Layout fest. Da wir den Erweiterungspunkt von Eclipse verwendet haben, können nun auch
andere Plugins durch den Erweiterungspunkt org.eclipse.ui.perpectiveExtension
unsere Perspektive durch Elemente und Menüeintrage erweitern.
- 80 -
Kapitel 8 : Umsetzung Plugin
WebTest Navigator
Editor Area
Outline
Task View / Properties View
Abbildung 26 WebTest initial Perspektive
Dies wird auch schon vom Plugin selbst genutzt, das noch die folgende Menüeinträge der
Perspektive hinzufügt:
•
Menü "New"
New WebTest Project
New Folder
New File
•
Menü "Show View"
Outline
Properties
Task
WebTest Navigator
Andere Plugins können, unter Verwendung des org.eclipse.ui.perspectiveExtension
und unserer Id der Perspektive, diese nun auch leicht durch eigene Menüeinträge und Ansichten
erweitern.
8.2.3.2 Wizards
Wizards sollen den Anwender bei der Neuanlage von Ressourcen unterstützen. Das UI Plugin stellt
einen neuen Wizard zur Verfügung, der es ermöglicht, ein neues WebTest Projekt anzulegen. Wir
verwenden dabei den Erweiterungspunkt org.eclipse.ui.newWizards von Eclipse. Der
Wizard an sich wird durch die Klasse com.webtest.ui.wizard.NewProjectWizard
realisiert; sie implementiert die vom Erweiterungspunkt erwartete Schnittstelle.
Als zusätzliche Informationen können wir im Erweiterungspunkt festlegen, welcher Kategorie der
Wizard zugeordnet sein soll und welche Perspektive nach erfolgreichem Beenden des Wizards
geöffnet werden soll. In unserem Fall wäre die Kategorie com.webtest.wizard.new mit
- 81 -
Kapitel 8 : Umsetzung Plugin
Namen "WebTest". Alle anderen Wizards unseres Plugins, die neue Ressourcen erzeugen, sollten
sich auch in diese Kategorie einordnen. Als Standardperspektive nach erfolgreichem Beenden des
Wizards, geben wir die im vorherigen Abschnitt erklärte Perspektive an.
Nach Beenden des Wizards wird ein neues Projekt mit dem vom Anwender festegelegten Namen im
Workspace angelegt. Der Wizard fügt diesem noch automatisch eine von uns angegebene Nature (s.
Seite 83) hinzu und kennzeichnet dadurch das Projekt als WebTest Projekt.
8.2.3.3 Präferenzen
Präferenzen dienen dazu, es dem Anwender zu ermöglichen, das Verhalten oder Aussehen des
Werkzeugs durch bestimmte Schalter und Eingaben anzupassen. Im UI Plugin gibt es noch keine
Einstellmöglichkeiten, es legt lediglich die Kategorie fest, in der andere Plugin Teile ihre
Präferenzseiten abzulegen haben.
Abbildung 27 UI Plugin: Präferenzseite
Der Erweiterungspunkt der hierzu genutzt wird, ist org.eclipse.ui.preferencePages. Er
ermöglicht es Präferenzseiten anzugeben, die dem Anwender im Präferenzdialog angezeigt werden.
Wie zuvor erwähnt, implementiert das UI Plugin nur eine leere Präferenzseite mit keiner Funktion.
Es legt damit die Kategorie fest, in der die anderen Plugins ihre Seiten abzulegen haben. In
Abbildung 27 ist die leere Seite des UI Plugins zu erkennen. Darunter wurde durch einen anderen
Pluginteil eine neue Seite eingefügt. Dadurch wird eine Gruppierung der Seiten erreicht, was es dem
Anwender erleichtert, die zum Werkzeug gehörenden Einstellungen zu Finden und zu Bearbeiten.
8.2.3.4 Actions
Hinter Actions verbergen sich Aktionen, die ausgeführt werden, wenn der Anwender einen
entsprechenden Eintrag aus einem Menü wählt. Sie werden nicht direkt in der Oberfläche dargestellt.
In der Oberfläche werden zuerst Platzhalterobjekte (Proxyobjekte) für die entsprechenden Actions
angezeigt. Erst wenn der Anwender einen Menüeintrag auswählt, wird die konkrete Action geladen
- 82 -
Kapitel 8 : Umsetzung Plugin
Vor Auswahl durch Anwender
Action
ExtensionPoint
ProxyAction
Klasse
Name
Icon
...
Nach Auswahl von Anwender
ProxyAction
Action
run()
Abbildung 28 Verwendung von Actions
und ausgeführt. Durch die Verwendung von Proxyobjekten kann das Laden des Plugins, zu dem die
Action gehört, verzögert und das Laufzeitverhalten verbessert werden.
Abbildung 28 soll das Verhalten bei Verwendung von Actions verdeutlichen. Die Informationen zum
Darstellen der Action werden aus der XML Beschreibung des Plugins entnommen. Dort sind alle
wichtigen Informationen aufgeführt, wie z.B. Menüname, Icon, für welche Objekte die Action
angezeigt werden soll und die Klasse, die die Action implementiert. Aus diesen Informationen wird
beim Aufruf des Menüs die Proxyaction erzeugt. Erst nach Auswahl durch den Anwender wird das
konkrete Actionobjekt geladen und somit auch das Plugin, das diese eingefügt hat. Das Proxyobjekt
leitet dabei alle Informationen an die Action weiter. Dies betrifft Information, wie z.B. wo wurde die
Action aufgerufen oder welche Objekte sind selektiert.
Momentan beinhaltet unser Plugin nur eine Action zum Ausführen von Testsammlungen.
Implementiert ist sie in der Klasse com.webtest.ui.action.RunCollectionAction. In
der run-Methode dieser Klasse wird der Testausführer aufgerufen. Er bekommt dabei als Argumente
das momentane Arbeitsverzeichnis als absoluten Pfad übergeben, sowie den relativen Pfad zur
Testsammlung von diesem Arbeitsverzeichnis; nach Beendigung des Testlaufes gibt er die
gesammelten Fehlermeldungen zurück.
Die Action kann über das Kontextmenü jeder Navigatoransicht, die von
org.eclipse.ui.views.navigator.ResourceNavigator geerbt hat und den
Projektinhalt darstellt, aufgerufen werden. Der Menüpunkt ist jedoch nur sichtbar, wenn genau eine
Testsammlung im Navigator durch den Anwender selektiert wurde (s. a. Abbildung 30).
8.2.3.5 Nature
Projekten im Workspace von Eclipse wird über Natures ein Verhalten und Funktionen zugeordnet.
Durch ein Nature spezifisches Projekticon wird dem Anwender gezeigt, dass eine Nature aktiv ist.
Dabei kann ein Projekt mehrere Natures besitzen, allerdings wird nur das Icon der ersten als
Projekticon verwendet.
- 83 -
Kapitel 8 : Umsetzung Plugin
Abbildung 29 Verwendung
von Natures
Bei uns wird eine Nature bisher nur zum Kennzeichnen des Projektes als WebTest Projekt verwendet
(s.a. Abbildung 29); zusätzliche Funktion wurde noch nicht implementiert. Das Konzept der Nature
wurde aus zwei Gründen verwendet. Erstens sollte ein WebTest Projekt leicht als solches in der
Eclipse Oberfläche kenntlich sein, zweitens wird ein späteres Erweitern des Plugins erleichtert.
<extension
point="org.eclipse.ui.projectNatureImages">
<image
icon="icons/webtest_project.gif"
natureId="com.webtest.nature.project"
id="com.webtest.nature.project.image">
</image>
</extension>
Listing 6 Erweiterungspunkt Nature Icon
Neue Natures werden in Eclipse über den Erweiterungspunkt
org.eclipse.core.resources.natures erstellt. Dieser Erweiterungspunkt erfordert das
Angeben einer Klasse, die die Nature Schnittstelle implementiert. Bei uns ist dies die Klasse
com.webtest.ui.nature.ProjectNature. Sie stellt die geforderte Schnittstelle zur
Verfügung, implementiert jedoch noch keinen Code darin. Das Icon wird durch den
Erweiterungspunkt org.eclipse.ui.projectNatureImages festgelegt. Als Parameter
erhält es die Id unserer Nature Erweiterung sowie das Icon, das verwendet werden soll. Den
verwendeten XML-Kode können sie in Listing 6 sehen.
8.2.3.6 Ansichten
Ansichten dienen der strukturierten Darstellung von Informationen. Im UI Plugin wurde eine
zusätzliche Ansicht zum Navigieren auf den Projektdaten eingeführt. Zu diesem Zweck wird der
Erweiterununkt org.eclipse.ui.views verwendet. Bei diesem Erweiterungspunkt muss eine
Klasse angegeben werden, die die Schnittstelle org.eclipse.ui.IViewPart implementiert.
Dies realisert bei uns die Klasse com.webtest.view.WebTestNavigator. Die Ansicht
wurde zwecks späterer Erweiterungen schon eingefügt, beherbergt allerdings noch keine
- 84 -
Kapitel 8 : Umsetzung Plugin
Funktionalität. Das momentane Aussehen der Ansicht ist in Abbildung 30 zu sehen.
Abbildung 30 Ansicht WebTest
Navigator
8.2.4 Editoren
Editoren sollen das einfache Bearbeiten der Testfälle, Sammlungen und Module ermöglichen. Für
jede der drei Dateiarten steht ein Editor mit spezifischen bzw. gemeinsamen Funktionen und
Ansichten zur Verfügung.
- 85 -
Kapitel 8 : Umsetzung Plugin
Abbildung 31 Editor: Testsammlung
Die Editoren sind als Multipage Editoren realisiert, d.h. es gibt mehrere Ansichten und
Möglichkeiten, die Daten zu bearbeiten. Die einzelnen Ansichten sind dabei auf Registerkarten
verteilt. In Abbildung 31 ist der Editor zum Bearbeiten von Testsammlungen zu sehen. Er besitzt vier
Registerkarten Configuration, Collection, Overview und Source. Die Ansichten
Overview und Source kommen in jedem Editor vor.
Um die Editoren in Eclipse einzufügen wird der Erweiterungspunkt org.eclipse.ui.editors
verwendet. Dort muss eine Klasse angegeben werden, die den Editor realisiert und eine, die das
Aktivieren und Deaktivieren von editorspezifischen Menüeinträgen regelt. Letzteres ist nötig, da sich
alle Editoren eine gemeinsame Menüleiste in Eclipse teilen und dort die Menüeinträge des momentan
aktiven Editors angezeigt werden.
Da all unsere Editoren die Ansichten Overview und Source besitzen, wurden diese in einer
zentralen, abstrakten Klasse realisiert. Von dieser Klasse erben alle konkreten Implementierungen
und fügen ihr charakteristisches Verhalten hinzu. Im Falle der Source Ansicht, die sozusagen ein
Editor im Editor darstellt, sind das DTD Daten für Codevervollständigung bzw. Kontrolle und
Hilfeverweise.
8.2.4.1 Quellcode Editor
Der Quellkode Editor befindet sich in jedem unserer Editoren in der letzten Registerkarte rechts. Er
ermöglicht es, die Daten im XML Format direkt zu editieren, bietet aber dennoch dem Anwender
- 86 -
Kapitel 8 : Umsetzung Plugin
Abbildung 32 Editor: Testsammlung Quellkode
durch Kodevervollständigung, Syntaxhilfe und Syntaxhighlighting mehr als ein reiner Texteditor. In
Abbildung 32 sehen sie den Quellkode Editor der Testsammlung.
Vor allem die Codevervollständigung ist sehr hilfreich, da sie neben den zulässigen bzw. möglichen
Elementen, zu jedem Element einen kurzen Hilfetext anzeigt. Dies erspart es dem Anwender, bei
jedem Element in der Referenz nachzulesen, welche Aufgabe es hat. Ein Beispiel für die
Verwendung der Codevervollständigung sehen sie in Abbildung 33. Im linken, gelben Fenster sind
alle möglichen Elemente aufgezählt, die im Element output erlaubt sind. Im rechten wird zu dem
momentan ausgewählten Element message ein kurzer Hilfetext angezeigt.
Um die Codevervollständigung und Hilfetexte leicht warten bzw. erweitern zu können, werden diese
dynamisch aus der DTD Beschreibung generiert. Es müssen also keine Änderungen am Kode
gemacht werden, um z.B. neue Elemente oder Attribute einzuführen. Die angezeigten Hilfetexte
werden direkt in der DTD als Kommentare definiert (s.a. DTD Seite 78).
- 87 -
Kapitel 8 : Umsetzung Plugin
Abbildung 33 Editor: Kodevervollständigung
Die Quellcode Editoren der verschiedenen XML Dateitypen müssen nur noch konfigurieren, welche
DTD sie zum Validieren verwenden. Ansonsten ist das Verhalten bei allen Quellcode Editoren
gleich. Die abstrakte Klasse com.webtest.editor.source.SourceEditor implementiert
alle Logik, die für die Verwendung von Codevervollständigung, Syntaxhighlighting und Hilfe
notwendig ist. Dadurch wird die Wartung und Implementierung vereinfacht und das Erstellen von
neuen Editoren, die auf anderen DTDs basieren, beschleunigt.
8.2.4.2 Übersicht
Abbildung 34 Editor: Übersichtsregisterkarte
Die Übersicht ist immer die vorletzte Registerkarte von rechts. Sie stellt den XML Inhalt der Datei in
einer Baumstruktur dar. Die Editoren können die Darstellung der einzelnen Einträge durch einen
eigenen sogenannten Labelprovider konfigurieren. In Abbildung 34 sehen wir die
Übersichtsseite des Editors für Testsammlungen. Um eine differenziertere Darstellung zu
ermöglichen, wurde hier statt des Standardlabelproviders
com.webtest.editor.multipage.DefaultModelLabelProvider eine erweiterte
Version dieses Providers verwendet. Über diesen werden für entsprechende Elemente andere Icons
angezeigt oder der Beschriftungstext angepasst. Durch diesen Aufbau wird eine Grunddarstellung der
- 88 -
Kapitel 8 : Umsetzung Plugin
Elemente gewährleistet, die aber durch Verwendung einer definierten Schnittstelle durch die Editoren
an ihre Bedürfnisse angepasst werden kann. Bei dem Editor für Testsammlungen geschieht dies
durch die Klasse
com.webtest.editor.collection.CollectionModelLabelProvider.
Zusätzlich zum Anzeigen der Elemente können diese in der Übersicht auch bearbeitet werden. Dazu
muss der Anwender ein Element durch Doppelklick auswählen. Es werden dann Informationen und
bearbeitbare Attribute und Inhalte des Elements in der Eigenschaftsanzeige dargestellt. Für eine
ausführlichere Erklärung siehe Abschnitt Eigenschaftenansicht auf Seite 89.
8.2.4.3 Zusätzliche
Möchten Editoren zusätzliche Seiten anbieten, so müssen sie diese erzeugen und als neue
Registerkarten einfügen. Im Falle des Editors für Testsammlungen wurden zwei neue Registerkarten
eingefügt.
Damit ein einheitliches Aussehen und Verhalten der Seiten erreicht wird, wurde die Klasse
com.webtest.editor.multipage.EditorPage implementiert. Sie legt ein
Grundverhalten fest und gibt vor, welche Methoden von den Editoren zum Erstellen der Seite
überschrieben bzw. Implementiert werden müssen.
Für eine bessere Übersicht wurde in den Seiten noch die Sektion eingefügt. Eine Sektion gruppiert
auf einer Seite nochmals zusammengehörige Elemente. Ein Beispiel hierfür sehen sie in Abbildung
31 auf Seite 86. Dort sind vier Sektionen zu erkennen Host, Library, Logger und HtmlTrace.
Diese Aufteilung dient nicht nur der besseren Übersicht des Anwenders, sondern spiegelt sich auch
in dem darunter liegenden Code wieder. Für jede angezeigte Sektion wird eine neue Klasse
implementiert, die ihr Verhalten enthält. Auch hier wurde wegen des gemeinsamen Grundverhaltens
und einheitlichen Aussehens eine abstrakte Klasse implementiert, von der alle Sektionen erben
müssen.
Durch den oben beschriebenen Aufbau können so leicht Änderungen am Layout vorgenommen
werden, ohne viel Code anpassen zu müssen, da sich zentrale Elemente des Lauyouts in wenigen
Klassen befinden.
8.2.4.4 Eigenschaftenansicht
Abbildung 35 Eigenschaftsanzeige
Die Eigenschaftsansicht ermöglicht es dem Anwender, Informationen über das ausgewählte Element
zu erlangen. Zusätzlich werden alle Attribute des Elementes mit ihrem Inhalt angezeigt, und können
vom Anwender geändert werden. In Abbildung 35 sehen wir die Eigenschaftsanzeige nach Auswahl
- 89 -
Kapitel 8 : Umsetzung Plugin
des htmltrace Elementes durch Doppelklick in der Übersicht.
Abbildung 36 Eigenschaftsanzeige: Listenfeld
Für die Anzeige der Daten in der Kategorie Info werden wieder dynamisch die Daten der DTD
herangezogen. Gleiches gilt auch für die Anzeige der Attribute in der Kategorie Attributes. Es
werden immer alle möglichen Attribute des Elementes angezeigt, auch die optionalen. Sollte das
Element auch einen Inhalt zwischen den Tags enthalten, so wird dieser in der Kategorie Content
mit der Eigenschaft Text angezeigt.
Der Anwender kann die Werte der Attribute in der Spalte Value bearbeiten. Für Attribute die nur
vordefinierte Werte annehmen können, wird ein Listenfeld angeboten. Die Werte dieses Listenfeldes
werden auch aus der DTD generiert. Abbildung 36 zeigt hierfür ein Beispiel.
Damit wird erreicht, dass die Anzeige der Elemente in der Eigenschaftsansicht leicht zu erweitern ist,
ohne dafür neuen Code implementieren zu müssen. Wie beim Quellkode Editor müssen die
Änderungen nur an der DTD vorgenommen werden.
8.2.4.5 Präferenzen
Über den Erweiterungspunkt org.eclipse.ui.preferencePages können neue
Eigenschaftsseiten zum Konfigurieren in den Eigenschaftsdialog von Eclipse eingefügt werden. Der
Anwender kann über diese bestimmtes Verhalten des Plugins an seine Bedürfnisse anpassen. Wie im
Abschnitt Präferenzen auf Seite 82 erklärt und in Abbildung 27 auf Seite 82 gezeigt, können die
Eigenschaftsseiten eines Plugins gruppiert werden und sind dadurch leichter vom Anwender einem
Werkzeug zuordbar.
Im Editor Plugin wird eine Eigenschaftsseite zum Konfigurieren des Syntaxhightlighting im
Quellcode Editor angeboten. Über diese kann der Anwender die Farben für die Codemarkierung
seinen Bedürfnissen anpassen. Als Kategorie wurde in der XML Definition des Erweiterungspunktes
die Eigenschaftsseite des UI Plugins angegeben. Die Seite erscheint hierdurch als Kindelement unter
der vom UI Plugin angegebenen Primärseite (s.a. Abbildung 27 auf Seite 82).
Der Code der Seite für die Anzeige wurde in der Klasse
com.webtest.editor.preference.SyntaxPreferencePage implementiert. Da die
Seite nur ein einfaches Verhalten aufweisen muss, erbt sie von einer von Eclipse bereitgestellten
abstrakten Klasse (org.eclipse.jface.preference.FieldEditorPreferencePage)
für das Darstellen von Eigenschaftsdialogen. Mit Hilfe dieser Klasse ist es schnell und einfach
möglich, Eigenschaftsseiten anzubieten und die Werte zu lesen und zu speichern.
8.2.4.6 Wizards
Das Editor Plugin stellt drei Wizards zur Verfügung. Sie ermöglichen das Anlegen von neuen
WebTest Dateien mit Hilfe von Templates. Dies stellt sicher, dass die vom Anwender erzeugten
- 90 -
Kapitel 8 : Umsetzung Plugin
Dateien die von uns erwartete Grundstruktur aufweisen und von den Editoren verstanden werden.
Da sich das Verhalten der Wizards sehr ähnelt, wurde eine abstrakte Klasse
com.webtest.editor.wizards.NewFileWizard implementiert, die das Grundverhalten
enthält. Die anderen Wizards erben von dieser und konfigurieren nur noch ihr Verhalten. Dabei
geben sie z.B. an, welche Dateierweiterung, welches Template und welchen Namen sie verwenden.
Dieser Aufbau ermöglicht ein leichtes Implementieren von neuen Wizards zum Erzeugen von
Dateien und vereinfacht das Warten des schon vorhandenen Codes.
Damit der Anwender leicht erkennen kann, zu welchem Plugin die Wizards gehören, wurden sie der
vom UI Plugin erstellten Kategorie "WebTest" untergeordnet.
8.2.5 Hilfe
Alle Dateien in denen Informationen für Hilfe enthalten sind, wurden in ein eigenes Plugin
ausgelagert und sind im Plugin com.webtest.help enthalten. Dadurch soll die Wartbarkeit der
Hilfedateien verbessert und das Verfügbarmachen von Mehrsprachigkeit vereinfacht werden.
Abbildung 37 WebTest Hilfe
Die Hilfe kann durch den in Eclipse enthalten Browser angesehen und durchsucht werden. In
Abbildung 37 ist die eingefügte Hilfe des WebTest Werkzeuges im Browser zu sehen. Die erste
Kapitelebene wurde zur besseren Übersicht geöffnet.
8.2.5.1 Struktur
Die Hilfe ist in zwei Teile geteilt. Zum einen gibt es die Dateien, die im Hilfebrowser angzeigt
werden, zum anderen Hilfeblöcke, die für die Kontexthilfe im Werkzeug benötigt werden. In den
zwei folgenden Abschnitten werden wir jeweils den Aufbau und ihre Verwendung näher betrachten.
HTML
Für den Hilfebrowser wird eine sogenannte Buchstruktur benötigt, die im linken Navigationsfenster
angezeigt wird (s.a. Abbildung 37). Diese legt den Aufbau der Kaptiel fest und wird in einer XML
- 91 -
Kapitel 8 : Umsetzung Plugin
Datei beschrieben. Aus dieser Struktur heraus wird auf die HTML Seiten verwiesen.
Ein Vorteil dieser Methode ist es, dass schon vorhandene Hilfen leicht integriert werden können und
die schon vorhandenen HTML Seiten nicht großartig angepasst werden müssen; so ist auch ein
nachträgliches Einhängen von Kapiteln in diese Struktur leicht möglich. Andere Plugins müssen dazu
nur ihre Hilfe an entsprechender Stelle in die bereits bestehende Kapitelstruktur einfügen. Das
Einfügen ist dabei bildlich gemeint, da sie ihre Dateien nicht in die Struktur kopieren, sondern nur
per Anker einhängen. Die Dateien an sich können an einer völlig anderen Stelle liegen. Dazu müssen
die Anker allerdings von der übergeordneten Hilfe schon vorgesehen sein.
<toc label="WebTest" topic="html/book.html">
<topic label="Overview" href="html/overview.html"/>
<topic label="User's Guide" href="html/users_guide/users_guide.html">
<link toc="toc_users_guide.xml"/>
</topic>
<topic label="Reference" href="html/reference/reference.html">
<link toc="toc_reference.xml"/>
</topic>
<topic label="Example's Guide" href="html/examples/examples_guide.html">
<link toc="toc_examples_guide.xml"/>
</topic>
<topic label="Questions Index" href="html/questions.html"/>
</toc>
Listing 7 Hauptbuch mit Kapiteleinträgen
Die in unserem Plugin definierte Kapitelstruktur ist in Listing 7 zu sehen. Dabei handelt es sich nur
um die Hauptkapitel. Die Unterkapitel sind zwecks besserer Übersicht in die Dateien
toc_users_guide.xml, toc_reference.xml und toc_examples_guide.xml
ausgelagert.
Kontext
Abbildung 38 Kontexthilfe im Editor
Kontexthilfen sind Hilfen, die kurze Hinweise und Verweise auf Kapitel in der Onlinehilfe geben.
Sie werden durch den Anwender bei drücken von F1 aufgerufen. Ein Beispiel für eine Kontexthilfe
sehen sie in Abbildung 38. Diese wird angezeigt, wenn der Anwender im Quellcodeeditor unseres
Plugins F1 drückt.
Was in der Kontexthilfe dargestellt wird, ist nicht direkt in die Elemente programmiert, sondern wird
über den Erweiterungspunkt org.eclipse.help.contexts realisiert. Elemente verweisen nur
- 92 -
Kapitel 8 : Umsetzung Plugin
<context id="editor_test">
<description>Help for use of the Test
Editor.</description>
<topic label="Test Editor"
href="html/users_guide/editor/test_editor.html"/>
<topic label="DTD - Test"
href="html/reference/dtd/dtd_test.html"/>
</context>
Listing 8 Kontexthilfe: Definition
durch eine eindeutige Id auf Hilfen, die in einer XML Datei definiert werden. Für die in Abbildung
38 gezeigte Hilfe würde ein Eintrag in dieser Datei, wie in Listing 8 aussehen.
Wie bei der Onlinehilfe hat dies den Vorteil, dass die Hilfen leichter zu warten sind und bei
Änderungen der Kapitelstruktur der Quellkode der Anwendung nicht angepasst werden muss. Ein
weiterer Vorteil ist, dass die Kontexthilfen nur einmal definiert werden müssen und ab dann an
mehreren Stellen verwendet werden können.
In unserem Plugin sind alle Kontexthilfen momentan im Plugin Teil com.webtest.help in der
Datei contexts.xml definiert. Da diese Datei mit wachsender Komplexität des Plugins immer
unübersichtlicher wird, sollte über eine Trennung der Datei in mehrere Teile nachgedacht werden.
8.2.6 Update Site
Die Update Site ermöglicht das Bereitstellen des Plugins. Alle Features die zu einem Plugin gehören,
können durch eine Update Site bereitgestellt werden. Zum Installieren des Plugins öffnet der
Anwender die Update Site im Update Manager. Dabei kann diese auf dem lokalen Rechner liegen
(z.B. auf der Festplatte oder CD-ROM) oder auf einem Web Server zur Verfügung stehen. Das
Bereitstellen dort kann auch in einem geschützten Verzeichnis erfolgen.
Über den Update Manager öffnet der Anwender dann die Site und wählt die zu installierenden
Features aus. Es werden automatisch alle Abhängigkeiten und Vorbedingungen geprüft und bei
Erfolg das Plugin heruntergeladen und installiert.
Nach einer Installation können über die Update Site auch Patches und neuere Versionen des Plugins
zur Verfügung gestellt werden. So kann der Anwender in regelmäßigen Abständen überprüfen, ob
Neuerungen oder Verbesserungen ausgegeben wurden und diese leicht nachinstallieren.
Momentan dient uns die Update Site nur zum Vereinfachen des Installationsprozesses. Dabei wird
über die Seite das Feature com.webtest.feature angeboten; in diesem ist das komplette Plugin
enthalten.
In einer späteren Version des Plugins soll eine differenziertere Installation über die Update Site
möglich sein, wie sie in Abbildung 25 auf Seite 76 gezeigt ist. Das Einbinden von zusätzlichen
Informationen, z.B. Installationsbeschreibung und Funktionsumfang in die Update Site ist auch
vorgesehen.
- 93 -
Kapitel 9 : Anwendungsbeispiel
9 Anwendungsbeispiel
Unsere Aufgabe war es zu zeigen, dass der entwickelte Prototyp bereits einsetzbar ist und die von
uns gesetzte Kriterien erfüllt.
9.1 Testumgebung
Das Anwendungsbeispiel basiert auf FlexiTRUST von der Firma FlexSecure. Diese ist eine
Trustcenter- Software, die mit Unterstützung von Professor Johannes Buchmann (TUD) entwickelt
wird. Die Software hat die Aufgabe, Zertifikate und digitale Schlüssel zu erstellen und zu verwalten.
Zu einer genaueren Beschreibung der Funktionsweise sei auf [FlexSec04] verwiesen.
Es standen sechs Formulare zur Verfügung, deren Funktionsweise getestet werden sollen. Diese
waren:
•
Mandant1001.Produktion.CA
•
Mandant1001.Produktion.Root
•
Mandant1001.Produktion.Softtoken
•
Mandant1001.Produktion.SSLServer
•
PKCS10.Produktion.CA
•
PKCS10.Produktion.Root
9.2 Teststruktur
Das Root Element ist die Testsammlung „flexsecure.wcx“. In diesem ist eine Testsammlung für
jedes zu testende Formular eingebunden. Die Dateien befinden sich jeweils im Ordner gleichen
Namens, und heißen folgend:
„Mandant1001.Produktion.CA.wcx“, „Mandant1001.Produktion.Root.wcx“,
„Mandant1001.Produktion.Softtoken.wcx“, „Mandant1001.Produktion.SSLServer.wcx“,
„PKCS10.Produktion.CA.wcx“ und „PKCS10.Produktion.Root.wcx“.
Getestet wurde mit der Funktionsabdeckung „black-box“ Testart. Dabei wurden die folgenden
Funktionalitäten (Testdateien jeweils enthalten in dem entsprechenden Ordner und eingefügt in der
dazugehörigen Testsammlungsdatei) behandelt:
•
Erfolgreicher Ablauf „testSuccessfulRun.wtx“
•
Abfangen von Fehlermeldungen
•
Doppelte Eingabe desselben CN Wertes „testDoubleCN.wtx“ (nur beim
Mandant1001.Produktion.CA und Mandant1001.Produktion.Root)
•
Nichtausfüllen von Pflichtfeldern „testRequiredFields.wtx“
•
Ungültige Eingabeformate „testInvalidInputs.wtx“
Es wurde dabei versucht nach Möglichkeit die Testdateien modular aufzubauen. Dieses kann man an
der Vielzahl der Moduldateien (mit der Endung .wcx) erkennen, die sich direkt unter dem
Projektordner bzw. in dem einzelnen Formularordner befinden. Ein Beispiel dafür ist das Modul
„EntryForm.wcx“, das den Vorgang beschreibt, wie das zu testende Formular erreicht werden soll.
- 94 -
Kapitel 9 : Anwendungsbeispiel
9.3 Testergebnis
Es sind alle definierte Testfälle erfolgreich durchgelaufen.
Dabei sind uns einige Mängel an der zu testende Software aufgefallen, auch wenn diese nicht
gravierend waren. Da wir leider keine richtige Spezifikation zur Hand hatten, könnte es auch sein,
dass einiger dieser Beobachtungen gewollt sind und keine Fehler aufweisen.
•
Ungültiger Ländercode wurde nicht erkannt. Beispiel: „x“ oder „xy“
•
Bei der Meldung „Datum ungültig“ („Date invalid“) wird der Feldinhalt des Datumfeldes
gelöscht. Diese Vorgehensweise widerspricht der Fehlerbehandlung anderer Felder, bei denen der
Inhalt des Feldes weiterhin (auch bei falschen Eingaben) angezeigt wird. Ein Beispiel dafür ist der
CN Feld.
•
Es wird bei dem „Mandant1001.Produktion.Softtoken“ Formular ein anderes Datumsformat
erwartet, als bei allen anderen Formularen.
•
Fehlermeldung in den „PKCS...“ Formularen für den Feld „Person-ID“ ist nicht gut
nachvollziehbar.
•
•
Kein Person-ID und kein Wert für CN Feld => „Eingabe erforderlich“
•
Falscher Person-ID und kein Wert für CN Feld => „Zahl erforderlich“
•
Kein Person-ID und ein Wert für CN Feld => „Keine gültige ID-Nummer“ + „Nicht überprüft,
da Person-ID fehlt oder ungültig“
•
Falscher Person-ID und ein Wert für CN Feld => „Keine gültige ID-Nummer“+ „Nicht
überprüft, da Person-ID fehlt oder ungültig“
Sprachen Deutsch und Englisch sind gemischt sowohl bei Bezeichnungen, als auch bei den
Fehlermeldungen. Beispiel: „This is not a valid IPv4 address“ aber „Eingabe erforderlich“
- 95 -
Kapitel 10 : Ausblick
10 Ausblick
Bedingt durch den zeitlichen Rahmen der Diplomarbeit konnte nur ein Prototyp erstellt werden.
Dieser eignet sich aber schon zum Testen der FlexiTrust Webanwendung, wie im Kapitel 9 auf Seite
94 gezeigt wurde.
Die schon implementierten Schnittstellen zum Erweitern von Überprüfungsmethoden,
Massentestdaten und Loggern bieten genügend Flexibilität, um auch anspruchsvollere Tests
schreiben und durchführen zu können. Dabei werden bisher die Testarten Funktions- und Massentest
unterstützt. Je nach Komplexität der enthaltenen Überprüfungsmethoden handelt es sich hierbei um
einen „black-box“ oder einen oberflächlichen „white-box“ Test.
Der Logmechanismus erlaubt es zudem dem Anwender, beliebige Ziele und Formate für die
Logdaten zu verwenden. Hierfür müssen lediglich die von Log4j gestellten Schnittstellen verwendet
werden. Standardmäßig stehen Loggerkonfigurationen zum Loggen in HTML-Dateien oder auf die
Konsole zur Verfügung. Zusätzlich kann die integrierte HTML Testverfolgung zum Auswerten der
Fehlerprotokolle herangezogen werden. Durch das sequentielle Abspeichern der aufgerufenen HTML
Seiten kann der Anwender die Reihenfolge der Testabschnitte des durchgeführten Tests leicht
nachvollziehen.
Die Trennung des Testausführers als eigenständige Komponente ermöglicht es zudem, Tests
automatisiert als sogenannte Batchjobs (z.B. als Skript für Ant) durchzuführen. Somit kann ein
Zurücksetzen der Anwendung in einen definierten Anfangszustand vor Beginn eines Testablaufes
bewerkstelligt werden.
Die durch das Plugin bereitgestellte Oberfläche in Eclipse unterstützt den Anwender beim Erstellen
und Bearbeiten der Testfälle. Bei der Implementierung dieser Oberfläche wurde auf die Verwendung
der Designvorschriften von Eclipse besonders geachtet. Anwendern, die Eclipse schon kennen, sollte
deswegen die Verwendung des Werkzeugs leichter fallen.
Neue Anwender werden durch diverse Wizards, Ansichten und die Editoren im Erstellen der
Testfälle unterstützt. Dabei wurde darauf geachtet, dass in allen Dialogen die in Eclipse integrierte
Hilfe genutzt wird, um dem Anwender nützliche Hinweise zu geben oder auf verwandte Themen zu
verweisen.
Die Editoren sollen es ermöglichen, auch ohne XML Kenntnisse Testfälle zu erstellen. Dafür bieten
sie abstraktere Sichtweisen auf die in XML beschriebenen Daten an und verwenden Dialoge zur
vereinfachten Informationseingabe. Für Anwender mit guten XML Kenntnissen steht auch ein
Quellcodeeditor zur Verfügung. Dieser unterstützt den versierten Anwender mit Syntaxhighlighting,
Kontexthilfe und Codevervollständigung.
Das offene Pluginkonzept von Eclipse erlaubt es, dem Werkzeug auch nachträglich neue
Funktionalität hinzuzufügen bzw. andere Plugins zu integrieren und den Funktionsumfang dadurch
zu steigern. Dem Anwender ist es hierdurch möglich eine auf seine Bedürfnisse angepasste
Entwicklungsumgebung zu erstellen.
Im Folgenden werden wir nun Punkte betrachten, die noch nicht oder nur teils im Prototypen
umgesetzt wurden und einer nachträglichen Überarbeitung bedürfen.
1. Die bisher verwendete DTD Definition der Test sollte gegen ein XML Schema ausgetauscht
werden. Durch das Schema könnten die in den Tests erlaubten Strukturen und Daten besser
- 96 -
Kapitel 10 : Ausblick
beschrieben werden. Da ein Schema auch nur eine XML Datei ist, könnten die in ihr enthaltenen
Informationen leichter für die Anwendung nutzbar gemacht werden.
2. Bei der internen Verarbeitung der XML Daten könnte das Laufzeit- und Speicherverhalten durch
Parallelisierung verbessert werden. Dies würde gerade bei einer umfangreichen Testanzahl deren
Ausführung beschleunigen.
3. Es sollte eine Möglichkeit zur Definition und Verwendung von globalen Variablen an zentraler
Stelle zur Verfügung gestellt werden. Dies reduziert den Wartungsaufwand und die
Fehleranfälligkeit bei Änderungen von gemeinsamen Daten.
4. Es werden im Moment nicht alle vorhandene HTML Tags bzw. Attribute unterstützt. Zum
Beispiel wird momentan der HTML Tag <iframe> gar nicht unterstützt. Bei Attributen wären da
„length“, „maxlength“ zu nennen. Während die Ergänzung mit den Attributen eine sehr einfache
Erweiterung ist (nur entsprechende DTD anpassen), wäre es bedeutend mehr Aufwand neue
HTML Tags hinzufügen ( Eine neue Klasse implementieren, anpassen der Parserklasse und
entsprechende DTD ändern).
5. Um ein breiteres Spektrum von Testarten zu unterstützen und somit eine größere Testabdeckung
zu erreichen, sollten Zeittest und Lasttest angeboten werden. Die dazu nötigen Änderungen bzw.
Ergänzungen müssen am Testausführer und Plugin durchgeführt werden.
6. Ein entfernteres Ziel wäre Testen mit einer beliebigen Anzahl von Benutzer mit zufällig
generierten oder ausgewählten Testabläufen. Dieser würde dann praktisch eine „realistische“
Nutzung der Software simulieren.
7. Es soll ermöglicht werden, dass die fehlgelaufenen Tests extrahiert werden. Diese können dann an
den entsprechenden Entwickler als Anleitung für eine Korrektur weitergereicht werden.
8. In den Editoren für den Testablauf und das Modul sollten weitere Ansichten hinzugefügt werden,
die ein einfaches Bearbeiten der Daten erlauben. Weiterhin sollte der Quellcodeeditor, was die
Codevervollständigung und Markierung von Codeblöcken angeht, verbessert werden.
9. Als zusätzliche Funktionen sollten mehrere Refactoringmethoden implementiert und angeboten
werden, wie man sie vom Java Plugin her kennt. Dabei handelt es sich hauptsächlich um das
Umbenennen und Verschieben von Dateien und das daraus resultierende Anpassen von
Pfadangaben.
10.Für das einfachere Erstellen von Tests, an einer schon vorhandenen Webanwendung, sollte ein
Wizard implementiert werden, der es ermöglicht, online Testfälle aufzuzeichnen und
abzuspeichern. Der Anwender muss hierbei durch eine geeignete Oberflächenschnittstelle
unterstützt werden, die die Daten aufbereitet und in verständlicher Form darstellt. Der daraus
entstandene Testablauf muss dann unserer intern verwendeten Struktur entsprechen und könnte so
mit den Editoren nachträglich weiterverarbeitet werden.
11.Durch Trennung weiterer Funktionalität in verschiedene Plugins, muss die interne Hilfe
überarbeitet und an die neuen Bedürfnisse angepasst werden. Von der Verwendung der bisherigen
Struktur ist abzusehen, da dies einen hohen Aufwand in Wartung und Ergänzung bedeuten würde.
12.Falls an eine weitere Verwertung der Ergebnisse gedacht ist, müssen etliche Lizenzfragen geklärt
werden. Dies betrifft vor allem die verwendeten Werkzeuge und Bibliotheken.
Der im Rahmen dieser Diplomarbeit erstellte Prototyp zeigt die Machbarkeit unserer Studie und
- 97 -
Kapitel 10 : Ausblick
Vorgaben. Allerdings ist er noch weit von einem fertigen Produkt entfernt. Die in ihm enthalten
Ansätze und Lösungen können jedoch gut als Grundlage für eine verbesserte Version herangezogen
werden.
- 98 -
Anhang
Anhang
Inhaltsverzeichnis
Bearbeitungsübersicht............................................................................................................................3
Installationsanleitung..............................................................................................................................4
Anwenderhandbuch................................................................................................................................7
XML Syntaxreferenz..............................................................................................................................8
Testsammlungsdatei..........................................................................................................................8
DTD (Collection.dtd)....................................................................................................................8
<testcollection>.............................................................................................................................8
<configuration>.............................................................................................................................9
<host>...........................................................................................................................................9
<loggerentry>................................................................................................................................9
<htmltrace>.................................................................................................................................10
<library>......................................................................................................................................11
<collection>................................................................................................................................12
<collectionentry>........................................................................................................................12
<testentry>..................................................................................................................................13
Testdatei...........................................................................................................................................13
DTD (Test.dtd)............................................................................................................................13
<test>...........................................................................................................................................14
<moduleentry>............................................................................................................................14
<variable>...................................................................................................................................15
<repeat>......................................................................................................................................15
<prepare>....................................................................................................................................16
DTD (Step.dtd)...........................................................................................................................16
<step>..........................................................................................................................................20
<input>........................................................................................................................................20
<output>......................................................................................................................................21
<anyField>..................................................................................................................................22
<a>..............................................................................................................................................23
<button>......................................................................................................................................23
<form>........................................................................................................................................24
<frame>.......................................................................................................................................25
<inputButton>.............................................................................................................................25
<inputCheckbox>........................................................................................................................26
<inputFile>..................................................................................................................................27
<inputImage>..............................................................................................................................27
<inputPassword>.........................................................................................................................28
<inputRadio>..............................................................................................................................29
<inputReset>...............................................................................................................................29
<inputSubmit>............................................................................................................................30
<inputText>................................................................................................................................31
<message>...................................................................................................................................31
<select>.......................................................................................................................................32
-1-
Anhang
<option>......................................................................................................................................32
<textarea>...................................................................................................................................33
Moduldatei.......................................................................................................................................33
DTD (Module.dtd)......................................................................................................................33
<module>....................................................................................................................................34
-2-
Anhang
Bearbeitungsübersicht
Kapitel
Bearbeiter
1 Einleitung
T. Kiss, A. Grahl
2 Einführung ins Testen
T. Kiss
3 Einführung Software Komponenten
A. Grahl
4 Einführung Plugins
A. Grahl
5 Planung Testausführer
T. Kiss
6 Planung Plugin
A. Grahl
7 Umsetzung Testausführer
T. Kiss
8 Umsetzung Plugin
A. Grahl
10 Ausblick
T. Kiss, A. Grahl
Anhang
T. Kiss, A. Grahl
-3-
Anhang
Installationsanleitung
1. Installieren sie Java in der Version 1.4.x.
Für weitere Informationen siehe [Java04].
2. Installieren sie Eclipse in der Version 2.1.x.
Für weitere Informationen siehe [Ecl04].
3. Starten sie Eclipse und öffnen sie über das Menü „Help -> Software Updates -> Update Manager“
die Update Manager Perspective (s. Abbildung 39 Installation: Update Manager öffnen).
Abbildung 39 Installation: Update Manager öffnen
4.
1. Für Installation von einer Webadresse.
1. Öffnen sie in der Ansicht "Feature Updates" mit Rechtsklick das Kontextmenü und wählen.
sie "New -> Site Bookmark..." aus. (s. Abbildung 40 Installation: Site Bookmark erstellen)
2. Im Wizard geben Sie für Name "WebTest" und für URL geben sie die Adresse an, wo das
Plugin hinterlegt ist. Danach drücken sie „finish“.
2. Für Installation vom lokalen Rechner.
1. Suchen sie das Verzeichnis über „My Computer“ in der Ansicht „Feature Updates“, wo die
site.xml des Plugins hinterlegt ist.
-4-
Anhang
Abbildung 40 Installation: Site Bookmark erstellen
5. Öffnen Sie in der Ansicht "Feature Updates" die neu angelegte Bookmark "WebTest" oder das
Verzeichnis falls sie vom lokalen Rechner installieren und wählen sie "Other ->
com.webtest.feature 1.0.0" aus (s. Abbildung 41 Installation: Feature auswählen).
Abbildung 41 Installation: Feature
auswählen
6. In der Editoransicht im "Preview" setzen sie bitte bei "Install by adding to the Selected Updates."
ein Häckchen und drücken dann "Install now" (s. Abbildung 42 Installation: Feature Dialog).
7. Im Wizard drücken Sie "Next", akzeptieren die Lizensbedingungen und drücken im dritten Dialog
"finish".
-5-
Anhang
Abbildung 42 Installation: Feature Dialog
8. Eclipse wird nach der Installation neu gestartet, danach steht Ihnen die Funktionalität des Plugins
zur Verfügung.
-6-
Anhang
Anwenderhandbuch
Hilfe für die Verwendung des Plugins finden sie in der Onlinehilfe von Eclipse. Die Hilfe können sie
über das Menü „Help -> Help Contents“ öffnen. Es öffnet sich der Hilfebrowser von Eclipse. Die
Hilfe zum Plugin ist dort unter der Kategorie „Webtest“ zu finden.
In den Editoren, Ansichten oder Dialogen des Plugins können sie auch über drücken von F1 direkt
Hilfe erhalten. Es erscheint dann eine Kontexthilfe mit kurzer Hilfestellung und Verweisen auf
entsprechende Themen in der Onlinehilfe.
-7-
Anhang
XML Syntaxreferenz
Testsammlungsdatei
DTD (Collection.dtd)
<!ENTITY % config_element "host,loggerentry,htmltrace,library*">
<!ENTITY % entry_element "collectionentry|testentry">
<!ELEMENT testcollection (configuration,collection)>
<!ELEMENT configuration (%config_element;)>
<!ELEMENT host EMPTY>
<!ATTLIST host
address CDATA #REQUIRED>
<!ELEMENT loggerentry EMPTY>
<!ATTLIST loggerentry
path CDATA #IMPLIED
enabled (on|off) "off">
<!ELEMENT htmltrace EMPTY>
<!ATTLIST htmltrace
path CDATA #REQUIRED
enabled (on|off) "off">
<!ELEMENT library EMPTY>
<!ATTLIST library
path CDATA #REQUIRED>
<!ELEMENT collection (%entry_element;)*>
<!ELEMENT collectionentry EMPTY>
<!ATTLIST collectionentry
path CDATA #REQUIRED>
<!ELEMENT testentry EMPTY>
<!ATTLIST testentry
path CDATA #REQUIRED>
<testcollection>
Der Tag <testcollection> ist das Root Element dieser XML Datei.
•
Attribute
keine
•
Inhalt
-8-
Anhang
(configuration,collection)
Es muss als Inhalt genau einmal der Tag <configuration> und dann genau einmal der Tag
<collection> folgen.
•
Eltern
keine
<configuration>
Der Tag <configuration> legt die Konfiguration für die Testsammlung fest. Diese Konfiguration wird
direkt nach dem erfolgreichen Einlesen der Datei gesetzt und ist so lange gültig, bis eine neue
Testsammlungdatei aufgerufen wird.
•
Attribute
keine
•
Inhalt
(host, loggerentry, htmltrace, library*)
Die Tags müssen in der oben aufgezählter Reihenfolge erfolgen. Genau einmal <host>, genau einmal
<loggerentry>, genau einmal <htmltrace> und beliebig oft der Tag <library>.
•
Eltern
<testcollection>
<host>
Der Tag <host> definiert die Hostadresse, an der die Anwendung zu finden ist. Zu bemerken ist
dabei, dass es sich NICHT um die vollständige Startadresse des Testablaufs handelt. Diese setzt sich
nämlich aus der Hostadresse plus URL zusammen. Die URL wird in dem einzelnen Testdateien
definiert.
•
Attribute
Name
address
•
Beschreibung
Wert
Die Hostadresse.
Beliebige
Zeichenkette
Pflicht
Ja
Inhalt
leer
•
Eltern
<configuration>
<loggerentry>
Der Tag <loggerentry> definiert, ob der Testablauf mitgeloggt werden soll und falls ja, welche
Properties-Datei zum Loggen benutzt werden soll. Die Log- Datei muss das Properties Dateiformat
haben und in Log4J Format definiert sein. Für weitere Informationen siehe Kapitel „Logger“.
-9-
Anhang
•
Attribute
Name
Beschreibung
Wert
Pflicht
path
Gibt an, von wo aus Beliebige
die Properties
Zeichenkette
Logger Datei
geladen werden
soll. Dieskann ein
absoluter Pfad sein
oder relativ vom
Arbeitsverzeichnis
aus.
Nein
enabled
Er zeigt an, ob der
Logger ein- oder
ausgeschaltet ist.
Nein; Standard ist
„off“
•
„on“ oder „off“
Inhalt
leer
•
Eltern
<configuration>
<htmltrace>
Der Tag <htmltrace> gibt an, ob eine Testverfolgung im HTML Dateiformat erfolgen soll oder nicht.
Falls ja, so wird auch hier der Pfad zu einem Ordner angegeben, in den die Dateien geschrieben
werden sollen. Dieser Pfad wird automatisch angelegt, falls er nicht existiert.
<htmltrace> ermöglicht nach der Testausführung die HTML Dateien in der Aufrufreihenfolge
anzuschauen. Dabei wird jede Seite angezeigt:
•
•
im Aufrufzustand (Hier ist es möglich die Seite mit ihren vordefinierten Defaultwerten zu
sehen.)
im ausgefüllten Zustand vor dem Abschicken (Falls eine Änderung in der Seite vorgefallen ist)
Dabei wird für jede Testsammlungsdatei unterhalb des angegeben Pfades ein neuer Ordner namens
Testsammlungdatei erzeugt. Innerhalb dieses Ordners werden erst wieder Ordner mit Namen
test_Nummer angelegt. Jeder dieser Ordner entspricht einer Testdatei in der Testsammlung. In diesen
Testordner werden nun die ausgeführten HTML Seiten in durchnummerierter Ausführreihenfolge
geschrieben. Ein Beispiel für diese Ordnerstruktur gibt Abbildung 43 Struktur der HTML
Testverfolgung :
- 10 -
Anhang
Abbildung 43 Struktur der HTML
Testverfolgung
•
Attribute
Name
Beschreibung
Wert
Pflicht
path
Gibt den Pfad für
Beliebige
den Ordner an,
Zeichenkette
wohin die HTML
Dateien geschrieben
werden sollen.
Dieser kann ein
absoluter Pfad sein
oder relativ vom
Arbeitsverzeichnis
aus.
Nein
enabled
Er zeigt an, ob die „on“ oder „off“
HTML
Testverfolgung einoder ausgeschaltet
ist.
Nein; Standard ist
„off“
•
Inhalt
leer
•
Eltern
<configuration>
<library>
Der Tag <library> gibt die Möglichkeit, eigens definierte Java Klassen in JAR Format im Programm
zu laden. Diese werden gebraucht, falls eigene Klassen, Methoden für die Schnittstellen Assert,
Massentest definiert wurden.
•
Attribute
- 11 -
Anhang
Name
path
•
Beschreibung
Gibt den Pfad für
die JAR Datei an.
Dieser kann ein
absoluter Pfad sein
oder relativ vom
Arbeitverzeichnis
aus.
Wert
Beliebige
Zeichenkette
Pflicht
Nein
Inhalt
leer
•
Eltern
<configuration>
<collection>
Der Tag <collection> gibt an welche Testdateien bzw. anderen Testsammlungsdateien in welcher
Reihenfolge ausgeführt werden sollen.
•
Attribute
keine
•
Inhalt
(collectionentry|testentry)*
Es dürfen in beliebiger Reihenfolge, beliebig oft die Tags <collectionentry> und <testentry> erfolgen.
•
Eltern
<testcollection>
<collectionentry>
Der Tag <collectionentry> erlaubt, dass in die Testsammlung neue Testsammlungen eingebunden
werden können. Das ist vor allem dann wichtig, wenn man eine kompliziertere Teststruktur haben
möchte, zum Beispiel für manche Gruppen von Tests andere Konfigurationen vorgesehen wurden.
(Manche Testergebnisse sollten in eine Datenbank geloggt werden, andere wieder nicht.)
Bei der Einbindung einer neuen Testsammlung ist auf jeden Fall zu beachten, dass damit kein Zyklus
in der Teststruktur entsteht.
•
Attribute
- 12 -
Anhang
Name
path
•
Beschreibung
Gibt den Pfad für
die Testsammlung
Datei an. Dieser
kann ein absoluter
Pfad sein oder
relativ vom
Arbeitsverzeichnis
aus.
Wert
Beliebige
Zeichenkette
Pflicht
Ja
Inhalt
leer
•
Eltern
<collection>
<testentry>
Der Tag <testentry> erlaubt, dass in die Testsammlung Testdateien eingebunden werden können.
•
Attribute
Name
path
•
Beschreibung
Gibt den Pfad für
die Testdatei an.
Dieser kann ein
absoluter Pfad sein
oder relativ vom
Arbeitsverzeichnis
aus.
Wert
Beliebige
Zeichenkette
Inhalt
leer
•
Eltern
<collection>
Testdatei
DTD (Test.dtd)
<!ENTITY % test_element "step|moduleentry">
<!ENTITY % steps SYSTEM "Step.dtd">
%steps;
- 13 -
Pflicht
Ja
Anhang
<!ELEMENT test ((%test_element;)*,repeat?,(%test_element;)*)>
<!ATTLIST test
id CDATA #IMPLIED
name CDATA #REQUIRED
url CDATA #REQUIRED>
<!ELEMENT moduleentry (variable)*>
<!ATTLIST moduleentry
path CDATA #REQUIRED>
<!ELEMENT variable EMPTY>
<!ATTLIST variable
name CDATA #IMPLIED
value CDATA #IMPLIED>
<!ELEMENT repeat ((argument)*,(step)*,prepare?)>
<!ATTLIST repeat
classname CDATA #REQUIRED>
<!ELEMENT prepare (%test_element;)*>
<test>
Der Tag <test> ist das Root Element dieser XML Datei. In diesem Tag wird die URL ab der
Hostadresse angegeben. Das Attribut url ist also keine vollständige Webadresse.
•
Attribute
Name
url
•
Beschreibung
Wert
Die URL zu der
Webseite, wo der
Test angefangen
werden soll.
Beliebige
Zeichenkette
Pflicht
Ja
Inhalt
((step|moduleentry)*,repeat?,(step|moduleentry)*)
Es dürfen beliebig viele Tags von Typ <step> und <moduleentry> in beliebiger Reihenfolge
auftreten. Der Tag <repeat> hingegen darf nur einmal an einer beliebigen Stelle eingebettet sein.
•
Eltern
keine
<moduleentry>
Der Tag <moduleentry> gibt die Möglichkeit ein Modul in den Testfall einzubinden. Ein Modul ist
ein Stück ausgelagerter Testablauf, das auch mit variablen Werten belegt werden kann. Die Belegung
der Variablen erfolgt auch in diesem Tag.
- 14 -
Anhang
•
Attribute
Name
path
•
Beschreibung
Wert
Der Pfad zu der
Beliebige
Moduldatei. Dieser Zeichenkette
kann ein absoluter
Pfad sein oder
relativ vom
Arbeitverzeichnis
aus.
Pflicht
Ja
Inhalt
(variable)*
Der Inhalt besteht aus einer beliebigen Anzahl von <variable> Tags.
•
Eltern
<test>
<variable>
Der Tag <variable> ermöglicht die Wertangabe an Variablen. Diese erfolgt immer nur für den
entsprechenden Testfall. So ist es möglich, beispielsweise ein Login- Modul immer wieder mit
verschiedenen Werten zu benutzen.
•
Attribute
Name
Beschreibung
Wert
Pflicht
name
Name der Variable
$+ eine beliebige
Zeichenkette
Ja
value
Wert der Variable
Beliebige
Zeichenkette
Ja
•
Inhalt
leer
•
Eltern
<moduleentry>
<repeat>
Der Tag <repeat> erlaubt Massentest über eine Menge von Seiten auszuführen. Dabei werden in
immer den gleichen HTML Seiten in den gleichen Feldern verschiedenste Daten eingegeben. Es darf
nur ein <repeat> Tag pro Testdatei definiert sein.
- 15 -
Anhang
Um die Massendaten einlesen zu können, muss eine Struktur für die Daten und eine Klasse definiert
werden, die diese Daten einliest. Die Angabe der Klasse muss innerhalb der JAR Dateien passieren,
die in die Testsammlung in dem Tag <library> definiert und eingebunden wurden.
•
Attribute
Name
classname
•
Beschreibung
Wert
Der Pfad zu der
Beliebige
Klasse,die die
Zeichenkette
Schnittstelle
RepeatInterface.jav
a implementiert.
Pflicht
Ja
Inhalt
((argument)*,(step)*,prepare?)
Erst erfolgen eine beliebige Anzahl von <argument> Tags, dann eine beliebige Anzahl von <step>
Tags und schließlich optional ein <prepare> Tag.
•
Eltern
<test>
<prepare>
Der Tag <prepare> gibt die Möglichkeit bei der Ausführung von Massentests, dass nach jedem
Durchlauf an die selbe Stelle (Seite) der Anwendung zurückgekehrt werden kann, um dann den
nächsten Test mit Massendaten durchzuführen.
Dieser Vorgang kann beispielweise nur das Drücken eines Verweises, aber auch ein komplettes
Ausloggen bzw. neu Einloggen bedeuten.
•
Attribute
keine
•
Inhalt
(step|moduleentry)*
Der Inhalt darf aus einer beliebigen Anzahl von <step> und <moduleentry> Tags, in beliebiger
Reihenfolge definiert sein.
•
Eltern
<repeat>
DTD (Step.dtd)
<!ENTITY % input_html_element
"anyField|
inputCheckbox|inputFile|inputPassword|inputRadio|inputReset|inputText|
message|select|textarea">
<!ENTITY % submit_element
- 16 -
Anhang
"a|button|inputButton|inputImage|inputSubmit">
<!ENTITY % html_element
"%input_html_element;|%submit_element;">
<!ENTITY % input_element
"frame?,form?,(%input_html_element;)*,(%submit_element;)?">
<!ENTITY % output_element
"(assert|frame)?,(assert|form)?,(assert|%html_element;)*">
<!ELEMENT step (input,(output)*)>
<!ELEMENT input (%input_element;)>
<!ELEMENT output (%output_element;)>
<!ELEMENT assert ((argument)*,(frame)?,(form)?,(%html_element;)*)>
<!ATTLIST assert
classname CDATA #IMPLIED>
<!ELEMENT argument (#PCDATA)>
<!ATTLIST argument
name CDATA #REQUIRED>
<!ELEMENT a (#PCDATA)>
<!ATTLIST a
id CDATA #IMPLIED
name CDATA #IMPLIED
href CDATA #IMPLIED
not CDATA #IMPLIED>
<!ELEMENT anyField (#PCDATA)>
<!ATTLIST anyField
id CDATA #IMPLIED
name CDATA #IMPLIED
value CDATA #IMPLIED
not CDATA #IMPLIED>
<!ELEMENT button (#PCDATA)>
<!ATTLIST button
id CDATA #IMPLIED
name CDATA #IMPLIED
value CDATA #IMPLIED
not CDATA #IMPLIED>
<!ELEMENT form EMPTY>
<!ATTLIST form
id CDATA #IMPLIED
name CDATA #IMPLIED
action CDATA #IMPLIED
- 17 -
Anhang
not CDATA #IMPLIED>
<!ELEMENT frame EMPTY>
<!ATTLIST frame
id CDATA #IMPLIED
name CDATA #IMPLIED
src CDATA #IMPLIED
not CDATA #IMPLIED>
<!ELEMENT inputButton EMPTY>
<!ATTLIST inputButton
id CDATA #IMPLIED
name CDATA #IMPLIED
value CDATA #IMPLIED
not CDATA #IMPLIED>
<!ELEMENT inputCheckbox EMPTY>
<!ATTLIST inputCheckbox
id CDATA #IMPLIED
name CDATA #IMPLIED
value CDATA #IMPLIED
checked (true|false) "true"
not CDATA #IMPLIED>
<!ELEMENT inputFile EMPTY>
<!ATTLIST inputFile
id CDATA #IMPLIED
name CDATA #IMPLIED
value CDATA #IMPLIED
not CDATA #IMPLIED>
<!ELEMENT inputImage EMPTY>
<!ATTLIST inputImage
id CDATA #IMPLIED
name CDATA #IMPLIED
value CDATA #IMPLIED
src CDATA #IMPLIED
not CDATA #IMPLIED>
<!ELEMENT inputPassword EMPTY>
<!ATTLIST inputPassword
id CDATA #IMPLIED
name CDATA #IMPLIED
value CDATA #IMPLIED
not CDATA #IMPLIED>
<!ELEMENT inputRadio EMPTY>
<!ATTLIST inputRadio
- 18 -
Anhang
id CDATA #IMPLIED
name CDATA #IMPLIED
value CDATA #IMPLIED
checked (true|false) "true"
not CDATA #IMPLIED>
<!ELEMENT inputReset EMPTY>
<!ATTLIST inputReset
id CDATA #IMPLIED
name CDATA #IMPLIED
value CDATA #IMPLIED
not CDATA #IMPLIED>
<!ELEMENT inputSubmit EMPTY>
<!ATTLIST inputSubmit
id CDATA #IMPLIED
name CDATA #IMPLIED
value CDATA #IMPLIED
not CDATA #IMPLIED>
<!ELEMENT inputText EMPTY>
<!ATTLIST inputText
id CDATA #IMPLIED
name CDATA #IMPLIED
value CDATA #IMPLIED
not CDATA #IMPLIED>
<!ELEMENT message (#PCDATA)>
<!ATTLIST message
id CDATA #IMPLIED
not CDATA #IMPLIED>
<!ELEMENT select (option)*>
<!ATTLIST select
id CDATA #IMPLIED
name CDATA #IMPLIED
not CDATA #IMPLIED>
<!ELEMENT option (#PCDATA)>
<!ATTLIST option
id CDATA #IMPLIED
value CDATA #IMPLIED
selected (true|false) "false"
not CDATA #IMPLIED>
<!ELEMENT textarea (#PCDATA)>
<!ATTLIST textarea
id CDATA #IMPLIED
- 19 -
Anhang
name CDATA #IMPLIED
not CDATA #IMPLIED>
<step>
Der Tag <step> gibt einen Schritt des Testablaufs ein. Ein Schritt besteht typischerweise aus:
1. Aufruf einer Webseite.
2. Bearbeiten bzw. Ausfüllen der Seite (z.b. Textfelder ausfüllen, Auswahl von Optionen etc.).
3. Verlassen der Seite.
•
•
Abschicken des Formulars mit Absende Knopf.
•
Verweis anklicken.
•
Beliebigen Knopf anklicken.
Attribute
keine
•
Inhalt
(input,(output)*)
Der Inhalt besteht aus genau einmal <input> Tag gefolgt von einer beliebigen Anzahl von <output>
Tags.
•
Eltern
<test>, <repeat>, <prepare>, <module>
<input>
Der Tag <input> definiert den Bereich vom Tag <step> in dem die aktuelle HTML Seite bearbeitet
werden kann.
•
Attribute
keine
•
Inhalt
(frame?,form?,(%input_html_element;)*,(%submit_element;)?)
Der Inhalt ist folgendermaßen zu verstehen: es darf erst genau einmal der Tag <frame>, dann der Tag
<form> vorkommen. Schließlich dürfen eine beliebige Anzahl von HTML Eingabeelementen %
input_html_element; und eine beliebige Anzahl von HTML Abschickelementen %
submit_element; folgen.
<!ENTITY % input_html_element
"anyField|
inputCheckbox|inputFile|inputPassword|inputRadio|inputReset|inputText|
message|select|textarea">
Die HTML Eingabeelemente sind die Folgenden:
- 20 -
Anhang
XML Tagname
Name des Elements
HTML Tagname
<anyField>
beliebiges Feld
alle
<inputCheckbox>
Mehrfachauswahl
<input type=“checkbox“>
<inputFile>
Datei aufladen
<input type=“file“>
<inputPassword>
Passwort Feld
<input type=“password“>
<inputRadio>
Einfachauswahl
<input type=“radio“>
<inputReset>
Zurücksetzen Knopf
<input type=“reset“>
<inputText>
Texteingabefeld
<input type=“text“>
<message>
Ein beliebiger Text
-
<select>
Auswahlbox
<select>
<textarea>
Textbox
<textarea>
<!ENTITY % submit_element
"a|button|inputButton|inputImage|inputSubmit">
Die HTML Abschickelemente sind die Folgenden:
XML Tagname
Name des Elements
HTML Tagname
<a>
Verweis
<a>
<button>
Klickknopf
<button>
<inputButton>
Klickknopf
<input type=“button“>
<inputImage>
Optischer Klickknopf
<input type=“image“>
<inputSubmit>
Abschicken Knopf
<input type=“submit“>
•
Eltern
<step>
<output>
Der Tag <output> definiert den Bereich vom Tag <step> in dem die Ergebnisseite überprüft werden
kann.
•
Attribute
keine
•
Inhalt
((assert|frame)?,(assert|form)?,(assert|%html_element;)*)*
Der Inhalt ist folgendermaßen zu verstehen: Es darf erst genau einmal der Tag <frame>, dann der
Tag <form> vorkommen. Schließlich dürfen eine beliebige Anzahl von HTML Elementen %
html_element; definiert werden. Der Tag <assert> darf an beliebigen Stellen beliebig oft
auftauchen.
- 21 -
Anhang
<!ENTITY % html_element
"%input_html_element;|%submit_element;">
Die HTML Elemente %html_element; bestehen aus allen definierbaren HTML Feldern. Diese
setzen sich aus %input_html_element; und %submit_element; zusammen.
<!ENTITY % input_html_element
"anyField|
inputCheckbox|inputFile|inputPassword|inputRadio|inputReset|inputText|
message|select|textarea">
<!ENTITY % submit_element
"a|button|inputButton|inputImage|inputSubmit">
•
Eltern
<step>
<anyField>
Der Tag <anyField> bezeichnet irgendein HTML Element. Dieses zu benutzen ist nur dann
empfehlenswert, wenn es für den HTML Tag, der benutzt werden soll, keine eigene Unterstützung
gibt. Das Setzen des Feldes mit einem Wert ist nicht möglich!
•
Attribute
Name
Beschreibung
Wert
Pflicht
id
Der eindeutige
Identifikator des
Feldes.
Attribut „id“ im
HTML Tag.
name
Der Name des
Feldes.
Attribut „name“ im Nein
HTML Tag.
value
Der Wert des
Feldes.
Attribut „value“ im Nein
HTML Tag.
not
Dieses Attribut gibt KEIN WERT.
an, dass das
Nichtvorhandensein
des Elements
überprüft wird.
•
Nein
Nein
Inhalt
beliebiger Text
Der Inhalt ist nach der Spezifikation evtl. der Wert des HTML Elements.
•
Eltern
<input>, <output>, <assert>
- 22 -
Anhang
<a>
Der Tag <a> entspricht einem Verweis in der HTML Seite.
•
Attribute
Name
Beschreibung
Wert
id
Der eindeutige
Identifikator des
Feldes.
href
Der Referenzwert
Attribut „href“ im
des Feldes. Gibt an, HTML Tag.
wohin beim Klick
gesprungen wird.
name
Der Name des
Feldes. Wird nur
beim Anker
benutzt.
Attribut „name“ im Nein
HTML Tag.
value
Der Wert des
Feldes.
Attribut „value“ im Nein
HTML Tag.
not
DiesesAttribut gibt KEIN WERT.
an, dass das
Nichtvorhandensein
des Elements
überprüft wird.
•
Attribut „id“ im
HTML Tag.
Pflicht
Nein
Nein
Nein
Inhalt
beliebiger Text
Der Inhalt ist der Verweistext, der in der HTML Seite erscheint.
•
Eltern
<input>, <output>, <assert>
<button>
Der Tag <button> bezeichnet den modernen Klickknopf.
•
Attribute
Name
Beschreibung
Wert
Pflicht
id
Der eindeutige
Identifikator des
Feldes.
Attribut „id“ im
HTML Tag.
name
Der Name des
Feldes.
Attribut „name“ im Nein
HTML Tag.
- 23 -
Nein
Anhang
Name
Beschreibung
Wert
value
Der Wert des
Feldes.
not
Dieses Attribut gibt KEIN WERT.
an, dass das
Nichtvorhandensein
des Elements
überprüft wird.
•
Pflicht
Attribut „value“ im Nein
HTML Tag.
Nein
Inhalt
beliebiger Text
Der Inhalt ist der Text des Knopfes, der in der HTML Seite erscheint.
•
Eltern
<input>, <output>, <assert>
<form>
Der Tag <form> bezeichnet ein ausfüll- und abschickbares Formular in der HTML Seite.
•
Attribute
Name
Beschreibung
Wert
Pflicht
action
Die Aktion, die
beim Abschicken
des Formulars
ausgeführt wird.
Attribut „action“ im Nein
HTML Tag.
id
Der eindeutige
Identifikator des
Feldes.
Attribut „id“ im
HTML Tag.
name
Der Name des
Feldes.
Attribut „name“ im Nein
HTML Tag.
value
Der Wert des
Feldes.
Attribut „value“ im Nein
HTML Tag.
not
Dieses Attribut gibt KEIN WERT.
an, dass das
Nichtvorhandensein
des Elements
überprüft wird.
•
Inhalt
leer
- 24 -
Nein
Nein
Anhang
•
Eltern
<input>, <output>, <assert>
<frame>
Der Tag <frame> bezeichnet ein Ansichtsfenster in der HTML Seite.
•
Attribute
Name
Beschreibung
Wert
Pflicht
id
Der eindeutige
Identifikator des
Feldes.
Attribut „id“ im
HTML Tag.
name
Der Name des
Feldes.
Attribut „name“ im Nein
HTML Tag.
src
Die Quelle, von wo Attribut „src“ im
aus das Fenster
HTML Tag.
geladen wird.
Nein
not
Dieses Attribut gibt KEIN WERT.
an, dass das
Nichtvorhandensein
des Elements
überprüft wird.
Nein
•
Nein
Inhalt
leer
•
Eltern
<input>, <output>, <assert>
<inputButton>
Der Tag <inputButton> bezeichnet einen „alten“ Klickknopf in der HTML Seite.
•
Attribute
Name
Beschreibung
Wert
Pflicht
id
Der eindeutige
Identifikator des
Feldes.
Attribut „id“ im
HTML Tag.
name
Der Name des
Feldes.
Attribut „name“ im Nein
HTML Tag.
value
Der Wert des
Feldes.
Attribut „value“ im Nein
HTML Tag.
- 25 -
Nein
Anhang
Name
not
•
Beschreibung
Wert
Dieses Attribut gibt KEIN WERT.
an, dass das
Nichtvorhandensein
des Elements
überprüft wird.
Pflicht
Nein
Inhalt
leer
•
Eltern
<input>, <output>, <assert>
<inputCheckbox>
Der Tag <inputCheckbox> bezeichnet ein Mehrfachauswahlfeld in der HTML Seite. Es können also
keines, eines oder mehrere Felder ausgewählt werden.
•
Attribute
Name
Beschreibung
Wert
Pflicht
checked
Zeigt an, ob das
Feld ausgewählt
wurde oder nicht.
Attribut „checked“
im HTML Tag.
Möglicher Werte:
„true“ oder „false“
Nein, Standard ist
„false“
id
Der eindeutige
Identifikator des
Feldes.
Attribut „id“ im
HTML Tag.
Nein
name
Der Name des
Feldes.
Attribut „name“ im Nein
HTML Tag.
value
Der Wert des
Feldes.
Attribut „value“ im Nein
HTML Tag.
not
DiesesAttribut gibt KEIN WERT.
an, dass das
Nichtvorhandensein
des Elements
überprüft wird.
•
Inhalt
leer
•
Eltern
<input>, <output>, <assert>
- 26 -
Nein
Anhang
<inputFile>
Der Tag <inputFile> bezeichnet ein Feld, mit dessen Hilfe Dateien ins Internet hochgeladen werden
können.
•
Attribute
Name
Beschreibung
Wert
Pflicht
id
Der eindeutige
Identifikator des
Feldes.
Attribut „id“ im
HTML Tag.
name
Der Name des
Feldes.
Attribut „name“ im Nein
HTML Tag.
value
Der Wert des
Feldes, ist ein Pfad
zur Datei, die
hochgeladen
werden soll.
Attribut „value“ im Nein
HTML Tag.
not
Dieses Attribut gibt KEIN WERT.
an, dass das
Nichtvorhandensein
des Elements
überprüft wird.
•
Nein
Nein
Inhalt
leer
•
Eltern
<input>, <output>, <assert>
<inputImage>
Der Tag <inputImage> bezeichnet einen optischen Abschickknopf in der HTML Seite. Das heißt,
dass der Knopf wie ein Bild in der Seite erscheint.
•
Attribute
Name
Beschreibung
Wert
Pflicht
id
Der eindeutige
Identifikator des
Feldes.
Attribut „id“ im
HTML Tag.
name
Der Name des
Feldes.
Attribut „name“ im Nein
HTML Tag.
- 27 -
Nein
Anhang
Name
Beschreibung
Wert
Pflicht
value
Der Wert des
Feldes. Der Text,
der in der HTML
Seite erscheint.
src
Gibt die Quelle an, Attribut „src“ im
von wo aus das Bild HTML Tag.
geladen werden
soll.
Nein
not
Dieses Attribut gibt KEIN WERT.
an, dass das
Nichtvorhandensein
des Elements
überprüft wird.
Nein
•
Attribut „value“ im Nein
HTML Tag.
Inhalt
leer
•
Eltern
<input>, <output>, <assert>
<inputPassword>
Der Tag <inputPassword> bezeichnet ein Feld, das für die Passworteingabe verantwortlich ist.
Anstelle von Zeichen erscheinen dabei in der HTML Seite nur Sternchen.
•
Attribute
Name
Beschreibung
Wert
Pflicht
id
Der eindeutige
Identifikator des
Feldes.
Attribut „id“ im
HTML Tag.
name
Der Name des
Feldes.
Attribut „name“ im Nein
HTML Tag.
value
Der Wert des
Feldes.
Attribut „value“ im Nein
HTML Tag.
not
Dieses Attribut gibt KEIN WERT.
an, dass das
Nichtvorhandensein
des Elements
überprüft wird.
•
Inhalt
- 28 -
Nein
Nein
Anhang
leer
•
Eltern
<input>, <output>, <assert>
<inputRadio>
Der Tag <inputRadio> bezeichnet ein Einfachauswahlfeld in der HTML Seite. Wie schon der Name
sagt, darf nur ein Feld selektiert werden.
•
Attribute
Name
Beschreibung
Wert
Pflicht
checked
Zeigt an, ob das
Feld ausgewählt
wurde oder nicht.
Attribut „checked“
im HTML Tag.
Möglicher Werte:
„true“ oder „false“
Nein, Standard ist
„false“
id
Der eindeutige
Identifikator des
Feldes.
Attribut „id“ im
HTML Tag.
Nein
name
Der Name des
Feldes.
Attribut „name“ im Nein
HTML Tag.
value
Der Wert des
Feldes.
Attribut „value“ im Nein
HTML Tag.
not
Dieses Attribut gibt KEIN WERT.
an, dass das
Nichtvorhandensein
des Elements
überprüft wird.
•
Nein
Inhalt
leer
•
Eltern
<input>, <output>, <assert>
<inputReset>
Der Tag <inputReset> bezeichnet den Rücksetzknopf eines Formulars in der HTML Seite.
•
Attribute
Name
id
Beschreibung
Der eindeutige
Identifikator des
Feldes.
Wert
Attribut „id“ im
HTML Tag.
- 29 -
Pflicht
Nein
Anhang
Name
Beschreibung
Wert
Pflicht
name
Der Name des
Feldes.
Attribut „name“ im Nein
HTML Tag.
value
Der Wert des
Feldes.
Attribut „value“ im Nein
HTML Tag.
not
Dieses Attribut gibt KEIN WERT.
an, dass das
Nichtvorhandensein
des Elements
überprüft wird.
•
Nein
Inhalt
leer
•
Eltern
<input>, <output>, <assert>
<inputSubmit>
Der Tag <inputSubmit> bezeichnet den Abschickknopf eines Formulars in der HTML Seite.
•
Attribute
Name
Beschreibung
Wert
Pflicht
id
Der eindeutige
Identifikator des
Feldes.
Attribut „id“ im
HTML Tag.
name
Der Name des
Feldes.
Attribut „name“ im Nein
HTML Tag.
value
Der Wert des
Feldes.
Attribut „value“ im Nein
HTML Tag.
not
Dieses Attribut gibt KEIN WERT.
an, dass das
Nichtvorhandensein
des Elements
überprüft wird.
•
Inhalt
leer
•
Eltern
<input>, <output>, <assert>
- 30 -
Nein
Nein
Anhang
<inputText>
Der Tag <inputText> bezeichnet ein Texteingabefeld in der HTML Seite.
•
Attribute
Name
Beschreibung
Wert
Pflicht
id
Der eindeutige
Identifikator des
Feldes.
Attribut „id“ im
HTML Tag.
name
Der Name des
Feldes.
Attribut „name“ im Nein
HTML Tag.
value
Der Wert des
Feldes.
Attribut „value“ im Nein
HTML Tag.
not
Dieses Attribut gibt KEIN WERT.
an, dass das
Nichtvorhandensein
des Elements
überprüft wird.
•
Nein
Nein
Inhalt
leer
•
Eltern
<input>, <output>, <assert>
<message>
Der Tag <message> bezeichnet einen beliebigen Text in der HTML Seite. Dieser Text darf auch
HTML Tags erhalten.
•
Attribute
Name
Beschreibung
Wert
id
Der eindeutige
Identifikator des
Feldes.
not
Dieses Attribut gibt KEIN WERT.
an, dass das
Nichtvorhandensein
des Elements
überprüft wird.
•
Attribut „id“ im
HTML Tag.
Inhalt
beliebiger Text
- 31 -
Pflicht
Nein
Nein
Anhang
Der Text, der in der HTML Seite gesucht werden soll.
•
Eltern
<input>, <output>, <assert>
<select>
Der Tag <select> bezeichnet die Auswahlbox in der HTML Seite.
•
Attribute
Name
Beschreibung
Wert
Pflicht
id
Der eindeutige
Identifikator des
Feldes.
Attribut „id“ im
HTML Tag.
name
Der Name des
Feldes.
Attribut „name“ im Nein
HTML Tag.
not
Dieses Attribut gibt KEIN WERT.
an, dass das
Nichtvorhandensein
des Elements
überprüft wird.
•
Nein
Nein
Inhalt
(option)*
Der Inhalt darf beliebig oft aus dem Tag <option> bestehen.
•
Eltern
<input>, <output>, <assert>
<option>
Der Tag <option> bezeichnet eine Option in der Auswahlbox.
•
Attribute
Name
Beschreibung
Wert
Pflicht
id
Der eindeutige
Identifikator des
Feldes.
Attribut „id“ im
HTML Tag.
Nein
selected
Zeigt an, ob die
Option gewählt
wurde oder nicht.
Attribut „selected“
im HTML Tag.
Nein
value
Der Wert des
Feldes.
Attribut „wert“ im
HTML Tag.
Nein
- 32 -
Anhang
Name
not
•
Beschreibung
Wert
Dieses Attribut gibt KEIN WERT.
an, dass das
Nichtvorhandensein
des Elements
überprüft wird.
Pflicht
Nein
Inhalt
beliebiger Text
Der Inhalt ist der Text der Option, der in der HTML Seite erscheint.
•
Eltern
<select>
<textarea>
Der Tag <textarea> bezeichnet die Textbox in der HTML Seite.
•
Attribute
Name
Beschreibung
Wert
Pflicht
id
Der eindeutige
Identifikator des
Feldes.
Attribut „id“ im
HTML Tag.
name
Der Name des
Feldes.
Attribut „name“ im Nein
HTML Tag.
not
Dieses Attribut gibt KEIN WERT.
an, dass das
Nichtvorhandensein
des Elements
überprüft wird.
•
Inhalt
beliebiger Text
Der Inhalt ist der Text, der in der HTML Seite erscheint.
•
Eltern
<input>, <output>, <assert>
Moduldatei
DTD (Module.dtd)
<!ENTITY % step SYSTEM "Step.dtd">
- 33 -
Nein
Nein
Anhang
%step;
<!ELEMENT module (step)*>
<module>
Der Tag <module> ist das Root- Element dieser XML Datei.
•
Attribute
keine
•
Inhalt
((step)*)
Als Inhalt können eine beliebige Anzahl von <step> Tags eingebunden werden.
•
Eltern
keine
- 34 -

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project