Die vorhergehenden Kapitel waren alle auf das Erstellen und Bearbeiten einzelner Testsuites ausgerichtet. Für das Testen von umfangreichen Applikationen ist dies eventuell nicht ausreichend. Es gibt mindestens zwei Szenarios, für die das Aufteilen von Tests in mehrere Testsuites von entscheidender Bedeutung ist:

• Mehrere Entwickler arbeiten simultan an der Erstellung von Tests. Um Redundanz zu vermeiden, sollten separat erstellte Testsuites nach Möglichkeit gemeinsame 'Prozeduren' und 'Komponenten' verwenden. Eine Testsuite kann zu einem bestimmten Zeitpunkt aber immer nur von einer Person bearbeitet werden.
• Tests werden schlicht und einfach zu groß und unhandlich. Bei ausgedehnten Testläufe reicht eventuell der verfügbare Speicher für Protokolle nicht aus. Eine Testsuite mit einer Vielzahl von Tests kann sehr unübersichtlich werden. Außerdem kann es wünschenswert sein, dass gewisse Tests sowohl als Teil des gesamten Tests, als auch für sich alleine ausgeführt werden können.

QF-Test bietet einige nützliche Hilfsmittel für die verteilte Entwicklung mit deren Hilfe Sie Tests auf mehrere Testsuites verteilen können. Mehrere Entwickler können damit an einzelnen Teilen von Tests arbeiten und später ihre Entwicklungen koordinieren um die 'Komponenten' ihrer Testsuites zusammenzuführen und Bibliotheken von gemeinsam genutzten 'Prozeduren' zu erstellen.

Dieses Kapitel erläutert zunächst die verschiedenen Mechanismen zur verteilten Entwicklung und deren Zusammenspiel. Der abschließende Abschnitt enthält eine knappe und präzise Schritt-für-Schritt Anleitung, um große Testprojekte mit QF-Test umzusetzen.

Es ist möglich, 'Prozeduren' und 'Komponenten' ausserhalb der aktuellen Testsuite zu referenzieren. Diese Referenzen können explizit oder implizit über Includedateien angegeben werden.

• Explizite Referenzen verwenden die gleiche Syntax, die auch in URLs zum Einsatz kommt, um eine bestimmte Stelle auf einer Webseite anzuspringen: Der Name der Datei wird, durch ein '#' Zeichen getrennt, dem 'Name der Prozedur' Attribut eines 'Prozeduraufruf' Knotens oder dem Attribut 'Id der Komponente' eines von einer 'Komponente' abhängigen Knotens vorangestellt. Aus PackagePfad.Prozedur wird somit Suite#PackagePfad.Prozedur
• Implizite Referenzen bedienen sich des 'Include Dateien' Attributs des 'Testsuite' Knotens. Kann ein Knoten in der aktuellen Suite nicht ermittelt werden, sucht QF-Test nach einer passenden 'Prozedur' oder 'Komponente' in allen direkt oder indirekt eingebundenen Testsuites (eine Testsuite wird als indirekt eingebunden bezeichnet, wenn Sie als Includedatei in einer direkt von der aktuellen Suite eingebundenen Datei aufgeführt ist).

Zwar sind implizite Referenzen im Normalfall flexibler und praktischer, es kann damit aber auch schwierig sein, den Überblick zu behalten, wo sich eine referenzierte 'Prozedur' oder 'Komponente' eigentlich befindet. Feststellen kann man dies durch die über das Kontextmenü erreichbaren Funktionen "Prozedur finden" ([Strg-P]) und "Komponente finden" ([Strg-W]). Zusätzlich bietet QF-Test die Menüeinträge »Extras«-»Referenzen absolut machen« und »Extras«-»Referenzen implizit machen«, mit deren Hilfe Sie schnell zwischen den beiden Darstellungen umschalten können, ohne die tatsächlich referenzierten Knoten zu verändern.

Im expliziten wie im impliziten Fall kann die referenzierte Testsuite entweder ein relativer oder ein absoluter Dateiname sein. Relative Dateinamen werden zunächst relativ zur aufrufenden Suite aufgelöst. Schlägt dies fehl, werden die Dateien des Bibliothekspfades (vgl. option Verzeichnisse mit Testsuite Bibliotheken) der Reihe nach durchsucht. Verwenden Sie grundsätzlich - auch unter Windows - das '/' Zeichen als Verzeichnistrenner. QF-Test verwendet dann zur Laufzeit das korrekte Trennzeichen für das jeweilige System. Dadurch bleiben die Testsuites auf verschiedenen Systemen lauffähig.

Hinweis Ihre 'Package' und 'Prozedur' Namen sollten die Zeichen '\' und '#' nicht enthalten. Wenn doch, müssen diese im 'Prozeduraufruf' geschützt werden. Näheres zu diesem Thema finden Sie in Abschnitt 36.6.

Wenn Sie die 'Prozedur' für einen 'Prozeduraufruf' oder die 'Komponente' für einen Event in dem Auswahldialog festlegen, bietet QF-Test alle derzeit geöffneten Testsuites zur Auswahl an. Wenn Sie eine 'Prozedur' oder eine 'Komponente' aus einer anderen Testsuite selektieren, erzeugt QF-Test automatisch die korrekte Referenz. Bei einem späteren Ablauf des Tests wird die referenzierte Testsuite gegebenenfalls automatisch nachgeladen, falls sie sich noch nicht im Speicher befindet.

Während der Ausführung eines Tests verwaltet QF-Test alle beteiligten Testsuites in einem Stapel. Wird eine 'Prozedur' in einer anderen Testsuite aufgerufen, kommt die neue Suite nach oben auf den Stapel. Ist die 'Prozedur' abgearbeitet, wird die Testsuite wieder vom Stapel entfernt. Wann immer während der Ausführung der 'Prozedur' ein Fenster oder eine Komponente über ihre 'Id' angesprochen werden, durchsucht QF-Test den Stapel der Testsuites von oben nach unten, d.h. zuerst in der aufgerufenen Suite, dann in der aufrufenden, wobei Includedateien berücksichtigt werden. Dieser Prozess ist nicht unkompliziert und Sie sind gut beraten, Includes nicht zu tief zu verschachteln. Für den Fall dass Sie bei auftretenden Problemen ein tieferes Verständnis für dieses Thema benötigen, finden Sie in Abschnitt 36.7 eine ausführliche Erklärung.

Wie bereits in Kapitel 6 mehrfach betont wurde, sind die 'Komponenten' der zentrale Bestandteil einer Testsuite. Bei Änderungen am SUT sind diese am ehesten betroffen. Wenn die Änderungen ein solches Ausmaß annehmen, dass QF-Test sich nicht mehr automatisch darauf einstellen kann, müssen die 'Komponenten' von Hand angepasst werden. Aus diesem Grund sollten Sie bei den Komponenten noch mehr als bei jedem anderen Teil der Tests auf das Vermeiden von Redundanz achten.

Wenn Sie Ihre Tests auf mehrere Testsuites verteilen, sollten Sie daher versuchen, die 'Komponenten' in einer zentralen Testsuite vorzuhalten und diese in den anderen Suites als Includedatei einzubinden. Für sehr große Applikationen kann es sinnvoll sein, die 'Komponenten' Hierarchie in Teile zu zerlegen, die jeweils einen zusammengehörenden Teil der Oberfläche des SUT repräsentieren.

Diese zentrale Bibliothek von 'Komponenten' zu verwalten ist nicht trivial. Die dabei auftretenden Probleme können wie folgt mit QF-Test gelöst werden:

• Wenn mehrere Entwickler von Tests gleichzeitig neue 'Komponenten' aufnehmen, können diese nicht sofort in die zentrale Suite integriert werden, da immer nur ein Anwender diese gleichzeitig bearbeiten kann. Stattdessen müssen Komponenten später in die zentrale Suite importiert werden, wenn die neuen Test stabil laufen. Dies wird im folgenden Abschnitt erläutert.
• Wenn sich das SUT ändert, müssen eventuell 'Komponenten' in der zentralen Suite angepasst werden. Werden dabei 'Ids' von 'Komponenten' geändert, werden dadurch Referenzen auf diese Komponenten aus anderen Testsuites ungültig. Um das zu vermeiden, passt QF-Test diese Referenzen automatisch an, vorausgesetzt, die Suites, die von der zentralen Suite abhängen sind im Moment geladen oder im Attribut 'Abhängige Dateien (umgekehrte Includes)' des 'Testsuite' Knotens der zentralen Suite aufgeführt.

Testsuites können durch Importieren einer Testsuite in eine andere miteinander verschmolzen werden. Sie erreichen diese Funktion über den Menüeintrag »Datei«-»Importieren...«.

Sie können auswählen, welche Bereiche der Testsuite zusammengeführt werden sollen.

Um die Konsistenz von Aufrufen sicherzustellen, sollten Sie auf eine korrekte Konstellation von Includes- und Umgekehrten Includes achten. Mehr zum Arbeiten mit mehreren Testsuiten finden Sie im Kapitel 25.

Beim Importieren von Komponenten werden die beiden Komponentenhierarchien miteinander verschmolzen. Hierfür werden alle 'Fenster' und 'Komponenten' der importierten Suite in die Hierarchie der Komponenten der importierenden Suite eingefügt. 'Komponenten', die bereits vorhanden sind, werden nicht kopiert. 'Id' Konflikte, zum Beispiel wenn identische 'Komponenten' in beiden Suites verschiedene 'Ids' oder verschiedene 'Komponenten' die selben 'Ids' haben, löst QF-Test automatisch, indem es die 'Id' der importierten 'Komponente' verändert.

Anschließend werden alle 'Fenster' und 'Komponenten' aus der importierten Suite entfernt. Knoten der importierten Suite, die sich auf diese 'Komponenten' bezogen haben, werden automatisch angepasst. Idealerweise sollte die importierte Suite die importierende Suite als Includedatei einbinden, so dass dabei keine expliziten Referenzen entstehen.

Analog zum Importieren von 'Komponenten' können auch 'Prozeduren', 'Packages', 'Abhängigkeiten' und 'Testfälle' sowie 'Testfallsätze' importiert werden, indem Sie 'Prozeduren' oder 'Tests' im Dialog auswählen. Achten Sie allerdings hierbei wieder auf die Konsistenz Ihrer Testsuite, z.B. macht es kaum Sinn, 'Prozeduren' ohne benutzte 'Komponenten' zu importieren.

Falls Sie nur eine bestimmte 'Prozedur' oder einen 'Testfall' importieren wollen, so können Sie den 'Einzelimport' Knopf auf den Importdialog auswählen und im erscheinenden Detaildialog den gewünschten Knoten auswählen.

Es gibt keinen goldenen Weg, um die Entwicklung von Tests zu organisieren, aber eine Vorgehensweise, die sich bewährt hat, ist die folgende:

• Beginnen Sie mit einer zentralen Testsuite, welche die nötige Funktionalität zum Starten und Stoppen des SUT sowie einen grundlegenden Satz von 'Tests' und 'Prozeduren' umfasst. Diese Suite wird Ihre Mastersuite, die alle Komponenten enthalten wird.
• Stellen Sie sicher, dass Ihre Entwickler die Wichtigkeit von setName() verstanden haben und dass, wo erforderlich, eindeutige Namen nach einheitlichem Schema vergeben werden. Wenn setName() nicht verwendet werden kann, setzten Sie ComponentNameResolver ein, um dies zu erreichen (vgl. Abschnitt 39.1). Sie sollten in der Lage sein, neue Sequenzen ohne viel Aufwand aufzunehmen und ohne dass dabei kleine Änderungen am SUT die Hierarchie der Komponenten völlig durcheinanderbringen.
• Verlagern Sie möglichst viel Funktionalität in 'Prozeduren', insbesondere häufig genutzte Sequenzen und die Vorbereitungs- und Aufräumsequenzen für das SUT.
• Um neue Tests zu erstellen, starten Sie mit einer leeren Testsuite. Binden Sie die Mastersuite über das Attribut 'Include Dateien' des 'Testsuite' Knotens ein. Erstellen Sie 'Vorbereitung' und 'Aufräumen' Knoten zum Starten und Stoppen des SUT indem Sie die entsprechenden 'Prozeduren' in der Mastersuite aufrufen.
• Erstellen Sie die erforderlichen Tests. Beim Aufnehmen von Sequenzen werden wenn möglich die 'Komponenten' in der Mastersuite verwendet. Neue 'Komponenten' werden der neuen Suite hinzugefügt, so dass die Mastersuite zu diesem Zeitpunkt nicht angefasst werden muss.
• Wo möglich, verwenden Sie die 'Prozeduren' der Mastersuite für allgemeine Operationen.
• Wenn Ihre neuen Tests komplett sind und zufriedenstellend funktionieren, importieren Sie alle erforderlichen Knoten der neuen Testsuite in die Mastersuite. Vor allem sollten Sie die 'Komponenten' importieren. Damit stellen Sie sicher, dass alle 'Komponente' Knoten, die neu aufgenommen wurden, in die Mastersuite integriert werden. Die bestehenden 'Komponenten' der Mastersuite werden dabei nicht verändert, so dass keine anderen von der Mastersuite abhängigen Testsuites betroffen sind.
• Nach erfolgtem 'Komponenten'-Import können Sie nun auch alle bzw. einzelne 'Prozeduren' in die Mastersuite importieren.
• Es gibt jetzt mehrere Möglichkeiten, wie Sie die Sequenzen aus Events und Checks organisieren können, die die eigentlichen Tests bilden. In jedem Fall ist es eine gute Idee, alles in 'Prozeduren' und 'Packages' zu verpacken, die entsprechend Ihrem Testplan strukturiert sind. Danach sollten die 'Test' Knoten der obersten Ebene in der Mastersuite und der neuen Suite nur noch aus der gewünschten Struktur von 'Test' und 'Sequenz' Knoten bestehen, welche die 'Prozeduraufrufe' der eigentlichen Testfälle enthalten. Ein solcher Aufbau hat mehrere Vorteile:
  • Alle Tests sind klar strukturiert.
  • Sie können sehr einfach Testläufe von unterschiedlicher Komplexität und Laufzeit zusammenstellen.
  • Sie haben die Möglichkeit, Testfälle in separate Testsuites auszulagern. Diese "Test-Bibliotheken" sollten die Mastersuite als Include Datei einbinden und selbst keine Komponenten enthalten. Damit können Sie die Tests so organisieren, dass Sie wahlweise über die Mastersuite alle Tests, oder nur die einzelnen Testsuites alleine ausführen können.
  • Die Tests können von verschiedenen Personen unabhängig voneinander gepflegt werden, sofern Änderungen an der Mastersuite miteinander abgestimmt werden.
• Wenn Sie Ihre neu erstellten Tests in der neuen Testsuite belassen wollen, tragen Sie die neue Suite im 'Abhängige Dateien' Attribut des 'Testsuite' Knotens der Mastersuite ein, um QF-Test auf diese neue Abhängigkeit hinzuweisen.
• Um einen bestehenden Test zu ändern oder zu erweitern, verfahren Sie nach dem selben Schema. Nehmen Sie zusätzliche Sequenzen nach Bedarf auf, importieren Sie die neuen 'Komponenten' in die Mastersuite.
• Wenn sich Ihr SUT auf eine Weise ändert, die Anpassungen an den 'Komponenten' erfordert, sollten Sie Ihre Tester koordinieren. Stellen Sie zunächst sicher, dass alle Testsuites, die die Mastersuite direkt oder indirekt einbinden, im Attribut 'Abhängige Dateien' des 'Testsuite' Knotens der Mastersuite aufgeführt sind. Wenn bei den Anpassungen 'Ids' von 'Komponenten' geändert werden, muss QF-Test die abhängigen Suites entsprechend modifizieren. Daher sollten diese zu diesem Zeitpunkt nicht von Anderen bearbeitet werden.
• Das Dateiformat der Testsuites von QF-Test ist XML und damit normaler Text. Dieses Format eignet sich ausgezeichnet zur Verwaltung in Systemen zum Versionsmanagement. Änderungen an einigen 'Id der Komponente' Attributen der abhängigen Suites lassen sich normalerweise problemlos mit anderen Änderungen integrieren, so dass die Koordination der Entwickler bei Einsatz eines solchen Werkzeugs nicht zwingend erforderlich ist.

Natürlich kann dieses Schema auch auf mehrere Mastersuites erweitert werden, um verschiedene Teile oder Aspekte einer Applikation zu testen. Dabei kann es sich auszahlen, wenn sich die Komponentenhierarchien dieser Suites möglichst wenig überschneiden, denn dadurch reduziert sich der Pflegeaufwand, wenn sich die grafische Oberfläche des SUT signifikant verändert.

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