what is incremental testing
Cu ajutorul acestui articol, voi acoperi una dintre cele mai importante abordări de integrare - testarea incrementală.
Până la sfârșitul acestei secțiuni, publicul va avea cunoștințe corecte despre următoarele:
- Ce este testarea incrementală?
- Obiectivul său
- Metodologii
- Avantaje
- Dezavantaje
Ce veți învăța:
- Ce este testarea incrementală
Ce este testarea incrementală
Testarea incrementală, cunoscută și sub numele de Testarea integrării incrementale, este una dintre abordările testării integrării și încorporează conceptele sale fundamentale.
Este ca un test care combină modulul și integrarea strategie de testare .
În cadrul acestei testări, testăm fiecare modul în mod individual în faza de testare a unității, iar apoi modulele sunt integrate incremental și testate pentru a asigura interfața și interacțiunea uniformă între module.
În această abordare, fiecare modul este combinat în mod incremental, adică unul câte unul până când toate modulele sau componentele sunt adăugate logic pentru a face aplicația necesară, în loc să integreze întregul sistem simultan și apoi să efectueze teste pe produsul final. Modulele integrate sunt testate ca un grup pentru a asigura integrarea cu succes și fluxul de date între module.
Ca și în testarea integrării, obiectivul principal al efectuării acestui test este verificarea interfeței, a legăturilor integrate și a fluxului de informații între module. Acest proces se repetă până când modulele sunt combinate și testate cu succes.
Exemplu
Să înțelegem acest concept cu un exemplu:
Aplicația de sistem sau software constă din următoarele module:
Abordarea de testare a integrării incrementale
- Fiecare modul adică M1, M2, M3 etc. sunt testate individual ca parte a testării unitare
- Modulele sunt combinate incremental, adică unul câte unul și testate pentru interacțiunea de succes
- În Fig2, Modulul M1 și Modulul M2 sunt combinate și testate
- În Fig3, Modulul M3 este adăugat și testat
- În Fig4, se adaugă modulul M4 și se efectuează testarea pentru a vă asigura că totul funcționează împreună cu succes
- Restul modulelor sunt, de asemenea, adăugate incremental la fiecare pas și testate pentru integrarea cu succes
Fig2
Fig3
inserarea și ștergerea arborelui binar în java
Fig4
Obiectivul testului incremental
- Pentru a vă asigura că diferite module funcționează împreună cu succes după integrare
- Identificați defectele mai devreme și în fiecare fază. Acest lucru oferă dezvoltatorilor un avantaj pentru a identifica unde este problema. Ca și dacă testarea după integrarea M1 și M2 este reușită, dar când se adaugă M3, testul eșuează; acest lucru îl va ajuta pe dezvoltator să separe problema
- Problemele pot fi rezolvate în faza incipientă fără prea multe lucrări și cu costuri mai mici
Metodologii de testare a integrării incrementale
Înainte de a începe cu acest subiect, îmi place să fac o scurtă prezentare despre Butoane și șoferi deoarece vom folosi des acești termeni.
Butoanele și driverele sunt pseudo cod sau cod fals utilizate în Integrare sau testarea componentelor când unul sau mai multe module nu sunt dezvoltate, dar sunt necesare pentru a testa un alt modul.
Cioturi sunt utilizate în abordarea de testare de sus în jos și sunt cunoscute sub numele de „programe numite”. Butoanele ajută la simularea interfeței dintre modulele cu pârghie inferioară care nu sunt disponibile sau dezvoltate.
Șoferii sunt utilizate în abordarea de testare de jos în sus și sunt cunoscute sub numele de „programe de apelare”. Driverele ajută la simularea interfeței dintre modulele de nivel superior care nu sunt dezvoltate sau disponibile.
O întrebare care ar putea apărea pentru unii dintre noi este de ce să nu așteptăm până când toate modulele de aplicație sunt dezvoltate în loc să folosească stub / driver înainte de a începe testarea?
Răspunsul simplu este că crește timpul de execuție a proiectului, deoarece testerii vor sta în repaus până vor fi dezvoltate toate modulele. De asemenea, acest lucru face dificilă analiza rădăcinii defectului. Acest tip de abordare de testare este cunoscut sub numele de testare a integrării Big-Bang.
Acum, că am acoperit butoane și șoferi, să trecem la diferite metodologii de testare incrementală:
# 1) Sus în jos
După cum sugerează și numele, testarea are loc de sus în jos, adică de la modulul central la submodulul. Modulele care încadrează stratul superior al aplicației sunt testate mai întâi.
Această abordare urmărește fluxul structural al aplicației supuse testării. Modulele sau componentele indisponibile sau nedezvoltate sunt înlocuite cu butoane.
Să înțelegem acest lucru cu un exemplu:
- Modul : Conectare site web aka L
- Modul : Comanda aka O
- Rezumatul comenzii modulului, alias sistemul de operare (încă nu a fost dezvoltat)
- Modul : Plata aka P
- Modul de plată în numerar aka CP
- Modul Plată de debit / credit aka DP (Nu a fost încă dezvoltat)
- Module Wallet Payment aka WP (Nu a fost încă dezvoltat)
- Modul: Reporting aka R (Nu a fost încă dezvoltat)
De sus în jos Abordarea de testare a integrării incrementale
Următoarele cazuri de testare vor fi derivate:
referință nedefinită la c ++ principal
Caz de test 1: Modulul L și modulul O vor fi integrate și testate
Testul 2: Modulul L, O și P vor fi integrate și testate
Testul 3: Modulul L, O, P și R vor fi integrate și testate.
Și așa mai departe sunt derivate alte cazuri de testare.
Acest tip de testare în care toate modulele dintr-un strat sunt mai întâi integrate și testate este cunoscut sub numele de „lățime-primul”. O altă categorie este „prima adâncime”.
Următoarele cazuri de testare vor fi derivate pentru „adâncime-primul”:
Caz de test 1: Modulul L și modulul O vor fi integrate și testate
Testul 2: Modulul L, O și sistemul de operare vor fi integrate și testate
Testul 3: Modulul L, O, OS, P va fi integrat și testat
Testul 4: Modulul L, O, OS, P, CP va fi integrat și testat
Și așa mai departe sunt derivate alte cazuri de testare.
Meritele metodologiei de sus în jos
- Expunerea timpurie a defectelor arhitecturale
- Acesta prezintă funcționarea unei aplicații în ansamblu în stadii incipiente și ajută la dezvăluirea timpurie a defectelor de proiectare
- Principalele puncte de control sunt testate devreme
De-Meritele metodologiei de sus în jos
- Modulele semnificative sunt testate târziu în ciclu
- Este foarte dificil să scrii condiții de testare
- Un butuc nu este o implementare perfectă a modulului asociat. Simulează doar fluxul de date între două module
# 2) De jos în sus
În această abordare, testarea are loc de jos în sus, adică modulele de la nivelul inferior sunt integrate și testate mai întâi și apoi secvențial alte module sunt integrate pe măsură ce ne deplasăm în sus. Modulele indisponibile sau nedezvoltate sunt înlocuite de drivere.
Să vedem un exemplu menționat mai jos pentru o mai bună înțelegere:
Clasificarea modulelor, notele, procentajul și gradul sportiv nu sunt încă dezvoltate, așa că vor fi înlocuite cu șoferul asociat:
Abordarea abordării de testare a integrării incrementale
Următoarele cazuri de testare vor fi derivate:
Caz de test 1: Testarea unității a modulului Practic și teoretic
Testul 2: Integrarea și testarea modulelor Marks-Practical-theory
Testul de caz3 : Integrarea și testarea modulelor Procentaj-Mărci-Practic-Teorie
Testul 4: Testarea unității de clasă sportivă a modulului
Testul 5: Integrarea și testarea modulelor Rang-Grad sportiv-Procentaj-Mărci-Practic-Teorie
Meritele metodologiei de jos în sus
- Această metodologie este foarte utilă pentru aplicații în care este utilizat modelul de proiectare de jos în sus
- Este mai ușor să creați condiții de testare în abordarea de jos în sus
- A începe testarea la nivelul inferior al ierarhiei înseamnă testarea modulelor critice sau a funcționalității într-un stadiu incipient. Acest lucru ajută la descoperirea timpurie a erorilor
- Defectele interfeței sunt detectate în stadiul incipient
De-meritele metodologiei de jos în sus
- Driverele sunt mai greu de scris decât stub
- Defectele de proiectare sunt surprinse în etapa ulterioară
- În această abordare, nu avem aplicație de lucru până când nu se construiește ultimul modul
- Driverul nu este o implementare completă a modulului aferent. Simulează doar fluxul de date între două module.
# 3) Testare sandwich
Această abordare este un hibrid de metodă de sus în jos și de jos în sus. Stub și driverele sunt utilizate pentru module incomplete sau ne dezvoltate.
Abordarea de testare
- Este identificat un strat de mijloc din care se fac teste de jos în sus și de sus în jos. Acest strat de mijloc este, de asemenea, cunoscut sub numele de strat țintă
- Stratul țintă este identificat conform abordării euristice, adică selectați un strat care permite utilizarea minimă a butoanelor și a driverelor
- Testarea de sus în jos începe de la stratul mediu și se deplasează în jos către module de nivel inferior. Acest strat sub stratul mediu este cunoscut sub numele de Stratul inferior
- Testarea de jos în sus începe, de asemenea, de la stratul de mijloc și se deplasează în sus către modulele de strat superior. Acest strat de deasupra stratului mediu este cunoscut sub numele de strat superior
- Cu ajutorul stuburilor și driverelor, interfața cu utilizatorul și funcțiile modulelor de nivel inferior sunt testate, respectiv
- La final, rămâne doar stratul de mijloc pentru executarea testului final
Exemplu:
Următoarele cazuri de testare pot fi derivate cu Sandwich Testing Strategy:
Caz de test 1: Testul A, X, Y și Z individual - în cazul în care Testul A intră sub testul stratului superior și Testul X, Y și Z intră sub testele stratului inferior
Testul 2: Testul A, G, H și I
Testul 3: Testați G, X și Y
Testul 4: Testează mâna Z
Testul 5: Testează A, G, H, I, X, Y și Z
Meritele metodologiei de testare sandwich
- Este foarte benefic pentru un proiect mare care are diverse sub-proiecte
- Metodologia de testare de sus în jos și de jos în sus poate rula unul lângă altul
De-meritele metodologiei de testare Sandwich
- Înainte de unificarea modulelor, subsistemele și interfețele acestora nu sunt testate temeinic
- Costuri mai mari datorită implicării atât a metodologiei de testare de sus în jos, cât și de jos în sus
- Acest tip de testare nu este recomandat pentru un sistem în care modulele sunt extrem de interdependente
Concluzie
Testarea incrementală se află sub acoperirea testelor de integrare. În această abordare de testare, testarea integrării se face pe modulul individual ca parte a testării unitare și în faza următoare, modulele sau componentele aplicației sunt integrate în mod incremental și testarea se efectuează pe module combinate ca grup.
Din cele trei metodologii de testare a integrării incrementale, alegerea metodologiei de ales depinde de structura aplicației și, de asemenea, de poziția modulelor cu risc ridicat.
Toate cele trei metodologii de testare incrementală intră în categoria Orizontală datorită următoarelor aspecte comportamentale:
- Toate cele trei metodologii se concentrează pe testarea stratului
- Toți consideră un design structural sau ierarhic
- Toate acestea integrează straturi în mod incremental
Merite:
Cu această abordare de testare, este mai ușor să identificați defectele mai devreme și, de asemenea, ajută dezvoltatorul să determine cauza problemei. Deoarece folosește elementele de bază ale testării structurate, această abordare de testare este foarte eficientă și precisă.
Demerite:
Acest tip de abordare de testare consumă mult timp din cauza utilizării butoanelor și a driverelor. Este, de asemenea, repetitiv.
Despre autor: Acest tutorial util este scris de Neha B. Ea este certificată ISTQB Lead Quality Analyst cu peste 8 ani de experiență.
Spuneți-ne dacă aveți întrebări / sugestii.
Lectură recomandată
- Cele mai bune instrumente de testare software 2021 (Instrumente de automatizare a testelor de calitate)
- Ce este testarea componentelor sau testarea modulelor (Aflați cu exemple)
- Descărcare eBook Descărcare Primer
- Testarea funcțională Vs testarea nefuncțională
- Ce este testarea de anduranță în testarea software (exemple)
- Testare pereche sau Tutorial de testare completă cu instrumente și exemple
- Tipuri de testare software: diferite tipuri de testare cu detalii
- Tutorial de testare a volumului: exemple și instrumente de testare a volumului