Что такое SIT? Системное интеграционное тестирование на примере.

Что такое системное интеграционное тестирование?

Система Интеграционное тестирование определяется как тип тестирования программного обеспечения, проводимый в интегрированной аппаратной и программной среде для проверки поведения всей системы. Это тестирование полной интегрированной системы с целью оценки ее соответствия установленным требованиям.

Системное интеграционное тестирование (SIT) выполняется для проверки взаимодействия между модулями программной системы. Он касается проверки требований к программному обеспечению высокого и низкого уровня, указанных в Спецификации/данных требований к программному обеспечению и Документе по проектированию программного обеспечения.

SIT также проверяет сосуществование программной системы с другими и тестирует интерфейс между модулями программного приложения. В этом типе тестирования модули сначала тестируются по отдельности, а затем объединяются для создания системы. Например, программные и/или аппаратные компоненты объединяются и тестируются постепенно, пока вся система не будет интегрирована.

Приведенная выше диаграмма иллюстрирует последовательность этапов тестирования интегрированной системы (SIT): отдельно проверенные модули поэтапно объединяются до тех пор, пока не будет сформирована единая интегрированная система, находящаяся на стадии тестирования.

Зачем проводить системное интеграционное тестирование?

В разработке программного обеспечения системное интеграционное тестирование проводится потому, что:

• Это помогает обнаружить дефект рано
• Ранее будет доступен отзыв о приемлемости отдельного модуля.
• График исправления дефектов является гибким и может совмещаться с разработкой.
• Правильный поток данных
• Правильный поток управления
• Правильное время
• Правильное использование памяти
• Правильно с требованиями к программному обеспечению

Интеграционное тестирование системы против системного тестирования против приемочного тестирования пользователями

Поскольку эти три уровня следуют один за другим, их часто путают. Тестирование системы SIT проверяет готовую конструкцию на соответствие требованиям, SIT проверяет стыки между конструкциями, и Пользователь приемочных испытаний Анализирует соответствие бизнеса потребностям клиента. В таблице ниже приведено их разделение.

Параметр	Системное интеграционное тестирование	Тестирование системы	Пользователь приемочных испытаний
Основной фокус	Интерфейсы и потоки данных между интегрированными модулями	Поведение собранной системы в целом.	Соответствие бизнес-требованиям для реального использования
Уровень тестирования	Второй уровень	Третий уровень	Финальный этап перед запуском в эксплуатацию.
Техника	Черный ящик	Черный ящик, белый ящик или серый ящик	Черный ящик
Выполняется	Интеграционные тестировщики и разработчики	Независимая группа тестирования	Клиенты или конечные пользователи
Типичные дефекты	Карта интерфейса, синхронизации, памяти и данныхping Ошибки	Функциональные и нефункциональные системные ошибки	Несоответствие между удобством использования и требованиями.
Запускается, когда	После Модульное тестирование	После SIT	После системного тестирования

Последовательность имеет значение. Модули проходят модульное тестирование, системное интеграционное тестирование (SIT) проверяет интерфейсы, системное тестирование (System Testing) проверяет собранный продукт, а пользовательское приемочное тестирование (UAT) подтверждает соответствие продукта ожиданиям бизнеса. Пропуститьping SIT переносит дефекты интерфейса в UAT, где каждое исправление обходится гораздо дороже.

Как провести системное интеграционное тестирование

Это систематический метод построения структуры программы с одновременным проведением тестов для выявления ошибок, связанных с взаимодействием с другими компонентами.

Все модули заранее интегрируются, а вся программа тестируется в целом. Но в ходе этого процесса, скорее всего, возникнет множество ошибок.

Исправление таких ошибок затруднено, поскольку изоляция причин усложняется огромным расширением всей программы. Как только эти ошибки будут исправлены и исправлены, появится новая, и процесс продолжится в бесконечном цикле.. Чтобы избежать этой ситуации, используется другой подход — инкрементальная интеграция. Инкрементальный подход подробно описан в следующем разделе.

Существуют некоторые дополнительные методы, например, интеграционные тесты проводятся в системе на базе целевого процессора. Используемая методология Цвет - Черный. Box Тестирование. Можно использовать интеграцию как снизу вверх, так и сверху вниз.

Тестовые случаи определяются только с использованием требований к программному обеспечению высокого уровня.

Интеграция программного обеспечения также может быть достигнута в основном в хост-среде, при этом модули, специфичные для целевой среды, продолжают моделироваться в хост-среде. Повторные тесты в целевой среде для подтверждения снова будут необходимы.

Подтверждающие тесты на этом уровне выявят проблемы, специфичные для среды, такие как ошибки при выделении и освобождении памяти. Практичность проведения интеграции программного обеспечения в хост-среде будет зависеть от того, насколько там имеется конкретная целевая функциональность. Для некоторых встроенных систем связь с целевой средой будет очень сильной, что делает непрактичным проведение интеграции программного обеспечения в хост-среде.

Крупные разработки программного обеспечения разделят интеграцию программного обеспечения на несколько уровней. Более низкие уровни интеграции программного обеспечения могут базироваться преимущественно в хост-среде, а более поздние уровни интеграции программного обеспечения становятся все более зависимыми от целевой среды.

Примечание: Если тестируется только программное обеспечение, то это называется интеграционным тестированием программного обеспечения [SSIT], а если тестируются как аппаратное, так и программное обеспечение, то это называется интеграционным тестированием аппаратного и программного обеспечения [HSIT].

Поэтапный подход

Поскольку одновременная интеграция всего процесса затрудняет выявление и локализацию дефектов, большинство команд следуют описанному здесь поэтапному подходу.

Инкрементальное тестирование — это способ интеграционного тестирования. В этом методе тестирования вы сначала тестируете каждый модуль программного обеспечения индивидуально, а затем продолжаете тестирование, добавляя к нему другие модули, затем еще один и так далее.

Постепенная интеграция контрастирует с подходом «большого взрыва». Программа строится и тестируется небольшими сегментами, где ошибки легче выявлять и исправлять. Интерфейсы, скорее всего, будут протестированы полностью, и может быть применен систематический подход к тестированию.

Существует два типа инкрементного тестирования.

• Нисходящий подход
• Подход «снизу вверх

Нисходящий подход

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

• Начиная с главного модуля управления, модули интегрируются, продвигаясь вниз по иерархии управления.
• Субмодули основного модуля управления встраиваются в структуру либо в ширину, либо в глубину.
• Интеграция в глубину объединяет все модули на основном пути управления структурой, как показано на следующей диаграмме:

Процесс интеграции модулей осуществляется следующим образом:

1. В качестве тест-драйвера используется основной модуль управления, а заглушки заменяют все модули, непосредственно подчиненные основному модулю управления.
2. Подчиненные заглушки заменяются по одному фактическими модулями в зависимости от выбранного подхода (сначала в ширину или сначала в глубину).
3. Тесты выполняются по мере интеграции каждого модуля.
4. По завершении каждого набора тестов другая заглушка заменяется реальным модулем после завершения каждого набора тестов.
5. Чтобы убедиться, что новые ошибки не были внесены Регрессионное тестирование может быть выполнено.

Процесс продолжается с шага 2 до тех пор, пока не будет построена вся структура программы. Стратегия «сверху вниз» звучит относительно несложно, но на практике возникают логистические проблемы.

Наиболее распространенные из этих проблем возникают, когда обработка на нижних уровнях иерархии необходима для адекватного тестирования верхних уровней.

Заглушки заменяют низкоуровневые модули в начале нисходящего тестирования, поэтому никакие важные данные не могут передаваться вверх по структуре программы.

Проблемы, с которыми может столкнуться тестер:

• Отложите многие тесты до тех пор, пока заглушки не будут заменены реальными модулями.
• Разработайте заглушки, выполняющие ограниченные функции, имитирующие реальный модуль.
• Интегрируйте программное обеспечение снизу вверх по иерархии.

Примечание: Первый подход приводит к тому, что мы теряем некоторый контроль над соответствием между конкретными тестами и включением конкретных модулей. Это может привести к трудностям с определением причины ошибок, что, как правило, нарушает строго ограниченный характер нисходящего подхода.

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

Подход «снизу вверх

Интеграция снизу вверх начинается с построения и тестирования модулей на самом низком уровне структуры программы. В этом процессе модули интегрируются снизу вверх.

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

Этот процесс интеграционного тестирования выполняется в четыре этапа.

1. Модули низкого уровня объединяются в кластеры, выполняющие определенную программную подфункцию.
2. Написан драйвер для координации ввода и вывода тестовых примеров.
3. Кластер или сборка тестируются.
4. Драйвера удаляются, а кластеры объединяются, продвигаясь вверх по структуре программы.

По мере продвижения интеграции вверх, необходимость в отдельных драйверах тестирования уменьшается. Фактически, если два верхних уровня структуры программы интегрируются сверху вниз, количество драйверов может быть существенно сокращено, а интеграция кластеров значительно упрощается. Интеграция следует схеме, показанной ниже.

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

Подход «большого взрыва»

При таком подходе все модули не интегрируются до тех пор, пока все модули не будут готовы. Как только они будут готовы, все модули интегрируются, а затем запускаются, чтобы узнать, работают ли все интегрированные модули или нет.

При таком подходе трудно узнать первопричину сбоя из-за интеграции всего сразу.

Кроме того, будет высока вероятность возникновения критических ошибок в производственной среде.

Этот подход применяется только тогда, когда интеграционное тестирование необходимо провести сразу.

Интеграционное тестирование аппаратного и программного обеспечения

Интеграционное тестирование аппаратного и программного обеспечения — это процесс тестирования компонентов компьютерного программного обеспечения (CSC) на предмет функциональности высокого уровня в целевой аппаратной среде. Целью тестирования интеграции аппаратного и программного обеспечения является проверка поведения разработанного программного обеспечения, интегрированного в аппаратный компонент.

Интеграционное тестирование аппаратного и программного обеспечения на основе требований

Цель тестирования интеграции аппаратного и программного обеспечения на основе требований — убедиться, что программное обеспечение на целевом компьютере соответствует требованиям высокого уровня. Типичные ошибки, выявляемые этим методом тестирования, включают в себя:

• Ошибки аппаратных/программных интерфейсов
• Нарушения программного разбиения.
• Невозможность обнаружить сбои встроенным тестом
• Неправильная реакция на аппаратные сбои
• Ошибка из-за последовательности, переходных входных нагрузок и переходных процессов входной мощности
• Неправильное поведение контуров обратной связи
• Неправильный или неправильный контроль оборудования управления памятью.
• Проблема конфликта на шине данных
• Неправильная работа механизма проверки совместимости и правильности загружаемого программного обеспечения.

Интеграция аппаратного программного обеспечения занимается проверкой требований высокого уровня. Все тесты на этом уровне проводятся на целевом оборудовании.

• Тестирование «черного ящика» — это основная методология тестирования, используемая на этом уровне тестирования.
• определять контрольные примеры только из требований высокого уровня
• Тест должен быть выполнен на стандартном оборудовании производства (на целевом объекте).

Что следует учитывать при разработке тестовых примеров для интеграции аппаратного и программного обеспечения

• Правильное получение всех данных с помощью программного обеспечения
• Масштабирование и диапазон данных, как и ожидалось, от аппаратного обеспечения до программного обеспечения.
• Корректный вывод данных из программного обеспечения в аппаратное обеспечение
• Данные в пределах спецификаций (нормальный диапазон)
• Данные за пределами технических характеристик (ненормальный диапазон)
• Граничные данные
• Прерывает обработку
• тайминг
• Правильное использование памяти (адресация, перекрытие и т. д.)
• Переходы между состояниями

Примечание: При тестировании прерываний все прерывания будут проверяться независимо от первоначального запроса, полного обслуживания и после завершения. Тестовые случаи будут специально разработаны для адекватного тестирования прерываний.

Интеграционное тестирование программного обеспечения

Это тестирование компонента компьютерного программного обеспечения, работающего в среде хост-компьютера/целевого компьютера, с имитацией всей системы [других компонентов компьютерного программного обеспечения] и ее высокоуровневой функциональности.

Основное внимание уделяется поведению CSC в смоделированной среде хост/цель. Подход к интеграции программного обеспечения может быть инкрементальным (сверху вниз, снизу вверх или их комбинация, также называемая сэндвич-подходом или гибридным подходом).

Критерии входа и выхода из интеграционного тестирования

После того, как подход и два варианта интеграции определены, остается вопрос, когда команда может начать и когда может закончить тестирование. Обычно при проведении интеграционного тестирования используется стратегия ETVX (критерии входа, задачи, проверки и критерии выхода).

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

• Завершение Модульное тестирование

Входы:

• Данные о требованиях к программному обеспечению
• Документ по дизайну программного обеспечения
• План проверки программного обеспечения
• Документы по интеграции программного обеспечения

Деятельность:

• На основе требований высокого и низкого уровня создайте тестовые сценарии и процедуры.
• Объединение сборок низкоуровневых модулей, реализующих общую функциональность.
• Разработать тестовую программу
• Протестируйте сборку
• После прохождения теста сборка объединяется с другими сборками и тестируется до тех пор, пока система не будет интегрирована в целом.
• Повторно выполните все тесты на целевой платформе процессора и получите результаты.

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

• Успешное завершение интеграции Программного модуля на целевое Оборудование.
• Корректная работа программного обеспечения в соответствии с указанными требованиями.

Выходы

• Отчеты об интеграционных тестах
• Примеры и процедуры тестирования программного обеспечения [SVCP].

Типичные проблемы при системном интеграционном тестировании

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

• Несоответствие окружающей среды: интегрированный тестовая среда Редко когда производство полностью соответствует производственным процессам, поэтому дефекты синхронизации и конфигурации остаются незамеченными до самого последнего момента.
• Готовность к зависимостям: Интерфейсы сторонних разработчиков и устаревшие интерфейсы часто остаются незавершенными, что вынуждает тестировщиков гораздо дольше, чем планировалось, полагаться на заглушки и симуляторы.
• Несоответствие данных: Два модуля могут представлять одну и ту же запись по-разному, что приводит к скрытым несоответствиям вместо видимых ошибок.
• Ответственность за дефект: Когда сбой затрагивает две команды, необходим анализ первопричин и управление дефектами Заметно сбавьте скорость.
• Стоимость регрессии: каждый новый интерфейс расширяет регрессионное тестирование В таком случае повторное выполнение вручную быстро становится нецелесообразным.

Большинство из них связаны с рисками, связанными со сроками, а не с техническими тупиками. Согласование дат готовности интерфейса, объема работ в симуляторе и ответственных за устранение дефектов до интеграции первой сборки позволяет исключить большинство из них. Для интерфейсов, принадлежащих поставщику, также следует зафиксировать согласованный формат сообщений и контактное лицо для эскалации, поскольку отсутствие ответственного лица задерживает исправление дольше, чем того требует дефект.

лучшие практики системного интеграционного тестирования

Повторяемый цикл системного тестирования зависит не столько от инструментов, сколько от дисциплинированного подхода к интерфейсам, данным и доказательствам. Пять описанных ниже методов одинаково подходят как для небольших встроенных систем, так и для крупных многовендорных платформ, и каждый из них сокращает объем доработок на более поздних этапах тестирования.

1. Сначала составьте карту всех интерфейсов. Перед написанием первого тестового примера перечислите каждый обмен данными, его направление, протокол и владельца.
2. Расставляйте приоритеты по степени риска. Прежде чем проверять интерфейсы, предназначенные для приема денежных средств, идентификации личности или передачи данных, подлежащих регулированию, убедитесь в их чисто эстетическом оформлении.
3. Разработайте реалистичные тестовые данные. Учитывайте нормальные, граничные и аномальные диапазоны, чтобы ошибки масштабирования и округления выявлялись на ранних стадиях.
4. Автоматизируйте создание стабильных маршрутов. Интерфейс проводной связи проверяет соединение. непрерывная интеграция Таким образом, каждый этап сборки выполняет повторную проверку этих параметров.
5. Храните улики tracэйбл. Свяжите каждый результат с требованием с помощью tracматрица возможностей Таким образом, критерии выхода можно доказать, а не утверждать.

⚠ Совет: Зафиксируйте спецификации интерфейса до начала интеграции. Позднее изменение формата сообщения делает недействительными тестовые примеры с обеих сторон интерфейса и является наиболее распространенной причиной доработки SIT.

Часто задаваемые вопросы (FAQ)