Водич за структурно испитивање - шта је структурно испитивање

structural testing tutorial what is structural testing

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

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

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

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

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

како отворити .јава датотеке

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

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

• Зашто је тестирање софтвера важно
  • Структурно испитивање против других врста испитивања
  • Шта структурно испитивање није
• Шта је структурно испитивање
  • Како извршити структурно испитивање
  • Испитивање контролног протока
    • Графикон контролног тока
    • Претпоставке о контроли протока
  • Нивои покривености у контролним токовима
    • # 1) Покривеност изјаве
    • # 2) Покривеност филијале
    • # 3) Покривеност путање
• Врсте структурних испитивања
  • Испитивање мутација
  • Испитивање засновано на пресецима
    • Како се врши резање
    • Врсте испитивања засноване на пресецима
    • # 1) Динамично тестирање на основу пресека
    • # 2) Испитивање засновано на статичком пресеку
  • Испитивање протока података
    • Аномалије протока података
    • Процес испитивања протока података
  • Врсте испитивања протока података
• Предности и недостаци испитивања конструкција
• Најбоље праксе за структурно испитивање
  • Честа питања за испитивање засновано на структури
• Закључак
  • Препоручено читање

Зашто је тестирање софтвера важно

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

У наставку су наведени неки разлози:

# 1) Да би се осигурало да су испуњени прописани захтеви пре почетка израде пројекта. Актери (на пример, програмери и клијенти) морају да се договоре о свим аспектима решења / производа / софтвера потребних за изградњу пројекта.

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

# 2) Потврђује да функција кода ради како је предвиђено. Тестирање такође укључује верификацију функционалности софтвера и у случају било каквог квара треба га поправити током раних фаза СДЛЦ (животни циклус развоја софтвера).

# 3) Проверава перформансе: На пример, да идентификује укупно време протекло током покретања кода. Ако користимо неколико Фор Лоопс у нашем коду ће требати много времена да се добије жељени излаз, а понекад може и да истекне.

# 4) Помаже у постизању бољег корисничког искуства. Корисници неће уживати у коришћењу софтвера који не ради правилно, греши или је „преспор“. Корисници ће вероватно постати нестрпљиви и одустати од употребе софтвера. Тестирање нам даје бољу прилику да осигурамо да корисници могу лако да користе наше производе.

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

# 6) Проверава рањивости у коду. Тестирање нам омогућава прилику да пазимо на сигурносне пропусте, На пример, код који може да угрози ПИИ (Подаци који могу лично да идентификују) што је главни приоритет за ГДПР.

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

Структурно испитивање против других врста испитивања

Постоји много врста тестирања софтвера. Међутим ЗАУСТАВИТИ (Међународни одбор за квалификовање тестирања софтвера), дефинише 4 главна типа тестирања софтвера, наиме

• Функционално
• Нефункционалан
• Структурни
• На основу промена

Разлике се могу објаснити на следећи начин:

Функционално тестирање: То укључује проверу функционалности софтвера у складу са предвиђеним захтевима. Подаци за тестирање се користе као улаз. Такође проверавамо да ли је дати резултат очекиван.

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

Испитивање конструкције: Ова врста тестирања заснива се на структури кода. На пример, ако је код намењен израчунавању просека парних бројева у низу, тада би испитивање засновано на структури било заинтересовано за „кораке који воде до израчунавања просека“, уместо да ли је коначни резултат тачна нумеричка вредност.

Претпоставимо да морамо да проверимо да ли смо дефинисали код који разликује парне бројеве од непарних. Овде можемо имати условни израз, на пример, ако је елемент низа дељив са два без остатка, ако (арр (и)% 2 === 0) тада се број може рећи као паран број.

Структурно испитивање врше исти људи који пишу код онако како га најбоље разумеју.

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

Шта структурно испитивање није

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

Шта је структурно испитивање

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

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

Како извршити структурно испитивање

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

Испитивање контролног протока

Ово је извођење тестова из контролних токова кода (редослед у коме се примењују изрази, функције и различити аспекти кода).

Процес испитивања контролног протока:

Графикон контролног тока

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

Ови визуелни прикази познати су као Графикони протока (ЦФГ) и имају неколико компоненти попут чворова, ивица, путања, спојева и тачака одлучивања. Графикон се може креирати ручно или аутоматски, где се софтвер користи за издвајање графа из изворног кода.

Погледајмо ове компоненте у наставку:

# 1) Процесни блок

Овај део се користи за представљање одељка кода који се извршава секвенцијално. То значи да се сваки пут извршава на исти начин и нема одлука или „разгранавања“ које треба учинити. Састоји се од чворова са једним улазним и излазним путем.

Пример блока процеса:

(слика извор )

Процесни блок није битан део контролног тока и као резултат тога треба га тестирати само једном.

# 2) Тачке одлуке

Ово су неке кључне компоненте у контролном току кода. Унутар ових чворова доносе се одлуке. То се обично ради поређењем и контролни ток се мења, у зависности од одлуке. Овај део ЦФГ-а чини један чвор са најмање 2 излаза.

Овдје донесена одлука може бити условна изјава попут наредби иф-елсе (које имају два могућа излаза) и изјаве случаја (које могу имати више од два излаза).

(слика извор )

У горњем дијаграму постоји тачка одлуке (из условног „старост = 18 година“) након које следе опције „да“ или „не“.

# 3) Тачке спајања

Из горњег дијаграма можемо лако препознати тачке спајања где се спајају тачке одлуке. Спојне тачке могу имати много улазних путања, али могу имати само један излазни пут.

Најбоље праксе у графовима контролног тока:

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

• Покушајте што је више могуће да ЦФГ остане једноставан. То можемо учинити комбиновањем делова који се могу сматрати „мање значајним“, на пример, процесни блокови.
• Уверите се да је у тачкама одлуке донета само једна одлука. У сложенијим ЦФГ-има постоје „последице“ које долазе након доношења одлуке. У нашем горенаведеном примеру могли бисмо да додамо и да ако појединац има 18 година или више, онда испуњава услове и мора да плати карту. Ако нису, онда је улаз бесплатан. Одлука „остало“ треба да „прескочи“ неколико чворова и сви ти кораци морају бити приказани у нашем ЦФГ-у.

Једном када смо дефинисали свој ЦФГ, сада је време да пређемо на следећи корак у процесу испитивања контролног тока, тј. Да дефинишемо у којој мери ћемо тестирати код.

Дефинисање количине за тестирање:

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

Ако кажемо да имамо за циљ тестирање 50% нашег кода, то би могло значити да ћемо дефинисати све извршне наредбе кода и тежити тестирању најмање половине њих. Међутим, питање које се овде поставља је „да ли тада треба да дефинишемо све могуће извршне путеве?“

Ово је опет можда практично немогуће. Бољи приступ могао би бити усмерен на тестирање 50% путања које можемо идентификовати у сваком одељку кода.

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

Креирање тест случајева:

Следећи корак је стварање тест случајева које ћемо користити. Испитни примери у испитивањима заснованим на структури заснивају се на следећим факторима:

• Извршне изјаве.
• ‘Одлуке’ које треба донети.
• Могући путеви којима се може ићи.
• Услови које треба испунити (они могу бити вишеструки или логички).

Горе наведени фактори дају нам представу о врстама тест случајева које треба да створимо. Такође можемо користити алатку за генерисање структурних тестова. Ако је наш код на програмском језику Ц, можемо да користимо ПатхЦравлер за генерисање пробног кода. Још један алат који можемо користити је фМБТ.

Извршење тест случајева:

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

Питања и одговори за пословне аналитичаре

Анализа резултата:

У овом делу, све што радимо је да проверимо да ли добијамо тачне резултате након извршења. На пример, ако унесемо низ где су све вредности изнад 18, тада би требало да имамо све тачке одлуке које резултирају „подобним“.

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

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

• Присутне су само оне грешке које могу утицати на проток контроле.
• Све променљиве, функције и елементи су тачно дефинисани.

Нивои покривености у контролним токовима

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

Погледајмо их укратко.

# 1) Покривеност изјаве

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

Циљ нам је постићи 100% покривеност, што значи да је свака извршна изјава тестирана најмање једном. Што је већа покривеност, то је мања вероватноћа да ћете пропустити грешке и грешке.

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

# 2) Покривеност филијале

Овај ниво покривености укључује испитивање бодова у ЦФГ филијалама (где се доносе одлуке). Исходи су логички. Чак и ако се користи свитцх наредба и има више исхода, у основи је сваки блок случаја поређење пара вредности.

Као и код покривања извода, и ми бисмо требали тежити 100% покривености филијала. Да бисмо то постигли, морамо бар једном тестирати сваки исход на сваком нивоу одлуке. С обзиром на то да имамо посла са логичким исходима, онда бисмо требали тежити извођењу најмање 2 теста по одељку кода.

# 3) Покривеност путање

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

Врсте структурних испитивања

(слика извор )

Испитивање мутација

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

>> Погледајте овај водич за детаљан преглед Испитивање мутација.

Испитивање засновано на пресецима

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

Како се врши резање

Пример сечења у СБТ: Код за испис парних и непарних бројева (Питхон)

Постоје два начина да се погледа одрезак: Пратећи путању променљиве од интереса или дела кода који утиче на излаз.

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

У критеријумима за резање које је дао Марк Веисер (који је увео СБТ), део је дефинисан помоћу ове формуле: С (в, н) , где, в односи се на променљиву о којој је реч ( на пример, где је дефинисана променљива), и н је изјава о интересу ( на пример, где се даје излаз), и С. стоји за кришку.

У горњем примеру, да бисмо добили пресек, почињемо од нашег резултата на линији 10, који постаје наш н . Наша променљива је где .

Дакле, наши критеријуми за резање су:

Наша брига су изјаве које нас воде до резултата.

Су:
10,9,8,4,3,1

Дакле, наш део у овом коду је:

Врсте испитивања засноване на пресецима

Постоје две врсте СБТ: статички и динамички

# 1) Динамично тестирање на основу пресека

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

Извршавамо код и користимо тест податке да бисмо осигурали да ради онако како треба. Могли бисмо повећати опсег на опсег (1,50), на пример, да бисмо видели да ли и даље генерише само непарне бројеве. Динамички СБТ познат је и као тестирање валидације.

# 2) СтатичкиИспитивање засновано на пресецима

За разлику од Динамиц СБТ, фокус статичког испитивања је на одређеној променљивој. Ако о свом резултату у горњем примеру размишљамо као где , срез који утиче на њега можемо пратити као 10,9,8,7,6,5,4,3,2,1

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

Важно је напоменути да је динамички СБТ „мањи“ у поређењу са статичким колегом. Такође је конкретније.

Најбоље праксе / смернице за тестирање на основу пресека

Критеријуме за резање треба одредити:

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

Предности тестирања заснованог на пресецима укључују:

• Будући да у СБТ радимо само са одређеним областима од интереса, то олакшава ефикасно генерисање пробних комплета.
• Путања је дефинисана зависностима унутар кода, што је боље него користити покривеност пута.
• Са СБТ-ом је лакше пронаћи грешке у изворном коду.

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

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

Испитивање протока података

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

Аномалије протока података

Аномалије протока података су једноставно грешке у софтверском програму. Подељени су у типове 1, 2 и 3, респективно.

Удубимо се у њих у наставку:

Тип 1: Дефинисана је променљива и додељена јој је вредност два пута.

Пример кода: Питхон

Лст_1 је дефинисано и додељене су му две различите вредности. Прва вредност се једноставно занемарује. Аномалије типа 1 не доводе до неуспеха програма.

Тип 2: Вредност променљиве се користи или референцира пре него што се дефинише.

Пример кода: Питхон

Горња петља нема вредности за понављање. Неправилности типа 2 узрокују неуспех програма.

Тип 3: А. вредност података се генерише, али се никада не користи.

Пример кода: Питхон

Променљива лст_2 није референциран. Аномалије типа 3 можда неће проузроковати неуспех програма.

Процес испитивања протока података

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

Корак 1) Нацртајте граф контролног тока

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

Пример кода: Питхон

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

Графикон контролног протока (ЦФГ):

Корак 2) Истражите дефиницију и употребу променљивих и вредности података.

Варијабла у програму је или дефинисана или се користи. У ЦФГ-у имамо променљиве на сваком чвору. Сваки чвор је именован према типу променљиве који је смештен. Ако је променљива дефинисана на одређеном чвору, она ствара чвор који дефинише. Ако се променљива користи на чвору, она ствара чвор употребе.

Ако узмемо у обзир променљиве трошкове у ЦФГ-у, ово су чворови за дефинисање и употребу:

Корак # 3) Дефинисати путање употребе дефиниције.

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

Пример путање једносмерне струје, путање јасне одлуке је путања у односу на променљиву рачуна као што је доле наведено:

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

Корак # 4) Направите тест пакет.

Ово је додавање уноса. Имајте на уму да за сваку променљиву морамо имати различит пакет за тестирање. Пакет тестова ће нам помоћи да идентификујемо аномалије протока података.

Врсте испитивања протока података

Постоје две врсте - Статички и динамички .

Статички значи да пролазимо кроз код и ЦФГ да бисмо идентификовали аномалије података, без извршења. Динамично значи да заправо идентификујемо одређене путање, а затим креирамо скупове за тестирање да бисмо их тестирали у покушају да „ухватимо“ аномалије које смо можда пропустили током статичког тестирања.

Предности и недостаци испитивања протока података:

• Тестирање протока података идеално је за идентификовање аномалија протока података, што га чини врло ефикасном методом структурног испитивања.
• Његова лоша страна је у томе што постоји потреба за добро познавањем језика који се користи за писање кода да би се користило тестирање протока података. Такође је дуготрајан.

Предности и недостаци испитивања конструкција

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

Предности:

• Омогућава темељито тестирање кода, што резултира минималним грешкама. Тестирање засновано на структури даје простор софтверу за темељно тестирање. Различити нивои покривености - изјава по изјава, свака тачка одлуке и пут имају за циљ постизање 100% покривености што у великој мери смањује шансе да грешке остану неоткривене.
• Способност аутоматизације . Постоји неколико алата које можемо користити за аутоматизацију тестирања. То ће нам помоћи да постигнемо максималну покривеност кода и то за краће време у поређењу са ручним тестирањем.
• То резултира квалитетнијим кодом . Програмери имају прилику да проуче структуру и имплементацију кода и исправе све грешке, као и да побољшају ове аспекте. Омогућава нам да имамо на уму сјајну структуру док пишемо наредне делове кода или имплементирамо преостале функције.
• То се може урадити кроз сваку фазу СДЛЦ - Структурно испитивање може се обавити у свакој фази СДЛЦ-а без чекања да се развој заврши 100%. Ово олакшава препознавање грешака у раној фази и на тај начин штеди много времена у поређењу са тестирањем након завршетка развоја.
• Помаже у уклањању мртвог кода . Ово се може сматрати „додатним“ или непотребним кодом, на пример, код који ће израчунати резултат, али га никада не користи ни у једном од следећих прорачуна.
• Ефикасност - Будући да су програмери који пишу код исти они који га тестирају, нема потребе да укључујете друге људе попут КА.

Мане:

• Програмери који врше тестирање засновано на структури морају добро да разумеју језик . Остали програмери и КА који нису добро упућени у језик не могу помоћи у тестирању.
• Време и новац могу постати прилично скупи . За ефикасно тестирање потребно је много времена и ресурса.
• То узрокује кашњења у испоруци карактеристика . То је зато што су програмери повучени из израде софтвера да би тестирали.
• Скалирање је проблем, посебно тамо где су укључене велике апликације . Велика апликација једнака је прекомерном броју рута које треба прећи. Постизање 100% покривености постаје немогуће.
• Могу бити пропуштени случајеви и руте , на пример, у случају када обележја нису у потпуности развијена или тек треба да се развију. То значи да га треба комбиновати са другим врстама тестирања, као што је испитивање захтева (где проверавамо да ли постоје одређене функције које је требало изградити).

Најбоље праксе за структурно испитивање

Неки од фактора који захтевају пажњу током извођења испитивања заснованих на структури су следећи:

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

Честа питања за испитивање засновано на структури

Овде ћемо истражити често постављана питања када је реч о испитивању заснованом на структури.

П # 1) Која је разлика између функционалног испитивања и структурног испитивања?

Одговор: Функционално тестирање је врста софтверског тестирања заснованог на утврђеним захтевима у СРС (Спецификација софтверских захтева). Обично се ради у намери да се пронађу разлике између спецификација у СРС-у и начина на који код функционише. Структурно испитивање се заснива на унутрашњој структури кода и његовој примени. Потребно је темељно разумевање кода.

П # 2) Које су врсте структурних испитивања?

како направити списак јава

Одговорите типови укључују:

• Тестирање протока података
• Испитивање мутација
• Испитивање контролног протока
• Испитивање засновано на пресецима

П # 3) Шта је пример структурног испитивања?

Одговор: Ево примера који показује покривеност изјаве:

Количина покривености коју добијемо зависи од података о тесту које пружамо као улаз (да ли испуњава услове> 0).

П # 4) Која је разлика између испитивања протока података и контролног протока?

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

П # 5) За шта се користи тестирање протока података?

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

П # 6) Која је разлика између исецања и резања коцкицама у тестирању софтвера?

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

П # 7) Која је разлика између тестирања мутација и покривености кода?

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

Закључак

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

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

Важно је напоменути да не постоји тип тестирања софтвера или приступ који је 100% ефикасан. Увек је препоручљиво комбиновати различите врсте и приступе испитивања.

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

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

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

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

• Водич за испитивање разарања и испитивања без разарања
• Функционално тестирање вс нефункционално тестирање
• Шта је техника испитивања заснована на недостацима?
• Водич за тестирање намакања - шта је тестирање потапања
• Водич за тестирање СОА: Методологија тестирања за модел архитектуре СОА
• Испитивање оптерећења помоћу ХП ЛоадРуннер водича
• Шта је гама тестирање? Завршна фаза испитивања
• Водич за тестирање ДевОпс-а: Како ће ДевОпс утицати на КА тестирање?
• Шта је испитивање усаглашености (испитивање усаглашености)?