В большинстве случаев одни и те же тесты можно запускать на разных браузерах
Я потратил довольно много времени на то, чтобы понять, как настроить сетку selenium. Поэтому я решил изложить то, что узнал, в письменном виде. В этой статье я расскажу о некоторых шагах по настройке selenium grid. Вам не нужно быть экспертом по селену…
Автор оригинала: Olawale Aladeusi.
Я потратил довольно много времени на то, чтобы понять, как настроить сетку selenium. Поэтому я решил изложить то, что узнал, в письменном виде. В этой статье я расскажу о некоторых шагах по настройке selenium grid. Вам не нужно быть экспертом по селену, чтобы понять эту статью, единственное, что вам нужно знать, это как написать базовый код JAVA.
Прежде чем мы начнем, давайте обсудим некоторые основные концепции
Что такое селен?
selenium – Проще говоря, selenium автоматизирует браузеры, и вы можете использовать эту возможность для автоматического взаимодействия с браузером в целях тестирования. Читайте больше здесь
Что такое Селеновая сетка?
Selenium-Grid позволяет вам запускать тесты на разных компьютерах в разных браузерах параллельно(в одно и то же время). То есть одновременное выполнение нескольких тестов на разных машинах с разными браузерами и операционными системами. Селеновая сетка поддерживает распределенное выполнение тестов. Подробнее читайте здесь . Selenium Grid использует концепцию узла-концентратора, в которой вы запускаете тест только на одной машине, называемой концентратором, но выполнение будет выполняться разными машинами, называемыми узлами.
Что такое концентратор и узел сети Selenium?
Что такое веб-драйвер Selenium?
Selenium Webdriver – WebDriver-это инструмент для автоматизации тестирования веб-приложений и, в частности, для проверки того, что они работают должным образом. Он направлен на предоставление удобного API, который легко изучить и понять. Webdriver предоставляет API-интерфейсы, необходимые для автоматического взаимодействия с браузерами так же, как обычный пользователь использовал бы браузер. Selenium webdriver поддерживает множество браузеров, таких как Chrome, Firefox, IE, EDGE и Safari. Подробнее здесь .
Что такое тестирование?
Тестирование Тестирование-это платформа тестирования, вдохновленная JUnit и NUnit, но представляющая некоторые новые функции, которые делают ее более мощной и простой в использовании. Он предназначен для охвата всех категорий тестов. Читайте больше здесь
Что такое Apache Maven?
Apache Maven – Apache Maven-это инструмент для управления проектами и понимания программного обеспечения. Основываясь на концепции объектной модели проекта ( POM ), Maven может управлять сборкой проекта, отчетностью и документацией из центральной части информации. Читайте больше здесь
Теперь, когда у нас есть базовое понимание некоторых важных концепций , давайте начнем с того, для чего мы здесь, а именно с настройки сетки Selenium.
Зависимости
Прежде чем вы сможете завершить эту статью, в вашей системе должно быть установлено следующее
-
– Это необходимо для запуска концентратора selenium grid
- Настройте виртуальную машину windows в своей системе – для целей этой статьи я буду использовать VMware Fusion , вы можете использовать любое другое приложение для виртуальных машин в зависимости от ваших предпочтений. Кроме того, убедитесь, что на нем установлена windows 7 или любая другая ОС – это потребуется для запуска нашего узла. Вам не нужно использовать локальную виртуальную машину, если у вас есть какая-либо удаленная машина с операционной системой. Установите браузеры chrome и firefox на виртуальную ОС. Для целей этого урока я буду использовать VMware Fusion с установленным на нем окном 7. – Установите maven в вашей системе.
- IDE – вы можете использовать любую Java IDE, для целей этой статьи я буду использовать IntelliJ IDEA – это бесплатная версия для сообщества
Выполните следующие действия на своем терминале, чтобы проверить, установлена ли в вашей системе среда выполнения Java и Maven
Результат должен быть похож на этот
Установив все зависимости, давайте начнем с настройки и запуска концентратора и узла selenium grid.
Настройка концентратора Selenium Grid
Нам нужно настроить концентратор Selenium Grid на тестовой машине( Машина A ) – на машине, на которой выходит код тестов.
ШАГ 1 Загрузите автономный сервер selenium и поместите его в любой каталог на тестовой машине, позвольте позвонить на нашу тестовую машину Машина А . Нажмите здесь , чтобы загрузить последнюю версию selenium standalone server. Автономный сервер Selenium-это единственное, что нам нужно для запуска нашего хаба.
Прежде чем продолжить, запишите IP-адрес вашей тестовой машины(машина A). Если вы используете систему mac, вы можете использовать следующую команду для проверки своего IP-адреса
и если вы используете оконную систему, выполните следующую команду в командной строке, чтобы получить свой IP-адрес
вы должны увидеть свой IP-адрес в результате выполнения вышеуказанных команд. Сохраните где-нибудь IP-адрес, он нам понадобится на следующем шаге
ШАГ 2 Теперь давайте запустим наш хаб . Откройте терминал или командную строку, если вы используете ОС windows, и измените каталог, в котором вы сохранили автономный сервер selenium, загруженный в ШАГ 1 .
Затем выполните следующую команду
- Замените именем вашего автономного сервера selenium – обычно оно в этом формате Замените именем вашего автономного сервера selenium - обычно оно в этом формате (это для версии 3.5.0). Если вы не запускаете команду из каталога, в котором вы сохранили автономный сервер selenium, замените
- путем к файлу selenium Заменить
- > с вашим IP-адресом. Вспомнил, я просил вас сохранить IP-адрес где-нибудь на ШАГЕ 1, у вас тот же IP здесь. Мы сообщаем автономному серверу selenium, что это наш концентратор , передавая концентратор в команду
После выполнения команды вы должны увидеть что-то похожее на приведенное ниже
Чтобы проверить, работает ли концентратор – Откройте браузер и перейдите к localhost:4444/сетка/консоль Если все прошло хорошо, вы должны это увидеть
-
– сервер selenium jar – Реализация веб-драйвера Chrome, которая управляет браузером Chrome, запущенным на локальном компьютере. – Драйвер Gecko-это реализация WebDriver, которая управляет браузером gecko, таким как firefox, работающим на локальном компьютере. – InternetExplorerDriver-это автономный сервер, который реализует проводной протокол WebDriver, управляющий браузером IE на локальном компьютере
Примечание: вы можете выбрать любой из вышеперечисленных драйверов в зависимости от того, в каком браузере вы хотите выполнить тест.
Когда вы закончите загрузку драйверов, если ваша вторая машина работает под управлением ОС windows, вы можете создать папку selenium на диске C и поместить в нее все драйверы.
Откройте командную строку или терминал, в зависимости от обстоятельств, на машине B и выполните следующие команды, чтобы запустить узел
Примечание: ШАГ 3 должен быть выполнен на виртуальной машине или на второй машине, если вы не используете виртуальную машину.
Если все прошло хорошо, после выполнения приведенной выше команды вы должны увидеть что-то похожее на изображение ниже
Вы должны увидеть что-то похожее на описанное выше, если все прошло хорошо. Заметил, что консоль показывает три браузера – chrome, ie11 и firefox, это потому, что мы говорим узлу использовать эти браузеры в команде, которую мы запустили, чтобы запустить узел.
Теперь, когда наш концентратор и узел запущены, давайте напишем простой тестовый сценарий, который будет выполняться параллельно в нескольких браузерах.
Что мы собираемся проверить?
Тестовые Зависимости
- ИДЕЯ – я буду использовать ИДЕЯ Intellij для целей этого урока
- Maven
- JAVA Тест будет написан с использованием языка программирования JAVA, не волнуйтесь, вам не нужно быть экспертом в JAVA – вам нужно только базовое понимание синтаксиса JAVA.
Создание Тестового Проекта На IntelliJ
- Запуск ИДЕИ IntelliJ
- Нажмите на файл, выберите Создать и нажмите на проект
- В диалоговом окне “Новый проект” выберите Maven и нажмите кнопку “Далее”.
- Введите идентификатор группы, идентификатор артефакта и нажмите кнопку Далее
- укажите название проекта и нажмите кнопку готово Когда это будет сделано, вы должны увидеть что-то похожее на изображение ниже
Теперь давайте добавим в проект следующие плагины
-
– Плагин Surefire используется на этапе тестирования жизненного цикла сборки для выполнения модульных тестов приложения. Он также нужен нам для создания отчета для наших тестов результат – Плагин компилятора используется для компиляции исходных текстов вашего проекта.
- селен
- Тестирование
Добавить плагины в проект Добавить следующий код в проект pom.xml (файл находится в корневом каталоге проекта) файл;
Затем создайте новый пакет в /src/main/java/ и назовите его base (внутри этого пакета мы создадим класс, который настроит наш тестовый драйвер). Когда вы закончите, создайте класс java внутри базового пакета и назовите его Драйвер настройки . Добавьте следующий код в SetupTestDriver класс
- Мы создали SetupTestDriver с помощью конструктора, который принимает в качестве аргументов ОС, браузер, базовый файл и узел . os – это название платформы, на которой мы хотим запустить тест, selenium поддерживает довольно много платформ, включая WINDOWS, LINUX, MAC и многое другое. браузер – это имя браузера, в котором мы хотим выполнить наш тест-это может быть chrome, firefox, ie11 или любые другие браузеры, которые мы настроили на нашем узле. baseUrl baseUrl указывает начальную точку URL-адреса вашего теста. узел
- узел-это URL-адрес вашей заметки, наш тест будет использовать его, чтобы узнать, на каком узле запустить тест. Затем мы настроим тестовую платформу с использованием selenium Платформа класс. Platform.fromString(os.прописные буквы()) мы создали новый экземпляр Платформы и мы использовали его метод fromString
- для передачи в нашей операционной системе. Затем мы добавили условие для проверки имени браузера, переданного конструктору класса SetupTestDriver , это поможет узнать, что параметры браузера класс мы должны использовать. Если имя браузера chrome , , мы создали новый экземпляр Опции Chrome класса и передали платформу в качестве одной из его возможностей, то же самое касается fireforx с использованием Параметры Firefox и IE11 использование Параметров Internet Explorer . Примечание – настройка возможностей браузера дает возможность настроить браузер с некоторыми возможностями, необходимыми для нашего теста, эти возможности могут включать добавление некоторого расширения браузера например,
- adobe flash плагин и отключение некоторых параметров безопасности браузера, которые могут повлиять на наш тест. Затем мы создали новый экземпляр класса selenium RemoteWebDriver
- , передав URL-адрес узла с опцией “Возможности браузера”. новый удаленный веб-драйвер(новый URL-адрес(узел + “/wd/концентратор”), т. е. опция); мы добавили получает , getBrowser , getBaseUrl , getNode
Теперь, когда у нас есть SetupTestDriver класс полностью настроен, давайте создадим простой тест java для проверки окна поиска Google.
создайте новый тестовый класс в src/test/java , мы можем назвать его Тест поиска Google
Добавьте в класс следующий код
- Мы прикрепили @BeforeClass декоратор к настройке методу – @BeforeClass является декоратором тестирования, который указывает testng сначала запустить определенный метод, прежде чем запускать другие тесты в классе. В нашем случае метод setUp будет запущен первым перед любым другим методом. мы также прикрепили @AfterClass декоратор к методу closeBrowser – этот декоратор сообщает testng о запуске этого метода в конце выполнения других тестов в классе, он будет запущен после завершения теста в классе.
- Мы также прикрепили @Parameters декоратор к методу настройки , нам нужно, чтобы этот декоратор мог передавать параметры в тестовый класс. В нашем случае мы будем передавать ОС, браузер, URL и узел в наш тест.
- В методе setUp мы создали новый экземпляр класса SetupTestDriver , передав необходимые параметры его конструктору.
- тест на заголовок Google , тест Url-адреса google , Тест кнопки поиска Google , тест кнопки Google На чувство Удачи и Окно поиска Google являются нашими методами тестирования, и мы прикрепили к ним @Test декоратор, чтобы сообщить testng , что эти методы являются тестами.
- Наконец, мы добавили некоторые утверждения в наши методы тестирования для проверки кнопки поиска Google, и я чувствую, что кнопка “Мне повезло” отображается и включена на странице, а также два других утверждения для проверки значения заголовка страницы и текущего URL-адреса страницы.
Далее, давайте настроим наш файл запуска – мы будем использовать этот файл при запуске теста
Создайте новый пакет ресурсов в src/test/ , назовем его ресурсы. Создайте новый пакет внутри ресурсы , назовем его пусковые установки - в нем будут размещены наши файлы пусковых установок тестов. Создайте другой файл google.xml внутри пакета пусковых установок.
Добавьте следующее в google.xml
- Мы добавили новый набор тестов с метка и мы указали, что все должны выполняться параллельно с parallel="тесты" – это приведет к запуску всех методов в теге в одном потоке, но каждый теге будет в отдельном потоке.- Подробнее здесь .
- Мы также добавили три отдельных , каждый с разными параметрами браузера |/- |/ie11 , хром и firefox . Это позволит нашему тесту выполняться параллельно с разными браузерами. Остальные три параметра были переданы через наборы тестов, так как эти три являются одинаковыми, в отличие от браузера, который отличается.
Бежать
Чтобы запустить тест, откройте google.xml и щелкните по нему правой кнопкой мыши, затем выберите Бежать
Это запустит тест, и если все будет работать нормально – тест должен быть запущен на МАШИНЕ B с использованием браузеров chrome, ie11 и firefox .
В этой статье мы рассмотрим кросс-браузерное тестирование. Это тип тестирования, который проверяет, работает ли приложение так, как ожидается, в нескольких браузерах, операционных системах и устройствах. Мы можем проводить кросс-браузерное тестирование с помощью автоматизации и без нее. Сценарии автоматизированного тестирования могут быть написаны или созданы с помощью таких программ, как TestProject и Selenium.
Примечание: Код из этой статьи находится на GitHub здесь.
Что такое кросс-браузерное тестирование?
Кросс-браузерное тестирование гарантирует, что наше тестируемое приложение (AUT) совместимо с каждым браузером, операционной системой и устройством. Цель заключается в сравнении ожидаемого поведения приложения в различных случаях. Бывают случаи, когда один и тот же тестовый сценарий проходит на одном или нескольких экземплярах, но не работает на другом экземпляре.
Возможно, сбой произошел из-за нашего тестового скрипта или приложения. Вы когда-нибудь пытались открыть веб-сайт с помощью Internet Explorer, но он не работал, а затем тот же сайт без проблем открывался в Chrome? Такие проблемы выявляются во время кросс-браузерного тестирования, поскольку данные из AUT отображаются по-разному в каждом браузере.
Преимущества кросс-браузерного тестирования
Мы проводим кросс-браузерное тестирование, устанавливая базовую линию. Базовая линия - это стандартный сценарий тестирования. Его цель - изучить, как работает наш AUT, используя один браузер, одну операционную систему и одно устройство. После этого мы можем использовать базовую линию в других комбинациях браузеров, операционных систем и устройств.
Я сосредоточусь на двух преимуществах кросс-браузерного тестирования:
Время
Создание и выполнение индивидуального сценария тестирования (Test Script) для уникальных сценариев занимает много времени. Поэтому наши тестовые сценарии создаются с тестовыми данными для использования их комбинаций. Один и тот же сценарий тестирования может выполняться на Chrome и Windows для первой итерации, затем на Firefox и Mac для второй итерации, а затем на других сценариях для последующих итераций.
Это экономит время, поскольку мы создаем только один тестовый сценарий, а не несколько. Ниже приведены 2 фрагмента кода для загрузки и получения заголовка для страницы TestProject. Один пример - это кросс-браузерное тестирование, а другой пример содержит отдельные тестовые сценарии для трех браузеров (Chrome, Firefox и Edge).
Тестовое покрытие
Тестовое покрытие - это техника, которая определяет, что и в каком объеме покрывается в наших тестовых сценариях.
Мы определяем особенности и убеждаемся, что для этих особенностей есть адекватные тестовые сценарии. Тестовое покрытие - это преимущество, поскольку оно позволяет нам измерить качество наших тестовых циклов.
Что будет включено в наши сценарии тестирования, зависит от требований.
То, сколько охвачено в наших сценариях тестирования, зависит от браузеров и их различных версий.
Тестовое покрытие является эффективным мерилом для процесса тестирования. Однако 100% покрытие трудно обеспечить, и, скорее всего, функция ведет себя не так, как это обычно происходит в конкретной версии.
Как осуществить кросс-браузерное тестирование в Selenium?
Мы осуществляем кросс-браузерное тестирование в Selenium, используя его сетку (grid) или тестовые данные. Selenium Grid упрощает процесс, а тестовые данные используются в качестве исходных. С помощью Selenium Grid наши тестовые сценарии выполняются параллельно на нескольких удаленных устройствах. Команды отправляются клиентом удаленным экземплярам браузера.
Тестовые данные могут храниться в файле Excel, CSV, файле свойств, XML или базе данных. Мы также можем объединить TestNG с тестовыми данными для проведения тестирования на основе данных или кросс-браузерного тестирования. Для тестирования на основе данных аннотация DataProvider и атрибут dataProvider или атрибут dataProviderClass позволяют нашему тестовому сценарию получать неограниченное количество значений.
Когда речь идет о кросс-браузерном тестировании, мы можем использовать тег параметра и аннотацию Parameters для передачи различных имен браузеров. Ниже приведены фрагменты кода, отображающие XML-файл с тегом параметра и тестовый сценарий с аннотацией Parameters.
В XML-файле тег параметра расположен на уровне теста. У нас есть возможность разместить тег на уровне тестового набора, на уровне теста или на обоих уровнях. Обратите внимание, что тег параметра имеет имя и значение с данными между двойными кавычками. Его имя, т.е. "BrowserType", передается тестовому сценарию через аннотацию @Parameters, а значение, т.е. "Chrome", передается в операторы if и else if.
Операторы if и else if устанавливают Chrome, Edge или Firefox. Каждый браузер получал команды от одного и того же тестового сценария после выполнения из XML-файла. Следующие результаты тестирования показывают, как успешно загружается страница TestProject, а консоль печатает уникальное имя браузера и заголовок страницы.
Кросс-браузерное тестирование в Selenium с помощью TestProject
OpenSDK / Закодированный тест
AI-Powered Test Recorder
С помощью AI-Powered Test Recorder мы создаем новое веб-задание, затем выбираем несколько браузеров, таких как Chrome, Edge и Firefox. Тест в задании TestProject позволяет нам выбрать дополнительный источник данных CSV, если мы хотим выполнить тестирование на основе данных. Вот несколько скриншотов, показывающих шаги по выполнению кросс-браузерного тестирования и отчета.
Вот пошаговая демонстрация кросс-браузерного тестирования с помощью TestProject AI-Powered Test Recorder.
Выводы
Подводя итоги, кросс-браузерное тестирование - это отличный способ использовать один сценарий тестирования и несколько браузеров одновременно. Некоторые из преимуществ включают время и тестовое покрытие. Время является нашим преимуществом, поскольку мы не создаем несколько тестовых сценариев для каждого браузера. Тестовое покрытие - это еще одно преимущество, поскольку мы можем тестировать не только версию браузера для конкретного браузера.
Кросс-браузерное тестирование осуществляется с помощью Selenium и TestProject.
Перевод статьи подготовлен в рамках курса "Java QA Engineer. Basic". Всех желающих приглашаем на двухдневный онлайн-интенсив «Теория тестирования и практика в системах TestIT и Jira». На интенсиве мы узнаем, что такое тестирование и откуда оно появилось, кто такой тестировщик и что он делает. Изучим модели разработки ПО, жизненный цикл тестирования, чек листы и тест-кейсы, а также дефекты. На втором занятии познакомимся с одним из главных трекеров задач и дефектов — Jira, а также попрактикуемся в TestIT — отечественной разработке для решения задач по тестированию и обеспечению качества ПО.
В это статье я расскажу о применении инструмента изначально предназначенного для функционального тестирования при тестировании нагрузочном web части системы электронного документооборота (СЭД).
Зачем вообще это понадобилось? Мы преследовал две цели – введение автоматических тестов для наших web-приложений и создание нагрузочных тестов на основе функциональных тестов.
Почему для теста использовался именно Selenium, а не более подходящий инструмент – LoadRunner, jMeter? С помощью LoadRunner’s нагрузочный тест был проведён, но результаты были поставлены под сомнения – при эмуляции двухсот пользователей страницы загружалась за 2 секунды плюс-минус 2%, хотя при открытии этих же страниц из браузера отображение происходило более чем за 3 секунды. Так что хотелось провести нагрузочные тесты максимально приближенные к реальности, а это можно сделать только с помощью полной эмуляции поведения пользователя. Для этого как раз подходили инструменты для функционального тестирования с их работой с браузерами – сайт открывался бы через обычный браузер, т.е. так как делал бы это пользователь.
Про Selenium
Общая архитектура
Приложение разделено на уровни (для наглядности на схеме элементы каждого уровня имеют осмысленные названия, а не просто Тест 1, Методы 2).
Первый уровень – уровень «запускальщика» тестов. Он просто запускает тесты. В настройках конфигурируется количество потоков, количество запусков теста, классы теста.
Второй уровень – сами тесты. Они выполняют бизнес операции – авторизируются, открывают списки документов, открывают документа, переходят по вкладкам документов.
Третий уровень – уровень работы с web-элементами. В нём содержаться атомарные пользовательские операции по работе с системой – открытие списка документов, переход к определённому документу, работа с вкладками документа.
Для начала перечисленных действий будет достаточно для обеспечения минимальной работы с системой. В дальнейшем они будут добавляться.
Запуск тестов
Программа для запуска 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.
Сбор статистики
Сбор статистики происходил из двух мест – собиралось общее время выполнение тестовых методов (из уровня «запускальщика») и время выполнения атомарных пользовательских операций (из третьего уровня). Для решения первой проблемы использовался наследник 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’ов. Но ситуацию это не сильно улучшило.
Конфигурация Selenium’а
В итоге пришли к следующей конфигурации: На одном компьютере запускался Selenium в режиме hub с дополнительным параметром –timeout 0. Это нужно было потому, что иногда сессии закрывались по timeout из за длительного бездействия тестов. На других компьютерах запускался Selenium в режиме node. Для мощных компьютеров, способных обеспечить работу 15 браузеров, node Selenium’а запускался с дополнительной настройкой, позволяющей запускать 15 копий FF и указывающей, что одновременно можно работать с 15 сессиями.
Проведение тестов
Тесты проводились следующим образом – на одном компьютере запускался один экземпляр браузера, который выполнял тестовые сценарии несколько раз и с которого снимали время выполнения. На остальных компьютерах запускались те же тестовые сценарии, но уже на нескольких браузерах. Такое разделение для замера времени нужно для того, что бы одновременная работа браузеров не отражалась на результате измерения. Так как если делать те же измерения на нескольких запущенных браузерах, то время будет чуть больше.
Пару слов нужно сказать о тестовых сценариях и подсчёте времени их выполнения. Каждый сценарий включал в себя открытие документов каждого типа. Т.е. сначала открывался входящий документ, потом исходящий документа и т.д. Вот здесь нужно учесть следующую ситуацию – если нужно снять время открытия только входящего документа, и при этом запустить на всех машинах выполнения только это сценария, то время будет существенно меньше (на 50%) чем, если бы снимать время при одновременном выполнении всех сценариев. В моём случае, скорее всего это было связано с кешированием на уровнях web приложения и СУБД. И тем, что открывалось мало уникальных документов. Возможно, при большом количестве разных документов различия будут не столь существенны.
В идеале хотелось бы получить распределение пользователей и документов таким, каким оно будет в реально работающей системе. Т.е., например, в реальной системе будет 10 человек работать с входящими и 30 с исходящими. И в нагрузочном тесте так же отразить это соотношение – количество тестов по исходящим в три раза больше чем с входящими документами. Но так как ещё тестируемая система пока не вошла в эксплуатацию и этих данных пока нет, то тестирования происходило без их учёта.
Подведение итогов
В результате тестов для 1-го, 16-ти, 26-ти и 70 пользователей был составлен график по каждым сценариям. Пока ещё количество пользователей не слишком большое, что бы сделать точные выводы, но уже сейчас можно проследить темпы роста времени.
Зависимость времени открытия документов от количества работающих пользователей:
По нему уже можно будет точно определить возможности системы и найти её узкие места.
Интеграционное тестирование (в отличие от Unit- или модульного тестирования) это тестирование не отдельных атомарных компонентов системы (классов) а результата их взаимодействия между собой в какой-либо среде.
Волею судеб я занимаюсь разработкой своего рода интерфейсного фреймворка заточенного на определенные корпоративные нужды. Среда исполнения фреймворка — браузер, а по сему язык — JavaScript.
О том, как можно Unit-тестировать JavaScript я писал ранее, сейчас же расскажу о процессе интеграционного тестирования, применяемого в команде.
Selenium
- написание TestSuite в SeleniumIDE и прогон их через SeleniumTestRunner, или
- использование WebDriver
WebDriver
Для каждого браузера имеется своя реализация WebDriver (FireFoxDriver, InternetExplorerDriver, ChromeDriver — сейчас включены в поставку, OperaSoftware разработали OperaDriver). Существует также «виртуальный» HtmlUnitDriver. В отличии от «браузерных» реализаций он не требует установленного браузера и за счет этого работает быстрее и платформонезависим, но есть и минусы — HtmlUnitDriver имеет «свою» реализацию JavaScript и потому поведение «богатых» веб-приложений может в нем отличаться. Для своих задач мы используем «браузерные» реализации, это позволяет проверить приложение именно в той среде, в которой оно будет исполняться впоследствии.
- реализуется код, использующий какую-либо имплементацию WebDriver. Данный код выполняет какие-либо действия с веб-страницей и сравнивает результат с эталонным
- WebDriver транслирует команды в запущенный браузер (при использовании «браузерной» реализации) и сообщает результаты «обратно в код»
Что умеет WebDriver
- поиск элементов: findElement(s)By*
- CssSelector
- ClassName
- Id
- LinkText
- TagName
- XPath
- получение текста (text)
- получение значения (value)
- click по элементу
- ввод с клавиатуры (клавиша, сочетание клавиш, последовательность клавиш/сочетаний)
Среда исполнения тестов
В качестве языка для написания тестов была выбрана 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 но работу с ней пока не пробовали)
Как запустить один и тот же тест в нескольких браузерах одновременно?
Пытался использовать Selenium grid, но не хватило знаний и навыков гугления.
Запускаю на своей машине Windows 8.1
Использую JUnit Webdriver 2.0 maven1 ответ 1
Параллельный запуск тестов является одним из мощных средств для ускорения тестирования. Хорошо автоматизированные тесты должны быть независимыми, изолированными и воспроизводимыми, эти качества делают их идеальными для одновременного выполнения. Однако на практике не все тестовые классы разработаны с возможностью параллельного запуска. Такие аспекты, как общие изменяемые переменные, общий доступ к файлу и базе данных, или использование встроенного веб-сервера, могут сделать параллельный запуск тестов очень сложным или вообще невозможным. Тем не менее, одновременный запуск тестов, определенно, очень полезная вещь.
Начиная с версии 4.7 в JUnit была добавлена возможность параллельного запуска, для этого нужно настроить Maven следующим образом:
Атрибут parallel может принимать значения «classes», «methods» или «both». При этом нельзя однозначно утверждать о количестве запущенных одновременно тестов, это напрямую зависит от параметров компьютера и настроек плагина по-умолчанию.
Во время запуска теста найдите следующую строку в консоли, она позволяет узнать параметры с которыми выполняется параллельный запуск:
Атрибут threadCount позволяет указать, сколько потоков должно быть выделено для запуска тестов (сколько тестов должно запускаться параллельно). Обратите внимание, что его использование с параметром perCoreThreadCount , установленным в true , может исказить реальное количество запускаемых одновременно тестов. В то же время perCoreThreadCount позволяет добиться большей гибкости при запуске тестов на разных машинах. Например, при запуске тестов со следующей конфигурацией на машине с 2-х ядерным процессором, одновременно будут выполняться 4 тестовых класса, а не 2:
Существует еще такой атрибут как useUnlimitedThreads . При его использовании будет создаваться столько потоков, сколько классов или методов в Вашем проекте, и все тесты будут пытаться запуститься одновременно. useUnlimitedThreads отлично работает для юнит-тестов, но для функционального web тестирования его лучше не использовать.
Настройки конфигурации полностью зависят от характера Ваших тестов, поэтому стоит поэкспериментировать с различными конфигурациями и посмотреть, какой из вариантов настройки больше всего подходит для Вас.
В будущем советую все таки использовать Google. И не бояться эксперементировать со своим проектом. Надеюсь предоставленная информация Вам поможет, удачи в дальнейших трудах)
Читайте также: