Что такое пример системного интеграционного тестирования (SIT)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Входы:

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

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

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

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

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

Выходы

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

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

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

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

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

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

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

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

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

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

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

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

Это тестирование компонента компьютерного программного обеспечения, работающего на главном/целевом компьютере.

Окружающая среда, моделирующая всю систему [другие CSC], и функциональность высокого уровня.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

Вы могли бы: