Element aanwezig en wachten op commando in Selenium

⚡ Slimme samenvatting

Controleer of het element aanwezig is en wacht op de commando's in Selenium De IDE controleert of een pagina de elementen en tekst bevat die een test verwacht, en pauzeert de weergave totdat een dynamische voorwaarde waar is voordat de volgende stap wordt uitgevoerd.

  • 🔘 Elementcontroles: verifyElementPresent retourneert TRUE wanneer de locator overeenkomt met iets op de pagina, en verifyElementNotPresent is precies het tegenovergestelde.
  • ☑️ Tekstcontroles: verifyTextPresent doorzoekt de hele pagina en is hoofdlettergevoelig, dus "Atlanta" komt nooit overeen met "atlanta".
  • ✅ Positiecontroles: verifyElementPositionLeft en verifyElementPositionTop vergelijken de pixelafstand van een element tot de paginarand.
  • 🧪 Pagina laadt: Commando's zoals clickAndWait pauzeren het script totdat een nieuwe pagina volledig is geladen.
  • ️ Dynamische inhoud: waitFor-opdrachten wachten op een bepaalde voorwaarde in plaats van op het laden van de pagina, wat geschikt is voor AJAX-schermen die nooit opnieuw laden.
  • 📊 Huidige IDE: De browserextensie hernoemt deze stappen en geeft elk wachtcommando een eigen time-out in milliseconden.

Controleer of het element aanwezig is en of het waitFor-commando aanwezig is. Selenium IDE

Een opgenomen Selenium IDE Het script klikt en typt, maar bepaalt zelf nooit of de applicatie correct heeft gehandeld. Twee commandofamilies doen dat wel: controleren commando's die de status van de pagina controleren, en wachten commando's die de uitvoering opschorten totdat de pagina gereed is om te worden gecontroleerd.

⚠️ Een opmerking over versies: De onderstaande schermafbeeldingen zijn afkomstig van het origineel. Firefox-inpluggen Selenium IDE, die niet langer wordt gedistribueerd, en ze gebruiken daarvoor de camelCase Selenese-namen. De huidige IDE is Chrome. Firefox en Rand browserextensieHet hier beschreven gedrag is nog steeds van toepassing, maar verschillende commandonamen zijn gewijzigd — een kaartping De tabel verschijnt later in dit artikel, en elk origineel commando en elke schermafbeelding is exact zoals gepubliceerd bewaard gebleven.

Controleer de aanwezigheid van een element

We kunnen de volgende twee opdrachten gebruiken om de aanwezigheid van een element te verifiëren:

  • verificatieElementPresent – retourneert TRUE als het opgegeven element op de pagina is GEVONDEN; FALSE als dit niet het geval is
  • verifieerElementNotPresent – retourneert WAAR als het opgegeven element nergens op de pagina GEVONDEN is; FALSE als het aanwezig is.

Beide commando's nemen een element als argument. locator in de Target veld — een id, een naam, een CSS-selector, een linktekst of een XPath uitdrukking — en geen van beide heeft een waarde nodig.

Het onderstaande testscript controleert of het tekstvak Gebruikersnaam aanwezig is in de Mercury Tours homepage terwijl het Voornaam tekstvak niet is. Het Voornaam tekstvak is eigenlijk een element aanwezig op de Registratiepagina van Mercury Rondleidingen, niet op de startpagina.

Selenium IDE-script dat verifyElementPresent gebruikt op het veld 'userName' en verifyElementNotPresent op het veld 'First Name'.

Omdat dit zijn controleren commando's in plaats van beweren Bij commando's wordt een foutmelding in het logboek vastgelegd, maar de resterende stappen worden wel uitgevoerd. Dit onderscheid wordt verderop in detail besproken.

Controleer de aanwezigheid van een bepaalde tekst in opdracht in Selenium

Controleren of een element bestaat is niet altijd voldoende; een test moet vaak ook de woorden bevestigen die aan de gebruiker worden getoond. Twee tekstcommando's dekken dat geval af.

  • verifieerTextPresent – retourneert TRUE als de opgegeven tekststring ergens op de pagina is GEVONDEN; FALSE als dit niet het geval is
  • verifieerTextNotPresent – retourneert WAAR als de opgegeven tekstreeks NIET ergens op de pagina is GEVONDEN; FALSE als het werd gevonden

Houd er rekening mee dat deze opdrachten hoofdlettergevoelig zijn.

Onderstaande log toont dezelfde pagina die twee keer is gecontroleerd met twee verschillende spellingen van dezelfde zin.

Selenium IDE-logboek toont aan dat verifyTextPresent slaagt voor Atlanta naar Las Vegas en mislukt voor Atlanta naar Las Vegas.

In het bovenstaande scenario werd "Atlanta to Las Vegas" anders behandeld dan "atlanta to Las Vegas", omdat de letter "A" in "Atlanta" in de eerste zin een hoofdletter was en in de andere een kleine letter. Toen de opdracht verifyTextPresent op beide zinnen werd toegepast, slaagde de ene voor de eerste en faalde de andere.

Controleer de specifieke positie van een element

Lay-outdefecten zorgen er zelden voor dat een locator niet werkt, waardoor aanwezigheidscontroles ze missen. Positiecommando's dichten die lacune.

Selenium IDE geeft de positie van een element aan door (in pixels) te meten hoe ver het zich van de linker- of bovenrand van het browservenster bevindt.

  • verificatieElementPositionLeft – verifieert of het opgegeven aantal pixels overeenkomt met de afstand van het element vanaf de linkerrand van de pagina. Dit retourneert FALSE als de opgegeven waarde niet overeenkomt met de afstand vanaf de linkerrand.
  • VerifiërenElementPositieBoven – verifieert of het opgegeven aantal pixels overeenkomt met de afstand van het element vanaf de bovenrand van de pagina. Dit retourneert FALSE als de opgegeven waarde niet overeenkomt met de afstand vanaf de bovenrand.

Het onderstaande script registreert de verwachte pixeloffsets in de kolom 'Waarde'.

Selenium IDE-stappen die verifyElementPositionLeft en verifyElementPositionTop gebruiken met pixelwaarden in de kolom Waarde.

Wees voorzichtig met deze twee commando's. Een pixeloffset verandert met de venstergrootte, het zoomniveau en de geïnstalleerde lettertypen, dus een vastgelegde waarde die op de ene machine werkt, kan op een andere machine een foutmelding geven.

Wachtcommando's binnen Selenium

Een verificatieopdracht kan alleen controleren wat al op het scherm te zien is, dus een controle die te vroeg wordt uitgevoerd, mislukt, ook al werkt de applicatie wel. Wachtopdrachten lossen dat timingprobleem op.

Hieronder staan ​​de typen wachtopdrachten in Selenium

en Wacht-opdrachten

Dit zijn opdrachten die wachten tot een nieuwe pagina is geladen voordat ze naar de volgende opdracht gaan.

Voorbeelden zijn

  • klikEnWacht
  • typEnWacht
  • selecteerEnWacht

Elk van deze commando's is een gewoon actiecommando met het achtervoegsel AndWait, zoals de onderstaande opgenomen stap laat zien.

Opgenomen clickAndWait-stap met ingedrukte muisknop Selenium IDE-script totdat de volgende pagina volledig is geladen

waitFor-opdrachten

Dit zijn opdrachten die wachten tot een bepaalde voorwaarde waar wordt voordat ze doorgaan naar de volgende opdracht (ongeacht het laden van een nieuwe pagina). Deze opdrachten zijn geschikter voor gebruik op AJAX-gebaseerde dynamische websites die waarden en elementen wijzigen zonder de hele pagina opnieuw te laden. Voorbeelden zijn onder meer:

  • wacht op titel
  • waitForTextPresent
  • wachtVoorAlert

Beschouw het Facebook-scenario hieronder.

Het Facebook-aanmeldingsformulier toont de link 'Waarom moet ik mijn geboortedatum opgeven?' voordat erop geklikt kan worden.

We kunnen een combinatie van “click” en “waitForTextPresent” gebruiken om de aanwezigheid van de tekst “Providing your birthday” te verifiëren.

Selenium IDE-stappen die klikken combineren met waitForTextPresent om te wachten tot de tekst van je verjaardag is ingevoerd

We kunnen clickAndWait niet gebruiken omdat er geen pagina is geladen toen we op de vraag "Waarom moet ik mijn verjaardag opgeven?" klikken. koppeling. Als we dat doen, mislukt de test

Dezelfde regel geldt voor alle inhoud die via een script wordt ingevoegd in plaats van via navigatie, en daarom AJAX-gestuurde schermen Je hebt bijna altijd waitFor nodig in plaats van andWait.

Assert-, Verify- en waitFor-opdrachten in Selenium IDE

Beginners kiezen vaak de verkeerde testfamilie en vragen zich vervolgens af waarom een ​​testsuite bij het eerste defect stopt, of waarom er twintig fouten worden gemeld die allemaal trace terug naar één. De drie voorvoegsels beantwoorden drie verschillende vragen.

Landcode Wat het doet Bij mislukking Best gebruikt voor
beweren Controleert direct een toestand Registreert de fout en stopt de testcase. Voorwaarden — een inlogprocedure die moet slagen voordat al het andere zinvol is.
controleren Controleert direct een toestand Registreert de fout en gaat verder met de volgende opdracht. Onafhankelijke controles, zoals meerdere labels op één bevestigingspagina.
wachten Peilingen totdat de situatie zich voordoet. Het programma registreert de fout zodra de time-out is verlopen en gaat vervolgens verder. Alles wat vertraagd lijkt te verschijnen — AJAX-reacties, laadindicatoren, dialoogvensters

Een praktische aanpak combineert alle drie: controleer de pagina waarop je bent terechtgekomen, wacht op het element dat asynchroon binnenkomt en controleer vervolgens elk afzonderlijk veld. Door het in die volgorde te doen, zorgt één fout in de navigatie ervoor dat de test vroegtijdig stopt, terwijl een handvol cosmetische afwijkingen allemaal in één keer worden gerapporteerd. Dezelfde discipline geldt voor... Selenium Tests geschreven in code, waarbij de equivalenten harde beweringen, zachte beweringen en expliciete wachttijden zijn.

Verifieer en wacht-opdrachten in de huidige Selenium IDE

De FirefoxDe plugin IDE die de bovenstaande schermafbeeldingen produceerde, is niet langer in gebruik en de commandoset is opnieuw opgebouwd voor de huidige browserextensie. Verschillende Selenese-namen zijn behouden gebleven, sommige zijn hernoemd en een paar zijn verwijderd. De onderstaande tabel koppelt de in dit artikel gebruikte commando's aan hun huidige equivalenten, afkomstig uit de officiële documentatie. Selenium IDE-opdrachtreferentie.

Legacy Selenese commando Opdracht in de huidige IDE
verificatieElementPresent controleer of het element aanwezig is
verifieerElementNotPresent Controleer of het element niet aanwezig is
verifieerTextPresent Controleer de tekst (beperkt tot een elementlocator, niet de hele pagina).
verifieerTextNotPresent controleren of het geen tekst is (beperkt tot een elementlocator)
verifieerTitel titel verifiëren
verifyElementPositionLeft / verifyElementPositionTop Geen equivalent — standpuntbeweringen werden ingetrokken
klikEnWacht, typEnWacht, selecteerEnWacht Geen AndWait-achtervoegsel — de open-opdracht wacht al op het laden van de pagina.
waitForElementPresent Wacht tot het element aanwezig is, met een wachttijd in milliseconden.
wachtVoorAlert Bevestig de waarschuwingstekst of verifieer de waarschuwingstekst nadat het dialoogvenster verschijnt.

Twee verschillen zijn het belangrijkst in het dagelijks werk. Ten eerste hebben de huidige wachtopdrachten — wacht tot een element aanwezig is, wacht tot een element zichtbaar is, wacht tot een element bewerkbaar is en hun negatieve tegenhangers — elk een expliciete wachttijd in milliseconden, waardoor een langzame stap niet langer één globale time-out hoeft te delen. Ten tweede is de paginabrede tekstzoekfunctie verdwenen: voor het verifiëren van tekst is een locator nodig, wat doorgaans toch al een scherpere controle oplevert.

Veelvoorkomende fouten bij de commando's Verify en waitFor

De meeste gemelde problemen met deze commando's zijn geen defecten in de IDE. De onderstaande lijst bevat de meest voorkomende fouten en de bijbehorende oplossingen.

  • Het element bestaat wel, maar de controle mislukt toch. Aanwezigheid en zichtbaarheid zijn verschillende toestanden. Een element dat verborgen is achter een CSS-regel is nog steeds aanwezig in de DOM. Combineer daarom de aanwezigheidscontrole met een wachttest tot het element zichtbaar is wanneer de test ervan afhangt dat de gebruiker het daadwerkelijk ziet.
  • Een tekstcontrole mislukt bij formuleringen die er identiek uitzien. Niet-brekende spaties, spaties aan het einde en gekrulde apostrofen die uit een ontwerpdocument zijn gekopieerd, zorgen ervoor dat een exacte overeenkomst niet werkt. Typ de verwachte tekenreeks handmatig over in plaats van deze te plakken.
  • Een wachtopdracht geeft een time-out op een pagina die duidelijk wel geladen is. Het element bevindt zich meestal in een iframe. Voer eerst `select frame` uit, anders wordt de locator geëvalueerd ten opzichte van het verkeerde document.
  • clickAndWait blijft hangen bij een applicatie met één pagina. Er vindt geen navigatie plaats, dus er is niets om op te wachten. Vervang dit door een klik plus het bijbehorende waitFor-commando.
  • Een positiecontrole slaagt lokaal, maar mislukt op de buildserver. Schermgrootte en lettertypeweergave verschillen. Geef de voorkeur aan een aanwezigheids- of tekstcontrole, of stel een expliciete venstergrootte in aan het begin van de test.
  • De hele reeks stopt bij de eerste mismatch. Er werd een assert-commando geregistreerd waar een verify-commando bedoeld was. Wijzig het voorvoegsel en de uitvoering zal elke fout rapporteren in plaats van alleen de eerste.

Als een script deze valkuilen eenmaal heeft doorstaan, is de volgende stap meestal om Sla runtimewaarden op in variabelen. De controles vergelijken dus met echte gegevens in plaats van met vastgelegde tekenreeksen.

Veelgestelde vragen

De oude IDE deelde één globale time-out voor elke waitFor-stap, die werd gewijzigd met de setTimeout-opdracht. De huidige extensie vereist een expliciete wachttijd in milliseconden voor elke wait-opdracht, waardoor een enkel traag scherm er niet langer voor zorgt dat elke volgende stap even lang moet wachten.

Nee. Pauzeer altijd gedurende de volledige duur, dus het kost tijd als de pagina snel laadt en werkt nog steeds niet als de pagina traag laadt. Gebruik het alleen om een ​​stap te demonstreren tijdens een demo, nooit in een suite die je herhaaldelijk wilt uitvoeren.

Nee, dat klopt niet. 'Presence' betekent dat het element in de DOM aanwezig is, wat ook geldt voor elementen die door CSS verborgen zijn of buiten beeld gepositioneerd zijn. Als de test afhankelijk is van het feit of de gebruiker iets ziet, voeg dan naast de aanwezigheidscontrole ook een 'wacht tot het element zichtbaar is'-controle toe.

Ja, en de huidige IDE vereist het. De opdracht 'verify text' vereist een elementlocator plus de verwachte tekenreeks, wat strenger is dan de oude paginabrede zoekopdracht en voorkomt dat een irrelevant menu-item voldoet aan een controle waaraan het nooit had moeten voldoen.

Code Export zet elk commando om in een equivalente instructie in de doeltaal, waardoor een wachtstap een expliciete WebDriver-wacht wordt. Lees het gegenereerde bestand voordat u het vertrouwt, want time-outs en het verschil tussen soft- en hard-failures blijven niet altijd intact na de vertaling.

Machine learning-modellen lezen historische uitvoeringsgegevens en markeren de stappen die intermitterend in plaats van consistent mislukken, wat een teken is van een ontbrekende wachtfunctie. AI-ondersteunde locatorreparatie pakt de andere veelvoorkomende oorzaak aan door een nieuwe selector voor te stellen wanneer de markup verandert.

Het handelt het mechanische gedeelte goed af — het zet een wachtstap om in een WebDriverWait met een verwachte voorwaarde. RevBekijk de time-out die het systeem kiest en de voorwaarde die het selecteert, aangezien een gegenereerde aanwezigheidsvoorwaarde vaak een zichtbaarheidsvoorwaarde moet zijn.

Locators worden geëvalueerd ten opzichte van het momenteel geselecteerde document, en een iframe is een apart document. Voer eerst de opdracht voor het selecteren van het frame uit, vervolgens de controle, en ga daarna terug naar het hoofddocument, zodat de volgende stappen niet in de verkeerde context worden uitgevoerd.

Vat dit bericht samen met: