Überprüfen Sie, ob das Element vorhanden ist, und warten Sie auf den Befehl Selenium
⚡ Intelligente Zusammenfassung
Überprüfen Sie das vorhandene Element und die waitFor-Befehle in Selenium Die IDE prüft, ob eine Seite die vom Test erwarteten Elemente und Texte enthält, und pausiert die Wiedergabe, bis eine dynamische Bedingung erfüllt ist, bevor der nächste Schritt ausgeführt wird.

Eine aufgezeichnete Selenium IDE Das Skript klickt und tippt, entscheidet aber selbstständig nicht, ob sich die Anwendung korrekt verhalten hat. Zwei Befehlsfamilien übernehmen diese Aufgabe: überprüfen Befehle, die den Zustand der Seite überprüfen, und warten Befehle, deren Ausführung so lange verzögert wird, bis die Seite zur Überprüfung bereit ist.
⚠️ Hinweis zu den Versionen: Die folgenden Screenshots stammen aus dem Original. Firefox-Plugin Selenium Die IDE wird nicht mehr vertrieben und verwendet deren CamelCase-Selenese-Namen. Die aktuelle IDE ist Chrome. Firefox und Kante BrowsererweiterungDas hier beschriebene Verhalten gilt weiterhin, jedoch haben sich einige Befehlsnamen geändert – eine Karteping Die Tabelle erscheint später in diesem Artikel, und jeder Originalbefehl und Screenshot wird genau so beibehalten, wie er veröffentlicht wurde.
Überprüfen Sie das Vorhandensein eines Elements
Um das Vorhandensein eines Elements zu überprüfen, können wir die folgenden beiden Befehle verwenden:
- überprüfenElementPresent – gibt TRUE zurück, wenn das angegebene Element auf der Seite GEFUNDEN wurde, andernfalls FALSE
- überprüfenElementNotPresent – gibt TRUE zurück, wenn das angegebene Element nirgendwo auf der Seite GEFUNDEN wurde; FALSE, wenn es vorhanden ist.
Beide Befehle benötigen ein Element Locator in England, Target Feld – eine ID, ein Name, ein CSS-Selektor, ein Linktext oder ein XPath Ausdruck — und keiner von beiden benötigt einen Wert.
Das folgende Testskript überprüft, ob das Textfeld Benutzername im Mercury Tours Homepage, während das Textfeld Vorname nicht vorhanden ist. Das Textfeld Vorname ist eigentlich ein Element auf der Registrierungsseite von Mercury Touren, nicht auf der Homepage.
Denn das sind sie überprüfen Befehle statt behaupten Bei einem Fehler wird dieser im Protokoll vermerkt, die restlichen Schritte werden jedoch weiterhin ausgeführt. Diese Unterscheidung wird weiter unten ausführlich erläutert.
Überprüfen Sie das Vorhandensein eines bestimmten Texts im Befehl in Selenium
Die Überprüfung, ob ein Element existiert, reicht nicht immer aus – ein Test muss oft die dem Benutzer angezeigten Wörter bestätigen. Zwei Textbefehle decken diesen Fall ab.
- überprüfenTextPresent – gibt TRUE zurück, wenn die angegebene Textzeichenfolge irgendwo auf der Seite GEFUNDEN wurde; andernfalls FALSE
- überprüfenTextNotPresent – gibt TRUE zurück, wenn die angegebene Textzeichenfolge NICHT irgendwo auf der Seite GEFUNDEN wurde; FALSE, wenn es gefunden wurde
Denken Sie daran, dass bei diesen Befehlen die Groß-/Kleinschreibung beachtet werden muss.
Das untenstehende Protokoll zeigt, dass dieselbe Seite zweimal mit zwei verschiedenen Schreibweisen desselben Ausdrucks überprüft wurde.
Im obigen Szenario wurde „Atlanta nach Las Vegas“ anders behandelt als „atlanta nach Las Vegas“, da der Buchstabe „A“ in „Atlanta“ im ersten Fall großgeschrieben, im zweiten jedoch kleingeschrieben war. Bei Anwendung des Befehls „verifyTextPresent“ auf beide Fälle war einer erfolgreich, der andere jedoch fehlgeschlagen.
Überprüfen Sie die spezifische Position eines Elements
Layoutfehler führen selten zum Ausfall eines Locators, daher werden sie bei Anwesenheitsprüfungen nicht erkannt. Positionsbefehle schließen diese Lücke.
Selenium Die IDE gibt die Position eines Elements an, indem sie (in Pixel) misst, wie weit es vom linken oder oberen Rand des Browserfensters entfernt ist.
- überprüfenElementPositionLeft – überprüft, ob die angegebene Pixelanzahl mit dem Abstand des Elements vom linken Rand der Seite übereinstimmt. Dies gibt FALSE zurück, wenn der angegebene Wert nicht mit dem Abstand vom linken Rand übereinstimmt.
- verifyElementPositionTop – überprüft, ob die angegebene Pixelanzahl mit dem Abstand des Elements vom oberen Rand der Seite übereinstimmt. Dies gibt FALSE zurück, wenn der angegebene Wert nicht mit dem Abstand vom oberen Rand übereinstimmt.
Das unten stehende Skript speichert die erwarteten Pixel-Offsets in der Spalte „Wert“.
Gehen Sie mit diesen beiden Befehlen vorsichtig um. Der Pixelversatz ändert sich mit der Fenstergröße, dem Zoomfaktor und den installierten Schriftarten, daher kann eine fest codierte Zahl, die auf einem Rechner funktioniert, auf einem anderen fehlschlagen.
Warten Sie auf Befehle Selenium
Ein Überprüfungsbefehl kann nur das prüfen, was bereits auf dem Bildschirm angezeigt wird. Daher schlägt eine zu früh ausgeführte Überprüfung fehl, obwohl die Anwendung funktioniert. Wartebefehle lösen dieses Timing-Problem.
Im Folgenden sind die Arten von Wartebefehlen in Selenium
andWait-Befehle
Dies sind Befehle, die darauf warten, dass eine neue Seite geladen wird, bevor sie mit dem nächsten Befehl fortfahren.
Beispiele
- clickAndWait
- typeAndWait
- selectAndWait
Jeder einzelne davon ist ein gewöhnlicher Aktionsbefehl mit dem Suffix AndWait, wie der unten aufgezeichnete Schritt zeigt.
waitFor-Befehle
Dies sind Befehle, die darauf warten, dass eine bestimmte Bedingung wahr wird, bevor sie mit dem nächsten Befehl fortfahren (unabhängig vom Laden einer neuen Seite). Diese Befehle eignen sich besser für die Verwendung auf AJAX-basierten dynamischen Websites, die Werte und Elemente ändern, ohne die gesamte Seite neu zu laden. Beispiele beinhalten:
- waitForTitle
- waitForTextPresent
- waitForAlert
Betrachten Sie das folgende Facebook-Szenario.
Wir können eine Kombination aus „click“ und „waitForTextPresent“ verwenden, um das Vorhandensein des Textes „Geburtstag angeben“ zu überprüfen.
Wir können clickAndWait nicht verwenden, da beim Klicken auf „Warum muss ich mein Geburtsdatum angeben?“ keine Seite geladen wurde. Verknüpfung. Wenn wir das tun, wird der Test fehlschlagen
Die gleiche Regel gilt für alle Inhalte, die per Skript und nicht durch Navigation eingefügt werden, weshalb AJAX-gesteuerte Bildschirme Man muss fast immer waitFor anstelle von andWait verwenden.
Assert-, Verify- und waitFor-Befehle in Selenium IDE
Anfänger wählen oft die falsche Produktfamilie und wundern sich dann, warum eine Suite beim ersten Defekt abbricht oder warum sie zwanzig Fehler meldet, die alle nicht behoben wurden. trace zurück zu eins. Die drei Präfixe beantworten drei verschiedene Fragen.
| Vorsilbe | Was sie tut, | Im Fehlerfall | am besten geeignet für |
|---|---|---|---|
| behaupten | Prüft sofort einen Zustand | Protokolliert den Fehler und beendet den Testfall. | Vorbedingungen – ein Login, der erfolgreich sein muss, bevor irgendetwas anderes Sinn ergibt |
| überprüfen | Prüft sofort einen Zustand | Protokolliert den Fehler und fährt mit dem nächsten Befehl fort. | Unabhängige Prüfungen, wie z. B. mehrere Etiketten auf einer Bestätigungsseite |
| warteAuf | Umfragen, bis die Bedingung erfüllt ist | Der Fehler wird nach Ablauf des Timeouts protokolliert, anschließend wird fortgefahren. | Alles, was verspätet erscheint – AJAX-Antworten, Ladekreise, Dialoge |
Ein praktisches Vorgehen kombiniert alle drei Schritte: Zuerst wird die Zielseite überprüft, dann wird auf das asynchron eintreffende Element gewartet und anschließend jedes einzelne Feld geprüft. Diese Reihenfolge führt dazu, dass ein fehlerhafter Navigationsvorgang den Test frühzeitig abbricht, während einige kosmetische Abweichungen in einem einzigen Durchlauf gemeldet werden. Dieselbe Vorgehensweise gilt auch für … Selenium Tests, die in Code geschrieben sind, wobei die Entsprechungen harte Zusicherungen, weiche Zusicherungen und explizite Wartezeiten sind.
Befehle zum Überprüfen und Warten im aktuellen Selenium IDE
Das FirefoxDas IDE-Plugin, das die obigen Screenshots erstellt hat, wurde eingestellt, und der Befehlssatz wurde für die aktuelle Browsererweiterung neu erstellt. Einige Selenese-Namen blieben erhalten, einige wurden umbenannt und einige wenige entfernt. Die folgende Tabelle ordnet die in diesem Artikel verwendeten Befehle ihren aktuellen Entsprechungen aus der offiziellen Dokumentation zu. Selenium IDE-Befehlsreferenz.
| Legacy Selenese-Befehl | Befehl in der aktuellen IDE |
|---|---|
| überprüfenElementPresent | Element überprüfen |
| überprüfenElementNotPresent | Prüfen, ob das Element nicht vorhanden ist |
| überprüfenTextPresent | Text überprüfen (bezogen auf einen Element-Locator, nicht auf die gesamte Seite) |
| überprüfenTextNotPresent | Überprüfung, ob es sich nicht um Text handelt (bezogen auf einen Element-Locator) |
| Titel überprüfen | Titel überprüfen |
| verifyElementPositionLeft / verifyElementPositionTop | Kein Äquivalent – Positionsbehauptungen wurden fallen gelassen. |
| Klicken und Warten, Tippen und Warten, Auswählen und Warten | Kein AndWait-Suffix – der Befehl open wartet bereits auf das Laden der Seite. |
| waitForElementPresent | Warten auf Vorhandensein des Elements, mit einer Wartezeit in Millisekunden. |
| waitForAlert | Warnmeldung bestätigen oder Warnmeldungstext überprüfen, nachdem das Dialogfeld angezeigt wird |
Zwei Unterschiede sind im Arbeitsalltag besonders wichtig. Erstens: Die bisherigen Wartebefehle – „Auf Element warten“, „Auf Element sichtbar warten“, „Auf Element bearbeitbar warten“ und ihre negativen Entsprechungen – benötigen jeweils eine explizite Wartezeit in Millisekunden. Dadurch muss ein langsamer Schritt nicht mehr mit einem globalen Timeout geteilt werden. Zweitens: Die seitenweite Textsuche entfällt: Die Überprüfung von Text erfordert nun einen Locator, was ohnehin meist präzisere Ergebnisse liefert.
Häufige Fehler bei den Befehlen „Verify“ und „waitFor“
Die meisten gemeldeten Probleme mit diesen Befehlen sind keine Fehler der IDE. Die folgende Liste beschreibt die häufigsten Fehler und deren Behebung.
- Das Element existiert, aber die Prüfung schlägt trotzdem fehl. Präsenz und Sichtbarkeit sind unterschiedliche Zustände. Ein Element, das durch eine CSS-Regel ausgeblendet ist, ist dennoch im DOM vorhanden. Daher sollte die Präsenzprüfung mit dem Warten auf die Sichtbarkeit des Elements kombiniert werden, wenn der Test davon abhängt, dass der Benutzer es tatsächlich sieht.
- Eine Textprüfung schlägt bei identisch aussehenden Formulierungen fehl. Geschützte Leerzeichen, nachfolgende Leerzeichen und typografische Apostrophe, die aus einem Designdokument kopiert wurden, führen zu einer fehlerhaften Übereinstimmung. Geben Sie die erwartete Zeichenkette manuell ein, anstatt sie einzufügen.
- Ein Wartebefehl schlägt auf einer Seite fehl, die eindeutig geladen wurde. Das Element befindet sich üblicherweise innerhalb eines iFrames. Führen Sie zuerst `select frame` aus, da der Locator sonst für das falsche Dokument ausgewertet wird.
- clickAndWait hängt sich bei einer Single-Page-Anwendung auf. Es findet keine Navigation statt, daher gibt es auch nichts zu warten. Ersetzen Sie dies durch einen Klick und den entsprechenden waitFor-Befehl.
- Ein Positionscheck wird lokal erfolgreich durchgeführt, schlägt aber auf dem Build-Server fehl. Bildschirmgröße und Schriftdarstellung variieren. Verwenden Sie daher am besten eine Anwesenheits- oder Textprüfung oder legen Sie zu Beginn des Tests eine explizite Fenstergröße fest.
- Die gesamte Suite scheitert an der ersten Diskrepanz. Es wurde ein Assert-Befehl anstelle eines Verify-Befehls ausgeführt. Ändern Sie das Präfix, dann meldet der Lauf alle Fehler anstatt nur den ersten.
Sobald ein Drehbuch diese Hürden überstanden hat, besteht der nächste Schritt in der Regel darin, Laufzeitwerte in Variablen speichern Die Prüfungen vergleichen also reale Daten anstatt fest codierter Zeichenketten.






