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.
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.
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.
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'.
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.
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.
We kunnen een combinatie van “click” en “waitForTextPresent” gebruiken om de aanwezigheid van de tekst “Providing your birthday” te verifiëren.
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.






