25

Verteilte Entwicklung von Tests

Die vorhergehenden Kapitel waren alle auf das Erstellen und Bearbeiten einzelner Testsuiten 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 Testsuiten von entscheidender Bedeutung ist:

• Mehrere Entwickler arbeiten simultan an der Erstellung von Tests. Um Redundanz zu vermeiden, sollten separat erstellte Testsuiten 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äufen 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 Testsuiten verteilen können. Mehrere Entwickler können damit an einzelnen Teilen von Tests arbeiten und später ihre Entwicklungen koordinieren um die 'Komponenten' ihrer Testsuiten 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.

25.1

Der Aufruf einer 'Prozedur' in einer anderen Testsuite

Es ist möglich, 'Prozeduren' und 'Komponenten' außerhalb 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 'QF-Test ID der Komponente' eines von einer 'Komponente' abhängigen Knotens vorangestellt. Aus PackagePfad.Prozedur wird somit Suite#PackagePfad.Prozedur
• Implizite Referenzen bedienen sich des 'Inkludierte 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 Testsuiten (eine Testsuite wird als indirekt eingebunden bezeichnet, wenn Sie als Includedatei in einer direkt von der aktuellen Suite eingebundenen Datei aufgeführt ist).

Eine Testsuite, die einen Knoten in einer anderen Testsuite referenziert, wird von dieser Testsuite abhängig. Bei einer Änderung des 'Namens' der 'Prozedur' oder der 'QF-Test ID' der 'Komponente' muss die verweisende Testsuite angepasst werden, ansonsten ist der Bezug falsch und die Testsuite funktioniert nicht mehr richtig. QF-Test führt solche Anpassungen automatisch durch, sofern es von der Beziehung weiß. Idealerweise sollten beide Testsuiten dem selben Projekt angehören, denn QF-Test verwaltet automatisch alle Include-Beziehungen und alle expliziten Referenzen innerhalb eines Projekts. Andernfalls muss die aufrufende Suite im Attribut 'Abhängige Dateien (umgekehrte Includes)' des 'Testsuite' Knotens der referenzierten Testsuite aufgeführt sein.

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 »Operationen«-»Referenzen explizit machen« und »Operationen«-»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 Testsuiten 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 48.5.

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 Testsuiten 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 Testsuiten 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 'QF-Test ID' angesprochen werden, durchsucht QF-Test den Stapel der Testsuiten 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 48.6 eine ausführliche Erklärung.

25.2

Die Verwaltung von 'Komponenten'

Wie bereits in Kapitel 5 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 Testsuiten verteilen, sollten Sie daher versuchen, die 'Komponenten' in einer zentralen Testsuite vorzuhalten und diese in den anderen Testsuiten 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 Tests 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 'QF-Test IDs' von 'Komponenten' geändert, werden dadurch Referenzen auf diese Komponenten aus anderen Testsuiten ungültig. Um das zu vermeiden, passt QF-Test diese Referenzen automatisch an, vorausgesetzt, die Testsuiten, die von der zentralen Suite abhängen sind im Moment geladen, gehören zum selben Projekt oder sind im Attribut 'Abhängige Dateien (umgekehrte Includes)' des 'Testsuite' Knotens der zentralen Suite aufgeführt.

25.3

Verschmelzen von Testsuiten

Testsuiten 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 36.

25.3.1

Importieren von Komponenten

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. 'QF-Test ID' Konflikte, zum Beispiel wenn identische 'Komponenten' in beiden Testsuiten verschiedene 'QF-Test IDs' oder verschiedene 'Komponenten' die selben 'QF-Test IDs' haben, löst QF-Test automatisch, indem es die 'QF-Test 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.

3.3+25.3.2

Importieren von Prozeduren und Testfällen

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.

25.4

Verteilte Entwicklung von Tests

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 53.1.7). 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 'Inkludierte 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 Testsuiten 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 'Testfallsatz' bzw. 'Testfall' Knoten der obersten Ebene in der Mastersuite und der neuen Suite nur noch aus der gewünschten Struktur von 'Testfallsatz', 'Testfall', 'Testschritt' 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 Testsuiten 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 Testsuiten 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, anstatt sie in die Mastersuite zu übernehmen, sorgen Sie dafür, dass beide Testsuiten zum selben Projekt gehören oder tragen Sie die neue Suite im 'Abhängige Dateien' Attribut des 'Testsuite' Knotens der Mastersuite ein, um QF-Test explizit 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 Testsuiten, die die Mastersuite direkt oder indirekt einbinden, zum selben Projekt wie die Mastersuite gehören oder im Attribut 'Abhängige Dateien' des 'Testsuite' Knotens der Mastersuite aufgeführt sind. Wenn bei den Anpassungen 'QF-Test IDs' von 'Komponenten' geändert werden, muss QF-Test die abhängigen Testsuiten entsprechend modifizieren. Daher sollten diese zu diesem Zeitpunkt nicht von Anderen bearbeitet werden.
• Das Dateiformat der Testsuiten von QF-Test ist XML und damit normaler Text. Dieses Format eignet sich ausgezeichnet zur Verwaltung in Systemen zum Versionsmanagement. Änderungen an einigen 'QF-Test ID der Komponente' Attributen der abhängigen Testsuiten 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 Testsuiten möglichst wenig überschneiden, denn dadurch reduziert sich der Pflegeaufwand, wenn sich die grafische Oberfläche des SUT signifikant verändert.

3.1+25.5

Statische Validierung von Testsuiten

Im Laufe eines Projektes wird es immer wieder zu Veränderungen, Refactoring oder Löschungen von Knoten in Ihrer Testsuite-Struktur kommen. Sie werden sicher manchmal 'Prozeduren' umbenennen oder diese löschen, falls diese nicht mehr benötigt werden.

25.5.1

Ungültige Referenzen vermeiden

In solchen Fällen ist es äußerst wichtig, dass Sie dabei alle Aufrufe der entsprechenden 'Prozedur' anpassen, um Ihre Testsuiten weiterhin lauffähig zu halten. Für diesen Zweck passt QF-Test beim Umbenennen oder Verschieben von Knoten alle Referenzen auf Wunsch automatisch an.

Wenn Sie nun sicherstellen wollen, dass Ihre Teststruktur keine Verweise auf nicht existierende 'Prozeduren' enthält, können Sie dies mit dem Kommando "Referenzen analysieren" bewerkstelligen. Diese statische Validierung wird Ihnen nach einer Analyse auch die Ergebnisse in einem Dialog zeigen, aus dem ersichtlich ist, welche Referenzen noch funktionieren und welche nicht mehr.

Sie können diese Analyse starten, indem Sie nach einem Rechtsklick den Menüeintrag »Weitere Knotenoperationen«-»Referenzen analysieren...« oder den entsprechenden Eintrag aus dem Hauptmenü unter »Operationen« auswählen. Diese Validierung ist auch im Batchmodus möglich.

		Abbildung 25.1:  Ergebnis einer Analyse

3.5+ QF-Test bietet Ihnen außerdem die Möglichkeit, Ihre Testsuiten auf Duplikate zu überprüfen oder nach leeren 'Packages' oder 'Prozeduren' zu suchen. Es ist auch möglich, Knoten auf ungültige Zeichen in deren Namen zu überprüfen.

Diese Art der statischen Validierung ist für 'Prozeduren', 'Abhängigkeiten', 'Testfälle', 'Testfallsätze' und 'Komponenten' und deren Referenzen verfügbar.

4.0.3+25.5.2

Ungenutzte Prozeduren finden

Während der Testentwicklung kann es immer wieder vorkommen, dass Prozeduren, die in früheren Versionen der Tests verwendet wurden, in neueren Version nicht mehr benötigt werden. Wenn Sie solche Prozeduren nicht sofort löschen, kann Ihre Testsuite wachsen. In manchen Fällen könnten Sie hier nun das Gefühl bekommen, dass Sie die Übersicht über die Prozeduren verloren haben könnten. Es gibt nun die Möglichkeit ungenutzte Prozeduren und Abhängigkeit zu finden. Hierfür klicken Sie mit der rechten Maustaste auf 'Testsuite' oder 'Prozeduren' und wählen »Weitere Knotenoperationen«-»Ungenutzte aufrufbare Knoten finden...« aus. Diese Operation liefert nun einen Report über alle ungenutzten Prozeduren und Abhängigkeiten. Jetzt können Sie entscheiden, was Sie damit tun wollen.

Manchmal ist es auch vom Vorteil solche ungenutzten Knoten einfach zu löschen, hierfür können Sie im Menü auch »Weitere Knotenoperationen«-»Ungenutzte aufrufbare Knoten entfernen« auswählen.

Letzte Änderung: 10.9.2024 Copyright © 1999-2024 Quality First Software GmbH