Какво е тестване за системна интеграция (SIT) с пример

Съдържание:

Anonim

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

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

Тестването на системна интеграция (SIT) се извършва, за да се провери взаимодействието между модулите на софтуерна система. Занимава се с проверка на изискванията за софтуер на високо и ниско ниво, посочени в Спецификацията / Данните за софтуерни изисквания и Документа за проектиране на софтуер.

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

Например, софтуерните и / или хардуерните компоненти се комбинират и тестват постепенно, докато цялата система не бъде интегрирана.

В този урок ще научите -

  • Какво е тестване на системната интеграция?
  • Защо се прави тестване на системната интеграция
  • Как да направите тестване на системната интеграция
  • Критерии за влизане и излизане за тестване на интеграция
  • Тестване на хардуер към интеграция на софтуер
  • Тестване на софтуер за интеграция на софтуер
  • Подход отгоре надолу
  • Подход отдолу нагоре
  • Подход за Големия взрив

Защо се прави тестване на системната интеграция

В софтуерното инженерство тестването на системна интеграция се извършва, защото,

  • Помага да се открие дефект рано
  • По-рано ще има обратна връзка относно приемливостта на отделния модул
  • Планирането на корекции на дефекти е гъвкаво и може да се припокрива с разработка
  • Коректен поток от данни
  • Коректен контрол на потока
  • Правилно време
  • Правилно използване на паметта
  • Коректно със софтуерните изисквания

Как да направите тестване на системната интеграция

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

Всички модули са предварително интегрирани и цялата програма е тествана като цяло. Но по време на този процес може да се срещне набор от грешки.

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

Има някои допълнителни методи, като тестовете за интеграция се провеждат в система, базирана на целевия процесор. Използваната методология е Black Box Testing. Може да се използва интеграция отдолу нагоре или отгоре надолу.

Тестовите случаи се дефинират, като се използват само софтуерните изисквания на високо ниво.

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

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

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

Забележка: Ако се тества само софтуер, това се нарича Тестване на софтуерна интеграция на софтуера [SSIT], а ако се тества както хардуер, така и софтуер, тогава се нарича Тестване на хардуерна интеграция на софтуер [HSIT].

Критерии за влизане и излизане за тестване на интеграция

Обикновено при извършване на тестове за интеграция се използва стратегия ETVX (критерии за влизане, задача, валидиране и изход).

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

  • Завършване на единично тестване

Входове:

  • Данни за софтуерни изисквания
  • Документ за софтуерен дизайн
  • План за проверка на софтуера
  • Документи за софтуерна интеграция

Дейности:

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

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

  • Успешно завършване на интеграцията на софтуерния модул на целевия хардуер
  • Коректно изпълнение на софтуера в съответствие с посочените изисквания

Изходи

  • Доклади от теста за интеграция
  • Случаи и процедури за тестване на софтуер [SVCP].

Тестване на интеграция на хардуерен софтуер

Тестването на хардуерна софтуерна интеграция е процес на тестване на компютърни софтуерни компоненти (CSC) за функционалности на високо ниво в целевата хардуерна среда. Целта на тестването на интеграция на хардуер / софтуер е да се тества поведението на разработения софтуер, интегриран върху хардуерния компонент.

Тестване на хардуерно-софтуерна интеграция на базата на изисквания

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

  • Грешки в хардуерния / софтуерния интерфейс
  • Нарушения на разделянето на софтуера.
  • Невъзможност за откриване на грешки чрез вграден тест
  • Неправилен отговор на хардуерни повреди
  • Грешка поради секвениране, преходни входни натоварвания и преходни мощности на входа
  • Неправилно поведение на обратната връзка
  • Неправилен или неправилен контрол на хардуера за управление на паметта
  • Проблем със спора в шината за данни
  • Неправилна работа на механизма за проверка на съвместимостта и коректността на полевия софтуер за зареждане

Интеграцията на хардуерен софтуер се занимава с проверка на изискванията на високо ниво. Всички тестове на това ниво се провеждат на целевия хардуер.

  • Тестването на черната кутия е основната методология за тестване, използвана на това ниво на тестване.
  • Дефинирайте тестовите случаи само от изискванията на високо ниво
  • Тестът трябва да бъде изпълнен на стандартния производствен хардуер (на целта)

Неща, които трябва да имате предвид при проектирането на тестови случаи за HW / SW интеграция

  • Правилно събиране на всички данни от софтуера
  • Мащабиране и обхват на данните, както се очаква от хардуер до софтуер
  • Коректно извеждане на данни от софтуер към хардуер
  • Данни в рамките на спецификациите (нормален диапазон)
  • Данни извън спецификациите (необичаен диапазон)
  • Данни за граници
  • Прекъсва обработката
  • Време
  • Правилно използване на паметта (адресиране, припокриване и т.н.)
  • Държавни преходи

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

Тестване на софтуер за интеграция на софтуер

Това е тестване на компютърния софтуерен компонент, работещ в хост / целевия компютър

Околна среда, като същевременно симулира цялата система [други CSC] и функционалността на високо ниво.

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

Инкрементален подход

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

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

Има два вида инкрементални тестове

  • Подход отгоре надолу
  • Подход отдолу нагоре

Подход отгоре надолу

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

  • Започвайки с основния контролен модул, модулите се интегрират чрез придвижване надолу през контролната йерархия
  • Подмодулите на основния модул за управление са включени в структурата или по ширина или по дълбочина.
  • Дълбочината интеграция интегрира всички модули по основен контролен път на структурата, както е показано на следната диаграма:

Процесът на интегриране на модула се извършва по следния начин:

  1. Основният контролен модул се използва като тест драйвер, а щифтовете са заместени за всички модули, пряко подчинени на основния контролен модул.
  2. Подчинените заглушки се заменят един по един с действителни модули в зависимост от избрания подход (първо ширина или първо дълбочина).
  3. Тестовете се изпълняват, когато всеки модул е ​​интегриран.
  4. При завършване на всеки набор от тестове, друг мъниче се заменя с реален модул при завършване на всеки набор от тестове
  5. За да сте сигурни, че не са въведени нови грешки, може да се извърши тестване на регресия.

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

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

Stubs заместват модулите на ниско ниво в началото на тестването отгоре надолу и следователно никакви значими данни не могат да изтекат нагоре в програмната структура.

Предизвикателства Изпитателят може да се изправи:

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

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

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

Подход отдолу нагоре

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

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

Този процес на интеграционен тест се извършва в поредица от четири стъпки

  1. Модулите от ниско ниво се комбинират в клъстери, които изпълняват специфична софтуерна подфункция.
  2. Написва се драйвер за координиране на входа и изхода на тестовия случай.
  3. Клъстерът или компилацията са тествани.
  4. Драйверите се премахват и клъстерите се комбинират, като се движат нагоре в програмната структура.

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

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

Подход за Големия взрив

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

При този подход е трудно да се разбере основната причина за неуспеха поради интегрирането на всичко наведнъж.

Също така ще има голям шанс за поява на критичните грешки в производствената среда.

Този подход се възприема само когато интеграционното тестване трябва да се извърши наведнъж.

Резюме:

  • Интеграцията се извършва, за да се провери взаимодействието между модулите на софтуерна система. Помага да се открие дефект рано
  • Интеграционно тестване може да се направи за хардуерно-софтуерна или хардуерно-хардуерна интеграция
  • Интеграционното тестване се извършва по два метода
    • Допълнителен подход
    • Подход с голям взрив
  • При извършване на тестове за интеграция обикновено се използва стратегия ETVX (критерии за влизане, задача, валидиране и изход).