# Интеграционное тестирование ## Что такое интеграционное тестирование Интеграционное тестирование – это тип тестирования, при котором программные модули логически интегрируются и тестируются как группа. Типичный программный проект состоит из нескольких программных модулей, написанных разными программистами. Цель интеграционного тестирования – выявить дефекты во взаимодействии между этими программными модулями, когда они интегрированы.
### Важность интеграционного тестирования То, что каждый программный модуль проходит модульное тестирование, еще не значит, что при их интеграции не проявятся дефекты. Причины могут быть разными: * Модуль чаще всего создается одним разработчиком, чье понимание и логика программирования могут отличаться от понимания и логики других разработчиков. Для проверки того, что программные модули работают вместе, необходимо интеграционное тестирование. * Во время разработки модуля существует большая вероятность изменения требований со стороны клиентов. Не факт, что эти новые требования протестированы на уровне модулей, поэтому важно все проверить в ходе интеграционного тестирования системы. * Интерфейсы программных модулей со внешними аппаратными интерфейсами, если таковые имеются, могут содержать ошибки. * Неадекватная обработка исключений может привести к проблемам. ### Пример интеграционного тест-кейса Интеграционный тест-кейс отличается от других тест-кейсов тем, что в нем **основное внимание уделяется интерфейсам и потоку данных между модулями**. Здесь приоритет отдается **интегрирующим связям**, а не функциям модулей, которые уже протестированы. Рассмотрим примеры интеграционных тест-кейсов для следующего сценария: *“Приложение имеет 3 модуля: “Login Page”, “Mailbox” и “Delete emails”. Все они логически интегрированы”*. Здесь не стоит сильно концентрироваться на тестировании страницы входа, так как это уже было сделано в модульном тестировании. Но проверьте, как она связана со страницей почтового ящика. Аналогично с почтовым ящиком: нужно проверить его интеграцию с модулем удаления писем. | **Test Case ID** | **Цель тест-кейса** | **Описание тест-кейса** | **Ожидаемый результат** | | ---------------- | ---------------------------------------------------------------------------- | -------------------------------------------------------------------- | --------------------------------------------------- | | 1 | Проверьте интерфейсную связь между модулем входа в систему и почтовым ящиком | Введите учетные данные для входа в систему и нажмите на кнопку Войти | Вход в почтовый ящик | | 2 | Проверьте интерфейсную связь между почтовым ящиком и модулем удаления писем | В почтовом ящике выберите письмо и нажмите кнопку удаления | Выбранное письмо должно появиться в папке Удаленные | ### Виды интеграционного тестирования Существуют разные стратегии выполнения интеграционного тестирования: * Подход “Большого взрыва” * Инкрементальный подход: * сверху вниз * снизу вверх * “сэндвич” – комбинация двух предыдущих. Давайте рассмотрим эти стратегии, способы их реализации, а также их ограничения и преимущества. #### Интеграционное тестирование методом “Большого взрыва” Если вы применяете подход “Большого взрыва”, все компоненты или модули интегрируются вместе, а затем тестируются. При этом объединенный набор компонентов рассматривается как единое целое. Если не все компоненты в наборе завершены, интегрировать их не получится. **Преимущества:** удобно для небольших систем. **Недостатки:** * Локализация неисправностей затруднена. * Можно легко пропустить какие-то интерфейсы в силу того, что при таком подходе они тестируются в больших количествах. * Поскольку интеграционное тестирование можно начать только после окончания разработки всех модулей, у команды тестировщиков будет меньше времени на выполнение фазы тестирования. * Поскольку все модули тестируются сразу, критические модули с высоким риском не изолируются и не тестируются в приоритетном порядке. Периферийные модули, касающиеся пользовательских интерфейсов, также не изолируются и не тестируются в приоритетном порядке. #### Инкрементное интеграционное тестирование Инкрементное тестирование проводится путем интеграции двух или более модулей, логически связанных друг с другом, после чего проверяется правильность функционирования приложения. Затем происходит постепенная интеграция других связанных модулей, и процесс продолжается до тех пор, пока все логически связанные модули не будут интегрированы и успешно протестированы. Инкрементное тестирование может выполняться как снизу вверх, так и сверху вниз. **Заглушки и драйверы** **Заглушки и драйверы** в интеграционном тестировании это программы, используемые для облегчения процесса тестирования. Они служат заменой отсутствующих моделей. Заглушки и драйверы не реализуют всю программную логику модуля, но имитируют обмен данными с вызывающим модулем во время тестирования. * **Заглушка** вызывается тестируемым модулем * **Драйвер** вызывает тестируемый модуль. #### **Интеграционное тестирование снизу вверх** **Интеграционное тестирование снизу вверх** – это стратегия, при которой сначала тестируются модули нижнего уровня. Эти протестированные модули затем используются для облегчения тестирования модулей более высокого уровня. Процесс продолжается до тех пор, пока не будут протестированы все модули верхнего уровня. **Схема:**
**Преимущества:** * Проще локализовать неисправности. * Не тратится время на ожидание разработки всех модулей, в отличие от подхода “Большого взрыва”. **Недостатки:** * Критические модули (на верхнем уровне архитектуры программного обеспечения), которые управляют потоком приложения, тестируются в последнюю очередь и могут быть подвержены дефектам. * Ранний прототип невозможен. #### **Интеграционное тестирование сверху вниз** **Интеграционное тестирование сверху вниз** – это метод, при котором интеграционное тестирование следует потоку управления системы. Чтобы проверить функциональность программного обеспечения, сначала тестируются модули верхнего уровня, а затем тестируются и интегрируются модули нижнего. Если какие-то модули не готовы, для тестирования используются заглушки. **Схема:**
**Преимущества:** * Упрощается локализация неисправностей. * Есть возможность получения раннего прототипа. * Критические модули тестируются в приоритетном порядке, поэтому основные недостатки конструкции можно найти и устранить в первую очередь. **Недостатки:** * Требуется много заглушек. * Модули более низкого уровня тестируются неадекватно. #### **Сэндвич-тестирование** **Сэндвич-тестирование** – это стратегия, при которой модули верхнего уровня тестируются вместе с модулями нижнего уровня, в то же время модули нижнего уровня интегрируются с модулями верхнего уровня и тестируются как система. Это сочетание нисходящего и восходящего подходов, поэтому его называют гибридным интеграционным тестированием. В нем используются как заглушки, так и драйверы.
### Как проводить интеграционное тестирование? Процедура интеграционного тестирования не зависит от выбранной стратегии (“Большой взрыв”, “сверху вниз”, “снизу вверх”, “сэндвич”). 1. Составление плана интеграционных тестов 2. Разработка тестовых сценариев, кейсов и скриптов. 3. Выполнение тест-кейсов с последующим сообщением о дефектах. 4. Отслеживание и повторное тестирование дефектов. 5. Шаги 3 и 4 повторяются до успешного завершения интеграции. ### План интеграционного тестирования В плане тестирования должны быть отражены следующие аспекты: * методы/подходы к тестированию * область тестирования и элементы вне этой области * роли и обязанности * предварительные условия для интеграционного тестирования. * среда тестирования. * риски и планы по их снижению. ### Вход и выход из интеграционного тестирования **Критерии входа:** * Компоненты/модули прошли модульное тестирование * Все высокоприоритетные ошибки исправлены и закрыты * Все модули завершены и успешно интегрированы. * План тестирования, тест-кейс, сценарии подписаны и задокументированы * Необходимая тестовая среда настроена для интеграционного тестирования **Критерии выхода:** * Успешное тестирование интегрированного приложения * Выполненные тест-кейсы задокументированы * Все баги с высоким приоритетом исправлены и закрыты * Техническая документация представлена с примечаниями к релизу. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://qabook.gitbook.io/start/teoriya-testirovaniya/osnovy-testirovaniya/vidy-testirovaniya/funkcionalnoe-testirovanie-i-ikh-vidy/integracionnoe-testirovanie.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.