Introducere

Fiecare produs software are o audiență caracteristică. De aceea, când se

investeștedezvoltă sau investește în dezvoltarea unui produs software, trebuie să se evalueze
acceptabilitatea produsului din perspectiva utilizatorilor finali, audienței țintă, cumpărătorilor și
altor părți interesate. Testarea Software este procesul care vine sa facă această evaluare posibilă
într-un mod cât mai obiectiv, entru a asigurarea calitatății şi siguranţei aplicaţiilor software .
Dezvoltarea aplicaţiilor software implică o serie de activităţi, în care posibilitatea erorii
umane este foarte ridicată. Testarea este un element cheie în procesul de dezvoltare, a cărui scop
este de a identifica aceste erori și de a izola defectele ce au cauzat aceste erori.
Obiectivul lucrării constă în evidenţierea importanţei testării ca etapă în dezvoltarea
oricărui sistem informatic, fazele de testare a unui produs software, prezentarea metodelor și
instrumentarelor folosite în testarea automată.
Testarea automată constă în executarea unei secvențe de acțiuni fără intervenție umană
și pot simula utilizarea unei aplicații în condiții de simultaneitate ridicată. Majoritatea produselor
necesită să fie testate de mai multe ori, pe mai multe platforme software și hardware. Prin
folosirea testării automate, costurile testărilor repetate se reduc aproape la zero.
Scopul principal al automatizării este de a reduce timpul de testare prin verificarea
zonelor care au fost deja testate menținând același nivel de calitate. În acest fel, se evită pierderea
de timp, bani și efort pentru a face angajări, deoarece noii testeri au nevoie de perioadă de
adaptare, training și cheltuieli logistice.
E cert faptul că pe termen scurt soluțiile de automatizare sunt mai scumpe decât
angajarea a câțiva noi testeri, însă soluțiile de testare automată sunt mai avantajoase pe măsură
ce se dezvoltă noi release-uri și este nevoie de încă câțiva angajați de fiecare dată și astfel
costurile pe termen lung treptat cresc. Investiția inițială este mai mare, dar beneficiile se văd în
timp, deoarece permite testerilor să se concentreze pe modulele noi făcînd ad-hoc testing, metoda
ce poate descoperi multe probleme.
În concluzie, pentru a avea produse software performante și bine testate într-un timp decent, este
importantă implementarea unei soluții de teste automate, însă echipa de testeri rămâne
indispensabilă.
1. TEMATICA TESTĂRII PRODUSELOR PROGRAM
Testarea unui produs program este la fel de importantă ca şi crearea ei. Statisticile
afirmă că dezvoltarea unui produs, oricît de bine ar fi executată, produce trei defecte la o sută de
instrucţiuni scrise.
Nu există un astfel de proces de testare ce ar permite găsirea tuturor defectelor ce le
poate conţine un produs program. În schimb, un astfel de proces poate furniza o viziune critică
sau comparativă, care vine să contrapună unele aspecte ale produsului (cum ar fi: starea şi
comportamentul actual), metricile şi constrângerile care reprezintă criterii de acceptanţă. Aceste
criterii pot fi derivate din specificaţiile tehnice, produse asemănătoare comparabile, versiuni
anterioare ale aceluiaşi produs, aşteptări faţă de produs enunţate de către utilizator sau client,
standarde distinctive, legi în vigoare, etc.
În funcție de metoda de testare utilizată, testarea software-ului poate fi aplicată în orice
moment al procesului de dezvoltare. În mod tradițional, majoritatea testelor se efectuează după
ce au fost definite cerințele și procesul de codificare a fost finalizat . De fapt, metodologia de
testare depinde esențial de modul de dezvoltare a programului. Este greu de determinat care
metoda de testare va fi cea mai eficientă.
Scopul esential al testării este de a verifica functionarea corecta a tuturor componentelor
si subansamblelor produsului. Procesul de testare presupune:

 stabilirea metodelor de testare si definirea cazurilor si scenariilor de test;

 eliminarea diverselor probleme tehnice sau bug-uri aparute, utilizandu-se instrumentele
de testare stabilite anterior.

1.1 Generalități

1.1.1. Testarea – etapă a procesului de dezvoltăre a produselor software

Finalizarea cu succes a unui proiect software depinde, in mare masura, de alegerea
solutiilor. Aceste solutii se raporteaza la realitatea inconjuratoare si, implicit, la necesitatile
clientului. Procesul de dezvoltare al produselor software este alcătuit din următoarele etape:
specificarea cerinţelor, analiză, proiectare, dezvoltare, testare şi mentenanță. În figura 1.1 este
reprezentat grafic modelul clasic de dezvoltare produselor program.
 Fig. 1.1 Modelul clasic de dezvoltare a produselor program.

În etapa de specificare a cerinţelor se determină necesităţile pentru toate elementele

sistemului, atât hardware cât şi software. Testarea specificaţiilor se realizează prin metode de
analiză statică: inspecţii, parcurgeri şi analize tehnice.

Etapa de analiză continuă procesul de stabilire a cerinţelor.

Obiectivele fazei de analiză sunt:

 comunicarea cu partenerul/clientul prin diferite mijloace (chestionare, mese rotunde, etc)

in vederea obtinerii informatiilor legate de cerintele proiectului si de diverse idei si
expectative;
 intelegerea exigentelor si necesitatilor atat exprimate cat si neexprimate ale clientului;
 examinarea aprofundata a situatiei initiale si determinarea cerintelor tehnice;
 elaborarea planului initial si evaluarea efortului necesar;
 constituirea echipei care va realiza proiectul.

În etapa de proiectare accentul se pune pe structurile de date, arhitectura sistemului, detaliile

procedurale şi caracterizarea interfețelor. Scopul proiectării constă în definirea tuturor
componentelor proiectului într-o formă detaliată. Participarea clientului este incurajata.
Etapele proiectarii sunt:

 alegerea metodologiei de proiectare;

 definirea mediului tehnic si selectarea instrumentelor de dezvoltare, testare si
monitorizare;
 impartirea pe arii de responsabilitate a echipei implicate in proiect;
 detalierea timpilor necesari si a costurilor proiectului.

Prin implementare se face trecerea de la proiect la o formă specifică maşinii de calcul.

Implementarea este cu atât mai uşor de realizat cu cât proiectarea se realizează mai în detaliu.
Testarea în etapa de implementare are rolul de a evidenţia diferenţele dintre comportamentul
produsului din specificaţii și cel dat la nivelul utilizatorilor. În aceasta etapa presupune
dezvoltarea proiectului pana la obtinerea produsului final solicitat. Totodata, in acest punct,
produsul va fi prezentat clientului pentru o analiza finala inaintea testarii.
La etapa de testare se concentrează atît asupra logicii interne a programului, avînduse în
vedere ca anumite elemente ale acestuia sa fie parcurse, cît şi pe funcţionalitatea sa externă, pe
baza specificaţiilor. Se compară rezultatele efective obţinute după rularea programului cu seturi
de date de test cu rezultatele prevăzute pe baza specificaţiilor.
În timp, după livrarea la beneficiar, aplicațiile software suferă schimbări care se
datorează erorilor descoperite pe parcursul funcţionării aplicaţiei, modificărilor mediului în care
rulează aplicaţia (software, hardware) precum şi noilor cerinţe de performanţă şi funcţionalitate
dorite de beneficiar. Întreţinerea aplicaţiilor software se aplică tuturor fazelor ciclului de viaţă.
Mentananta este necesara in special pentru acele produse care au nevoie de update-uri
periodice si suport tehnic. Tot aici se efectueaza si micile modificari ale proiectului aparute ca
urmare a unor cerinte ulterioare.
În cadrul ciclului de dezvoltare software, un rol important îl au verificarea şi validarea
(V & V). Verificarea şi validarea reprezintă un proces prin care se determină dacă cerinţele unui
sistem sau componentă sunt complete şi corecte, dacă rezultatul fiecărei faze de dezvoltare
îndeplineşte cerinţele sau condiţiile impuse în faza anterioară şi dacă sistemul sau componenta
finală este în concordanţă cu cerinţele specificate.
Verificarea este mulţimea activităţilor care asigură că o aplicaţie software
implementează corect o anumită funcţie. Testarea software este o componentă a procesului de V
& V. Validarea este mulţimea activităţilor care asigură că o aplicaţie software realizată este în
concordanţă cu cerinţele beneficiarului. Pe măsura dezvoltării incrementale a aplicaţiei e-DSI
rezultatele din fazele intermediare sunt validate de către beneficiar.
Testarea sau analiza statică are ca scop examinarea aplicaţiilor software fără a fi
executate şi cuprinde activităţi precum inspecţiile, execuția simbolică şi verificarea. Aceste
activităţi fac parte din categoria evaluările tehnice.
Inspecţiile codului presupun citirea sau inspecţia vizuală a codului sursă de către un
grup de persoane. Având la dispoziţie codul sursă și specificațiile de proiectare, grupul de
persoane din echipa de inspecţie urmăreşte explicaţiile programatorului legate de logica
programului, instrucţiune cu instrucţiune. În acest mod se descoperă o serie de erori specifice
acestei metode cum ar fi: declararea datelor, referirea datelor, erorile de calcul, erorile de
comparare, erorile de logică, erorile de intrare/ieşire, erorile de interfaţă etc.
Parcurgerile constau în citirea sau inspecţia vizuală a codului sursă de către un grup de
persoane, însă procedura de lucru este diferită având ca scop execuţia logică a fiecărei secvenţe
de cod de testat pe baza unor seturi de test pregătite anterior. Prin urmărirea programului pas cu
pas sunt identificate erori care apar la acest nivel. Rezultatele acestei activităţi de verificare
depind, ca şi în cazul inspecţiilor codului, de atitudinea echipei faţă de persoana care a scris
programul, având în vedere faptul că atenţia trebuie acordată programului care se verifică şi nu
celui care l-a scris.
Verificarea de birou este o tehnică de analiză statică în care listingurile codurilor sau
rezultatele testelor sau alte documente sunt examinate vizual, de obicei de persoana care le-a
realizat, pentru a identifica erorile sau abaterile de la standardele de dezvoltare sau alte probleme.
Testarea dinamică presupune examinarea aplicaţiilor software în scopul generării datelor de
test cu care acestea vor fi executate şi rularea aplicaţiilor cu seturile de date de test obţinute. Se
observă că spre deosebire de testarea statică, testarea dinamică presupune execuţia aplicaţiei care se
testează. Există două strategii de dezvoltare a cazurilor de test: o strategie bazată pe structura
programelor şi o alta, bazată pe funcţionalitatea acestora.
În dezvoltarea unui produs program testarea se realizează pe mai multe niveluri:
1) Testarea pe module
2) Testarea de integrare
3) Testarea de sistem
4) Testarea de acceptare (validare)
 În figura 1.2 este prezentat procesul de verificare şi validare în cadrul ciclului de
dezvoltare a unui produs program. Se identifică etapele şi nivelurile procesului de testare
produselor program.

Fig. 1.2 Testarea produselor program în ciclul de dezvoltare

În cadrul testării de module se realizează certificarea celor mai mici unități software
care pot fi compilate şi editate independent. În programarea clasică un modul este un subprogram
(funcţie sau procedură). În cadrul programelor orientate obiect, cea mai mică unitate testabilă
este clasa.[1]
Testarea de module se concentrează asupra verificarii interfeţelor modulelor, structurilor
de date locale, condiţiilor de limite, căilor independente şi căilor de tratare a erorilor.
Deoarece modulele nu sunt programe de sine stătătoare, este necesar să se construiască
programe sau funcţii care să ajute la testarea de module.
Testarea de integrare este o tehnică sistematică de constituire a structurii programului
prin gruparea componentelor în paralel cu testarea aspectelor legate de interfaţă dintre
componente. Testarea de integrare se realizează într-o manieră neincrementală sau incrementală.
 Testarea neincrementală (big-bang testing) constă în integrarea componentelor din
gruparea tuturor modulelor dintr-o dată, urmată de testarea întregului ansamblu. Acest tip de
integrare nu este recomandată, deoarece corectarea erorilor va fi greu de realizat.
Testarea incrementală presupune construirea structurii programului pas cu pas şi
testarea ansamblului obţinut. Un element important în execuţia testului este secvenţa în care
modulele trebuie sa fie testate. Astfel, testarea se realizează ascendent (bottom-up), descendent
(top-down) sau mixt.
Metoda de testare ascendentă (buttom-up testing) presupune testarea mai întâi a
modulelor de pe cel mai jos nivel al ierarhiei programului, apoi se continuă în sus cu testarea
celorlalte module. Metoda de testare ascendentă necesită construcţia de programe conducătoare
pentru a iniţializa mediul şi pentru a apela modulele. Programele de pe nivelul de sus, care de
obicei sunt critice, sunt testate ultimele. În timp sunt descoperite erori care pot influienţa multe
module care au fost deja testate. După corecţia erorilor este necesar ca toate modulele de pe
nivelurile de jos să fie testate regresiv.
În metoda testării descendente (top-down testing), modulul din vîrful ierarhiei de
programe este testat primul, procesul de testare continuând cu modulele de pe nivelurile
inferioare. Metoda de testare descendentă necesită construcţia de module vide asociate
subprogramelor care nu sunt disponibile. Avantajul acestei metode este că dacă este descoperită
o eroare în modulele de pe nivelurile înalte, impactul va fi asupra modulelor de pe nivelurile de
jos care nu au fost încă implementate, deci refacerea modulelor de pe nivelurile inferioare poate
fi evitată.
În cadrul metodei mixte, testarea urmează mai întâi metoda descendentă. Modulele
selectate de pe nivelurile inferioare sunt testate utilizînd metoda ascendentă. Această flexibilitate
permite preluarea avantajelor metodelor ascendentă şi descendentă. În cele mai multe produse
program, metoda mixtă este cea mai potrivită modalitate de abordare.
Pe masură ce sunt adaugate noi module în cadrul testarii de integrare, apar schimbări în
aplicaţie, care pot să modifice comporatmentul structurii obţinute anterior. În acest context este
executată testarea de regresie, prin care se re-testează noua structură obţinută, utilizînd o parte
din testele utilizate în etapa precedentă de integrare.
Testarea de validare are loc după ce toate erorile de interfaţă descoperite în cadrul
testării de integrare au fost corectate. Testarea de validare se încheie cu succes atunci cînd
funţionalitatea produsului program este în conformitate cu cerinţele beneficiarului. Pentru
testarea de validare se utilizează o serie de teste funcţionale pentru a confirma faptul că produsul
program se comportă conform cerinţelor.
În cadrul testării de validare se regăsesc testările alfa şi beta. Testarea alfa este realizată
la firma care produce produsul program, beneficiarul fiind acela care conduce testele. Testarea
beta este realizată la beneficiari şi utilizatori finali. Aceştea primesc o versiune a produsului
program, versiune apropiată de cea finală şi o utilizează în scopul descoperirii erorilor şi a
problemelor de performanţă şi funcţionalitate. Problemele apărute în cadrul acestei testări sunt
raportate firmei care a realizat aplicaţia. După ce perioada acordată pentru testarea beta s-a
terminat, toate erorile apărute sunt corectate, urmînd să se realizeze versiunea finală a produsului
program.
După ce a avut loc testarea produsului program, intervine testarea de sistem, prin care
se testează întregul sistem în care produsul program este o parte componentă a acestuia. Testarea
de sistem presupune rularea unor teste diferite, astfel incît să fie examinate toate caracteristicile
sistemului.

1.1.2 Defectele produselor program

Nu toate defectele software sunt cauzate de greseli in cod. O sursa raspindita de defecte
costisitoare sunt lacunele si neclaritatile la nivel de cerinte. Cerintele non-functionale precum ar
fi testabilitatea, scalabilitatea, mentenabilitatea, usabilitatea, performanta si securitatea sunt o
sursa raspindita de astfe de erori.

Defectele software se manifesta ca rezultat al urmatorului proces: un programator comite

o eroare , care la rindul ei rezulta intr-un defect(bug) la nivel de codul sursa al programului; daca
acest defect este executat, in anumite conditii sistemul va produce un rezultat gresit, ceea ce
ulterior va duce la o esuare a programului va duce la o esuare a programului.. De exemplu,
defectele ce se conțin într-o secțiune de cod "mort" niciodată nu vor duce la eșuarea programului.
Defectele se pot manifesta ca eșuări la schimbarea împrejurimii în care rulează programul.[2]

Un tester bun trebuie să poată folosi diferiţi termeni pentru a descrie ce s-a intamplat
cand a eşuat softul. In continuare este dată o listă cu termenii folosiţi:
1. Defect (Defect)

2. Excepţie (Variance)
 3. Eşec (Failure)

4. Problemă (Problem)

5. Eroare (Error)

6. Incident (Incident)

7. Anomalie (Anomaly)

8. Inconsistenţă (Inconsistency)

9. Aparenţă (Feature)

10. Neajuns (Fault)

11. Bug

Care dintre aceşti termeni vor fi folosiţi pentru descrierea erorilor ţine doar de cultura
companiei şi de stadiul la care a fost descoperită eroarea.
De obicei orice eroare software este numită „bug”, însă acest termen nu poate fi
acceptat cand se completează diferite rapoarte despre testarea softului. Erorile software apar cand
una sau mai multe dintre următoarele afirmaţii sunt adevărate:
1. Softul nu execută ceva ce specificaţiile spun că trebuie să execute.
2. Softul execută ceva ce specificaţiile spun că nu trebuie să execute.
3. Softul execută ceva ce in specificaţii nu este menţionat.
4. Softul nu execută ceva ce specificaţiile nu menţionează dar ar trebui să menţioneze.
5. Softul este greu de inţeles, greu de folosit, lent sau se vede că nu a fost proiectat corect.
Această definiţie a erorilor acoperă o mare parte de probleme, de aceea testerii folosesc
aceste reguli pentru a identifica diferite tipuri de probleme in aplicaţiile software.
Poate fi surprinzător, dar cel mai mic procent de erori sunt cele provenite de
programare. Cele mai multe erori sunt cauzate de deficienţele din specificaţie (≈ 60%), uneori
specificaţia pur şi simplu nu este scrisă. Alte motive – specificaţia nu este descrisă in detaliu, a
fost modificată constant şi nu a fost adusă la cunoştinţa intregii echipe de dezvoltare. Altă sursă
de erori este etapa de proiectare (≈ 30%), cauzele apariţiei erorilor aici sunt similare cu cele din
specificaţii ( modificări, comunicarea rea etc.). Relativ puţine (uneori sub 15%) sunt erorile
directe de programare. Ele pot apărea din cauza complexităţii softului, a documentaţiei
insuficiente (in special in codul care a fost modificat), a timpului insuficient planificat pentru
programare sau a erorilor de proiectare. Uneori programatorii nu inţeleg corect cerinţele ori
cerinţele nu sunt formulate bine.
Erorile depistate şi fixate in faza de scriere a specificaţiilor nu costă practic nimic, cele
care nu au fost depistate inainte de faza implementării şi testării pot ajunge la sute de dolari.
Dacă insă clientul a găsit defecte după livrarea şi lansarea produsului, costul erorilor poate creşte
de la mii la milioane de dolari. Deci costul erorilor poate creşte exponenţial avansand in procesul
de producţie de la specificare pană după livrare.

1.1.3 Comparaţie între testarea manuală şi cea automată

Testarea manuală este procesul de testare manuală a software-ului pentru identificarea
defectelor. Este nevoie de un tester ce va juca rolul unui utilizator final și va folosi toate
caracteristicile produsului pentru a se asigura că comportamentul este corect. Pentru a garanta
calitatea testării, testerul de multe ori scrie un plan de testare (Test Plan) după care se conduce.
Acest plan implică o serie importantă de scenarii și cazuri de testare. Testarea este o etapă
importantă în procesul de creare a software-lui înainte de a elibera produsul către utilizatorii
finali.
Pentru proiecte mici (inclusiv prototipuri), testarea de explorare poate fi suficientă. Cu
această abordare informală, testerul nu urmează nicio procedură de testare riguroasă, ci
explorează interfața aplicației folosind cât mai multe dintre caracteristicile acesteia. El utilizeaza
informații obținute în testele anterioare pentru a obține intuitiv alte teste suplimentare. Succesul
de explorare a testării manuale se bazează foarte mult pe expertiza domeniului de testere. Lipsa
de cunoștințe a testerului va conduce la incompletitudinea procesului de testare. Unul dintre
avantajele cheie ale unei abordări informale este de a obține o imagine intuitivă, prin cum “se
simte” de a utiliza aplicația.
Proiecte mari, de scară largă, care se bazează pe testarea manuală, necesită o
metodologie mai strictă, în scopul de a maximiza numărul de defecte care pot fi găsite. O
abordare sistematică se concentrează pe cazuri de testare prestabilite și implică, în general,
următorii pași:
1. Trebuie creat un plan de testare, în care este aleasă o metodologie de testare generală. Se
aleg resursele, cum ar fi oameni, calculatoare și licențe software.
2. Se scrie detaliat scenariile de testare, pas cu pas, clar pentru testeri.
 3. Se atribuie anumite cazuri de testare pentru testeri, care să urmeze manual pașii și să
înregistreze rezultatele.
4. Se înregistrează raportul de executare a scenariilor/cazurilor de testare. Acest raport
urmând a fi analizat atât de testeri, cât și de programatorii software-ului în cauză.
Testarea manuală poate fi aplicată prin metodele de testare "cutia albă", "cutia
neagră" sau "cutia sură". În testarea de tip "cutie albă" testerul este preocupat de executare
declarațiilor prin codul sursă. În testarea de tip "cutia neagra", software-ul este condus pentru a
verifica defectele și este mai puțin preocupat de modul de prelucrare a datelor de intrare.
Testerea de tip "cutia neagră" nu are acces la codul sursă. Testarea "cutia sură" este preocupată
de datele cu care rulează software-ul combinată cu o înțelegere a codului sursă și a algoritmilor.
Testarea automatizată - reprezintă o testare dinamică și analitică, care presupune
utilizarea unui program pentru executarea procedurilor (test case-urilor) sau a întregilor scenarii
de testare.
În ultimul timp pentru testarea automatizată se folosesc tot mai des așa-numitele xUnit
frameworks, din care fac parte JUnit, TestNG sau DBUnit. Ele permit testarea codului pentru a
verifica programul în diverse circumstanțe. De exemplu, aceleași proceduri de testare se folosesc
pentru a verifica comportamentul programului în diferite sisteme de operare.
Testarea automată are niște avantaje specifice pentru a crește eficacitatea testării
programelor pe o perioadă mai lungă. Aplicând testarea automată se obține răspuns la
următoarele:
 Testarea repetată a produsului
 Răspuns rapid pentru programatori referitor la calitatea produsului software
 Posibilitatea nelimitată a iterațiilor de testare
 Posibilitatea de a raporta defectele în mod automat
 Găsirea defectelor care nu sunt găsite de testarea manuală.

Testarea automată nu este mereu avantajoasă. Sunt multe cazuri unde testarea manuală
este mai indicată. De exemplu dacă interfața grafică a unei aplicații va fi schimbată des, testele
automate tot trebuie modificate. În unele cazuri nu este timp suficient pentru testarea automată.
Pentru perioadele scurte de testare, testarea manuală e indicată. Când programul trebuie finisat
într-un termen foarte restrâns si teste automate nu sunt, atunci testarea manuală e soluția cea mai
bună.
Testarea automată se doreşte a fi soluţia ideală pentru reducerea timpului de dezvoltare
şi a costurilor. O echipă de testeri poate să pornească uneltele de testare automată, să le lase să
ruleze şi în final să colecteze şi analizeze rezultatele. Timpul este astfel mai bine organizat şi
poate fi petrecut pentru izolarea şi raportarea bug-urilor.
Testarea manuală şi testarea automată sunt mai degrabă două procese diferite, decât
două căi diferite de a executa acelaşi proces: dinamica lor este diferită precum şi modul de a
releva bug-urile. Testarea manuală este mai folositoare în situaţiile în care este nevoie urgent de
rezultatele unor tipuri de teste specifice şi limitate, când se doreşte ca timpul de feedback să fie
foarte scurt, iar costurile să fie relativ mici.
Cum îmbunătăţirea calităţii produsului implică costuri adiţionale pentru găsirea bug-
urilor şi gestionarea acestora până la repararea lor definitivă, testarea manuală s-a dovedit a fi în
timp extrem de costisitoare. Testarea manuală pe scară largă presupune alocarea de resurse
hardware şi umane destul de mari, iar riscul să apară erori este amplificat de factorul uman.
Testarea automată necesită un efort iniţial mai mare pentru planificarea, organizarea şi
producerea testului, criteriul principal în obţinerea de rezultate bune fiind planificarea atentă,
amănunţită şi precisă a acestuia.
O alternativă interesantă este aşa-numita "testare parţială". Această soluţie este o
combinaţie de jumătate testare manuală şi jumătate testare automată, aceasta din urmă fiind
folosită numai acolo unde se pot obţine beneficii maxime.