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

Основные типы интеграций:

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

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

В одном из проектов я проводила E2E-тестирование, которое было завершающим этапом проверки. Необходимо было убедиться, что весь процесс — от создания статьи до её публикации на основном источнике — работает корректно, то есть протестировать реальные сценарии взаимодействия пользователей с системой.

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

E2E-тестирование — это самый длительный и трудоёмкий этап, который требует значительных ресурсов и времени. Наша команда старалась автоматизировать этот процесс, но это оказалось непростой задачей. Например, для интеграции одной системы с другой занимало в среднем 70 минут (нужно было дождаться создания и назначения ID сущности (статьи)) .

Есть несколько способов, как системы могут взаимодействовать между собой:

Пример: Система A отправляет запрос в систему B через брокер сообщений, чтобы передать данные для дальнейшей обработки.

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

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

2. Интеграция между логикой авторизации и микросервисом уведомлений: Когда пользователь проходит авторизацию в приложении, микросервис авторизации подтверждает его личность и передает результат другому микросервису, который отвечает за уведомления. Этот микросервис отправляет пользователю уведомление об успешном входе через e-mail или push-уведомление.

1. Интеграция с внешними платежными сервисами: После того как пользователь добавляет товары в корзину и переходит к оплате, система e-commerce взаимодействует с внешним платежным шлюзом (например, PayPal или Stripe). После отправки данных о транзакции внешний сервис обрабатывает оплату, а система интернет-магазина получает ответ о статусе: успешный платеж или ошибка.

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

На каждом этапе проверяются:

Хочу поблагодарить за вопросы, которые пишите в директ, это тоже опыт для меня. И вот был следующий вопрос: "Добрый день! Подскажите, что значит высокоуровневые и низкоуровневые модули?" после того как я запостила информацию про расшифровку понятий. И тут я поняла, что общими фразами как-то понятно , но нет примеров... Согласны?

Давайте разберемся.

Интеграционное тестирование - тестирование связи между модулями и тестирование связи между частями ПО.

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

Driver, Stub - эмулируемые компоненты системы.

#Драйвер (Driver) - это заглушка, которая отправляет запросы к нашей тестируемой системе (или другим образом управляет).

#Заглушка (Stub) - это заглушка, которая получает запросы от системы и отправляет какой-то "вшитый" ответ.

И заглушки, и драйверы являются фиктивными модулями и создаются только для тестовых целей.

#Заглушки используются при тестировании сверху вниз, когда основной модуль готов к тестированию, но подмодули еще не готовы. Таким образом, на простом языке заглушки - это «вызываемые» программы, которые вызываются для проверки функциональности основного модуля. Например, в ситуации, когда у одного есть три разных модуля: Login, Home, User. Предположим, модуль входа в систему готов к тестированию, но два второстепенных модуля Home и User, которые вызываются модулем входа, еще не готовы для тестирования. В это время написан кусок фиктивного кода, который имитирует вызываемые методы Home и User. Эти фиктивные фрагменты кода являются заглушками. Или Например, ситуация, в которой веб-приложение готово, но база данных ещё не готова, и вместо базы данных делают временно заглушку. Вместо базы данных будет использована заглушка.

#Драйверы являются «вызывающими» программами. Драйверы используются при восходящем тестировании (Снизу вверх). Драйверы - это фиктивный код, который используется, когда подмодули готовы, но основной модуль еще не готов. Возьмем тот же пример, что и выше. Предположим, на этот раз модули User и Home готовы, но модуль Login не готов к тестированию. Теперь, когда Home и User возвращают значения из модуля Login, создается фиктивный фрагмент кода, имитирующий модуль Login. Этот фиктивный код затем называется Driver.

Пример: https://ru.abcdef.wiki/wiki/Test_stub

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