Що таке інтеграційне тестування? (Приклад)

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

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

Інтеграційне тестування зосереджується на перевірці передачі даних між цими модулями. Тому його також називають як "Я і Т" (Інтеграція та тестування), «Тестування рядків» а іноді «Тестування потоку».

Коли і навіщо проводити інтеграційне тестування?

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

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

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

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

Натисніть тут якщо відео недоступне

Приклад інтеграційного тесту

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

Приклади тестових випадків інтеграції для наступного сценарію: Застосунок має 3 модулі, скажімо, «Сторінка входу», «Mail«поле» та «Видалити електронні листи», і кожен з них логічно інтегрований.

Тут не варто зосереджуватися на тестуванні сторінки входу, оскільки це вже було зроблено в Unit Testing. Але перевірте, як це пов’язано з Mail Box Сторінка.

Крім того, Mail BoxПеревірте його інтеграцію з функцією видалення Mails Модуль.

Ідентифікатор тестового випадку	Мета тестового випадку	Тестовий випадок Descriptіон	Очікуваний результат
1	Перевірте зв’язок інтерфейсу між входом і Mailкоробковий модуль	Введіть облікові дані для входу та натисніть кнопку «Вхід».	Для направлення до Mail Box
2	Перевірте зв'язок інтерфейсу між Mailполе та кнопку «Видалити» Mails Модуль	From Mailвиберіть електронний лист і натисніть кнопку видалення	Вибраний електронний лист має з’явитися в папці «Видалені/Кошик».

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

Програмна інженерія визначає різноманітні стратегії для виконання інтеграційного тестування, а саме.

• Підхід Великого Вибуху:
• Поступовий підхід: який далі поділяється на наступні
  • Підхід «знизу вгору».
  • Підхід зверху вниз
  • Сендвічовий підхід – поєднання «згори вниз» і «знизу вгору».

Нижче наведено різні стратегії, спосіб їх виконання та їхні обмеження, а також переваги.

Випробування великого вибуху

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

переваги:

• Швидше налаштування – Усі модулі інтегровані одночасно.
• Повний огляд системи – Негайно спостерігайте за загальною поведінкою.
• Без заглушок/драйверів – Зменшує додаткові зусилля на розробку.
• Добре підходить для невеликих проектів – Простіші системи добре підходять.
• Орієнтований на користувача – Тісно відповідає досвіду кінцевого користувача.

Недоліки:

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

Поступове тестування

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

Поступовий підхід, у свою чергу, здійснюється двома різними методами:

• Знизу вгору
• З верху до низу
• Сендвіч-підхід

Інтеграційне тестування знизу вгору

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

Схематичне зображення:

переваги:

• Раннє тестування модулів – Спочатку тестуються модулі нижчого рівня.
• Легше налагодження – Дефекти, ізольовані на рівні модуля.
• Не потрібні заглушки – Драйвери простіше створювати.
• Надійний фундамент – Основні модулі протестовані перед вищими рівнями.
• Прогресивна інтеграція – Система стабільно та впевнено зростає.

Недоліки:

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

Інтеграційне тестування зверху вниз

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

переваги:

• Думка раннього користувача – Інтерфейси протестовані з самого початку.
• Спочатку критичні модулі – Логіка високого рівня перевірена на ранній стадії.
• Прогресивна інтеграція – Проблеми вирішуються крок за кроком.
• Не потрібні драйвери – Потрібні лише заглушки.
• Рання перевірка дизайну – Швидко підтверджує архітектуру системи.

Недоліки:

• Потрібні заглушки – Написання великої кількості заглушок додає зусиль.
• Нижні модулі затримуються – Основні модулі протестовано пізніше.
• Незавершені ранні тести – Відсутні деталі з неінтегрованих модулів.
• Складніше налагодження – Помилки можуть поширюватися від заглушок.
• Витрата часу – Створення заглушок уповільнює процес.

переваги:

• Збалансований підхід – Поєднує сильні сторони як «зверху вниз», так і «знизу вгору».
• Паралельне тестування – Верхній та нижній модулі тестувалися одночасно.
• Швидше покриття – Більше модулів було протестовано раніше.
• Критичні модулі мають пріоритет – Підтверджено як високий, так і низький рівні.
• Знижений ризик – Проблеми виявлено з обох сторін.

Недоліки:

• Висока складність – Складніше планувати та керувати.
• Потрібні заглушки/драйвери – Додаткові зусилля для випробувальних риштувань.
• Дорого – Потрібно більше ресурсів і часу.
• Середні модулі затримуються – Перевірено лише після верхнього та нижнього шарів.
• Не ідеально підходить для невеликих систем – Накладні витрати переважають вигоди.

Що таке заглушки та драйвери в інтеграційному тестуванні?

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

Що таке заглушки?

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

Характеристики заглушок:

• Моделювання поведінки модулів нижчого рівня
• Повертати жорстко закодовані або прості обчислені значення
• Використовується в тестуванні інтеграції "зверху вниз"
• Мінімальна реалізація функціональності

Що таке драйвери?

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

Характеристики водіїв:

• Викликати тестовані модулі з тестовими даними
• Запис та перевірка відповідей
• Використовується у висхідному інтеграційному тестуванні
• Потік виконання контрольного тесту

Приклад практичної реалізації

Payment Module Testing:
- Stub: Simulates tax calculation service returning 10% tax
- Driver: Simulates checkout process calling payment module
- Result: Payment module tested independently of unavailable components

Коли використовувати кожен?

Компонент	Використати заглушку	Використати драйвер
Підхід до тестування	Тестування зверху вниз	Тестування знизу вгору
Замінює	Модулі нижчого рівня	Модулі вищого рівня
функція	Повертає фіктивні дані	Надсилає тестові дані
складність	Прості відповіді	Оркестрація тестів

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

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

Процедура інтеграційного тестування, незалежно від стратегій тестування програмного забезпечення (обговорюваних вище):

1. Підготуйте інтеграцію План тестів
2. Розробіть тестові сценарії, кейси та сценарії.
3. Виконання тестових випадків із подальшим звітуванням про дефекти.
4. Відстеження та повторне тестування дефектів.
5. Кроки 3 і 4 повторюються, доки інтеграція не завершиться успішно.

Brief Descriptпланів тестування інтеграції

Він включає такі атрибути:

• Методи/підходи до тестування (як обговорювалося вище).
• Області застосування та елементи поза областю застосування інтеграційного тестування.
• Ролі та обов'язки.
• Передумови для інтеграційного тестування.
• Тестове середовище.
• Плани ризиків і пом'якшення.

Які критерії входу та виходу з інтеграційного тестування?

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

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

• Компоненти/модулі, які пройшли модульне тестування
• Усі помилки з високим пріоритетом виправлено та закрито
• Усі модулі мають бути успішно написані та інтегровані.
• План інтеграційних тестів, тестовий приклад, сценарії, які необхідно підписати та задокументувати.
• Вимагається Тестове середовище налаштувати для інтеграційного тестування

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

• Успішне тестування інтегрованої програми.
• Виконані тестові випадки задокументовані
• Усі помилки з високим пріоритетом виправлено та закрито
• Технічні документи мають бути подані, а потім нотатки до випуску.

Як би ви розробили тестові випадки інтеграції?

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

Крок	вхід	Очікуваний результат
1	Користувач вводить дійсні облікові дані на екрані входу	Облікові дані безпечно надіслано до API автентифікації
2	API перевіряє облікові дані в базі даних	База даних підтверджує збіг імені користувача/пароля
3	API повертає токен автентифікації	Токен згенеровано та надіслано назад до програми
4	Інтерфейс користувача перенаправляє користувача на панель інструментів	Сеанс користувача успішно встановлено

Цей простий процес підтверджує зв'язок між трьома критично важливими модулями: Інтерфейс користувача → API → База данихНевдалий крок точно вказує на те, де інтеграція порушується, допомагаючи командам швидше ізолювати дефекти, ніж лише за допомогою тестування на системному рівні.

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

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

Загальні виклики та рішення

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

1. Управління складними залежностями

Задача: Кілька залежностей модулів створюють складні сценарії тестування з каскадними збоями.

Рішення: Використовуйте впровадження залежностей, контейнеризацію (Docker) та тестування на інкрементальних рівнях. Документуйте всі взаємозв'язки в матрицях залежностей.

2. Неповні модулі

Задача: Тестування блокується, коли залежні модулі не готові.

Рішення: Розробляйте комплексні заглушки/драйвери на ранній стадії, використовуйте віртуалізацію сервісів (WireMock), та впроваджувати контрактне тестування з чітко визначеними інтерфейсами.

3. Управління тестовими даними

Задача: Підтримка узгоджених, реалістичних тестових даних у всіх системах.

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

4. Конфігурація середовища

Задача: Неузгоджені середовища призводять до збоїв інтеграції.

Рішення: Використовуйте інфраструктуру як код (IaC), контейнеризацію для забезпечення паритету середовища та інструменти керування конфігурацією, такі як Ansible.

5. Налагодження збоїв інтеграції

Задача: Виявлення першопричин за кількома компонентами є складним завданням.

Рішення: Впроваджуйте комплексне ведення журналу, використовуйте розподілене трасування (Jaeger/Zipkin) та додавайте ідентифікатори кореляції для відстеження запитів у різних сервісах.

6. Інтеграція сторонніх сервісів

Задача: Недоступність зовнішніх сервісів або зміни API переривають тестування.

Рішення: Фіктивні зовнішні сервіси (Postman Імітація сервера), реалізуйте механізми повторних спроб та підтримуйте тестування сумісності версій API.

7. Вузькі місця продуктивності

Задача: Точки інтеграції стають вузькими місцями під навантаженням.

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

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

Підсумки