Schlüsselwortgetriebenes Testen bedeutet, lesbare Tests modular zu erstellen. Tests bestehen aus wiederkehrenden abstrakten Aktionen (Klicken, Selektieren, Überprüfen) und aus fachlichen Sequenzen solcher Aktionen (Einloggen, Anlegen / Löschen usw.), die jeweils als Schlüsselwörter abgebildet werden. So erreicht man durch Wiederverwendung eine große Testabdeckung. Auch der Wartungsaufwand ist gering, denn zentrale Veränderungen aktualisieren alle referenzierten Schlüsselwörter. Im schlüsselwortgetriebenen Ansatz wird Wert auf die Teststruktur und das Testdesign gelegt.

Nach der Identifizierung der Schlüsselwörter kann mit der Implementierung begonnen werden. Hier bietet GUIdancer / Jubula einen besonderen Vorteil: Die Implementierung erfolgt ohne Programmieraufwand. Somit spart man Zeit und Ressourcen und die gesamte Kontrolle über die Tests bleibt bei den fachlichen Testern. Schlüsselwörter können nun kombiniert werden um Tests zu erstellen. Sollte man erst im Nachhinein feststellen, dass ein Schlüsselwort sinnvoll ist, gibt es eine "Refactor" Funktion.

Zusammen mit GUIdancer / Jubula wird eine Schlüsselwort-Bibliothek installiert. Diese beschleunigt die Testfallerstellung und erleichtert die Orientierung.

Viele Werkzeuge erzeugen Programmcode, der als Basis für den automatisierten Test dient (z.B. Capture-Replay Tools). Andere Werkzeuge setzen voraus, dass Code geschrieben wird, um den Test auszuführen (beispielsweise viele schlüsselwortgetriebene Tools). Wenn Tests allerdings in Programmcode vorliegen, braucht man viel Zeit und Ressourcen für das Modularisieren und Parametrisieren der Tests oder/aber um neue high-level Aktionen zu programmieren. Der Code für die Testautomatisierung wird schnell unübersichtlich und muss selbst gepflegt und sogar getestet werden! Der Testfortschritt ist klein und viele Projekte gehen eben wegen des unerwarteten Aufwands zugrunde.

Testautomatisierung anhand von Programmcode ist sehr zeitintensiv. Die auszuführenden Aktionen müssen plattform- und anwendungsunabhängig sein. Zudem müssen sie high-level sein, damit ein Test aus mehr als einer Reihe an einfachen Klicks besteht. Es müssen Gedanken gemacht werden, wie ein Testframework für Testausführung aussehen soll, einschließlich Synchronisation, Fehlerbehandlung und Testergebnisse.

Als GUIdancer oder Jubula Tester bleibt einem diese Arbeit erspart. Wir haben uns die Zeit genommen, um den notwendigen Code zu entwerfen, erstellen, pflegen und testen. So stellen wir high-level Aktionen zur Verfügung, die plattform-, anwendung- und toolkitunabhängig sind. Außerdem sind unsere Aktionen leicht verständlich und einfach zu verwenden. Sie enthalten schon interne Synchronisation, Fehlerbehandlung und Ergebniskommunikation.

Das Ergebnis: Testautomatisierung mit GUIdancer oder Jubula ist erstaunlich produktiv. Es wird keine Zeit verschwendet - kein Code wird für die Testausführung gebraucht. Neben dem Zeitgewinn hat man den Vorteil, dass Tests aus der Benutzerperspektive (als Black-Box Test) geschrieben werden können. Alle nötige Aktionen sind von uns vorgefertigt und mitgeliefert in einer Bibliothek. Testerstellung erfolgt per Drag'n'Drop.

Die Vorteile unseres Ansatzes:

• Durchgehend hohe Produktivität
• Tester sind unabhängig von der Verfügbarkeit und vom Input sog. Automation Experts oder Engineers
• Einfache Testerstellung und -wartung
• Lesbare Tests

Wenn Sie doch Unterstützung für Ihre eigenen Komponenten hinzufügen wollen, können Sie diese über unsere Erweiterungsschnittstelle realisieren.

GUIdancer und Jubula haben zwar einen Beobachtungsmodus, aber wir bezeichnen uns nicht als Capture-Replay Tool, weil Tests auch anhand unserer Testfallbibliothek per Drag-and-Drop erstellt werden können. GUIdancer und Jubula haben verschiedene Vorteile gegenüber reinen Capture-Replay Werkzeugen:

• Sie können noch vor der Verfügbarkeit einer zu testenden Anwendung mit der Testerstellung anfangen. Tests sind dann lauffähig, wenn eine Anwendung bereit ist. So finden Sie frühzeitig Fehler in der Software, wenn die Behebungskosten noch gering sind.
• Tests sind von Anfang an modular und strukturiert. Es ist kein Programmieraufwand nötig, um Tests zu schreiben oder zu pflegen. Sogar der Beobachtungsmodus erzeugt lesbare Testschritte, die sich einfach zu wiederverwendbaren Modulen kombinieren lassen.
• Unsere Aktionen sind abstrakt und sinnvoll konzipiert. Somit enthalten Tests keine unnötigen Implementierungsdetails und keine Redundanzen. Ähnliche Aktionen lassen sich häufig mit dem gleichen Schlüsselwort testen. So bleiben Ihre Tests wartbar und flexibel.
• Wenn Sie unabhängig von der zu testenden Anwendung schon mit der Testerstellung anfangen, testen Sie gegen die Anforderungen statt gegen die Implementierung.

Ja, wir automatisieren unsere GUIdancer Funktionstests sowie die Tests für unsere Aktionen mit GUIdancer selbst.

Unsere Hauptstärke liegt in unserem einfachen aber machtvollen Wiederverwendungskonzept. Wir glauben, dass Tests die gleichen Best Practices wie ein Softwareprojekt einsetzen sollten, und zwar ohne Programmieraufwand. Die Erstellung wiederverwendbarer Bausteine ist daher der Schlüssel zu einer erfolgreichen Testautomatisierung.

Wir bezeichnen uns als funktionales GUI-Test Tool. Das heißt, Sie können Ihre Business-Regeln, sowie Reihenfolgeabhängigkeiten, Oberflächenszenarien wie Aktivieren von Buttons/Textfeldern, Eingaben und Ergebnisse usw., über die Oberfläche prüfen. Es werden keine Lasttests durchgeführt.

Nach der Installation laufen Ihre ersten Tests innerhalb kürzester Zeit. Sogar am ersten Tag werden Sie Tests für Ihre Anwendung erstellen können, die ein immer wachsendes Sicherhetsnetz bilden. Sie müssen keine Zeit für die Programmierung von Aktionen oder Funktionen verwenden, da eine vorgefertigte Bibliothek an Aktionen mit GUIdancer / Jubula ausgeliefert wird. Dank der Modularität und der Struktur eines GUIdancer / Jubula Tests bleibt der Test-Fortschritt auch nach Veränderungen an der zu testenden Anwendung groß.

Sollten Sie beim Versuch sich mit dem AUT-Agent zu verbinden eine Fehlermeldung bekommen, überprüfen Sie bitte folgendes:

• Sie haben den AUT-Agent aus dem Start-Menü oder über die Kommandozeile gestartet.
• Sie haben die AUT-Agent Hostname und Portnummer richtig eingestellt und ausgewählt. Informationen hierzu finden Sie in den Preferences in GUIdancer.

Mit GUIdancer / Jubula können Sie Ihre Java- (Swing, SWT/RCP) und HTML-Anwendungen testen. Wir unterstützen außerdem Anwendungen, die GEF (Graphical Editing Framework) Komponenten enthalten.

Sie können Java Web Start Anwendungen starten und testen, wenn die Anwendung zuerst heruntergeladen und im Dateisystem gespeichert wird. Der Java Web Start Mechanismus selbst wird zur Zeit nicht unterstützt.

Sie können über die Systemvoraussetzungen in unserem technischen Datenblatt lesen.

Sie können über die benötigte Java-Version in unserem technischen Datenblatt lesen.

GUIdancer und Jubula werden mit der Sun JRE getestet. Die GCJ/GIJ und OpenJDK Java Runtime Environments verwenden eine nicht-standard Implementierung und werden von uns nicht unterstützt.

Wenn Sie RCP-Anwendungen testen wollen, müssen Sie den RCP Remote Control Plugin ins Pluginverzeichnis Ihrer Anwendung entzippen. Anweisungen dazu finden Sie im Handbuch.

Wenn Sie eine neue Version verwenden, müssen Sie den neuen RCP Remote Control Plugin installieren. Wir empfehlen es, Ihre Anwendung einmal mit -clean zu starten, um sicherzustellen, dass der neue Plugin eingebunden wird.

In der AUT Configuration für Ihre RCP-Anwendung müssen Sie zusätzlich ein Tastatur-Layout angeben. Geben Sie das Tastatur-Layout ein, das in Ihren Systemeigenschaften steht. Die tatsächlich angeschlossene Tastatur hat keine Auswirkung.

RCP-Anwendungen haben meistens eine configuration/config.ini Datei, die den Parameter osgi.bundles enthält. Sie müssen gegebenenfalls diesen Parameter so verändern, dass der RCP Remote Control Plugin beim Starten auch geladen wird. Das org.eclipse.update.configurator Plugin lädt automatisch alle im Plugin-Verzeichnis gefundenen Plugins. Der RCP Remote Control Plugin startet mit der AUT, wenn im osgi.bundles Parameter schon org.eclipse.update.configurator@3:start definiert ist. Ansonsten müssen Sie org.eclipse.jubula.rc.rcp ans Ende des osgi.bundles Parameter hinzufügen.

Unsere Tests basieren auf sogenannten Toolkits. Ein Toolkit ist ein GUI-Framework. Die unterstützten Toolkits sind: Swing, SWT, RCP, GEF und HTML.

Wenn Sie SWT- oder RCP-Anwendungen testen, müssen Sie ein Tastatur-Layout in der AUT Configuration angeben. Dieses teilt dem Client wichtige Informationen über Ihr System mit. Geben Sie das Tastatur-Layout ein, das in Ihren Systemeigenschaften steht. Die tatsächlich angeschlossene Tastatur hat keine Auswirkung.

Wenn Ihre Anwendung ein Tastatur-Layout verwendet, das in der Standard-Installation nicht unterstützt wird, können Sie eine Keyboard-Mapping-Datei erstellen und hinzufügen. Anweisungen zur Erstellung und zum Hinzufügen der Mapping-Datei finden Sie im Reference Manual.

Im Moment wird keine direkte Unterstützung zur Integration angeboten. Projekte können allerdings als xml-Dateien exportiert werden. Sie sind deshalb in anderen Tools einfach zu verwalten.

Sie können ebenfalls anhand eindeutiger IDs Ihre Testfälle in externen Programmen referenzieren und anhand dieser ID in Ihren Tests suchen.

In GUIdancer (die kommerzielle Version von Jubula) können Sie Testergebnisse anhand des BIRT-Engines über längere Zeit verfolgen.

Ja, wir sind kompatibel sowohl mit UTF-8 als auch mit UTF-16 Anwendungen. Das heißt, Sie können sogar japanische oder chinesische Versionen Ihrer Anwendung testen.

Es gibt keinen Testschritt, der es direkt ermöglicht, auf eine Datenbank zuzugreifen. Externe Skripte können jedoch im Test ausgeführt werden. Ergebnisse von Datenbankabfragen können außerdem in Excel-Tabellen gespeichert werden. Excel-Tabellen können wiederum als Datenquellen für Tests benutzt werden.

Wenn Sie Ihre eigenen Datenbankabfragen unterstützen wollen, können Sie dieses mithilfe einer Erweiterung realisieren.

Sie können GUIdancer oder Jubula um Ihre eigenen Komponenten und Aktionen anhand der API erweitern. Sie können Erweiterungen für Swing, SWT und RCP schreiben, allerdings nicht für HTML. Informationen zur Erweiterung finden Sie im Extension Manual. Erweiterungen werden in Java geschrieben.

Das schrittweise Ausführen von Tests ist nicht möglich. Sie können allerdings einstellen, dass der Test im Fehlerfall pausiert wird, um den genauen Fehlerzustand zu sehen.

Ja, über den Command Line Client können Sie Ihre Tests starten. Der Command Line Client wird im User Manual beschrieben.

Sie können Ihre AUT ebenfalls in einem Virtual Frame Buffer testen.

Wir haben keine direkte Unterstützung von Ant-Targets. Sie können allerdings den exec Befehl verwenden:

< exec executable="GUIdancerCMD.exe" vmlauncher="false" failonerror="false" resultproperty="testResult" />

Wir empfehlen Ihnen, ein Tool oder ein Framework zur Continuous Build Integration zu verwenden. Somit können Sie Ihre Tests ausführen lassen, und die Ergebnisse evaluieren.

Wir benutzen Hudson als Continuous Build Integration Framework. Hudson läuft auf einem Testrechner, auf dem sich eine stabile Testumgebung und Konfiguration befinden. Unsere Tests werden von hier aus ausgeführt. Wir lassen AUT Agent sowohl lokal als auch auf anderen Testrechnern laufen. Hudson:

• checkt die Quellen aus dem Repository aus,
• baut die Anwendung,
• startet die Tests, und
• liefert die Testergebnisse.

Tests für Hauptfunktionalitäten (Smoke Tests) laufen nach jedem Check-In. Größere Tests laufen jede Nacht und sehr zeitintensive Tests werden am Wochenende ausgeführt. Somit können wir eine zeitnahe Fehlererkennung sicherstellen.

Wir benötigen verschiedene Ports zur Kommunikation in zwei Richtungen:

• Richtung Client - AUT Agent: diesen Port bestimmen Sie selber in den Preferences.
• Richtung AUT - Client: dieser Port wird bei jedem AUT-Start dynamisch bestimmt und kann zur Zeit nicht vom Benutzer festgelegt werden. Deshalb müssen alle auf der Testmaschine verfügbaren Ports auch auf dem Rechner, der die Tests steuert, freigeschaltet werden.

Alternativ zur Testausführung über Rechnergrenzen hinweg, können Sie auch den Test Executor lokal auf dem Rechner starten und mit dem lokalen AUT Agent verbinden und damit wiederum mit der lokalen AUT kommunizieren lassen. So umgehen Sie das Problem nicht näher definierbare Ports freischalten zu müssen.

Sie können verschiedene AUTs während eines Tests mit einem ''Test Job'' bedienen. In einem Test Job können sich mehrere Test Suites befinden, die nacheinander ausgeführt werden. Jede Test Suite kann eine andere Anwendung bedienen.

Wir empfehlen Ihnen, sich erstmal die Welcome Page anzuschauen. Danach, rufen Sie über das Help Menü die Cheat Sheets im Integrated Test Environment auf. Somit lernen Sie die Konzepte und Funktionen kennen.

GUIdancer und Jubula sind leistungsstarke Werkzeuge und unterstützen die Wiederverwendbarkeit von Testfällen. Aus diesem Grund empfehlen wir, dass Sie sich Gedanken darüber machen, wie Ihre Test am besten strukturieren.

GUIdancer und Jubula Tests werden aus Bausteinen (Testfällen, Schlüsselwörtern, Modulen) zusammengebaut. Nach der Spezifikation eines Testfalls, kann dieser wiederverwendet werden. Der Vorteil daran ist, dass Ihre Tests eine bessere Struktur haben. Je häufiger Sie Testfälle wiederverwenden, desto wartbarer sind Ihre Tests, denn zentrale Veränderungen aktualisieren dann einen ganzen Test.

GUIdancer / Jubula unterstützt Wiederverwendbarkeit, indem er Ihnen auf verschiedene Weise anbietet, Testfälle möglichst flexibel zu halten. Je abstrakter der Testfall, desto einfacher ist es, ihn an vielen Stellen wiederzuverwenden.

Wir empfehlen Ihnen, Ihre Daten getrennt von den Testfällen zu verwalten. Benutzen Sie in Ihren Testschritten Referenzen statt fester Parameterwerten. Sie können Ihre Gesamtmenge an Testfällen reduzieren, wenn Sie die zu testende Komponente in einem Testfall verändern. Wir unterstützen außerdem abstrakte Komponenten, um die Flexibilität Ihrer Tests zu verbessern. Mit der ausgelieferten Testfallbibliothek können Sie strukturierte, wartbare Tests einfach per Drag&Drop erstellen.

Wir bieten Ihnen verschiedene Hilfsmittel für Ihren Einstieg an:

• Drücken Sie F1 in der Oberfläche, um kontext-sensitive Hilfe zu sehen
• IÜber das Help-Menü können Sie das Handbuch und das Reference Manual in einem Browser öffnen
• Sie können Community-Support für Jubula auf der Jubula Website sowie professionellen Support für Jubula und GUIdancer über die BREDEX-Seiten erwerben.
• BREDEX GmbH bietet außerdem Schulungen und Beratung zu GUIdancer und Jubula an.

Als ''abstrakt'' werden allgemeine Komponenten bezeichnet, welche die genaue Implementierung offen lassen. Im Gegensatz zu sogenannten 'konkreten' Komponenten, die auf einen Komponententyp begrenzt sind (z.B Baum, Tabelle), schließt eine abstrakte Komponente mehrere konkrete Komponenten ein, welche die gleichen Aktionen auf ähnlichen Komponenten ausführen. Die abstrakte ''Component with Text Input'' kann zum Beispiel den Text in verschiedenen Komponenten prüfen.

Die Wiederverwendbarkeit Ihrer Testfälle wird durch solche Komponenten erhöht. Ihre Allgemeinheit macht sie einfach wiederverwendbar, denn die genauen Komponenten werden erst über das Object Mapping festgelegt. Abstrakte Komponenten verleihen Ihren Tests zudem eine gewisse Wartbarkeit, da eine Veränderung des Komponententyps einfach dem ursprüglichen Komponentennamen zugeordnet werden kann. Ein Testschritt zur Dateneingabe in einem Textfeld, der mit einer 'Component with Text' spezifiziert wurde, kann später auf einer Combobox gemappt werden.

GUIdancer und Jubula verwenden viele benutzerfreundliche high-level Aktionen. Dementsprechend verlangen viele Aktionen (z.B. auf Bäume, Menüleisten, usw.) einen Pfad als Parameter, weil sich die Komponenten so besser bedienen lassen. Der Pfad ist nichts anderes als der Weg durch das Menü oder durch den Baum, um zum gewünschten Eintrag oder Blatt zu kommen. Pfade können meistens entweder über den Inhalt, oder Textpfad (z.B. File/Edit) oder über die Position der Elemente, den Indexpfad (z.B. 1/2) angegeben werden.

Wichtig bei Pfadangaben ist, dass ein Trennsymbol ('/') zwischen Elementen benutzt wird. Die Indexnummerierung beginnt immer bei ''1''.

Kontext-Menüs werden in der Regel dadurch geöffnet, dass mit der rechten Maustaste auf einer bestimmten Stelle in einer Komponente geklickt wird. Der Inhalt des Menüs hängt von dieser Stelle und dem Zustand der Anwendung ab. Genauso öffnen GUIdancer und Jubula Kontext-Menüs. Sie wählen eine Komponente aus, auf der Sie ein Menü öffnen möchten. Danach selektieren Sie eine Aktion auf dieser Komponente, um das Kontext-Menü zu öffnen. Bei den meisten Komponenten haben Sie verschiedene Möglichkeiten anzugeben, wo das Menü geöffnet werden sollte, und wie der Menüeintrag selektiert werden sollte. Diese Details werden über die Parameter der Aktion bestimmt.

Das Object Mapping erfolgt ganz normal indem Sie die Komponente aus der Anwendung einsammeln, auf der Sie das Kontext-Menü öffnen möchten (z.B. Tree, Table).

Benutzen Sie reguläre Ausdrücke für Textselektion und -prüfung, um Ihre Tests robust zu halten. Sie können, zum Beispiel:

• Menüs
• Bäume
• Reiter
• Andere Komponenten mit Text

mit regulären Ausdrücken prüfen. Mit dem ''Operator'' matches können Sie reguläre Ausdrücke im Textstring verwenden. Simple match ist eine einfache Möglichkeit, Wildcards zu benutzen. Das Sternchen (*) ersetzt ein oder mehrere Zeichen (z.B. Projekt*).

In GUIdancer und Jubula gibt es Projekte mit atomaren Testfällen, die alle unterstützen Aktionen abdecken.

Selektieren Sie den wiederzuverwendenden Testfall aus der Bibliothek und fügen Sie ihn per Drag&Drop zu Ihrem Testfall hinzu. Geben Sie Parameterwerte oder Referenzen im Properties View ein, und überschreiben Sie den Komponentennamen im Component Names View mit einem sinnvollen Namen für die zu testende Komponente.

Benutzen Sie Event Handler, um mit gelegentlichen Pop-Ups und anderen Fehlern umzugehen. Event Handler sind Testfälle, die nur im Fehlerfall aufgerufen werden. Ein Event Handler zum Schließen eines Pop-Ups (mit Alt+F4, zum Beispiel) könnte spezifiziert werden, um mit einem fehlgeschlagenen Testschritt umzugehen. Der Test kann dann weiterlaufen. Sie finden ein ''Cheat Sheet'' zum Einsetzen von Event Handlers im Help Menü in der Anwendung.

Sie können Native Elemente (z.B. Auswahldialoge zum Öffnen einer Datei) mit den Aktionen external key combination und external input text bedienen. Diese Aktionen sind unter der ''Application'' Komponente zu finden und erlauben die Eingabe von Text und das Schicken von Tastaturbefehlen an native Elemente.

Sie können auch die Aktionen Copy to clipboard und anschließend Ctrl+V (oder Mod+V für plattformunabhängige Tests) als Tastatureingabe (Komponente: ''Application'') verwenden, um Text und Dateipfade in native Dialoge einzugeben.

Ein Testfall zum Prüfen von Eigenschaften ist ein Testfall wie jeder andere. Wählen Sie die Komponente, auf der Sie eine Prüfung ausführen wollen (z.B. eine component with text). Selektieren Sie dann die auszuführende Prüfaktion (z.B. check text). Geben Sie den zu prüfenden Text als Parameter ein. Wenn Sie reguläre Ausdrücke für Stringvergleiche verwenden, werden Ihre Tests robuster.

Sie können leere Felder prüfen, indem Sie:

• Den Operator matches auswählen, und '^\s*$' oder '^$' als Parameter eingeben (einschließlich Anführungszeichen).
• Den Operator equals, matches oder simple match auswählen, und '' (zwei Anführungszeichen) als Parameter eingeben.

Mit einem Backslash können Sie einzelne Sonderzeichen aufheben. Um einen ganzen String mit verschiedenen Sonderzeichen einzugeben, verwenden Sie einfache Anführungszeichen (z.B. 'String').

Im Reference Manual finden Sie weitere Informationen über Sonderzeichen.

In einem Test ist es einfach, Bedingungen wie die folgenden zu spezifizieren:

• "Warte bis der Text Geladen in der Statuszeile erscheint"
• "Wenn die Checkbox nicht selektiert ist, dann selektiere sie"
• "Wenn diese Aktion beim ersten Versuch fehlschlägt, führe andere (oder keine) Aktionen aus und danach die zuvor fehlgeschlagene Aktion erneut." Die Anzahl an Versuchen kann konfiguriert werden.
• "Wenn diese Aktion fehlschlägt, führe eine oder mehrere Aktionen aus." Die im Fehlerfall ausgeführten Aktionen können beliebige Aktionen sein, beispielsweise einen Screenshot machen oder die Anwendung neustarten.

Die Eingabe boolescher Werte in Excel kann zu Problemen führen. Gibt man true oder false in eine Zelle ein, wird dieses automatisch in einen Excel-booleschen Wert umwandelt. Der Test kann diesen Wert zur Laufzeit nicht auslesen.

Sie müssen die Formatierung für die Spalte auf Text setzen, damit die eingegebenen Werte nicht von Excel als boolesch interpretiert werden. Somit kann der Client die Werte für die Testausführung auslesen und verwenden.

Ja, Sie können Ihre Testdaten einfach übersetzen, damit Ihre Tests in allen Anwendungssprachen laufen.

Unsere Restart Aktion beendet die AUT mittels java.lang.Runtime.exit(). Wenn Ihre Anwendung nicht richtig heruntergefahren wird oder nicht richtig wieder startet, können Sie folgendes hinzufügen: java.lang.Runtime.addShutdownHook(). Diese Zeile wird vor dem Beenden ausgeführt und kann sich um alle Details kümmern, die für das richtige Herunterfahren benötigt werden.

Es gibt ein bekanntes Problem mit einer Environment-Variablen, die von verschiedenen Werkzeugen, auch von anderen Test-Tools, gesetzt wird. Die Variable heißt ''_JAVA_OPTION'' und kann die Lauffähigkeit von GUIdancer und anderen Java-Programmen beeinträchtigen. Sie wird eventuell auch dann nicht entfernt, wenn das Programm deinstalliert wird.

Sie können sehen, ob diese Variable auf Ihrem Rechner installiert ist, indem Sie auf Ihrem Windows-Desktop mit der rechten Maustaste auf das 'Arbeitsplatz' Icon klicken und 'Eigenschaften' auswählen. Selektieren Sie dann den 'Erweitert' Reiter im erschienenen Dialog und klicken Sie auf den 'Environment-Variablen' Knopf. Sie werden dann eine Liste der Environment-Variablen sehen können. Wenn die '_JAVA_OPTION' Variable aufgelistet ist und Sie das Programm bereits deinstalliert haben, dann können Sie die Variable einfach löschen.

Nein, das GUIdancer Schema darf nur für die GUIdancer Datenbank benutzt werden. Keine Tabellen von anderen Anwendungen dürfen sich in dem für GUIdancer bereitgestellten Schema befinden.

Unser Object-Mapping unterstützt verschiedene Komponenten, z.B. Bäume, Tabellen, Comboboxen. Wenn Sie eine Komponente aus der Anwendung ''einsammeln'', sind es genau solche unterstützten Komponenten, die gemappt werden (und entsprechend mit einem grünen Rahmen versehen werden). Wenn Sie zum Beispiel einen Testschritt spezifiziert haben, der eine Aktion auf einem Baum ausführt, dann müssen Sie die (ganze) Baum-Komponente mappen.

Es gibt ein bekanntes Problem mit dem Zusammenspiel zwischen Logitech Mäusen und Eclipse. Das Programm SetPoint.exe, das häufig mit einer Logitech Maus installiert wird, führt zu leeren Wizards in Eclipse. Das Beenden der SetPoint.exe und das Neustarten von Eclipse (oder GUIdancer / Jubula) behebt das Problem.

Weitere Informationen finden Sie auf der Eclipse Bugs Seite.