тестирование web приложений selenium
Интеграционное тестирование web-приложения с Selenium WebDriver
Интеграционное тестирование (в отличие от Unit- или модульного тестирования) это тестирование не отдельных атомарных компонентов системы (классов) а результата их взаимодействия между собой в какой-либо среде.
Волею судеб я занимаюсь разработкой своего рода интерфейсного фреймворка заточенного на определенные корпоративные нужды. Среда исполнения фреймворка — браузер, а по сему язык — JavaScript.
О том, как можно Unit-тестировать JavaScript я писал ранее, сейчас же расскажу о процессе интеграционного тестирования, применяемого в команде.
Selenium
WebDriver
Selenium WebDriver это набор «биндингов» к разным языкам (C#, Java), позволяющий отдавать различные команды «подчиненному» браузеру.
Для каждого браузера имеется своя реализация WebDriver (FireFoxDriver, InternetExplorerDriver, ChromeDriver — сейчас включены в поставку, OperaSoftware разработали OperaDriver). Существует также «виртуальный» HtmlUnitDriver. В отличии от «браузерных» реализаций он не требует установленного браузера и за счет этого работает быстрее и платформонезависим, но есть и минусы — HtmlUnitDriver имеет «свою» реализацию JavaScript и потому поведение «богатых» веб-приложений может в нем отличаться. Для своих задач мы используем «браузерные» реализации, это позволяет проверить приложение именно в той среде, в которой оно будет исполняться впоследствии.
Что умеет WebDriver
Среда исполнения тестов
В качестве языка для написания тестов была выбрана Java. Среда для исполнения — JUnit4.
DISCLAIMER: Не претендую на звание крутого джависта, посему если старшие коллеги найдут огрехи и всякие прочие «антипаттерны» — с удовольствием выслушаю в комментариях.
Базовый абстрактный класс веб-тестов.
Конкретный класс с набором тестов (для простоты убраны некоторые проверки, например на то, что элемент по CSS-селектору действительно найден и доступен на странице)
Все тесты запускаются с помощью отдельного таска Ant-билда:
Данный таск прогонит все известные тесты из классов, чьи имена начинаются с Test под браузерами Firefox и InternetExplorer. В зависимостях таски с базовой инициализацией, компиляцией и выгрузкой скомпилированных тестов на тестовую площадку.
Фишки-плюшки
Некоторые «браузерные» реализации (Firefox, Opera, Chrome) поддерживают снятие скриншотов. Это может быть полезно дабы зафиксировать визуальное состояние, в котором пребывала тестовая страница в момент, когда тест не прошел. Для этого подойдет функционал JUnit4 — TestWatchman.
Добавим переменную с путем к папке со скриншотами в Ant-билд
Интеграция
В текущей реализации Ant-билд гоняется через Jetbrains TeamCity. Запуск билда настроен на сброс кода в SVN. Интеграционные тесты — часть общей процедуры тестирования. При провале любого из интеграционных тестов снимается скриншот и публикуется как «артефакт» билда — можно видеть не только какие тесты «отъехали» после сброса в транк какого-либо функционала, но и увидеть «как» они «отъехали».
В настоящее время используется тестирование под IE и Firefox, Chrome не подключен по причине некоторых трудностей с интеграцией (судя по всему в ChromeDriver присутствуют некоторые ошибки, не позволяющие нормально искать элементы на странице в некоторых случаях — по состоянию на 2.0b1, сейчас доступна 2.0b2 но работу с ней пока не пробовали)
DevPoint: Selenium в тестировании веб-приложений
С такими ситуациями очень часто сталкивался и меня это не устраивало. При поиске подходящего метода/инструмента тестирования я наткнулся на Selenium. И применяю его уже более 3-х лет.
В Киеве 9-го апреля прошла конференция DevPoint, посвященная web — разработке. Организатором данного мероприятия была компания Uniweb. В рамках ее, решил поделиться впечатлением про Selenium.
Selenium состоит из множества подпроектов, но выделить хотел только три:
Selenium Core — JavaScript Framework для написание и выполнения тестов. Используется в Selenium IDE и Remote Control*.
Selenium IDE — плагин для Firefox, который позволяет записывать и воспроизводить тесты. Также может генерировать код тестов для использования в Selenium Remote Control.
Selenium Remote Control — клиент-серверная система, которая позволяет Вам управлять веб-браузерами локально, или на других компьютерах, используя практически любой язык программирования
В рамках этого доклада про Selenium Core не было времени акцентировать внимание, хотя этот проект наиболее интересен для написания тестов с нетривиальной логикой.
Selenium IDE
Применяем Selenium IDE на практике
Для примера взял живой старый проект, который покрыть тестами задача еще та. Это обычный интернет-магазин, который используется для внутренних оптовых закупок в одной компании, имен не называем…
Первый тест, который мы напишем будет просто авторизоваться в системе:
И последних два теста, которые покрывают логику создания и редактирования заказа:
И для проверки наших тестов было намерено испорчено сохранение заказа:
Selenium Remote Control
Selenium Remote Control — это http демон, который принимает команды через GET и выполняет их. API по общению с Selenium RC есть почти под все языки программирования. В данном докладе речь идет только про API для PHP, которое предоставляется c PHPUnit
Как уже говорилось ранние в Selenium IDE есть приятная опция по генерированию кода для *Unit:
Таким образом вы можете просто копировать код и выполнять его в своих PHPUnit suite.
Также в PHPUnit — Selenium есть возможность запускать тесты написанные в Selenium IDE:
Без напильника не обойтись…
Для решения проблемы с выполнением команд wait* нужно рассмотреть как они выполняются в PHPUnit:
Фактически мы зацикливаем выполнение команды, на определенный интервал и ждем пока наше условие не станет true. Реализация PHPUnit — Selenium посылая команду Selenium RC ждет от нее только два ответа, что все хорошо или что все плохо. Если пришел ответ ERROR, то он сразу закрывает браузер, пишет что произошла ошибка и соответственно наш цикл будет слать команды в уже закрытую сессию Selenium RC.
Код с решением этих проблем я выложил на github и не буду на нем останавливаться.
Еще из приятных вещей в Selenium RC то, что он умеет делать скриншоты при обнаружении ошибки:
Минус в том, что на скриншотах не подсвечивается место возникновения ошибки, но по тексту в PHPUnit обычно легко понять что не так.
Дергаем за ниточки не FireFox
Селениум: тестирование веб-приложений и другие полезные функции
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 — это эффективный набор инструментов для автоматизации тестирования.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Автоматизированное тестирование веб-приложения (MS Unit Testing Framework + Selenium WebDriver C#). Часть 2.2: Selenium API wrapper — WebElement
Введение
Ссылки
Вперед!
И так, я начал думать, как мне, как разработчику автотестов, было бы удобно описывать web-элементы. Первую проблему некоторые разработчики решают написанием getter’ов, выглядит это вот так:
Если уникальных свойств нет, то придется искать по набору свойств, воспользовавшись FindElements, а затем отсеивать с помощью GetAttribute и GetCssValue.
В WebDriver.Support есть такая фича, как PageFactory и атрибут FindsBy:
Идея и примеры использования
Основная идея заключается в том, чтобы при описании элемента заполнять критерии поиска, а сам поиск элемента выполнять при любых действиях с ним. Кроме того хочется реализовать кэширование результатов поиска для оптимальной работы тестов.
Также было бы весьма удобно описывать элементы в одну строчку, но не создавать и передавать массивы свойств. И тут как нельзя кстати приходится паттерн «цепочка вызовов» (call chain). Еще необходимо иметь возможность искать элементы по вхождению параметров.
Ну а для полного счастья необходимо реализовать групповые методы над элементами в стиле Linq, например, чтобы можно было проставить все чекбоксы по какому-либо критерию или получить массив строк из массива ссылок.
Попробую изобразить схему WebElement:
Замечу, что все равно при тестировании сложного приложения вы можете столкнуться с ситуациями, когда элемент не получается распознать с помощью Selenium WebDriver. Для решения этой проблемы предусмотрен метод Browser.ExecuteJavaScript (см. предыдущую статью), т.е. есть возможность работать с элементами через JavaScript и JQuery.
Перед тем, как переходить к коду wrapper’а, я покажу примеры описания:
Поиск последнего элемента по классу:
Поиск по вхождению значения в атрибут:
Поиск по нескольким параметрам:
Поиск по тэгу и по тексту (вхождению):
Заметьте, что в TestElement не обязательно хранится описание для одного элемента. Если элементов несколько, то при попытке кликнуть должно возникнуть исключение (но у меня в реализации будет использован первый попавшийся элемент). Так же мы имеем возможность указать индекс элемента, используя Index(. ), либо First() или Last(), чтобы гарантированно нашелся один элемент. Кроме того, не обязательно выполнять действие с одним элементом, можно выполнять его со всеми элементами сразу (см. ForEach в примерах ниже).
А теперь приведу примеры использования:
Клик по элементу с помощью Selenium WebDriver или с помощью JQuery:
Получение текста (например ссылки или текстового поля):
Перетаскивание элемента на другой элемент:
Отправка события элементу:
Разворачивание всех свернутых элементов (клик по плюсикам):
Получение значения всех заголовков:
Примененный паттерн call chain позволяет одновременно определять элемент и выполнять действие:
Для конечного пользователя (разработчика автотестов, который будет описывать элементы страниц) выглядит весьма дружелюбно, не так ли? Ничего не торчит наружу. Обратите внимание, что мы даже не разрешаем разработчику передавать в качестве параметров произвольные атрибуты и названия тэгов, используя для этого enum TagAttributes и TagNames. Это избавит код от многочисленных magic strings.
WebElement.cs
Тут основное внимание стоит обратить на FindIWebElements, FindSingleIWebElement и обработку исключений в TryFindSingle. В FindIWebElements мы дожидаемся, пока браузер завершит все свои дела (WaitReadyState и WaitAjax), производим поиск элементов (FindElements), а затем фильтруем их по различным критериям. Также в коде фигурирует _searchCache, это как раз наш кэш (автоматически поиск не кэшируется, у элемента нужно вызвать метод CacheSearchResult).
WebElementActions.cs
Плоский список свойств и методов, определенных для элементов. Некоторые принимают параметр useJQuery, который указывает методу, что действие стоит производить с помощью JQuery (сделано для сложных случаев и возможности совершить действие во всех трех браузерах). Кроме того выполнение JavaScript работает намного быстрее. В некоторых методах располагаются «костыли», например цикл с tryCount в SetCheck. Конечно, для каждого тестируемого продукта будут свои special cases.
WebElementByCriteria.cs
Большинство функций публичные, с их помощью разработчики будут описывать элементы в своих тестах. Почти для всех критериев предусмотрена возможность искать по вхождению (exactMatch). Как видно, в конечном случае все сводится к XPath (и я не исключаю, что XPath работает немного медленнее обычного поиска, но лично я этого не заметил).
WebElementExceptions.cs
Ну тут просто одно кастомное исключение.
WebElementFilters.cs
Фильтры, которые вызываются в FindIWebElements (файл WebElement.cs) для отсеивания элементов. Замечу только то, что с большими наборами данных Linq работает значительно дольше, чем for и foreach, поэтому, возможно, имеет смысл переписать этот код с использованием классических циклов.
Заключение
Буду раз увидеть в ЛС ошибки, допущенные в статье, а так же любые вопросы в комментариях.
Автоматизированное тестирование веб-приложения (MS Unit Testing Framework + Selenium WebDriver C#). Часть 1: Введение
Введение
Ссылки
Поехали
Итак, первым делом необходимо отобрать некоторое количество тестовых сценариев высокого приоритета, но довольно простых.
Далее создадим в студии новый solution. Вполне логично будет создать в нем 3 проекта: тесты, описание страниц и утилиты. Это и будут наши три базовые сущности.
Схема будет довольно простая: тест работает со страницами, запрашивая на них какие-либо данные или выполняя там какие-либо действия. В утилитах мы разместим классы, которые будут отвечать за работу c браузером и web-элементами на страницах посредством Selenium WebDriver. Вполне логично написать обертки (wrapper), поскольку Selenium WebDriver API имеет множество недостатков и может показаться довольно неудобным. Именно в этих обертках мы инкапсулируем (спрячем) весь специфический и некрасивый код. Для примера, создадим классы Browser и WebElement, которые предоставят разработчикам автотестов только тот футкционал, который им нужен. В дальнейшем я хотел бы описать этот процесс в отдельной статье, поэтому не буду останавливаться.
Тесты
Описание web-страниц тестируемого продукта
Что же будут представлять из себя описания страниц?
Во-первых, это описания элементов, с которыми мы будем работать, т.е. способ распознавания их по id, классу, имени, xpath и др. Не надо описывать сразу все имеющиеся на странице элементы, это нерациональная трата времени. При этом все эти описания должны быть приватными и не выходить за рамки класса страницы.
Во вторых, страница будет содержать свойства (getters) и методы, с помощью которых тесты смогут получить информацию со страницы, например значение какого-нибудь текстового поля.
И в третьих, страница будет содержать методы для совершения действий на самой странице, например клик по кнопке. Важно отметить, что описание страницы не должно содержать никакой логики и никаких проверок! Проверки должны быть в тестах. И в то же время, здесь не должно быть никаких вызовов Selenium WebDriver API.
Утилиты
В данном проекте, как минимум, будут находится обертки над Selenium WebDriver API. В последствии это место станет скоплением всевозможных helper’ов, утилит, расширений и т.д. до их вынесения в отдельные сущности и проекты.
Заключение и пример
Таким образом, нужно четко разграничить логику наших автотестов, для этого мы и создали три отдельных проекта. Я не исключаю, что в процессе развития проекта появятся и другие логические уровни со своими сущностями, но минимум будет такой.
Далее я покажу один простой пример и на этом закончу статью. Если она окажется интересной, я обязательно напишу продолжение, где опишу детали реализации тестов, страниц и оберток над WebDriver API.