Ce este Test Harness? (Exemple)

Testați harness în testarea software-ului

Testați harness în testarea software-ului este o colecție de stub-uri, drivere și alte instrumente de asistență necesare pentru a automatiza execuția testului. Harnașul de testare execută teste utilizând o bibliotecă de teste și generează rapoarte de testare. Harnașul de testare conține toate informațiile necesare pentru compilarea și rularea unui test, cum ar fi cazurile de testare, portul de implementare țintă (TDP), fișierul sursă testat, stub-uri etc.

Simplu spus, un sistem de hamuri încadrează componenta pe care doriți să o verificați într-un mediu controlat. Modulele învecinate care lipsesc sunt înlocuite cu programe fictive mici, intrările sosesc dintr-un set de date fix, iar fiecare rezultat este scris într-un jurnal în loc să fie citit de pe un ecran. Secțiunile care urmează explică de ce echipele construiesc un astfel de sistem, din ce este alcătuit, cum funcționează și unde se potrivește.

De ce să folosiți Test Harness?

Există un sistem de ham pentru a elimina așteptarea din ciclul de testare. Deoarece simulează orice nu este încă gata, un testare software Echipa poate începe verificarea comportamentului în primul sprint, mai degrabă decât după integrarea finală. Diagrama de mai jos arată unde se află o rețea între scripturile de testare și aplicația testată.

• Automatizați procesul de testare
• Executați seturi de teste de cazuri de testare
• Generați rapoarte de testare asociate
• Suport pentru depanare
• Pentru a înregistra rezultatele testelor pentru fiecare dintre teste
• Ajută dezvoltatorii să măsoare acoperirea codului la nivel de cod
• Creșteți productivitatea sistemului prin automatizare
• Îmbunătățiți calitatea componentelor software și a aplicațiilor
• Pentru a gestiona condiția complexă pe care testatorii le sunt dificil de simulat

Aceste câștiguri contează cel mai mult în ciclurile de lansare scurte. Când codul este livrat de mai multe ori pe săptămână, un defect care supraviețuiește până la etapa de integrare costă mult mai mult. tracmai mult decât unul prins de un ciot în ziua în care a fost scris. Această recompensă apare, însă, doar atunci când hamul este asamblat din piesele potrivite.

Componentele cheie ale unui cablaj de testare

Un ham nu este un singur program, ci un ansamblu de piese, fiecare eliminând un obstacol care altfel ar împiedica rularea nesupravegheată a unui test.

• Scripturi de testare: Instrucțiuni automate care precizează pașii de efectuat și rezultatul așteptat, scrise conform script de testare convenții.
• Motor de execuție a testelor: Runner-ul care citește scripturile în ordine, rezolvă dependențele și declanșează execuția secvențială sau paralelă.
• Depozit de date de testare: Valorile de intrare păstrate în afara scriptului în CSV, JSON, XML sau o bază de date inițializată, adesea completate de testarea instrumentelor de generare a datelor.
• drivere: Module de apelare fictive care invocă componenta testată atunci când stratul superior real, cum ar fi o interfață cu utilizatorul, este neterminat.
• Stubs: Modulele fictive apelau la returnarea de răspunsuri predefinite, de exemplu, un serviciu de plată care răspundea „Plată reușită” fără a contacta o bancă.
• Validator de ieșire: Logică de afirmație care compară rezultatul real cu valoarea așteptată și marchează fiecare caz ca fiind admis sau eșuat.
• Stratul de înregistrare și raportare: Marcaje temporale, capturi de ecran, ieșiri din consolă și un rezumat al execuției care evidențiază fiecare eșec tracposibil ulterior.

Îndepărtați orice piesă și hamul nu mai este automat, deoarece atunci trebuie furnizat ceva manual la fiecare cursă.

Cum funcționează un ham de testare?

Un ham repetă aceeași buclă la fiecare execuție. Cunoașterea acelei bucle îți spune exact unde se află propriul tău... testarea automatizării conectările de active și care pas eșuează atunci când o rulare devine roșie.

1. Pregătiți mediul: Cablajul rezolvă configurația mediului, deschide conexiuni și încarcă dispozitive de fixare, astfel încât fiecare rulare începe din aceeași stare cunoscută.
2. Încărcați scripturile de testare: Scripturile, parametrii și rezultatele așteptate sunt citite din repozitoriu. Nimic nu este introdus în timpul execuției, ceea ce face ca o a doua execuție să fie comparabilă cu prima.
3. Înlocuiți modulele lipsă: Șoferii înlocuiesc apelanții care nu există încă, iar apelurile scurte înlocuiesc serviciile neterminate, instabile sau costisitoare de apelat.
4. Invocați aplicația testată: Motorul de execuție declanșează fluxul de lucru descris de script, fie că este vorba de un apel de metodă, de un API cerere sau o interacțiune cu browserul.
5. Capturați rezultatul real: Valorile returnate, sarcinile utile de răspuns, rândurile bazei de date, liniile de jurnal și starea ecranului sunt toate înregistrate pe măsură ce sunt produse.
6. Comparați cu rezultatele așteptate: Validatorul de ieșire activează fiecare valoare capturată. Orice nepotrivire marchează cazul ca fiind eșuat și înregistrează atât valoarea așteptată, cât și cea observată.
7. Înregistrare și raportare: Ham-ul scrie un marcaj temporal trace a rulării și generează un raport de succes/eșec pe care un dezvoltator îl poate citi fără a rula din nou nimic.
8. Dărâma: Datele temporare, conexiunile și starea stub-ului sunt șterse, astfel încât următorul caz nu poate moșteni reziduuri de la acesta.

💡 Sfat: Reîmprospătați modulele de răspuns ori de câte ori se modifică modulul real. Un modul de răspuns care încă răspunde cu formatul din trimestrul trecut va raporta o rulare verde, în timp ce integrarea live este deja defectă.

Un exemplu practic concretizează bucla. Să presupunem că pagina de finalizare a comenzii este gata, dar gateway-ul de plată nu. Un driver lansează cererea pe care interfața ar trimite-o în mod normal, un stub răspunde mai întâi cu „Plată reușită” și apoi cu un timeout, iar validatorul confirmă comanda într-un caz și o solicitare de reîncercare în celălalt. Ambele căi sunt verificate înainte ca echipa gateway-ului să scrie o linie de cod.

Există două contexte în care este utilizat Test Harness

Același mecanism servește două scopuri distincte, iar vocabularul se schimbă ușor în funcție de care dintre ele te afli.

1. Testarea automatizării: Acesta conține scripturi de testare, parametri necesari pentru a rula aceste scripturi și pentru a aduna rezultate pentru a le analiza
2. Testare de integrare: Este folosit pentru a pune împreună două unități de cod sau modul care interacționează între ele pentru a verifica dacă comportamentul combinat este sau nu conform așteptărilor.

Luați în considerare un modul de autentificare și un modul de profil care trebuie să facă schimb de un token de utilizator. În contextul integrării, un driver simulează o autentificare reușită și transmite token-ul logicii de profil, astfel încât harta datelorping, verificarea permisiunilor și randarea ecranului pot fi verificate înainte de finalizarea serviciului de autentificare real. În contextul automatizării, aceeași pereche de cazuri este adăugată la o suită și rulată din nou la fiecare compilare, fără ca cineva să o mai atingă.

Tipuri de hamuri de testare

Deoarece software-ul este construit în straturi, un sistem de hamuri este de obicei specializat în stratul pe care îl verifică. Patru tipuri acoperă aproape fiecare proiect.

A cablaj de testare unitară exersează cele mai mici porțiuni de cod, cum ar fi o singură funcție sau metodă, fiecare dependență fiind înlocuită de un stub. Este cel mai rapid de executat și cel mai ieftin de întreținut, motiv pentru care testarea unitara Suitele sunt de obicei primul sistem de gestionare pe care o echipă îl construiește. Testarea unui calcul de impozit fără a atinge modulul de facturare este o utilizare tipică.

An cablaj de testare a integrării verifică dacă două sau mai multe module cooperează corect și este stratul unde apar nepotrivirile de date și apelurile eșuate. Este cablajul descris în testarea de integrare contextul de mai sus, de exemplu verificarea faptului că un serviciu de comenzi transmite sarcina utilă corectă unui serviciu de plată.

A cablaj de testare a sistemului gestionează un flux complet end-to-end prin interfață, serviciu și bază de date, astfel încât testarea sistemului poate confirma că regulile de business sunt valabile odată ce fiecare strat este prezent. A ham de testare de regresie apoi rulează din nou suita acumulată după fiecare modificare, ceea ce face ca testarea regresiei practic atunci când trebuie repetate câteva sute de scenarii la fiecare îmbinare.

Testați unelte pentru cablaj

Fiecare dintre aceste tipuri este construit în mod normal pe baza unui instrument existent, mai degrabă decât de la zero. Cele două opțiuni clasice rămân cadrele de lucru la nivel de unitate:

• Junit: Instrument utilizat în timpul utilizării Java
• Nunit: Instrument folosit pentru utilizare .Cadru net

Dincolo de aceste două, majoritatea echipelor adaugă instrumente care extind hamul la browser, la stratul API sau la profilul de încărcare. Tabelul de mai jos mapează opțiunile comune în funcție de rolul pe care îl joacă fiecare.

Indiferent de combinația pe care o alegeți, cablajul se amortizează doar atunci când funcționează nesupravegheat, așa că conectați-l la integrare continuă lucrare devreme. Un catalog mai amplu de opțiuni este listat în Guru99 instrumente de testare rezumat. O distincție încă provoacă confuzie și merită să o clarificați înainte de a alege ceva.

Test Harness vs Test Framework

Un sistem de împerechere (ham) și un framework de automatizare sunt adesea tratate ca fiind același lucru, însă răspund la întrebări diferite: sistemul de împerechere este cel care execută un test, în timp ce framework-ul este structura în interiorul căreia sunt proiectate testele. Tabelul de mai jos le prezintă una lângă alta.

Întrebări frecvente