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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Входове:

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

Дейности:

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

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

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

Изходи

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

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

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

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

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

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

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

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

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

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

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

Тестване на интеграцията на софтуер към софтуер

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

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

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

Постепенен подход

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Oбобщение

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