Analyse und Bewertung des Tools CubicTest

Aus Winfwiki

Name der Autoren:	Josué Badjeck, Joachim Krall, Baris Sancak, Sebastian Kulik
Titel der Arbeit:	"Analyse und Bewertung des Tools Cubic Test"
Hochschule und Studienort:	FOM Essen

Inhaltsverzeichnis 1 Einleitung 2 Grundlagen 2.1 Softwareentwicklung 2.2 Automatisiertes Testen 2.2.1 Methoden 2.2.1.1 White Box Test 2.2.1.2 Black Box Test 2.2.1.3 Grey Box Test 2.2.2 Pro und Contra automatisierter Testläufe 3 Entwicklungsumgebungen 3.1 Einleitung 3.2 Selenium 3.2.1 Einleitung 3.2.1.1 Selenium Core 3.2.1.2 Selenium IDE 3.2.1.3 Selenium Remote Control 3.2.1.4 Selenium Grid 3.3 Eclipse 3.3.1 Einleitung 3.3.2 Architektur 4 Tool Cubic Test 4.1 Autoren 4.2 Einsatzmöglichkeit 4.3 Systemumgebung 4.4 Anwendungskonzepte 4.4.1 Test Projekt 4.4.2 Test 4.4.3 Seitenzustände 4.4.4 Übergänge und Benutzerinteraktionen 4.4.5 Seitenelemente und Merkmale 4.4.6 Kontexte 4.4.7 Wiederkehrende Seiten 4.4.8 Startpunkte 4.4.9 Testsammlungen 4.5 Test Recorder 5 Bewertung des Tools Cubic Test 5.1 Bewertungskriterien 5.2 Anwendungsfallbeispiel 5.2.1 Werkzeuge zur Modellierung[22] 6 Zusammenfassung/Fazit 7 Fußnote 8 Literatur- und Quellenverzeichnis

1 Einleitung

Seit den Anfängen der Softwareentwicklung versucht man dauerhaft die Qualität von Software zu verbessern. Um eine stetig bessere Qualität bei den immer komplexer werdenden Programmen zu gewährleisten, bedient man sich eingängiger Prüfung. Die Anwendung von Testverfahren ist hauptsächlich darauf ausgerichtet Fehler in der Software aufzudecken. Da diese Methodik sehr zeit- und kostenintensiv ist, und Lücken und Fehler in der Programmierung nur schwer zu beheben sind, werden Werkzeuge zur Testautomatisierung schon in den ersten Phasen der Programmierung und Softwareentwicklung eingesetzt. Wichtige Ziele können dabei sein, die automatisierten Tests robuster und wiederverwendbar zu machen. Ein Werkzeug, welches Web-Tests schneller anwendbar machen soll und laut Entwickler leichter zu schreiben ist, wird in dieser Gruppenarbeit analysiert und bewertet, das CubicTest-Tool.

2 Grundlagen

2.1 Softwareentwicklung

„Warum eigentlich testen?“

Bei Komplexen Systemen sind Fehler zwangsläufig die Folge von begrenzten Entwicklungszeiten und Zeitdruck in der Softwareentwicklung. Mögliche Gründe dafür können z.B. Kommunikationsprobleme zwischen Internen und Externen sein, Gedächtnisprobleme, mangelndes fachliches Problemverständnis oder auch hohe Komplexität von Softwarelösungen. Die Lösung, um diese Probleme zu minimieren und eine höchstmögliche Effizienz zu erreichen sind wirkungsvolle Testprogramme. Ein Produkt zum frühestmöglichen Zeitpunkt auf den Markt zu werfen, entscheidet heute nicht selten über das Weiterleben oder das Sterben des Produktes, und somit natürlich auch über Leben und Tod des Unternehmens. Weiterhin erzwingen geringe Budgets und reduzierte Kosten die Unternehmen zu immer schnelleren Handlungen und setzten die Entwickler stark unter Druck. Softwareprojektmanager und Sofwareentwickler wollen dabei zur Zielerreichung so schnell und so gründlich wie möglich testen. Aus diesem Umstand geht man zum Automatisierten Testen über.

2.2 Automatisiertes Testen

Testen und Testautomatisierung sind unterschiedliche Handlungen, die aufeinander aufbauen. Das Ziel und die Intention einer Testautomatisierung besteht darin, effektiv Fehler zu finden und das Testes effizient und langfristig ökonomisch durchführen zu können.

Anforderungen an das automatisierte Testen liegen in der Qualität. Automatisierte Tests müssen programmiert werden. Es werden sich somit bei der Programmierung erneut Fehler einstellen. Deshalb ist es von enormer Wichtigkeit, daß Tests unabhängig voneinander laufen können und somit bei Fehlern eine eindeutige Ursache zu erkennen ist.^[1]

Neben der Identifizierung von Fehlern sind noch weitere Ziele an das Testen geknüpft, wie die Vermeidung, die Erkennung und die darauf folgende Entfernung von Fehlern zur Stabilisierung des Systems. Ein wichtiges Ziel des Automatisierten Testens ist dabei die Unterstützung manueller Testarbeit zur schnelleren Erreichung der o.g. Testziele. „Automatisiertes Testen ermöglicht bei korrekter Implementierung ein schnelleres, besseres und effizienteres Testen. Es kann letzendlich zur Verringerung des Testaufwands führen, zu einer Verringerung des Zeitaufwands, zu der Erstellung eines zuverlässigen Systems und zur Verbesserung der Wiederholbarkeit von Testprozessen.“^[2]

„Eine Definition für automatisiertes Testen könnte etwa folgendermaßen lauten: Verwaltung und Durchführung von Testaktivitäten einschließlich der Entwicklung und Ausführung von Testskripts zur Überprüfung der Testanforderungen mit Hilfe eines automatisierten Testwerkzeugs“^[3]

Das Hauptziel von automatisierten Tests ist also die Software-Qualität. Generell impliziert Software-Qualität alle Merkmale eines Softwareprodukts, welche sich zur Erfüllung der vorausgesetzten Erfordernisse eignen. Da nicht alles was machbar ist, gute Qualität beinhaltet, wendet man neben der Fehlersuche zusätzlicher Faktoren an. Nach der Norm ISO 9126 unterscheidet man folgende fünf :

• Funktionalität beinhaltet alle Charakteristiken, welche die geforderten Fähigkeiten eines Systems beschreiben. Dabei kann Funktionalität noch unterteilt werden in Angemessenheit, Richtigkeit, Interoperabilität, Ordnungsmäßigkeit und Sicherheit.

• Zuverlässigkeit ist die Bewahrung eines spezifizerten Leistungsniveaus unter festgelegten Bedingungen über einen definierten Zeitraum hinweg. Auch die Zuverlässigkeit kann unterteilt werden in Reife, Fehlertoleranz und Wiederherstellbarkeit.

• Benutzbarkeit umfasst die Aufwände wie Verständlichkeit, Erlernbarkeit und Bedienbarkeit,welche für die Softwarebenutzung der Benutzergruppen berücksichtigt werden muß.

• Effizienz impliziert Eigenschaften wie Leistung oder „Performance“. Man testet messbare Ergebnisse zur Aufgabenerfüllung. Solche Messgrößen können dabei Zeitverhalten oder Ressourcenverbrauch sein.

• Änderbarkeit und Übertragbarkeit besteht aus verschiedenen Aspekten wie Analysierbarkeit, Modifizierbarkeit, Stabilität und Prüfbarkeit. Übertragbarkeit umfasst dabei den Betrieb unter verschiedenen Hardware- und Softwareanforderungen z.B. bei unterschiedlichen Betriebssystemen auf verschiedenen Rechnern. Für die Übertragbarkeit sind Anpassbarkeit, Installierbarkeit, Konformität und Austauschbarkeit wichtig. Da nicht alle Qualitätsmerkmale bei einem Produkt gleich gut zu erfüllen sind, ist keine Priorisierung notwendig.^[4]
  

Die Entwicklung der Testautomatisierung von Software betrifft heutzutage nicht alleineden Softwaretester, sondern auch den Softwareentwickler. Während früher Manuelle Tests am Ende des Softwareentwicklungsprozesses ausgeführt wurden, wird automatisiertes Testen heute schon in den Anfängen der Entwicklungsphasen abgehalten, wobei eine ebenfalls sorgfältige Planung unabdingbar ist Die Fähigkeiten automatisierter Tests nehmen stetig zu, da die Nachfrage nach schnelleren und preisgünstigeren Produkten mit besseren Anwendungen dauerhaft steigt.

2.2.1 Methoden

2.2.1.1 White Box Test

Die Methode des White Box Test (Strukturtest):

„Zur gezielten Auswahl von Testeingangsdaten, zur Berücksichtigung interner Zustände (bei Programmen mit internem Gedächtnis) und zum Testen interner Zwischenergebnisse sind die Kenntnis und Nutzung der interne Struktur des Testobjekts notwendig. Dies wird vom White Box Test („inneres Testen“, „Strukturtest“) herangezogen“.^[5] Man spricht auch vom „Glas-Test“ da er sich auf das Interna der Anwendung konzentriert. Der White Box Test ist im Gegensatz zum Black Box Test programmorientiert und wird von den gleichen Entwicklern vorgenommen, welche die zu testende Software programmiert haben. White Box-Tests bedienen sich oft der Einheitsteststrategie auf Modul- und Funktionsebene, im inneren Pfade des Moduls. Der Test hat aufgrund Einzeldurchführungen eine Einsicht in die Interne Funktionsweise des Programms, der Programmcode liegt frei. Weitere Testtechniken können dabei sein:

Einfügen von Fehlern

Testen durch Fehlerbehandlung

Speicherproblemtests

Integrationstests

Kettentests etc.

2.2.1.2 Black Box Test

Der Black Box Test (Funktionstest):

Bei dem sog. Black Box Test wird das Testobjekt von außen betrachtet und die Reaktion auf die Testeingangsdaten nur an den Ausgängen beobachtet. Das Testobjekt wird als „schwarzer Kasten“ wahrgenommen. Dabei wird getestet, inwieweit das Testobjekt seine Funktionen in der Spezifikation erfüllt. Deshalb spricht man neben dem vom „äußerem Testen“ auch vom „Funktionstesten“.^[6]

Der Black Box Test bezieht primär auf die Person des Testers. Bisher wurde immer davon ausgegangen daß der Entwurf, das Kodieren und der anschließende Test immer von derselben Person ausgeführt wird. Diese Sichtweise kann allerdings eine häufige Fehlerquelle sein, da der Programmierer zu subjektiv und voreingenommen vorgeht, und eine objektive Betrachtung nur schwer möglich ist. Bei dem Black Box Test kennt der Tester das Programm nicht selber. Er beurteilt das Programm ledeglich nach der Funktion und weiß in der Regel nichts über die Funktionsweise.^[7]

2.2.1.3 Grey Box Test

Wieso braucht man diese beiden verschiedenen Verfahren? Ein Verfahren reicht in der Regel nicht aus. In der Praxis überprüft man mit White Box Tests wie fehlerfrei programmiert wurde. Mit Black Box Tests wird sichergestellt, daß auch die Anforderungen realisiert worden sind; somit das „Richtige“ programmiert worden ist. Der Grey Box Test ist eine Kombination aus White Box Test(Struktur) und Black Box Test (Funktion). Die Ähnlichkeit zum White Box Test besteht darin, daß dem Tester die Implementierung nicht ganz unvertraut ist, auch wenn er sie nur in groben Zügen kennt und nicht die Details. Die gegenseitige Ergänzung von Struktur- und Funktionstest kann für die Erfüllung von Testaufgaben sehr notwendig sein.

2.2.2 Pro und Contra automatisierter Testläufe

Die Automatisierung von Testabläufen hat – wie alles – zwei Seiten. Ob die Vor- oder Nachteile überwiegen, ist projektspezifisch zu bestimmen.

Pro

• Ein Regressionstest (die Überprüfung der korrekten Behebung früherer Fehler) lässt sich nach Erstellung der Testskripte ohne größeren Auf­wand ausführen.
• Automatisierte Tests sind in kürzerer Zeit durchführbar.
• Bei statischen Projekten und Anwendungen, die sich nur unwesentlich unterscheiden oder immer in derselben Umgebung laufen, lassen sich viele Testfälle abdecken.

Contra

• Vorbereitung und Entwicklung (ggf. auch die Pflege) sind zeit- und kos­tenintensiv.
• Testskripte und Tools selber können fehlerhaft sein und dadurch zu fehlerhaften Testergebnissen führen.
• Häufig ist eine Nachbearbeitung der Testergebnisse erforderlich.
• Der zeitliche, personelle und finanzielle Aufwand lohnt sich erst ab einer bestimmten Projektgröße.^[8]

3 Entwicklungsumgebungen

3.1 Einleitung

Eine Programmierumgebung oder Entwicklungsumgebung ist eine Sammlung von Softwarewerkzeugen, die zur Entwicklung von prinzipiell beliebiger Software verwendet werden kann. Die Entwicklungsumgebung kann aus einem Texteditor zum Schreiben der Programme, einem Dateiverwaltungssystem, einem Binder und einem Compiler bestehen. Oder sie kann sich aus einer umfangreichen Bibliothek von integrierten Werkzeugen zusammensetzten, auf die über eine einheitliche grafische Benutzeroberfläche zugegriffen wird. Im folgenden werden die Entwicklungsumgebungen Eclipse und Selenium näher erläutert.^[9]

3.2 Selenium

3.2.1 Einleitung

Selenium ist eine Open-Source-Software, die das Testen von Web-Applikationen dramatisch vereinfacht. Bei komplexen Anwendungen ist es nahezu ausgeschlossen, sämtliche Aktionen eines Benutzers manuell nachzuvollziehen und miteinander zu kombinieren. Selenium automatisiert diesen Prozess, und der Einstieg ist denkbar einfach: Die Selenium IDE klinkt sich direkt in den Firefox-Browser ein und zeichnet alle Aktionen des Nutzers im HTML-Format auf, um sie später beliebig oft abspielen oder modifizieren zu können. Auch der Internet Explorer, Safari oder Opera spielen diese Tests ab, da der Selenium-Kern browserunabhängig ist; und selbst Tests von Macromedia-Flash-Anwendungen sind möglich.

Mit weiteren Modulen lassen sich auch komplexe Testszenarien realisieren. So lassen sich mit Selenium Remote Control Tests ferngesteuert auf Servern ausführen. Das Selenium Grid schaltet mehrere Computer zu einem Test-Netzwerk zusammen, um die Performanz zu steigern, und erlaubt browserspezifische Tests. Doch nicht nur Tests, sondern auch die Implementierung von Testszenarien, zum Beispiel mit ANT-Tasks, kann Selenium automatisieren.

Selenium ist damit für den einzelnen Entwickler, aber auch für größere Projekt-Teams interessant, zumal die Integration in verbreitete Frameworks wie JUnit oder TestNG kein Problem darstellt.^[10] Zum Testen steuert Selenium den Web-Browser mittels JavaScript. Dadurch können verschiedene Browser auf verschiedenen Plattformen unterstützt werden.

Hauptsächlich besteht Selenium aus den Komponenten:

• Selenium Core,

• Selenium IDE,

• Selenium Remote Control und

• Selenium Grid.

3.2.1.1 Selenium Core

Das Core-Modul enthält die komplette Basisfunktionalität von Selenium, also die Testbefehl-API und den TestRunner. Unter Verwendung des Core-Modules kann die TestRunner.html-Webseite mit verschiedenen Browsern geöffnet werden. Dadurch werden Kompatibilitätstests mit verschiedenen Browsertypen möglich.

Selenium Core

3.2.1.2 Selenium IDE

Selenium IDE ist ein Mozilla-Firefox-Add-on, mit dem es möglich ist direkt im Browser durch die Interaktion mit einer Webanwendung Testfälle aufzunehmen und diese im Browser wieder abzuspielen.

Selenium IDE

3.2.1.3 Selenium Remote Control

RC ist ein Modul, das eine eigene Server-Instanz in Form eines Proxys bereitstellt. Dieser Selenium-Server wird von einem Selenium-Client-Treiber ferngesteuert. Dies kann in unterschiedlichen Programmiersprachen geschehen, wie z. B. in Java, .Net, Perl, PHP, Python, Ruby Bei Java lassen sich diese Testfälle beispielsweise mittels JUnit oder TestNG ausführen.

Selenium RC

3.2.1.4 Selenium Grid

Selenium Grid ist eine Erweiterung von Selenium RC und ermöglicht die parallele Ausführung von Tests auf mehreren Servern, um die Dauer der Testdurchführung zu verkürzen.^[11]

3.3 Eclipse

3.3.1 Einleitung

Eclipse ist der Name einer freien Entwicklungsplattform. Dabei steht die integrierte Entwicklungsumgebung (IDE) im Vordergrund, die sich durch Plug-Ins erweitern lässt und auf dem Code von IBMs Visual Age basiert. Der IT-Riese hatte den Quelltext 2001 komplett veröffentlicht und bezahlt auch heute noch Entwickler, die an Eclipse arbeiten. Vor allem in der Java-Entwicklung ist die IDE dabei prominent. Die Eclipse Foundation leitet die Entwicklung und veröffentlicht beispielsweise auch die "Business Intelligence and Reporting Tools" für Java-Entwickler.^[12]

Eclipse

3.3.2 Architektur

Bis einschließlich zur Version 2.1 war Eclipse als erweiterbare IDE konzipiert. Seit Version 3.0 ist Eclipse selbst nur der Kern, der die einzelnen Plug-ins lädt, die dann die eigentliche Funktionalität zur Verfügung stellen. Diese Funktionalität basiert auf Equinox. Sowohl Eclipse als auch die Plug-ins sind vollständig in Java implementiert. Zur Erstellung der grafischen Oberfläche wurde SWT verwendet. Zur Darstellung der GUI-Komponenten basiert SWT ähnlich wie AWT auf den nativen GUI-Komponenten des jeweiligen Betriebssystems. Eclipse ist daher nicht plattformunabhängig, wird aber für 14 verschiedene Systeme und Architekturen bereitgestellt. Die Plug-ins lassen sich durch einen Download direkt von einem Update-Server oder durch einfaches Entpacken installieren.^[13]

4 Tool Cubic Test

CubicTest ist eine Open Source Anwendung, die unter der Eclipse Public License v1.0 veröffentlicht wurde und stellt ein graphisches Eclipse Plug-in zur Verfügung, um automatisierte Tests von HTML-basierenden Internetanwendungen durchzuführen. Es soll das Erstellen von Tests, die auf Selenium oder Watir basieren, beschleunigen und durch Abstraktion die Wiederverwendbarkeit und Robustheit dieser erhöhen.^[14]

CubicTest visualisiert den Zustand von Webseiten und deren Veränderungen nach einer Interaktion mit diesen Seiten. Damit lassen sich typische Anwendungsszenarien für eine Webseite erstellen und diese dann mit einer beliebigen Anzahl und Kombination von Benutzereingaben durchspielen. Dies ist sowohl mit Webseiten möglich, die auf reinem HTML basieren, aber auch mit Webseiten, die mit AJAX programmiert wurden.

CubicTest ist seit dem 2. Juli 2009 in der Version 1.9.6 verfügbar. Die jeweils aktuellste Version und vorherige Versionen sind entweder direkt aus dem Eclipse Framework als Aktualisierungspaket von http://www.cubictest.org/update zu installieren oder als eigenständige Installation unter http://cubictest.seleniumhq.org verfügbar.

4.1 Autoren

Die Entwicklung von CubicTest begann bereits im Frühling 2005 als Forschungsprojekt bei Beck Consulting AS, um die funktionale testgesteuerte Programmierung voranzutreiben und wurde seitdem durch eine weltweite Gemeinde von Entwicklern vorangetrieben. Unter anderem wurden auch bereits vier Masterthesen über CubicTest geschrieben, die zur Weiterentwicklung beigetragen haben. Die Hauptentwickler sind Christian Schwarz und Stein Kåre Skytteren, die beide bei der Bekk Consulting AS tätig sind. Die Bekk Consulting AS ist ein norwegisches Beratungsunternehmen, das technische Lösungen im Rahmen von Prozessmanagement, Applikationsentwicklung und Management für große Unternehmen und den öffentlichen Sektor anbietet. Die Bekk Consulting AS ist ein Tochterunternehmen der ErgoGroup, einer der führenden norwegischen IT Unternehmen mit über 3700 Mitarbeitern und einem jährlichen Umsatz von mehr als 670 Millionen Euro.^[15]

Eigens für die Arbeit an OpenSource Projekten und deren Veröffentlichung hat die Bekk Consulting AS die BEKK Open Source Software (BOSS) ins Leben gerufen. BOSS ist die Internet-Plattform, auf der alle OpenSource Projekte der Bekk Consulting AS veröffentlicht werden, um diese der OpenSource Gemeinde zur Verfügung zu stellen.^[16]

Dank des großen Interesses an CubicTest verweist BOSS für dieses Projekt mittlerweile auf die Webseite des Selenium Projektes, welche auch der richtige Einstieg für all Interessierten sein sollte. Auf der CubicTest Webseite findet man neben allgemeinen Informationen zu CubicTest auch folgende Informationen:

• Projektdokumentation

• Benutzerforen

• Entwicklerforen

• Projektwiki

• Source Repository

Die Mitarbeit an CubicTest durch die OpenSource Gemeinde erfolgt in erster Linie über das Melden von Fehler, Mitarbeit an der Projektdokumentation und der aktiven Mitarbeit im Benutzerforum, in dem sich die Benutzer gegenseitig helfen.

Die Mitarbeit als aktiver Entwickler erfolgt nach Kontaktaufnahme nur auf Einverständnisses des bestehenden Entwicklerteams und verlangt die vorherige aktive Mitarbeit in der bereits genannten Form.

4.2 Einsatzmöglichkeit

Da Internet-Anwendungen immer größer und komplexer werden, wächst der Zeitaufwand, um diese nach Änderungen immer wieder erneut auf die gezielte Funktionalität und bestehende Qualität zu testen. CubicTest wurde entwickelt, um diese Tests zu automatisieren, und Entwicklern damit eine schnelle und verlässliche Möglichkeit an die Hand zu geben, die Vorgaben von Funktionalität und Qualität einzuhalten. Insbesondere durch die graphische Erstellung und Präsentation von Tests sollen auch nicht technischen Personen, also Personen die keine Kenntnisse in der Programmierung bzw. der Bibliotheken Selenium und Watir haben, in die Lage versetzt werden, diese Tests durchzuführen. Besonders im Umfeld der Agilen Softwareentwicklung sollte der Kunde die Tests spezifizieren, um dadurch die Anforderungen an die Applikation zu stellen.^[17]

Tests, die mit Hilfe von CubicTest erstellt wurden, können benutzt werden, um:

1. Fehler in Form von gescheiterten Tests zu berichten
2. Funktionalität und Qualität von bestehenden Features über den ganzen Entwicklungsprozesses zu sichern
3. Vorgaben an den Entwickler zu geben, bevor neue Funktionalitäten implementiert werden
4. Änderungen an bestehenden Funktionalitäten zu spezifizieren

Der Erfahrung der Entwickler nach ist CubicTest für folgende Anwendungen besonders geeignet:

• Plausibilitätsprüfungen der Hauptfunktionen einer Internetanwendung

• Testen der Javascript Komponente

• Testen von bestehenden Internetanwendungen auf der Ausführungsebene ohne den Einsatz von speziellen Unit Tests

Allerdings merken die Entwickler auch an, dass Tests von einzelnen Web-Komponenten am besten mit Hilfe eines Unit Testing Frameworks durchgeführt werden sollten, um auf den Einsatz eines Webservers zu verzichten und insbesondere die Ablaufgeschwindigkeit der Tests zu erhöhen. Auch sollte das Layout eines Tests wirklich nur die Abläufe umfassen, die für diesen einen Test ausschlaggebend sind, damit die Testresultate möglichst aussagekräftig sind und Quereffekte von anderen Programmteilen zu minimieren bzw. komplett zu eliminieren.^[18]

4.3 Systemumgebung

CubicTest ist grundsätzlich plattformunabhängig, da es als Plug-in für das Eclipse Framework konzipiert ist. Es benötigt allerdings mindestens die Eclipse Version 3.4 Ganymede und das Java 5 Runtime Environment.

Für Windows Betriebssysteme ist der sogenannte Rich Client in einer 32Bit Version verfügbar, der alle benötigten Komponente beinhaltet. Dieses Paket muss auch nicht installiert werden, da das vorkonfigurierte Eclipse aus der heruntergeladenen Ordnerstruktur direkt gestartet werden kann.

Cubic Test Rich Client

Sollte Eclipse bereits in der notwendigen Version installiert sein, kann man auf den Update Manager des Eclipse Frameworks zurückgreifen. Hierbei ist zu beachten, zunächst das Eclipse Graphical Editing Framework (GEF) in der Version 3.1.1 zu installieren. Ist diese vorhanden, muss die CubicTest Adresse http://www.cubictest.org/update/ als neue Installationsquelle angegeben werden. Nach Auswahl des Plug-in CubicTest und Bestätigung des Dialoges steht CubicTest beim nächsten Eclipse Neustart zur Verfügung.^[19]

CubicTest Update Site

Eclipse Update Manager

4.4 Anwendungskonzepte

CubicTest ist hauptsächlich auf zwei Anwendungskonzepten aufgebaut. Dazu gehören zum einen das Konzept der Seitenzustände und das Konzept zur Identifikation von Seitenelementen mit Hilfe von Merkmalen. Im Folgenden werden die Funktionsweise und Terminologien dieser Konzepte beschrieben.^[20]

4.4.1 Test Projekt

Das Test Projekt beinhaltet alle Tests und Ressourcen, die einem Projekt zugeordnet sind. Dieses Test Projekt wird mit allen zugehörigen Elementen im Package Explorer angezeigt.

Der Package Explorer

4.4.2 Test

Ein Test besteht aus einer oder mehrerer Anforderungen an eine Internetanwendung. Er besteht aus einer Serie von Seitenzuständen und den dazugehörigen Benutzerinteraktionen, die den Übergang zwischen diesen Seitenzuständen herbeiführen.

Test Webapplikation

In obiger Abbildung ist die Startseite "CubicShop" eines Webshops dargestellt. Auf dieser sind die Elemente Username und Password als Eingabefelder dargestellt und ein Feld, das den Log-in Vorgang auslöst. In dem grauen Feld darunter sind nun die Aktionen pro Element aufgeführt, die die Anwendung automatisiert durchführt. Das Ziel ist der angezeigte Zustand der "Logged in" Seite.

4.4.3 Seitenzustände

Eine Internetanwendung ist eine Sammlung von Seiten, die abhängig von der Benutzerinteraktion angezeigt werden. Der Zustand der Seiten wird durch das Vorhandensein von verschiedenen Elementen und deren Werten bestimmt. Jede Änderung an einer Seite führt zu einem neuen Seitenzustand.

4.4.4 Übergänge und Benutzerinteraktionen

Der Übergang beschreibt wodurch der Wechsel zwischen den Seitenzuständen herbeigeführt wird. Der Übergang enthält die Benutzerinteraktionen die von CubicTest simuliert werden. Dabei wird spezifiziert welches Element, das dem Benutzer zur Verfügung steht, wie verändert wird. Der Übergang endet mit einem neuen definierten Seitenzustand.

4.4.5 Seitenelemente und Merkmale

Seitenelemente werden verwendet, um den Seitenzustand zu beschreiben. Jedes Seitenelement hat Merkmale, welche dieses auf der jeweiligen Seite identifizieren und die außerdem beschreiben welche Arten von Benutzerinteraktionen zulässig sind. Es ist auch möglich, die Seite auf Elemente zu überprüfen, die nicht vorhanden sind.

Seitenelemente

Alle Elemente in obiger Abbildung sind verwendbar und können über eines oder mehrere der folgende Merkmale identifiziert werden.

• ID

• Name

• Href

• Src

• CSS Klasse

• Tooltip

In untenstehender Abbildung sind die Merkmale eines "Buy" Buttons und die verschiedenen Verknüpfungen mit den möglichen Werten dargestellt.

4.4.6 Kontexte

Über die Merkmale von einzelnen Seitenelementen hinaus, ist es möglich die Elemente aus dem Kontext ihrer Position auf einer Seite heraus zu bestimmen. Sollte zum Beispiel ein "Buy" Button mit den selben Merkmalen mehrfach auf einer Seite vorkommen, kann die Identifikation über die Existenz oder dem Fehlen eines benachbarten Elementes durchgeführt werden.

4.4.7 Wiederkehrende Seiten

Sollten wiederkehrende Seiten in der Internetanwendung vorhanden sein, wie es typischerweise durch ein Navigationsmenü vorkommt, müssen diese Seiten nicht jedes Mal aufs Neue beschrieben werden, sondern können über eine Virtualisierung des Seitenzustandes beliebig oft verknüpft werden.

4.4.8 Startpunkte

Der Startpunkt eines Tests ist entweder eine URL oder alternativ ein Extension Point eines anderen bereits vorhandenen Tests. Ein Extension Point kann zu jedem beliebigen Seitenzustand hinzugefügt werden. Somit kann die fertig entwickelte Log-in Prozedur eines Webshops als Basis für weitere Test benutzt werden ohne erneut alle Seitenzustände und Übergänge zu Beschreiben.

4.4.9 Testsammlungen

Ab einer gewissen Anzahl von Tests wird es unübersichtlich diese komplett mit allen ihren Seitenzuständen und Übergängen anzuzeigen. CubicTest ermöglicht die einfache Aneinanderreihung von verschiedenen Tests durch "Drag and Drop" aus dem PackageExplorer hinaus , sodass in der Übersicht nur die Tests als Elemente angezeigt werden.

4.5 Test Recorder

Ein besonderes Herausstellungsmerkmal von CubicTest ist die Möglichkeit, direkt aus dem Browser heraus ein Testscenario aufzunehmen, sodass dieses automatisch in den graphischen Editor überführt wird. Dies ist eine nützliche Funktion, wenn Tests für bereits bestehende Internetanwendungen erstellt werden sollen und kann dazu dienen Weiterentwicklungen an dieser Anwendung durchzuführen ohne bereits implementierte Funktionen zu beschädigen.

Die Aufnahme der Tests basiert auf der Selenium Remote Control mit der ein Browser automatisiert werden kann. Obwohl der Test Recorder aus dem aktiven Selenium Projekt stammt , wird dieser direkt von dem CubicTest Entwicklern unterstützt. Voraussetzung ist der Einsatz eines Firefox oder Opera Browsers. Der Recorder wird direkt aus CubicTest oder einem Kontextmenü des Browsers gestartet. Das Repertoire des Recorders umfasst unter anderem das Erfassen von Seitenzuständen bis zum Aufzeichnen aller Benutzerinteraktionen. Allerdings gibt es einige Limitationen. So kann der Recorder nicht in Zusammenspiel mit einem Proxyserver genutzt werden und bietet nur eingeschränkte Unterstützung für das Kontext Merkmal.^[21]

5 Bewertung des Tools Cubic Test

5.1 Bewertungskriterien

Die Bewertung einer Software ist seine Beurteilung anhand bestimmter Merkmale. Diese Merkmale werden je nach Zielerreichung des Bedarfsträgers gesetzt. Die gesetzte Merkmale werden auch als Kriterien bezeichnet. Um CubicTest bewerten zu können wurden im ersten Schritt allgemeinene Bewertungskriterien definiert und gesetzt. Im nächsten Schritt wurde das Tool im "Selbstversuch" anhand der definierten Kriterien getestet.

Bewertungskriterien des CubicTest-Tools

Grafische Darstellung der Kriterien

Beschaffung

Wie bereits in den Kapiteln vorher beschrieben, ist CubicTest eine OpenSource Anwendung und kann unter folgendem Link heruntergeladen werden: http://www.cubictest.org.

Installation

Mit Hilfe des "Installationsassistenten" verlief die Installation einwandfrei.

Anwendung

Die Anwendung von der Eclipse-Plattform ist für Anwender ohne entsprechende Erfahrung sehr schwierig. Eine kleine Einführung in die Entwicklungsumgebung ist erforderlich. Die dafür bereitgestellten Tutorials erleichtern die Einarbeitung.

Durchlaufzeiten

Die Durchlaufzeit pro Prozess ist auf 20 Sekunden voreingestellt. Der Testdurchlauf ist zügig.

Dokumentaton/Reporting

Der Verlauf des gesamten Testes wird protokolliert. Alle Fehler werden aufgelistet und angezeigt, was wiederum eine womögliche Fehleranalyse erleichtert. Dokumentationen bzw. Fragen können auf der Homepage in englischer Sprache problemlos bezogen werden.

5.2 Anwendungsfallbeispiel

Als Anwendungsbeispiel wurde folgendes Szenario definiert: Das Tool sollte die Webseite http://www.yahoo.de aufrufen und sich selbstständig anmelden, den Posteingang öffnen, eine E-Mail-Anwendung öffnen,den Verlauf abbrechen, die E-Mail als Entwurf speichern und in Posteingang zurück kehren.

5.2.1 Werkzeuge zur Modellierung^[22]

Mit Hilfe einer URL-Zuweisung wird die entsprechende Webseite lokalisiert. Dieser Schritt wird bei der Anlegung eines CubicTest-Projekts angelegt. Im Anwendungsfallbeispiel wurde folgender Link verwendet: https://login.yahoo.com/config/mail?.src=ym&.intl=de.

Alle Tests die in CubicTest durchgeführt werden, müssen in einem CubicTest-Testprojekt realisiert werden. Das Projekt wird in der CubicTest-Perspektive in Eclipse erstellt.

Die blau hinterlegten Felder, in der unteren Abbildung, repräsentieren URL-Seiten(Beispiel Werkzeugabbildung: CubicShop). Der Navigationspfeil stellt den Übergang(Benutzer) zwischen den beiden Seiten dar. Der Übergang bestimmt welche Aktion geführt werden muss um auf die nächste Seite zu gelangen. Die Attribute wie "Beutzername", "Passwort" etc. (siehe Abbildung) sind Formular-Elemente. Diese bilden die Grundlage für die Interaktion der beiden Seiten.

Fallbeispiel

Ablaufprozess

1. Ruf Yahoo-Mail-Loginseite auf
2. Auf die Aufgerufene Seite gibt es ein Feld mit Yahoo!-ID
3. Ist die Seite richtig?
4. Enter die Yahoo-ID
5. Enter Password
6. Klick auf die Taste „ Anmelden“
7. Ist die Seite richtig?
8. Klick auf die Taste „Posteingang“
9. Ist die Seite richtig?
10. Klick auf die Taste „Neu“
11. Ist die Seite richtig?
12. Klick auf die Taste „Dateien anhängen“
13. Ist die Seite richtig?
14. Klick auf die Taste „Dateien anhängen“
15. Ist die Seite richtig?
16. Klick auf die Taste „Abbrechen“
17. Ist die Seite richtig?
18. Klick auf die Taste „Als Entwurf speichern“
19. Ist die Seite richtig?

Ablaufprozess grafisch

6 Zusammenfassung/Fazit

Zusammengefasst stand die Sensibilisierung für das Themengebiet „Automatisches Testen mit Hilfe des Tools CubicTest“ im Vordergrund. Zum Automatischen Testen kann gesagt werden, dass immer wieder Menschen in der Geschichte danach streben, bestimmte Abläufe zu automatisieren, um schneller und rationeller produzieren zu können und dadurch nicht zuletzt Kosten einzusparen. Auch im Software-Qualitätsmanagement ist das nicht anders.

Die Analyse des Tools CubicTest ergab folgendes Fazit:

Um eine Aussage über die Bewertung des Tools CubicTest zu treffen, wurde entschieden diese anhand einer Nutzwertanlyse zu bestimmen. Wie in den vorher beschriebenen Kapiteln wurden selbst definierte Kriterien ermittelt und unterschiedlich stark bewertet. Die maximale Punktzahl die in dieser Nutzwertanlyse erreicht werden kann beträgt 310. Es wurde festgelegt, dass mindestens 75%( 232,5 Punkte) erreicht werden müssen, damit das entsprechende Tool eine positive Bewertung erhält.

Nutzwertanalyse

Ergebnis der Analyse

Mit einer erreichten Punktzahl von 237 entspricht das Tool den vorher erklärten Anforderungen.

7 Fußnote

1. ↑ Vgl.Vigenschow, Uwe: „Objektorientiertes Testen und Testautomatisierung in der Praxis. Konzepte, Techniken und Verfahren“, dpunkt Verlag, Heidelberg, 2005, Seite 159
2. ↑ Vgl. Dustin, Elfriede; Rashka, Jeff; Paul, John : „Software automatisch testen. Verfahren, Handhabung und Leistung“, Springer Verlag, Berlin, 2001, Seite 135
3. ↑ Dustin, Elfriede; Rashka, Jeff; Paul, John, 2001, Seite 4
4. ↑ Vgl.Vigenschow, Uwe, 2005, Seite 15-17
5. ↑ Trauboth, Heinz Dr.: „Software – Qualitätssicherung. Konstruktive und analytische Maßnahmen“ in : Endres, Albert Prof. Dr.; Krallmann, Hermann Prof. Dr.; Schupp, Peter Dr.: „Handbuch der Informatik“, R. Oldenbourg Verlag, München, 1996, Seite 204
6. ↑ Vgl.Trauboth, Heinz Dr., 1996, seite 203ff.
7. ↑ Vgl. Thaller, Georg Erwin: „Software Test. Verifikation und Validation“, Verlag Heinz Heine, Hannover, 2002, Seite 81ff
8. ↑ http://www.mediasupervision.de/info_center/artikel_archiv/automatisiertertest/
9. ↑ Hansen/Neumann
10. ↑ https://www.opensourcepress.de/index.php?26&backPID=15&tt_products=197
11. ↑ http://de.wikipedia.org/wiki/Selenium
12. ↑ http://www.golem.de/specials/eclipse/
13. ↑ http://de.wikipedia.org/wiki/Eclipse_%28IDE%29
14. ↑ http://cubictest.seleniumhq.org/
15. ↑ http://www.ergogroup.no/default.aspx
16. ↑ http://boss.bekk.no/display/BOSS/Bekk+Open+Source
17. ↑ http://boss.bekk.no/display/BOSS/CubicTest+and+Agile+Software+Development
18. ↑ http://boss.bekk.no/display/BOSS/CubicTest+and+Agile+Software+Development
19. ↑ : http://boss.bekk.no/cubictest/installDetails.html
20. ↑ http://boss.bekk.no/display/BOSS/Essential+Concepts+in+CubicTest
21. ↑ http://boss.bekk.no/display/BOSS/CubicTest+-+Recorder+Plugin
22. ↑ http://boss.bekk.no/display/BOSS/Essential+Concepts+in+CubicTest

8 Literatur- und Quellenverzeichnis

Nr.	Quellebezeichnung
01	Dustin, Elfriede; Rashka, Jeff; Paul, John: „Software automatisch testen. Verfahren, Handhabung und Leistung“, Springer Verlag, Berlin, 2001
02	Thaller, Georg Erwin: „Software Test. Verifikation und Validation“, Verlag Heinz Heine, Hannover, 2002
03	Trauboth, Heinz Dr.: „Software – Qualitätssicherung. Konstruktive und analytische Maßnahmen“ in : Endres, Albert Prof. Dr.; Krallmann, Hermann Prof. Dr.; Schupp, Peter Dr.:
04	Vigenschow, Uwe: „Objektorientiertes Testen und Testautomatisierung in der Praxis. Konzepte, Techniken und Verfahren“, dpunkt Verlag, Heidelberg, 2005
05	Hansen/Neumann Wirtschaftinformatik 2 - Informationstechnik 9.Auflage