what is regression testing
Ce este testarea de regresie?
Testarea prin regresie este un tip de testare care se face pentru a verifica dacă o modificare a codului din software nu are impact asupra funcționalității existente a produsului. Aceasta este pentru a vă asigura că produsul funcționează bine cu funcționalități noi, remedieri de erori sau orice modificare a funcției existente. Cazurile de testare executate anterior sunt reexecutate pentru a verifica impactul schimbării.
=> Faceți clic aici pentru seria completă de programe de testare
Testarea de regresie este un tip de testare software în care cazurile de testare sunt reexecutate pentru a verifica dacă funcționalitatea anterioară a aplicației funcționează bine și noile modificări nu au introdus erori noi.
Acest test poate fi efectuat pe o nouă versiune atunci când există o schimbare semnificativă în funcționalitatea originală, chiar și într-o singură soluție de eroare.
Regresia înseamnă retestarea părților neschimbate ale aplicației.
Ce veți învăța:
- Tutoriale acoperite în această serie
- Prezentare generală a testului de regresie
- Când să efectuați acest test?
- Testarea de regresie poate fi efectuată manual?
- Instrumente automate de testare a regresiei
- De ce testul de regresie?
- Tipuri de testare de regresie
- Câtă regresie este necesară?
- Ce facem în verificarea regresiei?
- Tehnici de testare a regresiei
- Cum să selectați o suită de testare de regresie?
- Cum se efectuează testarea de regresie?
- Regresia în agilitate
- Avantaje
- Dezavantaje
- Regresia aplicației GUI
- Diferența dintre regresie și re-testare
- Șablon de plan de testare de regresie (TOC)
- Concluzie
- Lectură recomandată
Tutoriale acoperite în această serie
Tutorial nr. 1: Ce este testarea de regresie (Acest tutorial)
Tutorial nr. 2: Instrumente de testare de regresie
Tutorial # 3: Retest Vs Testare de regresie
Tutorial # 4: Testare automată de regresie în Agile
Prezentare generală a testului de regresie
Testul de regresie este ca o metodă de verificare. Cazurile de testare sunt, în general, automatizate, deoarece cazurile de testare sunt necesare pentru a se executa din nou și din nou, iar rularea manuală a acelorași cazuri de testare este consumatoare de timp și de asemenea obositoare.
De exemplu, Luați în considerare un produs X, în care una dintre funcționalități este de a declanșa confirmarea, acceptarea și trimiterea e-mailurilor atunci când se face clic pe butoanele Confirmare, Acceptare și Expediere.
Unele probleme apar în e-mailul de confirmare și, pentru a remedia problema, se fac unele modificări de cod. În acest caz, nu numai e-mailurile de confirmare trebuie testate, ci și e-mailurile de acceptare și expediate trebuie testate pentru a se asigura că modificarea codului nu le-a afectat.
Testarea de regresie nu depinde de nici un limbaj de programare precum Java, C ++, C #, etc. Este o metodă de testare care este utilizată pentru a testa produsul pentru modificări sau pentru orice actualizări care se fac. Verifică dacă orice modificare a unui produs nu afectează modulele existente ale produsului.
Verificarea faptului că erorile sunt remediate și că noile funcții adăugate nu au creat nicio problemă în versiunea anterioară de lucru a software-ului.
Testerii efectuează testarea funcțională atunci când este disponibilă o nouă versiune pentru verificare. Intenția acestui test este de a verifica modificările făcute în funcționalitatea existentă și funcționalitatea nou adăugată.
La finalizarea acestui test, testerul ar trebui să verifice dacă funcționalitatea existentă funcționează conform așteptărilor și noile modificări nu au introdus niciun defect în funcționalitatea care funcționa înainte de această modificare.
Testul de regresie ar trebui să facă parte din ciclul de eliberare și trebuie luat în considerare în estimarea testului.
Când să efectuați acest test?
Testarea de regresie se efectuează de obicei după verificarea modificărilor sau a funcționalității noi. Dar nu este întotdeauna cazul. Pentru eliberarea care durează luni până la finalizare, testele de regresie trebuie încorporate în ciclul de testare zilnic. Pentru versiunile săptămânale, testele de regresie pot fi efectuate atunci când Testarea funcțională este terminată pentru modificări.
Verificarea regresiei este o variantă a retestării (care este pur și simplu repetarea unui test). La retestare, motivul poate fi orice. Spuneți, ați testat o anumită caracteristică și a fost sfârșitul zilei - nu ați putut termina testarea și a trebuit să opriți procesul fără a decide dacă testul a trecut / nu a reușit.
A doua zi, când vă întoarceți, efectuați din nou testul - asta înseamnă că repetați un test pe care l-ați făcut anterior. Simplul act de a repeta un test este un Retest.
Testul de regresie este esențial. Doar pentru ocazia specială, ceva din aplicație / cod s-a schimbat. Ar putea fi cod, design sau orice altceva care dictează cadrul general al sistemului.
O reevaluare care se desfășoară în această situație pentru a vă asigura că modificarea menționată nu a avut impact asupra a ceva care funcționa deja înainte se numește test de regresie. Cele mai frecvente motive pentru care acest lucru ar putea fi realizat sunt pentru că au fost create versiuni noi ale codului (creșterea sferei / cerinței) sau erorile au fost remediate.
Testarea de regresie poate fi efectuată manual?
Tocmai învățam într-una din aceste zile în clasa mea și mi-a venit o întrebare: „Se poate face regresia manual?”
Am răspuns la întrebare și am trecut mai departe în clasă. Totul părea OK, dar cumva această întrebare m-a necăjit destul de mult mai târziu.
În numeroasele loturi, această întrebare apare de mai multe ori în diferite moduri. Unii dintre ei sunt:
- Pentru a efectua execuția testului, avem nevoie de un instrument?
- Cum se efectuează testarea de regresie?
- Chiar și după o întreagă rundă de teste - noilor veniți le este greu să discearnă ce este exact testul de regresie?
Și, desigur, întrebarea inițială:
- Acest test poate fi efectuat manual?
Pentru început, Executarea testului este un act simplu de a folosi cazurile de testare și de a efectua acei pași pe AUT, furnizarea datelor de testare și compararea rezultatului obținut pe AUT cu rezultatul așteptat menționat în cazurile de testare.
În funcție de rezultatul comparației, stabilim starea cazului de testare trecere / eșec. Execuția testului este la fel de simplă, nu există instrumente speciale necesare pentru acest proces.
Instrumente automate de testare a regresiei
Testul automat de regresie este zona de testare în care putem automatiza majoritatea eforturilor de testare. Executăm toate cazurile de testare executate anterior pe o nouă versiune.
Aceasta înseamnă că avem un set de cazuri de testare disponibil și că rularea manuală a acestor cazuri de testare consumă mult timp. Știm rezultatele așteptate, astfel încât automatizarea acestor cazuri de testare economisește timp și este o metodă eficientă de testare de regresie. Gradul de automatizare depinde de numărul de cazuri de testare care vor rămâne aplicabile ore suplimentare.
Dacă cazurile de testare variază din când în când, domeniul de aplicare al aplicației continuă să crească și atunci automatizarea procedurii de regresie va fi risipa de timp.
Majoritatea instrumentelor de testare de regresie sunt de tip înregistrare și redare. Veți înregistra cazurile de test navigând prin AUT (aplicația aflată sub test) și veți verifica dacă rezultatele așteptate vin sau nu.
Instrumente
- Seleniu
- Catalog Studio
- AdventNet QEngine
- Tester de regresie
- vTest
- apă
- actiWate
- Tester funcțional rațional
- SilkTest
- TimeShiftX
Cele mai multe dintre acestea sunt instrumente de testare funcționale și de regresie.
Lectură recomandată => Consultați aici lista de instrumente de regresie de top
Adăugarea și actualizarea cazurilor de testare de regresie într-o suită de teste de automatizare este o sarcină greoaie. În timp ce selectați un instrument de automatizare pentru testele de regresie, ar trebui să verificați dacă instrumentul vă permite să adăugați sau să actualizați cu ușurință cazurile de testare.
html css întrebări și răspunsuri la interviu
În majoritatea cazurilor, trebuie să actualizăm frecvent cazurile automate de testare de regresie din cauza schimbărilor frecvente ale sistemului.
PRIVESTE FILMAREA
Pentru o explicație mai detaliată a definiției cu un exemplu, vă rugăm să verificați următoareleVideo test de regresie:
De ce testul de regresie?
Regresia este inițiată atunci când un programator remediază orice eroare sau adaugă un nou cod pentru funcționalități noi în sistem.
Pot exista multe dependențe în funcționalitatea nou adăugată și existentă.
Este o măsură de calitate pentru a verifica dacă noul cod respectă vechiul cod, astfel încât codul nemodificat să nu fie afectat. De cele mai multe ori, echipa de testare are sarcina de a verifica modificările de ultim moment din sistem.
Într-o astfel de situație, testarea numai a zonei de aplicație afectate este necesară pentru a finaliza procesul de testare la timp, acoperind toate aspectele majore ale sistemului.
Acest test este foarte important atunci când există o modificare / îmbunătățire continuă adăugată în aplicație. Noua funcționalitate nu ar trebui să afecteze negativ codul testat existent.
Este necesară regresia pentru a găsi erorile care au apărut din cauza unei modificări a codului. Dacă nu se face această testare, produsul ar putea avea probleme critice în mediul live și care într-adevăr poate duce clientul la probleme.
În timpul testării oricărui site web online, un tester raportează o problemă conform căreia prețul produsului nu este afișat corect, adică arată un preț mai mic decât prețul real al produsului și trebuie să fie remediat în curând.
Odată ce dezvoltatorul remediază problema, trebuie să fie re-testat, iar testarea de regresie este, de asemenea, necesară, deoarece verificarea prețului la pagina raportată s-ar fi corectat, dar s-ar putea afișa un preț incorect la pagina de rezumat, unde se afișează totalul cu celelalte taxe sau e-mailul trimis clientului are în continuare prețul incorect.
Acum, în acest caz, clientul va trebui să suporte pierderea dacă această testare nu este efectuată, deoarece site-ul calculează costul total cu prețul incorect și același preț este trimis unui client prin e-mail. Odată ce clientul acceptă, Produsul este vândut online la un preț mai mic, va fi o pierdere pentru client.
Deci, această testare joacă un rol important și este foarte necesară și importantă.
Tipuri de testare de regresie
Mai jos sunt prezentate diferitele tipuri de regresie:
- Regresia unității
- Regresie parțială
- Regresie completă
# 1) Regresia unității
Regresia unității se face în timpul Testarea unitara faza și codul sunt testate izolat, adică orice dependență de unitatea de testat este blocată, astfel încât unitatea să poată fi testată individual fără nicio discrepanță.
# 2) Regresie parțială
Regresia parțială se face pentru a verifica dacă codul funcționează bine chiar și atunci când modificările au fost făcute în cod și că unitatea este integrată cu codul nemodificat sau deja existent.
# 3) Regresie completă
Regresia completă se face atunci când o modificare a codului se face pe un număr de module și, de asemenea, dacă impactul schimbării unei modificări în orice alt modul este incert. Produsul în ansamblu este regresat pentru a verifica orice modificare din cauza codului modificat.
Câtă regresie este necesară?
Acest lucru depinde de sfera de funcții nou adăugate.
Dacă domeniul de aplicare al unei corecții sau al unei caracteristici este prea mare, atunci zona de aplicație afectată este, de asemenea, destul de mare, iar testarea trebuie efectuată cu atenție, inclusiv toate cazurile de testare a aplicației. Dar acest lucru poate fi decis în mod eficient atunci când testerul primește informații de la un dezvoltator cu privire la domeniul de aplicare, natura și cantitatea de schimbare.
Deoarece acestea sunt teste repetitive, cazurile de testare pot fi automatizate, astfel încât un set de cazuri de testare singur să poată fi executat cu ușurință pe o nouă versiune.
Cazurile de testare de regresie trebuie selectate foarte atent, astfel încât funcționalitatea maximă să fie acoperită într-un set minim de cazuri de testare. Acest set de cazuri de testare necesită îmbunătățiri continue pentru funcționalitatea adăugată recent.
Devine foarte dificil când domeniul de aplicare al aplicației este foarte mare și există creșteri sau patch-uri continue în sistem. În astfel de cazuri, testele selective trebuie executate pentru a economisi costul și timpul testării. Aceste cazuri de testare selectivă sunt selectate pe baza îmbunătățirilor aduse sistemului și a părților în care acesta poate afecta cel mai mult.
Ce facem în verificarea regresiei?
- Executați din nou testele efectuate anterior
- Comparați rezultatele actuale cu rezultatele testelor executate anterior
Acesta este un proces continuu realizat în diferite etape de-a lungul ciclului de viață al testării software-ului.
O bună practică este efectuarea unui test de regresie după Testarea sănătății sau a fumului și la sfârșitul testării funcționale pentru o scurtă versiune.
Pentru a efectua teste eficiente, regresia Planul de testare ar trebui creat. Acest plan ar trebui să prezinte strategia de testare a regresiei și criteriile de ieșire. Testarea performanței este, de asemenea, o parte a acestui test pentru a vă asigura că performanța sistemului nu este afectată din cauza modificărilor aduse componentelor sistemului.
Cele mai bune practici : Rulați cazuri de testare automate în fiecare zi seara, astfel încât orice reacție adversă de regresie să poată fi remediată în data următoare. În acest fel, reduce riscul de eliberare acoperind aproape toate defectele de regresie într-un stadiu incipient, mai degrabă decât găsirea și remedierea celor la sfârșitul ciclului de eliberare.
Tehnici de testare a regresiei
Mai jos sunt prezentate diferitele tehnici.
- Reîncercați toate
- Selecția testului de regresie
- Prioritizarea cazului de testare
- Hibrid
# 1) Reîncercați toate
După cum sugerează și numele, toate cazurile de testare din suita de testare sunt reexecutate pentru a se asigura că nu există erori care au apărut din cauza unei modificări a codului. Aceasta este o metodă costisitoare, deoarece necesită mai mult timp și resurse în comparație cu celelalte tehnici.
# 2) Selecția testului de regresie
În această metodă, cazurile de testare sunt selectate din suita de testare pentru a fi reexecutate. Nu întreaga suită este reexecutată. Selectarea cazurilor de testare se face pe baza modificării codului din modul.
Cazurile de testare sunt împărțite în două categorii, una este cazurile de testare reutilizabile și alta este cazurile de testare învechite. Cazurile de testare reutilizabile pot fi utilizate în cicluri de regresie viitoare, în timp ce cele învechite nu sunt utilizate în ciclurile de regresie viitoare.
# 3) Prioritizarea cazului de testare
Testele cu prioritate ridicată sunt executate mai întâi decât cele cu prioritate medie și mică. Prioritatea cazului de testare depinde de criticitatea și impactul său asupra produsului, precum și de funcționalitatea produsului care este utilizat mai des.
# 4) Hibrid
Tehnica hibridă este o combinație între selecția testului de regresie și priorizarea cazului de testare. În loc să selectați întreaga suită de teste, selectați doar cazurile de testare care sunt reexecutate în funcție de prioritatea lor.
Cum să selectați o suită de testare de regresie?
Majoritatea erorilor găsite în mediul de producție apar din cauza modificărilor efectuate sau a erorilor remediate la ora a unsprezecea, adică a modificărilor efectuate într-o etapă ulterioară. Remedierea erorilor din ultima etapă ar putea crea alte probleme / erori în produs. De aceea, verificarea regresiei este foarte importantă înainte de a lansa un produs.
Mai jos este o listă a cazurilor de test care pot fi utilizate în timpul efectuării acestui test:
- Funcționalități frecvent utilizate.
- Testează cazurile care acoperă modulul în care s-au făcut modificările.
- Cazuri complexe de testare.
- Cazuri de testare a integrării care includ toate componentele majore.
- Testează cazurile pentru funcționalitatea sau caracteristica de bază a produsului.
- Trebuie incluse cazurile de testare Prioritate 1 și Prioritate 2.
- Cazuri de testare care nu reușesc frecvent sau defecte de testare recente au fost găsite în același.
Cum se efectuează testarea de regresie?
Acum, că am stabilit ce înseamnă regresia, este evident că testează și - repetând pur și simplu într-o situație specifică dintr-un motiv specific. Prin urmare, putem deduce în siguranță că aceeași metodă se aplică pentru testare, în primul rând se poate aplica și acestui lucru.
Prin urmare, dacă testarea se poate face manual, atunci poate fi și testarea de regresie. Utilizarea unui instrument nu este necesară. Cu toate acestea, pe măsură ce trece timpul, aplicațiile se acumulează cu funcționalități din ce în ce mai mari, care continuă să mărească sfera de regresie. Pentru a profita la maximum de timp, acest test este cel mai adesea Automatizat .
Mai jos sunt prezentați diferiții pași implicați în efectuarea acestui test
- Pregătiți o suită de testare pentru regresie luând în considerare punctele menționate în „Cum se selectează suita de testare de regresie”?
- Automatizați toate cazurile de testare din suita de teste.
- Actualizați suita de regresie ori de câte ori este necesar, ca în cazul în care se constată un nou defect care nu este acoperit în cazul de testare, iar un caz de testare pentru același lucru ar trebui actualizat în suita de testare, astfel încât testarea să nu fie ratată pentru aceeași dată data viitoare. . Suita de testare de regresie ar trebui gestionată corect prin actualizarea continuă a cazurilor de testare.
- Executați cazurile de testare de regresie ori de câte ori există o modificare a codului, eroarea este remediată, se adaugă o nouă funcționalitate, se face o îmbunătățire a funcționalității existente etc.
- Creați un raport de execuție a testului care include starea Trecere / Eșecuri a cazurilor de testare executate.
De exemplu:
Permiteți-mi să explic acest lucru cu un exemplu. Vă rugăm să examinați situația de mai jos:
| Versiunea 1 Statistici | |
|---|---|
| Număr de testeri | 3 |
| Numele aplicatiei | XYZ |
| Număr versiune / versiune | 1 |
| Nr. De cerințe (domeniu) | 10 |
| Nr. Cazuri / teste de testare | 100 |
| Numărul de zile necesare dezvoltării | 5 |
| Numărul de zile de testare | 5 |
| Versiunea 2 Statistici | |
|---|---|
| Număr de testeri | 3 |
| Numele aplicatiei | XYZ |
| Număr versiune / versiune | Două |
| Nr. De cerințe (domeniu) | 10+ 5 cerințe noi |
| Număr de cazuri de testare / teste | 100+ 50 noi |
| Numărul de zile necesare dezvoltării | 2,5 (deoarece această jumătate din cantitatea de muncă decât anterior) |
| Numărul de zile de testare | 5 (pentru cele 100 de TC existente) + 2,5 (pentru cerințe noi) |
| Lansați 3 statistici | |
|---|---|
| Număr de testeri | 3 |
| Numele aplicatiei | XYZ |
| Număr versiune / versiune | 3 |
| Nr. De cerințe (domeniu) | 10+ 5 + 5 cerințe noi |
| Număr de cazuri de testare / teste | 100+ 50+ 50 noi |
| Numărul de zile necesare dezvoltării | 2,5 (deoarece această jumătate din cantitatea de muncă decât anterior) |
| Numărul de zile de testare | 7,5 (pentru cele 150 de TC existente) + 2,5 (pentru cerințe noi) |
Următoarele sunt observațiile pe care le putem face din situația de mai sus:
- Pe măsură ce versiunile cresc, funcționalitatea crește.
- Timpul de dezvoltare nu crește neapărat odată cu lansările, dar timpul de testare crește
- Nicio companie / conducerea sa nu va fi gata să investească mai mult timp în testare și mai puțin pentru dezvoltare
- Nu putem reduce nici timpul necesar testării prin creșterea dimensiunii echipei de testare, deoarece mai mulți oameni înseamnă mai mulți bani și oameni noi înseamnă, de asemenea, o mulțime de instruire și poate, de asemenea, un compromis de calitate, deoarece noii oameni s-ar putea să nu fie la egalitate cu cunoștințele necesare nivelurile imediat.
- Cealaltă alternativă este în mod clar reducerea cantității de regresie. Dar acest lucru ar putea fi riscant pentru produsul software.
Din toate aceste motive, testarea de regresie este un candidat bun pentru testarea automatizată, dar nu trebuie să fie făcută doar în acest fel.
Pași de bază pentru efectuarea testelor de regresie
De fiecare dată când software-ul suferă o modificare și apare o nouă versiune / lansare, următorii sunt pașii pe care îi puteți face pentru a efectua acest tip de testare:
- Înțelegeți ce fel de modificări au fost aduse software-ului
- Analizați și determinați ce module / părți ale software-ului ar putea fi afectate - echipele de dezvoltare și BA pot fi esențiale în furnizarea acestor informații
- Aruncați o privire asupra cazurilor de testare și stabiliți dacă va trebui să faceți o regresie completă, parțială sau unitară. Identifică-i pe cei care se vor potrivi situației tale
- Programați timpul și testați-vă!
Regresia în agilitate
Agil este o abordare adaptivă care urmează o metodă iterativă și incrementală. Produsul este dezvoltat în iterații scurte numite sprint, care durează 2-4 săptămâni. În mod agil, există o serie de iterații, prin urmare, această testare joacă un rol semnificativ, deoarece noua funcționalitate sau schimbarea codului se face în iterații.
Suita de testare de regresie ar trebui pregătită încă din faza inițială și ar trebui să fie actualizată cu fiecare sprint.
În Agile, verificarea regresiei este acoperită în două categorii:
- Regresie la nivel de sprint
- Regresie de la capăt la capăt
# 1) Regresie la nivel de sprint
Sprint Level Regression se face în principal pentru noua funcționalitate sau îmbunătățirea care se realizează în cel mai recent sprint. Cazurile de testare din suita de testare sunt selectate în funcție de noua funcționalitate adăugată sau de îmbunătățirea care se face.
# 2) Regresie de la un capăt la altul
Regresia de la un capăt la altul include toate cazurile de testare care urmează să fie reexecutate pentru a testa produsul complet cap la cap acoperind toate funcționalitățile de bază ale produsului.
Deoarece Agile are sprinturi scurte și continuă, este foarte necesar să automatizăm suita de teste, cazurile de testare sunt executate din nou și asta trebuie să fie finalizat într-un interval scurt de timp. Automatizarea cazurilor de testare reduce timpul de execuție și alunecarea defectelor.
Avantaje
Mai jos sunt prezentate diferitele avantaje ale testului de regresie
- Îmbunătățește calitatea produsului.
- Se asigură că orice remediere a erorilor sau îmbunătățiri efectuate nu afectează funcționalitatea existentă a Produsului.
- Pentru aceste teste pot fi utilizate instrumente de automatizare.
- Se asigură că problemele care sunt deja remediate nu mai apar din nou.
Dezavantaje
Deși există mai multe avantaje, există și unele dezavantaje. Sunt:
- Trebuie făcut și pentru o mică modificare a codului, deoarece chiar și o mică modificare a codului poate crea probleme în funcționalitatea existentă.
- Dacă în cazul în care automatizarea nu este utilizată în proiect pentru această testare, va fi o sarcină fastidioasă și fastidioasă să executăm cazurile de testare din nou și din nou.
Regresia aplicației GUI
Este dificil să efectuați un test de regresie GUI (Graphical User Interface) când structura GUI este modificat. Cazurile de test scrise pe interfața GUI veche fie devin învechite, fie trebuie modificate.
Reutilizarea cazurilor de test de regresie înseamnă că cazurile de testare GUI sunt modificate în conformitate cu noua GUI. Dar această sarcină devine dificilă dacă aveți un set mare de cazuri de testare GUI.
Diferența dintre regresie și re-testare
Re-testarea se face pentru cazurile de test care nu reușesc în timpul execuției și bug-ul ridicat pentru același lucru a fost remediat, în timp ce verificarea regresiei nu se limitează la remedierea bug-ului, deoarece acoperă și alte cazuri de testare, pentru a se asigura că remedierea bug-ului nu a fost a afectat orice altă funcționalitate a Produsului.
Șablon de plan de testare de regresie (TOC)
1. Istoria documentelor
2. Referințe
3. Planul de testare de regresie
3.1. Introducere
3.2. Scop
3.3. Strategia de testare
3.4. Caracteristică de testat
3.5. Cerința de resurse
3.5.1. Cerințe hardware
3.5.2. Cerințe software
3.6. Program de testare
3.7. Cerere de modificare
3.8. Criterii de intrare / ieșire
3.8.1. Criterii de intrare pentru acest test
3.8.2. Criterii de ieșire pentru acest test
3.9. Presupunere / Constrângeri
3.10. Cazuri de testare
3.11. Risc / Ipoteze
3.12. Instrumente
4. Aprobare / acceptare
Să aruncăm o privire la fiecare dintre ele în detaliu.
# 1) Istoricul documentelor
Istoricul documentelor constă într-o înregistrare a primei schițe și a tuturor celor actualizate în formatul de mai jos.
| Versiune | Data | Autor | cometariu |
|---|---|---|---|
| 1 | ZZ / LL / AA | ABC | Aprobat |
| Două | ZZ / LL / AA | ABC | Actualizat pentru funcția adăugată |
# 2) Referințe
Coloana de referințe ține o evidență a tuturor documentelor de referință utilizate sau necesare pentru proiect în timp ce se creează un plan de testare.
| Nu face | Document | Locație |
|---|---|---|
| 1 | Document SRS | Unitate partajată |
# 3) Plan de testare de regresie
3.1. Introducere
Acest document descrie modificarea / actualizarea / îmbunătățirea produsului care urmează să fie testat și abordarea utilizată pentru acest test. Toate modificările codului, îmbunătățirile, actualizările, caracteristicile adăugate sunt prezentate pentru a fi testate. Cazurile de testare utilizate pentru testarea unitară și testarea integrării pot fi utilizate pentru a crea o suită de testare pentru regresie.
3.2. Scop
Scopul planului de testare de regresie este de a descrie ce anume și cum ar fi efectuate testele pentru a obține rezultatele. Verificarea de regresie se face pentru a se asigura că nicio altă funcționalitate a produsului nu este împiedicată din cauza modificării codului.
3.3. Strategia de testare
Strategia de testare descrie abordarea care va fi utilizată pentru efectuarea acestei testări și care include tehnica care va fi utilizată, care vor fi criteriile de finalizare, cine va efectua ce activitate, cine va scrie scripturile de testare, ce instrument de regresie va fi utilizat , pași pentru acoperirea riscurilor, cum ar fi reducerea resurselor, întârzierea producției etc.
3.4. Caracteristici de testat
Caracteristicile / componentele produsului care urmează să fie testat sunt enumerate aici. În regresie, toate cazurile de testare sunt reexecutate sau cele care afectează funcționalitatea existentă sunt alese în funcție de remedierea / actualizarea sau îmbunătățirea efectuată.
3.5. Cerința de resurse
3.5.1. Cerințe hardware:
Cerința hardware este identificată aici, cum ar fi calculatoare, laptopuri, modemuri, cărți Mac, smartphone etc.
3.5.2. Cerințe software:
Cerința software este identificată ca sistem de operare și browsere care vor fi necesare.
3.6. Program de testare
Programul de testare definește timpul estimat pentru efectuarea activităților de testare.
De exemplu Câte resurse vor efectua o activitate de testare și asta în cât timp?
3.7. Cerere de modificare
Sunt menționate detaliile CR pentru care ar fi efectuată Regresia.
| S. Nu | Descriere CR | Regression Test Suite |
|---|---|---|
| 1 | ||
| Două |
3.8. Criterii de intrare / ieșire
3.8.1. Criterii de intrare pentru această testare:
Sunt definite criteriile de intrare pentru ca produsul să înceapă verificarea de regresie.
De exemplu:
- Modificările de codificare / îmbunătățirea / adăugarea de noi caracteristici ar trebui să fie finalizate.
- Planul testului de regresie ar trebui aprobat.
3.8.2. Criterii de ieșire pentru această testare:
Aici sunt definite criteriile de ieșire pentru regresie.
De exemplu:
- Testarea de regresie ar trebui finalizată.
- Orice erori critice noi găsite în timpul acestei testări ar trebui închise.
- Raportul de testare ar trebui să fie gata.
3.9. Cazuri de testare
Cazurile de test de regresie sunt definite aici.
3.10. Risc / Ipoteze
Orice risc și ipoteză sunt identificate și un plan de urgență este pregătit pentru același lucru.
3.11. Instrumente
Instrumentele care vor fi utilizate în proiect sunt identificate. Ca:
- Instrument de automatizare
- Instrument de raportare a erorilor
# 4) Aprobare / acceptare
Numele și denumirea persoanelor sunt enumerate aici:
| Nume | Aprobat / respins | Semnătură | Data |
|---|---|---|---|
Concluzie
Testarea de regresie este unul dintre aspectele importante, deoarece ajută la livrarea unui produs de calitate, asigurându-vă că orice modificare a codului, indiferent dacă este mic sau mare, nu afectează funcționalitatea existentă sau veche.
O mulțime de instrumente de automatizare sunt disponibile pentru automatizarea cazurilor de test de regresie, cu toate acestea, un instrument ar trebui selectat conform cerințelor proiectului. Un instrument ar trebui să aibă capacitatea de a actualiza suita de teste, deoarece suita de testare de regresie trebuie actualizată frecvent.
Cu aceasta, încheiem acest subiect și sperăm că va fi o claritate mult mai bună asupra subiectului de acum înainte.
Vă rugăm să ne anunțați întrebările și comentariile dvs. legate de regresie. Cum ți-ai abordat sarcinile de testare de regresie?
=> Vizitați aici pentru seria completă de programe de testare
Lectură recomandată
- Cele mai bune instrumente de testare software 2021 (Instrumente de automatizare a testelor de calitate)
- Topul celor mai populare 10 instrumente de testare a regresiei în 2021
- Ce este testarea fiabilității: definiție, metodă și instrumente
- Cele mai bune 11 instrumente de automatizare pentru testarea aplicațiilor Android (instrumente de testare a aplicațiilor Android)
- Testare automată de regresie: provocări, proces și pași
- Descărcare eBook Descărcare Primer
- Diferența dintre retestare și testare de regresie cu exemplu
- Top 10+ Cele mai bune instrumente de testare SAP (Instrumente de automatizare SAP)