Что такое интеграционное тестирование?
ИНТЕГРАЦИОННОЕ ТЕСТИРОВАНИЕ определяется как тип тестирования, при котором программные модули интегрируются логически и тестируются как группа. Типичный программный проект состоит из нескольких программных модулей, закодированных разными программистами. Целью данного уровня тестирования является выявление дефектов взаимодействия между этими программными модулями при их интеграции.
Интеграционное тестирование фокусируется на проверке обмена данными между этими модулями. Следовательно, оно также называется «I & T» (интеграция и тестирование), «тестирование строк» и иногда «тестирование потоков» .
- Что такое интеграционное тестирование?
- Почему Интеграционное Тестирование?
- Пример интеграционного теста
- Подходы, стратегии, методологии интеграционного тестирования
- Подход Большого взрыва:
- Инкрементальный подход
- Что такое заглушка и драйвер?
- Интеграция снизу вверх
- Интеграция сверху вниз:
- Интеграция гибрид / сэндвич
- Как сделать интеграционное тестирование?
- Краткое описание планов интеграционных испытаний:
- Критерии входа и выхода из интеграционного тестирования
- Лучшие практики / рекомендации по интеграционному тестированию
Почему Интеграционное Тестирование?
Хотя каждый программный модуль проходит модульное тестирование, дефекты все еще существуют по разным причинам, таким как
- Модуль, как правило, разрабатывается отдельным разработчиком программного обеспечения, чье понимание и логика программирования могут отличаться от других программистов. Интеграционное тестирование становится необходимым для проверки работы программных модулей в единстве
- Во время разработки модуля есть большие шансы на изменение требований со стороны клиентов. Эти новые требования могут не проходить модульное тестирование, и, следовательно, системная интеграция. Тестирование становится необходимым.
- Интерфейсы программных модулей с базой данных могут быть ошибочными
- Внешние аппаратные интерфейсы, если таковые имеются, могут быть ошибочными
- Неправильная обработка исключений может вызвать проблемы.
Нажмите здесь, если видео не доступно
Пример интеграционного теста
Интеграционный тестовый пример отличается от других тестовых примеров тем, что он сосредоточен в основном на интерфейсах и потоке данных / информации между модулями . Здесь приоритет должен быть отдан интегрирующим ссылкам, а не функциям блока, которые уже проверены.
Примеры тестовых примеров интеграции для следующего сценария: Приложение имеет 3 модуля, например «Страница входа», «Почтовый ящик» и «Удалить электронную почту», и каждый из них интегрирован логически.
Здесь не зацикливайтесь на тестировании страницы входа, как это уже было сделано в модульном тестировании . Но проверьте, как это связано со страницей почтового ящика.
Аналогично, почтовый ящик: проверьте его интеграцию с модулем удаления почты.
| Идентификатор теста | Цель теста | Описание теста | ожидаемый результат |
|---|---|---|---|
| 1 | Проверьте интерфейсную связь между модулем входа в систему и почтовым ящиком. | Введите учетные данные и нажмите кнопку «Войти» | Быть направленным в почтовый ящик |
| 2 | Проверьте интерфейсную ссылку между почтовым ящиком и модулем удаления почты. | Из почтового ящика выберите адрес электронной почты и нажмите кнопку удаления | Выбранное письмо должно появиться в папке «Удаленные / Корзина» |
Подходы, стратегии, методологии интеграционного тестирования
Программная инженерия определяет различные стратегии для проведения интеграционного тестирования, а именно.
- Подход Большого взрыва:
- Инкрементальный подход: который далее делится на следующие
- Нисходящий подход
- Подход «снизу вверх
- Сэндвич-подход — комбинация сверху вниз и снизу вверх
Ниже приведены различные стратегии, способы их выполнения и их ограничения, а также преимущества.
Подход Большого взрыва:
Здесь все компоненты объединены вместе в один раз , а затем тестируют.
Преимущества:
- Удобно для небольших систем.
Недостатки:
- Локализация неисправностей сложна.
- Учитывая огромное количество интерфейсов, которые необходимо протестировать в этом подходе, некоторые интерфейсы, которые нужно протестировать, могут быть легко пропущены.
- Поскольку интеграционное тестирование может начаться только после того, как «все» модули спроектированы, у группы тестирования будет меньше времени для выполнения на этапе тестирования.
- Поскольку все модули тестируются одновременно, критические модули высокого риска не изолируются и тестируются в приоритетном порядке. Периферийные модули, которые имеют дело с пользовательскими интерфейсами, также не изолированы и не проверены на приоритетность.
Инкрементальный подход
При таком подходе тестирование выполняется путем объединения двух или более логически связанных модулей . Затем другие связанные модули добавляются и тестируются для правильного функционирования. Процесс продолжается до тех пор, пока все модули не будут соединены и успешно протестированы.
Поэтапный подход, в свою очередь, осуществляется двумя разными методами:
- Вверх дном
- Сверху вниз
Что такое заглушка и драйвер?
Инкрементальный подход осуществляется с помощью фиктивных программ, называемых заглушками и драйверами . Заглушки и драйверы не реализуют всю логику программирования программного модуля, а только моделируют обмен данными с вызывающим модулем.
Заглушка : вызывается тестируемым модулем.
Драйвер : вызывает модуль для тестирования.
Интеграция снизу вверх
В восходящей стратегии каждый модуль на более низких уровнях тестируется с модулями более высокого уровня, пока не будут протестированы все модули. Требуется помощь драйверов для тестирования
Схематическое изображение :
Преимущества:
- Локализация ошибок проще.
- Не тратится время на ожидание разработки всех модулей, в отличие от подхода Большого взрыва
Недостатки:
- Критические модули (на верхнем уровне архитектуры программного обеспечения), которые контролируют поток приложения, тестируются последними и могут быть подвержены дефектам.
- Ранний прототип невозможен
Интеграция сверху вниз:
При подходе сверху вниз тестирование выполняется сверху вниз, следуя потоку управления программной системы.
Пользуется заглушками для тестирования.
Схематическое изображение:
Преимущества:
- Локализация неисправностей проще.
- Возможность получить ранний прототип.
- Критические Модули тестируются на приоритет; основные недостатки дизайна могут быть найдены и исправлены в первую очередь.
Недостатки:
- Нужно много пней.
- Модули на более низком уровне тестируются неадекватно.
Интеграция гибрид / сэндвич
В стратегии сэндвич / гибрид представляет собой комбинацию подходов сверху вниз и снизу вверх. Здесь верхние модули тестируются с нижними модулями, а нижние модули интегрируются с верхними модулями и тестируются. Эта стратегия использует заглушки, а также драйверы.
Как сделать интеграционное тестирование?
Процедура тестирования интеграции независимо от стратегий тестирования программного обеспечения (обсуждаемых выше):
- Подготовьте план интеграционных тестов
- Разработка тестовых сценариев, случаев и сценариев.
- Выполнение тестовых случаев с последующим сообщением о дефектах.
- Отслеживание и повторное тестирование дефектов.
- Шаги 3 и 4 повторяются до успешного завершения интеграции.
Краткое описание планов интеграционных испытаний:
Включает в себя следующие атрибуты:
- Методы / Подходы к тестированию (как обсуждено выше).
- Области применения и вне областей Тестирование интеграции.
- Роли и обязанности.
- Предварительные условия для Интеграционного тестирования.
- Тестовая среда.
- Планы по снижению рисков и снижению рисков.
Критерии входа и выхода из интеграционного тестирования
Критерии входа и выхода на этапе тестирования интеграции в любой модели разработки программного обеспечения
Критерии входа:
- Модульные компоненты и модули
- Все ошибки с высоким приоритетом исправлены и закрыты
- Все модули должны быть заполнены и успешно интегрированы.
- Интеграционные тесты План, тестовый набор, сценарии, которые должны быть подписаны и задокументированы.
- Необходимая среда тестирования, которая будет настроена для тестирования интеграции
Критерии выхода:
- Успешное тестирование интегрированного приложения.
- Выполненные тестовые случаи задокументированы
- Все ошибки с высоким приоритетом исправлены и закрыты
- Технические документы должны быть представлены после выпуска Примечания.
Лучшие практики / рекомендации по интеграционному тестированию
- Сначала определите стратегию интеграционных тестов, которая может быть принята, а затем подготовьте тестовые наборы и соответственно протестируйте данные.
- Изучите Архитектурный дизайн Приложения и определите Критические Модули. Они должны быть проверены на приоритет.
- Получите проекты интерфейсов от команды Architectural и создайте контрольные примеры для проверки всех интерфейсов в деталях. Интерфейс к базе данных / внешнему оборудованию / программному обеспечению должен быть детально протестирован.
- После тестовых случаев именно тестовые данные играют решающую роль.
- Всегда имейте подготовленные данные перед выполнением. Не выбирайте тестовые данные во время выполнения тестовых случаев.