Какво е тестване на интеграция?
ИНТЕГРАЦИОННОТО ИЗПИТВАНЕ се определя като вид тестване, при което софтуерните модули се интегрират логически и се тестват като група. Типичният софтуерен проект се състои от множество софтуерни модули, кодирани от различни програмисти. Целта на това ниво на тестване е да разкрие дефекти във взаимодействието между тези софтуерни модули, когато те са интегрирани
Интеграционното тестване се фокусира върху проверка на комуникацията на данни между тези модули. Следователно то се нарича още „I & T“ (интеграция и тестване), „тестване на низове“ и понякога „тестване на нишки“ .
- Какво е тестване на интеграция?
- Защо да тествам интеграция?
- Пример за тест за интеграция
- Подходи, стратегии, методологии на тестване за интеграция
- Подход за Големия взрив:
- Инкрементален подход
- Какво е Stub and Driver?
- Интеграция отдолу нагоре
- Интеграция отгоре надолу:
- Хибридна / сандвич интеграция
- Как да направя тестване за интеграция?
- Кратко описание на плановете за тестване на интеграцията:
- Критерии за влизане и излизане при тестване за интеграция
- Най-добри практики / насоки за тестване на интеграция
Защо да тествам интеграция?
Въпреки че всеки софтуерен модул е единично тестван, дефекти все още съществуват по различни причини като
- Модулът като цяло е проектиран от индивидуален разработчик на софтуер, чието разбиране и логика на програмиране може да се различава от другите програмисти. Интеграционното тестване става необходимо, за да се провери дали софтуерните модули работят в единство
- По време на разработването на модула има големи шансове за промяна в изискванията на клиентите. Тези нови изисквания може да не се тестват единично и следователно е необходимо тестване на системната интеграция.
- Интерфейсите на софтуерните модули с базата данни могат да бъдат погрешни
- Външните хардуерни интерфейси, ако има такива, може да са погрешни
- Неадекватното обработване на изключения може да причини проблеми.
Щракнете тук, ако видеоклипът не е достъпен
Пример за тест за интеграция
Интеграционният тестов случай се различава от другите тестови случаи по смисъла, че се фокусира главно върху интерфейсите и потока от данни / информация между модулите . Тук приоритет трябва да се даде на интегриращите връзки, а не на единичните функции, които вече са тествани.
Примерни случаи на тестове за интеграция за следния сценарий: Приложението има 3 модула, които казват „Страница за вход“, „Пощенска кутия“ и „Изтриване на имейли“ и всеки от тях е интегриран логически.
Тук не се концентрирайте много върху тестването на страницата за вход, тъй като това вече е направено в Unit Testing. Но проверете как е свързан със страницата на пощенската кутия.
По същия начин пощенска кутия: Проверете нейната интеграция в модула за изтриване на поща.
| Идентификатор на тестовия случай | Цел на тестовия случай | Описание на тестовия случай | очакван резултат |
|---|---|---|---|
| 1 | Проверете интерфейсната връзка между модула за вход и пощенска кутия | Въведете идентификационни данни за вход и кликнете върху бутона Login | Да бъде насочен към пощенската кутия |
| 2 | Проверете връзката на интерфейса между пощенската кутия и модула за изтриване на поща | От пощенска кутия изберете имейла и щракнете върху бутона за изтриване | Избраният имейл трябва да се появи в папката Изтрити / Кошче |
Подходи, стратегии, методологии на тестване за интеграция
Софтуерното инженерство определя разнообразие от стратегии за извършване на тестване за интеграция, а именно.
- Подход за Големия взрив:
- Инкрементален подход: който допълнително се разделя на следното
- Подход отгоре надолу
- Подход отдолу нагоре
- Сандвич подход - комбинация отгоре надолу и отдолу нагоре
По-долу са дадени различните стратегии, начинът им на изпълнение и техните ограничения, както и предимства.
Тестване на Големия взрив
Тестването на Големия взрив е подход за тестване на интеграция, при който всички компоненти или модули се интегрират едновременно и след това се тестват като единица. Този комбиниран набор от компоненти се разглежда като обект по време на тестване. Ако всички компоненти в устройството не са завършени, процесът на интегриране няма да се изпълни.
Предимства:
- Удобен за малки системи.
Недостатъци:
- Локализацията на грешки е трудна.
- Предвид огромния брой интерфейси, които трябва да бъдат тествани при този подход, някои интерфейси, които трябва да бъдат тествани, могат лесно да бъдат пропуснати.
- Тъй като тестването за интеграция може да започне само след като са проектирани "всички" модули, тестващият екип ще има по-малко време за изпълнение във фазата на тестване.
- Тъй като всички модули се тестват наведнъж, критичните модули с висок риск не се изолират и тестват приоритетно. Периферните модули, които се занимават с потребителски интерфейси, също не са изолирани и тествани по приоритет.
Допълнително тестване
В подхода на инкременталното тестване тестването се извършва чрез интегриране на два или повече модула, които са логически свързани помежду си и след това се тестват за правилното функциониране на приложението. След това другите свързани модули се интегрират постепенно и процесът продължава, докато всички логически свързани модули се интегрират и тестват успешно.
Инкрементният подход от своя страна се осъществява по два различни метода:
- Отдолу нагоре
- Отгоре надолу
Стъпки и драйвери
Stubs и Drivers са фиктивни програми в теста за интеграция, използвани за улесняване на дейността по тестване на софтуера. Тези програми действат като заместители на липсващите модели при тестването. Те не изпълняват цялата програмна логика на софтуерния модул, но симулират комуникация на данни с повикващия модул, докато тестват.
Stub : Извиква се от тествания модул.
Шофьор : Призовава модула да бъде тестван.
Тестване на интеграция отдолу нагоре
Интеграционното тестване отдолу нагоре е стратегия, при която първо се тестват модулите от по-ниско ниво. След това тези тествани модули се използват за улесняване на тестването на модули от по-високо ниво. Процесът продължава, докато всички модули на най-високо ниво бъдат тествани. След като модулите от по-ниско ниво са тествани и интегрирани, се формира следващото ниво от модули.
Диаграмно представяне :
Предимства:
- Локализирането на грешки е по-лесно.
- Не се губи време в очакване всички модули да бъдат разработени за разлика от подхода на Big-bang
Недостатъци:
- Критичните модули (на най-високото ниво на софтуерната архитектура), които контролират потока на приложението, се тестват последни и може да са склонни към дефекти.
- Ранен прототип не е възможен
Тестване на интеграция отгоре надолу
Интеграционното тестване отгоре надолу е метод, при който тестването на интеграция се извършва отгоре надолу, следвайки контролния поток на софтуерната система. Модулите от по-високо ниво се тестват първо и след това модулите от по-ниско ниво се тестват и интегрират, за да се провери функционалността на софтуера. Stubs се използват за тестване, ако някои модули не са готови.
Диаграмно представяне:
Предимства:
- Локализацията на грешки е по-лесна.
- Възможност за получаване на ранен прототип.
- Критичните модули се тестват приоритетно; могат да бъдат открити и отстранени първо основните конструктивни недостатъци.
Недостатъци:
- Нуждае се от много Stubs.
- Модулите на по-ниско ниво са тествани неадекватно.
Тестване на сандвич
Sandwich Testing е стратегия, при която модулите от най-високо ниво се тестват с модули от по-ниско ниво, като в същото време по-ниските модули се интегрират с топ модули и се тестват като система. Това е комбинация от подходи отгоре надолу и отдолу нагоре, поради което се нарича Тестване на хибридна интеграция . Използва както заглушители, така и драйвери.
Как да направя тестване за интеграция?
Процедурата за тестване на интеграцията, независимо от стратегиите за тестване на софтуера (обсъдени по-горе):
- Подгответе плана за тестове за интеграция
- Проектирайте тестовите сценарии, случаи и скриптове.
- Изпълнение на тестовите случаи, последвано от докладване на дефектите.
- Проследяване и повторно тестване на дефектите.
- Стъпки 3 и 4 се повтарят, докато завършването на интеграцията е успешно.
Кратко описание на плановете за тестване на интеграцията:
Той включва следните атрибути:
- Методи / Подходи за тестване (както е обсъдено по-горе).
- Обхвати и извън обхвата Елементи на тестване за интеграция.
- Роли и отговорности.
- Предпоставки за тестване на интеграция.
- Тестова среда.
- Планове за риск и смекчаване.
Критерии за влизане и излизане при тестване за интеграция
Критерии за влизане и излизане във фаза на тестване на интеграция във всеки модел за разработка на софтуер
Критерии за влизане:
- Единично тествани компоненти / модули
- Всички бъгове с висок приоритет са поправени и затворени
- Всички модули, които трябва да бъдат завършени и интегрирани успешно.
- Интеграционни тестове План, тестов случай, сценарии, които трябва да бъдат подписани и документирани.
- Необходима среда за тестване, която трябва да бъде създадена за тестване на интеграция
Критерии за изход:
- Успешно тестване на интегрирано приложение.
- Изпълнените тестови случаи са документирани
- Всички бъгове с висок приоритет са поправени и затворени
- Технически документи, които трябва да бъдат представени, последвани от бележки за изданието.
Най-добри практики / насоки за тестване на интеграция
- Първо, определете интеграционната тестова стратегия, която може да бъде приета, и по-късно подгответе тестовите случаи и тестовите данни съответно.
- Изучете архитектурния дизайн на приложението и идентифицирайте критичните модули. Те трябва да бъдат тествани по приоритет.
- Получете дизайна на интерфейса от Архитектурния екип и създайте тестови случаи, за да проверите подробно всички интерфейси. Интерфейсът към база данни / външен хардуер / софтуерно приложение трябва да бъде тестван подробно.
- След тестовите случаи тестовите данни играят решаваща роля.
- Винаги подготвяйте фалшивите данни, преди да ги изпълните. Не избирайте тестови данни, докато изпълнявате тестовите случаи.