DE69625751T2

DE69625751T2 - Verfahren und System zur Ausführungssynchronisation von Ereignissen beim Testen von Software

Info

Publication number: DE69625751T2
Application number: DE69625751T
Authority: DE
Inventors: Douglas R. Stein; A. Van Boughner
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1995-07-07
Filing date: 1996-07-05
Publication date: 2003-10-02
Anticipated expiration: 2016-07-06
Also published as: JPH09223029A; EP0752653A2; EP0752653B1; DE69625751D1; US5896495A; EP0752653A3; KR970007638A; CN1146025A

Description

Gebiet der Erfindung

Die vorliegende Erfindung betrifft allgemein ein Computerverfahren und ein -system zum Synchronisieren der Ausführung von Ereignissen, und insbesondere zum Synchronisieren von Ereignissen beim Testen eines Softwareprodukts.

Hintergrund der Erfindung

Ein Aspekt auf dem Gebiet des Testens von Software ist auf das Testen grafischer Nutzerschnittstellenprogramme (GUI- Programme) fokussiert. Bei einem GUI-Programm handelt es sich um ein Programm, das Funktionalität bereit stellt, die ausgehend von einer Befehls- bzw. Steuerleitung nicht zugänglich ist, sondern lediglich durch die grafische Nutzerschnittstelle des Programms. Typischerweise wird das GUI-Programm während eines Produktentwicklungszyklus eines neuen Programms getestet. Das GUI-Programmtesten kann auch während der Entwicklung einer neuer Version eines existierenden GUI- Programms stattfinden.
Auf Grund von nicht angemessenen manuellen Testtechniken sind automatisierte Testtechniken entwickelt worden. Fig. 1 zeigt ein Computersystem 100 zum Testen eines GUI-Programms 101 unter Verwendung automatisierter Testtechniken, die sich im Stand der Technik finden. Das Computersystem 100 umfasst eine Anzeigevorrichtung 103, eine Speichervorrichtung 105, eine Eingabevorrichtung 107 und einen Computer 109. Der Computer umfasst eine Schnittstelle 111, einen Prozessor 113 und einen Computerspeicher 115, der das GUI-Programm 101 speichert. Das GUI-Programm umfasst eine GUI-Komponente 119 und eine Maschinenkomponente 121. Die GUI-Komponente aktualisiert und gewinnt Information rück aus einem Datenübertragungsblockpuffer, der einer GUI 117 zugeordnet ist. Kurz gesägt, weist die GUI-Komponente einen Programmcode zum Steuern von Änderungen an der GUT auf. Der Code kann automatisch aus GUI-Erzeugern erzeugt werden. Bei dem Maschinencode handelt es sich um einen Code, der die Funktionalität des Programms implementiert. Beispielsweise erzeugt der Maschinencode die auf der GUI anzuzeigende Information.
Automatisierte Testverfahren gemäß dem Stand der Technik simulieren Eingabeereignisse (wie etwa Mausklicks), um dieselben Datenverarbeitungspfade zu testen, die bei der Reaktion auf eine Nutzereingabe aufgerufen werden. Auf diese Weise wird die gesamte Funktionalität eines GUI-Programms durch die GUI-Komponente des Programms getestet. Die Verfahren gemäß dem Stand der Technik beginnen den Testprozess, indem sie einen Nutzer veranlassen, Daten durch eine GUI 117 unter Verwendung der Eingabevorrichtung 107 einzugeben. Die Eingaben können beispielsweise anzeigen, dass ein "ButtonPress"- Ereignis (Tastendrückereignis) verarbeitet werden sollte. Das Verfahren zeichnet Nutzereingaben auf und speichert sie in eine getrennte Datei. Die aufgezeichneten Eingaben werden später als Testscript 123 wiedergegeben. Die Testscriptmaschine 124 treibt die Wiedergabe des Testscripts 123. In Reaktion auf die Eingaben ändert die GUI 117 ihren Zustand. Wenn die Eingaben beispielsweise anzeigen, dass eine "ButtonPress"-Operation aufgerufen werden soll, führt das Verfahren die Schritte durch, die mit dem ButtonPress-Ereignis verbunden sind. In Reaktion auf die Änderungen der GUI speichert das Verfahren den neuen GUI-Zustand als Bit-Routinenverzeichnis (Bitmap) in einer Rasterdatei (auch als Speichern eines "Schnappschusses" der GUI bezeichnet). Das Bit-Routinenverzeichnis kann auch in einer anderen Art eines Bildformats gespeichert werden. Zusätzlich zu oder anstelle der Tätigung eines Schnappschusses kann das Verfahren eine Ressourcenverifikation für die auf der GUI angezeigten Widgets durchführen.
Der Schnappschuss dient als Basis zum Vergleich der Programmreaktion auf Nutzereingaben zu einem früheren Zeitpunkt im Entwicklungsprozess mit der Programmreaktion auf eben diese Nutzereingabe zu einem späteren Zeitpunkt des Entwicklungsprozesses. Wenn beispielsweise der Entwicklungsprozess fortschreitet, werden am Programmcode, der der GUI-Komponente 119 und der Maschinenkomponente 121 zu Grunde liegt, Änderungen vorgenommen. Um die Änderungen unter Verwendung automatisierter Techniken zu testen, gibt das Verfahren gemäß dem Stand der Technik die Eingabeereignisse wieder, die früher aufgezeichnet wurden. In Reaktion auf die Wiedergabe der eingegebenen Ereignisse ruft die GUI-Komponente 119 die Maschinenkomponente 121 auf, die wiederum die GUI-Komponente instruiert, die GUI nachzuziehen bzw. nachzuführen. Auf diese Weise wird die Maschinenkomponente 121 durch die GUI- Komponente 119 aufgerufen. Das Verfahren tätigt daraufhin einen Schnappschuss der Änderungen an der GUI 117. Schließlich wird der frühere Schnappschuss mit dem späteren Schnappschuss verglichen. Wenn die Schnappschüsse identisch sind, schließt das Verfahren, dass die Änderungen, die an dem Programm vorgenommen wurden, korrekt arbeiten. Nicht identische Schnappschüsse können anzeigen, dass in das Programm ein Bug (eine versteckte Schwierigkeit) eingeführt wurde.
Eines der mit automatisierten Testtechniken verbundenen Probleme betrifft das korrekte Synchronisieren der Wiedergabe der eingegebenen Ereignisse. Probleme treten auf, weil häufig zwischen den eingegebenen Ereignissen eine gegenseitige Abhängigkeit vorliegt. Beispielsweise wird angenommen, dass ein erstes eingegebenes Ereignis ein Menü auf der GUI anzeigt, und dass ein zweites eingegebenes Ereignis einen Eintrag auf dem Menü wählt. Damit das zweite Ereignis korrekt arbeitet, muss das Menü angezeigt werden, bevor das zweite eingegebene Ereignis bzw. Eingabeereignis ausgeführt wird. Wenn der Computer versucht, einen Eintrag auf einem Menü zu wählen, der nicht angezeigt ist, antwortet das System mit einem Fehler.
In der Vergangenheit haben einige Systementwickler versucht, das Synchronisationsproblem durch Einführen von Verzögerungen in ihre Testscripts zu überwinden. In Fortsetzung auf das vorstehend angesprochene Beispiel führen diese Entwickler ein Verzögerungskommando zwischen den ersten und zweiten eingegebenen Ereignissen in der Hoffnung ein, dass die Verzögerung lange genug sein müsste, um sicherzustellen, dass das "Menüauswahlereignis" ausgeführt wird, nachdem das System die Anzeige des Menüs beendet hat.
Das Einführen von Verzögerungskommandos in Testscripts geht häufig fehl bei der Überwindung des Synchronisationsproblems, weil die gesamte Zeitdauer, die ein gegebenes Ereignis zum Ausführen auf einem bestimmten Computer benötigt, immer dann variiert, wenn der Computer das Ereignis ausführt. Zumindest diese Zeitverzögerungen sind nicht angemessen, um zwischen Ereignissen eine korrekte Synchronisation zu gewährleisten.
Die Variation der Zeitdauer, die benötigt wird, für ein gegebenes Ereignis die Ausführung zu beenden, kommt noch stärker zum Tragen, wenn der Vergleich zwischen Ereignissen erfolgt, die auf unterschiedlichen Systemen ausgeführt werden. Ein derartiger Fall tritt auf, wenn ein Testscript verwendet wird, um einen bestimmten Port eines bestimmten Softwareprodukts zu testen. Wenn beispielsweise ein Softwareentwickler ein Operationssystem ausgehend von einer Plattform mit schnellerem Mikroprozessor zu einer Plattform mit einem langsameren Mikroprozessor portet, kann die ursprünglich in das Testscript eingeführte Zeitverzögerung nicht ausreichen, korrekte Synchronisation zu gewährleisten. Aus zumindest diesem zusätzlichen Grund sind Zeitverzögerungen für die Gewährleistung korrekter Synchronisation unangemessen.
Außerdem ist das Teiltesten des Leistungsvermögens eines Softwareprodukts nicht möglich, wenn Zeitverzögerungen in das Testscript eingeführt werden. Teiltesten sieht das Laufen lassen eines Softwareprodukts durch eine Reihe von Tests und das Messendes Leistungsvermögens des Softwareprodukts während der Tests vor. Wenn Zeitverzögerungen in das Testscript eingeführt werden, werden Messungen von einem Teiltest offensichtlich bedeutungslos. Aus zumindest diesem zusätzlichen Grund sind Zeitverzögerungen unerwünscht.
Das Einführen von Zeitverzögerungen führt zu einem allgemeinen Problem, demnach diese die Testausführung langsamer machen. Dieses Problem kommt stärker zum Tragen, wenn große Testsuiten verwendet werden.
Es wäre vorteilhaft, ein verbessertes Verfahren und ein verbessertes System zum Gewährleisten der korrekten Synchronisation zwischen Testereignissen zu entwickeln.
Die Druckschrift GB-A-2242291 offenbart ein Verfahren zur Ausführung in einem Computersystem zum Synchronisieren der Ausführung von Ereignissen während des Testens eines Softwaremoduls, wobei das Verfahren die Schritte aufweist, ein erstes Ereignis zu empfangen; das erste Ereignis zu verarbeiten; und die Initiierung eines zweiten Ereignisses zu verzögern, wenn das erste Ereignis ein Synchronisationsereignis ist, bis eine Mitteilung bezüglich der Beendigung des ersten Ereignisses empfangen wird. Eine Journaldatei wird verwendet, um eine aufgezeichnete Reihe von Nutzeraktionen für die nachfolgende Wiedergabe zu speichern und Synchronisationspunkte sind in der Journaldatei für Aktionen enthalten, die beendet werden müssen, bevor die Aktionen durchgeführt werden. Bei der Wiedergabe werden Ereignisse aus der Journaldatei zu dem System für die Austragung überführt. Wenn das Ereignis ein Synchronisationsereignis ist, wartet der Mechanismus darauf, dass die Verarbeitung des Synchronisationsereignisses beendet ist, bevor das nächste Ereignis aus der Journaldatei ausgegeben wird.
Die vorliegende Erfindung ist in den unabhängigen Ansprüchen festgelegt.
Eine Ausführungsform sieht ein verbessertes Verfahren und ein verbessertes System zum Synchronisieren der Ausführung von zwei oder mehr Ereignissen vor, die zum Testen eines Softwareprodukts verwendet werden. Das verbesserte Verfahren beginnt durch Aufrufen eines Treibers zur Unterstützung bei der Erzeugung eines ersten Ereignisses. Das Treiberprogramm sendet eine erste Mitteilung aus, die den Klienten instruiert, die Erzeugung des ersten Ereignisses zu initiieren. Nachdem das erste Ereignis erzeugt worden ist, speichert der Klient das erste Ereignis in einer ersten Warteschlange. Als nächstes verarbeitet der Klient das erste Ereignis. Im Verlauf der Verarbeitung des ersten Ereignisses können andere Ereignisse erzeugt und in der ersten Warteschlange abgelegt werden. Der Klient prüft deshalb die erste Warteschlange, um zu ermitteln, ob Ereignisse, die während der Verarbeitung des ersten Ereignisses hervorgebracht wurden, auf die Verarbeitung warten. Wenn neue Ereignisse in der ersten Warteschlange abgelegt sind, verarbeitet der Klient die neuen Ereignisse. Dieser Prozess dauert an, bis die Prüfung ermittelt, dass die erste Warteschlange keine Ereignisse bevorratet. Nachdem sämtliche Ereignisse bezüglich ihrer Verarbeitung beendet sind, sendet der Klient an den Treiber eine Bestätigung. Die Bestätigung zeigt an, dass der Treiber eine zweite Mitteilung zur Verarbeitung durch den Klienten übersenden kann.

BESCHREIBUNG DER ZEICHNUNGEN

Fig. 1 zeigt ein Computersystem zum Testen eines GUI- Programms unter Verwendung automatisierter Testtechniken gemäß dem Stand der Technik.
Fig. 2 zeigt ein Blockdiagramm eines Computersystems zum Umsetzen der verschiedenen Ausführungsformen in die Praxis.
Fig. 2 zeigt ein Flussdiagramm eines Überblicks der Verarbeitung, die in dem GUI-Programm während des Programmtestvorgangs stattfindet.
Fig. 4 zeigt ein Flussdiagramm einer ersten Ausführungsform der XNextEvent-Routine.
Fig. 5 zeigt ein Flussdiagramm der NhSyn-Routine.
Fig. 6 zeigt ein Flussdiagramm einer zweiten Ausführungsform der XNextEvent-Routine.
Fig. 7 zeigt ein Flussdiagramm einer ersten Ausführungsform der NhPending-Routine.
Fig. 8 zeigt ein Flussdiagramm einer ersten Ausführungsform einer Ereignishandhaberroutine.
Fig. 9 zeigt ein Flussdiagramm einer dritten Ausführungsform der XNextEvent-Routine.
Fig. 10 zeigt ein Flussdiagramm einer zweiten Ausführungsform der NhPending-Routine.
Fig. 11 zeigt ein Flussdiagramm einer zweiten Ausführungsform der Ereignishandhaberroutine.
Fig. 12 zeigt ein Flussdiagramm des Prozesses der Leerlaufrückrufroutine.
Fig. 13 zeigt ein Flussdiagramm der Leerlaufrückruf- Handhaberroutine.
Fig. 14 zeigt ein Flussdiagramm einer vierten Ausführungsform der XNextEvent-Routine.
Fig. 15 zeigt eine modifizierte Version der Event-Handler- Routin.

NOTATIONEN UND NOMENKLATUR

Die nachfolgenden detaillieren Erläuterung erfolgen weitgehend in Begriffen von Verfahren und symbolischen Darstellungen von Operationen auf Datenbits in einem Computer. Diese Verfahrensbeschreibungen und -darstellungen sind die Mittel, die der Fachmann auf dem Gebiet der Datenverarbeitung am wirksamsten einsetzt, um die Substanz seiner Arbeit anderen Fachleuten wirksam mitzuteilen.
Bei einem Verfahren handelt es sich vorliegend allgemein um eine selbstkonsistente Sequenz aus Schritten, die zu einem erwünschten Ergebnis führen. Diese Schritte erfordern physikalische Manipulationen physikalischer Größen. Üblicherweise, obwohl nicht notwendigerweise, haben dieses Größen die Form elektrischer oder magnetischer Signale, die gespeichert, übertragen, kombiniert, verglichen und anderweitig manipuliert werden können. Mitunter erweist es sich als geeignet, prinzipiell aus Gründen der üblichen Nutzung, auf diese Signale als Bits, Werte, Elemente, Symbole, Zeichen, Größen, Zahlen oder dergleichen Bezug zu nehmen. Es wird jedoch bemerkt, dass sämtliche dieser sowie ähnliche Begriffe mit geeigneten physikalischen Größen verknüpft werden müssen, und dass sie lediglich geeignete Bezeichnungen sind, die auf diese Größen angewendet werden.
Nützliche Maschinen zum Durchführen der Operationen der Ausführungsformen umfassen übliche digitale Allzweckcomputer oder ähnliche Geräte. Der übliche Allzweckcomputer kann selektiv durch ein Computerprogramm aktiviert oder rekonfiguriert werden, das in dem Computer gespeichert ist. Ein Spezialzweckcomputer kann auch verwendet werden, um die Operationen der Ausführungsformen durchzuführen. Kurz gesagt, ist die Verwendung der vorstehend erläuterten und vorgeschlagenen Verfahren nicht auf eine spezielle Computerkonfiguration beschränkt.

DETAILLIERTE BESCHREIBUNG

Überblick über die bevorzugten Verfahren:

Die nachfolgend erläuterten Ausführungsformen stellen ein verbessertes Verfahren und ein verbessertes System zum Synchronisieren der Ausführung von zwei oder mehr Ereignissen bereit, die zum Testen eines Softwareprodukts verwendet werden. Eine Ausführungsform besteht darin, einen Treiber zur Unterstützung bei der Erzeugung eines ersten Ereignisses aufzurufen. Das Treiberprogramm überträgt eine Mitteilung, die den Klienten instruiert, die Erzeugung des ersten Ereignisses zu initiieren. Nachdem das erste Ereignis erzeugt worden ist, speichert det Klient das erste Ereignis in einer ersten Warteschlange. Als nächstes verarbeitet der Klient das erste Ereignis. Im Verlauf der Verarbeitung des ersten Ereignisses können neue Ereignisse erzeugt und in der ersten Warteschlange abgelegt worden sein. Der Klient prüft deshalb die erste Warteschlange zur Ermittlung, ob neue Ereignisse hervorgebracht wurden, während das erste Ereignis verarbeitet wird. Wenn neue Ereignisse in der ersten Warteschlange gespeichert sind, verarbeitet der Klient die neuen Ereignisse. Der Prozess dauert an, bis die Prüfung ermittelt, dass die erste Warteschlange keine neuen Ereignisse aufnimmt. Nachdem sämtliche Ereignisse bezüglich ihrer Verarbeitung beendet sind, fährt der Klient mit dem Übertragen einer Bestätigung an den Treiber fort. Die Bestätigung zeigt an, dass der Treiber eine neue Mitteilung zur Verarbeitung durch den Klienten übertragen kann.
Die nachfolgend erläuterten Ausführungsformen betreffen eine Implementation, die zur Verwendung in einer Softwaretestumgebung ausgelegt ist. Dessen ungeachtet erschließt sich dem Fachmann auf diesem Gebiet der Technik, dass die Ausführungsformen auch in anderen Umgebungen implementiert werden können, in denen Ereignisse eine Synchronisation erfordern.

Überblick über das bevorzugte System:

Fig. 2 zeigt ein Blockdiagramm eins Computersystems 200, um verschiedene Ausführungsformen in die Praxis umzusetzen. Das Computersystem 2 umfasst einen Computer 201, eine Eingabevorrichtung 203, eine Speichervorrichtung 205 und eine Anzeigevorrichtung 207. Die Anzeigevorrichtung 207 zeigt eine grafische Nutzerschnittstelle (GUI) 209 an. Ein (nicht gezeigter) Datenübertragungsblockpuffer stellt einen Speicher zum Speichern von Daten zur Anzeige auf der GUI 209 bereit. Die GUI stellt Information durch Icons dar, und ein Nutzer ruft Kommandos auf durch Zeigen auf oder Manipulieren der Icons. Der Computer 201 umfasst einen Prozessor 211, einen Speicher 213 und eine Schnittstelle 215, um eine Kommunikation zwischen dem Prozessor 211 und peripheren Vorrichtungen, wie etwa der Eingabevorrichtung 203 und der Anzeigevorrichtung 207, zu ermöglichen.
Der Computerspeicher umfasst eine Anzahl von Elementen, einschließlich einem GUI-Programm (oder einem "Klienten") 217 und einer Testmaschine 219. Die Testmaschine 219 enthält ein Testscript 221, einen No-Hands-Treiber 223 und einen Interpretierer 224. Das GUI-Programm 217 und die Testmaschine 219 sind bevorzugt als individuelle Prozesse implementiert. Das Testscript 221 enthält eine Reihe von Kommandos zum Aufrufen von Routinen, die eine Nutzeraktion auf der GUI 209 simulieren. Die simulierte Aktion wird verwendet, um das GUI-Programm 217 zu testen. Testscripts können manuell aus Konstruktionsspezifikationen der GUI-Komponente und der Maschinenkomponente entwickelt werden, während beide Komponenten sich in Entwicklung befinden. Die Testscripts können auch automatisch unter Verwendung eins Computerprogramms erzeugt werden, das für diesen Zweck entwickelt wurde.
Die Testscriptkommandos werden aus dem Testscript rückgewonnen und zu dem GUI-Programm 217 als Mitteilung über einen Treiber 223 übertragen. Der Treiber 223 ist bevorzugt unter Verwendung des No-Hands-Softwareprodukts von SunSoft, einer Tochterfirma von Sun Microsystems Inc. implementiert. Der No- Hands-Treiber enthält bevorzugt den Verarbeitungsraum bzw. Prozessraum der Testmaschine 219. Der No-Hands-Treiber kommuniziert mit der Testscriptmaschine und dem GUI-Programm durch einen beliebigen, an sich bekannten Zwischenptozesskommunikationsmechanismus (nicht gezeigt). Der No-Hands-Treiber 223 gewinnt ein Kommando aus dem Testscript 221 rück und überträgt eine entsprechende Mitteilung zu einer No-Hands-Bibliothek 225 über den Zwischenprozesskommunikations(IPC)mechanismus. Der No-Hands-Treiber blockiert bevorzugt, bis er eine Bestätigung aus dem GUP-Programm 217 empfängt, dass das GUI- Programm bereit ist, eine neue Mitteilung zu verarbeiten.
Die No-Hands-Bibliothek 225 führt die Mitteilung durch Initiieren der Erzeugung eines Ereignisses aus, das eine Nutzeraktion auf der GUI 209 simuliert. Beispielsweise kann das Ereignis einen "Doppelklick" eines Nutzers auf eine Taste zur Anzeige eines neuen Menüs simulieren.
Bevor diskutiert wird, wie simulierte Ereignisse durch die verschiedenen Ausführungsformen verarbeitet werden, kann es nützlich sein, zunächst zu erläutern, wie tatsächliche Ereignisse durch ein typisches Fensterbildungssystem verarbeitet werden. Bei dem X-Window-System (Marke) handelt es sich um das bevorzugte Fensterbildungssystem der Ausführungsformen zum Verwalten der Eingabe und Ausgabe auf einer GUI. Bei dem X-Window-System handelt es sich um eine Kombination aus einem X-Protokoll, einem X-Anzeigeserver, X-Klienten und Xlib- Routinen. Bei den X-Klienten handelt es sich um Anwendungen, wie etwa das GUI-Programm 217, das eine Computeranzeigevorrichtung nutzt. Der X-Klient formatiert seine Anfragen unter Verwendung des X-Protokolls und überträgt die Anfragen zu dem X-Anzeigeserver (beispielsweise dem Anzeigeserver 229). Der X-Anzeigeserver ist ein Prozess, der Ausgaben von dem Datenübertragungspuffer und Eingaben von der Tastatur und der Maus verwaltet. Der X-Anzeigeserver berücksichtigt alles, ausgehend von der Tastatur und der Maus, als Ereignisse, die dem Klienten zu berichten sind. Wenn beispielsweise ein Nutzer eine Maustaste in einem Fenster auf der GUI drückt und loslässt, sendet der X-Server diese eingegebenen Ereignisse zu der X-Klientenanwendung, die mit diesem Fenster verbunden ist. Der X-Klient prüft das eingegebene Ereignis und ermittelt, welche Aktion ergriffen werden soll. Typischerweise ist eine Reihe von "Rückrufen" mit jedem Ereignis verbunden. In Reaktion auf den Empfang eines Ereignisses ruft der X-Klient deshalb die geeigneten "Rückrufe" in die X-Bibliothekroutinen auf, um die geeignete Aktion durchzuführen. Rückrufe sind nicht auf Anrufe in die X-Windows-Bibliothek beschränkt; vielmehr können sie andere Schritte ebenfalls durchführen. Die X-Bibliothekroutinen senden Anfragen zu dem X-Anzeigeserver, der seinerseits die GUI aktualisiert. Detailliertere Information bezüglich des X-Window-Systems finden sich in X Window System Programming, von Naba Barkakati.
Die Ausführungsformen simulieren eine Nutzereingabe unter Verwendung von Testscriptkommandos, um den Testprozess zu automatisieren. Die Ausführungsformen empfangen deshalb nicht typischerweise eine tatsächliche Nutzereingabe. Um ein simuliertes Ereignis zu erzeugen, führt die No-Hands-Bibliothek 225 einen Anruf (oder eine Reihe von Anrufen) in die Bibliothek 241 durch. In der bevorzugten Ausführungsform ist die Bibliothek 241 unter Verwendung der XTrap-Erweiterungsklientenbibliothek für das X-Window-System implementiert. Die XTrap-Erweiterungsklientenbibliothek ruft daraufhin einen Anzeigeserver 229 auf, der die GUI 209 in Übereinstimmung mit den Verfahren von der Bibliothek tatsächlich aktualisiert.
Zusätzlich zum Initiieren einer Erzeugung des simulierten Ereignisses verfolgen die No-Hands-Bibliothekroutinen auch die Verarbeitung des Ereignisses, um zu ermitteln, wann die Verarbeitung des Ereignisses beendet ist. Wenn die Spurverfolgung anzeigt, dass die Verarbeitung des Ereignisses beendet ist, sendet die No-Hands-Bibliothekroutine eine Bestätigung zurück zu dem No-Hands-Treiber 223, wodurch angezeigt ist, dass die No-Hands-Bibliothek 225 bereit ist, eine neue Mitteilung von deni No-Hands-Treiber zu empfangen.

Flussdiagramme

Fig. 3 bis 13 zeigen Flussdiagramme zur Erläuterung unterschiedlicher Ausführungsformen. Bevor der Prozessablauf bzw. die Verarbeitung in den Fig. 3 bis 13 beginnt, wird das System 200 zu einem Punkt gebracht, an dem sämtliche Prozesse aktiv sind und laufen und durch Interprozesskommunikationsmechanismen verbunden sind. Sobald sie verbunden sind, werden die Prozesse aufgerufen, um ein simuliertes Ereignis in eine Anzeigeserverwarteschlange 233 zu injizieren.
Fig. 3 zeigt eine Ereignisschleife, die von dem GUI-Programm 217 genutzt wird, um das simulierte Ereignis zu verarbeiten. Die Ereignisschleife gewinnt das simulierte Ereignis aus der Anzeigeserverwarteschlange 233 rück, verarbeitet das rückgewonnene Ereignis und verfolgt die Verarbeitung des Ereignisses, um zu ermitteln, wann die Verarbeitung bzw. der Prozessablauf beendet ist. Wenn der Prozessablauf beendet bzw. vollständig ist, sendet die Ereignisschleife eine Bestätigung zu dem No-Hands-Treiber unter Anzeige, dass das GUI-Programm bereit ist, eine weitere Mitteilung von dem No-Hands-Treiber zu verarbeiten. Auf diese Weise wird die Ereignissimulation in geeigneter Weise bzw. korrekt synchtonisiert.
Innerhalb des X-Windows-Systems nutzt die Ereignisschleife die XNextEvent-Routine zum Rückgewinnen von Ereignissen von dem Anzeigeserver. XNextEvent prüft daraufhin die Fensteridentifikation und die Ereignistypinformation, die zusammen mit dem Ereignis übertragen wird, und entscheidet, was auf Grundlage dieser Information zu tun ist. Die Ereignisschleife wird typischerweise abgebrochen, wenn eine Variable ihren Wert von Null auf nicht Null ändert. Eines der Ereignisse, beispielsweise das Quit-Ereignis, wählt diese Variable mit einem Nicht-Null-Wert. Die Erzeugung eines XIOError kann auch ein Verlassen der Ereignisschleife hervorrufen.
Die XNextEvent-Routine, die mit dem X-Windows-System einhergeht, enthält keinen Code zur Verfolgung der Verarbeitung eines Ereignisses oder zum Übertragen einer Bestätigung zu dem No-Hands-Treiber, wenn die Verarbeitung des Ereignisses beendet ist. Um einen derartigen Code in die Ereignisschleifenverarbeitung einzufügen, erzeugten die Entwickler der vorliegenden Erfindung ihre eigene Version der XNextEvent-Routine, die bevorzugt dieselbe Funktionalität wie die XNextEvent- Routine enthält, jedoch zusätzlich außerdem einen Code zum Verfolgen des Status der Ereignisverarbeitung und zum Übertragen einer Bestätigung zu dem No-Hands-Treiber. Die Entwickler der vorliegenden Erfindung haben tatsächlich drei getrennte Ausführungsformen der XNextEvent-Routine entwickelt. Die XNextEvent-Routine ist bevorzugt in der No-Hands- Bibliothek 225 gespeichert.
Um sicherzustellen, dass die XNextEvent-Routine in der No- Hands-Bibliothek 225 vor oder anstelle der XNextEvent-Routine in der X-Bibliothek 227 ausgeführt wird, haben die Entwickler der vorliegenden Erfindung ihre Version Von XNextEvent vor der X-Windows-Version von XNextEvent angeordnet. Indem Solaris-Betriebssystem wird diese Anordnung bzw. Einfügung verwendet unter Nutzung der LD PRELOAD-Umgebungsvariablen. Die LD PRELOAD-Umgebungsvariable enthält eine Liste von geteilt genutzten Objekten, die durch den dynamischen Linker zum aktiven Zeitpunkt interpretiert werden sollen. Die spezifizierten nutzungsgeteilten Objekte werden eingefügt, nachdem das Programm ausgeführt wurde (beispielsweise das GUI-Programm 217) und vor den geteilt genutzten Objekten, auf die das Programm sich bezieht (beispielsweise die X-Bibliothek 227). Wenn auf diese Weise das GUI-Programm 217 seine Ereignisschleife initiiert und einen Aufruf für das Betriebssystem 231 durchführt, um die XNextEvent-Routine aufzurufen, ruft das Betriebssystem 231 die Version von XNextEvent auf, die in der No-Hands-Bibliothek 225 gespeichert ist. In der bevorzugten Ausführungsform nutzt das System das Solaris[Bei Solaris handelt es sich um eine Handelsmarke oder eingetragene Marke von Sun Microsystems Inc. in den Vereinigten Staaten und weiteren Ländern.]- Betriebssystem von Sun Microsystems. Dem Fachmann erschließt sich, dass andere Betriebssysteme als Solaris genutzt werden können, und dass andere Verfahren als LD_PRELOAD dann aufgerufen werden, um Verfahren einzuschieben, die verwendet werden, die Ereignisschleife des Systems zu implementieren. Dem Fachmann erschließt sich außerdem, dass andere Fensterbildungssysteme als X Windows genutzt werden können.

Erste Ausführungsform von XNextEvent:

Fig. 4 zeigt ein Flussdiagramm einer ersten Ausführungsform der XNextEvent-Routine. Im Schritt 401 prüft die Routine eine Klientenwarteschlange 235, um zu ermitteln, ob die aktuelle Klientenwarteschlange irgendein Ereignis speichert, das auf eine Verarbeitung wartet. Wenn die Klientenwarteschlange Ereignisse speichert, gewinnt die Routine das nächste Ereignis von bzw. aus der Klientenwarteschlange rück (Schritt 403). Im Schritt 405 kehrt XNextEvent zum Schritt 303 in der Ereignisschleife zurück, wo das Ereignis verarbeitet wird.
Wenn die Klientenwarteschlange aktuell keine Ereignisse speichert, prüft die Routine im Schritt 407 einen Mitteilungspuffer 237, um zu Ermitteln, ob irgendwelche Mitteilungen von dem No-Hands-Treiber 223 empfangen wurden. Wenn keine Mitteilungen empfangen worden sind, kehrt die Verarbeitung in der Routine schleifenartig zum Schritt 401 zurück. Wenn jedoch die Routine eine Mitteilung von dem No-Hands-Treiber empfangen hat, verarbeitet XNextEvent die Mitteilung im Schritt 409. Die Mitteilung initiiert das Verarbeiten im System 200, das ein simuliertes Ereignis in die Anzeigeserverwarteschlange 233 injiziert. In der bevorzugten Ausführungsform erfolgt dies durch Übertragen einer Anforderung zu dem Anzeigeserver 229, um ein Ereignis zu erzeugen. Die Ereigniserzeugung in dem Anzeigeserver wird bevorzugt mit Routinen ausgeführt, die in der XTrap-Erweiterung 239 des Anzeigeservers 229 und der XTrap-Erweiterungsklientenbibliothek 241 des GUI-Programms 217 gespeichert sind. Die XTrap-Erweiterungen sollten deshalb in dem System 200 installiert werden, bevor eine Eingabesimulierung versucht wird. Dem Fachmann erschließt sich, dass andere Fenstersysteme ähnliche Mechanismen zum Durchführen der Injektion eines Ereignisses in das System aufweisen. Nachdem das Ereignis in die Anzeigeserverwarteschlange injiziert wurde, ruft XNextEvent eine NhSync-Routine (Schritt 411) auf. Beim Rückkehren von NhSync wird die Verarbeitung in XNextEvent im Schritt 401 fortgesetzt.
Fig. 5 zeigt ein Flussdiagramm der NhSync-Routine. Im Schritt 501 überführt NhSync Ereignisse aus der Anzeigeserverwarteschlange 233 zu der Klientenwarteschlange 235. In der bevorzugten Ausführungsform wird die XSync-Routine von der X- Bibliothek genutzt, um Ereignisse aus der Anzeigeserverwarteschlange 233 zu der Klientenwarteschlange 235 zu überführen. Im Schritt 503 prüft NhSync die Klientenwarteschlange 235, um zu ermitteln, ob die Klientenwarteschlange leer ist. Wenn die Klientenwarteschlange nicht leer ist, wird im Schritt 505 ein rekursiver Aufruf der XNextEvent-Routine ausgeführt.
In Reaktion auf den rekursiven Aufruf von XNextEvent wird die Verarbeitung in XNextEvent im Schritt 401 fortgesetzt. Im Schritt 401 prüft die XNextEvent-Routine eine Klientenwarteschlange 235, um zu ermitteln, ob die Klientenwarteschlange aktuell irgendwelche Ereignisse speichert, die auf eine Verarbeitung warten. Wenn die Klientenwarteschlange keine Ereignisse speichert, gewinnt die XNextEvent-Routine als nächstes das nächste Ereignis aus der Klientenwarteschlange rück (Schritt 403). Im Schritt 405 kehrt XNextEvent zum Schritt 507 in NhSync zurück, wo NhSync eine Ereignishandhaberroutine aus der X-Bibliothek 227 aufruft. Die Ereignishandhaberroutine verarbeitet das Ereignis zur Durchführung der Aufgabe, die durch das Ereignis ausgeführt werden sollte. In dieser Ausführungsform handelt es sich bei der XtDispatchEvent-Routine (oder einer äquivalenten Routine für andere GUI-Werkzeugmittel) um die bevorzugte Ereignishandhaberroutine. Beim Zurückkehren von der Ereignishandhaberroutine wird die Verarbeitung mit dem Schritt 501 der NhSync-Routine fortgesetzt. Die Schritte 303 und 507 führen Ereignisverarbeitungsschritte durch. Der Schritt 303 führt jedoch eine Ereignisverarbeitung innerhalb der XNextEvent-Routine durch, während der Schritt 507 eine Ereignisroutine nur dann durchführt, wenn die Verarbeitung aus XNextEvent ausbricht.
Wenn unter erneutem Bezug auf die Diskussion des Schritts 503 NhSync ermittelt, dass die Klientenwarteschlange leer ist, überträgt NhSync im Schritt 509 eine Bestätigung zu dem No- Hands-Treiber 223 unter Anzeige, dass das GUI-Programm 207 bereit-ist, eine neue Mitteilung von dem No-Hands-Treiber zu verarbeiten. Im Schritt 511 endet die Verarbeitung in der NhSync-Routine.
Eine Beschränkung der ersten Ausführungsform von XNextEvent besteht darin, dass sie nicht in der Lage ist, einige GUI- Programmverarbeitungsvorgänge exakt zu simulieren, die in Reaktion auf tatsächliche Nutzeraktionen auf der GUI 209 stattfinden. Beispielsweise ruft in der ersten Ausführungsform von XNextEvent die Routine einen werkzeugmittelspezifischen Ereignishandhaber auf, um die tatsächliche Verarbeitung eines rückgewonnenen Ereignisses zu simulieren (siehe Schritt 507 von Fig. 5). Das Aufrufen des werkzeugmittelspezifischen Ereignishandhabers simuliert jedoch nicht exakt die Verarbeitung, die in Reaktion auf einige Nutzeraktionen stattfindet. Insbesondere werden einige Nutzeraktionen verarbeitet, ohne dass jemals ein nutzermittelspezifischer Ereignishandhaber aufgerufen wird. Statt dessen wird ein Kundencode verwendet, um das Ereignis zu verarbeiten. Da die erste Ausführungsform von XNextEvent den werkzeugmittelspezifischen Ereignishandhaber aufruft, den Kundencode jedoch nicht aufruft, simuliert die erste Ausführungsform nicht exakt jegliche Ereignisverarbeitung.

Zweite Ausführungsform von XNextEvent:

Fig. 6 zeigt ein Flussdiagramm einer zweiten Ausführungsform der XNextEvent-Routine. Im Schritt 601 prüft XNextEvent die Klientenwarteschlange 235, um zu ermitteln, ob sie aktuell ein Ereignis speichert, das auf Verarbeitung wartet. Wenn die Klientenwarteschlange leer ist (wie dies beim ersten Mal in dieser Routine der Fall sein kann), prüft XNextEvent im Schritt 603 den Mitteilungspuffer 237, um zu ermitteln, ob eine Ermittlung von dem No-Hands-Treiber 223 empfangen wurde. Wenn keine Mitteilungen empfangen wurden, springt die Verarbeitung zum Schritt 601 in Schleifenart zurück, um erneut zu prüfen, ob ein Ereignis in der Klientenwarteschlange wartet.

Verarbeitung von Mitteilungen von No-Hands

Wenn die Routine jedoch eine Mitteilung von dem No-Hands- Treiber im Schritt 605 empfangen hat, verarbeitet XNextEvent die Mitteilung. Die Mitteilung kann die Verarbeitung in dem System 200 initiieren, um ein simuliertes Ereignis in die Anzeigeserverwarteschlange 233 zu injizieren; alternativ kann sie andere Typen von Verarbeitung initiieren. In der bevorzugten Ausführungsform wird die XTrap-Routine XESimulateXEventRequest verwendet, wenn der No-Hands-Treiber beabsichtigt, das simulierte Ereignis in die Anzeigeserverwarteschlange zu simulieren. Nachdem die Mitteilung verarbeitet wurde, ruft die Routine im Schritt 607 eine NhPending-Routine auf. Wenn ein Ereignis nicht erzeugt wurde, überträgt die NhPending-Routine eine Bestätigung zurück zu dem No-Hands- Treiber. Wenn ein Ereignis erzeugt wurde, registriert NhPending eine Ereignishandhaberroutine, die die Verarbeitung des Ereignisses rückverfolgt, um den korrekten Zeitpunkt zu ermitteln, um eine Bestätigung zu dem No-Hands-Treiber zu übertragen. Die NhPending-Routine ist nachfolgend näher erläutert und in Fig. 7 gezeigt.

Verarbeiten von Ereignissen

Nach Rückkehr von dem NhPending-Aufruf schreitet der Prozess zum Schritt 601 der XNextEvent-Routine weiter. Wenn im Schritt 601 der XNextEvent ermittelt, dass die Klientenwarteschlange 235 aktuell Ereignisse speichert, die auf Verarbeitung warten (beispielsweise Ereignisse, die aus der Ausführung der No-Hands-Mitteilung erzeugt sind), wird das nächste Ereignis in der Klientenwarteschlange im Schritt 609 daraufhin rückgewonnen. Im Schritt 611 ermittelt XNextEvent, ob ein Ereignishandhaber für das Ereignis registriert ist, das aus der Klientenwarteschlange 235 rückgewonnen wurde. Die Registrierung von Ereignishandhabern wird durch einen kundenspezifisch entwickelten Code bereit gestellt, der eine Liste von Funktionen beibehält, die aufgerufen werden sollen, wenn das Ereignis rückgewonnen wird. Wenn ein Ereignishandhaber für ein gewähltes Ereignis registriert ist, ruft die eingefügte XNextEvent-Routine den Ereignishandhaber immer dann auf, wenn das Ereignis auftritt. Ein Ereignishandhaber stellt dadurch sicher, dass bestimmte Verarbeitungsschritte in Reaktion auf in dem System gewählte Ereignisse stattfindet. Wenn ein Ereignishandhaber für das im Schritt 609 rückgewonnene Ereignis registriert ist, wird er im Schritt 613 aufgerufen. Wie nachfolgend unter Bezug auf Fig. 8 näher erläutert, prüft der Ereignishandhaber, der durch diese Ausführungsform verwendet wird, die Klientenwarteschlange, um zu ermitteln, ob das System das letzte Ereignis aus der Klientenwarteschlange rückgewonnen hat. Wenn das System das letzte Ereignis aus der Klientenwarteschlange rückgewonnen hat, überträgt der Ereignishandhaber eine Bestätigung zu dem No-Hands-Treiber, wodurch angezeigt wird, dass das GUI-Programm zur Verarbeitung einer neuen Mitteilung von dem No-Hands-Treiber bereit ist. Bei Rückkehr von dem Ereignishandhaber, oder wenn an der ersten Stelle kein Ereignishandhaber registriert ist, kehrt XNextEvent zu der Ereignisschleife von Fig. 3 zurück, wo das rückgewonnene Ereignis durch die Prozessereignisroutine ausgeführt wird.

Die NhPending-Routine

Fig. 7 zeigt ein Flussdiagramm der NhPending-Routine. Die NhPending-Routine prüft die Klientenwarteschlange 235, um zu ermitteln, dass sie keine Ereignisse mehr speichert, die auf eine Verarbeitung warten. Sobald die Klientenwarteschlange leer ist, ist dies ein Anzeichen dafür, dass XNextEvent sämtliche Ereignisse verarbeitet hat, die in Reaktion auf die No- Hands-Mitteilung erzeugt werden. Sobald ermittelt wird, dass sämtliche Ereignisse verarbeitet worden sind, überträgt NhPending eine Bestätigung zu dem No-Hands-Treiber, wodurch angezeigt wird, dass das GUI-Programm bereit ist, die Verarbeitung einer neuen Mitteilung von dem No-Hands-Treiber zu starten.
Im Schritt 701 überträgt NhPending Ereignisse von der Anzeigeserverwarteschlange 233 zu der Klientenwarteschlange 235. Im Schritt 703 prüft NhPending, ob die Klientenwarteschlange 235 aktuell irgendwelche Ereignisse speichert, die auf eine Verarbeitung warten. Wenn die Klientenwarteschlange 235 nicht leer ist, registriert NhPending im Schritt 705 eine Ereignishandhaberroutine. Nachdem der Ereignishandhaber registriert ist, kehrt NhPending zu XNextEvent zurück (Schritt 707).
Wenn NhPending ermittelt, dass die Klientenwarteschlange aktuell keine Ereignisse speichert, die auf eine Verarbeitung warten (Schritt 703), überträgt NhPending im Schritt 709 eine Bestätigung zu dem No-Hands-Treiber. Die Bestätigung zeigt an, dass das GUI-Programm nunmehr bereit ist, eine neue Mitteilung von dem No-Hands-Treiber zu verarbeiten. Der Schritt 709 gelangt beispielsweise dann zur Ausführung, wenn die Ausführung der No-Hands-Mitteilung in dem System kein Ereignis erzeugt. Nach dem Übertragen der Bestätigung kehrt NhPending zu XNextEvent zurück (Schritt 707).

Die Ereignishandhaberroutine

Fig. 8 zeigt ein Flussdiagramm einer ersten Ausführungsform der Ereignishandhaberroutine. Im Schritt 801 überträgt der Ereignishandhaber Ereignisse aus der Anzeigeserverwarteschlange 233 zu der Klientenwarteschlange 235. Im Schritt 803 prüft die Ereignishandhaberroutine die Klientenwarteschlange, ob zu ermitteln, ob irgendwelche Ereignisse auf eine Verarbeitung warten, die aktuell in der Klientenwarteschlange gespeichert sind. Wenn die Klientenwarteschlange leer ist, wird eine Bestätigung zu dem No-Hands-Treiber 223 übertragen (Schritt 805) und die Ereignishandhaberroutine wird aufgerufen (Schritt 807). Die Bestätigung zeigt an, dass das GUI- Programm nunmehr bereit ist, eine neue Mitteilung von dem No- Hands-Treiber zu verarbeiten. Wenn die Klientenwarteschlange jedoch aktuell Ereignisse speichert, die auf eine Verarbeitung warten, kehrt die Ereignishandhaberroutine im Schritt 809 zu XNextEvent zurück und die Ereignisse werden verarbeitet, wenn XNextEvent zu der Ereignisschleife von Fig. 3 zurückkehrt.
Durch Aufrufen einer Ereignishandhaberroutine zum Prüfen des Status der Klientenwarteschlange werden Ereignisse hervorgerufen, während die Verarbeitung weiterer Ereignisse erfolgt, bevor eine Bestätigung zu dem No-Hands-Treiber 223 übertragen wird. Beispielsweise wird angenommen, dass, die Mitteilung von dem No-Hands-Treiber ein Tastendrückereignis in die Anzeigeserverwarteschlange injiziert. Während der Verarbeitung des ursprünglichen Tastendrückereignisses können weitere Ereignisse hervorgerufen werden und in der Anzeigeserverwarteschlange gespeichert werden. Beispielsweise können ein Routineverzeichnisereignis, ein Konfigurierereignis und ein Darlegereignis hervorgerufen und in der Anzeigeserverwarteschlange gespeichert werden, um einen Dialogkasten in Reaktion auf das ursprüngliche Tastendrückereignis anzuzeigen. Um eine korrekte Synchronisierung zwischen der Ausführung von Mitteilungen von dem No-Hands-Treiber zu gewährleisten, müssen sämtliche Ereignisse, die hervorgerufen werden, während das ursprüngliche Ereignis verarbeitet wird, selbst vollständig verarbeitet werden, bevor die Bestätigung zu dem No- Hands-Treiber übertragen wird. Das Aufrufen der Ereignishandhaberroutine gemäß der Ausführungsform gewährleistet die korrekte Synchronisierung, weil die Bestätigung nur dann zu dem No-Hands-Treiber übertragen wird, nachdem sämtliche anhängigen Ereignisse aus der Klientenwarteschlange entfernt worden sind.

Dritte Ausführungsform von XNextEvent:

Fig. 9 bis 13 zeigen Flussdiagramme zur Erläuterung einer dritten Ausführungsform der XNextEvent-Routine. Die dritte Ausführungsform erweitert im Wesentlichen die zweite Ausführungsform der XNextEvent-Routine durch Verarbeiten von Work- Procs (auch als Leerlaufrückrufe bezeichnet), bevor eine Bestätigung zu dem No-Hands-Treiber 223 zurück übertragen wird. Leerlaufrückrufe sind Routinen, die immer dann aufgerufen werden, wenn in der Klientenwarteschlange 235 keine Ereignisse vorliegen. Leerlaufrückrufe setzen Entwickler in die Lage, Aufgaben im Hintergrund durchzuführen und die Anzeige zu aktualisieren.
Im Schritt 901 prüft XNextEvent die Klientenwarteschlange 235, um zu ermitteln, ob sie aktuell ein Ereignis speichert, das auf eine Verarbeitung wartet. Wenn die Klientenwarteschlange leer ist, prüft XNextEvent im Schritt 903 den Mitteilungspuffer 237, um zu ermitteln, ob eine Mitteilung von dem No-Hands-Treiber 223 empfangen wurde. Wenn XNextEvent eine Mitteilung von dem No-Hands-Treiber empfangen hat, verarbeitet XNextEvent im Schritt 905 die Mitteilung. Die Mitteilung initialisiert eine Verarbeitung in dem System 200, das ein simuliertes Ereignis in die Anzeigeserverwarteschlange 233 injiziert (Schritt 907). In der bevorzugten Ausführungsform erfolgt dies durch die XESimulateXEventRequest-Routine. Nachdem das Ereignis in die Anzeigeserverwarteschlange injiziert wurde, ruft XNextEvent eine zweite Ausführungsform der NhPending-Routine im Schritt 909 auf.
Fig. 10 zeigt ein Flussdiagramm der zweiten Ausführungsform der NhPending-Routine. Die NhPending-Routine registriert einen Ereignishandhaber, wenn Ereignisse aktuell in der Klientenwarteschlange gespeichert sind. Die NhPending-Routine registriert einen Leerlaufrückrufhandhaber, wenn aktuell in der Klientenwarteschlange keine Ereignisse gespeichert sind. Im Schritt 1001 überführt NhPending Ereignisse aus der Anzeigeserverwarteschlange 233 in die Klientenwarteschlange 235. Im Schritt 1003 prüft NhPending, ob die Klientenwarteschlange 235 aktuell ein Ereignis speichert, das auf eine Verarbeitung wartet. Wenn die Klientenwarteschlange 235 kein Ereignis speichert, das auf eine Verarbeitung wartet, registriert NhPending im Schritt 1005 eine Ereignishandhaberroutine. Wenn ein Entwickler einen Ereignishandhaber für ein gewähltes Ereignis registriert, ruft der Kundencode den Ereignishandhaber immer dann auf, wenn das Ereignis verarbeitet wird. Der Ereignishandhabermechanismus prüft den Status der Verarbeitung von Ereignissen, um zu ermitteln, ob das GUI-Programm 217 bereit ist, eine neue Mitteilung von dem No-Hands-Treiber zu verarbeiten. Nachdem der Ereignishandhaber registriert ist, kehrt NhPending zu XNextEvent zurück (Schritt 1007).
Wenn unter erneutem Bezug auf die Diskussion von Schritt 1003 die Klientenwarteschlange 235 aktuell keine Ereignisse speichert, die auf Verarbeitung warten, registriert die NhPending-Routine im Schritt 1009 einen Leerlaufrückrufhandhaber. Wie nachfolgend näher erläutert, ermittelt der Rückrufhandhaber, ob Leerlaufrückrufe, die im voraus verarbeitet worden sind, neue Ereignisse erzeugen, die ebenfalls verarbeitet werden müssen, bevor eine Bestätigung zu dem No-Hands-Treiber 223 übertragen wird. Wenn beispielsweise die Leerlaufrückrufe Ereignisse erzeugt haben, die Anzeigeaktualisierungen erfordern, sollten sie typischerweise verarbeitet werden, bevor eine Bestätigung zu dem No-Hands-Treiber 223 rückübertragen wird. Nach dem Registrieren des Leerlaufrückrufhandhabers kehrt die NhPending-Routine zur XNextEvent-Routine zurück (Schritt 1007).
Unter erneuter Diskussion der XNextEvent-Routine kehrt der Prozessablauf mit dem Schritt 901 nach dem Rückkehren von dem NhPending-Aufruf zurück. Wenn im Schritt 901 XNextEvent ermittelt, dass die Klientenwarteschlange 235 aktuell Ereignisse speichert, die auf eine Verarbeitung warten (beispielsweise Ereignisse, die aus der Anzeigeserverwarteschlange zu der Klientenwarteschlange im NhPending-Aufruf bewegt wurden), wird das nächste Ereignis in der Klientenwarteschlange im Schritt 911 rückgewonnen. Im Schritt 913 ermittelt XNextEvent, ob ein Ereignishandhaber für das Ereignis registriert ist, das aus der Klientenwarteschlange 235 rückgewonnen wurde. Wenn ein Ereignishandhaber registriert ist, wird er im Schritt 915 aufgerufen.
Fig. 11 zeigt ein Flussdiagramm einer zweiten Ausführungsform der Ereignishandhaberroutine. Im Schritt 1101 überträgt der Ereignishandhaber Ereignisse aus der Anzeigeserverwarteschlange 233 zu der Klientenwarteschlange 235. Im Schritt 1103 prüft die Ereignishandhaberroutine die Klientenwarteschlange, ob zu ermitteln, ob irgendwelche Ereignisse, die auf eine Verarbeitung warten, in der Klientenwarteschlange aktuell gespeichert sind. Wenn die Klientenwarteschlange aktuelle Ereignisse speichert, die auf eine Verarbeitung warten, kehrt die Ereignishandhaberroutine im Schritt 1109 zu XNextEvent zurück und die Ereignisse werden verarbeitet, wenn XNextEvent zu der Ereignisschleife von Fig. 3 zurückkehrt.
Wenn die Klientenwarteschlange leer ist, wird jedoch der Ereignishandhaber im Schritt 1105 aufgehoben, weil sämtliche der Ereignisse aus der Klientenwarteschlange entfernt wurden. Im Schritt 1107 wird ein Leerlaufrückrufhandhaber registriert. Wie nachfolgend im Einzelnen hervorgeht, wird der Leerlaufrückrufhandhaber aufgerufen, nachdem Leerlaufrückrufe, die im System anhängig sind, verarbeitet worden sind. Der Leerlaufrückrufhandhaber prüft die Klientenwarteschlange 235, um zu ermitteln, ob im Verlauf der Verarbeitung der Leerlaufrückrufe Ereignisse erzeugt wurden. Wenn Ereignisse erzeugt worden sind, registriert der Leerlaufrückrufhandhaber den Ereignishandhaber neu, so dass die neu erzeugten Ereignisse durch das System verarbeitet werden können, bevor eine Bestätigung zu dem No-Hands-Treiber 223 übertragen wird.
Nachdem der Leerlaufrückrufhandhaber registriert worden ist, kehrt die Ereignishandhaberroutine im Schritt 1009 zu XNextEvent zurück und das unmittelbar zurückliegende Ereignis, das aus der Klientenwarteschlange gezogen wurde (im Schritt 911), wird verarbeitet, wenn XNextEvent zu der Ereignisschleife von Fig. 3 zurückkehrt. Der Schritt 1009 wird verarbeitet, wenn die Mitteilung von dem No-Hands-Treiber einen Leerlaufrückruf erzeugt, jedoch kein Ereignis erzeugt.
Die Diskussion von Fig. 9 hat bis zu diesem Punkt die bevorzugten Schritte verdeutlicht, die unternommen werden, wenn Mitteilungen von dem No-Hands-Treiber 223 empfangen worden sind, oder wenn die Klientenwarteschlange 235 aktuell Ereignisse speichert, die auf eine Verarbeitung warten. Die Schritte 919, 921 und 923 zeigen die bevorzugten Schritte, die unternommen werden, wenn sämtliche Ereignisse aus der Klientenwarteschlange 235 verarbeitet worden sind, und wenn XNextEvent keine Mitteilungen mehr von dem No-Hands-Treiber enthält, die verarbeitet werden müssen. Im Schritt 919 untersucht XNextEvent die Leerlaufrückrufwarteschlange 243, um zu ermitteln, ob irgendwelche Rückrufe auf Verarbeitung warten. Zumindest der Leerlaufrückrufhandhaber ist vom ersten Zeitpunkt durch diesen Teil der Routine anhängig, da er durch den Ereignishandhaber vorausgehend registriert wurde. Wenn Leerlaufrückrufe anhängig sind, wird im Schritt 921 eine Routine zur Verarbeitung von Leerlaufrückrufen (Process Idle Callbacks-Routine) aufgerufen.
Fig. 12 zeigt die bevorzugten Schritte, die durch die Prozessleerlaufrückrufroutine durchgeführt werden. Im Schritt 1201 gewinnt die Routine jeden Leerlaufrückruf rück, der auf eine Verarbeitung wartet, mit Ausnahme der Leerlaufrückrufhandhaberroutine. Im Schritt 1203 wird jeder rückgewonnene Leerlaufrückruf verarbeitet. In dieser Ausführungsform wird jeder Leerlaufrückruf zumindest ein Mal verarbeitet. Jeder Leerlaufrückruf wird nicht notwendigerweise zur Beendigung verarbeitet. Nach dem Verarbeiten von jedem rückgewonnen Leerlaufrückruf kehrt die Prozessleerlaufrückrufroutine im Schritt 1205 zu XNextEvent zurück.
Beim Rückkehren von der Prozessleerlaufrückrufroutine wird der Leerlaufrückrufhandhaber im Schritt 923 aufgerufen. Fig. 13 zeigt ein Flussdiagramm der bevorzugten Schritte der Leerlaufrückrufhandhaberroutine. Im Schritt 1301 wird der Leerlaufrückrufhandhaber aufgehoben, weil sämtliche Leerlaufrückrufe im voraus rückgewonnen und in der Prozessleerlaufrückrufroutine ausgeführt wurden (Fig. 12). Da die Verarbeitung der Leerlaufrückrufe neue Ereignisse in die Anzeigeserverwarteschlange 233 injiziert haben kann, überträgt der Leerlaufrückrufhandhaber im Schritt 1303 Ereignisse aus der Anzeigeserverwarteschlange 233 zur Klientenwarteschlange 235 blitzartig. Der Leerlaufrückrufhandhaber prüft daraufhin die Klientenwarteschlange 235, um zu ermitteln, ob die Warteschlange aktuell Ereignisse speichert, die auf eine Verarbeitung warten. Wenn die Klientenwarteschlange keine Ereignisse speichert, die auf eine Verarbeitung warten, wird eine Bestätigung zu dem No-Hands-Treiber 223 übertragen. Die Bestätigung zeigt an, dass das GUI-Programm 217 bereit ist, eine neue Mitteilung von dem No-Hands-Treiber zu Verarbeiten, weil sämtliche Ereignisse, die aus der vorausgehenden Mitteilung von dem No-Hands-Treiber hervorgebracht worden sind sowie sämtliche Ereignisse, die aus der Verarbeitung von Leerlaufrückrufen hervorgebracht worden sind, zu Ende verarbeitet wurden. Nachdem die Bestätigung übertragen wurde, kehrt der Leerlaufrückrufhandhaber zur XNextEvent zurück, wo XNextEvent damit beginnt, sämtliche neuen Mitteilungen von dem No-Hands- Treiber zu verarbeiten.
Wenn die Prüfung der Klientenwarteschlange im Schritt 1305 anzeigt, dass neue Ereignisse hervorgebracht wurden, während die Leerlaufrückrufe verarbeitet werden, wird die Ereignishandhaberroutine im Schritt 1311 erneut registriert. Wenn der Leerlaufrückrufhandhaber im Schritt 1309 zur XNextEvent zurückkehrt, werden erneut erzeugte Ereignisse verarbeitet, wie vorstehend erläutert.

Vorteile der bevorzugten Ausführungsformen

Die Ausführungsformen erbringen zahlreiche Vorteile im Vergleich zu Verfahren gemäß dem Stand der Technik zum Synchronisieren von Ereignishandhabungen. Beispielsweise können sie in Verbindung mit Systemen zum Teiltesten des Leistungsvermögens des Softwareprodukts eingesetzt werden. Außerdem erlauben sie, dass Testscripts ihre Verarbeitung rascher zu Ende bringen als in dem Fall, wenn die Testscripts zu Ende gehen, wenn sie in Verbindung gemäß dem Stand der Technik ausgeführt werden.

Beschränkungen der bevorzugten Ausführungsformen

Ein Problem tritt bei den zweiten und dritten Ausführungsformen von XNextEvent auf, wenn das in der Klientenwarteschlange 235 als letztes gespeicherte Ereignis neue Ereignisse hervorbringt, während es verarbeitet wird. Kurz gesagt, übertragen die zweiten und dritten Ausführungsformen eine Bestätigung zu dem No-Hands-Treiber, bevor die Ereignisse verarbeitet werden, die hervorgebracht werden, während das letzte Ereignis in de Klientenwarteschlange verarbeitet wird.
Die beste Lösung, die den Erfindern der vorliegenden Anmeldung zum Zeitpunkt der Einreichung dieser Patentanmeldung bekannt war, besteht darin, ein Synchronisierungsereignis in den Ereignisstrom einzuführen. Dieses SyncEvent wird durch den Klienten unter keinen Umständen entdeckt, weil es durch die eingeschobene Version von XNextEvent außer Betracht bleibt. Durch Übertragen eines SyncEvent werden sämtliche während der Verarbeitung des letzten Ereignisses hervorgebrachten Ereignisse verarbeitet, bevor die Bestätigung übertragen wird.
Fig. 14 zeigt ein Flussdiagramm einer vierten Ausführungsform der XNextEvent-Routine. Fig. 14 ist ähnlich zu Fig. 6 mit der Ausnahme des zusätzlichen Schritts 1414. Der Schritt 1414 führt eine Prüfung durch, um zu ermitteln, ob das allerletzte Ereignis, das aus der Klientenwarteschlange gezogen wurde, ein SyncEvent ist. Wenn dies der Fall ist, schreitet die Prozessschleife zurück zum Schritt 1401. Der Effekt dieses zusätzlichen Schritts besteht darin, dass die Verarbeitung sämtlicher SyncEvents durch den Klienten unterbunden werden.
Fig. 15 zeigt eine modifizierte Version der Event-Handler- Routine. Wenn in Fig. 8 die Klientenwarteschlange leer ist, wird eine Bestätigung unmittelbar zu dem Treiber übertragen.
Dies ist mit der Beschränkung verbunden, dass sämtliche Ereignisse, die während der Verarbeitung des letzten Ereignisses hervorgebracht wurden, nicht verarbeitet werden, bevor die Bestätigung übertragen wurde.
Wenn in Fig. 15 in der Warteschlange 1503 keine Ereignisse verbleiben, wird im Schritt 1508 SyncEvent erzeugt. Dies unterscheidet sich von Fig. 8 dadurch, dass eine Bestätigung zu diesem Zeitpunkt übertragen wurde. Während der folgenden XNextEvent-Schleife wird SyncEvent aus der Warteschlange gelesen und zu dem Event-Handler geleitet. Wenn keine zusätzlichen Ereignisse während des Verarbeitungsschritts hervorgebracht wurden, liegen in der Warteschlage 1503 keine anderen Ereignisse (andere als SyncEvent) vor. Wenn der Event-Handler das SyncEvent 1504 aus der Klientenwarteschlange rückgewinnt, wird eine Bestätigung zu dem Treiber 1505 übertragen. Wenn zusätzliche Ereignisse während des Verarbeitungsschritts hervorgebracht wurden, zeigt der Schritt 1503 an, dass keine zusätzlichen Ereignisse (andere als SyncEvent) in der Warteschlange vorliegen. Keine Bestätigung wird übertragen, bis diese zusätzlichen Ereignisse verarbeitet worden sind.

Modifikationen

Während die vorstehend erläuterten Ausführungsformen die XNextEvent-Routine aus dem X-Window-System überlasten, erkennt der Fachmann, dass andere Routinen in dem X-Windows- System ebenfalls überlastet sein können. Beispielsweise können die folgenden Routinen stattdessen überlastet sein: QLength, XAllowEvents, XCheckIfEvent, XCheckMaskEvent, XChecktyped-event, IfEvent, XCheckMaskEvent, XCheckTyped- Event, XCheckTypedWindowEvent, XCheckWindowEvent, XEvents- Queued, XGetInputFocus, XGetMotionEvents, XIfEvent, XMaskEvent, XPeekEvent, XPeekIfEvent, XPending, XPutBackEvent, XSelectInput, XSendEvent, XSetInputFocus, XSynchronize, XWindowEvent. Dem Fachmann auf diesem Gebiet erschließt sich, dass die Routinen in anderen Fenstersystemen ebenfalls überlastet sein können.

Claims

1. Verfahren zur Ausführung auf einem Computersystem (200) zum Synchronisieren der Ausführung von Ereignissen, die erzeugt werden, während ein Softwaremodul mit einem Grafiknutzerschnittstellen- (nachfolgend als GUI bezeichnet) Abschnitt (217) getestet wird, wobei das Verfahren die Schritte aufweist:

Empfangen eines ersten Ereignisses, das mit dem GUI- Abschnitt des getesteten Softwaremoduls verbunden ist;

Verarbeiten des mit dem GUI-Abschnitt verbundenen ersten Ereignisses;

und dadurch gekennzeichnet, dass das Verfahren außerdem die Schritte aufweist:

Verfolgen von zumindest einem Ereignis, das als Ergebnis der Verarbeitung des ersten Ereignisses hervorgebracht ist und Prüfen (503) eines Puffers (235) zum Ermitteln, ob der Puffer aktuell irgendwelche Ereignisse speichert, die auf eine Verarbeitung warten;

Verarbeiten (507) des zumindest einen Ereignisses, das als Ergebnis der Verarbeitung des ersten Ereignisses hervorgebracht ist; und

bei Beendigung der Verarbeitung der verfolgten Ereignisse Gewinnen eines neuen Ereignisses, das mit dem GUI-Abschnitt verbunden ist.

2. Verfahren nach Anspruch 1, außerdem aufweisend den Schritt, darauf zu schließen, dass sämtliche verfolgten Ereignisse verarbeitet worden sind, wenn der Schritt zum Prüfen ermittelt, dass der Puffer (235) aktuell keinerlei Ereignisse speichert, die auf eine Verarbeitung warten.

3. Verfahren nach Anspruch 1, außerdem aufweisend die Schritte:

Übertragen (801) von Ereignissen, die auf eine Verarbeitung warten, in den Speicher;

Inspizieren (803) des Puffers zum Ermitteln, ob der Puffer aktuell Ereignisse speichert; und

Rückstellen (807) eines Ereignishandhabungsmechanismus, wenn die Inspektion ermittelt, dass der Puffer aktuell keine Ereignisse speichert.

4. Verfahren nach Anspruch 1, außerdem aufweisend die Schritte:

Verarbeiten (921) von einem oder mehreren Leerlaufrückrufen; und

Verfolgen von zumindest einem Ereignis, das durch die Verarbeitung von einem oder mehreren Leerlaufrückrufen hervorgebracht ist.

5. Verfahren nach Anspruch 4, wobei der Schritt zum Prüfen (901) erfolgt, nachdem die Leerlaufrückrufe verarbeitet worden sind.

6. Verfahren nach Anspruch 1, außerdem aufweisend die Schritte:

Verarbeiten (921) von einem oder mehreren Leerlaufrückrufen; und

Verarbeiten von zumindest einem Ereignis, das durch die Verarbeitung von einem oder mehreren Leerlaufrückrufen hervorgebracht ist.

7. Verfahren nach Anspruch 1 unter Verwendung eines Computers (200) mit einer Grafiknutzerschnittstelle (209), einem Prozessor (211) und einem Speicher (213) zum Speichern eines GUI-Programms (217) und einer Testmaschine (219), wobei der Prozessor so konfiguriert ist, dass er das GUI-Programm und die Testmaschine ausführt, wobei der GUI-Abschnitt des Softwaremoduls das GUI-Programm (217) umfasst, wobei der Speicher außerdem eine Anzeigeserverwarteschlange (233) aufweist, die durch das GUI-Programm und die Testmaschine geteilt werden; aufweisend

den Schritt, ein erstes Ereignis zu empfangen, das die Anzeigeserverwarteschlange enthält, die ein Testereignis aufnimmt, und gefolgt von dem Schritt, eine Synchronisationsroutine in der Testmaschine auszuführen;

den Schritt, das erste Ereignis zu verarbeiten, das die Verarbeitung des Testereignisses in der Anzeigeserverwarteschlange auf dem GUI enthält, und empfangen von Ergebnissen von der Testereignisverarbeitung als Eingänge in das GUI-Programm; und

wobei das Verfahren nach dem Schritt, ein neues Testereignis zu gewinnen, den Schritt umfasst, die Beendigung der Verarbeitung der Ereignisse zu bestätigen, die bei Rückkehr der Ausführung der Synchronisationsroutine verfolgt werden.

8. Verfahren nach Anspruch 7, wobei das GUI-Programm außerdem eine Ereigniswarteschlange (235) umfasst,

wobei der Schritt zum Ausführen einer Synchronisationsroutine außerdem die Schritte umfasst:

Übertragen des Testereignisses aus der Anzeigeserverwarteschlange; und Aufrufen einer Ereignishandhabungsroutine (507) in dem GUI-Programm, ansprechend auf das übertragene Testereignis in der Ereigniswarteschlange, wobei der Schritt zum Verarbeiten des Testereignisses außerdem das Verarbeiten des Testereignisses mit der Ereignishandhabungsroutine umfasst.

9. Verfahren nach Anspruch 7 oder 8, außerdem aufweisend die Schritte:

Erzeugen weiterer Testereignisse in dem GUI-Programm;

Bereitstellen der weiteren Testereignisse für die Anzeigeserverwarteschlange; und

iteratives Verarbeiten von jedem weiteren Testereignis in der Anzeigeserverwarteschlange auf der GUI und Empfangen der Ergebnisse von jedem weiteren Testereignis unter Verarbeitung als Eingänge in das GUI-Programm, während weitere Testereignisse in der Anzeigeserverwarteschlange verbleiben.

10. Verfahren nach einem der Ansprüche 7 bis 9, wobei der Schritt zum Verarbeiten des Testereignisses außerdem den Schritt umfasst, eine Nutzereingabeaktion mit der Testmaschine auf der GUI zu simulieren.

11. Verfahren nach einem der Ansprüche 7 bis 10, wobei die Testmaschine außerdem einen Interpretierer (224), ein Treiberprogramm (223) und eine Reihe von Testskriptbefehlen (221) zum Aufrufen Von Routinen in der Testmaschine umfasst, die eine Nutzeraktion auf der GUI simuliert, wobei das Verfahren außerdem die Schritte aufweist:

Rückgewinnen eines derartigen Testskriptbefehls aus dem Testskript, das mit der Testmaschine gespeichert ist;

Interpretieren des Testskriptbefehls mit dem Interpretierer; und

Senden eines Ausgangs von dem Interpretierer für den Testskriptbefehl zu dem GUI-Programm über das Treiberprogramm.

12. Verfahren, das in einem Computersystem (200) zum Synchronisieren der Ausführung Von Ereignissen ausführbar ist, die erzeugt werden, während ein Softwaremodul getestet wird, aufweisend einen Grafiknutzerschnittstellen- (nachfolgend als GUI bezeichnet) Abschnitt (217), wobei das Verfahren aufweist:

Bereitstellen eines ersten Programmmechanismus, der ein erstes Ereignis empfängt, das mit dem GUI- Abschnitt des getesteten Softwaremoduls verbunden ist;

Bereitstellen eines zweiten Programmmechanismus, der das erste Ereignis verarbeitet, das mit dem GUI- Abschnitt verbundenen des Softwaremoduls verbunden ist;

und dadurch gekennzeichnet, dass das Verfahren außerdem aufweist:

Bereitstellen eines dritten Programmmechanismus, der zumindest ein Ereignis verfolgt, das als Ergebnis der Verarbeitung des ersten Ereignisses hervorgebracht ist und Breitstellen eines sechsten Programmmechanismus, der einen Puffers (235) prüft (503), um zu ermitteln, ob der Puffer aktuell irgendwelche auf eine Verarbeitung wartende Ereignisse speichert;

Bereitstellen eines vierten Programmmechanismus, der zumindest ein Ereignis verarbeitet (507), das durch die Verarbeitung des ersten Ereignisses hervorgebracht ist; und

Breitstellen eines fünften Programmmechanismus, der ein neues Ereignis gewinnt, das mit dem GUI-Abschitt verbunden ist, wenn die Verarbeitung des zumindest einen verfolgten Ereignisses beendet ist.

13. Verfahren nach Anspruch 12, wobei der fünfte Programmmechanismus schließt, dass sämtliche verfolgten Ereignisse verarbeitet worden sind, wenn der sechste Programmmechanismus ermittelt, dass der Puffer (235) aktuell keinerlei auf Verarbeitung wartende Ereignisse speichert.

14. Verfahren nach Anspruch 12 oder 13, wobei der fünfte Programmmechanismus

auf eine Verarbeitung wartende Ereignisse in den Puffer überträgt (801);

den Puffer inspiziert (803), um zu ermitteln, ob der Puffer aktuell Ereignisse speichert; und

einen Ereignishandhabungsmechanismus rücksetzt (807), wenn die Inspektion ermittelt, dass der Puffer aktuell keine Ereignisse speichert.

15. Verfahren nach einem der Ansprüche 12 bis 14, außerdem aufweisend:

Bereitstellen eines siebten Programmmechanismus, der einen oder mehrere Leerlaufrückrufe verarbeitet (921); und

Bereitstellen eines achten Programmmechanismus, der zumindest ein Ereignis verfolgt, das durch die Verarbeitung des einen oder der mehreren Leerlaufrückrufe hervorgebracht ist.

16. Verfahren nach Anspruch 15, wobei der achte Programmmechanismus einen Puffers prüft (1305), um zu ermitteln, ob irgendein Ereignis in dem Puffer gespeichert ist, nachdem die Leerlaufrückrufe verarbeitet worden sind.

17. Computersystem (200) zum Synchronisieren der Ausführung von Ereignissen, die während des Testens eines Softwaremoduls erzeugt werden, das einen Grafiknutzerschnittstellen- (nachfolgend als GUI bezeichnet) Abschnitt (217) umfasst, wobei das Computersystem aufweist:

Einen ersten Programmmechanismus, der ein erstes Ereignis empfängt, das mit dem GUI-Abschnitt des getesteten Softwaremoduls verbunden ist;

einen zweiten Programmmechanismus, der das erste Ereignis verarbeitet, das mit dem GUI-Abschnitt des Softwaremoduls verbunden ist;

und dadurch gekennzeichnet, dass das System außerdem aufweist:

Einen dritten Programmmechanismus, der zumindest ein Ereignis verfolgt, das als Ergebnis der Verarbeitung des ersten Ereignisses hervorrufen ist, und einen sechsten Programmmechanismus, der einen Puffer (235) prüft (503), um zu ermitteln, ob der Puffer aktuell irgendwelche Ereignisse speichert, die auf eine Verarbeitung warten;

einen vierten Programmmechanismus, der zumindest ein Ereignis verarbeitet (507), das als Ergebnis der Verarbeitung des ersten Ereignisses hervorgebracht ist; und

einen fünften Programmmechanismus, der ein neues Ereignis gewinnt, das mit dem GUI-Abschnitt verbunden ist, wenn die Verarbeitung des zumindest einen verfolgten Ereignisses beendet ist.

18. System nach Anspruch 17, wobei der fünfte Programmmechanismus schließt, dass sämtliche verfolgten Ereignisse verarbeitet worden sind, wenn der sechste Programmmechanismus ermittelt, dass der Puffer (235) aktuell keinerlei auf eine Verarbeitung wartende Ereignisse speichert.

19. System nach Anspruch 17 oder 18, wobei der fünfte Programmmechanismus

auf eine Verarbeitung wartende Ereignisse in den Puffer überträgt (801);

20. System nach einem der Ansprüche 17 bis 19, außerdem aufweisend:

Einen siebten Programmmechanismus zum Verarbeiten (921) von einem oder mehreren Leerlaufrückrufen; und

einen achten Programmmechanismus, der zumindest ein Ereignis verfolgt, das durch die Verarbeitung des einen oder der mehreren Leerlaufrückrufe hervorgebracht ist.

21. System nach Anspruch 20, wobei der achte Programmmechanismus einen Puffers prüft (1305), um zu ermitteln, ob in dem Puffer irgendwelche Ereignisse gespeichert sind, nachdem die Leerlaufrückrufe verarbeitet worden sind.

22. System zum Synchronisieren der Ausführung von Testereignissen nach Anspruch 17, wobei das System aufweist:

Eine grafisch Nutzerschnittstelle (209);

einen Speicher (213) zum Speichern eines GUI-Programms (217) und eine Testmaschine (219);

wobei die Testmaschine ein derartiges Testereignis einer Anzeigeserverwarteschlange (233) bereit stellt, die durch das GUI-Programm und die Testmaschine geteilt ist;

wobei das GUI-Programm eine Ereigniswarteschlange (235) aufweist;

einen Prozessor (211), der mit der GUI und dem Speicher verbunden ist und das Testereignis in der Anzeigeserverwarteschlange auf der GUT verarbeitet;

wobei der Prozessor zumindest ein weiteres Testereignis verfolgt, das als Ergebnis der Verarbeitung des Testereignisses hervorgebracht ist, einschließlich das Prüfen der Ereigniswarteschlange (235), um zu ermitteln, ob die Ereigniswarteschlange aktuell irgendwelche weiteren auf eine Verarbeitung wartende Testereignisse speichert, und das Verarbeiten (507) des zumindest einen weiteren Testereignisses, das als Ergebnis der Verarbeitung des Testereignisses hervorgebracht ist;

wobei bei Beendigung der Verarbeitung des zumindest einen weiteren Testereignisses der Prozessor ein neues Testereignis gewinnt, das mit dem GUI-Programm verbunden ist.

23. System nach Anspruch 22, wobei die Testmaschine eine Synchronisationsroutine ausführt, nachdem das Testereignis der Anzeigeserverwarteschlange bereit gestellt ist, wobei das GUI-Programm Ergebnisse von der Testereignisverarbeitung als Eingänge empfängt, wobei das System außerdem einen Monitor aufweist, der die Verarbeitung des Testereignisses überwacht; und

wobei die Testmaschine die Beendigung der Verarbeitung des Testereignisses bei Rückkehr der Ausführung der Synchronisationsroutine ansprechend auf den Monitor bestätigt.

24. System nach Anspruch 22 oder 23, wobei die Testmaschine außerdem so konfiguriert ist, dass sie das Testergebnis von der Anzeigeserverwarteschlange zu der Ereigniswarteschlange überträgt und eine Ereignishandhabungsroutine in dem GUI-Programm ansprechend auf das übertragene Testereignis aufruft, wobei der Prozessor das Testereignis mit der Ereignishandhabungsroutine verarbeitet.

25. System nach einem der Ansprüche 22 bis 24, wobei das GUI-Programm außerdem aufweist:

Einen Generator (225) zum Erzeugen weiterer Testereignisse; und

einen Kanal, der die weiteren Testereignisse der Anzeigeserverwarteschlange bereit stellt, wobei der Prozessor außerdem iterativ jedes weitere Testereignis in der Anzeigeserverwarteschlange auf der GUI verarbeitet; und

wobei die Ergebnisse von jeder weiteren Ereignisverarbeitung als Eingänge in das GUI-Programm empfangen werden, während weitere Testereignisse in der Anzeigeserverwarteschlange verbleiben.

25. System nach einem der Ansprüche 22 bis 25, wobei die Testmaschine außerdem einen Interpretierer (224), ein Treiberprogramm (223) und eine Reihe von Testskriptbefehlen (221) umfasst, um Routinen in der Testmaschine aufzurufen, die eine Aktion auf der GUI simulieren, wobei die Testmaschine diese Testskriptbefehle aus einem Testskript (221) rückgewinnt, die mit der Testmaschine gespeichert sind, wobei der Interpretierer den Testskriptbefehl interpretiert und wobei das Treiberprogramm den Ausgang von dem Interpretierer für den Testskriptbefehl zu dem GUI-Programm sendet.