ИНТЕГРАЦИОННОЕ ТЕСТИРОВАНИЕ
- Жусупов Тамерлан
- 18 апр. 2021 г.
- 5 мин. чтения
Обновлено: 19 апр. 2021 г.
INTEGRATION TESTING
Интеграционное тестирование — одна из фаз тестирования программного обеспечения, при которой отдельные программные модули объединяются и тестируются в группе.
Интеграционное тестирование в качестве входных данных использует модули, над которыми было проведено модульное тестирование, группирует их в более крупные множества, выполняет тесты, определённые в плане тестирования для этих множеств, и представляет их в качестве выходных данных и входных для последующего системного тестирования. Обычно интеграционное тестирование проводится после модульного тестирования и предшествует системному тестированию.
ЦЕЛЬ ИНТЕГРАЦИОННОГО ТЕСТИРОВАНИЯ
Целью интеграционного тестирования является проверка соответствия проектируемых единиц функциональным, приёмным и требованиям надежности. Тестирование этих проектируемых единиц — объединения, множества или группы модулей — выполняется через их интерфейс, с использованием тестирования «чёрного ящика».
Основная задача — поиск дефектов, связанных с ошибками в реализации и интерпретации взаимодействия между модулями. На следующем рисунке показана схема интеграционного тестирования:
Подходы, стратегии, методологии интеграционного тестирования:
Подход Большой Взрыв
Инкрементальный подход:
Метод Снизу Вверх
Метод Сверху Вниз
Смешанный подход – сэндвич
Ниже приведены различные стратегии, способы их выполнения и их ограничения, а также преимущества.
Подход Большого взрыва
Здесь все компоненты собираются вместе, а затем тестируются.
Преимущества:
Удобно для небольших систем.
Недостатки:
Сложно локализовать баги.
Учитывая огромное количество интерфейсов, некоторые из них при тестировании можно запросто пропустить.
Недостаток времени для группы тестирования, т.к тестирование интеграции может начаться только после того, как все модули спроектированы.
Поскольку все модули тестируются одновременно, критические модули высокого риска не изолируются и тестируются в приоритетном порядке. Периферийные модули, которые имеют дело с пользовательскими интерфейсами, также не изолированы и не проверены на приоритет.
Инкрементальный подход
В данном подходе тестирование выполняется путем объединения двух или более логически связанных модулей. Затем добавляются другие связанные модули и проверяются на правильность функционирования. Процесс продолжается до тех пор, пока все модули не будут соединены и успешно протестированы. Поэтапный подход, в свою очередь, осуществляется двумя разными методами:
Снизу вверх
Сверху вниз
Заглушка и драйвер
Инкрементальный подход осуществляется с помощью фиктивных программ, называемых заглушками и драйверами. Заглушки и драйверы не реализуют всю логику программного модуля, а только моделируют обмен данными с вызывающим модулем.
Заглушка: вызывается тестируемым модулем. Драйвер: вызывает модуль для тестирования.
Интеграция «снизу вверх»
В восходящей стратегии каждый модуль на более низких уровнях тестируется с модулями более высоких уровней, пока не будут протестированы все модули. Требуется помощь драйверов для тестирования
Преимущества:
Проще локализовать ошибки.
Не тратится время на ожидание разработки всех модулей, в отличие от подхода Большого взрыва.
Недостатки:
Критические модули (на верхнем уровне архитектуры программного обеспечения), которые контролируют поток приложения, тестируются последними и могут быть подвержены дефектам.
Невозможно реализовать ранний прототип
Интеграция «сверху вниз»
При подходе «сверху вниз» тестирование, что логично, выполняется сверху вниз, следуя потоку управления программной системы. Используются заглушки для тестирования.
Преимущества:
Проще локализовать баги.
Возможность получить ранний прототип.
Критические Модули тестируются на приоритет; основные недостатки дизайна могут быть найдены и исправлены в первую очередь.
Недостатки:
Нужно много пней.
Модули на более низком уровне тестируются неадекватно.
Сэндвич (гибридная интеграция)
Эта стратегия представляет собой комбинацию подходов «сверху вниз» и «снизу вверх». Здесь верхнеуровневые модули тестируются с нижнеуровневыми, а нижнеуровневые модули интегрируются с верхнеуровневыми, соответственно, и тестируются. Эта стратегия использует и заглушки, и драйверы.
Краткое описание интеграционных тест планов:
Методы/подходы к тестированию (как обсуждалось выше).
Области применения и вне областей применения Элементов интеграционного тестирования.
Роли и обязанности.
Предпосылки для интеграционного тестирования.
Среда тестирования.
Планы снижения рисков.
КРИТЕРИИ ДЛЯ ИНТЕГРАЦИОННОГО ТЕСТИРОВАНИЯ
ВХОД
Модульное Тестирование Компонентов/Модулей.
Все ошибки с высоким приоритетом исправлены и закрыты.
Все модули должны быть успешно завершены и интегрированы.
План интеграционных тестов, тестовый случай, сценарии, которые должны быть подписаны и задокументированы.
Необходимая тестовая среда для настройки интеграционного тестирования.
Необходимая тестовая среда для настройки интеграционного тестирования.
ВЫХОД
Успешное тестирование Интегрированного приложения.
Выполненные тестовые случаи документируются.
Все ошибки с высоким приоритетом исправлены и закрыты.
Технические документы, которые должны быть представлены, сопровождаются примечаниями к выпуску.
ПРЕИМУЩЕСТВА И НЕДОСТАТКИ ИНТЕГРАЦИОННОГО ТЕСТИРОВАНИЯ
Преимущества:
Интеграционное тестирование для разных модулей одновременно очень просто.
Может использоваться как на ранних, так и на более поздних стадиях процесса тестирования.
Покрытие длины кода больше по сравнению с другими методами тестирования программного обеспечения, так как могут использоваться как восходящий, так и нисходящий подходы.
В соответствии с изменениями требований, разработка меняется, поэтому важно тестирование модулей на разных уровнях, для которых можно легко использовать интеграционное тестирование.
Недостатки:
Поскольку все модули связаны, если в системах возникает какая-либо неисправность, ее трудно обнаружить.
Некоторые модули очень важны, и их необходимо протестировать. Эти модули должны быть проверены перед использованием в системе. Но во время интеграционного тестирования эти модули могут не проходить эффективное тестирование, так как все модули связаны друг с другом.
Соединение модулей может занять некоторое время, что может привести к увеличению времени общего времени процесса в программной системе.
Время, затрачиваемое на этот метод, больше, так как многие модули соединены вместе, и тестирование каждого модуля займет больше времени.
Время, затрачиваемое всей системой программного обеспечения, намного больше, чем другие подходы интеграционного тестирования.
Инструменты интеграционного тестирования и unit-тестов в Java
1. Запуск тестов:
1) JUnit — фреймворк, имеющий множество расширений. Он популярен и хорошо поддерживается, поэтому в случае возникновения сложностей вы без труда найдёте решение;
2) NestedRunner — расширение для JUnit, позволяющее запускать тестовые методы из вложенных классов. Плюсы: — есть возможность замены длинных имён методов на иерархию классов с учётом BDD-подхода; — вы можете избавиться от дублирующего кода посредством перемещения его в установочные методы в необходимых вложенных классах; — вы можете объявить константы во вложенных классах, а потом связать их с тестами, которым эти константы необходимы;
3) junit-davaprovider — это расширение для JUnit позволяет писать параметризованные тесты с применением TestNG в качестве провайдера данных. И это существенный плюс, если сравнивать со стандартным способом написания параметризованных тестов, который, мягко говоря, не очень.
2. Макеты, заглушки, подмены:
1) Mockito — популярный фреймворк, поддерживающий макетирование для unit-тестов. Из плюсов — простой API, множество полезных возможностей и превосходная техническая документация;
2) Greenmail — сервер электронной почты, поддерживающий POP3, SMTP и IMAP с поддержкой SSL-соединения. Главный плюс — простота применения;
3) MockFtpServer — данная библиотека предоставляет 2 разные реализации FTP-сервера (так называемые «обманка» и «заглушка»), которые вы сможете использовать при тестировании разных сценариев. И если надо потестить код, взаимодействующий с FTP-сервером, MockFtpServer — это ваш выбор.
3. Assertions:
1) Hamcrest предоставит вам инструменты для написания assertions (утверждений) для интеграционных и unit-тестов. Его неплохо использовать совместно со Spring MVC Test Framework;
2) AssertJ. Этот инструмент предоставляет гибкий API для написания assertions с полезными сообщениями об ошибках. Он улучшает читаемость тестового кода, позволяя превращать тесты в исполняемые спецификации, поддерживающие нужный предметно-ориентированный язык.
4. Тестирование кода доступа к данным:
1) H2 — быстрая база данных, полезная при написания интеграционных тестов, запускаемых на локальной машине разработчика;
2) DbUnit — расширение для JUnit. Вы можете использовать его для инициализации БД в известное состояние непосредственно перед выполнением каждого интеграционного теста, а также для заполнения БД необходимыми данными. Несмотря на недостатки DbUnit, этот инструмент весьма полезен и позволяет разделить тестовый код и тестовые данные.
5. Тестирование Spring-приложений:
1) Spring Test — не что иное, как швейцарский нож для написания автоматизированных тестов. Spring Test предоставляет собой 1-классную поддержку написания интеграционных и unit-тестов для приложений, где используется Spring;
2) Spring Test DbUnit — инструмент предназначен для интеграции DbUnit во фреймфорк String Test. Незаменимая вещь, если надо написать тесты доступа к данным для приложения, использующего реляционную БД и Spring.
ИТОГИ
В современном ИТ-мире, надобность в постоянном проведении интеграционного тестирования становится все более популярной и востребованной. Учитывая модульную гибкость интеграций, подобный вид тестирования можно применять как на больших, так и мелких проектах с различной направленностью.
Ежедневная практика использования интеграционного тестирования позволяет клиентам добиваться максимального значения коммерческой выгоды для своего веб-продукта. В то же время, QA компания, предоставляющая услуги по тестированию веб-приложений, оперирует исключительно надежными и эффективными инструментами верификации любого программного обеспечения.
Комментарии