«Во всяком автоматизированном тесте существует риск превращения в противоположность тому, ради чего проводится автоматизация: что-то медленное и нестабильное. Для этого достаточно не продумывать команды 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% нынешних приложений.
