Інтеграційне тестування (Integration testing)

Інтеграційне тестування (integration testing): Тестування, яке виконується для виявлення дефектів в інтерфейсах та у взаємодії між інтегрованими компонентами або системами. також тестування інтеграції компонентів, системне інтеграційне тестування. (ISTQB)

Системне інтеграційне тестування (system integration testing): Тестування інтеграції систем та пакетів програм, тестування інтерфейсів зв'язку із зовнішніми системами (інтернет тощо). (ISTQB)

Інтеграційне тестування в малому (Integration testing in the small): Див. Тестування інтеграції компонентів. (ISTQB)

Інтеграційне тестування загалом (Integration testing in the large): Див. системне інтеграційне тестування. (ISTQB)

Ізоляційне тестування (isolation testing): Тестування окремих компонентів в ізоляції від навколишніх компонентів в оточенні компонентів, які при необхідності емулюються заглушками та драйверами. (ISTQB)

Попарне інтеграційне тестування (pairwise integration testing): Вид інтеграційного тестування, націленого на пари компонентів, що працюють спільно відповідно до графи викликів. (ISTQB)

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

Рівні інтеграційного тестування :

Компонентний інтеграційний рівень (CIT – ): Перевіряється взаємодія між компонентами однієї системи після проведення компонентного тестування. Програмні компоненти або модулі можуть бути визначені в різний час абсолютно різними групами специфікацій, component integration testing виконується щоб переконатися, що навіть після відмінностей у розробці модулів інтеграція працює всього разом. У цьому випадку також важливо врахувати негативні випадки, оскільки компоненти можуть робити припущення щодо даних;
Системний інтеграційний рівень (SIT - ): - це повне тестування всієї системи, що складається з багатьох підсистем. Основна мета SIT – забезпечити правильне функціонування всіх залежностей програмних модулів та збереження цілісності даних між окремими модулями всієї системи. SUT ( ) може складатися з апаратного забезпечення, бази даних, програмного забезпечення, комбінації апаратного та програмного забезпечення або системи, що потребує взаємодії з людиною (HITL - Testing). SIT має попередню умову, коли кілька базових інтегрованих систем вже пройшли системне тестування. Потім SIT перевіряє необхідні взаємодії між цими системами загалом. Результати SIT передаються в UAT (приймальне тестування користувача);

Інтеграція може бути як програмною, так і софт-залізо :

HSIT - Hardware Software Integration Testing: це процес тестування компонентів комп'ютерного програмного забезпечення (CSC - Computer Software Components) щодо функціональності високого рівня цільової апаратної середовищі. Тестування чорної скриньки – це основний тип тестування, який використовується на цьому рівні тестування. Метою тестування інтеграції апаратного/програмного забезпечення є перевірка поведінки розробленого програмного забезпечення, інтегрованого в апаратний компонент. Мета тестування інтеграції апаратного та програмного забезпечення на основі вимог (Requirement based Hardware-Software Integration Testing) – переконатися, що програмне забезпечення на цільовому комп'ютері задовольняє високорівневим вимогам (high-level requirements);
SSIT - Software Software Integration Testing: це Computer Software Component Testing, що працює серед цільового комп'ютера при моделюванні всієї системи (інших CSC), і функціональності високого рівня. Воно фокусується на поведінці CSC у змодельованому середовищі хоста/мети. Для перевірки інтеграції програмного забезпечення використовують різні підходи;

Підходи до інтеграційного тестування :

Підхід Великого вибуху (Big Bang Approach) : “Вигляд підходу до інтеграційного тестування, у якому елементи програмного чи апаратного забезпечення, чи те й те, збираються в компонент чи цілу систему відразу, а чи не по этапам.” (IEEE 610) . Усі або практично всі розроблені модулі збираються разом у вигляді закінченої системи або її основної частини, а потім проводиться інтеграційне тестування. Такий підхід дуже добрий для збереження часу. Однак якщо Test case та їх результати записані невірно, то сам процес інтеграції сильно ускладниться, що стане перепоною для команди тестування при досягненні основної мети інтеграційного тестування;
Інкрементальний підхід (Incremental Approach) : за такого підходу тестування виконується шляхом об'єднання двох або більше логічно зв'язаних модулів. Потім інші пов'язані модулі поетапно додаються та тестуються для правильного функціонування. Процес триває доти, доки всі модулі не будуть з'єднані та успішно протестовані. Здійснюється різними методами:
- Східний підхід (Top-Down Approach) : Спочатку тестуються всі високорівневі модулі, і поступово один за одним додаються низькорівневі. Усі модулі нижчого рівня симулюються заглушками з аналогічною функціональністю, потім у міру готовності заміняються реальними активними компонентами. Переваги: Локалізація несправностей простіша. Можливість одержати ранній прототип. Основні недоліки дизайну можуть бути знайдені та виправлені насамперед. Недоліки: Потрібно багато заглушок. Модулі нижчому рівні тестуються недостатньо;
- Висхідний підхід (Bottom-Up Approach): У висхідній стратегії кожен модуль на нижчих рівнях послідовно тестується з більш високорівневими модулями, доки не будуть протестовані всі модулі. Потрібна допомога драйверів для тестування. Даний підхід вважається корисним, якщо всі або практично всі модулі, що розробляється, готові. Також цей підхід допомагає визначити за результатами тестування рівень готовності програми. Приклад низькорівневого модуля - модуль, який управляє зберіганням токенів авторизації. Високорівневий - модуль авторизації, до складу якого також входить модуль токенів. Переваги: Локалізація помилок простіше. Не витрачається час очікування розробки всіх модулів, на відміну підходу Великого вибуху. Недоліки: Критичні модулі (на верхньому рівні архітектури ПЗ), які контролюють потік програми, тестуються останніми і можуть бути схильні до дефектів. Ранній прототип неможливий;
- (Sandwich/Hybrid/Bi-Directional Approach) : Є комбінацією висхідного та низхідного підходів. Тут метою є середній шар, тоді як драйвери замінюють верхній шар, а заглушки нижній поки компоненти цих шарів не будуть розроблені;

Критерії початку та закінчення Integration Testing :

Критерії початку:
- завершено модульне тестування;
На вході:
- Software Requirements Data;
- Software Design Document;
- Software Verification Plan;
- Software Integration Documents;
Дії:
- На основі вимог високого та низького рівня (High and Low-level requirements) створіть test cases and procedures;
- Комбінуйте складання низькорівневих модулів, що реалізують загальну функціональність;
- Розробте тестове обв'язування (test harness);
- Протестуйте складання;
- Після проходження тесту складання об'єднується з іншими складаннями і тестується доти, доки система не буде інтегрована як єдине ціле;
- Повторіть усі тести на цільовий процесор-базований платформу та отримайте результати;
Критерії виходу:
- Успішне завершення інтеграції Програмного модуля на цільове Hardware;
- Правильна робота програмного забезпечення відповідно до зазначених вимог;
На виході:
- Integration test reports;
- SVCP - Software Test Cases and Procedures;

Інтерфейс веб-сервера та сервера додатків
Інтерфейс сервера додатків та бази даних

Тестування потоків (Thread testing) – це вид тестування програмного забезпечення, який перевіряє основні функціональні можливості конкретного завдання (потоку). Зазвичай, проводиться на ранній стадії фази інтеграційного тестування. Тестування на основі потоків є однією з додаткових стратегій, прийнятих під час System Integration Testing. Тому його, мабуть, слід правильніше назвати «тестом взаємодії потоків» (thread interaction test).

Thread Testing поділяється на дві категорії:

Однопотокове тестування (Single thread testing) включає одну транзакцію програми за раз;
Багатопотокове тестування (Multi-thread testing) включає одночасно кілька активних транзакцій;

Як проводити Thread Testing:

Тестування з урахуванням потоків є узагальненою формою тестування з урахуванням сеансів (session-based testing), у якому сеанси є формою потоку, але потік необов'язково є сеансом;
Для тестування потоку потік або програма (невелика функціональність) інтегруються і тестуються поступово як підсистема, а потім виконуються для всієї системи;
На найнижчому рівні воно надає інтеграторам найкраще уявлення про те, що тестувати;
Замість безпосереднього тестування програмних компонентів потрібно, щоб інтегратори зосередилися на тестуванні логічних шляхів виконання у контексті системи;

Поради:

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

Джерела:

Дод. матеріал:

PreviousМодульне/юніт/компонентне тестування (Module/Unit/Component testing)NextСистемне тестування (System Testing)

Last updated 2 years ago