Technisch-Naturwissenschaftliche

Fakultät

 

 

Das TPTP-Web-TEST-Projekt
Automatisierung von Regressionstests für HTML-basierte Webanwendungen

 

 

Masterarbeit

 

zur Erlangung des akademischen Grades

 

Diplom-Ingenieur

 

im Masterstudium

 

Informatik

 

 

Eingereicht von:

Günter Öller, Bakk.techn., 0355112

 

Angefertigt am:

Institut für Systemsoftware

 

Betreuung und Beurteilung:

o.Univ.-Prof.Dr.Dr.h.c. Hanspeter Mössenböck

 

 

Linz, August 2009


Danksagung

Diese Arbeit wäre ohne die Mithilfe und Unterstützung vieler Kollegen und Freunde nicht möglich gewesen und ich möchte mich auf diesem Weg bei ihnen herzlich bedanken.

Ich möchte meinem Diplomarbeitsbetreuer, Herrn o.Univ.-Prof.Dr.Dr.h.c. Hanspeter Mössenböck, vielmals für seine Unterstützung und für seine Offenheit für neue Themen danken. Ein großes Lob gilt weiters meinen Arbeitskollegen bei der Firma MathConsult GmbH, die für mich während der Diplomarbeit sehr viele Aufgaben übernommen haben. Besonders bedanken möchte ich mich bei Frau Mag. Anita Hofer, die alle Aufgaben übernommen hat, für die ich keine Zeit mehr hatte und bei Herrn Dipl. Ing. Sascha Kratky, der mir stets mit gutem Rat zur Seite stand.

Auf keinem Fall auslassen darf ich meine Freunde, insbesondere jene die sich die Zeit und Muße genommen haben und einen (längeren) Blick in meine Diplomarbeit geworfen haben und mir noch ein paar Tipps auf dem Weg mitgegeben haben. In diesem Sinne möchte ich meinen Korrekturlesern Herrn Mag. Bernhard Rumpl, Herrn Dipl. Ing. Sascha Kratky, Herrn Dipl. Ing. Florian König und Herrn Dipl. Ing. Roland Schatz vielmals für ihren Einsatz danken.

Natürlich möchte ich auch Danke sagen für die Unterstützung und die Geduld die mir meine Familie insbesondere meine Schwester Sonja entgegenbrachten. Soni du warst wirklich eine tolle und dringend benötigte Hilfe.

Und schließlich möchte ich mich bei meinem Studienkollegen, Freund und, ich möchte sagen, bei meiner Antriebskraft Herrn Dipl. Ing. Johannes Straßmayr herzlich und aufrichtig für seine langjährige Freundschaft und Kameradschaft bedanken. Gasi ohne dich wär’s bei weitem nicht so schön gewesen! Vielen, vielen Dank, dass Du stets da warst, um aus meiner Studienzeit die beste und lehrreichste Zeit meines Lebens zu machen.

Kurzfassung

Die vorliegende Arbeit beschreibt die Resultate des Projekts TPTP-Web-TEST. Dieses Projekt beschäftigt sich mit dem Testen von HTML-basierte Webanwendungen. Ziel ist es, ein Werkzeug zu erstellen, das die Funktionalität einer alten Version einer Webanwendung mit der Funktionalität einer neuen Version vergleicht. Damit wird verhindert, dass durch Änderungen in der Webanwendung die bereits existierenden Funktionen fehlerhaft werden. Das in diesem Projekt erstellte Werkzeug bietet dazu folgende Dienste:

Das erstellte Testwerkzeug soll sich dabei von anderen Testwerkzeugen im gleichen Umfeld durch folgende Punkte unterscheiden:

Abstract

This paper presents the results of the project TPTP-Web-TEST. For this project a tool has been developed that supports the generation and the execution of tests for HTML-based web applications. This tool compares the functionality of an old version of a web application with the functionality of a new version. The goal is to prevent that a change in the software causes previously working functions to fail. The tool provides following features to support this:

The developed test tool differentiates itself from other test tools in the same environment by following features:

 

 

Inhaltsverzeichnis

1     Einleitung und Zielsetzung. 1

1.1        Problembeschreibung. 1

1.2        Ziel des Projekts TPTP-Web-TEST. 5

1.2.1           Die Anforderungen an Web-TEST. 6

1.3        Aufbau der Arbeit 9

1.3.1           Die Verwendung von Fachausdrücken, Abkürzungen und Fremdwörtern. 10

2     Methoden zum  funktionalen Testen von HTML-basierten Webanwendungen. 11

2.1        White-Box-Testing. 13

2.2        Black-Box-Testing. 14

2.3        Regressionstests von HTML-basierten Webanwendungen. 16

3     Die Verwendung von Web-TEST.. 18

3.1        Installation von Web-TEST. 19

3.2        Konfiguration von Web-TEST. 21

3.2.1           Testen des Agent-Controllers. 21

3.2.2           Konfiguration eines Browsers und eines Proxy-Ports. 23

3.2.3           Einstellen des Inhaltsfilters und Anlegen des Java-Projekts. 26

3.3        Ein Anwendungsfall für Web-TEST. 27

3.3.1           Aufzeichnen eines Tests. 28

3.3.2           Bearbeiten des aufgezeichneten Tests. 34

3.3.3           Erstellen von Assertions. 40

3.3.4           Bearbeiten der Assertions. 52

3.3.5           Festlegung von dynamischen Request-Parametern. 59

3.3.6           Abspielen des Tests und Kontrolle der Ergebnisse. 64

4     Das TPTP-Framework. 71

4.1        Die Architektur von TPTP.. 72

4.1.1           Integration von TPTP in Eclipse. 73

4.1.2           Die Komponenten von TPTP. 74

4.2        Das Platform-Projekt 75

4.2.1           Das TPTP-Execution-Environment 76

4.3        Das Test-Projekt 78

4.3.1           TPTP-JUnit-Test 79

4.3.2           TPTP-Manual-Test 81

4.3.3           TPTP-URL-Test 83

4.3.4           TPTP-Automated-GUI-Test 84

4.4        Die Datenverwaltung im TPTP-Test-Projekt 86

4.4.1           Das Modell der Testdefinition. 87

4.4.2           Das Modell des Testverhaltens. 89

4.4.3           Das Execution-History-Modell 94

5     Die Umsetzung von Web-TEST.. 96

5.1        Integration von Web-TEST in TPTP und Eclipse. 97

5.2        Die Aufteilung von Web-TEST in Eclipse-Plug-Ins. 98

5.3        Daten und Datenmodelle in Web-TEST. 102

5.3.1           Beispiel der Verwendung des Test- und Behavior-Modell in Web-TEST. 102

5.3.2           Das webtestData-Datenmodell 108

5.4        Die verwendeten TPTP-Erweiterungspunkte. 122

5.4.1           Die verwendeten Erweiterungspunkte im Web-TEST-UI-Plug-In. 122

5.4.2           Die verwendeten Erweiterungspunkte im Web-TEST-Core-Plug-In. 125

5.4.3           Die verwendeten Erweiterungspunkte im Web-TEST-Recorder-Plug-In. 129

5.5        Die angebotenen Erweiterungspunkte. 130

5.5.1           Die Erweiterungspunkte des Web-TEST-Models-Plug-Ins. 130

5.5.2           Der Erweiterungspunkt des Web-TEST-Core-Plug-Ins. 134

5.5.3           Die Erweiterungspunkte des Web-TEST-UI-Plug-Ins. 135

6     Ausblick und Schlussfolgerung. 137

6.1        Persönliche Schlussfolgerung. 138


1                          Einleitung und Zielsetzung

Die Idee für das Projekt TPTP-Web-TEST, im Folgenden kurz als Web-TEST bezeichnet, entstand durch den beruflichen Hintergrund des Autors der vorliegenden Arbeit. Der Autor, Günter Öller, ist als Webentwickler bei der Firma MathConsult GmbH [3] an der Entwicklung des Produkts UnRisk-FACTORY [4] beteiligt. UnRisk-FACTORY ist eine HTML-basierte Intranetanwendung. In dieser Webanwendung werden die HTML-Seiten von einem Webserver generiert. Im Folgenden wird diese Art von Anwendung als HTML-basierte Webanwendung bezeichnet.

UnRisk-FACTORY wird von Banken und anderen Finanzdienstleistern im Intranet eingesetzt, um den Wert von Finanzprodukten schätzen und überwachen zu können.

1.1                     Problembeschreibung

Bei der Entwicklung von UnRisk-FACTORY ist es in der Vergangenheit oft zu Problemen gekommen. Neue Versionen des Produkts enthielten Fehler, die in Vorgängerversionen bereits ausgebessert waren, was unter anderem zu einer Verschlechterung des Produktimages führte. Das Problem ist, dass es bei Änderungen eines Dienstes oft zu Fehlern in einem anderen Dienst kommt. Abbildung 1.1 veranschaulicht dieses Problem.

Dienst B

 

Abbildung 1.1: Unerkannter Fehler durch eine neue Version der Anwendung

Wie Abbildung 1.1 darstellt, kann es durch eine Änderung eines Dienstes A zu einem Fehler in einem darauf aufbauenden Dienst B kommen, obwohl B nicht geändert und deshalb vielleicht nicht neu getestet wurde. Um dem vorzubeugen, kann man ein Testverfahren verwenden, das die unveränderten Dienste einer neuen Version mit der Vorgängerversion vergleicht. Diese Art des Testens wird als Regressionstesten bezeichnet und im Kapitel 2.3Regressionstests von HTML-basierten Webanwendungen“ näher beschrieben.

Für UnRisk-FACTORY wurde aufgrund dieses Fehlertyps entschieden, dass Regressionstests durchgeführt werden müssen. Um dies zu bewerkstelligen, wurde eine Mitarbeiterin als Tester eingesetzt, um die Vergleiche manuell durchzuführen. Da sich diese Arbeit als sehr zeitaufwendig und für den Tester demotivierend herausstellte, wurde dem Autor dieser Arbeit die Aufgabe übergeben, ein unterstützendes Testwerkzeug zu suchen.

Zu diesem Zweck wurden, unter anderem, folgende Werkzeuge getestet:

Bei der Evaluierung dieser Werkzeuge wurden jedoch folgende Punkte als unzureichend festgestellt:

Zur Erklärung des letzten Punkts: UnRisk-FACTORY verwendet häufig HTML-Seiten mit einer zweispaltigen Tabelle wie in Abbildung 1.2 gezeigt, um Information anzuzeigen.

Abbildung 1.2: Zweispaltige Tabelle in UnRisk-FACTORY mit Attributen als Name-Wert-Paare

Wobei die erste Spalte den Namen eines Attributes und die zweite Spalte den dazugehörigen Wert enthält. Ein verwendbares Werkzeug muss diese Einheitlichkeit ausnützen und den Test für alle diese Attribute mit wenigen Schritten erstellen können. Eine bedeutende Randbedingung ist dabei, dass die Anzahl der nötigen Schritte nicht von der Anzahl der Zeilen in der angezeigten Tabelle abhängt.

Weiters wurden Werkzeuge getestet, die es erlauben, einen Schnappschuss einer HTML-Seite aufzuzeichnen und diesen Schnappschuss dann mit der Testausführung zu vergleichen. Dieser Bildvergleich hat jedoch den Nachteil, dass sich kein Parameter einer Seite ändern darf, damit der Tests erfolgreich verläuft. In UnRisk-FACTORY und in vielen ähnlichen Anwendungen wird jedoch ein Änderungsdatum angezeigt, dass sich von Testaufnahme zu Testausführung verändert.

Eine weitere Alternative sind Testwerkzeuge, die es gestatten, eine maximale Veränderungsrate anzugeben. Diese Rate gibt an, zu wie viel Prozent sich eine HTML-Seite von der Aufzeichnung zur Testausführung verändern darf. Leider wurde auch dieses Verfahren als unzulänglich für UnRisk-FACTORY eingestuft. Beim Testen von UnRisk-FACTORY ist es wichtig, den Wert bestimmter Felder genau zu überprüfen, andere Felder, wie etwa ein Änderungsdatum, sollen hingegen nicht überprüft werden.

Da keines dieser Werkzeuge überzeugen konnte, entschied sich MathConsult, die Tests weiter manuell durchzuführen. Der Autor dieser Arbeit wurde allerdings durch den Evaluierungsprozess auf die Eclipse-Test-Plattform TPTP aufmerksam. Dieses Framework bietet bereits die grundlegenden Dienste zum Durchführen von Regressionstests. TPTP unterstützt sowohl das Aufzeichnen von Verwendungsszenarien von HTML-basierten Webapplikationen, als auch das Verwalten und Abspielen dieser Szenarien. Im Wesentlichen fehlen lediglich die Funktionen, um Testbedingungen für den Inhalt von HTML-Seiten zu verwalten und diese während der Testausführung zu überprüfen. Da TPTP darauf ausgerichtet ist Erweiterungen zu ermöglichen, und der Quellcode unter der Eclipse-Public-Licence (EPL) [14] zur Verfügung steht, ist es möglich, die fehlenden Dienste hinzuzufügen. Aufgrund dieser Überlegung wurde das Projekt TPTP-Web-TEST gestartet.

1.2                     Ziel des Projekts TPTP-Web-TEST

Im Rahmen des Projekts TPTP-Web-TEST sollen drei Ziele miteinander vereint werden:

  1. Es soll ein Testwerkzeug für Regressionstests von HTML-basierten Webanwendungen erstellt werden. Das Unternehmen MathConsult GmbH soll durch dieses Werkzeug beim Regressionstesten der Anwendung UnRisk-FACTORY unterstützt werden.
  2. Das Testwerkzeug soll auch für andere HTML-basierte Webanwendungen einsetzbar sein und von den jeweiligen Benutzern angepasst werden können.
  3. Das Testwerkzeug soll sich in TPTP integrieren und neue Versionen von TPTP unterstützten. Deshalb muss die Entwicklung von Web-TEST mit dem TPTP-Team abgesprochen werden.

1.2.1                   Die Anforderungen an Web-TEST

Die Firma MathConsult benötigt ein Werkzeug, das den in Abbildung 1.3 dargestellten Anwendungsfall zum Testen von UnRisk-FACTORY unterstützt.

Abbildung 1.3: Geforderter Anwendungsfall für Web-TEST

Abbildung 1.3 zeigt, aus welchen Schritten der geforderte Testprozess besteht:

  1. Der Tester nimmt eine zu gewährleistende Funktionalität auf. Dazu spielt er diese Funktionen in der zu testenden HTML-basierten Webapplikation durch und lässt einen Prozess mitlaufen, der alles protokolliert.
  2. Der Tester bearbeitet den so erstellten Test. Er führt Variablen für die Testausführung ein und legt Testbedingungen für den Inhalt von HTML-Seiten fest.
  3. Ein Benutzer (der Tester selbst oder ein Entwickler) kann durch Umstellen der Applikations-URL den Test mit verschiedenen Versionen der Applikation abspielen.
  4. Nach der Beendigung einer Testausführung kann sich der Benutzer den Testbericht anzeigen lassen.

Wesentlich ist der Schritt 2, in dem die Testbedingungen erstellt werden. Gerade in diesem Punkt muss sich Web-TEST von den evaluierten Testwerkzeugen unterscheiden. Folgende Funktionen müssen angeboten werden:

Die letzte der beiden hier angesprochenen Funktionen hilft dem Tester von UnRisk-FACTORY außerordentlich. Wie zuvor schon erwähnt, zeigt UnRisk-FACTORY sehr viele Informationen über zweispaltige Tabellen an. Wobei jede Zeile eine Eigenschaft eines in UnRisk-FACTORY verwendeten Objekts beschreibt. Jede Eigenschaft hat einen Namen und einen Wert. Bei der Testausführung müssen dann die Objekteigenschaften die gleichen Werte wie bei der Testaufnahme haben.

                 

Abbildung 1.4: Objekteigenschaften einer Testvorlage und einer Testausführung in UnRisk Factory

Abbildung 1.4 zeigt zweimal den gleichen Ausschnitt einer HTML-Seite von UnRisk-FACTORY. Dabei wird auf der linken Hälfte der Zustand dargestellt, der in einer älteren UnRisk-FACTORY Version als richtig festgehalten wurde. Auf der rechten Hälfte wird der Zustand der HTML-Seite dargestellt, der beim manuellen Durchführen eines Regressionstests mit einer neuen Version von UnRisk-FACTORY angezeigt wird.  Wenn man die Zeilen der dargestellten Tabellen vergleicht, dann erkennt man, dass diese bis auf die Zeile „Modification Date“ identisch sind. Somit ist der manuelle Regressionstest erfolgreich verlaufen. Wenn man das tatsächlich und gewissenhaft macht, dann bemerkt man schnell, dass das manuelle Überprüfen der Werte sehr zeitaufwendig und fehleranfällig ist. Unter anderem fehleranfällig, weil man bei der großen Anzahl der Zeilen und den oft ähnlichen Werten leicht etwas übersieht. Weiters ist zu beachten, dass es hunderte verschiedene Objekttypen und damit hunderte dieser Tabellen in UnRisk-FACTORY gibt, die getestet werden müssen.

Die automatische Erzeugung der Testbedingungen aus der Testvorlage und der programmgesteuerte Vergleich während der Testausführung sind deshalb eine wesentliche Erleichterung für den Tester. Dabei wird nicht nur der Tester entlastet, sondern auch die Qualität des Tests gesteigert.

1.3                     Aufbau der Arbeit

Diese Arbeit beschreibt die Umsetzung der zuvor beschriebenen Anforderungen im Rahmen des TPTP-Web-TEST-Projekts und ist inhaltlich wie folgt aufgebaut:

§         In Kapitel 2Methoden zum  funktionalen Testen von HTML-basierten Webanwendungen“ werden die verwendbaren Testmethoden vorgestellt, und es wird festgelegt, welche Testmethode das Werkzeug Web-TEST verwendet.

§         In Kapitel 3Die Verwendung von Web-TEST“ wird das Werkzeug Web-TEST aus Benutzersicht vorgestellt. Mit Hilfe eines Anwendungsfalls wird demonstriert, wie ein Benutzer Web-TEST verwendet.

§         In Kapitel 4Das TPTP-Framework“ wird das von Web-TEST verwendete Eclipse-Test-Framework TPTP vorgestellt.

§         In Kapitel 5Die Umsetzung von Web-TEST“ werden die Umsetzung und die Schnittstellen von Web-TEST besprochen.

§         In  Kapitel 6Ausblick und Schlussfolgerung“ wird ein Überblick über mögliche Erweiterungen gegeben. Abschließend wird in diesem Kapitel die persönliche Einschätzung des Autors für das Werkzeug Web-TEST dargelegt.

1.3.1                   Die Verwendung von Fachausdrücken, Abkürzungen und Fremdwörtern

Gebräuchliche und in der Informatik übliche Fachausdrücke, Abkürzungen und Fremdwörter werden im Text nicht speziell gesetzt und es wird kein Glossar aller verwendeten Ausdrücke angeboten. Nicht gebräuchliche und in der Informatik unübliche Fachausdrücke, Abkürzungen und Fremdwörter werden bei ihrer ersten Verwendung im Text erklärt oder mit einem Literaturverweis versehen. Weiters werden diese Ausdrücke bei ihrer ersten Verwendung in kursiver Schrift gesetzt. Bei jeder weiteren Verwendung werden diese Ausdrücke nicht nochmals erklärt und sie werden dann nicht mehr speziell gesetzt. Zusammengesetzte Fremdwörter und Eigennamen werden mit Bindestrich dargestellt. Außerdem wird bei der ersten Übersetzung eines englischen Begriffs (beispielsweise aus Tabellen, Grafiken oder  von Fachbegriffe) die englische Form in Klammer nach der Übersetzung notiert. Diese Notation wird auch verwendet, wenn im Text Synonyme für Begriffe aus Tabellen und Grafiken benutzt werden. Namen von Elementen in grafischen Oberflächen (Labels), Ordnernamen, Pfade und Werte von Attributen aus Grafiken und Tabellen werden mit Hilfe von Anführungszeichen gekennzeichnet.

2                          Methoden zum  funktionalen Testen von HTML-basierten Webanwendungen

Das Testen von Webanwendungen stellt sich aufgrund der oft mehrschichtigen Architektur etwas komplexer dar als bei normalen Desktop-Anwendungen. Auch UnRisk-FACTORY ist eine mehrschichtige Webanwendung, wobei die in Abbildung 2.1 dargestellte dreischichtige Webarchitektur verwendet wird. 

Textfeld: Storage System

Abbildung 2.1: Die Standard-Drei-Schichten-Webarchitektur

Abbildung 2.1 zeigt die Standard-Drei-Schichten-Webarchitektur. Diese besteht aus Datenhaltung (Storage System), Geschäftslogik (Business Layer) und Webserver (Web Server). Die einzelnen Schichten sind hierarchisch angeordnet und voneinander abhängig. Daraus ergibt sich auch, dass ein stufenweises Testverfahren benötigt wird, um zuerst die Einzelkomponenten und später das Gesamtsystem testen zu könne.  Das Testen von Webanwendungen wird deshalb, wie bei komplexen Software-Projekten üblich, in mehrere Phasen unterteilt [1]:

  1. Test der Spezifikation (Requirement Testing): Testen der Spezifikation auf Widerspruchsfreiheit, Vollständigkeit und Klarheit.
  2. Modultest (Unit Testing): Testen von einzelnen Klassen und später Modulen für sich selbst.
  3. Integrationstest (Integration Testing): Testen des schrittweisen Zusammenfügens der einzelnen Module.
  4. Systemtest (System Testing): Testen des Gesamtsystems unter realen Bedingungen.
  5. Abnahmetest (Acceptance Testing): Ein Kunde oder ein Anwender testet das System gegenüber der Spezifikation. Gegebenenfalls werden dabei auch Änderungen an der Spezifikation durchgeführt.
  6. Regressionstest (Regression Testing): Diese Testphase wird bei der Weiterentwicklungen von Software verwendet. Dabei wird getestet, ob eine neue Version einer Software die Kontrakte der Vorgängerversion noch erfüllt.

In den einzelnen Phasen können verschiedene Testmethoden eingesetzt werden. Dabei unterscheidet man zwischen zwei Kategorien [1]:

Statische Testmethoden: Tests die ohne das Ausführen des zu testenden Programms - im Folgenden kurz als SUT (Software under test) bezeichnet – durchgeführt werden können. Beispiele dafür sind: Schreibtischtests, Code-Inspektionen, Walkthroughs und Checklisten.

Dynamische Testmethoden: Diese Tests führen das Programm tatsächlich aus. Dabei werden Ergebnisse und Parameter mit Vorgabewerten verglichen. Dynamische Testmethoden werden wieder in zwei große Klassen unterteilt: White-Box-Testing und Black-Box-Testing.

2.1                     White-Box-Testing

Das White-Box-Testing wird vor allem verwendet, um in frühen Phasen der Entwicklung das korrekte Verhalten einzelner Komponenten zu gewährleisten.

Abbildung 2.2: Das White-Box-Testing-Prinzip

In Abbildung 2.2 wird das Prinzip des White-Box-Testings dargestellt. Der Tester hat dabei die vollständige Information über die innere Struktur der Software. Deshalb wird diese Testmethode auch als strukturelles Testen bezeichnet. Auch die Auswahl der Testfälle wird mit Hilfe der Kenntnis der inneren Struktur durchgeführt. Dabei haben sich drei Alternativen etabliert [1]:

  1. Die Testfälle werden so ausgewählt, dass jede Anweisung zumindest einmal ausgeführt wird.
  2. Die Testfälle werden so ausgewählt, dass jede Bedingung zumindest einmal auf wahr und einmal auf falsch gesetzt ist.
  3. Die Testfälle werden so gewählt, dass jeder Pfad zumindest einmal ausgeführt wird.

Wobei die Alternative drei das „stärkere“ Auswahlkriterium für Testfälle ist. Diese Alternative bedeutet, dass unter anderem alle Schleifen bis zur maximalen Durchlaufsgrenze ausgeführt werden müssen. Da diese Bedingung oft zu unendlich vielen Testläufen führen würde, ist sie nicht vollständig realisierbar.

White-Box-Testing wird vor allem für das Unit-Testing verwendet. Dabei werden die Tests meist vom Entwickler selbst erstellt. Dieser hat Kenntnis über den zu testenden Quellcode. Das Prinzip dabei ist, zuerst die kleinsten Einheiten mit vollständiger Kenntnis des Quellcodes zu testen und dann kontinuierlich zu größeren Einheiten und dafür zu weniger Kenntnis der internen Struktur überzugehen. Schließlich kennt der Tester – nicht mehr der Entwickler selbst - nur mehr die Schnittsellen zwischen den einzelnen Komponenten und man hat die Integrationstestphase erreicht.

2.2                     Black-Box-Testing

Das Black-Box-Testing wird verwendet, um die Spezifikation und die Umsetzung zu vergleichen. Dabei ist keine Kenntnis der internen Programmstrukturen nötig [1].

Abbildung 2.3: Das Black-Box-Testing-Prinzip

In Abbildung 2.3 wird das Prinzip des Back-Box-Testings dargestellt. Der Tester überprüft, ob die Software die in der Spezifikation geforderten Aufgaben richtig erfüllt. Dabei wird keine Information über die innere Struktur der Software benötigt. Die Auswahl der Testfälle wird deshalb ausschließlich mit Hilfe der Spezifikation durchgeführt. Aus der Spezifikation werden alle benötigen Funktionen ermittelt und alle dafür möglichen Eingaben in Eingabeklassen eingeteilt. Für ein Ganzzahlenfeld würden standardmäßig folgende vier Eingabeklassen entstehen:

  1. Gültige Eingabe größer 0
  2. Gültige Eingabe gleich 0
  3. Gültige Eingabe kleinern 0
  4. Ungültige Eingabe

Theorietisch reicht es für jede der gültigen Eingabeklassen einen Testfall für die zu testenden Funktion zu erstellen. Es ist jedoch üblich zumindest drei Testfälle pro gültige Eingabeklasse zu erstellen. Dabei werden meist die untere und die obere Grenze der Klasse und ein Wert aus der Mitte der möglichen Werte genommen. Für die Klasse der ungültigen Eingaben gilt jedoch: je mehr Testfälle desto besser [1].

Black-Box-Testing hat drei wesentliche Vorteile gegenüber dem White-Box-Testing [1]:

Diesen Vorteilen stehen folgenden Nachteile des Black-Box-Testings gegenüber:

Es ist bei beiden Methoden wichtig, dass die erwarteten Testergebnisse vor der Testausführung festgelegt werden. Manchmal können die Ergebnisse von Testfällen direkt aus der Spezifikation beziehungsweise aus der Funktionsbeschreibung abgeleitet werden. Wenn dies nicht möglich ist, müssen die Ergebnisse von einem Orakel, entweder einem menschlichen Experten oder einem anderen Programm, vorhergesagt werden.

 

2.3                      Regressionstests von HTML-basierten Webanwendungen

Eine andere Methode um die erwarteten Ergebnisse vorhersagen zu können, bieten Tests, bei denen die erwarteten Ergebnisse durch eine Vorgängerversion der SUT festgelegt werden. Diese Art des Testens zählt zu der Kategorie der Regressionstests. Als Software-Regressionstests werden alle Software-Tests bezeichnet, die versuchen festzustellen, ob ein Kontrakt der Spezifikation, der in einer Vorgängerversion der SUT bereits erfüllt war, in der aktuellen Version noch erfüllt wird. [1]

Diese Methode nutzt dabei die Eigenschaft von Software-Produkten, dass von einer Version einer Software auf die nächste der Großteil der Spezifikation gültig bleibt. Deshalb können die Tests und die erwarteten Ergebnisse der Vorgängerversion übernommen werden. Im Endeffekt müssen nur mehr die Neuentwicklungen und die Änderungen die ersten fünf zuvor in Kapitel 2 beschriebenen Testphasen durchlaufen. Der Großteil der Spezifikation muss lediglich die bereits existierenden Regressionstests passieren. Mit Hilfe von Regressionstests kann also sehr viel Zeit eingespart werden.

Regressionstests können sowohl White-Box-Tests als auch Black-Box-Tests sein [2]. In der Regressionstestphase werden deshalb sowohl die bereits existierenden Unit-Tests als auch die automatisierten Abnahmetests ausgeführt.

Das in dieser Arbeit entwickelte Werkzeug Web-TEST unterstützt die Erstellung und Wartung von Regressionstests und die automatische Ableitung der erwarteten Ergebnisse aus einer Vorgängerversion der SUT  und kombiniert diesen Testansatz mit dem Black-Box-Testing-Prinzip. Web-TEST konzentriert sich also auf die Wiederverwendung der Abnahmetests.  Dabei wird vor allem auf folgende Punkte geachtet, um die Vorteile von Regressionstests und Black-Box-Testing auch wirklich an den Tester weitergeben zu können:

Dem Gegenüber stehen folgende Nachteile von Web-TEST und der Regressionstests im Allgemeinen:

3    Die Verwendung von Web-TEST

Dieses Kapitel betrachtet das Werkzeug Web-TEST aus der Sicht des Benutzers. Einleitend wird beschrieben, wie Web-TEST installiert und konfiguriert wird. Dann wird ein umfassender Anwendungsfall durchgespielt, der die wesentlichen Funktionen und Konzepte von Web-TEST darstellt.

Folgende Voraussetzungen sind für das Verständnis dieses Kapitels erforderlich:

3.1    Installation von Web-TEST

Für die Installation von Web-TEST ist eine vorhergehende Installation von Eclipse und TPTP 4.5.1 oder höher erforderlich. Näher Details zur Installation dieser Voraussetzung findet man unter [20]. Web-TEST steht als Eclipse-Feature zum Download unter https://sourceforge.net/projects/tptpwebtest/ zur Verfügung. Ein Eclipse-Feature ist eine Sammlung von Eclipse-Plugins, die nur in Kombination sinnvoll funktionieren. Das Eclipse-Feature für Web-TEST wird als Zip-Datei heruntergeladen. Die Zip-Datei muss dann in den Eclipse-Installationsordner entpackt werden, um die Installation fertig zu stellen. Dabei werden ältere Versionen von Web-TEST ersetzt. Danach muss Eclipse mit der Option „-clean“ neu gestartet werden, damit die Änderungen übernommen werden.

Nach der Installation wird im About-Eclipse-SDK-Dialog, zu finden im Menu „Help/About Eclipse SDK“, das Web-TEST-Icon  () angezeigt. Abbildung 3.1 zeigt diesen Dialog.

Abbildung 3.1: About-Eclipse-SDK-Dialog mit Web-TEST-Icon

Wenn man auf das Web-TEST-Icon klickt, bekommt man die Information, welche Eclipse-Features und –Plug-Ins zu Web-TEST gehören und unter welcher Lizenz Web-TEST verfügbar ist. Abbildung 3.2 zeigt den Dialog, der erscheint wenn man auf das Web-TEST-Icon klickt und Abbildung 3.3 zeigt den Dialog, der die Web-TEST-Plug-Ins auflistet.

Abbildung 3.2: About-Eclipse-SDK-Feature-Dialog für Web-TEST

Abbildung 3.3: Feature-Plug-Ins-Dialog für Web-TEST

Web-TEST kann ebenfalls über den Eclipse-Update-Manager [22] installieren werden. Die dafür nötige Eclipse-Update-Site ist unter http://tptpwebtest.sourceforge.net/ verfügbar.

Alle Funktionen von Web-TEST werden dem Benutzer über die Eclipse-Perspektive „Test“ zur Verfügung gestellt. Zu finden ist diese Perspektive, ausgehend von einer englischen Eclipse-Installation, unter dem Menu „Window/Open Perspective/Other …/Test“ ().

3.2    Konfiguration von Web-TEST

Bevor man jetzt einen Test erstellen kann, müssen einige Einstellungen gesetzt werden und ein Java-Projekt muss erzeugt werden. Diese Konfigurationen müssen nur einmal nach der Installation von Web-TEST durchgeführt werden.

Folgende Vorbereitungen sind notwendig:

3.2.1                   Testen des Agent-Controllers

Der Agent-Controller ist ein eigener Dienst, der vom TPTP-Framework zur Verfügung gestellt wird. Er wird von TPTP unter anderem zum Aufnehmen der Tests verwendet. Dieser Dienst muss auf dem Rechner, auf dem der Test aufgenommen werden soll, laufen. Deshalb muss man überprüfen, ob dieser Dienst auf diesem Rechner ausgeführt wird und richtig auf Anfragen reagiert. Dazu kann die Funktion „Test Connection“ in der Eclipse-Einstellungsseite „Test“ ausgeführt werden. Abbildung 3.4 zeigt die Eclipse-Einstellungsseite „Test“. Diese Eclipse-Einstellungsseiten findet man unter dem Menüpunkt „Window/Preferences“.

Abbildung 3.4: Testen des Agent Controllers

Die Antwort, die man nach klick auf den Link bekommt, muss der Nachrichtenbox in Abbildung 3.4 entsprechen. Es muss also der Text „Connection success.“ angezeigt werden. Im Fehlerfall lassen sich die Einstellungen für den Agent-Controller in der Einstellungsseite „Agent Controller/Integrated Agent Controller“ anpassen - wie in Abbildung 3.5 dargestellt.

Abbildung 3.5: Konfigurieren des Agent Controllers

Die genaue Konfiguration des Agent-Controllers ist Teil von TPTP und kann in der Dokumentation von TPTP unter [13] nachgelesen werden.

3.2.2                   Konfiguration eines Browsers und eines Proxy-Ports

Nach dem erfolgreichen Test des Agent-Controllers muss man Web-TEST bekannt geben welcher Browser für die Testaufzeichnung verwendet wird.

Abbildung 3.6: Konfiguration des Browser für die Testaufnahme

Diese Konfiguration kann auf der Einstellungsseite „Test/TPTP URL/URL Recorder“ durchgeführt werden. Die Abbildung 3.6 zeigt die Konfiguration des Mozilla-Firefox-Browsers zur Aufnahme. Weiters kann hier der Port für den Proxy-Dienst eingestellt werden. Der von TPTP vorgeschlagene Port ist 1080. Es kann jedoch jeder freie Port für diesen Dienst verwendet werden. Der Proxy-Dienst ist Teil des Agent-Controllers und wird zum Aufzeichnen eines Tests benötigt.

Abbildung 3.7: Der Proxy-Dienst zum Aufzeichnen von  Testdaten

Wie Abbildung 3.7 zeigt, wird der Proxy-Dienst zwischen dem Browser und der SUT geschoben und zeichnet alle Nachrichten auf.

Zu beachten ist, dass es Unterschiede in der Verwendung verschiedener Browser innerhalb von TPTP gibt. Beispielsweise werden die Proxy-Einstellungen im Internet-Explorer automatisch übernommen, während Firefox diese nicht übernimmt. Dafür hat der Internet-Explorer ein Problem, wenn auf den Server „localhost“ zugegriffen wird. In diesem Fall ignoriert er die Proxy-Einstellungen. Um dennoch eine Anwendung  auf „localhost“ aufzeichnen zu können, kann man sich mit dem Work-around „localhost.“ (sprich: „localhost-punkt“) abhelfen. In Firefox muss der Proxy hingegen manuell definiert werden und wird dafür auch bei „localhost“ verwendet.

Abbildung 3.8: Konfiguration des Proxies in Mozilla Firefox

Die Proxy-Einstellungen können in Firefox unter dem Menüpunkt „Extras/Einstellungen…/Erweitert/Netzwerk/Einstellungen…“ festlegt werden. In Abbildung 3.8 wird dargestellt, wie der Proxy für die Standardkonfiguration von Web-TEST eingestellt werden muss. Dabei wird ein „SOCKS v4“-Proxy auf „localhost“ und Port „1080“ eingetragen. Um den Proxy für andere Browser einzustellen kann die Hilfe des jeweiligen Browsers verwendet werden.

3.2.3                   Einstellen des Inhaltsfilters und Anlegen des Java-Projekts

Um unnötige Testdaten zu vermeiden kann ein Inhaltsfilter für das Generieren der Testressource in Web-TEST definiert werden. Beispielsweise ist es aufgrund der Eigenschaften der Assertions sinnvoll, nur HTML-Antworten zu speichern.

 

Abbildung 3.9: Content Filter

Abbildung 3.9 zeigt die Einstellungsseite „Test/Web-TEST“, in der dieser Filter definiert wird. In diesem Beispiel ist der Filter auf „text/html“ gesetzt. Dadurch werden nur die Requests, die HTML-Seiten als Antwort haben, in die TPTP-Testressource übernommen. Die TPTP-Testressource (oder kurz die Testressource) ist die Ressource, die die gesammelte Testbeschreibung enthält. Diese Ressource wird in TPTP durch eine XML-Datei realisiert.

Weiters zeigt Abbildung 3.9 drei weitere Eingabefelder: „Execution – Host“, „Execution – Port“ und „Execution – Context“. Diese können dazu verwendet werden, um bei der Testausführung den Host, den Port und den Kontext der Requests zu überschreiben. Dadurch kann der Tests auf eine andere Version der SUT (unter einer anderen URL als bei der Testaufnahme) ausgeführt werden.

Bevor man nun beginnen kann einen Test zu erstellen, muss man noch ein Java-Projekt anlegen. Dies ist erforderlich, weil die Testressource später in eine JUnit-Klasse umgewandelt wird, damit der Test ausgeführt werden kann. Für den hier folgenden Anwendungsfall wird das Java-Projekt „Demo_WebTEST“ benannt und alle anderen Standardeinstellungen des Java-Project-Wizards beibehalten. Der Java-Project-Wizard ist der Eclipse-Wizard der zum Anlegen von Java-Projekten verwendet werden kann.

Nun ist Web-TEST installiert und vollständig konfiguriert und kann verwendet werden.

3.3    Ein Anwendungsfall für Web-TEST

Der folgende Anwendungsfall stellt alle wesentlichen Funktion von Web-TEST vor. Üblicherweise durchläuft der Benutzer von Web-TEST sechs Phasen um eine HTML-basierte Webanwendung zu testen. Diese Phasen werden im Rahmen des Anwendungsfalls in einzelnen Unterkapiteln beschreiben:

  1. Aufzeichnen eines Tests.
  2. Bearbeiten des aufgezeichneten Tests.
  3. Erstellen von Bedingungen für das Ausführen des Tests (im Folgenden als Assertions bezeichnet).
  4. Bearbeiten der Assertions.
  5. Festlegung von dynamischen Request-Parametern. Siehe Kapitel 3.3.5 für eine detaillierte Erklärung der dynamischen Request-Parameter.
  6. Programmgesteuertes Abspielen des Tests (mit einer anderen Version der SUT) und automatische Kontrolle der Ergebnisse.

3.3.1                   Aufzeichnen eines Tests

Der Tester verwendet die SUT ganz normal, um einen Test aufzuzeichnen. Während der Verwendung der SUT läuft im Hintergrund ein Prozess, der alle Eingaben (Requests) und die darauf folgenden Ausgaben (Responses) aufzeichnet. Web-TEST bietet zum Steuern dieses Prozesses die Recorder-Ansicht (Recorder-Control). Diese wird in der Eclipse-Test-Perspektive im unteren Bereich der Benutzeroberfläche dargestellt.

Abbildung 3.10: Die Recorder-Ansicht

Abbildung 3.10 zeigt die Recorder-Ansicht nach einer erfolgreichen Aufnahme. Die beiden Buttons rechts oben ermöglichen es, eine Aufnahme zu starten () und zu stoppen (). Im Feld „KBytes Recorded“ wird die Größe der aufgenommen Daten angezeigt. Das Feld „Recorder Status“ zeigt den aktuellen Status der Aufnahme an und im darunter liegenden Textfeld werden detaillierte Statusnachrichten ausgegeben.

Abbildung 3.11: Der Testaufzeichnungs-Wizard erste Seite

Beim Starten der Aufnahme über den Button  der Recorder-Ansicht wird der in Abbildung 3.11 dargestellte Wizard aufgerufen. Dieser erlaubt auf der ersten Seite folgende Einstellungen:

  1. Testaufnahme: Soll der Test neu aufgenommen werden oder soll die Testressource mit Hilfe einer bereits existierenden Recorder-Datei erzeugt werden? Der Unterschied zwischen Recorder-Datei und Testressource wird gleich nach dieser Aufzählung erklärt.
  2. Recorder: Welcher Aufnahmedienst soll verwendet werden?
  3. Test-Generator: Welcher Test-Generator soll verwendet werden um eine TPTP-Testressource zu erstellen?

Der Recorder speichert die gesamte Kommunikation zwischen Browser und Web-Server(n) in einer Recording-Datei. Eine Recorder-Datei enthält alle aufgenommenen Nachrichten, und aus ihr kann die Testressource generiert werden. Nach der Testaufnahme stehen also zwei Dateien zur Verfügung: die Recorder-Datei mit allen Nachrichten in einem speziellen Trace-Datenschema [35], das in TPTP Standard ist für jegliche Test- und Messdatenaufzeichnung, und die daraus abgeleitete Testressource. Der Test-Generator ist für die Generierung der Testressource aus der Recorder-Datei verantwortlich.

Für diesen Anwendungsfall müssen, wie in Abbildung 3.11 dargestellt, folgende Einstellungen gewählt werden:

Der von Web-TEST angebotene „TPTP Web TEST Generator“ hat den Vorteil, dass er auch die Antworten der Web-Servers, also die HTTP-Responses (im Folgenden kurz als Response bezeichnet), behandelt und sie in die erstellte Testressource einbaut. Der „TPTP URL Test Generator“ zeichnet hingegen keine Responses auf.

Abbildung 3.12: Der Testaufzeichnungs-Wizard zweite Seite

Als nächstes wird man nach einem Speicherort und einem Namen für die Testressource gefragt. Abbildung 3.12 stellt diesen Dialog dar. Nachdem man beides ausgewählt hat, kann man mit dem Button „Finish“ den Wizard beenden und die Testaufzeichnung wird gestartet. Dabei wird der zuvor eingestellte Browser automatisch gestartet. Dieser darf jedoch vorher noch nicht ausgeführt werden. Nun kann der Test in der SUT durchgespielt werden. Abbildung 3.13 veranschaulicht die Testaufzeichnung für dieses Szenario. Der Benutzer verwendet dabei die SUT wie üblich, während der Recorder im Hintergrund alle Anfragen (Requests) und Antworten (Responses) aufzeichnet.

Abbildung 3.13: Verwendung der SUT während der Testaufzeichnung

 Für dieses Szenario wurde die Anwendung UnRisk-FACTORY in der Version 1.2.12 (siehe [2]) verwendet. Die im nächsten Teil dieses Kapitels verwendete Aufnahme kann wie folgt nachgestellt werden:

  1. Aufruf der Seite http://www.unrisk.com/unriskfactory/pages/admin/overview.do im Browser
  2. Login mit Benutzername „oeller“ und Passwort „oeller“.
  3. Klicken des Links „Instruments“ im horizontalen Menu oben.
  4. Klicken des Links „IR Types/Average Rate Floaters“ im vertikalen Menu links.
  5. Danach erscheint eine Tabelle im zentralen Bereich. In der Zeile, in der die Spalte „Name“ den Wert „Test WebTEST1“ enthält, muss rechts auf den „Details“-Link geklickt werden.
  6. Dann wird eine zweispaltige Tabelle angezeigt, die alle Eigenschaften des ausgewählten Objekts darstellt.
  7. Klicken des Links „Edit“ rechts oberhalb der Tabelle.
  8. Nun erscheint wieder eine Tabelle, die es erlaubt, die Eigenschaften des Objekts zu ändern.
  9. Ändern des Felds ISIN auf „Test WebTEST_1“ anstelle von „Test WebTEST1“.
  10. Die Änderungen durch betätigen des Buttons „Save Changes“ bestätigen.
  11. Jetzt erscheint wieder die erste Tabelle, und man muss wieder auf den „Details“-Link in der Zeile „Test WebTEST1“ klicken.
  12. Daraufhin erscheinen wieder alle Eigenschaften des Objekts. Die Eigenschaft „ISIN“ muss den neuen Wert „Test WebTEST_1“ haben.
  13. Zuletzt noch über den Link „Logout“, äußerst rechts oben, ausloggen.

Sobald man fertig ist mit dem Durchspielen des Tests, kann man den Browser schließen. TPTP erkennt dann je nach Browser entweder automatisch, dass der Test beendet wurde, oder man muss noch den Stopp-Button () der Recorder-Ansicht betätigen. Danach wird der gewählte Test-Generator gestartet. Dieser generiert, aus den vom Proxy-Dienst aufgenommen Daten, die Testressource und öffnet den Web-TEST Assertion-Editor, wie in Abbildung 3.14 dargestellten.

Web-TEST-Editor-Actions

 

Abbildung 3.14: Der Assertion-Editor

In Abbildung 3.14 ist durch die leere Tabelle im linken unteren Teil der Editor-Seite erkennbar, dass für die erstellte Testressource noch keine Assertions generiert wurden. Der Assertion-Editor ist ein Multi-Page-Editor und bietet weitere Seiten an, um Assertions zu erstellen und zu bearbeiten. Zusätzlich zu den Funktionen zum Bearbeiten von Assertions, die im Kapitel 3.3.4 näher behandelt werden, bietet der Assertion-Editor folgende drei Editor-Actions (Buttons die in Eclipse speziell für einen Editor-Typ oberhalb des Editor-Fenster angezeigt werden – siehe auch Abbildung 3.14) an:

Diese Aktionen stehen im Werkzeugmenu rechts oberhalb des Assertion-Editors als Buttons zur Verfügung (siehe Abbildung 3.14). Die Buttons sind nur aktiv, falls ein Web-TEST-Editor den Fokus besitzt.

3.3.2                   Bearbeiten des aufgezeichneten Tests

Mit Hilfe der Change-Web-TEST-Editor-Aktion des Assertion-Editors kann auf den Test-Editor gewechselt werden. Dort kann man sich die vom Recorder erstellte Testressource ansehen und sie bearbeiten.

Testressource-Übersicht und Java-Code-Verzeichnis bearbeiten

Abbildung 3.15: Die  Overview-Seite des Test-Editors

Man wird dabei auf die „Overview“-Seite des Test-Editors geleitet. Hier sieht man einen Überblick der aufgenommenen Requests. Abbildung 3.15 zeigt, dass neun Requests trotz Inhaltsfilter in die Testressource übernommen wurden. Diese Requests sind rechts unter der Überschrift „HTTP Requests“ zu sehen. Die Namen der Requests werden aus einer fortlaufenden Nummer, der Art des Requests (GET oder POST) und dem Titel der darin enthaltenen HTML-Seite zusammengesetzt. Weiters bietet die „Overview“-Seite die Möglichkeit festzulegen wo der später zu generierende Java-Quellcode gespeichert wird. Dazu kann man unter „Source Folder“ den Quellcodeordner des Java-Projekts, unter „Package Name“ den Paket-Namen und unter „Class Name“ den Klassennamen angeben. In diesem Szenario werden, wie in Abbildung 3.15 dargestellt, die Werte „Demo_WebTEST/src“, „org.eclipse.tptp.web.test.demo“ und „Demo_WebTEST“ verwendet. Um gegebenenfalls den Java-Code zu generieren, wird im Test-Editor die Generate-JUnit-Code-Aktion () angeboten. Das Erstellen des Java-Codes wird in diesem Anwendungsfall erst durchgeführt, nachdem alle nötigen Änderungen in der Testressource gemacht wurden. Beschrieben wird das Erzeugen des Java-Codes deshalb im Kapitel  3.3.6Abspielen des Tests und Kontrolle der Ergebnisse“.

Bearbeiten der Requests

Abbildung 3.16: Test-Editor-HTTP-Requests-Seite

Die zweite Seite des Test-Editors, die „HTTP Requests“-Seite,  bietet die Übersicht und Detailansicht aller aufgenommenen Requests. Abbildung 3.16 zeigt links oben nochmals die neun aufgenommen Request. Diese können hier gelöscht, umgereiht oder neue hinzugefügt werden. Die Details des markierten und damit aktiven Requests, hier der Request „2 POST Admin Overview“, werden links unten unter „General Information“ und rechts unter „Detailled Porperties“ dargestellt. Dabei folgende Eigenschaften des aktiven Requests angezeigt und können editiert werden:

Festlegen der Ausführungsreihenfolge der Requests

Wichtig ist hier anzumerken, dass die Reihenfolge der definierten Requests noch keine Auswirkung auf die Reihenfolge während der Testausführung hat. Die Ausführungsreihenfolge wird auf der Seite „Behavior“ des Test-Editors festgelegt (siehe Abbildung 3.17).

Abbildung 3.17: Test-Editor-Behavior-Seite

Als Standardreihenfolge wird die gleiche Reihenfolge verwendet, die auch aufgezeichnet wurde. In Abbildung 3.17 wird die Standardreihenfolge für diesen Anwendungsfall dargestellt. Es ist mit Hilfe der „Behavior“-Seite möglich, Requests umzureihen, Requests mehrmals zu verwenden oder gar nicht. Weiters können über den Button „Insert…“ Schleifen (Loops) definiert werden, um einen oder mehrere Requests vielfach auszuführen. Eine Schleife ist dabei ein spezieller Knoten im Baum der selber wieder Kinder haben darf.

Bearbeiten eines Responses

Die nächste Seite „Ref. Response Overview“ zeigt den Response des aktiven Request. Der aktive Request ist der Request der auf der Seite „HTTP Requests“ ausgewählt ist. Es gibt jedoch unter dem Punkt „Test Case Navigation“, die Möglichkeit die Auswahl des aktiven Requests zu ändern. In Abbildung 3.18 ist die „Ref. Response Overview“-Seite dargestellt und der Punkt „Test Case Navigation“ findet sich links oben. Auch in den Seiten „HTML Browser“, „DOM Browser“ und „BA Browser“ des Test-Editors findet man die „Test Case Navigation“-Komponente. Jede dieser Seiten des Test-Editors stellt den aktiven Response auf eine spezielle Weise dar.

 

Abbildung 3.18: Test-Editor-Ref.-Response-Overview-Seite

Die „Ref. Response Overview“-Seite erlaubt es weiters, die Eigenschaften eines Responses zu betrachten, zu ändern und den Inhalt des aktiven Responses über die Aktion „Replace response body from file...“ zu ersetzten. Die angezeigten Eigenschaften des Responses sind:

Weiters wird links unter der Überschrift „Associated Assertions“ eine Übersicht von Assertions angezeigt. Diese Assertions beziehen sich auf den dargestellten Response. Zurzeit wurde noch keine Assertion für diesen Response erstellt, deshalb wird in Abbildung 3.18 noch kein Eintrag angezeigt.

3.3.3                   Erstellen von Assertions

Assertions lassen sich auf benutzerfreundliche Weise mit Hilfe der übrigen Seiten des Test-Editors erzeugen. Bevor dieser Anwendungsfall sich mit dem Erstellen von Assertions beschäftigt, muss zuerst der Aufbau einer Assertion erklärt werden. Eine Assertion ist ein Container, der Kriterien enthält. Die Kriterien enthalten wiederum Basiskriterien. Abbildung 3.19 zeigt den Aufbau von Assertions und verwendet dazu die in der Web-TEST-Oberfläche verwendete Benennung der Elemente.

Abbildung 3.19: Der hierarchische Aufbau von Assertions

Basiskriterium (Basic Criterion)

Das Basiskriterium ist die kleinste Einheit und wird durch einen Namen, einem Wert und einem Vergleichsoperator definiert. Ein Basiskriterium enthält im Wesentlichen den Wert nach dem gesucht wird. Je nach Typ des einschließenden Kriteriums wird dieser Wert in einem anderen Teil des Responses gesucht. Beispiel für ein Basiskriterium: Name=“HTML-Seiten-Titel“, Wert=“Administration“ und Vergleichoperator=“Equals“.

Kriterium (Criterion)

Ein Kriterium ist eine Zusammenstellung von ein oder mehreren Basiskriterien und zusätzlichen Eigenschaften. Die zusätzlichen Eigenschaften gelten für alle enthaltenen Basiskriterien. Kein Basiskriterium eines Kriteriums darf fehlschlagen, damit das Kriterium erfüllt ist. 

Mit Hilfe von verschiedenen Kriterientypen ist es möglich einen Response auf verschiedene Arten zu untersuchen. In der aktuellen Version von Web-TEST  werden drei Arten von Kriterien unterstütz:

Die Details der einzelnen Kriterientypen werden im Kapitel 3.3.4Bearbeiten der Assertions“ erklärt.

Assertion

Eine Assertion ist die Beschreibung, wann welche Kriterien überprüft werden müssen. Dazu können einer Assertion, wie in Abbildung 3.19 dargestellt, eine Menge von Kriterien zugeteilt werden und außerdem können zu testende Funktionen, also Requests, zugeteilt. Falls nun ein zugeteilter Request während einer Testausführung abgespielt wird, dann wird die Assertion aktiviert und alle darin enthaltenen Kriterien werden mit dem folgendem Response verglichen. Eine Assertion kann aus 0 bis n Kriterien und 0 bis n zugeteilten Requests bestehen, wobei n theoretisch unbegrenzt ist. Wenn eine Assertion ausschließlich Kriterien eines Kriterientyps enthält, dann wird diese Assertion im Folgenden nach diesem Typ benannt. Als Beispiel: eine Assertion die nur Text-Kriterien enthält, wird auch als Text-Assertion bezeichnet.

Erstellen von Text-Assertions

Um eine Text-Assertion erstellen zu können, wechselt man auf die Seite „HTML Browser“ des Test-Editors. Hier wird der aktive Response in einem HTML-Browser dargestellt. Da der Browser nicht mit der SUT verbunden ist, sondern auf einer lokalen Kopie des Responses arbeitet, können Bilder- und Stylesheet-Dateien nicht geladen werden.

Web-TEST-Editor-Actions

 

Abbildung 3.20:  Die HTML-Browser-Seite des Test-Editors

Wie in Abbildung 3.20 dargestellt, kann Text direkt im Browser markiert werden. Der markierte Text kann dann verwendet werden, um für den aktiven Request eine Assertion zu erstellen. Dazu bietet der Test-Editor die Aktion Create-Assertion (). Abbildung 3.20 zeigt diese Aktion direkt neben der Generate-JUnit-Code-Aktion ()  rechts oberhalb des Test-Editors an.

Abbildung 3.21: Der Automatic-Assertion-Generation-Dialog für eine Text-Assertion

Nach betätigen der Create-Assertion-Aktion ()  erscheint ein Informationsdialog, wie er in Abbildung 3.10 dargestellt ist. Dieser Dialog zeigt noch einmal die Eigenschaften der zu erstellenden Assertion. Dabei werden folgende Informationen geliefert:

In diesem Beispiel wird also ein Text-Kriterium mit genau einem Basiskriterium erzeugt. Das Basiskriterium wird auf den Wert „Administration“ gesetzt. Das Text-Kriterium wird einer neuen Assertion mit dem Namen „Browser View Assertion 0“ zugeteilt. Weiters wird der aktive Request mit dieser Assertion verknüpft. Abbildung 3.22 zeigt nochmals grafisch den Aufbau der Assertion „Browser View Assertion 0“.

Abbildung 3.22: Aufbau der Assertion "Browser View Assertion 0"

Diese Assertion sucht bei der Testausführung in der HTML-Seite des Responses (des Requests) „2 POST Admin Overview“ den Text „Administration“. Wird dieser Text irgendwo in der HTML-Seite gefunden, dann ist die Assertion erfolgreich.

Um diese Assertion automatisch erstellen zu lassen, muss man nur den angezeigten Dialog bestätigt. Wenn man anschließend wieder auf die Seite „Ref. Response Overview“ zurück geht, erkennt man das in der Tabelle „Associated Assertions“ die Assertion „Browser View Assertion 0“ eingetragen ist.

Erstellen von XPath-Assertions

Um eine Assertion für den Wert eines bestimmten XPath-Ausdrucks zu erstellen, wechselt man auf die Seite „DOM Browser“. Hier kann man Assertion erstellen die beispielsweise überprüfen, ob ein bestimmte Überschrift in einer HTML-Seite einen bestimmten Wert hat.

Abbildung 3.23: Die DOM-Browser-Seite des Test-Editors

In Abbildung 3.23 wurde mittels Auswahl aus dem DOM-Baum ein bestimmtes Element ausgewählt und der XPath-Ausdruck automatisch dafür generiert. Es ist genauso möglich einen XPath-Ausdruck anzugeben und daraus die Selektion im Baum zu generieren. Auf der rechten Seite wird dann in einem Browser und zusätzlich in einem Textfeld das Ergebnis der Ausführung des XPath-Ausdrucks im Response angezeigt. Auch für XPath-Assertions steht wieder die Create-Assertion-Aktion ()  zur Verfügung.

Abbildung 3.24: Der Automatic-Assertion-Generation-Dialog für eine XPath-Assertion

Wie Abbildung 3.24 darstellt, erstellt diese Aktion, wenn sie aus der „DOM Browser“-Seite aufgerufen wird, eine XPath-Assertion. Diese Assertion überprüft bei der Ausführung, ob im Response der XPath-Ausdruck „/html[1]/body[1]/div[5]/h1[1]“ ausgewertet werden kann und dabei der Wert „\r\n\tAdministartion\r\n\t“ geliefert wird. Wie man erkennen kann, sind mit Hilfe dieses Kriterientyps bereits deutlich restriktivere Bedingungen möglich. Erstens muss das Element „/html[1]/body[1]/div[5]/h1[1]“ im DOM-Baum existieren und zweitens muss genau dieses Element den gesuchten Wert enthalten.

Wenn man nun den in Abbildung 3.24 dargestellten Dialog bestätigt und dann wieder auf die Seite „Ref. Response Overview“ wechselt, sieht man das jetzt zwei Assertions dem aktiven Request zugeordnet sind.

Erstellen von BA-Assertions

Die dritte Art von Kriterien dient dazu, zu testen, ob eine Anzahl von Attributen beziehungsweise Elementen mit richtigem Namen und Wert auf einer HTML-Seite vorkommen. Beim Erstellen eines BA-Kriteriums wird versucht, aus der HTML-Seite eines aufgezeichneten Responses eine Liste von Elementen zu extrahieren. Ein Element kann dabei alles sein, das einen Namen und einen Wert besitzt und Name und Wert mittels eines bestimmten Muster gefunden werden. BA-Kriterien verwenden zum Extrahieren der Elemente, ihrer Namen und ihrer Werte aus dem Response XPath-Ausdrücke. Im Gegensatz zum XPath-Kriterium werden allerdings für ein BA-Kriterium drei XPath-Ausdrücke benötigt.

  1. Der XPath-Ausdruck für das Element (Get Element): Dieser Ausdruck wählt aus dem Response alle zu betrachtenden Elemente aus. Wie schon zuvor erwähnt wird das Element noch in einen Namen und einem Wert zerlegt. Wobei der Wert auch leer sein darf.
  2. Der XPath-Ausdruck für den Namen (Extract Name): Dieser Ausdruck wird auf jedes gefunden Element angewendet um den Namen zu extrahieren.
  3. Der XPath-Ausdruck für den Wert (Extract Value): Dieser Ausdruck liefert den Wert des Elements.

Die Kombination aus diesen drei Ausdrücken wird als BA-Muster (BA-Expression) bezeichnet. Die Elemente, die mit Hilfe eines BA-Musters gefunden werden, werden als Business-Attribute-Instances (BAIs) bezeichnet. Abbildung 3.25 zeigt die “BA Browser”-Seite. Auf dieser Seite wurde der aktive Response („5 Get Average Rate Floater Details“) bereits mit dem in der Abbildung dargestellten BA-Muster analysiert. Deshalb sind in der Tabelle auf der rechten oberen Hälfte unter der Überschrift „BA Expression Results“  bereits BAIs dargestellt. In der Tabelle der oberen Hälfte werden Namen und Werte der BAIs als Text dargestellt. Da diese jedoch wieder HTML-Elemente enthalten können, werden in einem HTML-Browser-Feld darunter alle Elemente nochmals dargestellt, wie sie in einem Web-Browser angezeigt werden.

Abbildung 3.25: Die BA-Browser-Seite des Test-Editors nach Auswahl des Templates „UnRisk Detail Table Template“

Um den in Abbildung 3.25 dargestellten Zustand herzustellen, müssen folgende drei Schritte durchgeführt werden:

  1. Mit Hilfe der „Test Case Navigation“, muss der aktive Request auf „5 GET Average Rate Floater Details“ gesetzt werden.
  2. Danach muss in der Combo-Box „Use Template“ das BA-Template „UnRisk Detail Table Template“ ausgewählt werden. Dabei werden die XPath-Ausdrücke für Element, Name und Wert ausgefüllt. Ein BA-Template ist ein vordefiniertes BA-Muster mit einem Namen.
  3. Schließlich kann der Button „Extract from Response“ verwendet werden, um die Elemente beziehungsweise die BAIs des aktiven Responses zu extrahieren. Dabei werden die BAIs in eine Tabelle und in einem HTML-Browser auf der rechten Hälfte der Test-Editor-Seite eingetragen.

Nun ist es möglich, eine BA-Assertion generieren zu lassen, die das eingestellte BA-Muster und die im aufgenommen Response gefunden BAIs verwendet. Dazu steht wieder die Create-Assertion-Aktion () zur Verfügung.

Abbildung 3.26: Der Automatic-Assertion-Generation-Dialog für eine BA-Assertion

Wie Abbildung 3.26 darstellt, wird mit dieser Aktion in diesem Kontext eine BA-Assertion erstellt. Diese Assertion überprüft bei der Ausführung, ob im Response das BA-Muster ausgewertet werden kann und alle Elemente mit den richtigen Werten in der korrekten Reihenfolge gefunden werden. Bei der Testausführung müssen also alle Werte, wie sie in der BAI-Tabelle von Abbildung 3.25 dargestellt sind, gefunden werden. Zum Erstellen der BA-Assertion wird aus jedem BAI der BAI-Tabelle von Abbildung 3.25 ein Basiskriterium erstellt und mit dem BA-Kriterium der Assertion verknüpft. Das BA-Kriterium enthält das zu prüfenden BA-Muster. Diese BA-Assertion wird nun automatisch durch bestätigen des Dialogs in Abbildung 3.26 erstellt. Eine detaillierte Erläuterung des BA-Kriteriums folgt in Kapitel 3.3.4Bearbeiten der Assertions“. Dort wird unter anderem auch gezeigt, wie man unerwünschte BAIs wieder aus dem Kriterium entfernt.

BA-Templates

Im Laufe der Verwendung des BA-Musters in Web-TEST wurde eine wichtige Entdeckung gemacht: Man benötigt nur eine kleine Menge von verschiedenen BA-Mustern, um nahezu alle Responses einer speziellen SUT analysieren zu können. Folgende Eigenschaften von HTML-basierten Webanwendungen können dafür verantwortlich gemacht werden:

  1. HTML verwendet standardisierte Elemente zur Darstellung und Eingabe von Werten wie etwa Input- und Select-Felder. Informationen werden etwa oft in zweispaltigen Tabellen im zentralen Bereich der Ansicht dargestellt. Wobei die erste Spalte meist den Titel und die zweite Spalte den Inhalt der Information darstellt. Auch UnRisk-FACTORY verwendet dieses Schema wie in der Einleitung schon gezeigt.
  2. Webanwendungen verwenden meist für alle HTML-Seiten ein einheitliches Schema. Die Struktur der Informationen auf den verschiedenen HTML-Seiten ist also identisch.

Durch Eigenschaft 1 ist es möglich allgemeine BA-Muster zu definieren und diese für alle Responses, in denen beispielsweise Input-Felder vorkommen, zu verwenden. Das BA-Muster für Input-Felder sieht immer gleich aus und kann deshalb als BA-Template in Web-TEST vordefiniert werden. Weiters ermöglicht Punkt 2, dass ein BA-Muster für viele HTML-Seiten einer bestimmten SUT verwendet werden kann. Web-TEST ermöglicht es deshalb, zusätzliche BA-Templates zu definieren. Dadurch erspart man sich die Eingabe der drei XPath-Ausdrücke beim Eingeben eines BA-Musters. Im Beispiel von Abbildung 3.25 wurde bereits eines dieser vordefinierten Templates („UnRisk Detail Table Template“), das speziell auf die Informationsdarstellung von UnRisk-FACTORY eingestellt wurde, verwendet.

Abbildung 3.27: Konfiguration von BA-Templates

Abbildung 3.27 zeigt die drei von Web-TEST Version 1.0 standardmäßig vordefinierten BA-Templates. Zu finden ist die Eclipse-Einstellungsseite zum Verwalten der BA-Templates unter dem Menu „Window/Preferences …“ und dem Pfad „Test/Web-TEST/Business Attribute Criterion“. Hier können die BA-Templates geändert, erstellt oder gelöscht werden. Zusätzlich zu dem BA-Muster kann man auch noch einen Namen, eine Beschreibung sowie Skip-Names (Skip-Attribute-Names) angeben. Skip-Names sind Namen von Elementen die ignoriert werden sollen. Diese Skip-Names werden ausschließlich im  BA-Assertion-Generation-Wizard () verwendet.

Der BA-Assertion-Generation-Wizard

Der BA-Assertion-Generation-Wizard wird über die gleichnamige Aktion aufgerufen. Die Aktion steht sowohl im Assertion- wie auch im Test-Editor zur Verfügung.

Abbildung 3.28: Der BA-Assertion-Generation-Wizard

Abbildung 3.28 zeigt den BA-Assertion-Generation-Wizard. Der Wizard kann zur automatischen Generierung einer Menge von BA-Assertions verwendet werden. Auf der linken Seite werden alle Requests in einer Tabelle angezeigt. Auf der rechten Seite werden alle vordefinierten BA-Templates und die zugeordneten Requests in einem Baum angezeigt.

Die Requests können mit dem „Add Selected >>“-Button zum aktuellen BA-Template im Baum zugeordnet werden. Das aktuelle Template wird dabei in der Mitte des Wizards oben unter der Bezeichnung „Actual Template:“ angezeigt und kann durch Auswahl eines anderen Knotens im Baum geändert werden.

Weiters kann über den Button „Add All Matching >>“ ein Dienst aufgerufen werden, der alle sinnvollen Kombinationen von Requests und BA-Templates in den Baum rechts einträgt. Dabei wird jedes BA-Template in jedem aufgenommenen Response ausgeführt. Wenn zumindest ein Element im Response gefunden wird, dessen Name nicht in den Skip-Namen des BA-Templates enthalten ist, dann wird der zugehörige Request zu dem verwendeten BA-Template im Baum eingetragen. In Abbildung 3.28 wurde dieser Button bereits benützt und alle sinnvollen BA-Assertions werden vorgeschlagen. Hinweis: Da für den Request „5 GET Average Rate Floater Details“ bereits manuell eine BA-Assertion erstellt wurde, ist es sinnvoll, diesen Request mittels „<< Remove Selected“-Button wieder aus dem Baum zu entfernen.

Darauf hin kann mit „Finish“ der Vorschlag bestätigt und der Wizard beendet werden. Dabei erscheint eine Meldung, dass die Testressource im Dateisystem geändert wurde. Diese Meldung muss mit „Yes“ bestätigt werden, damit alle Änderungen in der Testressource gespeichert werden. Schließlich wird man auf die „Behavior“-Seite des  Test-Editors geleitet.

3.3.4                   Bearbeiten der Assertions

Nachdem man mit Hilfe des Test-Editors die nötigen Assertions angelegt hat, kann man im Assertion-Editor die Assertions überprüfen und sie noch anpassen. Dazu verwendet man wieder die Aktion Change-Web-TEST-Editor (), um diesmal vom Test-Editor auf den Assertion-Editor zu wechseln. Dabei wird man auf die, in Abbildung 3.29 dargestellte, „Assertion Overview“-Seite des Assertion-Editors geleitet.

Die Übersicht der Assertions in der Testressource

Abbildung 3.29: Die Assertion-Overview-Seite des Assertion-Editors

Man sieht nun alle erzeugten Assertions in einer Tabelle links unten in der „Assertion Overview“-Seite. Abbildung 3.29 zeigt, dass in diesem Szenario fünf Assertions angelegt wurden. Von den Namen der Assertions kann abgeleitet werden, aus welcher Seite des Test-Editors diese erstellt wurden. Eine Assertion wurde von der „HTML Browser“-Seite, eine von der „DOM Browser“-Seite, eine von der „BA Browser“-Seite aus erstellt. Die beiden übrigen Assertions wurden durch den BA-Assertion-Generation-Wizard angelegt. Diese werden mit dem Namen „Auto Assertion“ und einer laufenden Nummer gekennzeichnet.

Man kann nun die Details der einzelnen Assertions auf der rechten Seite betrachten und editieren. In Abbildung 3.29 ist die Assertion „Browser View Assertion 0“ ausgewählt und man sieht, dass sie aus einem Text-Kriterium („Browser View Text Criterion 0“) besteht und dass diese Assertion dem Request „2 POST Admin Overview“ zugeteilt wurde.

Bearbeiten von Text-Kriterien

Auf der Seite „Text Criterion“ kann  man das verwendete Text-Kriterium weiter bearbeiten. Abbildung 3.30 zeigt diese Seite mit den Details des Kriteriums „Browser View Text Criterion 0“.

Abbildung 3.30  Die Text-Criterion-Seite des Assertion-Editors

Auf dieser Seite können Text-Kriterien erstellt, gelöscht und bearbeitet werden. Ein Text-Kriterium hat einen Namen, eine Beschreibung und eine Menge von Basiskriterien. Weitere Basiskriterien können hinzugefügt, entfernt und editiert werden. Für Basiskriterien von Text-Kriterien kann man folgende Eigenschaften festlegen:

Bearbeiten von XPath-Kriterien

Auch die XPath-Kriterien können auf ähnliche Weise gewartet werden. Hierfür steht die Seite „XPath Criterion“, wie in Abbildung 3.31 gezeigt, zur Verfügung.

Abbildung 3.31: Die XPath-Criterion-Seite des Assertion-Editors

Auf dieser Seite können XPath-Kriterien erstellt, gelöscht und bearbeitet werden. Ein XPath-Kriterium hat einen Namen, eine Beschreibung, einen XPath-Ausdruck (XPath-Expression) und eine Menge von Basiskriterien. Auch hier können Basiskriterien hinzugefügt, entfernt und editiert werden. Für Basiskriterien von XPath-Kriterien kann man folgende Eigenschaften festlegen:

Als Datentyp stehen „String“, „Integer“ oder „Double“ zur Verfügung. Weiters werden folgende Vergleichsoperatoren unterstützt: „Equals“, „Not Equal“, „Less Than“, „Greater Than“, „Contains“ und „Doesn’t Contain“.

Bearbeiten von BA-Kriterien

Schließlich können auch BA-Kriterien auf der Seite „Business Att. Criterion“ bearbeitet werden. Abbildung 3.32 zeigt diese Seite mit den BA-Kriterien, die im Rahmen des Anwendungsfalls bereits erstellten wurden.

Abbildung 3.32: Die BA-Criterion-Seite des Assertion-Editors

Mit Hilfe der linken Hälfte der Seite können BA-Kriterien erstellt, gelöscht und bearbeitet werden. Ein BA-Kriterium hat einen Namen, eine Beschreibung, ein BA-Muster, einen Schalter „Test Business Attribute Sequence“  und eine Menge von Basiskriterien, die in diesem Rahmen wieder als „Business Attribute Instances“  (BAIs) bezeichnet werden. Der Schalter „Test Business Attribute Sequence“ garantiert, dass bei der Testausführung die BAIs in der gleichen Reihenfolge gefunden werden, wie sie im BA-Kriterium definiert sind. Wieder können Basiskriterien hinzugefügt, entfernt und editiert werden.

Weiters gibt es auch über den Punkt „Business Attribute Auto Generation“ die Möglichkeit, automatisch zusätzlich Basiskriterien zu einem BA-Kriterium hinzuzufügen. Ähnlich wie in der Abbildung 3.25, die die BA-Browser-Seite des Test-Editors beschreibt, kann man auch hier wieder ein BA-Template und einen Request wählen. Man kann aus diesem Request alle Elemente extrahieren, die dem angegebenen BA-Muster entsprechen. Für die Basiskriterien (die BAIs) von BA-Kriterien gelten die gleichen Eigenschaften wie für die Basiskriterien von XPath-Kriterien, mit der Ausnahme, dass keine Beschreibung eingegeben werden kann. Üblicherweise sind hier nach der automatischen Generierung über den Punkt „Business Attribute Auto Generation“, über die „BA Browser“-Seite des Test-Editors oder über den  BA-Assertion-Generation-Wizard kaum mehr Änderungen nötig da beispielsweise auch der Vergleichoperator mit dem Standardwert „Equals“ vorbelegt wird.

Abbildung 3.32 zeigt auch, dass in dem Szenario vier BA-Kriterien erzeugt wurden. Wobei am Namen der Kriterien erkennbar ist, dass drei der Szenarien vom BA-Assertion-Generation-Wizard (Name der Assertions fängt mit „Auto BA“ an) und eines aus der „BA Browser“-Seite („BA View Criterion 0“) erzeugt wurden.

Wenn man nun die Liste der BAIs des BA-Kriteriums „BA View Criterion 0“ betrachtet, dann findet man dort die beiden Einträge „Creation Date“ und „Modification Date“. Diese Elemente sind in den Skip-Namen des BA-Templates enthalten und sind deshalb in den durch den Wizard erzeugten BA-Kriterien nicht mehr enthalten. Die „BA Browser“-Seite ignoriert jedoch die Skip-Namen eines BA-Templates, weshalb diese BAIs in der „BA View Criterion 0“ noch enthalten sind. Normalerweise werden BA-Kriterien  für die es schon ein BA-Template gibt mit dem  BA-Assertion-Generation-Wizard erzeugt und die „BA Browser“-Seite wird lediglich zum Testen neuer BA-Templates verwendet.

Es ist sehr wahrscheinlich, dass sich das „Modification Date“ in der von dem BA-Kriterium „BA View Criterion 0“  getesteten HTML-Seite beim späteren Abspielen des Tests ändert. In diesem Fall bekommt man eine Meldung, dass dieses Kriterium nicht erfüllt wird. Im Regelfall werden deshalb die Attribute, die sich ändern dürfen, aus der Liste der BAIs entfernt. Dies kann mit dem „Remove“-Button neben der BAI-Tabelle erledigt werden.

In diesem Anwendungsfall soll auch gezeigt werden, was passiert, wenn eine Assertion nicht erfüllt wird. Deswegen wird hier die BAI mit dem Namen „Currency“ auf einen Wert gesetzt, der bei der Testausführung nicht gefunden werden kann. Dazu kann einfach die BAI „Currency“ aus der Tabelle ausgewählt werden und der „Compare Value“ von „EUR“ auf „USD“ umgestellt werden.

Abbildung 3.33: Ändern des Werts des Currency-BAIs auf "USD"

Abbildung 3.33 zeigt diese Änderung im BA-Kriteriums „BA View Criterion 0“. Beim Ausführen des Tests wird nochmals darauf hingewiesen, dass mit Absicht eine Assertion erzeugt wurde, die einen Fehler liefern muss. Es wird auch gezeigt, dass Web-TEST diesen Fehler richtig erkennt.

3.3.5                   Festlegung von dynamischen Request-Parametern

Neben der Definition von Assertions können im Assertion-Editor auch dynamische Request-Parameter erstellt werden. Diese Parameter können beispielsweise eingesetzt werden, um lange Transaktionen zu unterstützen. Als lange Transaktionen bezeichnet man im Bereich von Webanwendungen Transaktionen, die mehrere Request benötigen. UnRisk-FACTORY verwendet lange Transaktionen etwa für das Editieren von Objekten. Dabei werden beim Erzeugen einer HTML-Seite, die zum Editieren eines Objekts dient, bereits alle Objekteigenschaften am Webserver gespeichert. Dem Benutzer wird dann die HTML-Seite mit einem zusätzlichen, versteckten Identifikationsfeld gesendet. Der Wert des Identifikationsfelds referenziert die am Webserver gespeicherten Objektdaten. Wenn der Benutzer von UnRisk-FACTORY seine Änderungen bestätigt, dann wird dieser Wert in den Bestätigungs-Request aufgenommen und an den Server gesandt. Der Server kann so auf die bereits gespeicherten Daten zugreifen und die neuen Änderungen eintragen. Das Problem beim Abspielen ist, dass der Wert des Identifikationsfelds am Webserver beim Aufnehmen nicht der gleiche ist wie beim Abspielen. Der Bestätigungs-Request kann also beim Abspielen nicht mehr den gespeicherten Wert des Identifikationsfeldes verwenden, sondern muss den neuen Wert des Webservers verwenden.

Web-TEST löst dieses Problem mittels dynamischer Request-Parameter. Dynamische Request-Parameter werden mit Hilfe eines Response-Value-Selectors aus einem Response gelesen und durch einen Request-Value-Selector in einem folgenden Request verwendet. Ein Response-Value-Selector definiert einen XPath-Ausdruck, der einen Wert aus dem Response extrahiert.  Ein Request-Value-Selector definiert einen Request-Parameternamen, als dessen Wert der zuvor gefundene Wert verwendet werden soll. Abbildung 3.34 zeigt die Definition eines Response-Value-Selectors.

Abbildung 3.34: Die Value-Selector-Seite des Assertion-Editors

Um den in Abbildung 3.34 dargestellten Zustand nachzustellen, muss man mit dem Button „New…“ einen neuen Value-Selector anlegen. Dabei wird als Standardtyp „Response“ ausgewählt. Danach muss man einen XPath-Ausdruck festlegen. In diesem Beispiel muss „//input[@name='responseUID']/@value“ eingegeben werden. Als  Referenz-Response (Reference-Response) muss „6 GET Modify Average Rate Floater“ ausgewählt werden. Mit Hilfe dieses Response-Value-Selectors wird im Response nach einem Input-Feld mit Namen „responseUID“ gesucht. Um den Response-Value-Selector in einem Referenz-Response zu testen, kann der „Refresh“-Button verwendet werden. Dabei wird der gefunden Wert links unten im Punkt „Test Value Selector“ angezeigt.

Um nun einen dynamischen Request-Parameter für das Feld „responseUID“ erzeugen zu können, muss noch ein Request-Value-Selector erstellt werden. Dazu klickt man wieder auf den „New …“-Button, wählt als Typ „Request“ aus und stellt als Referenz-Response „7 POST Show Average Rate Floaters“ ein. Schließlich wählt man als Request-Parameternamen (Request-Parameter) „responseUID“ aus.

UnRisk-FACTORY benötigt jedoch noch einen zweiten Parameter mit Namen „SUId“ um eine lange Transaktion durchführen zu können. Man kann hier nach dem gleichen Schema wie für „responseUID“ vorgehen, um Response- und Request-Value-Selector zu erzeugen.

Es gibt jedoch eine benutzerfreundlichere Alternative um den Response-Value-Selector zu erzeugen, wobei man sich die Eingabe des XPath-Ausdrucks erspart. In Abbildung 3.23, auf der „DOM-Browser“-Seite, sieht man eine zusätzliche Editor-Aktion: Generate-Response-Value-Selector  (). Diese Aktion erlaubt es, direkt aus der „DOM Browser“-Seite einen Response-Value-Selector zu erstellen. Man geht dabei genauso vor, wie wenn man eine XPath-Assertion erstellen möchte. Abbildung 3.35 zeigt den Informationsdialog, den man beim Erstellen des Response-Value-Selectors für das Feld „SUId“ bekommt, wenn man die Generate-Response-Value-Selector-Aktion verwendet.

Abbildung 3.35: Der Automatic-Value-Selector-Generation-Dialog

Wie der Dialog zeigt, muss ein XPath-Ausdruck mit dem Wert „//input[@name='SUId']/@value“ verwendet werden, um den Response-Value-Selector zu erstellen. Außerdem muss der Request „6 GET Modify Average Rate Floater“ ausgewählt werden. Zuletzt muss noch im Assertion-Editor der Request-Value-Selector für das Feld „SUId“ angelegt werden, bevor die für UnRisk-FACTORY nötigen dynamischen Request-Parameter erstellt werden können. Abbildung 3.36 zeigt die Einstellungen dieses Request-Value-Selectors für das Feld „SUId“. Weiters zeigt diese Abbildung alle vier benötigten Value-Selectoren in der Tabelle links oben.

Abbildung 3.36: Die Value-Selector-Seite des Assertion-Editors mit den benötigen Value-Selectoren

Mit Hilfe dieser Value-Selectoren können nun dynamischen Request-Parameter für die Felder “responseUID” und “SUId” angelegt werden. Wie schon zuvor erwähnt, werden diese beiden Parameter von UnRisk-FACTORY benötigt, um lange Transaktionen bei der Testausführen abspielen zu können. Diese Parameter können jetzt auf der Seite „Parameter“ erstellt werden. Abbildung 3.37 zeigt die beiden Parameter, die für dieses Szenario definiert werden müssen.

Abbildung 3.37: Die Parameter-Seite des Assertion-Editors

Ein neuer Parameter wird mit Hilfe des Buttons „New …“ angelegt und seine Eigenschaften können dann editiert werden. Mit dem Button „Refresh“ kann überprüft werden, welche Werte aus den aufgezeichneten Referenz-Requests und -Responses der zugrundeliegenden Value-Selectoren gelesen beziehungsweise ersetzt werden.  Die „Parameter“-Seite bietet folgende Felder an, um die Eigenschaften eines dynamischen Request-Parameters festzulegen:

Die in Abbildung 3.37 dargestellten Parameter müssen mit den in Tabelle 31 dargestellten Werten befüllt werden.

Parameter

Eigenschaft

Parameter 0

(für „responseUID”)

Parameter 1

(für „SUId”)

Response-Value-Selector

Value-Selector-0

(=Response-Value-Selector für „responseUID”)

DOM View Value Selector 0

 (=Response-Value-Selector für „SUId”)

Request-Value-Selector

Value-Selector-1

(=Request-Value-Selector für „responseUID”)

Value-Selector-2

(=Request-Value-Selector für „SUId”)

Aquired from Responses

6 GET Modify Average Rate Floater

6 GET Modify Average Rate Floater

Used in Requests

7 POST Show Average Rate Floaters

7 POST Show Average Rate Floaters

Tabelle 31: Die  Werte der Request-Parameter für die Parameter „responseUID“ und „SUId“

3.3.6                   Abspielen des Tests und Kontrolle der Ergebnisse

Das Test-Szenario ist jetzt vollständig definiert. Bevor man den Test jedoch abspielen kann, muss man noch den zur Testausführung benötigten Java-Code erzeugten. Wie schon zuvor erwähnt, wird in Web-TEST für jede Testressource eine eigene JUnit-Test-Klasse erzeugt, weil dies dem von TPTP vorgegebenen Schema entspricht.

Automatisches Erzeugen des Java-Code

Dazu kann die Generate-JUnit-Code-Aktion () verwendet werden, die bereits in Kapitel 3.3.1Aufzeichnen eines Tests“ vorgestellt wurde. Beim Aufruf dieser Aktion erscheint ein Dialog zum Einstellen des Quellcode-Verzeichnisses. Diese Einstellungen wurde schon im Kapitel 3.3.2  Bearbeiten des aufgezeichneten Tests“ im Test-Editor vordefiniert. Deshalb kann der Dialog einfach bestätigt werden. Nun wird eine Java-Klasse mit dem Namen „Demo_WebTEST“ im Packet „org.eclipse.tptp.web.test.demo“ erzeugt. Diese Java-Klasse ist eine ausführbare Ableitung der Testressource.

Um zu kontrollieren, ob der Java-Code erzeugt wurde, kann man in die Eclipse-Perspektive „Java“ wechseln. Abbildung 3.38 zeigt wie das Projekt „Demo-WebTEST“ nun aussehen muss. In der Abbildung ist auch die Datei „Demo_WebTEST.java“ erkennbar, die den generierten Test-Quellcode enthält.

Abbildung 3.38: Die Package-Explorer-Ansicht des Projekts „Demo_WebTEST“.

Ausführen des Tests

Bevor man den Test nun ausführt, muss die SUT noch in den dafür nötigen Ausgangszustand gebracht werden. Normalerweise werden dazu Datenbank-Backups verwendet, um die Anwendung auf den Zustand vor der Testaufzeichnung zurückzusetzen. Für dieses kurze Szenario kann man die Änderungen auch manuell rückgängig machen. Dazu sind folgende Schritte durchzuführen:

  1. Browser starten.
  2. Aufruf der Seite http://www.unrisk.com/unriskfactory/pages/admin/overview.do im Browser.
  3. Login mit Benutzername „oeller“ und Passwort „oeller“.
  4. Klicken des Links „Instruments“ im horizontalen Menu oben.
  5. Klicken des Links „IR Types/Average Rate Floaters“ im vertikalen Menu links.
  6. Danach erscheint eine Tabelle im zentralen Bereich, und in der Zeile, in der die Spalte „Name“ den Wert „Test WebTEST1“ enthält, muss rechts auf den „Edit“-Link geklickt werden.
  7. Nun erscheint wieder eine Tabelle, die es erlaubt, die Eigenschaften des Objekts zu ändern.
  8. Ändern des Felds ISIN auf „Test WebTEST1“ anstelle von „Test WebTEST_1“.
  9. Die Änderungen durch betätigen des Buttons „Save Changes“ bestätigen.
  10. Zuletzt noch über den Link „Logout“, äußerst rechts oben, ausloggen.
  11. Den Browser wieder schließen.

 Nun ist die SUT, hier UnRisk-FACTORY, wieder im gleichen Zustand, wie vor der Aufnahme des Tests.  Der Test kann also ausgeführt werden und sollte die gleichen Ergebnisse liefern. Zum Ausführen wechselt man wieder in die „Test“-Perspektive. Dort sieht man links die Test-Navigator-Ansicht. In dieser kann man mit einem Klick der rechten Maustaste über dem Element „Demo_WebTEST/Web-TEST Suite/Demo_WebTEST“ das Kontextmenu öffnen. Im Kontextmenu muss die Aktion „Run As/Test“ ausgewählt werden. Darauf hin wird dem Benutzer der in Abbildung 3.39 dargestellt Fortschrittsdialog angezeigt.

Abbildung 3.39: Die Ausführung des Tests

Während des Ausführens des Tests werden alle Requests, wie sie in der „Behavior“-Seite des Test-Editors definiert wurden, abgespielt. Wenn zu einem Request eine Assertion zugeteilt wurde, dann wird der Response dieses Request mit der Assertion verglichen und eine Statusmeldung wird erzeugt. Weiters werden zusätzlich noch alle einzelnen Vergleichsresultate der Kriterien und Basiskriterien in das Testprotokoll abgespeichert. Auch die dynamischen Request-Parameter werden aus den Responses gelesen und in den Requests verwendet. Am Ende erhält man ein Testprotokoll mit dem Namen der Testressource. In Abbildung 3.39 wird im Test-Navigator oberhalb der Testressource bereits das Protokoll unter dem Namen „Demo_WebTEST“ und dem Icon  angezeigt. Das Fragezeichen bedeutet, dass die Testausführung noch nicht fertig ist und noch kein Entscheid über Erfolg oder Misserfolg gegeben werden kann.

Kontrolle der Ergebnisse

Das Testprotokoll kann durch einen Doppelklick auf die neu hinzugekommen Testprotokoll-Ressource “Demo_WebTEST”  geöffnet werden. Zum Öffnen wird, wie in Abbildung 3.40 dargestellt,  der TPTP-Testprotokoll-Editor verwendet.

Abbildung 3.40: Das Testprotokoll im Testprotokoll-Editor

Dieser Editor zeigt auf der Seite „Events“, welche Requests erfolgreich waren (Verdict=“successful“), welche nicht ausgeführt werden konnten (Verdict=“error“) und welche Requests eine Assertion nicht erfüllen konnten (Verdict=“fail“). In diesem Anwendungsfall wurde nur eine Assertion nicht erfüllt und zwar im Request „5 GET Average Rate Floater Details“. Um herauszufinden, warum die Assertion nicht erfolgreich erfüllt wurde, kann der Text im Textfeld „Text“ des Testprotokoll-Editors in einen Texteditor oder in die „Console“-Ansicht von Eclipse kopiert werden. Quelltext 3.1 zeigt einen Ausschnitt dieser Meldung an.

 

junit.framework.AssertionFailedError: No Success Verdicts!

Failure Verdicts:

Assertion Exectuion Result:

Assertion [id=-64663237:120568d644e:-7fd5, name='BA View Assertion 0', description='Auto Generated Assertion from BA View for BA expresseion: BA Expression [elements: //table[@class='details']//tr, name: th, value: td]', genericCriterions=[...]]

Assertion Execution: Failure

Reason:

1.) Criterion 'Currency' not found!

Criterion 'Name' found!

Criterion 'ISIN' found!

Criterion 'Comment' found!

Execution Text:

1.) Failure: Attribute 'Currency' could not match value 'USD' in response. Instead found value 'EUR'

Success: Attribute 'Name' matched value 'Test WebTEST1' in response!

Success: Attribute 'ISIN' matched value 'Test WebTEST1' in response!

Success: Attribute 'Comment' matched value 'test Web-TEST Inst1' in response!

 

Quelltext 3.1: Auszug aus dem Testprotkoll für den Request „5 GET Average Rate Floater Details“

Dabei wird der Status aller Assertions, Kriterien und Basiskriterien des aktuellen Requests („5 GET Average Rate Floater Details“) angegeben. Bei fehlgeschlagenen Basiskriterien wird auch der genaue Grund für das Fehlschlagen angegeben. Im Quelltext-Ausschnitt  ist die Fehlermeldung für das Feld „Currency“ fett gesetzt.  

Im Kapitel 3.3.4Bearbeiten der Assertions“ wurde bereits festgestellt, dass für den betroffenen Request ein BA-Kriterium mit dem Wert „USD“ für das Element „Currency“ überprüft wird, und dass dieses bei der Testausführung einen Fehler liefern muss. Web-TEST erkannte also diesen Fehler.

Das Schema des Testprotokolls und der Testprotokoll-Editor werden von TPTP definiert. Nähere Information können in der TPTP Dokumentation [12] nachgelesen werden. Im Rahmen einer späteren Version von Web-TEST ist geplant, den Testprotokoll-Editor zu erweitern, um dem Benutzer eine bessere Übersicht der nicht erfüllten Assertions zu liefern. Diese Erweiterung ist jedoch nicht mehr Teil dieser Arbeit.

4    Das TPTP-Framework

Die Eclipse Test-and-Performance-Tools-Platform (TPTP) bietet in erster Linie ein Framework für die Entwicklung von Test- und Performanzwerkzeugen auf Basis von Eclipse. Zusätzlich werden in TPTP auch vorgefertigte Werkzeuge für spezielle Testzwecke bereitgestellt. Angefangen von Werkzeugen für statische Codeanalysen und funktionale Tests, bis zu Laufzeitanalysen,  Systemüberwachung und Performanztests. Aufgrund dieser zwei Ebenen von TPTP, einerseits als Testplattform und andererseits als Testwerkzeug, wird in TPTP auch zwischen zwei Zielgruppen unterschieden: Kunden und Anwender.

Abbildung 4.1: Die Zielgruppen und Verwendung von TPTP

Abbildung 4.1 stellt diese beiden Zielgruppen und ihre Rollen in TPTP dar. Als Kunden (Customer) werden dabei Personen oder Unternehmen bezeichnet, die mit Hilfe des TPTP-Frameworks neue Testwerkzeuge entwickeln. Als Anwender (User) werden Personen und Unternehmen bezeichnet, die eine SUT mit Hilfe von TPTP überwachen oder testen.

Weiters zeigt Abbildung 4.1, dass TPTP auf Eclipse basiert. Schließlich ist in der Abbildung noch dargestellt, dass die TPTP-Kunden zum Entwickeln von Testwerkzeugen auch die TPTP-Dienste verwenden können. Diese zusätzlichen Dienste werden in Form von Erweiterungspunkten und Datenmodellen zur Verfügung gestellt. Erweiterungspunkte sind Schnittstellen zum Hinzufügen neuer Funktionen in Eclipse oder in einem Eclipse-Plug-In. Mit Hilfe dieser Erweiterungspunkte können TPTP-Kunden das von TPTP angebotene Framework erweitern, um relativ einfach neue Test- und Überwachungswerkzeuge zu erstellen. Durch die Verwendung von TPTP können die verschiedenen erstellten Testwerkzeuge auch interagieren. Um dies zu bewerkstelligen, verwenden sie unter anderem die standardisierte Datenmodelle und Ablaufprozesse von TPTP.

TPTP selbst bietet, wie zuvor schon erwähnt, bereits einige Test- und Performanzwerkzeuge und kann daher auch ohne zusätzliche Erweiterungen verwendet werden, um eine Software zu testen beziehungsweise zu überwachen. Das vorrangige Ziel der in TPTP integrierten Werkzeuge ist allerdings, zu demonstrieren wie TPTP erweitert wird. Die Werkzeuge sind deshalb teilweise nicht für den produktiven Einsatz vorgesehen. Hier wird jedoch eindeutig die Zielsetzung von TPTP hervorgehoben: eine Plattform für Dritte bereit zu stellen, die es erlaubt, Test- und Performanzwerkzeuge zu erstellen, die dann durch gemeinsame, standardisierte Modelle und Verfahren miteinander kommunizieren können [13].

4.1                     Die Architektur von TPTP

TPTP steht unter einer freien Lizenz, der Eclipse-Public-License (EPL), zur Verfügung und kann daher sowohl für kommerzielle Projekte als auch für Projekte im Open-Source-Bereich eingesetzt werden. Die Benutzeroberfläche von TPTP basiert auf Eclipse beziehungsweise der Eclipse Rich-Client-Platform (RCP) [22]. Weiters wird mit Hilfe des Eclipse-Modeling-Framework (EMF) [23] eine standardisierte Programmierschnittstelle für die in TPTP verwendeten Datenmodelle angeboten. Es werden viele weitere Eclipse-Dienste von TPTP benützt und die Installation von Eclipse ist deshalb eine Voraussetzung für TPTP.

4.1.1                         Integration von TPTP in Eclipse

Abbildung 4.2: Eclipse Top-Level-Projekte (vergleiche [2] Seite 3)

Abbildung 4.2 zeigt die Eclipse Top-Level-Projekte, wie diese in der Präsentation „Eclipse Test & Performance Tools Platform (TPTP) Project – Project Structure“ [24]  von Tyler Thessin, dem Leiter des TPTP-Projekt-Teams, aufgelistet werden. Diese Präsentation zeigt unter anderem, dass TPTP zu den Top-Level-Projekten zählt. Dadurch wird festgelegt, dass TPTP den Eclipse-Entwicklungszyklus mitmacht. Es steht also für eine aktuelle Eclipse-Version immer auch eine passende TPTP-Version zur Verfügung.

4.1.2                         Die Komponenten von TPTP

Abgerundetes Rechteck: TestAbgerundetes Rechteck: Trace and ProfileAbgerundetes Rechteck: MonitoringAbgerundetes Rechteck: BIRT Reporting

Abbildung 4.3: Die Komponenten von TPTP (siehe [6] Seite 16)

Wie Abbildung 4.3 darstellt, besteht TPTP aus fünf Teilen, die in weitgehend voneinander unabhängige Projekte gegliedert sind. Die dargestellten Projekte erfüllen folgende Aufgaben:  

Die in der Abbildung 4.3 grün markierten TPTP-Projekte, das Platform-Projekt und das Test-Projekt, sind erforderlich für die Erweiterung durch Web-TEST und werden im Folgenden näher beschrieben.

4.2                     Das Platform-Projekt

Das Platform-Projekt stellt standardisierte Datenmodelle, allgemeine Infrastrukturdienste, Datensammlungs- und Kommunikationsdienste, sowie ein Execution-Environment zur Verfügung. Das Execution-Environment erlaubt es, Dienste auf entfernten Rechnern auszuführen und zu steuern und wird im Kapitel 4.2.1Das TPTP-Execution-Environment  näher beschrieben. Weiters stellt das Platform-Projekt Eclipse-Erweiterungspunkte und auch Execution-Environment-Erweiterungspunkte zur Verfügung. Wie zuvor schon erwähnt, basiert die gesamte Datenverarbeitung der TPTP-Projekte auf den im Platform-Projekt definierten Datenmodellen. Dabei werden folgenden Datenmodelle im Platform-Projekt definiert:

Besonders interessant im Zusammenhang mit Web-TEST ist das Test-Datenmodell. Dieses wird deshalb in einem eigenen Kapitel 4.4Die Datenverwaltung im TPTP-Test-Projekt“ noch näher erklärt. Das Platform-Projekt stellt auch die EMF-basierte Programmierschnittstelle für die Datenmodelle bereit. Die eigentliche Speicherung der Daten erfolgt dabei in einer XML-Datei, die zur effizienteren Speichernutzung komprimiert wird.

4.2.1                         Das TPTP-Execution-Environment

Das Execution-Environment von TPTP wird sowohl für die Aufzeichnung von URL- und Automatischen-GUI-Tests als auch für das Abspielen aller Testtypen verwendet. Das Execution-Environment wird auch in den anderen TPTP-Projekten für diverse Remote-Dienste verwendet. Im Trace-And-Profiling-Projekt dient es zum Aufzeichnen der Log-Daten, im Monitoring-Projekt liefert es die zu überwachenden Werte und kann Einstellungen und Kommandos an die SUT übermitteln, und im Test-Projekt wird es wie gesagt zum Aufzeichnen und zum Abspielen der Tests verwendet.

Abgerundetes Rechteck: Workbench MachineAbgerundetes Rechteck: Target Machine

Abbildung 4.4: Das TPTP-Execution-Environment (vergleiche dazu [19] auf Seite 30)

Abbildung 4.4 zeigt den gesamten Aufbau des TPTP-Execution-Environments:

Der Remote-Agent-Controller (RAC) und der Integrated-Agent-Controller (IAC)

Der Agent-Controller ist ein eigener Prozess und steht in zwei Ausführungen, als Remote-Agent-Controller (RAC) und als Integrated-Agent-Controller (IAC), zur Verfügung. Der RAC unterstützt die Ausführung und Überwachung von Agenten auf entfernen Rechnern und muss separat auf dem Ziel-Rechner installiert werden. Eine detaillierte Beschreibung der Installation des RAC findet man unter [27]. Der IAC wird hingegen automatisch mit TPTP installiert und kann Agenten auf dem lokalen Rechner ausführen. In Kapitel 3.3.1Aufzeichnen eines Tests“ wurde bereits die Konfiguration dieses internen Agent-Controllers angesprochen. Der Proxy-Dienst, der zur Aufnahme des Web-TEST-Tests im gezeigten Anwendungsfall diente, ist ein Agent, der vom IAC gesteuert wurde. Der IAC-Prozess wird dabei automatisch bei Bedarf von TPTP gestartet.

In den beiden Agent-Controllern, IAC und RAC, sind bereits Standard-Agenten für einige Dienste, wie etwa zum Abspielen eines Tests, vorinstalliert. Das Execution-Environment selbst muss deshalb von Web-TEST nicht mehr erweitert werden. Eine detaillierte Beschreibung des Execution-Enviornments wird somit in dieser Arbeit nicht benötigt, ist jedoch unter [13] verfügbar.

4.3                     Das Test-Projekt

Das Test-Projekt stellt Agenten zur Verfügung, um Tests aufnehmen und ausführen zu können sowie Dienste zum Editieren von Testdefinitionen. Standardmäßig werden vier Testtypen unterstützt:

Der Autor dieser Arbeit testete für die Firma MathConsult diese vier Testtypen. Dabei wurde versucht, Regressionstests für die Webanwendung UnRisk-FACTORY zu erstellen. Keiner dieser Testtypen konnte das Entwicklungsteam von UnRisk-FACTORY überzeugen. Es wurde jedoch festgestellt, dass eine Kombination des URL-Tests und des Automated-GUI-Tests die gewünschten Funktionen bieten würde. Web-TEST versucht deshalb, diese Kombination umzusetzen.

Es folgt nun eine kurze Beschreibung der einzelnen Testtypen, um einen Überblick über die von TPTP zur Verfügung gestellten Testfunktionen zu gewinnen. Weiters werden die Testtypen, insbesondere der URL-Test und der Automated-GUI-Test, mit dem Web-TEST-Testtyp vergleichen. Dabei wird auch erkennbar, warum eine Kombination dieser beiden Testtypen die von Web-TEST geforderte Funktionalität erfüllen kann.

4.3.1                         TPTP-JUnit-Test

Ein TPTP-JUnit-Test ist eine Hülle für einen Standard-JUnit-Test. Mit Hilfe dieser Hülle können die TPTP-Dienste auch für JUnit-Tests verwendet werden. Beispielsweise kann man die Testdefinition in einem grafischen Editor verwalten. Man kann den Test auf einem entfernten Rechner (einem Remote-Rechner) ausführen, und man kann die Testergebnisse aufzeichnen, grafisch darstellen und für benutzerdefinierte BIRT-Berichte verwenden. Eine „Hülle“ für einen JUnit-Test bedeutet in diesem Zusammenhang, dass der JUnit-Test in ein TPTP-Test-Datenmodell, wie im Kapitel 4.4.1Das Modell der Testdefinition“ beschrieben, abgebildet wird.

Abbildung 4.5: Der grafische Editor für TPTP-JUnit-Tests (siehe die Demonstration unter [28])

Abbildung 4.5 zeigt den grafischen Test-Editor für TPTP-JUnit-Tests. Dort können Informationen wie Name, Beschreibung und die zugrundeliegende JUnit-Testklasse eingestellt werden. Weiters können auf der Editorseite „Test Methods“ Testmethoden hinzugefügt und entfernt werden. Schließlich kann auf der „Behavior“-Seite auch die Ausführungsreihenfolge festgelegt werden. Die Definition (also der Code) der Testmethoden muss weiters manuell in der zugrundeliegenden JUnit-Klasse erstellt werden. Das Ausführen funktioniert genau wie beim Web-TEST-Test. Eine Demonstration des TPTP-JUnit-Tests, die dies alles veranschaulicht, ist unter [28] verfügbar. Wenn man diese Demonstration mit dem Anwendungsfall des Web-TEST-Tests im Kapitel 3.3Ein Anwendungsfall für Web-TEST“ vergleicht, so erkennt man, dass sehr viele Schritte identisch sind. Durch die Verwendung von TPTP wird ein einheitlicher Testprozess anwendbar.

4.3.2                         TPTP-Manual-Test

Der TPTP-Manual-Test ist ein manueller Test. Das heißt, er wird nicht programmgesteuert abgespielt, sondern muss von einem Tester abgespielt werden. Ein  manueller Test ist hier eine textuelle Beschreibung eines Tests. Sie besteht aus folgenden Teilen:

Dabei wird die Testbeschreibung wieder in einem TPTP-Test-Datenmodell abgebildet, wodurch die TPTP-Dienste auch für den Manual-Test verwendet werden können.

Abbildung 4.6: Der Test-Editor für TPTP-Manual-Tests (siehe Demonstration unter [29])

Abbildung 4.6 zeigt den TPTP-Manual-Test-Editor, der es erlaubt, die Testbeschreibung  für den Manual-Test zu erstellen. Dieser Test-Editor sieht den Test-Editoren von TPTP-JUnit-Test und Web-TEST-Test sehr ähnlich. Es wird eben bei allen Testtypen das gleiche Datenmodell verwendet. Zusätzlich zum Test-Editor wird beim Manual-Test eine Manual-Test-Client-Anwendung, wie sie in Abbildung 4.7 dargestellt ist, zur Verfügung gestellt. Diese Anwendung ist als Agent des Execution-Environments realisiert. Sie erweitert also das Execution-Environment und wird mit dem Test-Projekt in den IAC installiert.

Abgerundetes Rechteck: StatusAbgerundetes Rechteck: Stopp-Button

Abbildung 4.7: Die Manual-Test-Client-Anwendung für den Tester (siehe Demonstration unter [29])

Der Manual-Test-Client-Agent wird vom Execution-Environment auf dem Ziel-Rechner gestartet. Das ist der Rechner auf dem die SUT läuft. Die Eclipse-Workbench auf dem Workbench-Rechner (dargestellt in Abbildung 4.6) überwacht die Testausführung und kommuniziert mit dem Manual-Test-Client-Agent. Der Tester, der vor dem Ziel-Rechner sitzt, sieht im Manual-Test-Client die abzuarbeitenden Testschritte und deren Beschreibung. Mit Hilfe dieser Information kann er den Test in der SUT durchspielen und den Status zu den einzelnen Testschritten notieren. Sobald der Tester mit dem gesamten Test fertig ist, klickt er auf den Stopp-Button (). Dann wird über das Execution-Environment die Eclipse-Workbench von der Fertigstellung des Tests informiert und die Testergebnisse können wieder im TPTP-Testprotokoll-Editor betrachtet werden. Bemerkenswert ist, dass für den Benutzer der Eclipse-Workbench der Test genau gleich abläuft wie bei den anderen Testtypen, dass jedoch der eigentliche Test auf dem Ziel-Rechner manuell durchgeführt wird.

4.3.3                         TPTP-URL-Test

Ein TPTP-URL-Test besteht, wie auch ein Web-TEST-Test, aus einer Anzahl von HTTP-Requests, die während des Tests in einer bestimmten Reihenfolge abgespielt werden. Allerdings stehen beim URL-Test weder die gespeicherten Responses noch Assertions zur Verfügung. Der URL-Test ist deshalb nicht für das funktionale Testen auf Basis der Inhalte von HTML-Seiten geeignet. Vielmehr kann man die Performanz, insbesondere die Antwortzeiten, mit diesem Testtyp feststellen. Dazu kann man die Anzahl der simulierten Testbenutzer einstellen. Wenn ein Test gleichzeitig mehrfach ausgeführt werden soll, so kann die Benutzerzahl erhöht werden. Damit kann man beispielsweise das Ansteigen der Antwortzeit bei steigender Auslastung messen. Standardmäßig ist, wie Abbildung 4.8 zeigt, die Benutzerzahl (Users) auf „1“ gesetzt.

Abgerundetes Rechteck: Benutzeranzahl

Abbildung 4.8: Der Editor für TPTP-URL-Tests (siehe Demonstration unter [30])

Eine URL-Test-Definition wird mit Hilfe des in Abbildung 4.8 dargestellten URL-Test-Editors editiert. Der URL-Test kann jedoch auch mit Hilfe des im Kapitel 3.3.1Aufzeichnen eines Tests“ beschriebenen Recorders erstellt werden. Dazu muss während der Aufzeichnung der Test-Generator „TPTP URL Test Generator“ verwendet werden.

Da der URL-Test keine Response-Daten speichert, fehlen hier gegenüber dem Web-TEST-Test-Editor alle Seiten, die sich auf den Response beziehen. Außerdem stehen die Editor-Aktionen des Web-TEST-Test-Editors nicht zur Verfügung. Man kann jedoch wie beim Web-TEST-Test-Editor zusätzliche Requests hinzufügen und die Ausführungsreihenfolge definieren. Auch das Starten der Testausführung und das Betrachten der Ergebnisse funktioniert wie beim Web-TEST-Test. Im Gegensatz zum Web-TEST-Test werden während der Testausführung keine Überprüfungen bezüglich des Inhalts der Responses durchgeführt.

Der URL-Testtyp diente als Vorlage für die Entwicklung des Web-TEST-Tests. Deshalb ist ein Web-TEST-Test eine Obermenge des URL-Tests und bietet auch alle Funktionen eines URL-Tests an. Mit Hilfe der Demonstration des URL-Tests unter [30] kann man einen Überblick über die Funktionen dieses Testtyps gewinnen. Wenn man die beiden Demonstrationen, [30] für den URL-Test und Kapitel 3.3Ein Anwendungsfall für Web-TEST“ für den Web-TEST-Test, vergleicht, dann werden die Gemeinsamkeiten und Unterschiede der Testtypen deutlich. Die Unterschiede ergeben sich vor allem wegen der unterschiedlichen Zielsetzung der Testtypen: der URL-Test dient zur Analyse der Performanz und der Web-TEST-Test für Regressionstests von HTML-basierten Webanwendungen.

4.3.4                         TPTP-Automated-GUI-Test

Der Automated-GUI-Test dient zum Erstellen von Regressionstests für Eclipse selbst und für Eclipse-Plug-Ins. Man kann mit Hilfe eines Recorders einen Testfall während der Benützung von Eclipse aufzeichnen. Der Test wird in eine XML-Beschreibung umgewandelt, die die einzelnen Kommandos enthält, und man kann Verifikationspunkte einfügen. Die XML-Beschreibung kann später automatisch ausgeführt werden. Dabei wird der Test programmgesteuert durchgeführt. Außerdem werden die Verifikationspunkte überprüft. Beispielsweise könnte ein Verifikationspunkt sein, dass überprüft wird, ob bestimmte Ressourcen erzeugt oder Nachrichten ausgegeben wurden.

Abbildung 4.9: Der Editor für TPTP-Automated-GUI-Tests (siehe Demonstration unter [12])

Abbildung 4.9 zeigt die „Test Cases“-Seite des Automated-GUI-Test-Editors. Hier wurde das Erstellen eines Java-Projekts in Eclipse mit Hilfe eines GUI-Recorders aufgezeichnet und in eine XML-Beschreibung umgewandelt. In der Abbildung wird die XML-Beschreibung unter dem Punkt „Macro“ auf der rechten Hälfte des Editors angezeigt. Rechts oben ist der Start-Button () des Recorders. Damit kann der in Abbildung 4.10 dargestellte GUI-Recorder gestartet werden.

Abbildung 4.10: TPTP-GUI-Recorder

Der GUI-Recorder wird wieder über den Agent-Controller in einem nicht-modalen Dialog geöffnet. Der Tester verwendet dann Eclipse normal weiter und alle Aktionen werden aufgezeichnet. Beendet wird die Aufzeichnung über den Stopp-Button () des Recorders. Der Recorder erstellt nach dem Beenden einen neuen Testfall mit der XML-Beschreibung und fügt ihn zum aktiven Automated-GUI-Test hinzu. Die Reihenfolge der Tests kann dann wieder auf der Seite „Behavior“ des Test-Editors eingestellt werden. Das Ausführen des Tests funktioniert genau wie bei den anderen Testtypen. Für nähere Informationen über den Automated-GUI-Test empfiehlt sich die Demonstration unter [30] und die dort referenzierte Literatur.

4.4                     Die Datenverwaltung im TPTP-Test-Projekt

Alle Testtypen des Test-Projekts verwenden zum Speichern und Verwalten der Testdaten ein gemeinsames, standardisiertes Datenmodell. Dieses Datenmodell wird, wie alle TPTP-Datenmodelle, durch das Platform-Projekt zur Verfügung gestellt und ist eine Referenzimplementierung des UML-2.0-Testing-Profiles [32]. Das Modell besteht wieder aus drei Teilmodellen:

Im Folgenden werden die drei Teilmodelle mit Hilfe von Ausschnitten aus dem jeweiligen Teilmodell erklärt. Dazu werden die UML2-Infrastructur-Notation [33] und die UML2-Sequenzdiagramm-Notation [34] verwendet. Eine grobe Kenntnis dieser Notationen wird hier vorausgesetzt. Weiters ist zu beachten, dass die Ausschnitte stark vereinfacht wurden, um die Übersichtlichkeit zu erhalten. Dabei wird unter anderem die farbliche Codierung der Modell-Typen ignoriert. Eine vollständige Beschreibung der TPTP-Test-Projekt-Datenmodelle ist unter [35] nachzulesen.

4.4.1                         Das Modell der Testdefinition

Das Modell der Testdefinition (im Folgenden kurz Test-Modell genannt) ist eine Implementierung des UML-2.0-Test-Profiles und beschäftigt sich mit der Modellierung der Testkomponenten, der Teststruktur, der Testbeschreibung und der Zusammenstellung von Tests zu Testgruppen.  Abbildung 4.11 zeigt einen Ausschnitt der Modelldokumentation des Test-Modells.

Abbildung 4.11: Das Test-Modell

Die Bedeutung der im Ausschnitt dargestellten Relationen ist wie folgt:

 

4.4.2                         Das Modell des Testverhaltens

Das Modell des Testverhaltens (im Folgenden auch Behavior-Modell genannt) beschäftigt sich mit der Definition des Verhaltens eines Testobjekts. Als Metapher für  das Behavior-Modell dient das UML-Sequenzdiagramm. Deshalb sind die wesentlichen Typen des TPTP-Behavior-Modells ähnlich den Typen in einem UML-Sequenzdiagramm.

Nachricht

 

Interaktionsoperanden

 

Kombiniertes Interaktionsfragment

 

Lebenslinie

 

Interaktion

 

Abbildung 4.12: Grafische Darstellung eines UML-Sequenzdiagramm

Abbildung 4.12 zeigt ein Sequenzdiagramm mit den Elementen die auch im Behavior-Modell verwendet werden. Abbildung 4.13 und Abbildung 4.14 zeigen im Gegensatz dazu Ausschnitte aus dem Behavior-Modell. Die darin verwendeten Elemente sind äquivalent zu den Elementen des Sequenzdiagramms. Deshalb lassen sich mit Hilfe des Sequenzdiagramms die im Behavior-Modell verwendeten Elemente leicht verstehen.

Abbildung 4.13: Kernelemente des Behavior-Modells

Abbildung 4.13 stellt einen Ausschnitt des Behavior-Modells dar. Dabei werden die darin enthaltenen Typen im Rahmen des TPTP-Test-Projekts wie folgt verwendet:

Abbildung 4.14:  Ausschnitt aus den Elementen des Interaktionsoperand im Behavior-Modell

Abbildung 4.14 zeigt, wie ein Interaktionsoperand des Sequenzdiagramms im Behavior-Modell eingebunden werden kann. Damit können beispielsweise Schleifen (Loops) realisiert werden. Weiters wird dargestellt, wie die Eigenschaften der Tests, etwa Eingabeparameter, abgespeichert werden können. Die in Abbildung 4.14 dargestellten Typen haben dabei folgende Bedeutung:

Das hier verwendete Schema für das Test- und Behavior-Modell scheint auf den ersten Blick zu komplex gewählt. Man würde wahrscheinlich, wenn man nur einen der TPTP-Testtypen betrachtet, ein einfacheres Modell verwenden. Das von TPTP gewählte allgemeine Modell hat jedoch einige Vorteile, welche die Komplexität aufwiegen:

4.4.3                         Das Execution-History-Modell

Abbildung 4.15: Kernelemente des Execution-History-Modells

Das in Abbildung 4.15 dargestellte Modell beschreibt den Aufbau der Daten die bei der Testausführung gesammelt werden.

 

5    Die Umsetzung von Web-TEST

Das Testwerkzeug Web-Test baut auf dem TPTP-Framework auf. Dadurch ist es möglich, die Vorteile von TPTP in Web-TEST zu übernehmen. Besonders interessant sind dabei folgende Punkte:

Web-TEST muss sich bestmöglich in TPTP integrieren, um diese Eigenschaften optimal an den Kunden weiterzugeben.

5.1                     Integration von Web-TEST in TPTP und Eclipse

TPTP wurde als Dienstplattform für Erweiterungen konzipiert und bietet deshalb eine Fülle von Erweiterungspunkten an. Web-TEST nützt diese Erweiterungspunkte und kann dadurch den erprobten TPTP-Testprozess, die TPTP–Datenmodelle und andere TPTP-Dienste verwenden. Um die Integration in TPTP bestmöglich zu gestalten, wurden mit dem TPTP-Team folgende Kriterien für die Zusammenarbeit von TPTP und Web-TEST festgelegt:

Installiert wird Web-TEST als Eclipse-Feature, dass unter der Internet-Adresse https://sourceforge.net/projects/tptpwebtest/ verfügbar ist. Sourcefore.net bietet Entwicklern die Möglichkeit Open-Source-Projekte zu hosten. Für die Entwicklung und die Verbreitung von Web-TEST wurde auf sourceforge.net das Projekt TPTP-Web-TEST unter der oben angegebenen Internet-Adresse angelegt. Zurzeit steht ein Release der Version 1.0.0 zu Verfügung. Auch die vorliegende Arbeit ist über diese Internet-Adresse erhältlich.

Web-TEST erweitert nicht nur TPTP, sondern bietet Kunden auch neue Möglichkeit von Adaptionen und Erweiterungen an.  Die neuen Erweiterungspunkte von Web-TEST werden im Kapitel 5.5Die angebotenen Erweiterungspunkte“ detailliert besprochen. Ein Web-TEST-Kunde kann also seine kundenspezifischen Testwerkzeuge auf einer noch höheren Abstraktionsebene erstellen. Abbildung 5.1 zeigt dementsprechend Web-TEST als eine weitere Schicht, zwischen den Kunden-Erweiterungen und dem TPTP-Framework.

Abbildung 5.1: Integration von Web-TEST in TPTP

Weiters zeigt Abbildung 5.1, dass die Anwender drei Möglichkeiten haben Web-TEST zu verwenden:

  1. Sie können auf die von Web-TEST angebotenen Dienste zugreifen.
  2. Sie können auch auf die reinen TPTP-Dienste zugreifen.
  3. Sie können kundenspezifischen Erweiterungen verwenden, die auf Web-TEST und TPTP zurückgreifen.

5.2                     Die Aufteilung von Web-TEST in Eclipse-Plug-Ins

Web-TEST besteht, wie auch die einzelnen TPTP-Projekte, aus einer Anzahl von Plug-Ins, die über ein Eclipse-Feature installiert werden können.

Abbildung 5.2: Die Plug-Ins von Web-TEST

Abbildung 5.2 zeigt alle Web-TEST-Plug-Ins und ihre Abhängigkeiten zu den TPTP-Plug-Ins. Es ist erkennbar, dass die Plug-In-Struktur von Web-TEST streng hierarchisch ist, wobei Web-TEST-Lib die Basis ist und Web-TEST-Business-Attribute-Criterion alle anderen Plug-Ins voraussetzt. Weiters ist die Abhängigkeit der Web-TEST-Plug-Ins zu ihren jeweiligen TPTP-Gegenstücken dargestellt. So hängt etwa Web-TEST-Models von Hyades-Models ab. Web-TEST-Core hängt von TPTP-Test-Framework und TPTP-Test-Tools ab, und Web-TEST-UI hängt von Hyades-UI, TPTP-Test-Framework-UI und TPTP-Test-Tools-UI ab. Die Linien der Abhängigkeiten verlaufen hier über kreuz, weil die TPTP-Plug-Ins nach ihren Projekten und nicht nach der hierarchischen Ordnung sortiert sind.

Die einzelnen Web-TEST-Plug-Ins der Abbildung 5.2 erfüllen folgenden Aufgaben:

 

Web-TEST-Lib-Plug-In (org.eclipse.tptp.test.tools.web.lib)

Das Web-TEST-Lib-Plug-In stellt Dritt-Bibliotheken (benötigte Bibliotheken die weder von Eclipse noch von TPTP bereit gestellt werden) für alle darüber liegenden Web-TEST-Plug-Ins zur Verfügung. Unter anderem werden die Bibliotheken für Htmlunit [36], für einen Log4j-Adapter [37] und für einen speziellen Base64-Encoder von Ostermiller-Utils [38] zur Verfügung gestellt.

 

Web-TEST-Models-Plug-In (org.eclipse.tptp.test.tools.web.models)

Das Web-Test-Models-Plug-In stellt das Web-TEST-Datenmodell zur Verfügung. Alle weiteren Plug-Ins verwenden dieses Datenmodell, um Web-TEST spezifische Daten zu verwalten. Das Web-TEST-Datenmodell wird im Kapitel 5.3Daten und Datenmodelle in Web-TEST“ detailliert erklärt.

 

Web-TEST-Core-Plug-In (org.eclipse.tptp.test.tools.web.core)

Dieses Plug-In stellt Aktionen und Dienste für die darüber liegenden Plug-Ins zur Verfügung. So ist etwa die Geschäftslogik hinter den verschiedenen Wizards in diesem Plug-In implementiert. Die Wizards selbst sind jedoch im Web-TEST-UI-Plug-In enthalten.

 

Web-TEST-Runner-Plug-In (org.eclipse.tptp.test.tools.web.runner)

Dieses Plug-In stellt die nötigen Dienste für die Kontrolle der Assertions während der Testausführung bereit. Hier ist also die Logik umgesetzt, die die Assertions ausführt und die in den Assertions gespeicherten Werte mit den bei der Testausführung gesammelten Werten vergleicht.

 

Web-TEST-UI-Plug-In (org.eclipse.tptp.test.tools.web.ui)

Das Web-TEST-UI-Plug-In dient zur Umsetzung aller Benutzeroberflächenobjekte. In diesem Plug-In befindet sich unter anderem der Web-TEST-Test- und Assertion-Editor, alle Wizards und die Editor-Aktionen.

 

Web-TEST-Recorder-Plug-In (org.eclipse.tptp.test.tools.web.recorder)

Das Web-TEST-Recorder-Plug-In bietet den Test-Generator-Dienst an. Dieser Dienst erzeugt aus den aufgenommenen Daten automatisch eine Web-TEST-Testressource.

 

Web-TEST-Business-Attribute-Criterion-Plug-In (org.eclipse.tptp.test.tools.web.criterion.ba)

Das Web-TEST-Business-Attribute-Criterion-Plug-In bietet alle Dienste rund um Business-Attribute-Kriterien an. Unter anderem ist auch der BA-Assertion-Generation-Wizard in diesem Plug-In realisiert. Die Dienste rund um das Business-Attribute-Kriterium wurden in einem eigenen Plug-In zusammengefasst, um ein Beispiel für die Erweiterbarkeit von Web-TEST zu bieten. Web-Test funktioniert auch ohne dieses Plug-In, wobei jedoch der wichtigste Kriterientyp fehlt. Ein Web-TEST-Kunde kann dieses Plug-In als  Vorlage zur Entwicklung von eigenen Kriterientypen verwenden.

 

In den folgenden Kapiteln werden die Schnittstellen und Datenmodelle von Web-TEST beschrieben, um die Erweiterbarkeit zu demonstrieren und um Web-TEST-Kunden eine Dokumentation der Schnittstellen zu bieten. Dabei werden sowohl die Schnittstellen zwischen den TPTP-Plug-Ins und den Web-TEST-Plug-Ins, als auch die Schnittstellen zwischen Web-TEST und kundenspezifischen Erweiterungen erläutert:

5.3                     Daten und Datenmodelle in Web-TEST

Web-TEST verwendet die TPTP-Datenmodelle für Testdefinitionen und Testverhalten. Weiters verwendet Web-TEST ein eigenes Datenmodell webtestData für die Speicherung von Assertions und dynamischen Request-Parametern. Wie zuvor schon erwähnt darf Web-TEST seine Daten weder direkt in ein eigenes Dokument speichern noch darf das TPTP-Datenmodell erweitert werden. Aus diesem Grund wird aus dem webtestData-Datenmodell eine XML-Ressource erzeugt, die in einem zweiten Schritt in eine Zeichenkette konvertiert wird. Diese Zeichenkette kann dann als Wert eines generischen Elements des TPTP-Testdefinitionsmodells abgespeichert werden. Somit wird erreicht, dass alle Web-TEST-Daten im übergeordneten TPTP-Datenmodell abgespeichert werden, ohne dass das TPTP-Datenmodell geändert wird. Eine genauere Beschreibung dieses Vorgangs kann unter 5.5.1Die Erweiterungspunkte des Web-TEST-Models-Plug-In“ gefunden werden.

Im Folgenden wird gezeigt, wie Web-TEST die Test- und Assertiondaten mit Hilfe der TPTP-Datenmodelle und des Web-Test-Datenmodells webtestData verwalten kann.

5.3.1                   Beispiel der Verwendung des Test- und Behavior-Modell in Web-TEST

Dieses Kapitel beschreibt, wie Web-TEST seine Daten in das TPTP-Test-Modell und im TPTP-Behavior-Modell abbildet. Zur Veranschaulichung wird hier ein Test mit folgenden Eigenschaften verwendet:

1.      Anzeigen der Login-Seite - Name: „1 GET UnRisk-FACTORY“

2.      Einloggen - Name: „2 POST Admin Overview“

3.      Anzeigen der Benuzter-Objekte - Name: „3 GET Users

4.      Ausloggen - Name: „4 GET UnRisk-FACTORY“

Die folgenden Abbildungen - Abbildung 5.3, Abbildung 5.4 und Abbildung 5.5 - zeigen den Aufbau dieses Web-TEST-Tests, wie er in der Testressource nach der Aufnahme abgespeichert ist.

Abbildung 5.3 zeigt dabei die vollständige Datenstruktur als grafische Darstellung der XML-Testressource. Abbildung 5.4 und Abbildung 5.5 zeigen hingegen nur Ausschnitte aus Abbildung 5.3 mit Hilfe eines UML-Instanzdiagramms. In Abbildung 5.4  wird das Verhalten der Testsuite detaillierter erläutert und in Abbildung 5.5 wird das Verhalten der einzelnen Testfälle dargestellt.

Legende mit Linie (2): ID des verwendeten TesttypsLegende mit Linie (2): Testsuite-Behavior

Interaction-Fragment referenziert Testcase-Behavior

 
Legende mit Linie (2): Interaction-OperandLegende mit Linie (2): Testcases

Abbildung 5.3: Datenstruktur des Web-TEST-Tests „ShowModel_WebTEST“

In Abbildung 5.3 ist erkennbar, dass die Testsuite unter anderem aus einem „behavior“- und vier „testCase“-Elementen besteht, wobei das „behavior“-Element über die Kette „interaction“ / „interactionFragments“ / „interactionOperands“ weitere vier „interactionFragments“-Elemente enthält. Diese enthalten das Attribut „otherBehavior“. Das Element „otherBehavior“ ist eine Referenz auf das „behavior“-Element der einzelnen Testfälle - siehe den roten Kasten „Interaction-Fragment referenziert Testcase-Behavior“ in Abbildung 5.3.

In den folgenden UML-Instanzdiagrammen werden Kompositionen als Beziehungen und Aggregationen als Instanzvariablen beschrieben. Als Klassennamen werden die in den TPTP-Datenmodellen verwendeten Typbezeichnungen verwendet. Die Namen der UML-Instanzen entsprechen den Namen der XML-Elemente der in Abbildung 5.3 dargestellten Testressource.

Abbildung 5.4: Instanzmodell - Testsuite Behavior-Modell

Abbildung 5.4 zeigt nochmals die Definition des Testverhaltens der Testsuite (TPFTestSuite) „ShowModel_WebTEST“. Die Testsuite enthält das Testverhalten (TPFBehavior) „Test_Suite_behaviour“. Dieses enthält wiederum eine Interaktion (BVRInteraktion).

Die Interaktion wird ihrerseits durch die Lebenslinie (BVRLifeline) „TestSuite_LifeLine“ und durch ein Kombiniertes-Interaktionsfragment (BVRCombinedFragment) „Loop 1“ zusammengestellt. Das Kombinierte-Interaktionsfragment enthält einen  Interaktionsoperator „loop“. Dadurch wird das Kombinierte-Interaktionsfragment „Loop 1“ als Schleife erkannt werden. Weiters enthält das Kombinierte-Interaktionsfragment noch einen Interaktionsoperanden (BVRInteractionOperand), der unter anderem die Schleifenbedingung enthält. Der Wert in der Abbildung ist „1“, deshalb wird die Schleife beim Ausführen des Tests nur einmal ausgeführt.

Der Interaktionsoperand enthält alle Sub-Interaktionsfragmente die im Rahmen der Schleife ausgeführt werden. Da das Testverhalten nach dem Aufnehmen nicht geändert wurde, enthält dieser Interaktionsoperand vier Interaktionsfragmente. Eines für jeden der vier aufgezeichneten Requests.

Jedes dieser Interaktionsfragmente verweist selbst wieder auf das Testverhalten eines Requests. Dieses Testverhalten wird im Request (im Testfall) selbst definiert und legt fest wie der Request ausgeführt wird. Die Verknüpfung von der Testsuite zu den Testverhalten der einzelnen Requests funktioniert über das Feld „otherBehavior“. In Abbildung 5.4 wird dieses Feld durch einen roten Rahmen hervorgehoben.

Abbildung 5.5: Instanzmodell - Testfälle und deren Behavior-Modell

Die Definition der einzelnen Testfälle (TPFTestCase) ist, wie Abbildung 5.5 zeigt, auch Teil der Testsuite „ShowModel_WebTEST“. Jeder Testfall enthält sein eigenes Testverhalten. Beispielsweise enthält der Testfall „2 POST Admin Overview“ das Testverhalten „2 POST Admin Overview_behavior“.

Das Testverhalten „2 POST Admin Overview_behavior“ enthält ebenfalls eine Interaktion, die aus einer Lebenslinie und einem Interaktionsfragment besteht. Das Interaktionsfragment referenziert mit Hilfe der Instanzvariable „lifeline“ die Lebenslinie der Testsuite - die „TestSuite_LifeLine“. Damit wird beschrieben, dass das Verhalten der Testfälle im Kontext der Lebenslinie der Testsuite ausgeführt wird.

Das Interaktionsfragment der Testfälle enthält außerdem alle Testfallparameter (BVRProperty). Die Testfallparameter sind alle verwendeten Request- und Response-Parameter. Beispielsweise wird unter dem Namen DESC_ATT/Host“ der Host „www.unrisk.com“ abgespeichert. Auch der gesamte Response-Inhalt wird als Testfallparameter unter dem Namen „REF_RESP_ATT/Body“ abgespeichert. In der Abbildung 5.5 werden die Testfallparameter und ihre Werte rechts unten dargestellt.  Beispielsweise wird der Parameter „REF_RESP_ATT/Body“ mit dem Wert „&lt;!DOCTYPE html PUBLIC &quot; …“ angezeigt. Dieser Parameter enthält also die HTML-Antwortseite, die bei der Testaufzeichnung aufgenommen wurde.

Schließlich enthält das Interaktionsfragment noch eine Nachricht (BVRMessage). Diese gibt an, wie die Kommunikation erfolgen soll. Beim Web-TEST-Test wird hier angegeben, ob es sich um einen GET- oder POST-Request handelt.

Mit Hilfe dieses Schemas kann die Testdefinition eines Web-TEST-Tests im TPTP-Testmodell abgebildet werden. Als nächstes ist zu klären, wie Assertions in das TPTP-Testmodell aufgenommen werden können.

5.3.2                   Das webtestData-Datenmodell

Abbildung 5.6: Das „webtestData“ Datenmodell

Abbildung 5.6 zeigt den Aufbau der webtestData-Datenstruktur. Diese erlaubt es Web-TEST die zusätzlichen Daten, wie Assertions, zu speichern. Dabei wird die Speicherung von folgenden Elementen unterstützt:

Test-Value-Selector: dieser Datentyp erlaubt das Speichern von Value-Selector-Elementen, die über die Assertion-Editor-Seite „Value Selector“, die  in Abbildung 3.36 dargestellt ist, verwaltet werden können.

Test-Filled-Parameter: dieser Datentyp erlaubt das Speichern von dynamischen Request-Parametern. Diese Parameter können über die Assertion-Editor-Seite „Parameter“ wie in Abbildung 3.37 dargestellt verwaltet werden.

XPath-Criterion: dieser Datentyp erlaubt das Speichern von XPath-Kriterien. Diese Kriterien werden über die Assertion-Editor-Seite „XPath Criterion“ wie in Abbildung 3.31 dargestellt verwaltet.

Html-Criterion: dieser Datentyp erlaubt das Speichern von Text-Kriterien. Diese Kriterien werden über die Assertion-Editor-Seite „Text Criterion“ wie in Abbildung 3.30 dargestellt verwaltet.

Business-Attribute-Criterion: dieser Datentyp erlaubt das Speichern von Business-Attribute-Kriterien. Diese Kriterien werden über die Assertion-Editor-Seite „Business Att. Criterion“ wie in Abbildung 3.32 dargestellt verwaltet.

In Abbildung 5.6 ist auch erkennbar, dass die einzelnen Elemente beliebig oft vorkommen können  (markiert durch den Qualifier [0..*]).

Abbildung 5.7: Die Daten von „webtestData“ die im gezeigten Anwendungsfall erstellt wurden

Abbildung 5.7 zeigt die Datenstruktur webtestData, wie sie am Ende des gezeigten Anwendungsfalls aus Kapitel 3.3 aussieht. Man erkennt, dass die Datenstruktur vier Value-Selector-Elemente, zwei dynamische Request-Parameter, sechs verschiedene Kriterien und fünf damit zusammengestellte Assertions enthält.

Im Folgenden werden die verschiedenen Elemente erläutert und ihre Bedeutung erklärt. Weiters wird versucht, mit Hilfe der Daten des Anwendungsfalls dem Leser zu vermitteln, wie die Daten der Benutzeroberfläche in der Datenstruktur abgespeichert werden.

Der Datentyp Test-Value-Selctor

Abbildung 5.8: Der Datentyp Test-Value-Selector

Wie in Abbildung 5.8 dargestellt, enthält der Datentyp Test-Value-Selector folgende Elemente und Attribute:

Element- bzw. Attributname

Beschreibung

Id

Eine automatisch generierte eindeutige Identifikationsnummer.

Name

Ein für den Datentyp eindeutiger Name, der auch in der Benutzeroberfläche  zur Anzeige verwendet wird.

RefTestCaseRef

Enthält die Referenz auf einen Request. Hier wird keine IDREF verwendet, weil die Testfälle (Requests) in der übergeordneten TPTP-Datenstruktur festgelegt werden und deshalb nicht im selben XML-Dokument sind.

Type

Unterscheidet zwischen „RESPONSE“- und „REQUEST“-Value-Selector-Elementen. Eine Beschreibung dieser beiden Typen von Value-Selector-Elementen wurde bereits in Kapitel 3.3.5 gemacht.

XPath

Enthält den XPath-Ausdruck für einen Response-Value-Selector.

ParameterName

Enthält den Namen eines GET- oder POST-Request-Parameters eines Request-Value-Selectors. Die möglichen Parameternamen werden dabei aus dem unter RefTestCaseRef referenzierten Requests abgeleitet.

Tabelle 51: Elemente und Attribute des Datentyps Test-Value-Selector

Abbildung 5.9: Daten eines Test-Value-Selector-Elements

Abbildung 5.9 zeigt die Daten des Test-Value-Selectors „Value Selector 0“, der im Rahmen des gezeigten Anwendungsfalls erstellt wurde. Es handelt sich hierbei um einen Response-Value-Selector. Deshalb enthält das Feld Type den Wert „RESPONSE“, das Feld XPath enthält einen XPath-Ausdruck und das Feld ParameterName ist leer. Im Fall eines Request-Value-Selectors wäre das Feld XPath leer und dafür würde das Feld Parametername einen Wert enthalten.

Der Datentyp Test-Filled-Parameter

Abbildung 5.10: Der Datentyp Test-Filled-Parameter

Wie in Abbildung 5.10 dargestellt, enthält der Datentyp Test-Filled-Parameter folgende Elemente und Attribute:

 

Element- bzw. Attributname

Beschreibung

Id

Eine automatisch generierte eindeutige Identifikationsnummer.

Name

Ein für den Datentyp eindeutiger Name, der auch in der Benutzeroberfläche zur Anzeige verwendet wird.

DefaultValue

Ein Standardwert, der als Wert des Parameters herangezogen wird, falls während der Testausführung der assoziierte Response-Value-Selector noch keinen Wert geliefert hat.

ResponseValue-SelectorRef

Enthält eine Referenz auf einen Response-Value-Selector.

RequestValue-SelectorRef

Enthält eine Referenz auf einen Request-Value-Selector.

Response-TestCaseRef

Enthält eine Referenz auf einen Request (ein Request ist in Web-TEST ein Äquivalent zu einem Testfall). Nach der Ausführung dieses Requests wird der assoziierte Response-Value-Selector auf den gelieferten Response angewendet, um den Parameterwert zu ermitteln.

Ein Test-Filled-Parameter-Element kann beliebig viele ResponseTestCaseRef-Elemente enthalten.

Request-TestCaseRef

Enthält eine Referenz auf einen Request. Bei der Ausführung dieses Requests wird der aktuelle Wert des dynamischen Request-Parameters als Wert des durch den Request-Value-Selector ausgewählten Parameters verwendet.

Ein Test-Filled-Parameter-Element kann beliebig viele RequestTestCaseRef-Elemente enthalten.

Tabelle 52: Elemente und Attribute des Datentyps Test-Filled-Parameter

Abbildung 5.11: Daten eines Test-Filled-Parameter-Elements

Abbildung 5.11 zeigt die Daten des dynamischen Request-Parameters „Parameter 0“, der im Rahmen des Anwendungsfalls erstellt wurde. Der DefaultValue dieses Parameters ist leer. Es wird jedoch sowohl ein Response-Value-Selector, als auch ein Request-Value-Selector mit dem Parameter verknüpft. Weiters ist erkennbar, dass sowohl ein Request zum Extrahieren des Wertes referenziert wird (ResponseTestCaseRef), wie auch ein Request zum Verwenden des Parameterwerts (RequestTestCaseRef).

Der Datentyp XPath-Criterion und der Datentyp Criterion

Abbildung 5.12: Der Datentyp XPath-Criterion

Wie Abbildung 5.12 darstellt, kann der Datentyp XPath-Criterion folgende Elemente und Attribute enthalten:

Feld- bzw. Attributname

Beschreibung

Id

Eine automatisch generierte eindeutige Identifikationsnummer.

Name

Ein für den Datentyp eindeutiger Name, der auch in der Benutzeroberfläche  zur Anzeige verwendet wird.

Description

Eine Beschreibung der Instanz des Kriteriums, die dem Benutzer in der Oberfläche angezeigt wird. ZB: „Kriterium zur Überprüfung des Titels ‚Administration’“

XPathExpresssion

Enthält einen XPath-Ausdruck, der bei der Ausführung des Tests auf die assoziierten Requests angewendet wird. Das Ergebnis wird mit den im XPath-Criterion-Element gespeicherten Criterion-Elementen verglichen.

Criterion

Ein Criterion enthält den erwarteten Wert und die zu verwendende Vergleichsbedingung.

Ein XPath-Criterion-Element kann beliebig viele Criterion-Elemente enthalten.

Tabelle 53: Elemente und Attribute des Datentyps XPath-Criterion

In Abbildung 5.12 wird weiters dargestellt, wie ein Criterion-Element aufgebaut ist. In der folgenden Tabelle werden die Felder und Attribute des Criterion-Datentyps näher beschrieben:

Feld- bzw. Attributname

Beschreibung

Id

Eine automatisch generierte eindeutige Identifikationsnummer.

Name

Ein für den Datentyp eindeutiger Name, der auch in der Benutzeroberfläche  zur Anzeige verwendet wird.

Description

Eine Beschreibung der Instanz des Kriteriums, die dem Benutzer in der Oberfläche angezeigt wird. ZB: „Kriterium zur Überprüfung des Seitentitels ‚Administration’.“

Datatyp

Enthält den vollständigen Klassennamen eines Java-Datentyps. Zurzeit werden von Web-TEST folgende Datentypen unterstützt: java.lang.String, java.lang.Integer und java.lang.Double.

Operation

Enthält den Vergleichsoperator. Mit diesem Operator werden der gefundene Wert und der im Kriterium gespeichert Wert verglichen. Zurzeit werden von Web-TEST folgende Vergleichsoperatoren unterstützt: Equals, Not Equal, Less Than, Greater Than, Contains und Doesn’t Contain.

Value

Enthält den erwarteten Wert als Zeichenkette. Während der Testausführung muss der Wert wieder in den unter Datatype gespeicherten Datentyp konvertiert werden.

UseRegEx

Gibt an, ob der in Value gespeicherte Wert als regulärer Ausdruck interpretiert werden soll. „True“ oder „False“.

UseOnlyText

Gibt an, ob der erwartete Wert im gesamten HTML-Text des Responses oder in dem um die HTML-Tags bereinigten Text gesucht werden soll. „True“ oder „False“.

Tabelle 54: Elemente und Attribute des Datentyps Criterion

Abbildung 5.13: Daten eines XPath-Criterion-Elements

Abbildung 5.13 zeigt die Daten des XPath-Criterions „DOM View XPath Criterion 0“, das im Rahmen des Anwendungsfalls erstellt wurde. Das Element XPathExpression gibt den XPath-Ausdruck an, der verwendet wird, um einen Wert im Response auszuwählen. Weiters enthält das XPath-Criterion noch ein Criterion-Element, das einen „java.lang.String“ mit dem Wert „Administration“ mit der Operation „Equals“ mit dem durch den XPath-Ausdruck gefundenen Wert vergleicht.

Der Datentyp Html-Criterion

Abbildung 5.14: Der Datentyp Html-Criterion

Wie Abbildung 5.14 darstellt, enthält der Datentyp Html-Criterion folgende Elemente und Attribute:

Feld- bzw. Attributname

Beschreibung

Id

Eine automatisch generierte eindeutige Identifikationsnummer.

Name

Ein für den Datentyp eindeutiger Name, der auch in der Benutzeroberfläche  zur Anzeige verwendet wird.

Description

Eine Beschreibung der Instanz des Kriteriums, die dem Benutzer in der Oberfläche angezeigt wird. ZB: „Kriterium zur Überprüfung des Titels ‚Administration’“

Criterion

Ein Criterion enthält den erwarteten Wert und die zu verwendende Vergleichsbedingung.

Ein Html-Criterion-Element kann wieder beliebig viele Criterion-Elemente enthalten.

Tabelle 55: Elemente und Attribute des Datentyps Html-Criterion

Abbildung 5.15: Daten eines Html-Criterion-Elements

Abbildung 5.15 zeigt die Daten des Html-Criterions „Browser View Text Criterion 0“, das im Rahmen des Anwendungsfalls erstellt wurde. Das Html-Criterion enthält wieder ein Criterion-Element, das den im Response zu suchenden Wert und den Vergleichoperator enthält.

Der Datentyp Business-Attribute-Criterion

Abbildung 5.16: Der Datentyp Business-Attribute-Criterion

Wie Abbildung 5.16 darstellt, enthält der Datentyp Business-Attribute-Criterion folgende Elemente und Attribute:

Feld- bzw. Attributname

Beschreibung

Id

Eine automatisch generierte eindeutige Identifikationsnummer.

Name

Ein für den Datentyp eindeutiger Name, der auch in der Benutzeroberfläche  zur Anzeige verwendet wird.

Description

Eine Beschreibung der Instanz des Kriteriums, die dem Benutzer in der Oberfläche angezeigt wird. ZB: „Kriterium zur Überprüfung von Input-Feldern“

AbsElementXPath

Ein XPath-Ausdruck, der den Pfad zu den ausgewählten Elementen im Response angibt. Um alle Input-Felder auszuwählen, kann beispielsweise „//input“ verwendet werden.

RelNameXPath

Ein XPath-Ausdruck, der relativ zum ausgewählten Element ist. Mit Hilfe dieses XPath-Ausdrucks wird der Name des Elements extrahiert. Um den Namen von Input-Feldern auszuwählen, kann beispielsweise „@name“ verwendet werden.

RelValueXPath

Ein XPath-Ausdruck, der relativ zum ausgewählten Element ist. Mit Hilfe dieses XPath-Ausdrucks wird der Wert des Elements extrahiert. Um den Wert von Input-Feldern auszuwählen, kann beispielsweise „@value“ verwendet werden.

TestBASequence

Gibt an, ob die Reihenfolge der Kriterien überprüft werden muss. „True“ oder „False“.

Criterion

Ein Criterion enthält den erwarteten Wert und die zu verwendende Vergleichsbedingung.

Ein Business-Attribute-Criterion-Element kann wieder beliebig viele Criterion-Elemente enthalten.

Tabelle 56: Elemente und Attribute des Datentyps Business-Attribute-Criterion

 

Abbildung 5.17: Daten eines Business-Attriubte-Criterions

Abbildung 5.15 zeigt die Daten des Business-Attribute-Criterions „BA View BA Criterion 0“, das auch im Rahmen des Anwendungsfalls erstellt wurde. Das Element AbsElementXPath enthält den XPath-Ausdruck „//table[@class=“details“]//tr“. Dadurch werden alle Zeilen einer bestimmten Tabelle als Elemente ausgewählt. Mit Hilfe des Elements RelNameXPath „th“ wird der Name des Elements auf den Wert der Header-Zelle gesetzt. Weiters setzt das Elemente RelValueXPath „td“ den Wert des Elements auf den Inhalt der ersten normalen Zelle der Tabellen-Zeile. Das Business-Attribute-Criterion enthält zusätzlich mehrere Criterion-Elemente. Jedes dieser Criterion-Elemente entspricht einem Element, das im Response enthalten sein muss. Dabei wird zuerst innerhalb der gefundenen Elemente nach dem entsprechenden Namen gesucht und dann der Wert mit Hilfe des Vergleichsoperators überprüft. In dem in der Abbildung gezeigten Criterion-Element wird etwa die Tabellen-Zeile mit der Header-Zelle „ISIN“ gesucht und der Wert der ersten normalen Zelle mit der Zeichenkette „Test WebTEST1“ und dem Operator „Equals“ verglichen.

Der Datentyp Assertion

Abbildung 5.18: Der Datentyp Assertion

Wie Abbildung 5.18 darstellt, kann der Datentyp Assertion folgende Elemente und Attribute enthalten:

Feld- bzw. Attributname

Beschreibung

Id

Eine automatisch generierte eindeutige Identifikationsnummer.

Name

Ein für den Datentyp eindeutiger Name, der auch in der Benutzeroberfläche  zur Anzeige verwendet wird.

Description

Eine Beschreibung der Assertion, die dem Benutzer in der Oberfläche angezeigt wird. ZB: „Bedingung, die überprüft, ob die zuvor gespeicherten Daten einer Swapcurve richtig angezeigt werden.“

RefTestCaseRef

Die ID eines Referenz-Testfalles. Hier wird keine IDREF verwendet, weil die Testfälle in der übergeordneten TPTP-Datenstruktur festgelegt werden und deshalb nicht im selben XML-Dokument sind.

TestCaseRef

Die ID eines Testfalls (Requests), nach dem die Assertion ausgeführt werden soll. Hier wird wieder keine IDREF verwendet, weil die Testfälle in der übergeordneten TPTP-Datenstruktur festgelegt werden.

Eine Assertion kann beliebig viele TestCaseRef-Elemente enthalten.

XPathCriterionRef

Eine Referenz (eine IDREF) auf ein zu überprüfendes XPath-Criterion-Element.

HtmlCriterionRef

Eine Referenz (eine IDREF) auf ein zu überprüfendes HTML-Criteron-Element.

BusinessAttribute-CrtierionRef

Eine Referenz (eine IDREF) auf ein zu überprüfendes Business-Attribute-Criterion-Element.

Tabelle 57: Elemente und Attribute des Datentyps Business-Attribute-Criterion

 

Abbildung 5.19: Daten einer Assertion

Abbildung 5.19 zeigt die Daten der Assertion „Auto Assertion 0“, die ebenfalls im Rahmen des Anwendungsfalls erstellt wurde. Die Assertion enthält unter anderem eine Referenz auf einen Testfall, bei dem diese Assertion ausgeführt werden muss (TestCaseRef). Weiters werden noch zwei Business-Attribute-Criterion-Elemente referenziert, die im Rahmen dieser Assertion überprüft werden.

 

5.4                     Die verwendeten TPTP-Erweiterungspunkte

Im Folgenden werden die von Web-TEST verwendeten Erweiterungspunkte, des TPTP-Frameworks erläutert. Die folgenden Abbildungen, Abbildung 5.20, Abbildung 5.24 und Abbildung 5.26, zeigen alle von Web-TEST verwendeten TPTP-Erweiterungspunkte aufgeteilt auf die Web-TEST-Plug-Ins.

5.4.1                   Die verwendeten Erweiterungspunkte im Web-TEST-UI-Plug-In

Abbildung 5.20: Die in Web-TEST-UI erweiterten TPTP-Erweiterungspunkte

Abbildung 5.20 zeigt die Erweiterungspunkte, die im Web-TEST-UI-Plug-In verwendet werden. Es folgt eine Auflistung mit einer kurzen Beschreibung der einfachen Erweiterungen und eigene Unterkapitel für die bedeutenderen Erweiterungen.

typeValidators: Dieser Erweiterungspunkt ermöglicht es, bei der Testausführung zu überprüfen, ob der gewählte Testtyp ausgeführt werden darf.

launchconfigRunHandler: Dieser Erweiterungspunkt ermöglicht es, Aktionen vor und nach der Testausführung durchzuführen.

propertySourceExtension: Dieser Erweiterungspunkt ermöglicht es, spezielle Daten für die Eclipse-Property-View zur Verfügung zu stellen.

Der Erweiterungspunkt Testtyp-Beschreibung (typeDescriptions)

Abbildung 5.21: Die Erweiterung des Erweiterungspunkts Testtyp-Beschreibung

In Abbildung 5.21 wird die in Web-TEST verwendete Umsetzung des  Erweiterungspunkts Testtyp-Beschreibung dargestellt. Der Erweiterungspunkt dient dazu, neue Testtypen zu beschreiben. Dabei können neben einer ID auch ein Name, eine Beschreibung und ein Icon für einen Testtyp festgelegt werden. Weiters wird die Dateiendung der Testressource definiert, die diesem Testtyp zugeteilt ist. Eine entsprechende Testressource wird dann mit dem festgelegten Icon im Test-Navigator angezeigt. In Abbildung 5.21 wird im Feld type die ID des Testtyps mit „org.eclipse.hyades.test.web.junit.testSuite“ festgelegt. Diese ID findet sich auch in der Testressource wieder, wie in Abbildung 5.3 gezeigt wurde. Dadurch wird eindeutig bestimmt, welcher Testtyp in der Testressource enthalten ist.

Der Erweiterungspunkt Test-Editor-Extension (editorExtension)

Abbildung 5.22: Die Erweiterung des Erweiterungspunkts Test-Editor-Beschreibung

Abbildung 5.22 zeigt die beiden Realisierungen des Erweiterungspunkts Test-Editor-Extension, die in Web-TEST verwendet werden. Die erste Realisierung, mit dem Namen „Web TEST Http Test Editor“, stellt einen Multi-Page-Editor zum Editieren der Testdefinition eines Web-TEST-Tests zur Verfügung. Die Oberfläche des Editors ist in Abbildung 3.15  dargestellt. Die Implementierung des Editors findet sich in der Klasse org.eclipse.tptp.test.tools.web.ui.test.editor.WebTestEditorExtension. Die zweite Erweiterung, mit dem Namen „Web TEST Assertion Editor“, stellt einen Multi-Page-Editor zum Verwalten von Assertions zur Verfügung. Die Oberfläche dieses Editors ist in Abbildung 3.29 zu sehen. Die Implementierung des Editors ist in der Klasse org.eclipse.tptp.test.tools.web.ui.ass.editor.WebAssertionEditorExtension.

Der Erweiterungspunkt Testcode-Generierungs-Wizard (generateWizard)

Abbildung 5.23: Die Erweiterung des Erweiterungspunkts Testcode-Generierungs-Wizard

Abbildung 5.23 zeigt die Umsetzung des Erweiterungspunkts Testcode-Generierungs-Wizard. Dieser Erweiterungspunkt erlaubt es, einen Wizard zu definieren der die Testdefinition in eine ausführbare Form umwandelt. In Web-TEST wird aus der Testdefinition Java-Code erzeugt. Dieser Wizard ist in der Klasse org.eclipse.tptp.test.tools.web.ui.junit.wizard.WebHttpGenerateWizard implementiert.

5.4.2                   Die verwendeten Erweiterungspunkte im Web-TEST-Core-Plug-In

Abbildung 5.24: Die in Web-TEST-Core erweiterten TPTP-Erweiterungspunkte

Abbildung 5.24 zeigt alle TPTP-Erweiterungspunkte, die im Web-TEST-Core-Plug-In erweitert werden. Es folgt eine kurze Beschreibung der einfachen Erweiterungen:

ExecutableObjectAdapter: Dieser Erweiterungspunkt dient dazu, den Testausführungsprozess zur Laufzeit zu konfigurieren.

ExecutionDeploymentAdapter: Dieser Erweiterungspunkt dient dazu, dem Testausführungsprozess alle nötigen Daten zur Testausführung zur Verfügung zu stellen. Dabei werden die Datentransport-Dienste des Agent-Controllers verwendet.

ExecutionEnvironmentAdapter: Dieser Erweiterungspunkt dient zur Konfiguration der Ausführungsumgebung. Zum Beispiel wird der Testausführung mitgeteilt, wo der Agent-Controller zu finden ist.

launchconfigLaunchableType: Dieser Erweiterungspunkt dient zum Definieren der Testtypen, die über die Eclipse-Launch-Option „Test“ ausgeführt werden können.

launchconfigValidator: Dieser Erweiterungspunkt dient dazu, zu überprüfen, ob eine bestimmte Testressource wirklich über die Eclipse-Launch-Option „Test“ ausgeführt werden kann.

Da der Erweiterungspunkt RegisteredExecutionComponentImpl eine zentrale Rolle in der Ausführung eines Tests spielt, wird dieser in einem eigenen Unterkapitel beschrieben.

Der Erweiterungspunkt Test-Ausführungs-Komponente (RegisteredExecutionComponentImpl)

Mit Hilfe des Erweiterungspunkts Test-Ausführungs-Komponente können einem Testtyp Ausführungskomponenten zugeteilt werden. Nur mit Hilfe dieser Ausführungskomponenten kann ein Test dieses Testtyps über den Agent-Controller ausgeführt werden. Dabei können die Ausführungsumgebung (Environment), der Ausführungsprozess (Executor), der für das Monitoring verwendete Agent und das Ausführungsobjekt (Executable-Object) eingestellt werden.

Da jede der Komponenten über den Agent-Controller auf einer entfernten Maschine ausgeführt werden kann, muss auch jede Teilkomponente eine Stub- (lokaler Stellvertreter) und eine Skeleton-Implementierung (entfernter Stellvertreter) bereitstellen.

Abbildung 5.25: : Die Erweiterung des Erweiterungspunkts Test-Ausführungs-Komponente

In Abbildung 5.25 werden die Einstellung der in Web-TEST verwendeten Ausführungskomponenten dargestellt. Die Komponenten werden als eigene RegisteredExecutionComponentImpl-Elemente hinzugefügt. Das Feld type identifiziert die Art der Subkomponente, das Feld implClass gibt die Realisierung an, und mit Hilfe des Unterelements SupportedTestType kann angegeben werden, für welchen Testtyp diese Einstellungen verwendet werden. In Web-TEST werden dabei folgende, in  Abbildung 5.25 dargestellte, Komponenten festgelegt:

Teilkomponente

Beschreibung

Environment

Diese Komponente der Ausführung hat das Wissen über die Ausführungsumgebung. Alle nötigen Umgebungsvariablen können vom Executor über diese Komponente abgefragt werden. Implementiert wird diese Komponente, für den Web-TEST-Testtyp „org.eclipse.hyades.test.web.junit.testSuite“, von der Klasse org.eclipse.hyades.execution.core.impl.ExecutionEnvironmentImpl.

Executor

Diese Komponente der Ausführung stellt Dienste bereit, um ein Executable-Object zu starten, zu steuern und zu beenden. Implementiert wird diese Teilkomponente von der Klasse org.eclipse.hyades.execution.core.impl.ProcessExecutorImpl.

Debug-Executor

Ermöglicht das Ausführen von Executable-Objects im Eclipse-Debug-Modus. Gegenüber der Executor-Teilkomponente wird eine andere Stub-Implementierung speziell für den Debug-Modus verwendet: org.eclipse.hyades.execution.harness.DebugExecutorStub.

Agent

Stellt eine Schnittstelle zum Überwachen der Ausführung des Executable-Objects zur Verfügung. Zu erwähnen ist, dass die meisten Funktionen lokal im Stub-Teil umgesetzt sind und die eigentliche Agent-Implementierung kaum verwendet wird. Der Stub-Teil ist in der Klasse org.eclipse.hyades.execution.local.JavaTaskRemoteHyadesComponentStub realisiert und implementiert fast alle Methoden selbst, ohne auf die Agent-Implementierung in org.eclipse.hyades.execution.core.impl.JavaTaskRemoteHyadesComponentImpl zurückzugreifen.

Executable-Object

Ein Executable-Object ist eine Klasse die vom Executor in einer eigenen JVM ausgeführt werden kann. Das Executable-Object ist eine Hülle für den Quellcode eines Web-TEST-Tests. Dadurch kann der Test über den Agent-Controller ausgeführt werden. Realisiert wird diese Komponente der Ausführung in der Klasse org.eclipse.hyades.execution.core.impl.JavaProcessExecutableObjectImpl.

Tabelle 58: Erweiterungspunkt Test-Ausführungs-Komponente

Für die Umsetzung des Erweiterungspunkts Test-Ausführungs-Komponente konnten in Web-TEST die Klassen des TPTP-URL-Tests herangezogen werden. Somit wird zwar der Erweiterungspunkt von Web-TEST erweitert, um bekannt zu geben, wie ein Web-TEST-Test ausgeführt wird, dabei wird jedoch auf die selben Implentierungsklassen zurückgegriffen wie auch im TPTP-URL-Test.

5.4.3                   Die verwendeten Erweiterungspunkte im Web-TEST-Recorder-Plug-In

Abbildung 5.