Приклад тестування системної інтеграції (SIT).

Що таке тестування системної інтеграції?

SYSTEM Інтеграційне тестування визначається як тип тестування програмного забезпечення, що виконується в інтегрованому апаратному та програмному середовищі для перевірки поведінки всієї системи. Це тестування, що проводиться на повній інтегрованій системі для оцінки відповідності системи визначеним вимогам.

Тестування системної інтеграції (SIT) виконується для перевірки взаємодії між модулями програмної системи. Він стосується перевірки вимог до програмного забезпечення високого та низького рівнів, зазначених у специфікації/даних вимог до програмного забезпечення та документі щодо розробки програмного забезпечення. Він також перевіряє співіснування програмної системи з іншими та перевіряє інтерфейс між модулями програмної програми. У цьому типі тестування модулі спочатку тестуються окремо, а потім об’єднуються в систему. Наприклад, програмні та/або апаратні компоненти поєднуються та тестуються поступово, доки не буде інтегровано всю систему.

Тестування системної інтеграції

Навіщо проводити тестування системної інтеграції?

У розробці програмного забезпечення тестування системної інтеграції проводиться тому, що:

  • Це допомагає виявити Дефект рано
  • Попередні відгуки щодо прийнятності окремого модуля будуть доступні
  • Планування виправлення дефектів є гнучким і може накладатися на розробку
  • Правильний потік даних
  • Правильний потік керування
  • Правильний час
  • Коректне використання пам'яті
  • Відповідає вимогам програмного забезпечення

Як виконати тестування системної інтеграції

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

Всі модулі інтегруються заздалегідь, і вся програма тестується в цілому. Але під час цього процесу, ймовірно, виникне низка помилок.

Виправлення таких помилок є складним, оскільки ізоляція причин ускладнюється величезним розширенням усієї програми. Щойно ці помилки будуть виправлені та виправлені, з’явиться нова, і процес безперешкодно триватиме в нескінченному циклі. Щоб уникнути цієї ситуації, використовується інший підхід, поетапна інтеграція. Ми побачимо докладніші відомості про поступовий підхід пізніше в підручнику.

Існують деякі інкрементні методи, наприклад інтеграційні тести, які проводяться в системі на основі цільового процесора. Використана методологія Black Box Тестування. Можна використовувати інтеграцію знизу вгору або зверху вниз.

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

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

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

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

Примітка: Якщо тестується лише програмне забезпечення, це називається Тестування інтеграції програмного забезпечення [SSIT], а якщо тестуються як апаратне, так і програмне забезпечення, то це називається Тестування інтеграції програмного забезпечення [HSIT].

Критерії входу та виходу для інтеграційного тестування

Зазвичай під час виконання інтеграційного тестування використовується стратегія ETVX (критерії входу, завдання, перевірки та критерії виходу).

Критерії вступу:

Inputs:

  • Дані про вимоги до програмного забезпечення
  • Проектний документ програмного забезпечення
  • План перевірки програмного забезпечення
  • Документи щодо інтеграції програмного забезпечення

Діяльність:

  • На основі вимог високого та низького рівня створіть тестові випадки та процедури
  • Комбінуйте низькорівневі збірки модулів, які реалізують спільну функціональність
  • Розробіть тестовий джгут
  • Перевірте збірку
  • Після проходження тесту збірка поєднується з іншими збірками та тестується, доки система не буде інтегрована в єдине ціле.
  • Повторно виконайте всі тести на платформі цільового процесора та отримайте результати

Критерії виходу:

  • Успішне завершення інтеграції програмного модуля на цільове обладнання
  • Правильна робота програмного забезпечення відповідно до зазначених вимог

Виходи

  • Звіти про тестування інтеграції
  • Випадки тестування програмного забезпечення та процедури [SVCP].

Тестування апаратної інтеграції програмного забезпечення

Тестування апаратної інтеграції програмного забезпечення це процес тестування компонентів комп’ютерного програмного забезпечення (CSC) для функціональності високого рівня в цільовому апаратному середовищі. Метою тестування інтеграції апаратного/програмного забезпечення є перевірка поведінки розробленого програмного забезпечення, інтегрованого в апаратний компонент.

Тестування апаратно-програмної інтеграції на основі вимог

Метою тестування інтеграції апаратного та програмного забезпечення на основі вимог є переконатися, що програмне забезпечення на цільовому комп’ютері задовольнятиме вимогам високого рівня. Типові помилки, виявлені цим методом тестування, включають:

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

Інтеграція програмного забезпечення апаратного забезпечення займається перевіркою вимог високого рівня. Усі тести на цьому рівні проводяться на цільовому обладнанні.

  • Тестування чорного ящика є основною методологією тестування, яка використовується на цьому рівні тестування.
  • Визначте тестові справи лише від вимог високого рівня
  • Тест має бути виконано на стандартному виробничому апаратному забезпеченні (за призначенням)

Речі, які слід враховувати при розробці тестових випадків для інтеграції апаратного та програмного забезпечення

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

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

Тестування інтеграції програмного забезпечення

Це тестування компонента комп’ютерного програмного забезпечення, що працює на головному/цільовому комп’ютері

Середовище, імітуючи всю систему [інші CSC], і на функціональності високого рівня.

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

Інкрементальний підхід

Інкрементне тестування – це спосіб інтеграційного тестування. У цьому типі методу тестування ви спочатку тестуєте кожен модуль програмного забезпечення окремо, а потім продовжуєте тестування, додаючи до нього інші модулі, потім ще один і так далі.

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

Існує два типи інкрементального тестування

  • Підхід зверху вниз
  • Підхід «знизу вгору».

Підхід зверху вниз

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

Підхід зверху вниз

  • Починаючи з основного модуля керування, модулі об’єднуються шляхом просування вниз по ієрархії керування
  • Підмодулі головного модуля керування включені в структуру або в ширину, або в глибину.
  • Поглиблена інтеграція об’єднує всі модулі на головному шляху керування структурою, як показано на наступній діаграмі:

Підхід зверху вниз

Процес інтеграції модуля здійснюється таким чином:

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

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

Найбільш поширені з цих проблем виникають, коли обробка на низьких рівнях в ієрархії потрібна для адекватного тестування верхніх рівнів.

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

Проблеми, з якими може зіткнутися тестувальник:

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

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

Другий підхід працює, але може призвести до значних витрат, оскільки заглушки стають дедалі складнішими.

Підхід «знизу вгору».

Інтеграція «знизу вгору» починається з розробки та тестування модулів на найнижчому рівні в структурі програми. У цьому процесі модулі інтегруються знизу вгору.

У цьому підході обробка, необхідна для модулів, підлеглих даному рівню, завжди доступна, і потреба в заглушках усувається.

Цей процес тестування інтеграції виконується в серії з чотирьох кроків

  1. Модулі низького рівня об'єднуються в кластери, які виконують певну програмну підфункцію.
  2. Драйвер написаний для координації введення та виведення тестового випадку.
  3. Кластер або збірка тестується.
  4. Драйвери видаляються, а кластери об'єднуються, рухаючись вгору в структурі програми.

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

Підхід «знизу вгору».

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

Підхід Великого Вибуху

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

У такому підході важко визначити першопричину невдачі через інтеграцію всього й одразу.

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

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

Підсумки

  • Інтеграція виконується для перевірки взаємодії між модулями програмної системи. Це допомагає вчасно виявити дефект
  • Тестування інтеграції можна виконати для апаратно-програмної або апаратно-апаратної інтеграції
  • Інтеграційне тестування проводиться двома методами
    • Поетапний підхід
    • Підхід великого вибуху
  • Під час виконання інтеграційного тестування зазвичай використовується стратегія ETVX (критерії входу, завдання, перевірки та критерії виходу).