Handbuch
Handbuch
 |  |  |  |  |  |  |  |
| Version 7.1.3 |
Wenn Sie Exceptions erhalten, weil eine Komponente nicht gefunden wurde, kann einer der Gründe sein, dass nicht lang genug auf die Komponente gewartet wurde. Ein Mausklick hat zwar eine gewisse Standardwartezeit, diese ist aber nicht immer ausreichend. Daher sollten Sie prüfen, ob es genügend Synchronisationspunkte gibt, wie 'Warten auf Komponente' oder 'Check' Knoten mit Wartezeiten, um die Testschritte nur dann auszuführen, wenn das SUT wirklich bereit dazu ist.
Die 'Wartezeit' Attribute geben eine maximale Wartezeit an. Sobald der gewünschte Zustand in der Anwendung erreicht ist, fährt QF-Test mit der Ausführung fort. Diese Wartezeiten können daher großzügig gewählt werden.
Eine Änderung der Optionen für Standardwartezeiten (Abschnitt 39.3.6) sollte nur erfolgen, wenn generell längere Wartezeiten anwendungsweit Sinn machen.
Hinweis Als letzte Möglichkeit können Sie auch mit einer festen Verzögerung arbeiten. Bei Angaben im Attribut 'Verzögerung vorher/nachher' wartet QF-Test die komplette angegebene Zeit. 'Verzögerung vorher/nachher' sollten daher nur genutzt werden, wenn es gar keine für QF-Test erkennbare Zustandsänderung in der zu testenden Anwendung gibt, auf die gewartet werden kann.
Wenn sich Ihr SUT in einer Weise verändert, die es QF-Test unmöglich macht, eine Komponente
wiederzufinden, schlägt Ihr Test mit einer ComponentNotFoundException fehl. Diese
sollte nicht mit einer UnresolvedComponentIdException verwechselt werden, welche
durch Entfernen eines 'Komponente'-Knotens aus der Testsuite oder dem Ändern des
Attributs 'QF-Test ID der Komponente' eines 'Event' Knotens zu einer nicht vorhandenen 'QF-Test ID'
ausgelöst werden kann.
Es gibt zwei Videos, die die Behandlung einer ComponentNotFoundException
ausführlich erklären:
Wenn Sie eine ComponentNotFoundException erhalten, führen Sie den Test erneut mit
aktiviertem Test-Debugger aus, so dass der Test angehalten wird und Sie den Knoten, der
das Problem verursacht hat, untersuchen können. Hier zahlt es sich aus, wenn 'QF-Test ID'
Attribute aussagekräftig sind, da Sie verstehen müssen, welche Komponente der Test
anzusprechen versucht hat. Falls Sie sich gar keinen Reim darauf machen können, was der
Sinn des betreffenden Knotens sein soll, deaktivieren Sie ihn und versuchen Sie, ob der
Test ohne diesen Knoten durchläuft. Es könnte sich um einen Störeffekt handeln, der bei
der Aufnahme nicht gefiltert wurde, und der gar nichts zum eigentlichen Test beiträgt.
Grundsätzlich sollten Ihre Tests immer auf das Minimum an Knoten reduziert werden, mit
denen sich der gewünschte Effekt erzielen lässt.
Falls der Knoten erhalten bleiben muss, werfen Sie als nächstes einen Blick auf das SUT, um zu sehen, ob die Zielkomponente aktuell sichtbar ist. Wenn nicht, müssen Sie Ihren Test entsprechend anpassen, um diese Situation zu behandeln. Ist die Komponente sichtbar, überprüfen Sie anhand des Bildschirmabbilds im Protokoll, ob das auch zum Zeitpunkt des Fehlers der Fall war, und versuchen Sie, den fehlgeschlagenen Knoten noch einmal als Einzelschritt auszuführen. Wenn die Ausführung nun klappt, haben Sie ein Problem mit dem Timing, das Sie durch den Einbau eines 'Warten auf Komponente' Knotens, eines 'Check' Knotens mit 'Wartezeit' oder einer anderen Warteaktion (siehe Zeitliche Synchronisierung) lösen können.
Falls die Komponente sichtbar ist und die Wiedergabe kontinuierlich fehlschlägt, ist die Ursache eine Änderung an der Komponente oder einer ihrer Parent-Komponenten. Nun gilt es festzustellen, was sich geändert hat und wo. Nehmen Sie hierzu einen neuen Klick auf die Komponente auf und vergleichen Sie dann den alten und neuen 'Komponente'-Knoten in der Hierarchie unterhalb von 'Fenster und Komponenten'.
Hinweis Sie können vom 'Event' Knoten direkt zum zugehörigen 'Komponente' Knoten springen, indem Sie [Strg-W] drücken oder rechts-klicken und im Popup-Menü »Komponente finden« wählen. Sie können mittels [Strg-Backspace] oder »Bearbeiten«-»Vorherigen Knoten anwählen« wieder zurückspringen. Ein schlauer Trick ist, die zu vergleichenden 'Komponente' Knoten durch Setzen von Marken zu kennzeichnen »Bearbeiten«-»Marken«, um sie leichter wiederzufinden.
Der Knackpunkt ist die Stelle, an der die Hierarchie der beiden Knoten verzweigt. Wenn sie unter verschiedenen 'Fenster' Knoten angesiedelt sind, liegt der Unterschied in den betreffenden 'Fenstern' selbst. Andernfalls gibt es einen gemeinsamen Vorgänger direkt oberhalb der Verzweigung. Der entscheidende Unterschied ist dann in den jeweiligen Knoten direkt unterhalb dieses gemeinsamen Vorgängers zu finden. Wenn Sie die Stelle mit der Unterscheidung gefunden haben, vergleichen Sie die Attribute der betreffenden Knoten von oben nach unten und suchen Sie nach Abweichungen.
Hinweis Sie können mittels »Ansicht«-»Neues Fenster...« ein weiteres QF-Test Fenster öffnen und damit die Detailansichten der beiden Knoten nebeneinander platzieren.
Die einzigen Unterschiede, die immer zu einem Fehler bei der Wiedererkennung führen, sind Änderungen der Attribute 'Klasse' oder 'Name'. Abweichungen bei 'Merkmal', Struktur oder Geometrie können üblicherweise kompensiert werden, sofern sie sich nicht häufen.
Eine Änderung der 'Klasse' sollte bei der Verwendung von Generische Klassen
kaum vorkommen. Die Verwendung von generischen Klassen bietet einige Vorteile,
wird bei Web-Anwendungen aber manchmal erst nach der Erstellung erster Tests
eingeführt (siehe Verbesserte Komponentenerkennung mittels CustomWebResolver).
In diesem Fall müssen Sie das 'Klasse' Attribut der bereits vorhandenen
'Komponente'-Knoten an diese Änderung anpassen.
Auch der Komponentenbezeichner kann sich ändern. Falls die Änderung
beabsichtigt zu sein scheint, z.B. die Korrektur eines Rechtschreibfehlers, können Sie
das 'Name' Attribut entsprechend anpassen. Wahrscheinlicher ist, dass es sich um einen
automatisch generierten Komponentenbezeichner handelt,
der sich jederzeit wieder ändern kann. Auch hier kann es Sinn machen, das
Problem mit den Entwicklern diskutieren und entwicklungsseitig eine Lösung zu finden.
Ansonsten kann bei Web-Anwendungen der 'Name' über den
Der 'CustomWebResolver installieren' Knoten beeinflusst werden, speziell über die
Kategorien autoIdPatterns und customIdAttributes.
Bei allen Technologien kann der 'Name' mit Hilfe eines
NameResolvers, wie in
Abschnitt 52.1.7 beschrieben, beeinflusst werden.
Er kann ganz unterdrückt oder auf relevante Teile reduziert werden.
Änderungen am Attribut 'Merkmal' sind insbesondere für 'Fenster' Knoten nicht ungewöhnlich. Dort entspricht das 'Merkmal' dem Titel des Fensters. Kombiniert mit einer signifikanten Änderung der Geometrie kann das zum Scheitern der Wiedererkennung führen. Dies kann durch Anpassen des 'Merkmal' Attributs an die neuen Gegebenheiten, oder - bevorzugt - durch Verwendung eines regulären Ausdrucks (vgl. Abschnitt 47.3), der alle Varianten abdeckt, behoben werden.
Abhängig von Art und Umfang der Änderungen gibt es zwei grundsätzliche Möglichkeiten zur Korrektur:
Behalten Sie die neuen Knoten und entfernen Sie den alten. Hierzu müssen Sie zunächst sicherstellen, dass alle Knoten, die auf die alte Komponente verweisen, auf die neue 'QF-Test ID' geändert werden. Dies lässt sich durch einen kleinen Trick erreichen: Ändern Sie die 'QF-Test ID' des alten 'Komponente'-Knotens auf die 'QF-Test ID' des neuen. QF-Test beschwert sich zunächst, dass die 'QF-Test ID' nicht eindeutig ist, was Sie ignorieren können, und bietet dann an, alle Verweise zu aktualisieren, was Sie mit "Ja" bestätigen müssen. Anschließend können Sie den alten Knoten entfernen.
Hinweis Die automatische Anpassung der Verweise in anderen Testsuiten funktioniert nur, wenn diese zum selben Projekt gehören oder das Attribut 'Abhängige Dateien (umgekehrte Includes)' des 'Testsuite' Knotens korrekt gesetzt ist.
| | | | | | | Letzte Änderung: 23.4.2024 Copyright © 1999-2024 Quality First Software GmbH |
