Metodologie de testare a erorilor

fizice i umane pentru un produs

software
Exemplele de eecuri/defectari software sunt mai multe, printre ele se numr:
Prima lansare a rachetei Ageniei Spaiale Europene din iunie 1996, care a euat dup
37.5 sec. O eroare software a cauzat devierea rachetei de la ascendena sa vertical i
capacitile de auto-distrugere au fost activate ducnd la o problem i mai mare.
n noiembrie 2005, n Statele Unite un site web a dezvluit informaii despre top 10 cei mai
cutai criminali iar aceast poveste a fost redat la tiri i la radio, oferind astfel publicitate
site-ului web, ducnd la un numr impresionant de accesri care a atras dup site
performane disfuncionale, ntruct site-ul nu fusese testat la o rat att de mare a traficului.
Toate aceste exemple au n comun disfuncionalitatea datorat lipsei rigurozitii de testare
n figura de mai jos sunt prezentate cele 3 resurse care trebuiesc luate n consideratie la realizarea unui
produs software.

Defectele software se manifest ca rezultat al urmtorului

proces: un programator comite o eroare (greeal), care
la rndul ei rezult ntr-un defect (bug) la nivel de codul
surs al programului; dac acest defect este executat, n
anumite condiii sistemul va produce un rezultat greit,
ceea ce ulterior va duce la o euare a programului.[

1
 Paii realizrii proiectelor software

Rolul procesului de testare este de a asigura examinarea funcionalitilor nainte ca sistemul s fie folosit,
i orice defectare s fie raportat echipei de dezvoltare pentru a fi rezolvat. Testarea nu poate nltura
direct defectele, i nu poate nici mbunti calitatea, dar prin raportarea defectelor descoperite, acestea
pot fi nlturate crescand astfel fiabilitatea sistemului.

Practici n dezvoltarea software Dezvoltarea iterativ

Dezvoltarea in cascada poate fi i mai bine prezentat n figur urmtoare care pune n
eviden etapele executabile ale dezvoltrii proiectului.

Sistemul executabil al dezvoltrii iterative

2
 Fazele dezvoltrii unui proiect software
5

Realizarea testrii unui produs

software principii generale
Un test consta in executia programului pentru un set de date de intrare convenabil ales,
pentru a verifica daca rezultatul obtinut este corect

Un caz de test este un set de date de intrare impreuna cu datele de iesire pe care
programul ar trebui sa le produca.

Testarea este activitatea de conceptie a cazurilor de test, de executie a testelor si de

evaluare a rezultatelor testelor, in diferite etape ale ciclului de viata al programelor.

Scopul primordial pentru procesul de testare este (1) identificarea erorilor de software, (2) izolarea i
fixarea/corectarea defectelor care au cauzat aceste erori. Deoarece testarea nu poate demonstra cu
certitudine de 100% ca produsul funioneaz corect n orice condiii; testarea doar poate demonstra c
produsul nu funcioneaz corect n anumite condiii. n scopul testrii deseori se include att
examinarea static a codului surs, ct i examinarea codului n execuie n diferite mprejurri i sub
diferite condiii. Aspectele de cod ce rmn sub ochiul vigilent al test/software inginerului n timpul
acestui exerciiu sunt (1) codul face lucrul care este presupus sa-l fac i (2) codul face lucrul care
trebuie sa-l fac. Informaia obinut n urma procesului de testare poate fi folosit pentru corectarea i
mbuntirea procesului conform cruia se dezvolt produsul software.[

3
EVOLUTIE
1945 - 1956 - Teste orientate pe depanare-(Debugging oriented)
Primul cercetator care s-a ocupat de noiunea de testare a unui program este Alan Turing care public n 1949 un articol despre
principiile teoretice ale verificrii corectitudinii funcionrii unui program. n 1950, Turing public un alt articol, n care ridic
problema inteligenei artificiale, i definete un test pe care sistemul informatic trebuie s l treac, i anume rspunsurile oferite
de ctre acesta la ntrebrile adresate de un operator (testerul) s nu poat fi difereniate de ctre rspunsurile oferite de un om
(etalonul). Aceast lucrare poate fi considerat a fi prima care se ocup de conceptul de testare, considerat distinct de
activitile de elaborare a codului respectiv de depanare.
19571978 Teste orientate pe demonstrare functionalitatii (Demonstration oriented)
Testarea pe scar larg a devenit necesar datorit creterea impactului economic pe care defectele nedetectate le puteau
avea. De asemenea, persoanele implicate n dezvoltarea de programe informatice au devenit mai contiente de riscurile
asociate cu defectele din programe i au nceput s pun mai mult accent pe testarea i remedierea defectelor nainte ca
acestea s afecteze produsul livrat. n aceast perioad, termenii de testare i depanare se suprapuneau i se refereau la
eforturile fcute n scopul descoperirii, identificrii i remedierii defectelor din sistemele informatice. Scopul procesului de testare
era demonstrarea corectitudinii funcionrii programului, adic absena erorilor
19791982 - Orientare spre defectare (Destruction oriented)
In 1979. Glenford J. Myers face distincia dintre depanare care este o activitate care ine de dezvoltarea programului i testarea
care este activitatea de rulare a unui program cu scopul declarat de a descoperi erori. El susine c n testarea bazat pe
demonstraie exist pericolul ca operatorul s aleag n mod incontient acel set de parametri care ar asigura funcionarea
corect a sistemului, ceea ce creeaz pericolul ca multe defecte s treac neobservate. Myers propune n abordarea sa i o
serie de activiti de analiz i control care mpreun cu procesul de testare s creasc nivelul de calitate a sistemelor
informatice.
1983 - 1987 - Orientarea spre evaluare (Evaluation oriented )
instituiile americane ANSI i IEEE ncep elaborarea unor standarde care s formalizeze procesul de testare, efort concretizat n
standarde precum ANSI IEEE STD 829, n 1983, care stabilea anumite formate care s fie utilizate pentru crearea
documentaiei de testare.
1988 - n prezent - Orientarea spre prevenire Prevention oriented
Testarea trebuie fcut n toate fazele de lucru, n paralel cu programarea i are urmtoarele activiti principale: planificare,
analiz, proiectare, implementare, execuie i ntreinere. Respectarea acestei metodologii duce la scderea costurilor de
dezvoltare i de ntreinere a unui sistem prin scderea numrului de defecte care ajung nedetectate n produsul final
7

Metode de Testare
Testarea in vederea verificarii programului folose te date de
Functional Testing test alese de participantii la procesul de dezvoltare a
programului. Ea este efectuata la mai multe nivele: la nivel de
unitate functionala, de modul, de subsistem, de sistem.

Black box Testing Nu se bazeaz pe cunoaterea interna a design-ului sau a

codului. Testele sunt bazate pe cerine i funcionalitate

Se bazeaz pe cunoaterea logicii interne a codului

White box Testing aplicaiei. Testele sunt bazate pe acoperirea sintaxei de
cod, ramuri, cai, condiii

Testarea in vederea validarii programului, numita si testare de acceptare, are drept scop
stabilirea faptului ca programul satisface cerin ele viitorilor utilizatori. Ea se efectueaza n
mediul in care urmeaza sa functioneze programul, deci folosindu-se date reale. Prin testarea
de acceptare pot fi descoperite si erori, deci se efectueaza si o verificare a programului
8

4
 Testarea Funcional
Prima treapta a testrii; se testeaz funciile sau module de cod. De
obicei sunt fcute de programatori deoarece presupun cunotine
Unit Testing avansate a design-ului intern al aplicaiei i codului.

Testare combinat a diferitelor pri dintr-o aplicaie pentru a vedea

Integration Testing dac funcioneaz corect. Aceste "pari" pot fi module de cod,
aplicaii individuale, aplicaii client-server ntr-o reea etc.

System Testing Testare de tip Black-box bazata pe specificaii care acoper toate
prile sistemului

Testare prin care se determina dac software-ul este

User Acceptance Testing satisfctor pentru un utilizator final sau client.

Testare prin care se determin dac un software este "user-friendly"

(prietenos pentru utilizatorul final. Evident aceasta testare este
subiectiv i va depinde de utilizatorul sau clientul vizat. Interviurile
Usability Testing cu utilizatorii, sondajele, monitorizarea sesiunilor utilizatorilor sunt
metode care pot fi folosite.

Testare parial sau integral a procesului de instalare sau

Install/Uninstall Testing upgrade

End-to-end Testing Este similar cu System testing; este o testare de nivel 'macro';
presupune testarea aplicaiei n mediul n care va fi folosit

Sanity Testing sau Smoke Testing

10

5

Regression Testing
Reprezint aciunea de re-testare dup corecii sau
modificri ale software-ului sau a mediului su de
dezvoltare. Poate fi dificil de a determina ct de mult este
nevoie de re-testare, n special, aproape de sfritul
ciclului de dezvoltare. Instrumentele automate de testare
pot fi utile, n special, pentru acest tip de testare

Testare final pe baza specificaiilor utilizatorul final sau

Compatability Testing clientului, sau pe baza utilizrii de ctre acetia pentru
o perioad limitat de timp

Se testeaz ct de bine software-ul funcioneaz ntr-o

anumit configuraie de hardware / software / sistem de
Acceptance Testing operare / reea / etc

11

Testarea Non-Funcional
Acest tip este adesea folosit n mod alternativ cu testarea de
Performance Testing "stres" sau testarea de "ncrcare".
Folosit pentru a descrie testarea funcional a sistemului n timp, sub
Stress Testing ncarcri neobinuit de mari, repetarea n mai multe cicluri a unor anumite
aciuni sau intrri, inserarea de valori numerice mari, interogri complexe i
mari la un sistem de baze de date, etc
Testare a unei aplicaii n sarcini mari, cum ar fi testarea unui site web sub o
Load Testing serie de sarcini pentru a determina n ce moment timpul de rspuns a
sistemului se degradeaz sau nu
Recovery Testing Testare pentru a se vedea ct de bine un sistem se recupereaz de la
accidente, erori de hardware, sau alte probleme catastrofice

Acest tip de testare valideaz capacitatea unui sistem de a fi n msur s

Failover Testing aloce resurse suplimentare i s mute operaiunile pe sisteme back-up

Testare pentru a se evidenia ct de bine sistemul este protejat

mpotriva accesului intern sau extern neautorizat, deteriorarea
Security Testing intenionat, etc.; poate necesita tehnici de testare sofisticate

12

6
 Alte metode de testare
O testare informal, care nu se bazeaz pe planuri de testare oficiale
Exploratory Testing sau cazuri de testare. n aceast situaie specialitii n testare pot
nva software-ul n timp ce-l testeaz
Testare similar cu cea exploratoare, dar specialitii n testare nu
Ad-hoc Testing cunosc produsul software n amnunt
Testare efectuat din nevoia de a nelege mediul, cultura, i
destinaia de utilizare a software-ului. De exemplu, abordarea de
Context-driven testing testare pentru software-ul pentru echipamentele medicale de
urgen ar fi cu totul diferit de cea pentru un joc pe calculator cu
buget redus

Comparison Testing Testare ce const n compararea punctele slabe i punctele forte ale
software-ului de la produsele concurente
Testare a unei aplicaii atunci cnd dezvoltare sa se apropie de finalizare,
Alpha Testing modificri minore de design pot fi nc fcute ca urmare a unei astfel de testare.
Se efectueaz de obicei de ctre utilizatorii finali sau alte persoane, i nu de
programatori sau specialiti n testare.
Testare cnd dezvoltare i testare sunt, n general, complete i bug-uri finale i
Beta Testing problemele trebuie gsite nainte de produsul final. Se efectueaz de obicei de ctre
utilizatorii finali sau alte persoane, i nu de programatori sau specialiti n testare.
Este o metod pentru a determina dac un set de date de testare sau de cazuri
Mutation Testing de testare este util, prin introducerea n mod deliberat diferite modificri de cod
("bug-uri") i retestarea cu date de test / cazuri originale, pentru a determina dac
sunt detectate de "bug-uri".

n prezent, testarea se realizeaz utiliznd fie strategia black box (cnd se

urmarete numai comportamentul funcional al produsului), fie strategia
white box (se analizeaz comportamentul programului avnd la dispozitie
codul surs al acestuia).

Iniial, testarea se facea integral manual, fiind considerat singura soluie de

a descoperi eventualele defecte.

Testele automate execut practic o secven de aciuni cu intervenie

uman minim i pot simula utilizarea unei aplicaii n condiii reale, de
simultaneitate ridicat.

14

7
 Testarea Manual vs Testarea Automat

AVANTAJE

Testare Automat Testare Manual

Daca trebuiesc repetate aceleai teste de multe ori Daca Test Case-urile trebuiesc rulate de un numr mic de ori
automatizarea prezint un mare avantaj e mult mai probabil sa se prefere testarea manuala

Ajuta la executarea de teste de compatibilitate a

Permite tester-ului s fac mai multe teste ad-hoc
programelor create pe mai multe configuraii

Permite executarea scenariilor de testare ajutnd la

Costurile pe termen scurt sunt reduse
testele de regresie

Cu cat un tester petrece mai mult timp verificnd un modul

Permite rularea mai multor teste de regresie pe un cod
cu att cresc ansele de a gsi mai multe defecte i posibile
care se schimba des
greeli de utilizare

Pot fi rulate simultan pe mai multe maini astfel scznd

timpul de testare

Costurile pe termen lung sunt reduse

Testarea automat - prezentare

Cele mai importante beneficii sunt:
acoperirea tuturor etapelor de testare de la concepie
pn la lansare
posibilitatea simulrii testrii cu mai muli utilizatori.
posibilitatea repetrii testelor
creterea siguranei n produs
Un sistem de testare automat trebuie s aib la
baz dou caracteristici principale:
module reutilizabile
ntreinerea i urmrirea activitii dintr-un singur
punct de control
16

8
 Testarea automat
ntr-o abordare mai detaliat testarea automat nseamn:
1. planificare
identificarea cerinelor i a funcionalitilor.
gruparea acestora n condiii de test.
crearea cazurilor de test pentru aceste condiii.
2. design
construcia scripturilor de test.
generarea testelor de rulare.
3. execuie
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.

17

Tipurile de testare automat

1. structural (white-box testing) - se verific structura software-ului i necesit acces
complet la codul surs.
2. funcional (black-box testing) se definesc ateptrile clientului de la aplicaie i
se verific automat dac software-ul se comport conform acestor ateptri
3. regresiv (regression testing) - se verific dac s-a modificat neateptat
comportamentul aplicaiei n urma implementrii unor noi cerine/schimbri (change
requests).
4. negativ (negative testing) - se solicit aplicaia, producnd deliberat cazuri
complicate,neobinuite sau particulare pentru a fora apariia erorilor.
5. de solicitare (stress testing) - se determin capabilitile absolute ale aplicaiei i
ale infrastructurii pe care este implementat
6. de performan (performance testing) - n urma acestui tip de testare se verific
dac performana aplicaiei este adecvat pentru cerinele stabilite, n termeni de
vitez de acces, resurse de sistem utilizate i procesarea cererilor de acces.
7. de ncrcare (load testing) - se determin punctele slabe ale aplicaiei i dac sunt
necesare mbuntiri ale infrastructurii hardware sau software prin msurarea
caracteristicilor de performan i scalabilitate a principalelor componente ale
aplicaiei web; de regul aceasta se realizeaz prin creterea numrului de sesiuni
utilizator sau a conexiunilor TCP/IP.

18

9
 Unelte pentru sistemele de testare
automat
GUI , prin folosirea metodei "nregistrare/redare".
analizoare de cod - analizeaz complexitatea codului
scris, respectarea unor standarde de scriere a codului.
analizoare de memorie - detecteaz depirea memoriei
alocate, suprascrieri n zone nealocate i zone rmase
nedealocate.
testare de solicitare/performan - pentru testarea
aplicaiilor web i client/server n diferite cenarii de
solicitare.
testare servere web - verific validitatea i integritatea
link-urilor, a codului html, programe client-side i server-
side, securitatea transmiterii datelor.
alte unelte - pentru managementul documentaiei,
raportrii bug-urilor, configuraiei, etc.
19

Avantajele utilizrii testrii

automate
1. avantaje privind eficiena i costurile
prevenirea erorilor prin abordarea structurat a procesului de dezvoltare a proiectului.
detecia erorilor care au ajuns pn n faza de producie (prin teste de regresie automat).
reutilizarea informaiei acumulate (condiii de test, scripturi).
reducerea crerii de noi scripturi (refolosindu-le i adaptndu-le pe cele vechi).
execuia 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
redirecionat ctre alte necesiti.
2. avantaje privind economia de timp
analiz rapid i exact n cazul schimbrii parametrilor sistemului.
durat scurt a ciclurilor de testare.
estimri mai exacte pentru procesul de planificare a testului.
posibilitatea efecturii mai multor teste (scripturile de testare pot fi rulate i dup orele de
program economisind astfel timp).
generarea rapid a condiiilor de testare.
3. avantaje privind calitatea
o mai bun nelegere a scopului testrii.
o acoperire mai mare a elementelor de testat.
rezultate mai consistente datorit repetabilitii testelor.
compararea automat a rezultatelor.

20

10
 Test Driven Development -
prezentare
TDD (Test Driven Development) este o
tehnic de dezvoltare software bazat pe
iteraii mici care se desfasoar astfel: se
scrie codul de test pentru functionalitile
noi care trebuie introduse n aplicaie, apoi
se scrie codul care implementeaz
funcionalitatea.

21

Test Driven Development

Test Driven Developement nseamn s se scrie mai
intai unit test-uri i apoi s se scrie codul, trecnd prin
cele 3 strii specifice:
RED, cnd mai nti exist numai testul scris, far nici un
pic de cod, deci nu se compileaz. Apoi cnd se
"mimeaz" o funcie pentru a compila codul i a pica
testul.
GREEN, cnd se modific codul n cel mai simplu mod
pentru a satisface exact acel test (de exemplu, dac
exit o funcie de cutare i returneaz true/false i
verific s gaseasc un element se scrie doar return
true).
REFACTOR, unde se elimin codul duplicat, pentru a
simplifica i generaliza ct mai mult codul.
22

11
 Concluzii
Testarea automat nu va putea nlocui n ntregime
testarea manual i nici nu trebuie.
Tester-ii pot s observe cum un utilizator poate
interaciona cu produsul, n timp ce un sistem de testare
automat nu poate ntotdeauna s prevad aceste
aciuni sau s gseasc cea mai bun cale de a le testa.
Dac sunt bine folosite, programele de testare automat
mresc considerabil productivitatea QA, economisesc
costuri, mresc semnificativ consistena i calitatea
produsului i ajut la optimizarea i accelerarea
procesului de dezvoltare al unei aplicaii.

23

12