Menu

Výukový program pre štrukturálne testovanie - Čo je to štrukturálne testovanie

  • Hlavná
  • Iné
  • Výukový program pre štrukturálne testovanie - Čo je to štrukturálne testovanie

structural testing tutorial what is structural testing

Vyskúšajte Náš Nástroj Na Odstránenie Problémov

Tento komplexný výukový program pre štrukturálne testovanie vysvetľuje, čo je štrukturálne testovanie, jeho typy, čo je to Testovanie toku riadenia a Graf toku riadenia, úrovne pokrytia atď .:

Rýchle vyhľadanie niektorých z najdrahších softvérových chýb pomocou vyhľadávača Google ma opustilo - 500 miliárd dolárov. Áno, takto môže chyba stáť. Čítanie všetkého, čo súvisí so stratami na životoch v doprave a zdravotníctve kvôli softvérovej chybe, môže byť tiež hrozné.

Aj keď chyby v kóde nie sú vždy také extrémne, keď zahŕňajú stratu veľkého množstva peňazí a životov, jediným kľúčovým riešením, ktoré sa tu snažíme naznačiť, je, že nemožno prehliadnuť testovanie.

Štrukturálne testovanie

Keď sa testovanie vykonáva často v celom SDLC, umožňuje nám to chytiť chyby, ktoré by po odoslaní produktu potrebovali na opravu oveľa viac času.

Dôležité sú typy testovania softvéru, ktoré si vyberieme. Existuje niekoľko z nich, vrátane funkčného, ​​štrukturálneho a testovania založeného na zmenách.

Tento výukový program tiež vysvetľuje typy štrukturálnych testov. Naučte sa, ako podrobne robiť Testovanie mutácií, Testovanie na základe segmentov, Testovanie dátových tokov s príkladmi a vysvetleniami.

Čo sa dozviete:

Prečo je testovanie softvéru dôležité

Okrem šetrenia peňazí a predchádzania katastrofám, ako sú prípady uvedené vyššie, existuje ešte niekoľko ďalších dôvodov, ktoré odôvodňujú dôležitosť testovania.

Nižšie sú uvedené niektoré dôvody:

# 1) Zaistiť splnenie stanovených požiadaviek pred začatím výstavby projektu. Zainteresované strany (napríklad vývojári a klienti) sa musia dohodnúť na všetkých aspektoch riešenia / produktu / softvéru, ktoré sú potrebné na vytvorenie projektu.

Testovanie zahŕňa overenie, či sú splnené softvérové ​​požiadavky. Vývojár alebo spoločnosť podieľajúca sa na vytváraní riešenia si tiež získavajú dobrú povesť pri navrhovaní tak kvalitného riešenia, ktoré riadi kód eclat.

# 2) Overuje, či funkcia kódu funguje podľa očakávaní. Testovanie tiež zahŕňa overenie funkčnosti softvéru a v prípade akejkoľvek poruchy by mala byť opravená počas raných fáz SDLC (Software Development Life Cycle).

# 3) Kontroluje sa výkon: Napríklad na identifikáciu celkového času, ktorý uplynul pri spustení kódu. Ak použijeme niekoľko Pre slučky v našom kóde bude trvať dlho, kým získate požadovaný výstup, a niekedy môže uplynúť aj časový limit.

# 4) Pomáha dosiahnuť lepšiu používateľskú skúsenosť. Používateľov nebude baviť používať softvér, ktorý nefunguje správne, buguje alebo je príliš pomalý. Používatelia pravdepodobne budú netrpezliví a prestanú používať softvér. Testovanie nám dáva lepšiu šancu zaistiť, aby používatelia mohli ľahko používať naše produkty.

# 5) Kontroluje sa škálovateľnosť. Vývojár by sa mal zamerať na vývoj softvéru, ktorý je možné škálovať.

# 6) Kontroluje chyby zabezpečenia v kóde. Testovanie nám umožňuje hľadať chyby v zabezpečení, Napríklad, kód, ktorý môže byť kompromitujúci PII (Osobne identifikovateľné informácie), čo je vysoká priorita nariadenia GDPR.

V tomto článku sa zameriame na jeden typ testovania, t.j. Štrukturálne testovanie . Ako naznačuje názov, súvisí to so štruktúrou kódu. To sa líši od toho, čo sme už spomenuli skôr, že testovanie pomáha určiť aspekty, ako je výkon kódu, funkčnosť a bezpečnosť.

Štrukturálne testovanie vs. Iné typy testovania

Existuje mnoho druhov testovania softvéru. Avšak STOP (Rada pre medzinárodné testovanie softvéru) definuje 4 hlavné typy testovania softvéru, a to

  • Funkčné
  • Nefunkčné
  • Štrukturálne
  • Na základe zmien

Rozdiely možno vysvetliť nižšie:

Funkčné testovanie: To zahŕňa overenie funkčnosti softvéru podľa stanovených požiadaviek. Ako vstup sa používajú údaje z testu. Tiež kontrolujeme, či je daný výstup podľa očakávania.

ako urobiť súbory .jar otvorené pomocou Java

Nefunkčné testovanie : Zahŕňa to testovací proces na analýzu toho, ako dobre softvér funguje, napríklad, počet používateľov, ktorých dokáže súčasne spracovať.

Štrukturálne skúšky: Tento typ testovania je založený na štruktúre kódu. Napríklad, ak je kód určený na výpočet priemeru párnych čísel v poli, potom by sa testovanie založené na štruktúre zaujímalo skôr o „kroky vedúce k výpočtu priemeru“, ako o to, či je konečným výstupom správna číselná hodnota.

Predpokladajme, že musíme skontrolovať, či sme definovali kód, ktorý rozlišuje párne čísla od nepárnych. Môžeme tu mať podmienené vyhlásenie, napríklad ak je prvok poľa deliteľný dvoma bez zvyšku, if (arr (i)% 2 === 0) potom sa dá číslo povedať ako párne číslo.

Štrukturálne testovanie vykonávajú tí istí ľudia, ktorí kód píšu tak, ako mu najlepšie rozumejú.

Testovanie založené na zmenách : Zahŕňa to testovanie účinkov vykonania zmien v kóde a následné zaistenie implementácie vykonaných zmien. Zaisťuje tiež, že zmeny v kóde ho nerozbijú.

Čo nie je štrukturálne testovanie

Už sme spomenuli, že testovanie na základe štruktúry sa týka štruktúry kódu. Upozorňujeme, že tu sa zaoberáme skutočným kódom. Nekontrolujeme porovnanie s požiadavkami alebo dokonca netestujeme vstupy s očakávanými výstupmi. V tomto okamihu sa nezaoberáme funkčnosťou, užívateľskými skúsenosťami alebo dokonca výkonom.

Čo je to štrukturálne testovanie

Testovanie na základe štruktúry preto možno definovať ako typ testovania softvéru, ktorý testuje štruktúru kódu a zamýšľané toky. Napríklad, overenie skutočného kódu z hľadiska aspektov, ako je správna implementácia podmienených príkazov, a či je každý príkaz v kóde správne vykonaný. Je tiež známe ako testovanie na základe štruktúry.

Aby sme mohli vykonať tento typ testovania, musíme dôkladne porozumieť kódu. Preto toto testovanie zvyčajne vykonávajú vývojári, ktorí napísali kód tak, ako mu najlepšie rozumejú.

Ako vykonávať štrukturálne skúšky

Aby sme mohli otestovať rôzne aspekty kódu, musíme najskôr porozumieť riadiacim tokom.

Kontrolné testovanie prietoku

Toto je odvodenie testov z riadiacich tokov kódu (poradie, v ktorom sú implementované príkazy, funkcie a rôzne aspekty kódu).

Proces testovania kontrolného toku:

Kontrolný vývojový graf

Proces toku riadenia začína vytvorením vizuálnej reprezentácie rôznych častí kódu, čo nám pomáha definovať cesty, ktoré je možné sledovať počas vykonávania.

Tieto vizuálne reprezentácie sú známe ako Control Flow Graphs (CFG) a obsahujú niekoľko komponentov, ako sú uzly, hrany, cesty, križovatky a rozhodovacie body. Graf je možné vytvoriť manuálne alebo automaticky, pričom na jeho extrakciu zo zdrojového kódu sa použije softvér.

Pozrime sa na tieto komponenty nižšie:

Uzly a hrany

# 1) Procesný blok

Táto časť slúži na predstavenie časti kódu, ktorá sa vykonáva postupne. To znamená, že sa vykonáva zakaždým rovnakým spôsobom, a nie je potrebné robiť žiadne rozhodnutia alebo „vetvenia“. Skladá sa z uzlov s jednou vstupnou a výstupnou cestou.

Príklad procesného bloku:

Procesný blok

(obrázok zdroj )

Blok procesu nie je podstatnou súčasťou regulačného toku a vo výsledku ho treba testovať iba raz.

# 2) Rozhodovacie body

Toto sú niektoré kľúčové komponenty v toku riadenia kódu. V rámci týchto uzlov sa prijímajú rozhodnutia. Spravidla sa to robí porovnaním a regulačný tok sa mení v závislosti od rozhodnutia. Táto časť CFG je tvorená jedným uzlom s najmenej 2 výstupmi.

Tu môžu byť rozhodnuté podmienečné vyhlásenia, ako sú príkazy if-else (ktoré majú dva možné výstupy) a prípadové vyhlásenia (ktoré môžu mať viac ako dva výstupy).

CFG

(obrázok zdroj )

Vo vyššie uvedenom diagrame je rozhodovací bod (z podmieneného „veku = 18“), za ktorým nasledujú možnosti „áno“ alebo „nie“.

# 3) Spojovacie body

Z vyššie uvedeného diagramu môžeme ľahko identifikovať spojovacie body, kde sa spájajú rozhodovacie body. Spojovacie body môžu mať veľa vstupných ciest, ale môžu mať iba jednu výstupnú cestu.

Osvedčené postupy pre kontrolné diagramy toku:

Pri konštrukcii grafov toku riadenia je potrebné si uvedomiť niekoľko vecí:

  • Snažte sa čo najviac, aby bol CFG jednoduchý. Môžeme to urobiť kombináciou častí, ktoré sa môžu považovať za „menej významné“, napríklad, procesné bloky.
  • Zaistite, aby sa v rozhodovacích bodoch prijalo iba jedno rozhodnutie. V zložitejších CFG existujú „dôsledky“, ktoré nastanú po prijatí rozhodnutia. V našom príklade vyššie by sme tiež mohli dodať, že ak má jednotlivec 18 rokov alebo viac, je spôsobilý a musí za lístok zaplatiť. Ak nie sú, potom je vstup zadarmo. Rozhodnutie „else“ musí „preskočiť“ niekoľko uzlov a všetky tieto kroky musia byť uvedené v našom CFG.

Akonáhle sme definovali náš CFG, je teraz čas prejsť na ďalší krok v procese testovania kontrolného toku, teda definovať rozsah, v akom ideme testovať kód.

Definovanie toho, koľko sa má testovať:

Koľko zo zdrojového kódu by sa malo testovať? Mali by sme vyskúšať každú možnú cestu? Pokúsiť sa pokryť všetky cesty v našich testoch je prakticky nemožné. Musíme nájsť strednú cestu, aby sme určili, koľko testovania môžeme urobiť.

Ak hovoríme, že sa zameriavame na testovanie 50% nášho kódu, mohlo by to znamenať, že definujeme všetky príkazy spustiteľného kódu a zameriame sa na testovanie najmenej polovice z nich. Tu však vyvstáva otázka, „musíme potom definovať všetky možné cesty spustiteľnosti?“

To môže byť opäť prakticky nemožné. Lepším prístupom môže byť zameranie na testovanie 50% ciest, ktoré môžeme identifikovať v každej časti kódu.

Existujú rôzne úrovne pokrytia, konkrétne vyhlásenie, vetva a pokrytie trasy. Pozrime sa na ne neskôr.

Vytváranie testovacích prípadov:

Ďalším krokom je vytvorenie testovacích prípadov, ktoré použijeme. Testovacie prípady pri testovaní na základe štruktúry sú založené na nasledujúcich faktoroch:

  • Spustiteľné vyhlásenia.
  • „Rozhodnutia“, ktoré je potrebné prijať.
  • Možné cesty, ktorými sa dá kráčať.
  • Podmienky, ktoré je potrebné splniť (môžu byť viacnásobné alebo boolovské).

Vyššie uvedené faktory nám poskytujú predstavu o typoch testovacích prípadov, ktoré musíme vytvoriť. Môžeme tiež použiť nástroj na generovanie štrukturálnych testov. Pokiaľ je náš kód v programovacom jazyku C, môžeme pomocou PathCrawlera generovať testovací kód. Ďalším nástrojom, ktorý môžeme použiť, je fMBT.

Vykonanie testovacích prípadov:

Tu môžeme spustiť testy. Môžeme zadať vstup alebo údaje, aby sme skontrolovali, ako ho kód vykonáva, a potom overiť, či dostaneme očakávané výsledky. Napríklad, zadajte pole do volania funkcie, aby ste sledovali, či výsledky, ktoré získame po jeho pretočení, alebo skontrolujte, či rozhodovacie body robia správne rozhodnutia.

Analýza výsledkov:

V tejto časti stačí skontrolovať, či po vykonaní získame správne výsledky. Napríklad, ak zadáme pole, kde sú všetky hodnoty nad 18, potom by sme mali mať všetky rozhodovacie body, ktorých výsledkom je „vhodné“.

Kontrolné predpoklady toku

Je dôležité si uvedomiť, že na vykonanie testovania kontrolného toku existuje niekoľko predpokladov. Tie obsahujú:

  • Jediné prítomné chyby sú tie, ktoré môžu ovplyvniť tok riadenia.
  • Všetky premenné, funkcie a prvky sú presne definované.

Úrovne pokrytia v riadiacich tokoch

Ako sme už spomenuli skôr, v testovaní riadiaceho toku existujú rôzne úrovne pokrytia.

Pozrime sa na ne v krátkosti.

# 1) Pokrytie vyhlásenia

Pri štrukturálnom testovaní hrajú príkazy spustiteľného kódu zásadnú úlohu pri rozhodovaní o metódach navrhovania testov.

Naším cieľom je dosiahnuť 100% pokrytie, čo znamená, že každý spustiteľný príkaz bol testovaný aspoň raz. Čím vyššie je pokrytie, tým menšia je pravdepodobnosť chýb chýb a chýb.

Tu sa vyžaduje použitie testovacích prípadov. Dáta, ktoré potrebujeme, sú zaistenie toho, aby sa každý spustiteľný príkaz v bloku kódu vykonal aspoň raz.

# 2) Pokrytie pobočky

Táto úroveň pokrytia zahŕňa testovanie bodov v pobočkách CFG (kde sa rozhoduje). Výsledky sú logické. Aj keď sa použije príkaz switch a existuje viac výsledkov, v podstate je každý prípadový blok porovnaním dvojice hodnôt.

Rovnako ako v prípade pokrytia výpisom by sme sa mali zamerať na 100% pokrytie pobočiek. Aby sme to dosiahli, musíme aspoň raz otestovať každý výsledok na každej rozhodovacej úrovni. Pretože sa zaoberáme boolovskými výsledkami, mali by sme sa zamerať na spustenie minimálne 2 testov na sekciu kódu.

# 3) Pokrytie trasy

Táto úroveň pokrytia je v porovnaní s pokrytím rozhodnutia a vyhlásenia dôkladnejšia. Cieľom je „objaviť“ všetky možné cesty a aspoň raz ich otestovať. To môže byť mimoriadne časovo náročné. Môže však pomôcť odhaliť chyby alebo chyby v našom kóde alebo dokonca aspekty, ktoré musíme definovať, napríklad, vstup používateľa.

Typy štrukturálnych skúšok

Typy štrukturálnych skúšok
(obrázok zdroj )

Testovanie mutácií

Testovanie mutácií je testovacia technika založená na poruchách, pri ktorej sa testujú rôzne variácie softvérovej aplikácie oproti množine testovacích údajov.

>> V tejto príručke nájdete podrobný pohľad Testovanie mutácií.

Slice Based Testing

Slice Based Testing (SBT) možno definovať ako techniku ​​testovania softvéru, ktorá je založená na plátky - spustiteľné časti programu alebo skupiny príkazov, ktoré ovplyvňujú niektoré hodnoty v konkrétnych bodoch záujmu v programe, napríklad, časti, kde sú definované premenné, alebo výstup skupiny príkazov.

Ako urobiť krájanie

Príklad krájania v SBT: Kód na vytlačenie párnych a nepárnych čísel (Python)

num_list = range(1,12) even_nums = () odd_nums = () for var in num_list: if var%2==0: even_nums.append(var) print(f'Even numbers: {even_nums}') elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}')

Slice-based testovanie

Existujú dva spôsoby, ako sa na plátok pozrieť: Sledovaním cesty sledovanej premennej alebo časti kódu, ktorá ovplyvňuje výstup.

V našom príklade, ak sa pozrieme na výstup nepárnych čísel, môžeme vystopovať časť kódu, ktorá nás vedie k tomuto výstupu.

V kritériách krájania daných Markom Weiserom (ktorý predstavil SBT) je plátok definovaný pomocou tohto vzorca: S (v, n) , kde, v odkazuje na príslušnú premennú ( napríklad, kde je definovaná premenná) a n je vyhlásenie o úrokoch ( napríklad, kde je uvedený výstup) a S predstavuje plátok.

Vo vyššie uvedenom príklade, aby sme získali plátok, vychádzame z nášho výstupu na riadku 10, ktorý sa stane naším n . Naša premenná je kde .

Naše kritériá pre krájanie teda sú:

S(v,n) = S(var,10)

Našim záujmom sú vyhlásenia, ktoré nás vedú k výstupu.

Sú to:
10,9,8,4,3,1

Náš rez v tomto kóde je teda:

num_list = range(1,12) odd_nums = () for var in num_list: elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}')

SBTSlice

Typy testovania na základe rezov

Existujú dva typy SBT: statické a dynamické

# 1) Dynamické testovanie založené na rezoch

Vyššie vysvetlený príklad SBT, kde sme sa pozreli na príkazy, ktoré ovplyvňujú tlač nepárnych čísel, je dynamický SBT. Naša obava je veľmi konkrétna. Zameriame sa iba na to, čo priamo ovplyvňuje konkrétny výstup.

Spustíme kód a pomocou testovacích údajov zabezpečíme, aby fungoval tak, ako má. Mohli by sme zvýšiť rozsah na rozsah (1,50), napríklad, aby sme zistili, či stále generuje iba nepárne čísla. Dynamický SBT je tiež známy ako testovanie platnosti.

# 2) StatickéSlice Based Testing

Na rozdiel od Dynamic SBT sa statické testovanie zameriava na konkrétnu premennú. Ak uvažujeme o našom výstupe vo vyššie uvedenom príklade ako kde , môžeme vystopovať plátok, ktorý ho ovplyvňuje ako 10,9,8,7,6,5,4,3,2,1

Je to v podstate celý blok kódu! Tu overujeme správnosť kódu z hľadiska syntaxe a požiadaviek a nevykonávame ho. Statický SBT je tiež známy ako overovacie testovanie.

kde nájsť kľúč zabezpečenia siete na smerovači -

Je dôležité poznamenať, že dynamický SBT je „menší“ v porovnaní s jeho statickým náprotivkom. Je to aj konkrétnejšie.

Osvedčené postupy / pokyny pre testovanie na základe rezov

Kritériá krájania by mali byť určené:

  • Príkazy, kde sú hodnoty definované alebo priradené hodnote, ako aj opätovne priradenej hodnote.
  • Výpisy, kde sa hodnoty prijímajú mimo programu, napríklad, prostredníctvom vstupu používateľa.
  • Výpisy, ktoré tlačia výstup / vrátia výstup.
  • Posledné vyhlásenie programu, napríklad, volanie funkcie, ktoré môže definovať hodnoty alebo poskytovať hodnoty argumentom

Medzi výhody testovania na základe rezov patria:

  • Pretože v SBT pracujeme iba s konkrétnymi oblasťami záujmu, uľahčuje to efektívne generovanie testovacích balíkov.
  • Cesta je definovaná závislosťami v rámci kódu, čo je lepšie ako použitie pokrytie cesty.
  • Pomocou SBT je ľahšie nájsť chyby v zdrojovom kóde.

Medzi nevýhody testovania na základe rezov patria:

  • Ak pri testovaní veľkej kódovej základne použijeme dynamické testovanie, budeme potrebovať veľa výpočtových zdrojov.
  • Ak použijeme statické testovanie, mohli by sme prísť o chyby.

Testovanie toku údajov

Testovanie dátových tokov možno definovať ako techniku ​​testovania softvéru, ktorá je založená na údajových hodnotách a ich použití v programe. Overuje, či boli dátové hodnoty správne použité a či generujú správne výsledky. Testovanie toku údajov pomáha vysledovať závislosti medzi hodnotami údajov na konkrétnej ceste vykonania.

Anomálie toku údajov

Anomálie toku údajov sú jednoducho chyby softvérového programu. Sú klasifikované do typov 1, 2 a 3 v uvedenom poradí.

Poďme sa im venovať nižšie:

Typ 1: Premenná je definovaná a hodnota je k nej priradená dvakrát.

Príklad kódu: Python

lst_1 = (1,2,3,4) lst_1 = (5,6,7,8) for var in lst_1: print(var)

Typ1

Lst_1 je definované a sú mu priradené dve rôzne hodnoty. Prvá hodnota je jednoducho ignorovaná. Anomálie typu 1 nespôsobujú zlyhanie programu.

Typ 2: Hodnota premennej sa použije alebo na ktorú sa odkazuje pred jej definovaním.

Príklad kódu: Python

for var in lst_1: print(var)

Typ 2

Vyššie uvedená slučka nemá žiadne hodnoty, ktoré by bolo možné iterovať. Anomálie typu 2 spôsobujú zlyhanie programu.

Typ 3: A generuje sa údajová hodnota, ale nikdy sa nepoužíva.

Príklad kódu: Python

lst_1 = (1,2,3,4) lst_2 = (5,6,7,8) for var in lst_1: print(var)

Typ 3

Premenná lst_2 nebol uvedený. Anomálie typu 3 nemusia spôsobiť zlyhanie programu.

Proces testovania toku údajov

Aby sme definovali závislosti medzi dátovými hodnotami, musíme definovať rôzne cesty, ktoré môžu byť v programe sledované. Aby sme to dokázali efektívne, musíme si požičať od iného typu štrukturálneho testovania známeho ako testovanie regulačného toku .

Krok 1) Nakreslite kontrolný graf toku

Musíme nakresliť kontrolný graf toku, ktorý je grafickým znázornením ciest, ktorými by sme sa v našom programe mohli riadiť.

Príklad kódu: Python

cost = 20 y = int(input('How many visitor seats did you reserve? ')) x = int(input('How many member seats did you reserve? ')) if y>x: bill = cost -1 else: bill = cost print(bill)

Testovanie toku údajov

Vo vyššie uvedenom príklade kódu by člen mal dostať zľavu, ak pozve návštevníka.

Kontrolný prietokový graf (CFG):

Kontrolný vývojový graf

Krok 2) Preskúmajte definíciu a použitie premenných a údajových hodnôt.

Premenná v programe je buď definovaná, alebo použitá. V CFG máme premenné na každom uzle. Každý uzol je pomenovaný podľa typu premennej, ktorú obsahuje. Ak je premenná definovaná v konkrétnom uzle, vytvorí definujúci uzol. Ak sa premenná použije v uzle, vytvorí sa uzol použitia.

Ak vezmeme do úvahy variabilné náklady v CFG, ide o uzly definovania a použitia:

UzolTypZákonníka
jeden Definujúci uzolnáklady = 20
5 Uzol použitiaúčet = náklady -1
7 Uzol použitiaúčet = náklady

Krok č. 3) Definujte cesty definície a použitia.

Existujú dva typy ciest definície a použitia: du cesty a dc cesty. cesty du sú definičné cesty, ktoré začínajú uzlom definície a končia uzlom použitia. To je prípad cesty s odkazom na vyššie uvedené variabilné náklady.

Príkladom cesty dc, cesty rozhodovania, je cesta ohľadne premennej vyúčtovania, ako je uvedené nižšie:

UzolTypZákonníka
5 Definujúci uzolúčet = náklady -1
7 Definujúci uzolúčet = náklady
8 Uzol použitiatlač (účet)

dc cesta má viac ako jeden definičný uzol, aj keď stále končí v uzle použitia.

Krok č. 4) Vytvorte testovaciu sadu.

Toto pridáva vstup. Upozorňujeme, že pre každú premennú musíme mať inú testovaciu sadu. Testovací balík nám pomôže zistiť anomálie toku údajov.

Typy testovania toku údajov

Existujú dva typy - Statický a dynamický .

Statický znamená, že prechádzame kódom a CFG, aby sme identifikovali anomálie údajov, bez toho, aby sme ich vykonali. Dynamický znamená, že v skutočnosti identifikujeme konkrétne cesty a potom vytvoríme testovacie sady, aby sme ich otestovali v snahe „zachytiť“ anomálie, ktoré nám mohli pri statickom testovaní chýbať.

Výhody a nevýhody testovania toku údajov:

  • Testovanie toku údajov je ideálne na identifikáciu anomálií toku údajov, čo z neho robí veľmi efektívnu metódu štrukturálneho testovania.
  • Nevýhodou je, že je potrebné sa dobre orientovať v jazyku použitom na napísanie kódu, aby bolo možné použiť testovanie toku údajov. Je to tiež časovo náročné.

Výhody a nevýhody štrukturálnych skúšok

Poďme teraz nájsť dôvody, prečo je štrukturálne testovanie skvelým prístupom, a preskúmajme tiež niektoré z jeho nevýhod.

Výhody:

  • Umožňuje dôkladné testovanie kódu, čo vedie k minimálnym chybám. Štrukturálne testovanie dáva priestor na dôkladné testovanie softvéru. Rôzne úrovne pokrytia - vyhlásenie po vyhlásení, každý rozhodovací bod a cesta sú zamerané na dosiahnutie 100% pokrytia, čo výrazne znižuje pravdepodobnosť, že chyby nebudú odhalené.
  • Schopnosť automatizovať . Existuje niekoľko nástrojov, ktoré môžeme použiť na automatizáciu testovania. To nám pomôže dosiahnuť maximálne pokrytie kódom a za kratší čas v porovnaní s manuálnym testovaním.
  • Výsledkom je kód vyššej kvality . Vývojári majú šancu preštudovať štruktúru a implementáciu kódu, opraviť chyby a vylepšiť tieto aspekty. Umožňuje nám to mať na pamäti skvelú štruktúru, keď píšeme ďalšie časti kódu alebo implementujeme zostávajúce funkcie.
  • Môže sa to uskutočniť cez každú fázu SDLC - Štrukturálne testovanie je možné vykonať v každej fáze SDLC bez čakania na 100% dokončenie vývoja. To umožňuje ľahkú identifikáciu chýb v počiatočnej fáze, a tým šetrí veľa času v porovnaní s testovaním po dokončení vývoja.
  • Pomáha zbaviť sa mŕtveho kódu . Toto sa dá považovať za „extra“ alebo nepotrebný kód, napríklad, kód, ktorý vypočíta výsledok, ale nikdy ho nepoužije v žiadnom z nasledujúcich výpočtov.
  • Účinnosť - Pretože vývojári píšuci kód sú tí istí, ktorí ho testujú, nie je potrebné zapájať ďalších ľudí, ako sú napríklad kontroly kvality.

Nevýhody:

  • Vývojári, ktorí vykonávajú testovanie na základe štruktúr, musia dôkladne porozumieť jazyku . Ostatní vývojári a QA, ktorí sa v tomto jazyku nevyznajú, nemôžu s testovaním pomôcť.
  • Môže to byť dosť drahé z hľadiska času a peňazí . Efektívne testovanie vyžaduje veľa času a zdrojov.
  • Spôsobuje oneskorenie pri poskytovaní funkcií . Je to tak preto, lebo vývojári sú priťahovaní z tvorby softvéru na vykonávanie testov.
  • Zmena mierky predstavuje problém, najmä ak sa jedná o veľké aplikácie . Veľká aplikácia sa rovná nadmerne vysokému počtu trás, ktoré treba pokryť. Dosiahnutie 100% pokrytia sa stáva nemožným.
  • Môžu chýbať prípady a trasy , napríklad, v prípade, že vlastnosti nie sú úplne vyvinuté alebo sa ešte len vyvinú. To znamená, že je potrebné ho kombinovať s inými typmi testovania, ako je testovanie požiadaviek (kde kontrolujeme porovnanie so zadanými funkciami, ktoré bolo treba vytvoriť).

Osvedčené postupy pre štrukturálne testovanie

Niektoré z faktorov, ktoré si vyžadujú pozornosť pri testovaní na základe štruktúry, sú nasledujúce:

  • Jasne označte a pomenujte testy . Ak testy potrebuje vykonať niekto iný, musí byť schopný ľahko ich nájsť.
  • Pred vylepšením kódu, t. J. Jeho refaktorovaním a optimalizáciou na použitie v rôznych prostrediach, sa uistite, že jeho štruktúra a tok sú ideálne.
  • Spustite testy osobitne . Týmto spôsobom je ľahké identifikovať chyby a opraviť ich. Na druhej strane je menej pravdepodobné, že vynecháme chyby alebo cesty v dôsledku prekrývania sekcií kódu, blokov alebo ciest.
  • Pred vykonaním zmien generujte testy . Testy musia prebiehať podľa očakávania. Týmto spôsobom, ak sa niečo pokazí, je ľahké problém vysledovať a opraviť.
  • Testy pre každú sekciu alebo blok kódu uchovávajte osobitne . Týmto spôsobom, ak dôjde k zmenám v riadku, nemusíme meniť veľa testov.
  • Opravte chyby skôr, ako budete pokračovať v testovaní . Ak identifikujeme nejaké chyby, je lepšie ich opraviť, než začneme testovať ďalšiu časť alebo blok kódu.
  • Nikdy nevynechajte štrukturálne testovanie za predpokladu, že QA „bude aj tak testovať“. Aj keď sa chyby môžu spočiatku javiť ako nepodstatné, kumulatívne, môžu viesť k chybnému kódu, ktorý nikdy nemôže dosiahnuť svoj zamýšľaný účel.

Časté otázky týkajúce sa testovania na základe štruktúry

Tu preskúmame najčastejšie otázky týkajúce sa testovania na základe štruktúry.

Otázka 1) Aký je rozdiel medzi funkčným a štrukturálnym testovaním?

Odpoveď: Funkčné testovanie je typ testovania softvéru založený na stanovených požiadavkách SRS (Špecifikácie softvérových požiadaviek). Spravidla sa to robí v snahe nájsť rozdiely medzi špecifikáciami v SRS a tým, ako funguje kód. Štrukturálne testovanie je založené na vnútornej štruktúre kódu a jeho implementácii. Vyžaduje sa dôkladné pochopenie kódu.

Otázka 2) Aké sú typy štrukturálnych skúšok?

oracle sql rozhovor otázky a odpovede pdf

Odpovedať typy zahŕňajú:

  • Testovanie dátového toku
  • Testovanie mutácií
  • Kontrolné testovanie toku
  • Slice-based testovanie

Otázka č. 3) Čo je príkladom štrukturálneho testovania?

Odpoveď: Tu je príklad ukazujúci pokrytie vyhlásenia:

const addNums = (num) => { let sum = num.reduce ((a,b) => a+b); if (sum > 0) { alert(sum); } else { alert(‘please enter positive numbers’); } }; addNums();

Rozsah pokrytia, ktorý dostaneme, závisí od testovacích údajov, ktoré poskytneme ako vstup (či spĺňa podmienky súčtu> 0).

Otázka č. 4) Aký je rozdiel medzi testovaním toku údajov a testovaním kontrolného toku?

Odpoveď: Testovanie toku údajov aj testovanie kontrolného toku používajú grafy kontrolného toku. Jediný rozdiel je v tom, že pri testovaní toku riadenia sa zameriavame na cesty generované z kódu, zatiaľ čo pri testovaní toku údajov sa zameriavame na hodnoty údajov, ich definíciu a použitie v rámci ciest identifikovaných v rámci programu.

Otázka č. 5) Na čo sa používa testovanie toku údajov?

Odpoveď: Testovanie dátového toku je ideálne na identifikáciu anomálií vo využívaní dátových hodnôt v rámci ciest v kontrolnom grafe toku, napríklad, jedna premenná, ktorej bola priradená hodnota dvakrát, premenná, ktorá bola definovaná a nepoužívaná, alebo premenná, ktorá bola použitá alebo na ktorú sa odkazuje a ktorá nie je definovaná.

Otázka č. 6) Aký je rozdiel medzi krájaním a krájaním na kocky pri testovaní softvéru?

Odpoveď: Krájanie na plátno znamená sústredenie sa na konkrétne vyhlásenia o záujme v programe a ignorovanie ostatných. Dicing je, keď identifikujeme rez, ktorý má nesprávny vstup, a potom ho ďalej nakrájame, aby sme vysledovali správne správanie.

Otázka č. 7) Aký je rozdiel medzi testovaním mutácií a pokrytím kódu?

Odpoveď: Pri testovaní mutácií považujeme počet zabitých mutantov za percento z celkového počtu mutantov. Pokrytie kódu je jednoducho množstvo kódu, ktorý bol testovaný v programe.

Záver

V tomto tutoriáli sme sa podrobne zamerali na štrukturálne testovanie - čo to je, čo to nie je, ako na to, typy pokrytia, výhody a nevýhody, osvedčené postupy a dokonca aj niektoré časté otázky týkajúce sa tohto typu testovania softvéru.

Je tu ešte oveľa viac, čo sa môžeme dozvedieť o testovaní na základe štruktúry. V budúcich tutoriáloch preskúmame pokrytie kódu (výroky, rozhodnutia, vetvy a cesty), typy štrukturálneho testovania (mutácie, tok dát a rozčlenenie) a dokonca aj nástroje, ktoré môžeme použiť na automatizáciu týchto testovacích procesov.

Je dôležité poznamenať, že neexistuje žiadny typ alebo prístup k testovaniu softvéru, ktorý by bol 100% efektívny. Vždy je vhodné kombinovať rôzne typy testovania a prístupy.

Napríklad, štrukturálne testovanie je výrazne doplnené testovaním požiadaviek, pretože môžu existovať prvky, ktoré nemuseli byť vyvinuté v čase, keď sa testovanie na základe štruktúry uskutočňovalo.

Techniky štrukturálneho testovania sú založené na chybách, ktoré robia ľudskí programátori pri písaní kódu. Predpokladá sa, že programátor je odborník a vie, čo kóduje, ale občas sa mýli.

Rôzne typy štrukturálneho testovania, na ktoré sme sa pozreli - testovanie mutácií, testovanie na základe rezov a testovanie toku údajov možno vysledovať späť k chybám, ako je použitie nesprávneho operátora (testovanie mutácií) alebo odkazovanie na premennú pred jej použitím (testovanie toku údajov) .

Odporúčané čítanie

^