structural testing tutorial what is structural testing
Acest tutorial cuprinzător de testare structurală explică ce este testarea structurală, tipurile sale, ce este testarea fluxului de control și graficul fluxului de control, nivelurile de acoperire etc.:
O căutare rapidă pe Google a unora dintre cele mai scumpe erori de software mi-a lăsat mintea înfundată - 500 de miliarde de dolari. Da, atât de costisitor poate fi un bug. Citirea oricărui lucru legat de viețile pierdute în industria transporturilor și a asistenței medicale din cauza unei erori de software poate fi și îngrozitoare.
În timp ce erorile în cod nu sunt întotdeauna atât de extreme în care implică pierderea unor sume abundente de bani și de vieți, singura soluție cheie aici pe care încercăm să o transmitem este aceea că nu se poate trece cu vederea testarea.
Când testarea se face frecvent pe tot parcursul SDLC, ne permite să prindem erori care ar avea nevoie de mult mai mult timp pentru a le remedia după livrarea produsului.
Ceea ce este important este tipurile de testare software pe care le alegem. Există mai multe dintre acestea, inclusiv testarea funcțională, structurală și bazată pe schimbări.
Acest tutorial explică, de asemenea, tipurile de testare structurală. Aflați cum să faceți testarea mutației, testarea bazată pe felii, testarea fluxului de date în detaliu, cu exemple și explicații.
Ce veți învăța:
- De ce este importantă testarea software-ului
- Ce este testarea structurală
- Tipuri de testare structurală
- Avantajele și dezavantajele testării structurale
- Cele mai bune practici de testare structurală
- Concluzie
De ce este importantă testarea software-ului
Pe lângă economisirea banilor și evitarea dezastrelor, precum cazurile menționate mai sus, există și alte câteva motive care justifică importanța testării.
Înscrise mai jos sunt câteva motive:
# 1) Pentru a vă asigura că sunt îndeplinite cerințele stipulate înainte de a începe să construiască un proiect. Părțile interesate (de exemplu, dezvoltatorii și clienții) trebuie să fie de acord asupra tuturor aspectelor soluției / produsului / software-ului care sunt necesare pentru a construi un proiect.
Testarea implică verificarea dacă sunt îndeplinite cerințele software. Dezvoltatorul sau compania implicată în construirea soluției câștigă, de asemenea, o bună reputație pentru proiectarea unei astfel de soluții de înaltă calitate, administrată de codul eclat.
# 2) Verifică dacă funcția de cod funcționează conform intenției. Testarea implică, de asemenea, verificarea funcționalității software-ului și, în cazul unei disfuncționalități, ar trebui remediată în primele faze ale SDLC (Software Development Life Cycle).
# 3) Verifică performanța: De exemplu, pentru a identifica timpul total scurs în timpul rulării codului. Dacă folosim mai multe Pentru bucle în codul nostru, va dura mult timp pentru a obține rezultatul dorit și poate chiar expira uneori.
# 4) Ajută la obținerea unei experiențe de utilizare mai bune. Utilizatorilor nu le va plăcea să folosească software-ul care nu funcționează defectuos, nu are probleme sau este „prea lent”. Utilizatorii vor deveni probabil nerăbdători și vor renunța la utilizarea software-ului. Testarea ne oferă o imagine mai bună pentru a ne asigura că utilizatorii pot folosi cu ușurință produsele noastre.
# 5) Verifică scalabilitatea. Un dezvoltator ar trebui să vizeze crearea de software care poate fi scalat.
# 6) Verifică vulnerabilitățile din cod. Testarea ne permite să avem grijă de vulnerabilitățile de securitate, De exemplu, cod care poate compromite PII (Informații de identificare personală), care este o prioritate ridicată pentru GDPR.
În acest articol, ne vom concentra pe un tip de testare, adică Testarea structurală . După cum sugerează și numele, are de-a face cu structura codului. Acest lucru este diferit de ceea ce am menționat anterior că testarea ajută la determinarea unor aspecte precum performanța codului, funcționalitatea și securitatea.
Testarea structurală împotriva altor tipuri de testare
Există multe tipuri de testare software. Însă STOP (International Software Testing Qualifications Board), definește 4 tipuri majore de testare software, și anume
- Funcţional
- Funcțional
- Structural
- Pe bază de schimbare
Diferențele pot fi explicate după cum urmează:
Testarea funcțională: Aceasta implică verificarea funcționalității software-ului în raport cu cerințele stipulate. Datele de testare sunt utilizate ca intrare. De asemenea, verificăm dacă ieșirea dată este cea așteptată.
Testarea nefuncțională : Aceasta implică un proces de testare pentru a analiza cât de bine funcționează software-ul, de exemplu, numărul de utilizatori pe care îi poate gestiona simultan.
Testarea structurală: Acest tip de testare se bazează pe structura codului. De exemplu, dacă un cod este destinat să calculeze media numerelor pare dintr-o matrice, atunci testarea bazată pe structură ar fi interesată de „pașii care duc la calcularea mediei”, mai degrabă decât dacă rezultatul final este o valoare numerică corectă.
Să presupunem că trebuie să verificăm dacă am definit codul care diferențiază numerele pare de numerele impare. Putem avea aici o afirmație condițională, cum ar fi, dacă un element matrice este divizibil cu doi fără rest, if (arr (i)% 2 === 0) atunci numărul poate fi spus ca număr par.
Testarea structurală este efectuată de aceiași oameni care scriu codul așa cum îl înțeleg cel mai bine.
Testarea bazată pe schimbări : Aceasta implică testarea efectelor modificărilor aduse codului și apoi asigurarea faptului că modificările efectuate au fost implementate. De asemenea, se asigură că modificările aduse codului nu îl întrerup.
Ce nu este testarea structurală
Am menționat mai devreme că testarea bazată pe structură se referă la structura codului. Rețineți că aici ne ocupăm de codul real. Nu verificăm cerințele și nici nu testăm intrările în raport cu ieșirile așteptate. Nu ne preocupă funcționalitatea, experiența utilizatorului sau chiar performanța în acest moment.
Ce este testarea structurală
Prin urmare, testarea bazată pe structură poate fi definită ca un tip de testare software care testează structura codului și fluxurile preconizate. De exemplu, verificarea codului real pentru aspecte precum implementarea corectă a instrucțiunilor condiționale și dacă fiecare instrucțiune din cod este executată corect. Este, de asemenea, cunoscut sub numele de testare bazată pe structură.
Pentru a efectua acest tip de testare, trebuie să înțelegem temeinic codul. Acesta este motivul pentru care această testare este realizată de obicei de dezvoltatorii care au scris codul așa cum îl înțeleg cel mai bine.
Cum să efectuați testarea structurală
Pentru a testa diferite aspecte ale codului, trebuie mai întâi să înțelegem fluxurile de control.
Testarea fluxului de control
Aceasta derivă teste din fluxurile de control ale codului (ordinea în care sunt implementate instrucțiunile, funcțiile și diferitele aspecte ale codului).
Proces de testare a fluxului de control:
Graficul fluxului de control
Procesul fluxului de control începe prin crearea unei reprezentări vizuale a diferitelor secțiuni ale codului care ne ajută să definim căile care pot fi urmate în timpul execuției.
Aceste reprezentări vizuale sunt cunoscute sub numele de Control Flow Graphs (CFG) și au mai multe componente precum noduri, margini, căi, joncțiuni și puncte de decizie. Graficul poate fi creat manual sau automat, unde software-ul este utilizat pentru a extrage graficul din codul sursă.
Să vedem aceste componente mai jos:
# 1) Bloc de proces
Această parte este utilizată pentru a reprezenta o secțiune de cod care este executată secvențial. Acest lucru înseamnă că este executat în același mod de fiecare dată și că nu trebuie luate decizii sau „ramificări”. Este alcătuit din noduri cu o cale de intrare și ieșire.
Exemplu de bloc de proces:
care este cea mai bună aplicație de spionaj
(imagine sursă )
Blocul de proces nu este o parte esențială a fluxului de control și, ca urmare, trebuie testat o singură dată.
# 2) Puncte de decizie
Acestea sunt câteva componente cheie în fluxul de control al codului. În cadrul acestor noduri se iau decizii. Acest lucru se face de obicei prin comparație și fluxul de control se modifică, în funcție de decizie. Această parte a CFG este alcătuită dintr-un nod cu cel puțin 2 ieșiri.
Decizia luată aici ar putea fi afirmații condiționate precum, afirmații if-else (care au două rezultate posibile) și afirmații de caz (care pot avea mai mult de două rezultate).
(imagine sursă )
În diagrama de mai sus, există un punct de decizie (din condiționalul „vârstă = 18”) care este urmat de opțiunile „da” sau „nu”.
# 3) Puncte de joncțiune
Din diagrama de mai sus, putem identifica cu ușurință punctele de joncțiune cu privire la locul în care se unesc punctele de decizie. Punctele de joncțiune pot avea mai multe căi de intrare, dar pot avea o singură cale de ieșire.
Controlează cele mai bune practici ale graficelor de flux
Există câteva lucruri de reținut atunci când construiți grafice de flux de control:
- Încercați cât mai mult posibil pentru a păstra CFG simplu. Putem face acest lucru combinând părți care pot fi considerate ca fiind „mai puțin semnificative”, de exemplu, blocuri de proces.
- Asigurați-vă că la punctele de decizie se ia o singură decizie. În CFG-urile mai complexe, există „consecințe” care apar după luarea deciziei. În exemplul nostru de mai sus, am putea adăuga, de asemenea, că, dacă o persoană are 18 ani sau mai mult, atunci este eligibilă și trebuie să plătească pentru un bilet. Dacă nu sunt, atunci intrarea este gratuită. Decizia „altceva” trebuie să „sări” câteva noduri și toți acei pași trebuie să fie afișați în CFG-ul nostru.
Odată ce ne-am definit CFG-ul, este momentul să trecem la pasul următor în procesul de testare a fluxului de control, adică să definim măsura în care vom testa codul.
Definirea cantității de testat:
Cât din codul sursă ar trebui testat? Ar trebui să testăm fiecare cale posibilă? Încercarea de a parcurge toate căile în testele noastre este practic imposibilă. Trebuie să găsim o cale de mijloc pentru a determina cât de multe teste putem face.
Dacă spunem că ne propunem să testăm 50% din codul nostru, atunci acest lucru ar putea însemna că vom defini toate instrucțiunile de cod executabile și vom viza testarea a cel puțin jumătate dintre acestea. Cu toate acestea, întrebarea care se pune aici este „trebuie să definim toate căile executabile posibile?”
Acest lucru poate fi practic imposibil. O abordare mai bună ar putea avea ca scop testarea a 50% din căile pe care le putem identifica la fiecare secțiune a codului.
Există diferite niveluri de acoperire, și anume declarație, ramură și acoperire a căii. Le vom analiza pe scurt mai târziu.
Crearea cazurilor de testare:
Următorul pas este crearea cazurilor de testare pe care le vom folosi. Cazurile de testare în testarea bazată pe structuri se bazează pe următorii factori:
- Declarațiile executabile.
- „Deciziile” care trebuie luate.
- Posibile căi care pot fi urmate.
- Condițiile care trebuie îndeplinite (acestea pot fi multiple sau booleene).
Factorii de mai sus ne oferă o idee despre tipurile de cazuri de test pe care trebuie să le creăm. Putem folosi și un instrument de generare a testelor structurale. Dacă codul nostru este în limbajul de programare C, putem folosi PathCrawler pentru a genera codul de testare. Un alt instrument pe care îl putem folosi este fMBT.
Executarea cazurilor de testare:
Aici, vom rula testele. Putem introduce date de intrare sau date pentru a verifica modul în care codul le execută și apoi verificăm dacă obținem rezultatele așteptate. De exemplu, introduceți o matrice într-un apel funcțional pentru a observa că rezultatele pe care le obținem după ce le parcurgem sau pentru a verifica dacă punctele de decizie iau deciziile corecte.
Analizând rezultatele:
În această parte, tot ce facem este să verificăm dacă obținem rezultatele corecte după executare. De exemplu, dacă intrăm într-o matrice în care toate valorile sunt peste 18, atunci ar trebui să avem toate punctele de decizie care să ducă la „eligibil”.
Ipoteze de control al fluxului
Este important de reținut că pentru a efectua testarea fluxului de control, există câteva presupuneri care sunt făcute. Acestea includ:
- Singurele erori prezente sunt cele care pot afecta fluxul de control.
- Toate variabilele, funcțiile și elementele sunt definite cu acuratețe.
Nivele de acoperire în fluxurile de control
După cum am menționat mai devreme, există diferite niveluri de acoperire în testarea fluxului de control.
Să le privim pe scurt.
# 1) Acoperirea declarației
În testarea structurală, instrucțiunile de cod executabil joacă un rol vital atunci când vine vorba de a decide metodele de proiectare a testelor.
Ne propunem să realizăm o acoperire de 100%, ceea ce înseamnă că fiecare declarație executabilă a fost testată cel puțin o dată. Cu cât acoperirea este mai mare, cu atât este mai mică probabilitatea de a pierde erorile și erorile.
Este necesar să folosiți cazuri de testare aici. Datele pe care le dorim trebuie să ne asigurăm că fiecare instrucțiune executabilă dintr-un bloc de cod este executată cel puțin o dată.
# 2) Acoperirea sucursalei
Acest nivel de acoperire implică testarea punctelor din sucursalele CFG (unde se iau decizii). Rezultatele sunt booleene. Chiar dacă se folosește o instrucțiune switch și există rezultate multiple, în esență, fiecare bloc de caz este o comparație a unei perechi de valori.
La fel ca în cazul acoperirii extrasei, ar trebui să vizăm acoperirea 100% a sucursalelor. Pentru a realiza acest lucru, trebuie să testăm fiecare rezultat la fiecare nivel de decizie cel puțin o dată. Deoarece avem de-a face cu rezultate booleene, atunci ar trebui să ne propunem să rulăm cel puțin 2 teste pe secțiune de cod.
# 3) Acoperirea căii
Acest nivel de acoperire este mai aprofundat în comparație cu acoperirea deciziilor și a declarației. Scopul aici este de a „descoperi” toate căile posibile și de a le testa cel puțin o dată. Acest lucru poate fi extrem de consumator de timp. Cu toate acestea, poate ajuta la descoperirea de erori sau erori în codul nostru sau chiar aspecte pe care trebuie să le definim, de exemplu, introducerea utilizatorului.
Tipuri de testare structurală
(imagine sursă )
Testarea mutației
Testarea mutației este o tehnică de testare bazată pe erori, în care diferite variante ale unei aplicații software sunt testate în raport cu setul de date de testare.
>> Consultați acest tutorial pentru o privire detaliată Testarea mutației.
Testare bazată pe felii
Slice Based Testing (SBT) poate fi definit ca o tehnică de testare software pe care se bazează felii - părți executabile ale programului sau grupuri de declarații care afectează unele valori la anumite puncte de interes din program; de exemplu, părți în care variabilele sunt definite sau rezultatul unui grup de instrucțiuni.
Cum se face felierea
Exemplu de feliere în SBT: Cod pentru imprimarea numerelor pare și impare (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}') 
Există două moduri de a privi o felie: Urmând calea unei variabile de interes sau a părții de cod care afectează ieșirea.
În exemplul nostru, dacă ne uităm la ieșirea numerelor impare, putem urmări partea de cod care ne conduce la această ieșire.
În criteriile de feliere date de Mark Weiser (care a introdus SBT), o felie este definită folosind această formulă: S (v, n) , Unde, v se referă la variabila în cauză ( de exemplu, unde este definită o variabilă) și n este declarația de interes ( de exemplu, unde este dată ieșirea) și S stă pentru felie.
În exemplul de mai sus, pentru a obține felia, pornim de la ieșirea noastră pe linia 10, care devine a noastră n . Variabila noastră este Unde .
Deci, criteriile noastre de feliere sunt:
S(v,n) = S(var,10)Preocuparea noastră este afirmațiile care ne conduc la rezultat.
Acestea sunt:
10,9,8,4,3,1
Deci, felia noastră din acest cod este:
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}')
Tipuri de testare pe felii
Există două tipuri de SBT: static și dinamic
# 1) Testare dinamică bazată pe felii
Exemplul SBT explicat mai sus în care am analizat afirmațiile care afectează tipărirea numerelor impare este SBT dinamic. Preocuparea noastră este foarte specifică. Ne concentrăm doar asupra a ceea ce afectează în mod direct rezultatul particular.
Executăm codul și folosim datele de testare pentru a ne asigura că funcționează așa cum ar trebui. Am putea crește intervalul până la interval (1,50), de exemplu, pentru a vedea dacă generează în continuare doar numere impare. SBT dinamic este, de asemenea, cunoscut sub numele de testare de validare.
# 2) staticTestare bazată pe felii
Spre deosebire de Dynamic SBT, testarea statică se concentrează pe o anumită variabilă. Dacă ne gândim la rezultatul nostru în exemplul de mai sus ca Unde , putem urmări felia care o afectează ca 10,9,8,7,6,5,4,3,2,1
comenzi unix shell scripting cu exemple
Practic este întregul bloc de cod! Aici verificăm dacă codul este corect în ceea ce privește sintaxa și cerințele și nu îl executăm. SBT static este, de asemenea, cunoscut sub numele de testare de verificare.
Este important de reținut că SBT-ul dinamic este „mai mic” în comparație cu omologul său static. Este, de asemenea, mai specific.
Cele mai bune practici / linii directoare pentru testarea pe felii
Criteriile de feliere ar trebui să fie determinate de:
- Declarații în care valorile sunt definite sau atribuite, precum și valoarea realocată.
- Declarații în care se primesc valori din afara programului, de exemplu, prin introducerea utilizatorului.
- Instrucțiuni care imprimă ieșire / returnare ieșire.
- Ultima declarație a programului, de exemplu, un apel funcțional care poate defini valori sau poate oferi valori argumentelor
Avantajele testării pe felii includ:
- Deoarece în SBT lucrăm doar cu domenii de interes specifice, este mai ușoară generarea eficientă a suitelor de testare.
- Calea este definită de dependențe în cadrul codului, ceea ce este mai bun decât utilizarea acoperirea căii.
- Cu SBT, este mai ușor să găsiți erori în codul sursă.
Dezavantajele testării pe felii includ:
- Dacă folosim testarea dinamică atunci când testăm o bază de cod mare, vom avea nevoie de o mulțime de resurse de calcul.
- Dacă folosim testarea statică, este posibil să pierdem erorile.
Testarea fluxului de date
Testarea fluxului de date poate fi definită ca o tehnică de testare software care se bazează pe valorile datelor și utilizarea acestora într-un program. Verifică dacă valorile datelor au fost utilizate în mod corespunzător și că generează rezultatele corecte. Testarea fluxului de date ajută la urmărirea dependențelor dintre valorile datelor pe o anumită cale de execuție.
Anomalii ale fluxului de date
Anomaliile fluxului de date sunt pur și simplu erori într-un program software. Acestea sunt clasificate în tipurile 1, 2 și respectiv 3.
Să analizăm mai jos:
Tipul 1: O variabilă este definită și i se atribuie o valoare de două ori.
Exemplu de cod: Python
lst_1 = (1,2,3,4) lst_1 = (5,6,7,8) for var in lst_1: print(var) 
Lst_1 este definit și i se atribuie două valori diferite. Prima valoare este pur și simplu ignorată. Anomaliile de tip 1 nu determină eșecul programului.
Tipul 2: Valoarea unei variabile este utilizată sau menționată înainte de a fi definită.
Exemplu de cod: Python
for var in lst_1: print(var) 
Bucla de mai sus nu are valori peste care să se repete. Anomaliile de tip 2 determină eșecul programului.
Tipul 3: A valoarea datelor este generată, dar nu este folosită niciodată.
Exemplu de cod: Python
lst_1 = (1,2,3,4) lst_2 = (5,6,7,8) for var in lst_1: print(var) 
Variabila lst_2 nu a fost menționat. Anomaliile de tip 3 nu pot provoca eșecul programului.
Proces de testare a fluxului de date
Pentru a defini dependențele dintre valorile datelor, trebuie să definim căile diferite care pot fi urmate într-un program. Pentru a face acest lucru în mod eficient, trebuie să împrumutăm de la un alt tip de testare structurală cunoscut sub numele de testarea debitului de control .
Pasul 1) Desenați un grafic al fluxului de control
Trebuie să desenăm un grafic al fluxului de control, care este o reprezentare grafică a căilor pe care le-am putea urma în programul nostru.
Exemplu de cod: 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) 
În exemplul de cod de mai sus, un membru ar trebui să primească o reducere dacă invită un vizitator.
Graficul fluxului de control (CFG):
Pasul 2) Explorează definiția și utilizarea variabilelor și valorilor datelor.
O variabilă dintr-un program este fie definită, fie utilizată. În CFG, avem variabile la fiecare nod. Fiecare nod este denumit în funcție de tipul variabil pe care îl găzduiește. Dacă o variabilă este definită la un anumit nod, se creează un nod care definește. Dacă o variabilă este utilizată la un nod, se creează un nod de utilizare.
Dacă luăm în considerare costul variabil în CFG, acestea sunt nodurile de definire și utilizare:
| Nodul | Tip | Cod |
|---|---|---|
| 1 | Nod de definire | cost = 20 |
| 5 | Nod de utilizare | factura = cost -1 |
| 7 | Nod de utilizare | factura = cost |
Pasul 3) Definiți căi de utilizare a definiției.
Există două tipuri de căi de utilizare a definiției: du cărări și căi dc. căile du sunt căi de definiție care încep cu un nod de definiție și se termină cu un nod de utilizare. Acesta este cazul pentru cale în raport cu costul variabil de mai sus.
Un exemplu de cale DC, o cale clară de decizie, este calea cu privire la variabila factură, după cum urmează:
| Nodul | Tip | Cod |
|---|---|---|
| 5 | Nod de definire | factura = cost -1 |
| 7 | Nod de definire | factura = cost |
| 8 | Nod de utilizare | print (factura) |
calea dc are mai multe noduri de definiție, chiar dacă se termină în continuare cu un nod de utilizare.
Pasul 4) Creați suita de testare.
Aceasta adaugă intrare. Rețineți că trebuie să avem o suită de testare diferită pentru fiecare variabilă. Suita de testare ne va ajuta să identificăm anomaliile fluxului de date.
Tipuri de testare a fluxului de date
Există două tipuri - Static și dinamic .
Static înseamnă că parcurgem codul și CFG pentru a identifica anomaliile datelor, fără a le executa. Dinamic înseamnă că identificăm de fapt căile specifice și apoi creăm suite de testare pentru a le testa în încercarea de a „prinde” anomalii pe care poate le-am ratat în timpul testării statice.
Avantajele și dezavantajele testării fluxului de date:
- Testarea fluxului de date este ideală pentru identificarea anomaliilor fluxului de date, ceea ce îl face o metodă de testare structurală foarte eficientă.
- Dezavantajul său este că este necesar să fie bine versat în limba utilizată pentru a scrie codul pentru a utiliza testarea fluxului de date. De asemenea, consumă mult timp.
Avantajele și dezavantajele testării structurale
Să găsim acum motivele pentru care testarea structurală este o abordare excelentă și să explorăm și unele dintre dezavantajele sale.
Avantaje:
- Permite testarea detaliată a codului, rezultând erori minime. Testarea bazată pe structură oferă spațiu pentru testarea temeinică a software-ului. Diferitele niveluri de acoperire - declarație cu declarație, fiecare punct de decizie și cale vizează atingerea unei acoperiri de 100%, ceea ce reduce foarte mult șansele ca erorile să nu fie detectate.
- Capacitatea de a automatiza . Există mai multe instrumente pe care le putem folosi pentru automatizarea testării. Acest lucru ne va ajuta să obținem o acoperire maximă a codului și într-un timp mai scurt în comparație cu efectuarea testării manual.
- Rezultă un cod de calitate superioară . Dezvoltatorii au șansa de a studia structura și implementarea codului și de a remedia eventualele erori, precum și de a îmbunătăți aceste aspecte. Ne permite să avem în vedere marea structură în timp ce scriem părți ulterioare ale codului sau implementăm caracteristicile rămase.
- Se poate face prin fiecare fază a SDLC - Testarea structurală se poate face la fiecare fază a SDLC fără a aștepta finalizarea dezvoltării 100%. Acest lucru facilitează identificarea erorilor în faza incipientă și, astfel, economisește mult timp în comparație cu testarea după finalizarea dezvoltării.
- Vă ajută să scăpați de codul mort . Acesta poate fi văzut ca un cod „suplimentar” sau inutil, de exemplu, cod care va calcula un rezultat, dar nu îl va folosi niciodată în niciunul dintre următoarele calcule.
- Eficienţă - Deoarece dezvoltatorii care scriu codul sunt aceiași care îl testează, nu este necesar să se implice alte persoane, cum ar fi QA-urile.
Dezavantaje:
- Dezvoltatorii care efectuează teste bazate pe structuri trebuie să aibă o înțelegere aprofundată a limbii . Alți dezvoltatori și QA-uri care nu sunt bine versați în limbă nu pot ajuta la testare.
- Poate deveni destul de scump în termeni de timp și bani . Este nevoie de mult timp și resurse pentru a face testarea eficientă.
- Provoacă întârzieri în livrarea caracteristicilor . Acest lucru se datorează faptului că dezvoltatorii sunt scoși din construcția de software pentru a face teste.
- Scalarea este o problemă, mai ales în cazul în care sunt implicate aplicații mari . O aplicație mare este egală cu un număr excesiv de mare de trasee de parcurs. Obținerea unei acoperiri de 100% devine imposibilă.
- Pot exista cazuri și rute ratate , de exemplu, într-un caz în care caracteristicile nu sunt pe deplin dezvoltate sau sunt încă de dezvoltat. Aceasta înseamnă că trebuie combinat cu alte tipuri de testare, cum ar fi, testarea cerințelor (unde verificăm în funcție de caracteristicile specificate care trebuiau construite).
Cele mai bune practici de testare structurală
Unii dintre factorii care necesită atenție în timpul efectuării testelor bazate pe structuri sunt după cum urmează:
- Etichetați clar și denumiți testele . Dacă altcineva trebuie să efectueze testele, trebuie să le poată localiza cu ușurință.
- Înainte de a îmbunătăți codul, adică refactorizându-l și optimizându-l pentru a fi utilizat în diferite medii, asigurați-vă că structura și fluxul său sunt ideale.
- Rulați testele separat . În acest fel, este ușor să identificați erorile și să le remediați. Pe de altă parte, este mai puțin probabil să ratăm erori sau căi ca urmare a suprapunerilor în secțiuni de cod, blocuri sau căi.
- Generați teste înainte de a face modificări . Testele sunt necesare pentru a rula așa cum era de așteptat. În acest fel, dacă se sparge ceva, atunci este ușor să urmăriți și să remediați problema.
- Păstrați testele pentru fiecare secțiune sau bloc de cod separat . În acest fel, dacă există modificări pe linie, nu trebuie să schimbăm o mulțime de teste.
- Remediați erorile înainte de a trece mai departe cu testarea . Dacă identificăm erori, este mai bine să le remediem înainte de a continua să testăm următoarea secțiune sau bloc de cod.
- Nu treceți niciodată peste testarea structurală, presupunând că un QA „va face totuși testarea oricum”. Chiar dacă bug-urile pot părea nesemnificative la început, cumulativ, ele pot duce la un cod buggy care nu poate atinge niciodată scopul dorit.
Întrebări frecvente pentru testarea bazată pe structuri
Aici vom explora întrebările frecvente atunci când vine vorba de testarea bazată pe structuri.
Q # 1) Care este diferența dintre testarea funcțională și testarea structurală?
Răspuns: Testarea funcțională este un tip de testare software bazată pe cerințele stipulate în SRS (Specificațiile cerințelor software). De obicei, se face în încercarea de a găsi diferențe între specificațiile din SRS și modul în care funcționează codul. Testarea structurală se bazează pe structura internă a codului și implementarea acestuia. Este necesară o înțelegere aprofundată a codului.
Q # 2) Care sunt tipurile de testare structurală?
care este cel mai bun downloader de muzică pentru telefonul Android
Raspunde la tipurile includ:
- Testarea fluxului de date
- Testarea mutației
- Testarea debitului de control
- Testare pe felii
Î # 3) Ce este un exemplu de testare structurală?
Răspuns: Iată un exemplu care arată acoperirea declarației:
const addNums = (num) => { let sum = num.reduce ((a,b) => a+b); if (sum > 0) { alert(sum); } else { alert(‘please enter positive numbers’); } }; addNums(); Cantitatea de acoperire pe care o obținem depinde de datele de test pe care le furnizăm ca intrare (dacă îndeplinește suma> 0 condiții).
Q # 4) Care este diferența dintre testarea fluxului de date și testarea fluxului de control?
Răspuns: Atât testarea fluxului de date, cât și testarea fluxului de control utilizează grafice de flux de control. Singura diferență este că în testarea fluxului de control, ne concentrăm pe căile generate din cod, în timp ce în testarea fluxului de date, ne concentrăm pe valorile datelor, definiția lor și utilizarea în căile identificate în cadrul unui program.
Q # 5) Pentru ce se utilizează testarea fluxului de date?
Răspuns: Testarea fluxului de date este ideală pentru identificarea anomaliilor în utilizarea valorilor datelor în căi într-un grafic al fluxului de control, de exemplu, o variabilă căreia i s-a atribuit valoarea de două ori, o variabilă care a fost definită și neutilizată sau o variabilă care a fost utilizată sau referențiată și nedefinită.
Q # 6) Care este diferența dintre felierea și tăierea cuburilor în testarea software-ului?
Răspuns: Tranșarea înseamnă concentrarea pe anumite declarații de interes într-un program și ignorarea celorlalte. Decuparea este atunci când identificăm o felie care are o intrare greșită și apoi o tranșăm în continuare pentru a urmări un comportament corect.
Q # 7) Care este diferența dintre testarea mutației și acoperirea codului?
Răspuns: În testarea mutației, considerăm numărul de mutanți uciși ca procent din totalul mutanților. Acoperirea codului este pur și simplu cantitatea de cod care a fost testată într-un program.
Concluzie
În acest tutorial am analizat în profunzime testarea structurală - ce este, ce nu este, cum să procedăm, tipuri de acoperire, avantaje și dezavantaje, cele mai bune practici și chiar câteva întrebări frecvente cu privire la acest tip de testare software.
Există încă atât de multe lucruri pe care le putem învăța despre testarea bazată pe structuri. În tutoriale viitoare, vom explora acoperirea codului (declarație, decizie, ramură și cale), tipurile de testare structurală (mutație, flux de date și bazate pe felii) și chiar instrumentele pe care le putem folosi pentru automatizarea acestor procese de testare.
Este important să rețineți că nu există un tip sau o abordare de testare software care să fie 100% eficientă. Este întotdeauna recomandabil să combinați diferite tipuri de testare și abordări.
De exemplu, testarea structurală este completată în mare măsură de testarea cerințelor, deoarece pot exista caracteristici care ar putea să nu fi fost dezvoltate în momentul în care se efectuau testări bazate pe structuri.
Tehnicile de testare structurală se bazează pe erorile pe care programatorii umani le fac atunci când scriu codul. Presupunerea este că programatorul este un expert și știe ce codifică, dar greșește din când în când.
Diferitele tipuri de teste structurale pe care le-am analizat - testarea mutației, testarea bazată pe felii și testarea fluxului de date ar putea fi urmărite înapoi la erori cum ar fi utilizarea unui operator greșit (testarea mutației) sau referirea unei variabile înainte de a o utiliza (testarea fluxului de date) .
Lectură recomandată
- Tutorial de testare distructivă și testare nedistructivă
- Testarea funcțională Vs testarea non-funcțională
- Ce este tehnica de testare bazată pe defecte?
- Tutorial de testare a înmuierii - Ce este testarea înmuiere
- Tutorial de testare SOA: metodologie de testare pentru un model de arhitectură SOA
- Testarea încărcării cu tutoriale HP LoadRunner
- Ce este testarea Gamma? Etapa finală de testare
- Tutorial DevOps Testing: Cum va afecta DevOps testarea QA?
- Ce este testarea conformității (testarea conformității)?