Каждое программное приложение содержит несколько модулей, взаимодействующих друг с другом через интерфейс. Интеграция этих отдельных программных модулей и их совместное тестирование называется тестированием интеграции программного обеспечения. Это расширение модульного тестирования. В этом уроке мы увидим следующее.
Что такое интеграционное тестирование?
Интеграционное тестирование – это процесс проверки подключения или передачи данных между парой Модули с модульным тестированием. Это AKA I&T (Integration & Testing) или String Testing
Он подразделяется на подход Большого взрыва, подход сверху вниз, подход снизу вверх и подход сэндвич или гибридной интеграции (сочетание сверху вниз и снизу вверх). Этот процесс осуществляется с помощью фиктивных программ, называемых заглушками и драйверами. Заглушки и драйверы не реализуют всю программную логику программного модуля, а просто имитируют обмен данными с вызывающим модулем.
Это делается после модульного тестирования. Каждый модуль, участвующий в интеграционном тестировании, должен пройти модульное тестирование перед интеграционным тестированием. Выполнение модульного тестирования перед интеграционным тестированием дает уверенность в выполнении интеграционного тестирования программного обеспечения.
Это делается в соответствии с планом тестирования. Следуя плану тестирования перед проведением интеграционного тестирования, вы уменьшите хаос и проложите четкий путь к эффективному проведению интеграционного тестирования.
Посмотрите видео ниже, чтобы узнать об «интеграционном тестировании в SDLC»
Цели системного интеграционного тестирования
Цели интеграционного тестирования включают:
- Снизить риск
- Проверить, соответствует ли функциональное и нефункциональное поведение интерфейсов проектируемому и указанному
- Чтобы повысить уверенность в качестве интерфейсов
- Найти дефекты (которые могут быть в самих интерфейсах или внутри компонентов или систем)
- Чтобы предотвратить выход дефектов на более высокие уровни тестирования
Как написать тестовые примеры интеграции?
Предположим, что в приложении есть 3 модуля, например «Страница входа». ', 'Входящие' и 'Удалить почту'
При написании интеграционных тестов мы не сосредотачиваемся на функциональности отдельных модулей, потому что отдельные модули должны были быть охвачены во время модульного тестирования. Здесь мы должны сосредоточиться в основном на связи между модулями. В соответствии с нашим вышеприведенным предположением, мы должны сосредоточиться на том, «как страница входа связана со страницей папки «Входящие» и как страница папки «Входящие» связана с модулем удаления почты».
Что такое подход Большого взрыва?
Объединение всех модулей один раз и проверка функциональности после завершения тестирования отдельных модулей. В интеграционном тестировании Big Bang отдельные модули не интегрируются до тех пор, пока не будут готовы все модули. Затем они побегут, чтобы проверить, хорошо ли он работает. В этом типе тестирования могут возникнуть некоторые недостатки, например, дефекты могут быть обнаружены на более позднем этапе. Было бы трудно выяснить, возникает ли дефект в интерфейсе или в модуле.
Что такое подход сверху вниз?
< р>
При интеграционном тестировании сверху вниз тестирование выполняется сверху вниз. Сначала тестируются модули высокого уровня, затем модули низкого уровня и, наконец, модули низкого уровня интегрируются в высокий уровень, чтобы убедиться, что система работает должным образом.
В этом типе тестирования заглушки используются как временные модули, если модуль не готов к интеграционному тестированию.
Что такое подход «снизу вверх»?
Это ответ на подход «сверху вниз». При восходящем интеграционном тестировании тестирование проводится снизу вверх. Сначала тестируются модули самого низкого уровня, затем модули высокого уровня и, наконец, модули высокого уровня интегрируются в низкий уровень, чтобы убедиться, что система работает должным образом. Драйверы используются в качестве временного модуля для интеграционного тестирования.
В чем разница между заглушками и драйверами при тестировании программного обеспечения?
Заглушки и драйверы используются при тестировании на уровне компонентов. Проверьте изображение ниже
Предположим, у нас есть два модуля в приложении, скажем, «Модуль A» и «Модуль B». Разработчики приложений разработали только «Модуль А». Прежде чем они закончат разработку «Модуля Б», мы (тестировщики) получили требование протестировать «Модуль А». Здесь мы можем протестировать «Модуль А», если нет зависимости с «Модулем Б». Предположим, что «Модуль А» зависит от «Модуля Б». Вот что вы делаете. Чтобы проверить «Модуль А» в этом случае. Разработчики создают фиктивный модуль, скажем, Stub, чтобы заменить «Module B». То же самое, если «Модуль Б» зависит от «Модуля А», но «Модуль А» еще не готов. В этом случае мы используем драйвер для замены «модуля А».
Что такое заглушка?
Вызывается модулем под тестом.
Что такое драйвер?
Вызывает модуль для тестирования.
Эти термины (заглушка и драйвер) появляются при выполнении интеграционного тестирования. Работая над интеграцией, мы иногда сталкиваемся с ситуацией, когда часть функционала еще находится в разработке. Таким образом, функциональные возможности, которые находятся в стадии разработки, будут заменены некоторыми фиктивными программами. Эти фиктивные программы называются заглушками или драйверами.
Представьте, что у нас есть две страницы: страница входа и страница администратора.
Вы должны протестировать страницу входа (предположим, страница администратора находится в разработке). Страница входа вызовет страницу администратора после входа в систему, но страница администратора еще не готова. Чтобы преодолеть эту ситуацию, разработчики пишут фиктивную программу, которая действует как страница администратора. Эта фиктивная программа называется заглушкой.
Заглушки — это «вызываемые программы». Если «Вызываемая программа» неполная, она заменяется заглушкой. (Это происходит при подходе сверху вниз)
Переходим к Драйверам. В приведенном выше примере страница входа готова, но не страница администратора. на этот раз предположим, что страница администратора готова к тестированию, но страница входа еще не готова. Чтобы преодолеть эту ситуацию, разработчики пишут фиктивную программу, которая действует как страница входа. Эта фиктивная программа называется Driver. Драйверы — это «вызывающие программы». Если «Программа вызова» не завершена, она заменяется Драйвером. (Это происходит при восходящем подходе)
ЗАГОЛОВКИ | ДРАЙВЕРЫ |
---|---|
Заглушки, используемые в интеграционном тестировании сверху вниз | Драйверы, используемые в восходящем интеграционном тестировании |
Заглушки используются, когда подпрограммы находятся в стадии разработки | Драйверы используются, когда основные программы находятся в разработке |
Большинство модулей тестируются first | Сначала тестируется самый низкий модуль |
Он может имитировать поведение модулей более низкого уровня, которые не интегрированы | Может имитировать поведение модулей верхнего уровня, которые не интегрированы |
Заглушки называются программами | Драйверы — это вызывающие программы |
Что такое гибридное интеграционное тестирование?
Гибридное интеграционное тестирование также известно как многоуровневое интеграционное тестирование. Это комбинация интеграционного тестирования «сверху вниз» и «восходящего тестирования».
В чем разница между модульным тестированием и интеграционное тестирование?
UNIT TESTING | ИНТЕГРАЦИОННОЕ ТЕСТИРОВАНИЕ |
---|---|
Модульное тестирование — это первый уровень тестирования в тестировании программного обеспечения | интеграции. Тестирование — это второй уровень тестирования в тестировании программного обеспечения |
Рассматривает каждый компонент как единую систему | Интегрированные компоненты рассматриваются как единая система |
Цель – проверить работу отдельного модуля | Цель – проверить интеграцию несколько модульных модулей |
Он оценивает каждый компонент или модуль программного продукта | Он проверяет правильную работу, интерфейс и надежность , после интеграции модулей, а также с внешними интерфейсами и системой |
Область модульного тестирования ограничена конкретным тестируемым модулем | Область модульного тестирования шире по сравнению с модульным тестированием. Он охватывает два или более модулей |
У него нет дополнительных типов | Он разделен на следующие подходы • Снизу вверх интеграционный подход • Интеграционный подход “сверху вниз” • Подход “большого взрыва” • Гибридный подход |
Это также известно как тестирование компонентов | Оно также известно как I&T или тестирование строк |
Оно выполняется на уровне кода | Выполняется на коммуникационном уровне |
Выполняется с помощью многократно используемых тестовых примеров | Осуществляется с помощью заглушек и драйверов |
Подпадает под тестирование белого ящика | Это относится как к тестированию черного ящика, так и к тестированию белого ящика |
Оно выполняется разработчиками | Оно выполняется либо тестировщиками, либо разработчиками |
В чем разница между интеграционным тестированием и системным тестированием?
ТЕСТИРОВАНИЕ ИНТЕГРАЦИИ | ТЕСТИРОВАНИЕ СИСТЕМЫ | ||
---|---|---|---|
Это низкоуровневое тестирование | Это высокоуровневое тестирование< tr class="row-3 odd"> | За ним следует системное тестирование | За ним следует приемочное тестирование |
Выполняется после интеграционного тестирования | |||
Различные типы интеграции тестирование: • Интеграционное тестирование сверху вниз • Интеграционное тестирование снизу вверх • Интеграционное тестирование большого взрыва • Многослойное интеграционное тестирование | Различные типы системного тестирования: • Регрессионное тестирование • Проверка работоспособности • Тестирование удобства использования • Повторное тестирование • Нагрузочное тестирование • Тестирование производительности • Техническое тестирование | ||
Тестеры выполняют функциональное тестирование для проверки взаимодействия двух модулей | Тестировщики выполняют как функциональное, так и нефункциональное тестирование для оценки функциональности, удобства использования, тестирования производительности и т. д., | ||
Выполняется для проверки взаимодействия двух разных модулей. эффективно друг с другом или нет | Выполняется для проверки того, работает ли продукт в соответствии с ожиданиями пользователя и требуемыми спецификациями | ||
Это может выполняться как тестировщиками, так и разработчиками | Выполняется тестировщиками | ||
Тестирование проводится на интерфейсе двух отдельных модулей | Тестирование проводится на всем программном приложении< tr class="row-10 even"> | Здесь мы проверяем взаимодействие между отдельными модулями. | Здесь мы проверяем готовый продукт. |
Тестерам необходимо понимать взаимосвязанные модули и их взаимодействие. | Тестерам необходимо понимать внутреннюю структуру и язык программирования. | ||
Охватывает только функциональное тестирование. | Охватывает как функциональное, так и нефункциональное тестирование. |
Инструменты интеграционного тестирования
Некоторые из инструментов интеграционного тестирования:
- Citrus Integration Testing
- VectorCAST/C++
- FitNesse
- Validata
Это все об интеграционном тестировании. Если вам понравился этот пост, пожалуйста, поделитесь им с друзьями.
TAG: qa