Selenium grid что это
Совет инженерам по тестированию №1: Докеризируйте ваш Selenium Grid
И снова здравствуйте. Перевели для вас полезную заметку в преддверии старта курса «Java QA Engineer».
Каждый год инженеры по автоматизации тестирования со всего мира исследуют новейшие инструменты и методы, чтобы сделать свою среду автоматизации тестирования более стабильной, быстрой и простой в использовании и обслуживании. Это жизненно важно для обеспечения постоянного широкомасштабного внедрения их фреймворков в их компании. Так или иначе, раздутые устаревшие фреймворки быстро выходят из моды.
Selenium Grid, как известно, сложен в настройке, нестабилен и сложен в развертывании и/или управлении версиями на CI конвейере. Более простой, стабильный и удобный способ — использовать предварительно созданные образы Selenium Docker.
Примечание: Единственным недостатком этого метода является то, что не поддерживается IE (Internet Explorer), так как операционную систему Windows на данный момент невозможно поместить в контейнер.
Подготовка к работе
Чтобы приступить к работе, вам необходимо сначала установить Docker и Docker Compose на вашем компьютере. Если вы используете Windows 10 или Mac, они оба будут установлены с помощью Docker Desktop.
Запуск вашего Grid
Официальный репозиторий Selenium на Docker Hub содержит предварительно созданные образы Docker для ваших нодов (узлов) Selenium Hub, Firefox и Chrome.
Я включил пример ниже, который создает следующий Grid:
Файл Docker Compose описывает настройку вашего Grid. Дополнительные сведения о создании файлов Docker Compose см. в официальной документации.
Чтобы запустить свой Grid, просто используйте любой терминал ( PowerShell или cmd в Windows), в котором выполните следующую команду из корневого каталога вашего проекта:
Подключение к Grid
Вы можете подключиться к своему Selenium Grid точно в так же, как обычно, поскольку Hub прослушивает порт 4444 вашей локальной машины. Вот пример, в котором мы настроили наш Driver для использования нашего Chrome Node.
Затем вы можете использовать библиотеку TestNG, чтобы запускать тесты на нескольких нодах параллельно, как обычно.
Стоит отметить, что на каждом ноде можно запустить несколько браузеров. Однако это не рекомендуется, и использование одного браузера на каждом ноде считается лучшей практикой для достижения оптимальной производительности.
Дополнительные советы и хитрости
Если вы хотите увидеть, что происходит в браузере, в целях отладки своих тестов, то стоит иметь debug версию вашего docker-compose.yml файла, который загружает debug браузерные ноды. Они содержат сервер VNC, поэтому вы можете наблюдать за браузером во время выполнения теста.
Также возможно запускать headlessly-браузеры для увеличения скорости (обычный способ), и Selenium также предоставляет base версии образов, так что вы можете создавать свои собственные образы, если вам нужно установить дополнительное программное обеспечение.
Чтобы создать стабильную версию Grid для вашего CI конвейера, также можно развернуть ваш Grid на Kubernetes или Swarm. Это гарантирует быстрое восстановление или замену докеров в случае их выхода из строя.
Настраиваем Selenium Grid за 5 минут
Итак Selenium-Grid позволяет запускать тесты на разных машинах в разных браузерах параллельно.
В основном Selenium Grid используют по нескольким причинам:
Для распараллеливания запуска тестов на различных операционных системах, в различных браузерах; Для того, чтобы уменьшить общее время прогона тестов.
Selenium Grid оперирует такими составляющими, как Hub и Node.
Скачать Selenium Server Standalone здесь.
Создайте папку seleniumgrid и скопируйте в нее скачанный selenium_server_x.xx.x.jar файл.
Стартуем Hub.
Открываем окно команд и выполняем:
Должно появиться что-то подобное этому:
Для того, чтобы проверить, что все стартовало правильно, нужно набрать в браузере
Стартуем Node.
В моем случае и Hub и Node расположены на одном компьютере, но это не сильно меняет ситуацию.
Открываем консоль и пишем:
Node для браузера FireFox
Полные команды выглядят так:
Для Internet explorer я уже описывал, как можно использовать драйвер, написанный самим Майкрософт.
Для того, чтобы проверить, что все настроено корректно, нужно открыть все тот же http://localhost:4444/grid/console и убедиться, что там отображается один истанс IE и один Chrome.
Следует добавить, конфигурировать Hub и Node можно с помощью JSON файлов.
Пример для Hub:
Пример для Node:
Ну вот и все, в следующих заметках я покажу, как пользоваться настроенным гридом и запускать тесты. Если вам интересно, подписывайтесь,чтобы получать обновления первым.
Selenium
Selenium — это набор программ с открытым исходным кодом, которые применяют для тестирования веб-приложений и администрирования сайтов локально и в сети. Программы Selenium позволяют автоматизировать действия браузера. Среди программ проекта:
Selenium IDE
Selenium IDE — плагин для браузера Firefoх для записи действий пользователя (тестировщика) и их воспроизведения для тестирования. Является библиотекой Selenium с графическим интерфейсом и возможностями для работы со сценариями тестирования веб-страниц. IDE генерирует код для Selenium RC или Selenium WebDriver, который повторяет записанные действия пользователей.
Selenium RC
Selenium RC (Remote Control) — предыдущий основной продукт Selenium до появления WebDriver в 2007 году. Программа, называемая также Selenium 1.0, являлась средством удаленного управления браузером, но по функциональности сильно уступала WebDriver (Selenium 2.0). Selenium RC продолжает поставляться в дистрибутиве WebDriver, но продукт не развивается — при необходимости сложных тестов вне ограничений первой версии пользователям предлагают воспользоваться второй.
Selenium WebDriver
WebDriver напрямую отправляет команды браузеру, используя его API и получает результаты тестирования. В предыдущей версии Selenium RC принцип работы был другим — программа внедряла код на языке JavaScript в браузер для управления им. WebDriver же использует способ взаимодействия с браузером, максимально близкий к действиям обычного пользователя.
Тестировщик ПО на Java
Освойте ручное и автоматизированное тестирование и получите IT-профессию, даже не имея технического образования. Дополнительная скидка 5% по промокоду BLOG.
Selenium Grid
Selenium Grid — кластер из нескольких Selenium-серверов, которые позволяют управлять браузером удаленно по сети. Grid позволяет организовать сеть, в которой можно запускать большое количество браузеров на большом количестве компьютеров. Параллельное тестирование позволяет тестировщикам экономить время.
Преимущества Selenium
Selenium — бесплатный продукт с открытым исходным кодом для тестирования с поддержкой всех основных языков программирования. Его можно использовать на разных браузерах в разных операционных системах, включая мобильные устройства.
Selenium WebDriver — гибкий инструмент тестирования, который можно легко интегрировать с разными тестовыми фреймворками и другими инструментами тестирования. Это позволяет расширить инструментарий тестировщика и применять его для узких задач, например web crawling и тестирования производительности.
Selenium разрабатывают с 2004 года, и за это время он стал самым популярным инструментом функционального тестирования веб-приложений. Его используют в крупных корпорациях, включая Google.
Недостатки Selenium
В программах Selenium можно тестировать только веб-приложения, функций тестирования сетевых и десктопных приложений в комплекте нет. Также для работы с Selenium нужно владеть продвинутыми навыками программирования и написания скриптов. Новички в тестировании могут пользоваться более простыми аналогами Selenium, например Katalon Studio или UFT.
Быстрый вход в IT без технического образования — за 4 месяца вы на практике поймете основы веб-разработки, научитесь работать с баг-трекерами, тестировать приложения и API, составлять SQl-запросы.
Ставим 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 как самостоятельный продукт, без преобразования записанных сценариев в программный код. Это, конечно, не позволяет разрабатывать достаточно сложные тестовые наборы, но некоторым хватает и простых линейных сценариев.
Вот, кажется, и всё.
Если я забыл рассказать про какой-то термин – напишите в комментариях, и я постараюсь добавить его в этот мини-словарик.