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

Что такое ИФТ простыми словами

ИФТ (интеграционное функциональное тестирование, Integration testing, I&T, ИТ) — это проверка взаимодействия двух и более модулей системы. В пирамиде тестирования интеграционные следуют после unit-тестов. 

Разберем, для чего нужен каждый из уровней:

1. Unit-тесты — проверка работы отдельного «юнита». Юнит-тесты проверяют работу отдельного компонента. Например, корзины оформления заказа.
2. Интеграционные — проверка взаимодействия между двумя модулями. При оформлении заказа в интернет-магазине нам нужны:

а) оплата; 

б) доставка специализированной службой. 

На этапе Integration testing проверяют данные: модуль корзины + модуль оплаты или модуль корзины + модуль службы доставки.

1. Е2Е-тесты — проверка в формате «от начала до конца», в том числе и на интеграцию с внешними интерфейсами. Сквозное End-to-end, E2E, Chain testing проверяет работу системы в целом.
2. UI-тесты — симуляция пользовательского пути и работы системы. 

Пирамида (Test Pyramid) выглядит так, потому что на уровне «внизу» юнит-тестов больше всего, но все они простые, а иногда пишутся в одну строчку. Чем выше уровень, тем меньше тестов на нем нужно (но тем они сложнее). Давайте разберемся, как эти уровни связаны друг с другом.

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

Затем включаем краны в квартире и смотрим, не упало ли давление (как взаимодействуют 2–3 крана). Или включаем стиральную машину и смотрим, набирает ли она воду (электрика + сантехника). Это и есть интеграционное тестирование. 

Где используется и что позволяет проверить

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

Интеграция UI и backend. Например, пользователь заполняет форму с данными на сайте. В ходе Integration testing проверяют, правильно ли фронтенд отправляет эти данные, как их обрабатывает и возвращает бэкенд и что получает пользователь.

Например, проверим, как взаимодействуют UI/UX сайта GitVerse и его бэкенд. После заполнения формы произвольными данными нажимаем «Войти» (идет отправка POST-запроса). Бэкэнд отвечает, что данные логин или пароль неверные (падает 401 ошибка). Она отображается на экране, а пользователь понимает: нужно перепроверить логин и пароль. Взаимодействие корректное, система работает в соответствии с той логикой, которую закладывали разработчики.

Интеграция бэкенда и базы данных. Проверяем, обновляется ли база данных по запросу (удаление, добавление записей и иные), корректно ли обрабатываются данные.

Интеграция модулей внутри системы. Тестируем, как взаимодействуют микросервисы между собой, монолиты и микросервис.

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

Например, есть сайт-агрегатор объявлений, авиабилетов, бронирования жилья, билетов в театр. Самостоятельно он ничего не продает и не бронирует. Каждый раз, когда пользователь нажимает «Заказать», происходит запрос к API поставщика — авиакомпании или владельца жилья. С каждым поставщиком у сайта налажен канал интеграции (с каждым сайтом свой). Работу «сайт-агрегатор — сайт-поставщик» также проверяют в рамках ИТ.

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

Выделяют разные виды ИФТ в зависимости от уровня, подходов и других критериев. Ниже разберем основные из них.

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

• ИТ «Большого взрыва» (Big Bang);
• нисходящее (сверху вниз);
• восходящее (снизу вверх);
• многослойное/гибридное (сэндвич, песочные часы). 

Нисходящее и восходящее ИТ — часть так называемого инкрементного подхода. Его суть сводится к тому, чтобы разделить целое на мелкие кусочки (части), которые будут протестированы по отдельности. 

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

Интеграционное тестирование «большого взрыва» (Big Bang)

Все программные модули подключаются и тестируются одновременно. Например, в случае с интернет-магазином это могут быть:

• три сервиса доставки в зависимости от выбора пользователя;
• четыре варианта приема платежей.

«Биг Бэнг» актуален для ситуаций, когда модули относительно независимы. Преимущество в том, что Integration testing «большого взрыва» позволяет сразу оценить систему, а не писать отдельные тесты на каждый модуль.

Но Big Bang не подходит для ситуации, когда все подключаемые модули «сырые» (не готовы к эксплуатации). 

Интеграционное тестирование сверху вниз

Нисходящее (Top-Down Approach) тестирование подходит для ситуаций, когда компоненты верхнего уровня зависят от модулей нижнего уровня. Методика «сверху вниз» эффективна для ситуаций, когда высокоуровневые компоненты зависят от модулей более низкого уровня. В результате можно разбить систему на мелкие участки и быстрее найти причину ошибок. 

Integration testing сверху вниз используют на проектах со сложной архитектурой программного обеспечения. 

Интеграционное тестирование снизу вверх

Восходящее (Bottom-Up Approach) тестирование подразумевает проверку, которая начинается с модулей низкого уровня и постепенно поднимается до высокоуровневых компонентов. Методика «Снизу вверх» эффективна для ситуаций, когда практически все модули уровня готовы. По результатам можно оценить, насколько продукт «сырой» и сколько над ним еще необходимо работать. 

Bottom-Up Approach позволяет локализовать ошибки и сэкономить время на тестах (в отличие от «Большого Взрыва»). Но существуют и минусы. В частности, критические модули верхнего уровня, которые контролируют поток приложения, могут содержать ошибки, но их проверяют последними.

Многослойное/гибридное интеграционное тестирование

Sandwich/Hybrid/Bi-Directional Approach — подход, который сочетает преимущества восходящего и нисходящего. IT-специалисты работают со «средним уровнем». В ходе тестов проверяют работу модулей верхнего и нижнего уровней. Для имитации отсеивающихся компонентов используют драйверы или заглушки.

Непрерывное интеграционное тестирование

Continuous Testing — тесты, которые работают в рамках CI/CD (continuous integration, continuous delivery/continuous deployment). Непрерывное тестирование может подразумевать не только интеграционные тесты, но и другие виды: базовый линтинг, smoke-, E2E-, security-, performance-тесты и иные. 

Если программист работает в локальной ветке, достаточно базовых проверок. Но когда происходит слияние (merge) с основной веткой или ветками других разработчиков, нужно Integration testing. В противном случае существует риск, что изменения данных затронут ветки других разработчиков или вообще станут причиной проблем у конечного клиента.

Какой тип ИТ выбрать, зависит от конкретного проекта и принятых на нем практик.

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

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

Postman

Используется для API-тестирования и предоставляет набор следующих возможностей:

• составлять техническую документацию;
• тестировать API для интеграции;
• запускать коллекции тестов и многое другое.

Библиотеки для тестирования

Известны десятки библиотек, с помощью которых проводят Unit или Integration testing. Для Java это Mockito, TestNG, AssertJ, Spring Test (в рамках Spring Framework), JUnit, Spring Framework. 

Тесты на JavaScript пишут с помощью библиотек или фреймворков Mocha, Jest, Jasmine, Karma, Puppeteer. 

Ниже пример теста API в среде разработки GigaIDE с использованием библиотеки Jest. 

AI-ассистент GigaCode может подробнее объяснить, что происходит в коде. Для этого нужно вызвать чат и выбрать хинт /explain или /explain step-by-step.

Возможности IDE — среды разработки

В среде разработки доступны инструменты для тестирования и документирования кода. Например, GigaIDE Desktop поддерживает работу с AI-ассистентом GigaCode. Умный помощник может писать тесты по запросу разработчика. Для этого нужно вызвать CodeChat и выбрать команду /test.

GigaCode умеет не только писать и объяснять и код. AI-ассистента можно попросить написать документацию (выбрать команду /doc).

Platform V Works API Mock & Contract Testing

Platform V Works API Mock & Contract Testing от команды SberTech — это сервис интеграционного тестирования API на контрактах и заглушках. 

Платформа позволяет:

• генерировать заглушки API;
• вести реестр заглушек для ускорения разработки приложений;
• проверять историю вызовов;
• обмениваться заглушками и делать многое другое.

Platform V Works API Mock & Contract Testing помогает решить проблемы, с которыми сталкиваются команды:

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

Как выглядит интеграционный полигон, где не используются эмуляции (заглушки):

Если со смежной системой что-то случается («падает», переустанавливается или вообще в разработке), интеграция не получится.

Как работает интеграционное тестирование с использованием Platform V Works API Mock & Contract Testing:

Platform V API Mock & Contract Testing эмулирует работу смежной системы и делает ее доступной на любой стадии интеграционного тестирования.

В отличие от Mock Servers Postman-a инструмент от команды SberTech поддерживает HTTP, Kafka, MQ и может поставляться российским пользователям on-premise.

Для приемки новых версий продуктов и управления качеством может пригодиться Platform V Works::TestCulture.

Существуют и другие инструменты, которые используются для тестирования на коммерческих проектах: Selenium, Beautiful Soup, Robotium, Watir, Katalon. Часто в вакансиях при поиске QA-инженеров можно встретить требования: опыт работы с системами контроля версий (Git и иными), в баг-трекинговых системах. Нелишним будет умение составлять техническую документацию, рисовать графики и диаграммы. Кстати, в среде разработки GigaIDE Desktop доступна функциональность создания UML-диаграмм, схем и т.д.

Разница между интеграционным и системным тестированием

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

Как писать интеграционные тесты на проекте

При выполнении ИТ используют стратегию ETVX:

• entry Criteria — критерии начала тестов интеграции;
• task — действия;
• validation — валидация;
• exit Criteria — критерии выхода.

Критерий начала IT — завершение модульного (юнит) тестирования. Для старта ИТ нужны:

• software requirements data — список требований;
• software design document — функциональные спецификации, технические детали программного продукта;
• software verification plan — план верификации и валидации;
• software integration documents — план тестов, тестовые случаи, сценарии.

Что должен сделать тестировщик для проведения ИТ:

1. Создать тест-кейсы и процедуры (test-cases and procedures). Для этого нужно понимать требования высокого и низкого уровня (High and Low-level requirements).
2. Разработать тестовое окружение интеграции с заглушками и драйверами (test-harness). TestDriver (драйвер) — это то, что вызывает тестируемый компонент. TestStub (мок, заглушка, стаб) — фиктивные данные, которые приходят в ответ на запрос. Драйверы и заглушки нужны, чтоб эмулировать работу системы.
3. Протестировать сборку. В случае успеха — объединить с другими сборками и продолжить работу.
4. Повторить все тесты на целевой платформе.

На выходе тестировщик получает правильную работу ПО (все элементы интегрированы корректно) и завершение интеграции. По итогам проведенного тестирования составляют integration test-reports (репорты) и SVCP — software test cases and procedures (тест-кейсы и процедуры).

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

Integration testing — это всегда о том, как взаимодействуют несколько блоков. 

Специфика проверки интеграции зависит от конкретного проекта и задачи. Например, это могут быть:

1. Заказы в интернет-магазине. Должны проверить корректность работы стороннего API и платежного шлюза.
2. Резервирование билетов на агрегаторе. Следует проверить взаимодействие системы с API конкретного продавца билетов.
3. Обработка платежей в интернет-банке. Нужно проверить, происходит ли списание средств и отображение чека после того, как пользователь подтвердил оплату и так далее.

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

Это упрощенный пример тест-кейса, описанный «на пальцах». На реальных проектах интеграционные тесты пишутся на десятки строк кода.

Выводы про интеграционное тестирование

1. Цель IT — проверить интеграцию двух и более компонентов.
2. Стабы (заглушки с фиктивными данными) и драйверы (тот, кто вызывает тестируемый компонент) — обязательные элементы. 
3. Выбор инструментов зависит от проекта (веб, приложение, микросервис, монолит), инфраструктуры, архитектуры и целей.