Sunteți pe pagina 1din 21

PLANIFICAREA TESTRII

Planificarea testrii implic rspunsul la ntrebrile cine, ce, i cnd testeaz. La nivel tehnic
planificarea foloseste abloane instaniate de dezvoltatori dup necesiti. Vom descrie n
continuare o ierarhie de planuri de testare, n relaie cu abloanele standard de test (planul de
test standard de la IEEE).

Ne vom referi la un proces de testare de baz, ghidat de criteriul Testeaz devreme, testeaz
des, testeaz suficient, i vom considera un pas de testare pentru fiecare pas de dezvoltare:
1. Analizeaz. Testeaz.
2. Proiecteaz. Testeaz.
3. Implementeaz. Testeaz.

Vom descrie un set generic de pai, n care definim sarcinile de baz de la fiecare pas de
dezvoltare, privind testarea i din perspectiva management/ alocare de resurse.

Procesul de dezvoltare: vedere de ansamblu


Un proces este o serie continu de activiti pentru realizarea unui scop. n cazul nostru
procesul are urmtorii pai:

1. Analiza nelegerea problemei i definirea cerinelor software


 Analiza domeniului: nelegerea problemei ntr-un context mai general
 Analiza aplicaiei: nelegerea problemei specifice pentru care trebuie
construit proiectul

2. Design (proiectare) rezolvarea problemei prin software


 Design arhitectural
 Design-ul subsistemelor i package-urilor
 Design-ul claselor
 Design-ul algoritmilor

3. Implementare traducerea proiectului n cod executabil


 Implementarea claselor
 Integrarea

4. Testare asigurarea c intrrile programului vor produce ieirile specificate de cerine


 Testarea unitilor de baz
 Testarea unitilor integrate
 Testarea subsistemelor
 Testarea sistemelor

Vom lucra cu un model incremental de proces. Dezvoltarea incremental presupune faptul ca


sistemul este dezvoltat ca o secven de incremente, unde prin increment nelegem un produs
finit (model+documentare+cod), pentru o parte din funcionalitile cerute de la sistem.
Produsele dezvoltate ntr-un increment sunt folosite de urmtorul increment, care adaug (i
uneori schimb) funcionaliti noi, incrementul final fiind sistemul ce satisface toate
cerinele. Pentru fiecare increment se trece prin etapele analiz- design- implementare- testare.

Procesul va fi nu doar incremental, ci i iterativ: pentru fiecare increment pot exista mai multe
iteraii, care s soluioneze erorile/ lipsurile depistate la testare.
Figura . Proces de dezvoltare incremental, iterativ, secvenial

Dezvoltarea orientat pe obiecte este, n particular, adecvat dezvoltrii evolutive, ntruct


analiza, design-ul i implementarea orientate obiect implic rafinarea succesiv a aceluiai
model. Astfel, produsele unui increment sunt extinse i rafinate n incrementul urmtor (ceea
ce rmne valabil i pentru cazurile de testare, deoarece dezvoltarea incremental a produselor
implic i testarea lor incremental).

Exemplu. Plan de dezvoltare incremental, iterativ pentru Crmizile (un joc)

Dezvoltarea i testarea sunt dou procese separate, dar strns interconectate. Procesele sunt
distincte, ntruct au att scopuri distincte, ct i msuri distincte ale succesului. Astfel, de ce
rata defectelor este mai mic, dezvoltarea este mai bun, i de ce rata defectelor este mai
mare, testarea este mai bun, unde prin rata defectelor nelegem numrul de cazuri de test
euate, raportat la numrul total de cazuri de test.

Am vzut n Seciunea 1.1. c scopul testrii este identificarea cderilor sistemului, nu a


erorilor care au dus la cderile respective; gsirea sursei cderilor st n sarcina
dezvoltatorilor. ntre testare i dezvoltare exist o bucl de feedback (Figura ). Rapoartele
cderilor (mulimea de simptome) sunt folosite de dezvoltator pentru a gsi eroarea care a
generat cderea.

Figura . Relaia dezvoltare-testare

n general, testerii au nevoie ca dezvoltatorii s specifice cazurile de utilizare, pre- i post-


condiiile i modelele de stare ale subsistemelor (sistemului). Cazurile de utilizare sunt
folosite n generarea de cazuri de test pentru etapa de testare a sistemului i ofer testerilor
informaii despre posibila reutilizare a testelor/ datelor. Din pre- i post condiii se pot
deriva teste de secvene (i cutarea de dependene ascunse), iar din modelele de stare ale
subsistemelor/ sistemului se obin informaii despre secvenierea aciunilor i rspunsurile
ateptate.

Rezultatele testelor nu au ntotdeauna o interpretare imediat. Proprietatea de testabilitate


msoar ct de uor pot fi evaluate rezultatele testelor, i este influenat att de forma i
claritatea specificrii cerinelor (ntruct cerinele asupra produsului sunt sursa cazurilor de
testare a sistemului i a testrii acceptrii) ct i de momentul n care testm (de ce se
suprapun mai multe straturi de program, scade vizibilitatea valorilor stocate). Arhitectura
PACT de testare (Parallel Architecture Class Testing- JUnit) mbuntete testarea prin
prentmpinarea ascunderii informaiilor. n ceea ce privete cerinele, este util ca testerii s
participe la strngerea i validarea acestora pentru a putea seta gradul de risc i testabilitatea.

Cazurile de test sunt componentele de baz ale testrii. Forma general a unui caz este o
pereche (intrare, ieire ateptat), unde intrarea/ ieirea pot fi arbitrar de complexe (nu doar
iruri sau valori numerice). Spre exemplu, deseori intrrile conin informaii despre starea
sistemului, comenzi utilizator, valori de procesat, iar ieirile pot cuprinde rapoarte printate,
sunete, modificri pe ecran, actualizarea unei baze de date sau o schimbare a sistemului ce va
afecta procesarea urmtoarelor intrri.

Cazurile de test trebuie proiectate, implementate i executate la rndul lor. Execuia unui caz
de test presupune rularea programului cu intrrile cazului de test; se compar ieirile actuale
ale rulrii cu ieirile din caz i se concluzioneaz dac programul testat pic testul sau
trece testul. Un aspect interesant al dezvoltrii cazurilor de test este cine se ocup de
verificarea cazurilor de test; acestea sunt adesea revizuite dar prea puin testate formal.

Cazurile de test se grupeaz adesea ntr-o suit de teste. O suit de teste se organizeaz dup
tipul cazurilor de test coninute. Spre exemplu, pot exista suite pentru testarea capacitilor
sistemului sau pentru testarea utilizrilor tipice ale sistemului n cadrul capacitilor
specificate. Dac programul trece toate cazurile de test din suit, se spune ca trece suita de
teste. Dezvoltarea i organizarea unei suite de teste este o provocare in cadrul testarii, aceasta
trebuind s fie corect, adecvat i s aib rezultate observabile.

Tehnica STEP de testare, propus de William Hetzel, propune o abordare n 3 pai, pentru
orice tip de testare a unui proiect: analiza, construcia i execuia i evaluarea rezultatelor.

STEP 1: Analiza. Produsul de testare este examinat pentru identificarea trsturilor


particulare ce necesit atenie special i pentru determinarea cazurilor de test ce trebuie
construite. Exist tehnici de analiz automate (instrumente de testare a ramificaiilor) i
manuale, n care testerul decide ce testeaz (majoritatea).

STEP 2: Construcia. n cadrul acestui pas se creeaz artefactele necesare testrii: cazurile
de test sunt traduse n limbaje de programare/ scripting/ tool special i se colecteaz mulimile
de date (suficient de mari pentru a fi relevante).

STEP 3: Execuia i evaluarea. Aceasta este partea cea mai vizibil i mai scurt a efortului
de testare, n cadrul creia se execut cazurile de test construite la pasul 2 i se examineaz
rezultatele pentru a vedea dac programul a trecut sau a picat suita de teste. Multe activiti
ale acestui pas pot fi automatizate, pasul fiind util mai ales ntr-un mediu iterativ unde
aceleai teste se vor aplica repetat.

Analiza riscului ca instrument de testare


Analiza riscului este o parte a planificrii oricrui efort de dezvoltare, fiind util n a
determina ce s testm i ct de mult. Prin risc vom nelege orice amenin atingerea cu
succes a scopului proiectului: un eveniment cu o oarecare probabilitate de apariie, care duce
la anumite pierderi dac apare. n ierarhizarea riscurilor se ine cont de probabilitatea de
apariie i de gravitatea/ impactul pierderilor produse.

Testarea pe baz de riscuri presupune s testm mai aprofundat acele pari ale sistemului
care ascund cel mai mare risc pentru a identifica erorile cele mai nocive. Riscurile pot fi de
proiect, de business i tehnice. Riscurile de proiect presupun riscuri manageriale sau de mediu
ce nu pot fi afectate de procesul de testare (spre exemplu, insuficient personal calificat).
Riscurile de business sunt asociate cu noiunile legate de domeniu: atunci cnd domeniul
modelat este volatil, suita de teste a sistemului trebuie s verifice extensibilitatea i
modificabilitatea atributelor sistemului. Spre exemplu, modificarea regulilor de raportare
fiscal reprezinta un risc pentru stabilitatea unui sistem contabil. Acest tip de riscuri este
asociat cu funcionalitatea programului, deci cu testarea la nivel de sistem. Riscurile tehnice
includ unele concepte de implementare, fiind asociate cu testarea codului. Spre exemplu,
limbajul de programare poate fi o surs de risc pentru stabilitatea codului generat de
compilator, sau poate fi vorba de riscurile asociate stabilitatii componentelor software. De
obicei, testarea pe baz de riscuri este folosit cnd riscurile sunt foarte mari (implic pierderi
materiale substaniale sau chiar pierderi de viei omeneti).

Analiza riscului este o procedur de identificare a riscurilor i a modurilor de prevenire a


potenialelor probleme. Ieirea analizei riscului este lista de riscuri ierarhizate, folosit n
alocarea resurselor i prioritizarea deciziilor. Tehnica de analiz a riscului include 3 sarcini:

1. Identificarea riscului (riscurilor) adus de fiecare caz de utilizare pentru proiect

2. Cuantificarea riscului (riscurilor)

3. Crearea unei liste ierarhizate de cazuri de utilizare

Cazurile de utilizare cu risc ridicat sunt cele asociate cu cerinele volatile, cu cerinele aflate
n afara domeniului de expertiz a echipei de dezvoltare sau cu cerinele care necesit
tehnologii noi (spre exemplu, hardware dezvoltat n paralel cu software).

Gradele de risc cu care se lucreaza pot fi, pentru nceput, cobort, mediu, ridicat. Lista de
cazuri de utilizare ordonat n funcie de risc este folosit de manageri pentru a asigna cazurile
de utilizare incrementelor, i pentru a determina necesarul de testare pentru fiecare item.

Cazurile de test se pot selecta att pe baz de criticalitate ct i pe baza profilului de utilizare
(frecvena de utilizare a funcionalitii). Cele dou criterii se pot combina n obinerea unui
indice complex de risc (Figura 1 i Figura 2).

Exemplu: Brickles
 Cele mai mari riscuri: aspecte ce afecteaz mulumirea juctorului : ctigarea unui
joc- mai critic dect pierderea jocului
 Frecvena de apariie: Deoarece ctigarea i pierderea sunt realizate prin acelai
cod, sunt asignate acelai risc
 Se combin frecvena i criticalitatea cele dou cazuri de utilizare sunt considerate
de risc mediu (Figura 1)
 Deci programul trebuie testat cu acelai numr de rezultate ctigtoare ct i de
pierderi

Figura 1. Cazuri de utilizare pentru un joc de tip arcade

Figura 2 . Cazuri de utilizare pentru un sistem de management a personalului

Planificarea testrii
n practica obinuit, se ncepe cu testarea modulelor individuale, se continu cu testarea
integrrii subsistemelor (cnd sunt asamblate din module i alte susbsisteme) i n final se
ajunge la testarea sistemului. ntr-un proces iterativ i incremental testarea sistemului se face
dup fiecare increment, iar testarea claselor i a interaciunilor dup fiecare iteraie a unui
increment. n abordarea curent, putem ncepe testarea naintea scrierii de cod (testarea
modelelor de analiz i design, Seciunea...). Testarea modelelor de analiz i design asigur
validitatea sistemului (ofer o asigurare c sistemul este specificat corect).

Exist 5 dimensiuni ale testrii:


1. Cine testeaz?
2. Ce pri vor fi testate?
3. Cnd se va face testarea?
4. Cum se va face testarea?
5. Ct este suficient s testm?
1. Cine testeaz?
Activitile de generare a produsului sunt testate de catre dezvoltator, n cadrul etapelor de
analiz, design, programare, depanare i documentare. Se poate folosi schema testarea
colegului. Testerul deine activiti de detectare a cderilor unui produs i selecteaz testele
specifice unui scop, construiete testele, execut testele i evalueaz rezultatele. Testarea
sistemului se face de obicei de ctre testeri independeni. Atunci cnd riscurile sunt foarte
mari (life critical) fiecare unitate este testat de un tester independent.

Figura .

2. Ce testm?
Se poate merge de la testarea fiecrei clase n parte pn la a nu testa nimic, cderile fiind
descoperite prin: operarea aleatoare a sistemului, copii de evaluare pe web, sau rapoarte de
erori de la useri. Calea de mijloc ar fi selectarea statistic a componentelor de testat. Clasele
reutilizate din alte proiecte/ din librrii de clase nu sunt, de obicei, testate. n plus, unele clase
sunt dificil de testat individual, ntruct necesit drivere complexe pentru furnizare intrri/
examinare ieiri i trebuie asigurat un echilibru ntre beneficiul testrii (defecte depistate pe
or de efort) i efortul necesar construirii infrastructurii de testare. Alegerea cazurilor de test
ar trebui s in cont de utilizrile probabile ale sistemului, dar i de cazurile patologice de
utilizare.

Figura .

3. Cnd testm?
Testarea se poate desfura pe parcursul dezvoltrii componentelor sau dup integrarea ntr-
un singur executabil. Desigur, de ce testm mai trziu, de ce va fi mai costisitor s facem
modificri pe baza rezultatelor testelor. Testarea sistemului / a acceptrii (doar la sfrit) este
utila cnd sunt doar civa dezvoltatori lucrnd pe un set clar de cerine. La polul opus se afl
testarea zilnic. O alternativ rezonabil este testarea fiecrei componente pe msur ce se
realizeaz, abordare ce ncetinete dezvoltarea, dar compenseaz prin reducerea problemelor
mai trziu (la momentul asamblarii componentelor).

ntr-un proces incremental se practic testarea la sfritul fiecrui increment (cu componentele
asamblate). Aceasta poate fi dezavantajoas dac e vorba de o funcionalitate att de
complex nct e greu de verificat dup asamblarea componentelor, dar e util pentru
componente care necesit drivere de testare dificil de implementat.
Figura .

4. Cum testm?
Testarea se poate face pe baza specificaiei sau pe baza implementrii. Specificaia cuprinde
perechile (intrri ieiri corecte) definind ce face programul, iar implementarea cuprinde
algoritmul de producere a ieirilor corecte (conforme cu specificaia) i rspunde la ntrebarea
cum i realizeaz programul specificaia. Specificaiile claselor, subsistemelor i sistemului
sunt necesare n generarea cazurilor de test. Acoperirea specificaiei prin cazuri de test ne va
garanta c programul face ce trebuie, iar acoperirea implementrii va garanta c programul nu
face nimic din ce nu trebuie s fac. Pentru componentele cu risc ridicat este necesar testarea
pe baza implementrii (verificarea fiecrei linii de cod).

Testarea interaciunilor ntre componente se face n cadrul testrii integrrii i trebuie s


verifice posibilele erori de interfa i corectitudinea polimorfismului. Cazurile de test pentru
interaciuni se aleg prin metode speciale (vezi Seciunea...) pentru a limita numrul de cazuri
folosite.

Adecvarea cazurilor de test


ntruct testarea complet este imposibil practic, exist diferite standarde de adecvare a
suitelor de testare. Sunt necesare, desigur, cazuri de test pentru situaiile critice (viei
omeneti), dar i pentru utilizrile uzuale. Adecvarea presupune c s-a testat suficient pentru a
fi rezonabil de sigur c programul va lucra aa cum utilizatorii se ateapt .

Adecvarea se msoar prin acoperire. Acoperirea ar trebui msurat n primul rnd n funcie
de cerine (cte cerine din specificaie sunt testate verific ce face programul), dar i n
funcie de implementare (ct din program a fost rulat la executarea unui test testeaz cum
face programul ceea ce face). Dac o poriune de cod nu a fost executat trebuie vazut ce
cazuri de test lipsesc sau dac nu cumva programul implementeaz o funcionalitate
nespecificat. Testarea pe baz de specificaie se numete i testare funcional (tip cutie
neagr), i avantajul su este c se pot dezvolta cazuri de test nainte de scrierea codului.
Testarea pe baza de implementare se numete i testare structural (tip cutie alb), testele se
construiesc pe baza implementrii i ieirile cazului de test se determin pe baza specificaiei,
iar intrrile- din analiza codului (fiind vzute drept acele valori ce au dus la anumite ci de
execuie n sistem). Avantajul acestui tip de testare este acoperirea mbuntit. Exist trei
metrici de testare folosite preponderent: acoperirea codului, acoperirea postcondiiilor i
acoperirea elementelor modelului.

Figura .
5. Ct testm?
Ct testm nseamn ct de aprofundat testm o pies aleas pentru testare (a nu se
confunda cu ce (piese) testm). Aspectele de luat n vedere aici sunt durata de via
ateptat a programului i criticalitatea sa. Este adecvat s testm atat timp ct costurile de
testare sunt acoperite de costurile descoperirii de erori. Rspunsul la aceast ntrebare este dat
de standarde specifice domeniului (spre exemplu, n producerea de medicamente sunt
standarde diferite fa de producerea de mobil).

Figura .

Pot exista mai multe roluri n procesul de testare: tester-ul de clase, tester-ul de integrare,
tester-ul de sistem, manager-ul de testare. Tester-ul de clase se ocupa de testarea claselor
individuale pe msur ce sunt scrise (de obicei este facut de dezvoltatori). Tester-ul de
integrare realizeaz testarea unor obiecte ce provin din surse de dezvoltare diferite. Acesta
trebuie s testeze suficiente functionaliti pentru a fi sigur c obiectele funcioneaz bine
mpreun i rolul su este important ntr-un proiect ce folosete framework-uri mari i nc
imature, necesitnd abiliti de testare dar i de dezvoltare.

Tester-ul de sistem trebuie s dein cunotine asupra domeniului aplicaiei, ntruct rolul su
este de a verifica, independent, dac aplicaia complet este conform cerinelor. Tester-ul de
sistem reprezint perspectiva utilizatorului asupra proiectului. n fine, managerul de testare
conduce procesul de testare: acesta solicit, coordoneaz i utilizeaz resursele alocate testrii,
conducnd testerii dar i dezvoltatorii. Este bine ca testerii s participe la modelarea cazurilor
de utilizare i s nceap construirea cazurilor de test nca din timpul definirii cerinelor.

Mulimea detaliat a activitilor de testare


Vom face n continuare un rezumat al activitilor de testare pentru fiecare faz a procesului
de dezvoltare

Analiza domeniului
Produs Componente (Sub)sisteme

Pe baz de model Pe baz de Pe baz de model Pe baz de


implementare implementare

Verific dac se pot Verific dac toate


crea obiecte de tipul obiectele necesare
Modelul de clase al claselor din model, pentru definirea
domeniului i dac se pot stabili subsistemelor sunt
relaiile ntre clase disponibile i
corecte

Modelul dinamic al
Verific dac Verific dac
domeniului
obiectul poate subsistemul poate
ajunge n toate ajunge n toate
strile sale, i dac strile sale, i dac
precondiiile sunt precondiiile sunt
verificabile verificabile

Verific dac un Verificarea


utilizator expert nu consistenei
poate gsi cazuri mulimii cazurilor
Specificarea
nespecificate de de utilizare;
cerinelor
model verificarea
domeniului- exp.
completitudinii
cazurile de utilizare
acestei mulimi cu
ajutorul unui
utilizator expert

Analiza aplicaiei
Produs Componente (Sub)sisteme

Pe baz de model Pe baz de Pe baz de model Pe baz de


implementare implementare

Verific dac se pot Verific dac toate


crea obiecte de tipul obiectele necesare
Modelul de clase al claselor din model, pentru definirea
aplicaiei i dac se pot stabili subsistemelor sunt
relaiile ntre clase disponibile i
corecte

Verific dac Verific dac


obiectul poate subsistemul poate
Modelul dinamic al ajunge n toate ajunge n toate
aplicaiei strile sale, i dac strile sale, i dac
precondiiile sunt precondiiile sunt
verificabile verificabile

Verific dac un Verificarea


utilizator expert nu consistenei
poate gsi cazuri mulimii cazurilor
Specificarea
nespecificate de de utilizare;
cerinelor aplicaiei-
model verificarea
exp. cazurile de
completitudinii
utilizare
acestei mulimi cu
ajutorul unui
utilizator expert
Proiectarea arhitecturii
Produs Componente (Sub)sisteme

Pe baz de model Pe baz de Pe baz de model Pe baz de


implementare implementare

Verific dac se pot


crea obiecte de tipul
noilor clase din
model, i dac se
pot stabili relaiile

Verific aplicarea
corect a
abloanelor de
proiectare

Verific dac toate


strile pot fi atinse,
i dac precondiiile
sunt verificabile

Verific dac fiecare


mesaj primit de o
component refer o
operaie a interfeei
componentei, i c
fiecare component
este n starea corect
pentru a primi
mesajul respectiv

Verific dac fiecare Verific dac


component are cerinele pot fi
relaiile necesare ndeplinite, pentru
pentru comunicare captarea
rezultatelor n
diagramele de
interaciune

Verific dac toate Verific dac


componentele unui subsistemul i
subsistem i-au susine
stabilit conexiunile specificaia
necesare, n interior
i n exterior
Design-ul detaliat
Produs Componente (Sub)sisteme

Pe baz de model Pe baz de Pe baz de model Pe baz de


implementare implementare

Verific Verific
independent de independent de
aplicaie aplicaie

Verific structura
raportat la
arhitectur

Verific operaiile
raportate la
diagramele de
interaciune

Verificarea
consistenei
mulimii cazurilor
de utilizare;
verificarea
completitudinii
acestei mulimi cu
ajutorul unui
utilizator expert

Implementarea claselor
Produs Componente (Sub)sisteme

Pe baz de model Pe baz de Pe baz de model Pe baz de


implementare implementare

Verific Verific
implementarea interaciunile
raportat la ntre clase
specificaia folosind
Clasele complete
clasei cazuri de test
bazate pe
relaiile din
diagrama de
clase
Implementarea aplicaiei
Produs Componente (Sub)sisteme

Pe baz de model Pe baz de Pe baz de model Pe baz de


implementare implementare

Verific
implementarea
folosind
Aplicaia complet cazuri de test
dezvoltate din
cazurile de
utilizare

Figura . Tabelul activitilor de testare (t1.doc)

Dac folosim clase auxiliare n testare, putem determina din tabel costul producerii unei clase.
Astfel, pentru testare:
 Construiete o clas PACT pentru fiecare clas a aplicaiei ce va fi testat izolat
(PACT: Parallel Architecture for Component Testing/ Arhitectura Paralel de
Testare a Componentelor)
 Construiete o clas PAST pentru fiecare caz de utilizare (PAST: Parallel
Architecture for System Testing/ Arhitectura Paralel de Testare a Sistemului)
 Estimeaz numrul de clase necesar pentru infrastructur

Exemplu. Proces de testare pentru Brickles

1. Cine testeaz?
 Testarea mprit de doi autori :
 S face majoritatea implementrii el va face testarea claselor i a integrrii,

 G a scris cazurile de utilizare i a construit design-ul de nivel nalt, el va crea


cazurile de test pe baza cazurilor de utilizare i le va executa pe msur ce
implementarea este disponibil

2. Ce pri se vor testa?


 Se vor testa clasele primitive, de baz

 Clasele de nivel mai nalt au foarte multe inter-relaii, aa c se vor testa ca un grup
(cluster)

 Sistemul final va fi testat ca aplicaie complet


3. Cnd vom testa?
 Testarea claselor: repetat, n timpul iteraiilor de dezvoltare
 Testarea grupului de clase de nivel nalt: repetat, n timpul iteraiilor dar abia la al
doilea increment (dup ce n primul increment ne-am ocupat de clasele primitive)
 Testarea sistemului- dup ce este disponibil o versiune iniial, la sfritul primului
increment

4. Cum vom testa?
 Cazurile de test vor fi construite ca metode ale unei clase
 Va exista o clas de test pentru fiecare clas de producie
 Testarea cazurilor de utilizare va fi condus de o persoan ce folosete sistemul
jucarea repetat a jocului (fr s automatizm nimic)

5. Ct testare este adecvat pentru o pies individual?


 Clasele vor fi testate astfel nct fiecare metod public s se apeleze mcar o dat

 Nu vom ncerca s testm orice combinaie posibil de valori ale parametrilor

 Cazurile de test derivate din cazurile de utilizare vor acoperi toate rezultatele finale
posibile

abloanele documentelor
Exist abloane dedicate pentru planul de testare a proiectului, planul de testare a
componentelor, planul de testare a integrrii, planul de testare a cazurilor de utilizare i planul
de testare a sistemului. Relaiile ntre aceste planuri de test sunt ilustrate n Figura .
Semnificaia sgeilor este aceea c figura spre care indic sageata este referit de figura din
care pleac sgeata.
Figura . abloanele documentelor

Planul standard de testare IEEE 829 (IEEE.doc)

1.0. Introducere
2.0. Itemii testului
3.0. Caracteristici testate
4.0. Caracteristici netestestate (pe ciclu)
5.0. Strategia i abordarea testrii
5.1. Sintaxa
5.2. Descrierea funcionalitii
5.3. Argumentele testelor
5.4. Ieiri ateptate
5.5. Excluziuni specifice
5.6. Dependene
5.7. Criterii de success/eec ale unui caz de test
6.0. Criterii de succes/ eec pentru ciclul complet de test
7.0. Criterii de intrare / criterii de ieire
8.0. Criterii de suspendare a testului i cerine pentru reluare
9.0. Mijloace de comunicare a strii testului
10.0. Sarcini de testare
11.0. Cerine hardware i software
12.0. Determinarea problemei i responsabiliti de corectare
13.0. Necesiti de training / staffing
14.0. Programarea testrii
15.0. Riscuri i neprevzut
16.0. Acceptri

Urmatorii itemi din test sunt importani n particular:

 Caracteristicile netestate pentru testarea la nivel de clas; se raporteaz rezultatele


analizei HIT (Sectiunea). Analiza HIT cuprinde trsturi ce au fost testate i
necesit re-testare, i trsturi programate pentru dezvoltare n iteraii/ incremente
urmtoare.

 Criteriile de suspendare a testului: testarea se suspend cnd numrul de erori gsite


pe or scade sub criteriul (pragul) setat n aceast seciune. Aceast seciune a
planului de testare e important n dezvoltarea iterativ: vor exista criterii diferite
pentru iteraiile timpurii fa de cele trzii.

Pentru seciunea Riscuri i contingene, se consider, n acest context, ca un risc identific


potenialele probleme n ghidarea testului: erori posibile legate de rspunsurile corecte n
mulimi mari de date i posibilitatea ca platforme diferite s duc la rezultate diferite.

Planul de testare al proiectului rezum strategia de testare folosit de proiect i trebuie s


defineasc paii procesului de dezvoltare unde va apare testarea, frecvena cu care va apare
testarea i cine este responsabil cu testarea (Figura )

Figura . Planul de testare al proiectului

Partea a doua a planului de testare a proiectului (Figura ) asociaz fiecrei faze o strategie
specific (vom descrie n seciunile urmtoare mai multe strategii de testare). Tabelul conine
i standardele proiectului pentru testare adecvat pentru fiecare nivel de risc, n cadrul
fiecruia din cele 3 faze.
Figura

Planul de testare a componentelor are drept scop definirea strategiei globale i a cazurilor de
test specifice ce vor fi folosite pentru a testa o anume component. Din criteriile proiectului se
deriveaza standarde legate de ct de aprofundat vor fi testate componentele, dar i criteriile de
acoperire (spre exemplu: 100% din postcondiiile metodelor modificator s fie testate).
Procedurile proiectului definesc detaliile pentru strategiile de testare (spre exemplu:
construirea unei clase PACT (Sectiunea... ) pentru fiecare component ce va fi testat).

ablon de plan pentru testarea componentelor


(Plan de testare a componentelor.doc)

Numele componentei:
Responsabili:
Numele dezvoltatorului:

Obiectivele clasei

Procedura proiectului: cazurile de test trebuie s testeze o component pe baza obiectivelor


sale declarate

Cerinele inspeciei dirijate

Criteriu de proiect: 100% din produsele asociate componentelor critice vor fi testate. 75% din
produsele associate componentelor necritice vor fi testate. Componentele din librrii vor fi
supuse unor teste adiionale de calitate. Bifai una dintre urmtoarele:
Component critic a aplicaiei: __
Component necritic a aplicaiei : __
Component de librrie: __

Criteriu de proiect: se folosete analiza riscului pentru a ierarhiza pri ale clasei n raport cu
testarea.

Construirea i memorarea suitelor de test

Procedura de proiect: se va aplica algoritmul HIT pentru a vedea ce cazuri de test trebuie
executate pentru component.

Procedura de proiect: Este responsabilitatea dezvoltatorului s pregteasc suitele de test n


structura cerut de proiect.

Criteriu de proiect: pentru fiecare component exist o clas driver de test ce conine cazurile
de test ale componentei.

Criteriu de proiect: pentru fiecare metod exist metode de test ce reprezint cazuri de testare
funcional, structural i de interaciuni.

Cazuri de test funcionale

Criteriu de proiect: execut cazuri de test pentru fiecare postcondiie a fiecrei metode.
Verific i invariantul clasei ca parte a fiecrui caz de utilizare.

Criteriu de proiect: execut cazuri de test pentru fiecare valoare semnificativ a fiecrui
parametru.

Cazuri de test structurale

Criteriu de proiect: execut cazuri de test pentru fiecare linie de cod a fiecrei metode.

Criteriu de analiz a riscului asupra componentei: ____________________

Cazuri de test bazate pe stri

Criteriu de proiect: execut cazuri de test ce acoper fiecare tranziie din reprezentarea de
stri.

Cazuri de test pentru interaciuni

Procedura de proiect: execut cazuri de test pentru fiecare contract ntre componente.
Folosete strategia OATS pentru selecia cazurilor de test.
n seciunea Obiectivele clasei se scrie lista prioritizat de obiective (spre exemplu,
componenta este un element al framework-ului de baz al aplicaiei, abstraciune de nivel
nalt din care se vor deriva variante mai specifice).

Cerinele inspeciei dirijate conine construirea i memorarea suitelor de test, cu informaii


despre aplicarea HIT i detalii ale utilizrii procesului PACT pentru crearea claselor drivere
de test (termenul pentru scrierea cazurilor de test, specificaia test driver-ului, numrul relativ
de cazuri de test din fiecare categorie, prioritile ntre cele 3 categorii).

Pentru cazurile de test funcionale se furnizeaza informaii despre cazurile de test dezvoltate
din specificaie, despre invariantul clasei, i despre cte tipuri diferite de obiecte se testeaz.
Tipurile se bazeaz pe starea iniial a obiectului.

Seciunea Cazuri de test structurale cuprinde cazurile de test pentru acoperirea codului,
procesul de revizuire a codului i modul de folosire a instrumentului de verificare a acoperirii
codului. Cazurile de test pe baz de stri necesita reprezentarea de stare a clasei (diagrama
de stare) iar Cazurile de test pentru interaciuni descriu ce mesaje se testeaz folosind
procesul de selecie OATS.

Planul de testare a cazurilor de utilizare e scris pentru a descrie testele de sistem ce se vor
deriva dintr-un singur caz de utilizare. Aceste planuri sunt incluse n planurile de testare a
sistemului i a integrrii. n Figurile sunt pari ale ablonului de plan, alte pri vor fi
detaliate n cursurile urmtoare.
Figura Use case 1.doc
Figura Use case 2.doc
Figura Use case 3.doc

Planul de testare a integrrii este foarte important ntr-un mediu de dezvoltare iterativ, n
care anumite funcionaliti sunt finalizate naintea altora. Cazurile de testare pentru integrare
sunt alese din cazurile de testare ale componentelor ce creeaz alte componente. Acest plan
are acelai format ca planul de testare a sistemului.

n cadrul planurilor de testare a sistemului, planurile de testare ale cazurilor de utilizare sunt
mapate n teste specifice sistemului (Figura ).

Figura .