Англійською мовою: Selenium Testing

Selenium є одним з найстаріших і найбільш широко застосовуваних інструментів автоматизації браузерів, і команди, які підтримують великі набори WebDriver, потребують точного словника, щоб обговорити, чому тест не вдалося, чи це локатор, час або сам браузер. Правильне розуміння цієї мови допоможе вам писати більш чіткі звіти про помилки і коментарі щодо перегляду коду, коли набір програм містить сотні тестів.

Ключовий словник

** WebDriver ** — протокол і API, за допомогою якого Selenium може надсилати команди до реального переглядача (клацнути, ввести, перейти) і читати його стан, діючи як місток між вашим тестовим кодом і бінарним файлом переглядача. “Тест зазнав невдачі, оскільки WebDriver не зміг встановити сеанс з переглядачем — перевірте, чи chromedriver взагалі запущено.”

** Стратегія пошуку ** — метод, який використовується для пошуку елемента на сторінці, наприклад, CSS- селектор, XPath, ідентифікатор або текст посилання, який обирається на основі стабільності і специфічності елемента.

• “Змініть стратегію локалізації з XPath на CSS- селектор — це швидше і менше ймовірності, що вона буде порушена під час зміни структури DOM.” *

** Ясна черга ** — інструкція, яка наказує WebDriver зупинитися до виконання певної умови, наприклад, до того, як елемент стане натисканим, замість очікування певну кількість секунд. “Замініть цей твердо закодований sleep(5) на явне очікування, поки кнопка буде доступна для натискання — це буде швидше і надійніше.”

** Флакі тест ** — тест, який проходить і провалюється періодично без будь- яких змін коду, зазвичай, через проблеми з часом, нестабільні локатори або умови перегонів з асинхронною поведінкою сторінок. “Ця перевірка входу є нестабільною — вона зазнає невдачі приблизно раз на десять запусків, і це майже завжди тому, що сторінка ще не закінчила перенаправлення.”

** Модель об’ єкта сторінки ** — шаблон проектування, у якому кожна сторінка або компонент програми, що тестується, представлена класом, який містить її локалізатори і взаємодії, зберігаючи логіку тестування окремо від структури сторінки.

• “Ми пересунули поток вивантаження до класу Page Object Model, отже, коли змінюється ідентифікатор кнопки, нам потрібно лише оновити його у одному місці.” *

Звичайні фрази

• Чи є ця невдача справжньою помилкою, чи тест просто неефективний?»
• Яка стратегія локаторів ми використовуємо тут, і чи є вона стійкою до зміни макету?
• Чи можемо ми обміняти це неявне очікування на явне очікування на фактичну умову, про яку ми дбаємо?»
• Чи повинна ця взаємодія жити в Page Object Model замість прямо в тесті?»
• «Чи WebDriver дійсно підключається до правильної версії браузера?»

Приклади висловлювань

Пояснення провалу товаришу по команді: “Скасовано сеанс WebDriver, оскільки у сітківці не було вільних вузлів переглядача — це не проблема з нашою тестовою логікою.”

Перегляд запиту на звантаження:

• “Ця стратегія локалізації базується на нестабільному XPath з трьома вкладеними розділами — чи можемо ми додати атрибут data- testid замість цього?” *

Звітування про повторювані проблеми команді:

• “Це несправжній тест, а не справжня регресія — він залежить від явного часу очікування, який ми забуємо додати після відкриття модульного вивантаження.” *

Професійні поради

• Використовуйте мову ** locator strategy ** під час перегляду тестів — назвати саме той тип селекторів, який є нестабільним, зробить виправлення очевидним для кожного, хто підбере квиток.
• Використовуйте ** explicit wait ** замість нечітких термінів, таких як « add a wait » — це сигналізує про те, що ви чекаєте за умови, а не просто додаєте затримку, що має значення, коли хтось переглядатиме ваш код пізніше.
• Позначте ** фрагментарний тест ** у вашому журналі помилок, а не просто повторюйте його — повторне виконання без повідомлення приховує справжні проміжні помилки і підриває довіру до набору.
• Рекомендуємо використовувати Page Object Model, якщо у тестовому файлі змішано локалізатори і твердження — це стандартний словник для виправлення і сигналізує про те, що ви розумієте архітектуру тестування.

Практичні вправи

1. Поясніть різницю між явним очікуванням і фіксованим сном, а також чому останній є більш надійним у тесті WebDriver.
2. Опишемо дві можливі причини неправильного тестування потоку реєстрації, у коді якого не було останніх змін.
3. Написати короткий коментар щодо перегляду коду, у якому буде рекомендовано стабільнішу стратегію локалізації для тесту, який використовує вкладені вирази XPath.

Переклади: «Переклади» — переклади, що виходять за рамки літературного перекладу

Початкова мета вивчення англійської для тестування Selenium часто просто розуміння основних термінів - element, locator, assertion, test case. Однак, професійна розробка програмного забезпечення не тільки про знання визначення; це про * комунікацію * ефективно. Для носіїв, для яких мова не є рідною, це може бути неймовірно складним завданням, тому що тонкі зміни у фразування і тону мають значну вагу. Здається, нешкідлива зміна у формулюванні може перетворити незначну проблему на великий конфлікт або повністю неправильно зрозуміти запит. Давайте розглянемо, як обробляти зворотній зв’язок - особливо, коли він походить від перегляду коду або спільних обговорень - з більшою точністю.

Одним з найпоширеніших сценаріїв є отримання коментаря щодо запиту на завантаження. Замість того, щоб просто перекласти коментар (« Цей елемент не є стабільним »), вам слід зрозуміти, * чому * його позначено як нестабільний. Ефективнішою відповіддю, яка демонструє ваше розуміння і бажання співпрацювати, може бути: « Дякую, що звернув на це увагу, Марк. Я бачу, що елемент періодично зникає після натискання кнопки. Можеш роз’яснити, які конкретні умови спричиняють це? Я розгляну час клацання і досліджу різні стратегії локалізації — можливо, більш надійний селектор з використанням XPath або CSS покращить стабільність. Зауважте, що опис цього як * розслідування *, а не визнання помилки, у поєднанні з проактивною пропозицією дослідити рішення, є набагато продуктивнішим. Аналогічно, коли ви пояснюєте тест на несправність під час розмови у Slack, не слід просто стверджувати « Цей тест зазнає невдачі випадково ». Замість цього спробуйте: « Я виявив періодичні невдачі у тесті « входу ». Це залежить від затримки мережі - іноді відповідь сервера триває довше, ніж очікувалося, що призводить до тайм-аута і, врешті-решт, до невдачі. Я зараз додаю логіку повторних спроб з експоненційним відступом, щоб обробляти ці ситуації. ”

Ключовим є перехід від буквального перекладу до передачі наміру, що стоїть за зворотнім зв’язком. Не бійтеся задати прояснюючі питання. Питання про більш детальні деталі — «Чи можете ви надати приклад того, коли це відбувається?» або «Які очікувані умови?» — це цілком прийнятна практика, особливо в колективному середовищі. Пам’ ятайте, що всі намагаються досягти однієї мети: надійної і підтримуваної автоматизації. Крім того, навчання чітко висловлювати власні ідеї - описуючи * свій * процес мислення під час усунення несправностей - має вирішальне значення для демонстрації компетентності і будівництва довіри з вашою командою.

Ось приклад того, як можна використовувати grep для виявлення потенційних проблем у файлах журналу, що є звичайним сценарієм під час зневадження тестів flaky:

grep -i "timeout" /path/to/your/logfiles/*.log | sort | uniq -c

За допомогою цієї команди буде виконано пошук слова « timeout » (не залежно від регістру), буде підраховано кількість його випадків у всіх файлах журналу у вказаному каталозі, а потім буде показано цей показник. Це допомагає визначити частоту помилок тайм- аута, які можуть бути ключовим показником неефективних тестів.