Что такое selenium в тестировании
Селениум: тестирование веб-приложений и другие полезные функции
Selenium — это не одиночный инструмент, как многие считают по ошибке. Селениум — это целый набор разношерстного инструментария, который решает задачи разного уровня по тестированию. Поэтому если говорить о Селениуме, то нужно коснуться всего набора инструментов.
Селениум: набор инструментов
Selenium IDE — это специализированный плагин для FireFox, который дает тестировщикам возможность проводить запись своих действий для будущего анализа. Он способен разработать тестовые случаи, но только в «Огненной Лисе», так как другие браузеры он не поддерживает. При этом записанные сценарии тестирования можно конвертировать в другие языки программирования, чтобы выполнить их в других браузерах. Это простой в использовании плагин. Он не требует для тестирования глубоких знаний языков программирования, так как способен сам остоятельно сформировать нужный код.
Selenium RC — это полноценная среда для тестирования, которая дает возможность применять популярные языки программирования: Java, C#, PHP, Python, Ruby, PERL и другие. Данная среда уже практически не применяется и не рекомендуется для использования.
Selenium WebDriver — это среда для тестирования, которая пришла заменить Selenium RC. По сути, WebDriver — это несколько специальных библиотек для разных языков программирования, которые можно применять для написания программ для управления браузером. Это свободный набор библиотек, поэтому их можно использовать в разных браузерах. Selenium WebDriver позволяет создать собственный фреймворк для тестирования.
Selenium Grid — это крутой инструмент, который позволяет одновременно запускать по несколько тестов на разных устройствах или разных браузерах, что ускоряет сам процесс тестирования.
Особенности инструментов Селениум
Каждый из существующих на рынке инструментов имеет свои особенности, что отличает один инструмент от другого. Набор инструментов Селениум имеет свои особенности:
Открытый исходный код.
Расширяет свои возможности при подключении дополнительных технологий.
Работает с разными браузерами.
Работает с разными операционными системами.
Функционирует на мобильных устройствах.
Проводит тестирования прямо в браузере.
Можно проводить тестирования на разных устройствах одновременно, применяя Selenium Grid.
Недостатки набора инструментов Селениум
У Селениум есть свои недостатки:
Тестирует только веб-приложения.
Отсутствуют сценарии восстановления и хранилище объектов.
Нет полноценной IDE.
Не дает возможность контролировать элементы управления в браузере.
По умолчанию не генерирует отчеты о тестировании.
Заключение
Селениум идеально подойдет для тех, кто уже устал все тестировать «руками», потому что Selenium — это эффективный набор инструментов для автоматизации тестирования.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
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 тестировании
Когда перед вашей командой стоит задача написать действительно крупный проект, всегда становится задача тестировать написанный код. Если сервер тестировать относительно легко, то JS код чаще всего тестировать просто невозможно в связи с его природой.
Природу JS решила обойти отличная команда разработчиков, которая создала уникальный в своем роде продукт, который позволяет написать приемочные тесты, которые будут взаимодействовать на прямую с браузером. У них получилось очень и очень круто, но грабли были, есть и будут. По этому я расскажу о граблях, которые обычно встречаю во время работы с данным прекрасным продуктом.
Данная статья больше ориентирована на новичков, чем на профессионалов.
Архитектура тестов
Часто встает вопрос, как спроектировать тесты, чтоб сократить написание кода и не заниматься копипастом. Обычно используются generic файлы, которые наследуют unitTest класс вашего языка. У нас всегда есть возможность изменить поведение для какой-то группы тестов, не затрагивая другие группы. К примеру:
Когда вы отделяете функционал по категориям, выносите его в директории, а в каждой директории создавайте свой generic. Каждый тест должен наследовать класс generic с которым он лежит в директории. Generic может быть даже пустым, в будущем он пригодится, даю гарантию.
Запуск тестов
Разница между юнит тестами и приемочными тестами заключается, что в unittest обычно тестируют алгоритмы и логику, а приемочные уже тестируют саму систему, с реальными данными, которые получают из работающей БД.
База данных
Задача всех тестов, быть изолированными друг от друга. А значит на каждый запуск теста, нужно создавать новую тестовую БД. У каждого unittest функционала языка есть метод setUp, который вызывается перед запуском теста. Попробуйте в нем изменить настройки до иницилизации базы данных. Так вы сможете полностью изолироваться от других тестов и существующих данных, а если вы еще используете механизмы кэширования, очистите кэш или воспользуйтесь пустым хранилищем кэша как и с БД.
Фикстуры
По сути, это данные которые будут записаны в вашу тестовую БД, для того чтоб браузер открыл сайт и не получил ошибок. Базовые данные стоит записать в setUp методе главного generic`a. А остальные записывать по мере потребностей данных в самих тестах.
Сохранение данных базы
Создайте путь для возможного дебага, часто бывает так, что тесты по не понятной причине глохнут с ошибкой, часто бывает что нужно сохранить базу и оставить браузер в живых. Возможно вам и sleep подойдет? Если вы сделали функционал сохранения базы, сделайте так-же функционал очистки старых баз. У меня к примеру mongoDB смог за неделю разработки создать 80гб баз данных.
Передача подключения
Когда открывается браузер, запомните, он никак не связан с вашим тестом. Если селениум просто откроет браузер и начнет выполнять операции, скорее всего он будет выполнять их над существующим проектом. Передайте в браузер параметры, которые помогут идентифицировать нужную тестовую базу. В свое время, браузер должен будет передать информацию на сервер.
Кодовая база
Вот тут вам нужно будет сесть и подумать, как сделать для самого себя жизнь прекрасней.
К примеру, у вас асинхронное многопользовательское real time приложение(игра), нужно писать тесты где могут взаимодействовать два и более пользователей. Посмотрите, будет ли вам удобно переключатся между окнами браузера с помощью драйвера? Нет, напишите свою простую реализацию.
Нужно собственные assert`ы? К примеру проверить существование элемента в дереве?
Вполне вероятно, что у вашего проекта есть свои особенности и нужно подготовить некоторую функциоальную часть тестов для этого.
Таймауты
Всегда при тестировании, нам нужно будет выполнять таймауты. Толи это будет загрузка страницы, ajax или socket запрос на сервер. С загрузкой страницы драйвера содержат встроенный метод для ожидания. Но вот с ajax и socket запросами всё сложнее. Вам нужно будет написать счетчик отправленных запросов и полученных ответов. Когда вы отправляем запрос, счетчик инкрементится, когда приходит ответ, декрементится. В самом generic`e реализовываем метод, который будет проверять данный счетчик и если он не равен 0, то пусть ждет, но ограничивайте ожидание, ответ от сервера может и не прийти.
Взаимодействие кода тестов и браузера.
Порой нам нужно будет получать состояния или какие-то данные, для проверки их значений с ожидаемыми. Сразу напишите пути получения этих данных. К примеру если вы используете AngularJS, то чтоб получить доступ к данным сервиса, напишите прослойку для этого.
Если нету какой-то возможности с помощью тестов эмулировать действия пользователя, то нужно вызывать обработчики этих событий. Дайте возможность тестам стучаться к исполняемому JS коду.
Разные среды исполнения
Чаще всего получается так, что тест работает у вас на компе, но не работает у других. Это может быть связано с ОС, версией селениума, разрешением монитора и вплоть до версий браузера. Советую, заведите себе дешевый VPS, на котором вы сможете запускать тесты. На серверной линухе можно запускать тесты прямо из браузера. К примеру ман, который мне помог www.alittlemadness.com/2008/03/05/running-selenium-headless В добавок, вы сэкономите свое время, пока будете ожидать завершения тестов. Не забудьте, браузер весьма требовательный по оперативке, добавьте хороший запас swap.
Баги драйверов и самого селениума
Первое, посетите code.google.com/p/selenium/issues/list и пробегитесь глазами по багам.
Второе, если вы уверены, что это обязано работать, пройдитесь JS дебагом по коду. Вполне вероятно что вы найдете место, которое бажит по вине самого селениума или драйвера. К примеру я наткнулся на баг, когда при mouse move, chomedriver не передает событие which, которе отвечает за текущую нажатую кнопку мыши.
Так-же известная неприятность, которая связа со скролами. Селениум ничего не умеет скролить кроме скролла у body. Решения два. Писать функцию скролла или на сервере ставить большое разрешение виртуального монитора.
Часто тесты могут глючить из-за таймаутов. Воспользуйтесь функционалом, который сможет повторят тесты. Дайте ему возможность на сервере перезапускать тест раза 3. Если тест валится, значит он не рабочий, если он валится периодически, проблемы в таймаутах, которые не заметны пользователю, но заметны самому селениуму.
Нагрузочное тестирование с помощью Selenium
Введение
В это статье я расскажу о применении инструмента изначально предназначенного для функционального тестирования при тестировании нагрузочном web части системы электронного документооборота (СЭД).
Зачем вообще это понадобилось? Мы преследовал две цели – введение автоматических тестов для наших web-приложений и создание нагрузочных тестов на основе функциональных тестов.
Почему для теста использовался именно Selenium, а не более подходящий инструмент – LoadRunner, jMeter? С помощью LoadRunner’s нагрузочный тест был проведён, но результаты были поставлены под сомнения – при эмуляции двухсот пользователей страницы загружалась за 2 секунды плюс-минус 2%, хотя при открытии этих же страниц из браузера отображение происходило более чем за 3 секунды. Так что хотелось провести нагрузочные тесты максимально приближенные к реальности, а это можно сделать только с помощью полной эмуляции поведения пользователя. Для этого как раз подходили инструменты для функционального тестирования с их работой с браузерами – сайт открывался бы через обычный браузер, т.е. так как делал бы это пользователь.
Про Selenium
Для функционального тестирования был выбран именно Selenium по простой причине – он лучший из бесплатных инструментов для функционального тестирования. Если точнее – у него хорошая поддержка удалённого управления (Selenium Server, Selenium Grid), много документации (в том числе и на русском языке ( habrahabr.ru/post/151715 habrahabr.ru/post/152653 ) и поддержка всех основных браузеров (хотя это уже больше заслуга WebDriver).
Общая архитектура
Приложение разделено на уровни (для наглядности на схеме элементы каждого уровня имеют осмысленные названия, а не просто Тест 1, Методы 2).
Первый уровень – уровень «запускальщика» тестов. Он просто запускает тесты. В настройках конфигурируется количество потоков, количество запусков теста, классы теста.
Второй уровень – сами тесты. Они выполняют бизнес операции – авторизируются, открывают списки документов, открывают документа, переходят по вкладкам документов.
Третий уровень – уровень работы с web-элементами. В нём содержаться атомарные пользовательские операции по работе с системой – открытие списка документов, переход к определённому документу, работа с вкладками документа.
Для начала перечисленных действий будет достаточно для обеспечения минимальной работы с системой. В дальнейшем они будут добавляться.
Разделение на эти уровни даёт следующее выгоду – можно запускать тесты как с «запускальщикам», так и без – просто запуск одного теста из среды разработки. Вынесение атомарных пользовательских операций на отдельный уровень позволит в дальнейшем отказаться от написания тестов на Java, а разработать свой DSL ( ru.wikipedia.org/wiki/Предметно-ориентированный_язык_программирования) для того, что бы тесты могли писать любые люди.
Запуск тестов
Программа для запуска jUnit тестов довольно проста и состоит из трёх классов – класс, который выполняет указанные тесты в своём потоке; класс «слушателя» jUnit теста для подсчёта времени выполнения теста; класс для формирования потоков и их запуска.
Код Runner’а
Код класса запускающего тесты
Тесты
Тесты были написаны простые, но, тем не менее, отражающие работу пользователя – открытие списка документов, открытие карточки документа, переход по вкладкам карточки.
Для написания тестов использовался jUnit. Хотя также можно использовать TestNG, который поддерживает параллельный запуск тестов (а при нагрузочном тестировании это обязательное требование). Но выбран был именно jUnit по двум причинам: 1) в компании он широко распространён и давно используется 2) нужно было всё равно писать свой «запускальщик» который бы позволил, не изменяя тесты, запускать их в разных потоках (в TestNG параллельный запуск настраивается в самих тестах) и собирать статистику по их выполнению.
Помимо тестов были написаны дополнительные модули – pool webdriver’ов (здесь слово webdriver используется в терминологии Selenium’а), pool пользователей, pool документов, rule (в терминологии jUnit) по снятию скриншотов при ошибке, rule по выдаче webdriver тесту, rule авторизации.
Pool webdriver’ов – это класс, который управляет получением webdriver из сервера Selenium’а и распределяет их между тестами. Нужен для того, что бы абстрагировать работу с Selenium’ом – тесты будут получать webdriver’ы и отдавать их этому pool’у. Webdriver’ы при этом не закрываются (не вызывается метод close). Это нужно потому, что бы не перезапускать браузер. Т.е. таким образом получается «реиспользование» webdriver’ов другими тестами. Но повторное использование имеет свои минусы – при возвращении webdriver’а в pool нужно «подчистить» за собой – удалить все cookie или, если это сделать нельзя, выполнить logout.
Так же, как в последствии выяснилось, этот pool должен перезапускать webdriver’ы, сессия которых завершилась. Такое возможно, когда произошла ошибка на стороне сервера.
Pool пользователей нужен в основном при нагрузочном тестировании, когда нужно запускать одинаковые тесты под различными пользователями. Он всего лишь по кругу отдаёт логин/пароль очередного пользователя.
Pool документов, так же как и пользователей, нужен в основном при нагрузочной тестировании – он по кругу возвращает id документов определённого типа.
Rule по снятию скриншотов при ошибке, нужен, как следует из названия, снимать скриншот при ошибке выполнения теста. Он сохраняет его в папку и записывает в лог название скриншота со stacktrace’ом ошибки. Очень помогает в дальнейшем «увидеть» ошибку, а не только прочитать её в логах. ( internetka.in.ua/selenium-rule-screenshot )
Rule по выдаче webdriver’а тесту нужен для того, что бы автоматизировать получение перед началом тестового метода и возврат при его окончании webdriver’а из pool’а webdriver’ов.
Rule авторизации нужен так же для автоматизации, только теперь авторизации – что бы в каждом тестовом методе не писать login\logout.
Сбор статистики
Для сбора статистики было решено не изобретать велосипед, а использовать что-нибудь из готовых framework’ов. Поиск в интернете, к сожалению, не дал широкого выбора – всего один инструмент – JETM (http://jetm.void.fm/), да и он уже не изменялся с 2009 года. Хотя обладает хорошей документацией и небольшой плюсы – удалённое подключение по HTTP для просмотра статистики в реальном времени.
Код конфигурации монитора и запуска http-консоли:
Сбор статистики происходил из двух мест – собиралось общее время выполнение тестовых методов (из уровня «запускальщика») и время выполнения атомарных пользовательских операций (из третьего уровня). Для решения первой проблемы использовался наследник RunListener’а, в котором переопределялись методы начала и окончания теста и в них собиралась информация о выполнении.
Решение второй проблемы можно было выполнить «в лоб» — в начале и конце каждого метода, время выполнения которого нужно записывать, писать код для отсчёта этого времени. Но так как методов уже сейчас больше пяти, а в дальнейшем их будет гораздо больше, то хотелось бы это автоматизировать. Для этого воспользовался AOP, а конкретно AspectJ. Был написан простой аспект, который добавлял подсчёт времени выполнения всех public методов из классов с пользовательскими операциями. Время подсчитывалось только успешно выполненных методов, что бы методы, вылетевшие с ошибкой на середине выполнения, не портили статистику. Так же обнаружился один недочёт при сборе статистики по названиям методов – так как методы по работе с пользовательскими операциями были универсальны и вызывались всеми тестами, но статистику нужно было собирать по типам документов. Поэтому статистика собиралась не только по названию методов, но ещё и по их аргументам, идентифицирующих тип документа.
Код метода аспекта
Метод getPointName формирует название точки среза времени на основе названия метода и его параметров.
Браузеры для нагрузочного тестирования
После написания всех тестов встал вопрос, на каких браузерах его запускать. В случае функционального тестирования здесь всё просто – нужно запускать тесты на тех браузерах, на которых будут работать пользователи. Для нас это IE 9. Поэтому попробовал запустить тесты на IE с несколькими экземплярами браузера на машину, что бы один компьютер смог эмулировать работу нескольких пользователей (В Selenium один WebDriver – это один экземпляр браузера). В результате на моей машине (4Гб ОЗУ, 2.3 Core 2 Duo) нормально работало только 4 экземпляра IE. Что не очень хорошо – для эмуляции двухсот пользователей потребуется 50 машин. Нужно было искать альтернативу. А это: а) другие desktop браузеры б) headless браузеры.
Из desktop браузеров протестированы были FF и Chrome. С Chrome ситуация была аналогичная, плюс он для своей работы требовал запуска в отдельном процессе WebDriver’а на каждый экземпляр Chrome. Что повышало требования к ресурсам. С FF ситуация была чуть лучше – нормально работало 5 браузеров без дополнительного запуска WebDriver’ов. Но ситуацию это не сильно улучшило.
Тогда бы пришлось тестировать headless браузеры – браузеры, которые полностью работают с сайтом (строят DOM, выполняют JS), но не отображают его. По идее они должны работать быстрее. Из всех headless браузеров остановился на 2 – PhantomJS и HttpUnit. Перспективно выглядел PhantomJS, основанный на Webkit. Но по факту он ни чем не отличался от FF по потреблению ресурсов, но имел следующие минусы – иногда не находил элементы на странице и не корректно отображал сайт на скриншотах. Так что не удавалось понять, почему произошла ошибка. С HtmlUnit всё гораздо проще – его webdriver не поддерживал alert, а это для нашего web приложения было критично.
В итоге вернулись к использованию FF в нагрузочном тестировании. Хотя в нём тоже возникли проблемы с alert’ами – иногда возникали ошибки java.lang.Boolean cannot be cast to java.lang.String (java.lang.ClassCastException) (вот ссылка на ошибку в Google Code code.google.com/p/selenium/issues/detail?id=3565). Исправить эту ошибку не получилось, но зато получилось отказаться совсем от alert’ов. Так что в дальнейшем можно попробовать опять использовать HtmlUnit. Хотя у всех headless браузеров есть одно общее неудобство, связанное с их спецификой, — они не отображают страницы и так просто нельзя понять, из-за чего произошла ошибка. Возможность снятия скриншота не сильно помогает – иногда он не информативен.
Конфигурация Selenium’а
Сервер Selenium’а поддерживает запуск в двух режимах – как standalone сервер (режим запуска по умолчанию) и как часть общей сети из Selenium серверов – Selenium Grid (режимы запуска с –role hub и –role node). Так как нам нужно было использовать большое количество компьютеров, то первый режим не очень подходит – в этом случае нужно будет управлять каждым сервером в отдельности. Т.е., по сути, писать свой менеджер серверов. Хотя, по началу, мне это вариант импонировал – в таком случае у нас будет полный контроль над тем, на какой машине какой браузер запускать. Но в дальнейшем я от него отказался – полный контроль над запуском браузеров оказался не нужен, плюс Selenium Grid подкупил своей простотой в использовании. (ссылка на страницу конфигурации Selenium Grid code.google.com/p/selenium/wiki/Grid2)
В итоге пришли к следующей конфигурации: На одном компьютере запускался Selenium в режиме hub с дополнительным параметром –timeout 0. Это нужно было потому, что иногда сессии закрывались по timeout из за длительного бездействия тестов. На других компьютерах запускался Selenium в режиме node. Для мощных компьютеров, способных обеспечить работу 15 браузеров, node Selenium’а запускался с дополнительной настройкой, позволяющей запускать 15 копий FF и указывающей, что одновременно можно работать с 15 сессиями.
Проведение тестов
Тесты проводились следующим образом – на одном компьютере запускался один экземпляр браузера, который выполнял тестовые сценарии несколько раз и с которого снимали время выполнения. На остальных компьютерах запускались те же тестовые сценарии, но уже на нескольких браузерах. Такое разделение для замера времени нужно для того, что бы одновременная работа браузеров не отражалась на результате измерения. Так как если делать те же измерения на нескольких запущенных браузерах, то время будет чуть больше.
Пару слов нужно сказать о тестовых сценариях и подсчёте времени их выполнения. Каждый сценарий включал в себя открытие документов каждого типа. Т.е. сначала открывался входящий документ, потом исходящий документа и т.д. Вот здесь нужно учесть следующую ситуацию – если нужно снять время открытия только входящего документа, и при этом запустить на всех машинах выполнения только это сценария, то время будет существенно меньше (на 50%) чем, если бы снимать время при одновременном выполнении всех сценариев. В моём случае, скорее всего это было связано с кешированием на уровнях web приложения и СУБД. И тем, что открывалось мало уникальных документов. Возможно, при большом количестве разных документов различия будут не столь существенны.
В идеале хотелось бы получить распределение пользователей и документов таким, каким оно будет в реально работающей системе. Т.е., например, в реальной системе будет 10 человек работать с входящими и 30 с исходящими. И в нагрузочном тесте так же отразить это соотношение – количество тестов по исходящим в три раза больше чем с входящими документами. Но так как ещё тестируемая система пока не вошла в эксплуатацию и этих данных пока нет, то тестирования происходило без их учёта.
Подведение итогов
В результате тестов для 1-го, 16-ти, 26-ти и 70 пользователей был составлен график по каждым сценариям. Пока ещё количество пользователей не слишком большое, что бы сделать точные выводы, но уже сейчас можно проследить темпы роста времени.
Зависимость времени открытия документов от количества работающих пользователей:
Зависимость времени списка документов от количества работающих пользователей:
Дальше тесты будут продолжаться, что бы построить график до 200 пользователей. В результате должен получиться график, похожий на этот (взят из msdn.microsoft.com/en-us/library/bb924375.aspx):
По нему уже можно будет точно определить возможности системы и найти её узкие места.