Verifiera Element Present & waitFor Command in Selenium
Krishna Rungta
⚡ Smart sammanfattning
Verifiera att elementet finns och waitFor-kommandon i Selenium IDE bekräftar att en sida innehåller de element och den text som ett test förväntar sig, och pausar uppspelningen tills ett dynamiskt villkor uppfylls innan nästa steg körs.
A inspelad Selenium IDE skriptet klickar och skriver, men avgör aldrig på egen hand om programmet betedde sig korrekt. Två kommandofamiljer gör det jobbet: verifiera kommandon, som kontrollerar sidans tillstånd, och vänta kommandon, som håller körningen inne tills sidan är redo att kontrolleras.
⚠️ En anmärkning om versioner: Skärmdumparna nedan kommer från originalet Firefox-plugin Selenium IDE, som inte längre distribueras, och de använder dess camelCase Selenese-namn. Den nuvarande IDE:n är en Chrome, Firefox och Edge webbplatstilläggBeteendet som beskrivs här gäller fortfarande, men flera kommandonamn har ändrats — en kartaping Tabellen visas senare i den här artikeln, och alla ursprungliga kommandon och skärmdumpar bevaras exakt som de publicerades.
Verifiera närvaron av ett element
Vi kan använda följande två kommandon för att verifiera närvaron av ett element:
- verifyElementPresent – returnerar TRUE om det angivna elementet hittades på sidan; FALSK om annat
- verifyElementNotPresent – returnerar TRUE om det angivna elementet INTE HITTS någonstans på sidan; FALSK om det finns.
Båda kommandona tar ett element locator i Target fält — ett id, ett namn, en CSS-väljare, en länktext eller ett XPath uttryck — och ingetdera behöver ett värde.
Testskriptet nedan verifierar att textrutan Användarnamn finns i Mercury Tours hemsida medan textrutan Förnamn inte är det. Textrutan Förnamn är faktiskt ett element som finns på registreringssidan för Mercury Turer, inte på hemsidan.
För det är dessa verifiera kommandon snarare än hävda kommandon, skrivs ett fel till loggen och de återstående stegen körs fortfarande. Den skillnaden behandlas i detalj längre ner.
Verifiera närvaron av en viss text i kommandot i Selenium
Att kontrollera att ett element existerar är inte alltid tillräckligt – ett test behöver ofta bekräfta de ord som visas för användaren. Två textkommandon täcker det fallet.
- verifieraTextPresent – returnerar TRUE om den angivna textsträngen hittades någonstans på sidan; FALSK om annat
- verifyTextNotPresent – returnerar TRUE om den angivna textsträngen INTE HITTS någonstans på sidan; FALSK om den hittades
Kom ihåg att dessa kommandon är skiftlägeskänsliga.
Loggen nedan visar samma sida kontrollerad två gånger med två stavningar av samma fras.
I scenariot ovan behandlades "Atlanta till Las Vegas" annorlunda än "atlanta till Las Vegas" eftersom bokstaven "A" i "Atlanta" var stor i den första och liten i den andra. När kommandot verifyTextPresent användes på var och en av dem, godkändes den ena medan den andra misslyckades.
Verifiera specifik position för ett element
Layoutfel bryter sällan en lokalisering, så närvarokontroller missar dem. Positionskommandon täcker det gapet.
Selenium IDE anger positionen för ett element genom att mäta (i pixlar) hur långt det är från vänstra eller övre kanten av webbläsarfönstret.
- verifyElementPositionLeft – verifierar om det angivna antalet pixlar matchar elementets avstånd från sidans vänstra kant. Detta kommer att returnera FALSE om det angivna värdet inte matchar avståndet från den vänstra kanten.
- verifyElementPositionTop – verifierar om det angivna antalet pixlar matchar elementets avstånd från sidans överkant. Detta returnerar FALSE om det angivna värdet inte matchar avståndet från den övre kanten.
Skriptet nedan registrerar de förväntade pixelförskjutningarna i kolumnen Värde.
Hantera dessa två kommandon med försiktighet. En pixelförskjutning ändras med fönsterstorleken, zoomnivån och de installerade teckensnitten, så ett hårdkodat tal som skickas på en maskin kan misslyckas på en annan.
Vänta kommandon in Selenium
Ett verify-kommando kan bara inspektera det som redan finns på skärmen, så en kontroll som körs för tidigt misslyckas trots att applikationen fungerar. Wait-kommandon löser det tidsproblemet.
Följande är typerna av väntekommandon i Selenium
och Vänta kommandon
Dessa är kommandon som väntar på att en ny sida laddas innan du går vidare till nästa kommando.
Exempel är
- klicka och vänta
- typAndWait
- välj och vänta
Var och en av dem är ett vanligt åtgärdskommando med suffixet AndWait bifogat, vilket det inspelade steget nedan visar.
vänta på kommandon
Dessa är kommandon som väntar på att ett specificerat villkor blir sant innan du fortsätter till nästa kommando (oavsett om en ny sida laddas). Dessa kommandon är mer lämpliga att använda på AJAX-baserade dynamiska webbplatser som ändrar värden och element utan att ladda om hela sidan. Exempel inkluderar:
- waitForTitle
- waitForTextPresent
- vänta på varning
Tänk på Facebook-scenariot nedan.
Vi kan använda en kombination av "klick" och "waitForTextPresent" för att verifiera närvaron av texten "Ange din födelsedag".
Vi kan inte använda clickAndWait eftersom ingen sida laddades när du klickade på "Varför behöver jag ange min födelsedag?" länk. Om vi gör det kommer testet att misslyckas
Samma regel gäller för allt innehåll som injiceras via skript snarare än via navigering, vilket är anledningen till AJAX-drivna skärmar behöver nästan alltid waitFor snarare än andWait.
Assert vs Verify vs waitFor-kommandon i Selenium IDE
Nybörjare väljer ofta fel familj och undrar sedan varför en svit stannar vid den första defekten, eller varför den rapporterar tjugo fel som alla trace tillbaka till ett. De tre prefixen svarar på tre olika frågor.
| Prefix | Vad den gör | Vid fel | Används bäst till |
|---|---|---|---|
| hävda | Kontrollerar ett tillstånd omedelbart | Loggar felet och stoppar testfallet | Förutsättningar — en inloggning som måste lyckas innan något annat blir meningsfullt |
| verifiera | Kontrollerar ett tillstånd omedelbart | Loggar felet och fortsätter med nästa kommando | Oberoende kontroller, till exempel flera etiketter på en bekräftelsesida |
| väntaPå | Opinionsundersökningar tills villkoret blir sant | Loggar felet när timeout-tiden löper ut och fortsätter sedan | Allt som dyker upp sent — AJAX-svar, spinnare, dialogrutor |
Ett praktiskt mönster kombinerar alla tre: bekräfta sidan du landade på, vänta på elementet som anländer asynkront och verifiera sedan varje enskilt fält. Att göra det i den ordningen innebär att en trasig navigering stoppar testet tidigt, medan en handfull kosmetiska avvikelser rapporteras i en enda körning. Samma disciplin gäller även för Selenium tester skrivna i kod, där motsvarigheterna är hårda påståenden, mjuka påståenden och explicita väntningar.
Verifiera och vänta-kommandon i den aktuella Selenium IDE
Ocuco-landskapet Firefox-plugin IDE som producerade skärmdumparna ovan togs ur bruk och kommandouppsättningen byggdes om för det aktuella webbläsartillägget. Flera seleniska namn överlevde, vissa döptes om och några togs bort. Tabellen nedan mappar kommandona som används i den här artikeln till deras nuvarande motsvarigheter, hämtade från den officiella Selenium IDE-kommandoreferens.
| Äldre selenesiskt kommando | Kommando i den aktuella IDE:n |
|---|---|
| verifyElementPresent | verifiera att elementet finns |
| verifyElementNotPresent | verifieringselementet finns inte |
| verifieraTextPresent | verifiera text (avgränsad till en elementsökare, inte hela sidan) |
| verifyTextNotPresent | verifiera att det inte är text (omfattat till en elementsökare) |
| verifieraTitel | verifiera titel |
| verifieraElementPositionVänster / verifieraElementPositionTopp | Ingen motsvarighet — positionspåståenden togs bort |
| klickaOchVänta, skrivOchVänta, väljOchVänta | Inget AndWait-suffix — kommandot open väntar redan på att en sida ska laddas |
| waitForElementPresent | vänta på att elementet ska finnas, med en väntetid i millisekunder |
| vänta på varning | bekräfta varning eller verifiera varningstext efter att dialogrutan visas |
Två skillnader är viktigast i det dagliga arbetet. För det första tar de nuvarande väntekommandona – vänta på att elementet finns, vänta på att elementet är synligt, vänta på att elementet är redigerbart och deras negativa tvillingar – var och en en explicit väntetid i millisekunder, så ett långsamt steg behöver inte längre dela en global timeout. För det andra är den sidomfattande textsökningen borta: verifiera text behöver en lokaliseringsfunktion, vilket vanligtvis ger en skarpare kontroll ändå.
Vanliga fel med Verify- och waitFor-kommandon
De flesta rapporterade problemen med dessa kommandon är inte defekter i IDE:n. Listan nedan täcker de fel som uppstår oftast och vad som åtgärdar vart och ett.
- Elementet finns men kontrollen misslyckas fortfarande. Närvaro och synlighet är olika tillstånd. Ett element som är dolt bakom en CSS-regel finns fortfarande kvar i DOM:en, så para ihop närvarokontrollen med vänta på att elementet ska vara synligt när testet är beroende av att användaren faktiskt ser det.
- En textkontroll misslyckas på formuleringar som ser identiska ut. Hårda mellanslag, efterföljande blanksteg och lockiga apostrofer kopierade från ett designdokument bryter alla en exakt matchning. Skriv om den förväntade strängen för hand istället för att klistra in den.
- Ett wait-kommando får timeout på en sida som tydligt laddades. Elementet finns vanligtvis inuti en iframe. Kör select frame först, annars utvärderas locatorn mot fel dokument.
- clickAndWait hänger sig i en applikation med en enda sida. Ingen navigering sker, så det finns inget att vänta på. Ersätt det med ett klick plus lämpligt waitFor-kommando.
- En positionskontroll godkänns lokalt och misslyckas på byggservern. Skärmstorlek och teckensnittsrendering skiljer sig åt. Föredra en närvaro- eller textkontroll, eller ange en explicit fönsterstorlek i början av testet.
- Hela sviten stannar vid första missmatchningen. Ett assert-kommando registrerades där ett verify-kommando var avsett. Byt prefix så rapporterar körningen varje fel istället för bara det första.
När ett skript överlever dessa fällor är nästa steg vanligtvis att lagra runtime-värden i variabler så jämförs kontrollerna mot verklig data snarare än hårdkodade strängar.
