Что такое интеграционное тестирование? (Пример)

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

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

Интеграционное тестирование направлено на проверку обмена данными между этими модулями. Поэтому его еще называют 'ЭТО' (Интеграция и тестирование), «Тестирование строк» а иногда «Тестирование потоков».

Зачем проводить интеграционное тестирование?

Хотя каждый программный модуль проходит модульное тестирование, дефекты по-прежнему существуют по разным причинам, например

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

Нажмите здесь если видео недоступно

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

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

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

Здесь не стоит слишком концентрироваться на тестировании страницы входа, как это уже было сделано в Модульное тестирование. Но проверьте, как это связано с Mail Box Страница.

Аналогичным образом Mail Box: проверьте его интеграцию с Удалить MailМодуль s.

Идентификатор тестового случая	Цель тестового примера	Тестовый кейс Descriptион	ожидаемый результат
1	Проверьте интерфейсную связь между входом в систему и Mailкоробчатый модуль	Введите учетные данные для входа и нажмите кнопку «Войти».	Чтобы быть направленным в Mail Box
2	Проверьте интерфейсную связь между Mailполе и удалить Mailс Модуль	от Mailв поле выберите адрес электронной почты и нажмите кнопку «Удалить»	Выбранное электронное письмо должно появиться в папке «Удаленные/Корзина».

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

Разработка программного обеспечения определяет различные стратегии выполнения интеграционного тестирования, а именно.

• Подход «большого взрыва»:
• Поэтапный подход: который далее делится на следующие
  • Нисходящий подход
  • Подход «снизу вверх
  • Сэндвич-подход – сочетание сверху вниз и снизу вверх

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

Испытание Большого Взрыва

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

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

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

Минусы:

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

Инкрементное тестирование

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

Инкрементный подход, в свою очередь, осуществляется двумя разными методами:

• Вверх дном
• Сверху вниз

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

Заглушки и драйверы — это фиктивные программы в интеграционном тестировании, используемые для облегчения тестирование программного обеспечения активность. Эти программы заменяют отсутствующие в тестировании модели. Они не реализуют всю логику программирования программного модуля, но имитируют обмен данными с вызывающим модулем во время тестирования.

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

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

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

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

Схематическое представление:

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

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

Минусы:

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

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

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

Схематическое изображение:

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

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

Минусы:

• Требуется много заглушек.
• Модули более низкого уровня тестируются неадекватно.

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

Процедура интеграционного тестирования независимо от стратегии тестирования программного обеспечения (обсуждаемой выше):

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

Слип/Классические DescriptИон планов интеграционного тестирования

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

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

Критерии входа и выхода из интеграционного тестирования

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

Критерии входа:

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

Критерии выхода:

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

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

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