Мени

Шта је интеграционо тестирање (Водич са примером интеграционог тестирања)

what is integration testing

Испробајте Наш Инструмент За Елиминисање Проблема

Шта је интеграционо тестирање: научите на примерима интеграционог тестирања

Интеграционо тестирање се врши за тестирање модула / компоненти када су интегрисани како би се верификовало да раде како се очекује, тј. За тестирање модула који раде у реду, појединачно нема проблема када се интегришу.

Када се говори о тестирању велике апликације применом технике тестирања црне кутије, подразумева се комбинација многих модула који су међусобно тесно повезани. Можемо применити концепте технике испитивања интеграције за тестирање ове врсте сценарија.

Листа туторијала обухваћених овом серијом:

Туториал # 1: Шта је интеграционо тестирање? (Овај водич)
Туториал # 2: Шта је инкрементално тестирање
Туториал # 3: Шта је испитивање компонената
Туториал # 4: Континуирано интеграција
Водич бр. 5 Разлика између јединственог тестирања и интеграције
Лекција # 6: Топ 10 алата за тестирање интеграције

шта је интеграционо тестирање

Шта ћете научити:

Шта је интеграционо тестирање?

Значење интеграционог тестирања је прилично једноставно - Интегришите / комбинујте јединично тестирани модул један по један и тестирајте понашање као комбинована јединица.

Главна функција или циљ овог испитивања је тестирање интерфејса између јединица / модула.

Ми обично радимо интеграционо тестирање након „јединичног тестирања“. Једном када се креирају и тестирају све појединачне јединице, започињемо комбиновање модула „Јединствено тестирано“ и започињемо са интегрисаним испитивањем.

Главна функција или циљ овог испитивања је тестирање интерфејса између јединица / модула.

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

Овде бисмо требали схватити да се интеграционо тестирање не догађа на крају циклуса, већ се оно спроводи истовремено са развојем. Дакле, у већини случајева сви модули заправо нису доступни за тестирање и ево шта представља изазов тестирати нешто што не постоји!

Зашто тест интеграције?

Сматрамо да је интеграционо тестирање сложено и да захтева одређени развој и логичке вештине. То је истина! Шта је онда сврха интегрисања овог тестирања у нашу стратегију тестирања?

Ево неколико разлога:

  1. У стварном свету, када се апликације развијају, оне се рашчлањују на мање модуле и појединачним програмерима се додељује 1 модул. Логика коју имплементира један програмер прилично се разликује од другог програмера, па постаје важно да се провери да ли је логика коју имплементира програмер у складу са очекивањима и да ли даје тачну вредност у складу са прописаним стандардима.
  2. Често се лице или структура података мењају када путују од једног до другог модула. Неке вредности се додају или уклоне, што узрокује проблеме у каснијим модулима.
  3. Модули такође комуницирају са неким независним алатима или АПИ-јевима које такође треба тестирати да ли су подаци које тај АПИ / алат прихвата тачни и да је генерисани одговор такође очекиван.
  4. Врло чест проблем у тестирању - честа промена захтева! :) Много пута програмер примењује промене без да их јединица тестира. Тада интеграционо тестирање постаје важно.

Предности

Постоји неколико предности овог тестирања, а неколико њих је наведено у наставку.

  • Ово тестирање осигурава да интегрисани модули / компоненте раде исправно.
  • Тестирање интеграције може се започети када модули који се тестирају постану доступни. Не захтева да се други модул доврши да би се извршило тестирање, јер се за исти могу користити греде и управљачки програми.
  • Открива грешке повезане са интерфејсом.

Изазови

У наставку је наведено неколико изазова који су укључени у тест интеграције.

# 1) Интеграционо тестирање значи тестирање два или више интегрисаних система како би се осигурало да систем исправно ради. Не би требало тестирати само везе интеграције, већ би требало обавити исцрпно испитивање с обзиром на окружење како би се осигурало да интегрисани систем исправно ради.

Могу постојати различити путеви и пермутације који се могу применити за тестирање интегрисаног система.

#два) Управљање интеграцијским тестирањем постаје сложено због неколико фактора који су у њега укључени као што су база података, платформа, окружење итд.

# 3) Иако интегрише било који нови систем са застарелим системом, захтева много промена и напора на тестирању. Исто важи и приликом интеграције било која два наслеђена система.

# 4) Интегрисање два различита система која су развиле две различите компаније је велики изазов, јер није сигурно како ће један од система утицати на други систем уколико се изврше промене у било ком од њих.

Да би се минимализирао утицај током развоја система, мало ствари треба узети у обзир попут могуће интеграције са другим системима итд.

Врсте испитивања интеграције

Доље је дата врста интеграције теста заједно са њеним предностима и недостацима.

Приступ Великог праска:

Приступ Великог праска интегрише све модуле у једном потезу, тј. Не иде за интегрисањем модула један по један. Проверава да ли систем ради како се очекивало или није једном интегрисан. Ако је било који проблем откривен у потпуно интегрисаном модулу, постаће тешко открити који је модул изазвао проблем.

Приступ Великог праска дуготрајан је процес проналажења модула који и сам има квар, јер би за то требало времена, а када се квар открије, његово отклањање коштало би високо као што је квар откривен у каснијој фази.

Приступ великог праска

Предности приступа Великог праска:

  • То је добар приступ за мале системе.

Мане приступа великог праска:

  • Тешко је открити модул који узрокује проблем.
  • Приступ Великог праска захтева све модуле за тестирање, што заузврат доводи до мање времена за тестирање, јер би пројектовање, развој и интеграција одузимали већину времена.
  • Тестирање се одвија само одједном што на тај начин не оставља времена за критично тестирање модула у изолацији.

Кораци тестирања интеграције:

  1. Припремите интеграцију План испитивања.
  2. Припремите сценарије интеграционих тестова и тестове.
  3. Припремите скрипте за аутоматизацију теста.
  4. Извршити тест случајеве.
  5. Пријави недостатке.
  6. Пратите и поново тестирајте недостатке.
  7. Поновно тестирање и тестирање се наставља док се интеграционо тестирање не заврши.

Приступи интеграцији теста

Постоје фундаментално 2 приступа за извођење тест интеграције:

  1. Приступ одоздо према горе
  2. Одозго на доле приступ.

Размотримо доњу слику како бисмо тестирали приступе:

Интеграција 1

Приступ одоздо према горе:

Тестирање одоздо према горе, као што и само име говори, започиње од најниже или најунутарње јединице апликације и постепено се креће према горе. Тестирање интеграције започиње од најнижег модула и постепено напредује ка горњим модулима апликације. Ова интеграција се наставља све док се сви модули не интегришу и док се целокупна апликација не тестира као једна целина.

У овом случају, модули Б1Ц1, Б1Ц2 и Б2Ц1, Б2Ц2 су најнижи модул који је јединствено тестиран. Модули Б1 и Б2 још нису развијени. Функционалност модула Б1 и Б2 је у томе што позива модуле Б1Ц1, Б1Ц2 и Б2Ц1, Б2Ц2. Будући да Б1 и Б2 још нису развијени, требао би нам неки програм или „стимулатор“ који ће позвати модуле Б1Ц1, Б1Ц2 и Б2Ц1, Б2Ц2. Ови програми стимулатора су позвани ВОЗАЧИ .

Једноставним речима, ВОЗАЧИ су лажни програми који се користе за позивање функција најнижег модула у случају када позивна функција не постоји. Техника одоздо према горе захтијева да управљачки програм модула унесе улаз тест случаја у интерфејс модула који се тестира.

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

Недостатак је што главни програм заправо не постоји док се последњи модул не интегрише и не тестира. Као резултат, недостаци у дизајну вишег нивоа биће откривени тек на крају.

Одозго на доле приступ

Ова техника започиње од највишег модула и постепено напредује ка доњим модулима. Једино се горњи модул тестира у изолацији. После овога, доњи модули се интегришу један по један. Поступак се понавља све док се сви модули не интегришу и не тестирају.

које врсте имејлова постоје

У контексту наше слике, испитивање започиње од модула А, а нижи модули Б1 и Б2 интегрисани су један по један. Сада овде доњи модули Б1 и Б2 заправо нису доступни за интеграцију. Дакле, да бисмо тестирали врхунске модуле А, развијамо „ СТУБС ”.

„Стубс“ се могу означити као исечак кода који прихвата улазе / захтеве горњег модула и враћа резултате / одговор. На овај начин, упркос доњим модулима, не постоје, у могућности смо да тестирамо горњи модул.

У практичним сценаријима понашање клица није тако једноставно како се чини. У ово доба сложених модула и архитектуре, такозвани модул, већину времена укључује сложену пословну логику попут повезивања са базом података. Као резултат, стварање Стубс-а постаје једнако сложено и одузима пуно времена као и прави модул. У неким случајевима може се испоставити да је модул Стуб већи од стимулисаног модула.

И Стубс и возачи су лажни део кода који се користи за тестирање „непостојећих“ модула. Они покрећу функције / методу и враћају одговор, који се упоређује са очекиваним понашањем

Закључимо неку разлику између Стубс анд Дривер :

СтубсВозач
Користи се у приступу одозго надолеКористи се у приступу одоздо према горе
Прво се тестира најмодернији модулНајпре се тестирају најнижи модули.
Стимулише нижи ниво компоненатаСтимулише виши ниво компонената
Лажни програм компонената нижег нивоаЛажни програм за компоненту вишег нивоа

Једина промена је Константа на овом свету, па имамо још један приступ под називом „ Сендвич тестирање ”Који комбинује карактеристике приступа одозго према доле и одоздо према горе. Када тестирамо огромне програме попут оперативних система, морамо имати још неколико техника које су ефикасне и подижу више самопоуздања. Овде тестирање сендвича игра веома важну улогу, где се истовремено започиње и тестирање одозго према доле и одоздо према горе.

Интеграција започиње са средњим слојем и истовремено се креће према горе и доле. У случају наше слике, наше тестирање започиње од Б1 и Б2, где ће једна рука тестирати горњи модул А, а друга рука доње модуле Б1Ц1, Б1Ц2 и Б2Ц1, Б2Ц2.

Будући да оба приступа започињу истовремено, ова техника је помало сложена и захтева више људи заједно са одређеним скуповима вештина, што доводи до трошкова.

Тест интеграције ГУИ апликације

Хајде сада да разговарамо о томе како можемо да подразумевамо интеграционо тестирање у техници црне кутије.

Сви разумемо да је веб апликација вишестамбена апликација. Имамо предњи крај који је видљив кориснику, имамо средњи слој који има пословну логику, имамо још средњи слој који врши неке валидације, интегрише неке независне АПИ-је итд., Затим имамо задњи слој који је база података.

Пример интеграционог тестирања:

Проверимо пример у наставку:

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

ГенНект софтвер развио овај производ за мене, а испод је била архитектура:

Интеграција 2

ЛУК - Модул корисничког интерфејса, који је видљив крајњем кориснику, где су дати сви улази.
БЛ - Да ли је модул Бусинесс Логиц који садржи све прорачуне и пословне методе специфичне.
ВАЛ - Да ли је модул за проверу ваљаности, који има све провере исправности уноса.
ЦНТ - Да ли је модул са садржајем који има сав статички садржај специфичан за улазе које је унео корисник. Овај садржај се приказује у извештајима.
ИН - Да ли је модул Енгине, овај модул чита све податке који долазе из БЛ, ВАЛ и ЦНТ модула, издваја СКЛ упит и активира га у базу података.
Планер - Да ли је модул који распоређује све извештаје на основу избора корисника (месечно, тромесечно, полугодишње и годишње)
ДБ - Да ли је база података.

Сада, видевши архитектуру целокупне веб апликације, као једну целину, интеграционо тестирање ће се у овом случају фокусирати на проток података између модула.

Овде су питања:

  1. Како ће БЛ, ВАЛ и ЦНТ модул читати и тумачити податке унете у УИ модул?
  2. Да ли БЛ, ВАЛ и ЦНТ модул примају тачне податке из корисничког интерфејса?
  3. У ком формату се подаци са БЛ, ВАЛ и ЦНТ преносе на ЕК модул?
  4. Како ће ЕК читати податке и издвојити упит?
  5. Да ли је упит правилно издвојен?
  6. Да ли Планер добија тачне податке за извештаје?
  7. Да ли је скуп резултата који је ЕН примио из базе података тачан и како се очекује?
  8. Да ли ЕН може да пошаље одговор натраг на БЛ, ВАЛ и ЦНТ модул?
  9. Да ли УИ модул може да прочита податке и прикаже их на одговарајући начин на интерфејсу?

У стварном свету комуникација података врши се у КСМЛ формату. Дакле, које год податке корисник унео у корисничко сучеље, они се претварају у КСМЛ формат.

У нашем сценарију подаци унети у УИ модул претварају се у КСМЛ датотеку која се интерпретира са 3 модула БЛ, ВАЛ и ЦНТ. ЕН модул чита резултујућу КСМЛ датотеку коју генеришу 3 модула и из ње извлачи СКЛ и упите у базу података. ЕН модул такође прима скуп резултата и претвара га у КСМЛ датотеку и враћа натраг у УИ модул који резултате претвара у кориснички читљивом облику и приказује.

У средини имамо модул планера који прима скуп резултата од ЕН модула, креира и планира извештаје.

Дакле, где се тестирање интеграције појављује на слици?

Па, тестирање да ли информације / подаци правилно теку или не, биће ваше тестирање интеграције, што би у овом случају потврдило КСМЛ датотеке. Да ли су КСМЛ датотеке правилно генерисане? Да ли имају тачне податке? Да ли се подаци правилно преносе са једног модула на други? Све ове ствари ће бити тестиране у оквиру интеграционог тестирања.

Покушајте да генеришете или преузмете КСМЛ датотеке и ажурирате ознаке и проверите понашање. Ово је нешто веома различито од уобичајеног тестирања које тестери обично раде, али ово ће додати вредност знању и разумевању апликације тестера.

Неколико других услова за испитивање узорака могу бити следећи:

  • Да ли опције менија генеришу исправан прозор?
  • Да ли прозори могу да позивају тест прозор?
  • За сваки прозор идентификујте позиве функција за прозор који апликација треба да дозволи.
  • Идентификујте све позиве из прозора према другим функцијама које апликација треба да дозволи
  • Утврдите реверзибилне позиве: затварање позваног прозора требало би да се врати у прозор за позивање.
  • Идентификујте неповратне позиве: позивање прозора се затвара пре него што се појави позвани прозор.
  • Тестирајте различите начине извршавања позива у други прозор, нпр. - менији, дугмад, кључне речи.

Кораци за започињање интеграционих тестова

  1. Разумевање архитектуре ваше апликације.
  2. Идентификујте модуле
  3. Разумети шта сваки модул ради
  4. Схватите како се подаци преносе са једног модула на други.
  5. Разумети како се подаци уносе и примају у систем (тачка уласка и излаза апликације)
  6. Одвојите апликацију према вашим потребама за тестирање.
  7. Идентификујте и створите услове за тестирање
  8. Узмите по један услов и запишите тест случајеве.

Критеријуми за улаз / излаз за тестирање интеграције

Критеријуми за улазак:

  • Документ о плану интеграционог испитивања је потписан и одобрен.
  • Припремљени су примери интеграционих тестова.
  • Подаци о тестовима су створени.
  • Јединствено тестирање развијених модула / компонената је завршен.
  • Све критичне и високоприоритетне мане су затворене.
  • Пробно окружење је постављено за интеграцију.

Излазни критеријуми:

  • Сви случајеви интеграцијског теста су извршени.
  • Не отварају се критичне и приоритетне грешке П1 и П2.
  • Извештај о испитивању је припремљен.

Случајеви интеграционих тестова

Случајеви интеграционих тестова углавном се фокусирају на интерфејс између модула, интегрисане везе, пренос података између модула као модула / компоненти који су већ јединично тестирани, тј. функционалност и други аспекти испитивања су већ покривени.

Дакле, главна идеја је тестирати да ли интеграција два радна модула функционише онако како се очекује када се интегришу.

На пример, примери интеграционих тестова за апликацију Линкедин укључују:

  • Провера везе интерфејса између странице за пријаву и почетне странице, тј. Када корисник унесе акредитиве и евидентира, требало би да буде усмерен на почетну страницу.
  • Провера везе интерфејса између почетне странице и странице профила, односно странице профила, треба да се отвори.
  • Потврдите везу интерфејса између мрежне странице и страница са везом, тј. Кликом на дугме за прихватање на позивницама мрежне странице требало би да се на страници са везом прикаже прихваћени позив када се једном кликне.
  • Потврдите везу интерфејса између страница са обавештењима и реците дугме за честитање, тј. Ако кликнете на дугме кажи честитке требало би да се усмери ка новом прозору поруке.

За ову одређену веб локацију могу се написати многи примери интеграционих тестова. Горње четири тачке су само пример за разумевање шта су примери испитивања интеграције укључени у тестирање.

Да ли је интеграција техника беле или црне кутије?

Техника интеграционог тестирања може се рачунати и у обе црне кутије техника беле кутије . Техника црне кутије је место где испитивач не мора имати никакво интерно знање о систему, тј. знање кодирања није потребно, док техници беле кутије треба интерно знање о апликацији.

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

Дакле, није специфично да је интеграционо тестирање техника црне или беле кутије.

Алати за тестирање интеграције

Постоји неколико алата доступних за ово тестирање.

Доље је дата листа алата:

  • Тестер рационалне интеграције
  • Кутомер
  • Стеам
  • ТЕССИ

За више детаља о горњим алатима погледајте овај водич:

10 најбољих алата за тестирање интеграције за писање интеграционих тестова

Тестирање системске интеграције

Тест системске интеграције се ради за тестирање комплетан интегрисани систем .

Модули или компоненте се појединачно испитују у јединственом тестирању пре интеграције компонената.

Једном када се тестирају сви модули, врши се тестирање интеграције система интегрисањем свих модула и систем у целини се тестира.

Разлика између интеграционог тестирања и системског тестирања

Интеграционо тестирање је тестирање у којем се интегришу један или два модула који су јединствено тестирани да би се тестирало и врши се верификација да би се верификовало да ли интегрисани модули раде како се очекује или не.

Системско тестирање је тестирање где систем у целини тестира се, тј. сви модули / компоненте су интегрисани заједно да би се проверило да ли систем ради како се очекивало и да се због интегрисаних модула не појављују проблеми.

Закључак

Овде се ради о интеграцијском тестирању и његовој имплементацији у техници Вхите бок и Блацк бок. Надам се да смо то јасно објаснили релевантним примерима.

Интеграција теста важан је део циклуса испитивања, јер олакшава проналажење квара када су интегрисана два или више модула како би се сви модули интегрисали у првом кораку.

Помаже у проналажењу недостатака у раној фази, што заузврат такође штеди труд и трошкове. Осигурава да интегрисани модули раде исправно како се очекује.

Надам се да би вам овај информативни водич о интеграцијском тестирању обогатио знање о концепту.

Препоручено читање

^