Интеграционные тесты

Что такое интеграционное тестирование? Зачем оно нужно? Примеры, подходы, стратегия и методологии...

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

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

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

• Подходы, стратегии, методологии интеграционного тестирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Интерфейсы программных модулей с базой данных могут быть ошибочными

• Внешние аппаратные интерфейсы, если таковые имеются, могут быть ошибочными

• Неправильная обработка исключений может вызвать проблемы.

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

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

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

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

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

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

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

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

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

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

  • Нисходящий подход (сверху вниз)

  • Подход «снизу вверх»

  • Сэндвич – комбинация «сверху вниз» и «снизу вверх»

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

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

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

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

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

Недостатки:

• Сложно локализовать баги.

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

• Недостаток времени для группы тестирования, т.к тестирование интеграции может начаться только после того, как все модули спроектированы.

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

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

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

• Снизу вверх

• Сверху вниз

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

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

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

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

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

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

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

• Проще локализовать ошибки.

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

Недостатки:

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

• Не возможно реализовать ранний прототип

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

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

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

• Проще локализовать баги.

• Возможность получить ранний прототип.

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

Недостатки:

• Нужно много пней.

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

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

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

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

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

1. Подготовка план интеграционных тестов

2. Разработка тестовых сценариев.

3. Выполнение тестовых сценариев и фиксирование багов.

4. Отслеживание и повторное тестирование дефектов.

5. Повторять шаги 3 и 4 до успешного завершения интеграции.

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

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

• Методы / Подходы к тестированию (об этом говорили выше).

• Области применения и Тестирование интеграции.

• Роли и обязанности.

• Предварительные условия для Интеграционного тестирования.

• Тестовая среда.

• Планы по снижению рисков и автоматизации.

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

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

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

• Модули и модульные компоненты

• Все ошибки с высоким приоритетом исправлены и закрыты

• Все модули должны быть заполнены и успешно интегрированы.

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

• Наличие необходимой тестовой среды

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

• Успешное тестирование интегрированного приложения.

• Выполненные тестовые случаи задокументированы

• Все ошибки с высоким приоритетом исправлены и закрыты

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

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

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

• Изучите архитектуру приложения и определите критические модули. Не забудьте проверить их на приоритет.

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

• После тестовых случаев именно тестовые данные играют решающую роль.

• Всегда имейте подготовленные данные перед выполнением. Не выбирайте тестовые данные во время выполнения тестовых случаев.