Sunteți pe pagina 1din 19

TEHNICI DE TESTARE

SOFTWARE

Banu
Alexandru

Grupa 441A
Cuprins
Definitie Testare
Software1
Generalitati
1
Istoric
.2
Subiectele Testrii Software..4
Testarea etap a ciclului de dezvoltare
software........................................5
Etapa de analiz continua.Procesul de stabilire a
cerinelor6
Verificarea de birou
.7
Inspeciile codului
7
Parcurgerile
7
Testarea dinamic
7
Testarea de
Module7
Testarea
incremental
8

Testarea de integrare
..8
Fazele procesului de testare software...
..8
Planificarea
testelor..8
Analiza
testelor
.8
Faza de proiectare a
testelor...8
Faza de implementare a
testelor..9
Testarea
structural
10
Testarea funcional..
.11
Testarea software orientat
obiect11
Testarea sistemelor distribuite bazate pe
component12
Bibliografie
14

Testarea Software
Reprezint o investigaie empiric realizat cu scopul de a oferi prilor interesate informaia
vizavi de calitatea produsului sau serviciului supus testrii, lund n consideraie contextul
operaional n care acesta din urma va fi folosit. Testarea Software pune la dispoziie o viziune
obiectiv i independent asupra produsului n dezvoltare, oferind astfel businessului
posibilitatea de a nelege i evalua riscurile asociate cu implementarea produsului soft. Tehnicile
de testare includ, dar nu sunt limitate la, procesul de execuie a programului sau aplicaiei n
scopul identificrii defectelor/erorilor de software. Testarea Software mai poate fi definit ca un
proces de validare i verificare a faptului c un program/aplicaie/produs software (1) corespunde

business cerinelor i cerinelor tehnice care au ghidat proiectarea i implementarea lui; i (2)
ruleaz i se comport corespunztor ateptrilor.
n dependen de metodologia de testare aleasa, Testare Software poate fi implementat la orice
etap n cadrul procesului de dezvoltare, dei partea considerabil a efortului de testare deobicei
este aplicat la etapa de dup cizelarea/formalizarea cerinelor i finisarea implementrii/codrii
propriu-zise.

Generaliti
Nu exist un astfel de proces de testare ce ar permite identificarea tuturor defectelor posibile ce
le poate conine un produs software. n schimb, un astfel de proces poate furniza o viziune critic
sau comparativ, care vine sa contrapun unele aspecte ale produsului (cum ar fi: starea i
comportamentul actual) i metricile i constrngerile care servesc drept criterii de acceptan.
Aceste criterii pot fi derivate din specificaii tehnice, produse asemntoare comparabile,
versiuni anterioare ale aceluiai produs, ateptari fa de produs enunate de ctre utilizator sau
client, standarde relevante, legi n vigoare, etc.
Fiecare produs software are o audien caracteristic. De exemplu, audiena pentru un produs din
industria jocurilor video este complet diferit de audiena unui produs din sistemul financiarbancar. De aceea, cnd o organizaie dezvolt sau investete n dezvoltarea unui produs software,
ea trebuie s fie capabil s evalueze acceptabilitatea produsului din perspectiva utilizatorilor
finali, audienei int, cumprtorilor i altor pri interesate. Testarea Software este procesul
care vine sa fac aceast evaluare posibil ntr-un mod ct mai obiectiv.
Un studiu efectuat n anul 2002 de ctre NIST a artat c pierderile anuale pentru economia
S.U.A. cauzate de defecte de software se estimeaz la 59.5 miliarde de dolari. Mai mult de o
treime din aceste pierderi ar putea fi evitate dac s-ar face investiii mai serioase n
implementarea procesului de testare.

Istoric
Gelperin i Hetzel au analizat evoluia conceptului de testare a unui sistem informatic i au
mprit evoluia acestuia n mai multe etape, n funcie de filozofia care a stat la baza
conceptului:

1945 - 1956 - Orientarea spre depanare

Testarea programelor informatice este o activitate care a aprut o dat cu procesul de dezvoltare a
acestora. n perioada apariiei primelor sisteme informatice - 1945-1956, procesul de testare era
n special orientat ctre componentele hardware ale sistemului, iar defectele din software erau n
general considerate ca fiind mai puin importante. Persoanele care elaborau codul se ocupau i de
partea de testare, dei nu o fceau ntr-o manier metodic, i denumeau aceast activitate
verificare. Pentru muli dintre oamenii de tiin care se ocupau de scrierea programelor
informatice nu exista o distincie clar ntre activitile de scriere a codului, testare i depanare.
Din aceast perioad timpurie dateaz prima referire la conceptul de "bug" ntr-un sistem
informatic, cnd un operator al unui calculator descoper pe un circuit electronic care funciona
defectuos o molie, i o ataeaz n jurnalul de operaiuni, cu meniunea ca a descoperit primul
"bug" propriu-zis ntr-un calculator. Termenul de "bug" n sine este mai vechi, datnd din
perioada lui Thomas Edison. Primul savant 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.

1957 - 1978 - Orientarea spre demonstraie

Pe msur ce sistemele informatice creteau n numr, complexitate i cost, procesul de testare a


cptat o importan tot mai mare. 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.

1979 - 1982 - Orientare spre defectare

Conceptele de depanare i testare devin mai riguros separate o dat cu publicarea de ctre
Glenford J. Myers a lucrrii The Art of Software Testing, n 1979. 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. De asemenea, 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

n 1983, Biroul Naional de Standarde din Statele Unite ale Americii public un set de practici
adresate activitilor de verificare, validare i testare a programelor de calculator. Aceast
metodologie, adresat n mod specific instituiilor americane federale, cuprinde metode de
analiz, evaluare i testare care s fie aplicate de-a lungul ciclului de via al aplicaiei. Ghidul de
bune practici sugereaz alegerea unor diverse metode de verificare i validare, n funcie de
caracteristicile fiecrui proiect n scopul creterii calitii generale a produsului. n anii '70
nivelul de profesionalism al persoanelor implicate n activitatea de testare a crescut simitor. Apar
posturile dedicate de tester, manager de teste sau analist de teste. Apar de asemenea organizaii
profesionale ale celor care activeaz n domeniul testrii software, precum i publicaii
specializate, cri i articole de specialitate. Mai important, 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

Standardele precedente sunt dezvoltate i mbuntite ncepnd cu 1987 cnd IEEE public o
metodologie comprehensiv care se aplic n toate fazele ciclului de via a programului.
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.

Metodologii moderne
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 activiti care in
de dezvoltarea programelor informatice: planificare, proiectare, programare, evaluare i control.

Subiectele Testrii Software


Scopul
Scopul primordial pentru procesul de testare este (1) identificarea erorilor de software, (2)
izolarea i fixarea/corectarea defectelor care au cauzat aceste erori. Deseori este un exerciiu non-

trivial, 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.

Defecte i euri
Nu toate defectele software sunt cauzate de greeli n cod. O surs rspndit de defecte
costisitoare sunt lacunele i neclaritile la nivel de cerine, de exemplu, cerinele "ascunse" sau
incomplete pot s rezulte ntr-un set de erori introduse nc n faza de proiectare de ctre
designerul programului. Cerinele non-funcionale precum ar fi testabilitatea, scalabilitatea,
mentenabilitatea, usabilitatea, performana i securitatea, sunt o surs raspndit de astfel de
erori.
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. Nu toate defectele pot duce la euarea
programului. De exemplu, defectele ce se conin ntr-o seciune de cod "mort" niciodat nu vor
duce la euarea programului. Defectele se pot manifesta ca euri la schimbarea mprejurimii n
care ruleaz programul. Exemplele de astfel de modificri includ: trecerea pe o platform
hardware nou, alterri n sursa de date sau interaciunea cu software diferit.[10] Un singur defect
poate rezulta ntr-un spectru larg de simptome prin care se manifest cderile.

Compatibilitatea
Deseori aplicaiile software cad din cauza problemelor de compatibilititate cauzate att de
interaciunea lor cu alte aplicaii sau sisteme de operare, ct i de non-conformitile ce apar de la
o versiune a programului la alta ntr-un proces inceremental de dezvoltare a produsului.
Incompatibilitile ce apar ntre versiuni se datoreaz faptului ca la momentul scrierii codului
programatorul a considerat, sau a testat, produsul doar pentru un singur sistem de operare (sau un
set restrns de sisteme de operare), far a lua n calcul problemele ce pot aprea la schimbarea
contextului de execuie. Un rezultat nedorit al acestui fapt poate fi urmtorul: ultima versiune a
programului poate s nu mai fie compatibil cu acea combinaie de software/hardware folosit
mai devreme, sau poate s nu mai fie compatibil cu un careva alt sistem, compatibilitatea cu
care este critic de important. Deci, testarea de compatibilitate este o "strategie orientat spre
prevenire", fapt ce clar o asociaz cu ultima din fazele de testare propuse de Dave Gelperin i
William C. Hetzel

Combinri de date de intrare i precondiii


O problema fundamental a testrii software a fost i rmne imposibilitatea de a testa un produs
utilznd toate combinaiile posibile de date de intrare i precondiii (starea iniial). Aceasta este
adevrat chiar i n cazul produselor simple.

Testarea etap a ciclului de dezvoltare software


Proiectarea aplicaiilor software de dimensiuni mari, dezvoltat n cadrul unei
echipe, nu se face trecnd direct la implementarea programului, ci urmeaz
etape bine stabilite. Procesul de dezvoltare al aplicaiilor software este alctuit
din urmtoarele etape: specificarea cerinelor, analiz, proiectare,
implementare, testare i ntreinere. n figura este prezentat grafic modelul
clasic de dezvoltare software [PETE00].

n etapa de specificare a cerinelor se determin necesitile pentru toate


elementele sistemului, att hardware ct i software. Cerinele privind
aplicaia e-DSI au fost analizate mpreun cu beneficiarul. Pornind de la
cerina unei aplicaii accesibile ntr-o manier simpl, s-au stabilit variantele
posibile de realizare i cerinele globale. S-a convenit cu privire la detaliile
validrii sistemului de ctre beneficiar. Testarea specificaiilor se realizeaz
prin metode de analiz static: inspecii, parcurgeri i analize tehnice.

Etapa de analiz continua.Procesul de stabilire a


cerinelor
Analistul trebuie s neleag domeniul informaiilor pentru software,
funciile necesare, performanele i interfeele. Se documenteaz cerinele,
iar acestea sunt revzute mpreun cu beneficiarul. n aceast etap este
descris ceea ce trebuie s fac aplicaia informatic i nu modul n care se
realizeaz. Sunt descrise cazurile de test pentru fiecare component n parte.
n etapa de proiectare accentul se pune pe structurile de date, arhitectura
sistemului, detaliile procedurale i cara etap sunt identificate structurile de
date, interfeele, modulele i sunt descrii algoritmii. Pentru fiecare modul n
parte sunt definite specificaiile de realizare. Pentru aplicaia e-DSI s-a stabilit
structura fiecrei aplicaii componente, arhitectura de baz, tabele din baza
de date, modalitile de regsire i actualizare a datelor. Cazurile de test sunt
rafinate i sunt adugate.Se arat c peste 35% din erorile software i au
originea n fazele de analiz i proiectare. Prin implementare se face trecerea
de la proiect la o form specific mainii de calcul. Implementarea este cu
att mai uor de realizat cu ct proiectarea se realizeaz mai n detaliu.
Se compar rezultatele efective obinute dup rularea programului cu seturi
de date de test cu rezultatele scontate pe baza specificaiilor.
ntreinerea aplicaiilor software se aplic tuturor fazelor ciclului de via.
n cadrul ciclului de dezvoltare software, un rol important l au verificarea i
validarea (V & V). Verificarea i validarea reprezint un proces prin care se
determin dac cerinele unui sistem sau component sunt complete i
corecte, dac rezultatul fiecrei faze de dezvoltare ndeplinete cerinele sau
condiiile impuse n faza anterioar i dac sistemul sau componenta final
este n concordan cu cerinele specificate [PRES00].
Verificarea de birou este o tehnic de analiz static n care listingurile
codurilor sau rezultatele testelor sau alte documente sunt examinate vizual,
de obicei de persoana care le-a realizat, pentru a identifica erorile sau
abaterile de la standardele de dezvoltare sau alte probleme.Se
implementeaz corect o anumit funcie. Testarea software este o
component a procesului de V & V. Validarea este mulimea activitilor care
asigur c o aplicaie software realizat este n concordan cu cerinele
beneficiarului. Pe msura dezvoltrii incrementale a aplicaiei e-DSI
rezultatele din fazele intermediare sunt validate de ctre beneficiar. Testarea
sau analiza static are ca scop examinarea aplicaiilor software fr a fi
executate i cuprinde activiti precum inspeciile. Aceste activiti fac parte
din categoria evalurile tehnice [MYER79].
Inspeciile codului presupun citirea sau inspecia vizual a codului surs de
ctre un grup de persoane. Avnd la dispoziie codul su
aiile de proiectare, grupul de persoane din echipa de inspecie urmrete
explicaiile programatorului legate de logica programului, instruciune cu

instruciune. n acest mod se descoper o serie de erori specifice acestei


metode cum ar fi: declararea datelor, referirea datelor, erorile de calcul,
erorile de comparare, erorile de logic, erorile de intrare/ieire, erorile de
interfa etc.
Parcurgerile constau n citirea sau inspecia vizual a codului surs de ctre
un grup de persoane, ns procedura de lucru este diferit avnd ca scop
execuia logic a fiecrei secvene de cod de testat pe baza unor seturi de
test pregtite anterior. Prin urmrirea programului pas cu pas sunt
identificate erori care apar la acest nivel. Rezultatele acestei activiti de
verificare depind, ca i n cazul inspeciilor.
Testarea dinamic presupune examinarea aplicaiilor software n scopul
generrii datelor de test cu care acestea vor fi executate i rularea
aplicaiilor cu seturile de date de test obinute. Se observ c spre deosebire
de testarea static, testarea dinamic presupune execuia aplicaiei care se
testeaz. Exist dou strategii de dezvoltare a cazurilor de test: o strategie
bazat pe structura programelor i o alta, bazat pe funcionalitatea
acestora.
n dezvoltarea unui produs software testarea se realizeaz pe mai multe
niveluri: testarea de module, testarea de integrare, testarea de sistem i
testarea de acceptare (validare). n figura 2.2 este prezentat procesul de
verificare i validare n cadrul ciclului de dezvoltare a unui produs software
[TEST90]. Se identific etapele de realizare a aplicaiei precum i etapele i
nivelurile procesului de testare software.

n cadrul testrii de module se realizeaz verificarea celor mai mici uniti


software care pot fi compilate i link-editate independent. n programarea
clasic un modul este un subprogram (funcie sau procedur). n cadrul
programelor orientate obiect, cea mai mic unitate testabil este clasa.
Testarea de module se concentreaz asupra verificrii interfeelor modulelor,
structurilor de date locale, condiiilor de la limite, cilor independente i
cilor de tratare a erorilor. [PRES00]
Deoarece modulele nu sunt programe de sine stttoare, este necesar s se
construiasc programe sau funcii care s ajute la testarea de module. O
prim categorie o reprezint programele conductoare (drivers) care
apeleaz modulele supuse testrii cu datele de test construite.
Testarea incremental presupune construirea structurii programului pas cu
pas i testarea ansamblului obinut.
O alt categorie este reprezentat de funciile sau procedurile apelate de
ctre modulul de testat. Acestea sunt substituite cu subprograme care au
acelai prototip, ns cu funcionalitate redus la minim. Modulele vide sunt
funcii sau proceduri simple care nu fac nimic n afara returnrii controlului,
sau sunt funcii sau proceduri complexe, care simuleaz efectul apelrii

modulelor reale. n cele mai multe cazuri, modulele vide simple sunt
nepotrivite.
Testarea de integrare este o tehnic sistematic de construire a structurii
programului prin gruparea componentelor n paralel cu testarea aspectelor
legate de interfaa 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.
Metoda de testare ascendent (bottom-up testing) presupune testarea mai
nti a modulelor de pe cel mai de jos nivel al ierarhiei programului, apoi se
continu n sus. Programele de pe nivelul de sus, care de obicei sunt critice,
sunt testate ultimele. n timp sunt descoperite erori care pot influena multe
module care au fost deja testate. Dup corecia erorilor este necesar ca toate
modulele de pe nivelurile de jos s fie testate regresiv.

n figura este prezentat un exemplu de testare de integrare ascendent.

Fazele procesului de testare software


Fazele procesului de testare sunt: planificarea, analiza i proiectarea,
implementarea i execuia i evaluarea testelor.
Planificarea testelor se realizeaz n strns legtur cu planificarea
derulrii proiectului. n faza de planificare a proiectului pentru testare se
aloc resurse, specificndu-se bugetul i perioada de timp n care se va
derula testarea. Pe baza acestora se realizeaz planificarea detaliat a
procesului de testare. Planificarea testrii are scopul de a determina ce s
testeze i ct s testeze, astfel nct procesul de testare s se ncadreze n
limitele resurselor alocate. n urma planificrii testrii rezult planul de test,

un document pe baza cruia se desfoar celelalte faze ale testrii. n


aceast faz se identific i obiectivele testrii. Planul de test este un
document important, fiind utilizat ca baz pentru desfurarea ntregului
proces de testare. n plus, trebuie identificate i sursele de risc n testare.
Planificarea testrii poate s nceap din momentul n care au fost elaborate
cerinele aplicaiei software [PETE00].
n planul de test sunt descrise:
aria de cuprindere;
responsabilitile fiecrui membru al echipei de testare;
resursele umane necesare;
desfurarea n timp a testelor;
descrierea i configurarea mediului specific aplicaiei;
lista echipamentelor care trebuie achiziionate;
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 finalizrii testrii.
Analiza testelor rafineaz metodele prezentate n planul de test. n [DUST99]
sunt prezentate etapele fazelor de analiz i proiectare a testelor.
Astfel, n etapa de analiz se identific urmtorii pai:
identificarea scopurilor, obiectivelor i a strategilor testrii de ctre echipa
de testare;
metodele de verificare sunt asociate cerinelor sistemului sau cazurilor de
utilizare i sunt documentate n cadrul unei matrice de urmrire a cerinelor;
analiza cerinelor testelor;
construirea matricei cerinelor testelor, n care declaraiile cerinelor
testelor sunt asociate cerinelor sistemului sau a cazurilor de utilizare;
asocierea tehnicilor de testare cu declaraiile cerinelor testelor.
n faza de analiz a procesului de testare, un aspect important l ocup
analiza cerinelor pentru testare. Cerinele testrii trebuie s fie identificate
i documentate astfel nct toate persoanele implicate n procesul de testare
s fie contiente de scopul acestuia. Analiza se desfoar din mai multe
puncte de vedere, depinznd de faza de testare. Astfel se identific o
abordare structural i o abordare bazat pe comportament.
Faza de proiectare a testelor urmeaz dup ncheierea analizei. n faza de
proiectare, apar urmtorii pai:
definirea modelului programului de test astfel nct 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 nct fiecare cerin pentru datele de test
s se reflecte pentru fiecare procedur de test.

Programul de test se elaboreaz fie la nivelul proiectrii, fie la nivelul


tehnicilor de testare. n primul caz, procedurile de test sunt asociate
componentelor hardware i software ale aplicaiei, iar n al doilea caz
procedurile de testare sunt vzute la nivelul tehnicilor de testare.
Proiectarea procedurilor de test ncepe dup determinarea cerinelor testrii.
Proiectarea procedurilor de test const n:
analiza arhitecturii de test pentru determinarea tehnicilor de testare
relevante;
definirea procedurilor de test att la nivelul sistemului ct 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.
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 att parametrii de intrare ct i rezultatele ateptate dup execuie
utiliznd acei parametri. Realizarea de cazuri de test ct mai complete duce
la descoperirea unui numr mai mare de erori. Procedurile de test identific
toi paii necesari pentru executarea cazurilor de test specifice.
Primul pas n faza de implementare este iniializarea mediului de
implementare prin punerea la punct a arhitecturii dezvoltrii testelor.
Un alt aspect important este identificarea standardelor pe care se bazeaz
elaborarea secvenelor 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 convenii
de scriere a programelor de test (alinieri, comentarii, prefixe pentru date).
Implementarea secvenelor de test se realizeaz n limbaje specifice mediilor
de testare (asemntoare Visual Basic) sau se utilizeaz limbaje de
programare evoluate (C++, Java).
Prin reutilizare se folosesc proceduri de test din proiectele anterioare sau din
cadrul aceluiai proiect pentru module care au pri comune. n [McGR97c],
[McGR97d] este prezentat o arhitectur paralel de testare a claselor, n
care clasele de test sunt derivate n paralel cu dezvoltarea ierarhiei claselor
care se testeaz.
Faza de rulare a testelor are ca intrri planul de test i orarul execuiei
procedurilor de test, mediul de test fiind pregtit corespunztor. Ieirile fazei
de execuie a testelor sunt rezultatele testelor, leciile nvate i orarul
modificat al testelor. Execuia modulelor se realizeaz n conformitate cu
planul de test. Procedurile de test descriu intrrile i ieirile ateptate dup
execuie.

n aceast etap din cadrul procesului de testare sunt rulate secvenele de


test. Execuia secvenelor de test se realizeaz pe ct posibil n mediul
specific aplicaiei iar dac nu este posibil, acest mediu este simulat.
Rezultatele execuiei secvenelor de test sunt evaluate pentru a determina
dac produsul a trecut testul cu succes. Evaluarea rezultatelor testelor se
face de ctre un oracol. Oracolul este o persoan sau un instrument
automat, care pe baza specificaiilor determin dac rezultatele execuiei
testelor sunt corecte sau nu.
n figura este prezentat fluxul procesului de execuie i evaluare a testelor
pentru testarea la nivel de modul, bazat pe specificaii. Rezultatele testelor
arat dac programul a trecut sau nu testul.

Rezultatele execuiei testelor se vor memora ntr-o baz de date care conine
i alte informaii referitoare la aplicaia software realizat. Execuia i
evaluarea testrii de integrare necesit noi secvene de test pe rul structurii
programului care se testeaz.
. n execuia i evaluarea testrii de sistem, beneficiarul aplicaiei se implic
mai mult dect n celelalte faze. n mod asemntor, acesta trebuie s
semneze raportul de test pentru a considera ncheiat aceast faz de
testare.
Procesul de testare pentru aplicaia e-DSI a urmat aceleai etape, gradul de
aprofundare fiind diferit.

Testarea structural
Testarea structural (white box testing) este o strategie de testare care
necesit accesul la codul surs i la structura programului i pune accentul
pe acoperirea prin teste a cilor, ramificaiilor i fluxurilor programului.
Principalele metode de testare structural au n vedere gradul n care
cazurile de Strategiile de testare bazate pe ci utilizeaz fluxul de control al
programului. Acestea reprezint o familie de tehnici de testare bazate pe
selectarea cu atenie a unei mulimi de ci din program.

Testarea funcional
Testarea funcional (black-box testing) este o strategie de testare care
necesit cunoaterea comportamentului extern al programului pe baza
specificaiilor. Testarea funcional nu necesit cunoaterea structurii interne a
programului sau cunotine despre modul n care este implementat programul
sau modulul.
Principalele tehnici de testare funcional sunt testarea cu intrri
aleatoare, partiionarea pe clase de echivalene, analiza valorilor limit, graful
cauz-efect i ghicirea erorilor.
Testarea cu intrri aleatoare pornete de la domeniul datelor de intrare i
const n generarea de date de test n mod aleator, n cadrul domeniului
acestora. Este o tehnic slab de testare, cu cel mai mic procent de descoperire
a erorilor. Aceast tehnic de testare a fost dezvoltat, astfel nct datele de test
sunt alese aleatoriu din domeniu i sunt filtrate astfel nct s ndeplineasc
anumite condiii, ca de exemplu producerea unui rezultat dintr-o clas de ieiri
posibile.
Partiionarea pe clase de echivalene const n mprirea domeniului
datelor de intrare n subdomenii, astfel nct comportamentul programului s fie
acelai, cel puin teoretic, pentru orice dat de intrare din subdomeniul
corespunztor. De exemplu, pentru funcia care returneaz valoare absolut a
unui numr ntreg, un subdomeniu ar fi intervalul numerelor strict negative, iar
un alt subdomeniu ar fi cel al numerelor pozitive. Dintr-un numr ridicat de
cazuri de test posibile se ajunge la dou cazuri de test.
Caracteristicile partiionrii pe clase de echivalene sunt:
domeniul datelor de intrare este mprit n clase de echivalene;
elementele din aceeai clas sunt tratate n mod asemntor;
de asemenea se are n vedere partiionarea ieirilor;
se consider att clasele valide ct i cele invalide;
pentru testare se alege cel puin un element din fiecare clas de
echivalen.

Testarea software orientat obiect


Programarea orientat obiect presupune definirea de clase i obiecte,
construirea de ierarhii, precum i referirea obiectelor create. n cazul n care
clasele sunt bine definite, reutilizarea genereaz efecte pozitive. Cnd clasele
sunt subdefinite este necesar construirea de clase derivate de completare.
Cnd clasele sunt supradefinite apar restricii de referire i de reutilizare.
Testarea complet a claselor este premisa reutilizrii.

Testarea claselor evideniaz gradul de motenire i de acoperire


probabil a tipologiilor de clase de probleme prin constructori/destructori
definii.
Sistemul orientat obiect este caracterizat printr-un nivel foarte ridicat al
reutilizrii software. De aceea el a ctigat teren n faa metodologiilor clasice,
tocmai datorit acestui aspect al reutilizrii. Dac nu ar fi reutilizarea, tehnologia
orientat obiect ar fi la fel ca celelalte, doar puin mai rapid.
Construirea clasei CosCumparaturi n cadrul aplicaiei e-DSI este echilibrat,
nefiind necesar obinerea de clase derivate. Mai mult, definirea de metode de
tipul get, face ca referirea membrilor s se fac fr utilizarea de parametri:
getNumarProduse();
Numeroase aplicaii complexe se prezint sub forma unor programe apelatoare,
corespunztor limbajului C++ funcia principal main(), care conin secvene
lungi de directive #include iar ca instruciuni executabile, n general structuri
liniare de expresii de definire de obiecte i referire a funciilor membre ale
obiectelor definite [IVAN99].
Testarea software orientat obiect presupune dou planuri:
testarea construciilor proprii;
testarea construciilor incluse pentru reutilizare.
Metodele orientate obiect utilizeaz strategii diferite de ncapsulare fa
de metodele convenionale, acest lucru avnd un dublu impact asupra testrii
software [BERA90]:
cea mai mic unitate testabil nu mai este modulul;
strategia pentru testarea de integrare trebuie modificat.

Testarea sistemelor distribuite bazate pe


component
Cele mai cunoscute tehnologii pentru dezvoltarea sistemelor distribuite bazate
pe componente sunt CORBA, standardizat de Object Management Group,
DCOM(COM+) dezvoltat de Microsoft i RMI dezvoltat de firma Sun. Aceste
tehnologii presupun existena unor componente (denumite server) care, prin
intermediul unor interfee, pun la dispoziie funcii, care sunt apelate de
componente client aflate pe un alt sistem. Transferul n cadrul sistemului
distribuit se realizeaz prin intermediul unui protocol bine definit.

Criterii de clasificare a factorilor ce influenteaza testarea software


Exist numeroase criterii de clasificare a factorilor. Astfel, se identific clasificri
dup modul de aciune a factorilor, dup raportul dintre factori i procesul de
dezvoltare software, dup posibilitatea de cuantificare a acestora.
Factorii cu actiune directa sunt:
- complexitatea produsului software
- tehnicile de dezvoltare utilizate
- stadiul de certificare a firmei
- numrul de utilizatori

Bibliografie
bigfoot.cs.upt.ro
andrei.clubcisco.ro
www.biblioteca-digitala.ase.ro
anale-informatica.tibiscus.ro
www.scribd.com
ieee.org
www.wikipedia.com