Ce este testarea modulului? Definiție, Exemple

prin: Thomas Hamilton Thomas Hamilton
Hours Actualizat

⚡ Rezumat inteligent

Testarea modulelor verifică subprogramele, subrutinele, clasele și procedurile individuale, mai degrabă decât programul asamblat, astfel încât defectele apar în interiorul unui bloc de cod mic, bine înțeles, unde rămân ieftin de localizat și reparat.

  • 🎯 Obiectiv: Scopul este de a expune erorile dintr-un modul, nu de a demonstra că modulul funcționează.
  • ⚪ Orientare: Tehnica este în mare parte de tip cutie albă, completată de cazuri de tip cutie neagră extrase din specificație.
  • ⏩ Paralelism: Mai multe module pot fi testate simultan, ceea ce scurtează fereastra generală de testare.
  • 🔗 Două metode: Modulele sunt combinate fie incremental, pas cu pas, fie neincremental într-o singură trecere.
  • 🧰 Schele: Driverele furnizează date de test unui modul, în timp ce stub-urile înlocuiesc modulele pe care le apelează.
  • 🆚 Proprietate: Testerii scriu teste de module după codare, în timp ce dezvoltatorii scriu teste unitare în timpul acesteia.
  • ⚠️ provocări: Munca neincrementală, testele duble înțelese greșit și depanarea frecventă consumă cea mai mare parte a efortului.
Citește mai mult

Testarea modulelor explicată cu metode, drivere, stub-uri și comparații

Ce este testarea modulului?

Testarea modulelor este un tip de testare software care verifică subprograme, subrutine, clase sau proceduri individuale dintr-un program. În loc să testeze întregul program software dintr-o dată, testarea modulelor recomandă testarea elementelor constitutive mai mici ale programului.

Testarea modulelor este în mare parte orientată spre teste de tip „cutie albă”. Obiectivul testării modulelor nu este de a demonstra funcționarea corectă a modulului, ci de a demonstra prezența unei erori în acesta. Această inversiune contează: o rulare care nu găsește nimic a confirmat foarte puțin, în timp ce o rulare care expune un defect și-a făcut treaba.

Testarea la nivel de modul permite, de asemenea, introducerea paralelismului în procesul de testare, deoarece creează oportunitatea de a testa mai multe module simultan, în loc să se aștepte o construcție completă.

De ce să faceți testarea modulului

Testarea modulelor este recomandată deoarece schimbă aspectele economice ale detectării defectelor.

  • Probabilitatea de a identifica erori sau bug-uri în porțiuni mai mici ale unui program devine mai mare.
  • Mai multe module pot fi testate simultan, prin urmare, abordarea permite testarea paralelă.
  • Complexitatea testării poate fi gestionată cu ușurință, deoarece fiecare modul este raționat separat.
  • Un defect găsit în interiorul unui modul este tracposibil pentru o cantitate mică de cod, astfel încât timpul de depanare scade brusc.

Cum se face testarea modulului?

Proiectarea unui caz de testare este segmentul important al testării modulelor. Atunci când proiectează cazuri de testare pentru un modul, un tester trebuie să ia în considerare două lucruri.

  • Specificații pentru modul
  • Codul sursă al modulului

Analizați logica modulului utilizând unul sau mai multe dintre cutie albă metode și apoi completați aceste cazuri de testare aplicând cutie neagră metodele conform specificației modulului. Valorile realiste contează la fel de mult ca și căile alese, așa că pregătiți date de testare odată cu cazurile, mai degrabă decât ulterior.

Odată ce cazurile de testare sunt proiectate, următorul pas este combinarea modulelor pentru testare. Metoda utilizată este fie o incrementală sau un neincremental metodă.

  • Metodă neincrementală — toate modulele sunt testate independent. Mai întâi combină toate modulele și apoi testează întregul program.
  • Metoda incrementala — fiecare modul este testat mai întâi și apoi este adăugat treptat la colecția testată. Se efectuează o retestare pas cu pas.
  • În cadrul testării incrementale există două abordări, de sus în jos și de jos în sus de testare.
  • Pentru a executa modulul cu datele selectate, este necesar un driver pentru furnizarea datelor de test, monitorizarea execuției și capturarea rezultatelor.

Alegerea dintre cele două metode este un compromis între efortul de configurare și diagnosticabilitate.

Aspect Metoda incrementala Metodă neincrementală
Combinație Câte un modul pe rând, adăugat la o colecție testată Toate modulele combinate, apoi testate împreună
Schelă necesară Mai multe drivere și stub-uri, scrise progresiv Mai puține dubluri de testare, deoarece sunt prezente module reale
Izolare greșită Puternic — o eroare indică modulul tocmai adăugat Slab — o defecțiune ar putea apărea oriunde
Cel mai potrivit pentru Construcții mari cu multe module care interacționează Programe mici cu puține module și cuplare redusă

ARTICOLE SIMILARE

Drivere și Stub-uri în testarea modulelor

Driverul menționat mai sus este o jumătate dintr-o pereche. Deoarece un modul testat rareori se află în partea de sus sau de jos a lanțului de apeluri, testerii înlocuiesc codul fictiv cu orice lipsă de pe ambele părți ale acestuia.

  • Şofer — înlocuiește modulul apelant de deasupra celui testat. Acesta furnizează datele de testare, invocă modulul, monitorizează execuția și capturează rezultatele. Testarea ascendentă depinde de drivere, deoarece modulele inferioare sunt gata înaintea celor superioare.
  • Ciot — înlocuiește un modul apelat sub cel testat. Acceptă apelul și returnează un răspuns fix, cunoscut, astfel încât modulul testat să își poată finaliza calea. Testarea de sus în jos depinde de module, deoarece modulele superioare sunt gata primele.

Un caz rezolvat face ca asocierea să fie concretă. Dacă un modul de calcul al plății este finalizat, în timp ce ecranul de finalizare a comenzii care îl apelează nu este, un șofer furnizează modulului un set de totaluri ale comenzilor și înregistrează ce se întoarce. Dacă serviciul de căutare a taxelor apelat de modul este, de asemenea, neterminat, un fulger returnează o cotă de impozitare fixă, astfel încât calculul rulează în continuare. Niciuna dintre piesele de schelă nu este livrată; ambele sunt eliminate odată ce sosesc modulele reale, motiv pentru care neînțelegerea dublurilor de testare este listată mai târziu ca o provocare recurentă.

Exemple de sfaturi pentru testarea modulelor

Iată câteva sfaturi de luat în considerare înainte de a efectua testarea modulelor.

  • Revvizualizați cazurile de testare înainte de a le utiliza.
  • Evitați confuzia cu privire la sursa discrepanțelor.
  • Folosește instrumente de testare automate.
  • Examinați variabilele care ar trebui să rămână neschimbate.
  • Schimbați modulele între testere pentru a evita autotestele.
  • Reutilizați cazurile de testare.

Al cincilea sfat are mai multă greutate decât sugerează lungimea sa. Un dezvoltator care testează doar modulul recent scris repetă aceleași presupuneri care au produs defectul, așa că rotirea modulelor între persoane este unul dintre cele mai ieftine câștiguri de calitate disponibile.

Testarea unitară vs testarea modulelor

Cei doi termeni sunt folosiți interschimbabil în multe echipe, însă autorul și domeniul de aplicare diferă.

Testarea modulului Testarea unității
Testele de modul sunt o colecție de teste scrise de un tester după ce un cod a fost scris de un dezvoltator Testele unitare sunt o colecție de teste scrise de un dezvoltator în timpul procesului de dezvoltare software
Testarea modulelor poate implica combinarea testelor unitare Testarea unitară poate testa unitățile în mod izolat

Testarea Modulelor vs. Testarea Componentelor vs. Testarea Integrării

Testarea modulelor se află, de asemenea, lângă două niveluri învecinate, ușor de confundat cu aceasta. Tabelul le separă în funcție de ce este testat și cine îl efectuează în mod normal.

Aspect Testarea modulelor Testarea componentelor Testarea integrării
În testare Un subprogram, o clasă sau o procedură O componentă autonomă cu dependențele sale imediate Interfețele dintre modulele combinate
Proprietar obișnuit Tester, după ce codul este scris Laborant Tester de integrare
schelărie Drivere și cioturi Stub-uri pentru dependențe externe Din ce în ce mai puține teste duble
Defect expus Eroare logică în interiorul modulului Eroare de comportament în componentă Eroare de interfață și de transmitere a datelor

În utilizarea de zi cu zi testarea componentelor și testarea modulelor sunt adesea tratate ca aceeași activitate, în timp ce testarea de integrare începe numai după ce modulele individuale au fost trecute fiecare pe cont propriu.

Provocări în testarea modulelor

Acestea sunt provocările cu care se confruntă echipele cel mai des atunci când este introdusă testarea modulelor.

  • Testarea non-incrementală necesită mai multă muncă — combinarea tuturor lucrurilor mai întâi înseamnă că o singură eroare poate trimite testerii înapoi prin întregul program.
  • Testul de neînțelegere se dublează — un stub care returnează o valoare nerealistă produce o rulare verde care nu dovedește nimic.
  • Testele de depanare se fac frecvent — codul de schelă are propriile defecte, iar timpul petrecut pentru repararea unui driver este timp care nu este petrecut pentru testarea modulului.
  • Trebuie să înțelegeți codul — orientarea de tip cutie albă înseamnă că un tester care nu poate citi modulul nu poate proiecta cazuri semnificative pentru acesta.

Întrebări frecvente

Familia xUnit acoperă majoritatea limbajelor de programare, cu biblioteci de simulare care furnizează stub-urile și un instrument de acoperire care arată ce căi au fost atinse. Alegerea urmează limbajul modulului, nu nivelul de testare.

Un model citește sursa modulului, enumeră ramurile și propune un caz pentru fiecare, inclusiv valori limită pe care o trecere manuală le omite adesea. RevVizualizarea rămâne necesară, deoarece cazurile generate afirmă ce face codul, mai degrabă decât ce cere specificația.

Da, și schelele sunt domeniul în care astfel de asistenți performează cel mai bine, deoarece un driver sau un stub este cod repetitiv cu o formă cunoscută. Valorile returnate necesită în continuare o decizie umană, deoarece un stub cu aspect plauzibil poate ascunde chiar defectul căutat.

Este suficient ca fiecare ramură și fiecare limită din modul să fi fost exersată cel puțin o dată. O țintă procentuală în sine este înșelătoare, deoarece o acoperire ridicată a declarațiilor poate lăsa în continuare neîncercate rezultatele întregii decizii.

După ce un modul se compilează și înainte ca interfețele sale să fie exersate împreună. Acesta este primul nivel de testare aplicat codului livrat, motiv pentru care defectele detectate aici nu ajung niciodată în etapele de integrare sau de sistem.

Urmați codul existent. Codul de sus în jos se potrivește proiectelor în care logica de control este scrisă prima, iar modulele inferioare sunt stub; codul de jos în sus se potrivește proiectelor în care modulele utilitare ajung primele, iar driverele le apelează.

Modulul se compilează corect, specificația sa este disponibilă, dependențele sale sunt fie prezente, fie sunt incomplete, iar datele de test sunt gata. Începerea fără specificație transformă exercițiul într-o descriere a codului.

Testarea nu poate dovedi niciodată că un modul nu are defecte, ci doar că a supraviețuit cazurilor încercate. Prin urmare, proiectarea unor execuții care încearcă să deterioreze modulul returnează mai multe informații decât proiectarea unor execuții despre care se aștepta să reușească.

Rezumați această postare cu: