I.

Introducere
Testarea software o privire de ansamblu. Scopul acestei prelegeri este de a face mai clare urmtoarele
aspecte ale testrii software:
Impactul erorilor software asupra vieii noastre
Ce prezint erorile software i care este cauza apariiei lor
Cine sunt testorii i care este rolul lor n procesul de elaborare a softului
n secolul XXI nu ne putem imagina viaa fr produse software. Majoritatea populaiei sunt
posesori de calculatoare personale. Tehnologiile informaionale s-au infiltrat n toate domeniile activitii
umane. Mergnd la cumprturi putem primi mpreun cu o cutie de margarin sau de cereale un CDROM gratis cu un joc video sau cu muzic. Muli dintre noi nu pot petrece o zi fr Internet. Aplicaiile
software au nlocuit funcionarii n diverse ramuri, astfel avnd un impact enorm asupra vieii i activitii
umane. Pentru a asigura calitatea i sigurana aplicaiilor software se pune un accent deosebit pe testarea
acestor din urm. Testarea de software a devenit o profesie tehnic foarte important. Urmtoare exemple
pot ilustra foarte bine necesitatea testrii software.
Dezvoltarea aplicaiilor software implic o serie de activiti, n care posibilitatea erorii umane este
foarte ridicat. Testarea este un element cheie n procesul de dezvoltare, i reprezint o ultim
recapitulare a specificaiilor, design-ului i codului. Un studiu al Institutului de Testare Software (Software
Testing Institute), relev urmtoarele :

Testerii implicai n industria software sunt mai muli dect n orice alt industrie (43%)
Testarea software este executat mai degrab n cadrul departamentelor de programare (44%),
dect n cadrul unui departament orientat exclusiv pe testare (39%)
Doar 4% din productorii software supui acestui studiu prevd nfiinarea unui departament
orientat exclusiv pe testare.

Testarea software, prin definiie, urmrete focalizarea pe procesul de identificare a posibilelor erori
de program, erori care ar putea avea un impact negativ asupra produsului, i prin urmare asupra clienilor.
Satisfacia clienilor este cheia reuitei oricrei afaceri, i asta nu mai este o necunoscut.
Aceasta presupune c produsul oferit s fie de calitate ridicat, i s nu produc erori n timpul
utilizrii de ctre client. Calitatea ridicat nu poate fi obinut doar cu ajutorul unei echipe de programatori
de excepie. Este deja bine tiut faptul c orict de bine pus la punct ar fi produsul dezvoltat, acesta
conine totui erori.
Implicarea testrii n procesul de producie aduce urmtoarele avantaje:

Organizare disciplinat a procesului de dezvoltare i testare matur a procesului de producie.

Responsabilii i Managerii de proiect induc o linie bine trasat n scopul urmririi exacte a
procesului de producie.
nelegerea importanei calitii n procesul de producie, calitate care poate fi obinut doar n
urma unei testri profesionale.
Impunerea unor reguli i standarte care n timp vor duce la livrarea unor produse de cea mai nalt
calitate, i a unor soluii de cea mai nalt calitate pentru clienii organizaiei.

1.1.

Definiia erorii software

Unele dintre cele mai scandaloase erori software

1. Aparat medical pentru terapie cu radiaie Therac-25
- 6 accidente cu mori i rni grave (1985-87, SUA, Canada)
Cauza direct: erori in programul de control
Analiz retrospectiv [Leveson 1995]:
ncredere excesiv n software (n analiza produsului)

 fiabilitate siguran
2. Racheta Ariane 5
- Autodistrugere dup o defeciune la 40 s de la lansare (1996)
Cauza: conversia 64-bit float 16-bit int genereaz o excepie de depire netratat n programul
ADA
Cost: 500 milioane dolari (racheta), 7 miliarde dolari (proiectul)
Analiz retrospectiv
principala cauz: reutilizarea nejudicioasa de software
cod preluat de la Ariane 4, fr reanalizare corespunztoare:
3. Eroarea din procesorul Intel Pentium
Eroare n unitatea de mprire cu virgula mobila, 1994
Cost: cca. 400 milioane dolari
Analiz ulterioar
Circuitul putea fi verificat formal
- demonstrare automat de teoreme [Clarke, German & Zhao]
- cu structuri speciale de date pentru reprezentarea nmulirii/mpririi [Bryant & Chen]
Accentul a fost pus pe componente mai complexe (unitatea de execuie, coerena memoriei
cache)
Eroarea software
Din exemplele de mai sus se poate vedea impactul erorilor software asupra noastr. Erorile pot fi
catastrofice, cnd provoac pierderi de viei omeneti sau pot fi nite inconveniene dac este vorba de
exemplu de un joc pe calculator. Majoritatea erorilor sunt mult mai complicate dect par la prima vedere.
Sunt ns i erori simple, subtile despre care nu se poate cu siguran de spus, dac este o eroare adevrat
sau nu.
Un testor bun trebuie s poat folosi diferii termeni pentru a descrie ce s-a ntmplat cnd a euat
softul. n continuare este dat o list cu termenii folosii:
1.
Defect (Defect)
2.
Excepie (Variance)
3.
Eec (Failure)
4.
Problem (Problem)
5.
Eroare (Error)
6.
Incident (Incident)
7.
Anomalie (Anomaly)
8.
Inconsisten (Inconsistency)
9.
Aparen (Feature)
10.
Neajuns (Fault)
11.
Bug
Care dintre aceti termeni vor fi folosii pentru descrierea erorilor ine doar de cultura companiei i de
stadiul la care a fost descoperit eroarea. Dac ne uitm n dicionar, observm c toate aceste cuvinte se
deosebesc foarte puin, unele fiind chiar sinonime.
De obicei orice eroare software este numit bug, ns acest termen nu poate fi acceptat cnd se
completeaz diferite rapoarte despre testarea softului. n cadrul acestui curs vom folosi termenul: eroare
software.
nainte de a formula definiia erorii software avem nevoie de un termen de reper: specificaia
produsului software.
Specificaia produsului este un acord al echipei de dezvoltare software, n care este definit: cum ar
trebui el s fie, cum este ntr-adevr, ce trebuie s fac i ce nu trebuie s fac acest produs.
Definiie. Erorile software apar cnd una sau mai multe dintre urmtoarele afirmaii sunt adevrate:
1.
2.
3.
4.
5.

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

Softul execut ceva ce specificaiile spun c nu trebuie s execute.
Softul execut ceva ce n specificaii nu este menionat.
Softul nu execut ceva ce specificaiile nu menioneaz dar ar trebui s menioneze.
Softul este greu de neles, greu de folosit, lent sau se vede c nu a fost proiectat corect.

Aceast definiie a erorilor acoper o mare parte de probleme, de acea testorii folosesc aceste reguli
pentru a identifica diferite tipuri de probleme n aplicaiile software.

1.2.

Cauzele apariiei erorilor.

Poate fi surprinztor, dar cel mai mic procent de erori sunt cele provenite de programare. Cele mai
multe erori sunt cauzate de deficienele din specificaie ( 60%), uneori specificaia pur i simplu nu este
scris. Alte motive specificaia nu este descris n detaliu, a fost modificat constant i nu a fost adus la
cunotina ntregii echipe de dezvoltare. Alt surs de erori este etapa de proiectare ( 30%), cauzele
apariiei erorilor aici sunt similare cu cele din specificaii ( modificri, comunicarea rea etc.). Relativ
puine (uneori sub 15%) sunt erorile directe de programare. Ele pot aprea din cauza complexitii
softului, a documentaiei insuficiente (n special n codul care a fost modificat), a timpului insuficient
planificat pentru programare sau a erorilor de proiectare. Uneori programatorii nu neleg corect cerinele,
sau cerinele nu sunt formulate bine.

1.3.

Costul erorilor.

Erorile depistate i fixate in faza de scriere a specificaiilor nu cost practic nimic, cele care nu au
fost depistate nainte de faza implementrii i testrii pot ajunge la sute de dolari. Dac ns clientul a gsit
defecte dup livrarea i lansarea produsului, costul erorilor poate crete de la mii la milioane de dolari.
Deci costul erorilor poate crete exponenial avansnd n procesul de producie de la specificare pn
dup livrare.

1.4.

Rolul i scopurile testerului n procesul de dezvoltare software.

Definiia 1. Scopul testorului este de a depista erorile softului.

Se poate rula programul i confirma c el funcioneaz, fr a pune accentul pe detectarea erorilor. Dac se
testeaz doar componentele funcionale, pot fi omise multe erori. n cazul n care nu au fost depistate
erorile la timp clientul risc s piard muli bani. Deci testorul nu trebuie s se concentreze doar pe
detectarea erorilor, el trebuie s se gndeasc cum s fac acest lucru ct mai curnd posibil.
De aici avem:
Definiia 2. Scopul testorului este de a depista erorile softului ct mai devreme posibil.
Dar nici aceasta nu este suficient. Testorul este ochiul clientului, primul care ncearc produsul i el
dorete calitate.
Deci:
Definiia 3. Scopul testorului este de a depista erorile softului ct mai devreme posibil i se asigur c ele
au fost fixate i luate msuri n legtur cu aceasta.
Aceast definiie final este foarte important. La fel este important faptul c fixarea defectelor nu implic
neaprat corectarea softului. n legtur cu aceasta poate fi adugat un comentariu n manualul
utilizatorului sau poate fi fcut un seminar special cu utilizatorii.
Calitile unui testor bun
Cum am menionat mai sus testarea software este o profesie tehnic. Testorii trebuie implicai n
procesul de dezvoltare software nc din fazele incipiente, pentru a asigura calitatea bun a produsului
soft. Pentru a fi angajat i preuit un testor trebuie s posede urmtoarele caliti:
1. Trebuie s fie un explorator. Testorul software este cel care experimenteaz cu soft-uri noi
ncercndu-le funcionalitile.
2. Trebuie s fie nenduplecai. Testorul software este mereu n cutare. El caut erori prin toate
cile posibile.
3. Trebuie s fie creativ. Testarea superficial nu este suficient pentru testor. El trebuie s gndeasc
creativ i s intuiasc unde poate gsi erori.
4. Trebuie s fie perfecionist. Testorii tind spre perfeciune, cu toate c neleg c n industria
software ea este de neatins.
5. Trebuie s posede o bun judecat. Ei trebuie s decid ce trebuie de testat, ct timp i dac o
oarecare problem este ntr-adevr o eroare sau nu.
6. Trebuie s aib tact i s fie bun diplomat. El este cel care aduce vetile rele programatorului.
7. Trebuie s fie perseverent. Erorile gsite nu totdeauna sunt vizibile i uneori sunt greu de descris.
Testorul trebuie s-i poat expune punctul de vedere i s poat demonstra necesitatea fixrii i
posibil corectrii erorilor gsite.

Un testor nu trebuie s fie numaidect un programator, cunotinele din diferite domenii (economie,
nvmnt, aviaie, medicin, culinrie, construcii ) pentru care sunt dezvoltate produse software vor
fi de un imens ajutor pentru un testor.

1.5.

Termeni i definiii ale testrii

Psihologia testrii
Testarea software este o disciplin tehnic, ns ea implic importante consideraii economice i
psihologice.
Ideal ar fi testarea tuturor combinaiilor posibile ale intrrilor i ieirilor programului. n cele mai
multe cazuri ns aceasta este imposibil, deoarece chiar i un program simplu poate avea sute i chiar mii
de combinaii ale intrrilor i ieirilor. Crearea cazurilor de test pentru toate aceste combinaii este destul
de nepractic, pentru aceasta este nevoie de resurse umane i financiare enorme, mai mult ca att procesul
poate dura timp ndelungat. Plus la aceasta mai trebuie de luat n consideraie i viziunea testorului fa de
crearea unui test de succes. Atitudinea testorului fa de produs este de asemenea foarte important.
Pentru ca procesul de testare s nu se transforme ntr-o goan haotic dup erori este benefic de respectat
unele principii ale testrii pe care le-a artat practica testrii i timpul i de cunoscut nite tehnici de
testare, pentru a sistematiza acest proces.
Definiii ale testrii
O cauz important a calitii proaste a produselor soft este definirea incorect a procesului de
testare. De exemplu se spune c:
1. Testarea e procesul de a demonstra c programul nu are erori (or acest lucru este imposibil
folosind doar testarea)
sau
2. Scopul testrii este de a arta c produsul este performant i funcioneaz corect
sau
3. Testarea este procesul prin care se demonstreaz c produsul face ceea ce trebuie s fac
Aceste definiii nu sunt rele doar c sunt cam pe dos. Este cunoscut c aciunea de testare a unui
program se deosebete de celelalte faze prin care acesta trece (specificare, proiectare, programare) prin
caracterul su n aparen "demolator". ntr-adevr, n timp ce alte faze au o esen constructiv, testarea
are n aparen un caracter mai degrab distructiv, deoarece scopul acestei aciuni este de a pune n
eviden proasta funcionare a produsului obinut. Din punct de vedere psihologic programatorul trebuie s
adopte n aceasta etap o atitudine "dumnoas" fa de creaia sa i s-i expun defectele.
Esena procesului este fr ndoial tot constructiv, scopul su fiind de a pune n operare real un produs
la parametrii prevzui.
Deci cele mai adecvate definiii ale testrii ar fi:
1. Testarea e procesul prin care se execut un program cu intenia de a gsi erori (Myers) sau mai
mult ca att:
2. Testarea este utilizata pentru a semnala prezena defectelor unui program, fr a garanta absena
lor( Dijkstra).
3Un test de succes (test concludent) e acela care descoper (i localizeaz) o eroare.
Principii ale testrii (Myers)
Continund ideea acestei teme observm c cea mai important problem n testare este cea
psihologic. Reieind din aceasta pot fi formulate nite principii ale testrii.
Principiul 1: Un caz de test trebuie sa defineasc neaprat ieirea sau rezultatul dorit.
Formularea acestui principiu este bazat pe psihologia uman. Dac rezultatul corect nu este
predefinit , ansa c orice rezultat va fi interpretat ca corect este destul de mare. Avem aici fenomenul
Vedem ceea ce dorim s vedem. Cu alte cuvinte noi subcontient ateptm rezultatul corect. O cale de
combatere a acestui fenomen este ncurajarea examinrii detaliate a tuturor ieirilor. Conform acestui
principiu un caz de test trebuie s fie compus din:
1. Descrierea instanei unui program.
2. Descrierea precis a rezultatului sau a ieirii programului pentru aceast instan.
Principiul 2: Un programator ar trebui s evite i s testeze propriul program.

Orice scriitor cunoate, sau cel puin trebuie s cunoasc, c este o idee nu prea bun s-i corecteze i
s-i redacteze singur manuscrisele. Iari este vorba de un fenomen psihologic. Autorul nu dorete s
descopere erori n propria lucrare. Dup ce programatorul a lucrat constructiv la designul i scrierea
programului este foarte dificil s ia o atitudine distructiv fa de propria oper. Plus la aceasta
programatorul subcontient nu dorete s gseasc erori de teama criticii din partea clientului sau
beneficiarului. n afar de aceast problem psihologic mai este una important: Programul poate avea
erori din cauza nenelegerii de ctre programator a sarcinii puse sau a specificaiei produsului. Astfel
programatorul va transmite aceleai nenelegeri i testelor executate. Aceasta nu nseamn c
programatorul nu trebuie sub nici o form s-i testeze propriul program, ns testarea de ctre o alt
persoan va fi mai eficient. Acest principiu nu poate fi aplicat i depanrii. Acest proces este mai bine
efectuat de ctre programatorul care a codificat programul.
Principiul 3: Companiile de programare nu ar trebui s-i testeze produsele proprii.
Argumentele acestui principiu sunt similare cu cele de la principiul precedent. Aici pot avea loc
probleme de planificare: produsul trebuie livrat la timp, orice ntrziere cost bani. Este destul de dificil ca
o companie s fie obiectiv fa de calitatea propriului produs. Grupul de testori ar trebui s fie altul dect
cel de dezvoltare, iar ntreinerea unui departament de testare este destul de costisitoare i nu orice
companie poate s-i permit aceasta.
Principiul 4: Fiecare rezultat al testului trebuie examinat foarte minuios.
Acesta este probabil cel mai evident principiu. Ct de minuios nu ar fi fcut testarea este posibil s
se strecoare diferite erori. Erorile depistate ntr-un stagiu tardiv de testare deseori se dovedesc a fi cele
omise n stadii incipiente de testare.
Principiul 5: Cazurile de test trebuie s fie scrise att pentru condiii de intrare valide ct i pentru
cele invalide i neateptate.
Este normal tendina de testare a produsul pentru date valide de intrare, neglijnd datele incorecte.
Este ns forte important comportamentul produsului cnd sunt introduse date incorecte sau ilegale. Acest
principiu nu poate fi neglijat atunci cnd sunt elaborate cazurile de test.
Principiul 6: Trebuie testat c produsul face ce trebuie i nu face ce nu trebuie.
Putem considera acest principiu ca un corolar al principiului precedent. Programele trebuie supuse i
examinate pentru efecte neateptate. Mai ales astfel de teste trebuie elaborate pentru produsele cu
destinaie financiar.
Principiul 7: Trebuie de pstrat i refolosit cazurile de test.
Acest principiu este important i este respectat de specialitii n testare. Orice produs poate fi
mbuntit i dac dorim s vedem dac schimbrile nu au avut un efect negativ asupra altor componente
ale sistemului atunci este bine de a testa cu testele vechi noul produs. Astfel se testeaz integritatea i
funcionalitatea produsului. Refolosirea cazurilor de test este binevenit i atunci cnd au fost corectate
unele erori deja gsite. Pstrarea testelor i refolosirea lor dup modificri n produs poart denumirea de
testare regresiv (regression testing).
Principiul 8: Nu se planific procesul de testare presupunnd c nu vor fi gsite erori.
Este o greeal a managerilor de proiect cnd se folosete o definiie incorect a testrii. De exemplu:
Testarea e procesul prin care se demonstreaz c produsul este performant i funcioneaz corect n
locul Testarea e procesul prin care se execut un program cu intenia de a gsi erori
Principiul 9: Probabilitatea de a gsi erori ntr-un fragment de cod este proporional cu numrul de
erori deja gsite.
Dac avem de exemplu un program din dou module A i B i n modulul A au fost gsite cinci erori
iar n B numai una, i dac modulul A nu a fost supus intenionat unui test riguros, atunci acest principiu
ne spune c probabilitatea c n modulul A vor fi gsite mai multe erori dect n modulul B este destul de
mare. La prima vedere acest principiu nu are prea mult sens, ns este un fenomen prezent n majoritatea
programelor.
Principiul 10:Testarea este un lucru extrem de creativ i intelectual.
Este probabil adevrat c creativitatea cerut la testarea produselor serioase depete creativitatea
cerut n proiectarea acestora. Este clar c este imposibil de testat un produs suficient pentru a demonstra

absena erorilor n acest produs. Metodologia pe care o vom studia n cadrul cursului va fi de un mare
folos la elaborarea unui numr rezonabil de cazuri de test, ns aceast metodologie cere un nivel nalt de
creativitate a testorului.

1.6.

Axiomele testrii.

Axiomele testrii (Patton)

1. Este imposibil testarea complet a unui program.
Aceast axiom este adevrat din urmtoarele motive:
Numrul intrrilor posibile este foarte mare.
Numrul rezultatelor posibile este foarte mare.
Numrul drumurilor ntr-un program este foarte mare.
Specificaiile programului sunt subiective.
Exemplul calculatorului
2. Testarea software este un exerciiu de apreciere a riscurilor.
Dac ai luat decizia s nu testezi toate scenariile de test posibile, atunci i-ai asumat un oarecare risc.
De exemplu, dac ai decis s nu testezi n calculator cazul 1024+1024=2048, iar programatorul accidental
a greit aceast combinaie, nimerind acest produs la consumator, care este un contabil i a gsit aceast
eroare, ce se va ntmpla n aa caz? Aceast eroare va costa foarte mult. Sun destul de urt aceasta, dar
pe de alt parte este imposibil de testat tot, dar dac nu se testeaz totul este posibil s se strecoare diferite
erori. Ce se poate de fcut n astfel de cazuri? Un element important este c testorul trebuie s nvee cum
se poate reduce domeniul imens a datelor de intrare pn la nite seturi realizabile de teste i cum s ia
decizii ce este important de testat i ce nu este.
3. Testarea nu poate arta c produsul nu are erori.
Testarea poate arta c erorile exist ntr-un produs, dar nu poate arta c ele nu sunt n el. Pot fi
perfecionate testele, pot fi gsite i raportate erorile, dar nu este posibil de garantat c erori n produs nu
se vor mai gsi. Unicul lucru care se poate de fcut este de a continua testarea i posibil se vor mai gsi
erori.
4. Cu ct mai multe erori gseti, cu att mai multe sunt.
Erorile au tendina de a se gsi n grupuri. Dac ai gsit una, poi fi sigur c n vecintatea ei vor mai
fi i altele. Deseori, trece destul de mult timp pn cnd testerul gsete o eroare. ns dac a fost gsit
una el o va gsi i pe a doua i pe a treia etc. Exist motive serioase pentru aceasta:
Programatorul a avut o zi grea. Codul scris ntr-o zi poate fi perfect, iar unul scris n alt zi
poate avea o sumedenie de erori. O eroare gsit ne poate spune c mai sunt i altele prin
zon.
Programatorii foarte des fac aceleai erori. Un programator care a fcut aceiai greeal de mai
multe ori o va repeta iar i iar.
Fiecare eroare este ca un aisberg. Deseori proiectul i arhitectura software au probleme
serioase. Testerul ar trebui s le depisteze pe acestea n primul rnd, dar de obicei ele sunt
detectate dup ce au provocat multe probleme serioase.
5. Paradoxul pesticidelor: erorile devin rezistente la teste
Paradoxul pesticidelor n testare descrie fenomenul: cu ct mai mult testezi cu att mai imun fa de
teste devine softul. Analogic cu insectele i pesticidele: dac sunt aplicate aceleai pesticide de fiecare dat
insectele devin imune la ele i chiar mai puternice dect au fost. Pentru a gsi erori noi e nevoie de teste
noi.
6. Nu toate erorile gsite vor fi corectate.
O realitate trist atestrii este, c dup ce s-a lucrat destul de mult i greu pentru a depista erorile, nu
toate din ele sunt fixate i corectate. efii echipelor de testare trebuie s fac compromisuri i s ia decizii
bazate pe riscuri n ceea ce privete fixarea anumitor erori.
Acest lucru are motive serioase:
Nu este suficient timp pentru aceasta.
ntr-adevr nu este o eroare.
Este prea riscant de fixat( fixarea ei poate provoca mai multe erori).

 Nu are nici o valoare.

Procesul de luare a deciziilor fa de fixarea erorilor i implic pe testori, managerii de proiect i pe
programatori i fiecare are opinia lui fa de eroarea respectiv ns nimeni nu tie cine are dreptate, aa c
decizia luat este bazat pe anumite riscuri (exemplu Procesorul Intel Pentium)
7. E greu de spus cnd o eroare e o eroare ...
n afar de acele afirmaii care alctuiesc definiia erorii testorii pot apela i la opinia altor persoane
poate chiar a clientului, ce reprezint pentru el o eroare i i poate formula propria definiie a erorii.
8. Specificaiile produselor nu sunt niciodat definitive.
Industria software se dezvolt foarte rapid. n acelai timp produsele soft devin tot mai complexe, iar
termenii de predare mai scurte din cauza concurenei. Aceste dou aspecte sunt n conflict permanent i
rezultatul conflictului este schimbarea constant a specificaiilor. Un alt motiv este perfecionarea unui
produs care a fost scos pe pia cu ceva timp n urm specificaiile au fost rescrise, dar nu conin i
funcionalitile vechi ale produsului.
9. Testorii nu sunt cei mai populari membri ai echipei de proiect.
Ne amintim de scopul unui testor. Cteva sfaturi utile pentru testori:
Gsii erorile ct mai devreme. Toi vor fi mulumii dac o s gsii erorile serioase cu dou
luni, dar nu cu o zi nainte de sfritul perioadei de testare.
Temperai-v entuziasmul. Ct de bucuros nu ai fi c ai gsit o eroare critic, fii diplomat cnd
i-o spui programatorului.