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

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

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

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

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

Диаграмата по-горе показва прогресията, която определя SIT: отделно проверените модули се обединяват стъпка по стъпка, докато не остане една интегрирана система, която да се тества.

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

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

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

Тестване за системна интеграция срещу системно тестване срещу тестване за приемане от потребителя

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

Параметър	Тестване на системната интеграция	Тестване на системата	Тестване за приемане на потребителите
Основен фокус	Интерфейси и поток от данни между интегрираните модули	Поведение на сглобената конструкция като цяло	Бизнес годност за реална употреба
Ниво на тестване	Ниво две	Ниво трето	Последно ниво преди пускане в експлоатация
Техника	Черна кутия	Черна кутия, бяла кутия или сива кутия	Черна кутия
Изпълнено от	Тестери и разработчици на интеграции	Независим екип за тестване	Клиент или крайни потребители
Типични дефекти	Интерфейс, време, памет и карта на даннитеping грешки	Функционални и нефункционални системни грешки	Несъответствия между използваемостта и изискванията
Изпълнява се, когато	След Единично тестване	След SIT	След системно тестване

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Входове:

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

Дейности:

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

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

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

Изходи

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

Често срещани предизвикателства при тестването на системната интеграция

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

• Несъответствие в средата: интегрираният тестова среда рядко отразява производството, така че дефектите във времето и конфигурацията се проявяват чак много късно.
• Готовност за зависимост: Интерфейсите на трети страни и наследените интерфейси често са недовършени, което принуждава тестерите да разчитат на заготовки и симулатори много по-дълго от планираното.
• Несъответствие в данните: Два модула могат да представят един и същ запис по различен начин, което води до тихи несъответствия вместо видими грешки.
• Собственост на дефекта: Когато един провал обхваща два екипа, е необходим анализ на първопричините и управление на дефекти забавят осезаемо.
• Цена на регресия: всеки нов интерфейс разширява регресионно тестване пакет, така че ръчното повторно изпълнение бързо става неустойчиво.

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

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

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

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

⚠ Съвет: Замразете спецификациите на интерфейса преди началото на интеграцията. Късна промяна във формата на съобщение прави тестовите случаи невалидни от двете страни на интерфейса и е най-честата причина за преработка на SIT.

Въпроси и Отговори