Java e2e что такое

Руководство по сквозному тестированию: что такое E2E-тестирование с примерами

Сквозное тестирование (End-to-end, E2E, Chain testing) — это вид тестирования, используемый для проверки программного обеспечения от начала до конца, а также его интеграцию с внешними интерфейсами. Цель сквозного тестирования состоит в проверке всего программного обеспечения на предмет зависимостей, целостности данных и связи с другими системами, интерфейсами и базами данных для проверки успешного выполнения полного производственного сценария.

Наряду с программной системой тестирование также обеспечивает проверку пакетной обработки и обработки данных из других вышестоящих и нижестоящих систем. Отсюда и название «End-to-End». Сквозное тестирование обычно проводится после функционального и системного тестирования. Для его проведения используются реальные данные и тестовая среда для имитации рабочего режима.

Зачем нужно сквозное тестирование?

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

Процесс сквозного тестирования:

На схеме ниже представлен обзор процесса сквозного тестирования.

Основные виды деятельности, связанные со сквозным тестированием:

Изучение требований к сквозному тестированию;
Настройка тестовой среды и требования к оборудованию/программному обеспечению;
Описание всех процессов системы и ее подсистем;
Описание ролей и ответственности для всех систем;
Методология и стандарты тестирования;
Сквозное отслеживание требований и разработка тест-кейсов;
Входные и выходные данные для каждой системы.

Как писать тест-кейсы для сквозного тестирования?

Фреймворк сквозного тестирования включает в себя три части:

Создание пользовательских функций
Создание условий
Создание тест-кейсов

Рассмотрим каждую из них подробно.

Создание пользовательских функций

Как часть построения пользовательских функций, должны быть выполнены следующие действия:

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

Например, рассмотрите сценарий, при котором вы входите в свой банковский аккаунт и переводите деньги со своего счета на счет в другой банк (сторонняя подсистема):

Войти в банковскую систему.
Проверить сумму остатка на счете.
Перевести определенную сумму со своего счета на другой банковский счет (сторонняя подсистема).
Проверить текущий баланс счета.
Выйти из приложения.

Построение условий на основе пользовательских функций

В рамках построения условий выполняются следующие действия:

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

Например, проверка дополнительных условий, таких как:

Страница авторизации

Неверное имя пользователя и пароль
Проверка с действительным именем пользователя и паролем
Проверка надежности пароля
Проверка сообщений об ошибках

Сумма остатка

Проверьте текущий баланс через 24 часа (Если перевод отправляется в другой банк)
Проверьте сообщение об ошибке, если сумма перевода больше суммы текущего баланса.

Создайте тестовый сценарий

Построение тестового сценария для определенной пользовательской функции

Войти в систему
Проверить сумму остатка на банковском счете
Перевести сумму остатка на банковском счете

Создание нескольких тест-кейсов

Создайте один или несколько тест-кейсов для каждого определенного сценария. Тест-кейсы могут включать каждое условие как отдельный тестовый пример.

Инструмент сквозного тестирования

testRigor

В мире сквозного тестирования лидером отрасли является testRigor. Он помогает создавать тесты без кода для веб-интерфейса, нативных и гибридных мобильных приложений, мобильных браузеров и API. С его помощью можно тестировать электронную почту и SMS, загруженные файлы .XLS, .DOC, .PDF и т. д.

Функции:

Написание тестов без кода просто на английском языке.
Покрытие Web + Mobile + API в одном тесте. Кроссплатформенная и кроссбраузерная поддержка.
Создание тестов в 15 раз быстрее по сравнению с Selenium.
Сокращение обслуживания тестов до 99,5%.
testRigor безопасен и соответствует стандарту SOC 2 Type 2.
Интеграция с CI/CD и управлением тест-кейсами.
Выполнение 1000 тестов и получение результатов менее чем за 30 минут.

Метрики сквозного тестирования:

Ниже приведены некоторые метрики, используемые для оценки прогресса сквозного тестирования.

Статус подготовки тест-кейса: показывает реальный прогресс подготовки тест-кейса по сравнению с запланированным.
Еженедельный прогресс тестирования. Дает подробную информацию о завершении теста за неделю в процентах. Неудачные, не выполненные и выполненные тесты по сравнению с запланированными для выполнения тестами.
Статус и детали дефектов — показывает процент открытых и закрытых дефектов понедельно. Кроме того, распределение дефектов по неделям в зависимости от серьезности и приоритета.
Доступность среды — общее количество часов доступности / общее количество часов, запланированных в день для тестирования.

Сквозное тестирование vs системное тестирование

Сквозное тестирование

Системное тестирование

Проверяет программную систему, а также взаимосвязанные подсистемы.

Проверяет только программную систему в соответствии со спецификациями требований.

Проверяет весь сквозной поток процессов.

Проверяет функциональные возможности и функции системы.

Для тестирования рассматриваются все интерфейсы и серверные системы.

Рассматриваются функциональное и нефункциональное тестирование

Выполняется после завершения тестирования системы.

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

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

В заключение

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

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

java qa
end-to-end testing
сквозное тестирование
E2E тестирование
selenide

Блог компании OTUS
Тестирование веб-сервисов

End-to-End тестирование в деталях и примерах

Автоматизация тестирования: перспективно ли?

QA и QC: их роль и различия в процессе разработки ПО

Мобильное тестирование: что это и какие перспективы

Как стать тестировщиком — путь к успеху

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

End-to-end тестирование — это форма тестирования, которая проверяет работоспособность программного продукта от начала до конца, воссоздавая реальные сценарии использования и проверяя взаимодействие между различными компонентами системы. Поговорим об этом подробнее.

Что такое end-to-end тестирование

End-to-end тестирование — это процесс проверки функциональности и целостности программного продукта в реальных условиях использования. Если дымное тестирование проверяет только, запустилась система или ее часть, или нет, то End-to-end тестирование направлено на обнаружение проблем системы от начала до конца процесса работы.

В отличие от других видов тестирования, которые могут фокусироваться на отдельных компонентах или функциях, end-to-end тестирование проверяет взаимодействие и согласованность между всеми компонентами системы. Основная цель end-to-end тестирования — убедиться, что система работает корректно в реальных условиях и функциональность системы интегрирована правильно.

Процесс end-to-end тестирования

Процесс end-to-end тестирования включает следующие этапы и основные элементы:

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

�� Готовьтесь к яркой карьере на курсе QA Automation от Foxminded! ��

�� Интенсивное обучение онлайн

�� 7 дней тестового периода

��‍�� Менторская поддержка и бесплатная заморозка.

�� Насыщенная программа AQA, разнообразные инструменты.

�� Зависит от вас, насколько быстро вы проходите курс. Чем быстрее – тем меньше платите.

�� Выбирайте менторинг или менторинг+, погружайтесь в практические задания и наращивайте навыки.

�� Присоединяйтесь к нам и начните путь к успешной карьере!��

Примеры проведения end-to-end тестирования

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

Плюсы и минусы end-to-end тестирования

Преимущества end-to-end тестирования

Выявление реальных проблем: так как тестирование проводится на полной системе, можно обнаружить проблемы, которые могут возникнуть только взаимодействием различных компонентов.
Проверка функциональности: end-to-end тестирование позволяет проверить, работает ли система в соответствии с требованиями и ожиданиями пользователей.
Обнаружение уязвимостей: тестирование на всех уровнях системы позволяет обнаружить потенциальные уязвимости и проблемы безопасности.
Улучшение пользовательского опыта: тестирование от начала до конца позволяет проверить, как система взаимодействует с пользователем и насколько удобна для использования.

Сложности и ограничения end-to-end тестирования

Мужчина тестирует ПО

Сложность подготовки тестовых данных: для проведения end-to-end тестирования требуется создание или подготовка большого объема тестовых данных, что потребует времени и усилий.
Высокая стоимость и затраты времени: end-to-end тестирование требует больших ресурсов, включая время, усилия и инфраструктуру, что может повлечь за собой высокие затраты.
Сложность обнаружения причины ошибки: если в результате тестирования выявляются проблемы или ошибки, может быть сложно определить их источник из-за сложности системы и многоуровневого взаимодействия компонентов.

Создаем читабельный e2e тест для микросервисов на Spring Boot с помощью Cucumber 7 и Wiremock

Дорогой читатель, это мой первый туториал и если я что‑то упустил или не объяснил, хотя стоило бы, напиши пожалуйста комментарий и я обновлю статью.

TL;DR

Рекомендую быстро пробежаться по коду перед прочтением статьи т к в самой статье я объясню только неочевидные моменты реализации e2e тестирования.

Проблема

Нужно организовать сквозное/e2e (end-to-end) тестирование (далее буду использовать термин e2e) приложения, которое состоит из нескольких микросервисов, микросервисы используют сторонние апи.

Знакомимся c проектом

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

Аккаунт можно создать только когда тебе есть 18 лет.

А в постах нельзя использовать матные слова. Если найдено матное слово — пост не будет создан.

Разные детали про проект

в проекте используется монорепозиторий
технологии: maven, Spring Boot, Hibernate, H2, Feign client (из Spring Cloud)
в целях упрощения туториала не используем никаких либ для миграции базы (liquibase, flyway) и создаем таблицы с помощью Hibernate
в целях упрощения в качестве базы используем in-memory базу H2
для примера используется приложение с двуми микросервисами, но их может быть и больше
e2e тесты лежат в отдельном модуле с названием e2e-tests
для запуска сервисов для e2e тестирования будем использовать Spring профиль с название ‘e2e’

Про сервисы и их обязанности

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

UserService — отвечает за все, что связано с пользователем.
PostService — отвечает за все, что связано с постами.
Age API — сторонний сервис, который помогает нашей соцсети узнать реальный возраст пользователя.
Word API — сервис, который помогает понять есть ли в тексте матные слова.

Краткое описание технологий для e2e тестирования

Для создания e2e тестов будут использованы следующие либы: JUnit 5, Wiremock 2, Cucumber 7, Awaitility 4.

Wiremock — для мокирования(имитации) http ответов. В нашем случае используем wiremock для мокирования ответов от сторонних API. Короткий пример (создаем мок для get запроса на получение пользователя с id 1):

wiremockServer.stubFor(get("/api/users/1").willReturn(aResponse() .withStatus(200) .withHeader("Content-Type", "application/json") .withBody(jsonHelper.fromObjectToString(user))) );

Cucumber — для создания удобного для чтения e2e теста. Короткий пример:

Функция: Снятие денег со счета Сценарий: Успешное снятие денег со счета Дано на счете пользователя имеется 1200 рублей Когда пользователь снимает со счета 200 рублей Тогда на счете пользователя имеется 1000 рублей

Awaitility — для создания проверок в нашем e2e тесте с условиями, которые могут выполниться не сразу, а через какое-то время. Короткий пример:

// сделали что-то с кастомером someCustomerService.doSomething(); // тут мы ждем 5 секунд и проверяем обновился ли статус кастомера await().atMost(5, SECONDS).until(customerStatusIsUpdated()); // или могли бы проверять обновился ли статус кастомера каждые // 2 секунды в течение 10 секунд Awaitility.await().atMost(10, TimeUnit.SECONDS) .pollInterval(2, TimeUnit.SECONDS) .until(customerStatusIsUpdated());

Проговариваем логику e2e теста

Цель протестировать весь жизненный цикл пользователя в нашей социальной сети.

Напомню, что в соцсети нельзя создавать акки, если тебе меньше 18 лет и нельзя использовать маты в постах.

Логика теста: пользователь создает аккаунт в соцсети (попробуем создать аккаунт для двух людей: одному есть 18 лет, другому нет) и ведет какую-то активность (создадим пару постов с матами и без) и в итоге решает удалить свой аккаунт.

Что нужно сделать для успешного выполнения e2e теста

Чтобы провести e2e тестирование нам нужно замокать все сторонние сервисы, в этом нам поможет Wiremock. Наши сервисы будут работать и ничего не подозревать о том, что сторонние API не настоящие. На диаграмме ниже можно увидеть, что сервисы соцсети обращаются к wiremock, а не к реальным апи.

Подготавливаем сервисы для e2e тестирования

Для ускорения выполнения e2e тестов можно использовать in-memory базы данных. В нашем примере мы так и делаем — используем H2 базу данных вместо, например, MySql.

Так же нужно чтобы http клиенты, которые используются для общения со сторонними API, можно было перенаправить на Wiremock (то есть нужно изменить хост и порт для сторонних API). При этом хотелось бы чтобы использовался тот же самый клиент что и для прода. В нашем примере это сделано через спринговые проперти.

В проекте нашей социальной сети для создания клиентов используется FeignClient (из Spring Cloud), но и для других либ для создания клиентов логика будет такая же.

Проперти в аппликейшен файле для e2e профиля с указанием хоста и порта Wiremock-a:

Читаем готовый e2e тест и разбираемся как писать свои

Наша цель создать легкочитаемый e2e тесты. Для этого мы используем либу Cucumber. А читабельное описание нашего теста будет храниться в файле с расширением .feature

Ниже готовый файл с шагами для нашего e2e теста:

Наш файл .feature содержит ключевые слова:
“Функция” — тут обычно пишут описание тестируемого функционала. В нашем случае у нас один тест, который тестит вообще всё приложение, поэтому я использовал подходящее описание.
“Сценарий” — название и краткое описание нашего e2e теста.
“Дано”, “Когда”, “Тогда” — это ключевые слова, которые мы используем для описания шагов теста.
Так же доступны такие ключевые слова: Допустим, Если, Затем, И, Иначе, Ктомуже, Но, Пусть, Также, То.

Напомню, что все эти ключевые слова это синтаксический сахар.

Плагин для файлов .feature

Для удобного редактирования файлов типа .feature нужно установить плагин. IntelliJ Idea подскажет установить его когда вы откроете файл типа .feature

Пишем в фича файле на русском языке

Название шагов на русском можно писать без каких-либо дополнительных настроек. А чтобы можно было использовать русские ключевые слова нужно в начале .feature файла добавить это:

# language: ru

Пример можно увидеть на скриншоте выше.

Создаем новый шаг в фича файле

Шаг, для которого еще нет кода, который будет выполняться, подсвечивается желтым цветом:

Если навести курсов на этот шаг или прожать Alt+Enter когда курсор стоит на этой строке, то можно увидеть такое меню

Тут идея предлагает создать так называем step definition или метод, который будет содержать код, который будет выполнен для этого шага во время теста.

Если кликнуть на ”Create step definition”, то появится такое меню

Я выбрал существующий файл ThirdPartyServicesStepsDefinitions, если у вас таких пока нет, то выбирайте первый вариант.

Для меня в классе был создан метод с аннотацией @Дано, а также название метода на русском (если вдруг не знали, то можно писать на java используя русский язык ��). В этом методе нужно будет поместить код для этого шага

Давайте посмотрим на то, что я положил в этот метод. Чтобы произошло то, что написано в названии этого шага, в коде мы должны замокать ответ от Age Api. Вот как это сделано:

Тут создается мок для POST запроса по урлу /is-person-adult а также добавлено условие, что в теле запроса должен быть определенный джисон.

Проверяем с помощью Awaitility условие, которое выполнится не сразу

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

В нашем e2e тесте Awaitility используется на шаге проверки того, что у пользователя больше нет постов в соцсети. Тут нам нужен Awaitility т к в нашей соцсети удаление пользователя и его постов занимает много времени.

В этом методе мы запускаем проверку того, что у пользователя больше нету постов. Каждые 2 секунды на протяжении 10 секунд Awaitility будет выполнять код из метода .until()

Если в течение 10 секунд лямбда из .until() не вернет true, то вылетит эксепшен и тест завалится.

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

Смотрим вспомогательный код для e2e теста

Код для реализации логики в шагах из фича файла:

в пакете src/main/java/org/example можно увидеть класс c кодом для запуска Spring Boot приложения (в нем выключены сервлеты чтобы запускался только spring контекст). Этот класс нужен нам т к без него не получится запустить e2e тест со spring контекстом, и значит не получится удобно и красиво инжектировать бины в классы.
в пакете src/test/java/org/example/common/client у нас клиенты для сервисов для проведения CRUD операций для постов и пользователей.
src/test/java/org/example/common/config — пакет с конфигами, про них чуть ниже.
класс JsonHelper это обертка для ObjectMapper для работы с джисонами.
класс TestContext это класс для удобного хранения и передачи данных между шагами теста, который в сути своей обычная мапа.
класс AbstractStepsDefinitions — содержит код, который будет использован всеми остальными StepsDefinitions классами

Конфиги для запуска e2e теста

BeanConfig — тут ничего особенного, он содержит методы для создания spring бинов (в этом классе мы создаем инстанс Wiremock сервера)
CucumberSpringConfiguration — класс для конфигурации application context (в нашем случае это Spring контекст) который будет подниматься при запуске .feature файлов.
EndToEndCucumberTestConfiguration — в этом классе содержатся настройки для запуска .feature файлов с помощью JUnit 5. Давайте пройдемся по аннотациям из этого класса т к они могу ввести в замешательство.

@Suite — это аннотация из JUnit 5 для создания класса-запускатора тестов

@IncludeEngines(«cucumber») — эта аннотация для добавления Cucumber engine (движка для запуска тестов созданных с использованием Cucumber).

@ConfigurationParameter(key = GLUE_PROPERTY_NAME, value = «org.example») — тут мы указываем местоположение джава классов со StepsDefinitions и также в пакете должен быть класс с аннотацией @CucumberContextConfiguration иначе будет ошибка

@ConfigurationParameter(key = FEATURES_PROPERTY_NAME, value = «src/test/resources/features/») — тут указываем путь к пакету с .feature файлами

Запуск сервисов и e2e теста

Запускаем сервисы с e2e профилем. В корне модуля для PostService (/social-network-java-spring-wiremock-cucumber-e2e-test/post-service) запускаем:

mvn spring-boot:run '-Dspring-boot.run.profiles=e2e'

Таким же образом запускаем UserService.

Запускаем тесты из консоли. Переходим в модул с e2e тестами (/social-network-java-spring-wiremock-cucumber-e2e-test/e2e-tests) и запускаем:

mvn clean install

Если у вас появились какие-то вопросы, пишите, отвечу или обновлю пост.

E2E-тестирование в CI с помощью Testcontainers

Спикер расскажет, что такое E2E-тесты, чем они отличаются от юнит-тестов и интеграционных тестов и почему являются неотъемлемой частью релизного цикла в микросервисных продуктах. На конкретном примере вы увидите, как писать свои E2E-тесты на JUnit5 + Spring Boot Test и настроить их автоматический запуск на каждый пул-реквест с помощью Testcontainers.

# docker
# e2e-testing
# integration testing
# java
# spring
# testcontainers