testengineer.ru

Домой Обучение Автоматизированное тестирование ⏳ Борьба с задержкой тестов в Selenium: пример из практики

⏳ Борьба с задержкой тестов в Selenium: пример из практики

Автор

Дата

Категория

«Во всяком автоматизированном тесте существует риск превращения в противоположность тому, ради чего проводится автоматизация: что-то медленное и нестабильное. Для этого достаточно не продумывать команды Selenium и вставить их в неподходящие места. Большие медленные тесты это проблема.

Ниже пример, как это было у меня. Я проанализировал проблемный тест, нашел причину проблемы, и сократил задержку выполнения на целых 70%. 

У нас проблема

Причина, по которой команды Selenium в тесте “притормаживают”, часто заключается в том, что каждая команда имеет опасный потенциал некорректного локатора, или же, есть проблемы с синхронизацией.

В данном примере, старая версия тестов выполнялась около 300 секунд, за это время выполнила 364 запроса.

А после предлагаемой оптимизации тест выполняется за 92 секунды. То есть в 4 раза быстрее!

Ищем причину

В моем случае причиной сбоя была неспособность найти элемент (Sheduler). На это ушло 72 секунды выполнения.

Остаток времени ушел на нерелевантные и повторяющиеся действия, в итоге чисто “паразитные”. Например тест продолжал искать Scheduler еще 60 секунд (до отметки 2:12).

В этой точке тест выполнил некие рандомные операции, скорее всего обновление состояния, далее продолжил искать все тот же Scheduler, и все так же безрезультатно. 

В итоге, только 72 секунды из 300 были полезными, то есть проверялось что элемента “Scheduler” не существует. А ¾ времени теста потрачены впустую, не было новой значимой информации. А если большинство тестов будут такими же?

Решаем проблему

Большая часть современных веб-приложений не загружаются дольше чем 15-20 секунд, так что можно предположить что ждать загрузки элемента дольше чем 15-20 секунд бессмысленно. 

Из скриншота ниже понятно, что время от загрузки URL (в 11:00) до нахождения поля ввода имени и отправки значений — проходит всего 5,75 секунд. Эти 5,75 секунд идет на открытие страницы, ее отрисовку, и первое взаимодействие с элементом.

Поэтому 20-секундного «явного ожидания» в данном случае вполне достаточно. Явное ожидание выглядит примерно так:

И такой тест отнимет лишь 92 секунды рабочего времени тестировщика, при одинаковом результате.

Итак?

Писать простые красивые Selenium-тесты можно научиться. Начать с того, что запомнить максимальное количество времени, приемлемое для загрузки элемента страницы. Нет, это точно не 60 секунд как до сих пор делают многие, 15-20 секунд вполне достаточно во всех современных веб-приложениях. 

И стараемся применять явное (или, иначе, «эксплицитное») wait-ожидание перехода любого элемента страницы в другой статус: не более 20 секунд. По истечении этого порога тест должен быть однозначно объявлен как «failed», с меткой ошибки по таймауту: элемент так и не нарисовался на странице в ожидаемое время.

Подход работает для 90% нынешних приложений.

Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

ОСТАВЬТЕ ОТВЕТ

Пожалуйста, введите ваш комментарий!
пожалуйста, введите ваше имя здесь

$1100*
медианная зарплата в QA в ноябре

*по результатам опроса QA-инженеров в нашем телеграм-канале

Последние публикации

Последние комментарии