В большинстве случаев одни и те же тесты можно запускать на разных браузерах
Обновлено: 04.07.2024
Selenium Grid является неотъемлемой частью автоматизированного тестирования, поскольку позволяет выполнять выполнение тестовых наборов в различных комбинациях браузеров, операционных систем (или платформ) и компьютеров. Это также позволяет выполнять параллельное выполнение для ускорения процесса кроссбраузерного тестирования.
Введение в Селеновую сетку 4
Сетка Selenium в основном используется для распределенного выполнения тестов. Он работает на архитектуре узла-концентратора, и эти принципы проектирования сетки реализованы в Selenium 4 Alpha.
В отличие от более ранних версий Selenium (т. Е. версии 3.x), серверная jar Selenium 4 содержит все (включая зависимости), необходимые для запуска сетки. Согласно официальной документации Selenium , Selenium Grid 4 разработан с нуля и не имеет общей кодовой базы с более ранними версиями.
Как скачать Selenium Grid 4?
Рекомендуется загружать файл jar в том же месте, где присутствует веб-драйвер Selenium для разных браузеров. Это связано с тем, что Selenium 4 Alpha обладает способностью автоматически определять веб-драйверы, присутствующие на узловой машине.
Selenium 4 Alpha можно запустить, выполнив следующую команду с терминала:
В моем случае файл jar загружается в тот же каталог, где присутствует Selenium WebDriver для Chrome, Firefox и других браузеров.
Основные особенности селеновой сетки 4
Выпуск Selenium 4 был отложен на довольно долгое время, и это вызвало большой интерес к функциям, предлагаемым для автоматизации тестирования Selenium. Без дальнейших церемоний давайте взглянем на некоторые из наиболее важных функций Selenium 4 Alpha, прежде чем перейти к учебнику по Selenium 4:
Один контейнер для концентратора и узла
До сих пор процесс настройки Selenium Grid включал запуск концентратора и узлов отдельно. С Selenium 4 процесс стал намного более плавным, так как концентратор и узел являются частью одного и того же файла jar. Как только сервер запущен, он действует и как концентратор, и как узел.
Улучшенная Архитектура
Начиная с Selenium 2, Концентратор состоял из трех процессов – Маршрутизатора, Карты сеансов и Распределителя. Selenium 4 имеет новую архитектуру, которая поддерживает четыре отдельных процесса – Маршрутизатор, Карту сеансов, Распределитель и Узел.
- Маршрутизатор – Прослушивает запрос на новый сеанс.
- Распределитель – Выбирает соответствующий узел, на котором должен быть выполнен тест.
- Карта сеанса – Сопоставляет идентификатор сеанса с узлом.
- Узел – Тестовая машина, на которой выполняется тест.
В дальнейших разделах руководства по Selenium 4 мы подробно рассмотрим архитектуру Selenium 4 Alpha.
Различные Типы Сеток
До версии 3 сетки Selenium ее можно было использовать только в качестве концентратора и узла(узлов). Хотя это все еще поддерживается в Selenium 4, теперь он поддерживает еще два типа сетки. Вот три типа сеток, поддерживаемых в Selenium 4:
- Автономный режим
- Классическая сетка (концентратор и узел, как в более ранних версиях)
- Полностью распределенный (Маршрутизатор, Дистрибьютор, Сеанс и узел)
Поддержка Докеров
Эта версия также поставляется с поддержкой Docker. На данный момент интеграция Docker не использует доменные сокеты Unix, поэтому вам необходимо убедиться, что демон прослушивает порт 2375.
По сравнению с Selenium Grid 3, эту версию проще использовать на виртуальных машинах. Мы также обсудим простоту использования в этом уроке по Selenium 4.
Архитектурный обзор Selenium Grid 4
Прежде чем мы подробно рассмотрим архитектуру Grid 4, мы сделаем краткий обзор Selenium Grid 3. Это поможет получить более четкое представление об архитектурных различиях между Grid 4 и более ранними версиями Grid. Также помогает нам понять, как это влияет на процесс автоматизации тестирования Selenium.
Архитектура селеновой сетки 3
Как я уже упоминал в этом разделе учебника по Selenium 4, версия Grid 3 состоит из двух основных блоков – концентратора и узла, как показано на рисунке ниже.
Как вы можете видеть, эта версия Selenium Grid состояла только из концентратора и узлов (где выполняются тесты), подключающихся к Концентратору.
Архитектура селеновой сетки 4
В более ранних версиях сетки было только два компонента – концентратор и узел, но это изменилось с появлением Selenium Grid 4. Теперь Selenium Grid 4 состоит из четырех процессов – Маршрутизатора, Распределителя, Карты сеансов и Узла.
Вот схема архитектуры верхнего уровня Selenium 4 Alpha (в полностью распределенном режиме):
Вот подробный список шагов, выполненных в рамках кроссбраузерного тестирования полностью распределенного варианта Selenium Grid 4 :
Шаг 1 – Первым шагом является запуск карты сеансов, которая в первую очередь отвечает за сопоставление идентификаторов сеансов с соответствующим узлом, на котором выполняется сеанс.
При создании нового сеанса комбинация идентификатора сеанса и URI узла (Единый идентификатор ресурса) сохраняется на Карте Сеансов.
Все другие типы запросов отправляются Узлу на основе запроса после запроса URI узла с карты Сеансов с использованием идентификатора сеанса.
Шаг 4 – Сетка бесполезна без Узла. Веб-драйвер Selenium соответствующих браузеров размещается в том же каталоге, где находится файл jar Grid 4.
Опция –обнаружить-драйверы используется для автоматической идентификации веб-драйверов Selenium, присутствующих в системе.
Когда узел создается под распространителем, сведения об Узле вместе с URI узла обновляются на карте сеанса. На скриншоте, показанном ниже, URI узла равен 5555.
Шаг 5 – Запрос веб-драйвера Selenium для запуска удаленного сеанса отправляется маршрутизатору.
Шаг 6 – Вызовы для создания сеанса перенаправляются Маршрутизатором Распространителю, а все другие типы запросов отправляются непосредственно с Маршрутизатора на Узел.
В более ранних версиях Selenium Grid эти процессы происходили внутри концентратора, следовательно, внутренние компоненты не были полностью известны разработчикам и тестировщикам, использующим эту версию Selenium Grid. Обновленная архитектура Selenium Grid 4 упрощает процесс отладки и устранения неполадок, что, в свою очередь, делает автоматизацию тестирования Selenium более плавной.
Теперь мы перейдем к интересной части руководства по Selenium 4, то есть к запуску тестов для автоматизации тестирования Selenium.
Запуск тестов на Selenium Grid 4
В этой части руководства по Selenium 4 мы демонстрируем различные способы выполнения тестов на сетке 4 для автоматизации тестирования Selenium. Ниже приведен тестовый пример, используемый для демонстрации использования:
Далее в этом руководстве по Selenium 4 мы будем использовать платформу автоматизации тестирования для автоматизации тестирования Selenium. Вы можете обратиться к нашим более ранним блогам, если вам потребуется краткое описание структуры тестирования. ((См.: Поставщики данных в тестировании )
Мы использовали IDE IntelliJ для разработки и выполнения тестов. Вы также можете использовать тот же проект на предпочтительной СТОРОНЕ по вашему выбору, например, Eclipse для этой обучающей демонстрации Selenium 4.
Пошаговое руководство по коду
Тестовый случай (test_todo_app()) реализован в аннотации @test. Стандартные методы Selenium (например, SendKeys, click и т.д.) Применяются к необходимым веб-элементам.
Мы выполним один и тот же тестовый код на разных типах сеток – автономной сетке Selenium, классической сетке Selenium и полностью распределенной сетке Selenium.
Мы уже знаем из этого руководства по Selenium 4, что Grid 4 автоматически определяет драйверы Selenium, которые у вас есть в системе. Рекомендуется, чтобы все исполняемые файлы находились в ПУТИ или в папке, в которой находится файл Selenium jar.
Здесь начинается самая важная часть учебника по Selenium 4, которая будет необходима для успешной автоматизации тестирования Selenium.
Автономная Селеновая сетка
В автономном режиме сервер Selenium запускает все в процессе. Он вызывается путем выполнения следующей команды на терминале:
Сетка автоматически определяет, что веб-драйвер для Chrome и Firefox присутствует в системе.
Я надеюсь, что этот учебник по Selenium 4 помог вам понять, как создать сеанс с помощью Grid 4 для автоматизации тестирования Selenium.
Узел (если концентратор и узел работают на одной машине)
Узел (если концентратор и узел находятся на разных машинах)
Для демонстрации мы запускаем концентратор и узел на одной машине. После запуска концентратора он открывает сокеты XPUB и XSUB, которые привязываются к tcp://*:4442 и tcp://*.4443 соответственно.
Как только узел запускается с помощью упомянутой ранее команды, он подключается к тому же адресу (т.е. tcp://*:4442 и tcp://*.4443 ). Опция –обнаружить-драйверы автоматически определяет веб-драйверы Selenium, присутствующие в системе.
Как видно из выходных данных, был создан сеанс с идентификатором сеанса 609efa510550943bdcedc46f4d67d1c6 .
Сетка 4 может быть запущена полностью распределенным способом, при этом каждая часть выполняется в своем собственном процессе. Я уже описал архитектуру полностью распределенной сетки Selenium в этом разделе учебника по Selenium 4. Это даст общее представление о том, как выглядит полностью распределенная сетка.
Шаг 1 – Запустите карту сеансов
Он сопоставляет идентификаторы сеанса с узлом, на котором в данный момент выполняется сеанс.
Шаг 2 – Запустите дистрибьютора
Он прослушивает запросы сеанса на порту 5556.
Шаг 3 – Запустите маршрутизатор
Шаг 4 – Создайте узел
После создания Узла сведения об узле и URI Узла обновляются на Карте Сеансов.
Завершая Это
Я надеюсь, что этот Учебник по Selenium 4 смог привнести совершенно новый взгляд на автоматизацию тестирования Selenium для распределенного тестирования. Благодаря совершенно новой архитектуре он поддерживает различные режимы – Автономный, Концентратор и узел, а также полностью распределенный. Он более современный, чем предыдущие версии сетки, так как его можно легко использовать с современными технологиями, такими как Docker и Kubernetes. Он также предназначен для использования преимуществ облачных инфраструктур, таких как AWS и Azure. Хотя Selenium 4 все еще находится в альфа-фазе, сообщество разработчиков и тестировщиков испытывает большое волнение, и до сих пор его функции работали хорошо.
Selenium 4 можно использовать для автоматизации тестирования Selenium в LambdaTest, который предлагает кроссбраузерное тестирование для более чем 2000 браузеров и операционных систем. Генератор желаемых возможностей предлагает возможности как для Selenium Grid 3, так и для Selenium Grid 4. Счастливого тестирования!
Как запустить один и тот же тест в нескольких браузерах одновременно?
Пытался использовать Selenium grid, но не хватило знаний и навыков гугления.
Запускаю на своей машине Windows 8.1
Использую JUnit Webdriver 2.0 maven
Параллельный запуск тестов является одним из мощных средств для ускорения тестирования. Хорошо автоматизированные тесты должны быть независимыми, изолированными и воспроизводимыми, эти качества делают их идеальными для одновременного выполнения. Однако на практике не все тестовые классы разработаны с возможностью параллельного запуска. Такие аспекты, как общие изменяемые переменные, общий доступ к файлу и базе данных, или использование встроенного веб-сервера, могут сделать параллельный запуск тестов очень сложным или вообще невозможным. Тем не менее, одновременный запуск тестов, определенно, очень полезная вещь.
Начиная с версии 4.7 в JUnit была добавлена возможность параллельного запуска, для этого нужно настроить Maven следующим образом:
Атрибут parallel может принимать значения «classes», «methods» или «both». При этом нельзя однозначно утверждать о количестве запущенных одновременно тестов, это напрямую зависит от параметров компьютера и настроек плагина по-умолчанию.
Во время запуска теста найдите следующую строку в консоли, она позволяет узнать параметры с которыми выполняется параллельный запуск:
Атрибут threadCount позволяет указать, сколько потоков должно быть выделено для запуска тестов (сколько тестов должно запускаться параллельно). Обратите внимание, что его использование с параметром perCoreThreadCount , установленным в true , может исказить реальное количество запускаемых одновременно тестов. В то же время perCoreThreadCount позволяет добиться большей гибкости при запуске тестов на разных машинах. Например, при запуске тестов со следующей конфигурацией на машине с 2-х ядерным процессором, одновременно будут выполняться 4 тестовых класса, а не 2:
Существует еще такой атрибут как useUnlimitedThreads . При его использовании будет создаваться столько потоков, сколько классов или методов в Вашем проекте, и все тесты будут пытаться запуститься одновременно. useUnlimitedThreads отлично работает для юнит-тестов, но для функционального web тестирования его лучше не использовать.
Настройки конфигурации полностью зависят от характера Ваших тестов, поэтому стоит поэкспериментировать с различными конфигурациями и посмотреть, какой из вариантов настройки больше всего подходит для Вас.
В будущем советую все таки использовать Google. И не бояться эксперементировать со своим проектом. Надеюсь предоставленная информация Вам поможет, удачи в дальнейших трудах)
В это статье я расскажу о применении инструмента изначально предназначенного для функционального тестирования при тестировании нагрузочном web части системы электронного документооборота (СЭД).
Зачем вообще это понадобилось? Мы преследовал две цели – введение автоматических тестов для наших web-приложений и создание нагрузочных тестов на основе функциональных тестов.
Почему для теста использовался именно Selenium, а не более подходящий инструмент – LoadRunner, jMeter? С помощью LoadRunner’s нагрузочный тест был проведён, но результаты были поставлены под сомнения – при эмуляции двухсот пользователей страницы загружалась за 2 секунды плюс-минус 2%, хотя при открытии этих же страниц из браузера отображение происходило более чем за 3 секунды. Так что хотелось провести нагрузочные тесты максимально приближенные к реальности, а это можно сделать только с помощью полной эмуляции поведения пользователя. Для этого как раз подходили инструменты для функционального тестирования с их работой с браузерами – сайт открывался бы через обычный браузер, т.е. так как делал бы это пользователь.
Про Selenium
Общая архитектура
Приложение разделено на уровни (для наглядности на схеме элементы каждого уровня имеют осмысленные названия, а не просто Тест 1, Методы 2).
Первый уровень – уровень «запускальщика» тестов. Он просто запускает тесты. В настройках конфигурируется количество потоков, количество запусков теста, классы теста.
Второй уровень – сами тесты. Они выполняют бизнес операции – авторизируются, открывают списки документов, открывают документа, переходят по вкладкам документов.
Третий уровень – уровень работы с web-элементами. В нём содержаться атомарные пользовательские операции по работе с системой – открытие списка документов, переход к определённому документу, работа с вкладками документа.
Для начала перечисленных действий будет достаточно для обеспечения минимальной работы с системой. В дальнейшем они будут добавляться.
Запуск тестов
Программа для запуска jUnit тестов довольно проста и состоит из трёх классов – класс, который выполняет указанные тесты в своём потоке; класс «слушателя» jUnit теста для подсчёта времени выполнения теста; класс для формирования потоков и их запуска.
Код Runner’а
Код класса запускающего тесты
Тесты
Тесты были написаны простые, но, тем не менее, отражающие работу пользователя – открытие списка документов, открытие карточки документа, переход по вкладкам карточки.
Для написания тестов использовался jUnit. Хотя также можно использовать TestNG, который поддерживает параллельный запуск тестов (а при нагрузочном тестировании это обязательное требование). Но выбран был именно jUnit по двум причинам: 1) в компании он широко распространён и давно используется 2) нужно было всё равно писать свой «запускальщик» который бы позволил, не изменяя тесты, запускать их в разных потоках (в TestNG параллельный запуск настраивается в самих тестах) и собирать статистику по их выполнению.
Помимо тестов были написаны дополнительные модули – pool webdriver’ов (здесь слово webdriver используется в терминологии Selenium’а), pool пользователей, pool документов, rule (в терминологии jUnit) по снятию скриншотов при ошибке, rule по выдаче webdriver тесту, rule авторизации.
Pool webdriver’ов – это класс, который управляет получением webdriver из сервера Selenium’а и распределяет их между тестами. Нужен для того, что бы абстрагировать работу с Selenium’ом – тесты будут получать webdriver’ы и отдавать их этому pool’у. Webdriver’ы при этом не закрываются (не вызывается метод close). Это нужно потому, что бы не перезапускать браузер. Т.е. таким образом получается «реиспользование» webdriver’ов другими тестами. Но повторное использование имеет свои минусы – при возвращении webdriver’а в pool нужно «подчистить» за собой – удалить все cookie или, если это сделать нельзя, выполнить logout.
Так же, как в последствии выяснилось, этот pool должен перезапускать webdriver’ы, сессия которых завершилась. Такое возможно, когда произошла ошибка на стороне сервера.
Pool пользователей нужен в основном при нагрузочном тестировании, когда нужно запускать одинаковые тесты под различными пользователями. Он всего лишь по кругу отдаёт логин/пароль очередного пользователя.
Pool документов, так же как и пользователей, нужен в основном при нагрузочной тестировании – он по кругу возвращает id документов определённого типа.
Rule по снятию скриншотов при ошибке, нужен, как следует из названия, снимать скриншот при ошибке выполнения теста. Он сохраняет его в папку и записывает в лог название скриншота со stacktrace’ом ошибки. Очень помогает в дальнейшем «увидеть» ошибку, а не только прочитать её в логах. ( internetka.in.ua/selenium-rule-screenshot )
Rule по выдаче webdriver’а тесту нужен для того, что бы автоматизировать получение перед началом тестового метода и возврат при его окончании webdriver’а из pool’а webdriver’ов.
Rule авторизации нужен так же для автоматизации, только теперь авторизации – что бы в каждом тестовом методе не писать login\logout.
Сбор статистики
Сбор статистики происходил из двух мест – собиралось общее время выполнение тестовых методов (из уровня «запускальщика») и время выполнения атомарных пользовательских операций (из третьего уровня). Для решения первой проблемы использовался наследник RunListener’а, в котором переопределялись методы начала и окончания теста и в них собиралась информация о выполнении.
Решение второй проблемы можно было выполнить «в лоб» — в начале и конце каждого метода, время выполнения которого нужно записывать, писать код для отсчёта этого времени. Но так как методов уже сейчас больше пяти, а в дальнейшем их будет гораздо больше, то хотелось бы это автоматизировать. Для этого воспользовался AOP, а конкретно AspectJ. Был написан простой аспект, который добавлял подсчёт времени выполнения всех public методов из классов с пользовательскими операциями. Время подсчитывалось только успешно выполненных методов, что бы методы, вылетевшие с ошибкой на середине выполнения, не портили статистику. Так же обнаружился один недочёт при сборе статистики по названиям методов – так как методы по работе с пользовательскими операциями были универсальны и вызывались всеми тестами, но статистику нужно было собирать по типам документов. Поэтому статистика собиралась не только по названию методов, но ещё и по их аргументам, идентифицирующих тип документа.
Код метода аспекта
Метод getPointName формирует название точки среза времени на основе названия метода и его параметров.
Браузеры для нагрузочного тестирования
После написания всех тестов встал вопрос, на каких браузерах его запускать. В случае функционального тестирования здесь всё просто – нужно запускать тесты на тех браузерах, на которых будут работать пользователи. Для нас это IE 9. Поэтому попробовал запустить тесты на IE с несколькими экземплярами браузера на машину, что бы один компьютер смог эмулировать работу нескольких пользователей (В Selenium один WebDriver – это один экземпляр браузера). В результате на моей машине (4Гб ОЗУ, 2.3 Core 2 Duo) нормально работало только 4 экземпляра IE. Что не очень хорошо – для эмуляции двухсот пользователей потребуется 50 машин. Нужно было искать альтернативу. А это: а) другие desktop браузеры б) headless браузеры.
Из desktop браузеров протестированы были FF и Chrome. С Chrome ситуация была аналогичная, плюс он для своей работы требовал запуска в отдельном процессе WebDriver’а на каждый экземпляр Chrome. Что повышало требования к ресурсам. С FF ситуация была чуть лучше – нормально работало 5 браузеров без дополнительного запуска WebDriver’ов. Но ситуацию это не сильно улучшило.
Конфигурация Selenium’а
В итоге пришли к следующей конфигурации: На одном компьютере запускался Selenium в режиме hub с дополнительным параметром –timeout 0. Это нужно было потому, что иногда сессии закрывались по timeout из за длительного бездействия тестов. На других компьютерах запускался Selenium в режиме node. Для мощных компьютеров, способных обеспечить работу 15 браузеров, node Selenium’а запускался с дополнительной настройкой, позволяющей запускать 15 копий FF и указывающей, что одновременно можно работать с 15 сессиями.
Проведение тестов
Тесты проводились следующим образом – на одном компьютере запускался один экземпляр браузера, который выполнял тестовые сценарии несколько раз и с которого снимали время выполнения. На остальных компьютерах запускались те же тестовые сценарии, но уже на нескольких браузерах. Такое разделение для замера времени нужно для того, что бы одновременная работа браузеров не отражалась на результате измерения. Так как если делать те же измерения на нескольких запущенных браузерах, то время будет чуть больше.
Пару слов нужно сказать о тестовых сценариях и подсчёте времени их выполнения. Каждый сценарий включал в себя открытие документов каждого типа. Т.е. сначала открывался входящий документ, потом исходящий документа и т.д. Вот здесь нужно учесть следующую ситуацию – если нужно снять время открытия только входящего документа, и при этом запустить на всех машинах выполнения только это сценария, то время будет существенно меньше (на 50%) чем, если бы снимать время при одновременном выполнении всех сценариев. В моём случае, скорее всего это было связано с кешированием на уровнях web приложения и СУБД. И тем, что открывалось мало уникальных документов. Возможно, при большом количестве разных документов различия будут не столь существенны.
В идеале хотелось бы получить распределение пользователей и документов таким, каким оно будет в реально работающей системе. Т.е., например, в реальной системе будет 10 человек работать с входящими и 30 с исходящими. И в нагрузочном тесте так же отразить это соотношение – количество тестов по исходящим в три раза больше чем с входящими документами. Но так как ещё тестируемая система пока не вошла в эксплуатацию и этих данных пока нет, то тестирования происходило без их учёта.
Подведение итогов
В результате тестов для 1-го, 16-ти, 26-ти и 70 пользователей был составлен график по каждым сценариям. Пока ещё количество пользователей не слишком большое, что бы сделать точные выводы, но уже сейчас можно проследить темпы роста времени.
Зависимость времени открытия документов от количества работающих пользователей:
По нему уже можно будет точно определить возможности системы и найти её узкие места.
В этой статье мы рассмотрим кросс-браузерное тестирование. Это тип тестирования, который проверяет, работает ли приложение так, как ожидается, в нескольких браузерах, операционных системах и устройствах. Мы можем проводить кросс-браузерное тестирование с помощью автоматизации и без нее. Сценарии автоматизированного тестирования могут быть написаны или созданы с помощью таких программ, как TestProject и Selenium.
Примечание: Код из этой статьи находится на GitHub здесь.
Что такое кросс-браузерное тестирование?
Кросс-браузерное тестирование гарантирует, что наше тестируемое приложение (AUT) совместимо с каждым браузером, операционной системой и устройством. Цель заключается в сравнении ожидаемого поведения приложения в различных случаях. Бывают случаи, когда один и тот же тестовый сценарий проходит на одном или нескольких экземплярах, но не работает на другом экземпляре.
Возможно, сбой произошел из-за нашего тестового скрипта или приложения. Вы когда-нибудь пытались открыть веб-сайт с помощью Internet Explorer, но он не работал, а затем тот же сайт без проблем открывался в Chrome? Такие проблемы выявляются во время кросс-браузерного тестирования, поскольку данные из AUT отображаются по-разному в каждом браузере.
Преимущества кросс-браузерного тестирования
Мы проводим кросс-браузерное тестирование, устанавливая базовую линию. Базовая линия - это стандартный сценарий тестирования. Его цель - изучить, как работает наш AUT, используя один браузер, одну операционную систему и одно устройство. После этого мы можем использовать базовую линию в других комбинациях браузеров, операционных систем и устройств.
Я сосредоточусь на двух преимуществах кросс-браузерного тестирования:
Время
Создание и выполнение индивидуального сценария тестирования (Test Script) для уникальных сценариев занимает много времени. Поэтому наши тестовые сценарии создаются с тестовыми данными для использования их комбинаций. Один и тот же сценарий тестирования может выполняться на Chrome и Windows для первой итерации, затем на Firefox и Mac для второй итерации, а затем на других сценариях для последующих итераций.
Это экономит время, поскольку мы создаем только один тестовый сценарий, а не несколько. Ниже приведены 2 фрагмента кода для загрузки и получения заголовка для страницы TestProject. Один пример - это кросс-браузерное тестирование, а другой пример содержит отдельные тестовые сценарии для трех браузеров (Chrome, Firefox и Edge).
Тестовое покрытие
Тестовое покрытие - это техника, которая определяет, что и в каком объеме покрывается в наших тестовых сценариях.
Мы определяем особенности и убеждаемся, что для этих особенностей есть адекватные тестовые сценарии. Тестовое покрытие - это преимущество, поскольку оно позволяет нам измерить качество наших тестовых циклов.
Что будет включено в наши сценарии тестирования, зависит от требований.
То, сколько охвачено в наших сценариях тестирования, зависит от браузеров и их различных версий.
Тестовое покрытие является эффективным мерилом для процесса тестирования. Однако 100% покрытие трудно обеспечить, и, скорее всего, функция ведет себя не так, как это обычно происходит в конкретной версии.
Как осуществить кросс-браузерное тестирование в Selenium?
Мы осуществляем кросс-браузерное тестирование в Selenium, используя его сетку (grid) или тестовые данные. Selenium Grid упрощает процесс, а тестовые данные используются в качестве исходных. С помощью Selenium Grid наши тестовые сценарии выполняются параллельно на нескольких удаленных устройствах. Команды отправляются клиентом удаленным экземплярам браузера.
Тестовые данные могут храниться в файле Excel, CSV, файле свойств, XML или базе данных. Мы также можем объединить TestNG с тестовыми данными для проведения тестирования на основе данных или кросс-браузерного тестирования. Для тестирования на основе данных аннотация DataProvider и атрибут dataProvider или атрибут dataProviderClass позволяют нашему тестовому сценарию получать неограниченное количество значений.
Когда речь идет о кросс-браузерном тестировании, мы можем использовать тег параметра и аннотацию Parameters для передачи различных имен браузеров. Ниже приведены фрагменты кода, отображающие XML-файл с тегом параметра и тестовый сценарий с аннотацией Parameters.
В XML-файле тег параметра расположен на уровне теста. У нас есть возможность разместить тег на уровне тестового набора, на уровне теста или на обоих уровнях. Обратите внимание, что тег параметра имеет имя и значение с данными между двойными кавычками. Его имя, т.е. "BrowserType", передается тестовому сценарию через аннотацию @Parameters, а значение, т.е. "Chrome", передается в операторы if и else if.
Операторы if и else if устанавливают Chrome, Edge или Firefox. Каждый браузер получал команды от одного и того же тестового сценария после выполнения из XML-файла. Следующие результаты тестирования показывают, как успешно загружается страница TestProject, а консоль печатает уникальное имя браузера и заголовок страницы.
Кросс-браузерное тестирование в Selenium с помощью TestProject
OpenSDK / Закодированный тест
AI-Powered Test Recorder
С помощью AI-Powered Test Recorder мы создаем новое веб-задание, затем выбираем несколько браузеров, таких как Chrome, Edge и Firefox. Тест в задании TestProject позволяет нам выбрать дополнительный источник данных CSV, если мы хотим выполнить тестирование на основе данных. Вот несколько скриншотов, показывающих шаги по выполнению кросс-браузерного тестирования и отчета.
Вот пошаговая демонстрация кросс-браузерного тестирования с помощью TestProject AI-Powered Test Recorder.
Выводы
Подводя итоги, кросс-браузерное тестирование - это отличный способ использовать один сценарий тестирования и несколько браузеров одновременно. Некоторые из преимуществ включают время и тестовое покрытие. Время является нашим преимуществом, поскольку мы не создаем несколько тестовых сценариев для каждого браузера. Тестовое покрытие - это еще одно преимущество, поскольку мы можем тестировать не только версию браузера для конкретного браузера.
Кросс-браузерное тестирование осуществляется с помощью Selenium и TestProject.
Перевод статьи подготовлен в рамках курса "Java QA Engineer. Basic". Всех желающих приглашаем на двухдневный онлайн-интенсив «Теория тестирования и практика в системах TestIT и Jira». На интенсиве мы узнаем, что такое тестирование и откуда оно появилось, кто такой тестировщик и что он делает. Изучим модели разработки ПО, жизненный цикл тестирования, чек листы и тест-кейсы, а также дефекты. На втором занятии познакомимся с одним из главных трекеров задач и дефектов — Jira, а также попрактикуемся в TestIT — отечественной разработке для решения задач по тестированию и обеспечению качества ПО.
14 декабря на митапе в Санкт-Петербурге я (Артем Соковец) совместно с коллегой, Дмитрием Маркеловым, рассказывал о текущей инфраструктуре для автотестов в СберТехе. Пересказ нашего выступления — в этом посте.
Что такое Selenium
Selenium — это инструмент для автоматизации действий веб-браузера. На сегодня данный инструмент является стандартом при автоматизации WEB.
Существует множество клиентов для различных языков программирования, которые поддерживают Selenium Webdriver API. Через WebDriver API, посредством протокола JSON Wire, происходит взаимодействие с драйвером выбранного браузера, который, в свою очередь, работает с уже реальным браузером, выполняя нужные нам действия.
На сегодня стабильная версия клиента — Selenium 3.Х.
Simon Stewart, к слову, обещал представить Selenium 4.0 на конференции SeleniumConf Japan.
Selenium GRID
В 2008 году Philippe Hanrigou анонсировал Selenium GRID для создания инфраструктуры автотестов с поддержкой различных браузеров.
Selenium GRID позволяет запускать тесты на разных ОС и различных версиях браузеров. Также он существенно экономит время при прогоне большого количества автотестов, если, конечно, автотесты запускаются параллельно с использованием maven-surfire-plugin или другого механизма распараллеливания.
Само собой, Selenium GRID имеет и свои минусы. При использовании стандартной реализации приходится сталкиваться со следующими проблемами:
- постоянным рестартом hub и node. Если хаб и узел долго не используются, то при последующем коннекте возможны ситуации, когда при создании сессии на ноде, эта самая сессия отваливается по таймауту. Для восстановления работы требуется рестарт;
- ограничением на количество узлов. Сильно зависит от тестов и настроек грида. Без танцев с бубном оно начинает тормозить при нескольких десятках подключенных нод;
- скудной функциональностью;
- невозможностью обновлений без полной остановки сервиса.
Первоначальная инфраструктура автотестов в СберТехе
Ранее в СберТехе была следующая инфраструктура для UI-автотестов. Пользователь запускал сборку на Jenkins-е, который с помощью плагина обращался в OpenStack за выделением виртуальной машины. Происходило выделение ВМ со специальным «образом» и нужным браузером, и только затем на этой ВМ выполнялись автотесты.
Если требовалось прогнать тесты в браузерах Chrome или FireFox, то выделялись Docker-контейнеры. А вот при работе с IE приходилось поднимать «чистую» ВМ, что занимало до 5 минут. К сожалению, Internet Explorer является приоритетным браузером в нашей компании.
Основная проблема была в том, что такой подход занимал очень много времени при прогоне автотестов в IE. Приходилось разделять тесты на suites и стартовать сборки параллельно, чтобы достичь хоть какого-то сокращения времени. Мы стали задумываться о модернизации.
Требования к новой инфраструктуре
Посещая различные конференции по автоматизации, разработке и DevOps (Heisenbug, SQA Days, CodeOne, SeleniumConf и другие) у нас постепенно формировался список требований к новой инфраструктуре:
- Сократить время на прогон регрессионных тестов;
- Обеспечить единую точку входа для автотестов, что позволит облегчить их отладку для специалиста по автоматизации. Не редки случаи, когда локально все работает, а как только тесты попадают в pipeline – сплошные падения.
- Обеспечить кроссбраузерность и мобильную автоматизацию (Appium-тесты).
- Придерживаться облачной архитектуры банка: управление Docker-контейнерами должно происходить в OpenShift.
- Сократить потребление памяти и CPU.
Краткий обзор существующих решений
Определившись с задачами, мы проанализировали существующие на рынке решения. Основное, что мы рассмотрели, — продукты команды Aerokube (Selenoid и Moon), решения Alfalab (Альфа Лаборатория), JW-Grid (Авито) и Zalenium.
Ключевым минусом Selenoid стало отсутствие поддержки OpenShift (обертка над Kubernetes). О решении Alfalab есть статья на Хабре. Это оказался тот же Selenium Grid. Решение Авито описано в статье. Доклад о нем мы видели на конференции Heisenbug. В нем тоже были минусы, которые нам не понравились. Zalenium — это опенсорсный проект, также не без проблем.
Рассмотренные нами плюсы и минусы решений сведены в таблицу:
В итоге мы остановили свой выбор на продукте от Aerokube — Selenoid.
Selenoid vs Moon
Четыре месяца мы использовали Selenoid при автоматизации экосистемы Сбербанка. Это неплохое решение, но Банк движется в сторону OpenShift, а развернуть Selenoid в OpenShift нетривиальная задача. Тонкость в том, что Selenoid в Kubernetes управляет докером последнего, а Kubernetes про это ничего не знает и не может правильно шедулить другие ноды. Кроме того, для Selenoid в Kubernetes требуется GGR (Go Grid Router), в котором хромает распределение нагрузки.
Поэкспериментировав с Selenoid, мы заинтересовались платным инструментом Moon, который ориентирован именно на работу с Kubernetes и обладает рядом преимуществ по сравнению с бесплатным Selenoid. Он развивается уже два года и позволяет развернуть инфраструктуру под Selenium тестирования UI, не тратясь на DevOps инженеров, обладающих тайным знанием о том, как развернуть Selenoid в Kubernetes. Это важное преимущество — попробуйте проапдейтить кластер Selenoid без даунтайма и уменьшения емкости при запущенных тестах?
Moon был не единственным возможным вариантом. К примеру, можно было бы взять Zalenium, упомянутый выше, но фактически это тот же Selenium Grid. У него внутри хранится полный список сессий в хабе, и если хаб падает, то тестам конец. На этом фоне Moon выигрывает за счет того, что не имеет внутреннего состояния, поэтому падение одной из его реплик вообще незаметно. У Moon все «gracefully» — его можно перезапускать безбоязненно, не дожидаясь завершения сессии.
Zalenium имеет и другие ограничения. Например, не поддерживает Quota. Нельзя поставить две его копии за балансировщик распределения нагрузки, потому что он не умеет распределять свое состояние между двумя и более «головами». Да и в целом, он с трудом заведется на своем кластере. Zalenium использует PersistentVolume для хранения данных: логов и записанных видео тестов, но, в основном, это касается дисков в облаках, а не более отказоустойчивого S3.
Инфраструктура автотестов
Нынешняя инфраструктура с использованием Moon и OpenShift выглядит следующим образом:
Пользователь может запускать тесты как локально, так и используя CI-сервер (в нашем случае Jenkins, но могут быть и другие). В обоих случаях мы посредством RemoteWebDriver обращаемся к OpenShift, в котором развернут сервис с несколькими репликами Moon. Далее запрос, в котором указан нужный нам браузер, обрабатывается в Moon, в результате чего посредством Kubernetes API инициирует создание пода с этим браузером. Затем Moon напрямую проксирует запросы в контейнер, где и проходят тесты.
По окончании прогона заканчивается сессия, под удаляются, ресурсы освобождаются.
Запуск Internet Explorer
Конечно, не обошлось без сложностей. Как ранее говорилось, целевым браузером для нас является Internet Explorer — большинство наших приложений использует компоненты ActiveX. Поскольку у нас используется OpenShift, наши Docker-контейнеры работают на RedHat Enterprise Linux. Таким образом, встает вопрос: как запустить Internet Explorer в Docker-контейнере, когда хостовая машина у нас на Linux?
Ребята из команды разработчиков Moon поделились своим решением по запуску Internet Explorer и Microsoft Edge.
Недостаток такого решения в том, что Docker-контейнер должен запускаться в привилегированном режиме. Так инициализация контейнера с Internet Explorer после запуска теста у нас занимает 10 секунд, что в 30 раз быстрее по сравнению с использованием предыдущей инфраструктуры.
Troubleshooting
В заключение мы хотели бы поделиться с вами решениями некоторых проблем, с которыми столкнулись в процессе развертывания и настройки кластера.
Первая проблема — это распространение сервисных образов. Когда moon инициирует создание браузера, помимо контейнера с браузером у нас запускаются дополнительные сервисные контейнеры — логгер, дефендер, видео-рекордер.
Все это запускается в рамках одного пода. И если образы данных контейнеров не закэшированы на нодах, то они будут доставаться с Docker-хаба. У нас на этом этапе все падало, поскольку использовалась внутренняя сеть. Поэтому ребята из Aerokube оперативно вынесли данную настройку в конфиг мапу. Если вы тоже используете внутреннюю сеть, советуем запулить данные образы в свой registry и указать путь до них в конфиг мапе moon-config. В файле service.json нужно добавить секцию images:
Следующую проблему выявили уже при запуске тестов. Вся инфраструктура динамически создавалась, но тест падал через 30 секунд со следующей ошибкой:
Почему это происходило? Дело в том, что тест посредством RemoteWebDriver первоначально обращается к routing layer OpenShift, который отвечает за взаимодействие с внешней средой. В роли данного слоя у нас выступает Haproxy, который перенаправляет запросы на нужные нам контейнеры. На практике тест обращался к данному слою, его перенаправляли на наш контейнер, который должен был создать браузер. Но он его создать не мог, так как ресурсы заканчивались. Поэтому тест уходил в очередь, а прокси-сервер через 30 секунд ронял его по таймауту, так как по дефолту на нем стоял именно этот интервал времени.
Как это решить? Все оказалось довольно просто – нужно было просто переопределить аннотацию haproxy.router.openshift.io/timeout для роутера нашего контейнера.
Следующий кейс — работа с S3 совместимым хранилищем. Moon умеет записывать то, что происходит в контейнере с браузером. На одной ноде вместе с браузером поднимаются сервисные контейнеры, один из которых — это видеорекордер. Он записывает все, что происходит в контейнере и после окончания сессии отправляет данные в S3 совместимое хранилище. Чтобы отправлять данные в такое хранилище, нужно указать в настройках url, пароли-явки, а также название корзины.
И напоследок.
Каждый контейнер с браузером можно настроить самостоятельно — все доступные параметры есть в документации Moon. Обратим внимание на такие кастомные настройки, как privileged и nodeSelector.
Нужны они вот для чего. Контейнер с Internet Explorer, как упоминалось выше, должен запускаться только в привилегированном режиме. Работу в нужном режиме обеспечивает флаг privileged вместе с выдачей прав на запуск таких контейнеров сервис-аккаунту.
Чтобы запускать на отдельных нодах, нужно прописать nodeSelector:
Последний совет. Следите за количеством запущенных сессий. Мы выводим все запуски в Grafana:
Читайте также: