Ü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.

  • 🔘 Elementprüfungen: verifyElementPresent gibt TRUE zurück, wenn der Locator auf etwas auf der Seite zutrifft, und verifyElementNotPresent ist das genaue Gegenteil.
  • ☑️ Textprüfungen: verifyTextPresent durchsucht die gesamte Seite und unterscheidet zwischen Groß- und Kleinschreibung, daher findet sich „Atlanta“ niemals in „atlanta“.
  • ✅ Positionsprüfungen: verifyElementPositionLeft und verifyElementPositionTop vergleichen den Pixelabstand eines Elements vom Seitenrand.
  • 🧪 Seiten laden: Befehle wie clickAndWait pausieren das Skript, bis eine neue Seite vollständig geladen ist.
  • ️ Dynamischer Inhalt: waitFor-Befehle warten auf eine Bedingung anstatt auf das Laden der Seite, was für AJAX-Bildschirme geeignet ist, die nie neu geladen werden.
  • 📊 Aktuelle IDE: Die Browsererweiterung benennt diese Schritte um und weist jedem Wartebefehl ein eigenes Millisekunden-Timeout zu.

Überprüfen Sie, ob das Element vorhanden ist, und führen Sie den Befehl waitFor aus. Selenium IDE

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.

Selenium IDE-Skript, das verifyElementPresent für das Feld "Benutzername" und verifyElementNotPresent für das Feld "Vorname" verwendet.

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.

Selenium Das IDE-Protokoll zeigt, dass verifyTextPresent für die Verbindung von Atlanta nach Las Vegas erfolgreich ist, für die Verbindung von Atlanta nach Las Vegas jedoch fehlschlägt.

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“.

Selenium IDE-Schritte, die verifyElementPositionLeft und verifyElementPositionTop mit Pixelwerten in der Spalte „Wert“ verwenden.

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.

Aufgezeichneter Klick-und-Warten-Schritt, bei dem die Taste gedrückt gehalten wurde Selenium IDE-Skript, bis die nächste Seite vollständig geladen ist.

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.

Facebook-Anmeldeformular mit der Meldung „Warum muss ich mein Geburtsdatum angeben?“, bevor der Link angeklickt wird.

Wir können eine Kombination aus „click“ und „waitForTextPresent“ verwenden, um das Vorhandensein des Textes „Geburtstag angeben“ zu überprüfen.

Selenium IDE-Schritte: Klicken Sie auf „waitForTextPresent“, um auf die Eingabe Ihres Geburtstagstextes zu warten.

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.

Häufig gestellte Fragen

Die alte IDE verwendete ein gemeinsames globales Timeout für alle waitFor-Schritte, das mit dem Befehl setTimeout geändert werden konnte. Die aktuelle Erweiterung verwendet für jeden wait-Befehl eine explizite Wartezeit in Millisekunden, sodass ein einzelner langsamer Bildschirm nicht mehr dazu führt, dass alle anderen Schritte genauso lange warten müssen.

Nein. Die Pause-Funktion wartet immer die volle Dauer, was Zeitverschwendung bei schnellen Seitenladezeiten bedeutet und bei langsamen Seitenladezeiten fehlschlägt. Verwenden Sie sie nur, um einen einzelnen Schritt während einer Demo zu demonstrieren, niemals in einer Testreihe, die Sie wiederholt ausführen möchten.

Nein. Präsenz bedeutet, dass der Knoten im DOM existiert, was auch für Elemente gilt, die durch CSS ausgeblendet oder außerhalb des sichtbaren Bereichs positioniert sind. Wenn der Test davon abhängt, dass der Benutzer etwas sieht, fügen Sie zusätzlich zur Präsenzprüfung eine Wartezeit hinzu, bis das Element sichtbar ist.

Ja, und die aktuelle IDE erfordert dies. Ihr Befehl zur Textprüfung benötigt einen Elementlocator und die erwartete Zeichenkette. Dies ist strenger als die alte seitenweite Suche und verhindert, dass ein irrelevanter Menüpunkt eine Prüfung besteht, für die er nie vorgesehen war.

Code Der Export wandelt jeden Befehl in eine entsprechende Anweisung in der Zielsprache um, sodass ein Warteschritt zu einem expliziten WebDriver-Wartevorgang wird. Lesen Sie die generierte Datei sorgfältig durch, bevor Sie ihr vertrauen, da Timeouts und das Verhalten bei weichen bzw. harten Fehlern die Übersetzung nicht immer vollständig überstehen.

Maschinelle Lernmodelle analysieren historische Ausführungsdaten und kennzeichnen Schritte, die nur sporadisch statt konsistent fehlschlagen – ein typisches Anzeichen für fehlende Wartezeiten. Die KI-gestützte Locator-Reparatur behebt die andere häufige Ursache, indem sie bei Änderungen der Markierung einen neuen Selektor vorschlägt.

Den mechanischen Teil bewältigt es gut – es wandelt einen Warteschritt in ein WebDriverWait mit einer erwarteten Bedingung um. RevBeachten Sie das gewählte Timeout und die gewählte Bedingung, da eine generierte Präsenzbedingung oft stattdessen eine Sichtbarkeitsbedingung sein muss.

Locators werden anhand des aktuell ausgewählten Dokuments ausgewertet, wobei ein iFrame ein separates Locator-Objekt darstellt. Führen Sie zuerst den Befehl zum Auswählen des Frames und anschließend die Überprüfung aus. Kehren Sie danach zum obersten Dokument zurück, damit die folgenden Schritte nicht im falschen Kontext durchgeführt werden.

Fassen Sie diesen Beitrag mit folgenden Worten zusammen: