Напишите нам
Оставьте свои данные и мы свяжемся с вами
Суть данного метода заключается в следующем:
Если тест упадёт, он будет повторно запускаться то количество раз, которое установлено в конфигурации.
Для того чтобы посмотреть отчеты, необходимо перейти на сайт и авторизоваться под учетной записью. После успешной авторизации мы попадаем на главную страницу. В левом меню расположены проекты автотестов.
Автоматический запуск автотестов по расписанию
Расписание запуска - каждый день.
- Krasnodar Admin 5:00.
- Krasnodar Mobile 5:20.
- Traktor Admin 5:40.
- Traktor Mobile 6:00.
- Winline Admin 6:20.
- Zenit Admin 6:40.
- Zenit Mobile 7:00.
Ручной запуск автотестов
Для ручного запуска, выбираем проект и нажимаем кнопку Run.
Фреймворк отчетности Allure Report
Для перехода к отчетности, выбираем проект и открываем вкладку Allure Report.
- Overview
Авторизация
После того, как была проведена работа по написанию тестов, необходимо оценить полученные результаты. В этом блоке мы рассмотрим пример проекта для спортивных клубов и покажем, как посмотреть результаты автотестов.
Как посмотреть результаты
На данной странице можно посмотреть:
- Дату и время запуска
- Продолжительность выполнения
- Количество тест-кейсов
- Графическое представление тестов по статусам.
- SUITES
В этом разделе можно посмотреть сгруппированные тесты.
- FEATURES BY STORIES
Ниже располагаются тесты, сгруппированные по анотациям Features и Stories.
- TREND
В данном разделе показана накопительная статистика запуска всех тестов проекта.
- CATEGORIES
В данном разделе показаны ошибки по категориям (взята для примера из интернета).
- EXECUTORS
В данном разделе находится техническая информация запуска. В нашем случае - это TeamCity как инструмент непрерывной интеграции.
Categories
В данном разделе можно посмотреть найденные ошибки. Результаты можно скачать в csv формате. Также здесь присутствует удобный поиск и разнообразная фильтрация.
Suites
В данном разделе можно посмотреть все сгруппированные автотесты во всех статусах. Рядом с каждым комплектом установлено количество тестов, которое находится в комплекте. При раскрытии комплектов можно посмотреть статус, а так же время выполнения теста.
При открытии каждого теста здесь мы можем посмотреть следующую информацию:
- Сквозной путь к тесту
- Статус теста
- Название теста
- Severity - серьезность теста
- Предусловие с 1 параметров и 2-мя артефактами
- Проверка перед выполнением основного теста
- И артефакты запроса и ответа от сервера (в данном случае мы отправляем запрос на добавление роли, далее отправляем запрос на основное действие - Изменение роли, и завершающее действие - Удаление роли как постусловие).
В детализации запроса присутствует вся необходимая информация для отладки, включая заголовки, тело запроса, а так же cURL запроса. А так же ответ от сервера
На вкладке History можно посмотреть выполнение теста за разные дни (здесь для примера показано выполнение за 2 дня). На вкладке Retries можно посмотреть информацию о повторных запусках тестов.
- Аннотации @Feature, @Story, @Severity и @DisplayName нам нужны для отчета.
- С помощью аннотации @BeforeAll добавляем спецификацию запроса
- А в сам тест добавим спецификацию ответа под названием responseSpecOK200.
- Далее создаем тело для нашего запроса
- Добавляем тело в запрос
- Логируем запрос
- Отправляем методом post на эндпоинт /Role/AddRole
- Логируем ответ
- Распаковываем ответ в модель ответа от сервера
- и делаем проверку полученных строк
Спецификации
В классе 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 - методы для предусловий, вынесенных в отдельные классы.
В пакете helpers находятся классы, которые могут помочь нам создать предусловия для наших тестов. Как правило это обычные тесты, вынесенные в отдельный класс, которые вызываются из других тестов.
В данном пакете мы создаем модели для сериализации/десериализации наших объектов. С помощью аннотаций lombok @Data, @NoArgsConstructor, @AllArgsConstructor нам не нужно создавать геттеры, сеттеры и конструкторы. Мы просто определяем поля, которые присутствуют в теле запроса.
И тоже самое делаем для тела ответа от сервера.
- spec - спецификации для запросов и ответов.
В данном классе задаются спецификации запросов и ответов от сервера, здесь мы получаем токен, задаем Content Type для запросов и ответов. Так же устанавливаем ожидаемое время выполнения запроса, ожидаемые статус коды от сервера и Content Type для ответа.
- TestBase - базовый класс с конфигурацией.
Пример расположения тестов. Классы можно называть по названию Suites.
- resources - директория с файлами, необходимыми для тестов.
- build.gradle - файл конфигурации сборщика проекта с подключенными зависимостями, необходимыми для тестов.
В данной директории хранятся файлы, которые мы используем для тестов. Так же в пакете tpl хранятся красивые шаблоны для запроса и ответа в Allure Report.
- models - модели запросов и ответов для десерилизации.
- CustomAllureListener - класс добавляет красивые отчеты запроса и ответа для Allure Report
В директории data находятся классы для генерации тела запросов. В данном примере присутствует только один класс DataGenerator, где с помощью моделей мы собираем тело для запросов.
- data - генерация тестовых данных.
Структура минимального проекта
В данной статье мы рассмотрим основные преимущества автоматизированного тестирования, принципы его работы, наиболее популярные инструменты и технологии, а также рассмотрим практические советы по его внедрению и использованию. Ознакомившись с этой информацией, вы сможете определить, насколько полезным может быть автоматизированное тестирование для вашей компании и как начать использовать его на практике.
- Отсутствие человеческого фактора.
Хорошо написанный тест не может забыть что-то проверить, он каждый раз последовательно проверяет действия.
- Скорость выполнения.
Код для сценария пишется один раз, а его запуск обычно занимает несколько секунд.
- Переиспользуемость.
Код автотестов может быть использован неоднократно, особенно при внедрении новой функциональности.
Среди плюсов автоматизированного тестирования, можно выделить:
- Язык программирования — Java 17
- Паттерн проектирования — AAA (Arrange, Act and Assert)
- Сборщик проекта — Gradle
- Фреймворк отчетности — Allure Report
- Фреймворк запуска — Junit5
- Библиотека проверок — AssertJ
- DSL для тестирования REST-сервисов — Rest-Assured
- Оповещения — Discord
- Логирование — Slf4j
- Генерация тестовых данных — JavaFaker
- CI/CD - TeamCity
Стэк
- Для написания тестов использовался актуальный стэк технологий.
- Для каждого теста создаются уникальные тестовые данные, что исключает одну из главных проблем в тестировании - Эффект Пестицида.
- В рамках тестирования создаются тестовые данные как предусловие, происходит процесс тестирования, после чего тестовые данные удаляются, что является хорошей практикой.
- Для тестирования API используется самая распространенная библиотека - Rest-Assured, с её помощью реализованы как сами тесты, так и методы-помощники для генерации тестовых данных, а так же методы удаления сущностей после прохождения тестов.
- Автотесты полностью интегрированы с системой непрерывной интеграции TeamCity и запускаются по расписанию каждое утро в 5:00 (без выходных и праздников).
- Автотесты запускаются в несколько потоков, что позволяет оптимизировать время их выполнения, в среднем автотесты каждого проекта по отдельности выполняются 5-6 минут на текущих мощностях.
- При падении тестов - мгновенно приходит оповещение в канал в Discord, где закрепленный сотрудник сразу же может отреагировать.
- В каждом проекте ведется подробное логирование. Для отчетности используется фреймворк Allure Report, где можно найти все необходимые артефакты для оперативной локализации проблемы, а именно: заголовки запросов и ответов сервера, логи, cUrl запроса и иные артефакты.
- В рамках реализации проекта были выполнены основные сценарии (так называемый критический путь пользователя), а так же позитивные и негативные сценарии практически всех эндпоинтов (т.к. согласно одного принципа тестирования - Исчерпывающее тестирование недостижимо).
- Помимо автоматического расписания, реализованы так называемые “ручки запуска” каждого проекта с автотестами. Это позволяет запускать тесты неограниченное количество раз в любое время и быть уверенными в качестве приложения и всех сервисов.
Ключевые моменты
Завричко Андрей
Teamlead QA-инженер
Стэк, ключевые моменты и структура минимального проекта
Автоматизированное тестирование
Тестирование
Но в нашей реализации такая модель отключена специально, чтобы не упустить ни единой ошибки. Т.к. каждый эпизод падения рассматривается специалистами тестирования и специалистами DevOps для того чтобы еще больше увеличить качество всего продукта в целом.
GRAFS
Наиболее интересная вкладка GRAFS.
- STATUS
Здесь находится общий статус по каждому проекту
- SEVERITY
Градация тестов по серьезности.
- DURATION
Градация тестов по времени выполнения.
- DURATION TREND
Градация времени выполнения всех тестов.
- CATEGORIES TREND
Градация категорий ошибок (здесь для примера показана одна ошибка продукта).
- TREND
Градация выполнения всех тестов.
- Timeline
В данном интерактивном разделе можно отфильтровать тесты по времени выполнения.
- Behaviors
В данном разделе можно посмотреть функциональность как и в разделе Suites.
- Packages
В данном разделе можно посмотреть тесты с группировкой по пакетам.
В заключение, автоматизированное тестирование является незаменимым инструментом для спортивных клубов, которые стремятся обеспечить высокое качество своих услуг и улучшить удовлетворенность клиентов. Это позволяет значительно сократить время и затраты на тестирование, а также повысить его эффективность и точность.
Кроме того, автотесты помогают быстро выявлять и исправлять ошибки, что повышает уровень безопасности и надежности оборудования и программного обеспечения.