-
Gebiet der Erfindung
-
Die vorliegende Erfindung betrifft allgemein die Entwicklung von Software-Anwendungen und insbesondere ein Verfahren zum Testen von Web-Anwendungen.
-
Hintergrund der Erfindung
-
Ein großes Problem der Web-Anwendungen ist es, einen wirksamen Ansatz für die Test-Automatisierung der Web-Oberflächen zu finden. Dieses Problem ist bei Web-Oberflächen mit den neuen Technologien des Web 2.0 (wie AJAX- oder JavaScript-Rahmenstrukturen (Frameworks), z. B. Dojo) von größerer Bedeutung. Eine Web-Seite der Web-2.0-Anwendungen ist nicht einfach nur dynamisch, sondern eine sehr komplexe Anwendung, die das Ergebnis der Zusammensetzung vieler DOM-Elemente objektorientierter Sprachen ist (DOM ist das Dokumentenobjektmodell, bei dem es sich um ein hardware- und softwareunabhängiges Modell zur Darstellung von HTML-Seiten und Verwaltung von Objekten in HTML handelt). Jedes DOM-Element kann dynamisch durch JavaScript-Code aufgebaut sein (JavaScript ist ein Warenzeichen oder ein eingetragenes Warenzeichen von SUN Microsystems, Inc. oder verbundener Unternehmen in den USA und anderen Ländern), der mit einem nachgestellten System interagiert und AJAX-Technologie (Asynchronous JavaScript and XML Technology) umsetzt, um Web-Anwendungen auf der Client-Seite zu erstellen, und der sogar CSS-Stilvorlagen anwenden kann, um das Ändern des Erscheinungsbildes von der Client-Seite aus zu ermöglichen.
-
Der Code zum Erstellen der DOM-Elemente ist zudem an vielen Punkten verstreut und kann ebenso durch (mit AJAX-Rahmenstrukturen erstellte) Widgets erzeugt werden, die separat geschrieben sind und eine einzelne Funktionalität umsetzen.
-
Das Hauptproblem besteht nicht allein darin, ein System für eine Einheiten-Testfolge zum Testen der einzelnen Funktionalitäten, den einzelnen Widget-Klassen, umzusetzen, sondern ebenso die wirkliche Wechselwirkung zwischen durch die Widgets erzeugten DOM-Elementen und den anderen Beteiligten zu testen, welche die DOM-Elemente erzeugen.
-
Werkzeuge zum Testen von Web-Anwendungen nach dem Stand der Technik beruhen nur auf der „äußeren” Erscheinung einer Web-Seite oder Anwendung oder gehen, falls sie DOM-Elemente berücksichtigen, sogar vollständig am Innenleben der Anwendung vorbei. Umgekehrt hat die Anwendung keine Möglichkeit, einen Test dieses wichtigen Bereiches zu erzwingen, da sie nicht über die Mittel verfügt, auf das „äußere” Verhalten zuzugreifen und dieses selbst laufen zu lassen. Dabei hängt derartige Software stark von der beherbergenden Umgebung ab (diese Anwendungen laufen zum Beispiel im Browser). Das automatische Testen solcher Web-Anwendungen stellt heute eine Herausforderung dar.
-
Die US-Patentanmeldung US 2004/0025083 A1 beschreibt die allgemeine Idee, Testcode in ein Programm einzubetten, so dass das Programm seine Funktionalität testen kann. Trotz des breiten Umfangs dieser Erfindung, ist es mit diesem Verfahren jedoch nicht möglich, das Problem zu lösen, das Innenleben der Anwendungen in Verbindung mit dem Browser und dem ihn beherbergenden Betriebssystem vollständig zu testen. Einige Codebereiche der Anwendungen, die von Unterschieden in der Umgebung abhängen, können nicht getestet werden; eventuell ebenfalls nicht getestet werden darüber hinaus einige Codebereiche der Anwendungen, die nicht nur von solchen Unterschieden, sondern auch von den unterschiedlichen Code-Pfaden abhängen, zu deren Ausführung solche Unterschiede führen können. Zum Beispiel muss eine Web-Anwendung auf jedem der unterstützten Browser, wie beispielsweise dem Internet Explorer (Internet Explorer ist ein Warenzeichen der Microsoft Corporation in den USA, anderen Ländern oder beides), Firefox (Firefox ist ein eingetragenes Warenzeichen der Mozilla Foundation), Opera (Opera ist ein Warenzeichen oder ein eingetragenes Warenzeichen von Opera Software ASA) usw. separat getestet werden. Für Testzwecke ist es jedoch nicht zuverlässig, einen Testcode zu verwenden, der die Unterschiede ignoriert, die jeder Browser mit sich bringen kann, und der nur direkte Aufrufe der Software-Funktionen berücksichtigt.
-
Es besteht daher ein Bedarf nach einem Verfahren, das Web-Oberflächen-Code mit Code verwendet, der zum Testen des Innenlebens der Anwendung in Verbindung mit dem Browser und dem ihn beherbergenden Betriebssystem eine Benutzereingabe in eine Seite der Web-Oberfläche simuliert.
-
Zusammenfassung der Erfindung
-
Es ist daher eine Aufgabe der vorliegenden Erfindung, ein automatisches Testverfahren bereitzustellen, das eine Benutzereingabe in eine Seite der Web-Oberfläche simuliert und die internen Web-Oberflächen-Datenstrukturen der Web-Anwendung in der Umgebung des Browsers und des ihn beherbergenden Betriebssystems simuliert.
-
Die Aufgabe wird entsprechend Anspruch 1 durch ein Verfahren zum automatischen Testen einer innerhalb eines Web-Browsers eines Testcomputers laufenden Web-Anwendung erreicht, wobei die Web-Anwendung mit Testcode ausgestattet ist (400) und das Verfahren Folgendes umfasst:
- – Senden (410) einer Meldung vom in der Web-Anwendung ausgeführten Testcode durch eine in der Web-Anwendung festgelegte API ((Application Programming Interface, Anwendungsprogrammierschnittstelle) an einen HTTP-Server, wobei vom HTTP-Server das Simulieren einer Benutzereingabe erfragt wird und die Benutzereingabe mit dem in der Web-Anwendung laufenden Testcode in Verbindung steht;
- – Simulieren mindestens eines der Benutzereingabe entsprechenden Systemereignisses durch den HTTP-Server, der die Meldung empfängt (420), und deren Bereitstellen für den Web-Browser;
- – Bearbeiten des mindestens einen simulierten Systemereignisses durch den Web-Browser (430), wobei das mindestens eine Systemereignis selbst die Ausführung von Code in der Web-Anwendung auslöst;
- – durch den Testcode in der Web-Anwendung (440) Prüfen der Gültigkeit des Ergebnisses der Auslösung von Code in der Web-Anwendung durch das mindestens eine Systemereignis, indem die interne Datenstruktur der Web-Anwendung einschließlich JavaScript- und DOM-Elementen geprüft wird. Die interne Datenstruktur einer Web-Anwendung umfasst die HTML-Elemente, die von Web-Seiten und internen Zählern oder anderen möglichen Variablen und Objekten sichtbar sind.
-
Das Verfahren ermöglicht es zudem, Datenstrukturen der Anwendung durch Prüfung der Datenstruktur nach einer simulierten Benutzereingabe zu testen. Das Verfahren ermöglicht es zudem, die interne Datenstruktur der Anwendung zu testen, indem der Objektstatus nach einer erfolgten simulierten Benutzereingabe mit einem Vorlageobjektstatus verglichen wird, der gespeichert wurde.
-
Bei den Objekten kann es sich um HTML-, DOM- oder JavaScript-Objekte handeln. Ein automatisches Testsystem umfasst den HTTP-Server und den Code zur Erzeugung simulierter Systemereignisse entsprechend den getesteten Systemeingaben.
-
Um eine Web-Anwendung vollständig zu testen, umfasst das Verfahren der Erfindung nicht nur das Schreiben von Testcode und dessen Einbetten in die Anwendung. Vielmehr gewährt es Web-Anwendungen zudem Zugriff auf die „äußere” Umgebung einschließlich der Fähigkeit, die wirkliche Interaktion des Benutzers mit einer Web-Oberfläche zu reproduzieren. Mit diesem Verfahren können externe Eingaben so simuliert werden, dass es möglich ist, sie so zu empfangen, als ob sie von einem menschliche Benutzer oder irgendeiner externen Ereignisquelle kommen. Auf diese Weise ist die beherbergende Umgebung in der Lage, auch das Ereignis zu bearbeiten und seine eigene Datenstruktur zu aktualisieren, die ebenfalls einen direkten Einfluss auf das Verhalten der Anwendung besitzen. Ohne Vorhandensein dieses Systems ist kein Test in der Lage, die gesamte Funktionalität der Software abzudecken.
-
Die Web-Anwendung hat die Fähigkeit, mit sich selbst von „außen” durch einen externen Dienst wechselzuwirken. Der Dienst steuert den Browser und die externen Systeme (Festplatte usw.) und stellt der Web-Anwendung durch eine HTTP-Verbindung mit speziell codierten URLs Dienste bereit. Im Gegenzug verwendet die Web-Anwendung die bereitgestellten Dienste, um ihren internen Zustand von „außen” zu verändern und zu steuern, was mit aktuellen Systemen zur Testautomatisierung normalerweise nicht möglich ist.
-
Das folgende Verfahren und das folgende System überwinden die Begrenzungen der aktuellen Testverfahrensweisen, indem die menschliche Benutzereingabe reproduziert und simuliert und die Simulation zur Prüfung seiner internen Datenstrukturen und Algorithmen verwendet wird. Das Verfahren ruft die durch eine Benutzereingabe vom JavaScript-Code innerhalb der Web-Seiten erzeugten Systemereignisse selbst auf und erzeugt Veränderungen an der Web-Oberfläche (und damit an den Objektvorlageelementen wie beispielsweise den DOM-Elementen). Sobald die DOM-Elemente die Veränderungen widerspiegeln (durch die Abfragen der Benutzerereignisse) kann der JavaScript-Code den Status der internen Datenstrukturen prüfen und mit den erwarteten Werten vergleichen.
-
Das Verfahren der Erfindung bietet die folgenden Vorteile:
- – es kann alle DOM-Elemente testen und das Kundenszenario reproduzieren, indem es alle DOM-Elemente in den Web-Seiten der Anwendung testet. Die Lösung ermöglicht das Abdecken der interessierenden Testfälle für die oben genannten erweiterten Beispielbereiche, die von anderen Produktarten nicht abgedeckt werden können.
- – eine Web-Seite kann innerhalb und außerhalb der Seite selbst getestet werden.
- – die Art und Weise, wie die Überprüfungspunkte auf der Grundlage der DOM-Prüfungen und/oder durch Vergleichen von JSON-Objekten (JavaScript Object Notation – JavaScript Objektschreibweise – ist ein einfaches Format zur Darstellung von Objekten durch Zeichenketten) geprüft werden.
- – die Lösung ist nicht nur auf die DOJO-Rahmenstruktur anwendbar, sondern kann bei allen Verfahren eingesetzt werden, die zur Erzeugung der DOM-Elemente der Web-Seiten verwendet werden.
- – das Verfahren der Erfindung kann ausgeführt werden, wenn sich die für die Testfolge und die Anwendung verwendete Sprache von JavaScript unterscheiden. Die Sprache muss nur vom Browser verstanden werden.
-
Im Hinblick auf automatische Testprodukte und Vorgehensweisen nach dem Stand der Technik insbesondere für Web-Anwendungen bietet der aktuelle Stand der Technik viele Funktionen. Letztendlich wird das Testergebnis jedoch durch Vergleichen der „Ausgabe” der Anwendung mit einer Vorlage erreicht, deren Korrektheit bekannt ist. Bei einer Web-Anwendung ist die Ausgabe im Wesentlichen die HTML-Seite, die sie erzeugt oder verändert, oder deren entsprechende DOM-Darstellung. Mit dem Verfahren der Erfindung kann die Web-Anwendung auf die „äußere” Umgebung zugreifen und wirkliches Verhalten simulieren (einschließlich Eingaben durch den Menschen), was durch einfaches Ausstatten mit Code nicht möglich wäre. Die Fähigkeit, interne Strukturen zu prüfen, ist nicht mit Werkzeugen möglich, die nur das „Erscheinungsbild” des Programms prüfen können.
-
Kurze Beschreibung der Zeichnungen
-
1 zeigt die übliche Umgebung einer Web-Anwendung, bei der die Lösung der Erfindung ausgeführt werden kann;
-
2 zeigt die Umsetzung des Verfahrens der bevorzugten Ausführungsform in der üblichen Umgebung einer Web-Anwendung;
-
3 ist eine Darstellung einer Umgebung einer Web-Anwendung mit einem simulierten Ereignis gemäß der bevorzugten Ausführungsform;
-
4 ist der allgemeine Ablaufplan des Verfahrens der Erfindung gemäß der bevorzugten Ausführungsform.
-
Detaillierte Beschreibung der bevorzugten Ausführungsform
-
1 zeigt die übliche Umgebung einer Web-Anwendung, bei der die Lösung der Erfindung ausgeführt werden kann. Die übliche Umgebung einer Web-Anwendung umfasst eine im Browser (110) des Benutzer-Arbeitsplatzrechners (105) laufende Web-Client-Anwendung (115). Der Browser verwendet das Dateisystem (120) des Betriebssystems des Arbeitsplatzrechners des Benutzers. Die Web-Client-Anwendung wurde über das Netzwerk von einem Web-Anwendungs-Server (100) heruntergeladen, falls der Web-Anwendungs-Server entfernt angeordnet ist. Die Web-Anwendung kann in JavaScript geschrieben sein. Der Benutzer bedient die Anwendung über die durch den Browser erzeugten Web-Seiten. Die Benutzereingaben können in den Feldern der Web-Seite eingegebene Daten sein, die Systemereignisse erzeugen (beispielsweise über Tastatur und Maus).
-
2 zeigt die Umsetzung des Verfahrens der bevorzugten Ausführungsform in der üblichen Umgebung einer Web-Anwendung in einer Testfolge, die in einer für den Browser verständlichen Sprache geschrieben wurde, beispielsweise JavaScript als Web-Anwendung (115), und die auf einem Test-Hostrechner (240) läuft. Ein Web-Test-Automatisierungssystem (200) bietet für die auf dem Test-Hostrechner laufende Web-Anwendung (115) einen Testdienst. Der Testdienst beinhaltet drei Teilsysteme: einen HTTP-Server (210), der Befehle empfängt, den Systemereignis-Erzeuger (215), der festgelegte Systemereignisse erzeugt, und den entfernt angeordneten Ereignis-Sender (225), der die Ereignisse an den Host-Rechner sendet, auf dem im Falle eines entfernt angeordneten Testcomputers die Testfolge läuft. Diese Teilsysteme können als Software-Programme ausgeführt sein. Eine Ablage (220) wird durch die Teilsysteme des Testdienstes verwendet, um serialisierte Objekte zu laden/speichern, die den Status der Anwendung oder andere Daten darstellen (JSON kann ein Beispiel für in der Ablage gespeicherte linearisierte Objektcodierung sein).
-
In der auf dem Test-Hostrechner laufenden Web-Anwendung ermöglichen die JavaScript-APIs die Selbststeuerung des JavaScript-Testcodes. Die Selbststeuerungsbefehle für die JavaScript-API (235) ermöglichen den Datenaustausch zwischen dem JavaScript-Code vom Browser (der Web-Anwendung) und dem Testdienst. Ein Browser-Starter (230) ist optional und dient zum Starten des Browsers auf der URL des Test-Hostrechners. Bei Verwendung empfängt er das Ereignis vom entfernt angeordneten Ereignis-Sender (225), der es selbst von Systemereignis-Erzeuger (215) empfangen hat, und überträgt es an den Browser. Wenn kein Browser-Starter vorhanden ist, kann der Browser die simulierten Systemereignisse direkt empfangen, da der Browser gestartet wird, bevor der Testcode in der Web-Anwendung ausgeführt wird. Der Browser (110) empfängt und bearbeitet dasselbe Ereignis auf dem Test-Hostrechner. Innerhalb der Web-Anwendung beinhaltet der Testfolgen-Code (Web-Seiten, die HTML-/JavaScript-/Dojo-Code enthalten) den Code, um die Objekte zu testen, und verwendet die Selbststeuerungsbefehle für die JavaScript-API (235), um die Überprüfungspunkte zu prüfen und Aktionen in Richtung des HTTP-Servers (210) auszulösen, der den Testdienst bereitstellt.
-
Es wird darauf hingewiesen, dass sich das gesamte Testsystem, das die Komponenten des Testautomatisierungssystems umfasst, und der Testserver auf einem einzigen Computer befinden können. In diesem Fall, in dem sich das Testautomatisierungssystem und der Testserver auf einem einzigen Computer befinden, ist es nicht erforderlich, dass sich der entfernt angeordnete Ereignis-Sender (225) und die Ablage in räumlicher Nähe zur Web-Anwendung befinden.
-
Die JavaScript-API stellt eine Verbindung mit dem HTTP-Server her, um der Web-Anwendung das Senden von Ereignisbefehlen zu ermöglichen. Der Dienst erhält die Befehle und erzeugt über den Systemereignis-Erzeuger Tastatur- oder Mausereignisse, die der Browser (der immer als oberstes Fenster läuft) auffängt, so dass es scheint, als ob die Ereignisse und die Änderungen der Web-Seiten durch den Benutzer selbst erzeugt worden wären. An diesem Punkt wird der Testautomatisierungscode innerhalb der Web-Anwendung weiter ausgeführt.
-
Beispiel für Überprüfungspunkte auf der Grundlage der Web-Seiten-Objektprüfung wie beispielsweise DOM-Prüfungen: Es wird nun davon ausgegangen, dass die Web-Oberfläche eine Schaltfläche bereitstellt. Wenn der Benutzer auf die Schaltfläche klickt, wird ein neues Feld angezeigt. In diesem Beispiel sollte der JavaScript-Code der Testautomatisierung folgendermaßen aussehen: Das JavaScript erfragt einen Mausklick auf das oben genannte Schaltflächenelement. Dann empfängt der Dienst den Befehl durch die JavaScript-API und erzeugt die zugehörigen Systemereignisse. Sobald das Ereignis empfangen wird, wird eine neue Aufnahmestruktur (<DIV>) im DOM erzeugt, um das neue Feld aufzunehmen (ein Unter-DOM). Der JavaScript-Code kann dann prüfen, ob das DOM-Element wie erwartet eingefügt wurde.
-
Beispielhafte Überprüfungspunkte auf der Grundlage von Objektstatusprüfungen:
Eine weitere Möglichkeit zur Umsetzung der Überprüfungspunkte besteht darin, die (beispielsweise als JSON-Zeichenketten linearisierten) Objekte zu speichern, bevor simulierte Systemereignisse angefordert werden. Sobald die simulierten Systemereignisse dann empfangen werden und die Änderungen auf das DOM übertragen wurden, können die zuvor gespeicherten JSON-Objekte geladen und mit den veränderten Objekten verglichen werden. Es wird nun angenommen, dass die Web-Anwendung ein Widget in eine Web-Seite einfügt, das die Hintergrundfarbe wechselt, wenn sich die Maus darüber befindet. Zudem wird davon ausgegangen, dass sich das Widget-Objekt als serialisierter Original-Wert in der Original-Ablage befindet (mit der Hintergrundfarbe, die mit der Farbe erwartet wird, wenn sich die Maus über dem Widget befindet). In diesem Fall besteht der JavaScript-Test aus dem Erfragen eines JavaScript-Befehlsereignisses „Maus über” dem Widget. Wenn dann das Ereignis beim Browser ankommt und die Maus automatisch über das Widget bewegt wird, erfragt der JavaScript-Test beim Dienst den Vergleich des momentanen Widget-Status mit dem in der Ablage vorhandenen, Jede dieser Testfolgen erzeugt die folgenden Aktionen: Tätigen von HTTP-Anfragen auf dynamischen Web-Seiten, Speichern von JSON-Objekten als momentanen Status, Erzeugen von Ereignisbefehlen, Auffangen des Ereignisses und der Veränderungen der Web-Seite (durch den Browser), Prüfen von DOM-Änderungen durch Vergleichen von Ergebnissen mit Original-Werten (Vorlagen), Vergleichen von JSON-Objekten mit Original-Werten. Jede Testfolge erzeugt eine der üblichen Wechselwirkungen zwischen dem Browser und dem System.
-
Die folgenden beispielhaften Tests können ausgeführt werden:
- • „Vorausschauen” (Erzeugen der Ereignisse, um die ersten Zeichen einer zu suchenden Zeichenkette einzugeben).
- • „Feldgültigkeitsprüfung” (Erzeugen aller Tastaturzeichen).
- • „Seiten speichern” (Erzeugen des Ereignisses, um auf das Browser-Menü zuzugreifen und die Seite zu speichern).
- • „Datei hochladen” (Erzeugen der Ereignisse, um eine Datei in einem Popup-Menü des Browsers einzugeben und die Datei zu öffnen).
- • „Lokalisierung” (Erzeugen der Ereignisse, um auf das Browser-Menü zuzugreifen und die Browser-Sprache zu ändern).
- • „Browserabhängig”, Erzeugen derselben Tastatur- und Mausereignisse, um das unterschiedliche Verhalten der Ereignisse auf den unterschiedlichen Browsern zu testen.
- • „Zugangstestfälle”, Verwenden der Sequenzen von (Tabulator, Eingabe)-Tastaturereignissen.
-
Selbststeuerungsbefehle für die JavaScript-API werden asynchron an den HTTP-Server auf einem Anschluss gesendet wie zum Beispiel:
http://Servicehostname:port/?receiverhost=hostname&command=<name>&arg1=valuel&......&argN=valueN
-
Einige der grundlegenden API-Befehle können folgendermaßen aussehen:
click(x, y)
doubleclick(x, y)
key(k)'
Sondertasten sind (Tabulator, Eingabe, nach links, nach rechts, nach oben, nach unten) pause (Verzögerung)
fileload (Dateiname)
filesave (Dateiname)
-
Einige API-Befehle für die Überprüfungspunkte auf der Grundlage des JSON-Vergleichs können folgendermaßen aussehen:
saveAsJSON (Objekt, Name), speichert das Objekt als JSON-Zeichenkette. object loadJSON (Name), wandelt die JSON-Zeichenkette in ein Objekt um.
checkJSON (Objekt, Objekt), vergleicht zwei JSON-Objekte.
-
3 ist eine Darstellung der Web-2.0-Anwendungsumgebung mit einem simulierten Ereignis gemäß der vorliegenden Ausführungsform. Die Darstellung der Ereignisbearbeitung dient dem Verständnis der Unterschiede zum Testverfahren nach dem Stand der Technik, das lediglich das Einbetten von Code in ein Programm vorschlägt. Die Web-2.0-Anwendung ist in einer Aufnahme (z. B. Web-Browser) vorhanden, die kritische Komponenten (z. B. HTML-Rendering, DOM-Darstellung von Dokumenten, JavaScript-Sprachinterpretierer und -Funktionsbibliothek, HTTP- und HTTPS-Netzwerkdatenaustausch usw.) sowie eine Einrichtung zum Empfang von Ereignissen vom System (z. B. als Reaktion auf eine Benutzeraktion oder -eingabe) unterstützt. Die Umsetzung und das Verhalten einer solchen Aufnahme und aller zugehörigen Komponenten ist für Web-2.0-Anwendungen entscheidend: eine Web-2.0-Anwendung kann nicht vollständig getestet werden, wenn diese komplexe Umgebung während des Tests nicht berücksichtigt wird.
-
Es wird in 3 mit Schritt Nummer 2 begonnen (Erfragen der Ereigniserzeugung beim System). Dies ist im Wesentlichen auch für Benutzeraktionen derselbe Startpunkt. Wie in der Figur gezeigt, legt das Ereignis eine gewisse Wegstrecke zurück und wird durch mehrere Komponenten und Code-Ebenen bearbeitet, bevor es an die Web-2.0-Anwendung gesendet wird. Dabei „hinterlässt es üblicherweise eine Spur” in solchen Code-Ebenen und Komponenten, indem z. B. deren Datenstrukturen verändert werden usw. Wenn das Ereignis schließlich an die Web-Anwendung gesendet und durch die Web-Anwendung bearbeitet wird, kann die Anwendung so auf das Ereignis reagieren, als ob es „in Wirklichkeit” in einer realen Situation ausgelöst worden wäre, das heißt die Web-Anwendung stellt fest, dass ihre Umgebung das Ereignis auch bearbeitet hat und die Möglichkeit hatte, darauf zu reagieren. Dies ist nicht möglich, wenn die Web-Anwendung den Empfang des Ereignisses ganz alleine simuliert und diese gesamte lange Bearbeitung ignoriert.
-
Falls die Web-Anwendung ihre Reaktion nur auf eine Art von „abstraktem” Ereignis testen kann, eines das unbekannt ist und die Umgebung und die Aufnahme Web-Anwendung nicht beeinflusst, ist eine vollständige Abdeckung des Codes nicht möglich. Im Gegenteil (und dies trifft insbesondere auf Web-Anwendungen zu) unterscheidet sich jede Aufnahme (z. B. Web-Browser) von der anderen und oftmals auch von anderen Versionen ihrer selbst. Aus diesem Grund ist es erforderlich, die Web-Anwendung in jeder unterstützten Umgebung zu testen, und wie bereits erwähnt ist dies mit Sicherheit nicht möglich, wenn die Umgebung völlig in das Testszenario integriert ist.
-
3 zeigt ein Beispiel, wie ein Ereignis erzeugt und an die Software-Anwendung gesendet werden kann. Während das Ereignis bearbeitet wird, gibt es Schritte, die die beherbergende Umgebung beeinflussen (im Bild die Schritte Nummer 3. „Ereignisbearbeitung” zur Simulation des Ereignisses und 5. „Ereignisbearbeitung” zur Reproduktion des Ereignisses durch den Browser, die durch eingebetteten Code allein nicht reproduziert werden können.
-
4 ist der allgemeine Ablaufplan des Verfahrens der Erfindung gemäß der bevorzugten Ausführungsform. Das Verfahren wird auf einem oder zwei Hostrechnern, jedoch auf zwei Servern, ausgeführt. Auf einem Server läuft die Web-Anwendung in ihrer Umgebung (Web-Browser), und ein Testserver, der über eine Schnittstelle mit der Web-Anwendung verbunden ist, betreibt den Test. Das Verfahren zum automatischen Testen der Web-Anwendung umfasst einen ersten Schritt (400) des Ausführens von Testcode innerhalb des Web-Anwendungs-Codes zum Testen der Web-Anwendung. Ein zweiter Schritt (410) wird ausgeführt, indem von einem Testcode und über eine API eine Meldung einschließlich eines Befehls an den Test-Server gesendet wird. In einem dritten Schritt (420) empfängt der Testserver die Meldung und interpretiert den Befehl, um eine Benutzereingabe in eine Seite der Web-Anwendung zu simulieren oder ein Systemereignis zu erzeugen, das auch durch die Umgebung der Web-Anwendung und durch die Web-Anwendung verstanden werden kann. Die Benutzereingabe oder das Systemereignis steht mit dem in der Web-Anwendung laufenden Testcode in Verbindung. Der Test-Server sendet die simulierte Benutzereingabe oder das Systemereignis an den Web-Browser, der die Web-Anwendung beinhaltet. Der Web-Browser (430) bearbeitet die Benutzereingabe oder das Systemereignis, das die übliche Ausführung der Web-Anwendung auslöst, die getestet wird. Der Testcode in der Web-Anwendung prüft (440) die Gültigkeit des Ergebnisses der Ausführung des Web-Anwendungs-Codes, indem die internen Datenstrukturen der Web-Anwendung entweder durch ein Programm oder durch Vergleichen ihrer Darstellung mit einer bekannten Vorlage geprüft werden.
-
Einige spezielle Schritte des Verfahrens betreffen das Beispiel von auf der Prüfung von HTML-Objekten beruhenden Überprüfungspunkten. Wenn beispielsweise das Klicken des Benutzers mit der Maus in einem Web-Feld, das Teil einer Web-Seite ist, die Anzeige eines neuen Web-Feldes durch die Anwendung hervorruft, besteht der Schritt 410 in der Anfrage nach einer Mausklick-Simulation, und Schritt 430 schließt weiterhin ein, dass die Web-Anwendung bei ihrer normalen Codeausführung (die Ausführung von Testcode nicht eingeschlossen) eine neue, der Erzeugung von neuen Instanzen eines HTML-Objekts (DOM-Objekt) entsprechende Aufnahmestruktur erzeugt, die der neuen anzuzeigenden Web-Seite entspricht. Schritt 440 schließt Testcode ein, der prüft, ob das dieser Web-Seite entsprechende Objekt in der Web-Anwendung korrekt realisiert wurde.
-
Weitere spezielle Schritte des Verfahrens betreffen das Beispiel von auf der Prüfung des Objektstatus beruhenden Überprüfungspunkten, zum Beispiel Prüfen, ob die Verwendung des Widget durch den Benutzer die Farbe des Hintergrunds einer HTML-Seite geändert hat. Eine Anfrage vom Testcode der Web-Anwendung (410) könnte in der Anfrage nach einem Speichern des ursprünglichen Status des Widget-Objekts (zum Beispiel das Speichern eines Widget als JSON-Zeichenkette in der Ablage) und der Anfrage über einen JavaScript-Befehl nach der Simulation eines Systemereignisses (wie das Bewegen der Maus über ein Widget) in der Web-Seite bestehen, die dem Benutzer angezeigt wird und dieses Widget enthält. Wenn dann das simulierte Systemereignis empfangen wird, führt die Web-Anwendung bei Durchführung der simulierten Mausbewegung durch den Browser die entsprechende Funktion aus, und der Testcode (440), der die Änderungen der Web-Seite auffängt, sendet eine neue Anfrage an den Testdienst (410), um das gespeicherte Objekt (JSON-Zeichenkette) von der Ablage abzurufen, empfängt das gespeicherte Objekt durch die API der Web-Anwendung und liest den momentanen Status des Widget und prüft DOM-Änderungen durch Vergleichen von JSON-Objekten mit in der Ablage gespeicherten Objekten. Jede Testfolge erzeugt eine der üblichen Wechselwirkungen zwischen dem Browser und dem System.
-
Zusammenfassend gesagt, das Verfahren zum automatischen Testen der Web-Anwendung ist vollständig, wenn es sowohl die internen Strukturen (440) der Web-Anwendung als auch die äußere Umgebung (430) der Web-Anwendung testet.
-
Ein Beispiel, das das Testen der internen Struktur veranschaulicht, ist die Annahme, dass die Web-Anwendung einen internen Zähler unterhält, der die Anzahl der Widgets in fehlerhaftem Zustand verfolgt, so dass bei einer Anzahl größer als Null das gesamte Feld ungültig ist und nicht mehr bearbeitet werden kann. Ein Test, der eine korrekte Reaktion der Web-Anwendung auf eine unzulässige Eingabe vom Benutzer prüft, könnte drei Tests beinhalten:
- 1) ob das entsprechende Widget die Hintergrundfarbe ändert, um den Fehler anzuzeigen
- 2) ob eine Meldung erscheint, um den Benutzer zu informieren
- 3) ob der interne Zähler um eine Einheit vorrückt.
-
Punkt 3) bezieht sich auf eine interne Datenstruktur der Anwendung. Der interne Zähler ist nur in der Web-Anwendung vorhanden; er kann nicht durch Testen der externen Eingaben getestet werden, da kein HTML-Element und keine externe Darstellung diesem Zähler entsprechen. Der Code kann sich selbst analysieren. Ein HTML-, DOM- oder JavaScript-Objekt besitzt eine Datenstruktur, die extern durch die Web-Oberfläche der Web-Anwendung sichtbar ist und die intern sichtbar ist, wenn sie Daten innerhalb der Web-Anwendung wie den oben genannten Zähler umfasst.
-
Ein Beispiel, das das Testen der äußeren Umgebung der Web-Anwendung veranschaulicht, ist die Annahme, dass etwas außerhalb der Web-Anwendung im Betriebssystem des Computers geschieht, der die Web-Anwendung beherbergt. Das Testverfahren kann testen, wie die Web-Anwendung als Antwort auf die Systemereignisse reagiert. Ein anderes Verhalten zeigt sich, wenn man den Browser oder das Betriebssystem im Hostrechner, auf dem die Web-Anwendung ausgeführt wird, verändert. Folglich kann die interne Struktur als Reaktion auf ein externes Ereignis wie beim eingebetteten Testcode der Verfahren nach dem Stand der Technik getestet werden. Die interne Struktur der Anwendung kann nur als Reaktion auf eine interne Eingabe getestet werden, die durch den Testcode selbst und nicht durch die Systemumgebung simuliert wird.
