Какие браузеры поддерживает selenium

Обновлено: 03.07.2024

Компоненты Selenium Suite

Ниже приведены основные компоненты Selenium Test Suite:

Селен интегрированная среда разработки (IDE)
Селен пульт дистанционного управления (RC)
Selenium WebDriver
Selenium Grid

Теперь давайте подробно рассмотрим эти компоненты в этом учебном руководстве по Selenium WebDriver.

Селен интегрированная среда разработки (IDE)

Selenium IDE доступна для различных операционных систем, а именно Windows, Linux, Mac OS и т. Д. Selenium IDE для Firefox можно скачать здесь .

Селен пульт дистанционного управления (RC)

Selenium Server является основным компонентом Selenium RC. Некоторые из основных функций / обязанностей Selenium RC приведены ниже:

Как упоминалось ранее, Selenium RC поддерживает разные браузеры, в отличие от Selenium IDE, которая доступна только для Mozilla Firefox. Недостатком Selenium RC является то, что он не поддерживает функции записи и воспроизведения, которые могут быть жизненно важны для автоматизации тестовых случаев, когда задачи повторяются, особенно для регрессионного тестирования . Перед выполнением тестов с использованием Selenium RC необходимо вручную запустить экземпляр Selenium RC Server, и этот экземпляр должен работать на протяжении всего цикла тестирования .

Selenium WebDriver

Selenium Grid

Вернемся к основам: Selenium Grid в основном используется для параллельного тестирования, поскольку позволяет одновременно выполнять тесты на разных компьютерах с использованием разных браузеров и операционных систем. Это делает работу в сочетании с Selenium RC. Пример, демонстрирующий использование Selenium Grid, приведен ниже:

Selenium WebDriver Architecture

Взгляните на основные блоки, которые составляют архитектуру Selenium WebDriver:

Клиентские библиотеки Selenium
JSON Wire Protocol
Драйверы браузера
Браузеры

Давайте рассмотрим каждый компонент более подробно.

Клиентские библиотеки Selenium

JSON Wire Protocol

Проводной протокол JSON (нотация объектов JavaScript) облегчает передачу данных между клиентом и сервером. Это API, основанный на REST (передача состояния представления). Каждый браузер будет иметь свой собственный драйвер браузера.

Драйверы браузера

Драйвер браузера в основном используется для связи с браузерами. Поскольку внутренняя логика браузера и его функциональные возможности не раскрыты, драйвер браузера обеспечивает необходимый уровень «инкапсуляции», чтобы сохранить детализацию уровня выполнения более абстрактной. Каждый браузер имеет свой соответствующий драйвер браузера.

Браузеры

Поскольку драйверы браузеров доступны для популярных браузеров, таких как Chrome, Firefox, Internet Explorer, Safari и Microsoft Edge, вы можете использовать любой из них для проведения кросс-браузерного тестирования. Следует отметить, что вы не можете выполнять кросс-браузерное тестирование веб-сайта в браузере, драйвер браузера которого не является общедоступным.

LambdaTest теперь работает с сеткой Selenium на облаке

LambdaTest предлагает облачную Selenium Grid, которая поможет вам быстро отслеживать процесс тестирования автоматизации. Selenium Grid предлагает более 2000 реальных браузеров и версий браузеров, работающих в различных операционных системах. Вы можете выполнить параллельное тестирование с помощью LambdaTest Selenium Grid, не беспокоясь об установке какой-либо тяжелой инфраструктуры на локальном компьютере, а также получите широкий выбор браузеров для максимального увеличения охвата тестированием.

Количество параллельных сеансов, которые вы можете запустить, полностью зависит от выбранных вами одновременных сеансов. Параллельное тестирование может помочь вам значительно сократить ваши циклы тестирования. Например, скажем, у вас есть набор тестов, который занимает 60 минут без параллельного тестирования. Теперь, если у вас есть 2 параллелизма, вы можете запустить 2 теста одновременно, сократив общее время теста до 30 минут. Точно так же, если у вас есть 3 параллельных режима, общее время тестирования сокращается до 20 минут. Используйте калькулятор параллелизма LambdaTest, чтобы вычислить, сколько параллельных сеансов вам может понадобиться в соответствии с вашим набором тестов.

Selenium WebDriver в действии

Пример Firefox WebDriver

Поскольку тестовый код будет связываться с браузером (Chrome, Firefox, Internet Explorer и т. Д.), Убедитесь, что на вашем компьютере установлена соответствующая клиентская библиотека / WebDriver. Пожалуйста, обратитесь к разделу Драйверы браузера, чтобы узнать, как загрузить соответствующий WebDriver.

Ниже приведен пример кода, который использует Selenium, Firefox WebDriver для открытия веб-страницы:

Давайте пройдемся по коду. Перед выполнением какого-либо действия все необходимые модули импортируются с помощью оператора import [Строки 2

4]. В тестовом коде мы используем Firefox WebDriver, поскольку тестирование выполняется в браузере Firefox [Строка 7]. В коде ff_driver Если у вас не установлен WebDriver или вы пытаетесь использовать браузер, для которого нет поддержки (через WebDriver), вы получите следующую ошибку:

Когда все операции в браузере завершены, ff_driver.close()

Чтобы выполнить код, вы можете вызвать Ctrl + F9 в Eclipse IDE или скомпилировать код, используя параметры командной строки Python:

Пример Chrome WebDriver

Пример Internet Explorer WebDriver

До сих пор в нашем учебном руководстве по Selenium WebDriver мы демонстрировали кросс-браузерное тестирование с использованием Firefox WebDriver и Chrome WebDriver. В этом разделе мы рассмотрим изменения, которые необходимы, если вы используете браузер Chrome для тестирования. Вы должны скачать правильный Internet Explorer WebDriver (32 бит / 64 бит) здесь или здесь . Вставьте InternetExplorerDriver.exe в место, где вы установили Python (в нашем случае это был путь установки по умолчанию, например, C: \ Python27 \ Scripts) или в любое другое место по вашему выбору. Если вы копируете InternetExplorer WebDriver в путь, где присутствует исполняемый файл Python, вам не нужно указывать «абсолютный путь» при загрузке веб-драйвера [Строка 7]. В другом случае вы должны указать абсолютный путь [Строка 9]. Ниже приведен фрагмент кода с изменением (требуется для IE WebDriver), выделенным другим цветом:

Наконец, в нашем руководстве по Selenium WebDriver мы рассмотрим другой пример, в котором мы используем модуль ActionChains, который используется для автоматизации низкоуровневых взаимодействий, таких как движения мыши, движения кнопок, взаимодействия с контекстным меню и т. Д., Для обеспечения надежного дизайна пользовательского интерфейса . Более подробную информацию о ActionChains можно найти здесь .

Как видно из приведенного выше примера кода, мы сохраняем код для создания экземпляра Firefox WebDriver [Строки 9

Как только критерий поиска встречается, выполняется операция (CTRL + CLICK), что открывает эту страницу в «новой вкладке» [Строки 26–30]. Модуль ActionChains используется для выполнения этой операции. Выход ниже:

Тестирование с использованием локального WebDriver можно использовать в том случае, если вы планируете тестировать свой веб-сайт на ограниченном количестве комбинаций «браузер + операционная система + устройства». Тем не менее, подход может дать сбой, если количество комбинаций больше. Вы не можете иметь локальную настройку для каждой комбинации, так как это не масштабируемый подход, а также может оказаться очень дорогостоящим.

Лучшим решением было бы использовать возможности платформы, такой как LambdaTest, где вы можете выполнять кросс-браузерное тестирование в облаке. Используя LambdaTest, вы можете проверить свой веб-сайт в более чем 2000 браузерах, операционных системах и конфигурациях устройств. Для начала вам необходимо создать учетную запись на LambdaTest. Поскольку вы будете использовать Remote WebDriver (используя Selenium Grid в LambdaTest) для тестирования вашего веб-приложения, вы должны записать имя пользователя и ключ доступа в своем профиле LambdaTest .

Запуск Selenium Script с использованием удаленного WebDriver с LambdaTest

Теперь, когда вы знаете об использовании Selenium WebDriver и потенциальных недостатках использования этого подхода, мы рассмотрим, как вы можете перенести локальную реализацию WebDriver на Remote WebDriver. Основные принципы Remote WebDriver аналогичны Local WebDriver, за исключением того, что код Remote WebDriver может не выполняться на том же компьютере, откуда он был инициирован. Remote WebDriver основан на модели клиент-сервер, где сервер представляет собой простой Java-сервлет, размещенный на любом современном сервере приложений JEE. Концентратор / Сервер загружает тесты, которые должны быть выполнены. Он получает тестовые запросы от разных клиентов и, основываясь на требованиях (называемых желаемыми возможностями), направляет запрос к клиенту с наилучшим соответствием / наиболее подходящим вариантом.

После входа в LambdaTest вы должны сгенерировать возможности, требуемые узлами, посетив LambdaTest Capabilities Generator . Выберите предпочитаемый язык программирования (в нашем случае это Python) и соответствующую комбинацию ОС / браузера. Вы можете включить функции «Снимок экрана» и «Запись видео» при настройке возможностей. Как показано ниже, наше требование заключается в том, что тест должен выполняться на Firefox (версия 64.0), который установлен на компьютере с Windows 10. Возможности для требования ниже:

Ниже приведен скриншот из генератора возможностей LambdaTest:

Поскольку мы будем использовать Selenium Grid на сервере LambdaTest, нам нужно изменить наш код для доступа к их облачной инфраструктуре (также называемой удаленным URL). Удаленный URL-адрес показан ниже:

Давайте рассмотрим код, особенно основные изменения:

Чтобы проверить состояние теста, вам необходимо посетить панель управления LambdaTest . Вы можете искать тест по его имени сборки, которое используется при формировании возможностей. Снимок экрана вышеупомянутого теста, выполняемого в сетке LambdaTest, приведен ниже.

На панели «Вывод» имеются различные параметры, которые могут быть полезны при отладке. Некоторые из основных вариантов приведены ниже.

Одной из функций LambdaTest, которая может ускорить весь процесс тестирования, является параллельное тестирование. В зависимости от выбранной вами модели ценообразования вы можете одновременно выполнять тесты, чтобы сократить общее время выполнения тестов. В нашем случае у нас может быть два одновременных сеанса. Чем больше одновременных сеансов, тем короче общее время выполнения теста.

Чтобы продемонстрировать возможность распараллеливания, мы выполняем два теста одновременно. Наряду с предыдущим примером (parallel_test_example-1.py), мы выполняем второй тест (parallel_test_example-2.py) одновременно с ним.

Выполните два теста параллельно на двух разных терминалах, вызвав команду python.

Ниже приведен скриншот из журналов автоматизации LambdaTest, на котором видно, что параллельно выполняются два теста.

Вывод

Использование API Remote WebDriver в облачной инфраструктуре, такой как LambdaTest, дает ряд преимуществ, поскольку ускоряет весь процесс тестирования. Это также очень масштабируемый подход. Используя параллелизм, то есть распараллеливание, вы можете еще больше сократить общее время, затрачиваемое на автоматизированное тестирование.

Время от времени мне приходится распутывать терминологические хитросплетения, связанные с употреблением словосочетаний, в которых встречается слово Selenium – Selenium 2.0, Selenium IDE, Selenium RC, Selenium WebDriver, Selenium Server, Selenium Grid.

Путаница возникает во многом из-за того, что нигде нет чёткого описания всех этих терминов на одной страничке, и я постараюсь восполнить этот информационный пробел.

Selenium

Selenium WebDriver,
Selenium RC,
Selenium Server,
Selenium Grid,
Selenium IDE.

Selenium WebDriver

Selenium WebDriver – это программная библиотека для управления браузерами. Часто употребляется также более короткое название WebDriver.

Иногда говорят, что это «драйвер браузера», но на самом деле это целое семейство драйверов для различных браузеров, а также набор клиентских библиотек на разных языках, позволяющих работать с этими драйверами.

Это основной продукт, разрабатываемый в рамках проекта Selenium.

Selenium WebDriver называется также Selenium 2.0, причина этого будет объяснена ниже.

Как уже было сказано, WebDriver представляет собой семейство драйверов для различных браузеров плюс набор клиентских библиотек для этих драйверов на разных языках программирования:

В рамках проекта Selenium разрабатываются драйверы для браузеров Firefox, Internet Explorer и Safari, а также драйверы для мобильных браузеров Android и iOS. Драйвер для браузера Google Chrome разрабатывается в рамках проекта Chromium, а драйвер для браузера Opera (включая мобильные версии) разрабатывается компанией Opera Software. Поэтому они формально не являются частью проекта Selenium, распространяются и поддерживаются независимо. Но логически, конечно, можно считать их частью семейства продуктов Selenium.

Selenium RC

Selenium RC – это предыдущая версия библиотеки для управления браузерами. Аббревиатура RC в названии этого продукта расшифровывается как Remote Control, то есть это средство для «удалённого» управления браузером.

Эта версия с функциональной точки зрения значительно уступает WebDriver. Сейчас она находится в законсервированном состоянии, не развивается и даже известные баги не исправляются. А всем, кто сталкивается с ограничениями Selenium RC, предлагается переходить на использование WebDriver.

Иногда Selenium RC называется также Selenium 1.0, тогда как WebDriver называется Selenium 2.0. Хотя на самом деле дистрибутив версии 2.0 включает в себя одновременно обе реализации – и Selenium RC, и WebDriver. А вот когда выйдет версия 3.0 – в ней останется только WebDriver.

С технической точки зрения WebDriver не является результатом эволюционного развития Selenium RC, они построены на совершенно разных принципах и у них практически нет общего кода. Объединяет их лишь тот факт, что обе реализации были сделаны в рамках проекта Selenium. Ну, или если быть совсем точным, WebDriver сначала был самостоятельным проектом, но в 2008 году произошло слияние и сейчас WebDriver представляет собой основной вектор развития проекта Selenium.

Selenium Server

Selenium Server – это сервер, который позволяет управлять браузером с удалённой машины, по сети. Сначала на той машине, где должен работать браузер, устанавливается и запускается сервер. Затем на другой машине (технически можно и на той же самой, конечно) запускается программа, которая, используя специальный драйвер RemoteWebDriver, соединяется с сервером и отправляет ему команды. Он в свою очередь запускает браузер и выполняет в нём эти команды, используя драйвер, соответствующий этому браузеру:

Selenium Server поддерживает одновременно два набора команд – для новой версии (WebDriver) и для старой версии (Selenium RC).

Selenium Grid

Selenium Grid – это кластер, состоящий из нескольких Selenium-серверов. Он предназначен для организации распределённой сети, позволяющей параллельно запускать много браузеров на большом количестве машин.

Selenium Grid имеет топологию «звезда», то есть в его составе имеется выделенный сервер, который носит название «хаб» или «коммутатор», а остальные сервера называются «ноды» или «узлы». Сеть может быть гетерогенной, то есть коммутатор и узлы могут работать под управлением разных операционных систем, на них могут быть установлены разные браузеры. Одна из задач Selenium Grid заключается в том, чтобы «подбирать» подходящий узел, когда во время старта браузера указываются требования к нему – тип браузера, версия, операционная система, архитектура процессора и ряд других атрибутов.

Ранее Selenium Grid был самостоятельным продуктом. Сейчас физически продукт один – Selenium Server, но у него есть несколько режимов запуска: он может работать как самостоятельный сервер, как коммутатор кластера, либо как узел кластера, это определяется параметрами запуска.

Selenium IDE

Selenium IDE – плагин к браузеру Firefox, который может записывать действия пользователя, воспроизводить их, а также генерировать код для WebDriver или Selenium RC, в котором выполняются те же самые действия. В общем, это «Selenium-рекордер».

Тестировщики, которые не умеют (или не хотят) программировать, используют Selenium IDE как самостоятельный продукт, без преобразования записанных сценариев в программный код. Это, конечно, не позволяет разрабатывать достаточно сложные тестовые наборы, но некоторым хватает и простых линейных сценариев.

Вот, кажется, и всё.

Если я забыл рассказать про какой-то термин – напишите в комментариях, и я постараюсь добавить его в этот мини-словарик.

В первой части статьи я рассказал о простых подходах, позволяющих построить масштабируемый кластер Selenium без написания кода. В этой части мы рассмотрим более тонкие вопросы работы с Selenium:

Как создать легко масштабируемые рабочие ноды, используя стандартный Selenium Hub
Почему можно и нужно запускать большинство браузеров в контейнерах и как это делается
Какие open-source инструменты для этого существуют

Что внутри рабочей ноды

Все новые инструменты, описанные в первой части, на самом деле являются умными легковесными прокси, которые перенаправляют запросы пользователей в настоящие Selenium хабы и ноды. Если немного поразмышлять, то появляются вопросы:

Как организовать хабы и ноды, чтобы эффективно потреблять аппаратные ресурсы и хорошо масштабироваться?
Какую операционную систему использовать?
Какие программы должны быть установлены?
Можно ли работать без монитора?

Одним из способов может быть использование "железа" с одним Selenium хабом и множеством нод с различными браузерами. Выглядит разумно, но на самом деле неудобно:

Как было сказано Selenium хаб с большим числом нагруженных нод работает очень медленно. Не уверен насчет настоящих причин, но практика показывает именно это. Мой совет — не читайте исходники Selenium на ночь, если не хотите, чтобы вам снились кошмары. Таким образом мы не можем использовать десятки Selenium нод с одним и тем же хабом. Остается использовать один хаб и лишь несколько нод. Чтобы эффективно использовать железо нужно уменьшить общее число ядер на хаб — хорошая причина переехать в облака. Например, наш работающий грид длительное время использовал маленькие виртуальные машины с 2 ядрами и 4 Гб памяти.
Непонятно как установить разные версии одного браузера простым способом (например, из пакетов).
Непонятно как легко учитывать общее количество доступных браузеров одной версии.
Разные версии Selenium-ноды совместимы с разными версиями браузеров, т.е. более новая Selenium нода может не поддерживать более старый браузер.

Наиболее простой способ иметь одинаковое количество нод на один хаб — это запускать их внутри одной виртуальной машины. Если каждая версия браузера — это отдельная виртуальная машины, то подсчет общего числа доступных браузеров становится задачей из начальной школы. Можно легко добавлять и удалять виртуальные машины, содержащие совместимые версии ноды и браузера. Мы рекомендуем такой подход при установке кластера Selenium в облако с постоянно доступным количеством каждой версии браузера.

Что же еще кроме Selenium хаба и ноды находится внутри виртуальной машины, чтобы все работало?

Во-первых, мы рекомендуем использовать Linux в качестве основном операционной системы везде, где возможно. Используя Linux вы можете покрыть 80% потребности в браузерах. Легче перечислить то, что не покрыто:
1. Internet Explorer и Microsoft Edge. Эти браузеры работают только под Windows и заслуживают отдельной статьи. Нет повести печальнее на свете.
2. Desktop Safari. Кто-нибудь им вообще пользуется? Selenium довольно плохо поддерживает этот браузер.
3. iOS и мобильные телефоны Apple. Для работы с этими устройствами нужно использовать железо от Apple, например, MacMini и Appium.
Для запуска Selenium нужно установить Java (JDK или JRE), а также скачать нужную версию Selenium в виде JAR-архива.

Виртуальные машины не имеют монитора, поэтому Selenium должен быть запущен в особой версии X-сервера, которая эмулирует дисплей. Эта реализация называется Xvfb. Запускается это так:

Обратите внимание, что Xvfb нужно только для процесса Selenium-ноды.

Худеем

Как вы уже могли заметить, Selenium — это Java-приложение. Для запуска Selenium нужно установить Java Virtual Machine (JVM). Самый маленький установочный пакет Java, называемый JRE, имеет размер около 50 мегабайт. Selenium JAR самой последней версии 3.0.1 добавляет еще 20 мегабайт. Теперь добавим размер операционной системы, нужные шрифты, размер самого браузера и вы легко достигаете нескольких сотен мегабайт. И хотя жесткие диски сейчас стоят дешево, мы можем сделать лучше. Selenium версий 2.0 и 3.0 также называют Selenium Webdriver. Это связано с тем, что поддержка разных браузеров реализована при помощи отдельных приложений, называемых веб-драйверами.

Разработчики браузера могут писать свой продукт, как им хочется. Чтобы браузер поддерживался в Selenium им нужно предоставить приложение веб-сервер, предоставляющее то же API, что и сам Selenium Server и поддерживающий протокол JSONWire. Это приложение должно уметь запускать процесс браузера, выполнять команды Selenium согласно спецификации и останавливать браузер по запросу. Любые детали взаимодействия драйвера с браузером могут быть реализованы по-усмотрению разработчиков. Единственное требование — поддержка одинакового Selenium API. Например, Chrome имеет Chromedriver, Opera Blink предоставляет OperaDriver и так далее.
При установке Selenium требуется указать только путь до приложения-драйвера.
Когда вы запрашиваете браузер у Selenium, он, на самом деле, запускает процесс драйвера и проксирует все запросы в драйвер. Драйвер выполняет всю остальную работу. Такой же результат вы можете получить, если вручную запустите процесс драйвера на требуемом порту и нацелите свои тесты на него.

Теперь, когда мы выяснили это, встает вопрос: не слишком ли дорого тратить сотни мегабайт для простого проксирования? Год назад ответ был определенно нет, потому что не существовало приложения-драйвера для Firefox — наиболее часто используемый браузер в Selenium. Ответственностью Selenium было запустить Firefox, загрузить в него специальное расширение и проксировать запросы в порт, открытый этим расширением. За последний год ситуация изменилась. Начиная с Firefox 48.0 Selenium взаимодействует с браузером, используя отдельный бинарный драйвер — Geckodriver. Это означает, что теперь для большинства настольных браузеров мы можем совсем удалить Selenium Server и проксировать запросы напрямую в драйверы.

Переезжаем в контейнеры

В предыдущих разделах я описал как можно построить кластер Selenium, используя виртуальные машины в облаке. В этом подходе виртуальные машины всегда запущены и постоянно тратят ваши деньги. Кроме того общее число доступных браузеров для каждой версии ограничено и может приводить к полному исчерпанию доступных браузеров во время пиковых нагрузок. Я слышал о работающих и даже запатентованных сложных решениях, которые запускают и прогревают пул виртуальных машин в зависимости от текущей нагрузки, чтобы всегда иметь доступные браузеры. Это работает, но можно ли сделать лучше? Основная проблема гипервизорной виртуализации — это скорость. Запуск новой виртуальной машины может занимать неколько минут. Но давайте немного подумаем — нужна ли нам отдельная операционная система для каждого браузера? — Нет, нужна только простая изоляция по диску и сети. Вот почему контейнерная виртуализация становится актуальной. На данный момент контейнеры работают в основном только под Linux, но, как я уже говорил, Linux покрывает 80% наиболее популярных браузеров. Контейнеры с браузерами стартуют за секунды и останавливаются еще быстрее.

Что же должно быть внутри контейнера? — Практически то же самое, что и внутри виртуальной машины: сам браузер, шрифты, Xvfb. Для старых версий Firefox (< 48.0) по-прежнему нужно установить Java и Selenium Server, но для Chrome, Opera и свежих версий Firefox мы можем использовать приложение-драйвер в качестве основного процесса контейнера. Если использовать легковесный Linux дистрибутив (например, Alpine), можно получить очень маленькие и легковесные контейнеры.

Selenoid

На данный момент наиболее популярной и известной контейнерной платформой является Docker. Разработчики Selenium предоставляют набор готовых Docker контейнеров для запуска Selenium в режиме Standalone или Grid в Docker. Для того, чтобы запустить кластер из таких образов, нужно запускать и останавливать контейнеры вручную или при помощи инструментов наподобие Docker Compose. Такой подход уже намного лучше, чем установка Selenium из пакетов, но было бы еще лучше, если бы существовал сервер со следующим поведением:

Администратор стартует демон сервера вместо обычного Selenium хаба.
Демон "знает" (из конфигурации), что, например, для запуска Firefox 48.0 нужно скачать и запустить контейнер Х, а для Chrome 53 — контейнер Y.
Пользователь запрашивает Selenium сессию обычным способом, но у этого нового демона.
Демон анализирует капабилити (desired capabilities), стартует нужный контейнер и затем проксирует запросы в основной процесс контейнера (Selenium server или веб-драйвер).

Мы сделали такой демон… и даже больше.

За годы использования Selenium server в больших масштабах мы поняли, что очень неэффективно использовать JVM и "толстый" Selenium JAR для простого проксирования запросов. Поэтому мы искали более легковесную технологию. Наш выбор остановился на языке программирования Go также известном как Golang. Почему для наших целей Go подходит лучше?

Мы так и не придумали хорошего имени для описанного выше демона. Поэтому мы назвали его просто Selenoid. Чтобы попробовать Selenoid нужно выполнить 3 простых шага:

Создать JSON-файл, содержащий информацию о том какой контейнер нужно запустить для каждой версии браузера:

Как и в XML файле для Gridrouter указан список доступных версий браузеров. Поскольку Selenoid запускает контейнеры на той же машине или через Docker API, нет необходимости указывать имена хостов и регионы. Для каждой версии браузера нужно указать имя контейнера, его версию и порт, на котором слушает основной процесс контейнера.

По-умолчанию Selenoid стартует на порту 4444, как обычный Selenium хаб.

Запустить свои тесты на хост Selenoid, как будто это обычный Selenium хаб.

Наши эксперименты показывают, что даже контейнеры со стандартным Selenium сервером внутри стартуют за несколько секунд. Взамен вы получаете гарантированное состояние диска и памяти. Браузер всегда находится в состоянии как после установки на чистую операционную систему. Кроме того вы можете установить Selenoid на большой кластер из хостов имеющих одинаковый набор поддерживаемых браузеров, сохраненных в виде Docker образов. Это дает вам большой кластер Selenium, который автоматически масштабируется в зависимости от потребления браузеров. Например, если текущие запросы пользователей требуют больше Chrome — автоматически запускается больше контейнеров. Когда запросов на Chrome не поступает — контейнеры с Chrome останавливаются и освободившиеся хосты могут использоваться для других браузеров.

Чтобы обеспечить лучшее распределение нагрузки по кластеру, Selenoid ограничивает общее число параллельных сессий на хосте и ставит в очередь все превышающие лимит запросы. Запросы из очереди обрабатываются по мере того, как завершаются более ранние сессии на том же хосте.

Но Selenoid позволяет запускать не только контейнеры. Он также умеет запускать по требованию процессы веб-драйвера. Основное применение этой функциональности — замена Selenium Server на Windows. В этом случае Selenoid стартует процесс IEDriverServer, что позволяет экономить память и избегать ошибок проксирования в самом Selenium.

Go Grid Router (также известный как ggr)

Возможно, вы помните, что оригинальный GridRouter — это Java приложение. Мы написали с нуля легковесную реализацию этого прокси на Go и назвали просто Go Grid Router (или ggr). В чем преимущества новой версии по сравнению со старой?

Увеличенная производительность. Может обслуживать минимум на 25% больше запросов.
Меньшее потребление памяти. При нагрузке в 150 rps потребляет всего 100-200 мегабайт памяти и это число не меняется.
Отслеживается отсоединение клиента. Если клиент отсоединяется (например, из-за таймаута) Java-версия GridRouter продолжает перебирать хосты, пытаясь создать сессию. Это забивает сеть ненужными пакетами и уменьшает производительность GridRouter, когда много хабов становятся недоступны. Новая реализация на Go перестает пытаться получить браузер как только клиент отключается.
Перезагрузка сервера без потери соединений (graceful restart). Если сервер используется вне Docker контейнера, то можно перезагрузить его без потери соединений, послав процессу сигнал SIGUSR2.
Перезагрузка квот по запросу. Когда используется несколько инстансов GridRouter за балансером важно обновлять квоты одновременно. Когда в XML файлы квот добавляются новые хосты и квоты обновляются не одновременно на работающем кластере Selenium может произойти ситуация, когда одна "голова" GridRouter уже знает про новые хосты и перенаправляет туда запросы, а другая еще не знает об этих хостах и возвращает ошибку 404. Реализация на Go перезагружает квоты по сигналу SIGHUP, а не автоматически, как это происходит в Java версии. Эта функциональность работает как в Docker, так и без него.
Зашифрованные пароли. Ggr использует текстовые файлы формата Apache htpasswd для хранения логинов и паролей. Логины хранятся в открытом виде, а пароли зашифрованы.
Маленький размер исполняемого файла. Всего 6 мегабайт. Не требует установки Java. Если устанавливать в Docker, то контейнер на основе Alpine Linux занимает всего 11 мегабайт.

В связке с Selenoid, позволяет создавать масштабируемый, надежный кластер Selenium:

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

Почему Selenium хорошо упаковывается и запускается в контейнерах
Что должно быть внутри контейнера
Какие open-source инструменты для работы Selenium в контейнерах существуют

В заключение в одном месте собраны ссылки на упомянутые в статье продукты:

Что пишут в блогах

Автоматизация рутины. Скачиваем файлы через bash
Панбагон. 12 часов — опасное время
Оффер сразу после курса для тестировщиков с нуля. Что бывает, если выйти из зоны комфорта
Мои 12 недель в году. Часть 17 (переезд, ДР и пневмония)
Как тестировщику с небольшим опытом подготовиться и сдать экзамен ISTQB FL: интервью
Метрики в тестировании: какие выбрать и что делать, когда они становятся KPI?
Александр Александров про тренды и технологии тестирования, про влияние Covid19 на рынок QA
Зачем тестировщикам HTML и CSS и что о них нужно знать
Войти в айти после 30: с мороза на теплую и уютную «удаленку»
Ручное тестирование: что нужно знать, чтобы стать мануальным тестировщиком

Онлайн-тренинги

Что пишут в блогах (EN)

Agile Testing Days 2021 - My Heart Is Full
Balancing the Speaker Circuit
Agile Testing Days 2021 – Part 1
Automate for yourself first
I’m now a Developer Advocate!
Keeping the Customer Satisfied
Lessons Learned in Finding Bugs
Workshop on Built-in Quality at the Agile Testing Days
Increasing Understanding of Modern (Exploratory) Testing
The George Foreman Heuristic for Quality

Разделы портала

Про инструменты

Автор: Алексей Баранцев

Эта статья является продолжением более общей статьи "Что такое Selenium?", в которой объясняется, какое положение занимает Selenium WebDriver среди других инструментов семейства Selenium.

Здесь я постараюсь рассказать более подробно о том, что такое Selenium WebDriver, и почему его бессмысленно сравнивать с TestComplete, QuickTest Pro и другими инструментами автоматизации тестирования. И дело не только в том, что Selenium WebDriver бесплатный и открытый – его столь же бессмысленно сравнивать с другими бесплатными инструментами, такими как Sahi или Robot Framework.

Потому что Selenium WebDriver – это не инструмент для автоматизации тестирования.

А что же это такое?

Кроме того, я объясню, почему Selenium WebDriver имеет такой убогий и неудобный в использовании интерфейс (набор команд), почему он не генерирует красивые отчёты и почему несмотря на всё это он настолько популярен :)

На всякий случай оговорюсь, что хотя в этой статье речь идёт про WebDriver, многие аргументы справедливы и в отношении Selenium RC, но я не буду ничего говорить специально про эту устаревшую версию, потому что её место – на свалке истории.

Итак, что такое Selenium WebDriver?

По назначению Selenium WebDriver представляет собой драйвер браузера, то есть программную библиотеку, которая позволяет разрабатывать программы, управляющие поведением браузера.

По своей сущности Selenium WebDriver представляет собой:

спецификацию программного интерфейса для управления браузером,
референсные реализации этого интерфейса для нескольких браузеров,
набор клиентских библиотек для этого интерфейса на нескольких языках программирования.

Теперь понятно, почему бессмысленно сравнивать Selenium WebDriver с "другими инструментами тестирования"? Непонятно? Тогда добавим подробностей.

Selenium WebDriver – это драйвер браузера

Наверняка каждый, кто сталкивался с компьютерами, даже не айтишник, знает слово "драйвер". Это такая маленькая программа, точнее программная библиотека, которая позволяет другим программам взаимодействовать с некоторым устройством. Драйвер принтера позволяет печатать что-нибудь на принтере. Драйвер диска позволяет читать и писать данные. Драйвер сетевой карты позволяет обмениваться данными с другими компьютерами по сети.

С драйвером пользователи не работают непосредственно. Они работают с прикладными программами, которые, посредством драйверов, взаимодействуют с теми или иными устройствами. Драйвер не имеет пользовательского интерфейса. Постойте, но ведь иногда бывает пользовательский интерфейс для настройки драйвера? Бывает. Но это интерфейс программы для настройки драйвера, а не самого драйвера. Драйвер имеет только программный интерфейс, его назначение состоит в том, чтобы дать возможность прикладным пользовательским программам взаимодействовать с устройством.

Так вот, Selenium WebDriver, или просто WebDriver – это драйвер браузера, то есть не имеющая пользовательского интерфейса программная библиотека, которая позволяет различным другим программам взаимодействовать с браузером, управлять его поведением, получать от браузера какие-то данные и заставлять браузер выполнять какие-то команды.

Исходя из этого определения, ясно, что WebDriver не имеет прямого отношения к тестированию. Он всего лишь предоставляет автотестам доступ к браузеру. На этом его функции заканчиваются.

Впрочем, в рамках проекта Selenium разрабатывается не только драйвер, но ещё несколько сопутствующих продуктов – Selenium Server позволяет организовать удалённый запуск браузера, при помощи Selenium Grid можно построить кластер из Selenium-серверов. Они встают в один ряд с вышеперечисленными инструментами и фреймворками, потому что также участвуют в построении системы запуска тестов. Кроме того, имеется "рекордер", который называется Selenium IDE, он умеет записывать действия пользователя и генерировать код, в котором используется интерфейс WebDriver для выполнения записанных действий.

Но главным в проекте Selenium является именно WebDriver, это ключевой элемент экосистемы Selenium.

Существуют ли другие драйверы? Разумеется.

Внутри каждого коммерческого "интегрированного" инструмента имеются драйверы браузеров, но они как правило не могут быть использованы отдельно вне этого инструмента. Есть и бесплатные открытые драйверы – Watir предоставляет доступ к основным браузерам, WatiN имеет неплохой драйвер для браузера Internet Explorer, Sahi умеет работать с "большой пятёркой" браузеров.

Как сравнить Selenium WebDriver с другими инструментами?

Из всего вышенаписанного можно сделать вывод, что сравнивать WebDriver с каким-нибудь инструментом тестирования типа TestComplete или Sahi бессмысленно. Они находятся в разных весовых категориях. Это всё равно, что сравнивать драйвер принтера с текстовым редактором.

А что можно сравнивать?

Можно сравнивать WebDriver с драйверами, которые включены в состав различных инструментов. Например, можно сравнить:

И вот тут WebDriver оказывается бесспорным лидером.

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

Что касается сравнения с "комплексным" инструментами типа TestComplete или Sahi, для этого нужно брать не WebDriver, а полный стек.

Например, стек для технологии Java может быть таким: Jenkins + Maven + Thucydices + JUnit+ WebDriver. К этому добавляются ещё все возможности языка программирования Java, плюс масса плагинов для Maven и Jenkins, а чтобы совсем всё было круто – можно запускать тесты в облаках, используя какой-нибудь сервис типа SauceLabs.

Вот тогда сравнение будет интересным. Но это уже заслуга не только WebDriver, важен весь стек, а не только драйвер браузера. Что касается WebDriver, стоит отметить лишь то, что он прекрасно встраивается практически в любой стек, это одно из его достоинств как "независимого" драйвера.

Разумеется, WebDriver может использоваться не только при тестировании. Ему вообще безразлично, кто и зачем хочет управлять браузером. Вы можете автоматизировать какие-то рутинные задачи. Можете сделать ботов, которые будут флудить в форумах. Можете сделать скрипт, который автоматически снимает скриншоты для документации. Всё что угодно. Драйверу всё равно. Он всего лишь предоставляет доступ к браузеру.

Ну да, я уже несколько раз повторил, что "он лучший", но при этом не привёл сравнения с другими драйверами. И не буду. Потому что есть аргумент, который в перспективе важнее любых сравнений.

Selenium WebDriver – это спецификация интерфейса для управления браузером

Самое главное отличие WebDriver от всех остальных драйверов заключается в том, что это "стандартный" драйвер, а все остальные – "нестандартные".

И это не простая фигура речи.

Организация W3C действительно приняла WebDriver за основу при разработке стандарта интерфейса для управления браузером. Сейчас он находится в состоянии публичного рассмотрения.

Через год-полтора этот стандарт будет утверждён. И тогда реализация интерфейса WebDriver будет возложена на производителей браузеров, а WebDriver как независимый драйвер, возможно, в будущем исчезнет совсем, потому что он будет встроен непосредственно в браузеры.

Таким образом, можно сказать, что Selenium WebDriver это вообще не инструмент, а спецификация, документ, стандарт, описывающий, какой интерфейс браузеры должны предоставлять наружу, чтобы через этот интерфейс можно было браузером управлять.

Пока стандарт обсуждается, производители браузеров уже действуют. В рамках проекта Selenium было разработано несколько референсных реализаций для различных браузеров, но постепенно эта деятельность переходит в ведение производителей браузеров. Драйвер для браузера Chrome разрабатывается в рамках проекта Chromium, его делает та же команда, которая занимается разработкой самого браузера. Драйвер для браузера Opera разрабатывается в компании Opera Software. Драйвер для браузера Firefox пока разрабатывается участниками проекта Selenium, но в недрах компании Mozilla уже готовится ему замена, которая носит кодовое название Marionette. Этот новый драйвер для Firefox уже доступен в девелоперских сборках браузера. На очереди Internet Explorer и Safari, к их разработке сотрудники соответствующих компаний пока не подключились, но кое-какие сдвиги в этом направлении есть, потому что стандарт (даже будущий) обязывает.

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

А что случится после того, как во всех браузерах будет реализован этот стандарт?

Было бы логично ожидать, что производители инструментов тестирования не станут изобретать велосипеды, а будут управлять браузером через стандартный интерфейс. Можно сказать, что все инструменты станут использовать WebDriver для взаимодействия с браузером. Но это будет уже не Selenium WebDriver как независимый драйвер, а Selenium WebDriver как спецификация интерфейса.

Так почему же у него такой примитивный интерфейс?

Именно потому, что WebDriver – это:

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

При разработке Selenium WebDriver изначально была поставлена цель – не включать в него ничего лишнего. Стандартный интерфейс управления браузером должен быть простым и стабильным.

Набор команд последовательно сокращался, были выброшены такие «повышающие удобство использования» команды как check, uncheck (для чекбоксов), select (для выпадающих списков). Все они сводятся к более простой команде click и поэтому они лишние. Сейчас в интерфейсе WebDriver осталась только одна избыточная команда – это submit, но может быть когда-нибудь и она будет устранена.

Кроме того, структура интерфейса проектировалась таким образом, чтобы можно было описать его на языке IDL (именно это сделано в стандарте W3C) и сделать реализации на различных языках программирования. Поэтому использовался минимум языковых идиом, минимум «скрытых» переменных, интерфейс «тупой и прямолинейный».

И благодаря той же самой простоте WebDriver прекрасно интегрируется с любыми другими инструментами, встраивается в любой стек. В этом секрет его популярности и быстрого распространения – он не пытается «победить» другие инструменты, вместо этого он интегрируется с ними.

А как же удобство использования?

Эту задачу должны решать расширения, построенные на базе Selenium WebDriver. Именно они должны предоставлять расширенный набор команд, реализуя эти команды через примитивный интерфейс WebDriver. В дистрибутиве Selenium имеется класс Select, предназначенный для работы с выпадающими списками, который является наглядной демонстрацией того, как должны строиться расширения.

Постепенно появляются библиотеки, которые строятся на базе Selenium WebDriver и предоставляют более высокий уровень абстракции: Selenide, fluent-selenium, watir-webdriver, Thucidides. Популярные фреймворки для проектирования тестов позволяют наряду с другими драйверами использовать WebDriver. Среди таких фреймворков можно упомянуть Robot Framework, Capybara и тот же Thucidides.

Рано или поздно должны появиться вспомогательные библиотеки, облегчающие работу с теми или иными наборами виджетов – jQuery, Prototype, ExtJS, GWT и прочими.

Число таких расширений и инструментов будет расти, сложность тоже. Так что вскоре может так случиться, что вы, используя какой-то инструмент, будете выполнять тесты, даже не подозревая о том, что взаимодействие с браузером осуществляется через драйвер Selenium WebDriver.

Стоит ли тогда вообще изучать Selenium?

Может быть лучше изучать эти библиотеки и инструменты более высокого уровня?

Чтобы ответить на этот вопрос, я сформулирую его иначе: кому и зачем стоит изучать Selenium, а кому лучше изучать более высокоуровневые библиотеки и инструменты?

Какой бы инструмент вы ни использовали, вам нужно выбрать драйвер, управляющий браузером. Чтобы его выбрать, вы должны знать возможности драйвера – что он может, а чего не может. На этом уровне Selenium необходимо освоить каждому специалисту по автоматизации. При этом конкретно интерфейс WebDriver, если вы с ним работаете, изучать нет необходимости.
Простой набор команд выучить проще, чем «расширенный», то есть Selenium освоить проще, чем его расширение. У этого явления есть и обратная сторона – если вы изучили расширенный набор команд, то внезапно оказывается, что набор команд WebDriver вы при этом тоже освоили.
Расширения, как правило, языково-зависимые, потому что добавление удобства предполагает использование языковых идиом, типичных приёмов организации кода на том или ином языке программирования. Базовый интерфейс WebDriver простой, поэтому освоив его, вы сможете использовать его на любом языке, он будет выглядеть практически одинаково.
Большинство библиотек, нацеленных на повышение удобства интерфейса, улучшают средства поиска элементов – дополнительные типы локаторов, более удобный способ описания локаторов и так далее. Примитивы, соответствующие действиям пользователя, в WebDriver уже и так достаточно хороши. Хотя, конечно, библиотеки будут реализовывать типовые «связки», то есть последовательности этих действий, аналогично тому, как это сделано в классе Select для выпадающих списков.
Если вы используете «таблички» для описания тестов (как в Robot Framework) или специальный язык для описания на уровне предметной области (DSL, Domain Specific Language) – вам нет необходимости знать о примитивах WebDriver. Но если вы реализуете «фикстуры» для тестов, описываете действия, которыми можно будет оперировать в табличках, реализуете DSL – вам придётся работать непосредственно с WebDriver, либо с каким-то его расширением, но не слишком высокоуровневым.
И самый последний аргумент, который, я надеюсь, со временем будет становиться всё менее актуальным – увы, пока хороших расширений катастрофически не хватает. Они обязательно появятся. Может быть, именно вы реализуете одно из таких расширений. Для этого вам понадобиться изучить интерфейс WebDriver. И те, кто будут пользоваться плодами вашего труда, смогут работать с более высокоуровневой библиотекой. А пока приходится использовать непосредственно WebDriver с небольшими надстройками над ним.

Надеюсь, всё вышесказанное позволит вам лучше понять, какое место Selenium WebDriver занимает в общей картине мира и как он соотносится с другими инструментами. Если всё ещё остались непонятные моменты – задавайте вопросы в комментариях, я постараюсь всё прояснить.

Ну а если вы решили освоить Selenium WebDriver – добро пожаловать на мои тренинги, я научу вас пользоваться этим замечательным инструментом, разумеется, в связке с некоторыми другими инструментами, упомянутыми в этой статье.

Читайте также: