Verifiera Element Present & waitFor Command in Selenium

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.

Vanliga frågor