Следите за нашими новостями на Facebook! Всегда что-нибудь интересное ;)
Будьте в курсе!
Подпишитесь на нашу рассылку, и мы будем присылать вам интересные статьи, анонсы и новости.

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

09 июня 2020
  • Что такое интеграционное тестирование?
  • Зачем нужно интеграционное тестирование?
  • Примеры интеграционного тестирования
  • Подходы, стратегии, методологии интеграционного тестирования
  • Подход Большого взрыва
  • Инкрементальный подход
  • Заглушка и драйвер
  • Интеграция снизу вверх
  • Интеграция сверху вниз
  • Сэндвич (гибридная интеграция)
  • Как сделать интеграционное тестирование?
  • Атрибуты Интеграционного тестирования
  • Критерии старта и окончания Интеграционного тестирования
  • Лучшие практики / рекомендации по Интеграционному тестированию

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

Интеграционное тестирование - это тип тестирования, при котором программные модули объединяются логически и тестируются как группа. Как правило, программный продукт состоит из нескольких программных модулей, написанных разными программистами. Целью нашего тестирования является выявление багов при взаимодействии между этими программными модулями и в первую очередь направлен на проверку обмена данными между этими самими модулями. Именно поэтому оно также называется «I & T» (интеграция и тестирование), «тестирование строк» и иногда «тестирование потоков».

Зачем нужно интеграционное тестирование?
Модульное тестирование
Unit Testing
Интеграционное тестирование
Integration Testing
Системное тестирование
System Testing
Приемочное тестирование
Acceptance Testing
Каждый программный модуль проходит отдельные этапы тестирования (модульное тестирование), но не смотря на это, дефекты могут оставаться по ряду причин:

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

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

Интеграционное тестирование отличается от других видов тестирования тем, что он сосредоточен в основном на интерфейсах и потоке данных (между модулями). Здесь приоритет проверки присваивается интегрирующим ссылкам, а не функциям блока, которые уже проверены.

Пример тестирования интеграции для следующего сценария:
Приложение имеет 3 модуля, например «Страница входа», «Почтовый ящик» и «Удалить электронную почту». Каждый из них интегрирован логически.

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

Аналогично, «Почтовый ящик»: проверьте его интеграцию с модулем «Удалить электронную почту».
Стратегии, методологии и подходы в интеграционном тестировании

Программная инженерия задает различные стратегии интеграционного тестирования:
  • Подход Большого взрыва.
  • Инкрементальный подход:
    • Нисходящий подход (сверху вниз)
    • Подход «снизу вверх»
    • Сэндвич - комбинация «сверху вниз» и «снизу вверх»
Ниже приведены различные стратегии, способы их выполнения и их ограничения, а также преимущества.

Подход Большого взрыва

Здесь все компоненты собираются вместе, а затем тестируются.

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

Инкрементальный подход


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

Заглушка и драйвер


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

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

Интеграция «снизу вверх»

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

Преимущества:
  • Проще локализовать ошибки.
  • Не тратится время на ожидание разработки всех модулей, в отличие от подхода Большого взрыва.
Недостатки:
  • Критические модули (на верхнем уровне архитектуры программного обеспечения), которые контролируют поток приложения, тестируются последними и могут быть подвержены дефектам.
  • Не возможно реализовать ранний прототип

Интеграция «сверху вниз»


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

Преимущества:
  • Проще локализовать баги.
  • Возможность получить ранний прототип.
  • Критические Модули тестируются на приоритет; основные недостатки дизайна могут быть найдены и исправлены в первую очередь.
Недостатки:
  • Нужно много пней.
  • Модули на более низком уровне тестируются неадекватно

Сэндвич (гибридная интеграция)

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

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

Алгоритм интеграционного тестирования:
  1. Подготовка план интеграционных тестов
  2. Разработка тестовых сценариев.
  3. Выполнение тестовых сценариев и фиксирование багов.
  4. Отслеживание и повторное тестирование дефектов.
  5. Повторять шаги 3 и 4 до успешного завершения интеграции.

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

Включает в себя следующие атрибуты:
  • Методы / Подходы к тестированию (об этом говорили выше).
  • Области применения и Тестирование интеграции.
  • Роли и обязанности.
  • Предварительные условия для Интеграционного тестирования.
  • Тестовая среда.
  • Планы по снижению рисков и автоматизации.

Критерии старта и окончания интеграционного тестирования

Критерии входа и выхода на этап Интеграционного тестирования, независимо от модели разработки программного обеспечения

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

Критерии окончания:
  • Успешное тестирование интегрированного приложения.
  • Выполненные тестовые случаи задокументированы
  • Все ошибки с высоким приоритетом исправлены и закрыты
  • Технические документы должны быть представлены после выпуска Примечания.

Лучшие практики / рекомендации по интеграционному тестированию

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

Статья подготовлена на основе материалов сайта guru99.com