frameworks-770x270.jpg

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

30 октября 2019
rakauthor.jpg

Дмитрий
Рак

QA Group Manager

Мы продолжаем рассказывать о 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

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

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

Если тестовые сценарии написаны с помощью 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, ресурсы - вспомогательные классы/файлы для любых действий не связанных с пунктами, перечисленными выше.

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

907
Стань частью нашей команды