itechart_logo

Гайд для QA Engineers: как создать фреймворк для автоматизации тестирования

Development & QA

Мы продолжаем рассказывать о QA. Руководитель отдела тестирования Дмитрий Рак расскажет об архитектуре фреймворка для автоматизации тестирования.

Последние осенние солнечные деньки подходят к концу, мы лениво подбираемся к нашим лаптопам, перебирая в голове тысячи фотографий с желтой листвой под ногами. Чтобы перестать хандрить от мысли о наступающих промозглых утрах и грязевых ландшафтах вокруг, мы решаем создать что-то светлое, вдохновляющее и обещающее невероятные приключения. Например, новый фреймворк для автоматизации тестирования проекта. И, конечно, мы можем взять прекрасную инструкцию из интернета, но не возьмем потому что:

  • Создать-то фреймворк − они создали, но не объяснили, зачем;
  • Может быть даже какие-то из компонентов забыли;
  • Мы получаем невероятно удовольствие от изобретения очередного колеса через муки и страдания.

Зачем автоматизировать тестирование?

Цели автоматизации тестирования бывают разные. 

Цели автоматизации тестирования QA Automation - Как создать фреймворк для автоматизации тестирования

Цели создания фреймворка для автоматизации:

  • Не хотим писать один и тот же код дважды; 
  • После создания фреймворка – написание тестов должно свестись к простому составлению последовательности шагов, вытекающих в тестовые сценарии. 

Разработчики каждый раз пугаются фразе «создать фреймворк», считая, что это похоже на разработку собственного приложения/библиотеки/модуля. Реальность отличается: фреймворк для автоматизации тестирования − это адаптация нескольких решений, имеющихся на рынке, под нужды конкретного проекта.

Ниже расскажем, из чего может состоять фреймворк и какие цели та или иная его часть может преследовать. Добавим суматохи в ряды автоматизаторов и поговорим в формате User Stories, где каждая будет начинаться с привычных и столь нелюбимых нами: «Как автоматизатор я хочу...».

Как автоматизатор я хочу иметь возможность расширять решение, добавлять новые возможности и не зависеть от создателей сторонних продуктов.

Вечный выбор между record-replay или языками программирования. Я адепт решений, связанных с языками программирования потому что:

  • Готовые решения плохо работают с динамическими данными;
  • Готовые решения, в большинстве своем, платные;
  • Готовые решения могут менять набор функциональности, доступной для пользователей либо содержать баги, мешающие работе;
  • Готовые решения не дают возможности встроить все, что душе заблагорассудится, в их продукт. Необходимо ждать внедрения интеграции от создателей.

Если говорить о выборе языка программирования, то холивары на этот счет никогда не прекращаются в связи с тем, что:

  • Бытует миф, что разработчики могут помогать писать автотесты автоматизаторам (на самом деле, нет);
  • Говорят, что хранить код продукта вместе с кодом автотестов − это правильно.

Выбирая язык программирования, надейтесь только на себя и поддержку комьюнити. Выбор прост: у Java, C#, Python, Javascript шикарные комьюнити и их легко выучить.

Как автоматизатор я хочу иметь возможность легко подключать новые библиотеки и запускать тесты c помощью командной строки.

Далее мы рассмотрим примеры, приближенные к языку программирования Java. Тем не менее, информация ниже применима в любом из языков программирования.

Начнем. Подключаем любой build tool, например, Maven/Ant+Ivy/Gradle и наслаждаемся простотой добавления и широким выбором библиотек, которые можно использовать в проекте. Приятный бонус: запуск тестов из командной строки, что пригодится нам на этапе внедрения в CI, но об этом позже.

Как автоматизатор я хочу иметь возможность запускать тесты в параллели, использовать Asserts и группировку по тест-пакетам.

Для запуска тестов в параллели проще всего использовать xUnit-библиотеки. То есть хватаем JUnit или TestNG, и вуаля. Я фанат TestNG. Возможно, в паре с Hamcrest из-за большего количества функциональности и поддержки от создателей. Говорят, JUnit 5 просто космос. Пишите ваше мнение в комментариях.

Как автоматизатор я хочу описать взаимодействие со всеми элементами в приложении один раз и больше не задумываться о том, как это работает.

Ниже разговор пойдет о фреймворках, так или иначе касающихся взаимодействия с UI-частью приложения через Selenium. И здесь не о библиотеке, а о стандартном подходе в Page Object Model, где в каждом из проектов описаны такие пакеты/модули:

  • Elements − взаимодействие с кнопками/инпутами и другими элементами, доступными в приложении. Здесь и ожидания, и логирование, и обработка исключения;
  • Pages − описание локаторов и действий с каждым из элементов, используя классы из elements;
  • Steps − объединение отдельных действий из разных страниц в так называемые business-scenarios. Ценные для конечного пользователя/описываемые в репортинге. Создатели Serenity прекрасно «переиспользовали» модель у себя во фреймворке, но, к сожалению, пожертвовали гибкостью;
  • Tests − из отдельных шагов собирается тестовый сценарий. Из тестов только пробрасывается ввод от конечного пользователя.

Окей, элементы расписаны. Что дальше?

Вакансии для QA Engineers - Гайд для QA Engineers: как создать фреймворк для автоматизации тестирования

Из них составляем страницы, из страниц готовим наборы бизнес-шагов, из них − тестовые сценарии.

Как автоматизатор я хочу максимальное время уделять тестированию приложения, а не подготовке тестовых данных.

Если тестовые сценарии написаны с помощью UI-библиотеки, например, Selenium, то со временем вы удивитесь почему один небольшой тест занимает 5-10 минут времени. Проблема в создании тестовых данных. Поэтому чем раньше в вашем фреймворке появится возможность использовать REST API или базу данных приложения, тем лучше. REST Assured и JDBC вам в помощь. Приятным бонусом будет то, что теперь внутри фреймворка можно делать тестовую пирамиду и автоматизировать часть проверок, используя только REST API.

Как автоматизатор я хочу забыть, где объявлен WebDriver, забыть о проблемах с параллелизацией и частыми StaleElementReferenceException.

Ребята из Selenide за последние несколько лет сделали многое для того, чтобы мы писали меньше кода.

  • Встроенные ожидания;
  • WebDriver не хранится как поле класса, а вызывается методом getWebDriver из любой точки кода. Не конфликтует друг с другом из коробки при параллельном запуске;
  • StaleElementReferenceException побежден раз и навсегда за счет «умного» обращения к DOM вашей страницы под капотом Selenide.

Как автоматизатор я хочу запускать тесты не у себя на компьютере.

Словосочетание Continuous Integration и так всем известно. Зачем? Чтобы не пить чай, пока запускаются тесты, а продолжать разрабатывать новые. В это время старые генерируют нам проблемы. Здесь подробный список доступных сейчас CI tools. Из приятных нововведений, появившихся не так давно: CircleCI для Selenium-like фреймворка заводится за несколько минут и предоставляет 240 бесплатных минут в неделю.

Как автоматизатор я хочу понимать, почему мои тесты упали.

Здесь о логировании, репортинге и обработке исключений. Запустите ваш автотест, на минуту закройте глаза, глубоко вдохните, посмотрите в консольный вывод и расскажите, что делал ваш тест? Не можете? Тогда займитесь тем, чтобы добавить логирование в проект. Кстати, Lombok позволит это сделать довольно быстро и без лишних телодвижений, а заодно избавит от множества boilerplate-кода. Поделитесь финальным рапортом с заказчиком и попросите его рассказать, что происходило в вашем тестовом сценарии и почему он упал. Если в репорте есть хотя бы одно слово Exception, значит пора заняться оберткой стандартных исключений. Кастомных, с понятными человеку сообщениями об ошибках. Аннотации @Steps из библиотеки Allure вешаем на методы в классах пакета steps, чтобы весь ход действия теста был понятен и пользователю без технического бэкграунда.

Что в итоге?

Как создать фреймворк для автоматизации тестирования

  • Язык программирования позволит нам расширять фреймворк как нам будет угодно и не страдать от недостатка  какой-либо функциональности в готовых решениях;                                                                                                  
  • Средства сборки позволят легко добавлять новые библиотеки и запускать из консоли наши тесты;
  • xUnit-библиотеки делают наш фреймворк тестовым фреймворком и позволяют запускаться в параллели;
  • Page Object Model разбивает фреймворк на структуру, позволяющую использовать разные его части как маленькие кубики конструктора. К тому же, работа с GIT сильно облегчается благодаря более редким конфликтам;        
  • Описание моделей, используя аннотации из gson помогает быстрой сериализации в REST API-объекты для использования в адаптерах при подготовке тестовых данных. SQL здесь же в случае, если REST API отсутствует;
  • Selenide/Selenium - решать вам самим. Я к примеру устал от вечных wait.until();
  • Continuous Integration - просто must have и не заканчивается на Jenkins;
  • Логи, репортинг, кастомные exceptions - сильно облегчают последующие дебаг и увеличивают уровень счастья заказчика;
  • utils/others, ресурсы - вспомогательные классы/файлы для любых действий не связанных с пунктами, перечисленными выше.

У вас есть что добавить к архитектуре фреймворка?