selenium grid что это
Selenium Grid 4
Selenium Grid allows the execution of WebDriver scripts on remote machines (virtual or real) by routing commands sent by the client to remote browser instances. It aims to provide an easy way to run tests in parallel on multiple machines.
Selenium Grid allows us to run tests in parallel on multiple machines, and to manage different browser versions and browser configurations centrally (instead of in each individual test).
Selenium Grid is not a silver bullet. It solves a subset of common delegation and distribution problems, but will for example not manage your infrastructure, and might not suit your specific needs.
Purposes and main functionalities
Selenium Grid 4
Grid 4 takes advantage of a number of new technologies in order to facilitate scaling up while allowing local execution.
Selenium Grid 4 is a fresh implementation and does not share the codebase the previous version had.
To get all the details of Grid 4 components, understand how it works, and how to set up you own, please browse thorough the following sections.
Getting started with Selenium Grid
Instructions, step by step, showing how to run a simple Selenium Grid.
When to Use a Grid
Is Grid the right tool for you?
Selenium Grid Components
Check the different Grid components to understand how to use them.
Configuration of Components
Here you can see how each Grid component can be configured individually based on common configuration values and component-specific configuration values.
Grid architecture
Advanced features of Selenium
To get all the details of the advanced features, understand how it works, and how to set up your own, please browse thorough the following sections.
Как выполнять много UI-тестов параллельно, используя Selenium Grid?
Всем привет! Я работаю в Avito и занимаюсь разработкой инструментов для тестирования. Когда у нас стало много UI-тестов, мы столкнулись с проблемой масштабирования Selenium-серверов, и сейчас я расскажу, как мы ее решили.
И так как же все-таки выполнять много UI-тестов параллельно, используя Selenium Grid? К сожалению — никак.
Selenium Grid не способен выполнять большое количество задач параллельно.
Хотите зарегистрировать действительно большое количество нод? Что ж, попробуйте.
Хотите скорости? Её не будет — чем больше нод зарегистрировано на гриде, тем менее стабильно выполняется каждый тест. Как следствие — перезапуски.
Хотите отказоустойчивость на случай, если Grid перестал отвечать? Тоже нет: вы не можете запустить несколько реплик и поставить перед ними балансировщик.
Хотите обновить Grid без даунтайма и чтобы тесты, выполняющиеся в данный момент, не упали? Нет, это не про Selenium Grid.
Хотите не держать тысячи Selenium-ов разных конфигураций в памяти, а поднимать их по требованию? Не получится.
Хотите знать, как решить все эти проблемы? Тогда приглашаю вас прочитать эту статью.
*(Мой доклад с таким же названием уже звучал на Heisenbug 2017 Moscow, и, возможно, кто-то из читателей с ним знаком. Под катом — более подробная текстовая версия рассказа об инструменте).
Небольшое отступление, о том как работает Selenium-сервер.
Окей, а зачем нужен Selenium Grid? Selenium Grid предоставляет единую точку для работы со множеством Selenium-серверов разной конфигурации:
Замечательный инструмент, правда?
Но при его использовании мы столкнулись с рядом проблем.
1. Непредсказуемое поведение
Если кратко, то у вас отвалится что захочет и когда захочет, и вы никак не сможете на это повлиять.
2. Отсутствие поддержки большого количества нод
При попытке зарегистрировать много нод (а мы хотим много нод), регистрация произойдет, но протестировать приложение во много потоков все равно не получится, так как большая часть тестов упадет.
3. Масштабируемость
Первое, что приходит в голову, когда достигнут предел нод = N на селениум гриде, при котором не страдает стабильность, — это взять два, три, пять, (да хоть десять) гридов, зарегистрировать на каждый по N нод, вкрячить перед всем этим добром какой-нибудь балансировщик и запускать тесты в 10*N потоков. Но нет, Selenium Grid так не работает. Потому что вся информация о нодах и сессиях хранится в памяти у конкретной ноды и не шарится между ними. С этим тесно связана следующая проблема.
4. Отказоустойчивость
Если у вас выключается машина, где находится хаб, то все тесты сразу умирают, потому что у вас нет никаких резервных хабов, на которые могут идти следующие запросы, ибо опять же, все лежит в памяти. И это абсолютно никак не смасштабировать (конечно же, всегда можно переписать пару классов грида, но об этом позже). Слабое место — это Selenium Hub, при его падении ноды становятся недосягаемыми.
5. Отсутствие возможности динамического создания нод с использованием система оркестрации контейнерами
Если для тестирования вам необходимо множество различных конфигураций нод с разными конфигурациями браузеров, то возникает еще одна проблема: весь этот зоопарк занимает довольно много места в памяти. Предположим, у вас: 300 нод с Google Chrome (150GB RAM) + 300 нод с Firefox (150GB RAM) и еще 200 нод какого нибудь Firefox Nightly c магическими плагинами (100GB RAM). 400GB RAM постоянно заняты, плюс хочется эффективно перераспределять ноды в течение дня, скажем, занять все 400GB семью сотнями хромов при тестировании одного сьюта и гибко заменять их при появлении в очереди тестов с другими потребностями.
Для решения этой задачи идеально подойдет Docker, так как он позволяет быстро поднимать контейнер со свежим Selenium и так же быстро его убивать после завершения теста. И так как селениумов нам нужно много, на один железный сервер все это не влезет, возникает потребность в оркестрации контейнеров на кластере. На рынке существует несколько популярных решений для этой задачи, у нас используется Kubernetes. Почему мы выбрали Kubernetes, можно послушать здесь. Стандартными средствами Selenium эту проблему не решить.
6. Невозможно обновить/перезапустить грид без даунтайма
Еще одно следствие хранения сессий в памяти. Не то чтобы это суперкритичный минус, но всё равно неприятный.
Все вышеперечисленное — это ситуация, в которой мы в один прекрасный момент оказались.
Известные решения
Grid Router и новая реализация Go Grid Router — хорошее решение, но к сожалению далеко не идеальное. Основная проблема особенность, то что это не замена для Selenium Hub, это еще одна прокси сверху.
Отсюда и название — Grid Router, потому что он управляет не нодами, а гридами, поэтому есть минусы.
Selenoid — средство для запуска тестов в docker-контейнерах. При каждом запросе на создание сессии запускается свежий контейнер и при закрытии сессии удаляется. Инструмент замечательный, но есть минусы:
Когда мы столкнулись со всеми этими проблемами, мы решили поинтересоваться опытом других компаний. «Яндекс» писал в блоге на Habrahabr о том, что не получается регистрировать много нод и работать с ними, для решения этой проблемы они используют Grid Router. Для наших задач Grid Router не подходит.
«Альфа-Банк» писал о том, что у них все повисает, если grid какое-то время не использовать, и наш опыт это подтверждает — у нас то же самое было регулярно.
Конечно же мы не обделили вниманием github selenium, где нашли несколько issue… Вот пример отношения авторов к происходящему:
Q: «selenium-grid version 3.0+ support hub high availability?»
A: «I would recommend having a separate server monitor the hub and then if/when the hub goes down it would know how to restore the hub.»
Мы поняли, что надеяться нам не на что, и стали сами решать свои проблемы.
Исследование
Мы уже довольно долгое время используем это решение в продакшене, оно работает и не требует никакой поддержки. В процессе мы еще раз убедились в том, что не стоит бояться делать велосипеды. Популярные решения — это не всегда хорошо, нужно всегда исследовать возможности для решения проблем.
Ставим Selenium Grid на колеса Apache Mesos
Привет, Хабр! Меня зовут Настя, и я не люблю очереди. Поэтому я расскажу вам, на примере Альфа-Лаборатории и наших исследований, каким образом можно организовать инфраструктуру и архитектуру для прогона тестов, чтобы получать результат в разы быстрее. Например, нам удалось добиться такой цифры, как 5 минут суммарного времени прохождения тестов на приложение. Для этого нам пришлось поменять подход к запуску Selenium Grid.
Прежде чем начну рассказывать про сам selenium grid и все, что связано с ним, я хочу пояснить суть проблемы, которую мы пытались решить.
В прошлом году мы внедряли DevOps как процесс. И в один момент, автоматизируя все и вся, мы поняли, что time to market для каждого артефакта на этапе тестирования не должен превышать 30 минут. Концептуально мы хотели, чтобы некоторые релизы проходили автоверификацию, если приемочное тестирование им не нужно. Для тех артефактов, которые нужно проверять руками, 30 минут — это время, за которое тестировщик получает результаты прогона автотестов, анализирует их, а также делает приемочное тестирование. При этом автотесты должны автоматически запускаться в рамках нашего pipeline.
Чтобы достичь поставленной цели, нам необходимо было ускорить прогон автотестов. Но помимо ускорения автотестов, нужно было еще сделать так, чтобы при всем обилии проектов у нас не возникали очереди на их запуск.
Чаще всего задача ускорения прогона автотестов решается двумя способами:
Итак, цель ясна: ускорить и устранить очереди на запуск автотестов без привлечения дополнительного финансирования.
В самом начале у нас был довольно небольшой парк, состоящий из 15 виртуальных машин.
Ресурсов катастрофически не хватало. Почему? Давайте рассмотрим на конкретном примере:
Получается, что в один момент времени мы можем создать 120 контейнеров!
Это не только перекрывает наши запросы в 60 сессий, но и страхует на будущее. Ведь количество команд растет, а значит — количество запускаемых проектов тоже постоянно растет. Итак, стало достаточно очевидно, что нам нужно взять имеющиеся ресурсы и объединить их в единое пространство вычислительных мощностей, это еще называют песочницей. Объединяя, мы при этом не хотим думать о нем именно в парадигме каких-то хостов/виртуальных машин. Мы хотим иметь просто пространство, к которому мы сможем подключаться с помощью какого-нибудь api, и создавать в нем свои докер-контейнеры, на которых потом будем запускать тесты.
Динамическая песочница
Итак, нам необходимо создать песочницу вычислительных ресурсов. При этом она должна быть динамической: т.е. мы должны иметь возможность в любой момент подключить/отключить от нее ресурсы, которые у нас есть. Причем все хосты, которые мы подключаем, могут иметь разную конфигурацию и быть в различных подсетях, для нас лишь главное, чтобы между ними можно было установить связь по определенным ip и портам. Динамическую песочницу называют еще облаком или кластером, и в нем мы имеем интерфейс для создания и управления докер-контейнерами.
Когда мы поняли, как хотим решить задачу, мы построили нашу песочницу, объединив наши хосты в кластер с помощью Apache Mesos и Marathon.
Таким образом мы получаем общее пространство с вычислительными ресурсами, у которого есть свое api. API нам предоставляет Marathon, а Apache Mesos как раз таки и объединяет хосты.
Оркестратор тестов: Selenium grid спешит на помощь
Мы определились с тем, что нам нужен кластер, и даже его создали. Но вот вопрос, как же мы будем запускать тесты в кластере? Вы же помните, что мы хотим в любом случае получать результаты тестов не больше, чем за 10 минут?
И тут на помощь нам должна прийти параллелизация запуска тестов.
Для решения этой задачи нам нужен централизованный инструмент, который позволит запускать и параллелить тесты в несколько потоков для каждого проекта. Есть несколько популярных инструментов.
Фактически вся процедура представляет из себя 3 действия:
1. Мы копируем Selenium Standalone Server (нужной нам версии) в какую-нибудь директорию.
2. Затем выполняем команду, которая запускает этот сервер в нужном нам режиме: хаба, либо режим ноды. Обратите внимание, что за эти две функции отвечает один и тот же физический jar-ник, который вы продублировали на разные хосты.
3. Конфигурируем ноду. Либо через командную строку, либо в json-файле указываем набор браузеров и их параметры.
Что делает хаб после старта грида
Что делает нода
Чем же отличается старт грида в докер-контейнерах?
1. Нода на момент старта уже сконфигурирована.
Давайте посмотрим на содержимое ноды. Файл с json-конфигом для ноды находится в контейнере с ней, затем мы его переименовываем, и наш сервер узнает о своих параметрах из этого файла:
При этом если мы посмотрим на содержимое Dockerfile самой ноды, то увидим, что при конфигурировании окружения ноды мы сразу задаем переменные окружения, которые потом записываются в этот конфиг. Таким образом, нам не нужно лезть в “кишки” самого контейнера, чтобы изменить параметры запуска ноды, нам достаточно в Dockerfile переопределить значения указанных переменных. И все.
2. Когда мы стартуем ноду в контейнере, мы всегда можем быть уверены в том, что у нашего окружения уже есть браузер и драйвер для него. Потому что все это настраивается и устанавливается в момент сборки самого образа.
3. Также у нас есть скрипт sh, который выполняется после старта контейнера. И в этом скрипте мы видим, что после того, как у нас поднялся контейнер — у нас сразу же стартует наш java сервер.
Аналогично все по отношению к хабу.
В итоге запуск selenium grid в контейнере сводится к одной команде — старт докер-контейнера.
Проблема статического грида
Несмотря на то, что хаб хорошо умеет работать с очередями и тайм-аутами, в самом начале использования статического грида мы испытали проблемы из-за тайм-аутов. Если хаб и нода долго не использовались, то при последующем коннекте мы ловили ситуации, когда при создании сессии на ноде эта самая сессия отваливалась именно по тайм-аутам или по причине того, что remotewebdriver не может поднять браузер. И все эти проблемы лечились рестартом грида, именно тогда мы и поняли, что для нас on-demand selenium grid будет решением проблемы.
Также мы не хотели, чтобы статический грид просто занимал место в кластере, который у нас и так небольшой. Как решить ситуацию, когда для разных проектов нам нужны разные конфигурации грида? Когда для одного проекта нужна одна версия браузера, для другого — другая? Очевидно, что держать включенными гриды — не самая хорошая идея.
Selenium Grid On-Demand
Поэтому мы захотели поднимать selenium grid по запросу: объясню на примере
Автоматизация создания Selenium Grid On-Demand
Чтобы решить эту задачу, надо было написать скрипт автоматизированного создания грида. Мы ее решили с помощью ansible, написав нужные роли. Я не буду рассказывать, что такое ansible. Но могу сказать, что написать подобный скрипт вы у себя сможете также и на bash-e или на другом языке программирования, который на выходе вам предоставляет две команды на создание и удаление грида.
Помним, что запуск грида состоит из запуска парочки команд. И у каждой команды есть свои параметры. И чтобы автоматизировать запуск этих команд, эти параметры надо лишь автоматически вычислять до запуска команды. Либо же хардкодить.
Мы не можем хардкодить, потому что мы априори не знаем, на каком хосте и порту поднимутся компоненты Selenium Grid, так как за нас это решает Apache Mesos.
Мы, конечно, можем извернуться и вручную следить за открытыми портами и хостами, на которых поднимаем Selenium Grid, но тогда зачем нам вообще Apache Mesos и Marathon, если все будем делать вручную?
Итак, надо было автоматизировать вычисление следующих параметров:
Deploy Selenium Grid
test_id: уникальный идентификатор проекта с тестами
nodes_count: количество нод
nodes_type: тип браузера [chrome|firefox]
Delete Selenium Grid
Shell-скрипты, исполняемые на Jenkins, перед запуском ansible playbook рассчитываются автоматически и передают значение переменной. Прогон тестов встроен в pipeline с помощью job dsl.
Как только мы решили эту задачу и научились поднимать selenium grid в нашем кластере, то поспешили запустить тесты, и тут-то нас ожидало разочарование. Тесты не запускаются, более того — хаб даже не поднимает сессию с нодой.
Проблема поднятия Selenium Grid On-Demand в распределенном кластере
Давайте разберемся, чего же не хватало нашим скриптам.
Еще раз взглянем, как бы выглядела команда, если бы мы запускали каждый раз ноды в Docker-контейнере для selenium grid вручную:
Запуск ноды в Marathon
При настройке Apache Mesos-кластера мы для каждого хоста указываем диапазон портов. Этот диапазон используется для контейнеров, которые поднимаются Marathon’ом. 
К примеру, если мы ставим диапазон 20000-21000, то наши контейнеры будут получать случайный порт из этого диапазона.
Marathon-агент запускает примерно такую команду.
При запуске контейнера он выбирает следующий свободный порт и подставляет его вместо знака вопроса. Таким образом в момент старта ноды в режиме сетевого моста у нас происходит мапинг портов.
Marathon стартует контейнер на случайном хосте и случайном порту.
Нода отправляет неправильные координаты
Докер-контейнеры по умолчанию запускаются в режиме сетевого моста (bridge). Что это значит для нас? А то, что нода не будет видеть свой настоящий IP и порт! Допустим, что Apache Mesos поднял нам ноду на хосте 192.168.1.5 и порту 20345. Но процесс ноды в контейнере будет думать, что она поднимается на некотором 172.17.0.2; а порт у нее 5555.
И она зарегистрируется на хабе с таким обратным адресом. Естественно, хаб по этому адресу ее не найдет. И при запуске тестов хаб не сможет поднять сессию браузера. 
Решение проблемы регистрации ноды на хабе
Но есть еще режим host. Когда контейнер использует непосредственно порты хоста и у него нет такого понятия, как внутренний порт.
Когда мы задумались о решении данной задачи, естественно, мы подумали, зачем нам стартовать контейнер и при этом создавать сетевой мост, а почему бы не использовать хостовый режим? Мы указываем один порт, на котором поднимаемся, и контейнер, и на него же сразу смотрит selenium server.
Но не тут-то было. Чтобы наши тесты выполнялись в докер-контейнере, у которого как такового нет дисплея, а скриншоты снимать тоже надо, используем xvfb-сервер, который в момент старта контейнера тоже занимает определенный порт. Кстати, поэтому хостовый режим нас вообще не устраивает. Придется как-то подкручивать режим bridge.
Переменные среды контейнера
Когда Marathon стартовал контейнер, он выставляет в переменных среды этого контейнера фактический хост и порты, на которых он поднял контейнер.
То есть у контейнера появляются значения переменных HOST и PORT0.
А значит, внутри контейнера есть информация о том, на каком хосте он развернут и какие внешние порты у него есть.
Чтобы у нас все заработало, необходимо, чтобы в значениях переменных host и Port, отправляемых в запросе на регистрацию, передавались значения переменных HOST и PORT0 самого контейнера.
Параметр HOST указать легко — у Selenium есть специальная настройка.
С портом сложнее. Если передать этот PORT0, то Selenium не только зарегистрируется под ним на хабе, но еще и сам на нем поднимется! Почему это проблема?
К примеру, Apache Mesos выдал нам внешний порт 20765. При старте контейнера он делает маппинг: 20765:5555. Второе число мы задаем сразу, жестко, в конфиге. И docker будет ожидать, что внутри контейнера нода будет висеть на 5555. И будет пересылать туда соединения с внешнего порта 20765.
Возможно, вы уже догадались, что проблему можно решить, разделив понятие порта на два отдельных. Порт, на котором нода поднимается, и порт, который она должна сообщить хабу. В docker-среде эти значения как правило не совпадают.
Как сказать ноде об этих портах?
Никак.
Из коробки Selenium Standalone Server так не умеет.
Надо патчить Selenium.
Патчим Selenium Server
Код самого Selenium находится на GitHub. И мы решили добавить в selenium standalone server еще немного… чудесного кода.
Добавили параметр advertisePort.
И условие в метод регистрации на сервере.
Теперь, если при запуске ноды задан параметр advertisePort, то он используется вместо стандартного port во время регистрации на хабе. Это локальный патч, мы пока не делали Pull Request в репозиторий selenium. Когда обкатаем до конца нашу схему, сделаем.
С помощью этого параметра ноды правильно регистрируются на хабе. Проверено, работает. Тесты прогоняются.
И да, мы использовали Marathon, так как он применяется нашими разработчиками. Это по сути proof of concept. Но вообще для запуска selenium grid-а этот фреймворк не идеально подходит, так как заточен на long running tasks. Такие как сервисы, UI-приложения.
Выводы
В динамичной организационной среде требуется динамическое управление ресурсами. Статика будет ломаться об процессные проблемы.
Поэтому наша система для прогона тестов состоит из следующих компонент:
Стоили ли затраченные усилия полученного результата? Безусловно, ведь в сухом остатке мы ускорили прогон тестов как минимум вдвое.
Если вы тоже не сильно любите очереди и пытаетесь ускорить прогон тестов — возможно, вам будет полезен наш опыт.
Кстати, если от постов про тестирование ваше сердце бьется чаще и возникает желание провернуть что-то подобное — обратите внимание, что у нас есть вакансия тестировщика.
А если есть какие-то вопросы и уточнения — обязательно пишите в комментариях.
Что такое Selenium?
Время от времени мне приходится распутывать терминологические хитросплетения, связанные с употреблением словосочетаний, в которых встречается слово Selenium – Selenium 2.0, Selenium IDE, Selenium RC, Selenium WebDriver, Selenium Server, Selenium Grid.
Путаница возникает во многом из-за того, что нигде нет чёткого описания всех этих терминов на одной страничке, и я постараюсь восполнить этот информационный пробел.
Selenium
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 как самостоятельный продукт, без преобразования записанных сценариев в программный код. Это, конечно, не позволяет разрабатывать достаточно сложные тестовые наборы, но некоторым хватает и простых линейных сценариев.
Вот, кажется, и всё.
Если я забыл рассказать про какой-то термин – напишите в комментариях, и я постараюсь добавить его в этот мини-словарик.