Интересуетесь, как ускорить автоматизированные UI тесты? Узнайте эффективные и действенные советы, которые помогут вам быстрее и эффективнее выполнять UI автотесты.
Автоматизация пользовательского интерфейса (UI автоматизация) — это процесс тестирования, при котором скрипты выполняются с помощью автоматизированного инструмента на графическом интерфейсе пользователя (GUI). Он требует взаимодействия с браузером и его элементами для выполнения таких действий, как нажатие и ввод текста для проверки функциональности приложения. В графическом интерфейсе вы получаете визуальное представление, такое как кнопки и иконки, и взаимодействуете с этими иконками с помощью мыши или клавиатуры, а не с помощью текстовых сообщений или командной строки для выполнения задач или функций.
Из-за того, что автоматизация UI взаимодействует с большим количеством элементов и имеет множество зависимостей, она считается менее быстрой и более уязвимой, чем другие типы тестов, такие как API, тесты баз данных и модульные тесты. Автоматизация UI также имеет тенденцию к большому разнообразию пользовательских сценариев, а пользовательский интерфейс приложения вместе с его локаторами может меняться и приводить к сбоям. Автоматизация UI также требует взаимодействия с другими зависимостями, что может привести к узким местам. Несмотря на все это, существуют способы ускорения UI автотестов. И вот некоторые из них:
1. Используйте уровни API и базы данных приложения.
Уровень API приложения выполняет команды в тридцать пять раз быстрее, чем уровень пользовательского интерфейса, и может использоваться следующими способами для ускорения выполняемых автотестов:
Создание тестовых данных с помощью API — данные, необходимые для автоматизации тестирования в определенном формате, можно быстро создать с помощью API. Например, если вы хотите подготовить определенное количество пользователей с особыми функциями профиля, то вы можете использовать API для создания этих пользователей гораздо быстрее, чем если бы вы перешли к графическому интерфейсу пользователя и попытались создать эти 10 или 100 типов пользователей. Делая это через API, вы сэкономите много времени. При таком подходе будет меньше ошибок, поскольку, если вы собираетесь создать 20 пользователей, и запускаете тест на создание профиля 20 раз, то в процессе создания может случиться всякое. Интернет может быть медленным или графический интерфейс может долго загружаться, что влияет на скорость успешного создания профиля.
Очистка — очистка через API может помочь ускорить UI автотесты. Если мы воспользуемся сценарием, упомянутым выше, когда мы создали 20 пользователей, и предположим, что для каждого из этих пользователей мы добавили 10 товаров в корзину. При автоматизации тестирования мы хотим быть уверены, что все, что мы делаем в одном тесте, не оказывает негативного влияния на другие тесты. В этом случае нам нужно удалить товары из корзин 20 пользователей. Если бы мы делали это через пользовательский интерфейс, нам пришлось бы входить в профиль каждого пользователя, переходить в корзину, а затем удалять каждый товар из корзины (если нет кнопки удалить все товары). Это шаг очистки, который можно выполнить очень быстро с помощью одного-двух вызовов в API.
Верификация – верификация в тестах помогает нам определить, были ли предпринятые нами действия успешными или неудачными. Мы можем выполнять вызовы API для проверки того, что пользователь был создан, а также для проверки того, что покупки были совершены. Это сократило бы время, затрачиваемое нашими тестами вместо того, чтобы делать это через UI.
Таким же образом можно сэкономить время, создавая тестовые данные, очищая и проверяя их на уровне базы данных. Я использовал запросы к базе данных в проектах для поиска конкретных типов пользователей, которые мне нужны для выполнения тестов в определенных условиях. Например, я был на проекте, где мы продавали цветы для людей, которые ушли из жизни. В каждом похоронном бюро была своя бизнес-логика, а также дата смерти человека. Я использовал базу данных, чтобы получить пользователей, которые были в конкретном похоронном бюро и умерли менее 5 дней назад. Используя результаты этого запроса, я мог генерировать URL-адрес, который вел меня прямо на страницу смерти этого человека. Благодаря этому URL я мог без проблем проводить свои тесты.
Если бы я не сделал этот запрос, мне пришлось бы перейти на домашнюю страницу сайта, найти похоронное бюро, подождать, пока оно появится, а затем отфильтровать людей, которые умерли менее 5 дней назад, затем нажать на этого человека и ждать, пока страница загрузится. Это заняло бы больше времени, чем выполнение запроса к базе данных.
Если вы добавите этот метод к другим тестам с аналогичными условиями, то время выполнения уменьшится, и тем самым вы сэкономите много времени, используя базу данных. Таким образом можно ускорить UI тесты, используя API, базы данных и другие методы тестирования для управления Setup и Tear Down тестов.
2. Визуальная регрессия вместо выполнения определенных UI тестов
Визуальная регрессия — это процесс, с помощью которого проверяется графический интерфейс приложения, чтобы убедиться, что он сохраняет определенный вид. Это делается путем сравнения исходных или эталонных изображений с тем, что отображается в данный момент. Эти сравнения проводятся во время регрессионных тестов или всякий раз, когда добавляется что-то новое или вносятся некоторые изменения, и собираются новые скриншоты для сравнения с оригиналом.
Давайте подумаем о тестах, которые есть в наборе тестов автоматизации UI, которые он плохо обрабатывает или которые лучше выполнить с помощью визуальной регрессии. Проверку размера и цвета шрифта, интервала, выравнивания лучше всего выполнять с помощью визуальной регрессии, а не с помощью автоматизации UI. Визуальная регрессия также будет лучше находить ошибки в сценариях когда:
Размер, цвет и расположение шрифта различаются
Элемент присутствует на экране, но находится в неправильном месте, имеет неправильный цвет или заблокирован другим элементом
3. Параллельное выполнение
Автоматизацию тестирования можно запускать последовательно. То есть тесты один за другим. При использовании параллельного выполнения можно значительно повысить скорость автотестов. Параллельное выполнение позволяет запускать несколько автотестов одновременно. Таким образом, у вас будет открыто несколько браузеров, и вы увидите, что ваши тесты запускается одновременно.
Когда у вас есть несколькими наборов тестов (сьютов), таких как проверка входа в систему, оформление заказа и поиск/фильтрация, то вместо того, чтобы ждать завершения сьюта входа в систему, а затем запускать сьют оформления заказа и т. д., вы можете запустить все три сьюта одновременно. Во многих фреймворках автоматизации тестирования можно управлять количеством сессий и, следовательно, количеством параллельных потоков. Возможно, вы захотите провести две сессии. А возможно три или пять. Все зависит от типов тестов, которые у вас есть.
Преимущество этого заключается в том, что это сокращает время, необходимое для выполнения всего набора тестов. Если выполнение всех тестов заняло 10 минут, и вы решили запустить параллельное выполнение и разделили его на две сессии, то это будет означать, что теперь это должно занимать пять минут. Если вы увеличите количество параллелей, то это сократит время выполнения.
Это также поможет вам тестировать на большем количестве мобильных устройств и комбинаций браузеров. У вас может быть одно параллельное выполнение, предназначенное для работы в Google Chrome, одно для Safari, Internet Explorer, Firefox и так далее. Это означает, что у вас будет 4 разных сеанса для 4 разных браузеров, и время будет сокращено по сравнению с последовательным запуском.
При параллельном или распределенном выполнении тестов не забывайте о тестах, имеющих зависимости. В WebdriverIO есть возможность группировать зависимые тесты, чтобы при параллельном выполнении эти тесты выполнялись в одной и той же сессии в указанном порядке.
4. Распределенное выполнение
Распределенное выполнение обеспечивает те же преимущества и увеличение скорости, что и при параллельном выполнении тестов. Распределенное тестирование или распределенное выполнение — это когда тесты выполняются на множестве различных виртуальных машин или компьютеров в облаке. Облачные сервисы, такие как Docker, предоставляют возможность развертывания различных серверов или энвайронментов, которые можно использовать для выполнения тестов.
Вообще говоря, сквозные тесты или тесты UI — это емкие процессы, которые иногда могут занимать много вычислительной мощности. Распределенное выполнение в облаке повышает скорость тестирования; Машины более мощные, имеют больше памяти, места и позволяют выполнять тесты параллельно, поэтому тесты UI будут выполняться быстрее. Распределенное выполнение также избавляет от управления серверами и версиями браузеров. Это позволяет избежать трат времени на настройку новых энвайронментов. Эти энвайронменты могут быть настроены на этих компьютерах или ресурсах в облаке. Эти облачные сервисы обновляются при выходе новых версий мобильных телефонов или ОС, поэтому вам не нужно физически покупать новое мобильное устройство.
Параллельное и распределенное выполнение поможет ускорить тестирование и сократить время, необходимое для настройки новых энвайронментов.
Как параллельное и распределенное выполнение тестов экономит время
Параллельное и распределенное выполнение тестов экономит время, позволяя выполнять следующие действия:
Одновременный запуск нескольких автоматических тестов
сокращает время, необходимое для выполнения набора тестов
позволяет проводить одновременное тестирование на нескольких мобильных устройствах или в комбинациях ОС и браузера для настольных компьютеров
Запуск тестов на нескольких компьютерах с более быстрыми ресурсами или в облаке
увеличивает скорость проведения тестов
сокращает время, необходимое для настройки новых инвайроментов
избавляет от управления серверами и версиями браузера
5. Headless браузеры
Автоматизация браузера может быть выполнена как в обычном браузере, так и в headless-браузере. Headless-браузер работает так же, как и обычный браузер, однако у него нет графического интерфейса пользователя. Поэтому, когда вы запускаете тесты, вы не увидите всплывающего окна браузера и выполняемых действий. Взаимодействие с headless-браузером осуществляется через интерфейс командной строки.
Если тесты выполняются в конвейере непрерывной интеграции (CI pipeline), таком как GitHub Actions, Jenkins и т. д., то существует очень высокая вероятность того, что тесты пользовательского интерфейса выполняются без отображения UI.
Headless-браузеры не требуют видимого пользовательского интерфейса, и это делает headless тесты намного быстрее, чем в браузерах с пользовательским интерфейсом. При параллельном выполнении тестов браузеры на основе пользовательского интерфейса используют много памяти по сравнению с Headless браузерами.
Как и в случае со всеми советами, которыми я делился до сих пор, вы должны учитывать особенности вашего конкретного теста. Имейте в виду, что некоторые функции приложения могут иметь неожиданное поведение в headless. Headless браузеры не имитируют точное поведение пользователя, и некоторые тесты могут не пройти из-за скорости, с которой они выполняются. Кроме того, обычные пользователи не используют веб-сайт в headless-режиме, поэтому не менее важно запускать тестовые сценарии, проводить исследовательское тестирование, визуальную регрессию и другие формы тестирования на обычном браузере. Необходимо обеспечить согласованность функциональности и взаимодействия с пользователем веб-приложения.
Как headless-браузеры ускоряют автоматизацию UI тестирования
Headless-браузеры увеличивают скорость автоматизации UI тестирования, поскольку они:
Намного быстрее, чем браузеры с графическим интерфейсом.
Сокращают время, необходимое для выполнения автоматических сценариев по сравнению с браузером с графическим интерфейсом. Браузеры с графическим интерфейсом должны будут загружать CSS, изображения, рендерить HTML, и это увеличит время, необходимое для выполнения вашего скрипта.
Они полезны, когда сервер для выполнения тестов не имеет графического интерфейса. Это относится к большинству облачных серверов, которые можно использовать для выполнения параллельных/распределенных тестов.
Вы можете опробовать headless браузеры в различных фреймворках автоматизации тестирования, таких как WebdriverIO, Cypress, Selenium Webdriver, Puppeteer и других.
6. Эффективное управление «настройкой» (Setup) и «разрушением» (Tear Down) тестов
Мы обсуждали, как API и базы данных можно применять для создания конкретной среды, необходимой для проведения ваших тестов. Использование API, баз данных, файлов с данными, настраиваемых функций и других методик тестирования для организации процесса Setup и Tear Down тестового окружения может существенно ускорит выполнение ваших UI тестов.
Создавайте шаги для предварительной настройки приложения, которые необходимы для ваших тестов. Это особенно актуально для уникальных сценариев, когда данные пользователя или другие данные должны находиться в определенном состоянии до начала работы тестов. Не стоит заниматься подготовкой сценариев через графический интерфейс пользователя. Лучше использовать другие компоненты и подходы для выполнения этой предварительной настройки, таким образом, когда вы начинаете работу с тестом, вам нужно только проверить функционал, который вы непосредственно тестируете.
Подумайте о том, как и когда вы выполняете Setup и Tear Down. Они могут влиять на результаты тестов и вызывать их сбои, если не выполнять их правильно. Также это может увеличить время исполнения тестов.
Setup тестов — это процесс, с помощью которого создаются необходимые данные, пользователи или энвайронменты, необходимые для выполнения тестов. Tear Down— это противоположный процесс, когда вы удаляете или очищаете действия, выполненные во время тестов, чтобы убедиться, что они не оказывают негативного влияния на состояние, в котором должны находиться данные или энвайронменты для прохождения других тестов. В идеале Setup теста должен быть выполнен перед запуском теста. Поэтому, если у вас есть большая база данных, которую вы хотите настроить заранее, чтобы убедиться, что ваш энвайронмент, данные и пользователи находятся в определенном состоянии, сделайте это в самом начале.
Tear Down должен производиться после сценариев, где это необходимо; в противном случае делайте Tear Down, когда все тесты будут завершены. Это экономит время по сравнению с настройкой одного и того же или похожего сценария перед каждым тестом, а затем с последующим удалением и повторением процесса, тем самым увеличивая время, необходимое для выполнения тестов. Setup и Tear Down требуют некоторого планирования, но при правильном выполнении могут повысить скорость работы автоматизации UI.
7. Использование файлов cookie
Файлы cookie позволяют браузерам отслеживать, персонализировать и сохранять информацию о сеансе каждого пользователя. Без файлов cookies вам придется снова входить в систему после того, как вы покинете веб-сайт, или заново создавать корзину покупок, если вы случайно закроете страницу.
Cookies - важная часть интернет-взаимодействия. Они позволяют управлять сессиями, сохраняют информацию о входе в систему и предпочтениях. Cookies также используются для персонализации, чтобы вы могли получать индивидуальные рекламные объявления, а также для отслеживания действий. Если вы находитесь на сайте интернет-магазина и ранее просматривали товар, он может попасть в категорию вещей, которые вам понравились или которые вы ранее просматривали. Это помогает улучшить интернет-шопинг.
Файлы cookies можно использовать в веб-автоматизации, чтобы ускорить тестирование UI. Это достигается за счет использования информации, хранящейся в файлах cookies, такой как данные журнала для предварительной загрузки тестовых сценариев. Если вы не хотите каждый раз входить в систему через графический интерфейс или проводите определенный тест, вы можете использовать файлы cookies для предварительной загрузки информации для входа.
Проект, в котором есть фича-флаги, такие как A/B-тестирование, является хорошим кандидатом для использования файлов cookies, так как при A/B-тестах вы не уверены, какая версия A/B-тестирования появится, а при автоматизации тестирования вы захотите протестировать только определенный сценарий. Файлы cookies могут использоваться для отключения фича-флагов и конкретных фич. В этом случае ваши тесты всегда будут знать, какой сценарий будет загружен. Сценарий А или Б.
Сохраняя информацию, включая и выключая фичи, а также отслеживая и сохраняя информацию о сеансах пользователей, вы можете использовать файлы cookies для управления состоянием пользовательского интерфейса, чтобы увеличить скорость работы UI.
Различные фреймворки предоставляют возможность использовать файлы cookies в автоматизации тестирования. В Selenium Webdriver есть команда addCookie. Она используется для добавления файла cookies в текущий контекст просмотра. Она принимает набор определенных объектов JSON и показывает вам примеры на разных языках, которые поддерживает Selenium Webdriver.
Чтобы это сработало, вы должны находиться на домене, для которого будет действителен файл cookies. Вы можете предварительно установить файлы cookies перед началом взаимодействия с вашим сайтом. Как только он загрузится, эти файлы cookies будут там. Вы также можете управлять различными файлами cookies, и есть другие команды, которые вы можете использовать с Selenium Webdriver.
WebdriverIO также предоставляет возможность манипулировать файлами cookies и взаимодействовать с ними. Команда называется setCookies. Файл cookies может быть установлен для произвольной страницы, не находясь на этой странице, и в нем подробно описано, как вы устанавливаете различные файлы cookies.
Обратите внимание на конкретную платформу автоматизации тестирования, которую вы используете. Узнайте, как интегрировать файлы cookies в автоматизацию тестирования и ускорить UI тестирование.
8. Используйте навигационные ярлыки
Навигационные ярлыки ускоряют тест, так как исключают ненужные шаги. Переход непосредственно к UIautomation.com/profile/edit происходит намного быстрее, чем если
Перейдить в раздел uiautomation.com
Нажмать «Войти», затем
Нажмать Профиль
Нажмать «Редактировать»
Подождать, пока все эти страницы загрузятся
Переход непосредственно на страницу — это одна навигация, а не навигация, а затем выполнение полного списка шагов, прежде чем вы перейдете на страницу.
Использование всех советов, упомянутых выше, таких как настройка API и баз данных, для создания URL-адресов, к которым вы можете перейти напрямую, также поможет, как и использование файлов cookies для предварительной загрузки информации для входа, чтобы вы могли перейти непосредственно на веб-сайт.
9. Создание атомарных неповторяющихся тестов
В дополнение к этим советам, в целом, при автоматизации тестирования убедитесь, что вы создаете атомарные неповторяющиеся тесты. Не повторяйте несколько одинаковых сценариев раз за разом. Вы же не хотите, чтобы логин повторялся снова и снова в нескольких местах. Вместо этого вы можете использовать файлы cookies и ярлыки навигации, чтобы уменьшить это. Избегайте использования очень длинного сьюта, который будет работать очень долго и будет подвержен сбоям.
Ваши тесты должны быть очень маленькими и фокусировались на конкретной задаче, которую вы пытаетесь проверить. Используйте другие уровни пирамиды автоматизации тестирования и Ui автоматизацию, чтобы проверить те вещи, которые вам нужны.
Как ускорить UI тесты?
Автоматизация UI — это часть end-to-end тестов, которые выполняются медленно и дольше по сравнению с интеграционными и модульными тестами. Чтобы ускорить этот процесс, оцените свои тесты и выберите метод, который лучше всего подходит для проекта. Подумайте о других уровнях приложения, которые можно автоматизировать, и не пытайтесь сделать все на уровне пользовательского интерфейса. Вы также можете использовать другие уровни для помощи в ваших тестах. Файлы cookies, headless браузеры, параллельное/распределенное выполнение и ярлыки навигации — все это может помочь ускорить UI автотесты.
