Bekreft Element Present & waitFor Command in Selenium

⚡ Smart oppsummering

Bekreft at elementet er tilstede, og vent på kommandoene i Selenium IDE bekrefter at en side inneholder elementene og teksten en test forventer, og setter avspillingen på pause til en dynamisk betingelse blir sann før neste trinn kjøres.

🔘 Elementkontroller: verifyElementPresent returnerer TRUE når locatoren samsvarer med noe på siden, og verifyElementNotPresent er den eksakte inverse.
☑️ Tekstsjekker: verifyTextPresent søker gjennom hele siden og skiller mellom store og små bokstaver, så «Atlanta» samsvarer aldri med «atlanta».
✅ Posisjonskontroller: verifyElementPositionLeft og verifyElementPositionTop sammenligner et elements pikselforskyvning fra sidekanten.
🧪 Sideinnlastinger: andWait-kommandoer som clickAndWait setter skriptet på pause til en ny side er ferdig lastet inn.
🛠️ Dynamisk innhold: waitFor-kommandoer venter på en betingelse i stedet for en sideinnlasting, noe som passer for AJAX-skjermer som aldri lastes inn på nytt.
📊 Nåværende IDE: Nettleserutvidelsen gir disse trinnene nytt navn og gir hver ventekommando sin egen millisekund-timeout.

Les mer

Et innspilt Selenium IDE skriptet klikker og skriver, men avgjør aldri på egenhånd om applikasjonen oppførte seg riktig. To kommandofamilier gjør det arbeidet: verifisere kommandoer, som sjekker sidens tilstand, og vente kommandoer, som holder kjøringen inne til siden er klar til å bli sjekket.

⚠️ En merknad om versjoner: Skjermbildene nedenfor kommer fra originalen Firefox-plugin Selenium IDE, som ikke lenger distribueres, og de bruker dens camelCase Selenese-navn. Den nåværende IDE-en er en Chrome, Firefox og Edge nettleserutvidelseOppførselen som er beskrevet her gjelder fortsatt, men flere kommandonavn er endret – et kartping Tabellen vises senere i denne artikkelen, og alle originale kommandoer og skjermbilder er bevart nøyaktig slik de er publisert.

Bekreft tilstedeværelsen av et element

Vi kan bruke følgende to kommandoer for å bekrefte tilstedeværelsen av et element:

verifyElementPresent – returnerer TRUE hvis det angitte elementet ble FUNNET på siden; FALSE hvis annet
verifyElementNotPresent – returnerer TRUE hvis det angitte elementet IKKE ble FANT noe sted på siden; FALSE hvis den er til stede.

Begge kommandoene tar et element locator i Target felt – en ID, et navn, en CSS-velger, en lenketekst eller en XPath uttrykk – og ingen av dem trenger en verdi.

Testskriptet nedenfor bekrefter at UserName-tekstboksen er til stede i Mercury Tours hjemmeside mens Fornavn tekstboksen ikke er det. Tekstboksen Fornavn er faktisk et element som finnes på registreringssiden til Mercury Omvisninger, ikke på hjemmesiden.

Fordi disse er verifisere kommandoer heller enn hevde kommandoer, skrives en feil til loggen, og de gjenværende trinnene kjører fortsatt. Denne forskjellen dekkes i detalj lenger ned.

Bekreft tilstedeværelsen av en bestemt tekst i kommando i Selenium

Det er ikke alltid nok å sjekke at et element eksisterer – en test må ofte bekrefte ordene som vises til brukeren. To tekstkommandoer dekker dette tilfellet.

verifyTextPresent – returnerer TRUE hvis den angitte tekststrengen ble FANT et sted på siden; FALSE hvis annet
verifyTextNotPresent – returnerer TRUE hvis den angitte tekststrengen IKKE ble funnet noe sted på siden; FALSE hvis den ble funnet

Husk at disse kommandoene skiller mellom store og små bokstaver.

Loggen nedenfor viser den samme siden sjekket to ganger med to stavemåter av samme frasen.

I scenariet ovenfor ble «Atlanta til Las Vegas» behandlet annerledes enn «atlanta til Las Vegas» fordi bokstaven «A» i «Atlanta» var stor på den første, mens den var liten på den andre. Da verifyTextPresent-kommandoen ble brukt på hver av dem, bestod den ene, mens den andre mislyktes.

Bekreft spesifikk plassering av et element

Layoutfeil ødelegger sjelden en lokator, så tilstedeværelseskontroller bommer på dem. Posisjonskommandoer tetter dette gapet.

Selenium IDE indikerer posisjonen til et element ved å måle (i piksler) hvor langt det er fra venstre eller øvre kant av nettleservinduet.

verifyElementPositionLeft – bekrefter om det angitte antallet piksler samsvarer med avstanden til elementet fra venstre kant av siden. Dette vil returnere FALSE hvis verdien som er spesifisert ikke samsvarer med avstanden fra venstre kant.
verifyElementPositionTop – bekrefter om det angitte antallet piksler samsvarer med avstanden til elementet fra den øverste kanten av siden. Dette vil returnere FALSE hvis verdien som er spesifisert ikke samsvarer med avstanden fra toppkanten.

Skriptet nedenfor registrerer de forventede pikselforskyvningene i Verdi-kolonnen.

Behandle disse to kommandoene med forsiktighet. En pikselforskyvning endres med vindusstørrelsen, zoomnivået og de installerte skriftene, slik at et hardkodet tall som sendes på én maskin kan mislykkes på en annen.

Vent kommandoer inn Selenium

En verify-kommando kan bare inspisere det som allerede er på skjermen, så en sjekk som kjører for tidlig mislykkes selv om applikasjonen fungerer. Wait-kommandoer løser dette tidsproblemet.

Følgende er typene ventekommandoer i Selenium

og vent-kommandoer

Dette er kommandoer som vil vente til en ny side lastes inn før du går videre til neste kommando.

eksempler er

klikk og vent
typeAndWait
velg og vent

Hver og en av dem er en vanlig handlingskommando med AndWait-suffikset tilknyttet, som det registrerte trinnet nedenfor viser.

vente på kommandoer

Dette er kommandoer som venter på at en spesifisert tilstand blir sann før du fortsetter til neste kommando (uavhengig av lasting av en ny side). Disse kommandoene er mer passende å bruke på AJAX-baserte dynamiske nettsteder som endrer verdier og elementer uten å laste hele siden på nytt. Eksempler inkluderer:

vente på tittel
waitForTextPresent
vente på varsel

Tenk på Facebook-scenariet nedenfor.

Vi kan bruke en kombinasjon av «klikk» og «waitForTextPresent» for å bekrefte tilstedeværelsen av teksten «Oppgi bursdagen din».

Vi kan ikke bruke clickAndWait fordi ingen side ble lastet ved å klikke på "Hvorfor må jeg oppgi bursdagen min?" link. Hvis vi gjør det, vil testen mislykkes

Den samme regelen gjelder for alt innhold som injiseres av skript i stedet for navigasjon, og det er derfor AJAX-drevne skjermer trenger nesten alltid waitFor i stedet for andWait.

Assert vs. Verify vs. waitFor-kommandoer i Selenium IDE

Nybegynnere velger ofte feil familie og lurer deretter på hvorfor en suite stopper ved den første feilen, eller hvorfor den rapporterer tjue feil som alle tractilbake til én. De tre prefiksene svarer på tre forskjellige spørsmål.

Prefix	Hva det gjør	Ved feil	Best brukt til
hevde	Sjekker en tilstand umiddelbart	Logger feilen og stopper testtilfellet	Forutsetninger – en pålogging som må lykkes før noe annet gir mening
verifisere	Sjekker en tilstand umiddelbart	Logger feilen og fortsetter med neste kommando	Uavhengige kontroller, for eksempel flere etiketter på én bekreftelsesside
ventPå	Avstemninger inntil betingelsen blir sann	Logger feilen når tidsavbruddet utløper, og fortsetter deretter	Alt som dukker opp sent – AJAX-svar, spinnere, dialoger

Et praktisk mønster kombinerer alle tre: bekrefter siden du landet på, vent på elementet som ankommer asynkront, og deretter verifiserer du hvert enkelt felt. Å gjøre det i den rekkefølgen betyr at én ødelagt navigasjon stopper testen tidlig, mens en håndfull kosmetiske avvik rapporteres i én kjøring. Den samme disiplinen gjelder også for Selenium tester skrevet i kode, der ekvivalentene er harde påstander, myke påstander og eksplisitte ventinger.

Bekreft og vent-kommandoer i gjeldende Selenium IDE

Ocuco Firefox-plugin IDE som produserte skjermbildene ovenfor ble pensjonert, og kommandosettet ble gjenoppbygd for den nåværende nettleserutvidelsen. Flere selenske navn overlevde, noen ble omdøpt, og noen få ble fjernet. Tabellen nedenfor kartlegger kommandoene som brukes i denne artikkelen til deres nåværende ekvivalenter, hentet fra den offisielle Selenium IDE-kommandoreferanse.

Eldre selenisk kommando	Kommando i gjeldende IDE
verifyElementPresent	bekrefte elementet som er tilstede
verifyElementNotPresent	verifikasjonselementet er ikke tilstede
verifyTextPresent	bekrefte tekst (begrenset til en elementsøker, ikke hele siden)
verifyTextNotPresent	bekreft ikke tekst (beregnet til en elementsøker)
verifiserTittel	bekrefte tittel
verifisereElementposisjonVenstre / verifisereElementposisjonTopp	Ingen tilsvarende – posisjonspåstander ble droppet
klikkOgVent, skrivOgVent, velgOgVent	Ingen AndWait-suffiks – open-kommandoen venter allerede på at en side skal lastes inn
waitForElementPresent	vent på element til stede, med en ventetid i millisekunder
vente på varsel	hevde varsel eller bekrefte varseltekst etter at dialogboksen vises

To forskjeller er viktigst i det daglige arbeidet. For det første tar de nåværende ventekommandoene – vent på element tilstede, vent på element synlig, vent på element redigerbart og deres negative tvillinger – hver en eksplisitt ventetid i millisekunder, slik at et sakte trinn ikke lenger trenger å dele én global tidsavbrudd. For det andre er det sideomfattende tekstsøket borte: verifiser tekst trenger en locator, som vanligvis gir en skarpere sjekk uansett.

Vanlige feil med Verify- og waitFor-kommandoene

De fleste rapporterte problemene med disse kommandoene er ikke feil i IDE-en. Listen nedenfor dekker feilene som oppstår oftest og hva som løser hver enkelt.

Elementet finnes, men sjekken mislykkes fortsatt. Tilstedeværelse og synlighet er forskjellige tilstander. Et element som er skjult bak en CSS-regel er fortsatt tilstede i DOM-en, så koble tilstedeværelseskontrollen med vent på element som er synlig når testen er avhengig av at brukeren faktisk ser det.
En tekstsjekk mislykkes på ordlyd som ser identisk ut. Hart mellomrom, etterfølgende mellomrom og krøllete apostrofer kopiert fra et designdokument bryter alle en eksakt samsvar. Skriv inn den forventede strengen på nytt for hånd i stedet for å lime den inn.
En ventekommando får tidsavbrudd på en side som tydeligvis er lastet inn. Elementet er vanligvis inne i en iframe. Kjør select frame først, ellers blir locatoren evaluert mot feil dokument.
clickAndWait henger seg opp i et program med én side. Ingen navigering skjer, så det er ingenting å vente på. Erstatt det med et klikk pluss den riktige waitFor-kommandoen.
En posisjonssjekk består lokalt og mislykkes på byggeserveren. Skjermstørrelse og skriftgjengivelse varierer. Foretrekk en tilstedeværelses- eller tekstkontroll, eller angi en eksplisitt vindusstørrelse ved starten av testen.
Hele suiten stopper ved den første mismatchen. En assert-kommando ble registrert der en verifisere-kommando var ment. Bytt prefiks, og kjøringen vil rapportere alle feil i stedet for bare den første.

Når et skript overlever disse fellene, er neste trinn vanligvis å lagre kjøretidsverdier i variabler slik at kontrollene sammenlignes mot reelle data i stedet for hardkodede strenger.

Spørsmål og svar

Den eldre IDE-en delte én global timeout på tvers av hvert waitFor-trinn, noe som ble endret med setTimeout-kommandoen. Den nåværende utvidelsen tar en eksplisitt ventetid i millisekunder på hver wait-kommando, slik at en enkelt treg skjerm ikke lenger tvinger alle andre trinn til å vente like lenge.

Nei. Pause hviler alltid i hele varigheten, så den kaster bort tid når siden er rask, og feiler fortsatt når siden er treg. Bruk den bare for å demonstrere et trinn under en demonstrasjon, aldri i en pakke du har tenkt å kjøre gjentatte ganger.

Det gjør det ikke. Presence betyr at noden finnes i DOM-en, som forblir sant for elementer som er skjult av CSS eller plassert utenfor skjermen. Når testen er avhengig av at brukeren ser noe, legg til wait for element visible ved siden av presence-sjekken.

Ja, og den nåværende IDE-en krever det. Kommandoen «verify text» tar en elementsøker pluss den forventede strengen, som er strengere enn det gamle sideomfattende søket og hindrer et urelatert menyelement i å oppfylle en sjekk det aldri var ment å oppfylle.

Code `export` gjør hver kommando om til en tilsvarende setning i målspråket, slik at et `wait`-trinn blir en eksplisitt `WebDriver wait`. Les den genererte filen før du stoler på den, fordi `timeouts` og `soft-versus-hard`-feil ikke alltid overlever oversettelsen intakt.

Maskinlæringsmodeller leser historiske kjøredata og flagger trinnene som mislykkes av og til i stedet for konsekvent, noe som er et tegn på manglende ventetid. AI-assistert reparasjon av lokatorer takler den andre vanlige årsaken ved å foreslå en ny velger når markupen endres.

Den håndterer den mekaniske delen bra – og gjør et ventetrinn om til en WebDriverWait med en forventet betingelse. Revse tidsavbruddet den velger og betingelsen den velger, siden en generert tilstedeværelsesbetingelse ofte må være en synlighetsbetingelse i stedet.

Lokaliseringselementer evalueres mot det gjeldende valgte dokumentet, og en iframe er en separat en. Kjør kommandoen select frame først, deretter check, og gå tilbake til det øverste dokumentet etterpå, slik at de følgende trinnene ikke søkes i feil kontekst.