Sunteți pe pagina 1din 12

Introducere

Fiecare produs software are o audien caracteristic. De aceea, cnd se investetedezvolt sau investete n dezvoltarea unui produs software, trebuie s se evalueze acceptabilitatea produsului din perspectiva utilizatorilor finali, audienei int, cumprtorilor i altor pri interesate. Testarea Software este procesul care vine sa fac aceast evaluare posibil ntr-un mod ct mai obiectiv, entru a asigurarea calitatii i siguranei aplicaiilor software . Dezvoltarea aplicaiilor software implic o serie de activiti, n care posibilitatea erorii umane este foarte ridicat. Testarea este un element cheie n procesul de dezvoltare, a crui scop este 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 i instrumentarelor folosite n testarea automat. Testarea automat const n executarea unei secvene de aciuni fr intervenie uman i pot simula utilizarea unei aplicaii n condiii de simultaneitate ridicat. Majoritatea produselor necesit s fie testate de mai multe ori, pe mai multe platforme software i hardware. Prin folosirea testrii automate, costurile testrilor repetate se reduc aproape la zero. Scopul principal al automatizrii este de a reduce timpul de testare prin verificarea zonelor care au fost deja testate meninnd acelai nivel de calitate. n acest fel, se evit pierderea de timp, bani i efort pentru a face angajri, deoarece noii testeri au nevoie de perioad de adaptare, training i cheltuieli logistice. E cert faptul c pe termen scurt soluiile de automatizare sunt mai scumpe dect angajarea a civa noi testeri, ns soluiile de testare automat sunt mai avantajoase pe msur ce se dezvolt noi release-uri i este nevoie de nc civa angajai de fiecare dat i astfel costurile pe termen lung treptat cresc. Investiia iniial este mai mare, dar beneficiile se vd n timp, deoarece permite testerilor s se concentreze pe modulele noi fcnd 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 soluii de teste automate, ns echipa de testeri rmne indispensabil.

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 de instruciuni scrise. Nu exist un astfel de proces de testare ce ar permite gsirea tuturor defectelor ce le poate conine 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 constrngerile care reprezint criterii de acceptan. Aceste criterii pot fi derivate din specificaiile tehnice, produse asemntoare comparabile, versiuni anterioare ale aceluiai produs, ateptri fa de produs enunate de ctre utilizator sau client, standarde distinctive, legi n vigoare, etc. n funcie de metoda de testare utilizat, testarea software-ului poate fi aplicat n orice moment al procesului de dezvoltare. n mod tradiional, majoritatea testelor se efectueaz dup ce au fost definite cerinele i procesul de codificare a fost finalizat . De fapt, metodologia de testare depinde esenial de modul de dezvoltare a programului. Este greu de determinat care metoda de testare va fi cea mai eficient. Scopul esential al testrii 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 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 alegerea solutiilor. Aceste solutii se raporteaza la realitatea inconjuratoare si, implicit, la necesitatile clientului. Procesul de dezvoltare al produselor software este alctuit din urmtoarele etape: specificarea cerinelor, 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 cerinelor se determin necesitile pentru toate elementele sistemului, att hardware ct i software. Testarea specificaiilor se realizeaz prin metode de 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, 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 interfeelor. Scopul proiectrii 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 mainii de calcul.

Implementarea este cu att mai uor de realizat cu ct proiectarea se realizeaz mai n detaliu. Testarea n etapa de implementare are rolul de a evidenia diferenele dintre comportamentul produsului din specificaii 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 att asupra logicii interne a programului, avnduse n vedere ca anumite elemente ale acestuia sa fie parcurse, ct i pe funcionalitatea sa extern, pe baza specificaiilor. Se compar rezultatele efective obinute dup rularea programului cu seturi de date de test cu rezultatele prevzute pe baza specificaiilor. n timp, dup livrarea la beneficiar, aplicaiile software sufer schimbri care se datoreaz erorilor descoperite pe parcursul funcionrii aplicaiei, modificrilor mediului n care ruleaz aplicaia (software, hardware) precum i noilor cerine de performan i funcionalitate dorite de 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 ca urmare a unor cerinte ulterioare. n cadrul ciclului de dezvoltare software, un rol important l au verificarea i vali darea (V & V). Verificarea i validarea reprezint un proces prin care se determin dac cerinele unui sistem sau component sunt complete i corecte, dac rezultatul fiecrei faze de dezvoltare ndeplinete cerinele sau condiiile impuse n faza anterioar i dac sistemul sau componenta final este n concordan cu cerinele specificate. Verificarea este mulimea activitilor care asigur c o aplicaie software implementeaz corect o anumit funcie. Testarea software este o component a procesului de V & V. Validarea este mulimea activitilor care asigur c o aplicaie software realizat este n

concordan cu cerinele beneficiarului. Pe msura dezvoltrii incrementale a aplicaiei e-DSI rezultatele din fazele intermediare sunt validate de ctre beneficiar. Testarea sau analiza static are ca scop examinarea aplicaiilor software fr a fi executate i cuprinde activiti precum inspeciile, execuia simbolic i verificarea. Aceste activiti fac parte din categoria evalurile tehnice. Inspeciile codului presupun citirea sau inspecia vizual a codului surs de ctre un grup de persoane. Avnd la dispoziie codul surs i specificaiile de proiectare, grupul de persoane din echipa de inspecie urmrete explicaiile programatorului legate de logica programului, instruciune cu instruciune. 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/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 secvene de cod de testat pe baza unor seturi de test pregtite anterior. Prin urmrirea programului pas cu pas sunt identificate erori care apar la acest nivel. Rezultatele acestei activiti de verificare depind, ca i n cazul inspeciilor codului, de atitudinea echipei fa de persoana care a scris programul, avnd n vedere faptul c atenia 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 aplicaiilor software n scopul generrii datelor de test cu care acestea vor fi executate i rularea aplicaiilor cu seturile de date de test obinute. Se observ c spre deosebire de testarea static, testarea dinamic presupune execuia aplicaiei care se testeaz. Exist dou strategii de dezvoltare a cazurilor de test: o strategie bazat pe structura programelor i o alta, bazat pe funcionalitatea 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 testrii de module se realizeaz certificarea celor mai mici uniti software care pot fi compilate i editate independent. n programarea clasic un modul este un subprogram (funcie sau procedur). n cadrul programelor orientate obiect, cea mai mic unitate testabil este clasa.[1] Testarea de module se concentreaz asupra verificarii interfeelor modulelor, structurilor de 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 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 obinut. Un element important n execuia testului este secvena 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 nti 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 construcia de programe conductoare pentru a iniializa 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 influiena multe module care au fost deja testate. Dup corecia erorilor este necesar ca toate modulele de pe nivelurile 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 nivelurile inferioare. Metoda de testare descendent necesit construcia 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 nti metoda descendent. Modulele selectate de pe nivelurile inferioare sunt testate utiliznd 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 schimbri n aplicaie, care pot s modifice comporatmentul structurii obinute anterior. n acest context este executat testarea de regresie, prin care se re-testeaz noua structur obinut, utiliznd o parte din testele utilizate n etapa precedent de integrare. Testarea de validare are loc dup ce toate erorile de interfa descoperite n cadrul testrii de integrare au fost corectate. Testarea de validare se ncheie cu succes atunci cnd

funionalitatea produsului program este n conformitate cu cerinele beneficiarului. Pentru testarea de validare se utilizeaz o serie de teste funcionale pentru a confirma faptul c produsul program se comport conform cerinelor. n cadrul testrii de validare se regsesc testrile 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. Acetea primesc o versiune a produsului program, versiune apropiat de cea final i o utilizeaz n scopul descoperirii erorilor i a problemelor de performan i funcionalitate. Problemele aprute n cadrul acestei testri sunt raportate firmei care a realizat aplicaia. Dup ce perioada acordat pentru testarea beta s -a terminat, toate erorile aprute sunt corectate, urmnd 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 inct 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 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 intamplat cand a euat softul. In continuare este dat o list cu termenii folosii: 1. Defect (Defect) 2. Excepie (Variance)

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 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 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 folosesc aceste 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%), uneori specificaia pur i simplu nu este scris. Alte motive specificaia nu este descris in detaliu, a fost modificat constant i nu a fost adus la cunotina intregii echipe de dezvoltare. Alt surs de erori este etapa de proiectare ( 30%), cauzele apariiei erorilor aici sunt similare cu cele din specificaii ( modificri, comunicarea rea etc.). Relativ puine (uneori sub 15%) sunt erorile directe de programare. Ele pot aprea din cauza complexitii softului, a documentaiei insuficiente (in special in codul care a fost modificat), a timpului insuficient planificat pentru

programare sau a erorilor de proiectare. Uneori programatorii nu ineleg corect cerinele ori cerinele nu sunt formulate bine. Erorile depistate i fixate in faza de scriere a specificaiilor nu cost practic nimic, cele care 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 crete de la mii la milioane de dolari. Deci costul erorilor poate crete exponenial avansand in procesul de 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 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 testrii, 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 ctre 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 interfaa aplicaiei folosind ct mai multe dintre caracteristicile acesteia. El utilizeaza informaii obinute n testele anterioare pentru a obine intuitiv alte teste suplimentare. Succesul de explorare a testrii manuale se bazeaz foarte mult pe expertiza domeniului de testere. Lipsa de cunotine a testerului va conduce la incompletitudinea procesului de testare. Unul dintre avantajele cheie ale unei abordri informale este de a obine o imagine intuitiv, prin cum se 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. O abordare sistematic se concentreaz pe cazuri de testare prestabilite i implic, n general, urmtorii pai: 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 licene 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 paii i s nregistreze rezultatele. 4. Se nregistreaz raportul de executare a scenariilor/cazurilor de testare. Acest raport urmnd 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", "cutia neagr" sau "cutia sur". n testarea de tip "cutie alb" testerul este preocupat de executare declaraiilor prin codul surs. n testarea de tip "cutia neagra", software-ul este condus pentru a verifica defectele i este mai puin 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 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 scenarii de testare. n ultimul timp pentru testarea automatizat se folosesc tot mai des aa-numitele xUnit frameworks, din care fac parte JUnit, TestNG sau DBUnit. Ele permit testarea codului pentru a verifica programul n diverse circumstane. De exemplu, aceleai proceduri de testare se folosesc pentru a verifica comportamentul programului n diferite sisteme de operare. Testarea automat are nite avantaje specifice pentru a crete eficacitatea testrii programelor pe o perioad mai lung. Aplicnd testarea automat se obine rspuns la 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 manual este mai indicat. De exemplu dac interfaa grafic a unei aplicaii 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. Cnd programul trebuie finisat

ntr-un termen foarte restrns si teste automate nu sunt, atunci testarea manual e soluia cea mai bun. Testarea automat se dorete a fi soluia 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, dect dou ci diferite de a executa acelai proces: dinamica lor este diferit precum i modul de a releva bug-urile. Testarea manual este mai folositoare n situaiile n care este nevoie urgent de rezultatele unor tipuri de teste specifice i limitate, cnd se dorete ca timpul de feedback s fie foarte scurt, iar costurile s fie relativ mici. Cum mbuntirea calitii produsului implic costuri adiionale pentru gsirea bugurilor i gestionarea acestora pn la repararea lor definitiv, testarea manual s-a dovedit a fi n timp extrem de costisitoare. Testarea manual pe scar larg presupune alocare a de resurse hardware i umane destul de mari, iar riscul s apar erori este amplificat de factorul uman. Testarea automat necesit un efort iniial mai mare pentru planificarea, organizarea i producerea testului, criteriul principal n obinerea de rezultate bune fiind planificarea atent, amnunit i precis a acestuia. O alternativ interesant este aa-numita "testare parial". Aceast soluie este o combinaie de jumtate testare manual i jumtate testare automat, aceasta din urm fiind folosit numai acolo unde se pot obine beneficii maxime.