Подвид тестирования интеграции
Интеграционное тестирование начинается после юнит-тестирования и предваряет системное (или приемочное) тестирование. Программные «блоки» интегрируются друг с другом, и проверяется их взаимодействие.
Может быть два подхода, когда сначала интегрируют и проверяют низкоуровневые компоненты, во втором — наоборот, идут сверху вниз, сначала высокоуровневые. Существует еще один подход — Большого Взрыва.
Подробный гайд по интеграционному тестированию со схемами
Почему Big Bang
Принцип «Большого Взрыва» — гибридный метод, когда компоненты тестируют не инкрементально, то есть не последовательно, а как бы одномоментно. В этом заключается отличие от инкрементной интеграции, при которой компоненты проверяют последовательно небольшими группами от крупных к маленьким, или наоборот. Подход Большого Взрыва обычно используется в тех случаях, когда сроки сдачи ограничены, и работает несколько мало пересекающихся команд.
Например, простая система, состоящая из компонентов A, B, C. Компонент A протестировали и признали пригодным, так же B и C. Теперь все три компонента объединяются и тестируются вместе одномоментно (как Вселенная при Большом Взрыве).
Часто такой подход может быть единственным возможным, если система не подходит для тщательного инкрементального тестирования, а сроки поджимают.
Характеристики
- Симуляция системы: Предполагает симулирование системы в ее целостности.
- Проверка всех частей системы: Позволяет быстро проверить взаимодействия между компонентами.
- Полное тестирование: По большому счету не остается непроверенных компонентов.
- Раннее выявление дефектов: Позволяет выявить дефекты на сравнительно ранних этапах разработки. И исправить их до релиза.
- Проверка сложных взаимодействий: Которые могут быть слабо доступны для других методов.
- Симуляция низкоуровневых компонентов: Используются стабы и моки для имитации низкоуровневых компонентов.
- Подход сверху вниз: Чаще процесс идет в какой-то мере последовательно и логично, от высокоуровневых до низкоуровневых компонентов.
- Простейшая форма тестирования интеграции: Базовая форма, доступная всем членам команды.
- Риски: Метод не рекомендуется в исключительно важных и сложных проектах.
- Эрзац системного: Может быть использовано для первичной проверки системы как целого.
- Вручную: Поскольку автоматизировать проверку всех компонентов может быть затруднительно.
Схема
Ниже диаграмма процессов.
- Компоненты A и D тестируются по отдельности.
- Компонент C объединяется с компонентом B, компонент F объединяется с компонентом E.
- Тестируется компонент A, затем B(+С), затем D и, наконец, E(+F).
- После того как все модули протестированы, они объединяются в систему и проверяется ее функциональность.
Преимущества
- Простота: Как уже говорилось, базовый тип тестирования.
- Скорость: Легко реализовать, все компоненты уже есть.
- Ошибки можно выявить быстро: Множество дефектов проявятся одномоментно «за один ход».
- В небольших проектах: Которые легко интегрировать.
- Проверка интерфейсов: Тестирование работы интерфейсов между компонентами.
- Экономия времени и денег: Позволяет сэкономить благодаря вышеперечисленному.
- Обнаружение скрытых зависимостей: Позволяет выявить неявные зависимости между компонентами, незаметные при инкрементальном подходе.
- Упрощение процессов: За счет отсутствия необходимости устанавливать и настраивать много тестовых окружений.
Ограничения
- Возможные задержки: Перед началом процесса все компоненты должны быть готовы. Если это не так, или если какой-то компонент оказался проблемным, подход может привести к задержкам.
- Сложность выявления причины дефектов: При совместном тестировании интегрированных модулей бывает трудно найти первопричину проблем.
- Повышение рисков: Возможно снижение качества ПО из-за быстрого не очень тщательного тестирования отдельных групп компонентов.
- Ограниченная масштабируемость: Для сложных проектов с большим количеством модулей.
- Ограниченная видимость: При неинкрементном тестировании проект таит в себе риски «спящих» низкоуровневых дефектов, которые будут оставаться незамеченными до релиза.
