Diferențele dintre testarea unitară, testarea integrării și testarea funcțională

differences between unit testing

O comparație detaliată a testelor de unitate, integrare și funcționale:

Pentru orice aplicație software, atât testarea unității, cât și testarea integrării, sunt foarte importante, deoarece fiecare dintre ele folosește un proces unic pentru a testa o aplicație software.

Dar oricare sau chiar ambele nu pot înlocui testarea funcțională în niciun moment.

Ce veți învăța:

• Testarea unității Vs Testarea integrării Vs Testarea funcțională
• Ce este testarea unitară?
• Ce este testarea integrării?
  • a) Abordarea integrării Big Bang
  • b) Abordare de sus în jos
  • c) Abordare de jos în sus
• Testarea unității vs testarea integrării
• Testarea funcțională
• Diferența exactă
• Concluzie
• Lectură recomandată

Testarea unității Vs Testarea integrării Vs Testarea funcțională

Testarea unității înseamnă testarea individuală a modulelor individuale ale unei aplicații (fără nicio interacțiune cu dependențe) pentru a confirma că codul face lucrurile bine.

Testarea integrării înseamnă a verifica dacă diferite module funcționează bine atunci când sunt combinate împreună ca grup.

Testarea funcțională înseamnă testarea unei porțiuni de funcționalitate în sistem (poate interacționa cu dependențe) pentru a confirma că codul face lucrurile corecte.

Testele funcționale sunt legate de testele de integrare, cu toate acestea, ele semnifică testele care verifică funcționalitatea întregii aplicații cu tot codul care rulează împreună, aproape un super test de integrare.

Testarea unității are în vedere verificarea unei singure componente a sistemului, în timp ce testarea funcționalității ia în considerare verificarea funcționării unei aplicații în raport cu funcționalitatea intenționată descrisă în specificațiile cerințelor de sistem. Pe de altă parte, testarea integrării are în vedere verificarea modulelor integrate în sistem.

Și, cel mai important, pentru a optimiza rentabilitatea investiției (ROI), baza de coduri ar trebui să aibă cât mai multe teste unitare posibil, mai puține teste de integrare și cel mai mic număr de teste funcționale.

Acest lucru este ilustrat cel mai bine în următoarea piramidă de testare:

Testele unitare sunt mai ușor de scris și mai rapid de executat. Timpul și efortul pentru implementarea și menținerea testelor crește de la testarea unitară la testarea funcțională, așa cum se arată în piramida de mai sus.

diferența dintre testarea sistemului și testarea acceptării utilizatorilor

Exemplu:

Să înțelegem aceste trei tipuri de testare cu un exemplu simplificat.

De exemplu . Pentru un telefon mobil funcțional, principalele părți necesare sunt „bateria” și „cartela SIM”.

Exemplu de testare a unității - Bateria este verificată pentru durata de viață, capacitatea și alți parametri. Cartela SIM este verificată pentru activarea sa.

Exemplu de testare a integrării - Bateria și cartela SIM sunt integrate, adică asamblate pentru a porni telefonul mobil.

Exemplu de testare funcțională - Funcționalitatea unui telefon mobil este verificată în funcție de caracteristicile sale și de utilizarea bateriei, precum și de facilitățile cardului SIM.

Am văzut un exemplu în termeni laici.

Acum, să luăm acum un exemplu tehnic de pagină de conectare:

Aproape fiecare aplicație web necesită conectarea utilizatorilor / clienților săi. Pentru aceasta, fiecare aplicație trebuie să aibă o pagină „Login” care să conțină aceste elemente:

• Numele contului
• Parola
• Buton Autentificare / Conectare

Pentru testarea unitară, următoarele pot fi cazurile de testare:

• Lungimea câmpului - câmpuri de nume de utilizator și parolă.
• Valorile câmpului de intrare ar trebui să fie valide.
• Butonul de conectare este activat numai după introducerea valorilor valide (Format și longitudinal) în ambele câmpuri.

Pentru testarea integrării, următoarele pot fi cazurile de testare:

• Utilizatorul vede mesajul de întâmpinare după introducerea valorilor valide și apăsarea butonului de conectare.
• Utilizatorul ar trebui să fie navigat la pagina de întâmpinare sau la pagina de pornire după o intrare validă și făcând clic pe butonul Autentificare.

Acum, după terminarea testelor unitare și de integrare, să vedem suplimentar testarea cazurilor care sunt luate în considerare pentru testarea funcțională:

1. Comportamentul așteptat este verificat, adică utilizatorul este capabil să se conecteze făcând clic pe butonul de autentificare după introducerea unui nume de utilizator și a unei parole valide.
2. Există un mesaj de întâmpinare care să apară după o autentificare reușită?
3. Există un mesaj de eroare care ar trebui să apară pe o autentificare nevalidă?
4. Există cookie-uri de site stocate pentru câmpurile de autentificare?
5. Se poate conecta un utilizator inactivat?
6. Există vreun link „parolă uitată” pentru utilizatorii care și-au uitat parolele?

Există mult mai multe astfel de cazuri care vin în mintea unui tester funcțional în timp ce efectuează testarea funcțională. Dar un dezvoltator nu poate prelua toate cazurile în timp ce construiește cazuri de testare pentru unitate și integrare.

Astfel, există o mulțime de scenarii care nu sunt încă testate, chiar și după testarea de unitate și integrare.

Acum este timpul să examinați unul câte unul unitatea, integrarea și testarea funcțională.

Ce este testarea unitară?

După cum sugerează și numele, acest nivel implică testarea unei „Unități”.

Aici unitatea poate fi cea mai mică parte a unei aplicații care poate fi testată, fie că este cea mai mică funcție individuală, metodă etc. Dezvoltatorii de software sunt cei care scriu cazurile de testare a unității. Scopul aici este de a corespunde cerințelor și comportamentului așteptat al unității.

Mai jos sunt câteva puncte importante despre testarea unității și beneficiile acesteia:

• Testarea unității se face înainte de testarea integrării de către dezvoltatorii de software utilizând tehnici de testare a cutiei albe .
• Testarea unității nu verifică doar comportamentul pozitiv, adică ieșirea corectă în caz de intrare validă, ci și eșecurile care apar cu o intrare nevalidă.
• Găsirea problemelor / erorilor într-un stadiu incipient este foarte utilă și reduce costurile generale ale proiectului. Deoarece testarea unității se face înainte de integrarea codului, problemele găsite în această etapă pot fi rezolvate foarte ușor, iar impactul lor este, de asemenea, foarte redus.
• Un test unitar testează bucăți mici de cod sau funcții individuale, astfel încât problemele / erorile găsite în aceste cazuri de testare sunt independente și nu au impact asupra celorlalte cazuri de testare.
• Un alt avantaj important este că cazurile de testare unitară simplifică și facilitează testarea codului. Deci, devine mai ușor să rezolvați problemele și într-o etapă ulterioară, deoarece doar ultima modificare a codului urmează să fie testată.
• Testul de unitate economisește timp și costuri și este reutilizabil și ușor de întreținut.

JUnit ( Cadrul Java ), PHPUnit (cadru PHP), NUnit (cadru .Net) etc. sunt instrumente populare de testare a unității care sunt utilizate pentru diferite limbi.

Ce este testarea integrării?

Testarea integrării testează integrarea diferitelor părți ale sistemului împreună. Mai întâi sunt integrate două părți sau module diferite ale sistemului și apoi se efectuează testarea integrării.

Scopul testării integrării este de a verifica funcționalitatea, fiabilitatea și performanța sistemului atunci când este integrat.

Testarea integrării se efectuează pe modulele testate mai întâi pe unitate și apoi testarea integrării definește dacă combinația dintre module oferă sau nu rezultatul dorit.

Testarea integrării poate fi efectuată fie de testeri independenți, fie de dezvoltatori.

Există 3 tipuri diferite de abordări de testare a integrării. Să discutăm pe fiecare dintre ele pe scurt:

a) Abordarea integrării Big Bang

În această abordare, toate modulele sau unitățile sunt integrate și testate în ansamblu în același timp. Acest lucru se face de obicei atunci când întregul sistem este pregătit pentru testarea integrării într-un singur moment.

Vă rugăm să nu confundați această abordare a testării integrării cu testarea sistemului, doar integrarea modulelor sau unităților este testată și nu întregul sistem așa cum se face în testarea sistemului.

Abordarea big bang este majoră avantaj este că totul integrat este testat odată.

Unul major dezavantaj este că devine dificil să identificăm eșecurile.

Exemplu: În figura de mai jos, Unitatea 1 până la Unitatea 6 sunt integrate și testate folosind abordarea Big Bang.

b) Abordare de sus în jos

Integrarea unităților / modulelor este testată pas cu pas de la nivelurile de sus până jos.

Prima unitate este testată individual prin scriere test STUBS . După aceasta, nivelurile inferioare sunt integrate unul câte unul până când ultimul nivel este asamblat și testat.

Abordarea de sus în jos este un mod foarte organic de integrare, deoarece este în concordanță cu modul în care lucrurile se întâmplă în mediul real.

Singurul îngrijorare cu această abordare este că funcționalitatea majoră este testată la final.

c) Abordare de jos în sus

Unitățile / modulele sunt testate de la nivelul inferior până la nivelul superior, pas cu pas, până când toate nivelurile de unități / module sunt integrate și testate ca o singură unitate. Programele de stimulare numite ȘOFERE sunt utilizate în această abordare. Este mai ușor să detectați probleme sau erori la nivelurile inferioare.

Maiorul dezavantaj Această abordare constă în faptul că problemele de nivel superior pot fi identificate doar la sfârșit, atunci când toate unitățile au fost integrate.

Testarea unității vs testarea integrării

După ce am avut suficiente discuții despre testarea unității și testarea integrării, să trecem rapid prin diferențele dintre cele două din tabelul următor:

Testarea funcțională

LA tehnica de testare a cutiei negre , unde funcționalitatea aplicației este testată pentru a genera ieșirea dorită la furnizarea unei anumite intrări se numește „testare funcțională”.

În a noastră procese de testare software , facem acest lucru scriind cazuri de testare conform cerințelor și scenariilor. Pentru orice funcționalitate, numărul cazurilor de test scrise poate varia de la unul la multe.

Testele cuprind, în principiu, următoarele părți:

• Rezumatul testului
• Condiții preliminare (dacă există)
• Testați pașii de introducere a cazului
• Date de testare (dacă există)
• Ieșire preconizată
• Note (dacă există)

„Bazat pe cerințe” și „Bazat pe scenarii comerciale” sunt cele două forme de testare funcțională care se efectuează.

În testarea bazată pe cerințe, cazurile de testare sunt create conform cerințelor și testate în consecință. Într-un test funcțional bazat pe scenarii de afaceri, testarea se efectuează ținând cont de toate scenariile dintr-o perspectivă de afaceri.

Cu toate acestea, majorul dezavantaj de testare funcțională este redundanța probabilă în testare și posibilitatea de a pierde unele erori logice.

Diferența exactă

Să ne uităm la diferențele lor.

Iată câteva dintre cele mai importante:

Citește și => Ce este testarea caracteristicilor

ce este testarea cutiei negre cu exemplu

Concluzie

Toate aceste trei tipuri de testare sunt corelate.

Pentru a obține o acoperire completă, este necesar să existe teste unitare pentru căile / liniile de cod, teste funcționale și de integrare pentru asigurarea faptului că „unitățile” funcționează împreună.

Sper că acest articol ți-ar fi dat o idee clară despre testarea unității, integrarea și funcționalitatea, împreună cu diferențele lor, deși există multe mai multe la aceste forme de testare !!

Lectură recomandată

• Cele mai bune instrumente de testare software 2021 (Instrumente de automatizare a testelor de calitate)
• Spock pentru integrare și testare funcțională cu seleniu
• Testarea funcțională Vs testarea nefuncțională
• Descărcare eBook Descărcare Primer
• Top 10 instrumente de testare a integrării pentru a scrie teste de integrare
• Diferențele cheie dintre testarea cutiei negre și testarea cutiei albe
• Ghid complet de testare funcțională cu tipurile și exemplul său
• Testarea funcțională vs. Testarea performanței: ar trebui să se facă simultan?