-
TECHNISCHES GEBIET
-
Diese Offenlegung bezieht sich auf das Prüfen von Rahmenwerken, wie beispielsweise Skriptprüfungen. Unter Schutz gestellt werden und Gegenstand des Gebrauchsmusters sind dabei, entsprechend den Vorschriften des Gebrauchsmustergesetzes, lediglich Vorrichtungen wie in den beigefügten Schutzansprüchen definiert, jedoch keine Verfahren. Soweit nachfolgend in der Beschreibung gegebenenfalls auf Verfahren Bezug genommen wird, dienen diese Bezugnahmen lediglich der beispielhaften Erläuterung der in den beigefügten Schutzansprüchen unter Schutz gestellten Vorrichtung oder Vorrichtungen.
-
HINTERGRUND
-
Einheitenprüfung ist ein Verfahren, mit dem einzelne Einheiten von Quellcode (oder Skript) überprüft werden, um festzustellen, ob sie sich zur Nutzung eigenen. Beispielsweise kann eine Einheit der kleinste prüfbare Bestandteil einer Anwendung sein. In einem anderen Beispiel kann eine Einheit eine individuelle Funktion oder ein individuelles Verfahren sein. Einheitenprüfungen werden üblicherweise von Softwareentwickler geschrieben und ausgeführt, um sicherzustellen, dass Code sich wie geplant verhält, wenn er ausgeführt wird. Einheitenprüfungen werden üblicherweise unter Nutzung von Test-Rahmenwerken ausgeführt. Test-Rahmenwerke können zur Überprüfung einer Webseite verwendet werden, welche Skript enthält. Solche Überprüfungen der Webseite können Entwickler in die Lage versetzen, festzulegen, ob beispielsweise ein Script auf der Webseite ordnungsgemäß geladen und ausgeführt wird.
-
JsUnit ist ein Beispiel eines öffentlich zugänglichen Client-seitigen (oder Browser-seitigen) Einheiten-Testrahmenwerks für JavaScript. Eine Einheitenprüfung, welche das JsUnit-Rahmenwerk verwendet, bestimmt und ruft die erforderlichen Dateien (oder „Abhängigkeiten”) auf, welche Java Skript Code enthalten, damit eine Prüfung ordnungsgemäß ausgeführt wird. In einem ersten Ladeverfahren von Code-Abhängigkeiten in einen Browser kann das JsUnit-Prüfrahmenwerk einen Skripttag (zum Beispiel, ”<script>”) in dem Hypertext-Textmarkierungssprache(HTML)-Abschnitt einer Testseite setzen, um auf die Abhängigkeiten zu verweisen. In einem zweiten Verfahren kann das JsUnit-Prüftrahmenwerk dynamisch einen Script-Tag einfügen, welcher auf Abhängigkeiten verweist, wofür ein geladener Code verwendet wird. In einem dritten Verfahren, kann das JsUnit-Prüfrahmenwerk dynamisch Abhängigkeiten aus einem Server auslesen (beispielsweise, mittels einer iFrame- oder XMLHttp-Anfrage).
-
Jedes einzelne dieser Verfahren erfordert Server-, Netzwerk- und Browser-Ressourcen, was zu einer beträchtlich längeren Zeit für den Prüfaufbau führt. Wird die Anzahl der Prüfungen nicht trivial, nimmt die Prüfaufbauzeit bedingt durch den Aufwand an Ressourcen, im Browser und Server, welche erforderlich sind, um Testabhängigkeiten zu laden, zu. Darüber hinaus kann die tatsächliche Prüfungsausführungszeit bedingt durch verminderte Rechner- und Netzwerk-Ressourcen zu nehmen, was zu unangemessenen Prüfungsfehlschlägen führt. Das vorgenannte zweite und dritte Verfahren verbraucht jeweils ebenfalls Browserressourcen, was zu einer langsameren Prüfungsausführung führen kann und gelegentlich sogar zum Ausfall des Browsers.
-
Einige Prüfungs-Rahmenwerke können Abhängigkeiten auf einem Server zwischenspeichern oder sich auf den Zwischenspeicher des Browsers verlassen, um die Abhängigkeiten abzuspeichern. Zwischenspeicherung auf dem Server verringert lediglich die Zeit und die Ressourcen, die erforderlich sind, um die Abhängigkeiten an den Browser weiterzuleiten, erfordern dennoch eine Netzwerkverbindung und Browserressourcen. Weil darüber hinaus ein Browser-Zwischenspeicher inkonsistent ist, gewährleistet eine Zwischenspeicherung von Abhängigkeiten im Browser-Zwischenspeicher nicht, dass eine Skriptprüfung ordnungsgemäß und fehlerfrei abläuft.
-
KURZE ZUSAMMENFASSUNG
-
Ein Aspekt dieser Offenlegung bietet ein Verfahren für die in-line-Einfügung von Scriptabhängigkeiten, welches beinhaltet Extrahieren von Testressourcen, adressiert in einer Sprache, welche eine Testwebseite definiert, Platzieren von Markierungen, welche die Position jeder extrahierten Textressource innerhalb der Sprache, die die Testseite definiert, identifiziert, iteratives Aufrufen von externen Ressourcen, die mit einem Pfad jeder einzelnen Testresource assoziiert sind, analysieren jeder einzelner Testressource, um eine oder mehrere dynamisch hinzugefügte Abhängigkeiten zu identifizieren, und Ersetzen jeder Markierung durch externe Ressourcen und Abhängigkeiten, welche auf ihre entsprechende Markierung Bezug nehmen, um aktualisierte Sprache zu generieren, welche eine aktualisierte Test Webseite definiert. Das Verfahren beinhaltet darüber hinaus Hinzufügen jeder einzelnen identifizierten Abhängigkeit nach oder vor einer Top-Level Vorgängerressource, Durchführen des Analysierens und Hinzufügens, bis keine neue Abhängigkeiten mehr identifiziert werden, und Versehen jeder einzelnen neuen Abhängigkeit mit einer Referenz zu einer Vorgängermarkierung, welche mit der Top-Level Vorgängerressource assoziiert ist.
-
Auf diese Weise ermöglichen Implementierungen die in-line-Einfügung von Skriptabhängigkeiten, um die Belastung und Ausführungszeit einer Skriptprüfung zu verringern.
-
Die Details einer oder mehrerer Ausführungsformen der Offenlegung sind in den begleitenden Zeichnungen und der nachfolgenden Beschreibung dargelegt. Andere Merkmale, Objekte und Vorteile sind aus der Beschreibung und den Zeichnungen sowie aus den Ansprüchen ersichtlich.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
Die Zeichnung, in der ein Element zum ersten Mal erscheint, ist normalerweise durch die Ziffer ganz links in der entsprechenden Bezugsnummer angegeben.
-
1 zeigt ein beispielhaftes System für die in-line Einfügung von Scriptabhängigkeiten innerhalb von Testcode.
-
2A zeigt eine beispielhaften Gesamtoperation einer Prüfmaschine.
-
2B zeigt eine beispielhafte Operation, die von einer Prüfmaschine ausgeführt wird.
-
3 zeigt einen beispielhaften Computer, der für die Implementierung von Komponenten der erörterten Konfiguration geeignet ist.
-
Gleiche Bezugszeichen in den verschiedenen Zeichnungen zeigen gleiche Elemente an.
-
AUSFÜHRLICHE BESCHREIBUNG
-
Ausführungsformen beziehen sich auf in-line-eingefügte Scriptabhängigkeiten. Ausführungsformen können Testressourcen und ihre Abhängigkeiten innerhalb von HTML einschließen oder beinhalten, wodurch eine Testseite definiert wird. Da Testressourcen (beispielsweise Scripts) und ihre Abhängigkeiten (beispielsweise externe Dateien) vor der Prüfung der Testseite aufgerufen werden und direkt innerhalb HTML welches die Testseite definiert, eingebunden werden, müssen die Ausführungsformen keine Server- und Browser-Ressourcen aufwenden, um Testressourcen und deren Abhängigkeiten für eine Testlaufzeit in den Speicher zu laden. Auf diese Weise verringern Ausführungsformen die Ressourcenbelastung und Ausführungszeit einer Scriptprüfung.
-
Ausführungsformen extrahieren Testressourcen adressiert in einer Sprache, welche eine Testseite definiert, und platzieren Markierungen zur Identifizierung der Position jeder einzelnen extrahierten Testressource innerhalb von HTML, welches die Testseite definiert. Die Markierungen ermöglichen es den Ausführungsformen, die Positionen der extrahierten Textressourcen nach zu verfolgen, während Abhängigkeiten, die mit den Testressourcen assoziiert sind, abgerufen werden. Darüber hinaus ermöglichen die Markierungen es den Ausführungsformen ebenfalls, eine korrekte Rangfolge der aufgerufenen Vorgänger- und Nachfolge-Abhängigkeiten beizubehalten, sodass die aufgerufenen Vorgänger- und Nachfolge-Abhängigkeiten in der richtigen Rangfolge innerhalb des HTML, welches die Testseite definiert, ordnungsgemäß enthalten sind.
-
Ausführungsformen laden externe Ressourcen, die mit einem Pfad zu jeder einzelnen Testressource assoziiert sind, und analysieren jede einzelne Testressource, um dynamisch eingefügte Abhängigkeiten zu identifizieren, und dabei jede einzelne Markierung durch externe Ressourcen und Abhängigkeiten zu ersetzen, die ihre entsprechende Markierung referenzieren, um aktualisierte Sprache zu erstellen, welche eine aktualisierte (oder eingefügte) Testseite definiert Danach kann eine Skriptprüfung unter Nutzung der eingefügten Testseite ausgeführt werden.
-
Ausführungsformen beinhalten darüber hinaus das Hinzufügen jeder einzelnen identifizierten Abhängigkeit hinter oder vor einer Top-Level Vorgängerressource und das Durchführen der Analyse jeder Testressource und das Hinzufügen, bis keine neuen Abhängigkeiten mehr identifiziert werden. Die Ausführungsformen versehen jede einzelne neue Abhängigkeit mit einer Referenz zu einer Vorgängermarkierung, die mit der Top-Level Vorgängerressource, assoziiert ist.
-
Wenngleich das Folgende mit Verweis auf die illustrativen Ausführungsformen für bestimmte Anwendungen erörtert wird, so ist zu berücksichtigen, dass die Ausführungsformen nicht hierauf beschränkt sind. Fachleute mit Zugang zu den hier dargebotenen Erläuterungen werden zusätzliche Modifikationen und Anwendungen im Rahmen dieser Offenlegung und in weiteren Bereichen erkennen, in denen die Ausführungsformen von beträchtlichem nutzen sein würden.
-
System
-
Dieser Abschnitt beschreibt ein System für die in-line Einfügung von Skriptabhängigkeiten gemäß einer Ausführungsform dargestellt in 1. 1 ist ein Diagramm eines Systems 100 für in-line Einführungen von Scriptabhängigkeiten. Wenngleich die folgende Beschreibung sich auf Java Skript und HTML bezieht, so sind die Ausführungsformen nicht auf Java Skript und HTML beschränkt, sondern können auch auf beliebige andere Formen ausführbaren Inhalts, Code, oder Inhalt definierende (oder kennzeichnende) Sprache angewandt werden. Diese Ausführungsformen sind für jedes System anwendbar, das im Allgemeinen über die Struktur von 1 verfügt, oder das von der Operation, den Verfahren und Funktionen, wie hier beschrieben, Nutzen ziehen würde.
-
1 ist ein Strukturdiagramm der Prüfmaschine 110, gemäß einer Ausführungsform. Wie in 1 gezeigt, Prüfmaschine 110 beinhaltet den Testressourcenextraktor 120, Ressourcenlader und Analysator 130, Markierungsmodul 140 und in-lining Einfügemodul 150. 1 stellt ebenfalls Testseite 160 und in-line-eingefügte Testseite 162 dar. In einer Ausführungsform ist der Testressourcenextraktor 120 ausgelegt, auf die Extrahiehrung von Testressourcen 122 adressiert in Sprache (zum Beispiel, HTML), welches die Testseite 160 definiert. Markierungsmodul 140 ist ausgelegt auf die Platzierung von Markierungen 142 zur Identifizierung der Position jeder einzelnen Testressource 122 innerhalb der Sprache, welche die Testseite 160 definiert. Ressourcenlader und Analysator 130 ist ausgelegt auf das iterative Laden der externen Ressourcen 132 assoziiert mit dem Pfad jeder einzelnen Testressource 122 in den Speicher, um dynamisch hinzugefügte Abhängigkeiten 152 zu identifizieren. In einer Ausführungsform kann eine in-lining Einfügungsfunktion den Austausch einer Funktionsaufruf-Seite zusammen mit dem Körper (oder Code) der aufgerufenen Funktion beinhalten. Das in-lining Einfügemodul 150 ersetzt jede einzelne Markierung 142 durch Ressourcen 132 und Abhängigkeiten 152, die auf ihre respektive Markierung 142 referenzieren, um eine aktualisierte Sprache zu generieren, welche die eingefügte Testseite 162 definiert. In einer Ausführungsform führt danach die Prüfmaschine 110 eine Scriptprüfung durch, wofür es die eingefügte Testseite 162 verwendet. Da Testressourcen 122 (beispielsweise Scripts) und ihre Abhängigkeiten 152 (beispielsweise externe Dateien) vor der Prüfung der Testseite 160 aufgerufen werden und direkt innerhalb des HTML, welches die eingefügte Testseite 162 definiert, eingebunden werden, müssen die Ausfürhrungsformen keine Server- und Browser-Ressourcen aufwenden, um Testressourcen und deren Abhängigkeiten 152 für eine Testlaufzeit in den Speicher zu laden. Auf diese Weise können die Ausführungsformen die Last und Ausführungszeit einer Scriptprüfung verringern. Auf diese Weise verringern Ausführungsformen die Ressourcenbelastung und Ausführungszeit einer Scriptprüfung.
-
Der Funktionsablauf des Testtressourcenextraktors 120, Ressourcenlader und Anslysators 130, Markierungsmodul 140 und in-lining Einfügemodul 150 werden weiter unten dargelegt.
-
Prüfmaschine 110 kann eine beliebige prozessorgesteuerte (oder computergesteuerte) Vorrichtung sein, die sich aus einem oder mehreren Prozessoren zusammensetzt. Beispielsweise kann Prüfmaschine 110 eine Arbeitsstation, ein Mobilgerät, ein Computer, ein Computercluster, eine Set-Top-Box oder andere Vorrichtung mit mindestens einem Prozessor sein. Eine solche Vorrichtung kann beinhalten, ist jedoch nicht darauf beschränkt, ein Gerät mit einem Prozessor und Speicher für das Ausführen und Speichern von Anweisungen. Ein solches Gerät kann Software, Firmware und Hardware beinhalten. Die Software kann eine oder mehrere Anwendungen und ein Betriebssystem beinhalten. Die Hardware kann beinhalten, ist jedoch nicht darauf beschränkt, einen Prozessor, Speicher und Benutzerschnittstellenanzeige beinhalten. Optionale Eingabegeräte, wie beispielsweise eine Maus, Sensorbildschirm oder sonstige zukünftig entwickelte interaktive Verfahren, können benutzt werden.
-
Prüfmaschine 110 kann auch in einem Browser implementiert werden. Ein solcher Browser kann auf einer beliebigen prozessorgesteuerten (oder computergesteuerten) Vorrichtung implementiert werden, die sich aus einem oder mehreren Prozessoren zusammensetzt. In einer Ausführungsform kann die Prüfmaschine 110 auch als ein Java ”servlet” implementiert werden, das auf einem Server (nicht dargestellt) realisiert wird, und das über ein Netzwerk mit der Prüfmaschine 110 kommuniziert. Prüfmaschine 110 kann auch als eine Stand-Alone Anwendung oder Modul implementiert werden.
-
In einer Ausführungsform, ist die Prüfmaschine 110 ausgelegt für das Lesen der Testseite 160 und die Generierung der eingefügten Testseite 162, auf der Script-Abhängigkeiten 152 von Prüfmaschine 110 eingefügt worden sind. In einer Ausführungsform kann die Testseite 160 eine HTML Datei oder andere Datei sein. In einer Ausführungsform beinhaltet die Testseite 160 eine oder mehrere Testressourcen 122. Testressourcen 122 können Testfunktionen sein, welche Scriptcode beinhalten (zum Beispiel, JavaScript), der ausgeführt werden kann, wenn die Testseite 160 von Prüfmaschine 110 gelesen wird. In einer Ausführungsform können die Testressourcen 122 auf Testseite 160 von der Prüfmaschine 110 durch die Verwendung von Tags (oder Identifikatoren) identifiziert werden, die neben den Testressourcen 122 angeordnet (oder von diesen eingekapselt) sind. In einem Beispiel, in dem die Testressourcen 122 Java Script sind, können solche Tags Skripttags 124 (zum Beispiel, ”<script>”) sein. Wie Fachleuten bekannt ist, wird ein Scripttag für die Definition und Identifikation eines clientseitigen Scripts, wie beispielsweise Java Script, verwendet. Dass Scripttag kann Scipterlärungen enthalten oder es kann auf eine externe Skript Datei mittels einem ”src” Attribut verweisen. Es ist zu beachten, dass die Ausführungsformen nicht auf Scripttags und Java Skript beschränkt sind, sondern dass sie mit anderen Formen von Testressourcenidentifikation oder Skripten verwendet werden können, die gegenwärtig bekannt sind oder zukünftig entwickelt werden.
-
In einer Ausführungsform ist der Testressourcenextraktor 120 ausgelegt auf die Extrahierung von Testressourcen 122, die in Sprache (zum Beispiel, HTML), welche die Testseite 160 definiert, beeinhaltet oder adressiert sind. Testressourcen 122 können Testfunktionen sein, welches Scriptcode beinhalten (zum Beispiel, JavaScript), der ausgeführt werden kann, wenn die Testseite 160 von Prüfmaschine 110 für eine Prüfung gelesen wird. In einer Ausführungsform können die Testressourcen 122 auf Testseite 160 durch die Verwendung von Tags (oder Identifikatoren) identifiziert werden, die neben den Testressourcen 122 angeordnet (oder von diesen eingekapselt) sind. Wie oben angemerkt, können solche Skripttags in HTML eingebettet sein, das die Testseite 160 definiert. In einer Ausführungsform zergliedert der Testressourcenextraktor 120 die Testseite 160, um Scripttags und dazufgehörige Scripts zu identifizieren und zu extrahieren
-
in einer Ausführungsform ist das Markierungsmodul 140 darauf ausgelegt, Markierungen 142 zu platzieren, welche die Stelle jeder einzelnen extrahierten Testressource 122 innerhalb HTML identifiziert, welches die Testseite 160 definiert Eine Markierung 142 kann eine beliebige Form der Identifikation oder Datenstruktur sein, welche von Markierungsmodul 140 verwendet wird, um die Stelle jeder einzelnen extrahierten Testressourcen 132 zu identifizieren undaufrechtzuerhalten.
-
In einer Ausführungsform ist ein Ressourcenlader und Analysator 130 ist ausgelegt auf das Laden von externen Ressourcen 132 (beispielsweise Dateien, Bilder, Scripts, usw.), assoziiert mit dem Pfad jeder einzelnen Testressource 122, adressiert auf Testseite 160, in den Speicher. In einer Ausführungsform kann ein Ressourcenlader und Analysator 130 über den Pfad jeder einzelnen Testressource 122 iterieren, um externe Abhängigkeiten 152, zu laden, die durch den Pfad der Testressource 122 referenziert sein können. In einem Beispielszenario erfordert eine Testressource 122 möglicherweise externe Ressourcen 132 (beispielsweise Dateien, Bilder, Scripts, usw.) damit die Testressource 122 ordnungsgemäß ausgeführt werden kann. Solche externe Ressourcen 132 können sich auf einem Server befinden, der unabhängig von Prüfmaschine 110 ist, oder können sich sogar auf einer Recheneiheit befinden, auf der die Prüfmaschine 110 betrieben wird. Durch iteratives Laden externer Ressourcen 132 (oder anderer Abhängigkeiten 152), welche von einer Testressource 122 benötigt werden, in den Speicher im Voraus, wird weniger Zeit benötigt um eine Prüfung auszuführen, weil ein solches Laden der externen Ressourcen 132 nicht in Echtzeit erfolgen muss, wenn die Prüfung durchgeführt wird.
-
Wenn in einer Ausführungsform der Ressourcenlader und Analysator 130 feststellt, dass ein Testressourcenpfad nicht auflösbar (oder zugängig) ist, behalten der Ressourcenlader und Analysator 130 und das Markierungsmodul 140 die Platzierung der Testressource 122 zusammen mit dem unauflösbaren Pfad bei, um die Prüfmaschine 110 die Lage zu versetzen, die Ressourcen, die mit dem Test Ressourcenpfad assoziiert sind, zusammen mit dem assoziierten Testressourcenpfad während der Laufzeit zu laden.
-
In einer Ausführungsform analysiert Ressourcenlader und Analysator 130 jede einzelne geladene Testressource 122, um dynamisch hinzugefügte Abhängigkeiten 152 zu identifizieren. Dynamisch hinzugefügte Abhängigkeiten 152 können Scripts oder sonstige Dateien sein, die von einer Test Ressource 122 Während der Laufzeit benötigt werden. In einer Ausführungsform kann der Ressourcenlader und Analysator 130 dynamisch hinzugefügte Abhängigkeiten 152 identifizieren, indem er Scripts bewertet, wofür eine Skriptlaufzeitmaschine (zum Beispiel Java Skriptlaufzeitmaschine) verwendet wird, und die Testressourcen 122 zergliedert werden, um Hinweise auf Abhängigkeiten zu identifizieren. Solche Hinweise auf Abhängigkeiten können beispielsweise Ressourcenanforderungen sein.
-
In einer Ausführungsform, fügt der Ressourcenlader und Analysator 130 jede neu identifizierte Abhängigkeit 152 entweder nach der Top-Level Vorgängerressource 122 (d. h., Vortäuschung eines Browser Runtime HTML Ladebefehls), oder vor der Top-Level Vorgängerressource 122 (d. h., Vortäuschung des dynamischen Resolution-Ladebefehls) ein. Das Markierungsmodul 140 versieht auch jede einzelne neue Abhängigkeit 152 mit einer Referenz zu einer Vorgängermarkierung 142, die mit der Top-Level Vorgängerressource 122 assoziiert ist.
-
In einer Ausführungsform führt Ressourcenlader und Analysator 130 so lange fort, jede neue Abhängigkeit 152 zu identifizieren und zu einer Top-Level Vorgängerresource hinzuzufügen, bis keine neuen Ressourcen 122 mehr identifiziert werden. Auf diese Weise wird durch iteratives Laden externer Ressourcen 132 (oder anderer Abhängigkeiten), welche von einer Testressource 122 benötigt werden, vor dem Prüfen, wird weniger Zeit benötigt um eine Prüfung auszuführen, weil ein solches Laden der externen Ressourcen 132 nicht in Echtzeit erfolgen muss, wenn die Prüfung ausgeführt wird.
-
Wie oben bereits erwähnt, ist das Markierungsmodul 140 darauf ausgelegt, Markierungen 142 zu platzieren, welche die Stelle jeder einzelnen extrahierten Testressource 132 innerhalb HTML identifiziert, welches die Testseite 160 definiert. Eine Markierung 142 kann eine beliebige Form der Identifikation oder Datenstruktur sein, welche von Markierungsmodul 140 verwendet wird, um die Stelle jeder einzelnen extrahierten Testressourcen 122 zu identifizieren und aufrechtzuerhalten. In einer Ausführungsform ersetzt das in-lining Modul 150 jede einzelne Markierung 142 durch extrahierte Ressourcen 132 und Abhängigkeiten 152, die auf ihre respektive Markierung 142 referenzieren, um eine eingefügte Testseite 162 zu generieren.
-
In einer Ausführungsform, werden ungelöste Markierungen 142 (oder Markierungen, die mit ungelösten Pfaden assoziiert sind) unverändert gelassen, sodass Prüfmaschine 110 Ressourcen 122 zugehörig zu solchen ungelösten Pfaden während der Laufzeit laden kann. Danach führt die Prüfmaschine 110 eine Scriptprüfung durch, wofür es die eingefügte Testseite 162 verwendet. Da Testressourcen 122 (beispielsweise Scripts) und ihre Abhängigkeiten 152 (beispielsweise externe Dateien) vor der Prüfung der Testseite 160 aufgerufen und direkt innerhalb des HTML, welches die Testseite 162 definiert, eingebunden werden, müssen Ausführungsformen keine Server- und Browser-Ressourcen aufwenden, um Testressourcen 122 und deren Abhängigkeiten 152 für eine Testlaufzeit in den Speicher zu laden. Auf diese Weise verringern Ausführungsformen die Ressourcenbelastung und Ausführungszeit einer Scriptprüfung.
-
2A ist ein Flussdiagramm zur Erläuterung des Verfahrens 200. Verfahren 200 ist eine Gesamtoperation der Prüfmaschine 110, gemäß einer Ausführungsform.
-
Verfahren 200 beginnt damit, dass Prüfmaschine 110 die Testseite 160 liest (Schritt 202). Beispielsweise kann eine solche Testseite 160 eine HTML Datei oder andere Datei sein. In einer Ausführungsform beinhaltet die Testseite 160 eine oder mehrere Testressourcen 122. Testressource 122 kann Scriptcode enthalten (zum Beispiel., JavaScript).
-
Testressourcenextractor 120 extrahiert Scripttags 124 assoziiert mit Testressourcen 122 auf der Testseite 160 (Schritt 204). Wie oben angemerkt, können solche Skripttags 124 in HTML eingebettet sein, das die Testseite 160 definiert. In einer Ausführungsform zergliedert der Testressourcenextraktor 120 die Testseite 160, um Scripttags 124 und dazugehörige Scripts 126 zu identifizieren und zu extrahieren.
-
Ressourcenlader und Analysator 130 lädt externe Ressourcen 132 verknüpft mit einem Pfad jeder Testressourcen 122 (Schritt 206). In einem Beispielszenario erfordert eine Testressource 122 möglicherweise externe Ressourcen 132 (beispielsweise Dateien), damit die Test Ressource 122 ordnungsgemäß durchgeführt werden kann Solche externe Ressourcen 132 können sich auf einem Server befinden, der unabhängig von Prüfmaschine 110 ist, oder können sich sogar auf einer Recheneiheit befinden, auf der die Prüfmaschine 110 betrieben wird. Solche externen Ressourcen 132 können iterativ vom Ressourcenlader und Analysator 130 geladen werden.
-
der Ressourcenlader und Analysator 130 überprüft ebenfalls, ob externe Testressourcenpfade vorliegen, die nicht aufgelöst werden können (Schritt 208). Wenn der Ressourcenlader und Analysator 130 feststellt, dass ein Testressourcenpfad nicht auflösbar ist (Schritt 208), behalten Ressourcenlader und Analysator 130 und Markierungsmodul 140 die Platzierung der Testressource 122 zusammen mit dem unauflösbaren Pfad bei (Schritt 210), und Verfahren 200 geht über zum Schritt 212.
-
Zurückkommend auf Schritt 208, wenn der Ressourcenlader und Analysator 130 feststellt, dass alle externen Testressourcepfade aufgelöst worden sind (Schritt 208), analysiert der Ressourcenlader und Analysator 130 jede einzelne geladene Testressource 122, um dynamisch hinzugefügte Abhängigkeiten 152 zu identifizieren (Schritt 212). Dynamisch hinzugefügte Abhängigkeiten 152 können Scripts 126 oder sonstige Dateien sein, die von einer Testressource 122 bei Laufzeit benötigt werden.
-
Ressourcenlader und Analysator 130 überprüft, ob neue Abhängigkeiten 152 in Schritt 212 identifiziert worden sind (Schritt 214). Wenn Ressourcenlader und Analysator 130 neue Abhängigkeiten 152 identifiziert (Schritt 214), geht das Verfahren 200 zu Schritt 206 über, in dem Ressourcenlader und Analysator 130 externe Ressourcen 132 assoziiert mit einem Pfad für jede Testressource 122 lädt. Wenn der Ressourcenlader und Analysator 130 keine neuen Abhängigkeiten identifiziert (Schritt 214), ersetzt in-lining Modul 150 jede einzelne Markierung 142 durch Ressourcen 122 und Abhängigkeiten 152, die auf ihre respektive Markierung 142 referenzieren, um eine eingefügte Testseite 162 zu generieren (Schritt 216).
-
2B ist ein Flussdiagramm zur Erläuterung von Schritt 214 des Verfahrens 200 in größerem Detail gemäß einer Ausführungsform. In einer Ausführungsform kann der Ressourcenlader und Analysator 130 dynamisch hinzugefügte Abhängigkeiten 152 identifizieren, indem er Scripts 126 bewertet, wofür eine Skriptlaufzeitmaschine 134 (zum Beispiel Java Skriptlaufzeitmaschine) verwendet wird, und wobei die Testressourcen 122 zergliedert werden, um Hinweise auf Abhängigkeiten zu identifizieren (Schritt 220). Solche Hinweise können beispielsweise Ressourcenanforderungen beinhalten.
-
Der Ressourcenlader und Analysator 130 fügt jede neu identifizierte Abhängigkeit 152 entweder hinter der Top-Level Vorgängerressource 122 (d. h. Vortäuschung eines Browser HTML Laufzeitladebefehls) oder vor der Top-Level Vorgängerressource 122 (d. h. Vortäuschung des dynamischen Auflösungsladebefehls (Schritt 222) ein. Das Markierungsmodul 140 versieht auch jede einzelne neue Abhängigkeit 152 mit einer Referenz zu einer Vorgängermarkierung 142, die mit der Top-Level Vorgängerressource 122 assoziiert ist (Schritt 224).
-
Auf diese Weise wird durch iteratives Laden externer Ressourcen 132 (oder anderer Abhängigkeiten), welche von einer Testressource 122 benötigt werden, vor der Prüfung der Testseite 160, weniger Zeit benötigt, um die Prüfung auszuführen, weil ein solches Laden der externen Ressourcen 132 nicht in Echtzeit erfolgen muss, wenn die Prüfung erfolgt.
-
Beispielhafte Computer-Ausführungsform
-
In einer Ausführungsform, werden das System und die Komponenten der hierin beschriebenen Ausführungsformen durch die Verwendung von einem oder mehreren Computern umgesetzt, wie beispielsweise Computer 302, dargestellt in 3. Beispielsweise kann Prüfmaschine 110 durch Verwendung Computer(n) 302 umgesetzt werden.
-
Computer 302 kann ein beliebiger im Handel erhältlicher Computer sein, der in der Lage ist, die hierin beschriebenen Funktionen durchzuführen.
-
Der Computer 302 beinhaltet eine oder mehrere Prozessoren (auch „central processing Units”, oder CPUs genannt), wie Prozessor 306. Prozessor 306 ist mit einer Kommunikationsinfrastruktur 304 verbunden
-
Computer 302 beinhaltet ebenfalls einen Haupt- oder Primärspeicher 308, wie beispielsweise einen Radom Access Memory (RAM-Speicher). Im Primärspeicher 308 ist die Steuerlogik 368A (Computer Software) mit zugehörigen Daten gespeichert.
-
Der Computer 302 beinhaltet ebenfalls ein oder mehrere Sekundärspeichergeräte 310. Sekundäre Speichergeräte 310 beinhalten beispielsweise ein Festplattenlaufwerk 312 und/oder ein Wechselspeichergerät oder Wechselspeicherlaufwerk 314, sowie andere Arten von Speichervorrichtungen, wie Speicherkarten und Memorysticks Ein Wechselspeicherlaufwerk 314 stellt ein Diskettenlaufwerk, ein Magnetbandlaufwerk, ein Kompaktplattenlaufwerk, eine optisches Speichervorrichtung, ein Sicherungsband, usw. dar.
-
Das Wechselspeicherlaufwerk 314 interagiert mit einem Wechselspeichereinheit 316. Eine Wechselspeichereinheit 316 beinhaltet ein für einen Computer benutzbares oder lesbares Speichermedium 364A, auf dem Computer Software 368B (Control Logik) und/oder Daten gespeichert sind. Das Wechselspeicherlaufwerk 316 beinhaltet eine Diskette (Floppy), Magnetband, eine Kompaktdiskette, DVD, optische Speicherdiskette, oder ein sonstiges Computerdatenspeichergerät. Das Wechselspeicherlaufwerk 314 liest von und/oder schreibt auf wohl bekannte Art und Weise auf Wechselspeichereinheit 316.
-
Der Computer 302 beinhaltet ebenfalls Eingabe/Ausgabe/Anzeigegeräte 366, wie Bildschirme, Tastaturen, Zeigegeräte, Bluetooth-Geräte usw.
-
Der Computer 302 beinhaltet darüber hinaus eine Kommunikations- oder Netzwerkschnittstelle 318. Die Netzwerkschnittstelle 318 ermöglicht es dem Computer 302 mit ferngesteuerten Geräten in Verbindung zu treten. Beispielsweise ermöglicht die Netzwerkschnittstelle 318 dem Computer 302, über Kommunikationsnetzwerke oder Kommunikationsmediem 364B (repräsentierend eine Form von Computer nutzbarem und lesbarem Medium), wie LANs, WANs, das Internet usw., zu kommunizieren. Netzwerkinterface 318 kann mit entfernten Standorten oder Netzwerken über Leitungsverbindungen oder drahtlose Verbindungen kommunizieren.
-
Die Steuerlogik 368C kann über das Kommunikationsmedium 364B zu und von Computer 302 übertragen werden.
-
Jede beliebige konkrete Vorrichtung oder hergestellter Gegenstand, der einen Computernutzbares oder -lesbares Medium beinhaltet, mit darauf gespeicherter Steuerlogik (Software), wird hierin als ein Computerprogrammprodukt oder Programmspeichergerät bezeichnet. Diese beinhaltet, aber nicht ausschließlich, Computer 302, Hauptspeicher 308, Sekundärspeichereinheiten 310 und Wechselspeichereinheit 316. Solche Computerprogrammprodukte mit darin gespeicherter Steuerlogik, die wenn sie von einer oder mehreren Datenverarbeitungsgeräten ausgeführt wird, veranlassen solche Datenbearbeitungsgeräte, so zu funktionieren, wie in den hier beschrieben Ausführungsformen dargestellt.
-
Ausführungsformen können mit Software, Hardware, und/oder anderen als den hier beschriebenen Betriebssystem-Implementierungen betrieben werden. Jede beliebige Software, Hardware und Betriebssystem-Implementation, die für die Durchführung der hier beschriebenen Funktionen geeignet sind, können verwendet werden. Ausführungsformen sind anwendbar sowohl für einen Klienten als auch für einen Server oder für eine Kombination von beiden.
-
Die Abschnitte der Zusammenfassung und der Übersicht können eine oder mehrere aber nicht alle beispielhaften Ausführungsformen, wie durch den (die) Erfinder vorgesehen, darlegen und sind daher nicht geeignet, um die vorliegende Erfindung und die beigefügten Ansprüche in irgendeiner Weise zu begrenzen.
-
Die vorliegenden Ausführungsformen wurden oben beschrieben unter Zuhilfenahme von funktionalen Bausteinen, welche die Implementierung der spezifizierten Funktionen und Verhältnisse zueinander veranschaulichen. Grenzen dieser funktionalen Bausteine wurden zum besseren Verständnis der Beschreibung hierin willkürlich definiert. Alternative Grenzen können definiert werden, solange deren spezifizierte Funktionen und Beziehungen angemessen durchgeführt werden.
-
Die vorstehende Beschreibung der spezifischen Ausführungsformen wird so in vollem Umfang ihre generelle Natur offenbaren, sodass wiederum andere durch Anwendung des Fachwissens und Fertigkeiten in ihrem Fachbereich auf einfache Weise spezifische Ausführungsformen für vielfältige Anwendungen modifizieren und/oder anpassen können ohne unnötiges Experimentieren, ohne vom allgemeinen Konzept abzuweichen. Daher sind solche Anpassungen und Modifikationen auf Basis der hierin präsentierten Lehre und Anleitung als innerhalb der Bedeutungen des Bereichs der Äquivalente der offenbarten Ausführungsformen zu betrachten. Es versteht sich dass die hierin verwendete Phraseologie oder Terminologie der Beschreibung dient und nicht der Einschränkung, sodass die Terminologie oder Phraseologie der vorliegenden Spezifikation vom Fachmann unter der Sichtweise von Lehre und Führung zu interpretieren ist.
-
Die Tiefe und der Wirkungsbereich der Ausführungsformen sollte nicht durch eine der obig beschriebenen beispielhaften Ausführungsformen eingeengt werden, sondern sollten nur in Übereinstimmung mit den folgenden Ansprüchen und ihren äquivalenten interpretiert werden.
