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

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

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

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

Защо да правите интеграционно тестване?

Тестване на интеграцията

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

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

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

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

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

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

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

по същия начин Mail Box: Проверете интегрирането му в Delete Mails Модул.

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

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

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

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

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

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

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

Предимства:

  • Удобен за малки системи.

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

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

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

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

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

  • Отдолу нагоре
  • Отгоре надолу

Пънове и драйвери

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

коляно: Извиква се от тествания модул.

драйвер: Извиква модула за тестване.

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

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

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

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

Предимства:

  • Локализацията на повредата е по-лесна.
  • Не се губи време в чакане всички модули да бъдат разработени за разлика от подхода на Big-bang

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

  • Критичните модули (на най-високото ниво на софтуерната архитектура), които контролират потока на приложението, се тестват последни и може да са податливи на дефекти.
  • Ранен прототип не е възможен

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

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

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

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

Предимства:

  • Локализацията на повредата е по-лесна.
  • Възможност за получаване на ранен прототип.
  • Критичните модули се тестват приоритетно; основните дефекти в дизайна могат да бъдат намерени и коригирани първо.

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

  • Нуждае се от много пънчета.
  • Модулите на по-ниско ниво са тествани неадекватно.

Тестване на сандвич

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

Тестване на сандвич

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

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

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

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

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

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

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

Входни и изходни критерии към фазата на тестване на интеграцията във всеки модел за разработка на софтуер

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

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

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

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

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

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