Dieses Kapitel beschreibt die wichtigsten Aspekte, welche berücksichtigt werden sollten, bevor Sie QF-Test großflächig in einem Testprojekt einsetzen. Es wirft Fragen auf und versucht allgemeine Antworten mit Referenzen auf detailierte Beschreibungen zu geben.

Bevor Sie beginnen automatisierte Tests zu erstellen und auszuführen, sollten Sie sich ein paar Gedanken über die zu verwendende Testumgebung machen. Damit Sie Tests verlässlich und wiederholbar abspielen können, müssen Sie bedenken, dass Sie hierfür das SUT in einen definierten Zustand bringen sollten, inklusive das Backend, z.B. einen Server und/oder eine Datenbank. Wenn Sie sich dessen nicht bewusst sind, kann es unter Umständen ziemlich schwierig werden, Tests wiederholbar abzuspielen oder einfach nur die Testresultate zu analysieren. Außerdem kann die Wartung der Tests zu einem Albtraum werden.

Bitte bedenken Sie zusätzlich noch folgende Themen:

1. Wie sieht der Initialzustand des SUT aus?
   • Welcher Benutzer wird verwendet um die Tests in der SUT abzuspielen? Die meisten Projekte arbeiten mit dedizierten Testbenutzern. Ein anderer Ansatz ist, dass jeder Tester mit seinen eigenen Testbenutzer arbeitet.
   • Welche Spracheinstellung des SUT wird hauptsächlich verwendet? Ist es wirklich notwendig eine volle Sprachabdeckung über alle unterstützten Sprachen zu erreichen? Oder genügt es, die gesamten Testfälle auf einer speziellen Sprache auszuführen und nur ein paar ausgesuchte für die Lokalisierungstests zu verwenden? In den meisten Fällen deckt das Wiederholen der Testfälle in unterschiedlichen Sprachen dieselbe Funktionalität ab und Sie erlangen dadurch keine neuen Informationen über das SUT. Wenn Sie sich trotzdem entschließen mit mehreren Spracheinstellungen zu testen, könnte dies die Wiedererkennung der grafischen Komponenten beeinflussen, siehe Kapitel 27.
2. Wie sieht der Initialzustand der Datenbank aus?
   • Können Sie mit einer separaten Testdatenbank arbeiten oder benutzen Sie eine Produktionsdatenbank? Testdatenbanken können geplante Testdaten beinhalten, wohingegen Produktionsdatenbanken wirkliche Daten aus der realen Umgebung beinhalten. Sind diese Daten vorhersagbar und verlässlich? Was passiert, wenn Ihre Daten durcheinander kommen oder gar zerstört werden? Sie sollten in jedem Fall keine automatisierten Tests auf der Produktionsumgebung ausführen.
   • Können Sie Ihre Testumgebung nach einem Testlauf wieder auf den Ausgangszustand zurücksetzen, um den Testlauf zu wiederholen? Ist es möglich, Änderungen in der Datenbank zurückzunehmen oder benötigt jeder neue Testlauf neue Testdaten?
   • Wie können Testdaten gelesen bzw. geschrieben werden? Können Sie hierfür Standard SQL-Skripte verwenden oder gibt es Bibliotheken von der Entwicklung? Einige Projekte setzen sogar die Datenbank vor jedem Testlauf komplett neu auf, weil sie weder Testdaten wiederverwenden noch die Datenbank korrekt säubern können.
3. Wollen Sie QF-Test mit anderen Werkzeugen, z.B. Build- oder Testverwaltungswerkzeuge, integrieren?
   • Wie integriert man QF-Test in eine Testverwaltung? Wenn Sie bereits geplante Testschritte wiederverwenden können, dann vermeiden Sie redundante Arbeit in der Testplanungsphase. Einige Standardintegrationen sind unter Kapitel 19 beschrieben.
   • Sollen Tests von einem Buildtool gestartet werden? Nachdem Sie Tests erstellt haben, können Sie diese unbeaufsichtigt ausführen und diesen Testlauf von einem Buildtool, z.B. Ant oder CruiseControl, anstoßen. Für Details über Testausführung, siehe Kapitel 16.
   • Sollen Testresultate in ein Reporting- oder Testverwaltungssystem hochgeladen werden oder reicht es den erzeugten HTML-Report und die Protokolle auf einen zentralen HTTP-Server zu legen?
4. Wer wird mit QF-Test arbeiten?
   • Arbeiten nur ein oder zwei Tester mit QF-Test oder werden auch mehrere Entwickler und Fachtester in die Testentwicklung miteinbezogen? Im Abschnitt Abschnitt 25.5 finden Sie einige Tipps für das Arbeiten im Team.
   • Wie sind die Kenntnisse der Tester? Sie sollten mindestens eine dedizierte Person mit guten QF-Test Kenntnissen im Team haben, welche auch in der Lage ist, Skripte zu implementieren und Softwareentwicklungsprinzipien versteht.

Natürlich werden in Ihrem Projekt noch weitere Punkte auftauchen. Denken Sie einmal darüber nach.

Sie sollten sich überlegen, wohin Sie bestimmte Dateien legen bzw. installieren wollen:

1. Wo soll QF-Test installiert werden? QF-Test kann lokal auf jedem Rechner installiert werden. Dieses Vorgehen zwingt Sie allerdings wiederum, neue Versionen auf jedem Rechner einzeln zu installieren. Alternativ können Sie QF-Test auf einem Netzlaufwerk installieren, wenn Ihr Netzwerk verlässlich funktionieren sollte. Details hierzu finden Sie unter Abschnitt 24.2.1.
2. Wo soll die Konfigurationsdatei qftest.cfg abgelegt werden? Diese Datei beinhaltet u.a. wie QF-Test die grafischen Komponenten wiedererkennt oder was im Protokoll gespeichert werden soll. Diese Einstellungen müssen für jeden QF-Test Benutzer dieselben sein, sonst können keine Tests im Team geteilt werden. Damit Sie dieselbe Datei verwenden, können Sie QF-Test entweder zentral auf einem Netzlaufwerk installieren oder Sie geben den Pfad zur Konfigurationsdatei als Kommandozeilenparameter beim Start von QF-Test mit. Wenn Sie mit einer Datei auf einem Netzlaufwerk arbeiten, dann stellen Sie sicher, dass diese Datei schreibgeschützt ist und nur bestimmte Benutzer diese ändern können. Details finden Sie unter Abschnitt 1.4.
3. Wo soll die Lizenzdatei license liegen? Sie sollten die Lizenzdatei an einer zentralen Stelle ablegen, damit Sie die Lizenz nur einmal aktualisieren müssen, wenn Sie ein Update erhalten. Hier können Sie ebenfalls entweder an eine zentrale Netzwerkinstallation von QF-Test denken oder einen Kommandozeilenparameter beim Start von QF-Test verwenden. Details finden Sie unter Abschnitt 1.3.
4. Wo sollen Testsuiten gespeichert werden? Der beste Speicherort für Testsuiten ist ein Versionsmanagementsystem, womit Sie Änderungen verfolgen und auf jede Version der Datei zugreifen können. Wenn dies nicht möglich sein sollte, dann sollten die Dateien auf einem zentralen Netzlaufwerk installiert werden.
5. Wo sollen die Testdatendateien gespeichert werden? Testdatendateien gehören immer zu Testsuiten und sollten daher nahe an diesen abgelegt werden, d.h. im selben Versionsmanagementsystem oder Netzlaufwerk.
6. Wo sollen die HTML Reports und Protokolle abgelegt werden? Diese Dateien sollten an einer zentralen Stelle liegen, auf die jeder Tester zugreifen und die Testresultate auswerten kann. Die meisten Kunden legen diese auf einen zentralen HTTP Server oder einen Netzlaufwerk ab.

Wenn Sie planen QF-Test auf einem Netzlaufwerk zu installieren, müssen Sie einige Dinge beachten.

Der kritische Punkt ist die Konfigurationsdatei qftest.cfg. Es ist empfehlenswert (und notwendig), dass alle Tester dieselben Einstellungen verwenden, besonders für die Wiedererkennung. Dies erreichen Sie durch Sharen dieser Datei. Jedoch sollten Sie darauf achten, dass sie schreibgeschützt ist, damit ein Benutzer nicht unabsichtlich die Einstellungen verändert. Da QF-Test vorgenommene Änderungen so nicht beim Beenden speichern kann. Jede gewollte Änderung sollte durchgeführt werden, in dem Sie die Datei explizit mit Schreibrechten versehen, dann QF-Test beenden, und danach die Schreibrechte wieder entziehen. Eine andere Möglichkeit ist, dass jeder Benutzer, seine eigene Konfigurationsdatei benutzt, z.B. mittels den Kommandozeilenparameter -systemcfg, aber das ist nicht empfehlenswert.

Falls Sie eine Java/SWING Anwendung testen und die Option "Ohne JDK Instrumentierung verbinden" ausgeschaltet haben, kann die Liste der instrumentierten JDKs eine weitere Quelle für Unstimmigkeiten sein, welche zentral gespeichert wird. Dies führt zu Durcheinander, wenn Benutzer mit unterschiedlichen JDK Versionen oder mit unterschiedlichen Installationsverzeichnissen arbeiten. Sie können allerdings diese Liste als eine zentrale Stelle aller verwendeten JDK Verzeichnissen auf allen System verstehen. Die wirkliche Prüfung, ob das JDK auf dem aktuellen System instrumentiert ist, erfolgt unabhängig davon zur Laufzeit beim Öffnen des Instrumentierungsdialogs.

Die laufenden QF-Test Instanzen teilen sich auch das Logverzeichnis (internes Logging, das kein Problem darstellt) und den Jython Package Cache, welcher gelegentlich Probleme verursacht. In diesem Fall kann QF-Test den Jythoninterpreter nicht mehr initialisieren. Das passiert sehr selten und kann mit Säuberung (nicht kompletten Löschens) des Jython Cache Verzeichnisses behoben werden.

Auf Windows sollte jeder Benutzer die Datei setup.exe ausführen, damit die aktuelle QF-Test Version, die sich im installierten qftest-x.y.z. Verzeichnis befindet, mit den entsprechenden Windowseinstellungen in der Registry verknüpft wird.

In sehr seltenen Fällen kann das Überschreiben von Jar Dateien von QF-Test beim Einspielen eines QF-Test Patches, bereits laufende Instanzen auf Windows zum Absturz bringen.

Der wichtigste Aspekt eines GUI Testtools ist eine stabile und verlässliche Wiedererkennung der grafischen Komponenten. In diesem Bereich ist QF-Test sehr flexibel und bietet unterschiedlichen Konfigurationsmöglichkeiten. In den meisten Fällen reicht die Standardkonfiguration der Komponentenerkennung aus, allerdings müssen Sie diese manchmal anpassen.

Wenn Sie die Komponentenerkennungseinstellungen nach Erstellen mehrerer Testfälle ändern, laufen Sie Gefahr, dass diese Testfälle nicht mehr lauffähig sind. Deshalb sollten Sie so früh wie möglich versuchen eine angemessene Erkennungsstrategie für Ihr Testprojekt zu finden. Sie sollten sich diese Zeit in jedem Fall nehmen und diesen Bereich wirklich genau ansehen, bevor Sie viele Testfälle kreiren. Im schlimmsten Fall müssen Sie alle bereits erstellten Testfälle neu erstellen, nachdem Sie die Erkennungseinstellungen verändert haben.

Am besten erstellen Sie einige Demotestfälle und versuchen herauszufinden, wie QF-Test die Komponenten Ihres SUT erkennt. Der Wiedererkennungsmechanismus ist in den Kapiteln Kapitel 6 und Kapitel 7 beschrieben. Wenn Sie die Demotestfälle, im Idealfall mit einer anderen SUT Version, ausführen und auf Wiedererkennungsprobleme stoßen, versuchen Sie folgende Punkte zu klären:

1. Gibt es genügend Synchronisationspunkte, wie 'Warten auf Komponente' oder 'Check' Knoten mit Wartezeiten, um die Testschritte nur dann auszuführen, wenn das SUT wirklich bereit dazu ist?
   1. Beispiel 1: Nach Öffnen eines Fenster können Sie Aktionen nur dann darin ausführen, wenn es wirklich schon vorhanden ist -> Verwenden Sie einen 'Warten auf Komponente' Knoten.
   2. Beispiel 2: Nachdem Sie auf einen "Suchen" Knopf geklickt haben, können Sie erst dann fortfahren, wenn die Suche wirklich beendet ist -> Verwenden Sie einen 'Check' Knoten mit Wartezeit.

Ein weiterer Punkt neben Synchronisationspunkten ist die richtige Einstellung für die Komponentenerkennung. Sie sollten folgende Punkte vorab klären, um herauszufinden, welche Einstellung für Sie die geeignetste ist:

1. Werden eindeutige und stabile Namen für die Komponenten von den Entwicklern vergeben? Siehe Abschnitt 30.12 für Details.
2. Vielleicht reicht es aus, einen regulären Ausdruck im 'Merkmal' Attribut der Komponente des Hauptfensters unter des 'Fenster und Komponenten' Knotens zu setzen? Siehe Abschnitt 27.3 für Details.
3. Wenn die Entwicklung keine benutzbaren oder sogar dynamische Namen vergeben haben, dann könnten Sie dies mit einem NameResolver lösen. Siehe Kapitel 27.
4. Vielleicht kommen die Probleme vom Aufzeichnen unterschiedlicher Komponentenklassen. Das ist typischerweise ein Resultat von Obfuscation. Siehe Abschnitt 27.5.
5. Müssen Sie vielleicht die QF-Test Wiedererkennungsoptionen ändern? Diese sind im Kapitel Kapitel 27 beschrieben.
6. Ist es denkbar, generische Komponente einzusetzen? Siehe Abschnitt 27.6.

In einigen Fällen reicht es aus, einfach die Standardkonfiguration zu ändern. Angenommen die Entwicklung hat eindeutige und stabile Namen für die Zielkomponenten vergeben, d.h. für Buttons, Textfelder, Checkboxen etc., dann können Sie einfach die 'Gewichtung von Namen' Option von QF-Test auf 'Name übertrifft alles' setzen. Diese Einstellung teilt QF-Test mit, Änderungen in der Komponentenhierarchie zu ignorieren und nur mit der eigentlichen Zielkomponente und deren Fenster zu arbeiten.

Hinweis Sie müssen diese Option an zwei Stellen ändern. Einmal unter 'Aufnahme' -> 'Komponenten' -> 'Gewichtung von Namen' und einmal unter 'Wiedergabe' -> ' Wiedererkennung' -> 'Gewichtung von Namen'. Siehe Kapitel 27 für mehr Informationen.

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