Но в нашей реализации такая модель отключена специально, чтобы не упустить ни единой ошибки. Т.к. каждый эпизод падения рассматривается специалистами тестирования и специалистами DevOps для того чтобы еще больше увеличить качество всего продукта в целом.

GRAFS

Наиболее интересная вкладка GRAFS.

Здесь находится общий статус по каждому проекту

Суть данного метода заключается в следующем:

Если тест упадёт, он будет повторно запускаться то количество раз, которое установлено в конфигурации.

Для того чтобы посмотреть отчеты, необходимо перейти на сайт и авторизоваться под учетной записью. После успешной авторизации мы попадаем на главную страницу. В левом меню расположены проекты автотестов.

Автоматический запуск автотестов по расписанию

Расписание запуска - каждый день.

Ручной запуск автотестов

Для ручного запуска, выбираем проект и нажимаем кнопку Run.

Фреймворк отчетности Allure Report

Для перехода к отчетности, выбираем проект и открываем вкладку Allure Report.

Авторизация

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

На данной странице можно посмотреть:

В этом разделе можно посмотреть сгруппированные тесты.

Ниже располагаются тесты, сгруппированные по анотациям Features и Stories.

В данном разделе показана накопительная статистика запуска всех тестов проекта.

В данном разделе показаны ошибки по категориям (взята для примера из интернета).

В данном разделе находится техническая информация запуска. В нашем случае - это TeamCity как инструмент непрерывной интеграции.

Categories

В данном разделе можно посмотреть найденные ошибки. Результаты можно скачать в csv формате. Также здесь присутствует удобный поиск и разнообразная фильтрация.

Suites

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

При открытии каждого теста здесь мы можем посмотреть следующую информацию:

В детализации запроса присутствует вся необходимая информация для отладки, включая заголовки, тело запроса, а так же cURL запроса. А так же ответ от сервера

На вкладке History можно посмотреть выполнение теста за разные дни (здесь для примера показано выполнение за 2 дня). На вкладке Retries можно посмотреть информацию о повторных запусках тестов.

Спецификации

В классе Specification есть два вида спецификаций - для request и для response. Для request устанавливаем базовый адрес идентити, генерируем токен, достаем токен из ответа, устанавливаем базовый адрес, добавляем токен в заголовок, устанавливаем Content Type и Accept, добавляем фильтр для ответа и собираем наш запрос.

В спецификации ответа мы устанавливаем уровень логирования, ожидаемый Content Type от сервера, ожидаемый статус код и время ответа.

Вернемся к DataGenerator. К примеру мы собрали запрос с уникальным именем и policies для роли.

Если сделать точку останова, то можно посмотреть в поле name будет сгенерированное имя, а в policies будет переданная коллекция.

Создание тела запроса

В классе DataGenerator создаем с помощью builder'a наше тело. С помощью faker генерируем рандомное имя и указываем Policies

В классе RoleApiTest создадим тест с названием addRoleTest.

При выполнении теста происходит логирование запроса и ответа. Это необходимо для отладки тестов. В начале мы получаем токен, далее отправляем запрос, передаем заголовки и тело запроса. После получаем ответ от сервера, его заголовки и тело

Отчет

При генерировании отчета к каждому тесту прикрепляется request и response от сервера, так же прикрепляется cUrl для дебага ошибки.

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

Далее создадим модель ответа от сервера RoleModel, от сервера нам приходит json с 5-ю полями, к нашим предыдущим добавились еще даты создания, удаления и идентификатор.

Для начала создадим модель Role для запроса. В нашем теле запроса есть два поля это Name и Policies. Поэтому создаем два поля. Name - строковое и Policies - List<String>

Создание моделей

Перед тем, как приступить к созданию автотестов, необходимо иметь минимальную структуру проекта, включающую в себя все необходимые зависимости и конфигурационные файлы. После этого можно приступать к созданию моделей, которые будут тестироваться автоматически. Модели являются основным объектом тестирования и должны быть описаны с использованием языка программирования, используемого в проекте. Создание автотестов для моделей позволяет быстро выявлять и исправлять ошибки в коде, повышает качество и надежность программного продукта. Поэтому создание автотестов является важным шагом в разработке любого проекта.

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

В данном пакете мы создаем модели для сериализации/десериализации наших объектов. С помощью аннотаций lombok @Data, @NoArgsConstructor, @AllArgsConstructor нам не нужно создавать геттеры, сеттеры и конструкторы. Мы просто определяем поля, которые присутствуют в теле запроса.

И тоже самое делаем для тела ответа от сервера.

В данном классе задаются спецификации запросов и ответов от сервера, здесь мы получаем токен, задаем Content Type для запросов и ответов. Так же устанавливаем ожидаемое время выполнения запроса, ожидаемые статус коды от сервера и Content Type для ответа.

Пример расположения тестов. Классы можно называть по названию Suites.

В данной директории хранятся файлы, которые мы используем для тестов. Так же в пакете tpl хранятся красивые шаблоны для запроса и ответа в Allure Report.

В директории data находятся классы для генерации тела запросов. В данном примере присутствует только один класс DataGenerator, где с помощью моделей мы собираем тело для запросов.

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

Завричко Андрей

Teamlead QA-инженер

Автоматизированное тестирование

Градация тестов по серьезности.

Градация тестов по времени выполнения.

Градация времени выполнения всех тестов.

Градация категорий ошибок (здесь для примера показана одна ошибка продукта).

Градация выполнения всех тестов.

В данном интерактивном разделе можно отфильтровать тесты по времени выполнения.

В данном разделе можно посмотреть функциональность как и в разделе Suites.

В данном разделе можно посмотреть тесты с группировкой по пакетам.

В заключение, автоматизированное тестирование является незаменимым инструментом для спортивных клубов, которые стремятся обеспечить высокое качество своих услуг и улучшить удовлетворенность клиентов. Это позволяет значительно сократить время и затраты на тестирование, а также повысить его эффективность и точность.

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