Testarea software o privire de ansamblu

Scopul acestei prelegeri este de a face mai clare urmtoarele aspecte ale testrii software:
Impactul erorilor software asupra vieii noastre
Ce prezint erorile software i care este cauza apariiei lor
Cine sunt testorii i care este rolul lor n procesul de elaborare a softului
n secolul XXI nu ne putem imagina viaa fr produse software. Majoritatea
populaiei sunt posesori de calculatoare personale. Tehnologiile informaionale s-au
infiltrat n toate domeniile activitii umane. Mergnd la cumprturi putem primi
mpreun cu o cutie de margarin sau de cereale un CD-ROM gratis cu un joc video sau cu
muzic. Muli dintre noi nu pot petrece o zi fr Internet. Aplicaiile software au nlocuit
funcionarii n diverse ramuri, astfel avnd un impact enorm asupra vieii i activitii
umane. Pentru a asigura calitatea i sigurana aplicaiilor software se pune un accent
deosebit pe testarea acestor din urm. Testarea de software a devenit o profesie tehnic
foarte important. Urmtoare exemple pot ilustra foarte bine necesitatea testrii software.
Dezvoltarea aplicaiilor software implic o serie de activiti, n care posibilitatea erorii
umane este foarte ridicat. Testarea este un element cheie n procesul de dezvoltare, i
reprezint o ultim recapitulare a specificaiilor, design-ului i codului. Un studiu al
Institutului de Testare Software (Software Testing Institute), relev urmtoarele :
Testorii implicai n industria software sunt mai muli dect n orice alt industrie
(43%)
Testarea software este executat mai degrab n cadrul departamentelor de
programare (44%), dect n cadrul unui departament orientat exclusiv pe testare
(39%)
Doar 4% din productorii software supui acestui studiu prevd nfiinarea unui
departament orientat exclusiv pe testare.
Testarea software, prin definiie, urmrete focalizarea pe procesul de identificare a
posibilelor erori de program, erori care ar putea avea un impact negativ asupra produsului,
i prin urmare asupra clienilor. Satisfacia clienilor este cheia reuitei oricrei afaceri, i
asta nu mai este o necunoscut.
Aceasta presupune c produsul oferit s fie de calitate ridicat, i s nu produc erori
n timpul utilizrii de ctre client. Calitatea ridicat nu poate fi obinut doar cu ajutorul
unei echipe de programatori de excepie. Este deja bine tiut faptul c orict de bine pus la
punct ar fi produsul dezvoltat, acesta conine totui erori.
Implicarea testrii n procesul de producie aduce urmtoarele avantaje:
Organizare disciplinat a procesului/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.
1

 nelegerea importanei calitii n procesul de producie, calitate care poate fi

obinut doar n urma unei testri profesionale.
Impunerea unor reguli i standarde 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
Unele dintre cele mai scandaloase erori software
1. Aparat medical pentru terapie cu radiaie Therac-25
- 6 accidente cu mori i rni grave (1985-87, SUA, Canada)
Cauza direct: erori in programul de control
Analiz retrospectiv [Leveson 1995]:
ncredere excesiv n software (n analiza produsului)
fiabilitate siguran
2. Racheta Ariane 5
- Autodistrugere dup o defeciune la 40 s de la lansare (1996)
Cauza: conversia 64-bit float 16-bit int genereaz o excepie de depire
netratat n programul ADA
Cost: 500 milioane dolari (racheta), 7 miliarde dolari (proiectul)
Analiz retrospectiv
principala cauz: reutilizarea nejudicioasa de software
cod preluat de la Ariane 4, fr reanalizare corespunztoare:
3. Eroarea din procesorul Intel Pentium
Eroare n unitatea de mprire cu virgula mobila, 1994
Cost: cca. 400 milioane dolari
Analiz ulterioar
Circuitul putea fi verificat formal
- demonstrare automat de teoreme [Clarke, German & Zhao]
- cu structuri speciale de date pentru reprezentarea nmulirii/mpririi [Bryant &
Chen]
Accentul a fost pus pe componente mai complexe (unitatea de execuie, coerena
memoriei cache)

Eroarea software
Din exemplele de mai sus se poate vedea impactul erorilor software asupra noastr.
Erorile pot fi catastrofice, cnd provoac pierderi de viei omeneti sau pot fi nite
inconveniene dac este vorba de exemplu de un joc pe calculator. Majoritatea erorilor sunt
mult mai complicate dect par la prima vedere. Sunt ns i erori simple, subtile despre
care nu se poate cu siguran de spus, dac este o eroare adevrat sau nu.
Un testor bun trebuie s poat folosi diferii termeni pentru a descrie ce s-a ntmplat
cnd a euat softul. n continuare este dat o list cu termenii folosii:
1.
Defect (Defect)
2.
Excepie (Variance)
2

3.
Eec (Failure)
4.
Problem (Problem)
5.
Eroare (Error)
6.
Incident (Incident)
7.
Anomalie (Anomaly)
8.
Inconsisten (Inconsistency)
9.
Aparen (Feature)
10.
Neajuns (Fault)
11.
Bug
Care dintre aceti termeni vor fi folosii pentru descrierea erorilor ine doar de cultura
companiei i de stadiul la care a fost descoperit eroarea. Dac ne uitm n dicionar,
observm c toate aceste cuvinte se deosebesc foarte puii, unele fiind chiar sinonime
De obicei orice eroare software este numit bug, ns acest termen nu poate fi
acceptat cnd se completeaz diferite rapoarte despre testarea softului. n cadrul acestui
curs v-om folosi termenul: eroare software.
nainte de a formula definiia erorii software avem nevoie de un termen de reper:
specificaia produsului software.
Specificaia produsului este un acord al echipei de dezvoltare software, n care este
definit: cum ar trebui el s fie, cum este ntr-adevr, ce trebuie s fac i ce nu trebuie s
fac acest produs.
Definiie. Erorile software apar cnd una sau mai multe dintre urmtoarele afirmaii
sunt adevrate:
1. Softul nu execut ceva ce specificaiile spun c trebuie s execute.
2. Softul execut ceva ce specificaiile spun c nu trebuie s execute.
3. Softul execut ceva ce n specificaii nu este menionat.
4. Softul nu execut ceva ce specificaiile nu menioneaz dar ar trebui s
menioneze.
5. Softul este greu de neles, greu de folosit, lent sau se vede c nu a fost proiectat
corect.
Aceast definiie a erorilor acoper o mare parte de probleme, de acea testorii
folosesc aceste reguli pentru a identifica diferite tipuri de probleme n aplicaiile software.

Cauzele i costul 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 ori cerinele nu sunt formulate bine.
3

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

Locul testorului n procesul de elaborare a softului

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

6. Trebuie s aib tact i s fie bun diplomat. El este cel care aduce vetile rele
programatorului.
7. Trebuie s fie perseverent. Erorile gsite nu totdeauna sunt vizibile i uneori sunt
greu de descris. Testorul trebuie s-i poat expune punctul de vedere i s poat
demonstra necesitatea fixrii i posibil corectrii erorilor gsite.
Un testor nu trebuie s fie numaidect un programator, cunotinele din diferite
domenii (economie, nvmnt, aviaie, medicin, culinrie , construcii ) pentru care
sunt dezvoltate produse software vor fi de un imens ajutor pentru un testor.

Psihologia testrii
Testarea software este o disciplin tehnic, ns ea implic importante consideraii
economice i psihologice.
Ideal ar fi testarea tuturor combinaiilor posibile ale intrrilor i ieirilor
programului. n cele mai multe cazuri ns aceasta este imposibil, deoarece chiar i un
program simplu poate avea sute i chiar mii de combinaii ale intrrilor i ieirilor. Crearea
cazurilor de test pentru toate aceste combinaii este destul de nepractic, pentru aceasta
este nevoie de resurse umane i financiare enorme, mai mult ca att procesul poate dura
timp ndelungat. Plus la aceasta mai trebuie de luat n consideraie i viziunea testorului
fa de crearea unui test de succes. Atitudinea testorului fa de produs este de asemenea
foarte important. Pentru ca procesul de testare s nu se transforme ntr-o goan haotic
dup erori este benefic de respectat unele principii ale testrii pe care le-a artat practica
testrii i timpul i de cunoscut nite tehnici de testare, pentru a sistematiza acest proces.
Definiii ale testrii
O cauz important a calitii proaste a produselor soft este definirea incorect a
procesului de testare. De exemplu se spune c:
1. Testarea e procesul de a demonstra c programul nu are erori (or acest lucru este
imposibil folosind doar testarea)
sau
2. Scopul testrii este de a arta c produsul este performant i funcioneaz corect
sau
3. Testarea este procesul prin care se demonstreaz c produsul face ceea ce trebuie
s fac
Aceste definiii nu sunt rele doar c sunt pe 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.
5

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).
1. Un 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 sa evite sa-i testeze propriul program.
Orice scriitor tir, sau cel puin trebuie s tir, 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 poat s-i permit
aceasta.
6

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 testa 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 testa cu testele vechi noul
produs. Astfel se testeaz integritatea i funcionalitatea produsului. Refolosirea cazurilor
de test este binevenit i atunci cnd au fost corectate unele erori deja gsite. Pstrarea
testelor i refolosirea lor dup modificri n produs poart denumirea de testare regresiv
(regression testing).
Principiul 8: Nu se planific procesul de testare presupunnd c nu vor fi gsite erori.
Este o greeal a managerilor de proiect cnd se folosete o definiie incorect a
testrii. De exemplu: Testarea e procesul prin care se demonstreaz c produsul este
performant i funcioneaz corect n locul Testarea e procesul prin care se execut un
program cu intenia de a gsi erori
Principiul 9: Probabilitatea de a gsi erori ntr-un fragment de cod este proporional
cu numrul de erori deja gsite.
Dac avem de exemplu un program din dou module A i B i n modulul A au fost
gsite cinci erori iar n B numai una, i dac modulul A nu a fost supus intenionat unui
test riguros, atunci acest principiu ne spune c probabilitatea c n modulul A vor fi gsite
mai multe erori dect n modulul B este destul de mare. La prima vedere acest principiu nu
are prea mult sens, ns este un fenomen prezent n majoritatea programelor.
Principiul 10:Testarea este un lucru extrem de creativ i intelectual.
Este probabil adevrat c creativitatea cerut la testarea produselor serioase depete
creativitatea cerut n proiectarea acestora. Este clar c este imposibil de testat un produs
suficient pentru a demonstra absena erorilor n acest produs. Metodologia pe care o vom
studia n cadrul cursului va fi de un mare folos la elaborarea unui numr rezonabil de
cazuri de test, ns aceast metodologie cere un nivel nalt de creativitate a testorului.
7

Axiomele testrii (Patton)

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

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

Etapele dezvoltrii programelor

Cnd pornim la dezvoltarea unui program avem nevoie de:

nelegere clar a ceea ce se cere;

un set de metode i instrumente de lucru;

un plan de aciune.
Planul de aciune se numete metodologie de dezvoltare. Dezvoltarea unui anumit
program const ntr-un set de pai ce se fac pentru a-l realiza. Lund n considerare tipul
pailor ce se efectueaz se creeaz un model de lucru, ce poate fi aplicat unei serii mai
9

largi de proiecte. Acesta este motivul pentru care planul de aciune este numit model: el
poate fi privit ca un ablon al dezvoltrii de programe. n timpul dezvoltrii programelor sa constatat c exist anumite tipuri de activiti care trebuie fcute la un moment dat:

Analiza cerinelor: Se stabilete ce anume vrea clientul ca programul s fac.

Scopul este nregistrarea cerinelor ntr-o manier ct mai clar i mai fidel. Claritatea se
refer la lipsa ambiguitii iar fidelitatea la nregistrarea ct mai exact (posibil cuvnt cu
cuvnt);

Proiectarea arhitectural: Din motive de complexitate, programele mari nu

pot fi concepute i implementate ca o singur bucat. Programul va trebui construit aadar
din module sau componente. Proiectarea arhitectural mparte sistemul ntr-un numr de
module mai mici i mai simple, care pot fi abordate individual;

Proiectarea detaliat: Se realizeaz proiectarea fiecrui modul al aplicaiei, n

cele mai mici detalii;

Scrierea codului: Proiectul detaliat este transpus ntr-un limbaj de

programare. De obicei, aceasta se realizeaz modular, pe structura rezultat la proiectarea
arhitectural;
Integrarea componentelor: Modulele programului sunt combinate n produsul final.
Rezultatul este sistemul complet. n modelul numit big-bang componentele sunt dezvoltate
i testate individual, dup care sunt integrate n sistemul final. Avnd n vedere c
funcionarea corect a componentelor individuale a fost testat, integrarea ar trebui s fie o
formalitate. Din pcate, componentele nu pot fi testate exhaustiv, iar cnd acestea lucreaz
mpreun pot s apar situaii pe care o anumit component nu le-a ntlnit n procesul de
testare sau conflicte ntre anumite componente (de exemplu, conflicte de partajare a
resurselor). S-a constatat c atunci cnd se aplic acest model, timpul de testare
explodeaz, proiectul devenind greu de controlat; aceasta justific denumirea de bigbang. Modelul incremental propune crearea unui nucleu al aplicaiei i integrarea a cte o
component la un moment dat, urmat imediat de testarea sistemului obinut. Astfel, se
poate determina mai uor unde anume apare o problema n sistem. Acest tip de integrare
ofer de obicei rezultate mai bune dect modelul big-bang;

Validarea: n procesul de validare ne asigurm c programul ndeplinete

cerinele utilizatorului. ntrebarea la care rspundem este: construim produsul corect? Un
exemplu de validare este testul de acceptare, n care produsul este prezentat clientului.
Clientul spune dac este mulumit cu produsul sau dac mai trebuie efectuate modificri;

Verificarea: n procesul de verificare ne asigurm c programul este stabil i

c funcioneaz corect din punctul de vedere al dezvoltatorilor. ntrebarea la care
rspundem este: construim corect produsul?

ntreinerea: Dup ce programul este livrat clientului, mai devreme sau mai
trziu sunt descoperite defecte sau erori ce trebuie reparate. De asemenea, pot aprea
schimbri n specificaiile utilizatorilor, care vor diverse mbuntiri. ntreinerea const
n gestionarea acestor probleme.
Se poate constata uor c aceste activiti sunt n strns legtur cu cele patru faze
ale ingineriei programrii: analiza, proiectarea, implementarea i testarea.

Metodologii generice
n acest paragraf, vor fi prezentate trei categorii importante de metodologii:
secvenial, ciclic i hibrid. n metodologia secvenial (cascad), cele patru faze
urmeaz una alteia ntr-o modalitate serial. n metodologia ciclic (spiral), fazele sunt
10

dispuse n cicluri care i genereaz incremental contribuiile la sistemul final.

Metodologia hibrid (ecluz) combin progresul constant al metodologiei secveniale cu
incrementele iterative ale metodologiei ciclice.
Metodologia secvenial
n metodologia secvenial, cunoscut i sub numele de metodologia cascad, are
loc mai nti faza de analiz, apoi cea de proiectare, urmat de cea de implementare, iar n
final se realizeaz testarea. Echipele care se ocup de fiecare faz pot fi diferite, iar la
fiecare tranziie de faz poate fi necesar o decizie managerial.

Figura 1. Metodologia secvenial

Avantaje
Metodologia secvenial este potrivit cnd complexitatea sistemului este mic iar
cerinele sunt statice. Ea spune c mai nti trebuie s ne gndim ce trebuie construit, apoi
s stabilim un plan de lucru i apoi s realizm proiectul, innd cont de standardele de
calitate. De asemenea, se aliniaz metodelor de inginerie hardware. Foreaz meninerea
unei discipline de lucru care evit presiunea scrierii codului nainte de a cunoate precis ce
produs va trebui de fapt construit. De multe ori, echipa de implementare se afl n situaia
de a programa nainte de finalizarea analizei, ceea ce conduce inevitabil la descoperirea
unor pri de cod inutile sau care contribuie foarte puin (poate chiar i ineficient) la
funcionalitatea produsului final. Totui, acest cod devine un balast foarte costisitor: dificil
de abandonat i greu de schimbat. Aceast metodologie foreaz analiza i planificarea
naintea implementrii, o practic foarte nimerit n multe situaii.
Un mare numr de sisteme software din trecut au fost construite cu o metodologie
secvenial. Multe companii i datoreaz succesul acestui mod de realizare a programelor.
Trebuie spus totui i c presiunea de schimbare din partea surselor externe era destul de
limitat la momentul respectiv.
Dezavantaje
Unul din principalele dezavantaje ale metodologiei secveniale este faptul c acord
o foarte mare importan fazei de analiz. Membrii echipei de analiz ar trebui s fie
probabil clarvztori ca s poat defini toate detaliile aplicaiei nc de la nceput.
Greelile nu sunt permise, deoarece nu exist un proces de corectare a erorilor dup
lansarea cerinelor finale. Nu exist nici feedback de la echipa de implementare n ceea ce
privete complexitatea codului corespunztor unei anumite cerine. O cerin simplu de
formulat poate crete considerabil complexitatea implementrii. n unele cazuri, este
posibil s fie chiar imposibil de implementat cu tehnologia actual. Dac echipa de analiz
ar ti c o cerin nu poate fi implementat, ei ar putea-o schimba cu o cerin diferit care
s satisfac cele mai multe dintre necesiti i care s fie mai uor de efectuat.
Comunicarea dintre echipe este o problem: cele patru echipe pot fi diferite iar
comunicarea dintre ele este limitat. Modul principal de comunicare sunt documentele
realizate de o echip i trimise urmtoarei echipe cu foarte puin feedback. Echipa de
analiz nu poate avea toate informaiile privitoare la calitate, performan i motivare.
11

ntr-o industrie n continu micare, metodologia secvenial poate produce sisteme

care, la vremea lansrii, s fie deja nvechite. Accentul att de mare pus pe planificare nu
poate determina rspunsuri suficient de rapide la schimbare. Ce se ntmpl dac clientul
i schimb cerinele dup terminarea fazei de analiz? Acest lucru se ntmpl ns
frecvent; dup ce clientul vede prototipul produsului, el i poate schimba unele cerine.
Metodologia ciclic
Metodologia ciclic, cunoscut i sub numele de metodologia spiral, ncearc s
rezolve unele din problemele metodologiei secveniale. i aceast metodologie are patru
faze, ns n fiecare faz se consum un timp mai scurt, dup care urmeaz mai multe
iteraii prin toate fazele. Ideea este de fapt urmtoarea: gndete un pic, planific un pic,
implementeaz un pic, testeaz un pic i apoi ia-o de la capt. n mod ideal, fiecrei faze
trebuie s i se acorde atenie i importan egale. Documentele de la fiecare faz i
schimb treptat structura i coninutul, la fiecare ciclu sau iteraie. Pe msur ce procesul
nainteaz, sunt generate din ce n ce mai multe detalii. n final, dup cteva cicluri,
sistemul este complet i gata de lansare. Procesul poate ns continua pentru lansarea mai
multor versiuni ale produsului.

Figura 2. Metodologia ciclic

Documentele de la fiecare faz i schimb treptat structura i coninutul, la fiecare
ciclu sau iteraie. Pe msur ce procesul nainteaz, sunt generate din ce n ce mai multe
detalii. n final, dup cteva cicluri, sistemul este complet i gata de lansare. Procesul
poate ns continua pentru lansarea mai multor versiuni ale produsului.
Avantaje
Metodologia ciclic se bazeaz pe ideea perfecionrii incrementale ale
metodologiei secveniale. Permite feedback-ul de la fiecare echip n ceea ce privete
complexitatea cerinelor. Exist etape n care pot fi corectate eventualele greeli privind
cerinele. Clientul poate arunca o privire asupra rezultatului i poate oferi informaii
importante mai ales n faza dinaintea lansrii produsului. Echipa de implementare poate
trimite echipei de analiz informaii privind performanele i viabilitatea sistemului.
Acesta se poate adapta mai bine progresului tehnologic: pe msur ce apar noi soluii, ele
pot fi ncorporate n arhitectura produsului.
Dezavantaje
Metodologia ciclic nu are nici o modalitate de supraveghere care s controleze
oscilaiile de la un ciclu la altul. n aceast situaie, fiecare ciclu produce un efort mai mare
de munc pentru ciclul urmtor, ceea ce ncarc orarul planificat i poate duce la
eliminarea unor funcii sau la o calitate sczut. Lungimea sau numrul de cicluri poate
crete foarte mult. De vreme ce nu exist constrngeri asupra echipei de analiz s fac
lucrurile cum trebuie de prima dat, acest fapt duce la scderea responsabilitii. Echipa de
implementare poate primi sarcini la care ulterior se va renuna. Echipa de proiectare nu are
12

o viziune global asupra produsului i deci nu poate realiza o arhitectur complet. Nu

exist termene limit precise. Ciclurile continu fr o condiie clar de terminare. Echipa
de implementare poate fi pus n situaia nedorit n care arhitectura i cerinele sistemului
sunt n permanen schimbare.
Metodologia hibrid ecluz
Metodologia ecluz (engl. watersluice), propus de Ronald LeRoi Burback
(1998), separ aspectele cele mai importante ale procesului de dezvoltare a unui produs
software de detaliile mai puin semnificative i se concentreaz pe rezolvarea primelor. Pe
msur ce procesul continu, detaliile din ce n ce mai fine sunt rafinate, pn cnd
produsul poate fi lansat. Aceast metodologie hibrid preia natura iterativ a metodologiei
spiral, la care adaug progresul sigur al metodologiei cascad.

Figura 3. Metodologia hibrid ecluz

La nceput, ntr-un proces iterativ, fazele de analiz, proiectare, implementare i
testare sunt mprite n mai multe sarcini poteniale, fiecruia atribuindu-i-se o prioritate
care reflect beneficiul ndeplinirii sarcinii respective pentru scopul final. La fiecare
moment se execut sarcina cu prioritate maxim. n funcie de dimensiunea echipelor, mai
multe sarcini pot fi realizate n paralel. Sarcinile rmase, de prioritate minim, sunt
pstrate pentru examinare ulterioar. Descompunerea problemei este foarte important. Cu
ct descompunerea i stabilirea prioritilor sunt mai bune, cu att mai eficient este
metodologia.
Pe msur ce sarcinile stabilite sunt ndeplinite, noi sarcini pot fi descoperite.
Acestea sunt adugate sarcinilor rmase nesoluionate i se reatribuie prioritile. Procesul
continu pn cnd produsul este gata de lansare.
Prioritile se stabilesc pe baza unei funcii de prioritate, care depinde att de
domeniul problemei i de normele firmei. Ea trebuie s realizeze un compromis ntre
cantitate i calitate, ntre funcionalitate i constrngerile privind resursele, ntre ateptri i
realitate. Toate funciile de prioritate ar trebuie s aib ca prim scop lansarea produsului.
Pe lng rolul evident de a stabili prioritile i deci ordinea de execuie a sarcinilor
de lucru, funcia mai trebuie s gestioneze sarcinile conflictuale i nemonotone. Ea trebuie
s mpart aceste sarcini n grupuri consistente, s reglementeze selecia grupurilor
consistente i apoi s dirijeze selecia sarcinilor din cadrul grupurilor. Pe msur ce
sistemul crete, funcia de prioritate trebuie s aleag sarcini consistente cu partea deja
13

constituit din sistem. O sarcin nemonoton vine n contradicie cu sistemul realizat deja
i trebuie eliminat dac nu este absolut necesar pentru succesul sistemului.
Odat ce o component este terminat i acceptat de echip, schimbrile asupra sa
sunt ngheate. Componenta va fi schimbat numai dac modificrile sunt absolut necesare
iar echipa este dispus s ntrzie lucrul la restul sistemului pentru a le efectua.
Schimbrile trebuie s fie puine la numr, bine justificate i documentate.
Etapele principale ale metodei sunt: schia de principiu, prototipul, versiunile
alfa/beta i produsul final.
n prima etap, schia de principiu, echipele lucreaz simultan la toate fazele
problemei. Echipa de analiz sugereaz cerinele. Echipa de proiectare le discut i trimite
sarcinile critice de implementare echipei de implementare. Echipa de testare pregtete i
dezvolt mediul de test n funcie de cerine. Echipa de implementare se concentreaz
asupra sarcinilor critice, care n general sunt cele mai dificile. Aceast abordare
contrasteaz cu practica curent de realizare mai nti a sarcinilor simple. Totui,
majoritatea produselor care urmeaz acest model eueaz. Odat ce componentele critice
au fost realizate, sistemul este gata de a face tranziia ctre stadiul de prototip. Unul din
scopurile aceste etape este de a se convinge echipele c o soluie poate fi gsit i pus n
practic.
n cea de a doua etap, de prototip, cerinele i documentul cerinelor sunt ngheate.
Schimbrile n cerine sunt nc permise, ns ar trebuie s fie foarte rare i numai dac
sunt absolut necesare, deoarece modificrile cerinelor n acest stadiu al proiectului sunt
foarte costisitoare. Este posibil totui ajustarea arhitecturii, pe baza noilor opiuni datorate
tehnologiei. Dup ce sarcinile critice au fost terminate, echipa de implementare se poate
concentra pe extinderea acestora, pentru definirea ct mai multor aspecte ale aplicaiei.
Unul din scopurile acestei etape este de a convinge persoanele din afara echipelor c o
soluie este posibil.
Acum produsul este gata pentru lansarea versiunilor alfa i beta. Arhitectura este
ngheat, iar accentul cade pe implementare i asigurarea calitii. Prima versiune lansat
se numete n general alfa. Produsul este nc imatur; numai sarcinile critice au fost
implementate la calitate ridicat. Numai un numr mic de clieni sunt n general dispui s
accepte o versiune alfa i s-i asume riscurile asociate. O a doua lansare reprezint
versiunea beta. Rolul su este de a convinge clienii c aplicaia va fi un produs adevrat i
de aceea se adreseaz unui numr mai mare de clieni.
Cnd o parte suficient de mare din sistem a fost construit, poate fi lansat n sfrit
produsul. n aceast etap, implementarea este ngheat i accentul cade pe asigurarea
calitii. Scopul este realizarea unui produs competitiv. n produsul final nu se accept
erori critice.
Avantaje
Metodologia ecluz recunoate faptul c oamenii fac greeli i c nici o decizie nu
trebuie s fie absolut. Echipele nu sunt blocate ntr-o serie de cerine sau ntr-o arhitectur
imobil care se pot dovedi mai trziu inadecvate sau chiar greite. Totui, pentru
respectarea termenelor limit, metodologia impune date de ngheare a unor faze. Exist
timp suficient pentru corectarea greelilor decizionale pentru atingerea unui nivel suficient
de ridicat de ncredere. Se pune mare accent pe comunicarea ntre echipe, ceea ce reduce
cantitatea de cod inutil la care ar trebui s se renune n mod normal. Metodologia ncearc
14

s mute toate erorile la nceputul procesului, unde corectarea, sau chiar renceperea de la
zero a lucrului, nu sunt foarte costisitoare.
Dezavantaje
Metodologia presupune asumarea unor responsabiliti privind delimitarea etapelor
i nghearea succesiv a fazelor de dezvoltare. Ea presupune crearea unui mediu de lucru
n care acceptarea responsabilitii pentru o decizie care se dovedete mai trziu greit s
nu se repercuteze n mod negativ asupra individului. Se dorete de asemenea schimbarea
atitudinii echipelor fa de testare, care are loc nc de la nceput, i fa de comunicarea
continu, care poate fi dificil, ntruct cele patru faze reprezint perspective diferite
asupra realizrii produsului.

Metodologii concrete
Metodologia cascad
Metodologia cascad, propus de Barry Boehm, este una din cele mai cunoscute
exemple de metodologie de ingineria programrii. Exist numeroase variante ale acestui
proces. ntr-o variant detaliat, metodologia cascad cuprinde urmtoarele etape:

Figura 4. Metodologia cascad

Dup fiecare etap exist un pas de validare. Procesul curge de la etap la etap,
ca apa ntr-o cascad. n descrierea originar a lui Boehm, exist o ntoarcere, un pas napoi
interactiv ntre fiecare dou etape. Astfel, metoda cascad este de fapt o combinaie de
metodologie secvenial cu elemente ciclice. Totui, n practica inginereasc, termenul
cascad este utilizat ca un nume generic pentru orice metodologie secvenial.
15

Acesta este modelul dup care de obicei sistemele sunt dezvoltate n practic. De
asemenea, reordonarea fazelor s-a dovedit a fi sub-optimal. Exist o mare atracie pentru
acest model datorit experienei, tradiiei n aplicarea sa i succesului pe care l-a implicat.
O sarcin complex este mprit n mai muli pai mici, ce sunt mai uor de administrat.
Fiecare pas are ca rezultat un produs bine definit (documente de specificaie, model, etc.)
Modelul cascad cu feedback propune remedierea problemelor descoperite n pasul
precedent. Problemele la pasul i care sunt descoperite la pasul i + 3 rmn neremediabile.
Un model realist ar trebui s ofere posibilitatea ca de la un anumit nivel s se poat reveni
la oricare dintre nivelele anterioare.
Dezavantajul principal al modelului n cascad apare deoarece clientul obine o
viziune practic asupra produsului doar n momentul terminrii procesului de dezvoltare.
De asemenea, modelul nu are suficient putere descriptiv, n sensul c nu integreaz
activiti ca managementul resurselor sau managementul configuraiei. Aceasta face
dificil coordonarea proiectului.
Dup cum am menionat la prezentarea metodologiei generice secveniale, i
modelul cascad impune nghearea specificaiilor foarte devreme n procesul de
dezvoltare pentru a evita iteraiile frecvente (rentoarcerile n fazele anterioare atunci cnd
n faza curent s-au detectat erori: n timpul analizei se descoper erori de specificaii, n
timpul implementrii se descoper erori de specificaii/proiectare etc., astfel nct procesul
poate implica multiple secvene de iteraii ale activitilor de dezvoltare). nghearea
prematur a cerinelor conduce la obinerea unui produs prost structurat i care nu execut
ceea ce dorete utilizatorul. Conduce de asemenea la obinerea unei
documentaii neadecvate deoarece schimbrile intervenite n iteraiile frecvente nu
sunt actualizate n toate documentele produse.
Metodologia spiral
Metodologia spiral, propus tot de Boehm, este un alt exemplu bine cunoscut de
metodologie a ingineriei programrii. Acest model ncearc s rezolve problemele
modelului n cascad, pstrnd avantajele acestuia: planificare, faze bine definite, produse
intermediare. El definete urmtorii pai n dezvoltarea unui produs:

studiul de fezabilitate;

analiza cerinelor;

proiectarea arhitecturii software;

implementarea.
Modelul n spiral recunoate c problema principal a dezvoltrii programelor este
riscul. Riscul nu mai este eliminat prin aseriuni de genul: n urma proiectrii am obinut
un model corect al sistemului, ca n modelul cascad. Aici riscul este acceptat, evaluat i
se iau msuri pentru contracararea efectelor sale negative. Exemple de riscuri:

n timpul unui proces ndelungat de dezvoltare, cerinele noi ale clientului sunt
ignorate;

clientul schimb cerinele;

o firm concurent lanseaz un program rival pe pia;

un dezvoltator/arhitect prsete echipa de dezvoltare;

o echip nu respect un termen de livrare pentru o anumit component.

n modelul spiral se consider c fiecare pas din dezvoltare conine o serie de
activiti comune:

pregtirea: se identific obiectivele, alternativele, constrngerile;

16


gestionarea riscului: analiza i rezolvarea situaiilor de risc;

activiti de dezvoltare specifice pasului curent (de exemplu analiza

specificaiilor sau scrierea de cod);

planificarea urmtorului stadiu: termenele limit, resurse umane,

revizuirea strii proiectului.
Metodologia spiral cuprinde urmtoarele etape, grupate pe patru cicluri:

Figura 5. Metodologia spiral

Ciclul 1 Analiza preliminar:
1.
Obiective, alternative, constrngeri
2.
Analiza riscului i prototipul
3.
Conceperea operaiilor
4.
Cerinele i planul ciclului de via
5.
Obiective, alternative, constrngeri
6.
Analiza riscului i prototipul
Ciclul 2 Analiza final:
7.
Simulare, modele, benchmark-uri
8.
Cerine software i validare
9.
Plan de dezvoltare
10.
Obiective, alternative, constrngeri
11.
Analiza riscului i prototipul
Ciclul 3 Proiectarea:
12.
Simulare, modele, benchmark-uri
13.
Proiectarea produsului software, validare i verificare
14.
Integrare i plan de test
15.
Obiective, alternative, constrngeri
16.
Analiza riscului i prototipul operaional
Ciclul 4 Implementarea i testarea:
17.
Simulare, modele, benchmark-uri
18.
Proiectare detaliat
19.
Cod
20.
Integrarea unitilor i testarea acceptrii
17

21.
Lansarea produsului
Procesul ncepe n centrul spiralei. Fiecare ciclu terminat reprezint o etap. Pe
msur ce spirala este parcurs, produsul se maturizeaz. Cu fiecare ciclu, sistemul se
apropie de soluia final. Dei este considerat ca un exemplu generic pentru metodologia
ciclic, metoda are i elemente secveniale, puse n eviden de evoluia constant de la o
etap la alta.
Prototipizarea
O problem general care apare la dezvoltarea unui program este s ne asigurm c
utilizatorul obine exact ceea ce vrea. Prototipizarea vine n sprijinul rezolvrii acestei
probleme. nc din primele faze ale dezvoltrii, clientului i se prezint o versiune
funcional a sistemului. Aceast versiune nu reprezint ntregul sistem, ns este o parte a
sistemului care cel puin funcioneaz.
Prototipul ajut clientul n a-i defini mai bine cerinele i prioritile. Prin
intermediul unui prototip, el poate nelege ce este posibil i ce nu din punct de vedere
tehnologic. Prototipul este de obicei produs ct mai repede; pe cale de consecin, stilul de
programare este de obicei (cel puin) neglijent. ns scopul principal al prototipului este de
a ajuta n fazele de analiz i proiectare i nu folosirea unui stil elegant.
Se disting dou feluri de prototipuri:

de aruncat (throw-away);

evoluionar.
n cazul realizrii unui prototip de aruncat, scopul este exclusiv obinerea unei
specificaii. De aceea nu se acord nici o importan stilului de programare i de lucru,
punndu-se accent pe viteza de dezvoltare. Odat stabilite cerinele, codul prototipului este
aruncat, sistemul final fiind rescris de la nceput, chiar n alt limbaj de programare.
n cazul realizrii unui prototip evoluionar, scopul este de a crea un schelet al
aplicaiei care s poat implementa n prim faz o parte a cerinelor sistemului. Pe msur
ce aplicaia este dezvoltat, noi caracteristici sunt adugate scheletului existent. n contrast
cu prototipul de aruncat, aici se investete un efort considerabil ntr-un design modular i
extensibil, precum i n adoptarea unui stil elegant de programare.
Aceast metod are urmtoarele avantaje:

permite dezvolttorilor s elimine lipsa de claritate a specificaiilor;

ofer utilizatorilor ansa de a schimba specificaiile ntr-un mod ce nu

afecteaz drastic durata de dezvoltare;

ntreinerea este redus, deoarece validarea se face pe parcursul dezvoltrii; se

poate facilita instruirea utilizatorilor finali nainte de terminarea produsului.
Dintre dezavantajele principale ale prototipizrii amintim:

deoarece prototipul ruleaz ntr-un mediu artificial, anumite dezavantaje ale

produsului final pot fi scpate din vedere de clieni;

clientul nu nelege de ce produsul necesit timp suplimentar pentru

dezvoltare, avnd n vedere c prototipul a fost realizat att de repede;

deoarece au n fiecare moment ansa de a face acest lucru, clienii schimb

foarte des specificaiile;

poate fi nepopular printre dezvolttori, deoarece implic renunarea la

propria munc.
Metodologia Booch
18

Aceast metodologie asigur o dezvoltare orientat obiect n fazele de analiz i

proiectare. Faza de analiz este mprit n mai muli pai. Primul pas este stabilirea
cerinelor din perspectiva clientului, genernd o descriere de nivel nalt a funcionrii i
structurii sistemului. Al doilea pas este analiza domeniului, realizat prin definirea
claselor: atributele, metodele, motenirea. Faza de analiz este terminat cu un pas de
validare. Aceast faz itereaz cei trei pai pn cnd soluia este consistent.
i faza de proiectare este iterativ. Design-ul logic este transformat n design fizic,
cu detalii privind firele de execuie, procesele, performanele, tipurile de date, structurile
de date etc. Se creeaz un prototip i apoi se testeaz. Faza itereaz design-ul logic, cel
fizic, prototipurile i testarea.
Metodologia Booch este secvenial n sensul c mai nti este terminat analiza i
apoi proiectarea. Ea este ciclic datorit iteraiilor din fiecare faz. Metoda se concentreaz
n special asupra acestor dou faze, de analiz i proiectare, fr s insiste foarte mult
asupra implementrii i testrii.
Metode formale
n acest model de dezvoltare, sunt folosite formalismul i rigoarea matematicii. n
prima faz este construit o specificaie n limbaj matematic. Apoi, aceast specificaie
este transformat n programe, de obicei printr-un proces incremental.
Avantaje:

precizia obinut prin specificarea formal;

pstrarea corectitudinii n timpul transformrii specificaiei n cod executabil;

ofer posibilitatea generrii automate de cod;

verificarea consistenei i testarea prin metode similare demonstrrii automate

de teoreme.
Dezavantaje:

specificarea formal este de obicei o barier de comunicare ntre client i

analist;

necesit personal foarte calificat (deci mai scump);

folosirea impecabil a tehnicilor specificrii formale nu implic neaprat

obinerea de programe sigure, deoarece anumite aspecte critice pot fi omise din
specificaiile iniiale.
Datorit acestor caracteristici, metodele formale sunt potrivite n special pentru
sisteme cu cerine critice.
Exist mai multe limbaje pentru specificarea formal a funcionalitii programelor:
Z, CSP (Communicating Sequential Processes), VDM (Vienna Development Method),
Larch, FDM (Formal Development Methodology) etc.
Extreme Programming
Extreme Programming (Kent Beck, 1996) este o metodologie care propune rezolvri
originale pentru problemele care apar n dezvoltarea de programe. Fiind o tehnologie nou
(i extrem) are att adepi ct i critici. XP consider c dezvoltarea programelor nu
nseamn ierarhii, responsabiliti i termene limit, aa cum se afl acestea pe masa
administratorului, ci nseamn colaborarea oamenilor din care este format echipa. Acetia
sunt ncurajai s i afirme personalitatea, s ofere i s primeasc cunotine i s devin
programatori strlucii.
19

De asemenea, XP consider c dezvoltarea de programe nseamn n primul rnd

scrierea de programe. Aceast sintagm banal se pare c este uitat de multe companii
care se ascund n spatele proceselor de dezvoltare stufoase, a edinelor i a rapoartelor de
activitate. XP ne amintete cu respect ca fiierele PowerPoint nu se pot compila.
De altfel, inspirarea proceselor de dezvoltare a programelor din ingineria
construciilor se pare c nu este cea mai fericit alegere. Este adevrat c un inginer care
vrea s construiasc un pod peste un ru face mai nti msurtori, realizeaz un proiect i
abia apoi trece la execuie, toate acestea ntr-un mod secvenial i previzibil. Dar
dezvoltarea de programe nu seamn cu aa ceva, orict am vrea s credem asta. Dac
inginerului constructor respectiv i s-ar schimba cerinele de rezisten i i s-ar muta
malurile chiar cnd a terminat de construit jumtate de pod, putem fi siguri c acel inginer
i-ar schimba modul de lucru. Din pcate ns, nu tim (nc) cum.
Iniiatorii XP definesc urmtoarele dou carte, ca baz filosofic pentru aceast
metodologie.
Carta drepturilor dezvolttorului:

Ai dreptul s tii ceea ce se cere, prin cerine clare, cu declaraii clare de

prioritate;

Ai dreptul s spui ct i va lua s implementezi fiecare cerin, i s i

revizuieti estimrile n funcie de experien;

Ai dreptul s i accepi responsabilitile, n loc ca acestea s-i fie asignate;

Ai dreptul s faci treab de calitate n orice moment;

Ai dreptul la linite, distracie i la munc productiv i plcut.

Carta drepturilor clientului:

Ai dreptul la un plan general, s tii ce poate fi fcut, cnd, i la ce pre;

Ai dreptul s vezi progresul ntr-un sistem care ruleaz i care se dovedete c

funcioneaz trecnd teste repetabile pe care le specifici tu;

Ai dreptul s te rzgndeti, s nlocuieti funcionaliti i s schimbi

prioritile;

Ai dreptul s fii informat de schimbrile n estimri, suficient de devreme

pentru a putea reduce cerinele astfel ca munca s se termine la data prestabilit. Poi chiar
s te opreti la un moment dat i s rmi cu un sistem folositor care s reflecte investiia
pn la acea dat.
Aceste afirmaii, dei par de la sine nelese, conin semnificaii profunde. Multe din
problemele aprute n dezvoltarea programelor pornesc de la nclcarea acestor principii.
Enumerm pe scurt cteva dintre caracteristicile XP:

Echipa de dezvoltare nu are o structur ierarhic. Fiecare contribuie la proiect

folosind maximul din cunotinele sale;

Scrierea de cod este activitatea cea mai important;

Proiectul este n mintea tuturor programatorilor din echip, nu n

documentaii, modele sau rapoarte;

La orice moment, un reprezentant al clientului este disponibil pentru

clarificarea cerinelor;

Codul se scrie ct mai simplu;

Se scrie mai nti cod de test;

Dac apare necesitatea rescrierii sau eliminrii codului, aceasta se face fr

20

mil;

Modificrile aduse codului sunt integrate continuu (de cteva ori pe zi);

Se programeaz n echip (programare n perechi). Echipele se schimb la

sfritul unei iteraii (1-2 sptmni);

Se lucreaz 40 de ore pe sptmn, fr lucru suplimentar.

Procesul de testare software

n procesul de dezvoltare software testarea ocup cea mai mare parte din timpul
alocat pentru proiect. Un mare dezavantaj n proiectele IT este acela c dezvolttorii
subestimeaz testarea software, o neglijeaz. Ca urmare sunt puse n funciune aplicaii
care n loc s uureze munca utilizatorului mai mult o ngreuneaz datorit erorilor
generate de aplicaie.
n dezvoltarea unui produs software testarea este un proces, care se desfoar n
mai multe etape i pe mai multe nivele.

Etapele procesului de testare software

Etapele procesului de testare sunt:
implementarea i execuia i evaluarea testelor.

planificarea,

analiza

proiectarea,

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.
Planificarea testrii are scopul de a determina ce s testeze i ct s testeze, astfel
nct procesul de testare s se ncadreze n limitele resurselor alocate. n urma planificrii
testrii rezult planul de test, un document pe baza cruia se desfoar celelalte faze ale
testrii. n aceast faz se identific i obiectivele testrii.
Planul de test este un document important, fiind utilizat ca baz pentru desfurarea
ntregului proces de testare. n plus, trebuie identificate i sursele de risc n testare.
Planificarea testrii poate s nceap din momentul n care au fost elaborate cerinele
aplicaiei software. n planul de test sunt descrise:
aria de cuprindere;
responsabilitile fiecrui membru al echipei de testare;
resursele umane necesare;
desfurarea n timp a testelor;
descrierea i configurarea mediului specific aplicaiei;
lista echipamentelor care trebuie achiziionate;
crearea i managementul datelor de test;
criteriile de acceptare a testelor.
Deoarece este foarte dificil s se stabileasc momentul n care se va ncheia testarea,
n planul de test se specific o serie de criterii care constituie o baz pentru determinarea
finalizrii testrii.
Analiza testelor
n etapa de analiz se identific urmtorii pai:
21

 identificarea scopurilor, obiectivelor i a strategilor testrii de ctre echipa de

testare;
metodele de verificare sunt asociate cerinelor sistemului sau cazurilor de
utilizare i sunt documentate n cadrul unei matrice de urmrire a cerinelor;
analiza cerinelor testelor;
construirea matricei cerinelor testelor, n care declaraiile cerinelor testelor sunt
asociate cerinelor sistemului sau a cazurilor de utilizare;
asocierea tehnicilor de testare cu declaraiile cerinelor testelor.
n faza de analiz a procesului de testare, un aspect important l
ocup analiza cerinelor pentru testare. Cerinele testrii trebuie s fie identificate i
documentate astfel nct toate persoanele implicate n procesul de testare s fie contiente
de scopul acestuia. Analiza se desfoar din mai multe puncte de vedere, depinznd de
faza de testare. Astfel se identific o abordare structural i o abordare bazat pe
comportament.
Proiectarea testelor
Etapa de proiectare a testelor urmeaz dup ncheierea analizei. n faza de
proiectare, apar urmtorii pai:
definirea modelului programului de test astfel nct acesta s reflecte tehnicile de
testare utilizate;
definirea arhitecturii de test;
definirea procedurilor de test;
luarea deciziei de automatizare a anumitor teste i de testare manual a altor
componente;
asocierea datelor de test astfel nct fiecare cerin pentru datele de test s se
reflecte pentru fiecare procedur de test.
Programul de test se elaboreaz fie la nivelul proiectrii, fie la nivelul tehnicilor de
testare. n primul caz, procedurile de test sunt asociate componentelor hardware i
software ale aplicaiei, iar n al doilea caz procedurile de testare sunt vzute la nivelul
tehnicilor de testare.
Proiectarea procedurilor de test ncepe dup determinarea cerinelor testrii.
Proiectarea procedurilor de test const n:
analiza arhitecturii de test pentru determinarea tehnicilor de testare relevante;
definirea procedurilor de test att la nivelul sistemului ct i la nivelul de
implementare;
elaborarea sau preluarea de standarde de utilizare a procedurilor de test;
identificarea procedurilor de test care vor fi efectuate manual i a celor care vor fi
efectuate automat;
identificarea procedurilor de test complexe, pentru a fi proiectate n continuare n
faza de proiectare detaliat;
proiectarea detaliat.
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 aceti parametri. Realizarea de
cazuri de test ct mai complete duce la descoperirea unui numr mai mare de erori.
22

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
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 o
persoan 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 baz de date care conine i alte
informaii referitoare la aplicaia software realizat.
Execuia i evaluarea testrii de integrare necesit noi secvene de test pe msur 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.
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.

Nivelurile de testare software

n dezvoltarea unui produs software testarea se realizeaz pe mai multe nivele:
testarea de module, testarea de integrare, testarea de sistem i testarea de acceptare.
Pentru ilustrarea acestor nivele vom folosi modelul-V, care corespunde metodologiei
cascad de dezvoltare a softului, deoarece ne poate furniza mai multe detalii tehnice dect
celelalte metodologii.
Exist mai multe variante ale acestui model. n figura 6 este prezentat una dintre
ele.

23

Figura 6. Modelul-V pentru dezvoltarea softului

n partea stng a acestui model avem:
Specificaiile cerinelor - reflect necesitile utilizatorilor.
Specificaiile funcionale - definirea funciilor necesare pentru realizarea cerinelor.
Specificaiile tehnice - proiectarea tehnic a funciilor identificate n specificaiile
funcionale.
Specificaiile programului - proiectarea detaliat a oricrui modul conform
cerinelor de funcionalitate.
Mijlocul aceluiai model ne demonstreaz c planificarea i testarea trebuie s
nceap odat cu specificarea cerinelor pentru orice produs software. Astfel nc de la
aceast etap se planific testele de validare a produsului.
Partea dreapt se axeaz pe activitile de testare.
Testarea conform cerinelor se realizeaz la etapa testrii de acceptare .
Testarea conform specificaiilor funcionale se reia odat cu testarea sistemului
Testarea conform specificaiilor tehnice are loc odat cu testarea de integrare.
Testarea conform specificaiilor programului se realizeaz la faza de testare a
modulelor.
Aceasta permite orientarea testrii la detaliile predestinate produsului soft, ceea ce
favorizeaz depistarea precoce a defectelor.
Fiecare etap a testrii trebuie definitivat nainte de nceperea urmtoarei, astfel
validarea soft-ului de ctre utilizatori se va produce exact la sfritul ciclului de
dezvoltare. Dac cerinele beneficiarului nu au fost total respectate (receptate corect) sau
au fost modificate, problema se soluioneaz doar dup ce acesta testeaz (utilizeaz)
produsul. Rezolvarea problemei la etapa de validare este foarte costisitoare. Cu att mai
mult se poate recurge la anularea proiectului.
24

Termenul nivelul testrii indic scopului testrii i tipurile de probleme care le

poate descoperi. Fiecare nivel va include teste care vor nltura problemele specifice etapei
respective de dezvoltare. Aceste nivele pot fi aplicate i celorlalte metode de dezvoltare a
softului. Acestea se modific n dependen de sistem. De ex., dac sistemul presupune
folosirea unor componente soft dezvoltate de o parte ter, testarea de acceptare se petrece
naintea testrii de sistem.
n continuare sunt descrise mai n detaliu nivelele de testare.
Testarea de module
n cadrul testrii de module se realizeaz verificarea celor mai mici uniti software
care pot fi compilate i link-editate independent. n programarea clasic un modul este un
subprogram (funcie sau procedur). n cadrul programelor orientate obiect, cea mai mic
unitate testabil este clasa.
Testarea de module se concentreaz asupra verificrii interfeelor modulelor,
structurilor de date locale, condiiilor de la limite, cilor independente i cilor de tratare a
erorilor.
Deoarece modulele nu sunt programe de sine stttoare, este necesar s se
construiasc programe sau funcii care s ajute la testarea de module.
O prim categorie o reprezint programele conductoare (drivers) care apeleaz
modulele supuse testrii cu datele de test construite i preiau rezultatele execuiei.
O alt categorie este reprezentat de funciile sau procedurile apelate de ctre
modulul de testat. Acestea sunt substituite cu subprograme care au acelai prototip, ns cu
funcionalitate redus la minim, denumite module vide (stubs). Modulele vide sunt funcii
sau proceduri simple care nu fac nimic n afara returnrii controlului, sau sunt funcii sau
proceduri complexe, care simuleaz efectul apelrii modulelor reale. n cele mai multe
cazuri, modulele vide simple sunt nepotrivite. Un efort considerabil este necesar pentru
implementarea de module vide complexe.
Testarea de integrare
Aceasta este o tehnic sistematic de construire a structurii programului prin
gruparea componentelor n paralel cu testarea aspectelor legate de interfaa dintre
componente. Aici se pot evidenia dou maniere de testare: neincremental sau
incremental.
Testarea neincremental (big-bang testing) const n integrarea componentelor prin
gruparea tuturor modulelor dintr-o dat, urmat de testarea ntregului ansamblu. Acest tip
de integrare nu este recomandat, deoarece corectarea erorilor va fi foarte greu de realizat.
Testarea incremental presupune construirea structurii programului pas cu pas i
testarea ansamblului obinut. Un element important n execuia testului este secvena n
care modulele trebuie s fie testate. Astfel, testarea de integrare se realizeaz ascendent
(bottom-up), descendent (top-down) sau mixt.
Testarea de integrare se poate realiza prin cteva metode:
Metoda de testare ascendent (bottom-up testing).
25

Aceast metod presupune testarea mai nti a modulelor de pe cel mai de jos nivel
al ierarhiei programului, apoi se continu n sus cu testarea celorlalte module. Metoda de
testare ascendent necesit construcia de programe conductoare pentru a iniializa mediul
i pentru a apela modulele.

Figura 7. Bottom-up integration testing

Conform acestei scheme integrarea componentelor se va face n urmtoarea ordine:
4,2
5,2
6,3
7,3
2,1
3,1
Programele de pe nivelul de sus, care de obicei sunt critice, sunt testate ultimele. n
timp sunt descoperite erori care pot influena multe module care au fost deja testate. Dup
corecia erorilor este necesar ca toate modulele de pe nivelurile de jos s fie testate
regresiv.
Metoda de testare descendent (top-down testing).
n metoda testrii descendente modulul din vrful ierarhiei de programe este testat
primul, procesul de testare continund cu modulele de pe nivelurile inferioare. Metoda de
testare descendent necesit construcia de module vide asociate subprogramelor care nu
sunt disponibile.

26

Figura 8. Top-down integration testing

Conform acestei scheme integrarea componentelor se va face n urmtoarea ordine:
1,2
1,3
2,4
2,5
3,6
3,7
Avantajul acestei metode este c dac este descoperit o eroare n modulele de pe
nivelurile nalte, impactul va fi asupra modulelor de pe nivelurile de jos care nu au fost
nc implementate, deci refacerea modulelor de pe nivelurile inferioare poate fi evitat.
Metoda mixt.
n cadrul metodei mixte, testarea urmeaz mai nti metoda descendent. Modulele
selectate de pe nivelurile inferioare sunt testate utiliznd metoda ascendent. Aceast
flexibilitate permite preluarea avantajelor metodelor de ascendent i descendent. n cele
mai multe aplicaii, metoda mixt este cea mai potrivit modalitate de abordare.
Pe msur ce sunt adugate noi module n cadrul testrii de integrare, apar
schimbri n software, care pot s modifice comportamentul structurii obinute anterior. n
acest context este executat testarea de regresie, prin care se re-testeaz noua structur
obinut, utiliznd o parte din testele utilizate n etapa precedent.
Testarea de integrare poate reprezenta mai mult dect un nivel de testare. De ex. :
Testarea de integrare a componentelor se focuseaz pe interaciunea dintre
elementele soft-ului i e realizat dup testarea modulelor (unit testing). Testarea se
realizeaz de ctre dezvolttori.
Testarea de integrare a sistemului se axeaz pe interaciunea dintre diferite sisteme
i se poate efectua dup testarea fiecrui sistem n parte. De ex. un sistem comercial
ntr-o banc de investiii va interaciona cu bursa de valori pentru a obine ultimul
pre pentru fondurile i aciunile sale pe piaa internaional. Testarea se realizeaz
de ctre testeri.
27

Testarea de sistem
Dac ne-am convins de funcionarea mpreun a elementelor la nivel de module, se
trece la etapa urmtoare verificarea funcionalitii sistemului ca un tot ntreg.
Activitatea poart numele de testarea sistemului.
Testarea sistemului se impune din cauza c multe criterii ale testrii de module i
testrii de integrare genereaz seturi de cazuri de test nereprezentative pentru condiiile
reale de operare. Astfel testarea la aceste nivele este puin probabil s depisteze erori ale
interaciunii cu ntregul sistem ori probleme de mediu.
Testarea sistemului servete la nlturarea dezechilibrului prin concentrarea asupra
comportamentului ntregului sistem/produs precum este definit de scopul dezvoltrii
proiectului sau programului, ntr-un mediu de lucru reprezentativ. De obicei acesta este
realizat de o echip independent. Independena asigur obiectivitatea evalurii
sistemului, care se bazeaz pe specificaiile scrise, i nu pe codul produsului soft.
n modelul -V, comportarea adecvat a sistemului se documenteaz n specificaia
funcional, care definete ce trebuie construit pentru a satisface cerinele sistemului.
Specificaia funcional trebuie s conin definiiile ambelor cerine ale sistemului
funcionale i non-funcionale.
O cerin funcional este o cerin ce specific o funcie obligatorie a sistemului sau
a unei componente a sistemului. De ex., ai vrea s fie posibil programarea unui zbor pe
un website al unei companii turistice, n timp ce verifici on-line contul, dac ai suficiente
mijloace bneti pentru a plti pentru zbor.
Aceste cerine fundamentale furnizeaz detalii n baza crora se va dezvolta
aplicaia.
Testarea non funcional a sistemului examineaz aspectele importante, dar
influeneaz direct funciile pe care le ndeplinete sistemul. Acestea sunt nite cerine
generice (universale), care ar putea fi aplicate mai multor sisteme. n ex. de mai sus, de
pild ai vrea ca ambele sisteme s rspund apelului nostru (implicaiilor) ntr-un timp
rezonabil. Tipic aceste cerine vor aprecia ca normale ambele operaiuni la fel i
comportamentul sistemului n circumstane excepionale.
Astfel cerinele non-funcionale explic comportamentul aplicaiilor n practic.
Exemple de cerine non-funcionale:
Instabilitatea - proceduri de instalare.
Interoperabilitatea - execuia aplicaiei n diferite medii de lucru.
Stabilitatea - posibilitatea de a face schimbri n sistem.
Performana - comportamentul normal, ateptat.
ncrcarea ( loading) - comportamentul sistemului cnd resursele sunt ncrcate la
maxim.
Portabilitatea - utilizarea pe diferite platforme.
Capacitatea de recuperare - restabilirea sistemului dup ncheerea
necorespunztoare a execuiei.
Fiabilitatea - capacitatea softului de a-si pstra funcionalitilor dup o perioad de
timp.
Utilizabilitatea - simplitatea de comunicare a utilizatorului cu sistemul.

28

n literatura de specialitate, sunt prezentate cteva tehnici specifice pentru testarea

de sistem:
1. Testarea pentru determinarea capacitii de recuperare este un test de sistem
care, printr-o multitudine de ci, foreaz aplicaia software s i ncheie execuia n mod
necorespunztor. Prin acestea se testeaz capacitatea aplicaiei de revenire dintr-o situaie
necorespunztoare.
2. Testarea securitii se realizeaz pentru a verifica eficiena mecanismelor de
protecie dintr-un sistem software i dac acesta se comport corespunztor la atacurile
externe.
3. Testarea de solicitare se execut astfel nct sistemul s funcioneze cu un volum
mai mare de resurse dect cel normal, cu scopul de a determina fiabilitatea aplicaiei i
momentul n care funcionarea aplicaiei devine critic i pentru a lua msurile
corespunztoare, astfel nct s nu se ajung n exploatarea de zi cu zi a sistemului
informatic la astfel de situaii.
4. Testarea de ncrcare const n rularea sistemului software n condiiile n care
resursele (memorie, microprocesor, reea) sunt ncrcate la maxim astfel nct se ajunge la
situaii critice, n care o parte din resurse nu mai sunt disponibile. Se urmrete capacitatea
sistemului de a-i ntrerupe funcionarea fr pierderea sau coruperea datelor.
5. Testarea performanelor se realizeaz pentru determinarea conformitii
sistemului cu cerinele de performan impuse. De exemplu sistemul este ncrcat ntr-un
interval de timp pornind de la capacitatea minim pn la capacitatea maxim i se
verific dac resursele sistemului se afl n limitele corespunztoare i nu sunt ntrzieri n
executarea funciilor aplicaiei.
Securitatea se consider o cerin funcional a sistemului.
Testarea de acceptare
Testarea de acceptare are loc dup ce toate erorile de interfa descoperite n cadrul
testrii de integrare au fost corectate. De ex., testarea de acceptare poate evalua starea de
pregtire a sistemului pentru desfurare i utilizare.
Testarea de acceptare este o responsabilitate a beneficiarului sau utilizatorului, ns
pot fi implicai i ali membri ai echipei.
Formele tipice ale testrii de acceptare includ urmtoarele:
Testarea de acceptare a utilizatorului - testarea de ctre reprezentanii utilizatorilor
pentru a verifica dac sistemul satisface cerinele de business.
Testarea de acceptare a funcionalitii - denumit deseori testarea pregtirii
pentru activitate. Aceasta presupune verificarea dac procesele i procedurile sunt
n ordine i pot asigura utilizarea i stabilitatea sistemului. Activitatea include:
- Posibilitile de back-up
- Procedurile pentru restabilire dup eecuri
- Instruirea utilizatorilor
- Procedurile de stabilitate
- Procedurile de securitate
Testarea de acceptare a contractului i reglementrilor
- Testarea de acceptare a contractului - uneori criteriile de acceptare ale unui
sistem sunt consemnate n contract. Testarea se efectueaz nainte de validarea sistemului,
pentru confirmarea respectrii criteriilor solicitate.
29

- Testarea de acceptare a reglementrilor - n unele industrii sistemul trebuie s

respecte unele standarde guvernamentale, legale sau de securitate.
n cadrul testrii de acceptare se regsesc testrile alfa i beta. Testarea alfa este
realizat la firma care produce aplicaia software, beneficiarul fiind acela care conduce
testele. Testarea beta este realizat la beneficiari i utilizatori finali. Acetia primesc o
versiune a aplicaiei software, versiune apropiat de cea final i o utilizeaz n scopul
descoperirii erorilor i a problemelor de performan i funcionalitate. Problemele aprute
n cadrul acestei testri sunt raportate firmei care a realizat aplicaia. Dup ce perioada
acordat pentru testarea beta s-a terminat, toate erorile aprute sunt corectate, urmnd s se
realizeze versiunea final a aplicaiei software.
Testarea regresiv
Paragrafele anterioare arat necesitatea realizrii testrii la diferite etape ale
dezvoltrii produsului. Nici o etap a testrii nu este absolvit de depistarea erorilor.
Depistarea i nlturarea acestora mbuntete calitatea sistemului.
Depistarea i nlturarea unei greeli atrage dup sine retestarea pentru a se asigura
c problema a fost cu succes ameliorat. nlturarea defectului se numete debugging,
care nu e o activitate de testare. Testarea detecteaz defectele, iar prin debugging ele sunt
nlturate.
Un sistem, care nu a fost modificat, de asemenea trebuie testat pentru a se asigura
dac nu au fost introduse schimbri adiionale la schimbarea softului. Acest tip de testare
se numete testare regresiv. Testarea regresiv se desfoar i cnd este schimbat
mediul de lucru. Testarea regresiv presupune crearea unui set de teste care ar servi la
demonstrarea c sistemul funcioneaz corect. Acestea se vor aplica de mai multe ori
produsului testat. Repetarea testelor provoac, n unele cazuri, automatizarea testrii
regresive.
Testarea de ntreinere (maintenance testing)
Pentru multe proiecte sistemul este realizat n medii reale de lucru, ceea ce asigur o
funcionalitate ndelungat.
n perioada de dezvoltare sistemul poate suferi schimbri condiionate. Schimbrile
pot fi provocate de :
Cerine adiionale solicitate.
Schimbarea sistemului pe o platform de operare nou.
Sistemul este n curs de retragere din uz - datele cer schimbare sau arhivare.
Depistarea noilor erori.
Odat ce s-au efectuat modificrile, sistemul trebuie testat (testul de confirmare) i
trebuie supus analizei regresive pentru a verifica dac restul sistemului nu a suferit
schimbri adverse din cauza lor. Testarea sistemului n condiii reale ( n mediu real de
lucru) se numete testare de ntreinere.
Orice modificare trebuie testat, n mod ideal, ntregul sistem trebuie supus testrii
regresive. n practic activitile pot fi irealizabile sau costisitoare. Identificarea prii care
poate fi afectat de modificri ar reduce numrul testrilor regresive. Activitatea se
numete - analiza impactului( analizarea efectului schimbrilor asupra sistemului).
Analizarea impactului este dificil pentru un sistem deja realizat, deoarece
specificaiile pot lipsi, ori echipa de implementare lucreaz la un alt proiect, sau au prsit
organizaia.
30

Testarea static
Capitolul prezint o introducere n una dintre cele mai importante arii ale testrii tehnicile statice de testare. Tehnicile statice testeaz software fr a-l executa. Totui
prezint importan 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.
Tehnicile de inspecie (review) se axeaz pe tehnicilor statice. Astfel n acest capitol vom
cerceta diferite tipuri de inspecie i concordana lor cu procesul de testare definit n cap.2.
Capitolul trateaz 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 e deseori imposibil de realizat manual, astfel vom cerceta
tipurile testrii statice care solicit anumite mijloace (instrumente). Ne vom axa pe
tehnicile testrii statice, mijloacele caracteristice tipului de testare sunt descrise n alt
capitol. (cap.6)

Generaliti despre tehnicile statice

Tehnicile testrii statice presupun tehnicile de testare a soft-ului care nu implic
executarea codului. Aceasta include att testarea produsului soft diferit de cod, cerinele
tipice ori documentele ce conin specificaiile, i testarea codului fr executarea lui.
Prima activitate se numete revizuire (inspecie) i e utilizat de obicei pentru nlturarea
erorilor i ambiguitilor din documente nainte de a fi utilizate 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.(vezi cap.6)

Verificarea i testarea
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:
31


Poate fi mbuntit productivitii i reducerea limitelor temporale deoarece
corectrile defectelor ntr-o etapa incipient vor asigura c produsul este clar i
neambiguu. Aceasta ar trebui s-l ajute pe dezvolttor 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 testului.

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 softului. Revizuirea codului i detectarea defectelor nainte de
a deveni eecuri i permite testorului executarea mai rapid a testului.

n realitate e posibil obinerea reducerii costului datorit numrului mic de

defecte n final, care asigur c cheltuielile curente vor fi reduse.

Comunicarea constructiv se datoreaz autorilor i colegilor lor care

cerceteaz i nltur orice ambiguitate descoperit n timpul revizuirii pentru a asigura c
orice participant a neles exact ce se livreaz.
Cele mai tipice greeli depistate la revizuire:

Abaterile de la standardele interne i reglementrilor / legal definite de

Parlament sau de o organizaie comercial.

Defectele cerinelor-de ex. cerinele sunt ambigue sau au unele elemente lips.

Defectele de design - de ex. design-ul nu respect toate cerinele.

Insuficiena stabilitii - de ex. codul este prea complex i greu de meninut.

Interfaa incorect a specificaiilor - de ex. 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.
32

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 verificare

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 revizuirile tehnice i inspeciile, dein anumite
caracteristici prin care se deosebesc de cele mai puin oficiale.
Figura 9 demonstreaz etapele cheie 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

33

Figura 9. Etapele revizuirii formale

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 ex. inspecia).
* Selectarea prilor documentelor care trebuiesc revzute (nu ntotdeauna
necesar, aceasta depinde de mrimea documentelor: un document mai mare
necesit mprirea lui n pri mai mici 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
34

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.
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: 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.
35

 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 testerului. 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 testerul 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 testerul 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 ex. 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 4 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 ex. 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.
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.

36

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

37

 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 softului 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).
Mai pot fi utilizate n testarea static i urmtoarele metrici:
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 a softului i n modelele
software.
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 dezvolttor.
Un model software este imaginea unei soluii finale dezvoltate utiliznd tehnici ca
Unified Modeling Language (UML) - Limbajul de Modelare Unificat (LMU); generat de
designerul software.
Analiza static poate depista defectele dificil de depistat la executarea testului prin
analizarea codului programei, ex. 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.
38

 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.
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, ex. structurile password care nu sunt sigure.
Violarea sintaxei codului i modelelor soft, ex. 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 dezvolttori
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 software 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.

Tehnici de proiectare a testelor

39

Acest capitol trateaz un subiect destul de complex - tehnicile de design ale testelor.
ncepem prin familiarizarea cu unii termeni cheie i procesul fundamental de creare a
unei suite de teste pentru executare. Capitolul cerceteaz 3 categorii de tehnici de design
ale testelor: specification - based, structure - based i experience - based. Pentru fiecare
caz sunt explicate tehnicile specifice i exemplificate modalitile de utilizare. n final
discutm despre selectarea tehnicilor.

Test conditions, test cases i test procedures

Specificaia cazurilor de test este a 2 etap n procesul fundamental de testare (PFT)
definit n tema 2. Termenii specificaie i design sunt utilizate interanjabil n acest
context: n acest paragraf vom discuta despre crearea cazurilor de test cu ajutorul designului.
Proiectarea testelor conin 3 etape:
1. Identificarea condiiilor de testare.
2. Specificarea cazurilor de test.
3. Specificarea procedurilor de testare.
Prima sarcin pe care ne-o propunem e familiarizarea cu terminologia.
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, ex. 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
printr-un test sau un set de teste.
Test case - un set de valori incluse, executarea precondiiilor, rezultatele ateptate i
executarea postcondiiilor, dezvoltate pentru un obiectiv particular sau pentru condiia de
test, astfel nct s solicite o anumit 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 aplic 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 specificaie ce se va ntmpla cnd
se vor aplica input value.
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 dac se
finiseaz n locul potrivit.
Selectarea cazurilor de test este unicul pas important pe care testerii de soft-uri l
fac. Selectarea incorect a acestora induce testarea prea ndelungat, prea puin sau
testarea unor lucruri eronate. Estimnd inteligent riscurile i reducnd infinitatea de
posibiliti la un set eficient i administrabil de date n aceasta const tot farmecul.
Specificaia procedurii de testare o consecutivitate de aciuni pentru execuia
testului.

40

Procedura de testare - identific toate aciunile necesare executrii testului ntr-o

anumit ordine. Procedura de testare - deseori e numit test script (sau manual test script
pentru al deosebi de automated scripts care se execut cu diferite instrumente)
Pornind de la cele 3 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, ex. 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 s 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.

Bazele design-ului cazurilor de test

S presupunem c avem un sistem care conine urmtoarea specificaie pentru ecran:
1.2.3 ecranul trebuie s conin 3 cmpuri: un cmp titlu cu un selector dropdown, un cmp pentru prenume care accept mai mult de 20 de caractere din alfabet i
semnul (-) cratim; primul cmp pentru nume care accept peste 20 de caractere din
alfabet. Toate caracterele alfabetice trebuie s fie cazuri insenzitive. Toate cmpurile
trebuie s fie completate. Datele sunt validate la tastarea Enter. Odat validate datele
sistemul se mic spre job input screen, dac nu, se prezint un mesaj eroare.
Aceast specificaie permite definirea condiiilor testului. De ex., putem defini
condiia testului pentru cmpul prenumelui (el accept peste 20 de caractere alfabetice i
cratima) i poate defini un set de cazuri de test pentru a testa acest cmp.
Pentru a testa cmpul prenume va trebui s navigm sistemul la ecran, s selectm
un nume, s trecem la cmpul prenume (acestea presupun respectarea precondiiilor
testului), s introducem o valoare (prima parte a setului de valori), trecem la primul cmp
nume i introducem o valoare ( a doua parte care ne trebuie pentru a completa toate
cmpurile), apoi tastm Enter. Sistemul se va orienta spre job input screen (dac datele
incluse sunt valide) sau va afia un mesaj de eroare (dac datele introduse nu sunt valide).
Desigur se vor testa ambele cazuri.
Aliniatul precedent este efectiv o procedur de testare, pe care l putem expune
diferit de testarea real.
Un caz de test reuit conine unele informaii adiionale. n primul rnd, el trebuie
s fie coordonat cu condiia testului i cu elementele specificaiei testate, ex. prin
identificarea acestui test ca T1.2.3.1 (pentru c este primul test asociat cu specificaia
1.2.3.). n al doilea rnd vom avea nevoie s adugm o valoare specific pentru
introducerile, s zicem Hambling i Brian. n final vom specifica c sistemul trebuie s se
mite la job input screen la tastarea Enter.
Exemplu de proiectare a unui caz de test
Ca un exemplu, putem include urmtoarele cazuri de test:
Mr. Hambling
Brian
Ms. Samaroo
Angelina
Ms. Simmonite
Compo
41

Ms.

Hyde-Wide

Wilfred

Cazurile de test vor fi validate, cu toate c Compo Simmonite a fost un brbat

imaginar, personaj al unui serial TV, datele de intrare sunt corecte conform specificaiei.
Trebuie s testm unele date de intrare invalide, ca:
Mr. Thompson1 Geoff
Mr Morgan Peter
Mr. Williams Pete
Exist mai multe posibiliti de a nclca regulile specificaiei, dar acestea vor servi
la ilustrarea ideilor. Putei considera c aceast simpl specificaie poate genera un numr
impuntor de cazuri de test i vei avea dreptate. Unul dintre scopurile noastre n utilizarea
tehnologiilor de design a cazurilor de test va reduce numrul testelor necesare pentru a
atinge nivelul dat de ncredere n softul testat.
Procedura de testare va avea nevoie de adugat unele detalii pe parcursul
urmtoarelor linii:
1. Selecteaz opiunea <Nume sau Detalii Personale> din meniul principal.
2. Selecteaz opiunea Input pentru meniul Name i Detalii Personale.
3. Selecteaz Mr. din Title drop - down menu.
4. Verific dac cursorul se mic spre cmpul first name.
5. Tapeaz n Hambling i apas tab key o dat.; verific dac cursorul se mic la
cmpul first name.
6. Tapeaz n Brian i tasteaz Enter.
7. Verific dac ecranul Job Input este prezentat.
8. ....
Acestea ar trebui s fie suficiente pentru a demonstra ce trebuie de definit, i de
asemenea ct de ncet i dificil se va desfura un asemenea test.
Procedura de testare va aduna mpreun toate cazurile de test relatate de aceste
elemente de specificare nct se vor putea executa mpreun ca un bloc.
ntr-un proces mai amplu vom trece la urmtoarea etap a executrii testului. La
pregtirea pentru executarea testului, planul de executare a testului adun la un loc toate
testele i le aranjeaz ntr-o consecutivitate, innd cont de orice prioritate (testul cu cea
mai mare prioritate se va executa primul) i orice dependen dintre teste. De ex. se
recomand realizarea tuturor testelor referitoare la input screen mpreun i celelalte teste
care utilizeaz input data mai pe urm. Astfel facem ca testele ecranului s realizeze data
entry de care vom avea nevoie pentru testele de mai trziu. Consecutivitatea testelor poate
fi influenat i de unele cauze tehnice; de ex. testarea securitii parolei se va realiza
naintea celorlalte teste deoarece trebuie s intram n sistem pentru a desfura alte teste.
Testarea de acceptare i testarea spre eec
Sunt dou abordri fundamentale ale testrii de program: testarea de acceptare i
testarea spre eec. Cnd testai pentru acceptare, asigurai doar c softul ndeplinete
funciile minimale. Nu i presai capacitile. Nu ncercai s facei ceva ce l-ar scoate
din funciune. l tratai cu acuratee, aplicnd cazuri de test ce nu ar atinge careva limite
sau puncte slabe.

42

Putei crede c dac scopul Dvs. e de a gsi neajunsurile, pentru ce ar trebui s

testm pentru acceptare? Nu ai dori s gsii neajunsuri prin oricare mijloace? Rspunsul
este nu, nu iniial.
Proiectnd i rulnd cazurile Dvs. de test, aplicai mai nti testele de acceptare. Este
important de a vedea dac softul funcioneaz fundamental, nainte de a turna murdria
peste el. Putei fi surprins de numrul de neajunsuri gsite doar la o utilizare normal.
Dup ce v-ai asigurat c softul funcioneaz cum este specificat n circumstane
ordinare, este timpul s v punei la btaie mijloacele josnice, irete i ocoliurile, cu
scopul de a depista neajunsuri ncercnd lucrurile, care ar fora apariia acestora.
Proiectarea i rularea cazurilor de test cu singurul scop de a distruge softul este numit
testare spre eec sau forarea apariiei erorilor. Vei studia ulterior n acest capitol c
cazurile testrii spre eec deseori nu par periculoase. Ele par deseori cazuri ale testrii de
acceptare, dar sunt selectate strategic pentru a sonda punctele slabe comune ale softului.
Mesaje de eroare
O clas comun de teste este una care ncearc s foreze apariia mesajelor de
eroare. Cunoatei unele precum salvarea unui fiier pe dischet fr a avea ns una
inserat n dispozitiv. Aceste cazuri de fapt balanseaz ntre testarea de acceptare i
testarea spre eec. Specificaia probabil stipuleaz c asemenea condiii de intrare vor
genera un mesaj de eroare. Pare destul de clar c este un caz de testare de acceptare. Dar,
forai de asemenea o eroare, deci aceasta se poate privi ca o testare spre eec. n fine, sunt
probabil ambele.
Nu v ngrijorai pentru distincie. Ce este cu adevrat important este s ncercai
forarea apariiei mesajelor de eroare ce nu au fost nicicnd considerate. Probabil vei
sfri prin a gsi att neajunsuri de testarea de acceptare ct i de testare spre eec.

Ideea de acoperire cu teste (test coverage)

Test coverage este o idee foarte important pentru c furnizeaz o verificare a
proporiilor i calitii testului. Cu alte cuvinte este un rspuns la ntrebarea cte teste ai
realizat? ntr-un mod care nu las loc pentru interpretri. Afirmaiile ca Finisez n
curnd , Am testat 2 sptmni, Am fcut tot ce se poate genereaz mai multe
ntrebri dect rspunsuri. Nu sunt dect afirmaii despre ct s-a testat i despre ct efort sa depus i nu se refer la efectivitatea testului sau ce s-a realizat. Trebuie s cunoatem
despre acoperirea cu testule din dou motive importante:

Furnizeaz o evaluare cantitativ a calitii testrii realizat de msurrile

obinute.

Furnizeaz o estimare de ct testare e nevoie. Utiliznd metricile cantitative

putem stabili obiective pentru proporiile testului i proporiile progresului conform lor.
Afirmaia Am testat 75% din decizii sau 80% din cerine asigur o adevrat
informare. Ele nu sunt nici obiective, nici subiective, ci furnizeaz o real estimare a
volumului testat. Dac apelm la msurarea proporiilor pentru testarea bazat pe
prioriti, care se bazeaz ele nsi pe risc, caracteristic testelor individuale, vom avea un
cadru sigur i obiectiv.
Proporiile testului pot fi aplicate oricrei tehnici sistematice. n acest capitol vom
apela la tehnicile bazate pe specificaii (specification based techniques) pentru a estima
cte funcionaliti au fost testate i la tehnicile structurale pentru a vedea ct s-a testat din
43

cod. Evaluarea acoperirii cu teste poate fi parte a criteriului de completare, definit n

planul de testare i utilizat pentru momentul ncetrii testului .

Categoriile tehnicilor de proiectare a testului

Exis multe modaliti de a proiecta cazurile de test. Unele sunt generale, altele
specifice. Unele se implementeaz foarte simplu, altele sunt complexe i greu de
implementat. Multe cri publicate referitoare la tehnicile de testare a software
demonstreaz rata de dezvoltare a noilor i interesantelor abordri, ale schimbrilor cu
care se confrunt testerii profesioniti.
Exist totui un numr de tehnici de proiectare a cazurilor de test recunoscute ca
importante pentru un tester (s le cunoasc i s le pot aplica), i acestea au fost selectate
ca reprezentative pentru Certificatul Fundaiei i inclusiv i pentru aceast carte. Tehnicile
de proiectare a cazurilor de test se grupeaz n 3 categorii:
Acele care deriv cazurile de test direct din specificaie sau dintr-un model al
sistemului sau chiar din sistemul propus, cunoscut ca tehnici specification - based ori black
- box.
Acele care deriv cazurile de test direct din codul scris pentru implementarea
sistemului, cunoscute ca structure - based, sau tehicile white - box .
Acele care deriv cazurile de test din experiena testerilor legate de acest tip de
sistem i experiena general, cunoscut ca tehnicile experience - based.
E convenabil aceast categorisire a tehnicilor de proiectare a testelor cazuri (se
memoreaz mai uor). Aadar aceasta nu este unica clasificare i nu cuprinde toate
tehnicile. Exist mult mai multe.
Categoria specification-based, cunoscut anterior ca black-box, deoarece tehnicile
cerceteaz sistemul care nu necesit informaii despre ce se ntmpl n interior. Acei
nscui n prima jumtate a sec.20 vor recunoate termenul black-box ca nume pentru tot
ce-i tehnic i poate fi utilizat, dar despre care nu tii nimic sau aproape nimic. Numele a
fost schimbat relativ recent pentru a furniza mai mult informaie. Termenul opus acestuia
este white-box. nseamn a nu fi negru, dar unele persoane susin c trebuie s poi
vedea n interiorul cutiei (a vedea structura) i cutia alb va fi att de opac ca cutia
neagr - de aici numele de glass box (cutiea transparent).
Testarea bazat pe experien (experience-based) nu era tratat ca o testare real,
de aceea a primit un nume ca ad hoc. Sugestia c aceasta nu este o abordare sistematic
l-a exclus din multe discuii despre testare. Climatul intelectual i rafinamentul tehnicilor
experience-based vine din acele timpuri. Este adnc ntiprit n minte c multe sisteme
sunt nc testate pe aceast cale ,n parte deoarece sistemele nu sunt specificate cu
suficiente detalii sau printr-o modalitate suficient structurat care ar permite aplicarea altor
tehnici. Sau deoarece nici echipa de dezvoltare, nici cea experimentatoare nu a fost
antrenat pentru utilizarea tehnicilor specification-based sau structure based.
naintea unei analize ample a acestor categorii, s meditm asupra a ceea ce vrem
s obinem. Vrem s verificm dac sistemul ndeplinete tot ce indic specificaiile i
nimic altceva. n practic nimic altceva este partea cea mai dificil i genereaz cele mai
multe teste. Deoarece exist mai multe modaliti de a grei ceva dect a ndeplini corect.
Chiar dac ne concentrm asupra testrii a ce poate s ndeplineasc sistemul din cele
presupuse, vom genera un numr semnificativ de alte teste. Aceasta va fi costisitor i va
solicita mult timp, ceea ce poate semnifica c probabil nu se va realiza, iar noi trebuie s
44

ne asigurm c testarea va fi pe ct e posibil valoroas. Dup cum am observat, cele mai

bune tehnici realizeaz aceasta prin crearea unor seturi mici de teste care vor atinge
obiectivele propuse. i ele genereaz prin avantajul lor noi cunotine despre testare. De
ex. c defectele tind s se adune ntr-o modalitate interesant.

Tehnicile Black - Box

Principalul lucru despre tehnicile bazate pe specificaii este c deriv testele cazuri
direct din specificaii sau din alte tipuri de modele care trebuie s le ndeplineasc
sistemul. Dac baza testului e definit i adecvat structurat, putem uor identifica
condiiile testului din care poate fi derivat cazul de test. Un moment semnificativ despre
aceste tehnici e c specificaiile i modelele nu definesc cum trebuie sistemul s obin
comportamentul specificat la construire; este o specificaie a comportamentului solicitat
(sau cel puin dorit).
Una dintre complicatele lecii pe care le-au nvat inginerii software din experiene
rezid n necesitatea separrii definiiei care indic ce trebuie s fac sistemul de definirea
cum ar trebui s lucreze. Aceast delimitare permite acelor dou echipe de specialiti s
lucreze independent (testerii specificaiilor i designerii de proiect) ca mai apoi noi s
verificm dac au ajuns la un numitor comun, ex. ei trebuie s construiasc mpreun un
sistem i s-l testeze dac funcioneaz conform specificaiilor.
Dac iniiem cazuri de test pentru a verifica dac comportamentul dorit se manifest
actualmente atunci noi acionm independent de dezvolttori. Dac ei au neles greit
specificaiile sau le-au modificat fr a se consulta cu cineva, atunci implementarea lor va
provoca un comportament diferit de cele indicate de specificaii sau model. Testul nostru
bazat doar pe specificaii va eua i noi vom avea o problem nerezolvat.
Nu toate sistemele sunt definite de specificaii oficiale, detaliate. n unele cazuri,
modelul utilizat poate fi neoficial. Dac nu exist specificaii, testerul trebuie s
construiasc un model al sistemul propus, poate intervievnd principalii clieni pentru a
afla de ce au nevoie. Oficial sau neoficial modelul, oricum este construit i furnizeaz baza
testului din care putem genera sistematic teste.
Trebuie de reinut c specificaiile pot conine elemente funcionale ct i nonfuncionale. Acestea au nevoie la fel de o testare sistematic.
Ceea de ce avem nevoie mai trziu sunt tehnicile care exploreaz sistematic i
complet comportamentul specific pe att de eficient pe ct l putem face. Cu att mai
mult, noi utilizm ceea ce cunoatem despre software pentru a dirija problemele. Orice
tehnic de proiectare a cazurilor de test se bazeaz pe unele principii simple care rezult
din ceea ce cunoatem n general despre comportamentul softului.
Definiie
Testarea cutiei negre este o strategie n care testarea este bazat numai pe cerine i
specificaii. Spre deosebire de complementara sa, testarea cutiei albe, testarea cutiei negre
nu necesit cunoaterea cilor i structurii interne, nici a implementrii produsului soft
testat.
Procesul testrii cutiei negre const n:

Analiza cerinelor i specificaiilor

Alegerea datelor valide de intrare bazat pe specificaie spre a determina dac

produsul soft testat le prelucreaz corect. Sunt alese i date de intrare incorecte pentru a
verifica dac produsul soft testat le detecteaz i prelucreaz corespunztor.
45

Determinarea datelor de ieire

Construirea de teste cu ajutorul datelor de intrare selectate
Rularea testelor
Compararea rezultatelor reale cu rezultatele ateptate
Concluzionarea asupra funcionrii corecte a produsului soft testat

Aplicabilitate
Metoda cutiei negre poate fi aplicat la toate nivelele de dezvoltare a softului
dezvoltare de uniti, de integrare, de sistem i de acceptare.

Trecnd de la modul spre subsistem i apoi spre sistem, cutia devine mai mare, cu
intrri i ieiri tot mai complexe, dar abordarea rmne aceeai. De asemenea, odat cu
creterea cantitii, suntem forai spre abordarea cutiei negre, deoarece sunt prea multe ci
n cadrul produsului soft de testat pentru a efectua testarea cutiei albe.
Dezavantaje
Utiliznd metoda cutiei negre, tester-ul niciodat nu poate fi sigur a cta parte din
produsul soft a fost testat. n pofida iscusinei i silinei tester-ului, unele ci de execuie
pot rmne neexercitate. Spre exemplu, care este probabilitatea ca tester-ul s aleag un
caz de test care s descopere aceast trstur?
if (name=="Lee" && employeeNumber=="1234" &&
employmentStatus=="RecentlyTerminatedForCause") {
send Lee a check for $1,000,000;
}
Pentru a gsi fiece defect folosind metoda cutiei negre, tester-ul ar trebui s creeze
toate combinaiile posibile de date de intrare, att corecte, ct i incorecte. Acest tip
complet de testare a intrrilor este aproape ntotdeauna imposibil. Se poate alege doar o
submulime (deseori o submulime foarte mic) de combinaii ale datelor de intrare.
n cartea sa Arta testrii produselor soft (The Art of Software Testing), Glenford
Myers ofer un excelent exemplu de zdrnicie a testrii complete: Cum ai testa temeinic
un compilator? Prin scrierea fiecrui program corect sau incorect posibil.
Problema este substanial mai serioas n cazul sistemelor care trebuie s memoreze
evenimente anterioare. (de ex. care memoreaz starea lor). n cazul acestor sisteme, nu
doar fiece intrare posibil trebuie testat, ci i fiecare secven posibil de intrri posibile.
Chiar dac nu putem testa totul, metoda formal a cutiei negre direcioneaz testerul s aleag submulimi de teste care sunt att eficiente, ct i efective n gsirea
defectelor.
46

Avantaje
Chiar dac nu putem testa totul, metoda formal a cutiei negre direcioneaz testerul s aleag submulimi de teste care sunt att eficiente, ct i efective n gsirea
defectelor. Astfel, aceste submulimi vor gsi mai multe defecte dect un numr echivalent
de teste create la ntmplare. Metoda cutiei negre ajut la maximizarea restituirii investiiei
testrii.

Testarea claselor de echivalen

Testarea claselor de echivalen este o metod folosit spre a reduce numrul
cazurilor de teste la un nivel manevrabil pstrnd n acelai timp acoperirea rezonabil cu
teste. Aceast metod simpl este folosit intuitiv de ctre majoritatea testerilor, cu toate c
ei ar putea s nu o cunoasc ca pe o metod formal de proiectare a testelor. Muli testeri
au dedus logic utilitatea ei, n timp ce alii au descoperit-o pur i simplu din lips de timp
pentru a testa mai aprofundat.
S considerm aceast situaie. Scriem un modul pentru un sistem de resurse umane
care decide cum trebuie prelucrate aplicaiile pentru angajare bazndu-se pe vrsta
persoanelor. Regulile organizaiei noastre sunt:
0 - 16
16 - 18
18 - 55
55 - 99

Nu pot fi angajai
Pot fi angajai doar cu jumtate de norm
Pot fi angajai cu termen complet de munc
Nu pot fi angajai *

* Not: Dac ai identificat vreo problem legat de aceste cerine, nu-i f griji. Ele
sunt scrise n acest mod cu un anumit scop i vor fi corectate n capitolul urmtor.
Ar trebui s testm modulul pentru urmtoarele vrste: 0, 1, 2, 3, 4, 5, 6, 7, 8, ..., 90,
91, 92, 93, 94, 95, 96, 97, 98, 99? Dac am avea foarte mult timp (i nu ne-ar deranja
ameitoarea repetiie i am fi pltii pe or), desigur, am putea. Dac programatorul ar fi
implementat acest modul cu urmtorul cod, ar trebui s testm fiece vrst. (Dac nu ai o
pregtire n domeniul programrii, nu-i f griji. Aceste exemple sunt simple. Doar citete
codul i vei nelege.)
If (applicantAge == 0) hireStatus="NO";
If (applicantAge == 1) hireStatus="NO";

If (applicantAge == 14) hireStatus="NO";

If (applicantAge == 15) hireStatus="NO";
If (applicantAge == 16) hireStatus="PART";
If (applicantAge == 17) hireStatus="PART";
If (applicantAge == 18) hireStatus="FULL";
If (applicantAge == 19) hireStatus="FULL";

If (applicantAge == 53) hireStatus="FULL";

If (applicantAge == 54) hireStatus="FULL";
If (applicantAge == 55) hireStatus="NO";
47

If (applicantAge == 56) hireStatus="NO";

If (applicantAge == 98) hireStatus="NO";

If (applicantAge == 99) hireStatus="NO";
Dat fiind aceast implementare, faptul c orice mulime de situaii de teste nu ne
spune nimic despre urmtorul test pe care am putea s-l executm. El ar putea reui sau
eua.
Din fericire, programatorii nu scriu codul n acest mod (cel puin nu prea des). Un
programator mai bun ar putea scrie:
If (applicantAge >= 0 && applicantAge <=16)
hireStatus="NO";
If (applicantAge >= 16 && applicantAge <=18)
hireStatus="PART";
If (applicantAge >= 18 && applicantAge <=55)
hireStatus="FULL";
If (applicantAge >= 55 && applicantAge <=99)
hireStatus="NO";
Dat fiind aceast implementare tipic, este clar c pentru prima cerin nu trebuie
s testm 0, 1, 2, ..., 14, 15, i 16. Doar o valoare trebuie testat. Dar care valoare? Orice
valoare din acest interval este potrivit. Acelai lucru este adevrat pentru fiecare din
celelalte intervale. Intervale ca cele descrise aici sunt numite clase de echivalen. O clas
de echivalen const dintr-o mulime de date ce sunt tratate identic de ctre modul sau
care trebuie s produc acelai rezultat. Orice valoare a datelor n cadrul unei clase este
echivalent, conform termenilor ai testrii, cu orice alt valoare. Specific, am atepta
urmtoarele:

Dac un caz de test ntr-o clas de echivalen detecteaz un defect, toate

celelalte teste n aceeai clas de echivalen vor detecta probabil acelai defect.

Dac un caz de test ntr-o clas de echivalen nu detecteaz un defect, nu

exist probabiliatea ca vreunul din celelalte teste n aceeai clas de echivalen s
detecteze acest defect.
Un grup de teste formeaz o clas de echivalen dac se crede c:

Ele toate testeaz acelai lucru.

Dac un test capteaz un neajuns, celelalte probabil vor face la fel.

Dac un test nu capteaz un neajuns, probabil nici celelalte nu-l vor capta.
Aceast abordare presupune desigur existena unei specificri care definete
variatele clase de echivalen pentru testare. De asemenea, ea presupune c programatorul
nu a fcut nimic ciudat, de tipul:
If (applicantAge >= 0 && applicantAge <=16)
hireStatus="NO";
If (applicantAge >= 16 && applicantAge <=18)
hireStatus="PART";
48

If (applicantAge >= 18 && applicantAge <=41)

hireStatus="FULL";
// strange statements follow
If (applicantAge == 42 && applicantName == "Lee")
hireStatus="HIRE NOW AT HUGE SALARY";
If (applicantAge == 42 && applicantName <> "Lee")
hireStatus="FULL";
// end of strange statements
If (applicantAge >= 43 && applicantAge <=55)
hireStatus="FULL";
If (applicantAge >= 55 && applicantAge <=99)
hireStatus="NO";
Folosind abordarea claselor de echivalen, am redus numrul cazurilor de teste de
la 100 (testarea fiecrei vrste) la 4 (testarea unei vrste din fiece clas de echivalen) o
economisire semnificativ.
Acum, suntem gata s ncepem testarea? Probabil nu. Cum rmne cu valorile de
intrare ca 969, +42, FRED si &$#!@? Ar trebui s crem cazuri de teste pentru intrrile
incorecte? Rspunsul dat de orice bun consultant ar fi depinde. Spre a nelege acest
rspuns trebuie s examinm o abordare ce s-a nscut n lumea orientat pe obiecte numit
proiectare dup contract.
Din punct de vedere juridic, un contract este o nelegere legal obligatoare ntre
dou (sau mai multe) pri care descrie care sunt angajamentele de aciune a fiecrei pri.
Fiecare din aceste angajamente reprezint beneficii pentru ceilali.
n abordarea proiectrii dup contract, modulele (numite metode n paradigma
orientat pe obiecte, dar module este un termen mai general) sunt definite ca precondiii
sau postcondiii. Post-condiiile definesc ce promite modulul s fac (s calculeze o
valoare, s deschid un fiier, s imprime un raport, s nnoiasc o nregistrare n baza de
date, s schimbe starea sistemului, etc.). Pre-condiiile definesc ce necesit modulul pentru
a putea ndeplini post-condiiile. De exemplu, dac am avea un modul numit openFile, ce
promite el s fac? S deschid un fiier. Care ar fi precondiiile ndreptite ale lui
openFile? n primul rnd, fiierul trebuie s existe; n al doilea rnd, trebuie s specificm
un nume (sau alte informaii identificatoare) al fiierului; n al treilea rnd, fiierul trebuie
s fie posibil de deschis, adic nu poate fi exclusiv deschis de un alt proces; n al patrulea
rnd, trebuie s avem drepturi de acces la fiier; .a.m.d. Pre-condiiile i postcondiiile
stabilesc un contract ntre un modul i altele care l solicit.
Testarea dup contract este bazat pe filosofia proiectrii dup contract.
Abordarea sa const n crearea cazurilor de teste doar pentru situaii n care pre-condiiile
sunt ndeplinite. De exemplu, nu am testa modulul openFile n cazul n care fiierul nu
exist. Motivul este simplu. Dac fiierul nu exist, openFile nu promite s funcioneze.
Dac nu exist vreo afirmaie c el va funciona n anumite condiii, nu e nevoie de testare
n aceste condiii.
n acest punct testerii de obicei protesteaz. Da, ei sunt de acord, modulul nu afirm
c va funciona n acest caz, dar dac precondiiile sunt violate n decursul producerii? Ce
face sistemul? Obinem un cuvnt scris greit pe ecran sau un crater de fum n locul n care
obinuia s se afle compania noastr?
49

O alt abordare de proiectare este proiectarea defensiv. n acest caz modulul este
proiectat s accepte orice intrare de date. Dac precondiiile corespunztoare sunt
ndeplinite, modulul va realiza postcondiiile sale corespunztoare. Dac precondiiile
corespunztoare nu sunt ndeplinite, modulul va anuna apelantul prin returnarea unui cod
de eroare sau prin lansarea unei excepii (n dependen de limbajul de programare
utilizat). Aceast notificare este, de fapt, o alt postcondiie a modulului. Conform acestei
abordri, am putea defini testarea defensiv: o abordare ce testeaz att n cazul precondiiilor obinuite, ct i a celor neobinuite.
Cum influeneaz acest lucru clasa de echivalen? Trebuie s testm folosind intrri
ca -42, FRED i &$#!@? n cazul n care folosim proiectarea dup contract i testarea
dup contract, rspunsul este Nu. Dac folosim proiectarea defensiv i respectiv testarea
defensiv, rspunsul este Da. ntrebai proiectanii ce abordare folosesc. Dac ei rspund
contract sau defensiv, deja vei ti ce fel de testare s foloseti. Dac rspund
Poftim?! aceasta nseamn c ei nu se gndesc la felul n care modulele interacioneaz
ntre ele. Ei nu se gndesc la contractele cu pre-condiii i post-condiii. Testarea de
integrare se ateapt s fie sursa primar de defecte i va fi mult mai complex i va
consuma mai mult timp dect cel preconizat.
Paii de folosire a testrii claselor de echivalen este simpl. Mai nti, clasele de
echivalen sunt identificate. Apoi, un caz de test este creat pentru fiece clas de
echivalen. n cazul dispunerii de timp i bani, pot fi create cazuri de teste adiionale
pentru fiecare clas de echivalen. Cazurile de teste adiionale pot crea impresia de mai
mare siguran, dar ele rareori gsesc defecte pe care primul test nu le-a gsit.
Diferite date de intrare necesit diferite tipuri de clase de echivalen. S
considerm patru posibiliti. S presupunem o filosofie de testare defensiv pentru
testarea intrrilor att corecte, ct i incorecte. Testarea datelor de intrare incorecte este
deseori o enorm surs de defecte.
Dac o introducere de date reprezint un interval continuu de valori, atunci exist de
obicei o clas de valori corecte i dou clase de valori incorecte, una inferioar clasei
valide, alta superioar. S considerm exemplul Companiei Goofy Mortgage (GMC). Ei
vor scrie ipoteci pentru persoanele cu venit ntre $1000/lun i $83 333/lun. Orice sum
sub $1000/lun nu se calific. Orice sum peste $83 333/lun nu are nevoie de GMC,
poate plti prin bani lichizi.
Pentru o intrare valid puntem alege suma de $1 342/lun. Pentru intrri incorecte
putem alege sumele de $123/lun i $90 000/lun.

Clase continue de echivalen

50

Dac o condiie de intrare ia valori discrete ntr-un interval de valori posibile, exist
n mod normal o clas corect i dou incorecte. GMC ar scrie o singur ipotec pentru
una din 5 case. (E doar vorba de Goofy!). Zero sau cteva case nu reprezint o intrare
justificat, la fel ca i ase sau mai multe case. Nici valorile fracionale sau decimale aa ca
2 sau 3,14159 nu sunt valide.

Clase discrete de echivalen

Pentru a avea o intrare valid, am putea alege dou case. Incorecte ar putea fi
intrrile -2 i 8.
GMC va crea ipoteci doar pentru o persoan. Ei nu vor crea ipoteci pentru
corporaii, trusturi, parteneriate, sau alte tipuri de entiti legale.

Clase de echivalen cu selecie simpl

Drept intrare corect putem s folosim persoan. Drept intrare incorect putem s
alegem corporaie sau trust sau orice alt ir de caractere text. Cte cazuri incorecte
trebuie s crem? Ar trebui s avem cel puin unul; am putea alege teste adiionale pentru o
adiional impresie de siguran.
GMC va crea ipoteci pentru codomenii, apartamente sau locuine pentru o singur
familie. Ei nu vor crea ipoteci pentru duplexe, case mobile, case de lemn sau alte tipuri de
locuine.

51

Clase de echivalen cu selectare multipl

Drept intrare corect putem alege codomeniu, apartament sau cas de
familie. nct regula dicteaz alegerea unui caz de test din clasa de echivalen corect, o
abordare mai pe neles ar fi s crearea cazurilor de teste pentru fiece intrare in clasa
corect. Aceasta are sens atunci cnd lista de valori corecte este mic. Dar dac aceasta ar
fi lista celor 50 de state, a Districtului Columbia i a celorlalte teritorii ale SUA, fiecare
din ele ar trebui testate? Dar dac n list ar fi fiece ar a lumii? Rspunsul corect depinde,
desigur, de riscul organizaiei, dac, ca tester, omitem ceva vital.
Acum, rareori vom avea timp s crem teste individuale pentru fiece clas de
echivalen a fiecrei valori de intrare a sistemului nostru n parte. De mai multe ori, vom
crea cazuri de teste care testeaz simultan un numr de cmpuri de intrare. De exemplu,
am putea crea un singur caz de test cu urmtoarea combinaie de intrri:

Venit anual
$5 000

Tabelul 1: Un caz de test cu valori de date valide.

Numr de locuine
Aplicant
Tipurile locuinelor
2
Persoan
Codomeniu

Rezultat
Corect

Fiecare din aceste valori de date se afl n limita corect, deci ar fi de ateptat ca
sistemul s funcioneze corect i cazul de test s raporteze Trecut cu succes.
Folosirea unei abordri similare pentru valorile incorecte este tentant.
Tabelul 2: Un caz de test cu valori de date incorecte. Aceasta nu este o abordare
potrivit.
Venit lunar
Numr de locuine
Aplicant
Tipurile locuinelor
Rezultat
$100
8
Parteneriat
Cas de lemn
Incorect
Dac sistemul accept aceast intrare drept valid, evident c sistemul nu valideaz
cele patru cmpuri de intrare corespunztor. Dac sistemul respinge aceast intrare drept
incorect, aceasta se poate ntmpla ntr-un mod n care tester-ul s nu poat determina
care cmp este respins. De exemplu:
EROARE: 653X-2.7 INTRARE INCORECT
n multe cazuri, erorile unui cmp de intrare pot anula sau masca erori n alt cmp
astfel ca sistemul s-l accepte drept corect. O abordare mai bun este cea n care valorile
incorecte sunt testate pe rnd spre a verifica dac sistemul le detecteaz corect.
Tabelul 3: O mulime de cazuri de teste schimbnd valori incorecte pe rnd.
Venit lunar Numr de locuine
Aplicant
Tipurile locuinelor
Rezultat
$100
1
Persoan
Cas de familie
Incorect
$1 342
0
Persoan
Codomeniu
Incorect
$1 342
1
Corporaie
Apartament
Incorect
$1 342
1
Persoan
Cas de lemn
Incorect
52

Pentru o impresie adiional de siguran, intrrile (att corecte, ct i incorecte) pot

fi diversificate.
Tabelul 4: O mulime de cazuri de teste schimbnd valori incorecte pe rnd schimb
i valorile corecte.
Venit lunar Numr de locuine
Aplicant
Tipurile locuinelor
Rezultat
$100
1
Persoan
Cas de familie
Incorect
$1 342
0
Persoan
Codomeniu
Incorect
$5 432
3
Corporaie
Apartament
Incorect
$10 000
2
Persoan
Cas de lemn
Incorect
O alt abordare de folosire a claselor de echivalen este de a examina ieirile, nu
intrrile. Divizai ieirile n clase de echivalen, apoi determinai ce fel de intrri ar cauza
aceste ieiri. Acest procedeu are avantajul de a ghida tester-ul spre a examina, i deci testa,
fiece tip diferit de ieire. Dar aceast abordare poate fi decepionant. n exemplul anterior,
pentru sistemul de resurse umane, una din ieirile sistemului a fost NU, adic Nu Angaja.
O privire grbit asupra intrrilor ce ar cauza aceast ieire ar include {0, 1, ... , 14, 15}.
Noteaz c aceasta nu este mulimea complet. Adiional, {55, 56, , 98, 99} ar trebui de
asemenea s cauzeze ieirea NU. Este important s se asigure c toate ieirile poteniale
pot fi generate, dar nu v lsai ademenii n a alege date ale claselor de echivalen ce
omit intrri importante.
Aplicabilitate i Limitaii
Testarea claselor de echivalen poate reduce semnificativ numrul cazurilor de test
ce trebuie create i executate. Este mai potrivit pentru sisteme n care majoritatea datelor
de intrare iau valori cuprinse n anumite limite sau mulimi. Ea face presupunerea c datele
din aceeai clas de echivalen sunt, de fapt, procesate la fel de ctre sistem. Cea mai
simpl modalitate de a valida aceast presupunere este de a ntreba programatorii despre
implementrile lor.
Testarea claselor de echivalen este egal aplicabil pentru nivele de testare de
uniti, integrare, sistem sau acceptare. Tot ce necesit sunt intrri i ieiri ce pot fi
mprite n conformitate cu cerinele sistemului.

Testarea limitei valorilor

Clasa de echivalen de testare este cea mai principala tehnic de test design. Ea
ajut testerilor s aleag un subset din posibile cazuri de test meninnd totodat
acoperirea logic. Testarea clasei de echivalen are si alt avantaj. Ea ne conduce la
testarea valorilor de la limite, a doua tehnic de test design prezentat.
In capitolul precedent urmtoarele reguli erau date ca s indice cum trebuie de
procesat aplicaiile de angajare bazate pe vrsta unei persoane. Regulile erau:
016
1618
1855
5599

Nu se angajeaz
Se angajeaz numai pe baza part-time
Se angajeaz pe baza full-time
Nu se angajeaz
53

Observai problema limitelor fiecrei clase. Vrsta "16" este inclus n dou clase
de echivalen diferite (la fel 18 i 55). Prima regul spune c nu se angajeaz persoane de
16 ani. A doua regul spune c persoane de 16 ani pot fi angajate pe baza part-time.
Testarea valorilor de la limite se focuseaz pe limite pentru c acolo sunt foarte
multe defecte ascunse. Testerii experimentai observa problema aceast foarte des. Testerii
neexperimentai pot avea o intuiie c greelile pot aprea cel mai des la limite. Defectele
acestea pot fi n cerine (precum e prezentat mai sus) sau n codul ce urmeaz:
If (VirstaAplicant >= 0 && VirstaAplicant <=16)
angajareStatut="NU";
If (VirstaAplicant >= 16 && VirstaAplicant <=18)
angajareStatut="PART";
If (VirstaAplicant >= 18 && VirstaAplicant <=55)
angajareStatut="FULL";
If (VirstaAplicant >= 55 && VirstaAplicant <=99)
angajareStatut="NU";
Desigur, greeala pe care o comit programatorii este codarea condiiei de inegalitate
nepotrivit. Scrierea > (mai mare ca) n locul (mai mare ca sau egal) este un exemplu.
Cea mai eficient modalitate de a gsi aceste defecte, sau n cerine sau n cod, este
prin verificare. Probabil asta e ceea ce a avut n vedere organizaia de angajare:
015
1617
1854
5599

Nu se angajeaz
Se angajeaz numai pe baza part-time
Se angajeaz pe baza full-time
Nu se angajeaz

Dar vrsta -3 i 101? Observai c cerinele nu specific cum aceste valori trebuie
tratate. Noi am putea ghici dar "ghicirea cerinelor" nu este o practic acceptabil.
Codul ce implementeaz regulile corecte este:
If (VirstaAplicant >= 0 && VirstaAplicant <=15)
angajareStatut="NU";
If (VirstaAplicant >= 16 && VirstaAplicant <=17)
angajareStatut="PART";
If (VirstaAplicant >= 18 && VirstaAplicant <=54)
angajareStatut="FULL";
If (VirstaAplicant >= 55 && VirstaAplicant <=99)
angajareStatut="NU";
Valorile interesante pe i lng limite n acest exemplu sunt {-1, 0, 1}, {15, 16, 17},
{17, 18, 19}, {54, 55, 56}, i {98, 99, 100}. Alte valori, ca {-42, 1001, FRED, %$#@} pot
fi incluse n dependen de precondiiile documentate ale modulului.

Tehnic
54

Paii pentru utilizarea testrii valorilor de la limite sunt simpli. n primul rnd, se
identific clasele de echivalen. n al doilea rnd, se identific limitele fiecrei clase de
echivalen. n al treilea rnd, se creeaz cazurile de test pentru fiece valoare alegnd un
punct pe limit, un punct apropiat mai jos de limit, i un punct apropiat mai sus de limit.
"Mai jos" i "mai sus" sunt termeni relativi i depind de valoarea unitilor de date. Dac
limita este 16 i unitatea este "integer" atunci punctul "de jos" este 15 i punctul "de sus"
este 17. Dac limita este $5.00 i unitatea este "dolari i ceni US" atunci punctul de jos
este $4.99 i cel de sus este $5.01. Pe de alt parte, dac valoarea este $5 i unitatea este
"dolari US" atunci punctul de jos este $4 i cel de sus este $6.
Observai c un punct apropiat mai sus de limit poate fi n alt clas de echivalen.
N-are nici-un sens de dublat testul. Analogic poate fi adevrat i punctul apropiat mai jos
de limit.
Desigur, se poate de creat cazurile de test adugtoare mai departe de limitele (n
cadru claselor de echivalen) dac avei resursele. Precum era discutat n capitolul
precedent, aceste cazuri de test adugtoare pot crea situaii de disconfort, dar ele rar
descoper defecte adiionale.
Testarea valorilor de la limite este mult mai adecvat cnd datele de intrare
formeaz un ir continuu de valori. Revenind din nou la Goofy Mortgage Company, care
sunt limitele valorii interesante? Pentru venit lunar limitele sunt $1,000/lun i
$83,333/lun (presupunnd uniti dolarii US).

Limitele valorilor pentru un ir continuu de date de intrare.

Se testeaz datele de intrare {$999, $1,000, $1,001} pe limita de jos i {$83,332,
$83,333, $83,334} pe limita de sus alese pentru testarea limitelor.

Limitele valorilor pentru un interval discret de date de intrare.

Pentru c GMC va forma o ipotec pentru una sau cinci case, 0 sau mai puine case
nu este o intrare corect, la fel 6 i mai mult. Acestea identific limitele pentru testare.
55

Rar vom avea timp pentru crearea testelor individuale pentru fiece valoare de la
limit. Mai des vom crea cazuri de test ce testeaz un numr de cmpuri de intrare
simultan.
Tabelul 5: Un set de cazuri de test ce conin combinaiile valorilor valide (pe limite)
i puncte incorecte (n afara limitei).
Venit lunar Numrul de
Rezultat
Descrierea
locuine
$1,000
1
Valid
min venit, min locuine
$83,333
1
Valid
max venit, min locuine
$1,000
5
Valid
min venit, max locuine
$83,333
5
Valid
max venit, max locuine
$1,000
0
Incorect
min venit, mai puin min locuine
$1,000
6
Incorect
min venit, mai mult max locuine
$83,333
0
Incorect
max venit, mai puin min locuine
$83,333
6
Incorect
max venit, mai mult max locuine
$999
1
Incorect
Mai puin min venit, min locuine
$83,334
1
Incorect
Mai mult max venit, min locuine
$999
5
Incorect
Mai puin min venit, max locuine
$83,334
5
Incorect
Mai mult max venit, max locuine
Fixarea " venitului lunar" pe axa x i "numrul de locuine" pe axa y arat "poziiile"
punctelor datelor de testare.

Punctele datelor pe limitele i punctele datelor n afara limitei.

Observai c 4 dintre combinaii sunt pe limite n timp ce celelalte opt sunt n afara
lor. De asemenea observai c punctele de afar ntotdeauna combin o valoare valid cu
una incorect.
Aplicarea i Limitrile
56

Testarea valorilor de la limite poate reduce semnificativ numrul de cazuri de test ce

trebuie create i executate. Este cel mai potrivit sistemului n care majoritatea datelor de
intrare iau valori n cadrul unor iruri sau seturi.
Testarea valorilor de la limite este la fel aplicabil la testarea unitilor, de integrare,
a sistemului, i la nivelurile testrii de acceptare. Tot ce se cere sunt datele de intrare ce pot
fi mprite i limitele ce pot fi identificate bazate pe cerinele sistemului.

Testarea tabelelor de decizii

Tabelele de decizie sunt instrumentele excelente pentru capturarea anumitor tipuri
de cerine sistemului i pentru documentarea design-ului sistemului intern. Ele sunt
folosite pentru nscrierea regulilor complexe din business ce sunt implementate de sistem.
De asemenea, ele pot servi ca ghid pentru crearea cazurilor de test.
Tabelele de decizie sunt instrumentele vitale n cutia personal de instrumente. Din
pcate, muli analiti , designeri, programatori, i testeri nu sunt obinuii cu aceast
tehnic.
Tehnic
Tabelele de decizie prezint reguli complexe din business bazate pe un set de
condiii. Form general este:
Tabel 6: Forma general a unui tabel de decizie.
Regula 1
Regula 2

Regula p
Condiii
Condiia -1
Condiia -2

Condiia - m
Aciune
Aciune-1
Aciune-2

Aciune - n
Condiiile 1 - m sunt condiii variate de intrare. Aciunile 1 n sunt aciuni ce ar
trebui s fie luate n dependen de diferite combinaii a condiiilor de intrare. Fiece regul
definete o combinaie unic a condiiilor ce rezult n executarea (arderea) aciunilor
asociate cu regula ceea. Observai c aciunile nu depind de ordinea n care condiiile sunt
evaluate, dar numai de valorile lor. (Toate valorile se consider a fi disponibile simultan.)
De asemenea, aciunile nu depind de condiiile specificate, sau de orice condiii de intrare
precedent sau starea sistemului.
Posibil un exemplu concret va clarifica concepiile. O companie de asigurare auto
ofer reduceri pentru oferi cstorii i-sau studeni buni. S ncepem cu reguli. Urmtorul
tabel de decizie are 2 condiii, fiece din ei ia valorile Da sau Nu.
57

Tabel 7: Un tabel de decizie cu dou condiii binare.

Regula 1
Regula 2
Regula 3
Regula 4
Condiii
Cstorit?
Student Bun?

Da
Da

Da
Nu

Nu
Da

Nu
Nu

Observai c tabelul conine toate combinaiile condiiilor. Sunt date 2 condiii

binare (Da sau Nu), combinaiile posibile sunt {Da, Da}, {Da, Nu}, {Nu, Da}, i {Nu,
Nu}. Fiece regul este una dintre aceste combinaii. Ca un tester noi vom verifica dac
toate combinaiile condiiilor sunt definite. Lipsa unei combinaii poate rezulta n
dezvoltarea unui sistem ce nu poate procesa o mulime de valori de intrare corect.
Acum pentru aciuni. Fiece regul cauzeaz o aciune de "ardere". Fiecare regul
poate specifica o aciune unic la regula dat, sau mai multe reguli pot mpri aciuni.
Tabel 8: Adugarea unei singure aciuni la un tabel de decizie.
Regula 1
Regula 2
Regula 3
Regula 4
Condiii
Cstorit?
Student Bun?

Da
Da

Da
Nu

Nu
Da

Nu
Nu

60

25

50

Aciuni
Reducere ($)

Tabelele de decizie pot specifica mai mult de o aciune pentru fiecare regul. Din
nou, aceste reguli pot fi unice sau pot fi mprite.
Tabel 9: Un tabel de decizie cu aciuni multiple.
Regula 1
Regula 2
Regula 3

Regula 4

Condiii
Condiie-1

Da

Da

Nu

Nu

Condiie-2

Da

Nu

Da

Nu

Aciune-1

Execut X

Execut Y

Execut X

Execut Z

Aciune-2

Execut A

Execut B

Execut B

Execut B

Aciuni

n aceast situaie, alegerea cazurilor de test este simpl - fiecare regul (coloana
vertical) devine un caz de test. Condiiile specific date de intrare i aciunile specific
rezultatele ateptate.
58

n timp ce exemplele precedente folosesc simple condiii binare, condiii pot fi mult
mai complexe.
Tabel 10: Un tabel de decizie cu condiii ce nu sunt binare.
Regula 1
Regula 2
Regula 3
Regula 4
Condiii
Condiie-1

01

110

10100

1001000

Condiie-2

<5

6 or 7

>7

Aciune-1

Execut X

Execut Y

Execut X

Execut Z

Aciune-2

Execut A

Execut B

Execut B

Execut B

Aciuni

n aceast situaie alegerea cazului de test este puin mai complex - fiecare regul
(coloana vertical) devine un caz de test unde valorile alese trebuie sa satisfac condiiile.
Alegnd valorile corespunztoare noi trebuie s crem urmtorele cazuri de test:

ID Caz de Test
TC1
TC2
TC3
TC4

Tabel 11: Exemplu de caz de test.

Condiie-1
Condiie-2
Rezultatul Ateptat
0
3
Execut X / Execut A
5
5
Execut Y / Execut B
50
7
Execut X / Execut B
500
10
Execut Z / Execut B

Dac sistemul sub test are reguli complexe de business, i dac analitii sau
designerii nu au documentat aceste reguli n aceast form, ar trebui s acumuleze aceast
informaie i s-o reprezinte n form de tabel de decizie. Motivul este simplu.
Comportamentul sistemului dat este reprezentat n aceast form complet i compact i
cazurile de test pot fi create direct din tabelul de decizie.
n testare, se creeaz cel puin un caz de test pentru fiecare regul. Dac condiiile
regulii sunt binare, un singur test pentru fiecare combinaie este suficient. Pe de alt parte,
dac o condiie este un ir de valori se consider testarea att pe limita de sus ct i pe cea
de jos. n acest caz noi unim ideea Testrii Valorii de la Limite cu Testarea Tabelelor de
Decizii.
Se creeaz cel puin un caz de test pentru fiecare regula.
Pentru a crea un tabel de cazuri de test simplu se schimb titlurile rndului i
coloanei:
Tabel 12: Un tabel de decizie convertit la un tabel de caz de test.
Caz de Test1 Caz de Test2 Caz de Test3 Caz de Test4
Valori de intrare
59

Tabel 12: Un tabel de decizie convertit la un tabel de caz de test.

Caz de Test1 Caz de Test2 Caz de Test3 Caz de Test4
Condiie-1
Da
Da
Nu
Nu
Condiie-2
Da
Nu
Da
Nu
Rezultate Ateptate
Aciune-1
Aciune-2

Execut X
Execut A

Execut Y
Execut B

Execut X
Execut B

Execut Z
Execut B

Aplicarea i Limitrile
Testarea tabelelor de decizii poate fi folosit oricnd sistemul cere implementarea
regulilor complexe din business, cnd aceste Reguli pot fi reprezentate ca o combinaie de
condiii i cnd aceste condiii au aciuni discrete asociate cu ele.

State transition testing (testarea strilor i tranziiilor)

Tehnica tabelelor de decizie este util pentru sistemele unde combinaiile condiiilor
incluse produc diferite aciuni. Acum vom considera o tehnic similar, dar ne referim la
sistemele a cror rezultate sunt activate de schimbrile condiiilor de intrare sau
schimbarea strii; cu alte cuvinte, comportamentul depinde de starea curent i de cea
precedent, fiind o tranziie ce impulsioneaz comportamentul sistemului. Aceast tehnic
este cunoscut ca testarea strilor i tranziiilor iar diagram utilizat n aceast tehnic se
numete (diagrama state transition)state transition diagram .

Diagrama State - Transition

Diagrama tranziiei strii reprezent comportamentului sistemului. Ea include 2
simboluri. Primul este un

cerc care semnific starea, condiia. Starea este doar ceea ce se spune c este:
sistemul este static, ntr-o condiie stabil care se va schimba datorit unor evenimente
de diferit natur. De ex. televizorul este inclus pn nu-l deconectai. Un ceas
multifuncional v va arta ora dac nu schimbai regimul.
Al doilea simbol reprezint tranziia, ex. schimbarea dintr-o stare n alta.

Schimbarea strii va fi influenat de unele evenimente (apsarea unui buton sau

deconectarea luminii). Schimbarea va fi marcat de evenimentul care a cauzat-o i de
orice aciune rezultant. Deci putem avea regimul button pressed ca eveniment i
presentation changes ( prezentarea schimbrilor) ca aciune. De obicei ( dar nu e
60

obligatoriu ) starea iniial va avea dou sgei incidente n ea. Deseori starea iniial e
evident i nu se reprezint grafic.
Dac avem diagrama tranziiei strlor unui sistem, putem analiza comportamentul
lui pentru a vedea ce se ntmpl la tranziia de la o stare la alta.
Tranziia este cauzat de un eveniment i poate genera rezultate i/ sau schimbri ale
strii. Un eveniment e ceva care provoac schimbarea. Acesta poate fi o resurs (input)
pentru sistem , sau ceva din interiorul sistemului care se schimb, ca un cmp din baza de
date mbuntit (being updated).
n unele cazuri un eveniment genereaz un rezultat, n altele evenimentul schimb
starea interioar a sistemului fr a genera un rezultat, iar uneori un eveniment poate cauza
un rezultat i o schimbare a strii. Ce se ntmpl la fiecare schimbare se poate deduce
mereu din diagrama tranziiei strii.
Exemplu. Un sistem pentru rezervarea biletelor de avion.

61

O diagram de tranziie de stri ar trebui s prezinte urmtoarele aspecte:

- Fiecare stare unic n care se poate afla soft-ul. O regul bun aici ar fi c dac nu
suntei siguri dac o careva stare este separat, atunci ea probabil chiar este separat.
Oricnd apoi o putei cumula cu o oricare alta, dac vei descoperi c totui nu este.
- Tranziia sau condiia prin care se trece la urmtoarea stare. Aceasta poate fi
apsarea unei taste, o selectare de meniu, o intrare prin senzor, un sunet de telefon, etc. O
stare poate fi prsit fr vreo anumit cauz. Cauza anumit i este ceea ce cutai Dvs.
aici.
- Condiiile setate i ieirea produs atunci cnd ntr-o stare se intr sau ea se
prsete. Aceasta ar include un meniu sau butoane afiate, o setare de flag, o imprimare,
producerea unui calcul, etc. Este un eveniment sau/i o aciune ce are loc la o tranziie
dintr-o stare n urmtoarea.

Tabelul State - Transition

Dect s analizm de fiecare dat ce se ntmpl pentru fiecare eveniment, vom
iniia un test adoptnd o aciune intermediar de creare a ceea ce este cunoscut ca State
table (tabelul strii) TS. Un TS nregistreaz toate evenimentele posibile i toate strile
posibile prezentnd rezultatele privind starea nou i orice rezultat generat de fiecare
combinaie a evenimentelor i a strilor.
TS este o surs din care pot fi derivate cazuri de test. E recomandabil aceast
modalitate deoarece analiza tranziiilor de stare solicit timp i poate fi o surs de erori. E
mai bine s ndeplineti aceast sarcin o singur dat i atunci vei avea o simpl
modalitate de generare a testelor dect s o efectuezi de fiecare dat cnd trebuie de
generat un test case nou.
Tabelul 13: State-Table
Starea curent
null
null
null
null
null

Evenimentul
giveInfo
payMoney
print
giveTicket
cancel

Aciunea
startPayTimer
-----

Starea urmtoare
Made
null
null
null
null
62

null

PayTimerExpires

--

Made
Made
Made
Made
Made
Made

giveInfo
payMoney
print
giveTicket
cancel
PayTimerExpires

-------

Paid
Paid
Paid
Paid
Paid
Paid

giveInfo
payMoney
print
giveTicket
cancel
PayTimerExpires

--Ticket
-Refund
--

Paid
Paid
Ticketed
Paid
Can-Cust
Paid

Ticketed
Ticketed
Ticketed
Ticketed
Ticketed
Ticketed

giveInfo
payMoney
print
giveTicket
cancel
PayTimerExpires

----Refund
--

Ticketed
Ticketed
Ticketed
Used
Can-Cust
Ticketed

Used
Used
Used
Used
Used
Used

giveInfo
payMoney
print
giveTicket
cancel
PayTimerExpires

-------

Used
Used
Used
Used
Used
Used

giveInfo
payMoney
print
giveTicket
cancel
PayTimerExpires

-------

giveInfo
payMoney
print
giveTicket
cancel
PayTimerExpires

-------

Can-NonPay
Can-NonPay
Can-NonPay
Can-NonPay
Can-NonPay
Can-NonPay
Can-Cust
Can-Cust
Can-Cust
Can-Cust
Can-Cust
Can-Cust

null
Made
Paid
Made
Made
Can-Cust
Can- NonPay

Can-NonPay
Can-NonPay
Can-NonPay
Can-NonPay
Can-NonPay
Can-NonPay
Can-Cust
Can-Cust
Can-Cust
Can-Cust
Can-Cust
Can-Cust

Reducerea numrului de stri i tranziii

63

Crearea unei diagrame pentru un produs soft mare este o sarcin enorm. Posibil,
vei testa doar o poriune din ntregul produs, astfel nct crearea unei diagrame ar fi o
sarcin rezonabil. Odat finisat diagrama, o vei putea privi dintr-o parte spre a vedea
toate strile i cile spre i din acestea. Dac V-ai ndeplinit munca bine, va fi o imagine
de groaz!
Dac ai fi avut timp infinit, ai fi dorit s testai fiecare cale din soft, nu doar fiecare
linie ce conecteaz dou stri, ci oricare set de linii, nainte i napoi, iar i iar.
Exact cum ai nvat i pentru partiionarea pe clase de echivalen, trebuie s
reducei enorma mulime de posibiliti la o mulime de cazuri de test de mrimi lucrative.
Sunt 5 modaliti de a o face:
Vizitai fiecare stare cel puin o dat. Nu conteaz cum o s ajungei acolo, dar
fiecare stare trebuie testat.
Testai tranziiile din stare n stare care par a fi cele mai comune sau des utilizabile.
Sun subiectiv i este, dar trebuie s se bazeze pe cunotinele acumulate efectund
testarea prin metoda cutiei negre pe baza specificaiilor produsului. Unele scenarii vor fi
mai des folosite de ctre utilizatori dect altele. Vrei ca acelea s funcioneze!
Testai cele mai puin comune ci dintre stri. Este foarte probabil s fi fost scpate
din vedere de ctre designerii i programatorii produsului. Putei fi primul care le va
ncerca.
Testai toate strile de eroare i de ntoarcere din stri de eroare. Deseori, condiiile
de eroare sunt dificil de creat. Frecvent, programatorii scriu coduri pentru a trata erorile
specifice, dar nu pot testa ei nii codul. Sunt frecvente cazurile, cnd erorile nu sunt
tratate adecvat, cnd mesajele de eroare sunt incorecte, sau softul nu se restabilete
adecvat dup depirea erorii.
Testai tranziiile arbitrare ale strilor. Dac avei o diagram imprimat a strilor,
aruncai cu darts n ea i ncercai s v micai de la unele puncte nimerite spre altele.
Dac avei timp s facei ceva mai mult, citii Capitolul 15, Testarea automat i
instrumente de testare, pentru informaii despre automatizarea testrii tranziiilor arbitrare
ale strilor.

Crearea cazurilor de test

Dup identificarea strilor specifice i a tranziiilor de stare pe care dorii s le testai,
putei ncepe definirea cazurilor de test.
Testarea strilor i tranziiilor de stare implic verificarea tuturor variabilelor de
stare, a condiiilor statice, informaiei, valorilor, funcionalitii, etc. care sunt asociate
aflrii n stare sau trecerii din stare n stare.
inei minte c acelai proces de identificare a condiiilor de stare este folosit dac o
stare este ceva vizibil, precum o fereastr sau o caset de dialog, sau dac este invizibil,
aa cum ar fi o component a unui program de comunicaie sau pachet financiar.
Ar fi o idee bun s discutai premisele despre stri i tranziii cu programatorii din
echip i cei ce scriu specificaii. Ei ar putea oferi o privire profund a strilor ce au loc
dup paravan i pe care le-ai putea scpa din vedere.
Variabilele de stare pot fi invizibile, dar foarte importante. Un exemplu comun este
flagul documentului murdar.
64

Atunci cnd un document este ncrcat ntr-un editor, precum un procesor de texte
sau program de desenare, o variabil intern de stare numit flagul documentului murdar
este tears i soft-ul este n starea curat. Soft-ul se va afla n aceast stare att, ct nu
sunt efectuate schimbri n document. Ea poate fi vizionat i parcurs, starea rmnnd
aceeai. De ndat ce este tiprit ceva, sau documentul este modificat n oricare mod, softul i schimb starea n murdar.
Dac o tentativ de nchidere sau ieire din program are loc cnd acesta se afl n
starea curat, ea se va termina normal. Dac documentul este murdar, utilizatorii vor
recepiona un mesaj n care se ntreab dac ar dori s-i salveze lucrarea nainte de
prsire a aplicaiei.
Unele aplicaii sunt att de sofisticate, nct dac se va efectua o schimbare ce
,murdrete documentul, apoi un retur (undo) pentru a-l restabili la condiia original,
soft-ul i va restabili starea de curat i utilizatorul nu va fi ntrebat dac vrea s-i
salveze lucrarea n cazul unei eventuale ieiri din program.
Tot ce a fost discutat pn aici privind testarea strilor a fost ceea ce face parte din
testarea to pass. Dvs. revedei aplicaia, schiai strile, ncercai multe posibiliti valide,
asigurndu-v c strile i tranziiile funcioneaz. Partea opus a acestui lucru este, exact
ca n cazul testrii datelor, gsirea cazurilor de test n care soft-ul va eua. Exemple de
astfel de cazuri sunt condiiile de maraton, repetare, stres i ncrcare.
Condiii de maraton i temporizare rea
Majoritatea sistemelor de operare actuale, fie pentru calculatoare personale sau
echipament specializat, pot efectua multitasking. Prin multitasking se subnelege c
sistemul de operare (SO) a fost proiectat s poat rula procese separate concurent. Aceste
procese pot fi aplicaii separate, cum ar fi spreadsheet (tabel de format mare) i email, sau
pot fi pri componente ale unui i acelai program, precum imprimarea de fond,
concomitent cu permisiunea de a dactilografia caractere noi ntr-un procesor de texte.
Proiectarea unui SO cu multitasking nu este un exerciiu trivial, precum i
proiectarea aplicaiilor ce ar profita de multitasking este o sarcin dificil. ntr-un mediu
cu adevrat multitasking, softul nu poate da crezare la nimic. El trebuie s manevreze o
eventual ntrerupere n orice moment, s fie capabil s ruleze concurent cu orice altceva
n sistem, s partajeze resurse precum memoria, discul, comunicaiile i alte echipamente.
Rezultatele a toate acestea sunt probleme de condiii de maraton. Acestea apar
atunci cnd dou sau mai multe evenimente se aliniaz i induc confuzie soft-ului care nu
se atepta s fie ntrerup chiar n mijlocul unei operaii ale sale.
Cu alte cuvinte, aceasta este temporizare rea. Termenul condiie de maraton vine
chiar de la ceea ce Dvs. v-ai nchipui drept ntrecere ntre aplicaii pentru a ajunge la fini,
fr a ti care va ajunge nti.
Testarea condiiilor de maraton este greu de planificat, dar putei avea un nceput
bun dac privii la fiecare stare de pe harta de tranziie a strilor i v gndii cam care ar
putea fi influenele externe a cror influen ar putea ntrerupe starea. Luai n considerare
ce ar putea face starea dac datele folosite nu sunt pregtite sau sunt n proces de
schimbare la momentul n care sunt necesitate. Ce s-ar ntmpla dac dou sau mai multe
arce sau linii conectoare apar exact n acelai moment?
Iat cteva exemple de situaii care ar putea expune la condiii de maraton:
65

Salvarea i ncrcarea aceluiai document n acelai timp cu dou programe diferite;

Partajarea aceleiai imprimante, aceluiai port de comunicare sau a unui alt
periferic;
Tastarea sau trimitea click-urilor de mouse n timp ce softul se ncarc sau schimb
stri;
Deconectarea sau pornirea a dou entiti de acelai program n acelai moment de
timp;
Folosirea programelor diferite pentru accesul simultan ntr-o baz de date comun.
Acestea par s fie nite teste dure, dar ele nu sunt, iar utilizatorul deseori le poate
provoca accidental. Softul trebuie s fie destul de robust pentru a manipula aceste situaii.
Ceva ani n urm ar fi prut ceva ieit din comun, dar astzi, utilizatorii se ateapt ca
softul s funcioneze adecvat n aceste condiii.
Repetiia, stresul i ncrcarea
Trei alte teste spre eec ale strilor sunt repetiia, stresul i ncrcarea. Aceste teste
au int manipularea problemelor de stare atunci cnd programatorul nu a considerat ce sar putea ntmpla n aceste situaii.
Testarea de repetiie implic repetarea unei i aceleiai operaii iar i iar. Aceasta ar
putea fi ceva simplu, precum lansarea i nchiderea aplicaiei de multe ori. Aceasta ar
putea fi salvarea i ncrcarea repetat a datelor sau selectarea repetitiv a aceleiai
operaii. Ai putea gsi vre-un neajuns dup cteva repetiii sau ai necesita mii de ncercri
pentru a depista o problem.
Cauza principal pentru efectuarea testrii de repetiie este cutarea lapsusurilor de
memorie. O problem frecvent n acest sens apare atunci cnd memoria este alocat
pentru executarea unei anume operaii, iar apoi nu se elibereaz complet dup terminarea
acesteia. Rezultatul este c programul eventual folosete memorie de care depinde pentru a
lucra fiabil. Dac ai utilizat vreo dat programe care lucreaz bine la lansare, iar apoi
devin tot mai ncete i se comport eronat cu trecerea timpului, acest fapt se datoreaz unui
neajuns legat de lapsusul de memorie. Testarea de repetiie va scoate la iveal aceste
probleme.
Testarea de stres ruleaz softul sub condiii mai slabe dect ideale: memorie nceat,
spaiu puin pe disc, uniti centrale ncete, modeme ncete, etc. Privii softul Dvs. i
determinai ce resurse externe necesit i ce dependene are.
Testarea de stres doar limiteaz resursele la minimumul absolut.
Testarea de ncrcare este exact opusul testrii de stres. Cu testarea de stres,
stoarcei soft-ul, cu testarea de ncrcare l umplei cu tot ce se poate manipula.
Operai cu cele mai mari fiiere de date posibile. Dac softul opereaz cu periferice
precum imprimanta sau porturile de comunicaie, conectai ct de multe putei. Dac testai
un Internet server care poate dirija simultan mii de conexiuni, facei-le. Maximizai
capacitile softului. ncrcai-l.
Nu uitai despre timp ca variabila de ncrcare in cadrul testrii. Pentru majoritatea
soft-urilor, este important ca acestea sa fie rulate pe perioade mai lungi. Unele soft-uri ar
trebui sa fie capabile sa ruleze infinit fr a fi restartate.
Nu este vreun motiv s nu putei combina repetiia, stresul i ncrcarea, rulnd
aceste teste concomitent. Este un mod sigur de a elucida neajunsuri severe care altfel ar
putea fi dificil depistate.
66

Sunt dou consideraii importante cu privire la repetiie, stres i testarea de

ncrcare:
Programatorii i managerii de proiect ai echipei Dvs. ar putea s nu fie complet
receptivi la eforturile Dvs. de a sparge softul n aa un mod. Probabil c i vei auzi
plngndu-se c nici un utilizator nu ar folosi sistemul n aa un mod i nici nu l va stresa
precum Dvs. Rspunsul scurt este da, l vor stresa astfel. Sarcina Dvs. este sa v asigurai
c softul funcioneaz n aceste situaii i s raportai despre probleme, dac acestea vor
aprea.
Lansarea i nchiderea programului Dvs. de milioane de ori probabil nu este posibil
dac o facei manual. La fel, gsirea a cteva mii de persoane i conectarea lor la serverul
Dvs. de Internet ar fi dificil de organizat. Se recomand n astfel de cazuri testarea
automat.

Tehnici de testare White - Box

Definiie: Testarea Cutiei Transparente (testarea structural) este o strategie care se
bazeaz pe testrile cilor interne, structurilor, i implementrilor unui software n proces
de testare. Spre deosebire de complementul su, testarea Cutiei Negre, testarea Cutiei
Transparente n general are cerine mai mari asupra capacitilor programatorului.

n general procesul de testare structural se executa astfel:

este analizat metoda de proiectare a softului testat (ST);
sunt identificate cile n structura ST;
intrrile sunt alese n aa mod nct ST s execute cile selectate. (Aceast
procedur se numete sensibilizare de ci. Rezultatele ateptate pentru acele intrri
sunt determinate);
se ruleaz testele;
ieirile obinute sunt comparate cu ieirile preconizate;
se determin daca funcionalitatea ST este corect.

Aplicaii
Testarea Cutiei Transparente poate fi folosit la toate nivelele de dezvoltare a
aplicaiei ca sistem, a integrrii i a sistemului nsi. Metoda este egalat cu testrile
aplicaiilor efectuate de programatori i este apreciat ca una precis.
Testarea Cutiei Transparente este mai mult dect testare de cod este testare de cale.
n general, sunt testate cile din modul. Dar putem folosi aceeai tehnic pentru testarea
legturilor ntre module i ntre subsisteme, chiar i n interiorul sistemelor.
Dezavantaje: Testarea Cutiei Transparente are cteva dezavantaje:
1. Numrul cilor de executare poate fi att de mare nct nu pot fi testate toate.
ncercarea de a testa toate caile de executare prin metoda Cutiei Transparente este la fel
inutil ca i testarea tuturor combinaiilor de date de intrate prin metoda Cutiei Negre.
2. Testarea structural poate s nu detecteze erori sensibile ca:
67

p q , posibil s se execute corect, excepie r 0 , sau

r

y x2

va trece testul numai n

cazurile x 0, y 0 i x 2, y 4 .
3. Testarea Cutiei Transparente presupune c fluxul de control este corect (ori
aproape corect). Atta timp ct testele sunt bazate pe cile existente, cele inexistente nu
pot fi descoperite i testate prin aceast metod.
4. Testerul trebuie s aib abiliti de a nelege i de a evalua ST (softul testat). Din
nefericire muli programatori de astzi nu au aceste caliti.
Avantaje: Cnd se folosete testarea Cutiei Transparente, programatorul poate fi
sigur c toate cile existente a programului supus testrii au fost identificate i testate.

Testarea fluxului de control

Testarea fluxului de control este una din cele dou tehnici de testare a Cutiei
Transparente. Aceast abordare identific cile de executare ale unui modul din codul
programului dup care creeaz i executa teste pentru a le acoperi.
Definiie: Cale sau drum este o secven de cod n care execuia se ncepe de la intrarea n
secven i se termin la ieire din secven.
Din pcate, intr-un modul compus, ncercarea de a testa toate cile de executare are un ir
de neajunsuri:
1. Numrul cilor poate fi mare astfel unele rmnnd netestate pe o perioada
nedeterminat de timp. Fiecare instruciune dubleaz numrul cilor i fiecare bucl
multiplic cile proporional cu numrul de iteraii din ea.
Ca exemplu:
for (i=1; i<=1000; i++)
for (j=1; j<=1000; j++)
for (k=1; k<=1000; k++)
Add(i,j,k);

Instruciunea Add se executa de un miliard de ori (1000 x 1000 x 1000). Fiecare cale
unic merita s fie testat.
2. Unele ci specifice pot pur i simplu s lipseasc din modul. Orice ncercare de a testa
modulul pe cile existente, nu le va gsi niciodat pe cele inexistente.
if (a>0) doCrestere();
if (a==0) doEgal();
// lipsete condiia - if (a<0) doDescrestere();

3. Pot exista i defecte n procesarea unui cod dint-un modul chiar i atunci cnd
instruciunea n sine este corect.
//code actual (incorect)
a=a+1;
//code corect
a=a-1;

4. Modulul se poate executa corect pentru aproximativ toate datele intrate, i greit doar
pentru citeva.
int div(int a, int b){
return a/b;

68

se execut corect cu excepia cnd b=0.

Dei aceast metod de testare are multe neajunsuri totui este o unealt vital din cutia cu
unelte a programatorului.

Graful fluxului de control

Graful fluxului de control st la baza testrii fluxului de control. Codul modulelor
este reprezentat printr-un graf, cile din graf sunt analizate i sunt create toate cazurile
posibile. Graful fluxului de control este format urmtoarele elemente:
Bloc de Procese
Un bloc de procese este o secven de program care se execut secvenial. Nici o
intrare n bloc nu este permis dect la nceputul lui i nici o ieire nu este permis dect la
sfritul lui. Odat ce blocul este iniializat, orice instruciune din interiorul lui se v-a
executa secvenial. Blocurile de procese sunt reprezentate n graful fluxului de control
printr-un cerc cu o intrare i o ieire.

Bloc de Decizie
Un punct de decizie este locul din modul unde fluxul se poate schimba. Majoritatea
punctelor de decizie sunt binare i implementate de instruciunile if-then-else. Blocurile
decizionale multilaterale sunt implementate de instruciunile case. Ele sunt reprezentate
grafic prin cercuri cu o intrare dar cu multiple ieiri.

Punct de jonciune
Un punct de jonciune este atunci cnd fluxurile se reunesc.

Exemplu. Codul ce urmeaz este reprezentat sub form de graf:

69

q=1;
b=2;
c=3;
if(a==2){x=x+2;}
else {x=x/2;}
p=q/r;
if(b/c>3){z=x+y;}

Figura 1: Graful fluxului de control echivalent cu codul programului.

Nivelurile de Acoperire
n Testarea Fluxului de Control, sunt definite diferite nivele de acoperire. Prin acoperire
numim procentajul de cod care a fost testat din tot ntregul cod care a fost dat spre testare.
Aici definim acoperirea la un numr de diferite nivele.(Nota: aceste nivele de acoperire nu
sunt prezentate n ordine, de aceea n unele cazuri este mai uor s definim un nivel de
acoperire mai superior dup care s definim unul cu nivel de acoperire mai inferior n
termene celui superior.)
Nivel 1
Cel mai inferior nivel de acoperire este 100% acoperire de instruciuni(n
unele cazuri 100% este czut i se refer doar la acoperire de instruciuni). Aceasta
nseamn c fiecare instruciune din modul este executat sub test cel puin odat. Ct timp
acest lucru pare un scop rezonabil, multe defecte pot fi scpate cu acest nivel de acoperire.
Considerm acest fragment de cod:
70

if (a>0) {x=x+1;}
if (b==3) {y=0;}

Acest cod poate fi reprezentat grafic astfel:

Aceste dou rnduri de cod genereaz patru ci de execuie diferite:

n timp ce un singur caz este suficient pentru a testa toate liniile de cod n acest
modul(intrrile a=6, b=3), este aparent c acest nivel de acoperire v-a lsa multe ci netestate. Astfel, acoperirea de instruciuni n general nu este un nivel acceptabil de testare.
Dei acoperirea de instruciuni este cel mai inferior nivel de acoperire, poate fi
greu de implementat n practic. Deseori modulele au pri de cod care este executat
numai n cazuri excepionale memorie mic, disc plin, file-uri ne-citite, pierdere de
conexiuni, etc. Programatorii pot ntlni dificulti sau chiar imposibiliti de a simula
aceste circumstane i acel cod care genereaz aceste probleme v-a rmnea ne-testat.
Nivel 0
Actual exist un nivel de acoperire sub 100% acoperire de instruciuni. Acest
nivel este definit ca testeaz ce ai de testat; las utilizatorii s testeze restul. Nenumrate
corporaii au folosit aceast metod de testare. Legat de acest nivel de acoperire, Boris
Beizer a scris testnd mai puin dect 100% acoperire de instruciuni, pentru noile
software este imoral i ar trebui condamnate. ... n caz c nu m-am exprimat clar, ...
codurile ne-testate intr-un sistem este stupid i iresponsabil.
71

Nivel 2
Urmtorul nivel de acoperire este 100% acoperire de decizii numit i
acoperire de ramuri. La acest nivel sunt create attea cazuri de testare nct s evalueze
toate ieirile deciziilor Adevrat i Fals mcar odat. Folosindu-ne de cazul precedent,
aceasta poate fi ndeplinit prin dou cazuri(a=2,b=2 i a=4,b=3).

Instruciunile cauzale cu ieiri multiple va fi testat pe fiecare ieire. Noteaz ca acoperirea

de decizii nu garanteaz neaprat acoperirea cilor, dar sigur garanteaz acoperirea
instruciunilor.
Nivel 3
Nu toate instruciunile condiionale sunt aa de simple ca cele prezentate mai sus.
Considerm aceste instruciuni condiionate mai complicate:
if (a>0 && c==1) {x=x+1;}
if (b==3 || d<0) {y=0;}

Pentru a fi adevrata prima condiie intrrile trebuie s fie a>0 i c=1. A doua condiie
cere ca b=3 sau d<0.
n prima condiie dac valoarea lui a este setat n 0 pentru a fi testat codul, dup
care c==1 o parte din condiie nu va fi testat. (n majoritatea limbajelor de programare a
doua condiie nici nu va fi evaluat.) Urmtorul nivel de acoperire este 100% acoperire
condiii. La acest nivel sunt scrise attea teste nct fiecare instruciune condiional s
aib ieire ADEVARAT i FALS i sunt testate cel puin odat. Acest nivel de acoperire
poate fi atins n dou cazuri (a>0,c=1, b=3,d<0 i a0,c1,b3,d0). Acoperirea de
condiii este de obicei mai bun dect acoperirea de decizie, deoarece fiecare condiie
individual este testat mcar odat, n timp de acoperirea de decizie poate fi ndeplinit
fr testarea fiecrei condiii.
Nivel 4
Considerm aceast situaie:

if(x&&y) {InstructiuneConditionata;}
// nota: && indica i logic

Putem atinge acoperirea de condiie n dou cazuri (x = Adevrat, y = Fals i x = Fals, y =

Adevrat) dar cu aceste dou alegeri de date intrate InstructiuneConditionata nu se
72

v-a executa niciodat. Existnd aceast combinaie ca mai sus, s fie ct mai complet
100% Decizie / Condiie, acoperirea poate fi selectat. La acest nivel, cazurile testate
sunt create pentru fiecare condiie i fiecare decizie.
Nivel 5
Ca s fie ct mai complet, considerm c un compilator al limbajelor de
programare evalueaz, de fapt, condiiile multiple dintr-o decizie. Folosim aceste
cunotine pentru a crea cazuri de teste flexibile 100% multipl acoperire de condiie.
if (a>0 && c==1) {x=x+1;}
if (b==3 || d<0) {y=0;}
// not a: || inseamna OR logic

va fi evaluat ca:

Acest nivel de acoperire poate fi atins prin patru cazuri:

a>0,
a0,
a>0,
a0,

c=1,
c=1,
c1,
c1,

b=3,
b=3,
b3,
b3,

d<0
d0
d<0
d0

Obinnd 100% multipla acoperire de condiii de asemenea se atinge acoperirea de decizii,

condiii i decizie / condiie. De menionat c multipla acoperire de condiii nu garanteaz
acoperire de cale.
Nivel 7
n sfrit am ajuns la cel mai nalt nivel, care este 100% acoperire de cale.
Pentru modulele fr bucle numrul cilor este n general destul de mic ca un test s fie
construit pentru fiecare cale. Pentru modulele cu bucle, numrul cilor poate fi enorm i
acest lucru cauzeaz o problem de testare refractar.

73

O diagram de flux cu multe ci.

Nivel 6
Cnd un modul are bucle n cile codului, dac numrul cilor este infinit, o
reducere semnificativ poate fi fcuta limitnd execuia buclei la un numr mic de cazuri.
Primul caz nu execut bucla, al doilea executa bucla o data, al treilea de n ori unde n este
un numr mic reprezentnd o valoare tipic a buclei, al patrulea execut bucla la numrul
maxim m. Adugat se poate ncerca m-1 i m+1.
nainte de a ncepe testarea fluxului de control, trebuie ales un nivel de acoperire
corespunztor.

Testare structurat / Testarea cilor de baz

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 structurat const din urmtorii pai:
Extragem controlul fluxului grafic din modul software-ului;
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;
Considerm urmtorul graf al fluxului de control.

74

Un exemplu de graf al fluxului de control.

McCabe definete Ciclomatic Complex (C) al unui graf ca
C = muchiile nodurile + 2
Muchiile sunt sgeile iar nodurile sunt cercurile de pe graf. Precedentul graf are
24 muchii i 19 noduri, deci C = 24 19 + 2 = 7.
n unele cazuri aceasta calculare poate fi simplificat. Dac toate deciziile din graf
sunt binare (au exact dou ieiri), i sunt decizie p binar, atunci
C=p+1
Ciclomatic Complex 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.
Un proces de selectare a cilor de baz artat de ctre McCabe:
Alege o cale de baz. Aceast trebuie s fie o cale de execuie raional tipic,
nu una de procesare. Cea mai bun cale aleas va fi din punct de vedere al
programatorului.

75

Calea de baz aleas ABDEGKMQS.

Pentru a alege calea urmtoare, schimbm doar ieirea primei decizii, pstrnd
numrul maxim celorlalte decizii ca i la etapa precedent.

A doua cale de baz ACDEGKMQS

Pentru a genera a treia cale, se ncepe din nou cu linia de baz variind ns a doua
decizie.
76

A treia cale de baz ABDFILORS

Generarea celei de a patra ci, ncepem din nou cu linia de baz dar variem cea
dea treia instruciune. Continum varierea condiie de condiie pn cnd este
atins partea inferioar a grafului.

A patra cale de baz ABDEHKMQS

77

A cincia cale de baz ABDEGKNQS

Folosind toate strile deciziilor de-a lungul liniei de baz trecem la cea de a doua
cale, trecnd prin toate deciziile una cte una. Aceast metoda este aplicat
pn cnd setul cilor de baz este completat.

A asea cale de baz ACDFJLORS

78

A aptea cale de baz ACDFILPRS

Astfel, un set de ci de baz pentru acest graf:
ABDEGKMQS
ACDEGKMQS
ABDFILORS
ABDEHKMQS
ABDEGKNQS
ACDFJLORS
ACDFILPRS

Testarea structurat convoc crearea unui caz de test pentru fiecare din aceste
drumuri. Acest set de teste garanteaz att acoperirea pe instruciuni ct i pe ramuri.
Seturile de ci de baz nu sunt neaprat unice.
Aplicabilitate i limite
Testarea fluxului de control este piatra de temelie la testarea unitilor. Trebuie
folosit pentru toate modulele de cod care nu pot fi suficient testate prin verificri i
inspecii. Limitrile sunt c programatorul (persoana ce testeaz) trebuie s aib capaciti
de programare pentru a nelege codul i fluxul de control. n plus, testarea fluxului de
control poate consuma mult timp datorit tuturor modulelor i cilor de baz care cuprind
sistemul.
79

Testarea fluxului de date

Aproape fiecare programator face acest tip de greeal:
main() {
int x;
if (x==42){ ...}
}

Aceast greeal este referirea la o variabil fr a o iniializa mai nti.

Programatorii naivi, incontient, presupun c compilatorul sau sistemul de funcionare v-a
seta toate variabilele n zero, goluri, ADEVRAT, 42 sau n orice alt valoare de care au
nevoie mai trziu n program. Un simplu program n C ilustreaz acest defect:
#include <stdio.h>
main() {
int x;
printf ("%d",x);
}

Valoarea afiat la ecran oricare valoare ce a fost lsat n locaia de memorie

atribuit variabilei x, ne necesar la ce se atepta programatorul.
Testarea fluxului de date este un instrument puternic de detectare astfel de erori.
Rapps i Weyuker, popularizatorii acestei abordri au scris, Este n credina noastr c,
aa cum unii nu sunt ncrezui n program fr a executa i testa toate instruciunile din el,
aa i alii nu pot fi ncrezui n program fr a vedea efectele valorii produse de fiecare
compilare
Testarea fluxului de date este un instrument puternic ce detecteaz folosirile
nepotrivite a datelor datorit codificrii erorilor.
Tehnica
Variabilele ce conin date au un ciclu de via definit. Sunt create, folosite i
distruse. n unele limbaje de programare(FORTRAN i BASIC, de exemplu) crearea i
distrugerea se face automat. I se atribuie o valoare imediat ce este creat i distrusa ndat
ce se nchide programul.
n alte limbaje(C, C++ i Java) crearea este formal. Variabilele sunt iniializate astfel:
int x; // x iniializat ca ntreg
string y; // y iniializat ca ir
Aceste declaraii n general se gsesc ntr-un bloc de cod ce ncepe cu acolad deschis {
i se termin cu una nchis }. Variabilele definite ntr-un bloc sunt iniializate atunci cnd
definirea lor este executat i sunt automat distruse la sfritul blocului. Aceasta este raza
de aciune a unei variabile. De exemplu:
{
int x;
...;
{
int y;
...;
}
...;
}

//
//
//
//
//
//
//
//
//

nceperea blocului exterior

x este definit ca ntreg n acest bloc
x poate fi accesat aici
nceperea blocului interior
y este definit n acest bloc interior
ambele x i y pot fi accesate aici
y este automat distrus la sfritul acestui bloc
x poate fi accesat dar y nu
x este automat distrus

80

Variabilele pot fi folosite n calcule ( a=b+1). Pot fi folosite de asemenea n condiii

(if(a>42)). n ambele cazuri este important ca variabilelor s li se atribuie o valoare din
timp.
Exis trei posibiliti pentru prima apariie a unei variabile intr-un program:
~d variabila nu exist (indicat de ~) dup care este definit (d)
~u variabila nu exist, dup care este folosit (u)
~k variabila nu exist, dup care este distrus (k)
Prima variant este corect. Variabila nu exista i dup aceea este definit. A doua
variant este incorect. O variabil nu trebuie folosit nainte de a fi definit. A treia este
probabil incorect. Distrugerea unei variabile nainte de a fi creat indic ctre o eroare de
programare.
Acum s considerm urmtoarea secven de timp a perechilor definete(d)
folosete(f) i distruge(k):
dd - Definete i definete corect dar suspicios. Probabil o eroare de
programare.
du - Definete i folosete forma corect. Cazul normal.
dk - Definete dup care distruge nu este invalid dar probabil o eroare de
programare
ud - Folosete i definete acceptabil.
uu - Folosete i folosete din nou acceptabil.
uk - Folosete i distruge acceptabil.
kd Distruge i definete acceptabil. O variabil este distrus dup care
redefinit.
ku Distruge i folosete un defect serios. Folosirea unei variabile care nu
exist
sau nedefinit este ntotdeauna o eroare.
kk Distruge i distruge probabil eroare de programare.
Examineaz ordinea n timp a definirii, folosirii i distrugerii variabilelor
Graful fluxului de date este similar celui de control aici fiind inclus fluxul de
procesare prin modul. n plus, se detaliaz definiia folosete, folosete i distruge pentru
fiecare variabil a unui modul. Noi vom construi aceste diagrame i vom verifica ca
ablonul definete folosete distruge este adecvat. Mai nti, vom executa un test static
asupra diagramei. Prin static nelegem examinarea diagramei (Oficial prin inspecii sau
neoficial prin cutare). Dup care vom efectua un test dinamic asupra modulului. Prin
dinamic vom spune c construim i executm cazuri de teste. S ncepem cu testarea
static.

Testarea Static a Fluxului de Date

Urmtoare diagram a fluxului de control a fost adnotat cu definete folosete
distruge pentru fiecare variabil folosit n modul.

81

Diagrama fluxului de control.

Pentru fiecare variabil din modul vom examina ablonul definete folosete
distruge dea lungul cilor fluxului de control. Considerm variabila x n timp ce traversm
partea stng dup care dreapt:

Diagrama fluxului de control adnotat cu definete folosete distruge pentru

var. x.

82

ablonul definete folosete distruge pentru x (luate n perechi n timp ce

urmrim cile) este:
~definete
corect, caz normal
definete definete - suspicios, probabil o eroare de programare
definete folosete - corect, caz normal
Acuma pentru variabila y. Noteaz c prima ramur din modul nu are impact asupra
var. y

Diagrama fluxului de control adnotat cu definete folosete distruge

pentru var. y.
ablonul definete folosete distruge pentru y (luate n perechi n timp ce
urmrim cile) este:
~folosete
folosete definete definete folosete folosete distruge
definete distruge

gaf major
acceptabil
corect, forma normal
- acceptabil
- probabil eroare de programare

Acum pentru variabila z

83

Figure 11-3: Diagrama fluxului de control adnotat cu definete folosete distruge

pentru var. z

ablonul definete folosete distruge pentru z (luate n perechi n timp ce

urmrim cile) este:
~distruge
distruge folosete
folosete folosete
distruge distruge
distruge definete
definete folosete

eroare de programare
gaf major
acceptabil
probabil eroare de programare
acceptabil
corect. Forma normal

n efectuarea unei analize statice asupra acestui model a fluxului de date au fost
descoperite urmtoarele probleme:
x: definete definete
y: ~ folosete
y: definete distruge
z: ~ distruge
z: distruge folosete
z: distruge distruge
Din nefericire, n timp ce testarea static poate detecta multe erori la fluxurile de
date, nu le poate gsi pe toate. S consideram urmtoarele situaii:
Matricele sunt colecii de elemente de date care mpart acelai nume i tip. De
exemplu: int obiect [100];
definete o matrice denumit obiect constnd din 100 elemente ntregi. n C, C++ i
Java elementele individuale sunt definite obiect [0], obiect [1], obiect [2] etc. Matricele
sunt definite i distruse ca o unitate, dar elementele individuale ale matricei sunt utilizate
individual. De cele mai multe ori, programatorii se refera la obiectul [j] unde j se schimb
n mod dinamic n timp ce programul se execut. n cazul general, analiza static nu poate
determina dac regulile definete utilizeaz distruge au fost urmate ntocmai, dect
dac fiecare element este considerat n mod individual.
84

2. n cazul fluxurilor de control complexe este posibil ca o anumit cale s nu fie

executat niciodat. n acest caz o combinaie definete utilizeaz distruge improprie
ar putea exista, dar nu va fi executata niciodat i, deci, nu va fi pe deplin improprie.
3. n cadrul sistemelor n care procesele sunt ntrerupte unele aciuni definete
utilizeaz distruge s-ar putea produce la nivelul ntrerupt, n timp ce altele ar putea
aprea la nivelul de procesare principal. n plus, dac sistemul folosete nivele multiple de
prioriti de executare, analiza static a nenumratelor interaciuni posibile este, pur i
simplu, prea dificil pentru a putea fi executat manual.
Din acest motiv revenim acuma la testarea fluxurilor de date dinamic.

Testarea fluxurilor de date dinamica

Datorit faptului c testarea fluxurilor de date se bazeaz pe un modul al fluxului de
control, se presupune c fluxul de control este, n esen, corect. Procesul testrii fluxului
de date nseamn a alege destule cazuri de testare pentru a:
urmri fiecare definete pan la fiecare utilizeaz al sau;
urmri fiecare utilizeaz de la corespondentul sau definete.
Pentru a face acest lucru, enumerai cile dintr-un modul. Acest lucru se realizeaz
utiliznd aceeai apropiere ca i n cazul testrii fluxului de control. ncepei de la punctul
de intrare al modulului, luai calea cea mai din stnga din program pn la ieire. Revenii
la nceput i modificai prima condiie din ramur. Urmrii acea cale pan la ieire.
Revenii la nceput i modificai a doua condiie din ramur, apoi a treia i aa mai departe
pn ce toate cile sunt verificate. Apoi, pentru fiecare variabil creai cel puin cte un caz
de testare care s cuprind fiecare pereche definete utilizeaz.
Aplicabilitate i limite
Testarea fluxului de date construiete i extinde tehnicile testrii fluxului de control.
Ca atare testarea fluxului de control ar trebui s fie folosit pentru toate modulele de cod
care nu pot fi testate suficient prin revizii i inspecii. Limitele sale se refer la faptul c
testerul trebuie s aib suficiente abiliti de programare care s neleag codul, fluxurile
sale de control i variabilele sale. Asemenea testrii fluxului de control, testarea fluxului
de date poate fi uneori consumatoare din cauza tuturor modulelor, a cailor i a variabilelor
care compromit sistemul.

Managementul testrii
Acest capitol constituie o introducere n procesul de organizare a testrii i de
conducere a procesului de testare n cadrul unor organizaii. Privirea general asupra
acestei activiti nu va respecta modalitatea de organizare a testrii pentru o structur
specific. Totui problema este important pentru orice organizaie i trebuie studiat de
toi.
Vom ncepe cu fenomenul corelaiei dintre risc i testare, vom prezenta detaliat
subiectul planificrii i controlul testului, astfel vom identifica cum independena ajut
procesului de testare. O arie esenial n dirijarea procesului de testare este perceperea
diferitor roluri i sarcini asociate testrii, aa ca liderul testului i testorul.
Un capitol nu poate cuprinde toat informaia necesar pentru a oferi posibilitatea
unui cititor s devin liderul testului n practic sau managerul testului, dar intenionm s
85

v oferim informaia general necesar pentru a nelege variatele ipostaze ale rolurilor n
dirijarea testului

Riscul i testarea
Nu se poate de discutat despre managementul testrii nainte de a vorbi despre risc
i influena lui asupra proceselor fundamentale ale testrii. Dac nu ar exista riscul unor
posibile reacii adverse n dezvoltarea software sau hardware, atunci nu vor fi necesare
testrile. Cu alte cuvinte, dac nu ar exista defecte, nu ar exista teste.
Riscul poate fi definit ca un eveniment, hazard, situaie inacceptabil.
Riscul un factor care poate rezulta dintr-o consecin negativ, de obicei
exprimat ca impact sau probabilitate. ntr-un proiect liderul testului va folosi riscul n 2
modaliti diferite: riscul proiectului i riscul produsului. n ambele cazuri riscul poate fi
calculat ca:
Nivelul riscului = probabilitatea de manifestare a riscului * impactul n caz de
nregistrare.
Riscurile proiectului
La conducerea unui proiect de testare, un test lider va utiliza riscurile proiectului
pentru a dirija capacitatea de livrare.
Riscurile proiectului includ:
Problemele furnizrii:
* Nereuita persoanei a treia s distribuie la timp sau deloc.
* Problemele contractuale, ca satisfacerea criteriului de acceptare.
Factorii organizatorici :
* Lipsa abilitilor i personalului.
* Problemele personale i de instruire.
* Problemele politice, ca schimbarea administraiei i reorganizarea care vor afecta
resursele proiectului.
Problemele care i mpiedic pe testori s-i comunice cerinele sale i rezultatele
testrii.
Eecul de a continua la un nivel jos testarea i revizuirea:
* Lipsa aprecierii avantajelor testrii.
Problemele specialitilor:
* Probleme n definirea corect a cerinelor.
* Proporiile pe care le pot realiza cerinele n restriciile proiectului.
* Calitatea echipei de proiectare, dezvoltare i testare.
Pentru fiecare risc identificat ar trebui stabilite probabilitatea ( ansa ca riscul s se
realizeze) i impactul ( ce se va ntmpla n caz de manifestare a riscului), precum
identificarea i administrarea oricrei aciuni rezolvate ( aciuni pentru reducerea
posibilitii de apariie a riscului, sau reducerea impactului riscului dac s-ar nregistra).
Deci, de ex. dac s-a identificat un risc a treia persoan suplinitoare poate deveni falit n
timpul dezvoltrii, managerul testului va revizui raportul suplinitorului i poate decide c
probabilitatea aceasta este medie ( 3 pe scara de la 1 la 5, 1fiind un risc sporit i 5 redus ).
Impactul asupra proiectului, dac se va ntmpla va fi mare ( 1 utiliznd aceast scar).
Deci, nivelul riscului este 3x1=3. Astfel cu ct este mai mic numrul, cu att este mai mare
riscul. 3 fiind aria de risc medie, liderul testului va trebui s hotrasc ce aciuni de
ameliorare s ntreprind n ncercarea de a stopa riscul care devine realitate. Aceasta poate
86

include neparticiparea persoanei a treia, sau asigurndu-se de achitarea eficient a

livrrilor de ctre o persoan ter.
La analizarea, ameliorarea i administrarea acestor riscuri test managerul se
conduce de principiile proiectului managerial stabilite, al abordrilor i metodelor.
Riscurile proiectului recunoscute n timpul planificrii testului trebuie incluse n
planul testului IEEE 829 (vezi mai trziu n acest capitol detalii despre coninutul planului
testului), pentru managementul i controlul continuu al riscurilor noi i existente se
recomand ca liderul testului s in un registru al riscurilor.
Riscurile produsului
La planificarea ori definirea testelor un test lider sau testerul care utilizeaz testarea
risk-based va dirija riscurile produsului.
Ariile softului predispuse riscului se numesc riscurile produsului, pentru c
prezint risc pentru calitatea produsului. Cu alte cuvinte, un posibil defect manifestat n
realitate este un risc al produsului.
Exemple de riscuri ale produsului:
Softul distribuit predispus erorilor.
Puine cerine duc la o definire i construire inexact a softului.
Posibil ca defectul software/ hardware va cauza daune unei persoane sau unei
companii.
Puine caracteristici ale calitii software ( funcionalitatea, securitatea, reabilitarea,
utilitatea, performanele) duc la un feedback nesemnificativ.
Soft-ul poate s nu ndeplineasc cerinele i s posede funcionaliti nesolicitate.
Riscurile snt utilizate pentru a decide unde trebuie nceput testul n procesul de
dezvoltare a soft-ului, riscul cauzat de cerine puine poate fi ameliorat prin utilizarea unei
revizuiri formale de ndat ce cerinele au fost documentate la nceputul proiectului. Riscul
produsului furnizeaz de asemenea informaii care permit luarea deciziilor referitoare la
numrul testelor necesare pentru o component sau un sistem. Cu ct riscul este mai mare,
cu att mai detaliat i mai cuprinztor va fi testul. n acest mod testul este utilizat pentru a
reduce efectele adverse ( atestate sau care nu exist).
Reducerea riscului produsului poate include de asemenea alte activiti,
exceptnd testele. De ex. n situaia cnd se nregistreaz puine cerine, cea mai
recomandat soluie este nlocuirea n primul rnd, a analistului care scrie puine
revendicri.
Am menionat deja c abordarea testrii din perspectiva riscului asigur
oportuniti pro active pentru a reduce nivelul riscului produsului nc de la nceputul
proiectului. Acesta implic identificarea riscului produsului i modalitatea de utilizare
pentru a dirija planificarea, specificarea, i executarea testului. n abordarea bazat pe
riscurile identificate:
vor determina tehnicile de testare care trebuie de implicat, i /sau de realizat
extinderea testului, ex. Motor Industry Software Reability Association definete care teste
ar trebui utilizate pentru fiecare nivel de risc, cu ct este mai mare riscul, cu att mai mare
este aria de acoperire necesar tehnicilor testului.
prioretiza testarea n ncercarea de a depista defectele critice ct de devreme posibil,
ex. prin identificarea ariilor cu o posibilitate sporit de nregistrare a defectelor (cele mai
complexe) testarea ar putea fi orientat spre aceste arii.
87

vor determina orice activitate non-testare care ar putea fi realizat pentru a reduce
riscurile, ex. de a desfura procese de instruire a designerilor cu puin experien.
Testarea bazat pe risc se realizeaz n baza cunotinelor colective i pespicacitatea
acionarilor, testerilor, designerilor, tehnicienilor, reprezentani ai businessului i a oricrei
persoane care tie soluia pentru a determina riscurile i nivelele testrii la care pot aprea
aceste riscuri.
Pentru a se asigura c ansa de nereuit a produsului s-a minimizat, activitile
manageriale asigur o abordare organizat:
Verificarea continu a ce poate merge greit (riscuri). Periodic pe toat perioada de
elaborare, trebuie realizat revizuirea regulat a riscurilor existente i cutarea altora.
Determinarea riscului important de cercetat (probabilitate x impact). Ca i progresul
proiectului, datorit activitilor de reducere a riscului se poate reduce din importan sau
pot disprea ambele.
Implementarea aciunilor referitoare la acest risc (aciuni de reducere).
Testarea susine identificarea noilor riscuri ale proiectului prin revizuirea continu a
riscurilor proiectului distribuite pe parcursul ciclul de dezvoltare. Ajut la determinarea
riscului primordial de redus prin acordarea prioritilor. Poate diminua incertitudinile
despre risc, de ex. prin testarea unui component i verificarea dac nu conine defecte. Prin
desfurarea testelor specifice se poate de verificat alte strategii care se refer la risc, aa
ca contingency plans ( planurile ntmpltoare) .
Testarea este o activitate de control al riscului care asigur feedback-ul despre
riscul rmas n produs prin estimarea eficacitii nlturrii defectului stringent i prin
revizuirea eficacitii planurilor ntmpltoare.

Organizarea testrii
Organizarea testrii i independena
Testarea independent este cea care se realizeaz de cineva diferit de dezvolttorul
codului testat. Rmnnd independent, e posibil mbuntirea eficacitii testrii, dac se
implementeaz corect.
Oamenii pot comite greeli, de la simple greeli ortografice sau utilizarea greit a
sintaxei la erori fundamentale n mijlocul unui document pe care l scriem. Problema
const n aceea c noi ca autori percepem mai greu propriile greeli dect ceilali care vin
n contact mai puin direct cu documentul. Aceasta este o problem complicat n lumea
dezvoltrii software, din cauza diferitor viziuni ale testerilor i dezvolttorilor. O
ngrijorare c toi comitem greeli este c, la aceast etap, se neglijeaz prin prerea c
ceea ce a fost produs, e ceea ce a fost solicitat. Testerul, ns se va conduce de opinia c tot
ce se supune testului conine erori i va cuta minuios s depisteze i s localizeze pe
acestea. Iat prin ce se face testarea independent important, pentru c e cu adevrat
dificil pentru un autor s-i identifice propriile greeli, pe cnd pentru alii pare mai
simplu. Exist mai multe opiuni pentru multe nivele de independen. n general, cu ct
mai distanat este testerul de produsul testat cu att mai mare este nivelul de independen.
Fig.5.1 indic rolurile cele mai comune i gradul de independen pe care le presupun.
Gradul de
independen

Nivelul
1

Rolul
Dezvolttorul
88

2
3
4
5
6

Testerul independent care cedeaz echipei de

dezvoltare
Echip de testeri permanent i independent din
cadrul organizaiei de dezvoltare
Testeri independeni sau echipa de testare asigurai de
unitile operaionale comerciale
Testeri specializai n testarea utilizabilitii, securitii
sau performanelor
Testori sau echipe de testare outsourced (din alte
organizaii sau n baz de contract)

Desigur c independena se rsfrnge asupra preului. Cu ct mai mare este nivelul

de independen , cu att mai mare posibilitatea erorilor n testare din cauza necunoaterii.
Nivelul de independen va depinde i de amploarea organizaiei. ntr-o organizaie mic
unde oricine a contribuit la fiecare activitate e foarte dificil de difereniat rolul testatorului
de celelalte roluri, i apoi el poate s nu fie independent deloc. Soluia n aceste
circumstane pentru testator este s aib o independen n gndire, i nu e necesar s fie
separat ( o echip separat).
Este posibil de asemenea combinarea i mperecherea nivelelor de independen,
ex. echipa alctuit din resurse permanente , uniti de afaceri permanente i contracturi.
Pentru un complex proiect de strict securitate se recomand multiple nivele de testare, cu
toate sau unele nivele ndeplinite de testatori independeni. Abordarea agil a dezvoltrii
modific abordarea tradiional a independenii. n aceast situaie fiecare primete
multiple roluri, astfel meninerea independenei totale nu
este mereu posibil.
Experimentatorul n aceast situaie trebuie s fie capabil s se axeze pe o viziune
independent , la momentele relevante ale proiectului. Testorul obine independena
viziunilor nebnuind nimic i prin faptul c el nu pune stpnire pe soft precum fac
developatorii,
Independena n implementarea testrii cunoate avantaje i dezavantaje, urmrii
n tabela 5.1
Avantaje:
*testatorul vede alte i diferite defecte spre deosebire de autor.
*Experimentatorul este neprtinitor.
*Experimentatorul va vedea mai bine ceea ce s-a construit, dect ideile
implementate ale developatorului.
*Testatorul nu face presupuneri referitoare la calitate.
Dezavantaje:
* Izolarea de echipa experimentatoare ( totala independen) , semnific totala
dependen de bazele testului pentru a nelege c ceea ce reprezint experimentatorul este
testat ( documentaia care rareori corespunde ultimelor progrese).
* Testatorul poate fi perceput ca gtul unei sticle, deoarece executarea independent
a testului este ultima etap i este afectat de ntrzierile proceselor de testare n perioada
incipient.
* Developatorul, pierde simul responsabilitii pentru calitate , se poate presupune
c ei nu se ngrijoreaz de erori deoarece echipa independent de testare le va depista.
89

* Independena total a viziunilor aranjeaz developatorii i experimentatorii pe

pri diferite ale unui gard invizibil. Aceasta poate fi o susinere a comunicrii care n
circumstane normale ar asigura nelegerea comun i o activitate efectiv. Semnific
figurativ, totodat c developatorii snt vzui cum arunc soft-ul partea cealalt de gard.

Sarcinile test liderului i ale experimentatorului

Sarcinile snt realizate de persoane care fac din testare o carier. Totui acestea pot
fi realizate i de alte persoane ca managerul proiectului, managerul
calitii,
developatorul, expertul n afaceri i n domeniu, infrastructura sau operaiile TI.
Disponibilitatea resurselor determin de obicei tipurile resursei distribuite n fiecare
proiect, ex. dac nu exist experimentatori profesioniti disponibili, o organizaie poate
identifica lipsa testrii TI sau a resurselor comerciale pentru realizarea rolului de testator
pentru un proiect specific sau o perioad de timp. Programa definete 2 roluri de testare ,
test lider,( sau managerul testului/ coordonatorul testului) i experimentatorul. Pot exista i
alte roluri n organizaia voastr , dar nu snt dezvluite aici.
Rolurile testrii pot fi preluate de oricine care posed abilitile necesare sau cine
are instruirea potrivit. De exemplu, rolul de test lider poate fi ndeplinit de managerul
proiectului. Decizia cine va ndeplini rolurile va depinde de structurarea organizaiei i a
proiectului, precum i de amploarea i numrul resurselor active la acest proiect.
E esenial de realizat diferena dintre rolul de testator i funcia de testator. Rolul
este o activitate, ori o serie de activiti atribuite persoanei spre realizare, de ex. rolul de
test lider. O persoan poate avea mai multe roluri la un moment, depinde de experiena i
nivelul capacitii de munc ntr-un proiect. Funcia presupune ceea ce este angajat s fac,
deci unul sau mai multe roluri pot alctui o funcie. De exemplu liderul testului poate fi i
testator.
Sarcinile preluate de un lider se aseamn cu cele ale managerului proiectului i se
apropie de abordarea standard a conducerii proiectului. n acest context liderul testului
este cineva care conduce o echip de experimentatori (fie aceasta unul sau mai muli
experimentatori). Li se mai spune test programme managers (manageri ai programei de
testare), test manageri, lideri ai echipei de testare i coordonatorii testului.
Sarcinile acestuia includ:
Coordonarea dezvoltrii strategiilor testului create pentru proiect, i metodelor de
testare (politicii) prevzute de organizare.
Contribuirea activitilor altor proiecte din perspectiva testrii, ca dezvoltarea
planurilor de livrare.
Planificarea dezvoltrii testelor solicitate - care vor include asigurarea c
dezvoltarea percepe corect riscul, selectnd strategia potrivit a testrii (nivelele de testare,
perioadele, abordarea, obiectivele i planificarea managementului incidentelor), estimnd
timpul i efortul i transformndu-l n costul testrii i n obinerea resursele corecte.
Dirijarea specificaiilor, pregtirea, implementarea i executarea testelor, inclusiv
monitorizarea i controlul tuturor specificaiilor i execuiilor.
Considerarea aciunilor solicitate, incluznd adaptarea planificrii, bazat pe
rezultatele i progresele testului, i orice aciune necesar pentru a compensa problemele
i ntrzierile.
Asigurarea, c configuraiile adecvate ale gestionrii testware snt n ordine i c
testware este pe deplin trasat, de ex. exist o relaie ierarhic stabilit ntre cerinele i
specificaiile detaliate ale documentelor.
90

Stabilirea metricilor adecvate pentru msurarea progresului testului i evaluarea

calitii testului activat i a produsului testat.
A conveni ce trebuie s fie automatizat, la ce nivel i cum, asigurndu-ne c se
implementeaz conform planului.
Unde este necesar, selectarea mijloacelor pentru a susine testarea i asigurarea c
orice instruciune a uneltelor solicitate este respectat.
A conveni structura i implementarea mediului de testare.
Planificarea oricrei activitate de testare.
Scrierea, la sfritul proiectului, a unui raport sumar al testului bazat pe
informaiile referitoare la testare.
Aceste snt doar cele mai generale sarcini. De fapt alte resurse pot aplica una sau
mai multe sarcini, n dependen de cerine, sau pot fi ndemnai de lider s accepte altele.
Principalul s ne asigurm c fiecare i tie sarcinile, c ele snt executate la timp
respectnd bugetul i sunt dirijate spre completare.
Alt rol este cel al testerului, cunoscut i ca test analist sau test executor.
Sarcinile tipice preluate de un experimentator includ:
Revizuirea i contribuirea la dezvoltarea planului testului.
Analiza, revizuirea i verificarea cerinelor, specificaiilor i modelelor pentru
testare.
Crearea specificaiilor testului conform bazei testului.
Stabilirea mediului de testare ( n concordan cu sistemele de administrare i cu
network management). n unele organizaii acestea pot fi controlate centralizat. n aceast
situaie testorul va interaciona direct cu responsabilii de mediu i se va asigura c mediul
testului v fi gata la timp conform specificaiilor.
Pregtirea i obinerea /copierea/ crearea datelor testului.
Implementarea testelor la toate etapele testului, executarea i preluarea rezultatelor
testelor, evaluarea rezultatelor i documentarea deviaiilor de la rezultatele ateptate.
Utilizarea administrrii i dirijrii testului i utilitarele de monitorizare a testului
necesare.
Automatizarea testelor (poate fi susinut de testor sau expertul n testele automate).
Aplicarea testelor i msurarea performanelor componentelor i a sistemului, unde
este necesar (dac se poate aplica).
Revizuirea testelor dezvoltate de ctre ali testori.
Dup cum am menionat anterior, e esenial s reii cnd studiezi rolurile i sarcinile
unui proiect, c o persoan poate ndeplinii mai multe roluri si s realizeze unele sau toate
sarcinile aplicabile rolului. Aceasta semnific a avea un job: include mai multe roluri i
sarcini.

Strategiile de testare
Abordarea testului sau strategia de testare definete cum se va implementa testul.
Strategia de testare poate reflecta testarea pentru o ntreag organizaie, o program de
lucru sau un proiect individual. Poate fi:
dezvoltat devreme n perioada de dezvoltare, care e cunoscut ca preventiv - n
aceast manier procesul de proiectare a testelor este iniiat ct mai devreme posibil n
perioada de dezvoltare pentru a mpiedica introducerea greelilor n soluia final.
91

lsat pn exact la nceputul executrii testului, care este cunoscut ca reactiv aceasta se ntmpl cnd testul este ultima etap de dezvoltare i nu este iniiat pn cnd
proiectarea i codificarea nu au fost completate - cteodat identificat ca metoda cascad,
de ex. toate etapele de dezvoltare snt consecutive, urmtoarea nu poate ncepe pn la
definitivarea aproape complet a celei anterioare).
Exist multe abordri i strategii care pot fi utilizate:
Strategia analitic care ca i tehnicile risk - based testeaz ariile cu risc sporit (vezi
mai trziu o privire general a tehnicilor risk - based).
Abordarea model - based ca testarea stohastic care utilizeaz informaii statistice
despre defectele omise (aa ca sigurana modelelor dezvoltate) i utilizarea (profilul
operaional).
Abordarea metodic, ca failure - based (inclusiv ghicirea erorilor i asaltarea
defectelor), check-list based i bazat pe calitatea caracteristicilor.
Abordarea conform standardelor, stabilite de industria specific standardelor aa ca
The Railway Signaling Standarts (care stabilete nivelele de testare) sau MISRA (care
definete cum s proiectezi, s construieti i s testezi sigur software pentru motor
industry).
Process compliant approaches (abordarea conform procesului), care ader la
procesul de dezvoltare cu o varietate de metodologii sau cu strategiile tradiionale cascad.
Abordri dinamice i euristice, ca testarea de explorare (vezi cap.4), unde testele
sunt mai reactive la evenimente dect este prevzut, i cnd executarea i evaluarea
reprezint sarcini concurente.
Abordarea consultativ, ca acelea unde acoperirea testului este condus de
indicaiile i ghidarea tehnologiei i /sau de experii din domeniul businessului din echipa
de testare sau din exterior.
Abordarea regression - averse include reutilizarea materialele de testare existent,
automatizarea vast a testelor funcionale regresive i a test suitelor standarde.
Diferite abordri pot fi combinate dac e nevoie. Deciziile de tipul cum i de ce
trebuie combinate depind de circumstanele care prevaleaz la moment n proiectul dat. De
ex. o organizaie poate utiliza ca ceva standard metodele agile (active), dar n unele situaii
structura efortului testului poate utiliza o abordare bazat pe risc pentru a se asigura c
testarea este orientat corect. Abordarea necesar se indic de standarde. De ex. acele
utilizate n motor industry indicate de MISRA, sau la discreia acelor care dezvolt
metodele i strategiile. Cnd se accept discreia se recomand considerarea contextului i
scenariului.
De aceea la definirea strategiilor ori abordrilor se respect urmtorii factori:
Riscul de euare a proiectului, de ex. costul eecului va fi foarte mare. (mediu de
strict securitate ).
Abilitatea i experiena persoanelor referitoare la tehnicile, mijloacele i metodele
propuse. Nu exist justificare de a implementa componente sofisticate, abordarea sau
strategiile technique - driven cnd unica resurs disponibil de testare snt utilizatorii de
afaceri care nu au pregtire tehnic.
Obiectivele testrii i sarcina echipei de testare, ex. dac obiectivele se axeaz doar
pe depistarea celor mai serioase defecte.
Aspectele reglementatoare, aa ca regulamentele interne i externe pentru
dezvoltarea procesului, ex. The Railway Signaling standarts care oblig un anumit nivel al
calitii testrii.
92

Natura produsului i a afacerii. De ex. diferite abordri snt necesare pentru testarea
acoperirii telefoanelor mobile i pentru testarea unei operaii bancare on-line.

Planificarea i estimarea testrii

Planificarea testrii
Planificarea testului e cea mai important activitate a liderului echipei de testare n
orice proiect. El confirm existena la nceput a unei liste cu sarcini, precum i definirea
formei i volumului efortului testului. Planificarea este utilizat n dezvoltarea i
implementarea proiectelor (uneori numit green field). Principalul document produs n
planificarea testului este deseori numit master test plan sau project test plan( planul de
testare a proiectului). Acest document definete nivelul superior al activitilor de testare
planificate. Este produs n etapa nceptoare a proiectului (ex. deschiderea) i va oferi
suficient informaie pentru a ngdui proiectului de testare de a se constitui.
Detalii despre activitile test-level snt documentate n test-level plans, de ex.
planul de testare a sistemului. Aceste documente vor conine activiti i estimri pentru
nivelul respectiv de testare.
Prile din planul de test pentru fiecare plan fundamental al testului sau planul
pentru un nivel de testare snt similare sau identice. IEEE 829, Standardele pentru
Documentarea Testelor Software, conine detalii despre coninutul planului.
Standardul IEEE 829 identific c n planul de test trebuie s existe minimum 10
secii, prezentate n Tabel.
Planificarea testului este o activitate continu care se extinde pe toat perioada de
dezvoltare a proiectului; se manifest la toate etapele ciclului de dezvoltare. Dac apar
schimbri i se manifest riscul, planul i planificarea trebuiesc perfecionate pentru a
recunoate acestea i pentru a reflecta poziia curent. Dac planul va fi blocat dup prima
renunare, aceste schimbri vor fi dirijate de procesul de schimbare a proiectului. A bloca
un document, nseamn a-l proteja de schimbarea de mai departe, n afar de cea
autorizat de procesul de control al schimbrilor ( a change control process)
Tabelul 1.Compatimentele test planului
Nr.
Denumirea
Detalii
compart.
1
Identificatorul planului O identificare unic a referinei de ex. Doc ref
de test
XYZ v2.
2
Introducere
O
scurt
introducere
a
documentelor
i
proiectului pentru care au fost create.
3
(Elementele) Itemii
Itemul testului este itemul software care reprezint
testului
obiectul testrii.
Itemul tehnologiilor soft este unul sau mai muli itemi
din codul surs, codul obiectului, job control cod sau
control data. Acest compartiment conine orice
referin documentar., ex. documentele de design.
4
Particularitile
care O particularitate este o caracteristic distinctiv a
trebuie testate
softului (performan, portabilitate, funcionalitate).
Identific toate particularitile softului i combinaiile
trsturilor din specificaia design-ului testului.
93

5
6

7
8

10
11
12
13
14
15
16

Particularitile
netestabile

Identific toate trsturile i combinaiile softului i

menioneaz motivul pentru care nu au fost incluse n
testare.
Abordarea
Detalii despre abordarea desfurrii testrii; aceasta
poate include definirea unui proces detaliat sau se
poate referi la alte documente unde detaliile sunt
documentate, ex. strategia testrii.
Item pass/ fail criteria
Utilizate pentru a determina dac itemul softului a
trecut sau a euat testul.
Suspendare i reluarea Suspendarea cerinelor definete criteriile de ncetare
cerinelor
a unei pri sau toat activitatea de testare. Reluarea
cerinelor specific cerinele pentru rezumarea
testrii.
Test deliverables
Documentele n baza crora a fost realizat testarea,
ex . de la IEEE 829 documente ca:
* Planul de testare (pentru fiecare nivel)
* Specificaiile testului (design, caz i procedur)
* raportul sumar al testului
Sarcinile testrii
Orice sarcin pentru planificare i testare, inclusiv
dependenele dintre sarcini.
Mediul necesar
Definirea tuturor cerinelor ce in de mediu ca
hardware, software, PC, desks, stationery, etc.
Responsabilitile
Identific rolurile i sarcinile din proiect i cine va fi
responsabil de ndeplinirea lor.
Administrarea i
Identific orice cerin administrativ i orice abilitate
necesitatea instruirii
specific pentru instruire , ex. automatizarea.
Planificarea
Documentul despre datele livrabile i limitele
temporare.
Riscul i accidentele
Un proiect pentru cazurile de risc sporit i planul
simulrii accidentelor pentru fiecare risc.
Aprobarea
Identific toate documentele aprobate, titlurile lor,
data i semntura.

Activitile de planificare a testrii

Pe parcursul planificrii testului se fac variate activiti de ctre cei care lucreaz la
plan. Ele includ:
Unirea tuturor metodelor de abordare a testrii (numit uneori strategia testului ),
asigurarea c nivelele de testare i criteriile de intrare i ieire snt definite.
Legtura cu managerul proiectului si confirmarea c activitile testului au fost
incluse n ciclul de dezvoltare a softului, ca:
* designul - dezvoltarea design-ului softului;
* dezvoltarea - construirea codului;
* implementarea - activitile implementrii n mediul real.
Lucrnd cu proiectul se iau decizii n privina a ce trebuie testat, ce roluri snt
implicate si cine va ndeplini activitile testului, se planific cnd i cum se vor realiza
activitile testului, se decide cum vor fi evaluate rezultatele testrii, i s determini
momentul pentru ncetarea testrii (exit criteria).
94

Gsirea i alocarea resurselor pentru diferite sarcini definite.

Determinarea documentaiei pentru proiect, de ex. planurile, cum vor fi documentate
cazurile de test etc.
Definirea informaiei manageriale, care include metricile necesare i reglarea
procesului de monitorizare i control al pregtirii testului i executrii, rezolvarea
defectelor i a problemelor de risc.
Asigurarea c documentarea testului genereaz repetarea testului de verificare, ex.
test cases.

Exit criteria
Exit criteria snt utilizate pentru a determina momentul de definitivare a activitii
de testare sau cnd ar trebui s nceteze. Ele pot fi definite pentru toate activitile testului,
ca planificarea, specificarea i executarea ca un tot ntreg, sau la un anumit nivel al testului
pentru specificarea testului precum i executarea.
Exit criteria trebuiesc incluse n planurile relevante ale testului. Iat unele criterii
tipice de ieire:
Toate testele prevzute au fost realizate.
ndeplinirea unui anumit nivel de acopere a cerinelor.
Nu au fost ignorate prioritile i defectele.
Orice arie de risc a fost completamente testat, fr a lsa mcar un risc ct de
nesemnificativ.
Costul - cnd bugetul a fost epuizat.
Cele prevzute de plan au fost realizate, ex. data realizrii a fost respectat i
produsul poate fi livrat. Acesta este cazul millennium testing (ea trebuia definitivat
nainte de miezul nopii de 31 decembrie 1999), sau e legat de legislaia guvernamental.
Exit criteria trebuiesc acceptate ct de devreme posibil n ciclul de dezvoltare.
Totui ele pot fi i deseori supuse schimbrilor de control, astfel detaliile proiectului devin
mai bine nelese i deci abilitatea de a ndeplini criteriile este mai bine perceput de cei
responsabili de distribuire.

Estimarea testrii
Programa descrie 2 abordri de estimare a testului, metrics-based (bazat pe
metric) i expert-based (bazat pe experi). Aceste 2 abordri se deosebesc radical, prima
este bazat pe date, iar cealalt este o abordare puin cam subiectiv.
Abordarea metrics - based
Aceast abordare se manifest n baza datelor adunate dintr-un proiect anterior
similar.
Datele de tipul respectiv includ:
Numrul condiiilor testului.
Numrul test cazurilor scrise.
Numrul test cazurilor executate.
Timpul necesar pentru a dezvolta test cazurile.
Timpul necesar pentru rularea test cazurilor.
Numrul defectelor depistate.
Numrul ntreruperilor mediului i durata aproximativ a fiecreia.
95

Datele i abordarea respectiv favorizeaz estimarea aproape exact a timpului i a

bugetului unui proiect similar.
Este important ca actualul cost i timp s fie corect nregistrat. Acestea pot fi
utilizate apoi pentru a revalida i probabil pentru a actualiza metricile care se vor folosi la
urmtorul proiect similar.
Abordarea expert based
Aceast abordare alternativ a metricilor rezid n utilizarea experienei posesorilor
sarcinilor de acest tip sau a experilor n derivarea unei estimri (fenomen cunoscut ca
metoda Wide Band Delphi ). n acest context experi se consider:

Experii n business.

Consultanii procesului de testare.

Dezvolttorii.

Arhitecii tehnici.

Analitii i designerii.

Oricine care posed cunotine despre aplicaia care urmeaz a fi testat sau
sarcinile implicate n proces.
Exist mai multe modaliti de utilizare a acestora.
Iat 2 exemple:

A repartiza specificaiile cerinelor responsabililor pentru estimarea sarcinilor

lor independente. Combinarea estimrilor individuale; modelarea mprejurrile cerute
pentru a ajunge la cele estimate.

Distribuirea experilor cunoscui care i dezvolt viziunile sale individuale

despre estimrile generale i apoi s se ntruneasc s accepte /sau s dezbat estimarea
care va fi acceptat.
Estimrile experilor pot utiliza, separat sau combinat, ambele abordri, potrivindule adecvat. Muli factori influeneaz nivelul efortului necesar pentru ndeplinirea
cerinelor testului respectiv. Acetia pot fi mprii n mai multe categorii, cum e
demonstrat mai jos.
Caracteristicile produsului:
* Dimensiunea bazei testului;
* Complexitatea produsului final;
* Cantitatea cerinelor non funcionale;
* Securitatea cerinelor ( probabil respectarea BS 7799, securitatea standardelor);
* Documentaia necesar (unele legislaii schimb cererea unui anumit nivel al
documentaiei care poate fi mai mare dect va produce organizaia);
* Accesibilitatea i calitatea bazei testului (cerinele i specificaiile).
Caracteristicile procesului de dezvoltare:
* Scara timpului;
* Bugetul accesibil;
* Abilitile celor implicai n testare i dezvoltare (cu ct mai mic este nivelul
abilitilor, cu att mai multe indicaii conine documentaia testului);
* Mijloacele (instrumentele) utilizate n timpul ciclului de dezvoltare (ex., numrul
de teste automate va influena efortul cerut).
Rezultatele scontate ale testrii precum:
* Numrul erorilor;
96

* Numrul test cazurilor scrise.

innd cont de acestea, odat ce estimarea este dezvoltat i acceptat, liderul
testului se poate concentra asupra identificrii resurselor cerute i constituirii detaliate a
planului.

Monitorizarea i controlul progresului testului

Monitorizarea
Avnd planul testului, activitile i scara timpului determinate, acestea trebuie
revizuite n permanen conform realitii actuale. Aciunea reprezint monitorizarea
progresului testului. Scopul acesteia rezid n asigurarea feedback-ului i transparena
progresului n activitile testului.
Datele cerute pentru monitorizarea progresului pot fi colectate manual, ex.
numrarea la fiecare sfrit de zi a testului cazuri dezvoltate cu ajutorul unor instrumente
sofisticate de managementul ale testului. De asemenea e posibil adunarea datelor
automatizat cu ajutorul utilitarelor de - abia organizate ntr-un raport, sau ca un data file
care poate fi utilizat pentru a prezenta imaginea progresului.
Datele progresului snt utilizate pentru a msura exit criteria ca o acoperire a
testului, ex. realizarea a 50% din cerine.
Metricile generale ale testului includ:

Procentajul muncii efectuate la pregtirea test case-urilor (ex. sau procentajul

testelor cazuri plnuite i efectuate)

Executarea test case-urilor (numrul test case-urilor desfurate /

nedesfurate, test case-urilor reuite / nereuite)

Informaia despre defecte (densitatea defectelor, defectele depistate i

rezolvate, rata eecurilor i rezultatele retestate).

Proporia de realizare a cerinelor, riscurilor i a codului.

ncrederea subiectiv a testatorilor n produs.

Datele ale test milestones ( de difereniere, de demarcaie)

Costurile testrii, care includ costul comparat cu beneficiile determinrii

urmtorului defect sau desfurarea urmtorului test.
n final metricile testului snt utilizate pentru a mpinge progresul la definitizarea
testrii , aciune determinat de exit criteria. Deci metricile testului trebuie s se
relaioneze direct cu exit criteria.
Exist o orientare spre tabloul de bord care reflect toate metricile ntr-un singur
screen sau pagin, asigurnd o influen maxim. Pentru un tabloul de bord, i n general
la prezentarea metricilor e recomandabil utilizarea unui subset relativ mic de variate
opiuni metrice accesibile ( cu o influen pozitiv ).Deoarece cititorii nu vor s nainteze
prin mulimea de date pentru itemii cheie ai informaiei pe care o determin, a crei moto
este ( Ne propunem scopul s terminm la punct?)
Metricile snt repartizate de obicei ntr-o form grafic, ex. n figura 5.3 .Aceasta
reflect progresul testelor cazuri desfurate i raportarea defectelor depistate. Exist un
compartiment n partea stng de sus pentru unele comentarii scrise referitoare la
progresul care trebuie documentat (acestea pot fi problemele i / sau succesele referitoare
la perioadele anterioare). Graficul din fig. 5.4 e unul prezentat n partea de jos, n stnga
tabloului de bord n fig. 5.3.El raporteaz numrul incidentelor aprute, precum i numrul
accidentelor prevzute i a celor actuale.
97

Raportul referitor la test

Este un proces care demonstreaz cum influeneaz metricile testului sumarizate
viziunea cititorilor privitor la sarcinile testului. Informaia poate include:

Ce s-a ntmplat n timpul unei perioade de timp date, ex. o sptmn,

nivelul testului sau ntregul efort al testului, ori cnd s-a format criteriul de ieire.

Informaia analizat i metricile necesare pentru a respecta recomandrile i

deciziile despre aciunile viitoare ca:
* Verificarea defectului rmas
* Beneficiul economic al testrii n continuare, ex. testele adiionale snt mai
costisitoare dect beneficiile de pe urma aplicrii;
* riscurile rezistente (nerezolvate)
* gradul de ncredere a softului testat , ex. defectele prevzute vs. defectelor actuale
depistate:
Standartul 829 include un plan de realizare a unui test summary report care poate fi
utilizat la raportarea testului.
Nr. Titlul
Detalii
1
Identificatorul test sumary Identificatorul specific atribuit acestui document,
report
TSR XYX v1
2
Sumar
Identific itemii testai (includ orice traducere a
numerelor). Documenteaz mprejurrile n care
s-a realizat raportul despre activitatea testului.
Referirea la documentaia testrii pentru fiecare
test item ex. test plan, testelor cazuri sau raportul
defectelor testului.
3
Variaiile
Raportarea abaterilor de la metodele testului sau
strategiilor planul testului, testelor cazuri i
raportul defectelor testului.
4
Verificarea comprehensivitii Msoar actualul progres conform exit criteria i
explic cauza apariiei unor deosebiri.
5

Rezultatele concise

Realizeaz o generalizare a rezultatelor activitilor

testului. Include detaliile despre defectele aprute
i rezolvate, precum i acele rmase nerezolvate.

Evaluarea

Evalueaz calitatea fiecrui element al testului,

include prevederile despre riscul eecului la
testarea acestor elemente. Bazat pe metricile
testului sau test itemi pass/ fail criteria.

Sumarul aciunilor

8.

Aprobrile

Sumarul activitii testului i a evenimentelor ca

inaccesibilitatea mediului de testare, succesul i
insuccesele procesului de specificare a testului. Ar
trebui s includ datele despre utilizarea resurselor,
ex. cheltuielile prevzute i curente.
Identific toate aprobrile documentului.
98

Informaia adunat poate fi utilizat ca un suport pentru oricare oportunitate de

mbuntire a procesului. Aceast informaie se ntrebuineaz dac:

Obiectivele pentru testare snt corect stabilite (dac snt realizabile, dac nu
de ce?)

Abordrile testrii sau strategiile au fost adecvate ( ex. au asigurat c s-a

realizat suficient acoperire?)

Testarea a fost efectiv pentru a asigura c obiectivele testrii s fie realizate.

Control testrii
Ne-am referit mai sus la adunarea i raportarea datelor progresului testrii. Controlul
testrii realizeaz aceast informaie pentru a alege o desfurare a aciunilor care ar
asigura c, controlul activitilor testului se menine i c exit criteria s-au ndeplinit.
n special se face necesar cnd activitile testului snt prevzute naintea planului.
Aciunile efectuate pot influena orice activitate a testului i afecta alte activiti ale
ciclului de existen a softului
Exemple de activiti ale test-control:

Reacordarea prioritilor n cazul riscului identificat ( ex. softul distribuit

mai trziu).

Schimbarea planului (orarului) datorit accesibilitii mprejurrilor testului.

Stabilirea unui criteriu de intrare care cere retestarea de ctre un dezvolttor a

ameliorrilor nainte de a fi acceptate ntr-o structur (e deosebit de binevenit aciunea
cnd defectele rectificate eueaz din nou la retestare).

Revizuirea riscurilor produsului i probabil schimbarea ratei riscului pentru a

ndeplini scopul.

Adaptarea scopului testrii (probabil numrul testelor de desfurat) pentru a

conduce testrile ultimelor schimbri solicitate.
Urmtoarele activiti ale test-controlului snt n afara responsabilitilor liderului
de test. Totui, aceasta nu-l mpiedic s prezinte recomandri managerului proiectului.

Descoping funcionalitii, ex. schimbarea unor deliverabile mai puin

importante pentru reducerea timpului i efortului necesar pentru a obine o soluie.

Reinerea livrrii n mediul de producere pn la ndeplinirea exit criteria.

Continuarea testrii dup livrarea n mediul de producie pentru a depista

defectele de producie nainte de a fi depistate de utilizatorii finali.

Managementul incidentului
Un incident este un eveniment neplanificat care impune investigarea n continuare.
n activitatea testrii aceasta se transform n ceva unde rezultatul actual se deosebete de
cel scontat.
Incidente se isc la orice etap a ciclului de dezvoltare a software, de la revizuirea
bazelor testului (cerinele, specificaii) la specificarea i executarea testului.
Managementul incidentelor, conform IEEE 1044 ( Standardele de Clasificare ale
Anomaliilor Software) este procesul de recunoatere, investigaie, aciunile ntreprinse i
aranjarea (nlturarea) incidentelor. Aceasta presupune nregistrarea incidentelor,
clasificarea i identificarea impactului. Procesul de dirijare a incidentului asigur c
incidentele snt deplasate de la recunoatere la rectificare, i n final prin retestare la
99

nchidere (definitivare). Este semnificativ c organizaiile documenteaz incidentele din

procesul de management i asigur c ele au fost indicate cuiva (managerului
incidentelor/coordonatorului).
Incidentele apar n raportul incidentelor, astfel i pe cale electronic n sistemul de
management al incidentelor (de la Microsoft Excel la mijloace mai sofisticate de
management al incidentelor) sau pe hrtie. Rapoartele incidentelor au urmtoarele
obiective:

A asigura dezvolttorilor i altor pri feedback-ul referitor la o problem

pentru a nlesni identificarea, izolarea i rectificarea dup cum e necesar. Menionm c
muli dezvolttori i alte pri care vor corecta defectul sau vor clarifica orice confuzie nu
vor fi prezeni la orice moment al identificrii, deci fr o informare complet i concis
nu vor nelege problema, sau va mpiedica nelegerea modalitii de nlturare a acesteia.
Cu ct mai mult informaie cu att mai bine.
A asigura liderii testului cu mijloace de mbuntire a calitii sistemului de testat i
a progresului tastrii. Una din metricile eseniale utilizat pentru msurarea progresului
este viziunea despre numrul incidentelor aprute, prioritile sale i n sfrit c ele au
fost rectificate i anulate (corectate) .

A furniz idei pentru mbuntirea procesului testului. Pentru fiecare

incident trebuie documentat momentul (locul) injeciei, ex. efectele n cerine sau cod i o
mbuntire consecutiv se poate concentra pe o anumit arie pentru a stopa manifestarea
aceluiai defect.
Detaliile care se includ ntr-un raport al incidentelor:

Data problemei, organizaia care are problema, autorul, aprobrile i

statuturile.

Scopul, severitatea i prioritatea incidentului.

Referinele, care includ identitatea specificaiilor testelor cazuri i contribuie

la dezvluirea problemei.

Rezultatele scontate i cele actuale.

Data descoperirii incidentelor .

Elementul de identificare i configurare a software sau a sistemului.

Software sau procesul de dezvoltare a sistemului n care a fost depistat

incidentul.

Descrierea anomaliei pentru a favoriza corectarea.

Gradul impactului asupra interesului beneficiarilor.

Severitatea impactului asupra sistemului.

Caracterul urgent /prioritatea fixrii.

Statutul incidentului (deschis, ncetinit, duplicat, ateptarea (pregtirea) de a fi

fixat, fixat n ateptarea testului de confirmare, nchis) .

Concluziile i recomandrile.

Problemele globale, ca ariile care pot fi afectate de schimbrile rezultate din

incidente.

Schimbarea istoriei, ca de exemplu schimbarea ordinii aciunilor adoptate de

membrii echipei proiectului n privina izolrii incidentului, repararea i confirmarea
fixrii lui.
100