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

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

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

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

Чому потрібно інтеграційне тестування?

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

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

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

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

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

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

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

Аналогічно Mail Box: Перевірте його інтеграцію до Delete Mails Модуль.

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

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

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

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

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

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

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

переваги:

• Зручно для невеликих систем.

Недоліки:

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

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

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

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

• Знизу вгору
• З верху до низу

Заглушки та драйвери

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

Пень: Викликається тестованим модулем.

Водій: викликає модуль для тестування.

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

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

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

переваги:

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

Недоліки:

• Критичні модулі (на верхньому рівні архітектури програмного забезпечення), які контролюють потік програми, перевіряються в останню чергу та можуть бути схильні до дефектів.
• Ранній прототип неможливий

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

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

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

переваги:

• Локалізація несправності легша.
• Можливість отримати ранній прототип.
• Критичні модулі перевіряються в пріоритеті; основні недоліки дизайну можна знайти та виправити спочатку.

Недоліки:

• Потрібно багато заглушок.
• Модулі нижчого рівня перевірені неадекватно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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