Automated GUI testing: пошаговая инструкция
Статья будет полезна не только менеджерам, отвечающим за процессы разработки и тестирования, но и рядовым тестировщикам. Ведь нет такого тестировщика, который не хочет стать автоматизатором.
Тестирование — это неотъемлемая часть разработки ПО, цель которой — своевременное представление информации о качестве продукта группе заинтересованных лиц. Автоматизация тестирования — часть процесса тестирования с использованием программных средств для выполнения тестов и проверки результатов.
Главная цель автоматизации — ускорить процесс тестирования без потери качества, а также избавить ручного тестировщика от рутины прохождения регрессионных сценариев, позволив сфокусироваться на проверке бизнес-логики приложения с точки зрения конечного пользователя.
Преимущества автоматизации тестирования
- Исключен человеческий фактор. Автоматизация гарантирует, что тест-скрипт всегда будет выполнен одинаково, исключая ошибки по неосторожности.
- Скорость выполнения — время выполнения автоматизированного тест-скрипта в разы меньше ручного прохождения.
- Меньшие затраты на поддержку — единожды написанные скрипты требуют намного меньше времени на поддержку и анализ результатов.
- Отчеты — в результате прогона генерируется отчет с последующей рассылкой всем заинтересованным лицам.
- Выполнение тестов в удобное время — автотесты могут быть запущены в любое удобное время или по определенному событию. Часто это ночные прогоны и тестирование в нерабочее время, что позволяет рациональнее использовать тест-ресурсы.
Уровни тестирования
Существует несколько уровней тестирования:
- Unit tests;
- Integration tests;
- GUI tests;
- Manual tests.
Unit и Integration tests оставим разработчикам, с Manual тестами все понятно. Давайте остановимся более подробно на GUI-автоматизации, набирающей популярность огромными темпами.
GUI-автоматизация — наиболее распространенный вид автоматизации тестирования путем тестирования приложения через графический интерфейс пользователя (GUI). Главное его преимущество в том, что приложение тестируют точно так, как его будет использовать конечный пользователь. Также этот подход позволяет тестировать без доступа к исходному коду приложения.
Место автоматизации GUI в процессе разработки
Для успешного тестирования с применением автоматизации необходимо определиться с местом автотестов в процессе разработки. Поскольку при помощи автоматизации GUI покрываются в основном регрессионные сценарии, то есть смысл запускать тесты для каждой новой сборки. Для этого мы используем Jenkins. После каждого успешного билда автоматически стартует сборка проекта с тестами. Также есть возможность ручного запуска или по расписанию, для запуска тестов ночью — в момент минимальной нагрузки на тестовые стенды.
Инструменты для автоматизации GUI
Путем проб и ошибок мы в Ukad пришли к следующему инструментарию для GUI автоматизации:
- Java — как язык для написания тест-скриптов.
- Maven — для сборки проекта.
- Selenide — как фреймворк для написания GUI тестов.
- TestNG — как фреймворк для управления запуском тестов.
- Selenoid — для непосредственного управления сессиями браузера.
- Allure — для создания и эффектной презентации отчета.
- Jenkins — для непрерывной интеграции тестов в процесс разработки.
Более подробно об инструментах и причинах, почему мы выбрали именно этот набор:
- Java. Мы используем Java, так как это путь наименьшего сопротивления ведь сообщество просто огромно, что дает доступ к большому количеству готовых решений для тестирования и не только. Это в свою очередь позволяет не тратить много времени на исследование и решение часто возникающих проблем, так как очень велика вероятность того, что решение уже найдено.
- Maven. Можно использовать любой другой сборщик. Для автотестов это не принципиально, но лично мне Maven ближе.
- Selenide позволяет не изобретать свой велосипед для решения стандартных проблем Selenium (таких как ожидания и поиск элементов на странице, добавление «мягких» проверок и т. д.) и значительно повысить скорость разработки и стабильность тестов.
- TestNG. Мы перешли с Junit на TestNG для использования наборов на основе .xml файлов, а также возможности объединения тестов в группы.
- Selenoid. Мы используем Selenoid вместо Selenium Hub, так как он более стабилен и позволяет запускать сессии браузеров в Docker контейнерах, плюс добавляет такие приятные бонусы, как просмотр выполнения конкретного теста и запись видео его прохождения.
- Allure. Позволяет значительно расширить возможности стандартного TestNG отчета, эффектно и удобно презентовать всю информацию о пройденных сценариях. В репорте каждый член команды сможет найти для себя полезную информацию. Начиная от времени и количества пройденных сценариев с результатами прохождения, до прикрепленного видео прохождения и скриншотами для упавших тестов.
- Jenkins. Мы используем Jenkins для сборки некоторых своих проектов, поэтому мы решили использовать его же для сборки тестов. Также с Jenkins удобно интегрировать Allure репорты при помощи дополнительного плагина.
Пример использования GUI автоматизации
Создаем проект с тестами
Рассмотрим, как используется GUI автоматизация на примере простого теста. Для этого создадим Maven-проект и подключим необходимые зависимости для Selenide, TestNG и Allure. Добавим простой тест, который будет открывать главную страницу сайта и проверять, что футер отображается. Для написания теста используется PageObject паттерн. Для управлением драйверами браузера используется WebDriverManager.
Актуальный pom.xml и исходный код проекта доступен по ссылке.
Проект может быть запущен командой "mvn test" (Maven должен быть установлен и добавлен к системным переменным). Все работает, но тест будет запущен в локальном браузере, а нам необходимо запускать на тестовом стенде. Самые популярные варианты удаленного запуска тестов — Selenium hub и Selenoid. Остановимся подробнее на Selenoid.
Selenoid
Selenoid — это имплементация Selenium hub кода, использующая Docker-контейнеры для запуска браузера, что позволяет нам не задумываться об управлении браузерами и сессиями. Для каждого теста будет запущен свой Docker-контейнер, который будет остановлен после окончания теста. После установки Selenoid (по ссылке доступна подробная инструкция по установке) нам только остается подправить код создания драйвера на код предложенный Selenoid.
Снова запустим наш проект командой “mvn test”.
Тест работает. Но что если мы хотим видеть выполнение теста? Для этого достаточно добавить дополнительный параметр в создание браузера и использовать Selenoid контейнеры с поддержкой VNC, например “selenoid/vnc:chrome_66.0” для 66 версии Chrome. Также нужно добавить дополнительную Capability к созданию браузера “browser.setCapability("enableVNC", true);”.
Вот так выглядит browser.json после обновления. Для простоты я оставил только Chrome 66 версии.
Также добавим дополнительную Capability к созданию драйвера “browser.setCapability("enableVNC", true);”.
Запустим наш тест еще раз и перейдем на вкладку «Session». Теперь мы можем следить за выполнением теста.
Но для эффективного использования автотестов необходима непрерывная интеграция с процессом разработки. Для этого мы используем Jenkins.
Jenkins CI
Jenkins — проект для непрерывной интеграции с открытым исходным кодом, написанный на Java. Используется для сборки и поставки программного обеспечения. У нас есть возможность использовать Jenkins для запуска тестов для каждой новой сборки тестируемого продукта. Для создания тестовой сборки нам необходимо установить дополнительные плагины:
- Maven Integration — для более удобной интеграции с Maven.
- Allure Jenkins Plugin — для генерации и отображения отчета.
Создадим новую Jenkins job с типом «Maven project».
Добавим наш репозиторий с тестами в секцию «Source Code Management».
Для генерации Allure отчета добавим «Post-build Actions» -> «Allure report».
Теперь после сборки проекта с тестами у нас есть возможность просмотреть отчет тестового прогона для каждой сборки в истории и иконка быстрого доступа к последней сборке.
А вот и Allure отчет.
Финальная стадия интеграции — связываем нашу тестовую сборку со сборкой нашего тестируемого приложения путем добавления в «Build Triggers» — > «Project to watch».
Таким образом после каждой успешной сборки тестируемого проекта мы автоматически запускаем сборку тестов. Остается только оповестить о результатах теста заинтересованную группу людей путем отправки Email или Slack-уведомлений.
Полезные ссылки
- официальная документация Selenide;
- официальная документация TestNG;
- официальная страница Maven;
- официальная документация Selenoid;
- официальная документация Allure;
- официальная документация Jenkins;
- Иван Крутов «Selenoid: запускаем Selenium тесты в Docker контейнерах» — обзорный доклад о Selenoid от одного из разработчиков;
- Allure 2: new gen test report tool — обзорный доклад по Allure 2 от разработчика.
Вывод
По мере усложнения кода, добавления нового функционала и исправления багов, процесс тестирования будет занимать все больше времени. Команда мануального тестирования физически не сможет успевать за ритмом команды разработчиков. Ведь проверка нового функционала — это не только функциональные тесты, но и ресурсоемкие регрессионные прогоны. Внедрение автоматизированного тестирования позволяет снять с команды мануального тестирования достаточно объемную часть регрессионных прогонов. Но следует помнить, что ни полная автоматизация, ни стопроцентное ручное тестирование не дадут гарантии идеального результата. Оптимальным подходом в данном случае является разумный баланс.
Задача автоматизации — не только в создании автоматизированных сценариев, но также в непосредственной интеграции в процесс разработки ПО.
Использование связки автоматизированного и ручного тестирования и тесное взаимодействие с командой разработчиков от начала процесса работы над проектом до его реализации повысит качество конечного продукта.
