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

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

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

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

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

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

Недостатки:

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

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

Пользуется заглушками для тестирования.

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

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

Недостатки:

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

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

Подход Большого взрыва:
Здесь все компоненты объединены вместе в один раз , а затем тестируют.

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

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

Недостатки:

🔅 Локализация неисправностей сложна.
🔅 Учитывая огромное количество интерфейсов, которые необходимо протестировать в этом подходе, некоторые интерфейсы, которые нужно протестировать, могут быть легко пропущены.
Поскольку интеграционное тестирование может начаться только после того, как «все» модули спроектированы, у группы тестирования будет меньше времени для выполнения на этапе тестирования.
Поскольку все модули тестируются одновременно, критические модули высокого риска не изолируются и тестируются в приоритетном порядке. Периферийные модули, которые имеют дело с пользовательскими интерфейсами, также не изолированы и не проверены на приоритетность.

Читать более подробно: Интеграционное тестирование

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

Пример структуры комплекса программ - Интеграционное тестирование

https://youtube.com/playlist?list=PLKbJd47Kcbju2Vhi-FL7AI14vItVmGYk-

‼️
Полезная и актуальная информация

#курс

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

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

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

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

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

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

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

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

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


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

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

К. А. Кулаков, В. М. Димитров
🔹🔷
Основы тестирования
программного обеспечения
🔷🔹

Учебное электронное пособие - 57 стр

Содержание:
§ 1. Тестирование на этапах жизненного цикла проекта

§ 2. Проектирование и разработка тестов

§ 3. Структура документации тестирования

§ 4. Отчет об ошибке

§ 5. Статическое тестирование

§ 6. Динамическое тестирование

§ 7. Разработка через тестирование

Приложение. Пример практического задания

#пособие #книгипотестированию
#книги