Проверете дали елементът е наличен и изчакайте командата да влезе Selenium

Записано Selenium IDE Скриптът кликва и въвежда текст, но сам по себе си никога не решава дали приложението се е държало правилно. Две семейства команди правят това: провери команди, които проверяват състоянието на страницата, и чакам команди, които задържат изпълнението, докато страницата е готова за проверка.

⚠️ Бележка относно версиите: Снимките на екрана по-долу са от оригинала Firefox-плъгин Selenium IDE, която вече не се разпространява и те използват нейните имена с camelCase Selenese. Настоящата IDE е Chrome, Firefox и Edge разширение на браузъраОписаното тук поведение все още е валидно, но няколко имена на команди са променени — картаping Таблицата се появява по-късно в тази статия и всяка оригинална команда и екранна снимка са запазени точно както са публикувани.

Проверете наличието на елемент

Можем да използваме следните две команди, за да проверим наличието на елемент:

• verifyElementPresent – връща TRUE, ако посоченият елемент е НАМЕРЕН в страницата; FALSE, ако е друго
• verifyElementNotPresent – връща TRUE, ако посоченият елемент НЕ Е НАМЕРЕЕН никъде в страницата; FALSE, ако е налице.

И двете команди приемат елемент локатор в Target поле — идентификатор, име, CSS селектор, текст на връзка или XPath израз — и нито един от тях не се нуждае от стойност.

Тестовият скрипт по-долу проверява дали текстовото поле UserName присъства в рамките на Mercury Обиколка на началната страница, докато текстовото поле First Name не е. Текстовото поле First Name всъщност е елемент, присъстващ в страницата за регистрация на Mercury Обиколки, не в началната страница.

Защото това са провери команди, а не твърдя команди, грешка се записва в лога и останалите стъпки продължават да се изпълняват. Това разграничение е разгледано подробно по-долу.

Проверете наличието на определен текст в командата в Selenium

Проверката дали даден елемент съществува не винаги е достатъчна — тестът често трябва да потвърди думите, показани на потребителя. Две текстови команди покриват този случай.

• verifyTextPresent – връща TRUE, ако посоченият текстов низ е НАМЕРЕЕН някъде в страницата; FALSE, ако е друго
• verifyTextNotPresent – връща TRUE, ако посоченият текстов низ НЕ Е НАМЕРЕЕН никъде в страницата; FALSE, ако е намерен

Не забравяйте, че тези команди са чувствителни към малки и главни букви.

Дневникът по-долу показва една и съща страница, проверена два пъти с два правописа на една и съща фраза.

В горния сценарий, „Атланта до Лас Вегас“ беше третирано различно от „Атланта до Лас Вегас“, защото буквата „А“ на „Атланта“ беше с главна буква на първия, а с малка на другия. Когато командата verifyTextPresent беше използвана на всеки от тях, единият беше успешно изпълнен, а другият не.

Проверете конкретната позиция на елемент

Дефектите в оформлението рядко повреждат локатора, така че проверките за присъствие ги пропускат. Командите за позициониране запълват тази празнина.

Selenium IDE показва позицията на даден елемент, като измерва (в пиксели) колко далеч е от левия или горния край на прозореца на браузъра.

• verifyElementPositionLeft – проверява дали зададеният брой пиксели съответства на разстоянието на елемента от левия край на страницата. Това ще върне FALSE, ако зададената стойност не съответства на разстоянието от левия ръб.
• verifyElementPositionTop – проверява дали зададеният брой пиксели съответства на разстоянието на елемента от горния край на страницата. Това ще върне FALSE, ако зададената стойност не съответства на разстоянието от горния ръб.

Скриптът по-долу записва очакваните отмествания на пикселите в колоната „Стойност“.

Внимавайте с тези две команди. Пикселното отместване се променя в зависимост от размера на прозореца, нивото на мащабиране и инсталираните шрифтове, така че твърдо кодирано число, което е успешно изпълнено на една машина, може да не успее на друга.

Изчакайте командите Selenium

Командата verify може да провери само това, което вече е на екрана, така че проверка, която се изпълнява твърде рано, се проваля, въпреки че приложението работи. Командите wait решават този проблем с времето.

По-долу са типовете команди за изчакване в Selenium

andWait команди

Това са команди, които ще изчакат да се зареди нова страница, преди да преминат към следващата команда.

Примери за това са

• clickAndWait
• typeAndWait
• selectAndWait

Всяка една от тях е обикновена команда за действие с прикачен суфикс AndWait, както е показано на записаната стъпка по-долу.

изчакайте команди

Това са команди, които чакат определено условие да стане истина, преди да преминат към следващата команда (независимо от зареждането на нова страница). Тези команди са по-подходящи за използване на базирани на AJAX динамични уебсайтове, които променят стойности и елементи, без да презареждат цялата страница. Примерите включват:

• waitForTitle
• waitForTextPresent
• waitForAlert

Помислете за сценария във Facebook по-долу.

Можем да използваме комбинация от „click“ и „waitForTextPresent“, за да проверим наличието на текста „Providing your birthday“.

Не можем да използваме clickAndWait, защото не е заредена страница при щракване върху „Защо трябва да предоставя моята дата на раждане?“ връзка. Ако го направим, тестът ще се провали

Същото правило важи и за всяко съдържание, инжектирано от скрипт, а не от навигация, поради което AJAX-управлявани екрани почти винаги е необходимо waitFor, а не andWait.

Assert срещу Verify срещу waitFor команди в Selenium IDE

Начинаещите често избират грешното семейство и след това се чудят защо даден комплект спира при първия дефект или защо докладва двадесет отказа, които всички... tracобратно към едно. Трите префикса отговарят на три различни въпроса.

Префикс	Какво го прави	При неуспех	Най-добре се използва за
твърдя	Проверява състоянието незабавно	Регистрира неуспеха и спира тестовия случай	Предварителни условия — влизане, което трябва да е успешно, преди всичко друго да има смисъл
провери	Проверява състоянието незабавно	Регистрира грешката и продължава със следващата команда	Независими проверки, като например няколко етикета на една страница за потвърждение
чакай за	Анкети, докато условието стане истина	Регистрира неуспеха след изтичане на времето за изчакване, след което продължава	Всичко, което се появява със закъснение — AJAX отговори, спинери, диалози

Практическият модел комбинира и трите: проверете страницата, на която сте попаднали, изчакайте елемента, който пристига асинхронно, след което проверете всяко отделно поле. Изпълнението му в този ред означава, че една неработеща навигация спира теста преждевременно, докато няколко козметични несъответствия се отчитат в едно изпълнение. Същата дисциплина се пренася и за Selenium тестове, написани в код, където еквивалентите са твърди твърдения, меки твърдения и изрични чакания.

Команди за проверка и изчакване в текущия Selenium IDE

- Firefox-plugin IDE, който създаде екранните снимки по-горе, беше оттеглен и наборът от команди беше пресъздаден за текущото разширение на браузъра. Няколко имена на Selenese са оцелели, някои са преименувани, а няколко са премахнати. Таблицата по-долу съпоставя командите, използвани в тази статия, с техните съвременни еквиваленти, взети от официалния Selenium Справочник на IDE команди.

Стара селенска команда	Команда в текущата IDE
verifyElementPresent	проверете наличието на елемент
verifyElementNotPresent	проверете дали елементът не е наличен
verifyTextPresent	провери текста (обхватът е локатор на елементи, а не цялата страница)
verifyTextNotPresent	провери, че не е текст (с обхват до локатор на елементи)
провериЗаглавие	потвърди заглавието
verifyElementPositionLeft / verifyElementPositionTop	Няма еквивалент — твърденията за позиция бяха отхвърлени
clickAndWait, typeAndWait, selectAndWait	Без суфикс AndWait — командата open вече чака зареждане на страница
waitForElementPresent	изчакайте наличието на елемент, с време за изчакване в милисекунди
waitForAlert	потвърдете предупреждението или проверете текста на предупреждението, след като се появи диалоговият прозорец

Две разлики са най-важни в ежедневната работа. Първо, настоящите команди за изчакване — wait for element present, wait for element visible, wait for element editable и техните отрицателни близнаци — всяка от тях приема изрично време за изчакване в милисекунди, така че бавната стъпка вече не е необходимо да споделя едно глобално време за изчакване. Второ, търсенето на текст в цялата страница е премахнато: verify text се нуждае от локатор, което обикновено води до по-точна проверка.

Често срещани грешки с командите Verify и waitFor

Повечето докладвани проблеми с тези команди не са дефекти в IDE. Списъкът по-долу обхваща най-често срещаните проблеми и какво се решава за всяка от тях.

• Елементът съществува, но проверката все още е неуспешна. Присъствие и видимост са различни състояния. Елемент, скрит зад CSS правило, все още присъства в DOM, така че комбинирайте проверката за присъствие с wait for element visible, когато тестът зависи от това потребителят действително да го види.
• Проверката на текста е неуспешна при формулировки, които изглеждат идентични. Неразбиващите се интервали, празните интервали в края и къдравите апострофи, копирани от дизайнерски документ, нарушават точното съвпадение. Въведете отново очаквания низ на ръка, вместо да го поставяте.
• Команда за изчакване е изтекла на страница, която очевидно е заредена. Елементът обикновено е вътре в iframe. Първо изпълнете select frame, в противен случай локаторът ще бъде оценен спрямо грешен документ.
• clickAndWait замръзва в приложение с една страница. Не се случва навигация, така че няма какво да се чака. Заменете го с щракване плюс съответната команда waitFor.
• Проверката на позицията преминава локално и се проваля на сървъра за изграждане. Размерът на екрана и изобразяването на шрифта се различават. Предпочитайте проверка за присъствие или текст или задайте изричен размер на прозореца в началото на теста.
• Целият комплект спира при първото несъответствие. Записана е команда assert, където е била предназначена команда verify. Променете префикса и изпълнението ще докладва за всяка грешка, а не само за първата.

След като даден скрипт оцелее през тези капани, следващата стъпка обикновено е да съхранява стойности по време на изпълнение в променливи така че проверките се сравняват с реални данни, а не с твърдо кодирани низове.

Въпроси и Отговори