Що таке інтеграційне тестування?
ТЕСТУВАННЯ ІНТЕГРАЦІЇ визначається як тип тестування, де програмні модулі інтегровані логічно та перевіряються як група. Типовий програмний проект складається з безлічі програмних модулів, кодованих різними програмістами. Мета цього рівня тестування - виявити дефекти взаємодії між цими програмними модулями, коли вони інтегровані
Тестування інтеграції зосереджується на перевірці передачі даних між цими модулями. Тому його також називають "I & T" (інтеграція та тестування), "тестування рядків", а іноді і "тестування ниток" .
- Що таке інтеграційне тестування?
- Чому інтеграційне тестування?
- Приклад тестування інтеграції
- Підходи, стратегії, методології інтеграційного тестування
- Підхід до Великого вибуху:
- Додатковий підхід
- Що таке заглушка та драйвер?
- Інтеграція знизу вгору
- Інтеграція зверху вниз:
- Гібридна / сендвіч-інтеграція
- Як зробити інтеграційне тестування?
- Короткий опис планів тестування інтеграції:
- Критерії входу та виходу з інтеграційного тестування
- Кращі практики / Настанови щодо інтеграційного тестування
Чому інтеграційне тестування?
Хоча кожен програмний модуль є модульним тестуванням, дефекти все ще існують з різних причин, таких як
- Модуль, загалом, розробляється індивідуальним розробником програмного забезпечення, розуміння якого та логіка програмування можуть відрізнятися від інших програмістів. Тестування інтеграції стає необхідним для перевірки роботи програмних модулів в єдиній цілі
- На момент розробки модуля існує велика ймовірність зміни вимог з боку клієнтів. Ці нові вимоги не можуть бути перевірені модулем, а отже, тестування системної інтеграції стає необхідним.
- Інтерфейси програмних модулів з базою даних можуть бути помилковими
- Зовнішні апаратні інтерфейси, якщо такі є, можуть бути помилковими
- Неадекватна обробка винятків може спричинити проблеми.
Клацніть тут, якщо відео недоступне
Приклад тестування інтеграції
Тестовий приклад інтеграції відрізняється від інших тестових кейсів тим сенсом, що він зосереджений головним чином на інтерфейсах та потоці даних / інформації між модулями . Тут пріоритет повинен надаватися інтегруючим посиланням, а не одиничним функціям, які вже перевірені.
Приклади тестових випадків інтеграції для наступного сценарію: Додаток має 3 модулі, які кажуть «Сторінка входу», «Поштова скринька» та «Видалити електронні листи», і кожен з них інтегрований логічно.
Тут не зосереджуйте багато уваги на тестуванні сторінки входу, як це вже було зроблено в модульному тестуванні. Але перевірте, як воно пов’язане зі Сторінкою поштової скриньки.
Подібним чином поштова скринька: Перевірте її інтеграцію до модуля Видалення пошти.
| Ідентифікатор тестового кейсу | Мета тесту | Опис тестового кейсу | Очікуваний результат |
|---|---|---|---|
| 1 | Перевірте інтерфейсне посилання між модулем Вхід та Поштова скринька | Введіть дані для входу та натисніть кнопку Вхід | Буде спрямовано до поштової скриньки |
| 2 | Перевірте інтерфейсне посилання між поштовою скринькою та модулем видалення пошти | З поштової скриньки виберіть електронний лист і натисніть кнопку видалення | Вибране повідомлення електронної пошти повинно з’явитися в папці Видалено / Кошик |
Підходи, стратегії, методології інтеграційного тестування
Програмна інженерія визначає різноманітні стратегії для проведення інтеграційного тестування, а саме.
- Підхід до Великого вибуху:
- Додатковий підхід: який далі поділяється на наступне
- Підхід зверху вниз
- Підхід знизу вгору
- Сендвіч-підхід - поєднання зверху вниз і знизу вгору
Нижче наведені різні стратегії, спосіб їх виконання та їх обмеження, а також переваги.
Тестування Великого Вибуху
Тестування "Великого вибуху" - це підхід до інтеграційного тестування, при якому всі компоненти або модулі інтегруються одночасно, а потім перевіряються як цілісність. Цей комбінований набір компонентів розглядається як сутність під час тестування. Якщо всі компоненти блоку не завершені, процес інтеграції не виконується.
Переваги:
- Зручний для невеликих систем.
Недоліки:
- Локалізація несправностей складна.
- Враховуючи величезну кількість інтерфейсів, які потрібно перевірити за цим підходом, деякі інтерфейси, що перевіряються, можуть бути легко пропущені.
- Оскільки тестування інтеграції може розпочатися лише після того, як розроблені "всі" модулі, команда тестування матиме менше часу для виконання на етапі тестування.
- Оскільки всі модулі тестуються одночасно, критично важливі модулі з високим ризиком не ізолюються та перевіряються за пріоритетом. Периферійні модулі, які мають справу з користувальницькими інтерфейсами, також не є ізольованими та перевірені на пріоритет.
Додаткове тестування
У підході до додаткового тестування тестування проводиться шляхом інтеграції двох або більше модулів, які логічно пов’язані між собою, а потім перевіряються на належне функціонування програми. Потім інші пов'язані модулі інтегруються поступово, і процес триває, поки всі логічно пов'язані модулі не будуть інтегровані та успішно перевірені.
Інкрементальний підхід, у свою чергу, здійснюється двома різними методами:
- Знизу вгору
- З верху до низу
Заглушки та драйвери
Заглушки та драйвери - це фіктивні програми в рамках інтеграційного тестування, що використовуються для полегшення діяльності з тестування програмного забезпечення. Ці програми виступають як замінники відсутніх моделей у тестуванні. Вони не реалізують всю логіку програмування програмного модуля, але вони імітують передачу даних із викличним модулем під час тестування.
Заглушка : викликається модулем під тестом.
Драйвер : викликає модуль для тестування.
Тестування інтеграції знизу вгору
Тестування інтеграції знизу вгору - це стратегія, при якій спочатку тестуються модулі нижчого рівня. Потім ці перевірені модулі надалі використовуються для полегшення тестування модулів вищого рівня. Процес триває до тих пір, поки не будуть перевірені всі модулі верхнього рівня. Після тестування та інтеграції модулів нижчого рівня формується модуль наступного рівня.
Схематичне зображення :
Переваги:
- Локалізація несправностей простіша.
- На час, коли всі модулі розроблятимуться на відміну від підходу Великого вибуху, не витрачається часу
Недоліки:
- Критичні модулі (на верхньому рівні архітектури програмного забезпечення), які контролюють потік програми, перевіряються останніми і можуть схильні до дефектів.
- Ранній прототип неможливий
Тестування інтеграції зверху вниз
Інтеграційне тестування зверху вниз - це метод, при якому інтеграційне тестування відбувається зверху вниз, слідуючи потоку управління програмною системою. Спочатку тестуються модулі вищого рівня, а потім тестуються та інтегруються модулі нижчого рівня для перевірки функціональності програмного забезпечення. Заглушки використовуються для тестування, якщо деякі модулі не готові.
Схематичне зображення:
Переваги:
- Локалізація несправностей простіша.
- Можливість отримати ранній прототип.
- Критичні модулі перевіряються на пріоритет; основні недоліки конструкції можна було знайти та виправити спочатку.
Недоліки:
- Потребує багато заглушок.
- Модулі нижчого рівня перевірені неадекватно.
Тестування бутербродів
Сендвіч-тестування - це стратегія, при якій модулі верхнього рівня тестуються з модулями нижчого рівня, в той же час нижчі модулі інтегруються з верхніми модулями та перевіряються як система. Це поєднання підходів зверху вниз і знизу вгору, тому воно називається тестуванням гібридної інтеграції . Він використовує як заглушки, так і драйвери.
Як зробити інтеграційне тестування?
Процедура тестування інтеграції незалежно від стратегій тестування програмного забезпечення (обговорена вище):
- Підготуйте План інтеграційних випробувань
- Створіть тестові сценарії, справи та сценарії.
- Виконання тестових випадків з подальшим повідомленням про дефекти.
- Відстеження та повторне тестування дефектів.
- Етапи 3 і 4 повторюються до завершення інтеграції.
Короткий опис планів тестування інтеграції:
Він включає такі атрибути:
- Методи / Підходи до тестування (як обговорювалося вище).
- Обсяги та поза сфери застосування Предмети інтеграційного тестування.
- Ролі та обов'язки.
- Передумови для інтеграційного тестування.
- Середовище тестування.
- Плани ризиків та зменшення наслідків.
Критерії входу та виходу з інтеграційного тестування
Критерії входу та виходу на фазу тестування інтеграції в будь-якій моделі розробки програмного забезпечення
Критерії вступу:
- Блокові протестовані компоненти / модулі
- Усі помилки з високим пріоритетом виправлені та закриті
- Всі модулі, які потрібно кодувати, успішно завершені та інтегровані.
- Інтеграційні тести План, тестовий випадок, сценарії, що підписуються та документуються.
- Необхідне тестове середовище, яке слід створити для інтеграційного тестування
Критерії виходу:
- Успішне тестування інтегрованого додатка.
- Виконані тестові випадки задокументовані
- Усі помилки з високим пріоритетом виправлені та закриті
- Технічна документація, яку слід подати, а також примітки до випуску.
Кращі практики / Настанови щодо інтеграційного тестування
- Спочатку визначте стратегію інтеграційного тестування, яку можна було б прийняти, а згодом підготуйте тестові кейси та дані тестів відповідно.
- Вивчіть архітектурний дизайн програми та визначте критичні модулі. Їх потрібно перевірити на пріоритет.
- Отримати дизайни інтерфейсів у архітектурної команди та створити тестові кейси для детальної перевірки всіх інтерфейсів. Потрібно детально перевірити інтерфейс до бази даних / зовнішнього апаратного / програмного забезпечення.
- Після тестових випадків вирішальну роль відіграють дані тестів.
- Завжди готуйте фальшиві дані перед виконанням. Не вибирайте дані тесту під час виконання тестів.
