Какво е интеграционно тестване? (Пример)

Какво е интеграционно тестване?

Тестване на интеграцията се определя като вид тестване, при което софтуерните модули се интегрират логически и се тестват като група. Типичният софтуерен проект се състои от множество софтуерни модули, кодирани от различни програмисти. Целта на това ниво на тестване е да разкрие дефекти във взаимодействието между тези софтуерни модули, когато са интегрирани

Интеграционното тестване се фокусира върху проверка на комуникацията на данни между тези модули. Следователно се нарича още като „Аз и Т“ (Интегриране и тестване), „Тестване на низове“ и понякога „Тестване на нишки“.

Кога и защо се прави интеграционно тестване?

Интеграционното тестване се прилага след модулно тестване и преди пълно системно тестване. То е най-полезно при проверка на потока от данни, споделени API и взаимозависими модули в различни среди. Чрез ранно изпълнение на интеграционни тестове, екипите могат да открият несъответствия в интерфейсите, липсващи договори за данни и грешки в зависимостите, които модулните тестове често пропускат.

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

Въпреки че всеки софтуерен модул е ​​тестван като модул, все още съществуват дефекти поради различни причини, като например

• Модулът, като цяло, се проектира от отделен софтуерен разработчик, чието разбиране и програмна логика може да се различават от тези на други програмисти. Интеграционното тестване е необходимо, за да се провери дали софтуерните модули работят в единство.
• По време на разработването на модули има голяма вероятност от промени в изискванията от страна на клиентите. Тези нови изисквания може да не бъдат тествани по модули и следователно тестването за системна интеграция става необходимо.
• Интерфейсите на софтуерните модули с базата данни могат да бъдат грешни
• Външните хардуерни интерфейси, ако има такива, може да са грешни
• Неадекватното обработване на изключения може да причини проблеми.

Кликнете тук ако видеото не е достъпно

Пример за интеграционен тестов случай

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

Примерни тестови случаи за интеграция за следния сценарий: Приложението има 3 модула, да речем „Страница за вход“, „Mailкутия“ и „Изтриване на имейли“, като всяко от тях е логически интегрирано.

Тук не се концентрирайте много върху тестването на страницата за вход, тъй като това вече е направено в Единично тестване. Но проверете как е свързано с Mail Box Page.

По същия начин, Mail BoxПроверете интеграцията му с функцията за изтриване Mails Модул.

ID на тестов случай	Цел на тестовия случай	Тестов случай Descriptйон	очакван резултат
1	Проверете интерфейсната връзка между входа и Mailкутия модул	Въведете идентификационни данни за вход и щракнете върху бутона Вход	Да бъде насочен към Mail Box
2	Проверете интерфейсната връзка между Mailполето и бутона за изтриване Mails Модул	От Mailполето, изберете имейла и щракнете върху бутона за изтриване	Избраният имейл трябва да се появи в папката Изтрити/Кошче

Видове интеграционни тестове

Софтуерното инженерство определя различни стратегии за изпълнение на интеграционно тестване, а именно.

• Подходът на Големия взрив:
• Постепенен подход: който е допълнително разделен на следните
  • Подход отдолу нагоре
  • Подход отгоре надолу
  • Сандвич подход – Комбинация отгоре надолу и отдолу нагоре

По-долу са различните стратегии, начина, по който се изпълняват и техните ограничения, както и предимства.

Тестване на Големия взрив

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

Предимства:

• По-бърза настройка – Всички модули са интегрирани наведнъж.
• Пълен системен изглед – Незабавно наблюдавайте цялостното поведение.
• Без мъничета/драйвери – Намалява допълнителните усилия за разработка.
• Добър за малки проекти – По-простите системи са подходящи.
• Ориентиран към потребителя – Съответства плътно на потребителското изживяване.

Недостатъци:

• Трудно за отстраняване на грешки – По-трудни за изолиране грешки.
• Късно откриване на дефекти – Грешки, открити едва след пълна интеграция.
• Висок риск – Сериозни проблеми могат да блокират цялото тестване.
• Не е мащабируемо – Сложните системи стават неуправляеми.
• Слабо покритие на тестовете – Някои модули не са тествани достатъчно добре.

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

в Постепенно тестване При този подход тестването се извършва чрез интегриране на два или повече модула, които са логически свързани помежду си, и след това тестване за правилното функциониране на приложението. След това останалите свързани модули се интегрират постепенно и процесът продължава, докато всички логически свързани модули бъдат интегрирани и тествани успешно.

Инкременталният подход от своя страна се осъществява чрез два различни метода:

• Отдолу нагоре
• Отгоре надолу
• Сандвич подход

Интеграционно тестване отдолу нагоре

Интеграционно тестване отдолу нагоре е стратегия, при която първо се тестват модулите от по-ниско ниво. Тези тествани модули след това се използват за улесняване на тестването на модули от по-високо ниво. Процесът продължава, докато всички модули от най-високо ниво бъдат тествани. След като модулите от по-ниско ниво бъдат тествани и интегрирани, се формира следващото ниво модули.

Диаграмно представяне:

Предимства:

• Ранно тестване на модули – Първо се тестват модули от по-ниско ниво.
• По-лесно отстраняване на грешки – Дефекти, изолирани на модулно ниво.
• Не са необходими мъничета – Драйверите са по-лесни за създаване.
• Надеждна основа – Основните модули са тествани преди по-високите нива.
• Прогресивна интеграция – Системата расте стабилно и уверено.

Недостатъци:

• Преглед от късен потребител – Цялата система се вижда само в края.
• Търси шофьори – Допълнителни усилия за изграждане на драйвери.
• Забавен потребителски интерфейс – Интерфейсите от най-високо ниво са тествани много късно.
• Времеемко – Прогресивната интеграция отнема повече време.
• Пропуски в теста – Взаимодействията на високо ниво може да пропуснат проблеми.

Интеграционно тестване отгоре надолу

Тестване на интеграция отгоре надолу е метод, при който интеграционното тестване се извършва отгоре надолу, следвайки контролния поток на софтуерната система. Първо се тестват модулите от по-високо ниво, а след това се тестват и интегрират модулите от по-ниско ниво, за да се провери функционалността на софтуера. Stub-овете се използват за тестване, ако някои модули не са готови.

Предимства:

• Преглед на ранните потребители – Интерфейсите са тествани от самото начало.
• Първо критични модули – Логика на високо ниво, валидирана рано.
• Прогресивна интеграция – Проблеми, уловени стъпка по стъпка.
• Не са необходими драйвери – Необходими са само мъничета.
• Ранно валидиране на дизайна – Бързо потвърждава системната архитектура.

Недостатъци:

• Необходими са мъничета – Писането на много мънички добавя усилия.
• Долните модули се забавят – Основните модули са тествани по-късно.
• Непълни ранни тестове – Липсващи детайли от неинтегрирани модули.
• По-трудно отстраняване на грешки – Грешките могат да се разпространяват от заключващи се елементи.
• Времеемко – Създаването на заключителни блокове забавя процеса.

Предимства:

• Балансиран подход – Съчетава силните страни „отгоре надолу“ и „отдолу нагоре“.
• Паралелно тестване – Горните и долните модули са тествани едновременно.
• По-бързо покритие – Повече модули са тествани по-рано.
• Приоритизирани критични модули – Валидирани са както високи, така и ниски нива.
• Намален риск – Проблеми, открити и от двете страни.

Недостатъци:

• Висока сложност – По-трудно е да се планира и управлява.
• Необходими са драйвери/мънички – Допълнителни усилия за тестово скеле.
• скъп – Необходими са повече ресурси и време.
• Средните модули са закъснели – Тествано само след горната и долната част.
• Не е идеален за малки системи – Режийните разходи надвишават ползите.

Какво представляват Stub-овете и Драйверите в интеграционното тестване?

Заготовките и драйверите са основни фиктивни програми, които позволяват интеграционно тестване, когато не всички модули са налични едновременно. Тези тестови дубли симулират липсващи компоненти, което позволява тестването да продължи, без да се чака пълното разработване на системата.

Какво представляват мъничетата (Stub-овете)?

Заготовките (stub) са фиктивни модули, които заместват компоненти от по-ниско ниво, които все още не са разработени или интегрирани. Те се извикват от тествания модул и връщат предварително дефинирани отговори. Например, когато се тества модул за обработка на плащания, който се нуждае от изчисляване на данък, заготовката може да връща фиксирани данъчни стойности, докато действителният данъчен модул не е готов.

Характеристики на мъничетата:

• Симулирайте поведението на модули от по-ниско ниво
• Връщане на твърдо кодирани или просто изчислени стойности
• Използва се в тестване на интеграция отгоре надолу
• Минимална функционалност на внедряване

Какво представляват драйверите?

Драйверите са фиктивни програми, които извикват тествания модул, симулирайки компоненти от по-високо ниво. Те предават тестови данни на модули от по-ниско ниво и събират резултати. Например, при тестване на модул на база данни, драйверът симулира слоя на бизнес логиката, изпращайки заявки.

Характеристики на драйверите:

• Извикване на тествани модули с тестови данни
• Заснемане и валидиране на отговорите
• Използва се при интеграционно тестване „отдолу нагоре“
• Потокът на изпълнение на контролния тест

Пример за практическо изпълнение

Payment Module Testing:
- Stub: Simulates tax calculation service returning 10% tax
- Driver: Simulates checkout process calling payment module
- Result: Payment module tested independently of unavailable components

Кога да използваме всеки от тях?

Компонент	Използвайте Stub	Използвайте драйвера
Подход за тестване	Тестване отгоре надолу	Тестване отдолу нагоре
Заменя	Модули от по-ниско ниво	Модули от по-високо ниво
функция	Връща фиктивни данни	Изпраща тестови данни
Сложност	Прости отговори	Тестова оркестрация

Stub-овете и драйверите намаляват зависимостите от тестване, позволяват паралелна разработка и ускоряват циклите на тестване, като елиминират времето за изчакване за пълна наличност на системата.

Как се прави интеграционно тестване?

Процедурата за интеграционно тестване, независимо от стратегиите за тестване на софтуера (обсъдени по-горе):

1. Подгответе интеграцията План за тестове
2. Проектирайте тестови сценарии, случаи и скриптове.
3. Изпълнение на тестовите случаи, последвано от докладване на дефектите.
4. Проследяване и повторно тестване на дефектите.
5. Стъпки 3 и 4 се повтарят, докато завършването на интеграцията е успешно.

Кратък Descriptпланове за тестване на интеграция

Той включва следните атрибути:

• Методи/подходи за тестване (както е обсъдено по-горе).
• Обхвати и елементи извън обхвата на интеграционното тестване.
• Роли и отговорности.
• Предпоставки за интеграционно тестване.
• Среда за тестване.
• Планове за риск и смекчаване.

Какви са критериите за влизане и излизане от интеграционното тестване?

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

Критерии за влизане:

• Единично тествани компоненти/модули
• Всички грешки с висок приоритет са поправени и затворени
• Всички модули трябва да бъдат завършени с код и интегрирани успешно.
• Интеграционни тестове План, тестов случай, сценарии за подписване и документиране.
• Длъжен Тестова среда да бъдат настроени за интеграционно тестване

Критерии за изход:

• Успешно тестване на интегрирано приложение.
• Изпълнените тестови случаи са документирани
• Всички грешки с висок приоритет са поправени и затворени
• Техническите документи трябва да бъдат представени, последвани от бележки за изданието.

Как бихте проектирали тестове за интеграция?

Силен интеграционен тест валидира как модулите обменят данни в реални работни процеси. По-долу е даден пример за процес на влизане на потребителя който интегрира слоеве от потребителски интерфейс, API и база данни:

Стъпка	Вход	Очакван резултат
1	Потребителят въвежда валидни идентификационни данни на екрана за вход	Идентификационните данни са изпратени сигурно към API за удостоверяване
2	API валидира идентификационните данни спрямо базата данни	Базата данни потвърждава съвпадение за потребителско име/парола
3	API връща токен за удостоверяване	Токенът е генериран и изпратен обратно към приложението
4	Потребителският интерфейс пренасочва потребителя към таблото за управление	Потребителската сесия е установена успешно

Този прост поток потвърждава комуникацията между три критични модула: Потребителски интерфейс → API → База данниЕдна неуспешна стъпка показва точно къде се нарушава интеграцията, помагайки на екипите да изолират дефектите по-бързо, отколкото само чрез тестване на системно ниво.

Най-добри практики/Насоки за интеграционно тестване

• Първо, определете интеграцията Тестова стратегия които биха могли да бъдат възприети, и по-късно да подготвят тестовите случаи и тестовите данни съответно.
• Проучете Archiтектурен дизайн на приложението и идентифициране на критичните модули. Те трябва да бъдат тествани приоритетно.
• Получете дизайна на интерфейса от Archiтектурен екип и създайте тестови случаи, за да проверите всички интерфейси в детайли. Интерфейсът към база данни/външно хардуерно/софтуерно приложение трябва да бъде тестван подробно.
• След тестовите случаи, тестовите данни играят критична роля.
• Винаги подготвяйте макетните данни преди изпълнение. Не избирайте тестови данни, докато изпълнявате тестовите случаи.

Често срещани предизвикателства и решения

Интеграционното тестване представя уникални препятствия, които могат да повлияят на сроковете и качеството на проекта. Ето най-критичните предизвикателства и техните практически решения.

1. Управление на сложни зависимости

Предизвикателство: Множеството зависимости от модули създават сложни сценарии за тестване с каскадни неуспехи.

Решение: Използвайте инжектиране на зависимости, контейнеризация (Docker) и тествайте на инкрементални слоеве. Документирайте всички взаимовръзки в матрици на зависимостите.

2. Непълни модули

Предизвикателство: Тестването се блокира, когато зависимите модули не са готови.

Решение: Разработете подробни драйвери/заглавия рано, използвайте виртуализация на услугите (WireMock) и внедрете тестване на договори с добре дефинирани интерфейси.

3. Управление на тестови данни

Предизвикателство: Поддържане на последователни, реалистични тестови данни в различните системи.

Решение: Внедрете автоматизирано генериране на тестови данни, използвайте моментни снимки на базата данни за бързо нулиране и контролирайте версиите на тестовите данни заедно с тестовите случаи.

4. Конфигурация на средата

Предизвикателство: Непоследователните среди причиняват неуспехи в интеграцията.

Решение: Използвайте инфраструктура като код (IaC), контейнеризация за паритет на средата и инструменти за управление на конфигурацията като Ansible.

5. Отстраняване на грешки при интеграция

Предизвикателство: Идентифицирането на коренните причини в множество компоненти е сложно.

Решение: Внедрете цялостно регистриране, използвайте разпределено проследяване (Jaeger/Zipkin) и добавете идентификатори на корелация, за да проследявате заявките в различните услуги.

6. Интеграция на услуги от трети страни

Предизвикателство: Недостъпността на външни услуги или промените в API прекъсват тестването.

Решение: Симулирани външни услуги (Postman Mock Server), внедрете механизми за повторен опит и поддържайте тестване за съвместимост на версиите на API.

7. Тесни места в производителността

Предизвикателство: Точките на интеграция се превръщат в пречки под натоварване.

Решение: Извършвайте ранно профилиране на производителността, внедрявайте стратегии за кеширане и използвайте асинхронна комуникация, където е уместно.

Въпроси и Отговори

Oбобщение