Какво е интеграционно тестване? (Пример)
Какво е интеграционно тестване?
Тестване на интеграцията се определя като вид тестване, при което софтуерните модули се интегрират логически и се тестват като група. Типичният софтуерен проект се състои от множество софтуерни модули, кодирани от различни програмисти. Целта на това ниво на тестване е да разкрие дефекти във взаимодействието между тези софтуерни модули, когато са интегрирани
Интеграционното тестване се фокусира върху проверка на комуникацията на данни между тези модули. Следователно се нарича още като „Аз и Т“ (Интегриране и тестване), „Тестване на низове“ и понякога „Тестване на нишки“.
Защо да правите интеграционно тестване?
Въпреки че всеки софтуерен модул е единично тестван, все още съществуват дефекти по различни причини като
- Модулът като цяло е проектиран от индивидуален софтуерен разработчик, чието разбиране и програмна логика може да се различават от другите програмисти. Тестването на интеграцията става необходимо, за да се провери дали софтуерните модули работят в единство
- По време на разработването на модула има големи шансове за промяна в изискванията на клиентите. Тези нови изисквания може да не бъдат тествани модулно и следователно тестването на системната интеграция става необходимо.
- Интерфейсите на софтуерните модули с базата данни могат да бъдат грешни
- Външните хардуерни интерфейси, ако има такива, може да са грешни
- Неадекватното обработване на изключения може да причини проблеми.
Кликнете тук ако видеото не е достъпно
Пример за интеграционен тестов случай
Integration Тестов случай се различава от другите тестови случаи в смисъл, че фокусира се основно върху интерфейсите и потока от данни/информация между модулите. Тук приоритет трябва да се даде на интегриращи връзки вместо функциите на модула, които вече са тествани.
Примерни тестови случаи за интеграция за следния сценарий: Приложението има 3 модула, казват „Страница за влизане“, „Mailкутия“ и „Изтриване на имейли“ и всеки от тях е интегриран логически.
Тук не се концентрирайте много върху тестването на страницата за вход, тъй като това вече е направено в Единично тестване. Но проверете как е свързано с Mail Box Page.
по същия начин Mail Box: Проверете интегрирането му в Delete Mails Модул.
ID на тестов случай | Цел на тестовия случай | Тестов случай Descriptйон | очакван резултат |
---|---|---|---|
1 | Проверете интерфейсната връзка между входа и Mailкутия модул | Въведете идентификационни данни за вход и щракнете върху бутона Вход | Да бъде насочен към Mail Box |
2 | Проверете интерфейсната връзка между Mailкутия и Изтрий Mails Модул | от Mailизберете имейла и щракнете върху бутон за изтриване | Избраният имейл трябва да се появи в папката Изтрити/Кошче |
Видове интеграционни тестове
Софтуерното инженерство дефинира разнообразие от стратегии за изпълнение на интеграционно тестване, т.е.
- Подходът на Големия взрив:
- Постепенен подход: който е допълнително разделен на следните
- Подход отгоре надолу
- Подход отдолу нагоре
- Сандвич подход – Комбинация отгоре надолу и отдолу нагоре
По-долу са различните стратегии, начина, по който се изпълняват и техните ограничения, както и предимства.
Тестване на Големия взрив
Тестване на Големия взрив е подход за тестване на интеграция, при който всички компоненти или модули се интегрират заедно наведнъж и след това се тестват като единица. Този комбиниран набор от компоненти се счита за едно цяло по време на тестване. Ако всички компоненти в устройството не са завършени, процесът на интегриране няма да се изпълни.
Предимства:
- Удобен за малки системи.
Недостатъци:
- Локализацията на повредата е трудна.
- Предвид огромния брой интерфейси, които трябва да бъдат тествани при този подход, някои интерфейсни връзки, които трябва да бъдат тествани, могат лесно да бъдат пропуснати.
- Тъй като тестването на интеграцията може да започне само след като „всички“ модули са проектирани, екипът за тестване ще има по-малко време за изпълнение във фазата на тестване.
- Тъй като всички модули се тестват наведнъж, високорисковите критични модули не се изолират и тестват с приоритет. Периферните модули, които се занимават с потребителски интерфейси, също не са изолирани и тествани с приоритет.
Постепенно тестване
в Постепенно тестване подход, тестването се извършва чрез интегриране на два или повече модула, които са логически свързани един с друг и след това се тестват за правилното функциониране на приложението. След това другите свързани модули се интегрират постепенно и процесът продължава, докато всички логически свързани модули бъдат интегрирани и тествани успешно.
Инкременталният подход от своя страна се осъществява чрез два различни метода:
- Отдолу нагоре
- Отгоре надолу
Пънове и драйвери
Пънове и драйвери са фиктивните програми в интеграционното тестване, използвани за улесняване на тестване на софтуер активност. Тези програми действат като заместители на липсващите модели в тестването. Те не прилагат цялата програмна логика на софтуерния модул, но симулират комуникация на данни с извикващия модул по време на тестване.
коляно: Извиква се от тествания модул.
драйвер: Извиква модула за тестване.
Интеграционно тестване отдолу нагоре
Интеграционно тестване отдолу нагоре е стратегия, при която първо се тестват модулите от по-ниско ниво. След това тези тествани модули се използват допълнително за улесняване на тестването на модули от по-високо ниво. Процесът продължава, докато не бъдат тествани всички модули на най-високо ниво. След като модулите от по-ниско ниво са тествани и интегрирани, се формира следващото ниво от модули.
Диаграмно представяне:
Предимства:
- Локализацията на повредата е по-лесна.
- Не се губи време в чакане всички модули да бъдат разработени за разлика от подхода на Big-bang
Недостатъци:
- Критичните модули (на най-високото ниво на софтуерната архитектура), които контролират потока на приложението, се тестват последни и може да са податливи на дефекти.
- Ранен прототип не е възможен
Интеграционно тестване отгоре надолу
Интеграционно тестване отгоре надолу е метод, при който интеграционното тестване се извършва отгоре надолу, следвайки контролния поток на софтуерната система. Първо се тестват модулите от по-високо ниво и след това модулите от по-ниско ниво се тестват и интегрират, за да се провери функционалността на софтуера. Пънчетата се използват за тестване, ако някои модули не са готови.
Диаграмно представяне:
Предимства:
- Локализацията на повредата е по-лесна.
- Възможност за получаване на ранен прототип.
- Критичните модули се тестват приоритетно; основните дефекти в дизайна могат да бъдат намерени и коригирани първо.
Недостатъци:
- Нуждае се от много пънчета.
- Модулите на по-ниско ниво са тествани неадекватно.
Тестване на сандвич
Тестване на сандвич е стратегия, при която модулите от най-високо ниво се тестват с модули от по-ниско ниво, като в същото време модулите от по-ниско ниво се интегрират с модулите от най-високо ниво и се тестват като система. Това е комбинация от подходи отгоре надолу и отдолу нагоре, затова се нарича Тестване на хибридна интеграция. Той използва както пънове, така и драйвери.
Как се прави интеграционно тестване?
Процедурата за тестване на интеграцията, независимо от стратегиите за тестване на софтуера (обсъдени по-горе):
- Подгответе интеграцията План за тестове
- Проектирайте тестови сценарии, случаи и скриптове.
- Изпълнение на тестовите случаи, последвано от докладване на дефектите.
- Проследяване и повторно тестване на дефектите.
- Стъпки 3 и 4 се повтарят, докато завършването на интеграцията е успешно.
Кратък Descriptпланове за тестване на интеграция
Той включва следните атрибути:
- Методи/подходи за тестване (както е обсъдено по-горе).
- Обхвати и елементи извън обхвата на интеграционното тестване.
- Роли и отговорности.
- Предпоставки за интеграционно тестване.
- Среда за тестване.
- Планове за риск и смекчаване.
Входни и изходни критерии на интеграционното тестване
Входни и изходни критерии към фазата на тестване на интеграцията във всеки модел за разработка на софтуер
Критерии за влизане:
- Единично тествани компоненти/модули
- Всички грешки с висок приоритет са коригирани и затворени
- Всички модули трябва да бъдат завършени с код и интегрирани успешно.
- Интеграционни тестове План, тестов случай, сценарии за подписване и документиране.
- Длъжен Тестова среда да бъдат настроени за интеграционно тестване
Критерии за изход:
- Успешно тестване на интегрирано приложение.
- Изпълнените тестови случаи са документирани
- Всички грешки с висок приоритет са коригирани и затворени
- Технически документи, които трябва да бъдат изпратени, последвани от Бележки за изданието.
Най-добри практики/Насоки за интеграционно тестване
- Първо, определете интеграцията Тестова стратегия които биха могли да бъдат приети и по-късно да подготвят тестовите случаи и тестовите данни съответно.
- Проучете Archiтектурен дизайн на приложението и идентифициране на критичните модули. Те трябва да бъдат тествани приоритетно.
- Получете дизайна на интерфейса от Archiтектурен екип и създайте тестови случаи, за да проверите всички интерфейси в детайли. Интерфейсът към база данни/външно хардуерно/софтуерно приложение трябва да бъде тестван подробно.
- След тестовите случаи, тестовите данни играят критична роля.
- Винаги подготвяйте макетните данни преди изпълнение. Не избирайте тестови данни, докато изпълнявате тестовите случаи.