Testarea Produselor Software

8/13/2019 Testarea Produselor Software

1/12

Introducere

Fiecare produs software are o audien caracteristic. De aceea, cnd seinvestetedezvolt sau investete n dezvoltarea unui produs software, trebuie s se evalueacceptabilitatea produsului din perspectiva utilizatorilor finali,audienei int, cumprtorilor ialtor pri interesate. Testarea Software este procesul care vine sa fac aceast evaluare posibilntr-un mod ct mai obiectiv, entru a asigurarea calitatii i siguranei aplicaiilor software.

Dezvoltarea aplicaiilor software implic o serie de activiti, n care posibilitatea erorumane este foarte ridicat. Testarea este un element cheie n procesul de dezvoltare, a crui sceste de a identifica aceste erori i de a izola defectele ce au cauzat aceste erori.

Obiectivul lucrrii const n evidenierea importanei testrii ca etap n dezvoltarea

oricrui sistem informatic, fazele de testare a unui produs software, prezentarea metodelor iinstrumentarelor folosite n testarea automat.

Testarea automat const n executarea unei secvene de aciuni fr intervenie umani pot simula utilizarea unei aplicaii n condiii de simultaneitate ridicat. Majoritatea produsenecesit s fie testate de mai multe ori, pe mai multe platforme software i hardware. Prinfolosirea testrii automate, costurile testrilor repetate se reduc aproape la zero.

Scopul principal al automatizrii este de a reduce timpul de testare prin verificare

zonelor care au fost deja testate meninnd acelai nivel de calitate. n acest fel, se evit pierdede timp, bani i efort pentru a face angajri, deoarece noii testeri au nevoie de perioad dadaptare, training i cheltuieli logistice.

E cert faptulc pe termen scurt soluiile de automatizare sunt mai scumpe dectangajarea a civa noi testeri,ns soluiile de testare automat sunt mai avantajoase pe msurce se dezvolt noi release-uri i este nevoie de nc civa angajai de fiecare dat i astfelcosturile pe termen lung treptat cresc. Investiia iniial este mai mare, dar beneficiile se vd ntimp, deoarece permite testerilor s se concentreze pe modulele noi fcnd ad-hoc testing, metodace poate descoperi multe probleme.n concluzie, pentru a avea produse software performantei bine testate ntr-un timp decent, esteimportant implementarea unei soluii de teste automate, ns echipa de testeri rmnindispensabil.


2/12

1. TEMATICA TESTRII PRODUSELOR PROGRAM Testarea unui produs program este la fel de important ca i crearea ei. Statisticile

afirm c dezvoltarea unui produs, orict de bine ar fi executat, produce trei defecte la o sut instruciuni scrise.

Nu exist un astfel de proces de testare ce ar permite gsirea tuturor defectelor ce poate conine un produs program. n schimb, un astfel de proces poate furniza o viziune critsau comparativ, care vine s contrapun unele aspecte ale produsului (cum ar fi: starea comportamentul actual), metricile i constrngerile care reprezint criterii de acceptan. Acecriterii pot fi derivate din specificaiile tehnice, produse asemntoare comparabile, versiu

anterioare ale aceluiai produs, ateptri fa de produs enunate de ctre utilizator sau cliestandarde distinctive, legi n vigoare, etc.

n funcie demetoda de testare utilizat, testarea software-ului poate fi aplicat n oricemoment al procesului de dezvoltare. n mod tradiional, majoritatea testelor se efectueaz duce au fost definite cerinele i procesul de codificarea fost finalizat . De fapt, metodologia detestare depinde esenial de modul de dezvoltare a programului. Este greu de determinat cametoda de testare va fi cea mai eficient.

Scopul esential al testrii este de a verifica functionarea corecta a tuturor componentelosi 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 instrumentel

de testare stabilite anterior.

1.1 Generaliti

1.1.1. Testarea etap a procesului de dezvoltre a produselor software

Finalizarea cu succes a unui proiect software depinde, in mare masura, de alegereasolutiilor. Aceste solutii se raporteaza la realitatea inconjuratoare si, implicit, la necesitatilclientului. Procesul de dezvoltare al produselor software este alctuit din urmtoarele etapespecificarea cerinelor, analiz, proiectare,dezvoltare, testare i mentenan. n figura 1.1 estereprezentat grafic modelul clasic de dezvoltare produselor program.


3/12

Fig. 1.1 Modelul clasic de dezvoltare a produselor program.

n etapa de specificare a cerinelor se determin necesitile pentru toate elementesistemului, att hardware ct i software. Testarea specificaiilor se realizeaz prin metode analiz static: inspecii, parcurgeri i analize tehnice.

Etapa de analiz continu procesul de stabilire a cerinelor.

Obiectivele fazei de analiz sunt:

comunicarea cu partenerul/clientul prin diferite mijloace (chestionare, mese rotunde, etcin vederea obtinerii informatiilor legate de cerintele proiectului si de diverse idei sexpectative;

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 interfeelor. Scopul proiectrii const n definirea tuturorcomponentelor proiectului ntr-o form detaliat. Participarea clientului este incurajata.


4/12

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 for m specific mainii de calcul.Implementarea este cu att mai uor de realizat cu ct proiectarea se realizeaz mai n detalTestarea n etapa de implementare are rolul de a evidenia diferenele dintre comportament produsului din specificaii i cel dat la nivelul utilizatorilor. n aceasta etapa presupunedezvoltarea proiectului pana la obtinerea produsului final solicitat. Totodata, in acest punc produsul va fi prezentat clientului pentru o analiza finala inaintea testarii.

La etapa de testare se concentreaz att asupra logicii interne a programului, avnduse nvedere ca anumite elemente ale acestuia sa fie parcurse, ct i pe funcionalitatea sa extern, baza specificaiilor. Se compar rezultatele efective obinute dup rularea programului cu seturide date de test cu rezultatele prevzute pe baza specificaiilor.

n timp, dup livrarea la beneficiar, aplicaiile software sufer schimbri care sedatoreaz erorilor descoperite pe parcursul funcionrii aplicaiei, modificrilor mediuluin careruleaz aplicaia (software, hardware) precum i noilor cerine de performan i funcionalitat

doritede beneficiar. ntreinerea aplicaiilor 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 caurmare 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 cerinele unsistem sau component sunt complete i corecte, dac rezultatul fiecrei faze de dezvoltandeplinete cerinele sau condiiile impuse n faza anterioar i dac sistemul sau componenfinal este n concordan cu cerinele specificate.

Verificarea este mulimea activitilor care asigur c o aplicaie softwareimplementeaz corect o anumit funcie. Testarea software este o component a procesului de& V. Validarea este mulimea activitilor care asigur c o aplicaie software realizat este n


5/12

concordan cu cerinele beneficiarului. Pe msura dezvoltrii incrementale a aplicaiei e-DSIrezultatele din fazele intermediare sunt validate de ctre beneficiar.

Testarea sau analiza static are ca scop examinarea aplicaiilor software fr a fexecutate i cuprinde activiti precum inspeciile, execuia simbolic i verificarea. Acesactiviti fac parte din categoria evalurile tehnice.

Inspeciile codului presupun citirea sau inspecia vizual a codului surs de ctre ungrup de persoane. Avnd la dispoziie codul surs i specificaiile de proiectare, grupul de persoane din echipa de inspecie urmrete explicaiile programatorului legate de logi programului, instruciune cu instruciune. n acest mod se descoper o serie de erori specifiacestei metode cum ar fi: declararea datelor, referirea datelor, erorile de calcul, erorile dcomparare, erorile de logic, erorile de intrare/ieire, erorile de interfa etc.

Parcurgerile constau n citirea sau inspecia vizual a codului surs de ctre un grup de persoane, ns procedura de lucru este diferit avnd ca scop execuia logic a fiecrei secvede cod de testat pe baza unor seturi de test pregtite anterior. Prin urmrirea programului pas pas sunt identificate erori care apar la acest nivel. Rezultatele acestei activiti de verificadepind, ca i n cazul inspeciilor codului, de atitudinea echipei fa de persoana care a sc programul, avnd n vedere faptul c atenia trebuie acordat programului care se verific i celui care l-a scris.

Verificarea de birou este o tehnic de analiz static n care listingurile codurilor saurezultatele testelor sau alte documente sunt examinate vizual, de obicei de persoana care le-realizat, pentru a identifica erorile sau abaterile de la standardele de dezvoltare sau alte problem

Testarea dinamic presupune examinarea aplicaiilor software n scopul generrii datelor dtest cu care acestea vor fi executate i rularea aplicaiilor cu seturile de date de test obinute. Sobserv c spre deosebire de testarea static, testarea dinamic presupune execuia aplicaiei care testeaz. Exist dou strategii de dezvoltare a cazurilor de test: o strategie bazat pe structur programelor i o alta, bazat pe funcionalitatea acestora.

n dezvoltarea unui produs program testarea se realizeaz pe mai multe niveluri:1) Testarea pe module2) Testarea de integrare3) Testarea de sistem4) Testarea de acceptare (validare)


6/12

n figura 1.2 este prezentat procesul de verificare i validare n cadrul ciclului ddezvoltare a unui produs program. Se identific etapele i nivelurile pr ocesului de testare produselor program.

Fig. 1.2 Testarea produselor program n ciclul de dezvoltare

n cadrultestrii de module se realizeaz certificarea celor mai mici uniti softwarecare pot fi compilate i editate independent. n programarea clasic unmodul este un subprogram(funcie sau procedur). n cadrul programelor orientate obiect, cea mai mic unitate testabeste clasa.[1]

Testarea de module se concentreaz asupra verificarii interfeelor modulelor, structurilode date locale, condiiilor de limite, cilor independente i cilor de tratare a erorilor.

Deoarece modulele nu sunt programe de sine stttoare, este necesar s se construiasc programe sau funcii care s ajute la testarea de module.

Testarea de integrareeste o tehnic sistematic de constituire a structurii programului prin gruparea componentelor n paralel cu testarea aspectelor legate de interfa dintcomponente. Testarea de integrare se realizeaz ntr -o manier neincremental sau incremental.


7/12

Testarea neincremental (big-bang testing)const n integrarea componentelor dingruparea tuturor modulelor dintr-o dat, urmat de testarea ntregului ansamblu. Acest tip deintegrare nu este recomandat, deoarece corectarea erorilor va fi greu de realizat.

Testarea incremental presupune construirea structurii programului pas cu pas itestarea ansamblului obinut. Un element important n execuia testului este secvena n camodulele 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 nti amodulelor de pe cel mai jos nivel al ierarhiei programului, apoi se continu n sus cu testarcelorlalte module. Metoda de testare ascendent necesit construcia de programe conductoare pentru a iniializa mediul i pentru a apela modulele. Programele de pe nivelul de sus, care

obicei sunt critice, sunt testate ultimele. n timp sunt descoperite erori care pot influiena mumodulecare au fost deja testate. Dup corecia erorilor este necesar ca toate modulele de pnivelurile de jos s fie testate regresiv.

n metoda testrii descendente (top-down testing), modulul din vrful ierarhiei de programe este testat primul, procesul de testare continund cu modulele de pe nivelurilinferioare. Metoda de testare descendent necesit construcia de module vide asociasubprogramelor care nu sunt disponibile. Avantajul acestei metode este c dac este descopero eroare n modulele de pe nivelurile nalte, impactul va fi asupra modulelor de pe nivelurile d jos care nu au fost nc implementate, deci refacerea modulelor de pe nivelurile inferioare pofi evitat.

n cadrul metodei mixte,testarea urmeaz mai nti metoda descendent. Moduleleselectate de pe nivelurile inferioare sunt testate utiliznd metoda ascendent. Aceast flexibilit permite preluarea avantajelor metodelor ascendent i descendent. n cele mai multe produ program, metoda mixt este cea mai potrivit modalitate de abordare.

Pe masur ce sunt adaugate noi module n cadrul testarii de integrare, apar schimbri aplicaie, care pot s modifice comporatmentul structurii obinute anterior. n acest context eexecutattestarea de regresie , prin care se re-testeaz noua structur obinut, utiliznd o partedin testele utilizate n etapa precedent de integrare.

Testar ea de vali dare are loc dup ce toate erorile de interfa descoperite n cadrultestrii de integrare au fost corectate. Testarea de validare se ncheie cu succes atunci cn


8/12

funionalitatea produsului program este n conformitate cu cerinele beneficiarului. Penttestarea de validare se utilizeaz o serie de teste funcionale pentru a confirma faptul c produ program se comport conform cerinelor.

n cadrul testrii de validare se regsesc testrilealfa i beta. Testareaalfa este realizatla firma care produce produsul program, beneficiarul fiind acela care conduce testele. Testarebeta este realizat la beneficiari i utilizatori finali. Acetea primesc o versiune a produsulu program, versiune apropiat de cea final i o utilizeaz n scopul descoperirii erorilor i problemelor de performan i funcionalitate. Problemele aprute n cadrul acestei testri suraportate firmei care a realizat aplicaia. Dup ce perioada acordat pentru testarea beta s-aterminat, toate erorile aprute sunt corectate, urmnd s se realizeze versiunea final a produsu program.

Dup ce a avut loc testarea produsului program, intervinetestar ea de si stem , prin carese testeaz ntregul sistem n care produsul program este o parte component a acestuia. Testarde sistem pr esupune rularea unor teste diferite, astfel inct s fie examinate toate caracteristicisistemului.

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 osursa raspindita de astfe de erori.

Defectele software se manifesta ca rezultat al urmatorului proces: un programator comito eroare , care la rindul ei rezulta intr-un defect(bug) la nivel de codul sursa al programului; dacacest defect este executat, in anumite conditii sistemul va produce un rezultat gresit, ceea ceulterior va duce la o esuare a programului va duce la o esuare a programului.. De exemplu,defectele ce se conin ntr -o seciune de cod "mort"niciodat nu vor duce la euarea programului.

Defectele se pot manifesta ca euri la schimbarea mprejurimii n care ruleaz programul.[2]

Un tester bun trebuie s poat folosi diferii termeni pentru a descrie ce s-a intamplatcand a euat softul. In continuare este dat o list cu termenii folosii:

1. Defect (Defect)

2. Excepie (Variance)
http://ro.wikipedia.org/w/index.php?title=Cod_mort&action=edit&redlink=1http://ro.wikipedia.org/w/index.php?title=Cod_mort&action=edit&redlink=1


9/12

3. Eec (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 aceti termeni vor fi folosii pentru descrierea erorilor ine doar de culturcompaniei i de stadiul la care a fost descoperit eroarea.

De obicei orice eroare software este numit bug, ns acest termen nu poate f acceptat cand se completeaz diferite rapoarte despre testarea softului. Erorile software apar cauna sau mai multe dintre urmtoarele afirmaii sunt adevrate:

1. Softul nu execut ceva ce specificaiile spun c trebuie s execute. 2. Softul execut ceva ce specificaiile spun c nu trebuie s execute.

3. Softul execut ceva ce in specificaii nu este menionat. 4. Softul nu execut ceva ce specificaiile nu menioneaz dar ar trebui s menioneze. 5. Softul este greu de ineles, greu de folosit, lent sau se vede c nu a fost proiectat corect

Aceast definiie a erorilor acoper o mare parte de probleme, de aceea testerii foloseaceste reguli pentru a identifica diferite tipuri de probleme in aplicaiile software.

Poate fi surprinztor, dar cel mai mic procent de erori sunt cele provenite de programare. Cele mai multe erori sunt cauzate de deficienele din specificaie ( 60%), unespecificaia pur i simplu nu este scris. Alte motive specificaia nu este descris in detaliu, afost modificat constant i nu a fost adus la cunotina intregii echipe de dezvoltare. Alt sude erori este etapa de proiectare ( 30%), cauzele apariiei erorilor aici sunt similare cu cele dspecificaii ( modificri, comunicarea rea etc.). Relativ puine (uneori sub 15%) sunt eroriledirecte de programare. Ele pot aprea din cauza complexitii softului, a documentaiinsuficiente (in special in codul care a fost modificat), a timpului insuficient planificat pentr


10/12

programare sau a erorilor de proiectare. Uneor i programatorii nu ineleg corect cerinele oricerinele nu sunt formulate bine.

Erorile depistate i fixate in faza de scriere a specificaiilor nu cost practic nimic, cecare nu au fost depistate inainte de faza implementrii i testrii pot ajunge la sute de dolari.Dac ins clientul a gsit defecte dup livrarea i lansarea produsului, costul erorilor poate crede la mii la milioane de dolari. Deci costul erorilor poate crete exponenial avansand in procede producie de la specificare pan dup livrare.

1.1.3 Comparaie ntre testarea manual i cea automat

Testarea manual este procesul de testare manual a software-ului pentru identificareadefectelor. Este nevoie de un tester ce va juca rolul unui utilizator final i va folosi toacaracteristicile produsului pentru a se asigura c comportamentul este corect. Pentru a garancalitatea testrii, testerul de multe ori scrie un plan de testare (Test Plan) dup care se conducAcest plan implic o serie important de scenarii i cazuri de testare. Testarea este o etapimportant n procesul de creare a software-lui nainte de a elibera produsul ctre utilizatoriifinali.

Pentru proiecte mici (inclusiv prototipuri), testarea de explorare poate fi suficient. Caceast abordare informal, testerul nu urmeaz nicio procedur de testare riguroas,

exploreaz interfaa aplicaiei folosind ct mai multe dintre caracteristicile acesteia. El utilizeazainformaii obinute n testele anterioare pentru a obine intuitiv alte teste suplimentare. Succesde explorare a testrii manuale se bazeaz foarte mult pe expertiza domeniului de testere. Lipde cunotine a testerului vaconduce la incompletitudinea procesului de testare. Unul dintreavantajele cheie ale unei abordri informale este de a obine o imagine intuitiv, prin cum simte de a utiliza aplicaia.

Proiecte mari, de scar larg, care se bazeaz pe testarea manual, necesit o

metodologie mai strict, n scopul de a maximiza numrul de defecte care pot fi gsite. abordare sistematic se concentreaz pe cazuri de testare prestabilite i implic, n generaurmtorii pai:

1. Trebuie creat un plan de testare, n careeste aleas o metodologie de testare general. Sealeg resursele, cum ar fi oameni, calculatoare i licene software.

2. Se scrie detaliat scenariile de testare, pas cu pas, clar pentru testeri.
http://en.wikipedia.org/wiki/Software_testinghttp://en.wikipedia.org/wiki/Software_testinghttp://en.wikipedia.org/wiki/Software_testinghttp://en.wikipedia.org/wiki/Software_testinghttp://en.wikipedia.org/wiki/Software_testing


11/12

3. Se atribuie anumite cazuri de testare pentru testeri, care s urmeze manual paii i snregistreze rezultatele.

4. Se nregistreaz raportul de executare a scenariilor/cazurilor de testare. Acest raporturmnd a fi analizat att de testeri, ct i de programatorii software-ului n cauz.

Testarea manual poate fi aplicat prin metodele de testare "cutia alb", "cutineagr" sau "cutia sur". n testarea de tip "cutie alb" testerul este preocupat de executardeclaraiilor prin codul surs. n testarea de tip"cutia neagra", software-ul este condus pentru averifica defectele i este mai puin preocupat de modul de prelucrare a datelor de intrareTesterea de tip "cutia neagr" nu are acces la codul surs. Testarea "cutia sur" este preocupade datele cu care ruleaz software-ul combinat cu o nelegere 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 scenarde testare.

n ultimul timp pentru testarea automatizat se folosesc tot mai des aa-numitele xUnitframeworks, din care fac parte JUnit, TestNG sau DBUnit. Ele permit testarea codului pentru verifica programul n diverse circumstane. De exemplu, aceleai proceduri de testare se folose pentru a verifica comportamentul programului n diferite sisteme de operare.

Testarea automat are nite avantaje specifice pentru a crete eficacitatea testri programelor pe o perioad mai lung. Aplicnd testarea automat se obine rspuns urmtoarele:

Testarea repetat a produsului Rspuns rapid pentru programatori referitor la calitatea produsului software Posibilitatea nelimitat a iteraiilor de testare Posibilitatea de a raporta defectele n mod automat Gsirea defectelor care nu sunt gsite de testarea manual.

Testarea automat nu este mereu avantajoas. Sunt multe cazuri unde testarea manuaeste mai indicat. De exemplu dac interfaa grafic a unei aplicaii va fi schimbat des, testautomate tot trebuie modificate. n unele cazuri nu este timp suficient pentru testarea automat.Pentru perioadele scurte de testare, testarea manual e indicat. Cnd programul trebuie fini


12/12

ntr-un termen foarte restrns si teste automate nu sunt, atunci testarea manual e soluia cea m bun.

Testarea automat se dorete a fi soluia ideal pentru reducerea timpului de dezvoltai a costurilor. O echip de testeri poate s porneasc uneltele de testare automat, s le lase 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, decdou ci diferite de a executa acelai proces: dinamica lor este diferit precum i modul dereleva bug-urile. Testarea manual este mai folositoare n situaiile n care este nevoie urgent drezultatele unortipuri de teste specifice i limitate, cnd se dorete ca timpul de feedback s fifoarte scurt, iar costurile s fie relativ mici.

Cum mbuntirea calitii produsului implic costuri adiionale pentru gsirea bug-urilor i gestionarea acestora pn la repararea lor definitiv, testarea manual s-a dovedit a fi ntimp extrem de costisitoare. Testarea manual pe scar larg presupune alocarea de resursehardware i umane destul de mari, iar riscul s apar erori este amplificat de factorul umaTestarea automat necesit un efort iniial mai mare pentru planificarea, organizarea i producerea testului, criteriul principal n obinerea de rezultate bune fiind planificarea atenamnunit i precis a acestuia.

O alternativ interesant este aa-numita "testare parial". Aceast soluie este ocombinaie de jumtate testare manual i jumtate testare automat, aceasta din urm fiinfolosit numai acolo unde se pot obine beneficii maxime.

Testarea Produselor Software

Documents

Transcript of Testarea Produselor Software