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

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

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

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

Зачем нужно интеграционное тестирование?

Каждый программный модуль проходит отдельные этапы тестирования (модульное тестирование), но не смотря на это, дефекты могут оставаться по ряду причин:

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

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

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

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

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

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

Стратегии, методологии и подходы в интеграционном тестировании

Программная инженерия задает различные стратегии интеграционного тестирования:

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

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

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

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

Преимущества:

• Удобно для небольших систем.
  

Недостатки:

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

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

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

• Снизу вверх
• Сверху вниз
  

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

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

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

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

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

Преимущества:

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

Недостатки:

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

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

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

Преимущества:

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

Недостатки:

• Нужно много пней.
• Модули на более низком уровне тестируются неадекватно

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

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

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

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

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

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

Включает в себя следующие атрибуты:

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

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

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

Критерии старта:

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

Критерии окончания:

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

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

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

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