WebAnwendungen testen
Hier möchte ich eine Reihe von Wegen sammeln, wie man Web Applikationen automatisiert testen kann.
Automatisiertes Testen meint in diesem Zusammenhang Mehreres: Ist eine URL vorhanden/erreichbar? Sind Daten wie geplant (aus einer Datenbank, von einer anderen Ressource) auf einer Seite enthalten?Werden bei einer Eingabe neuer Daten diese dann auch angezeigt?
Weitergehend kann man aber auch das automatisierte Testen des Layouts/der Anzeige des von der eigentlichen Anwendung erzeugten HTML-Codes bspw. durch einen pixelgenauen Abgleich automatisch erzeugter Screenshots gemeint sein. Mir ist aber keine Implementierung bekannt, die soetwas leistet.
Weil hierbei auch das allgemeinere Thema des Testens von Anwendungen angeschnitten wird, wird jeweils an geeigneter Stelle darauf einzugehen sein, wie man die einzelnen Lösungen zum Testen von Web Anwendungen in die diesen Bereich überspannenden Test-Frameworks eingebunden werden können (oder noch allgemeiner: wie sie in den den Prozess des automtisierten Testens umgreifenden Build-Prozess eingebunden werden können).
Um die Funktionsfähigkeit einer bestimmten Web Applikation auf einer bestimmten Browser-Plattform testen zu können, kommen grundsätzlich nur die unter Variante B behandelten APIs in Betracht.
Automatisiertes Testen meint in diesem Zusammenhang Mehreres: Ist eine URL vorhanden/erreichbar? Sind Daten wie geplant (aus einer Datenbank, von einer anderen Ressource) auf einer Seite enthalten?Werden bei einer Eingabe neuer Daten diese dann auch angezeigt?
Weitergehend kann man aber auch das automatisierte Testen des Layouts/der Anzeige des von der eigentlichen Anwendung erzeugten HTML-Codes bspw. durch einen pixelgenauen Abgleich automatisch erzeugter Screenshots gemeint sein. Mir ist aber keine Implementierung bekannt, die soetwas leistet.
Weil hierbei auch das allgemeinere Thema des Testens von Anwendungen angeschnitten wird, wird jeweils an geeigneter Stelle darauf einzugehen sein, wie man die einzelnen Lösungen zum Testen von Web Anwendungen in die diesen Bereich überspannenden Test-Frameworks eingebunden werden können (oder noch allgemeiner: wie sie in den den Prozess des automtisierten Testens umgreifenden Build-Prozess eingebunden werden können).
Um die Funktionsfähigkeit einer bestimmten Web Applikation auf einer bestimmten Browser-Plattform testen zu können, kommen grundsätzlich nur die unter Variante B behandelten APIs in Betracht.
Variante A: Eigene Webclients
Vorhandene APIs:
- WWW::Mechanize (Perl, Ruby)
Jeweils in der angegebenen Sprache implementierter HTML-Client, der kein JavaScript spricht. Stellen jeweils ein Objekt zur Verfügung, das die Navigation innerhalb der Seite auf einer relativ abstrakten Ebene (auf der Ebene einer DOM: "finde Links mit Text … und klicke ihn", "trage in das input-Element mit id … folgendes ein und sende das Formular ab", CSS-Selektoren) erlaubt aber auch eine low-level Ebene zugänglich macht, auf der man direkt den HTML-Code untersuchen kann (und dann selbst oder mit einer beliebigen
vorhandenen Bibliothek eine DOM o.ä. erzeugen kann). - HtmlUnit (Java)
In Java geschriebenes Framework zum Testen von Web Applikationen. Interpretiert JavaScript mittels Rhino.
Wird von verschiedenen "höheren" (Open Source) WebApplication-Test-Frameworks im Hintergrund verwendet:- Canoo WebTest (bietet einen Ant-Job "webtest" um Tests in XML als Teil des Build-Prozesses durchführen zu können, erlaubt das Schreiben von WebTests in Groovy),
- JWebUnit (bietet Integration in die bestehende JUnit-API durch Implementation eines "WebTestCase", kann auch andere Backends, bspw. Selenium, als HtmlUnit nutzen),
- JSFUnit aus dem JBoss-Umfeld,
- Celebrity ist in Ruby geschrieben (kann aber über die Java Implementation von Ruby namens JRuby in der JVM leben).
-
JDownloader (Java)
Eigentlich ein Programm zum Downloaden von Dateien von sog. One-Click-Hostern, hat der JDownloader eine breite Unterstützung für die Navigation auf Webseiten, um eben Dateien von One-Click-Hostern automatisiert laden zu können.
Variante B: Vorhandenen Webbrowser fernsteuern
Bei diesem Ansatz wird ein vorhandener Browser ferngesteuert. Generell ist eine Fernsteuerung entweder über eine Schnittstelle des Betriebssystems denkbar (generell über Interprozesskommunikation oder Hooking; COM oder darauf basierend OLE und ActiveX unter Windows, das von allen MS-Sprachen, Java, Ruby,
Python, JavaScript, über AutoIt etc. nutzbar ist; [todo: Möglichkeiten unter Linux recherchieren]), über die der jeweilige Browser einen Zugriff über Interprozesskommunikation erlauben kann, oder über
Erweiterungsmechanismen, die jeder Browser auf seine eigene Art anbietet, oder in Form von JavaScript (hier entweder eingeschränkt durch "rohes" scripten oder Verwendung einer für viele Browser erhältliche Erweiterungen wie GreaseMonkey, Chrome und Opera können GreaseMonkey-Skripte
nativ verstehen). Dafür existieren mehrere Ansätze, bei denen man nach Betriebssystem und Browser unterscheiden muss:
Python, JavaScript, über AutoIt etc. nutzbar ist; [todo: Möglichkeiten unter Linux recherchieren]), über die der jeweilige Browser einen Zugriff über Interprozesskommunikation erlauben kann, oder über
Erweiterungsmechanismen, die jeder Browser auf seine eigene Art anbietet, oder in Form von JavaScript (hier entweder eingeschränkt durch "rohes" scripten oder Verwendung einer für viele Browser erhältliche Erweiterungen wie GreaseMonkey, Chrome und Opera können GreaseMonkey-Skripte
nativ verstehen). Dafür existieren mehrere Ansätze, bei denen man nach Betriebssystem und Browser unterscheiden muss:
-
Der Internet Explorer läuft nur unter Windows. Dort kann man ihn über die OLE-Schnittstelle
fernsteuern. Der IE hat auch eine AddOn-Schnittstelle, mit der man Erweiterungen schreiben kann, die auch eine Fernsteuerung erlauben.
Code: Automatische Google-Suche in VisualBasic
Code: Dasselbe in Ruby - Mozilla hat ein plattformunabhängiges "Component Object Model" XPCOM und ein mächtiges Extension-Modell, Automatisierungen sind so möglich.
-
Chrome/Chromium: Bietet eine C–API zum Testen und Automatisieren. Über den Extension-Mechanismus sind
Automatisierungen denkbar (in Form von GreaseMonkey- a.k.a. UserScripts, die im Kontext der betrachteten Webseite ablaufen können). - Opera: Der Hersteller des nicht-quelloffenen Browsers hat ein PlugIn für seinen Browser bereitgestellt, das sich in die Watir-Plattform (s.u.) einbinden lässt.
Es wäre auch denkbar die vorhandenen Open Source Browser Engines, auf denen dann die jeweiligen Browser aufgebaut sind (also Mozilla’s Gecko und die aus dem KDE-Umfeld stammende und von Chrome und iOS/Safari verwendete WebKit-Engine), direkt zu steuern.
Alle im Folgenden beschriebenen APIs nutzen die eben beschriebenen Möglichkeiten, um einen oder mehrere dargestellt Browser zu automatisieren und eine API auf "höherer" Abstraktionsebene bereitzustellen.
Vorhandene APIs
- iMacros
Kommerzielle Software, die den Internet Explorer und Firefox (via COM/XPCOM) fernsteuern kann und die Erweiterungen für beide eBrowser anbietet, mit denen man Surfverhalten (wie bei einem Makro-Recorder) aufzeichnen kann und das erzeugte Skript anschließend editieren kann.
- Watir-Familie (Ruby)
- Selenium/SeleniumHQ (Java/Ruby)
-
PyAuto (Python)
Bietet Zugriff auf die Automation Proxy Schnittstelle von Chrome/Chromium unter Python.
Ruby Bibliothek mit BSD-Lizenz, die Schnittstellen zu allen gängigen Browsern bietet (native Unterstüzung für IE, die anderen Browser brauchen ein PlugIn, alle außer IE und Firefox sind derzeit als "experimentell" gekennzeichnet, über Celerity s.o. wird ein "headless"-Modus bereit gestellt) und für diese eine einheitliche Fernsteuerungs-/Automatisierungs-API bietet.
Umfangreiche Schnittstellen zu vielen Programmiersprachen, unterstützt alle gängigen Browser, bietet Integration in viele Testframeworks (siehe hier). Bietet die Möglichkeit Surfverhalten mit einem (Firefox-)Plugin aufzuzeichnen und auch mit anderen Browsern auf anderen Plattformen zu wiederholen (siehe hier).
Session-Handling (über URL-Rewriting, Cookies oder auch jegliche Art von Authentifizierung) muss, soweit es zum Testen benötigt wird, selbst programmiert werden, jedenfalls sind mir außer für einzelne Authentifizierungsmethoden keine hieraus spezialisierten Bibliotheken bekannt.
Derartige "selbstgestrickte" HTML-Interpretatoren können natürlich mit den von großen Browserherstellern Engines nicht mithalten, wenn es darum geht, allgemein HTML zu unterstützen, für einen begrenzten Einsatzzweck können sie aber eine interessante Alternative oder Ergänzung darstellen.
Alle hier dargestellten Bibliotheken haben keine GUI und "rendern" die zu testenden Web Applikationen in dem Sinne nicht (headless).