WebAnwendungen testen




WebApps 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.

Variante A: Eigene Webclients

Hierbei wird ein Programm verwendet, dass selbst -in der Regel- HTML und bei Bedarf JavaScript interpretiert und vorher bestimmte Wege durch die WebApplikation geht. Solche Programme können prinzipiell in jeder Programmiersprache verfasst sein, die es erlauben HTTP-Anfragen zu versenden, eine vollständige HTML-Interpretation ist zum Testen u.U. nicht immer notwendig (man kann bspw. auch relativ einfach RegularExpressions verwenden, um das Vorhandensein bestimmter Werte zu überprüfen) und meistens muss man nicht klicken um zu navigieren, sondern hat Kenntnis der richtigen URLs, die man entsprechend generieren kann. (Außerdem gibt es eigene APIs, die aus Roh-HTML-Code eine DOM-Struktur erzeugen können, solche Bibliotheken, z.B. Nokogiri oder Hpricot, finden auch bei den unter Variante A dargestellten APIs Verwendung.) Zur Interpretation von JavaScript können vorhandene OpenSource JavaScript Implementationen genutzt werden (SpiderMonkey, Rhino, SquirrelFish, V8).
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).

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:

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)
  • 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.
  • Selenium/SeleniumHQ (Java/Ruby)
  • 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).
  • PyAuto (Python)

    Bietet Zugriff auf die Automation Proxy Schnittstelle von Chrome/Chromium unter Python.

Getagged mit: , , , , , , , , , , , , , , , , , ,

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*