fbpx

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

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

 

Table of Contents

Шта је инкрементално тестирање?

Шта је инкрементално тестирање у тестирању софтвера?

Тестирање је једна од најважнијих фаза животног циклуса развоја софтвера (СДЛЦ). Као и код СДЛЦ-а, тестирање је подељено на различите логичке кораке. Инкрементално тестирање је једна од ових фаза и обично се дешава током интеграционо тестирање и одмах након јединичног тестирања .

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

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

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

 

Шта су стубови и драјвери у инкременталном тестирању?

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

1. Стубови:

Стубови опонашају модуле који тек треба да се развију и као такви нису доступни за тестирање. Они дозвољавају модулу који се тестира (МУТ) да позове некомплетне модуле. Резултат је да се МУТ може тестирати изоловано, чак и када повезани модули нису доступни.

2. Возачи:

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

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

 

Различите врсте инкременталних

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

Различите врсте инкременталног тестирања интеграције

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

 

1. Инкрементална интеграција одозго надоле

 

Инкрементална интеграција одозго надоле почиње тестирањем модула највишег реда унутар система. Одатле постепено интегрише и тестира модуле нижег реда.Постоје два главна сценарија у којима се користи инкрементална интеграција одозго надоле. Су:

  • Када је систем веома велики или веома сложен
  • Када развојни тим ради на више модула истовремено.

Кораци за инкременталне интеграције одозго надоле

  • Идентификујте критичне модуле
  • Креирајте стубове да опонашате модуле нижег реда
  • Развијте драјвере за интеракцију са модулима вишег реда како бисте им послали податке и интерпретирали излазе модула
  • Јединични тест критичних модула са драјверима и стубовима
  • Интегришите модуле нижег реда и постепено замените стубове стварним имплементацијама
  • Рефакторирајте драјвере да бисте прилагодили нове модуле
  • Понављајте све док сви модули нижег реда не буду интегрисани и тестирани.

 

2. Инкрементална интеграција одоздо према горе

 

Инкременталне интеграције одоздо према горе иду у супротном смеру. Овим приступом тестирају се модули нижег реда (или најмање критични) система, уз постепено додавање модула вишег реда. Овај приступ је погодан у различитим сценаријима, као што су:

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

Кораци за инкременталне интеграције одоздо према горе

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

 

3. Функционална инкрементална интеграција

 

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

Функционална инкрементална интеграција се користи у Агиле/ДевОпс методологијама и одличан је избор за апликације са сложеним зависностима између модула или компоненти.

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

Кораци за функционалну инкременталну интеграцију

  • Идентификујте појединачне модуле и компоненте са добро дефинисаним интерфејсима
  • Проверите функционалност сваког модула путем тестирања јединица
  • Интегришите минималне основне модуле система и осигурајте да функционише
  • Постепено додајте појединачне модуле, тестирајући функционалност у сваком кораку
  • Рефакторирајте код како се сваки модул додаје
  • Када се додају сви модули, тестирајте функционалност и перформансе

 

Предности и мане инкременталног приступа тестирању

изазове тестирање оптерећења и РПА

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

 

Предности инкременталног приступа тестирању

 

1. Флексибилност

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

 

2. Рано откривање грешака

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

 

3. Једноставност

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

 

4. Мањи ризик регресије

Регресија је дуготрајно и сложено питање у развоју софтвера. Инкрементално тестирање може да ублажи учесталост и ризике узроковане регресијом јер омогућава тимовима да појединачно тестирају модуле и решавају проблеме када се појаве. Када се користи са чврстим регресијско тестирање , тимови могу уштедети много времена и болова.

 

5. Могућности повратних информација

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

 

Недостаци инкременталног приступа тестирању

 

1. Питања интеграције

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

 

2. Сложеност тестног пакета

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

 

3. Више посла

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

 

4. Повећани захтеви менаџмента

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

 

Пример инкременталног тестирања

Пример инкременталног тестирања

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

 

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

Сценарио: Тим прави апликацију за мобилно банкарство. Апликација се састоји од неколико различитих модула који омогућавају:

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

  • 2ФА и биометријска верификација корисника
  • Обрада трансакција
  • Контролна табла за управљање финансијским подацима

 

Објективан: Тим жели да тестира интеграцију сваког модула и утврди да ли добро функционишу заједно. Као резултат тога, они праве три тест случаја.

 

Тест случај 1

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

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

 

Тест случај 2

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

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

 

Тест случај 3

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

Апликација ће проћи тест ако корисник може започети трансакцију и приступити својим финансијским информацијама у исто време без икаквих недоследности или проблема у подацима.

 

Да ли је приступ тестирању инкременталности

исто као инкрементално тестирање?

алфа тестирање у односу на бета тестирање

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

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

 

Топ 3 алата за инкрементално тестирање

ЗАПТЕСТ РПА + Тест Аутоматион Суите

#1. ЗАПТЕСТ

Као и пружање првокласног РПА могућностима, ЗАПТЕСТ нуди низ алата за аутоматизацију тестирања софтвера који су савршени за инкрементално тестирање. Неке од карактеристика укључују:

  • Управљање тестним подацима : Смањите количину времена и труда укључених у инкрементално тестирање тако што ћете дозволити тимовима да поново користе податке теста
  • Снимање и репродукција скрипте : Овај алат без кодирања омогућава тимовима да снимају и извршавају скрипте и уштеде много времена током инкременталног тестирања
  • Тестни модули за вишекратну употребу : ЗАПТЕСТ је веома модуларан и омогућава тимовима да креирају и поново користе тестне модуле и скрате значајну количину времена ван процеса тестирања.

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

 

#2. Селен

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

 

#3. Тестсигма

Тестсигма је платформа за аутоматизацију тестирања заснована на облаку. Може се користити за тестирање веб и мобилних апликација и погодан је за инкрементално тестирање захваљујући креирању тестова без кода и интеграцији са ЦИ/ЦД цевоводима.

 

Последње мисли

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

Поред нашег најбољег РПА у класи алате, ЗАПТЕСТ нуди аутоматизацију тестирања софтвера без кодирања која је и на више платформи и на више апликација. Штавише, наш пакет за тестирање долази са функцијама као што су ЦИ/ЦД интеграција, робусно извештавање и аналитика, као и првокласна подршка и корисничка услуга.

Download post as PDF

Alex Zap Chernyak

Alex Zap Chernyak

Founder and CEO of ZAPTEST, with 20 years of experience in Software Automation for Testing + RPA processes, and application development. Read Alex Zap Chernyak's full executive profile on Forbes.

Get PDF-file of this post

Virtual Expert

ZAPTEST

ZAPTEST Logo