Що таке тестування системної інтеграції?
Тестування системної інтеграції визначається як тип тестування програмного забезпечення, що проводиться в інтегрованому апаратному та програмному середовищі для перевірки поведінки всієї системи. Це тестування, проведене на повній, інтегрованій системі для оцінки відповідності системи встановленим вимогам.
Тестування системної інтеграції (SIT) проводиться для перевірки взаємодії між модулями програмної системи. Це стосується перевірки вимог до програмного забезпечення високого та низького рівня, зазначених у Специфікації програмних вимог / даних та Документі проектування програмного забезпечення.
Він також перевіряє співіснування програмної системи з іншими та тестує інтерфейс між модулями програмного додатку. При такому типі тестування модулі спочатку тестуються індивідуально, а потім комбінуються для створення системи.
Наприклад, програмні та / або апаратні компоненти поєднуються та тестуються поступово, поки не буде інтегрована вся система.
У цьому підручнику ви дізнаєтесь-
- Що таке тестування системної інтеграції?
- Навіщо проводити тестування системної інтеграції
- Як зробити тестування системної інтеграції
- Критерії входу та виходу для інтеграційного тестування
- Тестування інтеграції програмного забезпечення на апаратне забезпечення
- Тестування інтеграції програмного забезпечення на програмне забезпечення
- Підхід зверху вниз
- Підхід знизу вгору
- Підхід Великого Вибуху
Навіщо проводити тестування системної інтеграції
У програмній інженерії тестування системної інтеграції проводиться тому, що,
- Це допомагає виявити дефект рано
- Раніше будуть доступні відгуки про прийнятність окремого модуля
- Планування виправлення дефектів є гнучким і може накладатися на розробку
- Правильний потік даних
- Правильний контроль потоку
- Правильний час
- Правильне використання пам'яті
- Виправте вимоги до програмного забезпечення
Як зробити тестування системної інтеграції
Це систематизована техніка побудови структури програми під час проведення тестів для виявлення помилок, пов’язаних із взаємодією.
Всі модулі інтегровані заздалегідь, і вся програма перевірена в цілому. Але під час цього процесу, ймовірно, буде зустрічатися набір помилок.
Виправити такі помилки важко, оскільки причини ізоляції ускладнюються великим розширенням всієї програми. Як тільки ці помилки будуть виправлені та виправлені, з’явиться нова, і процес безперервно триватиме у нескінченному циклі . Щоб уникнути такої ситуації, використовується інший підхід - Інкрементальна інтеграція. Детальніше про поступовий підхід ми побачимо пізніше у підручнику.
Є кілька додаткових методів, як тести інтеграції, що проводяться в системі на основі цільового процесора. Методологія, що використовується, - тестування чорної скриньки. Можна використовувати інтеграцію знизу вгору або зверху вниз.
Тестові випадки визначаються лише з використанням вимог програмного забезпечення високого рівня.
Інтеграція програмного забезпечення також може бути досягнута в основному в хост-середовищі, при цьому одиниці, характерні для цільового середовища, продовжують моделювати в хості. Для підтвердження знову будуть необхідні повторні тести в цільовому середовищі.
Підтверджувальні тести на цьому рівні дозволять виявити специфічні для середовища проблеми, такі як помилки у розподілі пам'яті та де-розподілі. Практичність проведення інтеграції програмного забезпечення в хост-середовищі буде залежати від того, скільки функцій є конкретною ціллю. Для деяких вбудованих систем зв'язок з цільовим середовищем буде дуже сильним, що робить недоцільним проведення інтеграції програмного забезпечення в хост-середовищі.
Великі розробки програмного забезпечення розділять інтеграцію програмного забезпечення на кілька рівнів. Нижні рівні інтеграції програмного забезпечення можуть базуватися переважно в хост-середовищі, а пізніші рівні інтеграції програмного забезпечення стають більш залежними від цільового середовища.
Примітка: Якщо тестується лише програмне забезпечення, це називається Тестування інтеграції програмного забезпечення програмного забезпечення [SSIT], а якщо тестується як апаратне, так і програмне забезпечення, це називається Тестування інтеграції програмного забезпечення [HSIT].
Критерії входу та виходу для інтеграційного тестування
Зазвичай під час проведення інтеграційного тестування використовується стратегія ETVX (критерії входу, завдання, перевірка та вихід).
Критерії вступу:
- Завершення модульного тестування
Входи:
- Дані вимог до програмного забезпечення
- Документ про розробку програмного забезпечення
- План верифікації програмного забезпечення
- Документи інтеграції програмного забезпечення
Діяльність:
- На основі вимог високого та низького рівня створіть тестові кейси та процедури
- Поєднують збірки модулів низького рівня, що реалізують загальну функціональність
- Розробіть пробний джгут
- Перевірте збірку
- Після проходження тесту збірка поєднується з іншими збірками та тестується, поки система не інтегрується як єдине ціле.
- Повторно виконайте всі тести на цільовій платформі на основі процесора та отримайте результати
Критерії виходу:
- Успішне завершення інтеграції програмного модуля на цільовому обладнанні
- Правильна робота програмного забезпечення відповідно до зазначених вимог
Виходи
- Звіти про інтеграційні випробування
- Випробувальні випадки та процедури програмного забезпечення [SVCP].
Тестування інтеграції програмного забезпечення
Тестування програмного забезпечення інтеграції програмного забезпечення - це процес тестування програмних компонентів комп’ютера (CSC) на наявність високоякісних функціональних можливостей цільового апаратного середовища. Метою тестування інтеграції апаратного / програмного забезпечення є перевірка поведінки розробленого програмного забезпечення, інтегрованого в апаратний компонент.
Тестування апаратно-програмної інтеграції на основі вимог
Метою тестування програмного забезпечення / інтеграції програмного забезпечення на основі вимог є переконатися, що програмне забезпечення цільового комп'ютера задовольняє високим вимогам. Типові помилки, виявлені цим методом тестування, включають:
- Помилки апаратного / програмного інтерфейсу
- Порушення розділення програмного забезпечення.
- Неможливість виявлення несправностей за допомогою вбудованого тесту
- Неправильна реакція на апаратні збої
- Помилка через послідовність, перехідні вхідні навантаження та вхідні перехідні процеси
- Цикли зворотного зв'язку неправильна поведінка
- Неправильний або неправильний контроль апаратного забезпечення для управління пам’яттю
- Проблема суперечки шини даних
- Неправильна робота механізму для перевірки сумісності та правильності завантажуваного на місцях програмного забезпечення
Інтеграція апаратного програмного забезпечення займається перевіркою вимог високого рівня. Всі тести на цьому рівні проводяться на цільовому обладнанні.
- Тестування чорної скриньки - основна методологія тестування, яка використовується на цьому рівні тестування.
- Визначте тестові кейси лише відповідно до вимог високого рівня
- Тест повинен бути виконаний на стандартному виробничому обладнанні (на цільовому рівні)
Що слід враховувати при розробці тестових кейсів для інтеграції HW / SW
- Правильне отримання всіх даних програмним забезпеченням
- Масштабування та діапазон даних, як очікується, від апаратного забезпечення до програмного забезпечення
- Правильний вихід даних із програмного забезпечення на апаратне забезпечення
- Дані в межах специфікацій (нормальний діапазон)
- Дані поза специфікаціями (ненормальний діапазон)
- Дані меж
- Обробка переривань
- Терміни
- Правильне використання пам'яті (адресація, перекриття тощо)
- Державні переходи
Примітка: Для тестування переривань усі переривання перевірятимуться незалежно від початкового запиту через повне обслуговування та до завершення. Тестові кейси будуть спеціально розроблені для адекватного тестування переривань.
Тестування інтеграції програмного забезпечення на програмне забезпечення
Це тестування Комп’ютерного програмного компонента, що працює в хост / цільовому комп’ютері
Навколишнє середовище, одночасно імітуючи всю систему [інші CSC], та функціонал високого рівня.
Він зосереджений на поведінці CSC в імітованому хост / цільовому середовищі. Підхід, який використовується для інтеграції програмного забезпечення, може бути додатковим (зверху вниз, підходом знизу вгору або їх комбінацією).
Додатковий підхід
Додаткове тестування - це спосіб інтеграційного тестування. У цьому типі методу тестування ви спочатку тестуєте кожен модуль програмного забезпечення окремо, а потім продовжуєте тестування, додаючи до нього інші модулі, потім інший тощо.
Поступова інтеграція є контрастом до підходу великого вибуху. Програма побудована та перевірена невеликими сегментами, де помилки легше відокремити та виправити. Інтерфейси, швидше за все, будуть протестовані повністю, і може бути застосований систематичний тестовий підхід.
Існує два типи додаткового тестування
- Підхід зверху вниз
- Підхід знизу вгору
Підхід зверху вниз
При цьому типі підходу індивідуальний початок тестування лише користувальницького інтерфейсу з базовою функціональністю, змодельованою заглушками, після чого ви рухаєтесь вниз, інтегруючи нижчий і нижній шари, як показано на зображенні нижче.
- Починаючи з основного модуля управління, модулі інтегруються, рухаючись вниз по ієрархії управління
- Підмодулі основного модуля управління вбудовуються в структуру або в першу чергу, або в глибину.
- Інтеграція по глибині інтегрує всі модулі на головному шляху управління структурою, як показано на наступній схемі:
Процес інтеграції модулів здійснюється наступним чином:
- Основний модуль управління використовується як тест-драйвер, а заглушки замінюються на всі модулі, безпосередньо підпорядковані основному модулю управління.
- Підпорядковані заглушки замінюються по черзі на фактичні модулі залежно від обраного підходу (спочатку ширини або спочатку глибини).
- Тести виконуються в міру інтеграції кожного модуля.
- Після завершення кожного набору тестів, інший заглушка замінюється реальним модулем після завершення кожного набору тестів
- Щоб переконатися, що нові помилки не були введені, може бути проведено тестування регресії.
Процес триває з кроку 2, поки не буде побудована вся структура програми. Стратегія зверху вниз звучить відносно нескладно, але на практиці виникають логістичні проблеми.
Найбільш поширені з цих проблем виникають, коли для адекватного тестування верхніх рівнів необхідна обробка на низьких рівнях в ієрархії.
Заглушки замінюють низькорівневі модулі на початку тестування зверху вниз, і тому ніякі суттєві дані не можуть надходити вгору в структурі програми.
Випробувач, з яким може зіткнутися:
- Затримуйте багато випробувань, поки заглушки не замінять справжніми модулями.
- Розробити заглушки, які виконують обмежені функції, що імітують фактичний модуль.
- Інтегруйте програмне забезпечення знизу ієрархії вгору.
Примітка: Перший підхід змушує нас втратити певний контроль над відповідністю між конкретними тестами та включенням конкретних модулів. Це може спричинити труднощі у визначенні причини помилок, які, як правило, порушують дуже обмежений характер підходу зверху вниз.
Другий підхід є дієвим, але може призвести до значних накладних витрат, оскільки заглушки стають дедалі складнішими.
Підхід знизу вгору
Інтеграція знизу вгору починає побудову та тестування за допомогою модулів на найнижчому рівні в структурі програми. У цьому процесі модулі інтегруються знизу вгору.
У цьому підході завжди доступна обробка модулів, підпорядкованих даному рівню, і необхідність у заглушках відпадає.
Цей процес перевірки інтеграції виконується у серію з чотирьох кроків
- Модулі низького рівня об’єднані в кластери, які виконують певну програмну підфункцію.
- Драйвер написаний для координації введення та виведення тестового випадку.
- Кластер або збірка тестується.
- Драйвери видаляються, а кластери об'єднуються вгору в структурі програми.
По мірі того, як інтеграція рухається вгору, необхідність окремих уроків тестування водіїв. Насправді, якщо два верхні рівні програми структурно інтегровані зверху вниз, кількість драйверів може бути значно зменшена, а інтеграція кластерів значно спрощена. Інтеграція слідує схемі, проілюстрованій нижче. По мірі того, як інтеграція рухається вгору, необхідність окремих уроків тестування водіїв.
Примітка. Якщо два верхні рівні програмної структури інтегровані зверху вниз, кількість драйверів може бути значно зменшена, а інтеграція збірок значно спрощена.
Підхід Великого Вибуху
При цьому підході всі модулі не інтегруються, доки всі модулі не будуть готові. Після того, як вони будуть готові, всі модулі інтегруються, а потім виконуються, щоб дізнатися, працюють чи всі інтегровані модулі.
При такому підході важко дізнатися першопричину несправності через інтеграцію всього відразу.
Крім того, буде висока ймовірність появи критичних помилок у виробничому середовищі.
Цей підхід застосовується лише тоді, коли інтеграційне тестування потрібно проводити відразу.
Короткий зміст:
- Інтеграція виконується для перевірки взаємодії між модулями програмної системи. Це допомагає рано виявити дефект
- Інтеграційне тестування можна провести для апаратно-програмного забезпечення чи апаратно-апаратного забезпечення
- Інтеграційне тестування проводиться двома методами
- Додатковий підхід
- Великий вибух
- Під час проведення інтеграційного тестування зазвичай використовується стратегія ETVX (критерії входу, завдання, перевірка та вихід).
