Интеграционное тестирование (Integration testing)

Интеграционное тестирование предназначено для проверки насколько хорошо два или более компонента ПО взаимодействуют друг с другом, а также взаимодействия с различными частями системы (операционной системой, оборудованием либо связи между различными системами). С технологической точки зрения интеграционное тестирование является количественным развитием компонентного, поскольку также оперирует интерфейсами модулей и подсистем и требует создания тестового окружения, включая заглушки (Stub) на месте отсутствующих модулей. Основная разница между компонентным и интеграционным тестированием состоит в целях, то есть в типах обнаруживаемых дефектов, которые, в свою очередь, определяют стратегию выбора входных данных и методов анализа. В частности, на уровне интеграционного тестирования часто применяются методы, связанные с покрытием интерфейсов, например, вызовов функций или методов, или анализ использования интерфейсных объектов, таких как глобальные ресурсы, средства коммуникаций, предоставляемых операционной системой.

Уровни интеграционного тестирования:

● Компонентный интеграционный уровень (CIT - Component Integration testing): Проверяется взаимодействие между компонентами одной системы после проведения компонентного тестирования. Программные компоненты или модули могут быть определены в разное время совершенно разными группами спецификаций, component integration testing выполняется чтобы убедиться, что даже после различий в разработке модулей интеграция всего работает вместе. В этом случае также важно учесть отрицательные случаи, так как компоненты могут делать предположения относительно данных;

● Системный интеграционный уровень (SIT - System Integration testing): - это полное тестирование всей системы, состоящей из множества подсистем. Основная цель SIT - обеспечить правильное функционирование всех зависимостей программных модулей и сохранение целостности данных между отдельными модулями всей системы. SUT (System Under Test) может состоять из аппаратного обеспечения, базы данных, программного обеспечения, комбинации аппаратного и программного обеспечения или системы, требующей взаимодействия с человеком (HITL - Human in the Loop Testing). SIT имеет предварительное условие, при котором несколько базовых интегрированных систем уже прошли системное тестирование. Затем SIT проверяет необходимые взаимодействия между этими системами в целом. Результаты SIT передаются в UAT (пользовательское приемочное тестирование);

Интеграция может быть как программной, так и софт-железо:

● HSIT - Hardware Software Integration Testing: представляет собой процесс тестирования компонентов компьютерного программного обеспечения (CSC - Computer Software Components) на предмет функциональности высокого уровня в целевой аппаратной среде. Тестирование черного ящика - это основной тип тестирования, используемый на этом уровне тестирования. Целью тестирования интеграции аппаратного / программного обеспечения является проверка поведения разработанного программного обеспечения, интегрированного в аппаратный компонент. Цель тестирования интеграции аппаратного и программного обеспечения на основе требований (Requirement based Hardware-Software Integration Testing) - убедиться, что программное обеспечение на целевом компьютере удовлетворяет высокоуровневым требованиям (high-level requirements);

● SSIT - Software Software Integration Testing: это Computer Software Component Testing, работающего в среде целевого компьютера при моделировании всей системы [других CSC], и на функциональности высокого уровня. Оно фокусируется на поведении CSC в смоделированной среде хоста / цели. Для проверки интеграции программного обеспечения используются разные подходы;

Подходы к интеграционному тестированию:

● Подход Большого взрыва (Big Bang Approach): Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если Test case и их результаты записаны неверно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования;

● Инкрементальный подход (Incremental Approach): при таком подходе тестирование выполняется путем объединения двух или более логически связанных модулей. Затем другие связанные модули поэтапно добавляются и тестируются для правильного функционирования. Процесс продолжается до тех пор, пока все модули не будут соединены и успешно протестированы. Осуществляется разными методами:

○ Нисходящий подход (Top-Down Approach): Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами. Преимущества: Локализация неисправностей проще. Возможность получить ранний прототип. Основные недостатки дизайна могут быть найдены и исправлены в первую очередь. Недостатки: Нужно много заглушек. Модули на более низком уровне тестируются недостаточно;

○ Подход снизу-вверх (Bottom-Up Approach): В восходящей стратегии каждый модуль на более низких уровнях последовательно тестируется с более высокоуровневыми модулями, пока не будут протестированы все модули. Требуется помощь драйверов для тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения. Пример низкоуровневого модуля - модуль, который заведует хранением токенов авторизации. Высокоуровневый - модуль авторизации, в состав которого помимо прочего входит модуль токенов. Преимущества: Локализация ошибок проще. Не тратится время на ожидание разработки всех модулей, в отличие от подхода Большого взрыва. Недостатки: Критические модули (на верхнем уровне архитектуры ПО), которые контролируют поток приложения, тестируются последними и могут быть подвержены дефектам. Ранний прототип невозможен;

○ Гибридный/сэндвич-подход (Sandwich Approach): Представляет собой комбинацию подходов сверху вниз и снизу-вверх. Здесь верхние модули тестируются с нижними модулями, а нижние модули интегрируются с верхними модулями и тестируются. Эта стратегия использует и заглушки и драйверы;

Критерии начала и окончания Integration Testing:

Обычно при выполнении интеграционного тестирования используется стратегия ETVX (Entry Criteria, Task, Validation, Exit Criteria).

● Критерии начала:

○ завершено модульное тестирование;

● На входе:

○ Software Requirements Data;

○ Software Design Document;

○ Software Verification Plan;

○ Software Integration Documents;

● Действия:

○ На основе требований высокого и низкого уровня (High and Low-level requirements) создайте test cases and procedures;

○ Комбинируйте сборки низкоуровневых модулей, которые реализуют общую функциональность;

○ Разработайте тестовую обвязку (test harness);

○ Протестируйте сборку;

○ После прохождения теста сборка объединяется с другими сборками и тестируется до тех пор, пока система не будет интегрирована как единое целое;

○ Повторите все тесты на целевой processor-based platform и получите результаты;

● Критерии выхода:

○ Успешное завершение интеграции Программного модуля на целевое Hardware;

○ Правильная работа программного обеспечения в соответствии с указанными требованиями;

● На выходе:

○ Integration test reports;

○ SVCP - Software Test Cases and Procedures;

Test Harness- это набор заглушек, драйверов и других вспомогательных инструментов, необходимых для объединения двух компонентов кода или модуля, которые взаимодействуют друг с другом, чтобы проверить, соответствует ли комбинированное поведение ожидаемому или нет.

Test Driver и Test Stub являются искусственными заменами компонентов программы на время тестов по аналогии с моками в тестировании API. Тестовый драйвер - то, что вызывает тестируемый компонент. Тестовая заглушка - то, что возвращает тестируемому компоненту фиктивный ответ. Т.е. заглушки и драйверы не реализуют всю логику программного модуля, а только моделируют обмен данными с тестируемым модулем.

Тестирование интерфейса - это тип интеграционного теста, который проверяет, правильно ли установлена ​​связь между двумя различными программными системами или их частями (модулями). Соединение, которое объединяет два компонента, называется интерфейсом. Этот интерфейс в компьютерном мире может быть чем угодно, как API, так и веб-сервисами и т. д. Тестирование интерфейса включает в себя тестирование двух основных сегментов:

● Интерфейс веб-сервера и сервера приложений

● Интерфейс сервера приложений и базы данных

Тестирование потоков (Thread testing) - это вид тестирования программного обеспечения, который проверяет основные функциональные возможности конкретной задачи (потока). Обычно проводится на ранней стадии фазы интеграционного тестирования. Тестирование на основе потоков является одной из дополнительных стратегий, принятых в ходе System Integration Testing. Поэтому его, вероятно, следует более правильно назвать «тестом взаимодействия потоков» (thread interaction test).

Thread Testing подразделяется на две категории:

● Однопоточное тестирование (Single thread testing) включает одну транзакцию приложения за раз;

● Многопоточное тестирование (Multi-thread testing) включает одновременно несколько активных транзакций;

Как проводить Thread Testing:

● Тестирование на основе потоков является обобщенной формой тестирования на основе сеансов (session-based testing), в котором сеансы являются формой потока, но поток не обязательно является сеансом;

● Для тестирования потока, поток или программа (небольшая функциональность) интегрируются и тестируются постепенно как подсистема, а затем выполняются для всей системы;

● На самом низком уровне оно предоставляет интеграторам лучшее представление о том, что тестировать;

● Вместо непосредственного тестирования программных компонентов требуется, чтобы интеграторы сосредоточились на тестировании логических путей выполнения в контексте всей системы;

Советы:

● Протестируйте свою многопоточную программу, многократно выполняя ее с другим набором запущенных приложений;

● Протестируйте свою многопоточную программу, активировав одновременно несколько экземпляров программы;

● Выполняйте многопоточную программу на разных моделях оборудования с различными уровнями нагрузки и рабочими нагрузками;

● Инспекция кода;

● Собирайте только ошибки и сбои, которые произошли в потоках, отличных от основного;

Источники:

● Integration Testing

● Лекция 5: Модульное и интеграционное тестирование

● What is Thread Testing in Software Testing?

Доп. материал:

● Интеграционные тесты в микросервисах

● Лекция 6: Интеграционное тестирование и его особенности для объектно-ориентированного программирования

● Для чего нужно интеграционное тестирование?

● Component / System integration testing examples

● #11 Артем и Сева. Моки(Mocks) и стабы(Stubs)

● Mocks Aren't Stubs

● Почему мы решили создать отдел кросс-системного тестирования

● Кто такой кросс-системный тестировщик и почему он не должен быть «agile»?

● What Is Thread Testing In Software Testing