Интеграционное тестирование: что это такое, виды и методы проведения

Что такое интеграционное тестирование

Интеграционное тестирование — проверка того, как объединённые компоненты программной системы работают вместе. Согласно глоссарию ISTQB (международная организация по квалификации специалистов в области тестирования ПО), его цель — выявить дефекты на стыках: некорректная передача данных, несовместимость интерфейсов, нарушение логики при совместной работе модулей. Тестирование интеграции проверяет совместимость интерфейсов и надёжность системы как целого.

Разработчик пишет модульные тесты — проверяет единицу кода в изоляции. QA-инженер подключается позже, когда компоненты уже объединены: нужно убедиться, что данные передаются правильно, API отвечает корректно, а бизнес-логика не ломается на стыке сервисов.

Уровни тестирования: unit, интеграционное, системное

Интеграционное тестирование занимает второй уровень в пирамиде проверки ПО — выше модульного, ниже системного и сквозного.

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

Виды интеграций: что проверяем

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

Внутренние интеграции

Внутренние интеграции — связи между компонентами одной системы. Четыре основных вида:

• Фронтенд ↔ бэкенд. Пользователь применяет фильтр в каталоге — фронтенд отправляет запрос через REST API, бэкенд возвращает отфильтрованные данные. Тест проверяет: передаются ли правильные параметры, корректен ли формат ответа.
• Бэкенд ↔ база данных. При регистрации бэкенд записывает строку в таблицу. Тест — убедиться, что запись появилась и поля заполнены корректно.
• Микросервис ↔ микросервис. Сервис заказов обращается к сервису геолокации за координатами точки доставки.
• Микросервис ↔ брокер сообщений. Сервис уведомлений получает событие из очереди брокера (Kafka или RabbitMQ) и отправляет push-уведомление.

Внешние интеграции

Внешние интеграции — подключение к сторонним сервисам: OAuth-авторизации (Яндекс ID, ВКонтакте), платёжному шлюзу, картам. Реальные токены и реальные деньги при тестировании не используют — провайдеры предоставляют тестовую среду.

Для OAuth пишут два тест-кейса: позитивный (корректный токен, успешная авторизация) и негативный (просроченный или недействительный токен, ожидаемая ошибка). Банковский эквайринг тестируют на тестовых картах YooMoney или Cloudpayments: проверяют успешную оплату, отклонение по лимиту, сценарий возврата.

Методы интеграционного тестирования

Метод выбирают в зависимости от архитектуры системы, готовности компонентов и сроков. Основных подходов четыре: «большой взрыв», восходящий, нисходящий и сэндвич.

Если хотите системно разобраться с практикой работы со сложными ИТ-системами — в рамках нацпроекта «Кадры» можно пройти программу «Специалист по информационным системам: от организации до сопровождения ИТ-проектов» бесплатно, без отрыва от работы.

«Большой взрыв» и инкрементальный метод

Big Bang («большой взрыв») — все модули объединяются и тестируются одновременно. На практике используется чаще остальных: быстро, не требует заглушек. Главный минус — при обнаружении дефекта сложно понять, какой компонент дал сбой.

Инкрементальный метод — постепенное подключение модулей. Начинают с двух, тестируют связку, затем добавляют третий. Два направления:

• Восходящий (bottom-up): тестирование от низкоуровневых модулей к высокоуровневым. Вместо верхних, ещё не подключённых модулей используют драйверы.
• Нисходящий (top-down): от высокоуровневых к низкоуровневым. Вместо нижних модулей — заглушки.

Сэндвич-метод

Сэндвич-метод — одновременное применение восходящего и нисходящего тестирования. Одна команда движется снизу вверх, другая — сверху вниз, встречаясь на среднем уровне. Второе название — «песочные часы». Метод сочетает скорость инкрементального подхода и точность локализации, но требует чёткой координации двух команд.

Заглушки и драйверы: инструменты изоляции при тестировании

При инкрементальном тестировании часть модулей ещё не готова. Чтобы не ждать — используют заглушки и драйверы. Оба термина закреплены в глоссарии ISTQB.

Заглушка — «подставной» модуль на месте того, кого вызывают. Драйвер — на месте того, кто вызывает. Управление зависимостями через мок-серверы и заглушки — базовый инструмент QA-инженера: без него проверять компоненты по отдельности практически невозможно.

Как проводить интеграционное тестирование: пошаговый процесс

Процесс состоит из семи шагов.

1. Дождаться unit-тестов. Интеграционные тесты запускают только после успешного прохождения модульных — иначе непонятно, дефект в самом модуле или на стыке.
2. Составить план. Определить, какие интеграции проверять, в каком порядке, какие тестовые данные потребуются.
3. Настроить тестовое окружение. Поднять изолированную среду через Docker — без этого тесты могут повлиять на продакшн или мешать друг другу.
4. Написать тест-кейсы. Для каждой интеграции — позитивный сценарий (данные переданы корректно) и негативный (ошибка обработана правильно).
5. Провести тестирование. Postman — для API-запросов, Jaeger — для трассировки в микросервисах, DBeaver — для валидации передачи данных в базе.
6. Документировать результаты. Фиксировать дефекты с шагами воспроизведения, ожидаемым и фактическим результатом.
7. Локализовать баг. Определить точный компонент или стык, где возник дефект, и передать разработчику с описанием.

Инструменты интеграционного тестирования

Инструменты подбирают под задачу: трассировка в микросервисах, API-тестирование, проверка базы данных, работа с брокерами сообщений, просмотр логов или создание заглушек. Разберём по категориям.

Jaeger: трассировка запросов в микросервисах

Jaeger — инструмент распределённой трассировки: отображает путь HTTP-запроса по всем микросервисам системы и помогает точно локализовать дефект.

Два ключевых понятия:

• Спан (span) — одна операция внутри компонента: например, запрос к базе данных.
• Трейс (trace) — полный маршрут запроса, совокупность всех спанов от входа до выхода.

Как работать: из заголовков HTTP-ответа берут trace ID и вводят в интерфейс Jaeger. Система строит граф — видно, какой сервис сколько времени занял и где возникла ошибка. В отличие от Kibana, где логи каждого сервиса хранятся отдельно, Jaeger даёт единую картину маршрута запроса, что ускоряет локализацию дефектов в микросервисной архитектуре.

Postman, Docker и инструменты для брокеров и БД

Postman решает две задачи: отправка API-запросов для ручного и автоматизированного тестирования, а также создание Mock Server — заглушки для ещё не готового API. Удобно тестировать фронтенд до завершения бэкенда.

Docker поднимает изолированное тестовое окружение за несколько команд. Docker Compose позволяет запустить все сервисы локально и просматривать их логи в одном терминале.

DBeaver — визуальный клиент баз данных. После теста регистрации или транзакции открывают таблицу и проверяют: запись появилась, поля заполнены корректно.

Для брокеров сообщений — Offset Explorer или Kafka UI (для Kafka), RabbitMQ Management (для RabbitMQ): позволяют убедиться, что сообщение дошло от producer к consumer.

Инструменты для просмотра логов

Типичные проблемы интеграционного тестирования и как их решать

В работе QA-инженера на этом уровне встречаются пять типичных трудностей.

Сложность настройки окружения. Воспроизвести конфигурацию всех сервисов вручную долго и ненадёжно. Решение — Docker и инфраструктура как код (IaC): среда поднимается одной командой, идентично на каждой машине.

Управление зависимостями. Один модуль изменился — тест сломался, хотя интеграция в порядке. Помогают заглушки с фиксированными контрактами и версионирование API.

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

Долгое выполнение тестов. В больших системах интеграционные тесты занимают минуты. Решение — параллельный запуск через TestNG и приоритизация критических интеграций в конвейере непрерывной интеграции (CI/CD).

Ложные следы при локализации. Дефект проявляется в одном компоненте, а причина — в другом. Помогает строгое документирование тест-кейсов и изоляция каждого теста.

Часто задаваемые вопросы

Что такое ИФТ в тестировании?

ИФТ — интеграционное функциональное тестирование: проверка взаимодействия компонентов системы с фокусом на бизнес-логике. ИФТ-стенд — изолированная тестовая среда, отдельная от продакшна, на которой проводится тестирование интеграций.

Чем интеграционное тестирование отличается от модульного?

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

Какие инструменты используются для интеграционного тестирования?

Postman — API и мок-серверы; Jaeger — трассировка в микросервисах; DBeaver — проверка базы данных; Docker — тестовое окружение; Kibana, Graylog, Sentry — логи; WireMock и Mockoon — заглушки; Kafka UI и RabbitMQ Management — брокеры сообщений.

Что такое заглушка и драйвер в тестировании?

Заглушка имитирует вызываемый модуль — используется, когда зависимый сервис не готов. Драйвер имитирует вызывающий модуль — когда не готов интерфейс, инициирующий вызов. Оба термина закреплены в ISTQB-глоссарии.

Когда проводится интеграционное тестирование?

После успешного завершения unit-тестов и до системного тестирования. В CI/CD-пайплайне: unit → интеграционное → системное → деплой. В Agile-разработке оно поддерживает непрерывную интеграцию и выявляет регрессии на каждом спринте.

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

Jaeger — инструмент трассировки, отображающий путь HTTP-запроса по микросервисам. Спан — одна операция, трейс — полный маршрут запроса. По trace ID из HTTP-заголовка тестировщик точно локализует компонент с ошибкой без просмотра логов каждого сервиса отдельно.

В чём разница между восходящим и нисходящим тестированием?

Восходящее (bottom-up) — тестирование от низкоуровневых модулей к высокоуровневым. Нисходящее (top-down) — наоборот. Сэндвич-метод («песочные часы») объединяет оба подхода одновременно, балансируя скорость и точность локализации дефектов.

Как начать проводить интеграционное тестирование с нуля?

Освойте Postman для API-запросов, DevTools для мониторинга сети, DBeaver для баз данных. Изучите заглушки и тест-кейсы по ISTQB-глоссарию. Программа «Специалист по информационным системам: от организации до сопровождения ИТ-проектов» (бесплатно, нацпроект «Кадры») даёт системную базу работы со сложными ИТ-системами.