O regresie software este un tip de bug software în care un feature care anterior funcționa încetează să funcționeze corect. Aceasta se poate întâmpla după ce se aplică modificări codului sursă al software-ului, inclusiv prin adăugarea de noi sau prin remedieri de buguri. Acestea pot fi introduse însă și prin modificări ale mediului în care rulează software-ul, cum ar fi actualizări de sistem, sau trecerea la sau încetarea orei de vară. O regresie de performanță este o situație în care software-ul funcționează în continuare corect, dar funcționează mai lent sau utilizează mai multă memorie sau altfel de resurse decât înainte. În practică au fost identificate diverse tipuri de regresii software, între care:
Locală – o modificare introduce un bug nou în modulul sau componenta modificată. Remote – o modificare a unei părți a software-ului întrerupe funcționalitatea unui alt modul sau componentă. Unmasked – o modificare expune o eroare deja existentă care până atunci nu avea niciun efect.
Regresiile sunt adesea cauzate de hotfixuri incluse în patch-uri. O abordare pentru a evita acest tip de problemă este . Un conceput corespunzător își propune să prevină această posibilitate înainte de lansarea oricărui software. Testarea automată și bine scrise pot reduce probabilitatea unei regresii.
Prevenire și detectare Au fost propuse tehnici concepute să prevină introducerea regresiilor în software în diferite etape de dezvoltare, așa cum este prezentat mai jos.
Înainte de lansare Pentru a evita ca regresiile să fie văzute de după lansare, dezvoltatorii rulează în mod regulat după ce sunt introduse modificări în software. Aceste teste pot include pentru a detecta regresiile locale, precum și pentru a detecta regresiile la distanță. Tehnicile de testare de regresie utilizează adesea cazurile de testare existente pentru a minimiza efortul implicat în crearea lor. Cu toate acestea, din cauza volumului acestor teste existente, este adesea necesar să se selecteze o submulțime reprezentativă a lor, folosind tehnici precum prioritizarea cazurilor de test.
Pentru detectarea regresiilor de performanță, se execută regulat , pentru a monitoriza timpul de răspuns și indicatorii de utilizare a resurselor software-ului după modificările ulterioare. Spre deosebire de testele de regresie funcțională, rezultatele testelor de performanță sunt supuse varianței adică rezultatele pot fi diferite de la un test la altul din cauza variației măsurătorilor de performanță; prin urmare, trebuie luată o decizie cu privire la faptul dacă o modificare a cifrelor de performanță constituie o regresie, pe baza experienței și a cerințelor utilizatorului final. Abordări precum testarea ipotezelor statistice și sunt uneori utilizate pentru a ajuta la luarea acestei decizii.
Înainte de commit Întrucât și localizarea cauzei principale a unei regresii software pot fi costisitoare, există și unele metode care încearcă să prevină în primul rând commiterea regresiilor în depozitul de cod. De exemplu, Git Hooks permit dezvoltatorilor să ruleze scripturi de testare înainte ca modificările de cod să fie commise sau trimise în depozitul de cod. În plus, se rulează o pentru a prezice impactul unei modificări de cod asupra diferitelor componente ale programului și pentru a suplimenta selecția și prioritizarea cazurilor de testare. De asemenea, sunt adesea adăugate la hook-urile de commit pentru a asigura un stil de codare consistent, reducând astfel la minimum problemele stilistice care pot face software-ul să fie predispus la regresii.
Localizare Multe dintre tehnicile utilizate pentru a găsi cauza principală a erorilor software care nu sunt de tip regresie pot fi folosite și pentru debugul regresiilor software, inclusiv debugging cu , debugging cu afișare de mesaje și .
Regresii funcționale O tehnică obișnuită utilizată pentru localizarea regresiilor funcționale este , care începe cu un commit care a introdus eroarea și cu un commit la care se știa ca problema nu se manifestă. Tehnica presupune efectuarea unei căutări binare prin commituri. Sistemele de control al versiunilor, cum ar fi Git și Mercurial, oferă modalități integrate de a efectua bisecția pe o anumită pereche de commit-uri.
Alte opțiuni includ asocierea directă a rezultatului unui test de regresie cu modificările de cod; setarea punctelor de întrerupere a divergenței; sau utilizarea , care identifică cazurile de test inclusiv cele eșuate care sunt relevante pentru un set de modificări de cod, printre altele.
Regresii de performanță măsoară performanța și utilizarea resurselor diferitelor componente ale unui program și este utilizată pentru a genera date utile în depanarea problemelor de performanță. În contextul regresiilor de performanță software, dezvoltatorii compară adesea (cunoscuți și sub denumirea de -uri) generați de profilere atât pentru versiunea cu erori, cât și pentru versiunea funcțională anterioară, și există mecanisme pentru a simplifica această comparație. oferă de obicei dezvoltatorilor posibilitatea de a înregistra aceste profiluri de performanță.
Logurile ajută și la localizarea regresiei de performanță și, similar arborilor de apeluri, dezvoltatorii pot compara logurile de performanță plasate sistematic pe mai multe versiuni ale aceluiași software. Există un compromis atunci când se adaugă aceste loguri de performanță, deoarece adăugarea de loguri multe poate ajuta dezvoltatorii să identifice cu granularitate mai fină care porțiuni ale software-ului regresează, în timp ce adăugarea de loguri puține va reduce costurile generale de execuție a programului.
Abordările suplimentare includ scrierea de teste unitare conștiente de performanță pentru a ajuta la localizare și clasificarea subsistemelor pe baza abaterilor contorului de performanță. Bisecția poate fi reutilizată și pentru regresii de performanță, considerând commit-urile care au performanțe sub (sau peste) o anumită valoare de referință ca fiind cele cu eroare și luând fie partea stângă, fie cea dreaptă a listei de commituri în baza rezultatelor acestei comparații.
Note
Categorie:Inginerie software