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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Входове:

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

Дейности:

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

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

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

Изходи

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

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

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

Изискване за хардуерно-софтуерно интегриране

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме:

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