Meni

Vadnica za strukturno preskušanje - kaj je strukturno preskušanje

  • Glavni
  • Drugo
  • Vadnica za strukturno preskušanje - kaj je strukturno preskušanje

structural testing tutorial what is structural testing

najboljši pretvornik youtube v mp4

Preizkusite Naš Instrument Za Odpravo Težav

Ta izčrpna vadnica za strukturno preskušanje pojasnjuje, kaj je strukturno preskušanje, njene vrste, kaj je preskušanje krmiljenja pretoka in graf krmiljenja pretoka, ravni pokritosti itd .:

Hitro Googlovo iskanje nekaterih najdražjih napak v programski opremi mi je pustilo v glavi - 500 milijard dolarjev. Da, tako je napaka lahko draga. Branje vsega, kar je povezano z izgubljenimi življenji v prometni in zdravstveni industriji zaradi napak v programski opremi, je lahko tudi grozljivo.

Čeprav napake v kodi niso vedno tako skrajne, če vključujejo izgubo obilnih količin denarja in življenj, je edini ključni odvzem, ki ga poskušamo posredovati, ta, da testiranja ni mogoče spregledati.

Strukturno preskušanje

Če se testiranje pogosto izvaja v celotnem SDLC, nam omogoča, da odkrijemo napake, ki bi po pošiljanju izdelka potrebovale veliko več časa.

Pomembne so vrste preskušanja programske opreme, ki jih izberemo. Teh je več, med njimi funkcionalno, strukturno in preskušanje na podlagi sprememb.

Ta vadnica razlaga tudi vrste strukturnih preskusov. Podrobno se naučite, kako opraviti mutacijsko testiranje, preskušanje na osnovi rezin, testiranje pretoka podatkov s primeri in razlagami.

Kaj se boste naučili:

Zakaj je testiranje programske opreme pomembno

Poleg prihranka denarja in izogibanja nesrečam, kot so zgoraj omenjeni primeri, obstaja še več razlogov, ki upravičujejo pomen testiranja.

Spodaj je navedenih nekaj razlogov:

# 1) Zagotoviti, da so izpolnjene določene zahteve preden začnete graditi projekt. Zainteresirane strani (na primer razvijalci in stranke) se morajo dogovoriti o vseh vidikih rešitve / izdelka / programske opreme, ki so potrebni za izdelavo projekta.

Testiranje vključuje preverjanje, ali so zahteve glede programske opreme izpolnjene. Razvijalec ali podjetje, ki sodeluje pri izdelavi rešitve, si prav tako pridobi dober sloves pri oblikovanju tako kakovostne rešitve, ki jo vodi koda eclat.

# 2) Preveri, ali funkcija kode deluje, kot je predvideno. Testiranje vključuje tudi preverjanje funkcionalnosti programske opreme in v primeru kakršne koli okvare jo je treba odpraviti v zgodnjih fazah SDLC (življenjski cikel razvoja programske opreme).

# 3) Preveri delovanje: na primer za prepoznavanje skupnega časa, ki je potekel med izvajanjem kode. Če jih uporabimo več Za zanke v naši kodi bo trajalo veliko časa, da dobimo predvideni izhod, včasih pa lahko tudi časovno omejitev.

# 4) Pomaga doseči boljšo uporabniško izkušnjo. Uporabniki ne bodo uživali v uporabi programske opreme, ki deluje okvarjeno, napačno ali 'prepočasi'. Uporabniki bodo verjetno postali nestrpni in zapustili uporabo programske opreme. Testiranje nam omogoča boljši poskus zagotavljanja, da lahko uporabniki enostavno uporabljajo naše izdelke.

# 5) Preveri razširljivost. Razvijalec si mora prizadevati za izdelavo programske opreme, ki jo je mogoče razširiti.

# 6) Preveri ranljivosti v kodi. Testiranje nam omogoča, da odpravimo varnostne ranljivosti, Na primer kodo, ki lahko ogrozi PII (Osebni podatki), ki je za GDPR glavna prednostna naloga.

V tem članku se bomo osredotočili na eno vrsto testiranja, tj. Strukturno preskušanje . Kot že ime pove, je to povezano s strukturo kode. To se razlikuje od tistega, kar smo že omenili, da testiranje pomaga določiti vidike, kot so zmogljivost kode, funkcionalnost in varnost.

Strukturno preskušanje proti drugim vrstam preskušanja

Obstaja veliko vrst testiranja programske opreme. Vendar pa STOP (International Software Testing Qualifications Board), opredeljuje 4 glavne vrste testiranja programske opreme, in sicer

  • Delujoč
  • Nefunkcionalno
  • Strukturni
  • Na podlagi sprememb

Razlike je mogoče razložiti spodaj:

Funkcionalno preskušanje: To vključuje preverjanje funkcionalnosti programske opreme glede na določene zahteve. Kot vhodni podatki se uporabljajo preskusni podatki. Prav tako preverimo, ali je podana izhodna vrednost pričakovana.

Nefunkcionalno preskušanje : To vključuje postopek testiranja za analizo, kako dobro deluje programska oprema, na primer, število uporabnikov, ki jih lahko hkrati obravnava.

Strukturna preskušanja: Ta vrsta testiranja temelji na strukturi kode. Na primer če je koda namenjena izračunu povprečja parnih števil v matriki, potem bi testiranje na podlagi strukture zanimalo 'korake, ki vodijo do izračuna povprečja', in ne, ali je končni izhod pravilna številčna vrednost.

Recimo, da moramo preveriti, ali smo definirali kodo, ki razlikuje parna števila od neparnih. Tu imamo lahko pogojni stavek, na primer, če je element matrike deljiv z dvema brez ostanka, če (arr (i)% 2 === 0) potem lahko številko rečemo kot sodo številko.

Strukturna testiranja izvajajo isti ljudje, ki pišejo kodo, kot jo najbolje razumejo.

Testiranje na podlagi sprememb : To vključuje preizkušanje učinkov spreminjanja kode in nato zagotovitev, da so bile izvedene spremembe izvedene. Zagotavlja tudi, da je spremembe kode ne prekinejo.

Kaj strukturno preskušanje ni

Prej smo že omenili, da se strukturno testiranje nanaša na strukturo kode. Upoštevajte, da tukaj obravnavamo dejansko kodo. Ne preverjamo zahtev ali celo preizkušamo vhode glede na pričakovane izhode. V tem trenutku nas ne zanimajo funkcionalnost, uporabniška izkušnja ali celo zmogljivost.

Kaj je strukturno preskušanje

Testiranje na podlagi strukture je torej mogoče opredeliti kot vrsto testiranja programske opreme, ki preizkuša strukturo kode in predvidene tokove. Na primer preverjanje dejanske kode za vidike, kot je pravilno izvajanje pogojnih stavkov, in ali je vsak stavek v kodi pravilno izveden. Znano je tudi kot strukturno testiranje.

Za izvedbo te vrste preskušanja moramo dobro razumeti kodo. Zato to testiranje običajno opravijo razvijalci, ki so kodo napisali, kot jo najbolje razumejo.

Kako izvesti strukturna preskušanja

Za preizkušanje različnih vidikov kode moramo najprej razumeti krmilne tokove.

Testiranje nadzornega pretoka

To izhaja iz testov iz krmilnih tokov kode (vrstni red izvajanja stavkov, funkcij in različnih vidikov kode).

Postopek testiranja kontrolnega pretoka:

Graf nadzornega toka

Proces krmilnega toka se začne z ustvarjanjem vizualne predstavitve različnih odsekov kode, ki nam pomaga določiti poti, po katerih lahko sledimo med izvajanjem.

Ti vizualni prikazi so znani kot nadzorni grafi pretoka (CFG) in imajo več komponent, kot so vozlišča, robovi, poti, križišča in odločitvene točke. Graf je mogoče ustvariti ročno ali samodejno, kjer se programska oprema uporablja za pridobivanje grafa iz izvorne kode.

Oglejmo si te komponente spodaj:

Vozlišča in robovi

# 1) Procesni blok

Ta del se uporablja za predstavitev dela kode, ki se izvaja zaporedno. To pomeni, da se izvede vsakič na enak način in ni nobenih odločitev ali 'razvejanja', ki bi jih bilo treba narediti. Sestavljen je iz vozlišč z eno vstopno in izhodno potjo.

Primer bloka procesa:

Procesni blok

(slika vir )

Procesni blok ni bistveni del krmilnega toka, zato ga je treba preizkusiti le enkrat.

# 2) Odločitvene točke

To je nekaj ključnih komponent v krmilnem toku kode. Znotraj teh vozlišč se sprejemajo odločitve. To se običajno opravi s primerjavo in nadzorni tok se spremeni, odvisno od odločitve. Ta del CFG je sestavljen iz enega vozlišča z vsaj dvema izhodoma.

Tu lahko sprejmemo pogojne stavke, kot so stavki if-else (ki imajo dva možna izhoda) in stavki case (ki imajo lahko več kot dva izhoda).

CFG

(slika vir )

V zgornjem diagramu je točka odločitve (iz pogojnega 'starost = 18'), ki mu sledijo možnosti 'da' ali 'ne'.

# 3) križišča

Iz zgornjega diagrama lahko zlahka prepoznamo točke stičišč glede mesta, kjer se točke odločitve združujejo. Križišča imajo lahko veliko vstopnih poti, lahko pa imajo samo eno izhodno pot.

Nadzor grafov pretoka najboljše prakse:

Pri izdelavi grafov krmilnega toka je treba upoštevati nekaj stvari:

  • Poskusite čim bolj, da ostane CFG preprost. To lahko storimo s kombiniranjem delov, ki se lahko štejejo za „manj pomembne“, na primer, procesnih blokov.
  • Poskrbite, da bo na točkah odločanja sprejeta samo ena odločitev. V bolj zapletenih CFG obstajajo 'posledice', ki nastanejo po sprejetju odločitve. V zgornjem primeru bi lahko dodali tudi, da če je posameznik star 18 let ali več, je upravičen in mora plačati vstopnico. Če niso, je vstop prost. Odločitev 'drugače' mora 'preskočiti' nekaj vozlišč in vsi ti koraki morajo biti prikazani v našem CFG.

Ko smo definirali svoj CFG, je zdaj čas, da preidemo na naslednji korak v postopku testiranja krmilnega toka, tj., Da določimo, v kolikšni meri bomo testirali kodo.

Določitev, koliko preizkusiti:

Koliko izvorne kode je treba preizkusiti? Bi morali preizkusiti vsako možno pot? Poskusiti zajeti vse poti v naših testih je praktično nemogoče. Moramo najti srednjo pot, da ugotovimo, koliko testiranja lahko opravimo.

Če rečemo, da želimo preizkusiti 50% naše kode, bi to lahko pomenilo, da bomo opredelili vse izvedljive stavke kode in jih preizkusili vsaj polovico. Vendar se tu postavlja vprašanje, 'ali moramo potem definirati vse možne izvedljive poti?'

To je spet praktično nemogoče. Boljši pristop je morda namenjen testiranju 50% poti, ki jih lahko prepoznamo v vsakem odseku kode.

Obstajajo različne stopnje pokritosti, in sicer pokrivanje izjav, podružnic in poti. Kasneje jih bomo na kratko pogledali.

Ustvarjanje testnih primerov:

Naslednji korak je ustvarjanje testnih primerov, ki jih bomo uporabili. Testni primeri pri strukturnih testiranjih temeljijo na naslednjih dejavnikih:

  • Izvršljivi stavki.
  • 'Odločitve', ki jih je treba sprejeti.
  • Možne poti, po katerih je mogoče slediti.
  • Pogoji, ki jih je treba izpolniti (ti so lahko večkratni ali logični).

Zgornji dejavniki nam dajejo predstavo o vrstah testnih primerov, ki jih moramo ustvariti. Uporabljamo lahko tudi orodje za ustvarjanje strukturnih testov. Če je naša koda v programskem jeziku C, lahko s pomočjo PathCrawler ustvarimo testno kodo. Drugo orodje, ki ga lahko uporabimo, je fMBT.

Izvajanje testnih primerov:

Tukaj moramo zagnati teste. Vnesemo lahko podatke ali podatke, da preverimo, kako se koda izvaja, in nato preverimo, ali dobimo pričakovane rezultate. Na primer v klic funkcije vnesite matriko, da opazite rezultate, ki jih dobimo po pregledu, ali da preverimo, ali odločitvene točke sprejemajo pravilne odločitve.

Analiza rezultatov:

V tem delu vse, kar naredimo, je preveriti, ali smo po izvedbi dobili pravilne rezultate. Na primer če vnesemo polje, kjer so vse vrednosti nad 18, potem bi morali imeti vse odločitvene točke, ki bi imele za posledico 'primerno'.

Predpostavke za nadzor pretoka

Pomembno je omeniti, da je za izvedbo preskusov kontrolnega pretoka podanih nekaj predpostavk. Tej vključujejo:

  • Prisotne so le napake, ki lahko vplivajo na nadzorni tok.
  • Vse spremenljivke, funkcije in elementi so natančno definirani.

Stopnje pokritosti v nadzornih tokovih

Kot smo že omenili, obstajajo različne stopnje pokritosti pri preskušanju nadzornega toka.

Oglejmo si jih na kratko.

# 1) Pokritost izjave

Pri strukturnem testiranju imajo izvršljivi stavki kode ključno vlogo pri odločanju o metodah načrtovanja testov.

Naš cilj je doseči 100-odstotno pokritost, kar pomeni, da je bila vsaka izvršljiva izjava vsaj enkrat preizkušena. Čim večja je pokritost, tem manj je verjetnosti, da bi pogrešali napake in napake.

Tu je treba uporabiti testne primere. Podatki, ki jih potrebujemo, so zagotoviti, da se vsak izvršljivi stavek v bloku kode izvede vsaj enkrat.

# 2) Pokritost podružnice

Ta raven pokritosti vključuje testiranje točk v podružnicah CFG (kjer se sprejemajo odločitve). Rezultati so logični. Tudi če je uporabljen stavek preklopa in obstaja več izidov, je v bistvu vsak blok primera primerjava para vrednosti.

Tako kot pri kritju izpisov bi si morali prizadevati za 100% pokritost poslovalnic. Da bi to dosegli, moramo vsaj enkrat preizkusiti vsak rezultat na vsaki ravni odločanja. Ker imamo opravka z logičnimi rezultati, bi si morali prizadevati za izvajanje vsaj dveh testov na odsek kode.

# 3) Pokritost poti

Ta raven pokritosti je bolj temeljita v primerjavi s pokritostjo odločitev in izjav. Cilj tukaj je 'odkriti' vse možne poti in jih vsaj enkrat preizkusiti. To je lahko zelo dolgotrajno. Lahko pa pomaga odkriti napake ali napake v naši kodi ali celo vidike, ki jih moramo definirati, na primer, uporabniški vnos.

Vrste strukturnih preskusov

Vrste strukturnih preskusov
(slika vir )

Preskušanje mutacij

Preskušanje mutacij je tehnika preskušanja, ki temelji na napakah, pri kateri se različne različice programske aplikacije preizkušajo glede na nabor podatkov.

>> Za podrobnejši pregled glejte to vadnico Preskus mutacije.

Preskus na osnovi rezin

Preskušanje na osnovi rezin (SBT) lahko definiramo kot tehniko preskušanja programske opreme, ki temelji na rezine - izvršljivi deli programa ali skupine izjav, ki vplivajo na nekatere vrednosti na določenih zanimivih točkah programa, na primer, deli, kjer so definirane spremenljivke, ali rezultat skupine stavkov.

Kako narediti rezanje

Primer rezanja v SBT: Koda za izpis parnih in neparnih številk (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}')

Preskušanje na osnovi rezin

Rezino lahko pogledate na dva načina: Z upoštevanjem poti spremenljivke, ki nas zanima, ali dela kode, ki vpliva na rezultat.

V našem primeru lahko, če pogledamo izhod neparnih števil, izsledimo del kode, ki nas vodi do tega izhoda.

V merilih rezanja, ki jih je podal Mark Weiser (ki je uvedel SBT), je rezina definirana po tej formuli: S (v, n) , kje, v se nanaša na zadevno spremenljivko ( na primer, kjer je definirana spremenljivka) in n je izjava o interesu ( na primer, kjer je podan izhod) in S pomeni rezino.

V zgornjem primeru, da dobimo rezino, začnemo z izhodom v vrstici 10, ki postane naša n . Naša spremenljivka je kje .

Naša merila za rezanje so torej:

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

Naša skrb so izjave, ki nas vodijo do rezultata.

To so:
10,9,8,4,3,1

Torej, naša rezina v tej kodi je:

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

Vrste preskusov na osnovi rezin

Obstajata dve vrsti SBT: statični in dinamični

# 1) Dinamično preskušanje na osnovi rezin

Zgornji primer SBT, kjer smo preučili izjave, ki vplivajo na tiskanje neparnih števil, je dinamični SBT. Naša skrb je zelo specifična. Osredotočiti se moramo le na tisto, kar neposredno vpliva na določen rezultat.

Izvedemo kodo in s testnimi podatki zagotovimo, da deluje, kot naj bi. Doseg bi lahko povečali na razpon (1,50), na primer, da bi ugotovili, ali še vedno ustvarja samo neparna števila. Dinamični SBT je znan tudi kot preverjanje veljavnosti.

# 2) StatičnoPreskus na osnovi rezin

Za razliko od Dynamic SBT je statično preskušanje osredotočeno na določeno spremenljivko. Če pomislimo na naš rezultat v zgornjem primeru kot kje , rezino, ki vpliva nanjo, lahko zasledimo kot 10,9,8,7,6,5,4,3,2,1

V bistvu gre za celoten blok kode! Tu preverimo, ali je koda pravilna glede skladnje in zahtev, in je ne izvajamo. Statični SBT je znan tudi kot verifikacijsko testiranje.

Pomembno je omeniti, da je dinamični SBT v primerjavi s statičnim kolegom 'manjši'. Je tudi bolj specifičen.

Najboljše prakse / smernice za preskušanje na osnovi rezin

Merila za rezanje je treba določiti z:

  • Izjave, pri katerih so vrednosti definirane ali jim je dodeljena vrednost, kot tudi prerazporejena vrednost.
  • Izjave, kjer vrednosti prejemajo zunaj programa, na primer, prek vnosa uporabnika.
  • Izjave, ki natisnejo izhodne / povratne izhodne podatke.
  • Zadnja izjava programa, na primer, funkcijski klic, ki lahko definira vrednosti ali podaja vrednosti argumentom

Prednosti preskusov na osnovi rezin vključujejo:

  • Ker v SBT delamo samo z določenimi interesnimi področji, olajšuje učinkovito ustvarjanje testnih zbirk.
  • Pot je definirana z odvisnostmi v kodi, kar je bolje kot uporaba pokritost poti.
  • S SBT lažje najdete napake v izvorni kodi.

Slabosti preskusov na osnovi rezin vključujejo:

  • Če pri testiranju velike kode uporabljamo dinamično testiranje, bomo potrebovali veliko računskih virov.
  • Če uporabimo statično preskušanje, bomo morda pogrešali napake.

Preskušanje pretoka podatkov

Preskušanje pretoka podatkov lahko definiramo kot tehniko preizkušanja programske opreme, ki temelji na vrednostih podatkov in njihovi uporabi v programu. Preveri, ali so bile podatkovne vrednosti pravilno uporabljene in ali ustvarjajo pravilne rezultate. Testiranje pretoka podatkov pomaga slediti odvisnostim med vrednostmi podatkov na določeni izvedbeni poti.

Anomalije pretoka podatkov

Anomalije pretoka podatkov so preprosto napake v programski opremi. Razvrščeni so v tipe 1, 2 in 3.

Poglobimo se vanje spodaj:

Tip 1: Spremenljivka je definirana in ji je dvakrat dodeljena vrednost.

Primer kode: Python

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

Tip1

Lst_1 je definiran in sta mu dodeljeni dve različni vrednosti. Prva vrednost se preprosto prezre. Zaradi nepravilnosti tipa 1 program ne uspe.

Tip 2: Vrednost spremenljivke se uporablja ali sklicuje nanjo, preden je definirana.

Primer kode: Python

for var in lst_1: print(var)

Tip 2

Zgornja zanka nima vrednosti za ponovitev. Nepravilnosti tipa 2 povzročajo neuspeh programa.

Tip 3: A podatkovna vrednost se ustvari, vendar se nikoli ne uporabi.

Primer kode: Python

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

Tip 3

Spremenljivka lst_2 ni bil sklican. Nepravilnosti tipa 3 morda ne bodo povzročile okvare programa.

Postopek preskušanja pretoka podatkov

Za opredelitev odvisnosti med vrednostmi podatkov moramo definirati različne poti, po katerih lahko sledimo v programu. Da bi to učinkovito naredili, se moramo sposoditi pri drugem tipu strukturnih preskusov, znanem kot preskušanje nadzora-pretoka .

Korak 1) Narišite graf kontrolnega toka

Narisati moramo graf krmilnega toka, ki je grafični prikaz poti, po katerih bi lahko sledili v našem programu.

Primer kode: 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)

Preskušanje pretoka podatkov

V zgornjem primeru kode mora član dobiti popust, če povabi obiskovalca.

Graf krmilnega pretoka (CFG):

Graf nadzornega toka

2. korak) Raziščite definicijo in uporabo spremenljivk in vrednosti podatkov.

Spremenljivka v programu je definirana ali uporabljena. V CFG imamo spremenljivke na vsakem vozlišču. Vsako vozlišče je poimenovano glede na vrsto spremenljivke, v kateri je. Če je spremenljivka definirana na določenem vozlišču, ustvari definirajoče vozlišče. Če je na vozlišču uporabljena spremenljivka, ustvari uporabniško vozlišče.

Če upoštevamo spremenljive stroške v CFG, so to vozlišča za določanje in uporabo:

VozliščeTipKoda
1. Definiranje vozliščastroški = 20
5. Uporabno vozliščeračun = strošek -1
7. Uporabno vozliščeračun = stroški

3. korak) Določite poti uporabe definicij.

Obstajata dve vrsti poti uporabe definicij: du poti in enosmerne poti. du poti so definicijske poti, ki se začnejo z definicijskim vozliščem in končajo z vozliščem za uporabo. To velja za pot v zvezi s spremenljivimi stroški zgoraj.

Primer poti enosmernega toka, poti jasne odločitve, je pot glede spremenljivke računa, kot je prikazano spodaj:

VozliščeTipKoda
5. Definiranje vozliščaračun = strošek -1
7. Definiranje vozliščaračun = stroški
8. Uporabno vozliščetisk (račun)

pot enosmernega toka ima več kot eno definicijsko vozlišče, čeprav se še vedno konča na vozlišču uporabe.

4. korak) Ustvarite preskusno zbirko.

To je dodajanje vnosa. Upoštevajte, da moramo imeti za vsako spremenljivko različen testni paket. Preizkusni paket nam bo pomagal prepoznati nepravilnosti pretoka podatkov.

Vrste preskušanja podatkovnega toka

Obstajata dve vrsti - Statično in dinamično .

Statično pomeni, da gremo skozi kodo in CFG, da ugotovimo nepravilnosti podatkov, ne da bi jih izvedli. Dinamično pomeni, da dejansko identificiramo določene poti in nato ustvarimo testne pakete, da jih preizkusimo, da bi ujeli anomalije, ki smo jih morda zamudili med statičnim preskušanjem.

Prednosti in slabosti testiranja pretoka podatkov:

  • Testiranje pretoka podatkov je idealno za prepoznavanje nepravilnosti pretoka podatkov, zaradi česar je zelo učinkovita metoda strukturnega testiranja.
  • Njegova slaba stran je, da je treba dobro poznati jezik, ki se uporablja za pisanje kode, da bi lahko uporabil testiranje pretoka podatkov. Prav tako je zamudno.

Prednosti in slabosti strukturnih preskusov

Poglejmo zdaj razloge, zakaj je strukturno preskušanje odličen pristop, in raziščimo tudi nekaj njegovih slabosti.

Prednosti:

  • Omogoča temeljito testiranje kode, kar povzroči minimalne napake. Strukturno preskušanje daje prostor za temeljito preizkušanje programske opreme. Različne stopnje pokritosti - izjava za izjavo, vsaka točka odločitve in pot so namenjene doseganju 100% pokritosti, kar močno zmanjša možnosti, da napake ostanejo neodkrite.
  • Sposobnost avtomatizacije . Obstaja več orodij, s katerimi lahko avtomatiziramo testiranje. To nam bo pomagalo doseči največjo pokritost kode in v krajšem času v primerjavi z ročnim testiranjem.
  • Posledica je višja kakovostna koda . Razvijalci imajo priložnost preučiti strukturo in izvedbo kode in odpraviti morebitne napake ter izboljšati te vidike. Omogoča nam, da imamo v mislih veliko strukturo, ko pišemo nadaljnje dele kode ali izvajamo preostale funkcije.
  • To je mogoče izvesti v vsaki fazi SDLC - Strukturna testiranja je mogoče izvesti v vsaki fazi SDLC, ne da bi čakali, da se razvoj dokonča 100%. To olajša prepoznavanje napak v zgodnji fazi in s tem prihrani veliko časa v primerjavi s testiranjem po zaključku razvoja.
  • Pomaga znebiti mrtve kode . To lahko razumemo kot 'dodatno' ali nepotrebno kodo, na primer, koda, ki bo izračunala rezultat, vendar ga nikoli ne bo uporabila v nobenem od naslednjih izračunov.
  • Učinkovitost - Ker so razvijalci, ki pišejo kodo, isti tisti, ki jo preizkušajo, ni treba vključevati drugih ljudi, kot je QA.

Slabosti:

  • Razvijalci, ki izvajajo strukturno testiranje, morajo temeljito razumeti jezik . Drugi razvijalci in skrbniki za kakovost, ki ne poznajo jezika, si ne morejo pomagati pri testiranju.
  • Časovno in denarno lahko postane precej drago . Za učinkovito testiranje je potrebno veliko časa in sredstev.
  • Povzroča zamude pri dostavi funkcij . Razlog za to je, da razvijalce od preizkušanja gradijo programska oprema.
  • Skaliranje je težava, zlasti kadar gre za velike aplikacije . Velika aplikacija je enaka prevelikemu številu poti, ki jih je treba prehoditi. Doseči 100% pokritost postane nemogoče.
  • Morda bodo zamujeni primeri in poti , na primer, v primeru, da funkcije niso v celoti razvite ali pa jih še ni treba razviti. To pomeni, da ga je treba kombinirati z drugimi vrstami testiranja, kot je testiranje zahtev (kjer preverjamo, ali so določene funkcije, ki jih je bilo treba zgraditi).

Najboljše prakse strukturnega preskušanja

Nekateri dejavniki, ki zahtevajo pozornost pri izvajanju strukturnih preskusov, so naslednji:

  • Jasno označite in poimenujte teste . Če mora kdo drug izvajati teste, jih mora biti enostavno najti.
  • Preden izboljšate kodo, torej z njeno refaktoring in optimizacijo za uporabo v različnih okoljih, zagotovite, da sta njena struktura in pretok idealna.
  • Zaženite teste ločeno . Na ta način je enostavno prepoznati napake in jih odpraviti. Po drugi strani pa je manj verjetno, da bomo pogrešali napake ali poti zaradi prekrivanja v odsekih, blokih ali poteh kode.
  • Pred spremembami ustvarite teste . Preskusi se morajo izvajati po pričakovanjih. Na ta način, če se kaj pokvari, je težavo enostavno izslediti in odpraviti.
  • Naj bodo testi za vsak odsek ali blok kode ločeni . Na ta način, če pride do sprememb po vrsti, nam ni treba spreminjati veliko testov.
  • Odpravite napake, preden nadaljujete s testiranjem . Če prepoznamo kakršne koli napake, jih je bolje odpraviti, preden nadaljujemo s testiranjem naslednjega odseka ali bloka kode.
  • Nikoli ne izpustite strukturnih preskusov s predpostavko, da bo QA 'vseeno opravil preskušanje'. Tudi če se napake na začetku zdijo nepomembne, lahko kumulativno povzročijo kodo napake, ki nikoli ne bo mogla doseči predvidenega namena.

Pogosta vprašanja za strukturno testiranje

Tukaj bomo raziskali pogosto zastavljena vprašanja, ko gre za strukturno testiranje.

V # 1) Kakšna je razlika med funkcionalnim in strukturnim preskušanjem?

Odgovor: Funkcionalno preizkušanje je vrsta preizkušanja programske opreme, ki temelji na določenih zahtevah v SRS (Software Requirements Specifications). Običajno se to stori tako, da se ugotovijo razlike med specifikacijami v SRS in načinom delovanja kode. Strukturno preskušanje temelji na notranji strukturi kode in njeni izvedbi. Potrebno je temeljito razumevanje kode.

V # 2) Katere so vrste strukturnih preskusov?

Odgovori vrste vključujejo:

  • Testiranje pretoka podatkov
  • Preskus mutacije
  • Preskušanje krmilnega pretoka
  • Preskušanje na osnovi rezin

V # 3) Kaj je primer strukturnega preskušanja?

Odgovor: Tu je primer, ki prikazuje pokritost izjav:

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

Količina kritja, ki jo dobimo, je odvisna od testnih podatkov, ki jih posredujemo kot vhodne podatke (ali izpolnjuje pogoje vsota> 0).

V # 4) Kakšna je razlika med testiranjem pretoka podatkov in nadzornim pretokom?

Odgovor: Tako preskušanje pretoka podatkov kot preskušanje pretoka podatkov uporabljata grafe pretoka nadzora. Edina razlika je v tem, da se pri testiranju nadzornega pretoka osredotočimo na poti, ustvarjene iz kode, medtem ko se pri testiranju pretoka podatkov osredotočimo na vrednosti podatkov, njihovo definicijo in uporabo znotraj poti, opredeljenih v programu.

V # 5) Za kaj se uporablja testiranje pretoka podatkov?

Odgovor: Testiranje pretoka podatkov je idealno za ugotavljanje nepravilnosti pri uporabi podatkovnih vrednosti znotraj poti v grafu nadzornega toka, na primer, ena spremenljivka, ki ji je bila dvakrat dodeljena vrednost, spremenljivka, ki je bila definirana in ni bila uporabljena, ali spremenljivka, ki je bila uporabljena ali sklicana in ni definirana.

V # 6) Kakšna je razlika med rezanjem in rezanjem na kocke pri testiranju programske opreme?

Odgovor: Rezanje pomeni osredotočanje na določene izjave o zanimanju v programu in ignoriranje ostalih. Kockanje je, ko prepoznamo rezino z napačnim vnosom in jo nato še narežemo, da sledimo pravilnemu vedenju.

V # 7) Kakšna je razlika med testiranjem mutacij in pokritostjo kode?

Odgovor: Pri mutacijskem testiranju štejemo število pokončanih mutantov kot odstotek vseh mutantov. Pokritost kode je preprosto količina kode, ki je bila preizkušena v programu.

Zaključek

V tej vadnici smo podrobno preučili strukturno testiranje - kaj je, kaj ni, kako se lotiti, vrste pokritosti, prednosti in slabosti, najboljše prakse in celo nekatera pogosta vprašanja glede te vrste testiranja programske opreme.

Še veliko več je, da se lahko naučimo o strukturnih testiranjih. V prihodnjih vajah bomo raziskali pokritost kode (izjava, odločitev, veja in pot), vrste strukturnih preskusov (mutacije, pretok podatkov in rezine) in celo orodja, s katerimi lahko avtomatiziramo te preskusne procese.

Pomembno je omeniti, da ni nobenega tipa ali pristopa, ki bi bil 100% učinkovit. Vedno je priporočljivo kombinirati različne vrste testiranja in pristope.

Na primer strukturno preskušanje močno dopolnjujejo preskušanje zahtev, saj lahko obstajajo lastnosti, ki v času izvajanja strukturnih preskusov morda niso bile razvite.

Tehnike strukturnega testiranja temeljijo na napakah, ki jih povzročajo človeški programerji pri pisanju kode. Predpostavlja se, da je programer strokovnjak in ve, kaj kodira, vendar se občasno zmoti.

Različne vrste strukturnih preskusov, ki smo jih preučevali - preskušanje mutacij, preskušanje na osnovi rezin in testiranje pretoka podatkov je mogoče izslediti do napak, kot je uporaba napačnega operaterja (testiranje mutacije) ali sklicevanje na spremenljivko pred uporabo (preskušanje pretoka podatkov) .

Priporočeno branje

^