Что такое тестирование системной интеграции?
Тестирование интеграции системы определяется как тип тестирования программного обеспечения, проводимого в интегрированной аппаратной и программной среде для проверки поведения всей системы. Это тестирование, проводимое на полной интегрированной системе для оценки ее соответствия установленным требованиям.
Тестирование интеграции системы (SIT) выполняется для проверки взаимодействия между модулями программной системы. Он занимается проверкой требований к программному обеспечению высокого и низкого уровня, указанных в Спецификации / данных требований к программному обеспечению и Документе по разработке программного обеспечения.
Он также проверяет сосуществование программной системы с другими и тестирует интерфейс между модулями программного приложения. В этом типе тестирования модули сначала тестируются по отдельности, а затем объединяются в систему.
Например, программные и / или аппаратные компоненты объединяются и постепенно тестируются, пока не будет интегрирована вся система.
В этом руководстве вы узнаете:
- Что такое тестирование системной интеграции?
- Зачем нужно тестирование системной интеграции
- Как проводить тестирование системной интеграции
- Критерии входа и выхода для интеграционного тестирования
- Тестирование интеграции оборудования в программное обеспечение
- Программное обеспечение для тестирования интеграции программного обеспечения
- Нисходящий подход
- Подход «снизу вверх
- Подход Большого Взрыва
Зачем нужно тестирование системной интеграции
В программной инженерии тестирование системной интеграции выполняется, потому что:
- Помогает обнаружить дефект на ранней стадии
- Отзывы о приемлемости отдельного модуля будут доступны раньше.
- Планирование исправлений дефектов является гибким, и его можно совмещать с разработкой.
- Правильный поток данных
- Правильный поток управления
- Правильный выбор времени
- Правильное использование памяти
- Правильно с требованиями к программному обеспечению
Как проводить тестирование системной интеграции
Это систематический метод построения структуры программы при проведении тестов для выявления ошибок, связанных с взаимодействием.
Все модули заранее интегрированы, и вся программа тестируется как единое целое. Но во время этого процесса, вероятно, встретится набор ошибок.
Исправление таких ошибок затруднено, поскольку устранение причин осложняется огромным расширением всей программы. Как только эти ошибки будут исправлены и исправлены, появится новая, и процесс будет плавно продолжаться в бесконечном цикле . Чтобы избежать этой ситуации, используется другой подход - инкрементная интеграция. Мы увидим более подробную информацию об инкрементальном подходе позже в этом руководстве.
Есть несколько дополнительных методов, например, интеграционные тесты проводятся в системе, основанной на целевом процессоре. Используемая методология - это тестирование черного ящика. Может использоваться либо восходящая, либо нисходящая интеграция.
Тестовые случаи определяются только с использованием требований к программному обеспечению высокого уровня.
Интеграция программного обеспечения также может быть достигнута в основном в среде хоста, при этом модули, специфичные для целевой среды, продолжают моделироваться в хосте. Для подтверждения снова потребуется повторение тестов в целевой среде.
Подтверждающие тесты на этом уровне выявляют проблемы, связанные с конкретной средой, такие как ошибки в распределении и освобождении памяти. Практичность проведения интеграции программного обеспечения в среде хоста будет зависеть от того, сколько целевых функций имеется. Для некоторых встроенных систем связь с целевой средой будет очень сильной, что делает непрактичным выполнение интеграции программного обеспечения в среде хоста.
Крупные разработки программного обеспечения разделят интеграцию программного обеспечения на несколько уровней. Более низкие уровни интеграции программного обеспечения могут базироваться преимущественно в среде хоста, а более поздние уровни интеграции программного обеспечения становятся более зависимыми от целевой среды.
Примечание. Если тестируется только программное обеспечение, оно называется «Тестирование интеграции программного обеспечения» [SSIT], а если тестируются как аппаратное, так и программное обеспечение, то оно называется «Тестирование интеграции программного обеспечения» [HSIT].
Критерии входа и выхода для интеграционного тестирования
Обычно при выполнении интеграционного тестирования используется стратегия ETVX (критерии входа, задачи, проверки и критерии выхода).
Критерии входа:
- Завершение модульного тестирования
Входы:
- Данные о требованиях к программному обеспечению
- Документ по разработке программного обеспечения
- План проверки программного обеспечения
- Документы по интеграции программного обеспечения
Деятельность:
- На основе требований высокого и низкого уровня создайте тестовые примеры и процедуры.
- Комбинируйте сборки низкоуровневых модулей, которые реализуют общую функциональность
- Разработайте тестовую привязь
- Протестируйте сборку
- После прохождения теста сборка объединяется с другими сборками и тестируется до тех пор, пока система не будет интегрирована как единое целое.
- Повторите все тесты на целевой платформе на базе процессора и получите результаты.
Критерии выхода:
- Успешное завершение интеграции Программного модуля на целевое Оборудование
- Правильная работа программного обеспечения в соответствии с указанными требованиями
Выходы
- Отчеты интеграционных тестов
- Сценарии и процедуры тестирования программного обеспечения [SVCP].
Аппаратное тестирование интеграции программного обеспечения
Аппаратное тестирование интеграции программного обеспечения - это процесс тестирования компьютерных программных компонентов (CSC) на предмет функциональности высокого уровня в целевой аппаратной среде. Целью тестирования интеграции аппаратного / программного обеспечения является проверка поведения разработанного программного обеспечения, интегрированного в аппаратный компонент.
Тестирование интеграции аппаратно-программного обеспечения на основе требований
Цель тестирования интеграции аппаратного и программного обеспечения на основе требований - убедиться, что программное обеспечение на целевом компьютере удовлетворяет требованиям высокого уровня. Типичные ошибки, выявляемые этим методом тестирования, включают:
- Ошибки аппаратных / программных интерфейсов
- Нарушения программной разметки.
- Невозможность обнаружения отказов встроенным тестом
- Неправильная реакция на аппаратные сбои
- Ошибка из-за последовательности, переходных входных нагрузок и переходных процессов входной мощности
- Неправильное поведение контуров обратной связи
- Неправильный или неправильный контроль оборудования управления памятью
- Проблема конкуренции на шине данных
- Некорректная работа механизма проверки совместимости и корректности загружаемого ПО
Аппаратно-программная интеграция занимается проверкой требований высокого уровня. Все тесты на этом уровне проводятся на целевом оборудовании.
- Тестирование черного ящика - это основная методология тестирования, используемая на этом уровне тестирования.
- Определите тестовые примеры только на основе требований высокого уровня
- Тест должен быть выполнен на стандартном производственном оборудовании (на целевом оборудовании)
На что следует обратить внимание при разработке тестовых примеров для интеграции HW / SW
- Правильный сбор всех данных программным обеспечением
- Ожидаемое масштабирование и диапазон данных от оборудования до программного обеспечения
- Правильный вывод данных из программного обеспечения в оборудование
- Данные в пределах спецификации (нормальный диапазон)
- Данные за пределами спецификации (ненормальный диапазон)
- Граничные данные
- Обработка прерываний
- Сроки
- Правильное использование памяти (адресация, перекрытия и т. Д.)
- Переходы между состояниями
Примечание. Для тестирования прерываний все прерывания будут проверяться независимо от первоначального запроса через полное обслуживание и до завершения. Тестовые примеры будут специально разработаны для адекватного тестирования прерываний.
Программное обеспечение для тестирования интеграции программного обеспечения
Это тестирование компонента компьютерного программного обеспечения, работающего на главном / целевом компьютере.
Среда, при моделировании всей системы [других CSC], а также на высокоуровневой функциональности.
Он фокусируется на поведении CSC в смоделированной среде хоста / цели. Подход, используемый для интеграции программного обеспечения, может быть поэтапным (нисходящий подход, восходящий подход или их комбинация).
Поэтапный подход
Инкрементальное тестирование - это способ интеграционного тестирования. В этом типе метода тестирования вы сначала тестируете каждый модуль программного обеспечения по отдельности, а затем продолжаете тестирование, добавляя к нему другие модули, затем еще один и так далее.
Пошаговая интеграция - это отличие от подхода большого взрыва. Программа построена и протестирована на небольших участках, где ошибки легче локализовать и исправить. Более вероятно, что интерфейсы будут полностью протестированы, и может применяться систематический подход к тестированию.
Есть два типа инкрементального тестирования.
- Нисходящий подход
- Подход «снизу вверх
Нисходящий подход
В этом типе подхода каждый человек начинает с тестирования только пользовательского интерфейса с базовой функциональностью, моделируемой заглушками, затем вы двигаетесь вниз, интегрируя нижние и нижние уровни, как показано на рисунке ниже.
- Начиная с основного модуля управления, модули интегрируются путем продвижения вниз по иерархии управления.
- Подмодули главного модуля управления встраиваются в структуру либо в ширину, либо в глубину.
- Интеграция в глубину объединяет все модули на главном пути управления структурой, как показано на следующей диаграмме:
Процесс интеграции модуля осуществляется следующим образом:
- Основной модуль управления используется в качестве тестового драйвера, а заглушки заменяют все модули, непосредственно подчиненные основному модулю управления.
- Подчиненные заглушки заменяются по одной фактическими модулями в зависимости от выбранного подхода (сначала в ширину или сначала в глубину).
- Тесты выполняются по мере интеграции каждого модуля.
- По завершении каждого набора тестов другая заглушка заменяется реальным модулем по завершении каждого набора тестов.
- Чтобы убедиться, что новые ошибки не были внесены, может быть выполнено регрессионное тестирование.
Процесс продолжается с шага 2 до тех пор, пока не будет построена вся структура программы. Стратегия «сверху вниз» кажется относительно несложной, но на практике возникают логистические проблемы.
Наиболее частые из этих проблем возникают, когда обработка на нижних уровнях иерархии требуется для адекватного тестирования верхних уровней.
Заглушки заменяют низкоуровневые модули в начале нисходящего тестирования, поэтому никакие важные данные не могут перемещаться вверх по структуре программы.
Проблемы, с которыми может столкнуться тестировщик:
- Отложите многие тесты до тех пор, пока заглушки не будут заменены реальными модулями.
- Разработайте заглушки, которые выполняют ограниченные функции, имитирующие реальный модуль.
- Интегрируйте программное обеспечение снизу вверх по иерархии.
Примечание. При первом подходе мы теряем некоторый контроль над соответствием между конкретными тестами и включением определенных модулей. Это может привести к затруднениям в определении причины ошибок, что, как правило, нарушает очень ограниченный характер нисходящего подхода.
Второй подход работает, но может привести к значительным накладным расходам, поскольку заглушки становятся все более сложными.
Подход «снизу вверх
Интеграция снизу вверх начинается с построения и тестирования модулей на самом низком уровне в структуре программы. В этом процессе модули объединяются снизу вверх.
При таком подходе всегда доступна обработка, необходимая для модулей, подчиненных данному уровню, и устраняется необходимость в заглушках.
Этот процесс интеграционного тестирования состоит из четырех этапов.
- Модули нижнего уровня объединяются в кластеры, которые выполняют определенную программную подфункцию.
- Драйвер написан для координации ввода и вывода тестового примера.
- Кластер или сборка тестируются.
- Драйверы удаляются, а кластеры объединяются, двигаясь вверх по структуре программы.
По мере развития интеграции возникает необходимость в отдельных уроках тестировщиков. Фактически, если два верхних уровня структуры программы интегрированы сверху вниз, количество драйверов может быть существенно уменьшено, а интеграция кластеров значительно упрощена. Интеграция происходит по схеме, показанной ниже. По мере развития интеграции возникает необходимость в отдельных уроках тестировщиков.
Примечание. Если два верхних уровня структуры программы интегрированы сверху вниз, количество драйверов может быть существенно уменьшено, а интеграция сборок значительно упростится.
Подход Большого Взрыва
При таком подходе все модули не интегрируются до тех пор, пока все модули не будут готовы. Когда они готовы, все модули интегрируются, а затем выполняется, чтобы узнать, все ли интегрированные модули работают или нет.
При таком подходе трудно определить основную причину сбоя из-за интеграции всего сразу.
Также высока вероятность появления критических ошибок в производственной среде.
Этот подход применяется только тогда, когда интеграционное тестирование необходимо провести сразу.
Резюме:
- Интеграция выполняется для проверки взаимодействия между модулями программной системы. Помогает выявить дефект на ранней стадии
- Интеграционное тестирование может быть выполнено для аппаратно-программной или аппаратно-аппаратной интеграции.
- Интеграционное тестирование проводится двумя способами.
- Поэтапный подход
- Подход большого взрыва
- При выполнении интеграционного тестирования обычно используется стратегия ETVX (критерии входа, задачи, проверки и критерии выхода).