Das wichtigste Feature eines GUI Testwerkzeuges ist die Wiedererkennung der grafischen Komponenten. QF-Test bietet hierfür jede Menge Konfigurationsmöglichkeiten. Dieses Kapitel gibt einen Überblick über die gebräuchlichsten Strategien und Einstellungen, um die Komponentenerkennung so stabil wie möglich zu gestalten.

Wir empfehlen auch, sich die Abschnitte Abschnitt 30.12 und Abschnitt 36.2 genauer anzuschauen.

Hinweis Sie müssen die Strategie zur Komponentenerkennung vor dem breiten Einsatz von QF-Test in Ihrem Projekt festlegen. Andernfalls kann die Wartung von Tests große Schwierigkeiten bereiten. Einige Denkanstöße hierzu finden Sie im Kapitel 24.

In den meisten Projekten können Sie mit der Standardeinstellung sehr gut arbeiten. Die Standardeinstellung benutzt für die Erkennung einer Komponente deren Namen, deren Klasse (Typ) und ebenso deren Hierarchie (Aufbau der Maske).

Mit diesen Einstellungen bekommen Sie Probleme, wenn

• die Entwicklung keine eindeutigen Namen vergibt.
• sich die Komponentenhierarchie, also der Maskenaufbau, stark ändert.
• sich die Namen ändern (siehe Abschnitt 27.4).
• sich die Klassen ändern (siehe Abschnitt 27.5).

Wenn die Entwicklung keine Namen vergibt, verwendet QF-Test andere Eigenschaften, wie einen Label oder den Text eines Buttons oder die Geometrie der Komponente für die Wiedererkennung. In diesem Fall funktioniert die Standardeinstellung auch, solange die Komponentenstruktur und die Geometrie einigermaßen stabil bleiben. Sie sollten allerdings darauf achten, dass für die Tests das SUT immer mit derselben Fenstergröße gestartet wird.

Die Standardeinstellung für Komponentenaufzeichnung sieht so aus:

		Abbildung 27.1:  Standardeinstellung Komponentenaufzeichnung

Die Standardeinstellung für die Wiedererkennung beim Abspielen sieht so aus:

		Abbildung 27.2:  Standardeinstellungen für die Wiedergabe

Wenn die Entwickler stabile und eindeutige Namen für alle wichtigen Komponenten eines Tests vergeben, z.B. für alle Buttons, Tabellen und Textfelder, dann können Sie die Wiedererkennungsoptionen auf 'Name übertrifft alles' setzen. Dies bringt den Vorteil, dass Sie nun die Komponenten direkt anhand deren Namen und des Fensters, in dem sich die Komponenten befindet, erkennen. Falls sich die GUI-Hierarchie des SUT ändert, wird das keine Auswirkung auf die Komponentenerkennung haben, da nur die Namen der eigentlichen Komponenten verwendet werden.

Mit dieser Einstellung bekommen Sie Probleme, wenn

• die Entwicklung keine eindeutigen Namen vergibt.
• sich die Namen ändern (siehe Abschnitt 27.4).
• sich die Klassen ändern (siehe Abschnitt 27.5).

Die 'Name übertrifft alles' Einstellung für das Aufzeichnen sieht so aus:

		Abbildung 27.3:  'Name übertrifft alles' Einstellung für die Aufzeichnung

Die 'Name übertrifft alles' Einstellung für das Abspielen sieht so aus:

		Abbildung 27.4:  'Name übertrifft alles' Einstellung für das Abspielen

In vielen Applikationen werden Sie auf die Situation treffen, dass keine eindeutigen Namen seitens der Entwicklung vergeben wurden und QF-Test dieselben Komponenten immer wieder an unterschiedlichen Stellen aufzeichnet. Die Wiedergabe dieser aufgezeichneten Komponenten funktioniert dann meistens solange sich die Geometrie des Fensters nicht drastisch verändert.

In diesem Fall ist es wahrscheinlich, dass der Titel des Hauptfensters sich immer wieder ändert, z.B. kann der Titel die aktuelle Versionsnummer, den gerade eingeloggten Benutzer oder einen Dateinamen beinhalten. Wenn Sie Ihre Tests stabil halten wollen und die unterschiedlich aufgezeichneten Fenster als einen 'Fenster' Knoten unter dem 'Fenster und Komponenten' Knoten behandeln wollen, dann selektieren Sie den 'Fenster' Knoten und editieren Sie dessen 'Merkmal' Attribut. Dort ersetzen Sie den dynamischen Teil durch einen regulären Ausdruck und haken dabei die Checkbox 'Als Regexp' an. Nun sollten Ihre Tests wieder funktionieren.

Hier sehen Sie ein Beispiel für einen regulären Ausdruck für eine Komponente des JCarConfigurators, deren 'Merkmal' mit dem Wort 'Fahrzeuge' beginnt, aber danach einen beliebigen dynamischen Teil enthalten kann:

		Abbildung 27.5:  Ein regulärer Ausdruck im 'Merkmal' Attribut

Reguläre Ausdrücke finden bei QF-Test an vielen Stellen Verwendung. Im Abschnitt 36.4 finden Sie detaillierte Informationen zu ihrer Verwendung.

Hinweis Komponenten-IDs können, wie im Abschnitt 6.3 beschrieben, unter Zuhilfenahme des 'Merkmal' Attributs generiert werden. Da das 'Id' Attribut nur ein künstliches Konzept ist, um Aktionen auf aufgezeichnete Komponenten abzubilden, kann es unter Umständen schön sein, wenn es zur besseren Lesbarkeit nachträglich geändert wird. QF-Test bieten die Möglichkeit, beim Umbenennen alle Referenzen automatisch anzupassen.

In GUI Testprojekten können Sie auf jede Menge interessanter Namenskonzepte für Komponenten stoßen. Manchmal haben die Komponenten keine Namen, aber die Tester kennen einen Algorithmus, um eindeutige Namen zu setzen. Ein anderes Mal existieren Namen, die sich aber von Zeit zu Zeit ändern, z.B. zeichnen Sie einen 'button1' beim ersten Mal auf und beim nächsten Mal heißt dieser Button plötzlich 'button2'. Eine andere Variante könnte sein, dass die aktuelle Versionsnummer des SUT im Namen des Hauptfensters steckt.

In solchen Fällen sollten Sie sich das NameResolver Interface von QF-Test genauer anschauen.

Ein NameResolver kann verwendet werden, um Namen aus der QF-Test Sicht zu ändern oder zu löschen. Diese Änderungen treffen dann nur für die QF-Test Sicht zu und ändern nichts am aktuellen Sourcecode.

Sie sollten über den Einsatz von NameResolver nachdenken, wenn:

• das SUT dynamische Namen besitzt.
• Sie einen Algorithmus kennen, um eindeutige Namen zu vergeben.
• Sie Namen auf andere Namen setzen wollen, z.B. wegen einer neuen Version oder für das Testen in anderen Sprachen.
• Sie die Namensgebung der Komponenten optimieren wollen, z.B. einige Teile ausschneiden, um lesbarere Komponenten-IDs in QF-Test zu erhalten.

Wenn Sie eine Eindeutigkeit pro Fenster erreichen, können Sie darüber nachdenken die Standardeinstellungen auf 'Name übertrifft alles' zu setzen, siehe hierzu Abschnitt 27.2.

Hinweis Wenn es möglich ist, dass die Entwickler eindeutige und stabile Namen direkt vergeben, dann sollten es diese im Sourcecode tun, da die Entwickler am besten wissen, welche Komponenten angelegt werden. Das Implementieren eines NameResolvers kann eine sehr aufwendige und mühsame Aufgabe sein, besonders wenn sich das GUI stark ändert.

NameResolvers sind im Abschnitt 39.1 beschrieben.

Sie können QF-Test so konfigurieren, dass nur die Systemklassen der Komponenten aufgezeichnet werden, anstatt der eigenen Klassennamen. Systemklassen sind javax.swing... und java.awt... Klassen für Java/Swing und org.eclipse.swt.widgets... Klassen für Java/SWT Applikationen.

		Abbildung 27.6:  Option um nur Systemklassen aufzuzeichnen

Wenn Sie diese Option setzen, haben Sie keine Probleme mehr mit Re-factoring Schritten der Entwickler, wenn sich Klassennamen ändern. Des Weiteren können Sie auch Klassen, die mit Obfuscatoren verändert wurden, für die Tests verwenden.

In den meisten Fällen können Sie mit dieser eingeschalteten Option arbeiten, da es immer wieder vorkommen kann, dass sich Klassennamen ändern. Diese Option bewahrt Sie vor Problemen, die ansonsten etwas zeitaufwendiger zu lösen wären.

Jedoch sollten Sie nicht mit dieser Option arbeiten, wenn die konkreten Klassen ein wichtiger Bestandteil Ihrer Komponentenerkennungsstrategie sind. Falls die Entwickler keine guten Namen gesetzt haben, allerdings unterschiedliche Klassen für bestimmte Container benutzen, dann kann QF-Test anhand dieser konkreten Klasse die Komponenten wiederum erkennen.

3.1+ Ein gemischter Ansatz ist mit dem Einsatz eines ClassNameResolvers möglich. ClassNameResolver können nützlich sein, wenn Sie nur für bestimmte Klassen Systemklassen aufzeichnen wollen, aber nicht für alle, z.B. nicht bei Drittanbieter Bilbiotheken. Eine genaue Beschreibung finden Sie unter Abschnitt 39.1.2.

Bis jetzt haben wir Ansätze kennen gelernt, um die Wiedererkennung an unsere Bedürfnisse anzupassen. Jedoch müssen wir immer noch jede einzelne Komponenten aufzeichnen, die wir im Test verwenden wollen.

Sie können sich sicher vorstellen, dass es ein sehr mühsamer Akt ist, jede Komponente, die in einem Test verwendet werden könnte, aufzuzeichnen. Manchmal könnte das sogar nahezu unmöglich sein, z.B. wenn es sich ändernde Namen oder ändernde Labels gibt. Ein typischer Anwendungsfall hierfür ist das Testen von lokalisierten Anwendungen.

Eine andere Situation könnte der Einsatz eines GUI Frameworks bei der Entwicklung sein. Dieser Einsatz generiert jede Menge ähnlicher Dialoge, wo sich nur ein paar Komponenten unterscheiden. Aber Sie müssen jedes Mal jeden Bereich neu aufzeichnen, auch wenn Sie dies schon einmal gemacht haben - z.B. Navigationsbuttons in jedem Fenster, weil es sich immer um ein neues Fenster handelt.

QF-Test bietet nun die Möglichkeit, die Aufzeichnung drastisch zu reduzieren. Dieses Konzept wird als 'Generisches Komponenten Konzept' bezeichnet. Hierfür benutzen Sie Variablen in den Komponenteneigenschaften oder löschen einfach dynamische Teile daraus.

Ein allgemeiner Ansatz für das Generalisieren von Komponenten ist folgender:

1. Zeichnen Sie einige Komponenten, die Sie generalisieren wollen, auf und vergleichen Sie diese.
2. Erstellen Sie eine generische Komponente, die in der ID 'generisch' enthält, damit Sie diese wiederfinden.
3. Entfernen Sie alle Attribute, die Sie nicht für die Wiedererkennung verwenden wollen, aus dieser generischen Komponente.
4. Legen Sie die Wiedererkennungseigenschaft fest, z.B: 'Name', 'Merkmal' oder 'Index'.
5. Setzen Sie in diesem Attribut eine Variable, z.B. $(name).
6. Um falsche Treffer zu vermeiden, deaktivieren Sie die Geometrieerkennung und setzen in den 'X' und 'Y' Attributen ein '-'.
7. Spezifizieren Sie '@generic' im Attribut 'Bemerkung', damit diese Komponenten nicht unabsichtlicherweise von der 'Ungenutzte Komponenten entfernen' Aktion gelöscht wird.
8. Erstellen Sie eine Prozedur, um auf diese generische Komponente zuzugreifen und verwenden Sie die Variable/diese Variablen von vorhin als Parameter der Prozedur.

Hinweis Generische Komponenten sind sehr nützlich für das Abspielen von Tests, aber QF-Test verwendet diese nicht für die Aufzeichnung. Sie werden immer die konkrete Komponenten aufgezeichnet bekommen. Sie müssen daher nachträglich die konkrete Komponenten durch die generische ersetzen.

Seit QF-Test Version 3.1 ist es sogar möglich, die Wiedererkennungsoptionen zur Laufzeit zu ändern. Daher sind Sie nun vollkommen flexibel und können unterschiedliche Varianten für das SUT verwenden.

Optionen können entweder in einem 'Server Skript' oder 'SUT Skript' - hängt von der jeweiligen Option ab - und Aufruf von rc.setOption(OPTION_NAME, OPTION_VALUE) gesetzt werden. Sie finden eine Liste aller möglichen Optionen für die Aufnahme unter Abschnitt 29.2 und für das Abspielen unter Abschnitt 29.3.

Letzte Änderung: 23.04.2012 Copyright © 1999-2012 Quality First Software GmbH