Testarea de regresie ( eng. testing de regresie ← lat. regressio „înapoi, întoarcere, retragere”) este un nume colectiv pentru toate tipurile de testare software care vizează detectarea erorilor în secțiunile deja testate ale codului sursă . Astfel de erori - atunci când, după efectuarea modificărilor în program, ceva care ar fi trebuit să continue să funcționeze încetează să funcționeze - ele se numesc erori de regresie .
Testarea de regresie (pentru unii[ ce? ] ) include o nouă remediere a erorilor - verificarea remedierii unui defect nou găsit, remedierea erorilor vechi - verificarea faptului că un defect remediat și verificat anterior nu este reprodus din nou în sistem și, de asemenea , efect secundar - verificarea faptului că funcționează anterior funcționalitatea nu a fost întreruptă, dacă codul său ar putea fi afectat de remedierea unor defecte în alte funcționalități. Metodele de testare a regresiei utilizate în mod obișnuit includ reluări ale testelor anterioare, precum și verificarea pentru a vedea dacă erorile de regresie au intrat în următoarea versiune ca urmare a îmbinării codului.
Din experiența dezvoltării software, se știe că apariția repetată a acelorași erori este un caz destul de frecvent. Uneori, acest lucru se datorează tehnicilor slabe de control al versiunilor sau din cauza unei erori umane în controlul versiunilor . Dar la fel de des, soluția la o problemă este „de scurtă durată”: după următoarea modificare a programului, soluția nu mai funcționează. Și, în cele din urmă, atunci când rescrieți orice parte a codului, apar adesea aceleași erori care au fost în implementarea anterioară.
Prin urmare, este considerată o practică bună atunci când remediați un bug să creați un test pentru acesta și să îl rulați în mod regulat cu modificările ulterioare ale programului. Deși testarea de regresie se poate face manual, cel mai adesea se face cu ajutorul unor programe specializate care vă permit să efectuați automat toate testele de regresie . Unele proiecte chiar folosesc instrumente pentru a rula automat teste de regresie la un anumit interval de timp. Acest lucru se face de obicei după fiecare compilație de succes (în proiecte mici), fie în fiecare seară, fie în fiecare săptămână.
Testarea de regresie este o parte integrantă a programării extreme . Această metodologie înlocuiește documentația de proiectare cu testarea extensibilă, repetabilă și automată a întregului pachet software în fiecare etapă a procesului de dezvoltare a software-ului .
Testarea de regresie poate fi folosită nu numai pentru a verifica corectitudinea unui program, ci este adesea folosită și pentru a evalua calitatea rezultatului. Deci, atunci când se dezvoltă un compilator , când se execută teste de regresie, se ia în considerare dimensiunea codului rezultat, viteza de execuție a acestuia și timpul de compilare al fiecăruia dintre cazurile de testare.
În articolul lor, S. Yoo și M. Harman [1] oferă următoarea clasificare a testelor de regresie:
Testul de minimizare a setului urmărește să reducă dimensiunea setului de teste prin eliminarea cazurilor de testare din setul de teste pe baza unui criteriu dat. Există trei abordări, dintre care prima utilizează testarea automată de securitate pentru a detecta vulnerabilități prin examinarea defecțiunilor aplicațiilor care pot detecta malware cunoscut, cum ar fi viruși sau viermi. Această abordare ia în considerare numai testele eșuate din versiunea anterioară pentru a fi reluate în noua versiune a sistemului după ce problema este remediată.
O altă abordare este concepută pentru a detecta și remedia vulnerabilitățile din versiunile minore ale aplicațiilor web. Acesta creează o legătură hard cu paginile versiunii anterioare folosind iteratoare care sunt selectate pentru a examina paginile web care conțin vulnerabilități.
Și, în sfârșit, a treia abordare oferă testarea cu autoadaptare a sistemului pentru defecțiuni deja cunoscute. Autorii evită reproducerea erorilor deja cunoscute, luând în considerare doar acele teste care au dezvăluit eșecuri cunoscute în versiunile anterioare.
Problema testului de prioritizare se referă la ordonarea corectă a testelor, ceea ce maximizează proprietățile dorite, cum ar fi detectarea timpurie a defecțiunilor. De asemenea, abordările actuale de prioritizare iau în considerare doar vulnerabilitățile.
O metodă oferă teste prioritare bazate pe erori care exploatează direct cunoștințele despre capacitatea lor de a detecta defecțiuni.
Celălalt oferă un sistem de înregistrare-redare modificabil care vă permite să rescrieți versiunea înregistrată și executată a aplicației într-una nouă, modificată. Execuția lor este prioritizată datorită determinării optime a rescrierii modificate pe baza funcției de cost și a măsurării diferenței dintre execuția inițială și cea modificată la reîncercare.
Metoda de selecție vă permite să selectați un subset sau toate cazurile de testare pentru a testa părțile modificate ale software-ului. Următoarele abordări testează atât mecanismele de securitate, cât și vulnerabilitățile.
Testarea de regresie este efectuată atunci când se fac modificări la funcționalitatea existentă a software-ului sau dacă există o remediere a erorilor în software. Testarea regresiei poate fi implementată prin mai multe abordări. Trecerea cu succes a tuturor testelor de către programul modificat oferă încredere că modificările aduse software-ului nu afectează funcționalitatea existentă, care ar trebui să rămână neschimbată în orice caz.
Într-un proces agil de management al proiectelor în care ciclul de viață al dezvoltării software este foarte scurt, resursele sunt limitate și modificările software sunt făcute foarte frecvent. Testarea de regresie poate introduce o mulțime de cheltuieli generale inutile.
De obicei, testarea regresiei se face folosind instrumente de automatizare, dar generația actuală de instrumente de testare a regresiei nu este concepută pentru a gestiona aplicațiile de baze de date. Din acest motiv, la rularea unui test de regresie pe aplicații care folosesc baze de date, poate exista un cost neplanificat deoarece necesită multă muncă manuală.
O problemă fundamentală în întreținerea software-ului este că remedierea unei erori are o probabilitate mare (20-50%) de a provoca apariția unuia nou. Prin urmare, întregul proces urmează principiul „doi pași înainte, un pas înapoi”.
De ce nu putem remedia erorile mai precis? În primul rând, chiar și un defect ascuns se manifestă ca un eșec într-un singur loc. În realitate, are adesea ramificații în întregul sistem, de obicei nu sunt evidente. Orice încercare de a o remedia cu efort minim va repara ceea ce este local și evident, dar dacă structura nu este foarte clară sau documentația este foarte bună, efectele pe termen lung ale acestei remedieri vor trece neobservate. În al doilea rând, erorile sunt de obicei remediate nu de autorul programului, ci adesea de un programator junior sau de un stagiar.
Datorită introducerii de noi erori, întreținerea programului necesită mult mai multă depanare a sistemului per instrucțiune decât orice altă formă de programare. Teoretic, după fiecare remediere, trebuie să rulați întregul set de cazuri de testare față de care sistemul a fost verificat înainte, pentru a vă asigura că nu a fost deteriorat într-un mod de neînțeles. În practică, o astfel de testare de backtracking (regresie) ar trebui într-adevăr să se apropie de acest ideal teoretic și este foarte costisitoare.
- F. Brooks Mitica lună a omului sau cum sunt create sistemele software [2]