Що таке тест на інтеграцію?

Ми з друзями намагалися класифікувати, що саме є інтеграційним тестом.

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

Я перевірив документацію Ruby on Rails на предмет їх класифікації цих типів тестування, і тепер мене це повністю кинуло.

Чи можете ви дати мені короткий академічний опис тесту на інтеграцію з прикладом реального світу?

На даний момент мені подобається це твердження: "Важливо не те, як ви його називаєте, а що це робить", зроблене Гойко Аджичем у цій статті .

Вам дійсно потрібно вказати разом з людьми, які говорять про тести, що ви маєте намір протестувати.

Дуже багато людей мають різні погляди, залежно від того, яка їх роль.

Для тестувальників загальноприйнята методика тестування в Нідерландах - TMap . TMap робить наступне розрізнення.

• одиничне випробування
• тест інтеграції блоку
• тест на систему
• тест на інтеграцію системи
• тест на прийняття (всі види / рівні)
• функціональний тест на прийняття
• тест на прийняття користувача
• випробування на прийняття виробництва

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

У Вікіпедії також є хороший огляд .

У книзі прагматичний програміст говорить:

• одиничний тест - це тест, який здійснює модуль
• Інтеграційні тести показують, що основні частини системи добре працюють разом

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

• хто взагалі робить тестування
• що тестується

• яка мета тесту

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

Мій список вище - це лише початок і пропозиція, але я дійсно думаю: "Важливо не те, як ви його називаєте, а що це робить"

Сподіваюся, це допомагає.

26-10-2016 Редагувати: Нещодавно дуже приємне вступ було розміщено на тестах YouTube Unit порівняно з інтеграційними тестами - MPJ's Musings - FunFunFunction # 55

інтеграційний тест, виявляється, це тест на прийняття

Очевидно.

Ці двоє - це майже одне й те саме. Але в тестовому визначенні є дещо інші розміри.

Інтеграція == система в цілому.

Прийняття == система в цілому.

Єдина відмінність - і це тонко - це визначення тестових випадків.

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

Прийняття == тестові випадки для 80% набору функцій, орієнтованих на кінцевого користувача. Не всі крайові та кутові корпуси. Тестові справи, як правило, нетехнічні, написані кінцевими користувачами.

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

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

У своєму (я визнаю) невеликому досвіді я зрозумів, що інтеграція слів справді може створити непорозуміння: дійсно, важко знайти щось цілком ізольоване в системі, деяким елементам напевно потрібна певна інтеграція.

Таким чином, я звик робити такі розрізнення:

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

Під визначенням тесту на інтеграцію під зовнішнім розумінням я мав на увазі систему, яка вийшла за рамки мого розвитку : з будь-якої причини я не можу негайно змінити спосіб їх поведінки. Це може бути бібліотека, складова системи, яку неможливо змінити (тобто її поділяють з іншими проектами в компанії), dbms тощо. Для цих тестів мені потрібно створити щось дуже схоже на реальне середовище системи працюватиме в: зовнішня система повинна бути ініціалізована і встановлена ​​в певний стан; реалістичні дані повинні бути зареєстровані у db; тощо.

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

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

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

Давайте уявимо, що ми говоримо про літальний апарат (з програмним забезпеченням це більш абстрактно і важко змінити значення). Інтеграційні тести включають:

• правильна взаємодія між деякими компонентами. Приклад: при натисканні на кнопку пуску двигун запускається, а гвинт досягає очікуваної швидкості обертання (літальний апарат все ще залишається на землі)
• правильна взаємодія із зовнішніми компонентами. Приклад: перевірте, чи може вбудована радіозв'язок зв’язуватися зі стаціонарною радіостанцією (літальний апарат все ще на землі)
• правильну взаємодію між усіма залученими компонентами, щоб ця система в цілому працювала так, як очікувалося. Приклад: екіпаж пілотів-випробувачів та інженерів запускає літак і летить з ним (всі вони носять парашути ...).

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

Тест на прийняття перевіряє, чи виріб відповідає призначенню. Вони в принципі виконуються замовником. Беручи аналогію літака, вони включають перевірку того, що:

• передбачені бізнес-сценарії призводять до очікуваного результату в майже реальній ситуації. Приклад: репетируйте посадку з пасажирами, які перевіряють, щоб перевірити, чи персонал може стежити за посадкою, як очікується в процесі експлуатації. Деякі сценарії можуть бути настільки простими, що виглядатимуть як тестові установки, але їх виконує користувач (наприклад, спробуйте електричні вилки з обладнанням компаній).
• система працює в майже реальній бізнес-ситуації. Приклад: здійснити порожній тестовий політ між двома реальними напрямками, з нещодавно підготовленими пілотами авіакомпанії, щоб перевірити, чи споживається паливо, як було обіцяно.

Тест прийняття вирішує більше питання відповідальності . У відносинах клієнт / постачальник може бути відповідальною за договір (відповідність усім вимогам). Але в будь-якому випадку відповідальність організації, що використовує, є також забезпечити виконання ними своїх обов'язків у системі та обережно запобігати будь-якому непередбаченому питанню (наприклад, наприклад, ця корпорація залізниць, яка виявила під час приймальних випробувань, що їм доведеться скоротити якісь перерви, оскільки нові вагони були на 5 см занадто великі - не жарт!).

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

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

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

Одне практичне визначення інтеграційного тесту: Будь-який тест, який вимагає взаємодії з чимось поза процесом.

Наприклад:

• Файлова система
• Мережа
• База даних
• Зовнішній API

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

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

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

NB Власне кажучи, так, це визначення також охоплювало б тести системи / кінцевих. У моїй філософії вони є формою "екстремальної" інтеграційної перевірки, тому їхні назви підкреслюють інший аспект. В іншому напрямку одиничним тестом можна вважати тест інтеграції нульових компонентів, тобто всі тести можна вважати лежачи десь на спектрі інтеграції, інтегруючи між 0-n компонентами :-)