Managementul Procesului de Testare al Unui Produs Software
Managementul procesului de testare al unui produs software
Introducere
-importanta testarii si a unui management bun
De unde apar probleme software
Cerințe definite incomplet 50%
Modelare neclară sau insuficientă 30%
Erori de programare 20%
Necesitatea testarii:
Satisfacerea cerințelor clientului este cheia reușitei oricărei afaceri.
Obținerea încrederii clientului prin oferirea un soft bun, de calitate.
Calitatea softului este indicată doar prin testarea acestuia.
Costurile erorilor
Erorile depistate și fixate în faza de descriere a specificațiilor nu costă practic nimic.
Erorile depistate după livrarea produsului mărește costul acestora de la mii la milioane de dolari.
Metodologiile moderne, precum Agile, Scrum, eXtreme Programming și altele pun un accent deosebit pe procesul de testare pe care îl integrează în profunzime cu celelalte activități care țin de dezvoltarea programelor informatice: planificare, proiectare, programare, evaluare și control.
[1] http://ro.wikipedia.org/wiki/Testarea_software
1. Testarea software
1.1. Definiție
Testarea software este procesul căutării erorilor într-un program software, indiferent dacă acestea au cauze logice sau fizice. Obiectivul principal al testării software este găsirea erorilor, altfel spus, de a identifica neconcordanța dintre ceea ce este planificat să efectueze aplicația și ceea ce realizează în realitate. Testarea nu presupune identificarea cauzei erorilor și corecția acestora, acestea fiind activități specifice depanării.
Conform IEEE Standard Glossary (1983), definitia testarii este:
"Procesul de exercitare sau evaluarea unui sistem prin mijloace manuale sau automate pentru a verifica dacă îndeplinește cerințele specificate sau pentru a identifica diferentele dintre rezultatele așteptate și cele reale."[6]
Testarea este privită ca o componentă majoră a calității software. Un produs software testabil se consideră ca fiind inteligibil (structurat, concis și auto-descriptibil) și măsurabil (accesibil și cuantificabil).
Testarea software este necesară pentru asigurarea calității, dar este un proces scump și laborios, ce consumă de la o treime până la o jumătate din costul unui proiect. Activitile de testare ocup circa 30-50% din efortul total de dezvoltare, n funcie de natura aplicaiei.[1]
Tehnicile și metodele moderne de elaborare a produselor software acordă o importanță deosebită efortului de înlăturare a erorilor de analiză, proiectare și programare prin folosirea unor mijloace evoluate de testare.
Aceasta nu este o doar fază ci un întreg proces care trebuie integrat în toate fazele construcției produsului software, fiecare faza având modul său specific de testare. Acest lucru permite descoperirea erorilor devreme în procesul de dezvoltare software având drept consecință costuri mai mici de corecție.
Bill Hetzel, unul dintre fondatorii meseriei de tester considera (Complete Guide to Software Testing Processes) că: “Testarea este orice activitate avînd ca obiectiv evaluarea unui atribut ori a funcționalității unui program sau sistem și determinarea măsurii în care acesta realizează cerințele impuse.” [6]
1.2. Caracteristicile testării
Testarea nu permite tragerea unei concluzii definitive privind inexistența oricărei erori în sistemul testat. Aceasta nu trebuie confundată cu depanarea, scopul ei creșterea calității sistemului testat prin eliminarea erorilor, reducerea timpului de dare în folosință, reducerea cheltuielilor legate de mentenanță, eliminarea insatisfacțiilor utilizatorilor.
Totodata ea urmarește să pună în evidență situațiile în care sistemul nu funcționează corect, nu să demonstreze că sistemul este funcțional. Problema dificilă este de a ști ce înseamnă că un sistem îndeplinește cerințele impuse. Pot să apară două concepții:
Se iau în considerare numai cerințele impuse prin specificațiile de proiect.
Pe lângă specificațiile de proiect (dacă există) se iau în considerare și cerințele presupuse pe baza experienței celui ce testează precum și nivelul de satisfacție al utilizatorilor.
Cu cât softwareul transformă mai repede defectele dintr-un program ȋn eșecuri, spunem că softwareul are un nivel mai ridicat de testabilitate, ceea ce convine echipei de testare.
Pentru a obține produse cu un grad ȋnalt de testabilitate este necesară o colaborare strȋnsă ȋntre testori și dezvoltatori ȋncă de la ȋnceputul ciclului de viață al produsului. [2]
Nu există niciun proces de testare care sa permita identificarea tuturor defectelor posibile ale unui ale unui produs software. Un proces de testare furniza o viziune critică sau comparativă, tudiind metricile si constrângerile care servesc drept criterii de acceptantă. Aceste criterii pot fi derivate din:
specificații tehnice
produse asemănătoare comparabile
versiuni anterioare ale aceluiași produs
așteptari față de produs enunțate de către utilizator sau client
standarde relevante
legi în vigoare
Fiecare produs software are o audiență caracteristică. Testarea Software este procesul care procesul care realizează evaluarea acceptabilității produsului din perspectiva utilizatorilor finali, audientei tintă si a cumpărătorilor într-un mod cât mai obiectiv.[3]
1.3. Nivelurile testării software
În dezvoltarea unui produs software testarea se realizează pe mai multe niveluri: testarea de module, testarea de integrare, testarea de sistem și testarea de acceptare (validare). În figura 1.1. este prezentat procesul de verificare și validare în cadrul ciclului de dezvoltare a unui produs software. Aici sunt identificate etapele de realizare a aplicației precum și etapele și nivelurile procesului de testare software.
Fig. 1.1. – Nivelurile testării software [4]
1.3.1. Testarea de module
În cadrul testării de module se realizează verificarea celor mai mici unități software care pot fi compilate și link-editate independent. În programarea clasică un modul este un subprogram (funcție sau procedură).
Testarea de module se concentrează asupra verificării interfețelor modulelor, structurilor de date locale, condițiilor de la 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.
O primă categorie o reprezintă programele conducătoare (drivers) care apelează modulele supuse testării cu datele de test construite și preiau rezultatele execuției.
O altă categorie este reprezentată de funcțiile sau procedurile apelate de către modulul de testat. Acestea sunt substituite cu subprograme care au același prototip, însă cu funcționalitate redusă la minim, denumite module vide (stubs). Modulele vide sunt funcții sau proceduri simple care nu fac nimic în afara returnării controlului, sau sunt funcții sau proceduri complexe, care simulează efectul apelării modulelor reale. În cele mai multe cazuri, modulele vide simple sunt nepotrivite. Un efort considerabil este necesar pentru implementarea de module vide complexe. Acestea vor fi descrise detaliat in capitolele urmatoare.[4]
1.3.2. Testarea de integrare
Testarea de integrare este o tehnică sistematică de construire a structurii programului prin gruparea componentelor în paralel cu testarea aspectelor legate de interfața dintre componente. Testarea de integrare se realizează într-o manieră neincrementală sau incrementală.
Testarea neincrementală (big-bang testing) constă în integrarea componentelor prin gruparea tuturor modulelor dintr-o dată, urmată de testarea întregului ansamblu. Acest tip de integrare nu este recomandată, deoarece corectarea erorilor va fi foarte 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 să fie testate. Astfel, testarea de integrare se realizează ascendent (bottom-up), descendent (top-down) sau mixt.
Metoda de testare ascendentă (bottom-up testing) presupune testarea mai întâi a modulelor de pe cel mai de 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 influenț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 de ascendentă și descendentă. În cele mai multe aplicații, metoda mixtă este cea mai potrivită modalitate de abordare.
Pe măsură ce sunt adăugate noi module în cadrul testării de integrare, apar schimbări în software, care pot să modifice comportamentul 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.[4]
1.3.3. Testarea de validare (acceptare)
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 funcționalitatea aplicației software este în conformitate cu cerințele beneficiarului. Pentru testarea de validare se utilizează o serie de teste funcționale pentru a confirma faptul că aplicația software 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 aplicația software, beneficiarul fiind acela care conduce testele. Testarea beta este realizată la beneficiari și utilizatori finali. Aceștia primesc o versiune a aplicației software, 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 aplicației software.[4]
1.3.4. Testarea de sistem
După ce a avut loc testarea aplicației software, intervine testarea de sistem, prin care se testează întregul sistem în care produsul software este o parte componentă a acestuia. Testarea de sistem presupune rularea unor teste diferite, astfel încât să fie examinate toate caracteristicile sistemului cum ar fi capacitatea de recuperare (recovery testing), securitatea, rezistenta la solicitare de solicitare (stress testing), rezistenta la încărcare (load testing) și performanta (performance testing), etc. Acestea vor fi detaliate in capitolele urmatoare.[4]
1.4 Principiile testării
Principiile testării software sunt:
Toate testele trebuie sa fie legate de cerințele (explicite și implicite) impuse produsului. Acest principiu ne arată ca ȋn primul rând este necesar să fie puse ȋn evidență și eliminate acele defecte care ȋmpiedică produsul să satisfacă cerințele utilizatorilor. Dacă ȋn urma testelor efectuate sunt puse ȋn evidență și alte defecte/anomalii, se va analiza cu atenție ȋn ce măsură ele pot fi acceptate, cel puțin momentan.
Testele trebuie sa fie planificate cu mult ȋnainte de efectuarea lor. Planificarea testelor pentru o componentă a produsului poate să ȋnceapă imediat după ȋncheierea formulării specificațiilor pentru acea componentă. Această abordare corespunde modelelor V și W de dezvoltare a unui proiect și este necesară deoarece pregătirea testelor este ȋn general laborioasă, implicând scrierea unui cod special pentru testare și eventual chiar crearea unor platforme hardware adecvate.
Principiul lui Pareto. Formularea adaptată a acestui principiu ȋn programare este: “80% dintre defectele descoperite sunt concentrate ȋn 20% din componentele testate”. Un corolar al acestui principiu ar putea fi formulat ȋn felul următor: “probabilitatea descoperirii de noi defecte este mai mare ȋn modulele ȋn care au fost deja descoperite defecte”. [3]
Testarea ȋncepe de la “simplu” și evoluează către “complex”. Acest principiu ne arată că primele teste planificate și executate se referă la componente de complexitate cât mai mică (uneori doar câteva linii de cod care realizează o funcție bine precizată) pentru a permite localizarea cât mai rapidă a defectelor. Numai după ce defectele de la acest nivel au fost eliminate, se trece la testarea unor grupe de module și ȋn final la testarea ȋntregului produs.
Atunci când definim un test, este esențial să precizăm la ce rezultate trebuie să ne așteptăm.
Testarea exhaustivă nu este posibilă adică niciodată nu putem garanta că dintr-un produs au fost eliminate toate defectele. Acest lucru se datorează faptului că activitatea de testare este o activitate economică cu resurse limitate și care trebuie să se desfășoare ȋntr-un interval de timp acceptabil pentru toți partenerii la proiect iar numărul total de teste necesare pentru a acoperi toate situațiile posibile poate fi foarte mare chiar ȋn cazul unor componente relativ simple.
Se vor interpreta cu grijă rezultatele tuturor testelor.
Trebuie să testăm cu aceași atenție atât situațiile normale de funcționare cât și pe cele anormale sau chiar inacceptabile.
Nu este suficient să punem în evidență că un produs nu realizează ceea ce se presupune că trebuie să realizeze. Este necesar să verificăm și dacă nu cumva realizează ceea ce nu trebuie să realizeze.
Nu vom distruge datele și/sau echipamentele de testare utilizate, până când nu renunțăm la produsul testat.
Nu evaluăm efortul de testare bazându-ne pe ipoteza că nu vor apare noi eșecuri.
Pentru a fi cu adevarat eficiente, testele trebuie realizate de o altă echipă decât cea care a dezvoltat produsele testate deoarece ȋn timp ce dezvoltatorul este orientat pe reducerea timpului de dare ȋn folosință, testorul este orientat pe asigurarea calității produsului.
Testarea este o activitate creativă de un înalt nivel intelectual.[3]
1.5. Etapele procesului de testare
Fazele procesului de testare, ilustrate și ȋn figura 1.2. sunt:
Planificarea și controlul testelor
Analiza și design-ul testelor
Implementarea și execuția testelor
Evaluarea criteriilor de terminare și raportare
Activități de finalizare a testelor
Fig. 1.2. – Fazele procesului de testare[5]
1.5.1. Planificarea testării
Planificarea testelor se realizează în strânsă legătură cu planificarea derulării proiectului. În faza de planificare a proiectului pentru testare se alocă resurse, specificându-se bugetul și perioada de timp în care se va derula testarea. Pe baza acestora se realizează planificarea detaliată a procesului de testare.
Planificarea testării are scopul de a determina ce să testeze și cât să testeze, astfel încât procesul de testare să se încadreze în limitele resurselor alocate. În urma planificării testării rezultă planul de test, un document pe baza căruia se desfășoară celelalte faze ale testării. În această fază se identifică și obiectivele testării.
Atributiile importante ale acestei faze sunt:
Definirea strategiei de testare
Determinarea scopului si riscurilor
Determinarea abordarii testarii (tehnici, acoperirea testelor, echipe implicate)
Programarea implementarii, executiei si evaluarea testelor
Definirea sistemul de testare (hardware si software)
Estimarea efortului de testare
Planul de test este un document important, fiind utilizat ca bază pentru desfășurarea întregului proces de testare. În planul de test sunt descrise:
aria de cuprindere;
responsabilitățile fiecărui membru al echipei de testare;
resursele umane necesare;
desfășurarea în timp a testelor;
descrierea și configurarea mediului specific aplicației;
lista echipamentelor care trebuie achiziționate;
crearea și managementul datelor de test;
criteriile de acceptare a testelor.
Deoarece este foarte dificil să se stabilească momentul în care se va încheia testarea, în planul de test se specifică o serie de criterii care constituie o bază pentru determinarea finalizării testării.[4]
1.5.2. Controlul testării
Este o activitate continuă de comparare a progresului actual față de plan și raportarea stării actuale incluzând și deviațiile de la plan. Implică luarea acțiunilor necesare pentru a se îndeplini misiunea și obiectivul proiectului.
1.5.3. Analiza și design-ul testării
În etapa de analiză se identifică următorii pași:
analizarea aplicatiei și identificarea scopurilor, obiectivelor și a strategilor testării de către echipa de testare;
metodele de verificare sunt asociate cerințelor sistemului sau cazurilor de utilizare și sunt documentate în cadrul unei matrice de urmărire a cerințelor;
analiza cerințelor testelor;
construirea matricei cerințelor testelor, în care declarațiile cerințelor testelor sunt asociate cerințelor sistemului sau a cazurilor de utilizare;
asocierea tehnicilor de testare cu declarațiile cerințelor testelor.
În faza de analiză a procesului de testare, un aspect important îl ocupă analiza cerințelor pentru testare. Cerințele testării trebuie să fie identificate și documentate astfel încât toate persoanele implicate în procesul de testare să fie conștiente de scopul acestuia. Analiza se desfășoară din mai multe puncte de vedere, depinzând de faza de testare. Astfel se identifică o abordare structurală și o abordare bazată pe comportament.[4]
Faza de proiectare a testelor urmează după încheierea analizei. În faza de proiectare, apar următorii pași:
definirea modelului programului de test astfel încât acesta să reflecte tehnicile de testare utilizate;
definirea arhitecturii de test;
definirea procedurilor de test;
luarea deciziei de automatizare a anumitor teste și de testare manuală a altor componente;
asocierea datelor de test astfel încât fiecare cerință pentru datele de test să se reflecte pentru fiecare procedură de test.
Programul de test se elaborează fie la nivelul proiectării, fie la nivelul tehnicilor de testare. În primul caz, procedurile de test sunt asociate componentelor hardware și software ale aplicației, iar în al doilea caz procedurile de testare sunt văzute la nivelul tehnicilor de testare.
Proiectarea procedurilor de test începe după determinarea cerințelor testării. Proiectarea procedurilor de test constă în:
analiza arhitecturii de test pentru determinarea tehnicilor de testare relevante;
definirea procedurilor de test atât la nivelul sistemului cât și la nivelul de implementare;
elaborarea sau preluarea de standarde de utilizare a procedurilor de test;
identificarea procedurilor de test care vor fi efectuate manual și a celor care vor fi efectuate automat;
identificarea procedurilor de test complexe, pentru a fi proiectate în continuare în faza de proiectare detaliată;
proiectarea detaliată.
1.5.4. Implementarea și execuția testelor
În etapa de implementare a testelor sunt construite cazurile de test și procedurile de test, pe baza rezultatelor fazei de proiectare. Cazurile de test descriu atât parametrii de intrare cât și rezultatele așteptate după execuție utilizând acei parametri. Realizarea de cazuri de test cât mai complete duce la descoperirea unui număr mai mare de erori. Procedurile de test identifică toți pașii necesari pentru executarea cazurilor de test specifice.
Primul pas în faza de implementare este inițializarea mediului de implementare prin punerea la punct a arhitecturii dezvoltării testelor.
Un alt aspect important este identificarea standardelor pe care se bazează elaborarea secvențelor de test. Dacă au fost definite astfel de standarde de implementare, atunci implementarea se realizează pe baza acestora. Dacă nu există standarde, în cadrul acestei faze, la început, se stabilesc convenții de scriere a programelor de test (alinieri, comentarii, prefixe pentru date).
Implementarea secvențelor de test se realizează în limbaje specifice mediilor de testare sau se utilizează limbaje de programare evoluate.
Prin reutilizare se folosesc proceduri de test din proiectele anterioare sau din cadrul aceluiași proiect pentru module care au părți comune.
Faza de rulare a testelor are ca intrări planul de test și orarul execuției procedurilor de test, mediul de test fiind pregătit corespunzător. Ieșirile fazei de execuție a testelor sunt rezultatele testelor, lecțiile învățate și orarul modificat al testelor. Execuția modulelor se realizează în conformitate cu planul de test. Procedurile de test descriu intrările și ieșirile așteptate după execuție.
În această etapă din cadrul procesului de testare sunt rulate secvențele de test. Execuția secvențelor de test se realizează pe cât posibil în mediul specific aplicației iar dacă nu este posibil, acest mediu este simulat. În figura 1.3. este prezentat fluxul procesului de execuție și evaluare a testelor pentru testarea la nivel de modul, bazată pe specificații.[4]
Fig. 1.3. – Fazele de execuție și evaluare pentru testarea de module [4]
1.5.5. Evaluarea criteriilor de terminare și raportare
Rezultatele execuției secvențelor de test sunt evaluate pentru a determina dacă produsul a trecut testul cu succes. Evaluarea rezultatelor testelor se face de către un oracol. Oracolul este o persoană sau un instrument automat, care pe baza specificațiilor determină dacă rezultatele execuției testelor sunt corecte sau nu. Rezultatele execuției testelor (jurnalele de teste) se vor memora într-o bază de date care conține și alte informații referitoare la aplicația software realizată.[4]
Un jurnalul de test ar trebui sa contina:
Versiunile software-ului și testelor
Specificațiile folosite ca bază a testelor
Cronometrarea testelor
Rezultatele testelor – rezultatele propriu-zise rezultatele așteptate
Detaliile defectelor
Din revizuirea jurnalului de test trebuie să rezulte dacă sunt necesare și alte teste sau dacă criteriile de terminare ale testelor trebuiesc modificate. [5]
1.5.6. Activitați de finalizare a testelor
Aceasta etapa consta in mai multi pasi:
Verificarea faptului ca produsul rezultat este conform planurilor
Finalizarea si arhivarea testelor si mediilor de testare
Daca testarea este finalizata atunci proiectul se poate inchide
Documentele trebuie sa fie actualizate si inregistrate intr-un sistem de control al versiunii
2. Testarea – etapă a ciclului de dezvoltare software
Proiectarea aplicațiilor software de dimensiuni mari, dezvoltată în cadrul unei echipe, nu se face trecând direct la implementarea programului, ci urmează etape bine stabilite . Se pot diferenția mai multe modele de dezvoltare fiecare având atât avantaje cât și dezavantaje.
2.1. Modelul cascadă
Acest model presupune ca procesul de dezvoltare al aplicațiilor software sa fie alcătuit din următoarele etape: specificarea cerințelor, analiză, proiectare, implementare, testare și întreținere. În figura 2.1. este prezentat grafic modelul clasic de dezvoltare software .
Avantajele acestui model sunt:
este simplu și ușor de utilizat
fazele și procesele sunt terminate pe rând
bun pentru proiectele mici unde cerințele sunt bine înțelese de la început
Dezavantaje lui sunt:
modificarea cerințelor este foarte greu de gestionat
nu se pot produce prototipuri decât foarte tarziu
Fig. 2.1. – Modelul clasic de dezvoltare software cascadă [7]
În cadrul ciclului de dezvoltare software există intercalate și etape de testare cum ar fi: testarea de module, testarea de integrare, testarea de sistem, testarea de acceptare. Corespondența dintre fazele ciclului de dezvoltare software și etapele testării este prezentată în figura 2.2.
Fig. 2.2. – Nivelele testării în cadrul ciclului de dezvoltare software [1]
2.2. Modelul V
Modelul V arată diferitele stagii în dezvoltare și testare, precum și relațiile dintre acestea.Se uitilizeaza patru nivele de testare pentru cele patru nivele de dezvoltare. În practică, se pot întâlni mai puține nivele de testare și dezvoltare, depinzând de proiect. Acest model este ilustrat în figură 2.3.
Acest model este mai bun decât modelul în cascadă din punct de vede al testării și asigurării calității deoarece planul de testare este făcut încă de la început. Acesta are următoarele dezavantaje:
Modificarea cerințelor este foarte greu de gestionat
Nu se pot produce prototipuri timpurii
Fig. 2.3. – Modelul de dezvoltare V [9]
2.3. Modelul de dezvoltare iterativ-incremental
Acest model se bazeaz pe o idee foarte simpl: dac un sistem este prea complex pentru a fi neles, conceput sau realizat intr-o singura faz este mai bine sa fie realizat n mai multe faze, prin evoluie.
Acesta presupune împărțirea proiectului într-o serie de subproiecte mici, iar fiecare subproiect urmărește un model V detaliat anterior. Figura 2.4. ilustrează modul în care se succed etapele de dezvoltare în cadrul acestui model.
Acesta are urmatoarele avantaje:
analiza timpurie a riscurilor
revizitarea planurilor
calitate pe nivele și o mai mare motivatie
posibilitatea de furnizare timpurie a prototipurilor
testarea se realizeaza în fiecare iterație
feedback-ul utilizatorilor este distribuit pe întreg parcursul dezvoltării
în cazul apariției unor schimbări în cerințe acestea pot fi încoporate în urmatorul prototip
Fig. 2.4. – Modelul de dezvoltare iterativ-incremental [8]
Indiferent de modelul care se folosește, este necesară o testare bună, întrucât pentru fiecare activitate de dezvoltare corespunde o activitate de testare. Fiecare nivel de testare are obiective specifice pentru acel nivel al aplicației. Analiza și designul testării pentru un anumit nivel de testare ar trebui să înceapă corespunzător activității de dezvoltare. [5]
3. Tipuri de teste metode de testare
3.1. Clasificarea tipurilor de testare
După modul în care se realizează testarea se pot distinge 2 categorii de testare:
testare automată – presupune creare de teste și scripturi ce vor fi rulate automat pentru a verifica modul în care funcționează aplicația
testare manuală – presupune verificarea modului în care funcționează aplicația de către un tester
O altă clasificare se poate face după ceea ce implică procesul de testare, astfel aceasta poate fi de 2 feluri:
testarea statică – are în vedere analiza codului sursă a programului fără rularea acestuia, independent de datele de intrare.
testarea dinamică – presupune examinarea aplicațiilor software în scopul generării datelor de test și execuția acestora cu seturile de date de test obținute.
Din punctul de vedere al strategiei de testare aceasta poate fi:
testarea structurală (white-box) – este o strategie de testare care necesită accesul la codul sursă și la structura programului și pune accentul pe acoperirea prin teste a căilor, ramificațiilor și fluxurilor programului. Principalele metode de testare structurală au în vedere gradul în care cazurile de test acoperă sau execută codul sursă al programului .
testarea funcțională (black-box) – nu necesită cunoașterea structurii interne a programului, cunoștințe despre program, în schimb necesită cunoașterea a cum ar trebui să fie comportamentul extern al programului, bazându-se pe specificațiile acestuia.
Testarea gray-box implică o cunoștință a structurilor de date interne și a algoritmilor în scopul elaborării testelor, ce vor fi executate la nivel de teste black-box. Cel care testează nu trebuie neapărat să aibă acces la codul sursă pentru a realiza un astfel de test.[12]
Un alt criteriu de clasificare poate fi modul în care procesul de testare influențează procesul de dezvoltare al unei aplicații software, astfel se disting mai multe tehnici:
Behavior-driven development (BDD)- după implementarea funcționalităților aplicației se scriu teste care să verifice corectitudinea codului scris și comportamentul acestuia în situații extreme cu parametrii limită
Test-driven development (TDD) – presupune crearea testelor înaintea implementării. Inițial se crează un test simplu care eșuează . Apoi se trece la implementarea funcționalității necesare astfel încât să treacă testul. Se refactorizeaza codul si treptat testul se extinde astfel încât să acopere tot mai multe funcționalități urmând că apoi acestea să se implementeze treptat astfel încât testul să treacă.[ 11]
Folosind o astfel de abordare codul final va arată foarte diferit în comparație cu cazul în care s-ar fi pornit de la implementarea funcționalitățiilor dar această metodă dă posibilitatea definirii foarte clare a comportamentului codului scris și al așteptărilor de la acesta.
S-a observat că în practică tehnica TDD nu este o metodă foarte eficientă și are multe lacune, nereușind să acopere toate cerințele procesului de dezvoltare al aplicațiilor actuale.[10]
Principiul TDD este ilustrat în figura 3.1.
Fig. 3.1. – Principiul de funcționare al TDD []
3.2. Tipuri de teste
În funcție de ceea ce se testează, se disting mai multe categorii de teste:
teste de bază – se asigura ca sistemul poate fi instalat, configurat si adus intr-o stare functionala.
teste funcționale – verifică că cerințele precizate în documentul de specificații ale sistemului sunt îndeplinite
teste nefuncționale – sunt teste care verifică atributele componentelor sau a sistemului și care nu se leagă de funcționalitate
3.2.1. Teste funcționale
Testele funcționale se pot clasifica în:
Teste de siguranța (security tests) – investighează funcții (ex. Firewall) care au în vedere detecția de amenințări cum ar fi viruși și factori dăunători și modul în care sistemul este protejat împotriva accesului neautorizat
Teste de interoperabilitate (interoperability tests) – combină diferite elemente ale sistemului într-un singur mediu de testare, pentru a asigura funcționarea lor corectă împreună. Sunt create pentru a asigura că sistemul poate fi interconectat cu alte sisteme și va continuă să funcționeze corect. Acestea sunt de două tipuri: de compatibility (verifică funcționarea versiunii actuale a sistemului în cadrul unei platforme mai vechi) și de backward compatibility (verifică menținerea vechilor funcționalități)
Teste de fum (smoke tests) – scopul acestora este să pună în evidență cu un minim de efort dacă un produs este funcțional înainte de a trece la realizarea unor teste detaliate. Testele din aceasta categorie sunt teste usoare, cu timp de execuție mic și sunt focalizate pe modificările introduse. Trecerea acestui test nu garantează calitatea impusă produsului, deci nu elimină celelalte categorii de teste.
Teste de integrare (integration test) – implică testarea combinată a diferitelor părți dintr-o aplicație pentru a vedea dacă funcționează corect. Aceste "părți" pot fi module de cod, aplicații individuale, aplicații client-server într-o rețea etc.
Teste pentru unități (unit tests) – verifică funcțiile sau module de cod . De obicei sunt făcute de programatori deoarece presupun cunoștințe avansate a design-ului intern al aplicației și codului. Nu întotdeauna sunt ușor de executat dacă aplicația nu are o arhitectură bine pusă la punct. Executarea lor poate presupune dezvoltarea de drivere sau stub-uri.
Teste de sistem (system tests) – ajută la realizarea unei testări de tip black-box bazată pe specificații care acoperă toate părțile sistemului.
Teste de acceptare (user acceptance tests) – sunt realizate la sfârșitul implementării unor funcționalități sau al întregii aplicații care determină dacă software-ul este satisfăcător pentru un end-user sau client. Testarea de acceptare poate fi de 2 feluri:
testarea alfa – se efectuează folosindu-se specificația cerințelor utilizator
testarea beta – programul este distribuit unor utilizatori selecționați, realizându-se astfel testarea lui în condiții reale de utilizare.
Teste de instalare/dezinstalare (install/uninstall tests) – testarea partiala sau integrala a procesului de instalare sau upgrade.
Teste de la un capat la altul (end-to-end tests) – similare cu testele de sistem. Aceste teste implica o testare de nivel 'macro'. Presupune testarea aplicatiei si a tuturor functionalitatilor acesteia in mediul in care va fi folosita.
Teste negative (negative tests) – se solicită aplicația, producând deliberat cazuri complicate, neobișnuite sau particulare pentru a forța apariția erorilor
3.2.2.Teste nefunctionale
Testele nefunctionale se pot clasifica in:
Teste de utilizabilitate (utilizability tests) – determina masura in care produsul software este inteles, usor de invatat, usor de operat si atractiv ("user-friendly") catre utilizatorii supusi unor conditii specifice.
Teste de performanta (performance tests) – masoara performantele reale ale sistemului, comparate cu cele teoretice. Metrica performantelor ce trebuie masurate variaza de la aplicatie la aplicatie. Exemplu: timpul de raspuns trebuie sa fie de mai putin de 1 secunda in 90% din cazuri la o aplicatie de genul Calculator matematic simplu. Performanta poate fi masurata, urmarind: – Timpul de raspuns – Iesirile sistemului – Utilizarea resurselor Daca masuratorile de performanta sunt nemultumitoare, atunci se iau masuri pentru imbunatatire (rescrierea codului, alocarea mai multor resurse, redesign de sistem …)
Teste de compatibilitate (compatibility tests) – testarea modului in care functioneaza software-ul pe anumite configuratii hardware, sisteme de operare sau retele
Teste de scalabilitate (scalability tests) – verifica sistemul pentru a isi atinge limitele sale tehnologice. Un sistem poate functiona intr-un scenariu cu utilizare limitata, dar nu poate fi extins uneori. Timpul de rulare al unui sistem poate creste exponential, in functie de cerinte si poate ceda dupa o anumita limita. O aplicatie este scalabila daca o crestere a incarcarii sistemului necesita doar resurse aditionale, fara modificari extensive ale aplicatiei. Limitele tehnologice sunt de obicei: – Limitari de stocare a datelor – Limitari de bandwidth – Limitari de viteza – CPU
Teste de stres (stress tests) – presupun evaluarea si gasirea comportamentului unei componente software, la limita sau in afara limitelor sale specificate tehnic. Sistemul este in mod intentionat stresat, prin impingerea lui dincolo de limitele specificate. Testele includ asigurarea de resurse putine si testarea pentru incompatibilitati. Testele de stress se asigura ca sistemul se comporta acceptabil in cele mai rele conditii. Daca limitele sunt depasite si sistemul cedeaza, ar trebui sa intre un mecanism de revenire. In testele de stress, trebuie urmarita “stricarea” aplicatiei ☺ si expunerea defectelor ce pot aparea in conditii de stress. – Coruperea datelor – Buffer overflow – Alocarea proasta a resurselor – Deadlocks etc
Teste de incarcare si stabilitate (load testing) – asigurarea stabilitatii sistemului pe o perioada lunga de timp cu incarcare completa (load). Un sistem poate functiona foarte bine cand este testat de cativa ingineri, care il folosesc in mod corect. Totusi, cand intervin un numar mai mare de utilizatori, care nu cunosc sistemul, si aplicatii care ruleaza luni fara repornire, se pot intalni diverse probleme: – Sistemul incetineste – Probleme de functionare – Sistemul se opreste treptat – Sistemul cedeaza complet. Acest tip de teste ne ajuta sa intelegem cum se va comporta sistemul in viata reala. Trebuie testate scenarii cat mai realiste.
Teste de fiabilitate (reliability tests) – presupun masurarea capacitatii sistemului de a ramane operational pentru perioade lungi de timp. Fiabilitatea sistemului se exprima de obicei in termeni de timp mediu pana la cedare – mean time to failure (MTTF). Pe masura ce testam sistemul, observam erorile, incercam sa indepartam defectele si sa continuam testarea. Pe masura ce avanseaza testarea, se inregistreaza duratele de timp intre esecuri succesive.
Teste de regresie (regression tests) – nu sunt teste noi ci se selecteaza teste dintre cele existente si sunt executate pentru a asigura ca nu este nimic defect in noua versiune a produsului software. Principala idee a testarii pentru regresie este verificarea faptului ca nici un defect nu a fost introdus in portiunea nemodificata a sistemului, datorita schimbarilor aduse in alte parti ale sistemului. In timpul testarii sistemului, multe defecte sunt descoperite si codul este modificat pentru a repara aceste defecte. Testele de regresie se efectueaza cand produsul sau mediul sau au fost schimbate: Se pot executa la orice nivel de testare Pot fi automatizate (din motive de costuri si de program)
Teste de revenire (recovery tests, failover tests) – testeaza modul in care un sistem isi revine dupa defectarea intregului sistem
Teste de documentatie (documentation tests) – verificarea acuratetii tehnice si a lizibilitatii manualelor de utilizare, inclusiv tutoriale si on-line help.
[1] http://www.shiva.pub.ro/PDF/TEST/Teste_functionale_curs_6.pdf
[1] TSCR04 2009-2010.pps
[1] http://www.softwaretesting.ro/Romana/Files/TestMethods/Software%20Testing%20Methods.html
[1] http://idsi.md/files/file/prezentari_practica_studenti/Tehnici%20de%20testare.pdf
4. Testarea automata
4.1. Testare automată vs testare manuală
Cand vine vorba de testare, cea mai des intalnita problema intr-o companie este daca sa se automatizeze procesul de testare sau sa se testeze manual. Nu toate testele pot fi automatizate si de cele mai multe ori poate fi dificil de decis ce sa se automatizeze si ce sa se testeze manual. La alegerea tipului de testare potrivit trebuie sa se tina cont de particulariltatile aplicatiei, dimensiunile acesteia si tipul ei.
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 bugurilorv ș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.
[1] http://www.scribd.com/doc/72039973/Testarea-Automata#scribd
Atat testarea manuala cat si cea automata au avantaje si dezavantaje.
Avantajele testarii automate sunt:
Se găsesc rapid problemele
Se câștigă timp când e nevoie să repetăm testele
Procesul de scriere a codului e mult mai flexibil
Reduce volumul de testare manuală
Posibilitatea de a testa continu/ciclic
Secventa stricta de pasi executati
Automatizarea secventelor lungi de teste
Automatizarea proceselor care necesita operatiuni complexe
Acoperirea tuturor etapelor de testare de la concepție până la lansare
Posibilitatea simulării testării cu mai mulți utilizatori
Dezvoltarea software devine previzibilă și repetabilă
Daca trebuiesc repetate aceleasi teste de multe ori automatizarea prezinta un mare avantaj
Ajuta la executarea de teste de compatibilitate a programelor dvs pe mai multe configuratii
Permite executarea scenariilor de testare ajutand la testele de regresie
Permite rularea mai multor teste de regresie pe un cod care se schimba des
Pot fi rulate simultan pe mai multe masini astfel scazand timpul de testare
Costurile pe termen lung sunt reduse
Permite vizualizarea proportiei in care este acoperit de teste codul testat (code coverage) pentru a sti cat de sigur impotriva erorilor este acel cod
a) avantaje privind eficiența și costurile
prevenirea erorilor prin abordarea structurată a procesului de dezvoltare a proiectului
detecția erorilor care au ajuns până în faza de producție (prin teste de regresie automată)
reutilizarea informației acumulate (condiții de test, scripturi)
reducerea creării de noi scripturi (refolosindu-le și adaptându-le pe cele vechi)
execuția automată a testelor de performanță în fazele de început ale proiectului poate evita eforturile de redesign în fazele ulterioare
odată ce scripturile de testare automată sunt implementate, o parte din personal poate fi redirecționat către alte necesități
b) avantaje privind economia de timp
analiză rapidă și exactă în cazul schimbării parametrilor sistemului
durată scurtă a ciclurilor de testare
estimări mai exacte pentru procesul de planificare a testului
posibilitatea efectuării mai multor teste (scripturile de testare pot fi rulate și după orele de
program economisind astfel timp)
generarea rapidă a condițiilor de testare
c) avantaje privind calitatea
o mai bună înțelegere a scopului testării
o acoperire mai mare a elementelor de testat
rezultate mai consistente datorită repetabilității testelor
compararea automată a rezultatelor
Avantajele testarii manuale sunt:
Rezolvă problemele de interfață: scrierea corectă a textelor, mesajelor, aranjarea corectă în pagină, în ordinea care trebuie, sunt vizibile, etc.
Realizarea Scenariilor de test poate fi o treabă de durată și anevoioasă și implică o cunoaștere temeinică a întregului sistem
Daca Test Cases-urile trebuiesc rulate de un numar mic de ori e mult mai probabil sa se prefere testarea manuala
Permite tester-ului sa faca mai multe teste ad-hoc
Costurile pe termen scurt sunt reduse
Cu cat un tester petrece mai mult timp verificand un modul cu atat cresc sansele de a gasi mai multe defecte si posibile greseli de utilizare
Dezavantajele testarii automate sunt:
E mult mai scump sa automatizezi, investitiile initiale sunt mai mari decat in cazul testarii manuale
Nu se poate automatiza totul, anumite teste trebuiesc facute manual
Crearea scripturilor necesita un efort substantial (nu intotdeauna justificat)
Scripturile testelor trebuie intretinute
Testele executa secvente de actiuni programate, nu poseda nici un fel de inteligenta spre deosebire de testarea manuala unde tester-ul poate lua anumite decizii
Dezavantajele testarii manuale sunt:
Testele manuale pot fi mari consumatoare de timp
Pentru fiecare release trebuiesc rulate acelaesi seturi de teste ceea ce poate deveni monoton
Fiind implicat un operator uman, acestea sunt predispuse la inconsecvente de la o testare la alta
[1] Laborator 3 – IP.ppt
[1]http://www.softwaretesting.ro/Romana/Files/ManualVsAutomation/Software%20Testing%20Manual%20vs%20Automated.html
[1] http://en.wikipedia.org/wiki/Unit_testing
O alternativă interesantă este așa-numita "testare parțială". Această soluție este 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.
4.2 Componentele testarii automate
Testarea software este o activitate esentiala, dar si scumpa si laborioasa. Automatizarea oricarei faze a procesului poate reduce timpul de testare si poate scadea costurile totale ale activitatii de testare. Exista mai multi factori ce trebuie luati în considerare atunci când se planifica automatizarea de testare software. Automatizare schimba complexitatea de testare si organizarea testelor de la proiectare pâna la punerea în aplicare si executarea acestora, avand un impact vast asupra organizatiei de la sarcinile îndeplinite, abordari de testare, si chiar caracteristici de produs. Sunt diverse opinii referitoare la avantajele si capacitatile testarii automatizare. Sunt studiate costurile si beneficiile înainte de a automatizare întreprinde o automatizare in scopul obtinerii unui randament crescut. Testarea software este, foarte importanta, deoarece:
30% din timp este pierdut cu corectarea defectelor
26% dintre proiecte sunt livrate cu intarziere
10% dintre companii platesc penalitati pentru intarzieri in livrare
Testare Software automata prezinta urmatoarele avantaje:
economiseste timp si bani
îmbunatateste precizia
creste aria de testare
face ceea ce testele manuale nu fac
ajuta dezvoltatorii si tester-ii
imbunatateste moralul echipei
[1] http://www.cs.ubbcluj.ro/~mfrentiu/Lectures/VerVal/lectii/C9%20~%20VvSs.pdf
Cele 7 moduri in care va ajuta testarea automata
Testarea automata va ajuta sa aflati daca aplicatiile software sau modulele dezvoltate suntconforme cu cerintele initiale si daca indeplinesc functiile pentru care au fost create.
Testarea automata va ajuta sa aveti un program software de calitate, prin identificarea defectiunilor din sistemul IT cat mai devreme.
Testarea automata va ofera informatii complete despre timpii de incarcare si raspuns ai programului, ceea ce va ajuta sa aveti o aplicatie rapida.
Testarea automata va garanteaza ca si in momentul in care aveti un numar foarte ridicat de utilizatori simultani ai aplicatiei software aceasta va oferi performanta asteptata si stabila.
Testarea automata va arata cum se comporta aplicatia atunci cand pe termen lung un numar ridicat de utilizatori ii folosesc functiile.
Testarea automata va ofera raspunsul la intrebarea cat de sigura este aplicatia.
Testarea automata va ajuta sa testati si livrati la timp aplicatia catre beneficiar fara a face compromisuri.
[1] http://www.pluriva.com/portfolio-view/de-ce-testare-automata/
Limitele testării automate
Sunt multe lucruri pe care uneltele de testare automată nu le pot face și este important să se cunoască aceste limitări pentru a alege pe cea mai potrivită. Un sistem de testare automată nu poate spune când ceva "arată bine" pe ecran sau când o poză sau fereastră nu este bine încadrată. De asemenea un test automat nu poate decide dacă logica programului are lipsuri funcționale decât în măsura în care au fost definite complet cerințele aplicației respective. Unele teste, mai ales pentru aplicații mici și pentru aplicații care se concentrează mai ales pe grafică și nu pe business logic, sunt mult mai ușor realizabile de către operatorul uman decât de către un computer. De aceea trebuie alcătuit un plan bine definit al procedurii de testare, când, unde și în ce condiții este fiabilă introducerea automatizării.
[1] http://www.scribd.com/doc/72039973/Testarea-Automata#scribd
Testarea automata a codului este o unealta esentiala in procesul de dezvoltare al sofware-ului.
Aceasta consta in activitatea de concepie a cazurilor de test, de execuie a testelor i de evaluare a rezultatelor testelor, n diferite etape ale ciclului de via al programelor si presupune utilizarea a unui program pentru executarea procedurilor (test case) sau a întregilor scenarii de testare.
Metodele traditionale de verificare/validare presupun realizarea verificrii/validrii prin inspectri i teste. Aceste activiti ocup circa 30-50% din efortul total de dezvoltare, n funcie de natura aplicaiei
Validarea este procesul de evaluare a unui sistem sau a unor componente ale acestuia, pe durata sau la sfarșitul ciclului de dezvoltare, cu scopul de a determina ȋn ce măsură acestea satisfac cerințele specificate, iar verificarea este procesul de evaluare a unui sistem sau a unei componente cu scopul de a determina dacă rezultatul unei faze de dezvoltare satisface cerințele impuse la ȋnceputul fazei.
Testarea n vederea verificrii programului folosete date de test alese de participanii la procesul de dezvoltare a programului. Ea este efectuat la mai multe nivele: la nivel de unitate funcional, de modul, de subsistem, de sistem.
Testarea n vederea validrii programului, numit i testare de acceptare, are drept scop stabilirea faptului c programul satisface cerinele viitorilor utilizatori. Ea se efectueaz în mediul n care urmeaz s funcioneze programul, deci folosindu-se date reale. Prin testarea de acceptare pot fi descoperite i erori, deci se efectueaz i o verificare a programului.
[1] 6.1_Testarea.doc
Un caz de test (test case) este o entitate care conține minim următoarele informații:
un set de date de test (a set of test input) – date primite de codul testat de la o sursă externă (umană, software, hardware);
condiții de execuție (execution conditions) – condițiile impuse pentru executarea unui test (o stare particulară a bazei de date, setările sistemului de operare sau ale altor programe auxiliare, configurarea unui dispozitiv hardware etc);
ieșirile estimate (expected outputs) – rezultatele așteptate ca urmare a execuției codului cu datele de test și ȋn condițiile specificate.
De exemplu, valorile coeficienilor a,b,c ai unei ecuaii de gradul doi mpreun cu valorile x1, x2, n testul unui program de rezolvare a ecuaiilor de gradul doi. Cazurile de test se aleg astfel nct s fie puse n eviden, dac este posibil, situaiile de funcionare necorespunztoare.
Profesionalismul în testare constă în abilitatea de a selecta numărul minim de cazuri de testare eficientă ce va fi capabil să verifice numărul maxim de funcții ale sistemului.
[1]Laborator 3 – IP.ppt
[1] 6.1_Testarea.doc
Un test (unit test) este o instanta a unui use case compusa din date intrare, conditii de executie si rezultate asteptate. Acesta const n execuia programului pentru un set de date de intrare convenabil ales, pentru a verifica dac rezultatul obinut este corect. Acesta poate fi redefinit ca un grup de cazuri de test corelate sau grup de cazuri de test corelate și proceduri. Scopul oricărui test este descoperirea de noi eșecuri ale produsului testat.
Un test este considerat cu atât mai bun cu cât asigură o probabilitate mai mare de depistare a unui nou eșec. Acesta are succes (test pozitiv) dacă a depistat un eșec ce nu a fost pus ȋn evidență de testele anterioare. Acesta poate fi considerat un bloc de constructie al testelor automate.
[1] TSCR03 2009-2010.pps
Specificațiile cazului de test sunt niste documente pe baza carora se proiecteaza cazul de test. Aceste documente se numesc specificatiile cazului de test si documenteaza ce anume trebuie testat. Este la latitudinea fiecare organizatii sa decida conținutul si formatul documentelor pentru precum si sistemele pe care le vor pastra.
Fiecare organizație poate decide introducerea ȋn cazul de test a unor informații adiționale pentru a-i crește valoarea ca obiect reutilizabil sau pentru a oferi informații detaliate testorilor și dezvoltatorilor.
Pentru o buna organizare se folosesc sisteme care sa permita organizarea acestor documente. Acestea permit accesul tuturor celor implicati in procesul de testare si redau stadiul in care se afla procesul testarii in orice moment.
[1] TSCR03 2009-2010.pps
4.3. Testele "unitare" (unit tests)
Testarea unui modul (o funcie, o clas, etc.) este realizat de programatorul care implementeaz modulul. Toate celelalte teste sunt efectuate, n general, de persoane care nu au participat la dezvoltarea programului.
Scopul testarii unui modul este de a se stabili ca modulul este o implementare corecta a specificatiei sale. In cursul testarii unui modul, modulul este tratat ca o entitate independent, care nu necesit prezena altor componente ale programului. Testarea izolat a unui modul ridic dou probleme:
simularea modulelor apelate de cel testat;
simularea modulelor apelante.
Modulele prin care se simuleaz modulele apelate de modulul testat se numesc module "ciot" (n englez, "stub") . Un modul "ciot" are aceeai interfa cu modulul testat i realizeaz n mod simplificat funcia sa returnand doar ceea ce ii este necesar metodei testate.
Cazurile de apel ale modulului testat de ctre celelalte module ale programului sunt simulate n cadrul unui "modul driver". Modulul driver apeleaz modulul testat furnizndu-i ca date de intrare datele de test ale modulului. Datele de test pot fi generate de modulul driver, pot fi preluate dintr-un fiier sau furnizate de testor ntr-o manier interactiv.
Interactiunea dintre aceste elemente este ilustrata in figura 2.2.1.
Figura 2.2.1. Structura programului executabil pentru testarea izolata a unui modul
[1]6.1_Testarea.doc
4.4. Determinarea cazurilor de test
Testarea unui modul, a unui subsistem sau chiar a ntregului program presupune stabilirea unui set de cazuri de test.
Un caz de test cuprinde:
– un set de date de intrare;
– funcia / funciile exersate prin datele respective;
– rezultatele (datele de ieire) ateptate;
n principiu (teoretic) testarea ar trebui s fie exhaustiv, adic s asigure exersarea tuturor cilor posibile din program. Adesea o astfel de testare este imposibil, de aceea trebuie s se opteze pentru anumite cazuri de test. Prin acestea trebuie s se verifice rspunsul programului atât la intrri valide cât i la intrri nevalide.
Sunt dou metode de generare a cazurilor de test, care nu se exclud, de multe ori fiind folosite mpreun. Ambele metode pot sta la baza unor instrumente de generare automat a datelor (cazurilor) de test:
Cazurile de test se determin pe baza specificaiei componentei testate, fr cunoaterea realizrii ei; acest tip de testare se numete
testare “cutie neagra” (“black box”).
Cazurile de test se determin prin analiza codului componentei testate. Acest tip de testare se mai numete i testare “cutie transparent”, sau
testare structural.
3.1. Testarea “cutie neagr”.
Cazurile de test trebuie s asigure urmtoarele verificri:
– reacia componentei testate la intrri valide;
– reacia componentei la intrri nevalide;
– existena efectelor laterale la execuia componentei, adic a unor efecte care nu rezult din specificaie;
– performanele componentei (dac sunt specificate).
Deoarece n marea majoritate a cazurilor testarea nu poate fi efectuat pentru toate seturile de date de intrare (testare exhaustiv), n alegerea datelor de test plecnd de la specificaii se aplic unele metode fundamentate teoretic precum i o serie de euristici.
Alegerea cazurilor de test folosind clasele de echivalen
Cazurile de test pot fi alese partiionnd att datele de intrare ct i cele de ieire ntr-un numr finit de clase de echivalen. Se grupeaz ntr-o aceeai clas datele care, conform specificaiei, conduc la o aceeai comportare a programului.
O dat stabilite clasele de echivalen ale datelor de intrare, se alege cte un eantion (de date de test) din fiecare clas.
In alegerea datelor de test trebuie s se elimine redundanele rezultate din considerarea atât a claselor de echivalen de intrare cât i a celor de ieire.
Unele programe trateaz datele de intrare n mod secvenial. n aceste cazuri se pot detecta erori n program testndu-l cu diverse combinaii ale intrrilor n secven. Metoda de partiionare n clase de echivalen nu ajut n alegerea unor astfel de combinaii. Numarul de combinaii posibile este foarte mare chiar i pentru programe mici. De aceea nu pot fi efectuate teste pentru toate combinaiile. n aceste cazuri este esenial experiena celui care alctuiete setul de cazuri de test.
Testele “cutie neagră”, numite și teste funcționale sunt utile nu numai pentru testarea programului. Ele pot fi utilizate (ca teste statice) pentru verificarea unei specificații intermediare față de o specificație de nivel superior.
“Slăbiciunile” testelor funcționale:
Nu este suficient să se verifice că programul satisface corect toate funcțiile specificate; unele proprietăți interne, nespecificate, ca de exemplu timpul de răspuns, nu sunt verificate;
Programul este testat pentru “ceea ce trebuie să facă” conform specificațiilor și nu și pentru ceea ce face în plus, de exemplu pentru ca implementarea să fie mai eficientă sau pentru a facilita reutilizarea;
In absența unui standard în privința specificațiilor formale, tehnicile de testare functională sunt eterogene
[1] 6.1_Testarea.doc
4.5. Etapele testarii automate
Testarea automata presupune urmatoarele etape:
Crearea unui Software Test Plan (STP) – Detaliază: scopul testării, planificarea în timp, cerințele ce se testează
Redactarea unui Test Requirement Definition (TRD) – Specifică ce cazuri trebuie testate pentru fiecare cerință (TC – Test Case)
Redactarea unui Software Test Description (STD) – Specifică step-by-step ce se execută și ce rezultat se așteaptă pentru fiecare TC
Executarea testelor (Tests Execution sau Test Cycles)
Generarea unui raport Software Test Report (STR) – Sumarizează rezultatele ciclurilor de testare și concluziile despre calitatea sistemului testat, este deobicei generat de unealta cu care se ruleaza testele
Toate aceste etape sunt ilustrate in figura 2.2.1.
Fig 2.2.1. – Etapele testarii automate
[1] Laborator 3 – IP.ppt
Un sistem de testare automată trebuie să aibă la bază două caracteristici principale:
module reutilizabile
întreținerea și urmărirea activității dintr-un singur punct de control
De aceea una din calitățile care trebuie să le aibă un astfel de sistem este capabilitatea de a fi ușor
configurat și adaptat în același ritm cu software-ul ce se testează .
Sistemele de testare automată sunt o tehnologie în plină dezvoltare care au ca scop descoperirea și
raportarea eventualelor defecte, mărirea longevității produsului și reducerea procesului de întreținere.
Testarea automată înseamnă mai mult decât o simplă captură de ecran și răspunsul la câteva scripturi : ea trebuie să înceapă cu planificarea și design-ul procedurii de testare, să conțină o serie de teste repetabile, o interfață de management al scenariilor de test și un mecanism de raportare și gestionare a bug-urilor descoperite în urma testării. Un sistem de test evoluat sprijină utilizatorii printr-un sistem de documentare pe tot parcursul acestui proces.
Într-o abordare mai detaliată testarea automată înseamnă:
1. planificare
identificarea cerințelor și a funcționalităților
gruparea acestora în condiții de test
crearea cazurilor de test pentru aceste condiții
2. design
construcția scripturilor de test
generarea testelor de rulare
3. execuție
crearea scenariului de rulare a scripturilor
rularea uneltelor monitor pentru înregistrarea datelor
înregistrarea rezultatelor pentru fiecare rulare
raportarea și gestionarea bug-urilor
4. management
generarea rapoartelor și graficelor
controlul dintr-un singur punct de comandă
documentarea permanentă a stadiului curent al proiectului
[1] http://www.scribd.com/doc/72039973/Testarea-Automata#scribd
4.6. Tehnologii de testare automata
Familia xUnit – [1]http://en.wikipedia.org/wiki/XUnit
Teste pt UI – Selenium, JMeter – simuleaza interactiunea utilizatorului cu interfata grafica pentru a vedea daca aplicatia se comporta pe masura asteptarilor
Test runners…integrari…job-uri si rulari automate
În ultimul timp pentru testarea automatizată se folosesc tot mai des asa-numitele xUnit frameworks, din care fac parte JUnit si NUnit. Ele permit testarea codului de program pentru a verifica programul în circumstanțe diferite. De exemplu, aceleași proceduri de testare se folosesc pentru a testa comportamentul programului în diferite diferite sisteme de operare sisteme de operare.
1. xUnit
2. CPPUnit
3. JUnit
4. NUnit
5. HtmlUnit
6. HttpUnit
7. TOSCA Testsuite
Continous integration
5.Studiu de caz (aplicatia Students Catalog)
a. descrierea apl
b. configurari framworks de teste
c.descriere teste
d.impartirea task-urilor(gantt) + teoria cap 4
e.simulare calcul buget si resurse
-importanta departamentului de QA
-rolurile implicate in QA
-exemplificare management
-diagramele gantt
Aplicatia prezentata in aceasta lucrare este un catalog online al unei universitati. Cu ajutorul acestei aplicatii se pot gestiona foarte usor notele studentilor si se poate avea in orice clipa o evidenta clara a acestora.
Aplicatia este alcatuita din 2 module:
Catalog student – sectiune disponibila tuturor tipurilor de utilizatori
Administrare catalog – sectiune disponibila doar celor cu drepturi de administrator
In functie de drepturile fiecarui utilizator acesta va avea disponibile in ecranul de start modulele aplicatiei.
Sectiunea "Catalog student" Ofera utilizatorului posibilitatea sa vizualizeze note ale studentilor alegandui selectand:
Departamente ale facultatii
Specializari ale unui departament
Ani de studii ai specializarii
Studenti din anii de studii
Fig 5.1 –
Sectiunea "Administrare catalog" ofera posibilitatea inregistrarii unui student nou precum si posibilitatea adaugarii sau modificarii notelor tuturor studentilor. de adaugat si restul functionalitatilor
Fig 5.2 –
Fiind o aplicatie web, aceasta este constituita din componenta de server (server-side) si componenta de client (client-side)
5.1. Server-side
5.1.1. Java
Java este o tehnologie inovatoare lansată inițial de Sun Microsystems și achiziționată ulterior
de Oracle. Aceasta este formată dintr-un limbaj de programare de nivel înalt pe bază căruia sunt
construite o serie de platforme destinate implementării de aplicații pentru toate segmentele
industriei software.
Acesta este un limbaj orientat pe obiecte dar nu este pur obiectual din cauză că deține și
tipuri primitive de date. Caracteristicile principale ale acestui limbaj sunt:\
Simplitatea
Ușurința
Robustețea
Complet orientat pe obiecte eliminând astfel stilul de programare procedural
Neutralitatea arhitecturala, neținând cont de arhitectura fizică a mașinii pe care rulează
Portabilitatea este data de codul compilat si interpretat care este independent de platform pe care rulează
Performanța
Limbajul de programare Java a fost folosit la dezvoltarea unor tehnologii dedicate rezolvării
unor probleme din cele mai diverse domenii.Aceste tehnologii au fost grupate în așa numitele
platforme de lucru, ce reprezintă seturi de librării scrise în limbajul Java precum și diverse
programe utilitare folosite pentru dezvoltarea de aplicații sau componente destinate unei anumite
categorii de utilizatori. Exemple de platforme sunt: J2SE (Standard Edition), J2ME (Micro
Edition), J2EE (Enterprise Edition).
Toate aplicațiile Java sunt transformate în octeți (fișiere *.class) și rulate de către JVM (Java
Virtual Machine).Acest lucru îi dă portabilitate, codul compilat putând fi executat pe oricare
mașină virtuală.
La realizarea acestei aplicații am folosit platforma de lucru J2EE și versiunea de limbaj
Java7. Această platformă de lucru vine în completarea J2SE și este destinată creării de aplicații
de tip enterprise. Aceste aplicații au arhitecturi complexe și sunt împărțite pe mai multe nivele.
J2EE face legătura dintre aceste nivele, mapează relațional obiectele și pune la dispoziție web
service-uri și suport pentru rețele.
Figura 5.1.1. ilustrează arhitectura platformei J2EE și modul în care elementele constituente
interactionează între ele. Aici este ilustrată structura tipică a unei aplicații de tip enterprise.
Pentru aceasta aplicatie am utilizat Java pentru a implementa nivelul DAO al aplicatiei. Acest nivel contine logica de extragere a datelor din baza de date si de procesare a acestora precum si logica de inserare sau modificare a datelor din baza de date.
Fig 5.1.1. – Arhitectura platformei J2EE [licenta]
5.1.2. Java Servlet
Un servlet este o clasă scrisă în limbajul Java al cărei scop este generarea dinamică de date
într-un server HTTP. O astfel de clasă poate crea atât conținut HTML, cât și documente XML,
imagini, alte fișiere etc. În cea mai mare parte servlet-urile sunt folosite împreună cu protocolul
HTTP, deși există posibilitatea de a utiliza servlet-uri generice care nu sunt legate de un anumit
protocol. Așadar prin „servlet” se înțelege de obicei „servlet HTTP”.
Este o funcționalitate din platforma J2EE care extinde capacitățile unui server. Un servlet nu
poate fi executat direct de către server, ci de către un container web. Acesta răspunde la diferite
tipuri de request venite de la paginile publicate pe un server. Pentru a răspunde unei cereri de la
un client (de obicei un browser) către un anumit servlet, serverul trimite mai departe cererea
către container, care se ocupă de instanțierea obiectului respectiv și de apelarea metodelor
necesare. Exemplele de containere web care suportă servlet-urile includ Apache Tomcat (acesta
poate rula și ca server de sine stătător, dar performanțele sale nu se compară cu cele ale unui
serverweb dedicat precum Apache).
Servlet-urile sunt folosite de obicei pentru a procesa datele primite de la un form HTML, de a
furniza dinamic datele extrase dintr-o bază de date sau de a realiza diferite operații în afara
paginii web.Acestea pot fi apelate folosind URL-ul lor direct în browser sau în cadrul altor
pagini web.
Ciclul de viață al unui servlet este alcătuit din 3 metode principale care sunt implementate de
fiecare servlet și sunt apelate la momente de timp specifice de către server:
init()
service()
destroy()
Fig 5.1.2. – Interacțiunea clientului cu baza de date utilizând framework-ul Servlet [licenta]
Aceasta figura ilustrează modul în care un client (browser) poate ajunge în posesia informațiilor
stocate într-o bază de date. Containerul de Servlet trimite o cerere la servlet. Acesta execută
operația de extragere a datelor și le furnizează înapoi containerului sub formă de răspuns.
La aplicația prezentată în această lucrare am folosit tehnologia Servlet 2.5 pentru a transmite interfetei grafice datele care trebuie afisate precum si pentru primirea datelor ce trebuie salvate in baza de date.
5.1.3. MSSQL Server 2012
Microsoft SQL Server este un sistem de gestionare de baze de date relaționale (RDBMS –
Relational Database Management System) produs de compania americană Microsoft Corp.
Limbajele primare de interogare sunt MS-SQL și T-SQL. Este un sistem destinat bazelor de date
de dimensiuni foarte mari.
MS SQL Server suportă conexiuni de diverse tipuri. Pentru realizarea acestei aplicații am
folosito conexiune de tip JDBC (Java DatabaseConnectivity).
JDBC este o tehnologie dezvoltată de Oracle care definește modul în care un client are acces
la server-ul de baze de date. Acesta pune la dispoziție metode de interogare a bazei de date și de
modificare a datelor din aceasta. Este conceput pentru baze de date relaționale. Am folosit acest
tip de conexiune pentru a selecta informațiile necesare din baza de date folosind limbajul Java.
Pentru a realiza acest lucru am folosit un driver JDBC (MSSQLJDBC-1.2.jar).
5.2.Client-side
5.2.1. SAPUI 5 – SAP Fiori
SAPUI 5 este un framework de JavaScript ce constituie o platformă de dezvoltare a
aplicaților web de business moderne . Conține o bibliotecă JavaScript de controale suportate de
toate browser-ele, destinate aplicaților web de tip RIA. Această bibliotecă a fost dezvoltată de
SAP, companie germană multi-națională de dezvoltare de soluții software pentru business-uri sau
relații cu clienții.
SAP este cunoscută pentru soluțiile sale SAP ERP (Enterprise Resource Planning), pentru
programele de gestiune a produselor comerciale destinate lanțurilor de magazine SAP BW
(Business Warehouse), suita de unelte de creare a rapoartelor de business SAP BO (Business
Objects), sistemul de gestiune a bazelor de date relaționale in-memory SAP HANA și SAP
Sybase, o suita de soluții software destinată telefoanelor mobile.
Această companie este lider mondial pe segmentul de Business Intelligence. În timp, și-a
creat propriul limbaj de programare ABAP (Advanced Business Application Programming) și
standarde foarte stricte în ceea ce privește întregul proces de realizare al aplicațiilor create de ei.
Aceste standarde sunt respectate și de framework-ul SAPUI care aduce pe lângă
interactivitate foarte mare și un aspect de "business application” oricărei aplicații în care sunt
folosite.
Aceast framework este destinat în special părții de client a unei aplicații web. Este un
framework deosebit de flexibil, el putând fi folosit împreună cu o sumedenie de alte platforme și
tehnologii precum: Apache Tomcat, Cascading Style Sheets (CSS) 3 version, Google Web
Toolkit (GWT), HTML5 version, Java Platform as a Service (JPaaS), JavaScript (JS), JavaServer
Faces (JSF), JavaScript Object Notation (JSON), jQuery, Open AJAX (Asynchronous JavaScript
and XML), oData (Open Data Protocol), XML (Extensible Markup Language).
Controalele puse la dispoziție de acest framework sunt construite cu HTML5, CSS 3, jQuery
și au capabilități de Ajax. Acestea suportă mai multe teme customizabile și pot fi accesate prin
JavaScript. Fiind un framework orientat pe obiecte, controalele se pot declara și instanția ca și în
Java urmând ca apoi să li se seteze proprietățile. Totodată acestea pot fi inițializate direct la
instanțiere specificând proprietatiile sub formă de JSON.
Framework-ul este proiectat să implementeze design pattern-ul Model-View-Controller.
Programatorul își poate crea ca și model datele sub formă de XML, JSON sau oData.
În această aplicație am folosit versiunea 1.12 a acestui framework din care am utilizat o
mare varietate de astfel de controale dorind să scot în evidență capacitățile acestui framework și
modul în care aceste controale pot fi utilizate.Am folosit de asemenea și design pattern-ul
Model-View-Controller (MVC) furnizat de acesta dar combinat cu facilitățile framework-ului
Struts care implementează același design pattern.
SAP Fiori este un nou look and feel al framework-ului SAPUI5, o noua tema a acestuia care aplica principile design-ului modern. Acest UX (user experience) ofera personalizare, responsivitate foarte mare si usureaza interactiunea utilizatorului cu aplicatie simplificand interfata grafica.
5.3.Arhitectura aplicatiei
Aceasta este o aplicație web care are o structură multi-nivel(multi-layer). Aceasta este structurată pe 3 niveluri:
Nivelul de extragere a datelor din baza de date (DAO)
Nivelul de business (Servlet-ul)
Nivelul interfața grafică cu utilizatorul (GUI)
Nivelul de extragere a datelor se bazează pe design pattern-ul DAO (Data Access Object).
Acesta oferă o interfață abstractă către orice tip de bază de date fără a expune detaliile conexiunii
și crează o separare între nevoile aplicației și datele acesteia. DAO este asociat de obicei cu
aplicațiile Java EE care folosesc baze de date relaționale accesate cu ajutorul JDBC.
Nivelul de business preia datele extrase de la DAO și le procesează (converteste sub forma de json) trimițându-le maideparte către intrefata cu utilizatorul sub formă sintetizată.
Totul începe de la un utilizator care accesează aplicația cu ajutorul unui browser. Acest lucru
crează o cerere (request) care e trimisă la server (Tomcat) unde este procesată de către un servlet
care trimite cererea la celelate component pentru a fi executată.
Fig 5.3.1. – Nivelurile și modul în care acestea interacționează pentru funcționarea aplicației [licenta]
Servlet-ul comunică direct cu aplicatia prin AJAX call-uritrimitand sau primind date de la aceasta.
Partea de client este alcătuită din control-ere de SAPUI5. Acestea au 2 parti:
view (xml) care ilustreaza structura interfetei cu utilizatorul
control (js) care descrie comportamentul interfetei grafice
Partea de server a aplicației este structurată de asemenea pe mai multe niveluri. Nivelul DAO ,
prin intermediul conexiunii JDBC, realizează conexiunea cu bază de date și extrage din aceasta
datele necesare funcționării aplicației pe care le trimite mai departe servlet-ului.
Privită in ansamblu, aceasta aplicație respectă principiile design pattern-ului MVC (Model
View Control), astfel:
modelul este constituit din datele extrase din baza de date
controlul este asigurat de partea de server a aplicației
prezentarea este asigurată de interfața grafică cu utilizatorul
http://www.pawlan.com/monica/articles/j2eearch/
http://vega.unitbv.ro/~cataron/Courses/BD/BD_Cap_5.pdf
http://ro.wikipedia.org/wiki/SQL
http://ro.wikipedia.org/wiki/JavaScript http://strutscx.cappuccinonet.com/overview.php?target=overview
http://static.springsource.org/spring/docs/3.0.x/spring-frameworkreference/
html/overview.html
http://ro.wikipedia.org/wiki/Servlet
6.Tehnologii folosite pentru testarea automata a aplicatiei
-pentru fiecare tip de limbaj
-avantaje/dezavantaje
-motivarea alegerii tehnologiilor
-QUnit, JUnit, JMeter, Selenium, mockrunner, blanket.js, cobertura
Familia xUnit
[1]http://en.wikipedia.org/wiki/XUnit
6.1 JUnit
JUnit este un framework cu ajutorul caruia se poate testa codul scris in limbajul Java. Acesta face parte din familia xUnit, o suita de framework-uri pentru testarea codului scris in diferite limbaje de programare.
Este un framework open source care permite crearea si rularea de teste. Acesta este constituit dintr-un jar care este incarcat la compilarea codului testat. Este localizat in pachetul junit.framework pana la versiunea 3.8 sau in pachetul org.junit incepand de la versiunea 4.
Ca si celelalte framework-uri din familia xUnit, acesta pune la dispozitia utilizatorilor:
Assertions for testing expected results
Test fixtures for sharing common test data
Test runners for running tests
Acest framework este foarte popular deoarece este foarte usor de folosit, fiind integrat in Eclipse IDE, dar si pentru ca se poate integra foarte usor cu unelte precum Maven pentru rularea automata a testelor.
[1] http://junit.org/faq.html
[2] http://en.wikipedia.org/wiki/JUnit
6.2 QUnit
QUnit este un framework cu ajutorul caruia se poate testa codul scris in limbajul javaScript. Si acesta, asemenea framework-ului JUnit, face parte din familia xUnit. Desi a fost in special utilizat de catre proiectul jQuery pentru testarea jQuery, jQuery UI si jQuery Mobile, acesta poate fi utilizat pentru a testa orice cod javaScript atat pe partea de client cat si pe partea de server.
Acest framework a fost dezvoltat initial de John Resing ca si parte integranta a framework-ului jQuery. Acesta a preluat din conceptele unui alt framework numit CommonJS. Acesta ajuta la creearea unui ecosistem pentru codul de javaScript in afara browser-ului destinat aplicatiilor pe partea de server sau aplicatiilor desktop native.
In 2008 a fost separat de acest framework intr-un proiect separat si a primit numele de QUnit. Acest lucru a permis si altor programatori sa isi creeze propriile teste pentru aplicatiile lor. In 2009 acesta a fost rescris complet astfel incat sa fie un proiect complet separat si sa nu mai depinda deloc de framework-ul jQuery pentru interactiunea cu DOM-ul. [1]
Ceea ce il diferentiaza de alte framework-uri de testare a codului javaScript este usurinta cu care poate fi utilizat(easy-to-use) , multitudinea de functionalitati pe care le ofera(powerful) precum si faptul ca acopera cerintele speciale de testare a codului astfel incat sa fie compatibil cu orice browser. Aceste calitati l-au facut sa fie utilizat la scara larga intr-o multitudine de proiecte.
Acesta este un framework automatizat. Se pot face configurari astfel incat testele sa ruleze singure fara interventia operatorului uman pe platforme specifice
esueaza
[1] http://en.wikipedia.org/wiki/QUnit
[2] http://qunitjs.com/cookbook/
[3] http://qunitjs.com/intro/
6.3 Mockrunner
A mock object is a simulated object that mimics the behavior of a real object in controlled ways. Mock objects are often employed in unit testing to scrutinize the performance of actual objects. In this context, an object is the smallest testable part of an application. A mock object makes use of the same interface as the element of code it is intended to imitate.
A mock object can be useful in place of a real object that:
Runs slowly or inefficiently in practical situations
Occurs rarely and is difficult to produce artificially
Produces non-deterministic results
Does not yet exist in a practical sense
Is intended mainly or exclusively for conducting tests.
[1] http://searchsoftwarequality.techtarget.com/definition/mock-object
6.4 SinonJS
http://www.todaysoftmag.ro/article/377/din-uneltele-artizanului-software-unit-testing
ce e un mock
ce e un stub
ce e un unit test
6.5 Cobertura
6.6 Blanket.js
Acoperirea codului (code coverage) este măsură utilizată în testarea software. Descrie gradul de testare a codului sursă a unui program. A fost printre primele metode inventate pentru testarea software sistematică. În general, uneltele și librăriile de acoperirea codului arătă ce costuri de performanțe sau/și memorie sunt inacceptabile pentru operațiuni normale ale programului. De aceea, ele sunt utilizate doar în laborator. Așa cum era de așteptat, există clase de programe software care nu pot fi subiecte posibile pentru acest tip de test, totuși un grad de acoperire al mapării poate fi exprimat prin analiză de printr-un test direct.
7.Managementul procesului de testare
-planificarea task-urilor de testare (messaging systems, aplicatii precum JIRA, CARLA)
-documente ce insotesc procesul de testare (testing scenarios, story docs, regression tests, V&Is)
-planificarea etapelor de testare (succesiunea lor in raport cu procesul de implementare) in ciclul de viata al produsului software
-testarea diferita pentru diferite etape (release, patch, bug fix)
-best practice-uri
-avantaje/dezavantaje diferite abordari
-calcularea resurselor umane si materiale (bugetul)s necesare testarii proiectului dat
Ponderea cheltuielilor cu testarea reprezintă între 30% și 50% din totalul cheltuielilor pentru dezvoltarea unei aplicații software.
Aceste activiti ocup circa 30-50% din efortul total de dezvoltare, n funcie de natura aplicaiei.
Instrumente pentru managementulării
Instrumente de testare:
Testlink Testlink, V. 1.9.5; – instrument pentru managementul testelor;
Jenkins Jenkins – instrument pentru integrarea continuă a softului a softului;
[http://jenkins http://jenkins-ci.org/];
JUnit, V. 4.10.0; – paltform ă de testare pentru limbajul de testare pentru limbajul Java; [http://sourceforge.net/projects/junit http://sourceforge.net/projects/junit/];
Instrumente de management:
Maven, V. 3.0.5; – instrument pentru managementul proiectelor și resurselor soft [http://maven.apache.org http://maven.apache.org/];
SVN , V. 1.0.0; – instrument pentru managementul versiunilor surselor (resurselor)
[1] http://www.cs.ubbcluj.ro/~mfrentiu/Lectures/VerVal/lectii/C9%20~%20VvSs.pdf
Procesul de testare automată presupune un efort de management deosebit. Acest proces începe
încă din faza de analiză a aplicației și continuă în toate etapele de dezvoltare. În diagrama următoare se pot observa etapele procesului, ordinea și frecvența acestora, precum și locul central pe care îl ocupă managementul defectelor și serviciile. Un factor important este menținerea centrală a comunicării între etape pentru managementul bug-urilor.
[1] http://www.scribd.com/doc/72039973/Testarea-Automata#scribd
Fig – Managementul testarii automate
[1] http://www.scribd.com/doc/72039973/Testarea-Automata#scribd
Tehnicile de testare sunt mult mai costisitoare decât metodele statice (inspectrile i demonstrrile de corectitudine), de aceea n prezent se apreciaz c tehnicile statice pot fi folosite pentru a le completa pe cele dinamice, obinndu-se astfel o reducere a costului total al procesului de verificare i validare. Metodele traditionale de verificare/validare presupun realizarea verificrii/validrii prin inspectri i teste. Aceste activiti ocup circa 30-50% din efortul total de dezvoltare, n funcie de natura aplicaiei.
8.Concluzii
O temere întâlnită adesea este că testerii își vor pierde locul de muncă o dată cu introducerea testării automate. În realitate, testerii devin mult mai importanți pentru că acum doar ei pot descoperi problemele ascunse, greu sau imposibil de găsit prin teste automate. Ei ajută să crească probabilitatea că totul funcționează corect de la 80+% la aproape 100%
[1] http://www.todaysoftmag.ro/article/377/din-uneltele-artizanului-software-unit-testing
Concluzii
Testarea este pricipalul proces fără de care nu se poate de realizat un produs software de calitate.
Testarea ocupă cel mai mult timp din dezvoltarea produsului.
Procesul de testare trebuie să înceapă de la etapele inițiale a proiectului și anume de la scrierea cerințelor proiectului.
Rolul testerului:
Definiția 1. Scopul testorului este de a depista erorile softului.
Definiția 2. Scopul testorului este de a depista erorile softului cât mai devreme posibil.
Definiția 3. Scopul testorului este de a depista erorile softului cât mai devreme posibil și se asigură că ele au fost fixate și luate măsuri în legătură cu aceasta.
[1] http://idsi.md/files/file/prezentari_practica_studenti/Tehnici%20de%20testare.pdf
Testarea automată nu va putea înlocui în întregime testarea manuală și nici nu trebuie. Tester-ii
pot să observe cum un utilizator poate interacționa cu produsul, în timp ce un sistem de testare automată nu poate întotdeauna să prevadă aceste acțiuni sau să găsească cea mai bună cale de a le testa. Dacă sunt bine folosite, programele de testare automată măresc considerabil productivitatea QA, economisesc costuri, măresc semnificativ consistența și calitatea produsului și ajută la optimizarea și accelerarea procesului de dezvoltare al unei aplicații. Deja în țările cu tradiție în dezvoltarea de software există cerința ca toate produsele software din sectorul militar, medical, guvernamental și financiar să fie testate cu unul din sistemele recunoscute de testare automată, iar rapoartele automate asupra felului cum a decurs testarea constituie baza acceptării unei aplicații de către client.
[1] http://www.scribd.com/doc/72039973/Testarea-Automata#scribd
9. Bibliografie
[1] http://www.testare-software.ase.ro/articole/test2.htm
[2] TSCR03 2009-2010.pps
[3] http://www.cs.ubbcluj.ro/~mfrentiu/Lectures/VerVal/lectii/C9%20~%20VvSs.pdf
[4]47406530-tehnici-testare.pdf
[5]http://stst.elia.pub.ro/news/IS/TEME_IS_2012_13/1_MiuMa_HereaCr_3GheorgheCo_PetreRa_ParaschivRa_NegreiAl_TeodorascuPa_Test%20PSW_ver_val_v3.pdf
[6] http://www.testingexcellence.com/software-testing-definitions/
[7] Damian Nae Paun 441ATestare_Software v4.doc
[8]http://www.google.ro/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCMQFjAA&url=http%3A%2F%2Fandrei.clubcisco.ro%2Fcursuri%2F3ip%2Fcurs%2F2.2_Modele_ale_procesului_de_dezvoltare.doc&ei=3vJhVf3WOOLjywOuioGoAg&usg=AFQjCNFXjFXdVkFJo-97NiVX3pFgZbh8Bw&sig2=ocqiRZZIaUsl66tyHDZeNw&bvm=bv.93990622,d.bGQ&cad=rja
[9] http://www.shiva.pub.ro/PDF/TEST/Testarea%20software%20si%20asigurarea%20calitatii%20-%20curs1.pdf
[10] http://thor.info.uaic.ro/~dlucanu/cursuri/css/resurse/Saptamana5.pdf
[11] http://en.wikipedia.org/wiki/Test-driven_development
[12]http://revistaie.ase.ro/content/30/ivan-pocatilu.pdf
Bibliografie
[1] http://www.testare-software.ase.ro/articole/test2.htm
[2] TSCR03 2009-2010.pps
[3] http://www.cs.ubbcluj.ro/~mfrentiu/Lectures/VerVal/lectii/C9%20~%20VvSs.pdf
[4]47406530-tehnici-testare.pdf
[5]http://stst.elia.pub.ro/news/IS/TEME_IS_2012_13/1_MiuMa_HereaCr_3GheorgheCo_PetreRa_ParaschivRa_NegreiAl_TeodorascuPa_Test%20PSW_ver_val_v3.pdf
[6] http://www.testingexcellence.com/software-testing-definitions/
[7] Damian Nae Paun 441ATestare_Software v4.doc
[8]http://www.google.ro/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCMQFjAA&url=http%3A%2F%2Fandrei.clubcisco.ro%2Fcursuri%2F3ip%2Fcurs%2F2.2_Modele_ale_procesului_de_dezvoltare.doc&ei=3vJhVf3WOOLjywOuioGoAg&usg=AFQjCNFXjFXdVkFJo-97NiVX3pFgZbh8Bw&sig2=ocqiRZZIaUsl66tyHDZeNw&bvm=bv.93990622,d.bGQ&cad=rja
[9] http://www.shiva.pub.ro/PDF/TEST/Testarea%20software%20si%20asigurarea%20calitatii%20-%20curs1.pdf
[10] http://thor.info.uaic.ro/~dlucanu/cursuri/css/resurse/Saptamana5.pdf
[11] http://en.wikipedia.org/wiki/Test-driven_development
[12]http://revistaie.ase.ro/content/30/ivan-pocatilu.pdf
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Managementul Procesului de Testare al Unui Produs Software (ID: 142299)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.