Меню

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

what is integration testing

Спробуйте Наш Інструмент Для Усунення Проблем

Що таке інтеграційне тестування: дізнайтеся на прикладах інтеграційного тестування

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

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

Список підручників, висвітлених у цій серії:

Підручник No1: Що таке інтеграційне тестування? (Цей підручник)
Підручник No2: Що таке додаткове тестування
Підручник No3: Що таке тестування компонентів
Підручник No4: Постійна інтеграція
Підручник No5 Різниця між модульним тестуванням та інтеграцією
Підручник No6: 10 найкращих інструментів тестування інтеграції

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

Що ви дізнаєтесь:

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

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

Основною функцією або метою цього тестування є перевірка інтерфейсів між блоками / модулями.

Зазвичай ми проводимо інтеграційне тестування після “модульного тестування”. Після того, як всі окремі блоки створені та протестовані, ми починаємо комбінувати ці модулі «Тестові модулі» і починаємо проводити інтегровані тестування.

Основною функцією або метою цього тестування є перевірка інтерфейсів між блоками / модулями.

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

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

Чому інтеграційний тест?

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

Ось кілька причин:

  1. У реальному світі, коли програми розробляються, вони розбиваються на менші модулі, а окремим розробникам призначається 1 модуль. Логіка, впроваджена одним розробником, суттєво відрізняється від іншої, тому стає важливим перевірити, чи відповідає логіка, реалізована розробником, очікуванням, і надає правильне значення відповідно до встановлених стандартів.
  2. Багато разів обличчя або структура даних змінюється, коли вони переходять від одного модуля до іншого. Деякі значення додаються або видаляються, що спричиняє проблеми в наступних модулях.
  3. Модулі також взаємодіють з деякими сторонніми інструментами або API, які також повинні бути перевірені на те, що дані, прийняті цим API / інструментом, є вірними та що відповідь також відповідає очікуваним.
  4. Дуже поширена проблема при тестуванні - часта зміна вимог! :) Багато разів розробник застосовує зміни, не перевіряючи їх. Тоді інтеграційне тестування стає важливим.

Переваги

Існує кілька переваг цього тестування, і декілька з них перераховані нижче.

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

Виклики

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

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

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

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

# 3) Інтегруючи будь-яку нову систему із застарілою системою, вона вимагає великих змін та зусиль для тестування. Те саме стосується інтеграції будь-яких двох застарілих систем.

# 4) Інтеграція двох різних систем, розроблених двома різними компаніями, є великим викликом, оскільки невідомо, як одна із систем впливатиме на іншу, якщо в будь-якій із систем будуть внесені будь-які зміни.

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

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

Нижче наведено тип інтеграції тестів разом із його перевагами та недоліками.

Підхід до Великого вибуху:

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

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

Великий вибух

Переваги підходу Big Bang:

  • Це хороший підхід для невеликих систем.

Недоліки підходу Великого вибуху:

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

Етапи тестування інтеграції:

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

Тестові підходи до інтеграції

Існує принципово 2 підходи до проведення тестової інтеграції:

  1. Підхід знизу вгору
  2. Підхід зверху вниз.

Давайте розглянемо наведену нижче фігуру, щоб перевірити підходи:

Інтеграція 1

Підхід знизу вгору:

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

У цьому випадку модулі B1C1, B1C2 & B2C1, B2C2 є найнижчим модулем, який перевіряється модулем. Модулі B1 і B2 ще не розроблені. Функціональність модулів B1 і B2 полягає в тому, що він викликає модулі B1C1, B1C2 & B2C1, B2C2. Оскільки B1 і B2 ще не розроблені, нам знадобиться якась програма або 'стимулятор', який буде викликати модулі B1C1, B1C2 & B2C1, B2C2. Ці програми стимуляторів називаються ВОДІЇ .

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

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

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

Підхід зверху вниз

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

злиття сортувати c ++ рекурсивно

У контексті нашої фігури тестування починається з модуля A, а нижчі модулі B1 та B2 інтегруються один за одним. Зараз тут нижні модулі B1 та B2 фактично не доступні для інтеграції. Тому для тестування найвищих модулів А ми розробляємо “ ШТУКИ '.

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

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

І Stubs, і драйвери є фіктивним фрагментом коду, який використовується для тестування “неіснуючих” модулів. Вони запускають функції / метод і повертають відповідь, яка порівнюється з очікуваною поведінкою

Зробимо висновок про різницю між Заглушки та драйвер :

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

Єдина зміна - це Постійна у цьому світі, тому ми маємо інший підхід, який називається “ Сендвіч-тестування ”, Який поєднує в собі особливості підходу зверху вниз і знизу вгору. Коли ми тестуємо величезні програми, такі як операційні системи, ми маємо мати ще кілька методів, які є ефективними та підвищують впевненість. Тут дуже важливу роль відіграє сендвіч-тестування, де і тестування зверху вниз, і знизу вгору починаються одночасно.

Інтеграція починається з середнього шару і рухається одночасно вгору та вниз. У випадку нашої фігури, наше тестування розпочнеться з B1 і B2, де одна рука перевірить верхній модуль A, а інша рука перевірить нижні модулі B1C1, B1C2 & B2C1, B2C2.

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

Тест інтеграції програми GUI

Тепер поговоримо про те, як ми можемо передбачити інтеграційне тестування в техніці Чорної скриньки.

Ми всі розуміємо, що веб-програма - це багаторівнева програма. У нас є передній кінець, який бачить користувач, у нас є середній рівень, який має бізнес-логіку, у нас є ще середній рівень, який виконує деякі перевірки, інтегрує деякі сторонні API і т.д., тоді у нас є задній шар, який є база даних.

Приклад тестування інтеграції:

Давайте перевіримо наведений нижче приклад:

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

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

Інтеграція 2

ЦИБУЛЯ - Модуль інтерфейсу користувача, який видно кінцевому користувачеві, де дані всі входи.
BL - Це модуль Business Logic, який містить усі розрахунки та конкретні бізнес-методи.
VAL - Це модуль перевірки, який має всі перевірки правильності вводу.
CNT - Це модуль вмісту, який має весь статичний вміст, характерний для входів, введених користувачем. Цей вміст відображається у звітах.
В - Це модуль Engine, цей модуль зчитує всі дані, що надходять з модулів BL, VAL і CNT, витягує запит SQL і запускає його до бази даних.
Планувальник - Це модуль, який планує всі звіти на основі вибору користувача (щомісяця, щокварталу, півроку та щороку)
БД - Є база даних.

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

Тут є такі запитання:

  1. Як BL, VAL і модуль CNT будуть зчитувати та інтерпретувати дані, введені в модулі UI?
  2. Чи отримує BL, VAL і CNT модуль правильні дані від інтерфейсу користувача?
  3. В якому форматі дані з BL, VAL і CNT передаються в модуль EQ?
  4. Як EQ зчитує дані та витягує запит?
  5. Чи правильно вилучено запит?
  6. Чи отримує Планувальник правильні дані для звітів?
  7. Чи є набір результатів, отриманий EN, з бази даних правильним і як очікується?
  8. Чи EN може надіслати відповідь назад до модулів BL, VAL та CNT?
  9. Чи може модуль інтерфейсу читати дані та відображати їх належним чином на інтерфейсі?

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

У нашому сценарії дані, введені в модуль інтерфейсу користувача, перетворюються у XML-файл, який інтерпретується 3 модулями BL, VAL і CNT. Модуль EN зчитує отриманий XML-файл, сформований 3-ма модулями, і витягує з нього SQL та запити до бази даних. Модуль EN також отримує набір результатів і перетворює його у XML-файл і повертає назад до модуля інтерфейсу, який перетворює результати в зручну для читання форму та відображає їх.

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

Тож де саме з’являється інтеграційне тестування?

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

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

Кілька інших умов тестування зразків можуть бути такими:

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

Кроки для початку інтеграційних тестів

  1. Зрозумійте архітектуру вашого додатка.
  2. Визначте модулі
  3. Зрозумійте, що робить кожен модуль
  4. Зрозумійте, як дані передаються від одного модуля до іншого.
  5. Зрозумійте, як дані вводяться та надходять у систему (точка входу та точка виходу програми)
  6. Розділіть програму відповідно до ваших потреб тестування.
  7. Визначте та створіть умови тестування
  8. Візьміть по одній умові і запишіть тестові кейси.

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

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

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

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

  • Усі випадки тестування на інтеграцію виконані.
  • Жодних критичних та пріоритетних дефектів P1 та P2 не відкрито.
  • Підготовлено звіт про випробування.

Випробувальні випадки інтеграції

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

Отже, головна ідея - перевірити, чи інтегрування двох робочих модулів працює належним чином при інтеграції.

Наприклад, приклади інтеграційних тестів для програми Linkedin включатимуть:

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

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

Інтеграція - це біла скринька чи техніка чорної скриньки?

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

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

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

Інструменти тестування інтеграції

Для цього тестування доступно кілька інструментів.

Нижче наведено перелік інструментів:

  • Тестер раціональної інтеграції
  • Транспортир
  • Пар
  • ТЕСНИЙ

Щоб отримати докладнішу інформацію про наведені вище інструменти, перегляньте цей посібник:

10 найкращих інструментів тестування інтеграції для написання тестів інтеграції

Тестування системної інтеграції

Тест системної інтеграції проводиться для перевірки повна інтегрована система .

Модулі або компоненти тестуються індивідуально під час модульного тестування перед інтеграцією компонентів.

Як тільки всі модулі перевіряються, тестування системної інтеграції проводиться шляхом інтеграції всіх модулів і тестується система в цілому.

Різниця між інтеграційним тестуванням та системним тестуванням

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

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

Висновок

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

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

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

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

Рекомендована література

^