Ghid pentru elevi

Testarea produselor program

Echipa de autori:

Gremalschi Anatol

doctor habilitat, profesor universitar, Universitatea Tehnic a

Moldovei coordonator;

Nastasenco Veaceslav

doctor n tehnic, confereniar, ef departament, Allied Testing SRL.

Spnu Valentina,

grad didactic unu, profesor de informatic, Colegiul Financiar Bancar;

Prvan Eugen

grad didactic superior, Colegiul Industrial-pedagogic, Cahul;

Bagrin Diana

grad didactic unu, profesor de informatic, Colegiul Financiar Bancar;

Recenzeni:

TEMA 1: Procesul de testare i importana asigurrii calitii produsului program

Unitatea de nvare: Planificarea procedurilor de testare
Aspecte ale testrii produselor soft:
Impactul erorilor produselor soft asupra vieii noastre;
Ce prezint erorile produselor soft i care este cauza apariiei lor;
Cine sunt testerii i care este rolul lor n procesul de elaborare a produselor soft.

Pentru a asigura calitatea i sigurana aplicaiilor prduse soft se pune un accent deosebit pe testarea
acestor din urm. Testarea de produse soft a devenit o profesie tehnic foarte important.
Urmtoare exemple pot ilustra foarte bine necesitatea testrii produselor soft:
Dezvoltarea aplicaiilor soft 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.
Testarea produselor soft, 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, totui acesta va conine 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 produsului soft

Una dintre cele mai scandaloase erori ale produsului soft
1. Aparat medical pentru terapie cu radiaie Therac-25 - 6 accidente cu mori i rni grave (198587, SUA, Canada). Cauza direct: erori in programul de comand.
Analiz retrospectiv [Leveson 1995]:

ncrederea excesiv n produsul soft (n analiza produsului)

fiabilitate siguran
3

2. Racheta Ariane 5
- Autodistrugerea 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 nejudicioas a produsului soft
cod preluat de la Ariane 4, fr re-analiz corespunztoare.

3. Eroarea din procesorul Intel Pentium

Eroare n unitatea de mprire cu virgula mobila, 1994
Cost: cca. 400 milioane dolari
Analiz retrospectiv

Circuitul putea fi verificat formal

- demonstrarea 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 produsului soft
Din exemplele de mai sus se poate vedea impactul erorilor produsului soft 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 de spus cu siguran 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, Bug)
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)
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.
4

De obicei orice eroare a produsului soft 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 a produsului soft.
nainte de a formula definiia erorii a produsului soft avem nevoie de un document de reper:
specificaia produsului soft.
Specificaia produsului este un acord al echipei de dezvoltare a produsului soft, n care este defini:
cum ar trebui el s fie, cum este ntr-adevr, ce trebuie s fac i ce nu trebuie s fac acest produs.
Definiie. Erorile produsului soft 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, deacea testorii folosesc aceste reguli
pentru a identifica diferite tipuri de probleme n aplicaiile soft.
1.1.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 sufucient de
complet, a fost incontinuu modificat 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.2.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.3. Rolul i scopurile testerului n procesul de dezvoltare produse soft
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 erorile
nu au fost depistate lpromt, 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.
5

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 a 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 produsului soft este o profesie tehnic. Testorii trebuie
implicai n procesul de dezvoltare a produsului soft nc din fazele incipiente, pentru a asigura
calitatea bun a produsului. Pentru a fi angajat i preuit un testor trebuie s posede urmtoarele
caliti:
1. Trebuie s fie un explorator. Testorul produselor soft este cel care experimenteaz cu softuri noi ncercndu-le funcionalitile.
2. Trebuie s fie nenduplecat. Testorul produselo soft 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
produselor soft 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 produse soft vor fi de un imens ajutor pentru un testor.
1.4. Termeni i definiii ale testrii
Psihologia testrii
Testarea produselor soft este o disciplin tehnic, ns ea implic importante consideraii
economice i psihologice.
Ideal ar fi testarea tuturor combinaiilor posibile ale intrrilor i ieirilor programului. ns n cele
mai multe cazuri aceasta este imposibil, deoarece chiar i un program simplu poate avea sute i
chiar mii de combinaii ale intrrilor i ieirilor.
6

Crearea cazurilor de test pentru toate combinaiile este nepractic, pentru ca aceasta va cere resurse
umane i financiare enorme, iar 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.
8

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.5.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 produsului soft 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.
9

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 produsului soft 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 produselor soft 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.
10

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.

TEMA 2: Principiile procesului de testare

Unitatea de nvare 2: Planificarea procesului de testare
1. Descrierea procesului de testare (testarea n funcie de bani, timp, calitate)
Costul erorilor.
Erorile depistate i fixate n 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.
Cauze ce pot duce la apariia defectelor n produsul soft:

Nimeni nu este perfect, oricine poate face greeli/omisiuni

Presiunea crescut poate duce la greeli
Restriciile de timp i buget
Pregtirea slab, comunicarea ineficient
Cerine slabe
Specificaii incomplete

Ct de mult testare este necesar?

Dac se oprete testarea prea devreme, se risc apariia de erori la rularea propriu-zis a
sistemului. Dac testarea continua pentru o perioad prea lung se poate amna lansarea
produsului, fapt ce poate duce la degradarea imaginii companiei sau chiar pierderi de venituri.
Foarte rar este posibil testarea tuturor posibilitilor, fapt ce duce la concentrarea ateniei asupra
anumitor factori :
Managementul i reducerea riscurilor
Analiza continua a riscurilor produsului
Testarea categoriilor mari de risc
ntelegerea efectului pe care l-ar putea avea un produs care nu funcioneaz corect

2. Riscurile procesului de testare

Unele dintre cele mai scandaloase erori n produsle soft
1. Aparat medical pentru terapie cu radiaie Therac-25
2. Racheta Ariane 5
3. Eroarea din procesorul Intel Pentium
11

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.
Psihologia testrii
Testarea produselor soft 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.
Rolul i scopurile testerului n procesul de dezvoltare a produsului soft.
1. Scopul testorului este de a depista erorile softului.
2. Scopul testorului este de a depista erorile softului ct mai devreme posibil.
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.
Calitile unui tester bun
1. Trebuie s fie un explorator. Testerul de produse soft este cel care experimenteaz cu softuri noi ncercndu-le funcionalitile.
2. Trebuie s fie nenduplecai. Testerul de produse soft 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. Testerii tind spre perfeciune, cu toate c neleg c n industria
produselor soft 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.
12

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 tester nu trebuie s fie numaidect un programator, cunotinele din diferite domenii
(economie, nvmnt, aviaie, medicin, culinrie, construcii ) pentru care sunt dezvoltate
produsele soft vor fi de un imens ajutor pentru un tester.
Principii ale testrii (Myers)
Principiul 1: Un caz de test trebuie sa defineasc neaprat ieirea sau rezultatul dorit.
Principiul 2: Un programator ar trebui s evite i s testeze propriul program.
Principiul 3: Companiile de programare nu ar trebui s-i testeze produsele proprii.
Principiul 4: Fiecare rezultat al testului trebuie examinat foarte minuios.
Principiul 5: Cazurile de test trebuie s fie scrise att pentru condiii de intrare valide ct i
pentru cele invalide i neateptate.
Principiul 6: Trebuie testat c produsul face ce trebuie i nu face ce nu trebuie.
Principiul 7: Trebuie de pstrat i refolosit cazurile de test.
Principiul 8: Nu se planific procesul de testare presupunnd c nu vor fi gsite erori.
Principiul 9: Probabilitatea de a gsi erori ntr-un fragment de cod este proporional cu numrul
de erori deja gsite.
Principiul 10:Testarea este un lucru extrem de creativ i intelectual.
Axiomele testrii (Patton)
1. Este imposibil testarea complet a unui program.
2. Testarea produselor soft este un exerciiu de apreciere a riscurilor.
3. Testarea nu poate arta c produsul nu are erori.
4. Cu ct mai multe erori gseti, cu att mai multe sunt.
5. Paradoxul pesticidelor: erorile devin rezistente la teste
6. Nu toate erorile gsite vor fi corectate.
7. E greu de spus cnd o eroare e o eroare ...
8. Specificaiile produselor nu sunt niciodat definitive.
9. Testerii nu sunt cei mai populari membri ai echipei de proiect.
Tema 3: Planul de testare
Unitatea de nvare: Planificarea procesului de testare
Fazele procesului de testare sunt:
1.
2.
3.
4.

planificarea,
analiza i proiectarea,
implementarea,
execuia i evaluarea testelor.
13

1. Planificarea 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. 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 soft.
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.
2. Analiza testelor
Analiza testelor rafineaz metodele prezentate n planul de test. Sunt prezentate etapele fazelor
de analiz i proiectare a testelor.
Astfel, n etapa de analiz se identific urmtorii pai:
1. identificarea scopurilor, obiectivelor i a strategilor testrii de ctre echipa de testare;
2. metodele de verificare sunt asociate cerinelor sistemului sau cazurilor de utilizare i sunt
documentate n cadrul unei matrice de urmrire a cerinelor;
14

3. analiza cerinelor testelor;

4. construirea matricei cerinelor testelor, n care declaraiile cerinelor testelor sunt asociate
cerinelor sistemului sau a cazurilor de utilizare;
5. 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 produselor soft 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.

3. Implementarea testelor
n etapa de implementare a testelor sunt construite cazurile de test i procedurile de test, pe baza
rezultatelor fazei de proiectare. Cazurile de test descriu att parametrii de intrare ct i rezultatele
ateptate dup execuie utiliznd acei parametri. Realizarea de cazuri de test ct mai complete duce
15

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.

4. Execuia i evaluarea testelor

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.

16

Fazele de executie i evaluare pentru testarea de module

Rezultatele execuiei testelor se vor memora ntr-o baz de date care conine i alte informaii
referitoare la aplicaia soft realizat.
Execuia i evaluarea testrii de integrare necesit noi secvene de test pe rul structurii programului
care sesteaz. Aprobarea de ctre beneficiar a rapoartelor testrii de modul i ale testarii de
integritate continue inchiierea acestor faze.
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.

CONCLUZIE
Testarea este un proces costisitor, nsa este necesar pentru asigurarea unui ncrederi mai mare n
aplicatia soft. Identificarea costurilor n procesul de testare reprezinta un aspect important pentru
problematica minimizarii costului ntregului proiect al produsului soft. Prin analiza surselor
cheltuielilor n procesul de testare pot fi gasite modalitati pentru reducerea acestora. Astfel,
scaderea cheltuielilor cu testarea se poate realiza prin:

alegerea de personal calificat;

automatizarea procesului de testare;
documentarea corespunzatoare a activitati de testare;
reutilizarea testelor;
nceperea testarii nca din fazele de nceput ale ciclului de dezvoltare a produsului soft;
alegerea unui criteriu optim de oprire a testarii.

Pe baza acestor cheltuieli nregistrate se construiesc modele de evaluare a costului testarii

produsului soft. De aceea, este necesar ca pentru fiecare echipa de testare, este necesar sa se
17

efectueze nregistrari de consumuri si de performanta pentru a putea obtine la timp baza de date
solicitata n procesul de estimare a coeficientilor pentru modelele testarii.
TEMA 4: Cazul de testare
Unitatea de nvare: Realizarea procesului de testare
TEMA4: Cazuri de testare
Competene elementare formate n cadrul modului:
CE2.

Realizarea procesului de testare.

Abiliti formate:
A8.

Alegerea sub ndrumare a tehnicilor de testare;

A9.

Selectarea criteriilor de testare;

A10.

Elaborarea cazurilor de test n baza specificaiilor.

Termeni cheie:
Test condition;
Test case;
Test suite;
Test case generation;
Test case execution
Test condition ( condiia, starea) - un element ori un eveniment al componentei sau
sistemului care poate fi verificat de unul sau mai multe cazuri de test, de exemplu o funcie, o
tranzacie, o trsturi, un atribut de calitate sau element structural.
Cu alte cuvinte condiia de test e o caracteristic a softului care poate fi verificat printrun test sau un set de teste.
Un caz de test este un set de date de intrare mpreun cu datele de ieire pe care programul
ar trebui s le produc. De exemplu, valorile coeficienilor a, b, c ai unei ecuaii de gradul doi
mpreun cu valorile x1, x2, n testul unui program de rezolvare a ecuaiilor de gradul doi. Cazurile
de test se aleg astfel nct sa fie puse n eviden, dac este posibil, situaiile de funcionare
necorespunztoare.
Alte definiii:
Standardul IEEE 610 - 1990: Un set de intrri ale testului, condiii de execuie i
rezultate ateptate, dezvoltat pentru un obiectiv anume, cum ar fi s exercite o anume cale a unui
program sau s verifice corespondena cu o cerin specific;
Ron Patton ( 2001): Cazurile de testare sunt intrrile specifice pe care le vei ncerca si
procedurile ce vor urma cnd testai produsul soft.
Test case - un set de valori incluse, executarea precondiiilor, rezultatele ateptate i
executarea postcondiiilor, dezvoltate pentru un obiectiv particular sau pentru condiia de test,
18

astfel nct s solicite o anumita parte a programului sau s verifice concordana cu o cerin
specific.
Cu alte cuvinte, un test case: aduce sistemul la un punct de start a testului (executarea
precondiiilor); apoi aplica un set de date de intrare care trebuie s genereze un anume rezultat
(rezultatul ateptat), i prsete sistemul la un moment dat (executarea postcondiiilor).
Activitile de proiectare vor genera un set de valori de intrare (input values) care vor
genera un anumit rezultat, de ex. stabilirea de ctre specificai ce se va ntmpla cnd se vor aplica
datele de intrare.
Trebuie s definim starea sistemului n care el este pregtit s primeasc intrri, i trebuie
s decidem n ce stare va fi el dup testare astfel nct s putem verifica daca se finiseaz n locul
potrivit.
Selectarea cazurilor de test este unicul pas important pe care testorii de soft-uri l fac.
Selectarea incorecta a acestora induce la testarea prea ndelungata, prea puina sau testarea unor
lucruri eronate. Estimnd inteligent riscurile i reducnd infinitatea de posibiliti la un set eficient
i administrabil de date.
Procedura de testare - identific toate aciunile necesare executrii testului ntr-o anumit
ordine. Procedura de testare - deseori e numita test script (sau manual test script pentru al deosebi
de automated scripts care se execut cu diferite instrumente)
Specificaia cazurilor de test este a doua etap n procesul fundamental de testare.
Proiectarea testelor conin 3 etape:
1. Identificarea condiiilor de testare.
2. Specificarea cazurilor de test.
3. Specificarea procedurilor de testare.
Pornind de la cele trei etape ale procesului, noi:
decidem o condiie de testare, care va fi o mic parte a specificaiei softului testat;
proiectm un test case care va verifica condiia de testare;
scriem o procedur pentru executarea testului, de exemplu: alegei o stare de start
corect, introducei datele de intrare (input values), verificai rezultatele obinute.
n pofida limbajului tehnic, e un set simplu de pai. Desigur va trebui sa utilizm de mai
multe ori aceti pai pentru a testa ntregul sistem, dar procesul de baz este acelai. Pentru a testa
tot sistemul scriem planul de executare a testului, care plaseaz procedurile individuale de testare
n ordinea adecvat i seteaz sistemul aa nct s fie posibil executarea testului.

Exemplu:
Unui testor, nou angajat, i se propune spre realizare urmtorul test-case:
Plata poate fi efectuata cu cartela VISA
19

Momentan apar minimum doua probleme:

Pentru executarea test-case-ului este necesara o cartela de testare VISA, pe care
testerul nu o are;
El nu cunoate cum s verifice dac plata a fost efectuata n realitate sau nu, chiar
daca el va avea la dispoziie cartela VISA.
Unicul lucru, care este clar, - acesta reprezint un proces de cumprare n internet-magazin
(cutarea produsului, adugarea lui in co s.a.m.d.), care n aceast situaie nu ajuta cu mult. Este
clar c nici o testare nu va fi realizat, deoarece pentru a ajunge la un careva rezultat va fi destul
de dificil. Pentru realizarea test-case-ului cu succes el ar trebui s arate n urmtorul mod:
1.

Deschide www.magazin.md

2.

Introdu n cmpul Numele utilizatorului: testuser1

3.

ntrodu in cmpul Parola: pa$$wOrd

4.

Apas pe butonul Intrare;

5.

ntrodu in cmpul Cutare: book117

6.

Apas pe butonul Gsete

7.

Efectueaz un click pe referina Adaug n cos

8.

Efectueaz un click pe referina Co

9.

Efectueaz un click pe referina Pltete

10.

Din meniul Tipul cartelei alege: VISA

11.

n cmpul Numrul cartelei introdu: 9999-3214-1111-3255

12.

n cmpul Valabil pn la introdu: 12/17

13.

n cmpul CW2 introdu:445

14.

Apas pe butonul Confirma comanda

15.

Scrie numrul comenzii: ________________

16.

Interogheaz baza de date: SELECT result from cc_transaction WHERE id =

<numarul comenzii>;
Rezultatul ateptat: 10
Este evident, ca acest test-case poate fi realizat de oricine, ce are abiliti de lucru la
calculator.
n acest exemplu la rezultatul ateptat s-au adugat pai (steps), care ar trebui sa ne conduc
la rezultatul real, pentru a cunoate dac este prezent bagul sau nu. Totalitatea acestor pai se
numete procedura (procedure).
Dup analogie:
Pai - trepte ale unei scri;
Rezultat ateptat - un oarecare obiect, pe care noi ar trebui s-l gsim, dup ridicarea
pe aceste trepte;
20

 Rezultat real - este ceea ce noi am gsit n realitate dup ce ne-am ridicat pe aceste
trepte.
Implementarea testelor
n etapa de implementare a testelor sunt construite cazurile de test i procedurile de test, pe
baza rezultatelor fazei de proiectare. Cazurile de test descriu att parametrii de intrare cat i
rezultatele ateptate dup execuie utiliznd aceti parametri. Realizarea de cazuri de test cat mai
complete duce la descoperirea unui numr mai mare de erori. Procedurile de test identific toi
paii necesari pentru executarea cazurilor de test specifice.
Rularea testelor.
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 daca 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 o persoana sau un instrument
automat, care pe baza specificaiilor determin dac rezultatele execuiei testelor sunt corecte sau
nu.
Rezultatele execuiei testelor se vor memora ntr-o baza de date care conine i alte
informaii referitoare la aplicaia soft realizata.
Execuia i evaluarea testrii de integrare necesit noi secvene de test pe msura ce se
adaug module n cadrul structurii programului care se testeaz. Aprobarea de ctre beneficiar a
rapoartelor testrii de modul i ale testrii de integrare constituie ncheierea acestor faze.
In execuia i evaluarea testrii de sistem, beneficiarul aplicaiei se implica mai mult dect
n celelalte faze. In mod asemntor, acesta trebuie s semneze raportul de test pentru a considera
ncheiata aceasta faza de testare.

21

Diagrama

strilor

crerii unui caz de testare:

creare, draft, revizuit,
ters, livrat, update i nvechit.
Anumite

aciuni

snt

efectuate de responsabilul strii,

dup care cazul de testare este
trecut n starea urmtoare, dup
ce aciunile se ncheie.
Diagrama

strii

rezultatelor:
PASS/FAIL/Blocat/Invalid

Proiectarea unui caz de testare:

Cazurile de utilizare i de testare provin din origini diferite i servesc scopuri diferite. Se
poate folosi un proces n patru pai pentru a trece de la cazurile de utilizare la teste:
Identificarea scenariilor cazurilor de utilizare.
Pentru fiecare scenariu, identificai unul sau mai multe cazuri de testare.
Pentru fiecare caz de testare, identificai condiiile care l vor face sa fie executabil.
Completarea cazului de testare prin adugarea de date cu valori.
Structura unui test:
Cazurile de testare trebuie s menioneze:
Titlul ( funcionalitatea ce va fi testata)
Versiunea (cazul de testare se modifica n timp, o dat cu aplicaia)
22

Cazurile de testare se scriu sub forma de tabel, si contin urmatoarele coloane:

ID
Paii testului
Rezultatele ateptate
Rezultatele reale
ID-ul defectelor
Versiunea pe care s-a executat testul
Rezultatul testului (pass, fail, etc.)
Unele teste precizeaz i condiiile necesare nainte de a se rula un test.
Exemplu de un caz de testare:
Test Case #:

Test Case Name:

System:

Subsystem:

Designed by:

Design Date:

Executed by:

Execution Date:

Page: 1 of ..

Short Description:

Nr. ID

Descriere

Rezultate
ateptate

Rezultate
reale

Co
Pass me
/Fail nta
rii

Lansarea aplicatiei:
1.
AD_lansare
Dublu clic pe ari Aparitia
e_dreptunghi. exe aplicatiei:
2.

ferestrei Apare
fereastra
Pass
aplicatiei.
AD_interfata_t Denumirea
Bara de titlu:
Bara de titlu: Aria
itlu
aplicatiei pe bara Aria
DREPTUN
Pass
de titlu.
DREPTUNGHIUL
GHIULUI
UI
Greeli frecvente la elaborarea cazurilor de testare:
Cazurile de testare sunt prea lungi;
Precondiii incomplete, incorecte sau neclare;
Omiterea unui pas;
Numirea unor cmpuri care s-au schimbat sau nu mai exista;
Neclaritatea daca testul a trecut sau a picat.
Concluzie:
Nu exista o formula simpla sau reet pentru a genera un caz de testare bun.
Unele teste sunt bune pentru scopul pe care l avem, pentru a afla tipul de informaie
pe care l dorim.
23

Tema

5:

Ciclul

de

via

al

elaborrii

produsului

program

Unitatea de nvare 4: Modaliti de realizare a testrilor

Ciclul de via a unui produs program - O secvena de etape n existena produsului soft. Sunt
incluse toate activitile necesare pentru dezvoltarea produsului i relaiile temporale dintre ele.
Fiecare etap din ciclul de viaa este caracterizat prin activiti specifice i produsele rezultate din
activitile respective.
Fazele ciclului de via al unui produs soft:

Analiza cerinelor

Proiectarea sistemului

Implementarea lui

Integrarea i instalarea la beneficiar, (testarea)

Operarea i ntreinerea

Analiza cerinelor - Determinarea cerinelor; Specificarea cerinelor; Instrumente CASE

(Computer Assisted Software Elaboration); Documentaia de specificaie a cerinelor; Asigurarea
calitii produsului soft.
Proiectarea sistemului - O descriere a structurii sistemului de implementat; Datele care sunt
prelucrate n sistem; Interfeele ntre componentele sistemului; Algoritmii utilizai (doar n
anumite situaii); Proiectarea detaliat (adaug detalii modelului realizat din analiza cerinelor);
Proiectarea arhitectural; Gestiunea relaionrii prilor aflate n diverse stadii de dezvoltare cerine, proiect sau segmente de cod.
Implementarea - O mare parte este programare; Extra proiectare nainte de programare;
Generare de cod; Revizuirea codului (prin treceri i inspecii); Testarea bazat pe execuie
(observarea comportamentului), testarea conform cu specificaiile (black box testing), testarea
conform cu codul (white-box testing) se urmresc ci de execuie.
Integrarea i instalarea - Se asambleaz aplicaia din setul de componente implementate i testate
n prealabil n faza de implementare prin integrarea continu, ce reese din proiectarea arhitectural
a sistemului. Instalarea este transmiterea sistemului funcional beneficiarului pentru utilizarea n
producie: softul este instalat n diverse versiuni; fiecare versiune este precedat de testare de
sistem (dezvoltator alpha-testing) i testarea de acceptare(beneficiar-beta-testing); training pentru
beneficiar; documentaie de utilizare.
Operarea i ntreinerea - Operarea semnific acea etap a ciclului de via n care un produs
soft este utilizat n munca de zi - cu - zi nlocuind sistemul precedent. Startul Operrii coincide cu
nceperea procesului de Mentenan:

Corectiv;

Adaptiv;

Perfectiv.

Ciclul de via difer n funcie de:

24

Experiena, abilitile i cunotinele membrilor echipei de dezvoltare;

Gradul de cunoatere i experiena n afacerea vizat de sistem;

Tipul domeniului aplicaiei;

Schimbrile de mediul afacerii;

Schimbrile din interiorul afacerii;

Dimensiunea proiectului.

Modele ale ciclului de via a unui produs soft:

Modelul Waterfall (cascad)

V-model

Incremental (spiraliform)

Modelul Waterfall
Modelul Waterfall Cerine sistem Cerine produs soft Design arhitectural (cerine
tehnice) Design detaliat(cerine program) Implementare (Coding) Testare.
Este lansat la nceputul anilor 70 ai secolului al XX-ea de ctre W.W. Royce
Presupune parcurgerea secvenial a etapelor (de la analiza cerinelor i pn la livrarea produsului
ctre client), cu reveniri, eventual doar la etapa precedent (model teoretic)
n realitate, parcurgerea etapelor este un proces iterativ, desfurat adesea n paralel la mai multe
activiti, cu retur napoi la etape nenvecinate.
Fiecare faz corespunde unei activiti i trebuie s se termine la o anumit dat prin producerea
anumitor documente sau programe.
Rezultatele fazei sunt supuse unei revizii aprofundate i nu se trece la faza urmtoare dect atunci
cnd sunt considerate satisfctoare.
Este aplicat unor sisteme de mic complexitate.
V-model
V-model
Este o variant a modelului cascad, care pune n eviden corelarea dintre activitile de
specificare i cele de testare, nlturarea n timp a activitilor fiind aceeai.
V-modelul presupune un ciclu de via secvenial.
Planificrile se fac o dat cu parcurgerea primei ramuri.
nceperea activitilor de testare n fazele incipiente ale ciclului de viaa.
Planul de testare afecteaz planul de dezvoltare.

Modelul Incremental
Modelul Incremental
Pentru modelul iterativ cerinele nu trebuie s fie definite n ntregime nainte de nceperea
codificrii. O versiune de lucru a produsului este construit, n cteva etape, sau iteraii. Acest tip
25

de dezvoltare este adesea menionat ca ciclic n cadrul proiectului. Proiectul va avea definit un
interval de timp i costuri. Fiecare ciclu va avea, de asemenea, un interval de timp i de cost.
Ciclurile sunt denumite n mod obinuit time-boxes. Pentru fiecare time-box este definit o cerin
i este produs o versiune a codului, care va permite testarea de ctre utilizatori. La sfritul
fiecrui time-box, va fi luat o decizie n privina funcionalitii i dac e necesar se va dezvolta
funcionalitatea n urmtoarea iteraie. Acest proces se repet pn cnd sistemul complet va
realiza produsul.
Modele:

Spiral (Boehm, 1988);

IBM Rational Unified Process (RUP)(IBM, 2003);

Model Driven Architecture(MDA) (OMG, 2003);

Agile lifecycle with short cycles (Agile Alliance, 2001)

Verificarea i Validarea pe tot parcursul ciclului de via

Verificarea - verific dac produsul ndeplinete cerinele stabilite. Verificarea asigur construirea
produsului n mod corect.
Validarea - asigurar potrivirea comportamentului produsului la nevoile clienilor.
De exemplu, pentru un site web:
Validarea va include utilizatorii,
Verificarea c ei pot folosi site-ul cu uurin.
Mentenana testrii
Pentru unele proiecte sistemul este instalat beneficiarului. Odat implementat de mizeaz pe faptul
c el va funciona dup destinaie, civa ani sau poate zeci de ani.
ns cu timpul apare necesitatea de a schimba sistemul. Necesitatea modificrilor se datoreaz
urmtorilor factori:

Apare necesitatea includerii caracteristicilor suplimentare;

Sistemul a fost migrat pe o nou platform;

Sistemul a fost retras i apare necesitatea migrrii sau arhivrii datelor;

Apariia de noi anomalii care trebuiesc fixate... .

Modificrile ce au fost fcute n sistem vor trebui testate, retestate i deasemenea se vor efectua
teste de regresie, pentru a se asigura c sistemul nu a fost afectat.
Testarea care are loc pe un sistem ce funcioneaz real este numit mentenana testrii.
Concluzii
Etapele procesului de dezvoltare a soft-ului sunt cunoscute ca faze al e ciclului de via a
produsului soft.
Fazele ciclului de via sunt: analiza cerinelor, proiectarea sistemului, implementarea, integrarea
i instalarea, operarea i mentenan.
Modelele ciclului de via pot fi mprite n:

modele cascad cu variante succesive;

modele iterative cu variante succesive.

26

Modelele n cascad nu sunt adecvate proceselor moderne de dezvoltare.

Cele mai reprezentative patru modele iterative sunt:

Spiral,

Rational Unified Process(RUP),

Model driven Architechture(MDA)

Agile.

Tema 6: Nivelele modelelor de testare

Unitatea de nvare: Modaliti de realizare a testrilor
Termenul de 'testare unitar' se refer la testarea individual a unor uniti separate dintr-un produs
soft.
n timpul proiectrii i codificrii se comit erori care sunt grupate n urmtoarele categorii:

erori legate de alegerea i descrierea algoritmului: algoritm incorect, sau corect dar
inadecvat problemei;

erori n definirea i utilizarea datelor ce provin din variabile neiniializate: formate

improprii de citire, contoare de capacitate insuficient, neverificarea datelor de intrare;

erori de calcule: expresii complicate cu posibiliti necontrolate de eroare;

erori produse n tehnica de programare cum sunt variabile i structuri de date globale,
acces necontrolat la zone de memorie partajate;

erori produse din neatenie caz n care logica de control e defectuoas, salt n afara
limitelor programului, condiii logice compuse sau incorect negate;

erori n contextul execuiei datorate memoriei dinamice insuficiente sau nealocat,

periferice neoperaionale, comunicare defectuoas cu sistemul de operare.

erori produse n tehnica de programare cum sunt variabile i structuri de date globale,
acces necontrolat la zone de memorie partajate;

erori produse din neatenie caz n care logica de control e defectuoas: condiii logice
compuse sau incorect negate, neprelucrarea primei sau ultimei nregistrri, neluarea n
considerare a posibilitii de existen a fiierelor vide;

erori n contextul execuiei datorate memoriei dinamice insuficiente sau nealocat,

periferice neoperaionale, comunicare defectuoas cu sistemul de operare;

Testele unitare au cteva caracteristici importante:

fiecare test valideaz un comportament din aplicaie;

ruleaz foarte repede, maxim n cteva minute;

sunt foarte scurte i uor de citit;

ruleaz la apsarea unui buton, fr configurri suplimentare.

Testele unitare sunt scrise de programator, n timp ce implementeaz o funcionalitate.

Test First Programming este o metod de a scrie teste care implic urmtorii pai:

crearea unui design pentru implementarea de funcionaliti;

27

crearea minimului de cod necesar (compilabil, dac limbajul folosit este compilat) pe baza
design-ului;

scrierea unuia sau mai multor teste care codeaz ceea ce trebuie s fac design-ul;

Test Driven Development (TDD) este o alt metod de a scrie teste. De fapt, TDD este o metod
de a face design incremental.
Greeli comune
Cteva greeli comune legate de unit testing sunt:

Scrierea multor teste de integrare(care implic mai multe clase sau module) lente i fragile
n detrimentul testelor unitare mici, rapide i uor de ntreinut;

Abandonarea dublelor de testare, sau folosirea lor n scopuri pentru care nu au fost create.
Dublele de testare ajut la obinerea unor teste scurte i rapide;

Numele testelor nu exprim comportamentul testat. Numele testului poate da foarte multe
informaii atunci cnd testul pic;

Folosirea intensiv a debugger-ului (depnarea) pe teste. Testele bine scrise vor spune
imediat unde este problema n cazul n care pic. Debugging-ul este n continuare util n
situaii exotice;

Cod de testare nengrijit. Codul de testare este cel puin la fel de important ca i codul de
producie, i trebuie ntreinut cu aceeai grij.

2.Testarea integrrii
Dup ce unitile au fost scrise, urmtoarea etap ar fi s le nteracionm pentru a crea sistemul.
Aceasta se numete integrare.
Scopul testrii de integrare este de a expune defectele interfeelor.
Testarea de integrare include:

soft-ul i sistemul de proiectare;

o diagram a arhitecturii sistemului;

fluxurile de lucru i cazuri folosite.

Exist trei strategii de integrare

Integrarea big-bang
Sunt integrate ntr-un program executabil toate modulele existente la un moment dat. Metoda este
periculoas cci toate erorile apar n acelai timp i localizarea lor este dificil.
Acest tip de integrare este n general considerat ca o alegere proast a strategiei de integrare.
Integrare de sus n jos (Top-down integration)
Se ncepe prin testarea modulului principal, apoi se testeaz programul obinut , i aa mai departe.
Componentele care apeleaz alii sunt de obicei plasate deasupra celor care sunt numite. Testarea
de integrare de sus n jos v permite s evaluai componentele interfeei, de sus n jos
Integrare de jos n sus (Bottom-up integration)
Aceasta este opusul strategiii de sus n jos i componentele sunt integrate n de jos n sus.

3.Testarea de acceptare
28

Testarea de acceptare este o testare care are n vedere nevoile i cerinele utilizatorilor. Este o
metod menit s determine dac un sistem ndeplinete sau nu criteriul de acceptare. In acelai
timp, utilizatorul, clientul sau orice alt entitate asociat determin dac accepta sau nu sistemul.
n cazul testarii de acceptare gsirea de defecte nu este scopul principal i nu este neaprat
ultimul nivel al testarii.
Testarea de acceptare se poate realiza pe mai multe nivele.
Forme obisnuite de testare de acceptare:
1. Testare de acceptare a utilizatorului: utilizatorul unui produs final efectueaz testele. Setrile
lor vor reprezenta un mediu de lucru i acopera toate ariile poriectului, nu numai ale sistemului.
2. Testarea de lucru presupune testarea unei rezerve(backup), refacerea n caz de dezastru,
mentenana task-urilor i verificri periodice ale vulnerabilitii securitii.
3. Testarea privind acordul si reglementrile reprezint o demonstraie a criteriului de acceptare
care a fost definit n contract. nainte ca produsul soft sa fie acceptat, este necesar s vizibil ca el
ndeplinete condiiile aa cum sunt specificate n contract. Acest tip de testare este efectuat contrar
oricrei reglementri la care produsul trebuie s adere cum ar fi guvernamentale, legale sau de
siguran.
4. Testarea Alpha permite testrii de ctre client. Oamenii care reprezint inta folosesc produsul
n acelai fel ca i cum ar fi cumparat versiunea final. Aceast testare se realizeaz n cas (pe
site-ul dezvoltatorilor).
5. Testarea Beta se aseamana cu testarea Alpha, numai c utilizatorii efectueaz testarea pe
propriile site-uri.
4.Testarea sistemului
Dup ce s-a verificat c componentele toate lucreaz mpreun la nivel de unitate, pasul urmtor
este de a lua n considerare funcionalitatea din perspectiva end-to-end. Aceast activitate este
numit testarea sistemului.
Testele de sistem sunt teste ale sistemului de programe i echipamente complet. Sistemul este
instalat i apoi testat n mediul su real de funcionare.
Acesta se realizeaz de obicei prin o echipa care este independent de procesul de dezvoltare.
Avantajul acestei independene este c o evaluare obiectiv a sistemului poate fi fcut, n baza
specificaiilor scrise, i nu a codului.
Sunt teste n conformitate cu specificaia cerintelor de sistem (produs soft):

teste functionale, prin care se verifica satisfacerea cerintelor functionale

teste prin care se verific satisfacerea cerintelor ne-functionale :

o

de performan,

de fiabilitate,

de securitate, etc.

Adesea, testele de sistem ocup cel mai mult timp din ntreaga perioad de testare
Exemple de cerine non-funcionale:
Procedurile de instalare - Installability.
Mentenabilitate - capacitatea de a introduce modificri ale sistemului.
29

Performance - ateapt un comportament normal.

Manipularea de ncrcare - comportamentul sistemului n cretere.
TEMA 7: Testarea static i modul de organizare a revizuirii statice
Unitatea de nvare: Planificarea procedurilor de testare. Realizarea procesului de testare
TEMA 7: Testarea static i modul de organizare a revizuirii statice
Competene elementare formate n cadrul modului:
Planificarea procedurilor de testare. Realizarea procesului de testare.
Abiliti formate:
A2.

Elaborarea sub ndrumare a planului de testare

A3.

Stabilirea activitilor testerului la diferite etape de testare.

A4.

Revizuirea caietului de sarcini.

A5.

Revizuirea documentaiei proiectului;

A9.

Selectarea criteriilor de testare;

A10.

Elaborarea cazurilor de test n baza specificaiilor.

Termeni cheie:
Testare static
Inspecie/ revizuire (review)
Grad de formalitate
Eroare de sintax
Eroare semantic
Metodele statice testeaz produsul program fr ca el s fie executat. Totui prezint
important deosebit prin abilitatea de a depista erorile i defectele nainte de executarea codului,
n primele etape ale desfurrii proiectului, facilitnd i reducnd din cheltuielile necesare pentru
depistarea i corectarea aceleiai greeli ntr-o etap mai avansat. Printre aceste metode se
regsete i tehnicile de inspecie (review).
n aceast tem vom cerceta i analiza static a codului dezvoltat, considerat o tehnic de
examinare a codului fr activarea lui pentru a identifica problemele actuale sau poteniale.
Testarea static deseori este imposibil de realizat manual, astfel vom cerceta tipurile testrii statice
care solicit anumite mijloace (instrumente).
Generaliti despre tehnicile statice
Tehnicile testrii statice presupun tehnicile de testare a soft-ului care nu implic executarea
codului. Aceasta include:
testarea produsului soft diferit de cod: cerinele tipice ori documentele ce conin
specificaiile;
30

 testarea codului fr executarea lui.

Prima activitate se numete revizuire (inspecie) i este utilizat de obicei pentru
nlturarea erorilor i ambiguitilor din documente nainte de a fi folosite la dezvoltarea
proiectului, astfel eliminnd o surs a defectelor n cod.
A doua activitate e cunoscut sub numele de analiz static i permite cercetarea codului
de defectele structurale i insuficienele sistematice care pot favoriza defectele.
Inspeciile sunt fcute manual, analiza static se realizeaz de obicei automatizat cu
ajutorul unor instrumente.
Revizuirea este o examinare sistematic a documentului de ctre una sau dou persoane
care au ca obiectiv detectarea i nlturarea erorilor. ncredinarea reexaminrii primei variante a
documentului colegilor e cel mai simplu exemplu de revizuire i care de obicei scoate la iveal o
mulime de erori anticipate.
Revizuirea se aplic documentelor scrise sau tiprite: documente ca specificaiile
cerinelor, design-urile sistemului, codul, test-planurile i cazurile de test. Revizuirea reprezint
prima form de testare posibil n perioada de dezvoltare a soft-ului. Testarea documentelor ce
conin specificaii prin revizuirea lor la etapa iniial a ciclului de nfiinare a soft-ului favorizeaz
detectarea defectelor nainte de a fi incluse n codul surs. Astfel reducnd din efortul i cheltuielile
necesare pentru nlturarea defectelor, acelai defect detectat de o testare dinamic va solicita un
extra cost pentru re-crearea i testarea codului defect, diagnosticarea sursei defectului, corectarea
problemei i rescrierea codului pentru eliminarea defectelor. Inspecia codului conform
standardelor de dezvoltare poate preveni apariia defectelor la executarea testului. Dar i n aceste
cazuri, dac codul a fost scris nu se pot evita unele cheltuieli.
Pe lng economisirea timpului i a finanelor exist i alte avantaje ale depistrii timpurii
a defectelor n perioada de dezvoltare:
Poate fi mbuntit productivitatea i reducerea limitelor temporale deoarece
corectrile defectelor ntr-o etapa ct mai timpurie vor asigura c produsul este clar i
neambiguu. Aceasta ar trebui s-l ajute pe dezvoltator s se mite mai repede n
procesul de scriere a codului. De asemenea, dac defectele s-au nlturat nainte ca
proiectul s devin cod se vor detecta i fixa mai puine erori pe parcursul executrii
testrii ulterioare.
Costul i timpul testrii poate fi redus prin nlturarea principalelor ntrzieri ale
testului, care au loc cnd defectele sunt depistate dup ce devin eecuri i testorul
trebuie s atepte corectarea soft-ului. Revizuirea codului i detectarea defectelor
nainte de a deveni eecuri i permite testorului executarea mai rapid a testrii.
n realitate e posibil obinerea reducerii costului datorit numrului mic de defecte n
final, care asigur c cheltuielile curente vor fi reduse.
31

 Comunicarea constructiv se datoreaz autorilor i colegilor care cerceteaz i nltur

orice ambiguitate descoperit n timpul revizuirii pentru a asigura c orice participant
a neles exact ceia ce se livreaz.
Cele mai tipice greeli depistate la revizuire:
Abaterile de la standardele interne i reglementrilor/legilor definite n legislaie sau de
o organizaia comercial.
Defectele cerinelor - de exemplu: cerinele sunt ambigue sau au unele elemente lips.
Defectele de design - de exexemplu design-ul nu respect toate cerinele.
Insuficiena stabilitii - de exemplu codul este prea complex i greu de meninut.
Interfaa incorect a specificaiilor - de exemplu interfaa specificaiilor nu corespunde
design-ului sau interfeelor de transmitere sau primire a datelor.
Orice revizuire are ca scop depistarea defectelor, unele ns evideniaz anumite tipuri de
defecte mai efectiv i mai eficient dect altele.
Procesul de revizuire
Procesele de revizuire variaz vizibil n dependen de gradul de formalitate - cnd
formalitatea se asociaz cu nivelul structurii i documentarea cu activitatea. Unele tipuri de
reexaminare au caracter informal, pe cnd altele sunt foarte formale. Stabilirea gradului de
formalitate se bazeaz pe combinarea urmtorilor factori:
Maturitatea procesului de dezvoltare: cu ct acesta este mai matur cu att revizuirea este
mai formal.
Cerinele legale sau reglementare. Acestea se folosesc la administrarea activitii de
dezvoltare a soft-ului n anumite industrii, obligator n ariile de strict-securitate ca de
exemplu semnalizarea cilor ferate.
Necesitatea unei proceduri de audit. Procesele formale de revizuire asigur posibilitatea
unei retrospective a procesului de dezvoltare a soft-ului. Nivelul formalitii tipului de
analiz static utilizat ne poate ajuta s stabilim nivelul procesului de audit.
Revizuirea poate avea o varietate de obiective, iar termenul obiectiv de revizuire semnific
scopul principal al revizuirii.
Obiectivele revizuirii includ:
Detectarea defectelor.
nelegerea..
Generarea discuiilor.
Deciziile luate n consens.
Modalitatea revizuirii se stabilete n dependen de obiectivele specifice. Deci o revizuire
orientat spre detectarea defectelor se va deosibi de una care reflect nelegerea unui document.
Procesul fundamental de revizuire
32

Toate tipurile de revizuire manifest aceleai elemente fundamentale ale procesului:

Documentele aflate n curs de examinare se studiaz de ctre inspectori.
Inspectorii identific problemele i informeaz autorul verbal sau prin document scris,
oficial printr-un raport al defectelor sau neoficial printr-o adnotare a documentului
examinat.
Autorul decide ce aciuni s adopte ca rspuns la comentarii i asupra adaptrii
documentului la acestea.
Procesul de baz se realizeaz permanent, dar n unele examinri formale se includ etape
suplimentare, se insist mai mult pe
documentare i pe msurare.
Etapele reexaminrii formale
Revizuirile din spectrul oficial ca
i revizuirile tehnice i inspeciile, dein
anumite

caracteristici

prin

care

se

deosebesc de cele mai puin oficiale.

n

figura

demonstreaz

alturat

etapele

cheie

se
ale

revizuirii formale:
Planificarea:
Selectarea

personalului

asigurarea c cei alei pot i vor aduga

valoare procesului. Exist un criteriu de
selectare a revizorilor care vor fi de-acord
cu cele scrise de autor. Se recomand includerea unor revizori din diferite departamente ale
organizaiei, care au renume de oameni pretenioi i impariali. Revizorii ca i nunta uimesc prin
ceva vechi , ceva nou, ceva mprumutat, ceva albastru. n acest caz ceva vechi va fi un profesionist
experimentat, ceva nou un membru nou al echipei, ceva mprumutat cineva din alt echip,
ceva albastru opoziionistul greu de mpcat. La etapa iniial a procesului de revizuire se
stabilete un revizor lider. Acesta va dirija activitatea de revizuire.
Repartizarea rolurilor - fiecare revizor primete o anumit sarcin. Cineva poate testa
testabilitatea i claritatea definiiei, altcineva simplitatea i claritatea relaiilor comerciale. Toi
revizorii care lucreaz la acelai document au diferite perspective asupra acestuia.
Definirea criteriului de intrare i ieire, n special pentru tipurile de revizuire formal (de
exemlu inspecia).
Selectarea prilor documentelor care trebuise revzute (nu ntotdeauna necesar, aceasta
depinde de mrimea documentelor: un document mai mare necesit mprirea lui n pri mai mici
33

i analiza fiecrei pri de persoane diferite pentru a se asigura c documentul este revizuit n
ntregime).
Startul: distribuirea documentelor, explicarea obiectivelor, procesului i documentelor
participanilor, verificarea criteriului de intrare. Aceasta poate fi desfurat ca o ntrunire sau
simplu prin distribuirea detaliilor revizorilor. Metoda utilizat depinde de limitele temporale i de
volumul de informaie. Un volum impuntor de informaie poate fi mprit mai bine la o ntlnire
dect prin citirea paginilor de ctre utilizatori.
Pregtirea individual: munca efectuat individual de fiecare participant naintea
ntrunirii, care presupune citirea documentelor surs, consemnarea potenialelor defecte, ntrebri
i comentarii. Aceasta este principala surs i poate fi constrns de timp, participanii primesc 2
ore pentru a-i definitiva pregtirea.
ntrunirea de revizuire: aceasta poate include discuiile referitoare la orice defect gsit.
Inspecia, un tip de revizuire mai formal, va documenta rezultatele. Participanii edinei pot doar
nota defectele care urmeaz s fie corectate de autor. De asemenea pot face recomandri pentru
corectarea defectelor .Determinarea abordrii se bazeaz pe unul sau pe toi factorii de mai jos:
Timpul disponibil - dac dispunem de puin timp ntrunirea poate doar colecta defectele.
Cerinele autorului - dac autorul accept ajutor la corectarea defectelor.
Tipul revizuirii - n cazul inspeciei se permite doar colectarea nu exist nici o discuie.
Refacerea: dup ntrunirea de revizuire autorul va avea mai multe defecte de corectat,
corectarea defectelor se numete refacere. Autorul va nltura problemele depistate i va confirma
necesitatea rectificrii.
Continuarea: liderul reexaminrii va verifica dac defectele acceptate au fost localizate i
va determina de ct timp a fost nevoie pentru revizuire i ct de multe defecte au fost depistate.
Acesta va mai verifica criteriile de ieire (pentru inspecie) pentru a garanta ndeplinirea lor.
Rolurile i responsabilitile
Rolul revizorilor rezid n cercetarea documentelor din perspectiva oferit; aceasta include
utilizarea listei. Pentru identificarea defectelor se poate folosi o list bazat pe perspective
particulare (utilizatorul, mecanicul, testerul sau operatorul) sau una mai general (ca problemele
tipice ale cerinelor).
n afar de acestea procesul de revizuire definete el singur roluri specifice i
responsabiliti care trebuie ndeplinite pentru revizuirea formal:
Managerul: el decide ce trebuie de revizuit (dac nu era definit nc), se asigur dac
timpul alocat n planul proiectului va fi suficient pentru toate activitile de reexaminare necesare,
i determin dac au fost realizate obiectivele analizei. Managerul nu se implic n procesul actual
de revizuire dect n cazul cnd poate aduga ceva important, de exemplu dac el posed
cunotine tehnice importante pentru activitatea respectiv.
34

Moderatorul: e cunoscut uneori ca liderul revizorilor. E persoana care dirijeaz

reexaminarea unui document sau a unui set de documente, planific activitatea, realizeaz
ntrunirea i cele ce urmeaz. Dac e necesar, el va media ntre diferite puncte de vedere i deseori
de el depinde succesul aciunilor rmase. La fel va realiza decizia final despre ce trebuie inclus
n documentul de informare.
Autorul: este cel care a scris sau persoana responsabil de dezvoltarea documentului care
trebuie revizuit. Autorul va prelua n diferite instane responsabilitatea de a localiza i aproba
greeala.
Revizorii: Acestea sunt persoanele cu cunotine tehnice ori comerciale speciale (numii
nc verificatori i inspectori), care dup o pregtire adecvat, identific i descriu cele observate
(de ex. defectele) produsului revizuit. Dup cum am menionat mai sus inspectorii trebuie alei s
reprezinte diferite perspective n procesul de revizuire i s participe la orice ntrunire a
inspectorilor.
Secretar (grefier): acesta particip la ntrunirile revizorilor i documenteaz toate
problemele, defectele i prile discutabile care au fost depistate.
Un rol indirect asociat cu revizuirea e cel al testorului. El deine un rol aparte n relaia cu
documentul reexaminat. El va fi solicitat s analizeze documentul pentru a permite dezvoltarea
testului. La analiza documentului acesta testorul va stabili scenariul, va nota dac este vreo lacun
n cerine care ar stopa funcionarea produsului, aa ca lipsa unui proces sau absena unor date la
momentul dat. Efectiv testorul ar putea fi invitat oficial al activitii de revizuire sau ar putea
renuna la acesta.
Tipurile de revizuire
Un singur document poate fi supus mai multor tipuri de revizuire: de exemplu o revedere
informal poate precede o analiz tehnic, sau depinde de gradul de risc, revizia tehnic sau
inspecia se poate aplica naintea controlului mpreun cu cumprtorul.
Fiecare tip de revizuire are caracteristicile sale. Am identificat patru tipuri de analiz care
definesc gradul de formalitate. Acestea sunt cunoscute ca :
1. Revizuire neoficial ( cea mai puin formal). Caracteristici:
Nu exist un proces oficial care ar motiva revizuirea.
Revizuirea ar putea fi documentat, dar nu se cere aceasta; multe reexaminri neoficiale
nu se documenteaz.
Se pot produce unele modificri (depinde de revizor) pentru eficacitatea revizuirii, de
exemplu revizorul nu posed abiliti tehnice, doar este mputernicit s verifice repede
i s asigure semnificaia documentului.
Scopul principal const n depistarea defectelor, i aceasta este o modalitate
necostisitoare pentru a nregistra unele beneficii.
35

 Revizuirea poate fi implementat de o pereche de programatori (cnd unul verific codul

celuilalt) sau de o abordare tehnic de revizuire a codului i design-ului.
2. Analiza codului. Caracteristici:

ntrunirea e condus de ctre autorul documentului care va fi revizuit i prezentat de

colegii autorului, membri ai aceluiai grup.

Sesiunile de revizuire sunt finisate deschis i pot varia n practic de la informale la

formale.

Pregtirea de ctre revizori nainte de edina de analiz, raportul produsului de

revizuire ori lista cu cele depistate, i ntrevederea cu grefierul sunt aciuni opionale,
care se ndeplinesc uneori.

Principalul scop const n oferirea posibilitii de a studia coninutul documentului, ca

s ajute membrii echipei s neleag coninutul documentului i s gseasc defecte.

Analiza codului de obicei exploreaz scenariul, ori aplic o execuie artificial a codului
ori a procesului.

3. Revizuirea tehnic. Caracteristici:

Este documentat i utilizeaz un proces bine definit de detectare a erorilor care include
att colegi ct i experi tehnici.

Este realizat ca o verificare amical fr participare managerial i este condus de un

moderator, diferit de autor.

Revizorii pregtesc ntrunirea, uneori utiliznd lista de verificare, i un raport al erorilor

depistate.

Revizuirile tehnice pot varia n practic de la informale la formale i au un numr de

obiective, incluznd: dezbaterile, luarea deciziilor, evaluarea alternativelor, depistarea
defectelor, rezolvarea problemelor tehnice i verificarea conform specificaiilor i
standardelor.

4. Inspecia (un grad sporit de formalitate). Caracteristici:

Inspecia este condus de un moderator care nu este autorul i de obicei presupune o

dubl examinare a documentelor; fiecare inspector lucreaz n dependen de rolul
definit.

Procesul de inspectare este oficial, bazat pe reguli i liste cu ntrebri (checklists), i

utilizeaz criteriul de intrare i ieire.

Pregtirile preliminare ntrunirii sunt eseniale, i includ citirea oricror documente

pentru a asigura consistena.

Se ntocmete raportul privind inspecia, cu lista celor depistate, care include date
(metricile) utile la mbuntirea procesului, precum i la corectarea defectelor n
documentul analizat.
36

ntrunirea este urmat de un proces care asigur c aciunea s-a ncadrat n timp i e
definitivat.

n realitate hotarele dintre diferite tipuri de revizuiri sunt vagi. Ceva tratat de o companie
ca o revizie tehnic, e privit de alta ca o inspecie. Aceasta este viziunea clasic asupra revizuirii.
Esenialul pentru fiecare companie este stabilirea obiectivelor i avantajelor revizuirii plnuite.
Factorii care asigur succesul revizuirii.
Cnd contm pe succesul unei revizuiri trebuie s avem n vedere urmtorii factori:

Fiecare revizuire presupune obiective clare prestabilite i acceptate ct i alegerea

persoanelor adecvate pentru desfurare ei astfel asigurnd ndeplinirea obiectivelor.
De ex. n timpul unei inspecii orice revizor va avea un rol definit i trebuie s aib
experien pentru a-i ndeplini funcia.

Orice defect depistat e binevenit i exprimat obiectiv, iar liderul revizor se asigur c
problemele persoanelor i aspectele psihologice sunt tratate adecvat. ( ex. o experien
pozitiv pentru autor i ceilali participani).

Tehnicile de revizuire (formale i informale) trebuie s fie potrivite pentru nivelul i

tipul soft-ului testat i pentru revizori (aceasta este foarte important n inspectri).

Trebuie folosite checklist-le sau rolurile, pentru a spori efectivitatea de depistare a

defectelor; de ex. la o inspecie roluri ca funcionar data entry sau arhitect tehnic pot fi
solicitate la reexaminarea unui document particular.

Suportul managerial este esenial pentru un proces reuit de revizuire (prin acordarea
timpului necesar revizuirii adecvat programului).

Metricile utilizate n testarea static:

Numrul defectelor depistate.

Timpul necesar revizuirii/ inspeciei-

Procentajul bugetului utilizat/ economisit pentru proiect.

n exemplarul su original referitor la inspeciile sale n 1976, Michael Fagan de la IBM,

care a dezvoltat Metodele de Inspectare Fagan, a raportat 23% progres n coding productivity (n
productivitatea codrii) datorit inspeciei. Succesul poate fi obinut prin mai multe modaliti,
totui trebuie mai nti de respectat parametrii care asigur atingerea succesului i mai important
trebuie s se fac raportarea lor unui auditoriu larg.
Analiza static prin diferite mijloace
Asemeni revizuirii, analiza static caut defectele fr a activa codul. Dar spre deosibire
de reexaminare analiza static se desfoar dup ce a fost scris codul. Obiectivul acesteia const
n detectarea defectelor n codul surs i n modelele produsului soft.

37

Codul surs este orice secven de instruciuni scrise n unul din limbajele de programare,
limbaj ce poate fi citit de persoane, i care poate fi convertit apoi ntr-un cod echivalent executabil
pentru computer - creat de dezvoltator.
Un model produsul soft este imaginea unei soluii finale dezvoltate utiliznd tehnici ca
Unified Modeling Language (UML) - Limbajul de Modelare Unificat (LMU); generat de
designerul produsului soft.
Analiza static poate depista defectele dificil de depistat la executarea testului prin
analizarea codului programei, exemplu: instruciunile pot avea forma unui control flow graph
(cum se realizeaz controlul printre module) i data flow ( asigurarea c datele sunt identificate i
utilizate corect).

Importana analizei statice const n:

Detectarea defectelor nainte de executarea testului. Dar referindu-ne la revizuire cu ct

mai devreme se gsete defectul, cu att mai simpl i mai ieftin este nlturarea lui.

Prevenirea unor aspecte suspicioase codului sau design-ului, prin calcularea datelor,
astfel ca msurarea extra-complicat. Dac codul e prea complex poate fi predispus
greelilor sau mai puin dependent de orientarea atribuit codului de ctre developator.
Dac ei neleg c, codul trebuie s fie complex, apoi ei mai mult ca probabil vor verifica
de mai multe ori, dar dac codul este extrem de complex, atunci exist mai multe anse
c el va conine defecte.

Identificarea defectelor depistate cu greu de testarea dinamic, aa ca dezvoltarea

standard a lacunelor. De asemenea detectarea dependenelor i inconsistenelor n
modelele soft, aa ca conexiunile i corelaiile de care nu se tia sau erau incorecte pn
la realizarea analizei statice.
38

mbuntirea ntreinerii codului i design-ului. Prin realizarea analizei statice se vor

nltura defectele i va spori mentenana necesar dup nfiinare. Pot recunoate de
asemenea un cod complex care corectat l-ar face mai simplu de neles i mai uor de
ntreinut.

Prevenirea defectelor. Prin identificarea defectelor n primele etape ale ciclului de

dezvoltare e cu mult mai uor de identificat cauza original (analiza cauzei de baz ( root
cause analysis) dect n timpul execuiei testului, astfel furniznd informaie despre
posibilele mbuntiri ale procesului care ar putea preveni reapariia aceluiai defect .
Descoperirea defectelor prin utilitarele analizei statice:

Referirea la o variabil cu o valoare nedefinit - utilizarea variabilei ca o component

a calculelor nainte ca variabila s primeasc o valoare.

Corelarea inconsecvent dintre module i componente, ex. modulul X cere trei valori
de la modulul Y, care are doar 2 rezultate (outputs).

Variabilele care nu sunt utilizate niciodat. Nu au erori stabile, dar dac programatorul
declar o variabil n program i nu se folosete de ea, aceasta presupune ca unele pri
necesare ale programei s fie ntmpltor omise.

Inaccesibilitatea codului. Aceasta presupune liniile codului care nu pot fi realizate

deoarece logica programei nu aduce nici un drum n care este inclus acest cod.

Nerespectarea standardelor programrii, dac standardele prevd adugarea

comentariilor doar la sfritul unei pri a codului, dar exist explicaii prin tot codul,
aceasta va fi o violare a standardelor codului.

Vulnerabilitatea securitii, exemplu: structurile password care nu sunt sigure.

Violarea sintaxei codului i modelelor soft, de exemplu utilizarea incorect a limbajului

de programare sau de modelare.

Mijloacele analizei statice au mai mult valoare utilizate mpreun cu testarea

componentelor i testarea de integrare. Aceasta presupune verificarea de ctre dezvoltatori
conform regulilor predefinite ori standardelor de dezvoltare i de designeri n timpul modelrii
soft-ului.
Mijloacele analizei statice se desfoar automat i raporteaz toate defectele identificate.
Unele dintre ele pot fi nesemnificative i necesit puin efort pentru rectificare, pe cnd altele mai
serioase solicit corectarea imediat. Aceste defecte necesit un important management pentru a
se asigura c s-a obinut un beneficiu deplin datorit utilizrii mijloacelor n primul rnd.
Compilatoarele soft-ului sunt programele computerului (sau un set de programe) care traduc codul
scris n unul din limbajul computerului (limbajul int). Ca parte a procesului de compilare, desigur
analiza static ntreprinde identificarea unor defecte i va furniza calculele metrice ale soft-ului.

39

Dup caracterul su erorile n cod se mpart n: erori de sintax i erori de semantic

(logice);
Erorile de sintax sunt neajunsuri, neclariti n scrierea codului, ce sunt legate du
introducerea eronat a instruciunilor, scrierea incorect a identificatorilor i alte4 aciuni
incorecte. Eroarea de sintax este gsit foarte rapid de ctre compilator, deoarece compilatorul
va genera produsul program doar n cazul nd n cod vor lipsi erorile de sintax. Deci, erorile de
sintax, n produsele program, sunt depistate n mod automat n procesul de compilare.
Erorile semantice sunt erorile n logica lucrului programului. Codul produsului program
poate arta absolut corect, dar n acelai timp s lucreze incorect. Astfel de erori sunt depistate i
corectate destul de dificil. Erorile logice deseori sunt legate cu realizarea incorect a algoritmului
programului (de exemplu n loc de c+b a fost scris c-b, a fost admis necorespondena intern
dintre variabile i operatori, ct i a regulilor generale de programare). Formele de baz a erorilor
logice:

Programul ntr-un moment anumit nu mai poate prelungi executarea ( apare aa numita
ntrerupere forat a programului, de obicei cu indicarea locului n program, care a
generat aceast ntrerupere);

Programul funcioneaz, dar nu afieaz toate rezultatele planificate sau nu se oprete

(are loc ciclarea programului);

Programul afieaz rezultatele i finiseaz lucrul, dar aceste rezultate corespund parial
sau totalmente nu corespund cu rezultatele de
control;

Cele mai frecvente tipuri de erori pot fi depistate cu

ajutorul mediilor de programare. Pentru aceasta n setrile
proiectului se stabilesc anumii parametri: controlul ieirii
indicilor din limitele masivului, controlul erorilor de
intrare/ieire,

adugarea

informaiei

de

depnare,

vizualizarea structurii codului .a. De exemplu fereastra

opiunilor proiectului n mediul DELPHI:
Dup identificarea erorilor logice i eliminarea cauzelor apariiei acestora n program se
efectueaz coreciile corespunztoare, i depanare continu din nou. i acest lucru este repetat de
mai multe ori. Cu toate acestea, chiar i n procesul de depanare nu este ntotdeauna posibil s se
identifice toate erorile.
n prezent pentru reducerea timpului i a costurilor pentru desfurarea testrii se folosesc
mijloace speciale de testare (de exemplu: generatoare de date de testare) i metode de depnare

40

(cum ar fi trasarea programului, ce permite s verificam, dac toate ramurile programului au fost
implicate n rezolvarea problemei cu setul de date iniial).
n mediul Visual Studio (redacia Ultimate) exist instrumentul de analiz arhitectural:
Arhitecture Explorer, care permite crearea i vizualizarea grafurilor diagramelor aplicaiei.
Analiza metricilor codului aplicaiei i multe alte faciliti pentru analiza static a codului
aplicaiei.

TEMA 8: Mentenana i documentarea procesului de testare

Unitatea de nvare : Descrierea tipurilor de testare
Mentenana produsului soft presupune finalizarea dezvoltarii produsului prin predarea
documentaiei, soluionarea disfuncionalitilor sesizate n etapa anterioar, sesiuni de training cu
viitori utilizatori sau realizarea de tutoriale pentru a crete gradul de accesibilitate al produsului.
De asemenea, dezvoltatorii unui produs soft vor oferi suport celor care l utilizeaz de-a lungul
timpului pentru a asigura buna sa funcionare i a repara eventualele erori aprute. n plus, este
posibil mbuntirea unui produs soft, caz n care documentaia original va fi necesar.

Cauze ce pot duce la apariia defectelor in produsul soft:

Nimeni nu este perfect, oricine poate face greeli

Presiunea crescut poate duce la greeli

Restriciile de timp i buget

Pregatirea slab, comunicarea ineficient

Cerine slabe

Specificaii incomplete

Dac se oprete testarea prea devreme, se risc apariia de erori la rularea propriu-zis a sistemului.
Dac testarea continu pentru o perioad prea lung se poate amna lansarea produsului, fapt ce
poate duce la degradarea imaginii companiei sau chiar pierderi de venituri.
Corectarea erorilor descoperite pe parcursul integrrii necesit repetarea procesului de
proiectare, codificare i testare a modulelor. Principalele erori de proiectare sunt descoperite de
abia la sfrit, cnd sunt testate modulele principale ale programului, ceea ce conduce la
reproiectare i reimplementare. Scopul primordial pentru procesul de testare este identificarea
erorilor de produse soft, izolarea i corectarea defectelor care au cauzat aceste erori. Este un
exerciiu non-trivial, deoarece testarea nu poate demonstra cu certitudine de 100 % c produsul
41

funcioneaz corect n orice condiii; testarea doar poate demonstra c produsul nu funcioneaz
corect n anumite condiii.
Testarea regresiv prezint testele executate dup corectarea erorilor, pentru a se verifica dac n
cursul corectrii nu au fost introduse alte erori. Aceste teste sunt efectuate de regul n timpul
ntreinerii. Pentru uurarea lor este necesar s se arhiveze toate testele efectuate n timpul
dezvoltrii programului, ceea ce permite, n plus, verificarea automat a rezultatelor testelor
regresive. Testarea regresiei reprezint testarea unui program testat anterior care a suferit
modificri pentru a se asigura c nu au fost introduse sau ascunse defecte ca rezultat a modificarilor
fcute. Acest tip de testare este realizat atunci cnd este schimbat soft-ul sau mediul. Msura n
care se realizeaz testarea regresiei este bazat pe riscul negsirii defectelor n soft-ul care a
funcionat anterior. Acest tip de testare este la toate nivele de testare. Testrile sunt necesar de
reluat atunci cnd se verfic actualizrile soft-ului. Aceste teste trebuie reluate atunci cnd se
semnaleaz o modificare n produs soft sau mediu i sunt utilizate pentru a se dovedi c nu au fost
schimbate aspecte ale sistemului sau componentelor. Selecia cazurilor de test pentru testarea
regresiei cuprinde:

Teste care acoper funcii critice de securitate

Teste pentru arii care se schimb n mod regulat

Teste ale funciilor care au nivel mare de defecte

*Testarea
regresiei
reprezint
un
candidat
ideal
pentru
Automatizare.
Testarea regresiva se efectueaza pentru a ne da seama daca o schimbare aplicata unui produs soft
reprezinta
un
pas
inapoi
sau
un
pas
inainte.
Ea se foloseste pentru a determina daca o schimbare nu cumva aduce mai mult rau decat bine: daca
acea
schimbare
duce
la
regres
sau,
dimpotriva,
la
progres.
Testarea regresiva se efectueaz pentru a vedea dac schimbrile aduse unei componente a
produsului soft au creat noi defecte sau au redus fiabilitatea, performanta sau funcionalitatea
produsului soft din care face parte componenta respectiva.
BUG (defect, greeal, problem) - este un defect ntr-un sistem sau o component care cauzeaz
ca sistemul sau componentele respective s nu reueasc s i ndeplineasc funcia. Un defect,
dac este ntlnit la execuie, poate avaria ntregul sistem.
Termenul de bug este adesea folosit pentru a descrie o problem ntr-un calculator. Exist dou
tipuri de bug-uri: cele de produs soft i cele de hardware. n aceast privin testarea produsului
soft nu ar trebui asociat cu debugging. Debugging-ul este procesul de analiz i localizare a
bugului atunci cnd produsul nu se comport conform ateptrilor. Erorile de programare n
produsul soft, aa-numitele bug-uri, au cauzat de-a lungul timpului pagube uriae, de la pierderea
de viei omeneti n aplicaii militare pn la milioane i miliarde de dolari pe burs sau n misiuni
de explorare a spaiului.
Managementul proiectelor reprezint o nou tiin, rezultat al sintezei unor domenii diferite,
avnd ca obiectiv maximizarea eficienei sociale, indiferent de produsul/serviciul ce trebuie
realizat.
Obiectivul de baza al managementului de proiect este minimizarea risipei generate de serviciile
asupra unor operaii ncheiate, inserarea de operaii noi ntre operaii executate, repetarea execuiei
de operaii, gestiunea riscului i meninerea sub control a elementelor de noncaliti. Toate acestea
se concretizeaz prin definirea de termene, durate, cantiti, niveluri de calitate, momente de start
i de fini, durate i obiective de stationare.
42

n dezvoltarea unui proiect, se iau n considerare aspectele structurilor organizaionale, constituirea

echipelor, funciile de management, aspectele conflictuale, tehnicile de planificare i variabilele
care intervin, alocarea, nivelarea i ncrcarea resurselor pe traseul de tip graf i abordrile n plan
economic prin intermediul preurilor estimate, controlului costurilor i, mai ales, prin dezvoltarea
unor tehnici de analiz.
Realizarea unui proiect i managementul acestuia sunt procese dinamice, care se conecteaz i a
cror eficien trebuie urmarit continuu, analizndu-se latura calitativ i latura cantitativ a
procesului de desfurare, n raport cu coninutul contractelor ncheiate.
Planificarea testelor se realizeaz n strns legtur cu planificarea derulrii proiectului. In faza
de planificare a proiectului pentru testare se aloc resurse, specificndu 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.
Istrumente de urmrire a bug-urilor
Sistem de bug tracking - O aplicaie soft care are ca rol uurarea bug tracking-ului (este o metod
eficient centralizat i uor utilizabil.) Exist soluii gratuite, dar i soluii enterprise cu preuri
foarte ridicate. Un sistem de bug tracking este un subtip de sistem de issue tracking.
Sistem de issue tracking - O aplicaie soft care are ca rol centralizarea i adresarea tuturor cererilor
legate de unul sau mai multe produse, de la probleme la schimbri de design i aplicri de patchuri. Cele mai multe sunt n acelai timp i bug trackere. n general, sunt mai complexe dect bug
trackerele.
TEMA 9: Testarea non-funcional
Unitatea de nvare : Descrierea tipurilor de testare
Calitatea unui produs este uneori definita ca totalitatea caracteristicilor sale prin care el
satisface o serie de necesitati definite sau impuse.
Calitatea unui produs soft este data de capacitatea sa de a putea fi utilizat eficient, efectiv si
confortabil, de catre un set de utilizatori, pentru un set de scopuri, in conditii specificate .
Caracteristicile de calitate ale unui produs soft sunt proprietati ale produsului la care utilizatorii
sunt sensibili. De exemplu : usurinta de utilizare, fiabilitatea, timpul de raspuns, s. a.
Exista diferite modele de clasificare a caracteristicilor (atributelor) de calitate ale unui produs soft.
Modelele includ adesea si masuri pe baza carora se stabileste gradul in care produsul intruneste
fiecare atribut de calitate. Fiecare model poate avea un set de atribute diferit la nivelul cel mai inalt
al clasificarii, de asemenea selectia si definitiile atributelor pot sa difere la toate nivelele.
Calitatea ceruta pentru un produs soft trebuie sa fie definita in documentul de definitie a cerintelor
ctre produsul soft (SRD). De asemenea, trebuie specificate definitiile atributelor de calitate,
metodele de masurare si criteriile de acceptare pentru atribute.
1. Caracteristici de calitate ale produselor soft
Incercarile de standardizare a terminologiei referitoare la calitatea produselor soft au condus la
standardul ISO 9126 (InformationTechnology Sofware Product Quality, Part 1: Quality Model,
1998). Standardul contine definitii in special pentru produsul final.
Sunt definite 6 caracteristici de calitate, impartite in 21 de subcaracteristici.
1) Functionalitatea: realizarea scopului de baza pentru care a fost realizat produsul
43

Oportunitatea: prezenta unui set de functii adecate pentru tascuri specificate

Precizia: furnizarea unor rezultate sau efecte corecte sau agreate

Interoperabilitatea: capacitatea produsului de a interactiona cu sisteme specificate

Securitatea: capacitatea de a preveni accesul neautorizat, accidental sau deliberat, la

programe sau date

Conformitatea: adeziunea la standarde, conventii, legi si protocoale

2) Fiabilitatea: capacitatea produsului de a-si mentine nivelul de performanta, in conditii definite,

pentru o perioada de timp definita.

Maturitatea: atribut bazat pe frecventa caderilor datorate greselilor in produsul soft

Toleranta la defecte (robustetea): capacitatea de a-si mentine un nivel de perfomanta

specificat in cazuri de caderi a produsului soft sau intrari neasteptate

Restabilirea dupa caderi: capacitatea si efortul necesar pentru restabilirea nivelului de

performanta, recuperarea datelor afectate, dupa posibile caderi

Conformitatea

3) Utilizabilitatea: efortul necesar pentru utilizarea sa de catre un set de utilizatori definit

Usurinta de intelegere: efortul solicitat unui utilizator de a recunoaste conceptul logic si

aplicabilitatea sa

Usurinta de invatare : efortul solicitat unui utilizator de a invata aplicatia, operarea,

intrarile si iesirile

Operabilitatea: usurinta de operare si de control de catre utilizatori

Puterea de atractie: capacitatea produsului de a fi atragator pentru utilizatori

Conformitatea

4) Eficienta: relatia intre nivelul de performanta al produsului si cantitatea de resurse utilizate, in

conditii definite

Timp la executie: viteza de raspuns, timpi de prelucrare, rata iesirilor la realizarea

functiilor

Utilizarea resurselor: cantitatea de resurse utilizate si durata utilizarii pentru realizarea

functiilor sale

Conformitatea

5) Usurinta de intretinere: efortul necesar pentru efectuarea modificarilor, inclusiv corectii,

imbunatatiri sau adaptari ale produsului la schimbari ale mediului de functionare, a cerintelor si
schimbarilor functionale

Usurinta de analiza: efortul necesar pentru diagnoza defectelor, a cauzelor caderilor,

pentru identificarea partilor care trebuie sa fie modificate

Usurinta de modificare: efortul necesar pentru inlaturarea defectelor sau schimbari

Stabilitatea: riscul efectelor neasteptate in urma modificarilor

Usurinta de testare: efortul necesar pentru a valida produsul modificat

44

Conformitatea

6) Portabilitatea: capacitatea produsului de a fi transferat de la o organizatie sau platforma soft/

hardware la o alta

Adaptabilitatea: capacitatea de adaptare la diferite medii specificate

Usurinta de instalare: efortul necesar pentru instalarea produsului intr-un mediu

specificat

Co-existenta: capacitatea de a co-exista cu alte produse independente in acelasi mediu

Oportunitatea si efortul necesar pentru a folosi produsul in locul altui produs intr-un mediu
particular

Conformitatea

Tipuri speciale de sisteme si cerintele de calitate

Exista multe cerinte de calitate particulare care se incadreaza sau nu in cele din ISO 9126.
Anumite clase speciale de aplicatii pot avea si alte atribute de calitate de considerat.
Exemple :
Sisteme ale caror caderi pot avea consecinte extrem de severe:

Gradul de incredere al sistemului in ansamblul sau (hardware, software, oameni) este

scopul principal, in plus fata de cel de realizare a functiilor de baza

Un grad inalt de incredere include atribute ca: toleranta la defecte, siguranta I functionare,
securitatea, utilizabilitatea.
Sisteme inteligente si bazate pe cunostinte:

Proprietatea oricand (garanteaza raspunsul cel mai bun care poate fi obtinut intr-un timp
dat daca se cere un raspuns in intervalul de timp respectiv)

Capacitatea de explicare ( explica procesul de gandire la furnizarea unui raspuns).

Sisteme de interfata cu omul si de interactiune

o

Usurinta de adaptare la trasaturile si interesele utilizatorilor, Help inteligent,

s.a.

Sisteme informationale
o

Usurinta de interogare

Precizie in furnizarea raspunsurilor (numai informatia relevanta)

Caracteristici de calitate a produsului soft, care afecteaza procesul de inginerie a produsului

Stilul codului

Reutilizabilitatea codului

Modularitatea codului si independenta modulelor

2. Asigurarea calitatii produselor soft

Rolul activitatilor de asigurare a calitatii produseelor soft este de a stabili ca produsele si
procedurile sunt in conformitate cu standardele si planurile.
45

In proiectele mici asigurarea calitatii poate fi efectuata de echipa de dezvoltare, dar in proiectele
mari trebuie sa fie realizata de o echipa speciala.
Activitatile de asigurare a calitatii sunt documentate in Planul de Asigurare a Calitatii (Software
Quality Assurance Plan (SQAP).
Prin activitatile de asigurare a calitatii se urmareste:

Concordanta planurilor cu standardele

Realizarea proceselor in concordanta cu planurile

Implementarea produselor in concordanta cu planurile

Verificarea si validarea produsului soft sunt de asemenea activitati de asigurare a calitatii.

Ce este un sistem de asigurare a calitii
Ansamblul activitilor care trebuie ntreprinse pentru ca un produs s fie de calitate
Ce acoper un Sistem de Asigurare a Calitii:
a) Activitile propriuzise de inginerie
- analiza;
- proiectarea (concepia);
- codificarea
- testarea (metode i instrumente)
b) Reviziile aplicate la fiecare pas al proiectului,
c) Strategiile de testare,
d) Controlul documentaiei a produsului soft i a susinerii ei actuale,
e) Compatibilitatea cu standardele (dac este cazul),
f) Mecanismele de msurare i raportare (pentru a avea o msur cantitativ a calitii)

TEMA 10: Tehnica de testare Black Box

Unitatea de nvare: Particularitile testrilor
Tehnicile de proiectare a cazurilor de teste (case test) sunt grupate n trei categorii:

Cele bazate pe cazuri de testare care rezult direct dintr-o specificaie, cum ar fi tehnici
black-box;

Cele bazate pe cazuri de testare care deriv direct din structura unei componente sau a unui
sistem, cunoscut sub numele de tehnici de structur white-box;

Cele bazate pe cazuri de testare care rezult din experiena testerului, sistemelor similare
i experiena general de testare, cunoscut sub numele de tehnici bazate pe experien.

Black Box
Testarea domeniilor de valori, testarea funcional, testarea bazat pe specificaii, testarea axat
pe riscuri, testarea la limit, testarea de regresie, testarea bazat pe scenarii.
Este o tehnic de testare a produsului soft care se bazeaz n ntregime pe cerinele fa de produs
i specificaiile acestuia.
Tipuri de testare Black Box

Testarea funciilor (function testing);

Testarea domeniilor de valori (domain testing);

Testarea bazat pe specificaii;

46

Testare axat pe riscuri (risk-based testing);

Testarea la limita (stress testing);

Testarea de regresie;

Testarea de ctre utilizatori;

Testarea bazata pe scenarii;

Testarea bazata pe stri (state-model-based testing);

Testarea automata de volum ridicat;

Testarea prin explorare;

Partiionarea n clase de echivalen

Intrrile sistemului sau al produsului soft sunt mprite n grupuri pentru care se ateapt
un comportament similar;

Identificarea de partiii echivalente (sau clase) pentru: date valide i date invalide;

Se aplic i pentru: ieiri, valori interne, valori cu referire la timp (ce se modific nainte
sau dup apariia unui eveniment), parametri ai interfeei;

EP este utilizat la toate nivelele de testare;

Pentru un interval: va avea o clas de valori valide(n interior) i dou clase de valori
invalide(din ambele pri);

Pentru un numr specificat: un caz valid i dou cazuri invalide(mai mare, mai mic)

Testarea prin analiza valorilor marginale

Se analizeaz comportamentul la marginea fiecrei partiii de echivalen.

Testele trebuie create att pentru valorile limit valide ct i invalide!

Tehnica poate fi aplicat la toate nivele de testare.

Testarea prin utilizarea tabelului decizional;

Definiie: Un tabel de decizie este formularea cazurilor de test bazat pe deciziile luate; rezult
astfel un proces de lucru cu un grad ridicat de acuratee i completitudine.
Funcionalitatea sistemului este verificat de cazurile de test bazate pe logica de decizie din cadrul
sistemului. Numrul cazurilor de test depinde de cerine.
Utilizare: Unit testing, Integration testing, System testing, Functional acceptance testing
Pasul 1: Determinarea condiiilor. Acestea se trec n subtabelul A a tabelului.
Pasul 2: Definirea aciunilor. Acestea se trec n subtabelul B.
Pasul 3: Completarea subtabelului C fiecare condiie devine adevarat o data i fals o dat.
Pasul 4: Completarea subtabelului D determinarea deciziilor care sunt imposibile i combinarea
cazurilor de test duble.
Pasul 5: Dac este necesar, descrierea n limbaj natural a cazurilor de test.
Testarea prin tranziia strilor;

Sistemul este reprezentat printr-o diagram de tranziie a strilor;

Strile sistemului sunt finite i identificabile.

47

Testarea folosind cazuri de utilizare

Teste specificate n cazuri de utilizare sau scenarii business;

Un caz de utilizare descrie interaciunea ntre actori - utilizatori i sistem, ce produce un

rezultat cu o anumit valoare pentru utilizator;

TEMA 11: Tehnica de testare white-box

Unitatea de nvare: Tehnici de realizare a testrii
TEMA 11: Tehnica de testare white-box.
Competene elementare formate n cadrul modului:
Tehnici de realizare a testrii.
Abiliti formate:
A15. Verificarea datelor de intrare.
A16. Verificarea corectitudinii procesrii datelor;
A17. Verificarea datelor de ieire;
A18. Verificarea completitudinii prelucrrii datelor;
A19. Verificarea funcionrii corecte a ansamblului;
A20. Verificarea compatibilitii componentelor;
A21. Depistarea erorilor de depnarea a programelor;
A22. Verificarea mecanismelor de protecie.
A23. Verificarea stabilitii produselor-program.
A24. ntocmirea documentaiei rezultatelor testrii;
A25. Verificarea performanelor produsului-program;
A26. Verificarea funcionalitii produselor-program pe diverse platforme;
Termeni cheie:
Testare structural;
Testare Whte-Box;
Graf;
Controlul fluxului;
Complexitatea ciclomatic;
Formula lui McCabe.
Obiective: Realizarea testrii prin metoda White-Box.
Tehnica de testare White-Box (mai este numit cutie transparent,) este o tehnic de testare
complementar metodei cutiei negre. n principiu, prin aceast metod testul se elaboreaz
examinnd detaliile programului: instruciuni, date etc. Ea poate fi utilizat independent sau
mpreun cu metoda cutiei negre.
Dificultile n aplicarea acestei strategii sunt legate de prezena instruciunilor de decizie
(if, case etc.), a celor iterative (while, repeatj sau a celor de transfer (goto). Acestea determin
48

apariia unui mare numr de combinaii n care instruciunile elementare ale programului (atribuiri,
instruciuni de intrare/ieire, apeluri de proceduri) pot fi executate. Ideal ar fi ca testul s solicite
executarea fiecrei combinaii posibile cel puin o dat. Din punct de vedere practic acest lucru nu
este realizabil, chiar n cazul programelor de dimensiune relativ mic. De pild, n cazul
while a do
if b then M
else P
dac se execut n iteraii, sunt posibile 2n combinaii n care se execut instruciunile M i P. n
testare exhaustiv ar trebui ca setul de date s conin 2n eantioane.
n realitate nu se testeaz dect un numr limitat de astfel de combinaii, considerate mai
importante. n stabilirea acestui numr de combinaii se utilizeaz diferite criterii de acoperire,
dintre care cele mai importante sunt:
1)

acoperirea tuturor instruciunilor;

2)

acoperirea tuturor ramurilor;

3)

testarea condiiilor:
testarea condiiilor de ramificare;
testarea combinaiilor condiiilor de ramificare;

4)

acoperirea tuturor cilor.

1.1. Acoperirea tuturor instruciunilor:

Acest criteriu se bazeaz pe observaia evident c o eroare nu va fi descoperit dac nu se
execut deloc instruciunile ce o conin. Prin urmare, testul trebuie s fie astfel ales nct pentru
fiecare instruciune elementar a programului s existe un eantion de date care s provoace
executarea sa.
Este clar ns c testul nu garanteaz semnalarea erorii.

Testele ce satisfac acest criteriu sunt n general

49

neconcludente deoarece acelai eantion de date poate provoca executarea mai multor instruciuni;
este deci foarte probabil s putem minimiza numrul eantioanelor din test, meninnd criteriul de
acoperire a instruciunilor.
Pentru a trece prin toate nodurile, laturile grafului vor trebui traversate n urmtoarea
ordine:

a, b, f, g, h, d, e
Criteriul de completitudine a testului:
Acoperirea_instruciunilor = (numr_instruciuni_executate/numr_total_instruciuni)*100%

Este cel mai slab dintre testele white-box deoarece poate lsa nedetectate multe
defecte.
1.2 Acoperirea tuturor ramurilor.
Condiiile din instruciunile de decizie i iterative provoac ramificri la executarea
programului. Dup cum acestea sunt adevrate sau false. Aceste ramificri pot fi puse n eviden
prin aa numitul graf de control al programului. Acest graf poare fi construit inductiv pentru
programe ce conin instruciuni elementare (adic atribuiri, instruciuni de intrare/ieire, apeluri de
proceduri), instruciuni de decizie (if - then - else, if - then) i instruciuni iterative (while, repeat
etc.).
Criteriul de acoperire a tuturor arcelor cere ca testul s fie astfel ales nct pentru orice
arc din graf (multigraf) s existe eantioane care s provoace parcurgerea ramului la executarea
programului.
Observaie 1. Criteriul de acoperire a tuturor arcelor este mai tare dect criteriul de
acoperire a tuturor instruciunilor.
Observaie 2. Criteriul de acoperire a tuturor arcelor are calitatea c impune alegerea unui
test care s provoace evaluarea fiecrei condiii cel puin o dat att cu rezultatul true ct i cu
rezultatul false.
Exemplu:
-

se observ c n testul din exemplul precedent ramurile c, i, k nu au fost testate;

pentru a acoperi i aceste ramuri, este necesar s mai fie executate urmtoarele teste:

a, b, c, d, e;

a, b, f, g, i, h, d, e;

a, k, e.
Apare o anumit redundan datorit necesitii de a parcurge anumite ramuri n cadrul mai

multor teste, dar acest lucru nu poate fi n general evitat;

Acoperirea_ramurilor =(Numrul_ramurilor_testate/Numrul_total_al_ramurilor)*100%

Este un criteriu mai bun dect acoperirea instruciunilor deoarece garanteaz i acoperirea
acestora, dar preul de cost este mai mare.
50

Permite testarea tuturor condiiilor simple dar nu implic neaprat testarea condiiilor
complexe.
1.3 Acoperirea tuturor condiiilor simple
n cazul cnd n program exist condiii compuse de forma C and D sau C or D, acoperirea
tuturor arcelor nu conduce totdeauna la evaluarea condiiilor C i D att cu rezultatul false ct i
cu rezultatul true.
Este util prin urmare s considerm un criteriu mai tare dect cel al acoperirii tuturor arcelor, prin
care se cere ca testul s acopere toate arcele i s asigure evaluarea tuturor condiiilor simple att
cu rezultatul true ct i cu rezultatul false. Acest criteriu este echivalent cu acoperirea tuturor
arcelor, dac programul conine doar condiii simple, n care nu apar operatorii logici and sau or.
Cazuri particulare:
1. Se formuleaz urmtorul criteriu, numit acoperire multipl a tuturor condiiilor simple:
testul trebuie s asigure evaluarea condiiilor simple cu rezultatul true i false n toate
combinaiile cerute de structura condiiei compuse n care ele apar. De pild, n cazul C and D se
obine pentru perechea de condiii simple (C, D) patru combinaii: (false, false) , (false, true) etc.
Acest criteriu este strict mai tare dect acoperirea tuturor condiiilor simple.
Exemplul. Fie instruciunile
if (x <> 0) and (y <> 0) then z :=
1 else z := 1 / (xy + x + y)
Testul { (x = l, y = 0) ; (x = 0, y =1); (x =l, y =l)} acoper toate condiiile simple dar nu
provoac evaluarea (false; false). El este de altfel neconcludent. Eroarea este descoperit chiar prin
eantionul (x = 0, y = 0) care adugat la testul considerat acoper multiplu toate condiiile simple.
Pentru acest program, acest criteriu este mai bun dect acoperirea tuturor condiiilor simple.
2. Se consider un program P n care executarea este dirijat doar prin expresii logice
(condiii), alte mecanisme (precum instruciunea case) sunt excluse. Fie C1, ..., C toate condiiile
care apar n P. Se consider toate sistemele de valori logice w = (v1, ., v), unde vi e {true, false}
pe care le pot lua aceste condiii. Se formuleaz urmtorul criteriu, numit acoperirea tuturor
atribuirilor logice: testul trebuie s asigure evaluarea condiiilor astfel nct s se obin toate
sistemele w. Acest criteriu este strict mai tare dect acoperirea tuturor arcelor.
Exemplul 2. Fie instruciunile
if x = 0 then z : = 0 else z := l;
if y = 0 then z := 0 else z := l / (x + y)
Testul { (x = 0, y = l) ; (x = l, y = 0) } acoper toate arcele dar nu acoper toate atribuirile
logice; sistemele (true, true) i (false, false) nu sunt evaluate. Testul trebuie completat cu alte dou
eantioane, de pild (x = 0, y = 0) i (x = 1, y = l). Primul face ca testul s devin concludent
(criteriul este mai bun).
1.4 Acoperirea tuturor drumurilor
n conformitate cu acest criteriu, pentru fiecare drum al grafului de control testul conine
eantioane prin prelucrarea crora executarea programului s urmeze drumul ales.
Acest criteriu este strict mai tare dect cele prezentate nainte i exprim un deziderat greu
de realizat n practic datorit instruciunilor iterative. Criteriul poate fi ns aplicat n forme mai
slabe, selectnd pentru testare doar anumite drumuri considerate critice. Dei aceast selecie este
dependent de problem, ea poate fi totui ghidat de sugestia ca datele de test s provoace
parcurgerea unor drumuri ce corespund:
numrului minim de iteraii (adic nici o iteraie n cazul while i o iteraie n cazul
51

repeat);
numrului maxim de iteraii;
numrului mediu de iteraii, dac acesta poate fi stabilit ntr-un fel oarecare; n caz
contrar se accept o executare cu un numr semnificativ de iteraii.
Exemplul 3. S considerm cazul unui algoritm de cutare secvenial a unei valori x
printre componentele v[i] , . . .v[n] ale vectorului v. Se presupune 0 < n < dmax.

const
dmax
type index = 1..dmax;
numar_componente
=
element
=
vector
=
array[index]
of
function secvential ( x : element; v : vector; n : numar_componente ) :
var gasit : boolean;
pozitie
:
begin
gasit := false; pozitie := 1;
while (not gasit) and (pozitie < n) do
begin
gasit := (v[pozitie] = x ) ;
pozitie
:=
pozitie
+
1
end;

=100;
0..dmax;
integer;
element;
boolean;
index;

while (not gasit) and (pozitie < n)

Fig. 1.
Graful asociat acestui algoritm este prezentat n figura 1.
TESTARE: Este important ca setul de date de test s asigure:
-

parcurgerea drumului n care instruciunea while nu este executat (n = 0);

parcurgerea unui drum n care instruciunea while se execut n zero iteraii (n = i);

- parcurgerea unui drum n care instruciunea while se execut n cteva iteraii, distingnd
situaiile n care x face sau nu parte din secvena v[1]. . .v [n] .
Considerm testul :
Nr.

Rezultat

10

()

10

(10)

10

(10, 20, 30)

20

(10, 20, 30)

52

30

(10, 20, 30)

(10, 20, 30)

(10)

Acesta este un test concludent, deoarece n cazurile 2 i 5 este semnalat o eroare. Aceste
eantioane au valoarea x pe ultima poziie a vectorului. Depanarea algoritmului const n
nlocuirea condiiei (poziie < n) prin (poziie <=n).
2. Numrul ciclomatic al grafului fluxului de control
Nici o discuie la testarea fluxului de control poate fi ncheiat fr a prezenta testarea
structurilor, cunoscut i sub numele de testarea cilor principale. Testarea structurat este bazat
pe munca de pionier al lui Tom McCabe. Aceasta folosete analiza topologiei grafului fluxului de
control pentru a identifica cazuri de teste.
Procesul de testare structural const din urmtorii pai:
Extragem graful fluxului de control din modelul produsului soft;
Calculam numrul ciclomatic al grafului (C);
Selectm un set de C ci de baz;
Cream un caz de testare pentru fiecare cale de baz;
Executam aceste teste.
Complexitatea ciclomatic, calculat cu formula lui McCabe:
1.
2.
3.
4.
5.

V(G)=E-N+2
unde:
E - numrul ramurilor din graf;
N - numrul nodurilor grafului.
Numrul Ciclomatic este exact numrul minim de ci independente, ci fr bucle (numite
ci de baz) care pot, n combinaie linear, s genereze toate cile posibile dintr-un modul. n
termeni de flux grafic, fiecare cale de baz traverseaz mcar o ramur pe care no traverseaz
celelalte ci.
Tehnica de testare McCabe creeaz C cazuri de testare, cte unul pentru fiecare cale. Acest
set de teste garanteaz att acoperirea pe instruciuni ct i pe ramuri. Seturile de ci de baz nu
sunt neaprat unice.
Exemplu Acoperirea cilor.
Fie c avem o funcie ce calculeaz preul n baza mai multor criterii: discount, cantitate.
function calculare_pret(baseprice, specialprice, extraprice, discount: real;
extras: integer): real;
var
addon_discount, res: real;
begin
if (extras >= 3) then addon_discount := 10 else
if (extras >= 5) then addon_discount := 15 else
addon_discount := 0;
res := baseprice / 100.0 * (100 - discount) +
specialprice + extraprice / 100.0 * (100 - addon_discount);
calculare_pret := res;
end;

53

V(G)=14-12+2=4
1. a-b-c-j-k-l-n
2. a-b-c-j-m-n
3. a-d-e-f-i-j-m-n
4. a-d-g-h-i-j-m-n
//testcase 01
price=calculate_price(10000.00, 2000.00,
1000.1. 3.0);
test_ok=test_ok&&(abs(price-12900.00)<0.01); a,
b, c, j, m, n
//testcase 02
price=calculate_price(25500.00, 3450.00,
6000.1. 6.0);
test_ok=test_ok&&(abs(price-12900.00)<0.01);
a, b, c, j, m, n
acoperire_ramuri=6/14*100%=43%
//testcase 03
price=calculate_price(10000.00,
2000.00,
1000.00,0,10);
test_ok=test_ok&&(abs(price-12900.00)<0.01);
a, d, g, h, i, j, k, l, n
//testcase 04
price=calculate_price(25500.00, 3450.00,
6000.00, 6,0);
test_ok=test_ok&&(abs(price-12900.00)<0.01);
a, b, c, j, k, l, n
acoperire_ramuri=12/14*100%=86%
Observaie! Ramurile e i f nu pot fi testate
deoarece nu este posibil ca simultan extras<3 i
extras>=5
Testarea ciclurilor:
Dac ciclul are de la 0 la n iteraii, cazurile de test dezvoltate vor fi:
0 iteraii;
iteraie;
dou iteraii;
k iteraii k<n;
n iteraii
n+1 iteraii (dac este posibil).
Dac ciclul are de la ni la n2 iteraii, se va testa i pentru k=n1 -1.
Dac este posibil, se va testa i pentru n2+1.
Se vor avea n vedere i valori negative ale variabilei de ciclare.
Concluzii:
AVANTAJE

DEZAVANTAJE
Numrul drumurilor poate fi foarte mare

Avantajul principal ncrederea, c

fiecare ramur a codului va fi testat. Trebuie

(ciclurile!) i el nu pot fi testate toate.

Testele selectate pot s nu conin datele

numai s selectm datele corespunztoare.

Acest lucru nu este realizabil la

specifice:
p=q/r se execut corect pentru

testarea black-box. Este imposibil doar

toate valorile, afar de r=0;

54

 y=2*x n loc de y=x^2. Vor trece

numai dup cerinele programului s ghicim

toate strile posibile ale programului.

doare testele: x=0,y=0 i x=2, y=4;

Testarea

White-box

este

bazat

pe

afirmaia, c graful fluxului de date este

corect. Testarea verific numai cile
existente n graf. Dac n graf calea lipsete,
atunci ea nu va fi testat;
Este necesar calificarea corespunztoare a
testorului pentru nelegerea codului iniial
al programului;
Testarea exhaustiv a cilor nu garanteaz
corespunderea
specificate.

55

programului

cerinelor

Exerciii:
Exerciiul 1:
Fie este dat urmtoarea secven de cod:
1. void foo(int a,b,x);
2. {
3. if (a>1 && b==0)
4. x/=a;
5. if (a==2 || x>1)
6. x++;
7. }
Care dintre grafurile reprezentate mai jos corespunde acestei secvene de cod?

56

Exerciiul 2.
Pentru algoritmul de mai jos indicai toate ramurile posibile i toate cile posibile:

57

RAMURI

CALE

58

59

Rspuns:
Exerciiu 1:

60

RAMURI

CALE

1-3-2

1-2-4

1-2

1-3-2-4

2-5-4

1-2-5-4

2-4

1-3-2-5-4

Tema 12: Instrumente de comunicare i planificare a activitilor de testare

Unitatea de nvare 7: Automatizarea testelor. Utilitare pentru automatizarea testelor
Risc - un factor care ar putea duce la viitoarele consecine negative, de obicei, exprimat n
portabilitate i impact.
Riscul se calculeaz:
Nivelul de risc = probabilitatea apariiei riscului * impactul producerii lui
Riscurile proiectului:

Factori organizaionali;

Legate de furnizori;

Legate de specialiti;

Riscurile produsului:

Livrarea produsului cu erori;

Specificaii incomplete;
61

Probabilitatea c un defect poate cauza dezastre unei companii/ persoane;

Aplicaie lipsit de caliti/atribute( funcionaliti, securitate, performan).

Managementul testrii
Testarea independent
Cauza:

Este mai uor de gsit greelile altora dect cele proprii;

Puncte de vedere diferite: Un dezvoltator percepe rezultatul final ca fiind corect, pe cnd
un tester, va considera c orice produs final are greeli i va cuta cu srguin identificarea
i localizarea lor.

Nivele ale testrii independente

Dezvoltatorii;

Testeri independeni ce fac partee din echipa de dezvoltatori;

O echip de testare independent, dintr-un centru de excelen, din aceeai organizaie;

Testeri independeni sau un grup de testeri din mediul de afaceri;

Testeri specialiti, testeri de securitate, testeri de performan;

Testarea n afara proiectului: alt companie, prin contract.

Testarea n companii specializate se face cu scopul de a:

Verifica dac produsul respect specificaiile i standardele prestabilite;

Demonstra eficiena i eficacitatea soluiilor propuse de ingineri;

De a face comparaie obiectiv a mai multor produse;

Verifica utilitatea produsului pentru uz comercial;

Pentru a identifica modaliti de a mbunti performana produsului soft, optimizarea

serviciilor i altele.

Sarcinile unui Test-Lider:

Stabilirea strategiilor de testare i planificare;

ntocmirea strategiilor de inspecie;

Planificarea cerinelor: riscurile, ciclurile, nivelele, tehnicile, obiectivele, estimrile n timp

i bani;

Coordonarea pregtirilor, implementrilor i executrilor testelor;

Decide ce trebuie automatizat, stabilete limite i cum se va face;

Repartizarea activitilor n echip;

Scrierea de rapoarte;

Sarcinile unui tester:

Inspecia i contribuia la planificare;

Setarea mediului de testare;

Pregtirea/copierea/crearea datelor pentru testare;

Implementarea de teste, executarea, evaluarea rezultatelor i documentarea;

62

Automatizarea testelor;

Rularea de teste i msurarea performanei componentelor sistemului;

Revizuirea testelor implementate de ali testeri;

Strategii de testare

O abordare a atestrii include toate deciziile luate cu privire la modul de desfurare a

testrii;

Pe baza testrii se definesc scopurile i obiectivele proiectului, precum i evaluarea

riscurilor;

Este un punct de pornire pentru planificarea testrii prin tehnici de proiectare, tipuri de
testare i angajaii ce vor fi implicai;

De asemenea se definesc criterii de intrare i de ieire.

Exist mai multe abordri:

1. Abordri analitice - testarea bazat pe riscuri;
2. Abordri bazate pe model pe baza informaiilor statistice;
3. Abordri metodice - bazate pe eec;
4. Abordri specificate de standardele specifice industriei(Standardele cilor ferate);
5. Abordri dinamice i euristice testarea de exploatare . a.
Estimarea i plnuirea testrii
Factorii ce influeneaz la plnuirea procesului de testare: Risc, constrngeri, resurse, criterii,
politici de testare, scopul testrii, obiectivele testrii, testabilitate.
Pentru memorarea celor 16 seciuni ale Planului de testare IEEE829 se folosete acronimul
SPACEDIRT
Criteriile de finisare a testrii:

Toate testele planificate au fost executate cu succes;

mare parte din cerine au fost acoperite;

Nu sunt defecte de severitate critica;

Toate defectele de severitate nalta au fost testate

Cnd bugetul s-a epuizat;

Orarul a fost bine ndeplinit i produsul este gata de utilizare.

Instrumente
Definiie Un produs soft care realizeaz una sau mai multe activiti de testare cu ar fi:
planificarea i controlul, ntocmirea specificaiilor, elaborarea fiierelor iniiale, execuia i analiza
testrii.
Tipuri de instrumente:

Incident management tool;

Requirements management tool;

Configuration management tool;

63

Instrumente pentru inspecie;

Instrumente de analiz static;

Instrumente de modelare;

Instrumente tipice de testare;

Instrumente de evaluare a calitii datelor;

Instrumente de monitorizare . a.

TEMA 13: Automatizarea procesului de testare. Istrumente de jurnalizare a procesului de

testare. Automatizarea testelor
Unitatea de nvare : Automatizarea testelor. Utilitare pentru automatizarea testelor
Testarea automat presupune:
1. existena unui produs soft complex care s dezvolte astfel de procese;
2. definirea la intrare a programului care face obiectul testrii;
3. realizarea unei varieti de mecanisme de testare care s acopere o gam ct mai variat de
programe;
4. identificarea de criterii de evaluare a rezultatului testrii care s stea la baza revizuirilor
ulterioare;
5. prezentarea de procese ale prelucrrilor inverse care s permit verificarea n mod
independent a calitii soluiilor produsului testat.
Avantaje:
1.

Daca trebuiesc repetate aceleasi teste de multe ori automatizarea prezinta un mare avantaj

2. Ajuta la executarea de teste de compatibilitate a programelor dvs pe mai multe configuratii

3.

Permite executarea scenariilor de testare ajutand la testele de regresie

4. Permite rularea mai multor teste de regresie pe un cod care se schimba des
5. Pot fi rulate simultan pe mai multe masini astfel scazand timpul de testare
6.

Costurile pe termen lung sunt reduse

Dezavantaje:
1. E mult mai scump sa automatizezi, Investitiile initiale sunt mai mari decat in cazul testarii
manuale
2. Nu se poate automatiza totul, anumite teste trebuiesc facute manual
Testarea regresiv
Testarea regresiv reprezint o treapt deosebit de important pentru echipele care doresc s
dezvolte procese accelerate. Ca modalitate de lucru, prevede repetarea testrii cu date de test i n
condiii identice, pentru fiecare nou versiune intern a unui produs soft. Prin compararea
rezultatelor testrii i identificarea diferenelor se depisteaz erorile nou aprute; acest lucru este
deosebit de util pentru maniera actual de dezvoltare a aplicaiilor RAD - Rapid Application
Development, care implic utilizarea instrumentelor vizuale de programare i se caracterizeaz
prin apariia unui numr mare de modificri ntr-un interval scurt de timp.
Se apreciaz c utilizarea instrumentelor de testare aduce beneficii comparativ cu efectuarea
manual a testelor, deoarece:
64

testarea manual, chiar n cazul unei planificri riguroase, prezint riscul neidentificrii
erorilor din neatenie sau din cauza nerespectrii riguroase a cazurilor de test prevzute;

testarea manual solicit un consum intens de resurse umane, care sunt costisitoare i nu
ntotdeauna disponibile;

testarea manual este nceat comparativ cu testarea automatizat; adesea apare problema
dezvoltrii unor noi versiuni interne ale componentelor nainte de testarea complet a
versiunilor precedente;

Categorii de instrumente pentru asistarea testrii

Instrumente de capturare/redare nregistreaz o sesiune de testare ntrun fiier script,

permind repetarea acesteia i sunt efectuate teste multiple n manier automat cu
efectuarea de comparaii asupra rezultatelor, aceste instrumente sunt eficiente n testarea
regresiv;

Instrumente de execuie automat a testelor asemntoare cu cele de mai sus, dar

cazurile de test sunt specificate de utilizator n fiiere script;

Aanalizor de acoperire evalueaz gradul n care structura codului testat a fost acoperit
prin cazurile de test, astfel de instrumente sunt utile pentru identificarea poriunilor de cod
netestate;

Generator de cazuri de test este un instrument care, pe baza unor informaii precum
cerine, modele ale datelor, modele obiectuale; generaz cazuri de test semnificative,
avantajul este eliminarea redundanei n testare, prin determinarea cazurilor de test care
asigur acoperirea ct mai mare a codului; aceast activitate, executat manual, este
dificil;

Generator de date de test este un instrument care folosete la popularea fiierelor i

bazelor de date n vederea testrii, popularea se face n general cu date aleatoare, dar unele
instrumente prevd i posibilitatea specificrii unor condiii; instrumentele sunt utilizate n
general pentru popularea cu volume mari de date, necesare testrilor operaionale i la
capacitate maxim;

Analizor logic / de complexitate servete la cuantificarea complexitii unor poriuni de

cod; multe astfel de instrumente ofer i reprezentri grafice ale cilor posibile n structura
codului; sunt utile pentru determinarea cazurilor de test necesare pentru atingerea anumitor
puncte din cod din rutine complexe.

Instrumente de trasare a erorilor permit gestiunea informaiilor privitoare la erorile

detectate i stadiul corectrii lor i centralizarea acestor informaii pentru urmrirea
tendinelor acestor defecte; pe baza acestor tendine se efecteaz mbuntiri n procesele
de dezvoltare i/sau mentenan ale organizaiei;

Instrumente de gestionare a testrii au rolul de a asista planificarea i organizarea

elementelor implicate n testare precum fiiere script, cazuri de testare, rezultate

Instrumente Case
Prin instrumente CASE nelegem aplicaiile soft care-i sprijin pe analiti, proiectani,
programatori, inclusiv personalul de testare i ntreinere, s analizeze, s proiecteze, s
implementeze (cel puin parial), s modifice (extind), respectiv s construiasc teste pentru
sistemele informatice.
65

Un produs de tip CASE reprezint, aadar, o colecie de metode, instrumente i procese utilizate
n ingineria soft-ului asistat de calculator. Aceste produse ofer suport pentru automatizarea
metodelor i tehnicilor folosite pe parcursul ciclului de dezvoltare de sisteme informatice, de
aplicaii, de programe.
Utilizarea instrumentelor CASE nu este astzi o problema de mod, ci de eficien n activitatea
de proiectare, realizare i/sau dezvoltare de produse soft. ntr-un domeniu dinamic si inovator
apare permanenta nevoie de adaptare a proceselor de desfurare a afacerilor i a soluiilor care le
implementeaz. Meninerea sistemelor existente devine din ce n ce mai costisitoare, mai riscant
i mai ineficient.

Tema 14: Aplicarea instrumentelor de automatizare la realizarea test case-urilor

Unitatea de nvare: Automatizarea procesului de testare
TEMA 14: Aplicarea instrumentelor de automatizare la realizarea test case-urilor.
Competene elementare formate n cadrul modului:
Automatizarea procesului de testare
Abiliti formate:
A27.

Instalarea instrumentelor de automatizare a procesului de testare;

A28.

Construirea abloanelor de test n baza specificaiilor.

A29.

Utilizarea instrumentelor de automatizare a testrii;

A30.

Rularea unui caz de testare automatizat;

A31.

Rularea unui scenariu de testare automatizat

A32.

Utilizarea instrumentelor de automatizare a testrii;

Termeni cheie:
Testare automatizat
Script de testare
Instrument specific de testare (Test Tool)
Coded UI
Selenium IDE
Cerinele moderne fa de elaborarea produselor program constau n:
Elaborare n termeni minimali;
Elaborare cu resurse minimale;
Investete ct mai puin => Venituri ct mai mari
Acest deziderat aduce la aceea c:
90% din proiecte nu sunt finisate la timp;
67% de dezvoltatori regulat nu se includ n termeni;
66

 n 91% din cazuri se reduce din funcionalitate, pentru a se ncadra n termenii

stabilii.
Acest lucru impune micorarea cheltuielilor i optimizarea procesului de elaborare a
produsului program. Una din cile de optimizare a acestui proces automatizarea acestui proces.
Bineneles vom analiza testarea automatizat a produselor program.
Testare automatizat gestionarea i efectuarea lucrrilor de testare, ce includ n sine
elaborarea i executarea scripturilor de testare cu utilizarea instrumentelor specifice de testare.
Script de testare set de instruciuni pentru verificarea automatizat a unei anumite pri
ale produsului program;
Instrument specific de testare (Test Tool) Produs program, cu ajutorul cruia testorul
efectueaz crearea, depnarea, executarea i analiza rezultatelor lansrii scripturilor de testare.
Testarea automat este caracteristica unei etape superioare a produciei de produse soft.
Testarea automat presupune:
existena unui produs soft complex care s dezvolte astfel de procese;
definirea la intrare a programului care face obiectul testrii;
realizarea unei varieti de mecanisme de testare care s acopere o gam ct mai
variat de programe;
identificarea de criterii de evaluare a rezultatului testrii care s stea la baza
revizuirilor ulterioare;
prezentarea de procese ale prelucrrilor inverse care s permit verificarea n mod
independent a calitii soluiilor produsului testat.
Mecanismele de testare vizeaz:
numrul seturilor de date de test;
diversitatea seturilor de date de test;
soluiile iniiale, exacte, recunoscute ca fiind corecte;
definirea sistemului de generare a datelor de baz;
recrearea de seturi de date derivate care se concateneaz cu datele de baz i devin
n totalitate componentele seturilor de date;
integrarea n procesul de testare automat a programului care face obiectul testrii;
includerea unui sistem de indicatori de apreciere a rezultatului testrii;
agregarea de indicatori privind comportamentul de ansamblu a procesului de testare
automat.
Testarea automata este un deziderat. Maximizarea gradului de generalitate trebuie inclus
n categoria dezideratelor majore. Daca se ncepe cu testarea automat a programelor aparinnd
unei clase de aplicaii se obin concluzii valoroase care stau la baza trecerii la produse soft cu grad
de complexitate ridicat. Prin pai succesivi se creeaz premisele favorabile fundamentrii unei
67

teorii coerente a testrii automate. Creterea gradului de generalitate este o chestiune legat de
experiena acumulata n procesul testrii, coroborat cu utilizarea unor tehnici i metode evoluate
de extragere a informaiilor dintr-un text sursa devenit intrare pentru un produs soft orientat pe
testare automat.
Mecanismele necesare testrii automate vizeaz de la problem la problem realizarea unor
componente care s efectueze i prelucrrile inverse proceselor pentru care s-a elaborat produsul
soft. n aceste situaii speciale, mecanismul de testare automat este cel prezentat n figura
alturat.

Din figur se identific urmtoarele elemente care apar n testarea automat a produselor
soft specializate:
G generatorul de date de intrare;
D datele de intrare generate;
P programul supus testrii;
R rezultate obinute prin programul P cu datele de intrare D;
P programul care implementeaz un algoritm invers celui implementat n
programul P sau un algoritm pentru verificare;
D rezultate obinute de programul P;
V program care compar rezultatele generate cu rezultatele obinute.
n funcie de specificul aplicaiei, fluxurile prezentate n figura dat variaz, ns principiul
acestui mecanism de testare automat rmne acelai.
Cele mai importante ntrebri la automatizarea testelor:
De ce s automatizm?
Ce s automatizm;
Cum s automatizm.
68

Automatizarea testrii ridic calitatea testrii, deoarece:

Instrumentele de testare totdeauna vor executa precis scripturile de testare i nu vor
grei niciodat;
Instrumentele de testare acoper un diapazon mai mare de testare;
Automatizarea testrii reduc cheltuielile de resurse pentru testare, deoarece:
Instrumentele de testare execut scripturile de testare cu mult mai rapid dect omul;
n timpul lucrului scriptului de testare, testorul poate efectua alte activiti;
DAR!
Pentru a obine aceste avantaje, testarea automatizat trebuie integrat n proiect corect i
cu foarte mult atenie.
Pentru integrarea cu succes a testrii automatizate se folosete metodologia cilcului de
via a testrii automatizate (Automated Testing Lifecycle Metodology, ATML).
ATML este o abordare structural pentru implementare i executarea testelor
automatizate la toate etapele elaborrii produsului program;
ATML reflect avantajele includerii testrii timpurii n lucrrile asupra proiectului;
ATML reprezint o iteraie, format di ase etape, ce urmeaz una dup alta:

Erorile tipice comise n procesul de testare automatizat:

Implementarea instrumentului de testare fr prezena procesului de testare, este
creat o program de testare, car nu poate fi repetat i evaluat.

69

 Realizarea proiectului de testare fr evidena standardelor de proiectare. Snt

elaborate scripturi de testare, care nu pot fi folosite pentru urmtoarele versiuni ale
produsului program;
ncercarea de a automatiza 100% de testare, cnd instrumentul de testare nu susine
automatizarea tuturor testelor necesare;
Alegerea incorect a instrumentului de testare;
Implementarea trzie a instrumentului de testare, fr asigurarea timpului necesar
pentru instalare, instruire obinerea prototipului;
AVANTAJE
Testare Automata
Testare Manuala
Daca trebuie repetate aceleai teste de multe Daca Test Case-urile trebuie rulate de un
ori automatizarea prezinta un mare avantaj
numr mic de ori e mult mai probabil sa se
prefere testarea manuala
Ajut la executarea de teste de Permite testor-ului s fac mai multe teste
compatibilitate a produsului program pe mai ad-hoc
multe configuraii;
Permite executarea scenariilor de testare Costurile pe termen scurt sunt reduse;
ajutnd la testele de regresie;
Permite rularea mai multor teste de regresie Cu cat un testor petrece mai mult timp
pe un cod care se schimb des;
verificnd un modul cu att cresc ansele de a
gsi mai multe defecte i posibile greeli de
utilizare;
Pot fi rulate simultan pe mai multe maini
astfel scznd timpul de testare;
Costurile pe termen lung sunt reduse.
DEZAVANTAJE
Testare Automata
Testare Manuala
E mult mai scump sa automatizezi, Testele manuale pot fi mari consumatoare de
Investiiile iniiale sunt mai mari dect n timp;
cazul testrii manuale;
Nu se poate automatiza totul, anumite teste Pentru fiecare release trebuie rulate aceleai
trebuie fcute manual.
seturi de teste ceea ce poate deveni monoton
n ultimul timp pentru testarea automatizat se folosesc tot mai des izatse folosesc tot mai
des aa-numitele xUnit frameworks, Coded UI din Visual Studio, Selenium.
Detaliat vor fi analizate framweork-urile Coded UI din Visual Studio i Selenium.
Coded UI reprezint un instrument de automatizare a testrii interfeelor WEB, WPF,
XAML i Windows Forms n mediul de dezvoltare Visual Studio. Acest instrument este accesibil
doar n versiunile Ultimate, Premium i Professional (doar rularea testelor).
Crearea unui test cu ajutorul coded UI:
1. Lansai Visual Studio i creai un nou proiect Coded UI Test Project:
70

2. n generatorul de cod alegem opiunea Record actions

Apare instrumentul de nregistrare a testului:

71

3. Apsm pe ptrelul rou pentru a ncepe nregistrarea, lansm aplicaia calculator

win+R, calc apsm pe butonul pauz, i generm metoda de test openapplication:

72

A fost generat metoda UIMap.openapplication()

4. Pornim nregistrarea din nou i cream o nou metod de testare pentru adunarea a dou
numere adunare2numere. Pentru aceast metod vom crea verificare (assert)

5. Adugm metoda de testare pentru nchiderea aplicaiei Calculator: vom avea

urmtoarele metode:

6. Crearea i adugarea sursei de date:

73

7. Cream fiierul data.csv, l deschidem i ntroducem datele pentru testare:

74

8. Modificm

proprietatea

Copy

to

output

Directory a fiierului data.csv:

9. Adugm n partea de sus a codului rndul:
using

Microsoft.VisualStudio.TestTools.UITesting.WinControls;
10. Modificm metodele de testare:
[DataSource("Microsoft.VisualStudio.TestTools.DataSource.CSV",
"|DataDirectory|\\data.csv",
"data#csv",
DataAccessMethod.Sequential),
DeploymentItem("data.csv"), TestMethod]
public void CodedUITestMethod1()
{
this.UIMap.UICalculatorWindow.UIItemWindow.UIItem7Button.SearchProperties[Win
Button.PropertyNames.Name] = TestContext.DataRow["Num1"].ToString();
this.UIMap.UICalculatorWindow.UIItemWindow2.UIItem8Button.SearchProperties[Wi
nButton.PropertyNames.Name] = TestContext.DataRow["Num2"].ToString();
this.UIMap.AddTwoNumbers();
this.UIMap.ValidateSumTwoNumbersExpectedValues.UIItem15TextDisplayText1
=
TestContext.DataRow["Sum"].ToString();
this.UIMap.ValidateSumTwoNumbers();
}

11. Lansm n executie testul, i obinem rezultatulm pentru trei iteraii:

75

Instrumentele pentru testarea performanelor aplicaiilor web sunt folosite pentru a testa
aplicaii web i interfee legate de web. Aceste instrumente sunt folosite pentru performan,
sarcin, i teste de stres pentru aplicaii web, site-uri web, servere web i alte interfee web.
Instrumentele pentru testarea performanelor aplicaiilor web simuleaz utilizatori virtuali. Astfel,
instrumentul este util pentru a verifica strangulrii n trafic i probleme de performan ale siteului sau aplicaiei web n curs de testare.
Un astfel de instrument se confrunt cu diverse provocri n timpul testrii i ar trebui s
fie n msur s efectueze teste pentru:
Compatibilitate browser
Compatibilitate sistem de operare
Compatibilitate aplicaie Windows, n cazul n care este necesar
Selenium IDE (Integrated Development Environment) este un utilitar folosit la dezvoltarea
cazurilor de test Selenium. Este un plug-in pentru Firefox, eficient n dezvoltarea cazurilor de
testpentru testarea aplicaiilor web.
Cele mai folosite comenzi n Selenium IDE sunt:
open

deschide o pagin folosind un URL

click/clickAndWait

execut o aciune de apsare i opional, ateapt ncrcarea unei noi

pagini

verifyTitle/assertTitle

verific titlul unei pagini

verifyTextPresent

verific prezena unui text undeva n pagin

76

verifyElementPresent

verific prezena unui element al interfeei grafice n pagin, definit prin

tag HTML

verifyText

verific prezena unui text i a unui tag HTML n pagin

verifyTable

verific coninutul ateptat al unui table

waitForPageToLoad

amn execuia pn cnd o pagin ateptat se ncarc. Este chemat

automat cnd se folosete clickAndWait

waitForElementPresen

amn execuia pn cnd un element al interfeei grafice, definit prin

tag HTML, este prezent n pagin.

Vom realiza testarea automatizat a conectrii n contul skype de pe web: skype.com

1. Verificm comportamentul aplicaiei web
de autentificare n cazul cnd nu se
introduce nimic n cmpurile nume i
parola;
2. Verificm n cazul cnd numele i parola
este corect;
3. Verificm deconectarea contului.
4. Salvm suita de cazuri de testare n
formatul HTML .i eventual pentru C#
pentru testarea n WEBDRIVER/ Nunit.

77

Obiectivele specifice i realiste reprezint fundaia care st la baza oricrei testri

automatizate de succes.
Testarea automatizat aduce multe beneficii, dar doar n anumite condiii:
cnd este aplicat n contextul potrivit;
cnd acest proces este abordat ntr-un mod corect;
cnd obiectivele urmrite sunt specifice i msurabile;
cnd factorii de decizie contientizeaz c aceast iniiativ este una care va aduce
avantaje pe termen lung.

78

Test: "Evaluare sumativ: Testarea Produselor Program".

Item 1

Pe imaginea de mai jos este reprezentat schema generalizat a mediului de

testare. Aceast schem conine urmtoarele blocuri: driverul de testare, modulul
testat, stub-uri, rezultate ateptate, rezultate reale, date de intrare i prelucrarea
rezultatelor.
Pentru fiecare din tehnicile de testare aceast schem poate varia puin.
Indicai pe aceast imagine blocul care lipsete n cazul testrii prin metoda
cutiei negre:
Indicai locul pe imagine

Item 2

Selectai etapa de proiectare a cazurilor de testare:

Selectai unul din 4 variantele de rspuns:
1)
2)
3)
4)

configurarea testrii
specificarea testrii
nregistrarea testrii
planificarea testrii
Item 3

Completai spaiul omis (prin sublinierea noiunii din paranteza patrat) n

definirea uneia din fazele de testare:
Completai spaiile libere:

[------|Planificarea testrii|Analiza i proiectarea|Implementarea

testelor|Rezultatele execuiei secvenelor de test] sunt evaluate pentru a
determina dac produsul a trecut testul cu succes.
Item 4

Dintre afirmaiile de mai jos selectai afirmaia corect ce descrie diferena

dintre retestare i testarea de regresie:
Selectai unul din 5 variantele de rspuns:

79

1)

2)

3)

4)

5)

retestare se face de ctre dezvoltatori; testarea de regresie se face

prin testori independeni
retestare execut din nou un test; testarea de regresie caut efecte
secundare neateptate
retestare folosete diferite medii; testarea de regresie utilizeaz
acelai mediu
retestare se face dup ce greelile sunt fixate; testarea de regresie se
face mai devreme
retestare caut efecte secundare neateptate; testarea de regresie
execut un test nou
Item 5

Indicai pe imaginea de mai jos, pe ce buton trebuie s apsm pentru a ncepe

nregistrarea unui nou caz de testare.
Indicai locul pe imagine

Item 6

Cnd ntr-un caz de testare, un careva pas nu poate fi redat, ce rezultat va fi

atribuit acestui caz de testare? (Selectai unul din rspunsurile propuse mai
jos)
Selectai unul din 4 variantele de rspuns:
1)
2)
3)
4)

Invalid
Fail
Blocat
Pass
80

Item 7

Facei referire la imaginea alturat.

Un testor a primit sarcina s testeze un cod de program. n urma analizei acestui
cod au fost elaborate seturi de cazuri de testare.
Completai spaiile omise n cazurile de testare de mai jos:

Completai spaiile libere:

prima i a doua condiie se ndeplinesc pentru: [--|34|101|9|1];

prima condiie nu se ndeplinete, a doua condiie se ndeplinete: [2|97|100|10];
prima condiie se ndeplinete, a doua condiie nu se ndeplinete: [120|99|9|2];
Item 8

Care dintre urmtoarele sarcini sunt atribuite unui testor?

Slectai cteva din 6 variantele de rspuns
1)
2)
3)
4)
5)
6)

Corectarea erorilor gsite

Implementarea de teste, executarea, evaluarea rezultatelor i
documentarea;
Modificarea specificaiei produsului program
Automatizarea testelor;
Pregatirea/copierea/crearea datelor pentru testare;
Coordonarea pregtirilor, implementrilor i executrilor testelor;
Item 9

81

Selectai afirmaia corect ce descrie principiul de divizare a procesului de

testare n etape distincte:
Selectai unul din 4 variantele de rspuns:
1)
2)
3)
4)

cu ct mai multe etape avem, cu att mai bun este testarea

este mai uor de a gestiona testarea pe etape
putem rula teste diferite n diferite medii
fiecare etap de testare are un scop diferit
Item 10

Dintre instrumentele propuse mai jos, selectai instrumentele utilizate pentru

testarea automatizat:
Slectai cteva din 5 variantele de rspuns
1)
2)
3)
4)
5)

nUnit
Selenium
Coded UI
TestTopia
Visio
Item 11

Dintre grafurile fluxului de date, propuse mai jos, selectai graful pentru
urmtoarea secven de cod:
/* Funcia calculeaz puterea nenegativ n a numrului x */
1 double Power (double x, int n) {
2 double z= 1; int i;
3 for ( i = 1;
4
i <= n;
5
i++ )
6
{z = z * x;}// intoarcere la rindul 4
7 return z;
}
Selectai unul din 5 variantele de rspuns:

1)

2)

3)

82

4)

5)

Item 12

Care dintre urmtoarele modele ale ciclului de via a dezvoltrii produslui

program reprezint un exemplu de abordare de dezvoltare secvenial:
Selectai unul din 5 variantele de rspuns:
1)
2)
3)
4)
5)

Programare extremal
Agile
Code-and-Fix
Spirall
Waterfall
Item 13

Care dintre fazele ciclului de via a produsului program enumerate mai jos
urmeaz dup etapa de proiectare a produsului program:
Selectai unul din 5 variantele de rspuns:
1)
2)
3)
4)
5)

ntreinere
analiz
implementare
specificarea cerinelor
testare
Item 14

Indicai corespondena corect dintre criteriile calitii i caractersiticile lor:

Indicai corespondena dintre 4 variante de rspuns:
1)
2)
3)
4)

Funcionalitate
Fiabilitate
Eficien
Portabilitate

1)
2)
3)
4)
5)

Maturitate
Securitate
Timp de execuie
Co-existen
Putere de atracie
Item 15

Care dintre urmtoarele modele de testare ale produsului program sunt

modele iterative de testare?
83

Slectai cteva din 4 variantele de rspuns

1)
2)
3)
4)

Waterfall
Spiral
Agile
V-model
Item 16

Indicai corespondena corect dintre clasificarea cazului de testare i

descrierea lui:
Indicai corespondena dintre 2 variante de rspuns:
1)

2)

Verificare c produsul
realizeaz ceea ce trebuie s
realizeze
Verificarea situaiilor de
excepie ale produsului
program.

Negativ
1)

Pozitiv
2)

3)

Excepional

Item 17

Dintre metodele de mai jos selectai metodele de prevenire a erorilor:

Slectai cteva din 5 variantele de rspuns
1)
2)
3)
4)

5)

Metodele de copiere i restanilire a datelor;

Metodele de mbuntire a schimbului de informaie;
Metodele de prelucrare a deficienelor dispozitivelor tehnice;
Metodele de inspecie i nlturare a erorilor la fiecare etap a
proiectului;
Metode de asigurare a corectitudinii a procesului de traducere a
informaiei
Item 18
Indicai corespondena dintre 7 variante de rspuns:

1)
2)
3)
4)
5)

6)
7)

Analiza cerinelor
Realizarea testelor
Testare de sistem
Depnarea testelor
Planificarea
verificrilor
Exploatare i
mentenan
Proiectarea testelor

1)
2)

Metode statice de testare

Metode dinamice de testare

Item 19

Dintre afirmaiile de mai jos selectai de ctre cine este efectuat testarea
Beta?
Selectai unul din 4 variantele de rspuns:

84

1)
2)
3)
4)

Efectuat de ctre o echip de test independent

Efectuat de ctre dezvoltatorul software-ul lui
Efectuat de ctre clieni
Efectuat de ctre testorul principal din proiect
Item 20

Selectai neajunsurile testrii prin metoda cutiei negre

Slectai cteva din 4 variantele de rspuns
1)

2)
3)
4)

Volum foarte mare: chiar i pentru aplicaii cu complexitate medie,

numrul de ci posibile poate ajunge la zeci de mii
Greutatea gsirii i a reproducerii erorilor, ce apar destul de rar (erori de
lucru cu memoria)
Imposibilitatea determinrii eorirlor ce se distrug reciproc
Complexitatea urmririi calclulelor timpului testrii

85

Rapunsuri:
#1 (2 p.)

#2 (1 p.)

#3 (1 p.)

[Rezultatele execuiei secvenelor de test] sunt evaluate pentru a

determina dac produsul a trecut testul cu succes.

#4 (1 p.)

#5 (1 p.)

#6 (1 p.)

#7 (3 p.)

prima i a doua condiie se ndeplinesc pentru: [34];

prima condiie nu se ndeplinete, a doua condiie se ndeplinete: [2];
prima condiie se ndeplinete, a doua condiie nu se ndeplinete:
[120];

#8 (3 p.)

2, 4, 5

#9 (1 p.)

#10 (1 p.)

1, 2, 3

86

#11 (2 p.)

#12 (1 p.)

#13 (1 p.)

#14 (1 p.)

1=2, 2=1, 3=3, 4=4

#15 (2 p.)

2, 3

#16 (2 p.)

1=2, 2=1

#17 (1 p.)

2, 4, 5

#18 (3 p.)

1=1, 2=2, 3=2, 4=2, 5=1, 6=2, 7=1

#19 (1 p.)

#20 (1 p.)

2, 3

87