Sunteți pe pagina 1din 10

Uiversitatea Politehnica Bucuresti - ETTI

CONCEPTELE
TESTARII
SOFTWARE

Balan Fillip-Ioan
MASTER I.C.F.
Concepte generale

Testarea programelor reprezinta o parte a devoltarii unui produs care nu poate


lipsi din ciclul de viata al acestuia. Testarea apare ca singura posibilitate de a face
software-ul operational. Este componenta a etapelor procesului de dezvoltare software.
Fiecare etapa aduce erori specifice, ceea ce implica modalitati, de asemenea, specifice, de
testare. Realizarea de software fiabil este conditionata de efectuarea unei testari cât mai
riguroase. Cu cât procesul de testare este mai riguros, cu atât costurile care se propaga
în timp la utilizatori sunt mai reduse. Aceleasi efecte le resimte însusi producatorul.
Crearea de software orientat spre reutilizare 100 % schimba atât atitudinea producatorului
cât si pe cea a echipei de testare, acordând o atentie speciala produselor care se
realizeaza. Metricile testarii evidentiaza caracteristici de calitate software si progresele
acestora ca rezultate ca rezultat al procesului de testare-corectie.

Defectele sunt cauzate de erorile umane introduse in timpul dezvoltarii unui


program. Ele se manifesta fie prin functionarea incorecta a aplicatiei la nivel logic, fie
prin nefunctionarea sa sau printr-un comportament, sa ii spunem, deviant (erori, crash-
uri, etc.).

Ce inseamna "Testarea software / QA Engineering?"

Testarea in general si in particular cea software, reprezinta suma tuturor procedurilor,


operatiilor si actiunilor menite sa asigure buna functionare a programelor. Prin "buna
functionare" intelegem:

 Respectarea specificatiilor / cererilor clientului


 Implementarea corecta a cerintelor de functionare (requirements)
 Absenta erorilor de proiectare logica si algoritmica
 Siguranta datelor folosite in cadrul programului
 Viteza optima de rulare a aplicatiei
 Folosirea eficienta a resurselor disponibile
 Grad ridicat de folosinta

In acceptiunea generala, testarea se caracterizeaza prin rularea testelor. Aceasta este,


in schimb, doar partea vizibila din exterior. Pentru a asigura toate cele de mai sus, este
nevoie de mult mai multe etape pana a ajunge in punctul executiei testelor. Din motive de
eficienta, planurile de teste trebuie neaparat sa contina si o perioada de timp alocata
planificarii testelor, design-ului test case-urilor, planificarii executiei si, bineinteles,
analizei rezultatelor.
Procesul fundamental de testare este alcatuit din urmatoarele activitati principale:

 Planificare si control
o Verificarea misiunii de testare, definirea obiectivelor si specificarea
activitatii de testare astfel incat aceasta sa atinga obiectivele si scopul
misiunii
o Compararea progresului / evolutiei actual(e) cu planul initial si raportarea
starii de fapt, inclusiv deviatiile de la plan. Pentru a controla eficient
procesul de testare, acesta trebuie monitorizat pe toata durata proiectului.
 Analiza si Design
o Sectiunea in care obiectivele sunt transformate in test case-uri si conditii
de testare tangibile
 Implementare si executie
o Sunt definite proceduri de testare si/sau scripturi prin aranjarea test case-
urilor intr-o anumita ordine si includerea de informatii aditionale necesare
executiei; se pregateste mediul de test si se executa testele
 Evaluarea rezultatelor si raportarea acestora
o Analiza rezultatelor executiei testelor si compararea acestora cu
obiectivele initiale; evident, raportarea situatiei
 Finalizarea procesului de testare
o Adunarea de date stranse pe parcursul proiectului (cifre, numere, impresii
ale membrilor echipei, etc.) in vederea analizei workflow-ului

Diagnosticarea starii tehnice a unui sistem complex, cum ar fi unul software, se bazează
pe faptul că în principiu, comportarea globală a sistemului este determinată de
comportarea fiecărei componente în parte. La rândul ei, fiecare componentă, are
comportarea caracterizată de un set de parametri tehnici care pot fi măsuraţi. În aceste
condiţii, se poate spune că în principiu, dacă toţi parametrii caracteristici ai unui sistem
tehnic sunt măsuraţi şi valorile acestora (vectorii de test) se încadrează în valorile
normale, sistemul respectiv se găseşte într-o stare tehnică bună de funcţionare, iar
comportarea sistemului este normală.

Principiile testarii software

Principiul 1: Cea mai importantă parte a unui scenariu de test este definirea
rezultatului final
Acest principiu evident este una din greşelile cele mai frecvente în testarea
software. Din nou, acest lucru se bazează pe psihologia umană. Dacă rezultatul unui
scenariu de test nu a fost predefinit, şansele sunt să obţinem un rezultat plauzibil, dar
eronat, un fenomen care apare atunci când “ ochiul vede numai ce vrea el să vadă ”. Cu
alte cuvinte, în ciuda definirii testării ca o activitate destructivă, trebuie să existe o dorinţă
în subconştient de a descoperi rezultate corecte ale unor scenarii de test. Un mod de a
combate această problemă este tocmai de a predefine rezultate unui scenariu de test.
Astfel, putem spune că un scenariu de test are două componenete principale:
1. O descriere a datelor de intrare.
2. O descriere foarte precisă a rezultatelor aşteptate pentru anumite date de intrare.
O problemă poate fi caracterizată ca o stare de fapt pentru care nu avem explicaţii
plauzibile, pentru care aşteptările şi preocupările noastre au dat greş. Putem spune că
dacă nu există aşteptări, nu vor exista nici rezultate surprinzatoare.

Principiul 2: Un programator trebuie să evite să testeze propriul program

Orice scriitor ştie – sau ar trebui să ştie – că este o idee proastă să editezi sau să corectezi
propriul text. Asta pentru că un scriitor ştie ce ar vrea să spună textul respectiv şi s-ar
putea să nu realizeze atunci când textul spune altceva. Alt motiv este că în subconştient
nu se doreşte a se găsi erori în propria muncă. Acelaşi principiu se aplică şi pentru “
autorii software ”. O altă problemă apare atunci când se schimbă prioritaţile într-un
program software. Atunci când un programator a construit migălos un program, îi va fi
greu să se uite la el dintr-o altă persepctivă, mai ales una destructivă.
Majoritatea programatorilor nu pot să îşi testeze în mod eficient propriul cod pentru că nu
pot simula diferite stări psihologice pentru a identifica erori. În plus, un programator se
poate chiar şi teme de a găsi erori pentru a nu fi tras la raspundere de supervizori, clienţi
sau patron. În afară de aceste aspecte psihologice, mai există încă o problemă
semnificativă: programul poate conţine erori şi din cauza lipsei de informare sau
înţelegerii greşite a programatorului cu privire la specificaţiile produsului. Cel mai
probabil este ca şi scenariile de test sa fie construite prost tocmai din cauza acestor
neînţelegeri.
Aceste aspecte nu fac totuşi imposibilă testarea de către programator a propriului
program. Totuşi, testarea este mult mai riguroasă şi mai productivă atunci când este
facută de către specialişti. O observaţie importantă trebuie totuşi facută. Argumentele
aduse până acum nu se aplică în cazul corectării erorilor deja cunoscute de programator
(proces numit “ debugging ”); dimpotrivă, cel mai eficient este atunci când un
programator face debugging pe propriul program.

Principiul 3 : O echipă de dezvoltare nu trebuie să îşi testeze propriul program

Argumentul de aici este similar cu cel precedent. Un proiect sau o echipă de dezvoltare
este, de cele mai multe ori, o organizaţie în viaţă, cu probleme psihologice similare cu
cele ale indivizilor care formează echipa. O echipă de dezvoltare sau un manager de
proiect are rolul şi abilitatea să producă un porgram care respectă anumite specificaţii, cât
şi un termen limită de predare şi costuri de producţie. Astfel, va fi foarte dificil să
estimeze şi să cuantifice fiabilitatea unui produs, deci partea de testare va fi una foarte
obiectivă, tocmai pentru că nu se doreşte depăşirea termenului limită şi nici a resurselor
financiare.
Din nou, acest lucru nu inseamnă că este imposibil pentru o organizaţie să găsească erori
în propriul produs, ci că este mai fiabil, chiar economic ca acest lucru să fie facut de către
o altă echipă independentă.
Principiul 4: Rezultatele fiecarui test trebuie inspectate in detaliu

Acest principiu este probabil cel mai evident, dar, din nou, este un aspect deseori trecut
cu vederea. Au fost multe experienţe în care nu au fost descoperite anumite erori, deşi
erau usor de observat din rezultatele scenariilor de test. Altfel spus, existau multe erori ce
puteau fi descoperite încă din primele testări ale unui produs şi au fost scoase la iveală pe
parcurs, tocmai datorită lipsei de atenţie din testele anterioare.

Principiul 5: Scenariile de test trebuie concepute cu date de intrare nevalide şi


neaşteptate, cât şi cu date valide şi aşteptate.
Există o tendinţă naturală atunci când se testează un program să ne concentrăm asupra
unor date de intrare valide pentru care ne asteptăm la un anumit răspuns, existând
probabilitatea să neglijăm anumite date de intrare ce generează condiţii neaşteptate într-
un program.

Principiul 6: Un program trebuie testat că face ceea ce trebuie sa facă, dar şi că nu face
ceea ce nu trebuie sa facă

Acest principiu poate fi privit mai mult ca un corolar la principiul anterior. Programele
trebuie testate şi pentru efecte colaterale nedorite. De exemplu, un program de gestiune a
salariilor care generează diferite sume poate avea erori atunci când se generează date
pentru angajaţi care nu există, deşi acţiunile pot fi corecte.

Principiul 7: A se evita utilizarea de testcaseuri ce nu pot fi folosite decât o singură dată


Această problemă apare mai ales în sisteme interactive. O practică uzuală este de a
genera scenarii de test de la un terminal al aplicaţiei şi apoi să le trimitem în program.
Principala problemă apare atunci când scenariile de test nu pot fi folosite decât în
momentul respective pentru a genera diferite rezultate pentru că programul nostru
interacţionează în timp real cu userul. Presupunem că apare o eroare şi o corectam. Pentru
viitoarele testări vor trebui cu totul alte scenarii, practic vor fi reinventate. Pentru ca
această acţiune necesită mult timp şi muncă, este de dorit a se evita. Tocmai de aceea
trebuie pus foarte mult accent pe testele iniţiale pentru a identifica cât mai multe erori ce
nu vor apărea în modificari ulterioare ale aplicaţiei. Aceleaşi scenarii de test vor putea fi
din nou efectuate într-o altă variantă a programului pentru a testa că erorile nu au aparut
din nou. Acest tip de testare mai poartă şi numele de testare regresivă.

Principiul 8: A se evita testarea cu intenţia de a demonstra că un program nu conţine erori

Aceasta este o greseală pe care managerii de proiect obişnuiesc să o faca şi este un semn
clar al înţelegerii unei definiţii incorecte a testării – procesul prin care se demonstrează că
un program funcţionează corect. Încă o dată trebuie reamintită definiţia corectă a testării
software – procesul prin care un program este executat cu intenţia de a găsi erori.
Principiul 9: Probabilitatea existenţei erorilor într-un program este direct proportională cu
numărul erorilor deja găsite

La o primă vedere poate nu are suficient sens, dar acest fenomen este prezent în
majoritatea programelor. De exemplu, dacă un program este format din doua module, A
si B, clase sau subrutine, iar 5 erori sunt găsite în modulul A şi una singură în modulul B,
putem trage o concluzie că testele viitoare vor relata mai multe erori în modulul A decât
în B.
Un alt mod de a întelege acest principiu este că erorile tind să vină în serie şi că, într-un
program tipic, modulele lui nu sunt proporţional predispuse la erori, ci unele tind să aibă
mai multe erori decât celelalte. Încă nu există o explicaţie concretă a acestui fenomen,
însă ne poate oferi un excelent feedback în procesul de testare al programului pentru că
vom şti ce secţiuni au nevoie de o testare suplimentară.

Principiul 10: Testarea este o activitate extrem de creativă, intelectuală şi provocatoare

Este probabil adevărat faptul că nivelul de creativitate în testarea unei aplicaţii mari
depaşeşte nivelul de creativitate în conceperea acestuia. Deja am observat că este practic
imposibil să testăm un program şi să identificăm toate erorile posibile.

Metode de testare

Metoda "Black Box"

Presupune testarea programului la nivelul user-ului, plecand de la premisa ca nu


cunoastem modul in care acesta functioneaza. Practic, nu luam in calcul modul in care
programul este construit si metodele sale, ci pur si simplu noi ii cerem ORICE, iar
programul trebuie sa ne dea un raspuns. Pentru acest tip de testare, tester-ul trebuie sa
cunoasca rezultatele ce se asteapta din partea programului pentru fiecare caz in parte.

Metoda "White Box"

Este opusul metodei Black box. In acest caz, se presupune ca tester-ul are acces in sursele
programului (structuri, cod, algoritmi). De multe ori, testarea prin aceasta metoda implica
scrierea de cod sau cel putin, urmarirea celui existent. Practic, luand la cunostinta
constructia programului si modul sau de lucru, se testeaza fiecare metoda in parte initial,
cat si interoperarea metodelor. Aceasta metoda este aproape identica cu testarea unitara.
Metoda "Gray Box"

Pe parcursul anilor, aceasta metoda a aparut din nevoie si practicabilitate. Este, dupa cum
ii spune si numele, etapa intermediara intre "White box" si "Black box". Ca mod de lucru,
avand acces la sursele programului, se construiesc test case-urile. Dupa care, acestea sunt
executate in mod Black box ca si user simplu, neaxandu-ne in momentul executarii
testului pe structura interna a programului.

Toate metodele de testare prezente in ciclul de viata al unui produs software sunt incluse
in diagrama de mai jos:

Testarea functionala este o testare de tip black box canalizata pe verificarea cerintelor
functionale ale aplicatiei; acest tip de testare trebuie facut de testeri. Asta nu inseamna ca
programatorii nu ar trebui sa isi verifice codul (asta fireste se aplica oricarui stadiu al
testarii). Testarea functionala cuprinde diverse metode de testare:

 Unit testing – testarea pe unitate este prima treapta a testarii ; se testeaza functiile
sau module de cod . De obicei sunt facute de programatori deoarece presupun
cunostinte avansate a design-ului intern al aplicatiei si codului. Nu intotdeauna
sunt usor de executat daca aplicatia nu are o arhitectura bine pusa la punct; poate
presupune dezvoltarea de drivere sau alte componente.
 Testarea integrata - Testarea combinata a diferitelor parti dintr-o aplicatie pentru
a vedea daca functioneaza corect. Aceste "parti" pot fi module de cod, aplicatii
individuale, aplicatii client-server intr-o retea etc.
 Testarea de sistem - Testare de tip black-box bazata pe specificatii care acopera
toate partile sistemului.
 Testarea acceptarii de catre user – Determina daca softul este satisfacator pentru
utilizatorul final sau client.
 Testarea utilizabilitatii - Testarea daca un software este "user-friendly". Evident
aceasta testare este subiectiva si va depinde de utilizatorul sau clientul vizat.
Interviuri cu utilizatorii, survey-uri, monitorizarea sesiunilor utilizatorilor sunt
metode care pot fi folosite. Programatorii si testerii nu sunt cei mai indicati pentru
acest tip de testare.
 Testarea instalarii si a dezinstalarii - testarea partiala sau integrala a procesului
de instalare sau upgrade.
 End-to-end testing - similar cu system testing; este testare de nivel 'macro' ;
presupune testarea aplicatiei in mediul in care va fi folosita.
 Sanity testing or smoke testing – testarea starii de “sanatate” a sistemelor dupa a
noua versiune de soft a aplicatiei. Daca un nou soft face ca sistemele sa se
blocheze frecvent, corupe bazele de date, etc inseamna ca aplicatia nu este destul
de “sanatoasa” pentru a fi testate in continuare in starea curenta. Mentinerea
testarii in stadiul actual poate duce la distrugerea sistemelor de test.
 Testarea de acceptanta – testarea finala bazata pe specificatiile utilizatorului
final, sau bazata pe folosirea de catre utilizatorul final intr-o anumita perioada de
timp; este tesatrea tipica pentru variatele de program aparute in stadiul beta, care
sunt disponibile pentru toti utilizatorii pentru o perioada limitata de timp;
 Testarea de compatibilitate – se testeaza cat de bine se comporta aplicatia intr-o
anumita configuratie hardware, sistem de operare si impreuna cu alte aplicatii;

Testarea non-functionala: - este testarea care nu se are ca scop verificarea


functionalitatii aplicatiei ci aspecte legate de performanta, incarcare, securitate, etc.
Exista o convingere pe scara larga ca testarea nonfunctionala sa se faca la sfarsitul fazei
de testare dupa sau in timpul testarii de acceptanta. În practică, acest lucru se adaugă risc
prea mult pentru a programului. Ce se întâmplă în cazul în care se gaseste un defect de
performanţă, care necesită un redesign major al funcţionalităţii? Este de preferat sa se
faca niste teste nonfunctionale inca din primele etape ale dezvoltarii softului, sip e masura
ce softul se maturizeaza si testarea non-functionala poate deveni mai complexa.

 Testarea de performanta – testarea obiectivelor de performanţă sau eficacitate


prestabilite, precum timpi de răspuns sub încărcarea unui anumit set de date sau
diferite condiţii de configuraţie. Din moment ce scopul unei testări de sistem este
să demonstrăm că un program nu îşi îndeplineşte obiectivele, scenariile de test
pentru o testare de performanţă ar trebui create astfel încât să demonstrăm că
programul nu respectă obiectivele de performanţă.
 Testarea de stocare - Similar testării de performanţă, există unele programe care
au anumite obiective în ceea ce priveşte capacitatea de stocare a datelor. De
exemplu, ne putem pune întrebările: care sunt dimensiunile memoriei principale?
Dar ale memoriei secundare? Care este cantitatea de fişiere temporare ce pot fi
stocate de program? Scenariile de test trebuie create analog, demonstrând că
programul nu respectă obiectivele privind capacitatea de stocare a datelor.
 Testarea de stress – este strans legata de testarea de incarcare si performanta.
Pentru astfel de testare se incearca operatii cu un numar foarte mare de repetitii,
introducere de valori foarte mari, interogari complexe in bazele de date, etc.
Pentru că inevitabil în acest tip de testare intervine factorul de timp, nu se poate
executa asupra tuturor programelor. Este aplicabilă în special programelor care
funcţionează în timp real sau care controlează procesele într-o activitate. Dacă un
sistem de operare suportă maxim 15 aplicaţii, o altă testare de stress ar fi rularea
celor 15 aplicaţii simultan. Unul din domeniile în care testarea de stress este foarte
utilă este cel al aplicaţiilor web-based. Aici practic dorim să ne asigurăm că atât
aplicaţia, cât şi sistemul sub test poate să proceseze cererile simultane a mai
multor useri conectaţi. Pentru a putea concepe astfel de planuri de teste, trebuie să
cunoaştem foarte bine “ audienţa ”, adică să cunoaştem cu aproximare numărul de
clienţi, sau volumul de date ce poate fi prezent la un moment dat în sistem. Erorile
generate de astfel de teste sunt destul de rare, pentru că avem de-a face cu situaţii
excepţionale, puţin întâlnite în viaţa reală, dar ne putem face o idee concretă
despre limitarile programului.
 Testarea de recuperare - Programe complexe, precum sistemele de operare sau
de administrare a bazelor de date au impuse obiective de recuperare în cazul unor
defecţiuni critice provocate de erori în programare sau de ordin hardware. Există
funcţii speciale de recuperare a datelor, iar testarea va consta în a demonstra că
aceste funcţii nu funcţionează corect. Astfel, putem în mod intenţionat injecta
erori de programare în sistemul software şi să urmărim dacă acesta poate să-şi
recupereze integritatea software. Partea hardware ar putea provoca erori în
paritatea memoriei sau erori în intercomunicaţia cu echipamentele periferice.
Nu este suficient ca sistemul să îşi revină la starea iniţială. Scopul este ca acest
lucru să se întâmple într-un timp cât mai scurt (MTTR: mean-time-to-recovery).
 Testarea de securitate - Fiindcă societatea este din ce în ce mai îngrijorată în
privinţa securitaţii datelor, multe dintre programele software din ziua de astăzi
pun accent pe acest aspect. Acest gen de testare este foarte important mai ales in
aplicatiile web, la care au acces cu foarte putine restrictii un numar teoretic
nelimitat de persoane, din care in mod sigur un anumit procent vor incerca sa
pericliteze integritatea aplicatiei sau chiar a serverului pe care ruleaza aceasta
daca este posibil. Una din tehnicile inovatoare de securizare a datelor este
encriptarea metodă ce nu permite citirea datelor fară o cheie de decriptare.
Concluzii:

Testarea are un loc bine precizat în structura ciclului de dezvoltare software.


Testarea este necesara pentru a stabili nivelurile caracteristicilor de calitate pentru
programul care se livreaza si pentru a le compara cu nivele planificate, respectiv nivele
anuntate de elaborator. Programele efectueaza pe lânga prelucrarile din specificatii si alte
prelucrari complementare. Rolul testarii este de a evidentia combinatii de optiuni care
genereaza aceste prelucrari. Testarea este absolut necesara în procesul industrializarii
productiei de software. Lucrul în echipe de programare presupune predare si preluare de
module. Testarea este singurul mod de a verifica un modul înainte de predare precum si
la predarea de catre producator a produsului software. Eficienta testarii influenteaza toate
fazele ciclului de dezvoltare software. Revenirile la fazele precedente sunt rezultatul
concluziilor ce se desprind din testare. Rigurozitatea si gradul de acoperire scurteaza
distanta dintre punctul de unde se efectueaza revenirea si faza care necesita modificari.
Costurile testarii se reflecta direct în structura cheltuielilor atât la producatorii de
software cât mai ales la utilizatori. Daca s-a acordat atentie testarii, costurile la
producator sunt cosiderabile, însa ele se recupereaza prin efectele pozitive de la nivelul
utilizatorilor, efecte care sunt bazate pe calitatea produselor, iar aceasta cu cât este mai
ridicata cu atât presupune un cost stimulativ mai ales pentru utilizator.

BIBLIOGRAFIE:

http://www.testingreflections.com
http://www.softwaretesting.ro
wikipedia - functional/nonfunctional testing
http://www.kaner.com/imposs.htm (The Impossibility of Complete Testing – Cem Kaner)