functional testing vs performance testing
Testarea funcțională vs. testarea performanței:
Diferente intre Testarea performanței, testarea sarcinii și testarea stresului au fost explicate cu exemple în ultimul nostru tutorial.
Testarea software acoperă o gamă largă de domenii în care poate apărea orice verificare sau validare a funcționalității software-ului. Ocazional, aspectele nefuncționale devin mai puțin preocupante pentru aspectele funcționale. Nu sunt efectuate practic; simultan în timpul testării software-ului.
=> Faceți clic aici pentru seriile complete de testare a performanței
Acest articol explică avantajele suplimentare ale calității produsului software în timpul diferitelor scenarii din ciclul de viață al testării software-ului când atât funcționale cât și nefuncționale sunt luate simultan.
Ce veți învăța:
- Diferență rapidă între testarea performanței și testarea funcțională
- De ce testarea funcțională și testarea performanței ar trebui făcute simultan?
- Studiu de caz
- Concluzie
- Lectură recomandată
Diferență rapidă între testarea performanței și testarea funcțională
Sl NU | Testarea funcțională | Test de performanta |
---|---|---|
unu | Pentru a verifica acuratețea software-ului cu intrări definite față de ieșirea așteptată | Pentru a verifica comportamentul sistemului în diferite condiții de încărcare |
Două | Poate fi manual sau automat | Poate fi realizat eficient dacă este automatizat |
3 | Un utilizator care efectuează toate operațiunile | Mai mulți utilizatori care efectuează operațiunile dorite |
4 | Implicare necesară de la client, tester și dezvoltator | Implicare necesară din partea clientului, testerului, dezvoltatorului, echipei DBA și N / W Management |
5 | Mediul de testare dimensionat pentru producție nu este obligatoriu, iar cerințele H / W sunt minime | Cerințe apropiate de mediul de testare a producției și mai multe facilități H / W pentru a completa încărcătura |
De ce testarea funcțională și testarea performanței ar trebui făcute simultan?
Testarea funcțională devine mult mai importantă pentru orice pre-lansare a software-ului. Bazat pe rezultate reale verificare si validare în mediul de producție sau de testare replicat, se întâmplă de obicei testarea.
Scurgerea defectelor poate deveni una dintre cele mai mari probleme:
Testerii au mai multă responsabilitate decât dezvoltatorii în ceea ce privește calitatea produsului. Practic, nu vor ca produsul testat să prezinte scurgeri de defecte. Testerii tind, în general, să efectueze doar teste funcționale pentru a realiza acest lucru.
Următoarea este o conversație între aManager de test și un tester :
(Managerul de testare este denumit „TM” și Testerul „TR”)
TM : Hei prietene ... Cum ne descurcăm testarea produsului „A”?
TR : Da ... Progresăm într-un mod mai mare.
TM : E fantastic ... Și care este scopul nostru în ceea ce privește testarea performanței în timp ce testarea funcțională este în curs de execuție?
TR : Nu le acoperim, livrabilele noastre ar trebui să fie doar în zona funcțională și nu în zona nefuncțională. De asemenea, mediul de testare pe care îl folosim nu este o replică exactă a producției.
Există câteva întrebări din conversația de mai sus care trebuie luate în considerare:
- Testarea funcțională are un factor dependent de performanță?
- Ce se întâmplă dacă performanța software-ului este degradată, dar livrarea produsului are loc fără a verifica performanța?
- Testarea performanței - coexistă în cadrul procesului de testare funcțională?
A devenit o practică generală pentru testeri să nu lucreze la aspectele nefuncționale decât dacă li se solicită acest lucru. Este obișnuit să eviți testarea nefuncțională până când clientul a raportat probleme cu performanța software-ului testat.
Așadar, există 2 întrebări pe care trebuie să le luați în considerare:
- Performanță - are impact asupra testării funcționale?
- Continuăm testarea performanței ca un produs separat, chiar dacă îi îngrijorează pe client?
Testarea performanței este important !
exemple de programe c ++ care utilizează funcții
Software-ul funcționează pe diferite arhitecturi și următoarele modele, inclusiv:
- Modele de răspuns necesare pentru răspuns
- Sisteme bazate pe tranzacții
- Sisteme bazate pe sarcină
- Sisteme bazate pe replicarea datelor
Comportamentul de testare funcțională a modelului sistematic menționat mai sus depinde de performanța sistemului.
Punctul de vedere al automatizării necesită multă atenție în ceea ce privește testarea performanței.
Următoarea este o conversație între aclient și Managerul de teste.
(Clientul este denumit „CL” și Managerul de testare „TM”)
CL : Prin urmare, venind la soluția pe care am solicitat-o, sper că vor exista mai multe iterații ale testării care se întâmplă în prezent.
TM : Da, acest lucru se poate face. După cum ați spus, va exista o probabilitate mai mare de testare iterativă, am dori să propunem automatizarea pentru a face față testării funcționale (de regresie).
CL : OK bine, vă rugăm să ne trimiteți abordarea dvs., astfel încât să putem aproba acest lucru. Automatizarea va avea un randament mult mai mare cu un efort minim.
TM : Exact. Vom lucra la abordare și ne vom întoarce cu o dovadă a conceptului.
Din conversația de mai sus, este clar că nevoia clienților este de a optimiza eficiența.
Studiu de caz
Compania ABC lucrează la un proiect pentru dezvoltarea software-ului A. Testarea software-ului A este realizată de compania XYZ.
Contractul pentru compania ABC și XYZ are unele restricții pentru colaborarea lor. Orice discuție între cele două companii ar trebui să aibă loc o dată pe săptămână sau de trei ori pe lună. Sistemul funcționează pe un model de mod solicitare-răspuns. Faza de dezvoltare a fost finalizată de Compania ABC.
Acum este momentul ca Compania XYZ să efectueze testarea funcțională formală a software-ului A. XYZ începe să lucreze la testarea software-ului A. Au oferit o soluție curată asupra software-ului și au dat „Go” pentru implementare live după 2 cicluri de testare.
În ciuda certificatului de calitate de la echipa de testare, implementarea live nu a mers bine. Au existat o mulțime de bug-uri de post-producție. Au existat un număr mare de probleme cu care s-au confruntat clienții, inclusiv întreruperea funcționalității proceselor de business end-to-end.
Deci acum ce esteproblemă?
- Este o problemă cu o restricție de colaborare între echipa de dezvoltare și testare?
- Este faptul că cerințele nu au fost capturate 100%?
- Este faptul că produsul nu a fost testat într-un mediu de testare adecvat?
- Sau alte cauze?
După o cercetare și o analiză atentă,au fost deduse următoarele:
- Au existat puține aplicații dependente și interdependente care au avut probleme de performanță în timp ce preluau răspunsurile.
- Intrările de test utilizate nu au fost absolute.
- Robustețea software-ului nu a fost îngrijită.
- O mulțime de probleme de sincronizare între multiplele aplicații independente.
- Testarea software-ului a efectuat mai multe refaceri care nu au fost luate în considerare.
Prin urmare, dupăacțiuni de remedierea intervenit echipa de planificare, au fost sugerate următoarele:
- Interacțiunea dintre echipa de dezvoltare și echipa de testare trebuie să fie sporită.
- Toate aplicațiile dependente trebuie conectate și incluse în testarea funcțională a sistemului
- Valoarea expirării solicitării și răspunsului trebuie mărită pentru a da loc mediilor neproductive
- În testarea funcțională trebuie folosite diverse intrări, între simple și complexe
- Testarea nefuncțională, în special testarea performanței și a sarcinii, trebuie făcută conform recomandărilor echipei de remediere.
- În plus față de testarea sistemului, trebuie efectuată testarea integrării sistemului.
- Trebuie prevăzut un interval de timp minim între oricare două iterații de testare. Aceasta este pentru re-testarea erorilor identificate anterior.
- Toate erorile identificate în iterațiile anterioare ar trebui să fie remediate în iterația curentă.
Echipa de testare a implementat toate acțiunile propuse și a existat un număr mare de defecte descoperite în puțin timp.
Observații:
- Programul de implementare live a software-ului s-a îmbunătățit semnificativ prin optimizarea timpilor ciclului de testare.
- S-au înregistrat progrese semnificative în optimizarea calității software-ului. Prin urmare, a existat o scădere extraordinară a biletelor de asistență după implementare.
- Re-lucrările au fost reduse și au fost testate iterații în loc de re-lucrări. Între diferitele iterații, s-au observat îmbunătățiri mai bune ale calității.
Concluzie
Efectuarea testării nefuncționale în timpul executării testului funcțional este mai avantajoasă și va adăuga mai multe beneficii calității generale a software-ului. Aceasta va identifica erorile de performanță (limitate la mediul de testare și dependență) și, prin urmare, va reduce situațiile de presupuneri funcționale de problemă.
Trebuie făcută o planificare suficientă pentru efectuarea testării funcționale și nefuncționale (la un nivel minim) pentru a menține o relație puternică între ceilalți actori ai proiectului.
Despre autor: Acesta este un articol scris de Nagarajan. Lucrează ca șef de testare cu peste 6 ani de experiență în testări în diverse domenii funcționale, cum ar fi bancar, linii aeriene, telecomunicații, atât în ceea ce privește manualul, cât și automatizarea.
Următorul nostru tutorial va explica mai multe despre planul de testare a performanței și strategia de testare.
=> Vizitați aici pentru seria completă de testare a performanțelor
Lectură recomandată
- Testarea funcțională Vs testarea non-funcțională
- Cele mai bune instrumente de testare software 2021 [Instrumente de automatizare a testelor de calitate]
- Testarea performanței vs Testarea sarcinii vs Testarea stresului (Diferență)
- Georgia Tech își standardizează testarea performanței pe RadView WebLOAD
- Diferența dintre Desktop, Client Server Testing și Web Testing
- Descărcare eBook Descărcare Primer
- Diferențele dintre testarea unitară, testarea integrării și testarea funcțională
- Testarea performanței în cloud: Furnizori de servicii de testare a încărcării bazate pe cloud