Интеграционное тестирование – это тип тестирования, при котором программные модули логически интегрируются и тестируются как группа. Типичный программный проект состоит из нескольких программных модулей, написанных разными программистами. Цель интеграционного тестирования – выявить дефекты во взаимодействии между этими программными модулями, когда они интегрированы.
БЕСПЛАТНО СКАЧАТЬ КНИГИ в телеграм канале "Библиотека тестировщика"
Содержание
- Важность интеграционного тестирования
- Пример интеграционного тест-кейса
- Виды интеграционного тестирования
- Как проводить интеграционное тестирование?
- План интеграционного тестирования
- Вход и выход из интеграционного тестирования
- Best Practices интеграционного тестирования
Возможно, вы предпочитаете смотреть и слушать, а не читать. Если это так, вот видеоверсия этой статьи:
Важность интеграционного тестирования
То, что каждый программный модуль проходит модульное тестирование, еще не значит, что при их интеграции не проявятся дефекты. Причины могут быть разными:
- Модуль чаще всего создается одним разработчиком, чье понимание и логика программирования могут отличаться от понимания и логики других разработчиков. Для проверки того, что программные модули работают вместе, необходимо интеграционное тестирование.
- Во время разработки модуля существует большая вероятность изменения требований со стороны клиентов. Не факт, что эти новые требования протестированы на уровне модулей, поэтому важно все проверить в ходе интеграционного тестирования системы.
- Интерфейсы программных модулей со внешними аппаратными интерфейсами, если таковые имеются, могут содержать ошибки.
- Неадекватная обработка исключений может привести к проблемам.
Примечание редакции: о модульном тестировании у нас есть отдельная статья.
Пример интеграционного тест-кейса
Интеграционный тест-кейс отличается от других тест-кейсов тем, что в нем основное внимание уделяется интерфейсам и потоку данных между модулями. Здесь приоритет отдается интегрирующим связям, а не функциям модулей, которые уже протестированы.
Примечание редакции: о тест-кейсах также можно почитать в статье “Шаблон тест-кейса с примером”.
Рассмотрим примеры интеграционных тест-кейсов для следующего сценария: “Приложение имеет 3 модуля: “Login Page”, “Mailbox” и “Delete emails”. Все они логически интегрированы”.
Здесь не стоит сильно концентрироваться на тестировании страницы входа, так как это уже было сделано в модульном тестировании. Но проверьте, как она связана со страницей почтового ящика. Аналогично с почтовым ящиком: нужно проверить его интеграцию с модулем удаления писем.
| Test Case ID | Цель тест-кейса | Описание тест-кейса | Ожидаемый результат |
| 1 | Проверьте интерфейсную связь между модулем входа в систему и почтовым ящиком | Введите учетные данные для входа в систему и нажмите на кнопку Войти | Вход в почтовый ящик |
| 2 | Проверьте интерфейсную связь между почтовым ящиком и модулем удаления писем | В почтовом ящике выберите письмо и нажмите кнопку удаления | Выбранное письмо должно появиться в папке Удаленные |
Виды интеграционного тестирования
Существуют разные стратегии выполнения интеграционного тестирования:
- Подход “Большого взрыва”
- Инкрементальный подход:
- сверху вниз
- снизу вверх
- “сэндвич” – комбинация двух предыдущих.
Давайте рассмотрим эти стратегии, способы их реализации, а также их ограничения и преимущества.
Интеграционное тестирование методом “Большого взрыва”
Если вы применяете подход “Большого взрыва”, все компоненты или модули интегрируются вместе, а затем тестируются. При этом объединенный набор компонентов рассматривается как единое целое. Если не все компоненты в наборе завершены, интегрировать их не получится.
Преимущества: удобно для небольших систем.
Недостатки:
- Локализация неисправностей затруднена.
- Можно легко пропустить какие-то интерфейсы в силу того, что при таком подходе они тестируются в больших количествах.
- Поскольку интеграционное тестирование можно начать только после окончания разработки всех модулей, у команды тестировщиков будет меньше времени на выполнение фазы тестирования.
- Поскольку все модули тестируются сразу, критические модули с высоким риском не изолируются и не тестируются в приоритетном порядке. Периферийные модули, касающиеся пользовательских интерфейсов, также не изолируются и не тестируются в приоритетном порядке.
Инкрементное интеграционное тестирование
Инкрементное тестирование проводится путем интеграции двух или более модулей, логически связанных друг с другом, после чего проверяется правильность функционирования приложения. Затем происходит постепенная интеграция других связанных модулей, и процесс продолжается до тех пор, пока все логически связанные модули не будут интегрированы и успешно протестированы.
Инкрементное тестирование может выполняться как снизу вверх, так и сверху вниз.
Заглушки и драйверы
Заглушки и драйверы в интеграционном тестировании это программы, используемые для облегчения процесса тестирования. Они служат заменой отсутствующих моделей. Заглушки и драйверы не реализуют всю программную логику модуля, но имитируют обмен данными с вызывающим модулем во время тестирования.
- Заглушка вызывается тестируемым модулем
- Драйвер вызывает тестируемый модуль.
Интеграционное тестирование снизу вверх
Интеграционное тестирование снизу вверх – это стратегия, при которой сначала тестируются модули нижнего уровня. Эти протестированные модули затем используются для облегчения тестирования модулей более высокого уровня. Процесс продолжается до тех пор, пока не будут протестированы все модули верхнего уровня.
Схема:
Преимущества:
- Проще локализовать неисправности.
- Не тратится время на ожидание разработки всех модулей, в отличие от подхода “Большого взрыва”.
Недостатки:
- Критические модули (на верхнем уровне архитектуры программного обеспечения), которые управляют потоком приложения, тестируются в последнюю очередь и могут быть подвержены дефектам.
- Ранний прототип невозможен.
Интеграционное тестирование сверху вниз
Интеграционное тестирование сверху вниз – это метод, при котором интеграционное тестирование следует потоку управления системы. Чтобы проверить функциональность программного обеспечения, сначала тестируются модули верхнего уровня, а затем тестируются и интегрируются модули нижнего. Если какие-то модули не готовы, для тестирования используются заглушки.
Схема:
Преимущества:
- Упрощается локализация неисправностей.
- Есть возможность получения раннего прототипа.
- Критические модули тестируются в приоритетном порядке, поэтому основные недостатки конструкции можно найти и устранить в первую очередь.
Недостатки:
- Требуется много заглушек.
- Модули более низкого уровня тестируются неадекватно.
Сэндвич-тестирование
Сэндвич-тестирование – это стратегия, при которой модули верхнего уровня тестируются вместе с модулями нижнего уровня, в то же время модули нижнего уровня интегрируются с модулями верхнего уровня и тестируются как система. Это сочетание нисходящего и восходящего подходов, поэтому его называют гибридным интеграционным тестированием. В нем используются как заглушки, так и драйверы.
Как проводить интеграционное тестирование?
Процедура интеграционного тестирования не зависит от выбранной стратегии (“Большой взрыв”, “сверху вниз”, “снизу вверх”, “сэндвич”).
- Составление плана интеграционных тестов
- Разработка тестовых сценариев, кейсов и скриптов.
- Выполнение тест-кейсов с последующим сообщением о дефектах.
- Отслеживание и повторное тестирование дефектов.
- Шаги 3 и 4 повторяются до успешного завершения интеграции.
План интеграционного тестирования
В плане тестирования должны быть отражены следующие аспекты:
- методы/подходы к тестированию
- область тестирования и элементы вне этой области
- роли и обязанности
- предварительные условия для интеграционного тестирования.
- среда тестирования.
- риски и планы по их снижению.
Вход и выход из интеграционного тестирования
Критерии входа:
- Компоненты/модули прошли модульное тестирование
- Все высокоприоритетные ошибки исправлены и закрыты
- Все модули завершены и успешно интегрированы.
- План тестирования, тест-кейс, сценарии подписаны и задокументированы
- Необходимая тестовая среда настроена для интеграционного тестирования
Критерии выхода:
- Успешное тестирование интегрированного приложения
- Выполненные тест-кейсы задокументированы
- Все баги с высоким приоритетом исправлены и закрыты
- Техническая документация представлена с примечаниями к релизу.
Best Practices интеграционного тестирования
- Сначала определите стратегию интеграционного тестирования. После ее утверждения подготовьте тест-кейсы и соответствующие тестовые данные.
- Изучите архитектурный дизайн приложения и определите критические модули. Они должны быть протестированы в приоритетном порядке.
- Получите проекты интерфейсов от команды архитекторов и создайте тест-кейсы для детальной проверки всех интерфейсов. Интерфейс с базой данных/внешним аппаратным/программным приложением должен быть детально протестирован.
- После тест-кейсов решающую роль играют тестовые данные.
- Всегда готовьте тестовые данные заранее, не во время выполнения тест-кейсов.
Перевод статьи Thomas Hamilton «Integration Testing: What is, Types with Example».