Інтеграційне тестування
| Цикл розробки програмного забезпечення |
|---|
 Програміст за роботою |
| Діяльність і кроки |
| Допоміжні дисципліни |
| Практики |
| Інструменти |
| Стандарти та галузі знань |
Інтеграційне тестування (англ. integration testing) — це фаза тестування програмного забезпечення, під час якої окремі модулі програми комбінуються та тестуються разом, у взаємодії. Інтеграційне тестування виконується після модульного тестування та перед верифікацією та валідацією ПЗ. Якщо розглядати цей процес як систему, то на вхід їй подаються модулі, які вже пройшли модульне тестування; потім модулі групуються в більші частини, виконуються тести передбачені планом, а на виході системи — інтегрована система, що готова до системного тестування.
Метою інтеграційного тестування є верифікувати вимоги з функціональності, продуктивності, надійності до основних компонентів програми. Ці компоненти, тобто групи модулів, тестуються методом чорної скриньки (англ. «black-box testing»), успішні та неуспішні тест-кейси симулюються відповідними вхідними параметрами.
В процесі інтеграційного тестування тестуються симульоване використання спільних (англ. «shared») даних та комунікація між процесами. Тест-кейси перевіряють чи коректно взаємодіють всі компоненти, наприклад: через виклик процедури або активізацію процесу.
Дуже важливо те, що до інтеграційного тестування приступають тільки після модульного. Це дозволяє реалізувати стратегію «будівельних блоків», коли до верифікованої системи інтегруються верифіковані модулі.
Серед різновидів інтеграційного тестування є: «big bang» тестування, тестування зверху-донизу та знизу-вгору.
В цьому підході всі або більша частина розроблених модулів збираються разом, формуючи завершену програмну систему або її значну частину та використовуються для інтеграційного тестування. Цей метод дуже ефективний для збереження часу тестування програмної системи. Тим не менше, якщо тест-кейси та їх результати не занотовані належним чином, весь процес стане дуже складним та втратить сенс.
Тестування знизу-вгору — це такий підхід до тестування, коли першими тестуються компоненти нижнього рівня, щоб полегшити тестування високорівневих компонентів. Після інтеграційного тестування групи компонентів певного рівня з них формується наступний рівень, який теж повинен бути протестований. Цей підхід ефективний тільки коли всі модулі одного рівня вже розроблені. Також цей підхід допомагає визначити які рівні системи вже розроблені та виразити процес тестування в відсотках.
Тестування зверху-донизу — це такий підхід до тестування, коли тестуються компоненти вищого рівня та гілки кожного з модулів тестуються крок за кроком, поки модуль не буде протестований повністю.
Сендвіч-тестування — підхід, комбінований з двох попередніх.
Перший підхід дозволяє легко знаходити програмні дефекти, коли другий знаходить архітектурні.
Для автоматизації інтеграційного тестування використовують системи безперервної інтеграцію (Continuous Integration System, CIS). Принцип дії таких системи складається з наступного:
- CIS виконує моніторинг системи контролю версій.
- У випадку змін кода в репозиторії виконується оновлення локальної версії.
- Виконується модульне тестування.
- Збираються програмні модулі.
- Виконуються інтеграційні тести.
- Генерується звіт.
Таким чином, автоматичні інтеграційні тести виконуються відразу після внесення змін, що дозволяє виявити та усунути помилки за короткий проміжок часу.
Деякі відомі CIS:
- BuildBot
- Hudson або Jenkins
- Teamcity
Рівні інтеграційного тестування:
- компонентний інтеграційний рівень (Component Integration testing). Перевіряється взаємодія між компонентами системи після проведення компонентного тестування;
- системний інтеграційний рівень (System Integration Testing). Перевіряється взаємодія між різними системами після проведення системного тестування.
Інтеграційне тестування: Перевіряє інтерфейси між компонентами, взаємодію з різними частинами системи, такими як операційна система, файлова система та апаратне забезпечення, інтерфейси між системами. Інтеграційне тестування може складатися з одного чи більше рівнів та може виконуватися на тестових об'єктах різного розміру таким чином:
- Компонентне інтеграційне тестування перевіряє взаємодію між компонентами системи. Виконується після компонентного тестування.
- Системне інтеграційне тестування перевіряє взаємодію між різними системами або між апаратним та програмним забезпеченням. Може виконуватися після системного тестування. В цьому випадку організація, яка розробляє продукт, може контролювати тільки одну сторону інтерфейсу. Однак це можна розглядати як ризик. Бізнес процеси, зображені як потоки робіт, можуть включати послідовність систем. Кросплатформенні розбіжності можуть бути суттєвими.
- Переконайтеся, що у вас є відповідний документ детального проектування, де взаємодія між кожними модулями чітко визначені. Насправді, ви не зможете виконати інтеграційне тестування без цієї інформації.
- Переконайтеся, що у вас є надійна система управління конфігурацією програмного забезпечення. Або ж, ви будете мати проблеми з відстеженням правильної версії кожного модуля, особливо якщо число модулів, які будуть інтегровані величезне.
- Переконайтеся, що кожен модуль спершу протестований модульним тестуванням, перш ніж почати інтеграційне тестування.
- Наскільки це можливо, автоматизуйте тести, особливо при використанні підходів «зверху вниз» або «знизу вгору», так як регресивне тестування важливе кожен раз, коли ви інтегрували єдине ціле, і ручне регресивне тестування може бути неефективним.
Будь-який метод з тестування чорного ящика, тестування методом білого ящика. Також може бути використаний метод сірого ящика Як правило, метод залежить від вашого визначення «одиниці».
- ↑ Integration Testing – Software Testing Fundamentals. softwaretestingfundamentals.com. Архів оригіналу за 13 липня 2016. Процитовано 15 липня 2016.
 | Ця стаття не містить посилань на джерела. (липень 2013) |
