Ниједан развој софтвера не може без тестирања извршног кода. У ствари, то траје половину времена утрошеног на развој и више од половине трошкова пројекта. Међутим, он је саставни дио процеса креирања нових апликација, програма, система.
Један од начина контроле квалитета софтвера је тестирање интеграције, на улаз у који се уносе појединачни тестирани модули у претходној фази. За разлику од модуларне верзије, током које се откривају грешке, локализоване у свакој појединачној функцији или класи, интеграционо тестирање је тражење дефеката везаних за имплементацију интеракције између појединих делова креираног производа. Функционално тестирање интеграције користи метод бијеле кутије, тј. инжењер квалитета доступним и познатим текстовима сваког појединачног модула, као и принципима интеракције између њих.
Монолитни метод значи да се сви модули, који ће у будућности бити подвргнути интеграционом тестирању, саставе у исто вријеме. Скоро сигурно постоје ситуације када део тестираног комплекса још није спреман.
У овом случају, замењују га додатно развијени "утикачи" или управљачки програми.
Поред монолитне методе, идентификује се и инкрементални метод (назива се и корак по корак), јер се обим тестираног кода постепено повећава, омогућавајући локализацију подручја са дефектима у међусобним односима између појединих делова.
Инкрементални метод укључује два начина за додавање модула:
Главни недостатак монолитног типа монтаже је велика количина времена и трошкова рада за опонашање недостајућих делова тестираног комплекса. Чини се да су стубови прилично погодан алат за тестирање, међутим, ситуација се јавља када процес мора поново створити симулацијске дијелове програма. На пример, у случају промена у саставу тестираних модула. Поред тога, ефикасност потраге за дефектима није толико висока када се рад не обавља са стварним производом, већ само са лажном компонентом. Исти недостатак прати инкрементално тестирање методом изградње према горе.
У исто време, један од недостатака степ-би-степ метода је потреба да се организује и створи окружење за извршавање модула у датој секвенци. И паралелни развој горњег и доњег нивоа је готово немогућ.
Наравно, оба начина монтаже, монолитна и инкрементална, имају не само недостатке, већ и предности. У првом случају, постоје одличне могућности за паралелни развој свих класа и функција укључених у тестирање, како у почетној фази тако и након усавршавања. Метод корак по корак је мање радно интензиван: модули се постепено повезују, а грешке и дефекти се такође постепено откривају. Ово вам, као што знате, омогућава да скратите време за тражење таквих ствари.
У овој фази врши се колосални рад на провјери интерконекција на свим нивоима, без којих је, наравно, немогуће даље тестирање.
Тестирање интеграционог софтвера има неколико предности:
Тестирање интеграције је завршено, али то није све. Пронађене грешке се фиксирају и шаљу програмеру ради исправке, након чега процес почиње поново.
Прво, потребно је провјерити да ли су откривени недостаци уклоњени. Друго, током промене изворног кода, могу се појавити нове грешке у раду програма и интеракција са софтвером треће стране.
Иако тренутно постоји велики број метода контроле квалитета, интеграциона испитивања и даље играју важну улогу. Пример ове врсте верификације може јасно показати "уска грла" у развоју софтвера и документације.
У зависности од величине почетног скупа података и домена развоја, може постојати проблем са временом тестирања и сложеношћу догађаја у цјелини.
За најефикаснију верификацију развоја неопходно је користити огромну количину улазних података и услова, са којима је немогуће руковати "ручно". Да би се решио овај проблем, користи се аутоматизација тестирања. Као и други типови, тестирање интеграције се може аутоматизовати. Ово ће смањити време развоја као целине, као и побољшати ефикасност процеса откривања грешака.
Међутим, аутоматизација тестирања не може у потпуности заменити рад инжењера квалитета, већ га само допунити.
Дакле, интеграцијско тестирање је саставни дио развоја било којег софтвера и једне од фаза цијелог процеса провјере квалитете производа. Као и свака метода, она има бројне предности и недостатке, али без њене примјене, постаје немогуће развити софтвер високе квалитете.