Що таке SIT? Тестування системної інтеграції з прикладом

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

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

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

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

Наведена вище діаграма показує послідовність, яка визначає SIT: окремо перевірені модулі об'єднуються крок за кроком, доки не залишиться єдина інтегрована система, що перебуває в тестуванні.

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

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

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

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

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

Параметр	Тестування системної інтеграції	Тестування системи	Користувач приймальних випробувань
Основний фокус	Інтерфейси та потік даних між інтегрованими модулями	Поведінка зібраної конструкції в цілому	Придатність для бізнесу для реального використання
Рівень тестування	Другий рівень	Третій рівень	Фінальний рівень перед запуском
Техніка	Чорна скринька	Чорна скринька, біла скринька або сіра скринька	Чорна скринька
Виконано	Тестувальники та розробники інтеграції	Незалежна команда тестувальників	Клієнт або кінцеві користувачі
Типові дефекти	Інтерфейс, синхронізація, пам'ять та карта данихping Помилки	Функціональні та нефункціональні системні помилки	Невідповідність зручності використання та вимог
Виконується, коли	після Unit Testing	Після СІТ	Після тестування системи

Послідовність має значення. Модулі проходять модульне тестування, SIT перевіряє інтерфейси, системне тестування перевіряє зібраний продукт, а UAT підтверджує відповідність продукту бізнес-очікуванням. Пропустити.ping SIT переносить дефекти інтерфейсу в UAT, де кожне виправлення коштує набагато дорожче.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Завершення Unit Testing

Inputs:

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

Діяльність:

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

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

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

Виходи

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

Поширені проблеми тестування системної інтеграції

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

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

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

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

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

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

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

Поширені запитання