Meni

Vodič za strukturno ispitivanje - što je strukturno ispitivanje

  • Glavni
  • Ostalo
  • Vodič za strukturno ispitivanje - što je strukturno ispitivanje

structural testing tutorial what is structural testing

Isprobajte Naš Instrument Za Uklanjanje Problema

Ovaj sveobuhvatni vodič za strukturno ispitivanje objašnjava što je strukturno ispitivanje, njegove vrste, što je ispitivanje kontrolnog protoka i graf kontrolnog protoka, razine pokrivenosti itd.:

Brzo traženje nekih najskupljih softverskih grešaka na Google-u napustilo me je u glavi - 500 milijardi dolara. Da, to je koliko skupa programska pogreška može biti skupa. Čitati bilo što vezano uz izgubljene živote u prometnoj i zdravstvenoj industriji zbog programske greške također može biti užasavajuće.

Iako pogreške u kodu nisu uvijek toliko ekstremne kada uključuju gubitak obilnog novca i života, jedino ključno iznošenje koje ovdje pokušavamo prenijeti jest da se ne može previdjeti testiranje.

Ispitivanje konstrukcije

Kada se testiranje obavlja često tijekom SDLC-a, omogućuje nam hvatanje programskih pogrešaka kojima bi trebalo puno više vremena za otklanjanje nakon isporuke proizvoda.

Ono što je važno su odabrane vrste testiranja softvera. Postoji nekoliko takvih, uključujući funkcionalno, strukturno i ispitivanje temeljeno na promjenama.

Ovaj vodič također objašnjava vrste strukturnih ispitivanja. Doznajte kako detaljno izvesti testiranje mutacija, testiranje na presjecima, ispitivanje protoka podataka s primjerima i objašnjenjima.

Što ćete naučiti:

Zašto je testiranje softvera važno

Osim uštede novca i izbjegavanja katastrofa poput gore spomenutih slučajeva, postoji još nekoliko razloga koji opravdavaju važnost testiranja.

U nastavku su navedeni neki od razloga:

# 1) Osigurati ispunjavanje propisanih zahtjeva prije početka izrade projekta. Dionici (na primjer, programeri i klijenti) moraju se složiti o svim aspektima rješenja / proizvoda / softvera potrebnih za izgradnju projekta.

Testiranje uključuje provjeru jesu li ispunjeni softverski zahtjevi. Programer ili tvrtka uključena u izgradnju rješenja također stječu dobru reputaciju jer su dizajnirali tako visokokvalitetno rješenje kojim upravlja eclat kod.

# 2) Potvrđuje da funkcija koda radi kako je predviđeno. Testiranje također uključuje provjeru funkcionalnosti softvera, a u slučaju bilo kakve neispravnosti to bi trebalo popraviti tijekom ranih faza SDLC (životni ciklus razvoja softvera).

# 3) Provjerava performanse: Na primjer, kako bi se identificiralo ukupno vrijeme proteklo tijekom pokretanja koda. Ako upotrijebimo nekoliko Za petlje u našem će kodu trebati puno vremena dok se ne dobije željeni izlaz, a ponekad može čak i vremensko ograničenje.

# 4) Pomaže u postizanju boljeg korisničkog iskustva. Korisnici neće uživati ​​u korištenju softvera koji kvari, kvari ili je 'prespor'. Korisnici će vjerojatno postati nestrpljivi i odbaciti se pomoću softvera. Testiranje nam daje bolju priliku za osiguravanje da korisnici mogu lako koristiti naše proizvode.

# 5) Provjerava skalabilnost. Programer bi trebao težiti izradi softvera koji se može prilagoditi.

# 6) Provjerava ranjivosti u kodu. Testiranje nam omogućuje priliku da pripazimo na sigurnosne ranjivosti, Na primjer, kod koji može ugroziti PII (Podaci koji mogu osobno identificirati) što je visoki prioritet za GDPR.

U ovom ćemo se članku usredotočiti na jednu vrstu testiranja, tj. Ispitivanje konstrukcije . Kao što i samo ime govori, to ima veze sa strukturom koda. To se razlikuje od onoga što smo ranije spomenuli da testiranje pomaže u određivanju aspekata poput performansi koda, funkcionalnosti i sigurnosti.

Strukturno ispitivanje protiv ostalih vrsta ispitivanja

Postoji mnogo vrsta testiranja softvera. Međutim STOP (Međunarodni odbor za kvalificiranje testiranja softvera), definira 4 glavne vrste testiranja softvera, naime

  • Funkcionalni
  • Nefunkcionalan
  • Strukturne
  • Na temelju promjena

Razlike se mogu objasniti na sljedeći način:

Funkcionalno ispitivanje: To uključuje provjeru funkcionalnosti softvera prema utvrđenim zahtjevima. Podaci testa koriste se kao ulaz. Također provjeravamo je li dati izlaz očekivan.

Nefunkcionalno ispitivanje : To uključuje postupak testiranja kako bi se analiziralo kako softver funkcionira, na primjer, broj korisnika s kojima istovremeno može postupati.

Ispitivanje konstrukcije: Ova vrsta testiranja temelji se na strukturi koda. Na primjer, ako je kod namijenjen izračunu prosjeka parnih brojeva u nizu, tada bi ispitivanje temeljeno na strukturi bilo zainteresirano za 'korake koji vode do izračunavanja prosjeka', a ne da li je konačni rezultat točna numerička vrijednost.

Pretpostavimo da moramo provjeriti jesmo li definirali kod koji razlikuje parne brojeve od neparnih. Ovdje možemo imati uvjetnu izjavu, na primjer, ako je element niza djeljiv s dva bez ostatka, ako (arr (i)% 2 === 0) tada se broj može reći kao paran broj.

Strukturno ispitivanje provode isti ljudi koji pišu kod onako kako ga najbolje razumiju.

Ispitivanje temeljeno na promjenama : To uključuje testiranje učinaka izmjena koda, a zatim osiguravanje da su izvršene promjene izvršene. Također osigurava da ga promjene koda ne slome.

Što strukturno ispitivanje nije

Ranije smo spomenuli da se ispitivanje temeljeno na strukturi odnosi na strukturu koda. Imajte na umu da se ovdje bavimo stvarnim kodom. Ne provjeravamo zahtjeve niti čak testiramo ulaze u odnosu na očekivane izlaze. U ovom se trenutku ne bavimo funkcionalnošću, korisničkim iskustvom ili čak izvedbom.

Što je strukturno ispitivanje

Stoga se ispitivanje temeljeno na strukturi može definirati kao vrsta softverskog testiranja koje testira strukturu koda i predviđene tokove. Na primjer, provjera stvarnog koda za aspekte poput ispravne provedbe uvjetnih izjava i je li svaka izjava u kodu ispravno izvršena. Također je poznato kao ispitivanje temeljeno na strukturi.

Da bismo izvršili ovu vrstu testiranja, moramo temeljito razumjeti kôd. Zbog toga ovo testiranje obično rade programeri koji su napisali kôd kako ga najbolje razumiju.

Kako izvršiti strukturno ispitivanje

Da bismo testirali različite aspekte koda, prvo moramo razumjeti tokove upravljanja.

Ispitivanje kontrolnog protoka

Ovo je izvođenje testova iz kontrolnih tijekova koda (redoslijed u kojem se implementiraju izrazi, funkcije i različiti aspekti koda).

Postupak ispitivanja kontrolnog protoka:

Grafikon protoka upravljanja

Proces kontrolnog toka započinje stvaranjem vizualnog prikaza različitih odjeljaka koda koji nam pomažu u definiranju putova kojima se može slijediti tijekom izvršavanja.

Ovi vizualni prikazi poznati su kao Grafikoni protoka (CFG) i imaju nekoliko komponenata poput čvorova, rubova, staza, spojeva i točaka odlučivanja. Grafikon se može stvoriti ručno ili automatski, gdje se softver koristi za izdvajanje grafa iz izvornog koda.

Pogledajmo ove komponente u nastavku:

Čvorovi i rubovi

# 1) Procesni blok

Ovaj se dio koristi za predstavljanje dijela koda koji se izvršava uzastopno. To znači da se svaki put izvršava na isti način i da nema odluka ili ‘razgranavanja’ koje treba učiniti. Sastoji se od čvorova s ​​jednim ulaznim i izlaznim putem.

Primjer bloka procesa:

Blok procesa

(slika izvor )

Procesni blok nije bitan dio kontrolnog toka i kao rezultat toga treba ga testirati samo jednom.

# 2) Točke odluke

Ovo su neke ključne komponente u tijeku upravljanja kodom. Unutar tih čvorova donose se odluke. To se obično radi uspoređivanjem i mijenja se kontrolni tok, ovisno o odluci. Ovaj dio CFG-a sastoji se od jednog čvora s najmanje 2 izlaza.

Ovdje donesena odluka mogla bi biti uvjetni iskazi poput, if-else izraza (koji imaju dva moguća izlaza) i case (koji mogu imati više od dva izlaza).

CFG

(slika izvor )

U gornjem dijagramu nalazi se točka odluke (iz uvjetne 'dob = 18') nakon koje slijede opcije 'da' ili 'ne'.

# 3) Spojne točke

Iz gornjeg dijagrama možemo lako prepoznati točke spoja gdje se spajaju točke odluke. Spojne točke mogu imati mnogo ulaznih putova, ali mogu imati samo jedan izlazni put.

Najbolje prakse u grafovima protoka upravljanja:

Postoji nekoliko stvari na koje treba obratiti pažnju prilikom izrade grafikona protoka upravljanja:

  • Pokušajte što je više moguće kako bi CFG bio jednostavan. To možemo učiniti kombiniranjem dijelova koji se mogu smatrati ‘manje značajnima’, na primjer, procesni blokovi.
  • Osigurajte da se na mjestima odlučivanja donese samo jedna odluka. U složenijim CFG-ima postoje ‘posljedice’ koje dolaze nakon donošenja odluke. U našem gore navedenom primjeru mogli bismo dodati i da ako pojedinac ima 18 godina ili više, tada ispunjava uvjete i mora platiti kartu. Ako nisu, tada je ulaz besplatan. Odluka ‘ostalo’ treba ‘preskočiti’ nekoliko čvorova, a svi ti koraci moraju biti prikazani u našem CFG-u.

Nakon što smo definirali svoj CFG, vrijeme je da prijeđemo na sljedeći korak u procesu ispitivanja kontrolnog toka, tj. Da definiramo u kojoj ćemo mjeri testirati kôd.

Određivanje količine za testiranje:

Koliki dio izvornog koda treba testirati? Trebamo li testirati svaki mogući put? Pokušaj pokrivanja svih putova u našim testovima je praktički nemoguć. Moramo pronaći sredinu kako bismo utvrdili koliko testiranja možemo obaviti.

Ako kažemo da nam je cilj testirati 50% našeg koda, to bi moglo značiti da ćemo definirati sve izvršne naredbe koda i težiti testiranju barem polovice njih. Međutim, pitanje koje se ovdje postavlja je 'trebamo li onda definirati sve moguće izvršne staze?'

To bi opet moglo biti praktički nemoguće. Bolji pristup mogao bi biti usmjeren na testiranje 50% putova koje možemo prepoznati u svakom odjeljku koda.

Postoje različite razine pokrivenosti, naime izvještaj, grana i pokrivenost puta. Ukratko ćemo ih pogledati kasnije.

Izrada test slučajeva:

Sljedeći je korak stvaranje testnih slučajeva koje ćemo koristiti. Ispitni slučajevi u ispitivanjima temeljenim na strukturi temelje se na sljedećim čimbenicima:

  • Izvršne izjave.
  • 'Odluke' koje treba donijeti.
  • Mogući putovi kojima se može ići.
  • Uvjeti koje treba ispuniti (oni mogu biti višestruki ili logički).

Gore navedeni čimbenici daju nam predodžbu o vrstama testnih slučajeva koje moramo stvoriti. Također se možemo poslužiti alatom za generiranje strukturnih ispitivanja. Ako je naš kod na programskom jeziku C, možemo koristiti PathCrawler za generiranje testnog koda. Drugi alat koji možemo koristiti je fMBT.

Izvršenje test slučajeva:

Evo, moramo pokrenuti testove. Možemo unijeti unos ili podatke kako bismo provjerili kako ga kôd izvršava, a zatim provjeriti dobivamo li očekivane rezultate. Na primjer, unesite niz u poziv funkcije kako biste primijetili rezultate koje dobivamo nakon prolaska kroz njega ili provjerili donose li odluke odluke ispravne odluke.

Analiza rezultata:

U ovom dijelu sve što radimo je provjeriti da li nakon izvršenja dobivamo točne rezultate. Na primjer, ako unesemo niz u kojem su sve vrijednosti iznad 18, tada bismo trebali imati sve točke odluke koje rezultiraju 'prihvatljivim'.

Pretpostavke o kontroli protoka

Važno je napomenuti da je za provođenje kontrolnog ispitivanja protoka napravljeno nekoliko pretpostavki. To uključuje:

  • Prisutne su samo one pogreške koje mogu utjecati na protok kontrole.
  • Sve su varijable, funkcije i elementi točno definirani.

Razine pokrivenosti u kontrolnim tokovima

Kao što smo ranije spomenuli, postoje različite razine pokrivenosti u ispitivanju kontrolnog protoka.

Pogledajmo ih ukratko.

# 1) Obuhvat izvještaja

U strukturnom testiranju, izvršni izrazi koda igraju vitalnu ulogu kada je riječ o odlučivanju o metodama dizajniranja testova.

Cilj nam je postići 100% pokrivenost, što znači da je svaka izvršna izjava testirana barem jednom. Što je veća pokrivenost, to je manja vjerojatnost da će propustiti bugove i pogreške.

Ovdje je potrebno koristiti testove. Podaci koje koristimo trebaju osigurati da se svaki izvršni izraz u bloku koda izvrši barem jednom.

# 2) Pokrivenost podružnice

Ova razina pokrivenosti uključuje ispitivanje bodova u podružnicama CFG-a (gdje se donose odluke). Ishodi su logički. Čak i ako se koristi naredba switch i postoji više ishoda, u osnovi je svaki blok slučaja usporedba para vrijednosti.

Kao i kod pokrivanja izvoda, i mi bismo trebali težiti 100% pokrivenosti poslovnica. Da bismo to postigli, moramo barem jednom testirati svaki ishod na svakoj razini odluke. Budući da imamo posla s logičkim ishodima, tada bismo trebali težiti izvođenju najmanje 2 testa po odjeljku koda.

# 3) Pokrivenost puta

Ova razina pokrivenosti temeljitija je u usporedbi s pokrićem odluka i izjava. Cilj je ovdje ‘otkriti’ sve moguće putove i testirati ih barem jednom. To može biti izuzetno dugotrajno. Međutim, to može pomoći u otkrivanju grešaka ili pogrešaka u našem kodu, ili čak aspekata koje moramo definirati, na primjer, unos korisnika.

Vrste strukturnih ispitivanja

Vrste strukturnih ispitivanja
(slika izvor )

Ispitivanje mutacija

Ispitivanje mutacija tehnika je ispitivanja zasnovana na greškama u kojoj se ispituju različite varijacije softverske aplikacije u odnosu na skup podataka ispitivanja.

>> Pogledajte ovaj vodič za detaljniji uvid Ispitivanje mutacije.

Ispitivanje na osnovi kriški

Testiranje na temelju kriška (SBT) može se definirati kao tehnika softverskog testiranja koja se temelji na kriške - izvršni dijelovi programa ili skupine izjava koji utječu na neke vrijednosti u određenim točkama interesa programa, na primjer, dijelovi gdje su definirane varijable ili izlaz grupe izraza.

Kako napraviti rezanje

Primjer rezanja u SBT-u: Kôd za ispis parnih i neparnih brojeva (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}')

Ispitivanje na osnovi kriški

Dva su načina da pogledate krišku: Slijedeći put varijable od interesa ili dijela koda koji utječe na izlaz.

U našem primjeru, ako pogledamo izlaz neparnih brojeva, možemo pratiti dio koda koji nas vodi do ovog izlaza.

U kriterijima za rezanje koje je dao Mark Weiser (koji je uveo SBT), kriška se definira pomoću ove formule: S (v, n) , gdje, v odnosi se na dotičnu varijablu ( na primjer, gdje je definirana varijabla), i n je izjava o interesu ( na primjer, gdje se daje izlaz), i S stoji kriška.

U gornjem primjeru, da bismo dobili krišku, započinjemo s našim izlazom na retku 10, koji postaje naš n . Naša varijabla je gdje .

Dakle, naš kriterij za rezanje je:

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

Naša briga su izjave koje nas vode do rezultata.

Ovi su:
10,9,8,4,3,1

Dakle, naš dio u ovom kodu 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 ispitivanja na osnovi kriški

Postoje dvije vrste SBT-a: statički i dinamički

# 1) Dinamično testiranje na osnovi kriški

Gore objašnjeni primjer SBT-a gdje smo gledali izjave koje utječu na ispis neparnih brojeva je dinamički SBT. Naša je briga vrlo specifična. Moramo se usredotočiti samo na ono što izravno utječe na određeni rezultat.

Izvršavamo kôd i koristimo testne podatke kako bismo osigurali da radi kako treba. Mogli bismo povećati raspon na raspon (1,50), na primjer, kako bi se vidjelo generira li i dalje samo neparne brojeve. Dinamički SBT poznat je i pod nazivom provjera valjanosti.

# 2) StatičkiIspitivanje na osnovi kriški

Za razliku od Dynamic SBT, fokus statičkog ispitivanja je na određenoj varijabli. Ako o našem rezultatu u gornjem primjeru razmišljamo kao gdje , krišku koja utječe na nju možemo pratiti kao 10,9,8,7,6,5,4,3,2,1

To je u osnovi cijeli blok koda! Ovdje provjeravamo je li kod ispravan u smislu sintakse i zahtjeva i ne izvršavamo ga. Statički SBT poznat je i kao verifikacijsko testiranje.

Važno je napomenuti da je dinamički SBT 'manji' u usporedbi sa svojim statičkim kolegom. Također je specifičniji.

Najbolje prakse / smjernice testiranja na osnovi kriški

Kriteriji za rezanje trebaju biti određeni:

  • Izjave u kojima su vrijednosti definirane ili im je dodijeljena vrijednost, kao i preraspodijeljena vrijednost.
  • Izjave u kojima se vrijednosti primaju izvan programa, na primjer, putem korisničkog unosa.
  • Izjave koje ispisuju izlazni / povratni izlaz.
  • Posljednja izjava programa, na primjer, poziv funkcije koji može definirati vrijednosti ili pružiti vrijednosti argumentima

Prednosti testiranja na osnovi kriški uključuju:

  • Budući da u SBT-u radimo samo s određenim područjima interesa, to olakšava učinkovito generiranje ispitnih paketa.
  • Put je definiran ovisnostima unutar koda, što je bolje nego koristiti pokrivenost puta.
  • Pomoću SBT-a lakše je pronaći pogreške u izvornom kodu.

Nedostaci testiranja na osnovi kriški uključuju:

  • Ako koristimo dinamičko testiranje kada testiramo veliku bazu koda, trebat će nam puno računarskih resursa.
  • Ako koristimo statičko testiranje, mogli bismo propustiti pogreške.

Ispitivanje protoka podataka

Testiranje protoka podataka može se definirati kao tehnika softverskog testiranja koja se temelji na vrijednostima podataka i njihovoj upotrebi u programu. Provjerava jesu li vrijednosti podataka pravilno korištene i generiraju li točne rezultate. Testiranje protoka podataka pomaže u praćenju ovisnosti između vrijednosti podataka na određenom putu izvođenja.

Anomalije protoka podataka

Anomalije protoka podataka jednostavno su pogreške u softverskom programu. Podijeljeni su u tipove 1, 2 i 3.

Udubimo se u njih u nastavku:

Tip 1: Varijabla je definirana i vrijednost joj se dodjeljuje dva puta.

Primjer koda: Python

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

Tip1

Lst_1 definiran je i dodijeljene su mu dvije različite vrijednosti. Prva se vrijednost jednostavno zanemaruje. Anomalije tipa 1 ne uzrokuju neuspjeh programa.

Tip 2: Vrijednost varijable koristi se ili se na nju upućuje prije nego što se definira.

Primjer koda: Python

for var in lst_1: print(var)

Tip 2

Gornja petlja nema vrijednosti za ponavljanje. Anomalije tipa 2 uzrokuju neuspjeh programa.

Tip 3: A generira se vrijednost podataka, ali se nikad ne koristi.

Primjer koda: Python

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

Tip 3

Varijabla lst_2 nije referenciran. Anomalije tipa 3 možda neće uzrokovati neuspjeh programa.

Postupak ispitivanja protoka podataka

Da bismo definirali ovisnosti između vrijednosti podataka, moramo definirati različite putove kojima se može slijediti u programu. Da bismo to učinkovito učinili, moramo posuditi od druge vrste strukturnih ispitivanja poznate kao ispitivanje kontrolnog protoka .

Korak 1) Nacrtajte graf kontrolnog toka

Moramo nacrtati graf kontrolnog toka, koji je grafički prikaz putova koje bismo mogli slijediti u našem programu.

Primjer koda: 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)

Ispitivanje protoka podataka

U gornjem primjeru koda, član bi trebao dobiti popust ako pozove posjetitelja.

Grafikon kontrolnog protoka (CFG):

Grafikon protoka upravljanja

Korak 2) Istražite definiciju i upotrebu varijabli i vrijednosti podataka.

Varijabla u programu je ili definirana ili se koristi. U CFG-u imamo varijable na svakom čvoru. Svaki čvor imenuje se prema vrsti varijable u kojoj se nalazi. Ako je varijabla definirana na određenom čvoru, ona stvara čvor koji definira. Ako se varijabla koristi na čvoru, ona stvara čvor upotrebe.

Ako uzmemo u obzir varijabilne troškove u CFG-u, ovo su čvorovi za definiranje i upotrebu:

pitanja razgovora za službu za pomoć na razini 1
ČvorTipKodirati
1 Definirajući čvortrošak = 20
5 Upotrebni čvorračun = trošak -1
7 Upotrebni čvorračun = trošak

Korak # 3) Definirajte putove korištenja definicije.

Postoje dvije vrste putanja korištenja definicije: du staze i dc staze. du staze su staze definicije koje započinju čvorom definicije i završavaju čvorom upotrebe. To je slučaj za put koji se odnosi na gornju varijabilnu cijenu.

Primjer jednosmjerne putanje, putanje jasne odluke je put s obzirom na varijablu računa kao što je dolje prikazano:

ČvorTipKodirati
5 Definirajući čvorračun = trošak -1
7 Definirajući čvorračun = trošak
8 Upotrebni čvorispis (račun)

dc put ima više od jednog čvora definicije, iako još uvijek završava na uporabnom čvoru.

Korak # 4) Stvorite testni paket.

Ovo je dodavanje unosa. Napominjemo da za svaku varijablu trebamo imati različit paket za testiranje. Programski paket pomoći će nam identificirati anomalije protoka podataka.

Vrste ispitivanja protoka podataka

Postoje dvije vrste - Statički i dinamički .

Statički znači da prolazimo kroz kôd i CFG kako bismo identificirali anomalije podataka, bez izvršenja. Dinamično znači da zapravo identificiramo određene staze, a zatim stvaramo ispitne pakete kako bismo ih testirali u pokušaju da 'uhvatimo' anomalije koje smo možda propustili tijekom statičkog testiranja.

Prednosti i nedostaci ispitivanja protoka podataka:

  • Ispitivanje protoka podataka idealno je za identificiranje anomalija protoka podataka, što ga čini vrlo učinkovitom metodom strukturnog ispitivanja.
  • Loša mu je strana što postoji potreba za dobro poznavanjem jezika koji se koristi za pisanje koda kako bi se koristilo testiranje protoka podataka. Također je dugotrajan.

Prednosti i nedostaci ispitivanja konstrukcija

Pronađimo sada razloge zašto je ispitivanje konstrukcija izvrstan pristup i istražimo i neke njegove nedostatke.

Prednosti:

  • Omogućuje temeljito testiranje koda, što rezultira minimalnim pogreškama. Testiranje temeljeno na strukturi daje prostor za temeljito testiranje softvera. Različite razine pokrivenosti - izjava po izjava, svaka točka odluke i put imaju za cilj postizanje 100% pokrivenosti što uvelike smanjuje šanse da greške ostanu neotkrivene.
  • Sposobnost automatizacije . Postoji nekoliko alata koje možemo koristiti za automatizaciju testiranja. To će nam pomoći da postignemo maksimalnu pokrivenost koda i za kraće vrijeme u usporedbi s ručnim testiranjem.
  • To rezultira kvalitetnijim kodom . Programeri imaju priliku proučiti strukturu i implementaciju koda i ispraviti sve pogreške, kao i poboljšati ove aspekte. Omogućuje nam da imamo na umu sjajnu strukturu dok pišemo sljedeće dijelove koda ili implementiramo preostale značajke.
  • To se može učiniti kroz svaku fazu SDLC-a - Strukturna ispitivanja mogu se provesti u svakoj fazi SDLC-a bez čekanja da se razvoj završi 100%. To olakšava prepoznavanje pogrešaka u ranoj fazi i tako štedi puno vremena u usporedbi s testiranjem nakon završetka razvoja.
  • Pomaže u uklanjanju mrtvog koda . To se može smatrati 'dodatnim' ili nepotrebnim kodom, na primjer, kod koji će izračunati rezultat, ali ga nikada ne koristi u bilo kojem od sljedećih izračuna.
  • Učinkovitost - Budući da su programeri koji pišu kôd isti oni koji ga testiraju, nema potrebe za uključivanjem drugih ljudi poput QA-a.

Mane:

  • Programeri koji provode testiranje temeljeno na strukturi moraju temeljito razumjeti jezik . Ostali programeri i provjere kvalitete koji nisu dobro upućeni u jezik ne mogu pomoći u testiranju.
  • Vremenski i novčano može postati prilično skupo . Za učinkovito testiranje potrebno je puno vremena i resursa.
  • To uzrokuje kašnjenja u isporuci značajki . To je zato što su programeri povučeni iz softvera za izgradnju da bi testirali.
  • Skaliranje je problem, posebno tamo gdje su uključene velike aplikacije . Velika aplikacija jednaka je pretjerano velikom broju ruta koje treba proći. Postizanje 100% pokrivenosti postaje nemoguće.
  • Možda postoje propušteni slučajevi i rute , na primjer, u slučaju kada značajke nisu u potpunosti razvijene ili tek trebaju biti razvijene. To znači da ga treba kombinirati s drugim vrstama ispitivanja, poput ispitivanja zahtjeva (gdje provjeravamo da li postoje određene značajke koje je trebalo izgraditi).

Najbolje prakse za strukturno ispitivanje

Neki od čimbenika koji zahtijevaju pažnju tijekom provođenja ispitivanja temeljenih na strukturi su sljedeći:

  • Jasno označite i imenujte testove . Ako netko drugi treba pokrenuti testove, mora ga moći lako pronaći.
  • Prije poboljšanja koda, tj. Refaktoriranjem i optimizacijom za upotrebu u različitim okruženjima, osigurajte da su njegova struktura i protok idealni.
  • Pokreni testove odvojeno . Na taj je način lako prepoznati greške i ispraviti ih. S druge strane, manja je vjerojatnost da ćemo propustiti greške ili staze kao rezultat preklapanja u odjeljcima koda, blokovima ili stazama.
  • Generirajte testove prije uvođenja promjena . Testovi se trebaju izvoditi prema očekivanjima. Na taj je način, ako se nešto pokvari, lako pronaći i riješiti problem.
  • Neka testovi za svaki odjeljak ili blok koda budu odvojeni . Na taj način, ako postoje promjene u nizu, ne moramo mijenjati puno testova.
  • Ispravite programske pogreške prije nego što nastavite s testiranjem . Ako prepoznamo bilo kakve greške, bolje je da ih popravimo prije nego što nastavimo testirati sljedeći odjeljak ili blok koda.
  • Nikada nemojte preskočiti strukturno ispitivanje s pretpostavkom da će QA 'ionako i dalje raditi testiranje'. Čak i ako se bugovi u početku mogu činiti beznačajni, kumulativno, mogu rezultirati programskim kodom koji nikada ne može postići namjeravanu svrhu.

Često postavljana pitanja za ispitivanje temeljeno na strukturi

Ovdje ćemo istražiti često postavljana pitanja kada je riječ o ispitivanju temeljenom na strukturi.

P # 1) Koja je razlika između funkcionalnog ispitivanja i strukturnog ispitivanja?

Odgovor: Funkcionalno testiranje vrsta je softverskog testiranja koja se temelji na utvrđenim zahtjevima u SRS-u (Specifikacije softverskih zahtjeva). To se obično radi u svrhu pronalaženja razlika između specifikacija u SRS-u i načina na koji kôd funkcionira. Strukturno ispitivanje temelji se na unutarnjoj strukturi koda i njegovoj provedbi. Potrebno je temeljito razumijevanje koda.

P # 2) Koje su vrste strukturnih ispitivanja?

Odgovoriti vrste uključuju:

  • Ispitivanje protoka podataka
  • Ispitivanje mutacije
  • Ispitivanje kontrolnog protoka
  • Ispitivanje na osnovi kriški

P # 3) Što je primjer strukturnog ispitivanja?

Odgovor: Evo primjera koji pokazuje pokrivenost izjave:

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 pokrića koju dobijemo ovisi o testnim podacima koje pružamo kao ulaz (udovoljava li zbroju> 0 uvjetima).

P # 4) Koja je razlika između testiranja protoka podataka i kontrolnog protoka?

Odgovor: I ispitivanje protoka podataka i ispitivanje kontrolnog protoka koriste grafikone kontrolnog protoka. Jedina je razlika u tome što se u kontrolnom testiranju protoka fokusiramo na putove generirane iz koda, dok se u testiranju protoka podataka fokusiramo na vrijednosti podataka, njihovu definiciju i upotrebu unutar staza identificiranih unutar programa.

P # 5) Za što se koristi testiranje protoka podataka?

Odgovor: Testiranje protoka podataka idealno je za identificiranje anomalija u korištenju vrijednosti podataka unutar staza u grafikonu kontrolnog toka, na primjer, jedna varijabla kojoj je dva puta dodijeljena vrijednost, varijabla koja je definirana i nije korištena ili varijabla koja je korištena ili je navedena i nije definirana.

P # 6) Koja je razlika između rezanja i rezanja kockicama u testiranju softvera?

Odgovor: Rezanje znači usredotočiti se na određene izjave o interesu u programu i zanemariti ostalo. Kockanje je kad identificiramo krišku koja ima pogrešan unos, a zatim je dalje narežemo kako bismo pratili ispravno ponašanje.

P # 7) Koja je razlika između testiranja mutacija i pokrivanja koda?

Odgovor: U testiranju mutacija, broj ubijenih mutanata smatramo postotkom od ukupnog broja mutanata. Pokrivenost koda jednostavno je količina koda koja je testirana u programu.

Zaključak

U ovom smo tutorijalu detaljno pogledali strukturno ispitivanje - što je to, što nije, kako se to riješiti, vrste pokrivenosti, prednosti i nedostaci, najbolje prakse, pa čak i neka često postavljana pitanja u vezi s ovom vrstom testiranja softvera.

Još je toliko mnogo toga što možemo naučiti o ispitivanju temeljenom na strukturi. U budućim tutorijalima istražit ćemo pokrivenost koda (izjava, odluka, grana i put), vrste strukturnih ispitivanja (mutacija, protok podataka i zasnovan na rezovima), pa čak i alate koje možemo koristiti za automatizaciju tih procesa testiranja.

Važno je napomenuti da ne postoji vrsta testiranja softvera ili pristup koji je 100% učinkovit. Uvijek je poželjno kombinirati različite vrste i pristupe ispitivanja.

Na primjer, strukturno ispitivanje uvelike se nadopunjuje ispitivanjem zahtjeva, jer mogu postojati značajke koje možda nisu bile razvijene u vrijeme kada se provodilo ispitivanje temeljeno na strukturi.

Tehnike strukturnog ispitivanja temelje se na pogreškama koje ljudski programeri čine prilikom pisanja koda. Pretpostavka je da je programer stručnjak i zna što kodira, ali s vremena na vrijeme pogriješi.

Različite vrste strukturnih ispitivanja koje smo pogledali - ispitivanje mutacija, testiranje na osnovi kriška i ispitivanje protoka podataka mogu se pratiti do pogrešaka poput upotrebe pogrešnog operatora (ispitivanje mutacija) ili referenciranja varijable prije upotrebe (ispitivanje protoka podataka) .

Preporučena literatura

^