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