Analyse und Bewertung des Tools Selenium

Aus Winfwiki

1 Titel

2 Inhaltsverzeichnis

3 Abkürzungsverzeichnis

4 Abbildungsverzeichnis

5 Tabellenverzeichnis

6 Einleitung

Schon lange bekommt man eine Software nicht mehr auf eine 3 ½ Zoll Diskette. Dies liegt nicht allein an der graphischen Oberfläche, sondern auch an der stetig steigenden Komplexität von Software. Vorbei sind die Zeiten einfacher Programmcodes mit HTML. Mittlerweile stecken in der Web-Programmierung komplette Content Management Systeme mit einer Vielzahl von Funktionen die nicht mehr überschaubar sind. Um solche Programme prüfen zu können sind mittlerweile ganze Testteams erforderlich, die enorme Ressourcen wie Arbeit und Geld verbrauchen. Im Bezug auf den Umfang von Web-Applikationen besteht nun auch die Notwendigkeit von Werkzeugen zur Testautomatisierung. Softwarehersteller können nur so sicherstellen, dass Software korrekt und zuverlässig arbeitet. Automatisiertes Testen ermöglicht die effiziente Durchführung von Regressionstests^[1]. Diese Seminararbeit befasst sich ausschließlich mit dem Testwerkzeug Selenium. Dieses Open Source Produkt soll eine kostengünstige, schnelle und flexible Möglichkeit der Testautomatisierung von Web-Applikationen bieten.

7 Grundlagen

7.1 Softwaretest

Abbildung 7.1-1: Schematische Darstellung des Softwaretest^[2]

Der Softwaretest dient als Werkzeug für die Qualitätssicherung eines Produktes. Ziel des Softwaretest ist es, fehlerhaftes Verhalten von Spezifikationen eines Programms aufzudecken. Dabei wird der Sollzustand mit dem Istzustand verglichen und anschließend beurteilt. In der Abbildung 7.1-1 ist eine schematische Darstellung eines Softwaretest beschrieben. Die Software-Testklassifikation wird im Verlauf der Arbeit noch näher erläutert.

"Testen ist der Prozess, ein Programm mit der Absicht auszuführen, Fehler zu finden. [...] Testen [ist] ein destruktiver, ja geradezu ein sadistischer Prozess."^[3]

7.2 Testautomatisierung

In der Geschichte versuchten die Menschen immer wieder Prozesse zu vereinfachen und auch zu automatisieren. Durch Automatisierung werden vor allem wiederkehrende und arbeitsintensive Aufgaben dem Tester abgenommen. Dies schafft nicht nur freie Ressourcen, sondern sorgt gleichzeitig für qualitätssichernde Maßnahmen. Tester die immer wieder die gleichen Fälle bearbeiten, neigen eher zu Fehlern als ein automatisierter Prozess durch Testfälle und Testsuites. Ein Testfall beschreibt das Verhalten einer Eigenschaft, Funktion oder Methode im Zusammenhang mit definierten Spezifikationen. Testfälle werden an Hand von Prüfebenen, Prüfkriterien und Prüfmethodik erstellt. Wenn man mehrere Testfälle zusammenfasst spricht man von einer Testsuite. Ein großer Vorteil des automatisierten Testens ist die Wiederverwendbarkeit und Reproduzierbarkeit. Zudem können Tests immer und immer wieder durchgeführt werden. Dies führt in der Regel zu besseren und aussagekräftigeren Testergebnissen. Dennoch ist zu beachten, dass Testautomatisierung nicht immer sinnvoll ist. In Einzelfällen sind die Aufwände zur Erstellung der Test-Skripte und die anschließende Wartung höher als manuelles Testen. Es darf zudem auch nicht vergessen werden, dass automatisiertes Testen keine Fehlerfreiheit garantiert, denn ein vollständiges Testen ist niemals möglich^[4]. Automatisiertes Testen bietet im Idealfall Wiederverwendbarkeit und Reproduzierbarkeit. Manuelles Testen hingegen erlaubt projektspezifisches und individuelles Vorgehen. Es können somit nicht nur Fehler aufgezeigt werden, sondern auch konstruktive Optimierungsvorschläge gegeben werden.

7.3 Ziele von Softwaretests

"Schon wieder Blue Screen" oder "Wieso wird das Formular nicht versendet" kommt jedem sicherlich bekannt vor. Szenarien wie diese kommen immer wieder bei Anwendern vor und sorgen für Unzufriedenheit. Dies zu verhindern ist eines der Ziele von Softwaretests. Mit Softwaretests wird versucht möglichst viele und schwerwiegende Fehler mit geringem Aufwand in kürzester Zeit zu entdecken. Dabei wird ein Fehler als nicht korrekte Verhaltensweise einer vorher definierten Spezifikation verstanden. Die Sicherstellung der Produktqualität muss gewährleistet werden. Da die Programme aber immer komplexer und kurzlebiger werden, braucht man schnellere und flexibler Testwerkzeuge, die auch ohne großen Aufwand bedient werden können. Produktqualität hat dabei mehrere Merkmale:

• Funktionalität
• Zuverlässigkeit
• Benutzbarkeit
• Effizienz
• Änderbarkeit
• Übertragbarkeit

Durch sogenannte Test-Skripte können die Merkmale für Produktqualität überprüft werden ohne unnötig Ressourcen zu verbrauchen. Auch wenn die Vorbereitung auf einen automatisierten Test durchaus höheren Aufwand erfordert, können in vielen Fällen enorme Zeitersparnisse erzielt werden. Dies ist dann der Fall, wenn bereits existierende Testfälle auf ein modifiziertes Programm erneut angewandt werden kann. Diese Art von Test wird Regressionstest genannt.

Weitere Teilziele von Testautomatisierung

• Effektive Gestaltung von Testfällen

Die effektive Gestaltung von Testfällen ist Voraussetzung für effizientes Testen und das Erreichen der unten angeführten Teilziele. Testskripte müssen gut geplant und strukturiert sein, damit sie auch wiederverwendbar und flexibel anpassbar sind. So kann immer kurzfristig auf Softwareänderungen reagiert werden. Das Testen im Allgemeinen wird dadurch nicht nur schneller, sondern auch effizienter.

• Automatisierung zeitintensiver Aufgaben

Die Problematik bei zeitintensiven und einfachen Aufgaben kann durch Testautomatisierung gelöst werden. Stupide Tastatureingaben oder das Ausfüllen von Formularen können durch die Automatisierung nicht nur schneller und zuverlässiger durchgeführt werden, sondern erhöhen auch die Motivation der Tester, die in der Regel die langweiligen Eingaben monoton durchführen.

• Ressourcen Erhöhung

Testautomatisierung führt in der Regel zu mehr freien Ressourcen, da sich die Mitarbeiter oder Tester anderen wichtigen Aufgaben zuwenden können, wie zum Beispiel dem Planen und Warten von Testfällen. Diese können bis heute nicht automatisiert werden und verlangen manuelles Eingreifen.

• Höhere Fehler-Erfassung

Eine höhere Fehler-Erfassungsquote wird nicht zwangsweise durch Automatisierung erreicht, jedoch kann Automatisierung dabei unterstützen, Fehler schneller zu finden.

• Kosteneinsparung

Ein durchaus nicht zu vernachlässigender Punkt ist die Kosteneinsparung. Erst wenn sich auch die Kosten der Testautomatisierung im Vergleich zum manuellen Testen mindestens ausgleichen, ist Automatisiertes Testen sinnvoll. Dass sich die Kosten meist erst später decken ist dabei nicht ungewöhnlich. Eine gute Planung der Testfälle und Testsuites, die Wiederverwendbarkeit gewährleisten, sind Voraussetzung für dieses Teilziel. Ähnlich wie bei Investitionen wird der Gewinn erst nach einiger Zeit erfolgen.

7.4 Testklassifikation

Tests lassen sich bezüglich ihrer Merkmale in Klassen einteilen. Abbildung 7.4-1 stellt die Klassifikation der Testarten, welche im Folgenden erläutert werden, schematisch dar.

Abbildung 7.4-1: Die drei Merkmalsräume der Testklassifkation^[5]

7.4.1 Prüfebenen

Abbildung 7.4.1-1: Übersicht der Prüfebenen^[6]

Softwaretests werden in vier unterschiedliche Prüfebenen unterschieden, wie in Abbildung 7.4.1-1 zu sehen. Diese unterscheiden sich durch die zu testende Programmstruktur und die Phase in der sich die Entwicklung befindet. Nicht unterschieden wird, was mit Hilfe der Testfälle getestet wird.

• Unit-Test

Beim Unit-Test wird eine einzelne Unit getestet. Diese stellt die kleinste testbare Programmeinheit dar. Durch diese sehr wage Definition von Units werden in der Praxis innerhalb eines Unit-Tests von Funktionen, über Klassen, bis hin zu ganzen Klassenpaketen getestet.

• Integrationstest

Der Integrationstest bildet die nächst höhere Prüfebene. Hier wird getestet, ob die bereits in Unit-Tests einzeln getesteten Module, zu größeren Software-Komponenten zusammengesetzt, fehlerfrei mit einander funktionieren.

• Systemtest

Nachdem alle System-Komponenten zusammengesetzt und jeweils mit einem Integrationstest erfolgreich getestet wurden, wird ein Systemtest durchgeführt, um das System als Ganzes auf die Einhaltung des Pflichtenheftes hin zu prüfen. Im Gegensatz zum Integrationstest wird beim Systemtest rein funktional, ohne Kenntnis der internen Programmstruktur, getestet.

• Abnahmetest

Der Abnahmetest unterscheidet sich nur wenig vom Systemtest. Hierbei testet nicht der Hersteller der Software, sondern der Auftraggeber in einer realen Umgebung mit authentischen Daten.

7.4.2 Prüfkriterien

Abbildung 7.4.2-1: Prüfkriterien ^[7]

Der zweite Baustein der Testklassifikationen sind die verschiedenen Prüfkriterien. Das Schaubild 7.4.2-1 zeigt die schematische Darstellung der Prüfkriterien. Anders als bei den Prüfebenen spielen hier die inhaltlichen Aspekte eine Rolle für die Erstellung der Testfälle. Unterschieden wird hier in den folgenden Oberklassen.

• Funktionaler Softwaretest

Bei den Funktionalen Softwaretests werden hauptsächlich die Funktionen der Software getestet. Sowohl einfachste Funktionen wie Sortieren einer leeren Liste oder drehen von Elementen werden geprüft. Solche Funktionstests werden nochmals unterteilt in Crashtests, Zufallstest und Trivialtests.

• Operationaler Softwaretest

Der operationale Softwaretest befasst sich mit der Programmumgebung, also um Sicherheitstests, Installationstests und Ergonomietests. Diese Art von Test ist sicherlich wichtig für das gesamte Produkt, jedoch hat der funktionale Softwaretest Priorität.

• Temporaler Softwaretest

Tests dieser Art prüfen die Leistungsfähigkeit des Programms zu jedem beliebigen Zeitpunkt und Zustand. Unterteilt wird hier in Stresstest, Lasttest und Laufzeittest.

7.4.3 Prüfmethodik

Abbildung 7.4.3-1: Die drei klassischen Prüfmethodiken im Vergleich ^[8]

Beim Testen gibt es verschiedene Techniken zur Erstellung von Test Skripten. Auf die drei klassischen Prüftechniken wird im Folgenden eingegangen.

7.4.3.1 Black Box Test

Im sogenannten Black Box Test (Ein-/Ausgabe Test) betrachtet der Tester oder das Test Skript das Programm als Black Box, also als einen Gegenstand, der nicht bekannt ist. Da die Funktionsweise des Programms nicht bekannt ist, sondern nur dessen Spezifikationen, wird allein auf diese getestet (vgl. Abbildung 7.4.3-1, links). Ein Black Box Test kann nicht alle Fehler aufdecken, ist aber häufig sinnvoll um nicht funktionsorientiert zu testen. Ein Programmierer, der sein Programm selber testet oder das Test Skript erstellt, geht meist von anderen Testfällen aus.

• Vorteil

Bei einem Black Box Test werden häufig Fehler gefunden, die meist durch falsche Bedienung des Programms verursacht werden mit denen ein Programmierer nicht unbedingt rechnet.

• Nachteil

Es können auf Grund der möglichen Testreihen nur eine geringe Anzahl der möglichen Fehler aufgedeckt werden. Um möglichst viele Fehler aufzudecken, müssten die entsprechenden Testszenarien in astronomischer Anzahl erstellt werden.

7.4.3.2 White Box Test

Der White Box Test oder auch Glastest genannt, ist das Gegenstück vom Black Box Test. White Box-Techniken nutzen im Gegensatz zu Black Box-Techniken die Struktur des Programmcodes^[9]. Die Funktionsweise des Programms ist hier bekannt, das heißt es wird ein Funktionstest des Programms durchgeführt (vgl. Abbildung 7.4.3-1, Mitte). Meistens ist der Programmierer auch gleichzeitig der Tester und erstellt somit die Skripte für den Test. Dies kann negative Folgen für das Testergebnis haben, wenn der Programmierer nach seinen Vorstellungen testet, wie die Software zu reagieren hat. Daher macht ein reiner White Box Test in vielen Fällen keinen Sinn. Die Mischung aus White Box und Black Box Test führt zu brauchbaren und aussagekräftigen Testergebnissen.

• Vorteil

Die Funktionen eines Programms sind meist fehlerfrei, da der Programmierer direkt auf Funktionen hin testet.

• Nachteil

Es ist durchaus möglich, dass zwar die Funktion eines Programms korrekt ist, jedoch nicht den Spezifikationen entspricht. Dies bedeutet dass die Syntax korrekt ist, jedoch die Semantik falsch.

7.4.3.3 Grey Box Test

Diese Testmethode kombiniert sowohl die Vorteile des Black Box Test als auch die Vorteile des White Box Test. Bei Grey Box Tests werden die Testfälle nach den Prinzipien des Black Box Tests erstellt. Jedoch verschafft sich der Software Tester zuvor einen Überblick über die interne Programmstruktur und lässt dieses Wissen in die Testfallkonstruktion einfließen (vgl. Abbildung 7.4.3-1, rechts)^[10]. Der Grey Box Test ist aber nicht als Alternative zu White Box Tests zu sehen, da Programmierer von einer anderen Sicht aus testen und eher funktionsorientiert arbeiten. Der Grey Box Test optimiert lediglich die Methode des White Box Tests.

7.5 Anwendungsbereiche automatisierter Tests

Die Anwendungsbereiche für automatisiertes Testen sind breit gefächert. Schon in den frühen sechziger Jahren versuchte man Prozesse zu automatisieren. Zu diesem Zeitpunkt gab es zwar noch keine Web-Anwendungen oder andere komplexe Programme, dennoch wollte man die monotonen und immer wiederkehrenden Aufgaben an Maschinen weitergeben. In Zuge der schnellen Verbreitung von PCs, sowohl im Heim als auch im gewerblichen Bereich, wurde automatisiertes Testen immer wichtiger. Automatisierte Prüfroutinen für Hard- und Software sollen das Verhalten von Maschinen und Programmen analysieren und auf Fehler aufmerksam machen. In den letzten Jahren hat sich vor allem der Softwarebereich als geeigneter Anwendungsbereich für automatisiertes Testen etabliert. Die Komplexität von Software-Programmen und kürzere Programm-Lebenszyklen, führen zu immer aufwendigeren Tests, die durch manuelles Testen nicht immer komplett abgedeckt und kostensparend durchgeführt werden können. Der Bereich der Web-Applikationen in Verbindung mit Selenium wird hier analysiert und bewertet. Mit Selenium soll dem Entwickler oder aber auch dem Test-Team ein Werkzeug zur Verfügung gestellt werden, welches nicht nur einfach zu bedienen und Open-Source ist, sondern auch Plattformunabhängig, Browser unabhängig und mit allen gängigen Sprachen wie PHP, Java oder Python kompatibel ist.

7.6 Besonderheiten beim Testen von Web-Anwendungen

Beim Testen von Web-Anwendungen sind wichtige Punkte zu beachten. Anders als bei normalen Desktop-Anwendungen wird auf mehreren Ebenen des ISO/OSI-Schichtenmodells gearbeitet. Hierdurch können ganz andere Fehlerquellen auftreten, die eine Desktop-Anwendung in der Regel nicht hat. Tests müssen daher speziell auch auf die Netzwerkkommunikation hin getestet werden. Da die Netzwerkschicht im unteren Bereich des Schichten-Modells liegt, sind Fehler meist äußerst schwer zu finden und zu reproduzieren. Hier kann also nur per Black Box Methode getestet werden. Zudem kommt auch die Möglichkeit der Verwendung von unterschiedlichen Browser. Tests müssen also auf allen Browsern durchgeführt werden, was wiederum mehr Zeitaufwand für den Test bedeutet. Letzlich ist auch zu beachten das bei Web-Anwendungen der Client immer unterschiedliche Hard- und Software-Konfiguratrionen hat, was das Testen enorm erschwert. Zwar können die gängigen Soft- und Hardware Konfiguration per Automatischem Test durchgeführt werden, dennoch steigt die Fehlerquote im Bereich von Web-Anwendungen.

8 Komponenten von Selenium

Selenium ist eine Zusammenstellung von Werkzeugen zum Testen von Webapplikationen. Es wurde von ThoughtWorks entwickelt, ist heute Open-Source und unter Apache 2.0 lizenziert^[11]. Um Testfälle auszuführen steuert Selenium einen Webbrowser mit Hilfe von JavaScript. Dies ermöglicht es verschiedene Browser auf unterschiedlichen Plattformen zu unterstützen. Allerdings sind die JavaScript Implementierungen in den meisten Browsern nicht vollständig miteinander kompatibel. So ist es notwendig für die unterschiedlichen Browser auch mehrere JavaScript-Code Bibliotheken zu verwenden. Für die gängigen Browser bringt Selenium JavaScript-Code Bibliotheken mit und wählt den jeweils passenden aus. Durch die breit gefächerte Kompatibilität eignet sich Selenium daher, laut Aussage der Entwickler, vor allem für Browser-Kompatibilitäts-Tests und funktionale System-Tests.

Hauptsächlich besteht Selenium aus den Komponenten

Selenium Core,

Selenium IDE,

Selenium Remote Control und

Selenium Grid.

Des Weiteren gibt es noch

Selenium on Rails,

Selenium on Ruby,

CubicTest (for Eclipse) und

Bromine^[12].

Jede Komponente spielt eine spezielle Rolle bei der Entwicklung und Unterstützung von automatisierten Tests für Webanwendungen. Diese Ausarbeitung konzentriert sich auf die vier erstgenannten Komponenten, da sie die Haupteinsatzzwecke von Selenium abdecken.

Selenium ist auf einer Vielzahl von Browser / Betriebssystem Kombinationen lauffähig. Die Tabelle 8.1-1 gibt dazu einen Überblick.

In den folgenden Abschnitten werden die verschiedenen Komponenten sowie die Selenium eigene Sprache Selenese vorgestellt und die jeweiligen Einsatzzwecke bestimmt.

8.1 Selenese

Die Sprache Selenese besteht aus Actions, Acessors, Element Locators und Variablen.

• Actions

Actions sind Befehle zur Manipulation der zu testenden Webanwendung, also wo der Test wirklich etwas in der Anwendung macht. Actions sind zum Beispiel

• click

einen Button oder Link anklicken

• type

etwas in ein Textfeld eingeben

• open

öffnet eine URL im Browser

Jede Action hat ein zugehöriges Pendant mit dem Suffix AndWait. Diese veranlassen Selenium dazu, nach der ausgeführten Aktion auf das Laden einer neuen Seite zu warten.

Sollte die Ausführung eines Action-Kommandos fehlschlagen, bedeutet dies, dass der gesamte Test fehlgeschlagen ist und die weitere Ausführung des Testfalls gestoppt wird.

• Accessors

Accessors dienen dazu den Zustand der Anwendung zu untersuchen. Es gibt sie in sieben verschiedenen Ausführungen:

• store (locator, variable)

Mittels der store-Kommandos können Werte, wie zum Beispiel bei storeTitle, in Variablen geschrieben werden

• verify und verifyNot (locator, pattern)

Anhand der verify-Kommandos kann überprüft werden, ob bestimmte Elemente der Anwendung dem gewünschten Zustand entsprechen.

Tritt bei einem verify-Kommando ein Fehler auf bricht der Test nicht ab, der Fehler wird jedoch in der Statistik aufgeführt.

• assert und assertNot (locator, pattern)

Assert-Kommandos funktionieren genauso wie die verify-Kommandos. Der Unterschied ist, dass bei einem Fehler der Test abbricht.

• waitFor und waitForNot (locator, pattern)

WaitFor-Kommandos warten darauf, dass eine Bedingung wahr wird. Tritt diese Bedingung in einem bestimmten Zeitintervall nicht auf, bricht der Test wie bei den assert-Kommandos ab.

• Element Locators

Um Elemente mit den Accessors zu prüfen muss man sie lokalisieren können. Dazu dienen die Element Locators identifier, id, name, dom, xpath, link und css. Zur Verdeutlichung der Erklärungen dient der folgende kurze HTML Quelltext.

<html> <head> </head> <body> <form> <input type="button" id="Button1" name="Knopf1" value="Drücker 1"> <input type="button" id="Button2" name="Knopf2" value="Drücker 2"> <a href="http://www.winfwiki.de" id="link" name="Verweis">Winfwiki</a> </form> </body> </html>

Die Locator id und name beziehen sich direkt auf die gleichnamigen HTML-Tag-Attribute. Der erste Button aus dem obigen Beispiel kann mit "id=Button1" oder "name=Knopf1" angesprochen werden. Der Locator identifier verbindet die beiden zuvor genannten. Identifier sucht zunächst nach einem Element anhand des HTML-Tag-Attributs id und falls nichts gefunden wird nochmals mit dem Attribut name. Die Locator "identifier=Button1" und "identifier=Knopf1" finden also im Beispiel beide das gleiche Element.

Die XML Path Language (XPath) ist eine vom W3C-Konsortium entwickelte Anfragesprache, mit deren Hilfe man Elemente von XML-Dokumenten adressieren kann^[13]. Einen ähnlichen Ansatz verfolgt dom, das Document Object Model (DOM). Auch dieses wird vom W3C-Konsortium spezifiziert und bietet eine API zum Zugriff auf XML-Dokumente. Das Interface stellt eine plattform- und sprachenunabhängige Schnittstelle zum lesenden als auch schreibenden Zugriff dar^[14]. Beide Ansätze verwalten XML-Dokumente als Baum-Strukturen. Bei dem Locator xpath wird als Argument eine XPathExpression und bei dom ein JavaScript-Ausdruck übergeben. Konkret, für den Zugriff auf den ersten Button, gelten unter anderem die Argumente "xpath=//[@id='Button1']", "xpath=//body/form[0]/input[0]", "dom=document.getElementById('Button1')" oder "dom=document.forms[0].elements[0]".

link sucht nach einem Link im Dokument mit dem angegebenen Text. Der Locator "link=Winfwiki" findet im Beispiel den Verweis auf www.winfwiki.de.

Der css Locator spürt Elemente mit Hilfe der CSS Selector Syntax auf. Auch die CSS Selector Syntax ist vom W3C-Konsortium standardisiert^[15]. Um auf den zweiten Button aus dem Beispiel zuzugreifen kann man beispielsweise "css=input[value='Drücker 2']" oder "css=input[id='Button2']" schreiben.

Die Tabelle 8.1.1-1 zeigt die Element Locators mit Beispielen. Zu beachten ist, dass die Beispiele nicht alle Möglichkeiten abdecken.

Locator	Element
	Drücker 1	Drücker 2	Link
id	id=Button1	id=Button2	id=Link
name	name=Knopf1	name=Knopf2	name=Verweis
xpath	xpath=//[@id="Button1"] xpath=//body/form[0]/input[0]	xpath=//[@id="Button2"] xpath=//body/form[0]/input[1]	xpath=//[@id="Link"] xpath=//body/form[0]/a[0]
dom	dom=document.getElementById("Button1") dom=document.forms[0].elements[0]	dom=document.getElementById("Button2") dom=document.forms[0].elements[1]	dom=document.getElementById("Link") dom=document.forms[0].elements[2]
link	nicht möglich	nicht möglich	link=Winfwiki
css	css=input[value="Drücker 1"] css=input[id="Button1"]	css=input[value="Drücker 2"] css=input[id="Button2"]	css=a[href="http://www.winfwiki.de"] css=a[id="Link"]

Tabelle 8.1.1-1: Element Locator Beispiele

• Variablen

Um den oben beschriebenen Store Accessor ausführen zu können werden Variablen benötigt. Variablen speichern einen Wert für die spätere Verwendung. Mit "storeValue id=Button1 temp" wird das HTML-Tag-Attribut value des ersten Buttons in der Variable temp gespeichert. Um auf die Variable zuzugreifen schreibt man ${temp}. Variablen ermöglichen somit eine einfache Logik in Selenese Skripten.

Neben den Standardelementen von Selenium ist es möglich, eigene Actions, Accessors und Locators zu schreiben und zu verwenden. Da Selenium auf JavaScript basiert, müssen hierfür die Methoden nur in JavaScript geschrieben und in der Datei user-extensions.js hinterlegt werden. Selenium schaut in dieser Datei nach und lädt die Funktionen. So ist es möglich, Selenium seinen eigenen Vorstellungen anzupassen, ohne die Original-Quellen zu verändern. Die user-extensions.js kann in allen unten genannten Modulen verwendet werden.

8.2 Selenium Core

Abbildung 8.1.2-1: Startbildschirm der Selenium Core TestRunner Suite

Abbildung 8.1.2-2: Selenium Core TestRunner Suite beim Abarbeiten einer Testsuite

Selenium Core ist das Herzstück von Selenium. In diesem Modul befinden sich die benötigten JavaScript-Bibliotheken für die Ausführung von Testfällen. Es bietet ein Web-Interface zur Durchführung von einzelnen Testfällen und Testsuiten in einem iFrame, wie in Abbildung 8.1.1-1 zu sehen ist^[11]. Um hier Testfälle durchführen zu können, muss vorher für jeden Testfall eine HTML-Datei erstellt werden, die entweder aus der Selenium IDE exportiert oder manuell in einem Texteditor geschrieben wird. Die Datei kann beispielsweise folgenden Inhalt haben:

<table>
    <tr><td>open</td><td>/</td><td></td></tr>
    <tr><td>type</td><td>q</td><td>selenium</td></tr>
    <tr><td>clickAndWait</td><td>btnG</td><td></td></tr>
    <tr><td>verifyTextPresent</td><td>Selenium web application testing system</td><td></td></tr>
</table>

Daraus ergibt sich dann die folgende Tabelle mit Selenese Befehlen:

Zeilen, in denen nicht genau drei Spalten eingetragen sind, werden von Selenium ignoriert und können für Kommentare verwendet werden.

Um mehrere Testfälle zu einer Testsuite zusammenzufassen muss für die Testsuite eine HTML-Datei erzeugt werden, die auf die HTML-Dateien der Testfälle verweist. Dies könnte zum Beispiel folgendermaßen aussehen:

<html>
  <head>
    <title>Test Suite</title>
  </head>
  <body>
    <table>
      <tr><td><b>Test Suite</b></td></tr>
      <tr><td><a href="./Login.html">Login</a></td></tr>
      <tr><td><a href="./SearchValues.html">Test Searching for Values</a></td></tr>
      <tr><td><a href="./SaveValues.html">Test Save</a></td></tr>
    </table>
  </body>
</html>

Im diesem Beispiel wird eine Testsuite Test Suite erzeugt mit den Testfällen Login (Login.html), Test Searching for Values (SearchValues.html) und Test Save (SaveValues.html).

Im Beispiel in Abbildung 8.1.2-1 ist im oberen linken Frame zu sehen, dass derzeit die Testsuite Test Suite geladen ist die eine Hand voll Test beinhaltet. Diese Testsuite ist standardmäßig im Core Modul enthalten und testen den Browser auf bestimmte Funktionen, wie zum Beispiel Popups, DOM Manipulationen oder XPath-Kompatibilität. Im oberen mittleren Frame wird der Inhalt des aktuell ausgewählten Testfalles dargestellt. Diese Tabelle besteht immer aus dem Namen des Testfalles und den durchzuführenden Tests, wobei für jeden Test in der ersten Spalte der Selenese-Befehl steht und in den anderen beiden die Parameter für diesen Befehl. Einige Befehle erwarten nur einen oder gar keinen Parameter. Im oberen rechten Frame befindet sich die Steuerung des TestRunners. Die Buttons in Form von Bildern bedeuten (von links nach rechts) Alle Testfälle dieser Testsuite durchführen, Den derzeit ausgewählten Testfall durchführen, Pause, Weiter und Führe nur den nächsten Befehl aus. Durch Verstellen des Sliders kann stufenlos die Geschwindigkeit, in der die Befehle abgearbeitet werden, eingestellt werden. Außerdem gibt es die Möglichkeit die aktuell involvierten HTML-Elemente auf der zu testenden Seite hervorzuheben. Darunter wird eine Statistik angezeigt aus der entnommen werden kann, wie viele Tests und Befehle bisher abgearbeitet wurden, und wie viele davon fehlerhaft waren. Zuletzt gibt es die Möglichkeit sich die Objektstruktur des HTML-Dokuments der aktuell getesteten Seite und einen Log anzeigen zu lassen. Wie in Abbildung 8.1.2-2 zu sehen ist, werden Testfälle und Selenese Befehle, die erfolgreich durchgeführt werden konnten, grün hinterlegt. Fehlgeschlagene werden rot hinterlegt. Gelb hinterlegt wir der Testfall und der Selenese Befehl, der aktuell abgearbeitet wird.

Durch die Beschränkungen des Webbrowsers sind nicht alle Test möglich die z.B. mit der Selenium IDE oder Selenium RC durchgeführt werden können. Denn durch die Sicherheitsbeschränkungen der meisten Browser (Same Origin Policy) darf JavaScript nur auf Seiten des aktuellen Servers mit dem aktuellen Port zugreifen, so dass nur Web-Applikationen auf dem selben Server getestet werden können, auf denen der TestRunner läuft, und kein Wechsel von HTTP nach HTTPS oder umgekehrt möglich ist^[11].

Das Selenium Core Modul wird kaum noch weiterentwickelt, da der Fokus jetzt auf Selenium IDE und Selenium RC liegt, die ihre eigene Core-Bibliothek mitbringen^[11].

8.3 Selenium IDE

Abbildung 8.1.2-1: Selenium IDE

Abbildung 8.1.2-2: Selenium IDE Source Tab

Selenium IDE ist ein Mozilla Firefox add-on, welches für andere Browser bisher nicht verfügbar ist. Es dient dazu Testfälle direkt im Browser aufzunehmen, abzuspielen, zu editieren und zu debuggen. Es ist die am einfachsten zu bedienende Variante von Selenium und hauptsächlich für Anfänger und nicht Programmierer gedacht.

Durch die Aufnahmefunktion müssen Testfälle nicht manuell geschrieben werden sondern können direkt durch die Bedienung der zu testenden Webapplikation im Browser aufgezeichnet werden. Dazu startet man zunächst das Selenium IDE add-on, welches sich sofort nach dem Start im Aufnahmemodus befindet. Die einzelnen Schritte eines Testfalls können nun einfach durch Bedienung der zu testenden Webapplikation aufgezeichnet werden. Im Selenium IDE Fenster ist nun zu beobachten, wie die benötigten Selenese Kommandos automatisch erstellt werden. Durch die Integration in das Kontextmenü innerhalb des Browserfensters kann durch Rechtsklick auf einen markierten Text oder ein HTML-Element ein Selenese Kommando zur Verifizierung, dass dieser Text oder dieses Element vorhanden ist, erstellt werden. Wenn der Testfall fertig durchgespielt ist kann man die Aufnahme nun durch den entsprechenden Knopf im Selenium IDE Fenster beenden. Die Abbildungen 8.1.2-1 und 8.1.2-2 zeigen einen einfachen Testfall in den zwei möglichen Ansichten Table und Source. In der Table-Ansicht werden die Selenese Kommandos mit den zugehörigen Parametern aufgelistet. Die Source-Ansicht zeigt den zugehörigen Quellcode an in dem auch gespeichert wird. Standardmäßig ist hier HTML vorgewählt, es können aber auch folgende Sprachen zum Speichern gewählt werden:

• Java
• C#
• Perl
• PHP
• Python
• Ruby

Der hier generierte Code kann auch in den anderen Selenium Modulen verwendet werden. Es bietet sich daher an, Testfälle und Testsuiten mit Selenium IDE zu erstellen, um sie anschließend zu exportieren und in den anderen Modulen zu benutzen.

Im Gegensatz zu Selenium Core gilt bei Selenium IDE die Same Origin Policy nicht, da es sich hier um ein Firefox add-on handelt, welches Zugriff auf das Mozilla chrome-Protokoll hat. Chrome bezeichnet grundsätzlich die Oberfläche von Mozilla-Anwendungen, wie Firefox. Die hierzu gehörenden Komponenten können mittels einer chrome-URL angesprochen werden. Da es sich hierbei um installierte Pakete handelt, haben diese nicht die Sicherheitsrestriktionen wie über das HTTP-Protokoll angesprochene Webseiten^[11]. Daraus ergibt sich allerdings das Problem, dass mit Selenium IDE erstellte Testfälle und -suiten nicht unbedingt mit anderen Browsern im Zusammenhang mit Selenium Core kompatibel sind.

Zum Abspielen der aufgenommenen Testfälle bietet Selenium IDE unterschiedliche Optionen. Testfälle können einzeln oder zusammengefasst in einer Testsuite in einer stufenlos einstellbaren Geschwindigkeit abgespielt werden oder per Einzelkommando Schritt für Schritt durchlaufen werden. Außerdem können Breakpoints gesetzt werden um den Zustand der Webanwendung manuell an frei wählbaren Positionen des Testfalls zu begutachten. Kommandos, die erfolgreich abgearbeitet wurden, werden grün hinterlegt und bei einem Fehler wird das entsprechende Kommando rot eingefärbt.

Ein Problem der Selenium IDE ist die Beschränkung auf den Browser Firefox. Selenium will plattform- und browserunabhängig sein, was bei Selenium IDE nicht gegeben ist. Außerdem schränkt die Sprache Selenese die Möglichkeiten stark ein. Schleifen oder die Wiederverwendung von Quellcode, zum Beispiel durch Funktionen, sind nicht möglich. Außerdem ist auch kein Zugriff auf Daten außerhalb des Browsers möglich. Hier setzt Selenium RC an und versucht diese Unzulänglichkeiten, durch Verwendung gängiger Programmiersprachen, zu beheben.

8.4 Selenium Remote Control (RC)

Abbildung 8.1.4-1: Funktionsweise des Selenium RC Servers^[16]

Die bisher vorgestellten Selenium Module, Selenium Core und Selenium IDE, haben einige Schwachstellen was die Durchführung von erweiterten Testfällen angeht. Zum Beispiel ist es nicht möglich Testfälle mehrfach mit verschiedenen Eingabewerten durchzuführen oder auf das Fehlschlagen eines Tests zu reagieren.

Hier leistet Selenium RC Abhilfe. Dieses Modul ermöglicht es Testfälle und Testsuiten in Java, PHP, Ruby, Python, Perl und .Net zu entwickeln. Es ist die flexibelste Möglichkeit Selenium einzusetzen, benötigt jedoch einige Entwicklungskenntnisse um es zu nutzen. Es besteht aus einem in JAVA programmierten Server und bietet einen so genannten Client-Driver für jede der zuvor genannten Programmiersprachen. Der Server dient als Verbindung zwischen den programmierten Tests und der laufenden Application Under Test (AUT). Mit ihm ist es möglich jeden Browser zum Testen zu verwenden. Bei den Browsern die er kennt (zum Beispiel Internet Explorer 6 und 7 und Mozilla Firefox 2 und 3) kann er die Konfiguration des Proxy-Servers automatisch vornehmen. Bei denen die er nicht von Haus aus kennt, muss er mit einer selbst erstellten Konfiguration gestartet werden, nachdem im Browser manuell der Proxy eingestellt wurde. Durch die Funktion als Proxy-Server kann er die Sicherheitsbeschränkungen der Browser umgehen indem er die JavaScript-Bibliotheken aus dem Core-Modul direkt in den HTML-Quelltext der zu testenden Seite einfügt. Außerdem kann er den Internet Explorer und den Firefox in speziellen Modi starten um dieses Problem auch ohne Proxy zu umgehen. Der Internet Explorer wird dabei als eine HTML-Applikation gestartet und im Firefox nutzt er eine chrome-URL^[17], die dort normalerweise nur für interne Konfigurationsseiten verwendet wird und daher keinerlei Beschränkungen unterliegen^[11].

In Abbildung 8.1.4-1 ist die Funktionsweise des Selenium Remote Control Server schematisch dargestellt. Der programmierte Test schickt die Selenese-Befehle an den Selenium Remote Control Server welcher diese mit Hilfe der Selenium Core Befehle an die laufende Instanz der AUT schickt. Diese nutzt dann die JavaScript-Bibliothek des Selenium Cores um die Befehle im Browser durchzuführen und schickt das Ergebnis zurück zum Remote Control Server. Dieser leitet das Ergebnis an das laufende Testprogramm.

Ein einfacher Testfall für die Suche nach selenium bei Google, der in der Selenium IDE aufgezeichnet und im Tabellen-Format so aussieht

würde in Java exportiert so aussehen:

import com.thoughtworks.selenium.*;
import java.util.regex.Pattern;

public class google_test extends SeleneseTestCase {
	public void setUp() throws Exception {
		setUp("http://www.google.de/", "*firefox");
	}
	public void testGoogle_test() throws Exception {
		selenium.open("/");
		selenium.type("q", "selenium");
		selenium.click("btnG");
		selenium.waitForPageToLoad("30000");
		verifyTrue(selenium.isTextPresent("Selenium web application testing system"));
	}
}

Dieser Code kann jetzt frei modifiziert werden. Dadurch ist es möglich zum Beispiel die zu suchenden Begriffe und die daraus erwarteten Suchergebnisse aus einer Datenbank oder anderen Quelle zu laden und durch zu testen oder die Testergebnisse automatisch in eine Test-Datenbank einzutragen oder per Email zu verschicken.

Der Remote Control Server kann außerdem in einem interaktiven Modus gestartet werden, der es erlaubt, während der Tests Befehle in der Konsole direkt an die laufenden Testfälle in den Browser zu schicken und auszuwerten.

8.5 Selenium Grid

Abbildung 8.1.5-1: Aufbau Selenium Grid

Selenium Grid ermöglicht es auf mehrere Selenium RC Server parallel zuzugreifen. Dabei kommuniziert das Testprogramm nicht mehr mit dem Remote Control Server sondern mit dem so genannten Selenium Hub, der mehrere Selenium Remote Control Server verwaltet wie in Abbildung 8.1.5-1 zu sehen.

Bei der Verwendung von Selenium RC ist die Verbindung vom RC Server zum Browser der Flaschenhals. Es können nur wenige Browser-Instanzen gleichzeitig getestet werden, vor allem mit dem Internet Explorer. Wenn nun komplexe Testsuiten durchgetestet werden müssen, kann das einige Stunden dauern. Durch den Einsatz von Selenium Grid wird dieser Flaschenhals verringert, da mehrere RC Server angesprochen werden. Hierfür muss nur eine andere Adresse beim Verbinden des Testprogramms mit dem Server angegeben werden. Alles andere bleibt bestehen, da das Grid die Befehle transparent an die RC Server weiterleitet. Um die Tests wirklich parallelisiert an den Hub schicken zu können sind allerdings Änderungen nötig. Für in Java geschriebene Tests geht das zum Beispiel mit Parallel JUnit oder mit dem parallel-Flag in TestNG. Aber auch ohne die Parallelisierung der Testsuiten ist die zentrale Verwaltung der Testumgebung mit Selenium Grid von Vorteil, da nicht für jedes Projekt ein Remote Control Server genutzt werden muss, sondern alle die verfügbaren RC Server nutzen können^[18].

Wenn ein Testprogramm einen neuen Test starten will und diesen Befehl an das Selenium Grid schickt, prüft dieser, ob ein RC Server mit der geforderten Umgebung verfügbar ist. Sollte keine verfügbar sein, wartet der Hub so lange, bis ein Testfall auf einer passenden Umgebung beendet wurde. Da der Tester im Gegensatz zum Selenium Remote Control Server nicht genau weiß, auf welcher Maschine mit welchem Betriebssystem der Test letztendlich ausgeführt wird, kann die Logik des Grids angepasst werden. Zum Beispiel in der Weise, dass die RC Server das Betriebssystem und die verfügbaren Browser an das Grid melden und beim Starten des Tests nicht nur der Browser so wie hier

setUp("http://www.google.de/", "*firefox");

angegeben wird, sondern die komplette geforderte Umgebung, wie zum Beispiel:

setUp("http://www.google.de/", "Firefox auf Windows XP SP2");

oder:

setUp("http://www.google.de/", "Internet Explorer auf Windows XP SP2 mit französischer Lokalisierung");

Dies ist vor allem dann von Vorteil, wenn es einen Bug in der Web-Applikation gibt, der bei einer bestimmten Kombination, wie zum Beispiel Internet Explorer 6 auf Windows XP mit SP1 oder Firefox 3.5 auf Windows 7, auftritt, da in solch einem Fall einfach ein entsprechende Umgebungsbezeichnung angegeben werden muss, vorausgesetzt solch eine Umgebung ist im Selenium Hub verfügbar^[18].

9 Bewertung des Tools Selenium

Die Bewertung für Selenium erfolgt an Hand der zur Verfügung stehenden Module Core, IDE, RC und Grid. Eine Bewertung mit einer Nutzwertanalyse, die zwei Produkte miteinander vergleicht, wird hier nicht durchgeführt. Selenium wird lediglich als Einzelprodukt bewertet. Kriterien für die Bewertung sind Anforderungen, Einsatzmöglichkeiten, Funktion, Kosten und Nutzen.

9.1 Anforderungen und Funktionen

Selenium stellt verschiedene Anforderungen an die Hard- und Software sowie an die Mitarbeiter, die mit dem Testwerkzeug arbeiten.

Der Vorteil an Selenium ist, dass die Module Core, IDE und RC keine Anschaffung von weiterer Hardware erfordern, da die Software entweder auf dem Server (Core), auf dem die Web-Applikation läuft, oder auf den PC des Testers installiert wird (IDE und RC). Nur in den Fällen, in denen große Testsysteme mit Hilfe von Selenium Grid aufgebaut werden sollen, müssen PCs jeweils für den Selenium Hub in die einzelnen Selenium Remote Control Server bereitgestellt werden.

Die Anforderungen an die Software sind bei Selenium sehr gering. Um Selenium IDE nutzen zu können ist der Mozilla Firefox ab Version 1.5 Voraussetzung, da es dieses Modul bisher nur in Form eines Add-Ons für diesen Browser gibt. Der Selenium Remote Control Server ist in Java geschrieben und benötigt daher ein installiertes Java Runtime Environment (JRE). Ansonsten wird nur noch ein Browser mit JavaScript-Unterstützung benötigt um mit Selenium Tests durchführen zu können.

Ein großer Vorteil von Selenium ist definitiv die geringe Notwendigkeit von Hard Skills. Es sind keinerlei Vorkenntnisse oder Programmierkenntnisse erforderlich. Selbst Grundlagen der Technik von Softwaretests sind nicht erforderlich. Mit der Selenium IDE Rekorder Funktion können selbst Testprozeduren erstellt und wiederverwendet werden. Nur in den Fällen, in denen erweiterte oder dynamische Testfälle erstellt werden sollen, sind je nach nach Komplexität grundlegende bis fundierte Programmierkenntnisse in einer der unterstützten Programmiersprachen erforderlich.

Die Anforderungen und Funktionen der einzelnen Selenium Module sind in Tabelle 9.1-1 dargestellt und zeigen die jeweiligen Schwächen und Stärken

9.2 Einsatzmöglichkeiten

Zunächst muss auf Grund der zur Verfügung stehenden Module geklärt werden, welches Modul für welchen Einsatz den größten Nutzen bringt. Die Tabelle 9.1-1 zeigt hier eine Übersicht der Anforderungen und Funktionen. Selenium IDE ist dabei sicherlich für Einsteiger die richtige Wahl, da es einfach zu bedienen, leicht zu installieren ist und keine weiteren Anforderungen an das zu testende System hat. Mit geringem Zeitaufwand und ohne Programmierkenntnisse lassen sich einfache Testfälle erstellen. Für komplexe und dynamische Tests reichen die Funktionen von Selenium IDE nicht aus. Hier bietet Selenium RC mit seinen Schnittstellen zu verschiedensten Programmiersprachen Abhilfe. Testfälle die in Selenium IDE erstellt wurden, können in die verschiedenen unterstützten Programmiersprachen exportiert und mit Selenium RC weiterverwendet werden. Selenium Core bietet für den Anwender den wohl geringsten Nutzen, da es durch den ausschließlichen Gebrauch der Sprache Selenese nur sehr begrenzte Möglichkeiten hat. Auch die Pflicht es auf demselben Server zu installieren, auf dem die zu testende Webapplikation läuft, schränkt die Möglichkeiten weiter ein. Das Selenium Core Modul bietet dem Anwender lediglich eine Kompatibilität mit allen Browsern.

Probleme ergeben sich bei der Nutzung von Selenium vor allem dann, wenn vom Browser Up- oder Downloads ausgeführt werden sollen. Ein Upload lässt sich nur im Firefox über das chrome-Protokoll realisieren. Ansonsten verbieten die JavaScript Sicherheitsrestriktionen ein scriptbasiertes Steuern der Oberfläche. Bei Downloads verhält es sich ähnlich. Sie lassen sich zwar automatisiert anstoßen, der dann erscheinende "Speichern unter ..." Dialog lässt sich aber nicht steuern. Zugriff auf Daten oder Programme außerhalb des Browsers sind mit den Selenium Boardmitteln nicht möglich. Durch Selenium RC und die unterstützen Programmiersprachen kann diese Einschränkung jedoch umgangen werden. Nützlich wäre eine Funktion Screenshots von den durchgeführten Schritten anzufertigen. Mit Hilfe dieser Screenshots wäre die Fehlersuche einfacher, da so ein aufgetretener Fehler besser lokalisiert werden kann.

Hervorzuheben ist die Möglichkeit Selenium auf einfache Art und Weise mit neuen Funktionen auszustatten. Hierzu gibt es eine spezielle Datei namens user-extensions.js, die die vorhandenen JavaScript Funktionen durch benutzerdefinierten Code erweitert. So kann Selenium unter anderem der Umgang mit Flash beigebracht werden^[20].

Selenium lässt sich im Prüfebenen-Modell hauptsächlich bei den Systemtests einsetzen. Für die anderen Ebenen ist der Aufwand Tests in Selenium zu erstellen entweder zu groß um einen Nutzen zu bringen oder einfach nicht möglich. Prüfkriterien die von Selenium getestet werden können, sind die funktionalen und temporalen Tests. Operationale Tests können von Selenium nicht durchgeführt werden, da die zu testenden Eigenschaften in Web-Applikationen entweder nicht vorkommen oder nicht automatisiert zu testen sind. Ob die Testfälle nach dem Black-, White- oder Grey-Box Verfahren erstellt werden spielt für den Einsatz von Selenium keine Rolle. Allerdings ist es notwendig, sich bei der Erstellung von Black- oder Grey Box Testfällen sehr genau an die Schnittstellenbeschreibung zu halten. Auch die Programmierer der zu testenden Anwendung müssen diese Definitionen streng einhalten. Andernfalls gelingt es mit Selenium nicht die Elemente einer HTML Seite zu lokalisieren und anzusprechen.

Dadurch, dass Selenium Open-Source ist, können die Module den eigenen Anforderungen angepasst werden. Somit können weitere Funktionen hinzugefügt werden oder bestehende Fehler im Programmcode selbständig beseitigt werden.

Alle Module von Selenium sind plattformunabhängig entwickelt worden. Bis auf Selenium IDE sind alle Module dazu browserunabhängig. Infolgedessen eignet sich Selenium sehr gut für Kompatibilitätstest von verschiedenen Browsern auf unterschiedlichsten Plattformen. Mit Hilfe von Selenium Grid im Zusammenspiel mit mehreren Selenium RC Servern kann man sehr gut Last- und Stresstests durchführen.

9.3 Wirtschaftlichkeit

In der Theorie wird Wirtschaftlichkeit als Quotient von Ertrag und Aufwand dargestellt. Dies lässt sich bei einem Tool wie Selenium nur schwer bemessen, da der Aufwand aus sehr vielen Faktoren besteht und sich der Ertrag auch nicht eindeutig auf den Einsatz von Selenium zurechnen lässt. Trotzdem werden hier die anfallenden Kosten und der daraus gezogene Nutzen beschrieben.

9.3.1 Kosten

Da Selenium Open-Source und frei verwendbar ist, fallen keine Kosten für die Beschaffung der Software an. Kosten entstehen nur durch die zusätzlich benötigten PCs für die Nutzung von Selenium RC und Selenium Grid.

Wie bei allen automatisierten Tests ist die Vorbereitung weitaus zeitintensiver als es bei manuellen Tests der Fall ist. Denn zusätzlich zum Testplan müssen die Testfälle erst einmal aufgezeichnet beziehungsweise programmiert werden, bevor die Tests durchgeführt werden können.

Es entstehen also noch versteckte Kosten, die mit in die Bewertung aufgenommen werden müssen. Dazu zählen unter anderem die Entwicklungs- und Wartungskosten für die Testskripte. Selenium ist schon allein durch die Komplexität schwerer zu bedienen als z.B. Webtest. Dadurch fallen für einen Neuanwender sicherlich höhere Kosten für die Erlernung von Selenium an, als für geübte Anwender. Zudem ist die Erstellung der Testskripte für komplexe Anwendungen sehr aufwändig und benötigt auch für einen erfahrenen Nutzer viel Zeit. Bei der Erstellung von Testuiten ist daher auch auf Wiederverwendbarkeit zu achten um die Kosten möglichst gering zu halten.

9.3.2 Nutzen

Durch die Nutzung von Selenium können die Personalkosten für das Testen von Web-Applikationen gesenkt werden. Dies wird zum Beispiel mit Selenium IDE in Verbindung mit Selenium RC erreicht, indem die aufgenommenen Skripte aus der IDE in RC für automatische Tests modifiziert werden um in einer Schleife die möglichen Eingabevariationen abzudecken. Dadurch ist es nicht mehr nötig, dass ein komplettes Testteam lange damit beschäftigt ist, diese Eingaben manuell in der Web-Applikation zu tätigen. Die einmal erstellten Tests können immer wieder verwendet werden, sei es mit geringfügigen Änderungen für das Testen von Änderungen in der Applikation, oder zum schnellen, erneuten Testen nach fehlerhafter Durchführung eines Tests und anschließendem Beheben des Fehlers. Der Nutzen eines Testtools, welches so einfach zu bedienen ist und dennoch viele verschieden Funktionen hat, hat für einen Benutzer definitiv einen hohen Stellenwert. Hinzu kommt auch, dass das Testen mittlerweile einen Großteil des gesamten Projekts in Anspruch nimmt, da ein korrekt funktionierendes Programm zu den Merkmalen der Produktqualität zählt.

9.4 Alternativen

Es gibt mehrere Alternativen die ähnliche Zwecke, Ziele und Möglichkeiten wie Selenium anbieten. Hierzu gehören unter anderem

• WebTest

Eine Alternative zu Selenium ist Canoo Webtest. Dieses ebenso mächtige Testwerkzeug kann auch zum Testen von Web-Anwendungen verwendet werden und bietet Funktionalitäten, die Selenium nicht hat. Es ist möglich dynamisch erzeugte PDF-Dokumente inhaltlich zu testen, zudem können tote Links per Mausklick leicht überprüft werden. Die Rekorder Funktion ist in Webtest ebenfalls integriert und funktioniert mit vielen Browsern.

• Watir, Watij und WatiN

Watir, Watij und WatiN arbeiten entweder mit Ruby, Java oder mit .Net. Ihr grundsätzliches Prinzip ist die Fernsteuerung des Internet Explorers. Watir und WatiN unterstützt zusätzlich noch den Mozilla Firefox. Alle Grundfunktionen des Testens, die Selenium bietet sind auch hier vorhanden, so dass für einen kurzen schnellen Test Watir sicherlich auf Grund der Bedienerfreundlichkeit Selenium vorzuziehen ist. Jedoch ist gerade Selenium RC auf größere Tests ausgelegt und bietet weitere nützliche Funktionen zum Testen, so dass bei größeren Test Projekten sicherlich Selenium die bessere Wahl wäre.

10 Zusammenfassung

Kann Selenium erst einmal vollständig bedient werden, ist die Wirtschaftlichkeit dieser Software hoch. Hierzu muss aber im Voraus abgewogen werden, wie oft und welche Applikationen getestet werden sollen. Bei kleineren Anwendungen, die keine wiederkehrenden Aufgaben oder häufige Softwareänderungen haben, ist Selenium sicherlich das falsche Werkzeug, da die Entwicklungskosten für die Skripte einen zu hohen Aufwand haben. Für große und komplexe Anwendungen ist Selenium dann aber eine gute Wahl. Es ist bei guter Vorbereitung der Testfälle nicht nur wirtschaftlich, sondern auch im Hinblick auf die Ziele der Testautomatisierung das richtige Werkzeug. Selenium bleibt dabei aber nur ein sinnvolles Testwerkzeug für die funktionalen und temporalen Systemtests.

11 Ausblick

In Zukunft werden die Teams von Selenium und WebDriver zusammen arbeiten um ein noch besseres Testsystem bereitstellen zu können. WebDriver wurde von Google entwickelt und bietet ähnliche Möglichkeiten wie Selenium RC und ist ebenfalls Open Source. Es ist aber nicht Kompatibel zu allen Browsern und bietet keine API-Implementierung für so viele Programmiersprachen. Dafür bietet es bessere Testmöglichkeiten in den unterstützten Browsern und eine einfachere API zum Programmieren von Tests. Da für jeden Browser eine eigene C-Library geschrieben werden muss, ist der Aufwand, um neue Browser zu unterstützen, sehr hoch. Daher ist es unwahrscheinlich, dass Browser die kaum genutzt werden, jemals hiermit getestet werden können. Im Gegensatz zu Selenium, welches durch JavaScript mit der Webseite interagiert, nutzt WebDriver das Betriebssystem um auf den Browser zuzugreifen. Dadurch stehen weit flexiblere Testmöglichkeiten zur Verfügung. Zum Beispiel ist es mit Selenium nicht möglich auf der Google-Suchseite durch ein Senden des ASCII-Codes der Taste Pfeil-Runter die Einträge aus der Vorschlagliste zu selektieren.

Aktuell werden vom WebDriver folgende Browser und Programmiersprachen unterstützt:

Zusätzlich gibt es noch den operaDriver, eine Implementierung vom WebDriver für den Opera Browser. Damit ist es sogar möglich, auf Smartphones Tests durchzuführen.

12 Fußnoten

1. ↑ Vgl. Dustin, Seite 4
2. ↑ Braus, Seite 223
3. ↑ Myers, Seite 4
4. ↑ Vgl. Spilner, Seite 10
5. ↑ Hoffmann, Seite 158
6. ↑ Hoffmann, S. 159
7. ↑ Hoffmann, Seite 171
8. ↑ Hoffmann, Seite 174
9. ↑ Vgl. Liggesmeyer, Seite 40
10. ↑ Vgl. Hoffmann, Seite 174
11. ↑ ^{11,0 11,1 11,2 11,3 11,4 11,5} Vgl. Selenium Doc
12. ↑ Quelle der Icons SelHQ
13. ↑ Vgl. W3C1
14. ↑ Vgl. W3C2
15. ↑ Vgl. W3C3
16. ↑ Selenium Doc
17. ↑ Vgl. Chrome
18. ↑ ^{18,0 18,1} Vgl. Selenium Grid
19. ↑ OpenQA a
20. ↑ OpenQA b

13 Literatur- und Quellenverzeichnis