Bekræft Element Present & waitFor Command in Selenium
Krishna Rungta
⚡ Smart opsummering
Bekræft tilstedeværelsen af elementet og waitFor-kommandoer i Selenium IDE bekræfter, at en side indeholder de elementer og den tekst, som en test forventer, og sætter afspilningen på pause, indtil en dynamisk betingelse bliver sand, før næste trin køres.
A optaget Selenium IDE scriptet klikker og skriver, men afgør aldrig alene, om applikationen opførte sig korrekt. To kommandofamilier udfører det arbejde: verificere kommandoer, som kontrollerer sidens tilstand, og vente kommandoer, som holder kørelsen tilbage, indtil siden er klar til at blive kontrolleret.
⚠️ En bemærkning om versioner: Skærmbillederne nedenfor stammer fra originalen Firefox-plugin Selenium IDE, som ikke længere distribueres, og de bruger dens camelCase Selenese-navne. Den nuværende IDE er en Chrome, Firefox og Edge browser udvidelseDen her beskrevne adfærd gælder stadig, men flere kommandonavne er ændret — et kortping Tabellen vises senere i denne artikel, og alle originale kommandoer og skærmbilleder bevares nøjagtigt som offentliggjort.
Bekræft tilstedeværelsen af et element
Vi kan bruge følgende to kommandoer til at bekræfte tilstedeværelsen af et element:
- verifyElementPresent – returnerer TRUE, hvis det angivne element blev FUNDET på siden; FALSK hvis andet
- verifyElementNotPresent – returnerer TRUE, hvis det angivne element IKKE blev FUNDET noget sted på siden; FALSK, hvis den er til stede.
Begge kommandoer tager et element locator i Target felt — et id, et navn, en CSS-vælger, en linktekst eller et XPath udtryk — og ingen af dem behøver en værdi.
Testscriptet nedenfor bekræfter, at tekstboksen Brugernavn er til stede i Mercury Tours hjemmeside, mens tekstfeltet Fornavn ikke er det. Tekstboksen Fornavn er faktisk et element, der findes på registreringssiden for Mercury Rundvisninger, ikke på hjemmesiden.
Fordi disse er verificere kommandoer snarere end hævde kommandoer, skrives en fejl til loggen, og de resterende trin kører stadig. Denne sondring er dækket i detaljer længere nede.
Bekræft tilstedeværelsen af en bestemt tekst i kommando i Selenium
Det er ikke altid nok at kontrollere, om et element eksisterer – en test skal ofte bekræfte de ord, der vises til brugeren. To tekstkommandoer dækker dette tilfælde.
- verifyTextPresent – returnerer TRUE, hvis den angivne tekststreng blev FUNDET et sted på siden; FALSK hvis andet
- verifyTextNotPresent – returnerer TRUE, hvis den angivne tekststreng IKKE blev FUNDET noget sted på siden; FALSK hvis den blev fundet
Husk, at disse kommandoer skelner mellem store og små bogstaver.
Loggen nedenfor viser den samme side kontrolleret to gange med to stavemåder af den samme sætning.
I ovenstående scenarie blev "Atlanta til Las Vegas" behandlet anderledes end "atlanta til Las Vegas", fordi bogstavet "A" i "Atlanta" var stort på den første, mens det var lille på den anden. Da verifyTextPresent-kommandoen blev brugt på hver af dem, bestod den ene, mens den anden mislykkedes.
Bekræft specifik position af et element
Layoutfejl ødelægger sjældent en lokator, så tilstedeværelseskontroller overser dem. Positionskommandoer lukker dette hul.
Selenium IDE angiver positionen af et element ved at måle (i pixels), hvor langt det er fra venstre eller øverste kant af browservinduet.
- verifyElementPositionLeft – verificerer, om det angivne antal pixels svarer til elementets afstand fra venstre kant af siden. Dette vil returnere FALSK, hvis den angivne værdi ikke svarer til afstanden fra venstre kant.
- verifyElementPositionTop – verificerer, om det angivne antal pixels svarer til elementets afstand fra sidens øverste kant. Dette vil returnere FALSK, hvis den angivne værdi ikke svarer til afstanden fra den øverste kant.
Scriptet nedenfor registrerer de forventede pixelforskydninger i værdikolonnen.
Behandl disse to kommandoer med forsigtighed. En pixelforskydning ændrer sig med vinduesstørrelsen, zoomniveauet og de installerede skrifttyper, så et hardcodet tal, der sendes på én maskine, kan fejle på en anden.
Vent kommandoer ind Selenium
En verify-kommando kan kun inspicere det, der allerede er på skærmen, så en kontrol, der kører for tidligt, mislykkes, selvom applikationen fungerer. Wait-kommandoer løser dette timingproblem.
Følgende er typerne af ventekommandoer i Selenium
og vent-kommandoer
Disse er kommandoer, der vil vente på, at en ny side indlæses, før du går videre til den næste kommando.
eksempler er
- klik og vent
- typeAndWait
- vælgOgVent
Hver af dem er en almindelig handlingskommando med AndWait-suffikset tilknyttet, som det optagede trin nedenfor viser.
vente på kommandoer
Disse er kommandoer, der venter på, at en specificeret betingelse bliver sand, før du fortsætter til den næste kommando (uanset indlæsning af en ny side). Disse kommandoer er mere passende til at blive brugt på AJAX-baserede dynamiske websteder, der ændrer værdier og elementer uden at genindlæse hele siden. Eksempler omfatter:
- vente på titel
- venteTekstPresent
- vente på advarsel
Overvej Facebook-scenariet nedenfor.
Vi kan bruge en kombination af "klik" og "waitForTextPresent" for at bekræfte tilstedeværelsen af teksten "Oplyser din fødselsdag".
Vi kan ikke bruge clickAndWait, fordi ingen side blev indlæst ved at klikke på "Hvorfor skal jeg oplyse min fødselsdag?" link. Hvis vi gør det, vil testen mislykkes
Den samme regel gælder for alt indhold, der indsættes via script i stedet for navigation, hvilket er grunden til AJAX-drevne skærme har næsten altid brug for waitFor i stedet for andWait.
Assert vs. Verify vs. waitFor-kommandoer i Selenium IDE
Begyndere vælger ofte den forkerte familie og undrer sig derefter over, hvorfor en suite stopper ved den første defekt, eller hvorfor den rapporterer tyve fejl, der alle tractilbage til én. De tre præfikser besvarer tre forskellige spørgsmål.
| Præfiks | Hvad gør den | Ved fejl | Bedste brugt til |
|---|---|---|---|
| hævde | Kontrollerer en tilstand med det samme | Logger fejlen og stopper testcasen | Forudsætninger — et login, der skal lykkes, før noget andet giver mening |
| verificere | Kontrollerer en tilstand med det samme | Logfører fejlen og fortsætter med den næste kommando | Uafhængige kontroller, såsom flere etiketter på én bekræftelsesside |
| ventPå | Afstemninger indtil betingelsen bliver sand | Logger fejlen, når timeouten udløber, og fortsætter derefter | Alt, der dukker op sent — AJAX-svar, spinners, dialoger |
Et praktisk mønster kombinerer alle tre: bekræfter den side, du er landet på, vent på det element, der ankommer asynkront, og verificerer derefter hvert enkelt felt. Hvis du gør det i den rækkefølge, stopper én defekt navigation testen tidligt, mens en håndfuld kosmetiske uoverensstemmelser alle rapporteres i en enkelt kørsel. Den samme disciplin overføres til Selenium tests skrevet i kode, hvor ækvivalenterne er hårde påstande, bløde påstande og eksplicitte ventetider.
Bekræft og vent-kommandoer i den aktuelle Selenium IDE
Firefox-plugin IDE'et, der producerede skærmbillederne ovenfor, blev trukket tilbage, og kommandosættet blev genopbygget til den nuværende browserudvidelse. Adskillige selenesiske navne overlevede, nogle blev omdøbt, og et par stykker blev droppet. Tabellen nedenfor viser de kommandoer, der bruges i denne artikel, i forhold til deres nuværende ækvivalenter, taget fra den officielle Selenium IDE-kommandoreference.
| Ældre selenisk kommando | Kommando i det nuværende IDE |
|---|---|
| verifyElementPresent | verificér tilstedeværende element |
| verifyElementNotPresent | verificeringselementet er ikke til stede |
| verifyTextPresent | bekræft tekst (afgrænset til en elementsøger, ikke hele siden) |
| verifyTextNotPresent | bekræft ikke tekst (beregnet til en elementsøger) |
| verificérTitel | bekræft titel |
| verificerElementPositionVenstre / verificerElementPositionTop | Ingen tilsvarende — positionspåstande blev droppet |
| klikOgVent, skrivOgVent, vælgOgVent | Intet AndWait-suffiks — kommandoen "åbn" venter allerede på, at en side indlæses |
| waitForElementPresent | Vent på element til stede, med en ventetid i millisekunder |
| vente på advarsel | hævd advarsel eller bekræft advarselstekst efter dialogboksen vises |
To forskelle er vigtigst i det daglige arbejde. For det første tager de nuværende ventekommandoer - vent på element til stede, vent på element synligt, vent på element redigerbart og deres negative tvillinger - hver en eksplicit ventetid i millisekunder, så et langsomt trin ikke længere behøver at dele én global timeout. For det andet er den sideomfattende tekstsøgning væk: verificer tekst kræver en locator, hvilket normalt giver en skarpere kontrol alligevel.
Almindelige fejl med Verify- og waitFor-kommandoer
De fleste rapporterede problemer med disse kommandoer er ikke defekter i IDE'en. Listen nedenfor dækker de fejl, der opstår oftest, og hvad der løser hver enkelt.
- Elementet findes, men kontrollen mislykkes stadig. Tilstedeværelse og synlighed er forskellige tilstande. Et element, der er skjult bag en CSS-regel, er stadig til stede i DOM'en, så par tilstedeværelseskontrollen med vent på elementets synlighed, når testen afhænger af, at brugeren rent faktisk ser det.
- En tekstkontrol mislykkes ved formulering, der ser identisk ud. Hartbrudte mellemrum, efterfølgende mellemrum og krøllede apostroffer kopieret fra et designdokument afbryder alle et præcist match. Indtast den forventede streng i hånden i stedet for at indsætte den.
- En wait-kommando får timeout på en side, der tydeligvis er indlæst. Elementet er normalt inde i en iframe. Kør select frame først, ellers evalueres locatoren i forhold til det forkerte dokument.
- clickAndWait hænger i en applikation med én side. Der sker ingen navigation, så der er intet at vente på. Erstat det med et klik plus den relevante waitFor-kommando.
- En positionskontrol gennemføres lokalt og mislykkes på byggeserveren. Skærmstørrelse og skrifttypegengivelse varierer. Foretræk en tilstedeværelses- eller tekstkontrol, eller angiv en eksplicit vinduesstørrelse i starten af testen.
- Hele suiten stopper ved den første uoverensstemmelse. En assert-kommando blev optaget, hvor en verify-kommando var tiltænkt. Skift præfikset, og kørslen vil rapportere alle fejl i stedet for kun den første.
Når et script overlever disse fælder, er det næste skridt normalt at gemme runtime-værdier i variabler så kontrollerne sammenlignes med reelle data i stedet for hardcodede strenge.
