Перевірте присутність елемента та зачекайте команду Selenium
Krishna Рунгта
⚡ Розумний підсумок
Перевірте наявність елемента та команду waitFor у Selenium IDE підтверджує, що сторінка містить елементи та текст, які очікує тест, і призупиняє відтворення, доки динамічна умова не стане істинною, перш ніж виконуватиметься наступний крок.
А записаний Selenium IDE скрипт клікає та друкує, але сам по собі він ніколи не вирішує, чи правильно поводиться програма. Для цього використовуються два сімейства команд: перевірити команди, які перевіряють стан сторінки, та чекати команди, які призупиняють виконання, доки сторінка не буде готова до перевірки.
⚠️ Примітка щодо версій: скріншоти нижче взяті з оригіналу Firefox-підключати Selenium IDE, яке більше не розповсюджується, і вони використовують його назви у верблюжому регістрі селенських літер. Поточне IDE — це Chrome, Firefox і край Розширення браузераОписана тут поведінка все ще застосовується, але кілька назв команд змінилися — картаping Таблиця з’явиться далі в цій статті, і кожна оригінальна команда та знімок екрана збережені точно так, як опубліковано.
Перевірити наявність елемента
Ми можемо використовувати наступні дві команди, щоб перевірити присутність елемента:
- verifyElementPresent – повертає TRUE, якщо вказаний елемент ЗНАЙДЕНО на сторінці; FALSE, якщо інакше
- verifyElementNotPresent – повертає TRUE, якщо вказаний елемент НЕ ЗНАЙДЕНО ніде на сторінці; FALSE, якщо він присутній.
Обидві команди приймають елемент локатор , Target поле — ідентифікатор, ім'я, селектор CSS, текст посилання або XPath вираз — і жоден з них не потребує значення.
Наведений нижче тестовий сценарій перевіряє наявність текстового поля UserName у файлі Mercury Домашня сторінка Tours, а текстове поле Ім’я – ні. Текстове поле «Ім’я» фактично є елементом на сторінці реєстрації Mercury Тури, не на головній сторінці.
Тому що це перевірити команди, а не стверджувати команди, помилка записується в журнал, а решта кроків все ще виконуються. Ця різниця детально розглядається далі.
Перевірити наявність певного тексту в команді в Selenium
Перевірки існування елемента не завжди достатньо — тест часто потребує підтвердження слів, що відображаються користувачеві. Для цього достатньо двох текстових команд.
- verifyTextPresent – повертає TRUE, якщо вказаний текстовий рядок ЗНАЙДЕНО десь на сторінці; FALSE, якщо інакше
- verifyTextNotPresent – повертає TRUE, якщо вказаний текстовий рядок НЕ ЗНАЙДЕНО ніде на сторінці; FALSE, якщо його було знайдено
Пам'ятайте, що ці команди чутливі до регістру.
У журналі нижче показано, що одну й ту саму сторінку перевірено двічі, і в ній є два варіанти написання однієї й тієї ж фрази.
У наведеному вище сценарії, «Атланта до Лас-Вегаса» оброблялося по-різному, оскільки літера «А» назви «Атланта» була великою в першому випадку, а малою в іншому. Коли команда verifyTextPresent використовувалася в кожному з них, один пройшов перевірку, а інший — не пройшов.
Перевірте конкретне положення елемента
Дефекти макета рідко порушують роботу локатора, тому перевірки присутності їх пропускають. Команди позиціонування заповнюють цю прогалину.
Selenium IDE вказує положення елемента, вимірюючи (у пікселях), наскільки він знаходиться від лівого або верхнього краю вікна браузера.
- verifyElementPositionLeft – перевіряє, чи відповідає задана кількість пікселів відстані елемента від лівого краю сторінки. Це поверне FALSE, якщо вказане значення не відповідає відстані від лівого краю.
- verifyElementPositionTop – перевіряє, чи відповідає задана кількість пікселів відстані елемента від верхнього краю сторінки. Це поверне FALSE, якщо вказане значення не відповідає відстані від верхнього краю.
Наведений нижче скрипт записує очікувані зміщення пікселів у стовпці «Значення».
Обережно поводьтеся з цими двома командами. Зсув пікселя змінюється залежно від розміру вікна, рівня масштабування та встановлених шрифтів, тому жорстко задане число, яке пройде на одному комп'ютері, може не пройде на іншому.
Зачекайте команди Selenium
Команда verify може перевірити лише те, що вже відображається на екрані, тому перевірка, яка виконується занадто рано, завершується невдачею, навіть якщо програма працює. Команди wait вирішують цю проблему з часом.
Нижче наведено типи команд очікування Selenium
і Зачекайте команди
Це команди, які очікують завантаження нової сторінки перед переходом до наступної команди.
Прикладами можуть служити
- клацніть і зачекайте
- typeAndWait
- selectAndWait
Кожна з них є звичайною командою дії з доданим суфіксом AndWait, як показано на записаному кроці нижче.
очікування команд
Це команди, які очікують виконання певної умови перед переходом до наступної команди (незалежно від завантаження нової сторінки). Ці команди краще використовувати на динамічних веб-сайтах на основі AJAX, які змінюють значення та елементи без перезавантаження всієї сторінки. Приклади:
- waitForTitle
- waitForTextPresent
- waitForAlert
Розглянемо наведений нижче сценарій у Facebook.
Ми можемо використовувати комбінацію «click» і «waitForTextPresent», щоб перевірити наявність тексту «Providing your birthday».
Ми не можемо використовувати clickAndWait, оскільки жодна сторінка не завантажувалася після натискання на «Чому мені потрібно вказувати свою дату народження?» посилання. Якщо ми це зробимо, тест провалиться
Те саме правило застосовується до будь-якого контенту, введеного скриптом, а не навігацією, тому Екрани, керовані AJAX майже завжди потрібно waitFor, а не andWait.
Команди Assert vs. Verify vs. waitFor в Selenium IDE
Початківці часто вибирають неправильне сімейство, а потім дивуються, чому комплект зупиняється на першому ж дефекті або чому повідомляє про двадцять невдач, які всі... tracе назад до одиниці. Три префікси відповідають на три різні питання.
| префікс | Що вона робить | У разі невдачі | Найкраще використовувати для |
|---|---|---|---|
| стверджувати | Негайно перевіряє стан | Записує помилку та зупиняє тестовий випадок | Передумови — вхід, який має бути успішним, перш ніж будь-що інше матиме сенс |
| перевірити | Негайно перевіряє стан | Записує помилку та продовжує виконання наступної команди | Незалежні перевірки, такі як кілька етикеток на одній сторінці підтвердження |
| чекати | Опитування, доки умова не стане справжньою | Записує помилку після закінчення часу очікування, а потім продовжує | Все, що з'являється із запізненням — відповіді AJAX, спінери, діалоги |
Практичний шаблон поєднує всі три: перевірити сторінку, на яку ви потрапили, чекати на елемент, який надходить асинхронно, а потім перевірити кожне окреме поле. Виконання цього в такому порядку означає, що одна несправна навігація зупиняє тест раніше терміну, тоді як кілька косметичних невідповідностей повідомляються за один прогін. Та сама дисципліна поширюється на Selenium тести, написані кодом, де еквівалентами є жорсткі твердження, м'які твердження та явні очікування.
Команди перевірки та очікування в поточному Selenium IDE
Команда FirefoxІнтегроване середовище розробки плагінів -plugin, яке створювало наведені вище знімки екрана, було виведено з експлуатації, а набір команд було перебудовано для поточного розширення браузера. Кілька назв на селенській мові збереглися, деякі були перейменовані, а деякі були видалені. У таблиці нижче команди, що використовуються в цій статті, зіставлені з їхніми сучасними еквівалентами, взятими з офіційного... 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 та waitFor
Більшість повідомлених проблем із цими командами не є дефектами IDE. У наведеному нижче списку наведено помилки, які виникають найчастіше, та способи їх виправлення.
- Елемент існує, але перевірка все одно не вдається. Присутність та видимість – це різні стани. Елемент, прихований за правилом CSS, все ще присутній у DOM, тому поєднуйте перевірку присутності з очікуванням видимості елемента, коли тест залежить від того, чи користувач його фактично бачить.
- Перевірка тексту не вдається для формулювань, які виглядають ідентичними. Нерозривні пробіли, пробіли в кінці та фігурні апострофи, скопійовані з документа дизайну, порушують точну відповідність. Передрукуйте очікуваний рядок вручну, а не вставляйте його.
- Команда очікування перевищила час очікування на сторінці, яка явно завантажилася. Елемент зазвичай знаходиться всередині iframe. Спочатку запустіть select frame, інакше локатор оцінюватиметься для неправильного документа.
- clickAndWait зависає в односторінковій програмі. Навігація не відбувається, тому немає на що чекати. Замініть це клацанням миші та відповідною командою waitFor.
- Перевірка позиції проходить локально та завершується невдачею на сервері збірки. Розмір екрана та відображення шрифтів відрізняються. Віддайте перевагу перевірці присутності чи тексту, або встановіть чіткий розмір вікна на початку тесту.
- Вся сюїта зупиняється на першій же невідповідності. Там, де мала бути команда verify, було записано команду assert. Змініть префікс, і запуск повідомлятиме про кожну помилку, а не лише про першу.
Як тільки скрипт виживає через ці пастки, наступним кроком зазвичай є зберігати значення часу виконання у змінних тому перевірки порівнюються з реальними даними, а не з жорстко закодованими рядками.
