static testing dynamic testing difference between these two important testing techniques
Testarea este Verificare si validare . Știm cu toții că este nevoie de 2 V pentru a finaliza testarea.
În articolul de astăzi, vom face puțină lumină Testarea statică . Se mai numește și Verificare. Vom afla totul despre asta și vom pune un accent deosebit pe acest lucru, deoarece Testare dinamică primește adesea atenția maximă și are nenumărate articole care o detaliază.
Cu toate acestea, nicio discuție cu privire la testarea statică nu ar fi completă fără o explicație a ceea ce înseamnă omologul său, testarea dinamică. Testarea dinamică este validarea, celălalt „V”.
Testarea dinamică are loc atunci când lucrați cu sistemul actual (nu cu vreun artefact sau model care reprezintă sistemul), furnizând o intrare, primind ieșire și comparând ieșirea cu comportamentul așteptat. Lucrul practic cu sistemul este intenționat să găsească erori.
În timpul acestui proces, vom înțelege cum următoarele două concepții greșite comune despre testare nu sunt adevărate:
- Testarea este o activitate care vine la final
- Este realizat numai de testeri, iar ceilalți nu au ce face
Să începem cu o referință rapidă la modelul v :
- Pe partea stângă din modelul V, avem activități care nu sunt efectuate de echipa QA.
- Pe partea dreaptă , avem unele dintre ele care sunt îngrijite de echipa Dev, altele de testeri și altele de utilizatori.
Sa incepem cu - Adunarea cerințelor . Este realizat de Business Analyst și de alte conduceri de nivel superior - documentul de ieșire pentru această fază este documentul de cerințe de afaceri, BRD.
referință nedefinită la c ++ principal
Următoarea etapă este Proiectarea sistemului . Proiectarea sistemului este o fază în care cerințele de afaceri sunt traduse în cerințe funcționale, în FRD (documentul de cerințe funcționale).
Când se întâmplă traducerea, echipa Dev (care este principalul actor în acest pas) va trece peste documentul BRD pas cu pas, pagină cu pagină și linie cu linie. Chiar dacă obiectivul principal este de a consuma cerințele comerciale de dragul traducerii, documentul BRD este revizuit la rândul său.
Un exemplu: Spuneți că acesta este BRD pentru un site bancar important în materie de securitate. Există o secțiune în BRD care vorbește despre regulile de parolă pentru diferiții utilizatori care creează un cont pe site-ul bancar online. Una dintre reguli este: Un utilizator nu poate folosi o parolă pe care o folosește pentru alte conturi.
Acest lucru nu este posibil. Deoarece, un site poate sugera doar modul în care utilizatorul ar trebui să seteze acreditările de conectare, dar nu există nicio modalitate, această restricție poate fi impusă. Deci, această cerință nu este fezabilă - cu alte cuvinte, nu poate fi realizată prin intermediul software-ului.
Să luăm acum în considerare următoarele puncte pe baza acestui exemplu:
- Cum se determină că această cerință nu este construibilă și, prin urmare, nu poate fi testată (cu alte cuvinte, nu este fezabilă)? Avem site-ul băncii și apoi setăm datele de conectare și parola - și apoi ne dăm seama că acest lucru nu este posibil? Nu, ne bazăm pur și simplu pe recenzia noastră despre BRD și, desigur, pe un bun simț al afacerii.
- Testăm această cerință? Sigur, dar pur bazat pe simțul teoretic, conceptual, dar nu pe AUT-ul propriu-zis (Aplicație sub test).
- Care este forma fizică a acestui test? -O lectură simplă sau o revizuire formală a BRD sau o analiză de fezabilitate și mai formală a cerințelor afacerii.
Revenind la concepțiile noastre greșite:
- Cine efectuează această recenzie a BRD? - În principal echipa de dezvoltatori și alte echipe tehnice care sunt responsabile pentru crearea produsului. Nu testeri.
- Această revizuire se desfășoară la sfârșitul creării produsului? Nu, chiar în stadiul inițial al dezvoltării proiectului. Prin urmare, nu doar sfârșitul.
Tehnici de testare statică:
Pentru a rezuma, testarea statică este partea de verificare a testării software care urmează metodele de:
- Recenzii de documente
- Rezolvări
- Inspecţie
- Analiza de fezabilitate sau orice altă formă de analiză pentru a determina dacă software-ul este ceea ce ar trebui să fie sau nu
- Revizuire a Codului
Pentru a cita CSTE CBOK, „Verificarea răspunde la întrebarea„ Am construit sistemul potrivit? ” în timp ce validările se adresează, „Am construit sistemul corect?”
Următoarele sunt toate activitățile de testare statică care se întâmplă în partea stângă a modelului V.
Etapa SDLC | Ieșire | Verifică | Actori |
---|---|---|---|
Adunarea cerințelor de afaceri | BRD (document de cerințe de afaceri) | Document de aplicare (dacă există) | |
Proiectarea cerințelor de sistem | FRD (Document de cerințe funcționale) | Revizuiește / verifică BRD | Dev, Echipe tehnice |
Proiectarea cerințelor tehnice | TDD (Document de proiectare tehnică) | Revizuiește / verifică FRD | Dev, Echipe tehnice |
Proiectare (cod) | Cod | Revizuiește / verifică TDD. Revizuirea codului de către echipa de dezvoltatori pentru completitudine, format etc. | Dev, Echipe tehnice |
Notă: Aceste informații pot fi extrapolate pentru proiecte, urmând orice metodologii de dezvoltare, deoarece pașii vor fi mai mult sau mai puțin similari.
În partea dreaptă a modelului V este validarea.
Tehnici de testare dinamică:
- Testarea unitara
- Testarea integrării
- Testarea sistemului
Unitatea, integrarea, sistemul și fazele UAT se referă la crearea de teste care să fie efectuate pe AUT în timpul diferitelor etape ale dezvoltării sale. Chiar dacă testele vizează validarea diferitelor tipuri de cerințe, toate sunt teste la fel.
Deci, orice formă de testare în care avem un test care trebuie executat pe un AUT și rezultatul acestuia este necesar pentru a determina rezultatul testului (reușit sau nu) - este validare.
Acum, ar fi bine să generalizăm că pe partea dreaptă (RHS) a modelului V nu există deloc verificare? Raspunsul este nu.
Toate testele care se creează în fiecare etapă de pe RHS sunt revizuite de mai multe ori în timpul etapei de creare / finalizare a testului. Procesul detaliat de revizuire a documentației de testare este la https://www.softwaretestinghelp.com/test-documentation-reviews/
Pe RHS:
- Testele și codul sunt revizuite în etapele de testare a unității / integrării de către dezvoltatori.
- Testele de sistem sunt supuse unei evaluări inter pares în timpul documentației lor și la finalizare sunt supuse unei revizuiri de către echipa de dezvoltatori și analistul de afaceri.
- Testele UAT sunt supuse unei revizuiri de către echipa QA, precum și de către utilizatori, înainte de începerea UAT.
Concluzie
În concluzie, testarea statică este o tehnică importantă de testare care ia forma revizuirii cerințelor afacerii, revizuirii funcționale a cerințelor, revizuiri de proiectare, pasaje de cod și revizuire a documentației de testare. Este o activitate continuă și nu este realizată doar de testeri.
Validare, partea de testare dinamică este mai practică și se întâmplă pe produsul în sine și nu pe un artefact sau o reprezentare a produsului. Un proces mult formal de identificare a cazului / condiției de testare, considerații de acoperire, execuție și raportare a defectelor marchează toate metodele de testare dinamică.
Despre autor: Acest articol este scris de Swati S., membru al echipei STH.
Vă rugăm să împărtășiți comentariile, întrebările și experiențele dvs. pe tema testării statice și dinamice.
Lectură recomandată
- Diferența dintre Desktop, Client Server Testing și Web Testing
- Tehnici de estimare agilă: o estimare adevărată într-un proiect agil
- Testarea cutiei negre: un tutorial detaliat cu exemple și tehnici
- Ce este testarea conformității (testarea conformității)?
- Care este diferența dintre testarea SIT vs UAT?
- Testarea alfa și testarea beta (un ghid complet)
- Diferențele cheie dintre testarea cutiei negre și testarea cutiei albe
- Diferențele dintre testarea unitară, testarea integrării și testarea funcțională