Что такое интеграционное тестирование
09 июня 2020
Интеграционное тестирование: что это? Виды, примеры.
Что такое интеграционное тестирование? Зачем оно нужно? Примеры, подходы, стратегия и методологии.
- Что такое интеграционное тестирование?
- Зачем нужно интеграционное тестирование?
- Примеры интеграционного тестирования
- Подходы, стратегии, методологии интеграционного тестирования
- Подход Большого взрыва
- Инкрементальный подход
- Заглушка и драйвер
- Интеграция снизу вверх
- Интеграция сверху вниз
- Сэндвич (гибридная интеграция)
- Как сделать интеграционное тестирование?
- Атрибуты Интеграционного тестирования
- Критерии старта и окончания Интеграционного тестирования
- Лучшие практики / рекомендации по Интеграционному тестированию
Зачем нужно интеграционное тестирование?
Модульное тестирование
Unit Testing
Интеграционное тестирование
Integration Testing
Системное тестирование
System Testing
Приемочное тестирование
Acceptance Testing
Каждый программный модуль проходит отдельные этапы тестирования (модульное тестирование), но не смотря на это, дефекты могут оставаться по ряду причин:
- Поскольку, как правило, модули разрабатываются разными специалистами, их понимание и логика программирования могут отличаться. Тут интеграционное тестирование становится необходимым для проверки взаимодействия модулей между собой.
- Во время разработки модуля заказчики часто меняют требования, и если у вас сжатые сроки требования могут попросту не успеть пройти модульное тестирование, и, следовательно, системная интеграция может пройти с помехами. Опять получается, что от интеграционного тестирования не убежать.
- Интерфейсы программных модулей с базой данных могут быть ошибочными
- Внешние аппаратные интерфейсы, если таковые имеются, могут быть ошибочными
- Неправильная обработка исключений может вызвать проблемы.
Пример тестирования интеграции для следующего сценария:
Приложение имеет 3 модуля, например «Страница входа» , «Почтовый ящик» и «Удалить электронную почту» . Каждый из них интегрирован логически.
Здесь нет нужды тестировать страницу входа, т.к. это уже было сделано в модульном тестировании. Но проверьте, как это интегрировано со страницей почтового ящика.
Аналогично, «Почтовый ящик» : проверьте его интеграцию с модулем «Удалить электронную почту» .
Идентификатор теста;Цель теста;Описание теста;Ожидаемый результат
1;Проверьте интерфейсную связь между модулем входа в систему и почтовым ящиком.;Введите учетные данные и нажмите кнопку «Войти»;Быть направленным в почтовый ящик 2;Проверьте интерфейсную ссылку между почтовым ящиком и модулем удаления почты.;Из почтового ящика выберите адрес электронной почты и нажмите кнопку удаления;Выбранное письмо должно появиться в папке «Удаленные / Корзина»
- Подход Большого взрыва.
- Инкрементальный подход:
- Нисходящий подход (сверху вниз)
- Подход «снизу вверх»
- Сэндвич – комбинация «сверху вниз» и «снизу вверх»
Под ход Боль шого взрыва
Здесь все компоненты собираются вместе, а затем тестируются.
- Удобно для небольших систем.
- Сложно локализовать баги.
- Учитывая огромное количество интерфейсов, некоторые из них при тестировании можно запросто пропустить.
- Недостаток времени для группы тестирования, т.к тестирование интеграции может начаться только после того, как все модули спроектированы.
- Поскольку все модули тестируются одновременно, критические модули высокого риска не изолируются и тестируются в приоритетном порядке. Периферийные модули, которые имеют дело с пользовательскими интерфейсами, также не изолированы и не проверены на приоритет.
- Снизу вверх
- Сверху вниз
Инкрементальный подход осуществляется с помощью фиктивных программ, называемых заглушками и драйверами . Заглушки и драйверы не реализуют всю логику программного модуля, а только моделируют обмен данными с вызывающим модулем.
Заглушка: вызывается тестируемым модулем.
Драйвер: вызывает модуль для тестирования.Интеграция «снизу вверх»
В восходящей стратегии каждый модуль на более низких уровнях тестируется с модулями более высоких уровней, пока не будут протестированы все модули. Требуется помощь драйверов для тестирования
- Проще локализовать ошибки.
- Не тратится время на ожидание разработки всех модулей, в отличие от подхода Большого взрыва.
- Критические модули (на верхнем уровне архитектуры программного обеспечения), которые контролируют поток приложения, тестируются последними и могут быть подвержены дефектам.
- Не возможно реализовать ранний прототип
При подходе «сверху вниз» тестирование, что логично, выполняется сверху вниз, следуя потоку управления программной системы. Используются заглушки для тестирования.
- Проще локализовать баги.
- Возможность получить ранний прототип.
- Критические Модули тестируются на приоритет; основные недостатки дизайна могут быть найдены и исправлены в первую очередь.
- Нужно много пней.
- Модули на более низком уровне тестируются неадекватно
- Подготовка план интеграционных тестов
- Разработка тестовых сценариев.
- Выполнение тестовых сценариев и фиксирование багов.
- Отслеживание и повторное тестирование дефектов.
- Повторять шаги 3 и 4 до успешного завершения интеграции.
- Методы / Подходы к тестированию (об этом говорили выше).
- Области применения и Тестирование интеграции.
- Роли и обязанности.
- Предварительные условия для Интеграционного тестирования.
- Тестовая среда.
- Планы по снижению рисков и автоматизации.
- Модули и модульные компоненты
- Все ошибки с высоким приоритетом исправлены и закрыты
- Все модули должны быть заполнены и успешно интегрированы.
- Наличие плана Интеграционного тестирования, тестовый набор, сценарии, которые должны быть задокументированы.
- Наличие необходимой тестовой среды
- Успешное тестирование интегрированного приложения.
- Выполненные тестовые случаи задокументированы
- Все ошибки с высоким приоритетом исправлены и закрыты
- Технические документы должны быть представлены после выпуска Примечания.
- Сначала определите интеграционную тестовую стратегию, которая не будет противоречить вашим принципам разработки, а затем подготовьте тестовые сценарии и, соответственно, протестируйте данные.
- Изучите архитектуру приложения и определите критические модули . Не забудьте проверить их на приоритет.
- Получите проекты интерфейсов от команды разработки и создайте контрольные примеры для проверки всех интерфейсов в деталях. Интерфейс к базе данных / внешнему оборудованию / программному обеспечению должен быть детально протестирован.
- После тестовых случаев именно тестовые данные играют решающую роль.
- Всегда имейте подготовленные данные перед выполнением. Не выбирайте тестовые данные во время выполнения тестовых случаев.
Для чего нужно интеграционное тестирование?
Эта статья является конспектом книги «Принципы юнит-тестирования». Материал статьи посвящен интеграционным тестам.
Юнит-тесты прекрасно справляются с проверкой бизнес-логики, но проверять эту логику «в вакууме» недостаточно. Необходимо проверять, как разные ее части интегрируются друг с другом и внешними системами: базой данных, шиной сообщений и т. д.
В этой статье рассматривается роль интеграционных тестов, когда их следует использовать и когда лучше положиться на классические юнит-тесты. Также затронем эффективное написание интеграционных тестов.
Что такое интеграционный тест?
Юнит-тест удовлетворяет следующим трем требованиям:
- проверяет правильность работы одной единицы поведения;
- делает это быстро;
- и в изоляции от других тестов.
Тест, который не удовлетворяет хотя бы одному из этих трех требований, относится к категории интеграционных тестов. На практике интеграционные тесты почти всегда проверяют, как система работает в интеграции с внепроцессными зависимостями.
Если все внепроцессные зависимости заменить моками, никакие зависимости не будут совместно использоваться между тестами, благодаря чему эти тесты останутся быстрыми и сохранят свою изоляцию друг от друга и становятся юнит-тестами. Тем не менее во многих приложениях существует внепроцессная зависимость, которую невозможно заменить моком. Обычно это база данных — зависимость, не видимая другими приложениями.
Важно поддерживать баланс между юнит- и интеграционными тестами. Работа напрямую с внепроцессными зависимостями замедляет интеграционные тесты. Кроме того, их сопровождение также обходится дороже.
С другой стороны, интеграционные тесты проходят через больший объем кода, что делает их более эффективными в защите от багов по сравнению с юнит-тестами. Они также более отделены от рабочего кода, а, следовательно, обладают большей устойчивостью к его рефакторингу.
Соотношение между юнит- и интеграционными тестами зависит от особенностей проекта, но общее правило выглядит так: проверьте как можно больше пограничных случаев бизнес-сценария юнит-тестами; используйте интеграционные тесты для покрытия одного позитивного пути, а также всех граничных случаев, которые не покрываются юнит-тестами.
Для интеграционного теста выберите самый длинный позитивный путь, проверяющий взаимодействия со всеми внепроцессными зависимостями. Если не существует одного пути, проходящего через все такие взаимодействия, напишите дополнительные интеграционные тесты — столько, сколько потребуется для отражения взаимодействий с каждой внешней системой.
Какие из внепроцессных зависимостей должны проверяться напрямую
Все внепроцессные зависимости делятся на две категории.
- Управляемые зависимости (внепроцессные зависимости, находящиеся под вашим полным контролем): эти зависимости доступны только через ваше приложение; взаимодействия с ними не видны внешнему миру. Типичный пример — база данных.
- Неуправляемые зависимости (внепроцессные зависимости, которые не находятся под вашим полным контролем) — результат взаимодействия с такими зависимостями виден извне. В качестве примеров можно привести сервер SMTP и шину сообщений.
Взаимодействия с управляемыми зависимостями относятся к деталям имплементации. И наоборот, взаимодействия с неуправляемыми зависимостями являются частью наблюдаемого поведения вашей системы.
Это различие приводит к тому, что такие зависимости по-разному обрабатываются в интеграционных тестах. Взаимодействия с управляемыми зависимостями являются деталями имплементации. Использовать их следует в исходном виде в интеграционных тестах. Взаимодействия с неуправляемыми зависимостями являются частью наблюдаемого поведения системы. Такие зависимости должны заменяться моками.
Требование о сохранении схемы взаимодействий с неуправляемыми зависимостями обусловлено необходимостью поддержания обратной совместимости с такими зависимостями. Моки идеально подходят для этой задачи. Они позволяют обеспечить неизменность схемы взаимодействий при любых возможных рефакторингов. Поддерживать обратную совместимость во взаимодействиях с управляемыми зависимостями не обязательно, потому что никто, кроме вашего приложения, с ними не работает. Внешних клиентов не интересует, как устроена ваша база данных; важно только итоговое состояние вашей системы. Использование реальных экземпляров управляемых зависимостей в интеграционных тестах помогает проверить это итоговое состояние с точки зрения внешних клиентов.
Иногда встречаются внепроцессные зависимости, обладающие свойствами как управляемых, так и неуправляемых зависимостей. Хорошим примером служит база данных, доступная для других приложений.
База данных — не лучший механизм для интеграции между системами, потому что она связывает эти системы друг с другом и усложняет дальнейшую их разработку. Используйте это решение только в случае, если других вариантов нет. Правильнее осуществлять интеграцию через API (для синхронных взаимодействий) или шину сообщений (для асинхронных взаимодействий).
В этом случае следует рассматривать таблицы, видимые для других приложений, как неуправляемую зависимость. Такие таблицы фактически выполняют функции шины сообщений, а их строки играют роль сообщений. Используйте моки, чтобы гарантировать неизменность схемы взаимодействий с этими таблицами. В то же время следует рассматривать остальные части базы данных как управляемую зависимость и проверять ее итоговое состояние, а не взаимодействия с ней.
Основные приемы интеграционного тестирования
Существует несколько общих рекомендаций, которые помогут извлечь максимальную пользу из интеграционных тестов:
- явное определение границ доменной модели (модели предметной области);
- сокращение количества слоев в приложении;
- устранение циклических зависимостей.
Явное определение границ модели предметной области. Доменная модель представляет собой совокупность знаний о предметной области задачи, для решения которой предназначен ваш проект. Данная практика помогает с тестированием. Юнит-тесты должны ориентироваться на доменную модель и алгоритмы, тогда как интеграционные тесты — на контроллеры. Таким образом, четкое разграничение между доменными классами и контроллерами также помогает отделить юнит-тесты от интеграционных.
Сокращение количества слоев. Многие разработчики стремятся к абстрагированию и обобщению кода путем введения дополнительных уровней абстракции.
В некоторых приложениях находится столько уровней абстракции, что разработчик уже не может разобраться в коде и понять логику даже простейших операций.
«Все проблемы в программировании можно решить путем добавления нового уровня абстракции (кроме проблемы наличия слишком большого количества уровней абстракции)».
Дэвид Дж. УилерЛишние абстракции также затрудняют юнит- и интеграционное тестирование. Кодовые базы со слишком большим количеством слоев обычно не имеют четкой границы между контроллерами и моделью предметной области. Старайтесь ограничиться минимально возможным количеством уровней абстракции. В большинстве серверных систем можно обойтись всего тремя: слоем доменной модели, слоем сервисов приложения (контроллеров) и слоем инфраструктуры.
Исключение циклических зависимостей. Циклическая зависимость возникает в том случае, если два или более класса прямо или косвенно зависят друг от друга. Типичный пример циклической зависимости — обратный вызов:
public class CheckOutService < public void CheckOut(int orderId) < var service = new ReportGenerationService(); service.GenerateReport(orderId, this); /* остальной код */ >> public class ReportGenerationService < public void GenerateReport( int orderId, CheckOutService checkOutService) < /* вызывает checkOutService при завершении генерирования */ >>Как и в случае с избыточными уровнями абстракции, циклические ссылки создают дополнительную когнитивную нагрузку при попытке прочитать и понять код. Циклические зависимости также усложняют тестирование. Вам часто приходится использовать интерфейсы и моки, для того чтобы разбить граф классов и изолировать одну единицу поведения.
Что же делать с циклическими зависимостями? Лучше всего совсем избавиться от них. Отрефакторить класс ReportGenerationService, чтобы он не зависел от CheckOutService и сделать так, чтобы ReportGenerationService возвращал результат работы в виде простого значения вместо вызова CheckOutService:
public class CheckOutService < public void CheckOut(int orderId) < var service = new ReportGenerationService(); Report report = service.GenerateReport(orderId); /* прочая работа */ >> public class ReportGenerationService < public Report GenerateReport(int orderId) < /* . */ >>Использование нескольких секций действий в тестах
Как вы, возможно, помните из предыдущего конспекта «Анатомия юнит-тестов», наличие более одной секции подготовки, действий или проверки в тесте — плохой признак. Он указывает на то, что тест проверяет несколько единиц поведения, что, в свою очередь, ухудшает сопровождаемость теста. Например, если имеются два связанных сценария использования (допустим, регистрация и удаление пользователя).
- подготовка — подготовка данных для регистрации пользователя;
- действие — вызов UserController.RegisterUser();
- проверка — запрос к базе данных для проверки успешного завершения регистрации;
- действие — вызов UserController.DeleteUser();
- проверка — запрос к базе данных для проверки успешного удаления.
Лучше всего разбить тест, выделив каждое действие в отдельный тест. На первый взгляд это может показаться лишней работой, но эта работа окупается в долгосрочной перспективе. Фокусировка каждого теста на одной единице поведения упрощает понимание и изменение этих тестов при необходимости.
Исключение из этой рекомендации составляют тесты, работающие с внепроцессными зависимостями, трудно приводимыми в нужное состояние. Например, регистрация пользователя приводит к созданию банковского счета во внешней банковской системе. Банк предоставил вашей организации тестовую среду, которую вы хотите использовать для сквозных тестов. К сожалению, тестовая среда работает слишком медленно; также возможно, что банк ограничивает количество обращений к этой тестовой среде. В таком сценарии удобнее объединить несколько действий в один тест, чтобы сократить количество взаимодействий с проблемной внепроцессной зависимостью.
Выводы
Интеграционные тесты проверяют, как ваша система работает в интеграции с внепроцессными зависимостями.
Интеграционные тесты покрывают контроллеры; юнит-тесты покрывают алгоритмы и доменную модель.
Интеграционные тесты обеспечивают лучшую защиту от багов и устойчивость к рефакторингу; юнит-тесты более просты в поддержке и дают более быструю обратную связь.
«Порог» для написания интеграционных тестов выше, чем для юнит-тестов: их эффективность по метрике защиты от багов и устойчивости к рефакторингу должна быть выше, чем у юнит-тестов, для того чтобы скомпенсировать дополнительную сложность в поддержке и медленную обратную связь. Пирамида тестирования отражает этот компромисс: большинство тестов должны составлять быстрые и простые в поддержке юнит-тесты при меньшем количестве медленных и более сложных в поддержке интеграционных тестов, проверяющих правильность системы в целом.
Управляемые зависимости представляют собой внепроцессные зависимости, доступ к которым осуществляется только через ваше приложение. Взаимодействия с управляемыми зависимостями не видимы извне. Типичный пример — база данных приложения.
Неуправляемые зависимости — внепроцессные зависимости, доступные для других приложений. Взаимодействия с неуправляемыми зависимостями видны снаружи. Типичные примеры — сервер SMTP и шина сообщений.
Взаимодействия с управляемыми зависимостями являются деталями имплементации; взаимодействия с неуправляемыми зависимостями являются частью наблюдаемого поведения вашей системы.
Иногда внепроцессная зависимость обладает свойствами как управляемых, так и неуправляемых зависимостей. Типичный пример — база данных, доступная для других приложений. Наблюдаемую часть такой базы следует интерпретировать как неуправляемую зависимость; заменяйте ее моками в тестах. Рассматривайте остальную часть зависимости как управляемую — проверяйте ее итоговое состояние, а не взаимодействия с ней.
Выделите явное место для модели предметной области в коде. Четкая граница между классами предметной области и контроллерами помогает отличать юниттесты от интеграционных.
Лишние уровни абстракции отрицательно влияют на вашу способность понимать код. Постарайтесь свести количество этих уровней к минимуму. В большинстве бэкенд-систем достаточно всего трех слоев: предметной области, сервисов приложения и инфраструктуры.
Циклические зависимости увеличивают когнитивную нагрузку при попытках разобраться в коде. Типичный пример — обратный вызов (когда вызываемая сторона уведомляет вызывающую о результате своей работы).
Множественные секции действий в тестах оправданны только в том случае, если тест работает с внепроцессными зависимостями, которые трудно привести в нужное состояние. Никогда не включайте несколько действий в юнит-тест, потому что юнит-тесты не работают с внепроцессными зависимостями. Многофазные тесты почти всегда принадлежат к категории сквозных.
Ссылки на все части
- Анатомия юнит-теста
- Аспекты хороших юнит-тестов
- Для чего нужно интеграционное тестирование?
- автоматическое тестирование
- интеграционное тестирование
- интеграционные тесты
Что такое интеграционное тестирование
События
- Тестирование
- Основы
- Откуда берутся ошибки в ПО?
- Почему тестирование необходимо?
- Мифы о тестировании
- Психология тестирования
- Когда начинать и заканчивать тестирование?
- Фундаментальный процесс тестирования
- Принципы тестирования
- Верификация и валидация
- QA, QC и тестирование
- Кто занимается тестированием?
- Цели тестирования
- Что такое тестирование программного обеспечения?
- Роль тестирования в процессе разработки ПО
- Сколько стоят дефекты?
- Качество программного обеспечения (ISO/IEC 25010)
- Матрица соответствия требований (Requirements Traceability Matrix)
- Тестирование веб-проектов: основные этапы и советы.
- Мобильное и веб-приложение. В чем разница?
- Тест дизайн (Test Design)
- Agile
- Словарь тестировщика
- 75 популярных вопросов на собеседовании QA (+ примеры и ответы)
- HTML и CSS для тестировщиков
- Итеративная модель (Iterative model)
- Спиральная модель (Spiral model)
- V-модель (V-model)
- Каскадная модель (Waterfall model)
- Стадии цикла разработки ПО
- Жизненный цикл ПО
- Приемочное тестирование
- Системное тестирование
- Интеграционное тестирование
- Модульное тестирование
- White/Black/Grey Box-тестирование
- Статическое и динамическое тестирование
- Ручное и автоматизированное
- Тестирование документации
- Интернационализация и локализация
- Стресс тестирование
- Тестирование установки
- Конфигурационное тестирование
- Тестирование на отказ и восстановление
- Юзабилити
- Тестирование сборки
- Тестирование взаимодействия
- Тестирование безопасности
- Дымное тестирование
- Регрессионное тестирование
- Тестирование производительности
- Функциональное тестирование
- Нефункциональное тестирование
- Спецификация требований
- Test Plan
- Checklists для тестировщика
- Test Case
- Bug report
- Жизненный цикл дефектов
- Классификация дефектов
- Тестирование мобильных приложений
- Протоколы
- Протокол TCP/IP или как работает Интернет (для новичков)
- Автоматизация
- Автоматизированное тестирование
- Теория по X-Path локаторам
- Как написать X-Path локатор.
- Использование tagname
- Вложенность родительского элемента.
- Как выбрать инструмент автоматизации?
- Базы данных в тестировании
- Зачем нужен SQL для тестирования?
- Общее
- Интерфейс в коде ПО
- Что такое микросервисная архитектура ПО?
- Что такое монолитная архитектура?
- Что такое API?
- Процесс коммуникации с помощью API
- Что такое JSON
- Что не так с Android?
- Android Studio 2.0
- RxJava
- Основы
- Внутренний мир компьютера: что там внутри
Исходя из различий между модульным тестированием и системным тестированием, интеграционное тестирование является переходным этапом между представлением программы в виде отдельных модулей в вид полностью функциональной системы.
Интеграционное тестирование – вид тестирования, при котором на соответствие требований проверяется интеграция модулей, их взаимодействие между собой, а также интеграция подсистем в одну общую систему. Для интеграционного тестирования используются компоненты, уже проверенные с помощью модульного тестирования, которые группируются в множества. Данные множества проверяются в соответствии с планом тестирования, составленным для них, а объединяются они через свои интерфейсы.
Так как модули соединяются между собой с помощью предусмотренных реализацией интерфейсов и в процессе тестирования у нас нет потребности рассматривать внутреннюю структуру компонентов, можно утверждать, что интеграционное тестирование выполняется методом «черного ящика».
Объект тестирования выделен красным цветом.
Существует несколько подходов к интеграционному тестированию:
• Снизу вверх. Сначала собираются и тестируются модули самих нижних уровней, а затем по возрастанию к вершине иерархии. Данный подход требует готовности всех собираемых модулей на всех уровнях системы.
• Сверху вниз. Данный подход предусматривает движение с высокоуровневых модулей, а затем направляется вниз. При этом используются заглушки для тех модулей, которые находятся ниже по уровню, но включение которых в тест еще не произошло.
• Большой взрыв. Все модули всех уровней собираются воедино, а затем тестируется. Данный метод экономит время, но требует тщательной проработки тест кейсов.
При автоматизации тестирования используется Система непрерывной интеграции. Принцип ее действия заключается в следующем:
1) Система непрерывной интеграции производит мониторинг системы контроля версий.
2) При изменении исходных кодов в репозитории производится обновление локального хранилища.
3) Выполняются необходимые проверки и модульные тесты.
4) Исходные коды компилируются в готовые выполняемые модули.
5) Выполняются тесты интеграционного уровня.
6) Генерируется отчет о тестировании.
Это позволяет тестировать систему сразу после внесения изменений, что существенно сокращает время обнаружения и исправления ошибок.
- Выбери курс для обучения
- Тестирование
- Базовый модуль тестирования
- Тестирование ПО
- Тестирование WEB-сервисов
- Тестирование мобильных приложений
- Тестирование нагрузки с JMeter
- Расширенный модуль автоматизации тестирования
- Автоматизация тестирования с Selenium WebDriver (Python)
- Автоматизация тестирования с Selenium WebDriver (Java)
- Автоматизация тестирования с Selenium WebDriver (C#)
- Автоматизация тестирования на JavaScript
- Java для автоматизаторов
- Fullstack Web Developer
- Java
- Python
- JavaScript
- HTML5 И CSS3
- Полный стек разработки на фреймворке Laravel
- Разработка CMS на основе PHP
- Git для автоматизаторов
- Практический SQL
- Основы Unix и сети
- WEB-серверы и WEB-сервисы
- Создание проекта автоматизации и написания UI тестов
- Составление комбинированных тестов UI и API. Написание BDD тестов
- IT Project Manager
- HR-менеджер в ИТ-компании
- Как правильно составить резюме и пройти собеседование
- Подготовка к сертификации ISTQB Foundation Level на основе Syllabus Version 2018
- Тестирование
- Базовый модуль тестирования
Интеграционное тестирование: что это и зачем
Интеграционное тестирование — это процесс проверки соответствия взаимодействия компонентов ПО заданным требованиям. Это важный шаг в тестировании, который позволяет проверить работоспособность ПО в целом. В рамках интеграционного тестирования проверяется, как различные компоненты ПО работают вместе и как они обмениваются данными.
Интеграционное тестирование является необходимым этапом в процессе разработки ПО, потому что это позволяет обнаружить ошибки и проблемы, связанные с взаимодействием компонентов. Без интеграционного тестирования могут возникнуть проблемы при запуске ПО на реальной среде. Интеграционное тестирование также помогает убедиться, что ПО работает как ожидается в реальных условиях.
Подходы в интеграционном тестировании
Подход Большого взрыва (Big Bang Approach) — это подход в тестировании, при котором все компоненты тестируются одновременно после сборки в одну систему.
Преимущества подхода:
- Удобен для небольших систем или для систем с независимыми компонентами, которые не имеют много взаимодействий между собой.
- Позволяет быстро запустить тестирование, не требуя много времени на подготовку.
Недостатки подхода Большой взрыв
- Сложно локализовать и исправить баги, поскольку все компоненты тестируются одновременно.
- При большом количестве компонентов могут быть упущены некоторые интерфейсы, что может привести к непредсказуемым результатам.
- Требуется много времени на подготовку и сборку компонентов, прежде чем можно начать тестирование интеграции.
- Критические модули высокого риска не изолируются и не тестируются в приоритетном порядке. Периферийные модули, которые имеют дело с пользовательскими интерфейсами, также не изолируются и не проверяются на приоритет.
- В целом, подход Большого взрыва не рекомендуется использовать в больших системах или в системах с высоким уровнем риска. Рекомендуется использовать более структурированные подходы, такие как инкрементное интеграционное тестирование или модульное тестирование, чтобы убедиться, что все компоненты работают правильно и взаимодействуют друг с другом без проблем.
Инкрементальный подход в интеграционном тестировании
Инкрементальный подход — это метод тестирования, при котором тестируемые модули объединяются попарно или группами и проверяются на соответствие заданным требованиям. Этот процесс повторяется до тех пор, пока все модули не будут объединены и протестированы. Данный подход может быть реализован с помощью двух разных методов: снизу вверх и сверху вниз.
Снизу вверх — начинается с тестирования наименьших и наиболее базовых модулей, которые затем объединяются с другими модулями для тестирования более сложных функций.
Сверху вниз — начинается с тестирования более крупных и сложных модулей и постепенно спускается до более мелких и базовых.
Для реализации инкрементального подхода используются заглушки и драйверы. Заглушки — это программы, которые моделируют взаимодействие тестируемого модуля с его окружением. Они не реализуют всю логику модуля, а только имитируют обмен данными с другими модулями. Драйверы, с другой стороны, вызывают модуль для тестирования и передают ему тестовые данные. Оба этих элемента помогают проводить тестирование отдельных модулей, даже если другие модули еще не готовы.
Инкрементальный подход имеет несколько преимуществ, таких как более быстрое выявление проблемных зон и более гибкая адаптация к изменениям в проекте. Однако, он также имеет некоторые недостатки, такие как необходимость тестировать одни и те же модули несколько раз и сложность обнаружения ошибок, которые могут возникнуть при взаимодействии разных модулей.
Интеграционное тестирование практики и советы
Интеграционное тестирование является важным этапом в разработке программного обеспечения и может существенно улучшить качество конечного продукта. Чтобы успешно пройти этот этап, следует придерживаться ряда лучших практик и рекомендаций:
- Определите интеграционную тестовую стратегию, которая соответствует вашим принципам разработки. Решите, какой подход к тестированию лучше всего подходит для вашего проекта: верхнего уровня, инкрементальный или Большой Взрыв.
- Изучите архитектуру приложения и определите критические модули. Эти модули должны быть проверены в первую очередь, поскольку они имеют наибольшее влияние на работу всего приложения.
- При получении проектов интерфейсов от команды разработки создайте контрольные примеры для проверки всех интерфейсов в деталях. Интерфейсы к базе данных, внешнему оборудованию или другому программному обеспечению должны быть детально протестированы.
- Подготовьте тестовые данные заранее. Не выбирайте тестовые данные во время выполнения тестовых случаев. Это поможет избежать ошибок и упущений в процессе тестирования.
- Создайте тестовые сценарии, которые полностью покрывают все функциональные возможности приложения. Обратите внимание на граничные условия и нестандартные ситуации, которые могут возникнуть в процессе использования приложения.
- При тестировании используйте автоматизированные инструменты тестирования. Это позволит сократить время тестирования и увеличит точность результатов.
- После проведения тестов анализируйте результаты и отслеживайте найденные ошибки. Исправьте ошибки и перезапустите тесты, чтобы убедиться, что они были исправлены.
- Не забывайте обновлять тестовые случаи при изменении приложения. Регулярное обновление тестовых случаев поможет гарантировать, что приложение будет работать корректно и без ошибок.
Все о тестировании и качестве ПО
- Мобильное тестирование
- Собеседование Junior QA
- Методы верификации программного обеспечения
- Валидация и верификация
- Расширенное тестирование
I believe in QA, все о тестировании
Октябрь 2023
Пн Вт Ср Чт Пт Сб Вс 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Больше о тестировании и качестве ПО
- Мобильное тестирование
- Виды нагрузочного тестирования
- Валидация и верификация
- Тестирование по степени глубины
- Тестирование локализации
- Системное тестирование
- Тестирование
- Основы