Ghid pentru elevi

Testarea produselor program

1
Echipa de autori:

Gremalschi Anatol doctor habilitat, profesor universitar, Universitatea

Tehnică a Moldovei – coordonator;
Nastasenco Veaceslav doctor în tehnică, conferenţiar, şef departament, Allied
Testing SRL.
Spînu Valentina, grad didactic unu, profesor de informatică, Colegiul
Financiar Bancar;
Pîrvan Eugen grad didactic superior, Colegiul Industrial-pedagogic,
Cahul;
Bagrin Diana grad didactic unu, profesor de informatică, Colegiul
Financiar Bancar;

Recenzenţi:

2
TEMA 1: Procesul de testare și importanța asigurării calității produsului program

Unitatea de învățare: Planificarea procedurilor de testare

Aspecte ale testării produselor soft:

● Impactul erorilor produselor soft asupra vieţii noastre;

● Ce prezintă erorile produselor soft şi care este cauza apariţiei lor;
● Cine sunt testerii şi care este rolul lor în procesul de elaborare a produselor soft.

Pentru a asigura calitatea şi siguranţa aplicaţiilor prduse soft se pune un accent deosebit pe
testarea acestor din urmă. Testarea de produse soft a devenit o profesie tehnică foarte importantă.
Următoare exemple pot ilustra foarte bine necesitatea testării produselor soft:
Dezvoltarea aplicaţiilor soft implică o serie de activităţi, în care posibilitatea erorii umane este
foarte ridicată. Testarea este un element-cheie în procesul de dezvoltare, şi reprezintă o ultimă
recapitulare a specificaţiilor, design-ului şi codului.
Testarea produselor soft, prin definiţie, urmăreşte focalizarea pe procesul de identificare a
posibilelor erori de program, erori, care ar putea avea un impact negativ asupra produsului, şi
prin urmare asupra clienţilor. Satisfacţia clienţilor este cheia reuşitei oricărei 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
utilizării de către client. Calitatea ridicată nu poate fi obţinută doar cu ajutorul unei echipe de
programatori de excepţie. Este deja bine ştiut faptul că oricât de bine pus la punct ar fi produsul
dezvoltat, totuşi acesta va conţine erori.
Implicarea testării în procesul de producţie aduce următoarele avantaje:

● Organizare disciplinată a procesului de dezvoltare şi testare matură a procesului de

producţie.
● Responsabilii şi Managerii de proiect induc o linie bine trasată în scopul urmăririi exacte
a procesului de producţie.
● Înţelegerea importanţei calităţii în procesul de producţie, calitate care poate fi obţinută
doar în urma unei testări profesionale.
● Impunerea unor reguli şi standarte care în timp vor duce la livrarea unor produse de cea
mai înaltă calitate, şi a unor soluţii de cea mai înaltă calitate pentru clienţii organizaţiei.

1.1. Definiţia erorii produsului soft

Una dintre cele mai scandaloase erori ale produsului soft
1. Aparat medical pentru terapie cu radiaţie „Therac-25” - 6 accidente cu morţi şi răni grave
(1985-87, SUA, Canada). Cauza directă: erori in programul de comandă.
Analiză retrospectivă [Leveson 1995]:

● încrederea excesivă în produsul soft (în analiza produsului)

● fiabilitate ≠ siguranţă
3
2. Racheta Ariane 5
- Autodistrugerea după o defecţiune la 40 s de la lansare (1996)
Cauza: conversia 64-bit float —► 16-bit int generează o excepţie de depăşire, netratată în
programul ADA
Cost: 500 milioane dolari (racheta), 7 miliarde dolari (proiectul)
Analiză retrospectivă

● principala cauză: reutilizarea nejudicioasă a produsului soft

● cod preluat de la Ariane 4, fără re-analiză corespunzătoare.

3. Eroarea din procesorul Intel Pentium

Eroare în unitatea de împărţire cu virgula mobila, 1994
Cost: cca. 400 milioane dolari
Analiză retrospectivă

● Circuitul putea fi verificat formal

- demonstrarea automată de teoreme [Clarke, German & Zhao]

- cu structuri speciale de date pentru reprezentarea înmulţirii/împărţirii [Bryant & Chen]
• Accentul a fost pus pe componente mai complexe (unitatea de execuţie, coerenţa memoriei
cache)
Eroarea produsului soft
Din exemplele de mai sus se poate vedea impactul erorilor produsului soft asupra noastră.
Erorile pot fi catastrofice, când provoacă pierderi de vieţi omeneşti sau pot fi nişte inconvenienţe
dacă este vorba de exemplu de un joc pe calculator. Majoritatea erorilor sunt mult mai
complicate decât par la prima vedere. Sunt însă şi erori simple, subtile despre care nu se poate de
spus cu siguranţă - este o eroare adevărată sau nu.
Un testor bun trebuie să poată folosi diferiţi termeni pentru a descrie ce s-a întâmplat când a
eşuat softul. În continuare este dată o listă cu termenii folosiţi:

1. Defect (Defect, Bug)

2. Excepţie (Variance)
3. Eşec (Failure)
4. Problemă (Problem)
5. Eroare (Error)
6. Incident (Incident)
7. Anomalie (Anomaly)
8. Inconsistenţă (Inconsistency)
9. Aparenţă (Feature)
10. Neajuns (Fault)
Care dintre aceşti termeni vor fi folosiţi pentru descrierea erorilor ţine doar de cultura companiei
şi de stadiul la care a fost descoperită eroarea. Dacă ne uităm în dicţionar, observăm că toate
aceste cuvinte se deosebesc foarte puţin, unele fiind chiar sinonime.

4
De obicei orice eroare a produsului soft este numită „bug”, însă acest termen nu poate fi acceptat
când se completează diferite rapoarte despre testarea softului. În cadrul acestui curs vom folosi
termenul: eroare a produsului soft.
Înainte de a formula definiţia erorii a produsului soft avem nevoie de un document de reper:
specificaţia produsului soft.
Specificaţia produsului este un acord al echipei de dezvoltare a produsului soft, în care este
defini: cum ar trebui el să fie, cum este într-adevăr, ce trebuie să facă şi ce nu trebuie să facă
acest produs.
Definiţie. Erorile produsului soft apar când una sau mai multe dintre următoarele afirmaţii sunt
adevărate:

1. Softul nu execută ceva, ce specificaţiile spun că trebuie să execute.

2. Softul execută ceva, ce specificaţiile spun că nu trebuie să execute.
3. Softul execută ceva, ce în specificaţii nu este menţionat.
4. Softul nu execută ceva ce, specificaţiile nu menţionează, dar ar trebui să menţioneze.
5. Softul este greu de înţeles, greu de folosit, lent sau se vede, că nu a fost proiectat corect.

Această definiţie a erorilor acoperă o mare parte de probleme, deacea testorii folosesc aceste
reguli pentru a identifica diferite tipuri de probleme în aplicaţiile soft.
1.1.Cauzele apariţiei erorilor
Poate fi surprinzător, dar cel mai mic procent de erori sunt cele provenite de programare.
Cele mai multe erori sunt cauzate de deficienţele din specificaţie (≈ 60%),
uneori specificaţia pur şi simplu nu este scrisă. Alte motive – specificaţia nu
este sufucient de completă, a fost incontinuu modificată şi nu a fost adusă la cunoştinţa întregii
echipe de dezvoltare.
Altă sursă de erori este etapa de proiectare (≈ 30%). Cauzele apariţiei erorilor aici
sunt similare cu cele din specificaţii ( modificări, comunicarea rea etc.).
Relativ puţine (uneori sub 15%) sunt erorile directe de programare. Ele pot apărea din cauza
complexităţii softului, a documentaţiei insuficiente (în special în codul, care a fost modificat), a
timpului insuficient planificat pentru programare sau a erorilor de proiectare. Uneori
programatorii nu înţeleg corect cerinţele, sau cerinţele nu sunt formulate bine.
1.2.Costul erorilor
Erorile depistate şi fixate in faza de scriere a specificaţiilor nu costă practic nimic, cele care nu
au fost depistate înainte de faza implementării şi testării pot ajunge la sute de dolari. Dacă însă
clientul a găsit defecte după livrarea şi lansarea produsului, costul erorilor poate creşte de la mii
la milioane de dolari. Deci, costul erorilor poate creşte exponenţial avansând în procesul de
producţie de la specificare până după livrare.
1.3. Rolul şi scopurile testerului în procesul de dezvoltare produse soft
Definiţia 1. Scopul testorului este de a depista erorile softului.
Se poate rula programul şi confirma că el funcţionează, fără a pune accentul pe detectarea
erorilor. Dacă se testează doar componentele funcţionale, pot fi omise multe erori. În cazul, în
care erorile nu au fost depistate lpromt, clientul riscă să piardă mulţi bani. Deci, testorul nu

5
trebuie să se concentreze doar pe detectarea erorilor, el trebuie să se gândească cum să facă acest
lucru cât mai curând posibil.
De aici avem:
Definiţia 2. Scopul testorului este de a depista erorile softului cât mai devreme posibil.
Dar nici aceasta nu este suficient. Testorul este ochiul clientului, primul care încearcă produsul şi
el doreşte calitate.
Deci:
Definiţia 3. Scopul testorului este de a depista erorile softului cât mai devreme posibil şi a se
asigură că ele au fost fixate şi luate măsuri în legătură cu aceasta.
Această definiţie finală este foarte importantă. La fel este important faptul că fixarea defectelor
nu implică neapărat corectarea softului. În legătură cu aceasta poate fi adăugat un comentariu în
manualul utilizatorului sau poate fi făcut un seminar special cu utilizatorii.

Calităţile unui testor bun

Cum am menţionat mai sus testarea produsului soft este o profesie tehnică. Testorii trebuie
implicaţi în procesul de dezvoltare a produsului soft încă din fazele incipiente, pentru a asigura
calitatea bună a produsului. Pentru a fi angajat şi preţuit un testor trebuie să posede următoarele
calităţi:

1. Trebuie să fie un explorator. Testorul produselor soft este cel care experimentează cu soft-
uri noi încercându-le funcţionalităţile.
2. Trebuie să fie neînduplecat. Testorul produselo soft este mereu în căutare. El caută erori
prin toate căile posibile.
3. Trebuie să fie creativ. Testarea superficială nu este suficientă pentru testor. El trebuie să
gândească creativ şi să intuiască unde poate găsi erori.
4. Trebuie să fie perfecţionist. Testorii tind spre perfecţiune, cu toate că înţeleg că în
industria produselor soft ea este de neatins.
5. Trebuie să posede o bună judecată. Ei trebuie să decidă ce trebuie de testat, cât timp şi
dacă o oarecare problemă este într-adevăr o eroare sau nu.
6. Trebuie să aibă tact şi să fie bun diplomat. El este cel care aduce veştile rele
programatorului.
7. Trebuie să fie perseverent. Erorile găsite nu totdeauna sunt vizibile şi uneori sunt greu de
descris. Testorul trebuie să-ţi poată expune punctul de vedere şi să poată demonstra
necesitatea fixării şi posibil corectării erorilor găsite.

Un testor nu trebuie să fie numaidecât un programator, cunoştinţele din diferite domenii

(economie, învăţământ, aviaţie, medicină, culinărie, construcţii) pentru care sunt dezvoltate
produse produse soft vor fi de un imens ajutor pentru un testor.
1.4. Termeni şi definiţii ale testării

Psihologia testării
Testarea produselor soft este o disciplină tehnică, însă ea implică importante consideraţii
economice şi psihologice.

6
Ideală ar fi testarea tuturor combinaţiilor posibile ale intrărilor şi ieşirilor programului. Însă în
cele mai multe cazuri aceasta este imposibil, deoarece chiar şi un program simplu poate avea
sute şi chiar mii de combinaţii ale intrărilor şi ieşirilor.
Crearea cazurilor de test pentru toate combinaţiile este nepractică, pentru ca aceasta va cere
resurse umane şi financiare enorme, iar procesul poate dura timp îndelungat. Plus la aceasta mai
trebuie de luat în consideraţie ş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 testării
pe care le-a arătat practica testării şi timpul şi de cunoscut nişte tehnici de testare, pentru a
sistematiza acest proces.
Definiţii ale testării
O cauză importantă a calităţii 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 testării este de a arăta că produsul este performant şi funcţionează corect”
sau
3. „Testarea este procesul prin care se demonstrează că produsul face ceea ce trebuie să facă ”
Aceste definiţii nu sunt rele doar că sunt cam pe dos. Este cunoscut că acţiunea de testare a unui
program se deosebeşte de celelalte faze prin care acesta trece (specificare, proiectare,
programare) prin caracterul său în aparenţă "demolator". Într-adevăr, în timp ce alte faze au o
esenţă constructivă, testarea are în aparenţă un caracter mai degrabă distructiv, deoarece scopul
acestei acţiuni este de a pune în evidenţă proasta funcţionare a produsului obţinut. Din punct de
vedere psihologic programatorul trebuie să adopte în aceasta etapă o atitudine "duşmănoasă" faţă
de creaţia sa şi să-i expună defectele.
Esenţa procesului este fără îndoială tot constructivă, scopul său fiind de a pune în operare reală
un produs la parametrii prevăzuţi.
Deci cele mai adecvate definiţii ale testării ar fi:
1. “Testarea e procesul prin care se execută un program cu intenţia de a găsi erori” (Myers) sau
mai mult ca atât:
2. “Testarea este utilizata pentru a semnala prezenţa defectelor unui program, fără a garanta
absenţa lor” (Dijkstra).
3Un test de succes (test concludent) e acela care descoperă (şi localizează) o eroare.
Principii ale testării (Myers)
Continuând ideea acestei teme observăm că cea mai importantă problemă în testare este cea
psihologică. Reieşind din aceasta pot fi formulate nişte principii ale testării.
Principiul 1: Un caz de test trebuie sa definească neapărat ieşirea 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 subconştient aşteptăm
7
rezultatul corect. O cale de combatere a acestui fenomen este încurajarea examinării detaliate a
tuturor ieşirilor. Conform acestui principiu un caz de test trebuie să fie compus din:

1. Descrierea instanţei unui program.

2. Descrierea precisă a rezultatului sau a ieşirii programului pentru această instanţă.

Principiul 2: Un programator ar trebui să evite şi să testeze propriul program.

Orice scriitor cunoaşte, sau cel puţin trebuie să cunoască, că este o idee nu prea bună să-şi
corecteze şi să-şi redacteze singur manuscrisele. Iarăşi este vorba de un fenomen psihologic.
Autorul nu doreşte 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 subconştient nu doreşte să găsească 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 neînţelegerii de către programator
a sarcinii puse sau a specificaţiei produsului. Astfel programatorul va transmite aceleaşi
neînţelegeri şi testelor executate. Aceasta nu înseamnă că programatorul nu trebuie sub nici o
formă să-şi testeze propriul program, însă testarea de către o altă persoană va fi mai eficientă.
Acest principiu nu poate fi aplicat şi depanării. Acest proces este mai bine efectuat de către
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 întârziere 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 decât cel de dezvoltare, iar întreţinerea unui departament de testare este destul
de costisitoare şi nu orice companie poate să-şi permită aceasta.
Principiul 4: Fiecare rezultat al testului trebuie examinat foarte minuţios.
Acesta este probabil cel mai evident principiu. Cât de minuţios nu ar fi făcută 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 atât pentru condiţii de intrare valide cât şi
pentru cele invalide şi neaşteptate.
Este normală tendinţa de testare a produsul pentru date valide de intrare, neglijând datele
incorecte. Este însă forte important comportamentul produsului când sunt introduse date
incorecte sau ilegale. Acest principiu nu poate fi neglijat atunci când 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 neaşteptate. Mai ales astfel de teste trebuie elaborate pentru
produsele cu destinaţie financiară.
Principiul 7: Trebuie de păstrat şi refolosit cazurile de test.
Acest principiu este important şi este respectat de specialiştii în testare. Orice produs poate fi
îmbunătăţit şi dacă dorim să vedem dacă schimbările nu au avut un efect negativ asupra altor
componente ale sistemului atunci este bine de a testa cu testele vechi noul produs. Astfel se
testează integritatea şi funcţionalitatea produsului. Refolosirea cazurilor de test este binevenită şi
8
atunci când au fost corectate unele erori deja găsite. Păstrarea testelor şi refolosirea lor după
modificări în produs poartă denumirea de testare regresivă (regression testing).
Principiul 8: Nu se planifică procesul de testare presupunând că nu vor fi găsite erori.
Este o greşeală a managerilor de proiect când se foloseşte o definiţie incorectă a testării. De
exemplu: „Testarea e procesul prin care se demonstrează că produsul este performant şi
funcţionează corect” în locul “Testarea e procesul prin care se execută un program cu intenţia
de a găsi erori”
Principiul 9: Probabilitatea de a găsi erori într-un fragment de cod este proporţională cu
numărul de erori deja găsite.
Dacă avem de exemplu un program din două module A şi B şi în modulul A au fost găsite cinci
erori iar în B numai una, şi dacă modulul A nu a fost supus intenţionat unui test riguros, atunci
acest principiu ne spune că probabilitatea că în modulul A vor fi găsite mai multe erori decât î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 adevărat că creativitatea cerută la testarea produselor serioase depăşeşte
creativitatea cerută în proiectarea acestora. Este clar că este imposibil de testat un produs
suficient pentru a demonstra absenţa erorilor în acest produs. Metodologia pe care o vom studia
în cadrul cursului va fi de un mare folos la elaborarea unui număr rezonabil de cazuri de test,
însă această metodologie cere un nivel înalt de creativitate a testorului.
1.5.Axiomele testării.
Axiomele testării (Patton)
1. Este imposibilă testarea completă a unui program.
Această axiomă este adevărată din următoarele motive:

● Numărul intrărilor posibile este foarte mare.

● Numărul rezultatelor posibile este foarte mare.
● Numărul drumurilor într-un program este foarte mare.
● Specificaţiile programului sunt subiective.

Exemplul calculatorului
2. Testarea produsului soft este un exerciţiu 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 greşit această combinaţie, nimerind acest produs la consumator, care
este un contabil şi a găsit această eroare, ce se va întâmpla în aşa caz? Această eroare va costa
foarte mult. Sună destul de urât 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 făcut în astfel de
cazuri? Un element important este că testorul trebuie să înveţe cum se poate reduce domeniul
imens a datelor de intrare până la nişte seturi realizabile de teste şi cum să ia decizii ce este
important de testat şi ce nu este.
3. Testarea nu poate arăta că produsul nu are erori.

9
Testarea poate arăta că erorile există într-un produs, dar nu poate arăta că ele nu sunt în el. Pot fi
perfecţionate testele, pot fi găsite şi raportate erorile, dar nu este posibil de garantat că erori în
produs nu se vor mai găsi. Unicul lucru care se poate de făcut este de a continua testarea şi
posibil se vor mai găsi erori.
4. Cu cât mai multe erori găseşti, cu atât mai multe sunt.
Erorile au tendinţa de a se găsi în grupuri. Dacă ai găsit una, poţi fi sigur că în vecinătatea ei vor
mai fi şi altele. Deseori, trece destul de mult timp până când testerul găseşte o eroare. Însă dacă a
fost găsită una el o va găsi ş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 găsită ne poate spune că mai sunt şi altele
prin zonă.
● Programatorii foarte des fac aceleaşi erori. Un programator care a făcut aceiaşi greşeală
de mai multe ori o va repeta iar şi iar.
● Fiecare eroare este ca un aisberg. Deseori proiectul şi arhitectura produsului soft au
probleme serioase. Testerul ar trebui să le depisteze pe acestea în primul rând, 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 cât mai mult testezi cu atât mai imun faţă
de teste devine softul. Analogic cu insectele şi pesticidele: dacă sunt aplicate aceleaşi pesticide
de fiecare dată insectele devin imune la ele şi chiar mai puternice decât au fost. Pentru a găsi
erori noi e nevoie de teste noi.
6. Nu toate erorile găsite vor fi corectate.
O realitate tristă atestării este, că după ce s-a lucrat destul de mult şi greu pentru a depista erorile,
nu toate din ele sunt fixate şi corectate. Şefii echipelor de testare trebuie să facă compromisuri şi
să ia decizii bazate pe riscuri în ceea ce priveşte fixarea anumitor erori.
Acest lucru are motive serioase:

● Nu este suficient timp pentru aceasta.

● Într-adevăr 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, aşa că decizia luată este bazată pe anumite riscuri (exemplu Procesorul Intel Pentium)
7. E greu de spus când o eroare e o eroare ...
În afară de acele afirmaţii care alcătuiesc definiţia erorii testorii pot apela şi la opinia altor
persoane poate chiar a clientului, ce reprezintă pentru el o eroare şi îşi poate formula propria
definiţie a erorii.
8. Specificaţiile produselor nu sunt niciodată definitive.
Industria produselor soft se dezvoltă foarte rapid. În acelaşi timp produsele soft devin tot mai
complexe, iar termenii de predare mai scurte din cauza concurenţei. Aceste două aspecte sunt în
10
conflict permanent şi rezultatul conflictului este schimbarea constantă a specificaţiilor. Un alt
motiv este perfecţionarea unui produs care a fost scos pe piaţă cu ceva timp în urmă specificaţiile
au fost rescrise, dar nu conţin şi funcţionalităţile vechi ale produsului.
9. Testorii nu sunt cei mai populari membri ai echipei de proiect.
Ne amintim de scopul unui testor. Câteva sfaturi utile pentru testori:

● Găsiţi erorile cât mai devreme. Toţi vor fi mulţumiţi dacă o să găsiţi erorile serioase cu
două luni, dar nu cu o zi înainte de sfârşitul perioadei de testare.
● Temperaţi-vă entuziasmul. Cât de bucuros nu ai fi că ai găsit o eroare critică, fii diplomat
când i-o spui programatorului.

TEMA 2: Principiile procesului de testare

Unitatea de învățare 2: Planificarea procesului de testare
1. Descrierea procesului de testare (testarea în funcție de bani, timp, calitate)
Costul erorilor.
Erorile depistate şi fixate în faza de scriere a specificaţiilor nu costă practic nimic, cele care nu
au fost depistate înainte de faza implementării şi testării pot ajunge la sute de dolari. Dacă însă
clientul a găsit defecte după livrarea şi lansarea produsului, costul erorilor poate creşte de la mii
la milioane de dolari. Deci costul erorilor poate creşte exponenţial avansând în procesul de
producţie de la specificare până după livrare.
Cauze ce pot duce la apariția defectelor în produsul soft:

● Nimeni nu este perfect, oricine poate face greșeli/omisiuni

● Presiunea crescută poate duce la greșeli
● Restricțiile de timp și buget
● Pregătirea slabă, comunicarea ineficientă
● Cerințe slabe
● Specificații incomplete

Cât de multă testare este necesară?

Dacă se oprește testarea prea devreme, se riscă apariția de erori la rularea propriu-zisă a
sistemului. Dacă testarea continua pentru o perioadă prea lungă se poate amâna lansarea
produsului, fapt ce poate duce la degradarea imaginii companiei sau chiar pierderi de venituri.
Foarte rar este posibilă testarea tuturor posibilităților, fapt ce duce la concentrarea atenției asupra
anumitor factori :

● Managementul și reducerea riscurilor

● Analiza continua a riscurilor produsului
● Testarea categoriilor mari de risc
● Întelegerea efectului pe care l-ar putea avea un produs care nu funcționează corect

2. Riscurile procesului de testare

11
Unele dintre cele mai scandaloase erori în produsle soft

1. Aparat medical pentru terapie cu radiaţie „Therac-25”

2. Racheta Ariane 5
3. Eroarea din procesorul Intel Pentium

Cauzele apariţiei erorilor.

Poate fi surprinzător, dar cel mai mic procent de erori sunt cele provenite de programare. Cele
mai multe erori sunt cauzate de deficienţele din specificaţie (≈ 60%), uneori specificaţia pur şi
simplu nu este scrisă. Alte motive – specificaţia nu este descrisă în detaliu, a fost modificată
constant şi nu a fost adusă la cunoştinţa întregii echipe de dezvoltare. Altă sursă de erori este
etapa de proiectare (≈ 30%), cauzele apariţiei erorilor aici sunt similare cu cele din specificaţii
( modificări, comunicarea rea etc.). Relativ puţine (uneori sub 15%) sunt erorile directe de
programare. Ele pot apărea din cauza complexităţii softului, a documentaţiei insuficiente (în
special în codul care a fost modificat), a timpului insuficient planificat pentru programare sau a
erorilor de proiectare. Uneori programatorii nu înţeleg corect cerinţele, sau cerinţele nu sunt
formulate bine.
Psihologia testării
Testarea produselor soft este o disciplină tehnică, însă ea implică importante consideraţii
economice şi psihologice.
Ideală ar fi testarea tuturor combinaţiilor posibile ale intrărilor şi ieşirilor programului. În cele
mai multe cazuri însă aceasta este imposibil, deoarece chiar şi un program simplu poate avea
sute şi chiar mii de combinaţii ale intrărilor şi ieşirilor. Crearea cazurilor de test pentru toate
aceste combinaţii este destul de nepractică, pentru aceasta este nevoie de resurse umane şi
financiare enorme, mai mult ca atât procesul poate dura timp îndelungat. Plus la aceasta mai
trebuie de luat în consideraţie ş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 testării
pe care le-a arătat practica testării şi timpul şi de cunoscut nişte tehnici de testare, pentru a
sistematiza acest proces.

Rolul şi scopurile testerului în procesul de dezvoltare a produsului soft.

1. Scopul testorului este de a depista erorile softului.

2. Scopul testorului este de a depista erorile softului cât mai devreme posibil.
3. Scopul testorului este de a depista erorile softului cât mai devreme posibil şi se asigură că
ele au fost fixate şi luate măsuri în legătură cu aceasta.

Calităţile unui tester bun

1. Trebuie să fie un explorator. Testerul de produse soft este cel care experimentează cu
soft-uri noi încercându-le funcţionalităţile.
2. Trebuie să fie neînduplecaţi. Testerul de produse soft este mereu în căutare. El caută erori
prin toate căile posibile.
3. Trebuie să fie creativ. Testarea superficială nu este suficientă pentru testor. El trebuie să
gândească creativ şi să intuiască unde poate găsi erori.

12
 4. Trebuie să fie perfecţionist. Testerii tind spre perfecţiune, cu toate că înţeleg că în
industria produselor soft ea este de neatins.
5. Trebuie să posede o bună judecată. Ei trebuie să decidă ce trebuie de testat, cât timp şi
dacă o oarecare problemă este într-adevăr o eroare sau nu.
6. Trebuie să aibă tact şi să fie bun diplomat. El este cel care aduce veştile rele
programatorului.
7. Trebuie să fie perseverent. Erorile găsite nu totdeauna sunt vizibile şi uneori sunt greu de
descris. Testorul trebuie să-ţi poată expune punctul de vedere şi să poată demonstra
necesitatea fixării şi posibil corectării erorilor găsite.

Un tester nu trebuie să fie numaidecât un programator, cunoştinţele din diferite domenii

(economie, învăţământ, aviaţie, medicină, culinărie, construcţii ) pentru care sunt dezvoltate
produsele soft vor fi de un imens ajutor pentru un tester.
Principii ale testării (Myers)
Principiul 1: Un caz de test trebuie sa definească neapărat ieşirea sau rezultatul dorit.
Principiul 2: Un programator ar trebui să evite şi să testeze propriul program.
Principiul 3: Companiile de programare nu ar trebui să-şi testeze produsele proprii.
Principiul 4: Fiecare rezultat al testului trebuie examinat foarte minuţios.
Principiul 5: Cazurile de test trebuie să fie scrise atât pentru condiţii de intrare valide cât şi
pentru cele invalide şi neaşteptate.
Principiul 6: Trebuie testat că produsul face ce trebuie şi nu face ce nu trebuie.
Principiul 7: Trebuie de păstrat şi refolosit cazurile de test.
Principiul 8: Nu se planifică procesul de testare presupunând că nu vor fi găsite erori.
Principiul 9: Probabilitatea de a găsi erori într-un fragment de cod este proporţională cu
numărul de erori deja găsite.
Principiul 10:Testarea este un lucru extrem de creativ şi intelectual.
Axiomele testării (Patton)
1. Este imposibilă testarea completă a unui program.
2. Testarea produselor soft este un exerciţiu de apreciere a riscurilor.
3. Testarea nu poate arăta că produsul nu are erori.
4. Cu cât mai multe erori găseşti, cu atât mai multe sunt.
5. Paradoxul pesticidelor: erorile devin rezistente la teste
6. Nu toate erorile găsite vor fi corectate.
7. E greu de spus când o eroare e o eroare ...
8. Specificaţiile produselor nu sunt niciodată definitive.
9. Testerii nu sunt cei mai populari membri ai echipei de proiect.
Tema 3: Planul de testare
Unitatea de învățare: Planificarea procesului de testare

Fazele procesului de testare sunt:

13
 1. planificarea,
2. analiza şi proiectarea,
3. implementarea,
4. execuţia şi evaluarea testelor.

1. Planificarea testelor

Planificarea testelor se realizează în strânsă legătură cu planificarea derulării proiectului. În

faza de planificare a proiectului pentru testare se alocă resurse, specificându-se bugetul şi
perioada de timp în care se va derula testarea. Pe baza acestora se realizează planificarea
detaliată a procesului de testare. Pe baza acestora se realizează planificarea detaliată a procesului
de testare.

Planificarea testării are scopul de a determina ce să testeze şi cât să testeze, astfel încât procesul
de testare să se încadreze în limitele resurselor alocate. În urma planificării testării rezultă planul
de test, un document pe baza căruia se desfăşoară celelalte faze ale testării. În această fază se
identifică şi obiectivele testării.

Planul de test este un document important, fiind utilizat ca bază pentru desfăşurarea întregului
proces de testare. În plus, trebuie identificate şi sursele de risc în testare. Planificarea testării
poate să înceapă din momentul în care au fost elaborate cerinţele aplicaţiei soft.

În planul de test sunt descrise:

• aria de cuprindere;

• responsabilităţile fiecărui membru al echipei de testare;

• resursele umane necesare;

• desfăşurarea în timp a testelor;

• descrierea şi configurarea mediului specific aplicaţiei;

• lista echipamentelor care trebuie achiziţionate;

• 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 finalizării testării.

2. Analiza testelor

Analiza testelor rafinează metodele prezentate în planul de test. Sunt prezentate etapele fazelor
de analiză şi proiectare a testelor.
14
Astfel, în etapa de analiză se identifică următorii paşi:

1. identificarea scopurilor, obiectivelor şi a strategilor testării de către echipa de testare;

2. metodele de verificare sunt asociate cerinţelor sistemului sau cazurilor de utilizare şi sunt
documentate în cadrul unei matrice de urmărire a cerinţelor;
3. analiza cerinţelor testelor;
4. construirea matricei cerinţelor testelor, în care declaraţiile cerinţelor testelor sunt asociate
cerinţelor sistemului sau a cazurilor de utilizare;
5. asocierea tehnicilor de testare cu declaraţiile cerinţelor testelor.

În faza de analiză a procesului de testare, un aspect important îl ocupă analiza cerinţelor pentru
testare. Cerinţele testării trebuie să fie identificate şi documentate astfel încât toate persoanele
implicate în procesul de testare să fie conştiente de scopul acestuia. Analiza se desfăşoară din
mai multe puncte de vedere, depinzând de faza de testare. Astfel se identifică o abordare
structurală şi o abordare bazată pe comportament.

Faza de proiectare a testelor urmează după încheierea analizei. În faza de proiectare, apar
următorii paşi:

● definirea modelului programului de test astfel încât 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 încât fiecare cerinţă pentru datele de test să se reflecte
pentru fiecare procedură de test.

Programul de test se elaborează fie la nivelul proiectării, fie la nivelul tehnicilor de testare. În
primul caz, procedurile de test sunt asociate componentelor hardware şi produselor soft ale
aplicaţiei, iar în al doilea caz procedurile de testare sunt văzute la nivelul tehnicilor de testare.

Proiectarea procedurilor de test începe după determinarea cerinţelor testării. Proiectarea

procedurilor de test constă în:

● analiza arhitecturii de test pentru determinarea tehnicilor de testare relevante;

● definirea procedurilor de test atât la nivelul sistemului cât şi la nivelul de implementare;
● elaborarea sau preluarea de standarde de utilizare a procedurilor de test;
● identificarea procedurilor de test care vor fi efectuate manual şi a celor care vor fi
efectuate automat;
● identificarea procedurilor de test complexe, pentru a fi proiectate în continuare în faza de
proiectare detaliată;
● proiectarea detaliată.

3. Implementarea testelor
15
Î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 atât parametrii de intrare cât şi
rezultatele aşteptate după execuţie utilizând acei parametri. Realizarea de cazuri de test cât mai
complete duce la descoperirea unui număr mai mare de erori. Procedurile de test identifică toţi
paşii necesari pentru executarea cazurilor de test specifice.

Primul pas în faza de implementare este iniţializarea mediului de implementare prin punerea la
punct a arhitecturii dezvoltării testelor.

Un alt aspect important este identificarea standardelor pe care se bazează elaborarea secvenţelor
de test. Dacă au fost definite astfel de standarde de implementare, atunci implementarea se
realizează pe baza acestora. Dacă nu există standarde, în cadrul acestei faze, la început, se
stabilesc convenţii de scriere a programelor de test (alinieri, comentarii, prefixe pentru date).

Implementarea secvenţelor de test se realizează în limbaje specifice mediilor de testare

(asemănătoare Visual Basic) sau se utilizează limbaje de programare evoluate (C++, Java).

Prin reutilizare se folosesc proceduri de test din proiectele anterioare sau din cadrul aceluiaşi
proiect pentru module care au părţi comune.

4. Execuţia şi evaluarea testelor

Faza de rulare a testelor are ca intrări planul de test şi orarul execuţiei procedurilor de test,
mediul de test fiind pregătit corespunzător. Ieşirile fazei de execuţie a testelor sunt rezultatele
testelor, lecţiile învăţate şi orarul modificat al testelor. Execuţia modulelor se realizează în
conformitate cu planul de test. Procedurile de test descriu intrările şi ieşirile aşteptate după
execuţie.

În această etapă din cadrul procesului de testare sunt rulate secvenţele de test. Execuţia
secvenţelor de test se realizează pe cât posibil în mediul specific aplicaţiei iar dacă nu este
posibil, acest mediu este simulat.

Rezultatele execuţiei secvenţelor de test sunt evaluate pentru a determina dacă produsul a trecut
testul cu succes. Evaluarea rezultatelor testelor se face de către un oracol.

Oracolul este o persoană sau un instrument automat, care pe baza specificaţiilor determină dacă
rezultatele execuţiei testelor sunt corecte sau nu.

În figura este prezentat fluxul procesului de execuţie şi evaluare a testelor pentru testarea la nivel
de modul, bazată pe specificaţii. Rezultatele testelor arată dacă programul a trecut sau nu testul.

16
Fazele de executie şi evaluare pentru testarea de module

Rezultatele execuţiei testelor se vor memora într-o bază de date care conţine şi alte informaţii
referitoare la aplicaţia soft realizată.

Execuţia şi evaluarea testării de integrare necesită noi secvenţe de test pe rul structurii
programului care sestează. Aprobarea de către beneficiar a rapoartelor testării de modul şi ale
testarii de integritate continue inchiierea acestor faze.

În execuţia şi evaluarea testării de sistem, beneficiarul aplicaţiei se implică mai mult decât în
celelalte faze. În mod asemănător, acesta trebuie să semneze raportul de test pentru a considera
încheiată această fază de testare.

CONCLUZIE

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

● alegerea de personal calificat;

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

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

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

17
efectueze înregistrari de consumuri si de performanta pentru a putea obtine la timp baza de date
solicitata în procesul de estimare a coeficientilor pentru modelele testarii.

TEMA 4: Cazul de testare

Unitatea de învățare: Realizarea procesului de testare
TEMA4: Cazuri de testare

Competențe elementare formate în cadrul modului:

CE2. Realizarea procesului de testare.
Abilități formate:
A8. Alegerea sub îndrumare a tehnicilor de testare;
A9. Selectarea criteriilor de testare;
A10. Elaborarea cazurilor de test în baza specificaţiilor.
Termeni cheie:
Test condition;
Test case;
Test suite;
Test case generation;
Test case execution
Test condition ( condiția, starea) - un element ori un eveniment al componentei sau
sistemului care poate fi verificat de unul sau mai multe cazuri de test, de exemplu o funcție, o
tranzacție, o trăsături, un atribut de calitate sau element structural.
Cu alte cuvinte condiția de test e o caracteristică a softului care poate fi verificată printr-
un test sau un set de teste.
Un caz de test este un set de date de intrare împreună cu datele de ieșire pe care
programul ar trebui să le producă. De exemplu, valorile coeficienților a, b, c ai unei ecuații de
gradul doi împreună cu valorile x1, x2, în testul unui program de rezolvare a ecuațiilor de gradul
doi. Cazurile de test se aleg astfel încât sa fie puse în evidență, dacă este posibil, situațiile de
funcționare necorespunzătoare.
Alte definiții:
Standardul IEEE 610 - 1990: “Un set de intrări ale testului, condiții de execuție și
rezultate așteptate, dezvoltat pentru un obiectiv anume, cum ar fi să exercite o anume cale a unui
program sau să verifice corespondența cu o cerință specifică”;
Ron Patton ( 2001): “Cazurile de testare sunt intrările specifice pe care le veți încerca
si procedurile ce vor urma când testați produsul soft.”
Test case - un set de valori incluse, executarea precondițiilor, rezultatele așteptate și
executarea postcondițiilor, dezvoltate pentru un obiectiv particular sau pentru condiția de test,
18
astfel încât să solicite o anumita parte a programului sau să verifice concordanța cu o cerință
specifică.
Cu alte cuvinte, un test case: aduce sistemul la un punct de start a testului (executarea
precondițiilor); apoi aplica un set de date de intrare care trebuie să genereze un anume rezultat
(rezultatul așteptat), și părăsește sistemul la un moment dat (executarea postcondițiilor).
Activitățile de proiectare vor genera un set de valori de intrare (input values) care vor
genera un anumit rezultat, de ex. stabilirea de către specificați ce se va întâmpla cînd se vor
aplica datele de intrare.
Trebuie să definim starea sistemului în care el este pregătit să primească intrări, și trebuie
să decidem în ce stare va fi el după testare astfel încât să putem verifica daca se finisează în locul
potrivit.
Selectarea cazurilor de test este unicul pas important pe care testorii de soft-uri îl fac.
Selectarea incorecta a acestora induce la testarea prea îndelungata, prea puțina sau testarea unor
lucruri eronate. Estimând inteligent riscurile și reducând infinitatea de posibilități la un set
eficient și administrabil de date.
Procedura de testare - identifică toate acțiunile necesare executării testului într-o
anumită ordine. Procedura de testare - deseori e numita test script (sau manual test script
pentru al deosebi de automated scripts care se execută cu diferite instrumente)
Specificația cazurilor de test este a doua etapă în procesul fundamental de testare.
Proiectarea testelor conțin 3 etape:
1. Identificarea condițiilor de testare.
2. Specificarea cazurilor de test.
3. Specificarea procedurilor de testare.
Pornind de la cele trei etape ale procesului, noi:
● decidem o condiție de testare, care va fi o mică parte a specificației softului testat;
● proiectăm un test case care va verifica condiția de testare;
● scriem o procedură pentru executarea testului, de exemplu: alegeți o stare de start
corectă, introduceți datele de intrare (input values), verificați rezultatele obținute.
În pofida limbajului tehnic, e un set simplu de pași. Desigur va trebui sa utilizăm de mai
multe ori acești pași pentru a testa întregul sistem, dar procesul de bază este același. Pentru a
testa tot sistemul scriem planul de executare a testului, care plasează procedurile individuale de
testare în ordinea adecvată și setează sistemul așa încît să fie posibilă executarea testului.

Exemplu:
Unui testor, nou angajat, i se propune spre realizare următorul test-case:
”Plata poate fi efectuata cu cartela VISA”
Momentan apar minimum doua probleme:
19
 ● Pentru executarea test-case-ului este necesara o cartela de testare VISA, pe care
testerul nu o are;
● El nu cunoaște cum să verifice dacă plata a fost efectuata în realitate sau nu, chiar
daca el va avea la dispoziție cartela VISA.
Unicul lucru, care este clar, - acesta reprezintă un proces de cumpărare în internet-
magazin (căutarea produsului, adăugarea lui in coș s.a.m.d.), care în această situație nu ajuta cu
mult. Este clar că nici o testare nu va fi realizată, deoarece pentru a ajunge la un careva rezultat
va fi destul de dificil. Pentru realizarea test-case-ului cu succes el ar trebui să arate în următorul
mod:
1. Deschide www.magazin.md
2. Introdu în cîmpul ”Numele utilizatorului”: ”testuser1”
3. Întrodu in cîmpul ”Parola”: ”pa$$wOrd”
4. Apasă pe butonul ”Intrare”;
5. Întrodu in cîmpul ”Căutare”: ”book117”
6. Apasă pe butonul ”Găsește”
7. Efectuează un click pe referința ”Adaugă în cos”
8. Efectuează un click pe referința ”Coș”
9. Efectuează un click pe referința ”Plătește”
10. Din meniul ”Tipul cartelei” alege: ”VISA”
11. În cîmpul ”Numărul cartelei” introdu: ”9999-3214-1111-3255”
12. în cîmpul ”Valabil pînă la” introdu: ”12/17”
13. În cîmpul ”CW2” introdu:”445”
14. Apasă pe butonul ”Confirma comanda”
15. Scrie numărul comenzii: ________________
16. Interoghează baza de date: ”SELECT result from cc_transaction WHERE id =
<numarul comenzii>”;
Rezultatul așteptat: 10
Este evident, ca acest test-case poate fi realizat de oricine, ce are abilități de lucru la
calculator.
În acest exemplu la rezultatul așteptat s-au adăugat pași (steps), care ar trebui sa ne
conducă la rezultatul real, pentru a cunoaște dacă este prezent bagul sau nu. Totalitatea acestor
pași se numește procedura (procedure).
După analogie:
● Pași - trepte ale unei scări;
● Rezultat așteptat - un oarecare obiect, pe care noi ar trebui să-l găsim, după ridicarea
pe aceste trepte;

20
 ● Rezultat real - este ceea ce noi am găsit în realitate după ce ne-am ridicat pe aceste
trepte.
Implementarea testelor
În etapa de implementare a testelor sunt construite cazurile de test și procedurile de test,
pe baza rezultatelor fazei de proiectare. Cazurile de test descriu atît parametrii de intrare cat și
rezultatele așteptate după execuție utilizând acești parametri. Realizarea de cazuri de test cat mai
complete duce la descoperirea unui număr mai mare de erori. Procedurile de test identifică toți
pașii necesari pentru executarea cazurilor de test specifice.
Rularea testelor.
Faza de rulare a testelor are ca intrări planul de test și orarul execuției procedurilor de
test, mediul de test fiind pregătit corespunzător. Ieșirile fazei de execuție a testelor sunt
rezultatele testelor, lecțiile învățate și orarul modificat al testelor. Execuția modulelor se
realizează în conformitate cu planul de test. Procedurile de test descriu intrările și ieșirile
așteptate după execuție.
În această etapă din cadrul procesului de testare sunt rulate secvențele de test. Execuția
secvențelor de test se realizează pe cît posibil în mediul specific aplicației iar daca nu este
posibil, acest mediu este simulat.
Rezultatele execuției secvențelor de test sunt evaluate pentru a determina dacă produsul a
trecut testul cu succes. Evaluarea rezultatelor testelor se face de către o persoana sau un
instrument automat, care pe baza specificațiilor determină dacă rezultatele execuției testelor sunt
corecte sau nu.
Rezultatele execuției testelor se vor memora într-o baza de date care conține și alte
informații referitoare la aplicația soft realizata.
Execuția și evaluarea testării de integrare necesită noi secvențe de test pe măsura ce se
adaugă module în cadrul structurii programului care se testează. Aprobarea de către beneficiar a
rapoartelor testării de modul și ale testării de integrare constituie încheierea acestor faze.
In execuția și evaluarea testării de sistem, beneficiarul aplicației se implica mai mult decît
în celelalte faze. In mod asemănător, acesta trebuie să semneze raportul de test pentru a considera
încheiata aceasta faza de testare.
Diagrama stărilor
creării unui caz de testare:
creare, draft, revizuit,
șters, livrat, update și învechit.

21
 Anumite acțiuni sînt efectuate de responsabilul stării, după care cazul de testare este
trecut în starea următoare, după ce acțiunile se încheie.
Diagrama stării rezultatelor:
PASS/FAIL/Blocat/Invalid

Proiectarea unui caz de testare:

Cazurile de utilizare și de testare provin din origini diferite și servesc scopuri diferite. Se
poate folosi un proces în patru pași pentru a trece de la cazurile de utilizare la teste:
● Identificarea scenariilor cazurilor de utilizare.
● Pentru fiecare scenariu, identificați unul sau mai multe cazuri de testare.
● Pentru fiecare caz de testare, identificați condițiile care îl vor face sa fie
executabil.
● Completarea cazului de testare prin adăugarea de date cu valori.
Structura unui test:
● Cazurile de testare trebuie să menționeze:
● Titlul ( funcționalitatea ce va fi testata)
● Versiunea (cazul de testare se modifica în timp, o dată cu aplicația)
Cazurile de testare se scriu sub forma de tabel, si contin urmatoarele coloane:
● ID
● Pașii testului
● Rezultatele așteptate
● Rezultatele reale
● ID-ul defectelor
● Versiunea pe care s-a executat testul
● Rezultatul testului (pass, fail, etc.)
Unele teste precizează și condițiile necesare înainte de a se rula un test.
Exemplu de un caz de testare:

22
Test Case #: Test Case Name: Page: 1 of ..

System: Subsystem:
Designed by: Design Date:
Executed by: Execution Date:

Short Description:

Co
Rezultate Rezultate Pass me
Nr. ID Descriere
așteptate reale /Fail nta
rii
Lansarea aplicatiei:
1. AD_lansare Dublu clic pe Aparitia ferestrei
ari aplicatiei: Apare
Pass
e_dreptunghi. fereastra
exe aplicatiei.
2. AD_interfata Denumirea Bara de titlu: Bara de titlu:
_titlu aplicatiei pe ”Aria ”Aria
Pass
bara de titlu. DREPTUNGHIUL DREPTUN
UI” GHIULUI”
Greșeli frecvente la elaborarea cazurilor de testare:
● Cazurile de testare sunt prea lungi;
● Precondiții incomplete, incorecte sau neclare;
● Omiterea unui pas;
● Numirea unor cîmpuri care s-au schimbat sau nu mai exista;
● Neclaritatea daca testul a trecut sau a picat.
Concluzie:
● Nu exista o formula simpla sau rețetă pentru a genera un caz de testare bun.
● Unele teste sunt bune pentru scopul pe care îl avem, pentru a afla tipul de
informație pe care îl dorim.

Tema 5: Ciclul de viață al elaborării produsului program

Unitatea de învățare 4: Modalități de realizare a testărilor

Ciclul de viață a unui produs program - O secvența de etape în existența produsului soft. Sunt
incluse toate activitățile necesare pentru dezvoltarea produsului și relațiile temporale dintre ele.
Fiecare etapă din ciclul de viața este caracterizată prin activități specifice și produsele rezultate
din activitățile respective.
Fazele ciclului de viață al unui produs soft:
● Analiza cerințelor
● Proiectarea sistemului

23
 ● Implementarea lui
● Integrarea și instalarea la beneficiar, (testarea)
● Operarea și întreținerea
Analiza cerințelor - Determinarea cerințelor; Specificarea cerințelor; Instrumente CASE
(Computer Assisted Software Elaboration); Documentația de specificație a cerințelor; Asigurarea
calității produsului soft.
Proiectarea sistemului - O descriere a structurii sistemului de implementat; Datele care sunt
prelucrate în sistem; Interfețele între componentele sistemului; Algoritmii utilizați (doar în
anumite situații); Proiectarea detaliată (adaugă detalii modelului realizat din analiza cerințelor);
Proiectarea arhitecturală; Gestiunea relaționării părților aflate în diverse stadii de dezvoltare -
cerințe, proiect sau segmente de cod.
Implementarea - O mare parte este programare; Extra – proiectare înainte de programare;
Generare de cod; Revizuirea codului (prin treceri și inspecții); Testarea bazată pe execuție
(observarea comportamentului), testarea conformă cu specificațiile (black – box testing), testarea
conformă cu codul (white-box testing) – se urmăresc căi de execuție.
Integrarea și instalarea - Se asamblează aplicația din setul de componente implementate și
testate în prealabil în faza de implementare prin integrarea continuă, ce reese din proiectarea
arhitecturală a sistemului. Instalarea este transmiterea sistemului funcțional beneficiarului pentru
utilizarea în producție: softul este instalat în diverse versiuni; fiecare versiune este precedată de
testare de sistem (dezvoltator alpha-testing) și testarea de acceptare(beneficiar-beta-testing);
training pentru beneficiar; documentație de utilizare.
Operarea și Întreținerea - Operarea semnifică acea etapă a ciclului de viață în care un produs
soft este utilizat în munca de zi - cu - zi înlocuind sistemul precedent. Startul Operării coincide
cu începerea procesului de Mentenanță:
● Corectivă;
● Adaptivă;
● Perfectivă.
Ciclul de viață diferă în funcție de:
● Experiența, abilitățile și cunoștințele membrilor echipei de dezvoltare;
● Gradul de cunoaștere și experiența în afacerea vizată de sistem;
● Tipul domeniului aplicației;
● Schimbările de mediul afacerii;
● Schimbările din interiorul afacerii;
● Dimensiunea proiectului.
Modele ale ciclului de viață a unui produs soft:
● Modelul Waterfall (cascadă)
● V-model
● Incremental (spiraliform)

Modelul Waterfall
24
Modelul Waterfall – Cerințe sistem → Cerințe produs soft → Design arhitectural
(cerințe tehnice) → Design detaliat(cerințe program) → Implementare
(Coding) → Testare.
Este lansat la începutul anilor 70 ai secolului al XX-ea de către W.W. Royce
Presupune parcurgerea secvențială a etapelor (de la analiza cerințelor și până la livrarea
produsului către client), cu reveniri, eventual doar la etapa precedentă (model teoretic)
În realitate, parcurgerea etapelor este un proces iterativ, desfășurat adesea în paralel la mai multe
activități, cu retur înapoi la etape neînvecinate.
Fiecare fază corespunde unei activități și trebuie să se termine la o anumită dată prin producerea
anumitor documente sau programe.
Rezultatele fazei sunt supuse unei revizii aprofundate și nu se trece la faza următoare decât
atunci când sunt considerate satisfăcătoare.
Este aplicat unor sisteme de mică complexitate.
V-model
V-model
Este o variantă a modelului cascadă, care pune în evidență corelarea dintre activitățile de
specificare și cele de testare, înlăturarea în timp a activităților fiind aceeași.
V-modelul presupune un ciclu de viață secvențial.
Planificările se fac o dată cu parcurgerea primei ramuri.
Începerea activităților de testare în fazele incipiente ale ciclului de viața.
Planul de testare afectează planul de dezvoltare.

Modelul Incremental
Modelul Incremental
Pentru modelul iterativ cerințele nu trebuie să fie definite în întregime înainte de începerea
codificării. O versiune de lucru a produsului este construită, în câteva etape, sau iterații. Acest tip
de dezvoltare este adesea menționat ca ciclic în cadrul proiectului. Proiectul va avea definit un
interval de timp și costuri. Fiecare ciclu va avea, de asemenea, un interval de timp și de cost.
Ciclurile sunt denumite în mod obișnuit time-boxes. Pentru fiecare time-box este definită o
cerință și este produsă o versiune a codului, care va permite testarea de către utilizatori. La
sfârșitul fiecărui time-box, va fi luată o decizie în privința funcționalității și dacă e necesar se va
dezvolta funcționalitatea în următoarea iterație. Acest proces se repetă până când sistemul
complet va realiza produsul.
Modele:
● Spirală (Boehm, 1988);
● IBM Rational Unified Process (RUP)(IBM, 2003);
● Model Driven Architecture(MDA) (OMG, 2003);
● Agile lifecycle with short cycles (Agile Alliance, 2001)
Verificarea și Validarea pe tot parcursul ciclului de viață

25
Verificarea - verifică dacă produsul îndeplinește cerințele stabilite. Verificarea asigură
construirea produsului în mod corect.
Validarea - asigurară potrivirea comportamentului produsului la nevoile clienților.
De exemplu, pentru un site web:
Validarea va include utilizatorii,
Verificarea că ei pot folosi site-ul cu ușurință.
Mentenanța testării
Pentru unele proiecte sistemul este instalat beneficiarului. Odată implementat de mizează pe
faptul că el va funcționa după destinație, câțiva ani sau poate zeci de ani.
Însă cu timpul apare necesitatea de a schimba sistemul. Necesitatea modificărilor se datorează
următorilor factori:
● Apare necesitatea includerii caracteristicilor suplimentare;
● Sistemul a fost migrat pe o nouă platformă;
● Sistemul a fost retras și apare necesitatea migrării sau arhivării datelor;
● Apariția de noi anomalii care trebuiesc fixate... .
Modificările ce au fost făcute în sistem vor trebui testate, retestate și deasemenea se vor efectua
teste de regresie, pentru a se asigura că sistemul nu a fost afectat.
Testarea care are loc pe un sistem ce funcționează real este numit mentenanța testării.
Concluzii
Etapele procesului de dezvoltare a soft-ului sunt cunoscute ca faze al e ciclului de viață a
produsului soft.
Fazele ciclului de viață sunt: analiza cerințelor, proiectarea sistemului, implementarea,
integrarea și instalarea, operarea și mentenanță.
Modelele ciclului de viață pot fi împărțite în:
● modele cascadă cu variante succesive;
● modele iterative cu variante succesive.
Modelele în cascadă nu sunt adecvate proceselor moderne de dezvoltare.
Cele mai reprezentative patru modele iterative sunt:
● Spirală,
● Rational Unified Process(RUP),
● Model driven Architechture(MDA)
● Agile.
Tema 6: Nivelele modelelor de testare
Unitatea de învățare: Modalități de realizare a testărilor
Termenul de 'testare unitară' se referă la testarea individuală a unor unități separate dintr-un
produs soft.
În timpul proiectării şi codificării se comit erori care sunt grupate în următoarele categorii:

26
 ● erori legate de alegerea şi descrierea algoritmului: algoritm incorect, sau corect dar
inadecvat problemei;
● erori în definirea şi utilizarea datelor ce provin din variabile neiniţializate: formate
improprii de citire, contoare de capacitate insuficientă, neverificarea datelor de intrare;
● erori de calcule: expresii complicate cu posibilităţi necontrolate de eroare;
● erori produse în tehnica de programare cum sunt variabile şi structuri de date globale,
acces necontrolat la zone de memorie partajate;
● erori produse din neatenţie caz în care logica de control e defectuoasă, salt în afara
limitelor programului, condiţii logice compuse sau incorect negate;
● erori în contextul execuţiei datorate memoriei dinamice insuficiente sau nealocată,
periferice neoperaţionale, comunicare defectuoasă cu sistemul de operare.
● erori produse în tehnica de programare cum sunt variabile şi structuri de date globale,
acces necontrolat la zone de memorie partajate;
● erori produse din neatenţie caz în care logica de control e defectuoasă: condiţii logice
compuse sau incorect negate, neprelucrarea primei sau ultimei înregistrări, neluarea în
considerare a posibilităţii de existenţă a fişierelor vide;
● erori în contextul execuţiei datorate memoriei dinamice insuficiente sau nealocată,
periferice neoperaţionale, comunicare defectuoasă cu sistemul de operare;
Testele unitare au câteva caracteristici importante:
● fiecare test validează un comportament din aplicație;
● rulează foarte repede, maxim în câteva minute;
● sunt foarte scurte și ușor de citit;
● rulează la apăsarea unui buton, fără configurări suplimentare.
Testele unitare sunt scrise de programator, în timp ce implementează o funcționalitate.

Test First Programming este o metodă de a scrie teste care implică următorii pași:
● crearea unui design pentru implementarea de funcţionalităţi;
● crearea minimului de cod necesar (compilabil, dacă limbajul folosit este compilat) pe
baza design-ului;
● scrierea unuia sau mai multor teste care codează ceea ce trebuie să facă design-ul;
Test Driven Development (TDD) este o altă metodă de a scrie teste. De fapt, TDD este o
metodă de a face design incremental.
Greșeli comune
Câteva greșeli comune legate de unit testing sunt:
● Scrierea multor teste de integrare(care implică mai multe clase sau module) lente și
fragile în detrimentul testelor unitare mici, rapide și ușor de întreținut;
● Abandonarea dublelor de testare, sau folosirea lor în scopuri pentru care nu au fost create.
Dublele de testare ajută la obținerea unor teste scurte și rapide;

27
 ● Numele testelor nu exprimă comportamentul testat. Numele testului poate da foarte multe
informații atunci când testul pică;
● Folosirea intensivă a debugger-ului (depănarea) pe teste. Testele bine scrise vor spune
imediat unde este problema în cazul în care pică. Debugging-ul este în continuare util în
situații exotice;
● Cod de testare neîngrijit. Codul de testare este cel puțin la fel de important ca și codul de
producție, și trebuie întreținut cu aceeași grijă.
2.Testarea integrării
După ce unitățile au fost scrise, următoarea etapă ar fi să le înteracționăm pentru a crea sistemul.
Aceasta se numește integrare.
Scopul testării de integrare este de a expune defectele interfețelor.
Testarea de integrare include:
● soft-ul și sistemul de proiectare;
● o diagramă a arhitecturii sistemului;
● fluxurile de lucru și cazuri folosite.
Există trei strategii de integrare
Integrarea big-bang
Sunt integrate într-un program executabil toate modulele existente la un moment dat. Metoda
este periculoasă căci toate erorile apar în același timp și localizarea lor este dificilă.
Acest tip de integrare este în general considerată ca o alegere proastă a strategiei de integrare.
Integrare de sus în jos (Top-down integration)
Se începe prin testarea modulului principal, apoi se testează programul obținut , și așa mai
departe. Componentele care apelează alții sunt de obicei plasate deasupra celor care sunt numite.
Testarea de integrare de sus în jos vă permite să evaluați componentele interfeței, de sus în jos
Integrare de jos în sus (Bottom-up integration)
Aceasta este opusul strategiii de sus în jos și componentele sunt integrate în de jos în sus.

3.Testarea de acceptare
Testarea de acceptare este o testare care are în vedere nevoile și cerințele utilizatorilor. Este o
metodă menită să determine dacă un sistem îndeplinește sau nu criteriul de acceptare. In același
timp, utilizatorul, clientul sau orice altă entitate asociată determină dacă accepta sau nu sistemul.
În cazul testarii de acceptare găsirea de defecte nu este scopul principal și nu este neapărat
ultimul nivel al testarii.
Testarea de acceptare se poate realiza pe mai multe nivele.
Forme obisnuite de testare de acceptare:
1. Testare de acceptare a utilizatorului: utilizatorul unui produs final efectuează testele. Setările
lor vor reprezenta un mediu de lucru și acopera toate ariile poriectului, nu numai ale sistemului.
2. Testarea de lucru presupune testarea unei rezerve(backup), refacerea în caz de dezastru,
mentenanța task-urilor și verificări periodice ale vulnerabilității securității.
28
3. Testarea privind acordul si reglementările reprezintă o demonstrație a criteriului de acceptare
care a fost definit în contract. Înainte ca produsul soft sa fie acceptat, este necesar să vizibil ca el
îndeplinește condițiile așa cum sunt specificate în contract. Acest tip de testare este efectuat
contrar oricărei reglementări la care produsul trebuie să adere cum ar fi guvernamentale, legale
sau de siguranță.
4. Testarea Alpha permite testării de către client. Oamenii care reprezintă ținta folosesc produsul
în același fel ca și cum ar fi cumparat versiunea finală. Această testare se realizează în casă (pe
site-ul dezvoltatorilor).
5. Testarea Beta se aseamana cu testarea Alpha, numai că utilizatorii efectuează testarea pe
propriile site-uri.
4.Testarea sistemului
După ce s-a verificat că componentele toate lucrează împreună la nivel de unitate, pasul următor
este de a lua în considerare funcționalitatea din perspectiva end-to-end. Această activitate este
numit testarea sistemului.
Testele de sistem sunt teste ale sistemului de programe și echipamente complet. Sistemul este
instalat și apoi testat în mediul său real de funcționare.
Acesta se realizează de obicei prin o echipa care este independentă de procesul de dezvoltare.
Avantajul acestei independențe este că o evaluare obiectivă a sistemului poate fi făcută, în baza
specificațiilor scrise, și nu a codului.
Sunt teste în conformitate cu specificația cerintelor de sistem (produs soft):
● teste functionale, prin care se verifica satisfacerea cerintelor functionale
● teste prin care se verifică satisfacerea cerintelor ne-functionale :
o de performanță,
o de fiabilitate,
o de securitate, etc.
Adesea, testele de sistem ocupă cel mai mult timp din întreaga perioadă de testare
Exemple de cerințe non-funcționale:
Procedurile de instalare - Installability.
Mentenabilitate - capacitatea de a introduce modificări ale sistemului.
Performance - așteaptă un comportament normal.
Manipularea de încărcare - comportamentul sistemului în creștere.
TEMA 7: Testarea statică și modul de organizare a revizuirii statice
Unitatea de învățare: Planificarea procedurilor de testare. Realizarea procesului de testare
TEMA 7: Testarea statică și modul de organizare a revizuirii statice

Competențe elementare formate în cadrul modului:

Planificarea procedurilor de testare. Realizarea procesului de testare.
Abilități formate:
A2. Elaborarea sub îndrumare a planului de testare
29
 A3. Stabilirea activităților testerului la diferite etape de testare.
A4. Revizuirea caietului de sarcini.
A5. Revizuirea documentației proiectului;
A9. Selectarea criteriilor de testare;
A10. Elaborarea cazurilor de test în baza specificațiilor.
Termeni cheie:
Testare statică
Inspecție/ revizuire (review)
Grad de formalitate
Eroare de sintaxă
Eroare semantică

Metodele statice testează produsul program fără ca el să fie executat. Totuși prezintă
importantă deosebită prin abilitatea de a depista erorile şi defectele înainte de executarea codului,
în primele etape ale desfășurării proiectului, facilitând şi reducând din cheltuielile necesare
pentru depistarea şi corectarea aceleiași greșeli într-o etapă mai avansată. Printre aceste metode
se regăsește și tehnicile de inspecție (review).
În această temă vom cerceta și analiza statică a codului dezvoltat, considerat o tehnică de
examinare a codului fără activarea lui pentru a identifica problemele actuale sau potențiale.
Testarea statică deseori este imposibil de realizat manual, astfel vom cerceta tipurile testării
statice care solicită anumite mijloace (instrumente).
Generalități despre tehnicile statice
Tehnicile testării statice presupun tehnicile de testare a soft-ului care nu implică
executarea codului. Aceasta include:
● testarea produsului soft diferit de cod: cerințele tipice ori documentele ce conțin
specificațiile;
● testarea codului fără executarea lui.
Prima activitate se numește revizuire (inspecție) şi este utilizată de obicei pentru
înlăturarea erorilor şi ambiguităților din documente înainte de a fi folosite la dezvoltarea
proiectului, astfel eliminând o sursă a defectelor în cod.
A doua activitate e cunoscută sub numele de analiză statică şi permite cercetarea codului
de defectele structurale şi insuficiențele sistematice care pot favoriza defectele.
Inspecțiile sunt făcute manual, analiza statică se realizează de obicei automatizat cu
ajutorul unor instrumente.
Revizuirea este o examinare sistematică a documentului de către una sau două persoane
care au ca obiectiv detectarea şi înlăturarea erorilor. Încredințarea reexaminării primei variante a

30
documentului colegilor e cel mai simplu exemplu de revizuire şi care de obicei scoate la iveală o
mulțime de erori anticipate.
Revizuirea se aplică documentelor scrise sau tipărite: documente ca specificațiile
cerințelor, 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
conțin specificații prin revizuirea lor la etapa inițială a ciclului de înființare a soft-ului
favorizează detectarea defectelor înainte de a fi incluse în codul sursă. Astfel reducând din
efortul şi cheltuielile necesare pentru înlăturarea defectelor, acelaşi 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.
Inspecția codului conform standardelor de dezvoltare poate preveni apariția defectelor la
executarea testului. Dar şi în aceste cazuri, dacă codul a fost scris nu se pot evita unele cheltuieli.
Pe lîngă economisirea timpului şi a finanțelor există şi alte avantaje ale depistării timpurii
a defectelor în perioada de dezvoltare:
● Poate fi îmbunătățită productivitatea şi reducerea limitelor temporale deoarece
corectările defectelor într-o etapa cît mai timpurie vor asigura că produsul este clar şi
neambiguu. Aceasta ar trebui să-l ajute pe dezvoltator să se miște mai repede în
procesul de scriere a codului. De asemenea, dacă defectele s-au înlăturat înainte ca
proiectul să devină cod se vor detecta şi fixa mai puține erori pe parcursul executării
testării ulterioare.
● Costul şi timpul testării poate fi redus prin înlăturarea principalelor întîrzieri ale
testului, care au loc când defectele sunt depistate după ce devin eșecuri şi testorul
trebuie să aștepte corectarea soft-ului. Revizuirea codului şi detectarea defectelor
înainte de a deveni eșecuri îi permite testorului executarea mai rapidă a testării.
● În realitate e posibilă obținerea reducerii costului datorită numărului mic de defecte în
final, care asigură că cheltuielile curente vor fi reduse.
● Comunicarea constructivă se datorează autorilor şi colegilor care cercetează şi
înlătură orice ambiguitate descoperită în timpul revizuirii pentru a asigura că orice
participant a înţeles exact ceia ce se livrează.
Cele mai tipice greșeli depistate la revizuire:
● Abaterile de la standardele interne şi reglementărilor/legilor definite în legislație sau
de o organizația comercială.
● Defectele cerințelor - de exemplu: cerințele sunt ambigue sau au unele elemente lipsă.
● Defectele de design - de exexemplu design-ul nu respectă toate cerinţele.
● Insuficiența stabilității - de exemplu codul este prea complex şi greu de menținut.
● Interfața incorectă a specificațiilor - de exemplu interfața specificațiilor nu
corespunde design-ului sau interfețelor de transmitere sau primire a datelor.

31
 Orice revizuire are ca scop depistarea defectelor, unele însă evidențiază anumite tipuri de
defecte mai efectiv şi mai eficient decât altele.
Procesul de revizuire
Procesele de revizuire variază vizibil în dependență de gradul de formalitate - cînd
formalitatea se asociază cu nivelul structurii şi documentarea cu activitatea. Unele tipuri de
reexaminare au caracter informal, pe când altele sunt foarte formale. Stabilirea gradului de
formalitate se bazează pe combinarea următorilor factori:
● Maturitatea procesului de dezvoltare: cu cît acesta este mai matur cu atît revizuirea
este mai formală.
● Cerințele legale sau reglementare. Acestea se folosesc la administrarea activității de
dezvoltare a soft-ului în anumite industrii, obligator în ariile de strictă-securitate ca de
exemplu semnalizarea căilor ferate.
● Necesitatea unei proceduri de audit. Procesele formale de revizuire asigură
posibilitatea unei retrospective a procesului de dezvoltare a soft-ului. Nivelul
formalității 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.
● Înțelegerea..
● Generarea discuțiilor.
● Deciziile luate în consens.
Modalitatea revizuirii se stabilește în dependență de obiectivele specifice. Deci o
revizuire orientată spre detectarea defectelor se va deosibi de una care reflectă înțelegerea unui
document.
Procesul fundamental de revizuire
Toate tipurile de revizuire manifestă aceleași elemente fundamentale ale procesului:
● Documentele aflate în curs de examinare se studiază de către 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 acțiuni să adopte ca răspuns la comentarii şi asupra adaptării
documentului la acestea.

32
 Procesul de bază se realizează permanent, dar în unele examinări formale se includ etape
suplimentare, se insistă mai mult pe
documentare şi pe măsurare.
Etapele reexaminării formale
Revizuirile din spectrul oficial ca
și revizuirile tehnice şi inspecțiile, dețin
anumite caracteristici prin care se
deosebesc de cele mai puțin oficiale.
În figura alăturată se
demonstrează etapele cheie ale
revizuirii formale:
Planificarea:
Selectarea personalului -
asigurarea că cei aleși pot şi vor adăuga
valoare procesului. Există un criteriu de
selectare a revizorilor care vor fi de-
acord cu cele scrise de autor. Se recomandă includerea unor revizori din diferite departamente ale
organizației, care au renume de oameni pretențioși şi imparțiali. 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 – opoziționistul greu de împăcat. La etapa inițială a procesului de
revizuire se stabilește un revizor lider. Acesta va dirija activitatea de revizuire.
Repartizarea rolurilor - fiecare revizor primește o anumită sarcină. Cineva poate testa
testabilitatea şi claritatea definiției, altcineva – simplitatea şi claritatea relațiilor comerciale. Toți
revizorii care lucrează la același document au diferite perspective asupra acestuia.
Definirea criteriului de intrare şi ieşire, în special pentru tipurile de revizuire formală
(de exemlu inspecţia).
Selectarea părților documentelor care trebuise revăzute (nu întotdeauna necesară,
aceasta depinde de mărimea documentelor: un document mai mare necesită împărțirea lui în părţi
mai mici şi analiza fiecărei părți de persoane diferite pentru a se asigura că documentul este
revizuit în întregime).
Startul: distribuirea documentelor, explicarea obiectivelor, procesului şi documentelor
participanților, verificarea criteriului de intrare. Aceasta poate fi desfășurată ca o întrunire sau
simplu prin distribuirea detaliilor revizorilor. Metoda utilizată depinde de limitele temporale şi de
volumul de informație. Un volum impunător de informație poate fi împărțit mai bine la o
întîlnire decît prin citirea paginilor de către utilizatori.
33
 Pregătirea individuală: munca efectuată individual de fiecare participant înaintea
întrunirii, care presupune citirea documentelor sursă, consemnarea potențialelor defecte, întrebări
şi comentarii. Aceasta este principala sursă şi poate fi constrînsă de timp, participanţii primesc 2
ore pentru a-şi definitiva pregătirea.
Întrunirea de revizuire: aceasta poate include discuțiile referitoare la orice defect găsit.
Inspecția, un tip de revizuire mai formală, va documenta rezultatele. Participanții ședinței pot
doar nota defectele care urmează să fie corectate de autor. De asemenea pot face recomandări
pentru corectarea defectelor .Determinarea abordării se bazează pe unul sau pe toți factorii de
mai jos:
Timpul disponibil - dacă dispunem de puțin timp întrunirea poate doar colecta defectele.
Cerințele autorului - dacă autorul acceptă ajutor la corectarea defectelor.
Tipul revizuirii - în cazul inspecției se permite doar colectarea – nu există nici o discuţie.
Refacerea: după întrunirea de revizuire autorul va avea mai multe defecte de corectat,
corectarea defectelor se numește refacere. Autorul va înlătura problemele depistate şi va
confirma necesitatea rectificării.
Continuarea: liderul reexaminării va verifica dacă defectele acceptate au fost localizate
şi va determina de cât timp a fost nevoie pentru revizuire şi cât de multe defecte au fost depistate.
Acesta va mai verifica criteriile de ieșire (pentru inspecție) pentru a garanta îndeplinirea lor.
Rolurile şi responsabilitățile
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 cerințelor).
În afară de acestea procesul de revizuire definește el singur roluri specifice şi
responsabilități 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 activităţile de reexaminare
necesare, şi determină dacă au fost realizate obiectivele analizei. Managerul nu se implică în
procesul actual de revizuire decât în cazul când poate adăuga ceva important, de exemplu dacă el
posedă cunoştinţe 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 acțiunilor rămase. La fel va realiza decizia finală despre ce trebuie
inclus în documentul de informare.

34
 Autorul: este cel care a scris sau persoana responsabilă de dezvoltarea documentului care
trebuie revizuit. Autorul va prelua în diferite instanțe responsabilitatea de a localiza şi aproba
greșeala.
Revizorii: Acestea sunt persoanele cu cunoștințe tehnice ori comerciale speciale (numiți
încă verificatori şi inspectori), care după o pregătire adecvată, identifică şi descriu cele observate
(de ex. defectele) produsului revizuit. După cum am menţionat mai sus inspectorii trebuie aleşi
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 pârțile discutabile care au fost depistate.
Un rol indirect asociat cu revizuirea e cel al testorului. El deține un rol aparte în relația cu
documentul reexaminat. El va fi solicitat să analizeze documentul pentru a permite dezvoltarea
testului. La analiza documentului acesta testorul va stabili scenariul, va nota dacă este vreo
lacună în cerințe care ar stopa funcționarea produsului, așa ca lipsa unui proces sau absența unor
date la momentul dat. Efectiv testorul ar putea fi invitat oficial al activității de revizuire sau ar
putea renunța la acesta.
Tipurile de revizuire
Un singur document poate fi supus mai multor tipuri de revizuire: de exemplu o revedere
informală poate precede o analiză tehnică, sau depinde de gradul de risc, revizia tehnică sau
inspecția se poate aplica înaintea controlului împreună cu cumpărătorul.
Fiecare tip de revizuire are caracteristicile sale. Am identificat patru tipuri de analiză care
definesc gradul de formalitate. Acestea sunt cunoscute ca :
1. Revizuire neoficială ( cea mai puțin formală). Caracteristici:
• Nu există un proces oficial care ar motiva revizuirea.
• Revizuirea ar putea fi documentată, dar nu se cere aceasta; multe reexaminări
neoficiale nu se documentează.
• Se pot produce unele modificări (depinde de revizor) pentru eficacitatea revizuirii, de
exemplu revizorul nu posedă abilități tehnice, doar este împuternicit să verifice repede
şi să asigure semnificația 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 (cînd unul verifică
codul celuilalt) sau de o abordare tehnică de revizuire a codului şi design-ului.
2. Analiza codului. Caracteristici:
• Întrunirea e condusă de către autorul documentului care va fi revizuit şi prezentat de
colegii autorului, membri ai aceluiași grup.
• Sesiunile de revizuire sunt finisate deschis şi pot varia în practică de la informale la
formale.

35
 • Pregătirea de către revizori înainte de ședința de analiză, raportul produsului de
revizuire ori lista cu cele depistate, şi întrevederea cu grefierul sunt acțiuni opționale,
care se îndeplinesc uneori.
• Principalul scop constă în oferirea posibilității de a studia conținutul documentului, ca
să ajute membrii echipei să înțeleagă conținutul documentului şi să găsească defecte.
• Analiza codului de obicei explorează scenariul, ori aplică o execuție artificială a
codului ori a procesului.
3. Revizuirea tehnică. Caracteristici:
• Este documentată şi utilizează un proces bine definit de detectare a erorilor care
include atât colegi cât şi experți tehnici.
• Este realizată ca o verificare amicală fără participare managerială şi este condusă de
un moderator, diferit de autor.
• Revizorii pregătesc întrunirea, uneori utilizând lista de verificare, şi un raport al
erorilor depistate.
• Revizuirile tehnice pot varia în practică de la informale la formale şi au un număr de
obiective, incluzând: dezbaterile, luarea deciziilor, evaluarea alternativelor, depistarea
defectelor, rezolvarea problemelor tehnice şi verificarea conform specificațiilor şi
standardelor.
4. Inspecția (un grad sporit de formalitate). Caracteristici:
• Inspecția 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 întrebări (checklists), şi
utilizează criteriul de intrare şi ieșire.
• Pregătirile preliminare întrunirii sunt esenţiale, şi includ citirea oricăror documente
pentru a asigura consistența.
• Se întocmește raportul privind inspecţia, cu lista celor depistate, care include date
(metricile) utile la îmbunătăţirea procesului, precum şi la corectarea defectelor în
documentul analizat.
• Întrunirea este urmată de un proces care asigură că acţiunea 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 inspecție. Aceasta este viziunea clasică asupra
revizuirii. Esențialul pentru fiecare companie este stabilirea obiectivelor şi avantajelor revizuirii
plănuite.
Factorii care asigură succesul revizuirii.
Cînd contăm pe succesul unei revizuiri trebuie să avem în vedere următorii factori:
• Fiecare revizuire presupune obiective clare prestabilite şi acceptate cât şi alegerea
persoanelor adecvate pentru desfăşurare ei astfel asigurând îndeplinirea obiectivelor.

36
 De ex. în timpul unei inspecţii orice revizor va avea un rol definit şi trebuie să aibă
experienţă pentru a-şi îndeplini funcţia.
• 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 ceilalţi participanţi).
• Tehnicile de revizuire (formale şi informale) trebuie să fie potrivite pentru nivelul şi
tipul soft-ului testat şi pentru revizori (aceasta este foarte important în inspectări).
• Trebuie folosite checklist-le sau rolurile, pentru a spori efectivitatea de depistare a
defectelor; de ex. la o inspecţie roluri ca funcţionar data entry sau arhitect tehnic pot fi
solicitate la reexaminarea unui document particular.
• Suportul managerial este esenţial pentru un proces reuşit de revizuire (prin acordarea
timpului necesar revizuirii adecvat programului).
Metricile utilizate în testarea statică:
• Numărul defectelor depistate.
• Timpul necesar revizuirii/ inspecţiei-
• Procentajul bugetului utilizat/ economisit pentru proiect.
În exemplarul său original referitor la inspecțiile sale în 1976, Michael Fagan de la IBM,
care a dezvoltat Metodele de Inspectare Fagan, a raportat 23% progres în coding productivity
(în productivitatea codării) datorită inspecției. Succesul poate fi obținut prin mai multe
modalități, totuşi trebuie mai întîi 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 fără a activa codul. Dar spre deosibire
de reexaminare analiza statică se desfășoară după ce a fost scris codul. Obiectivul acesteia constă
în detectarea defectelor în codul sursă şi în modelele produsului soft.
Codul sursă este orice secvență de instrucțiuni scrise în unul din limbajele de programare,
limbaj ce poate fi citit de persoane, şi care poate fi convertit apoi într-un cod echivalent
executabil pentru computer - creat de dezvoltator.
Un model – produsul soft este imaginea unei soluţii finale dezvoltate utilizând tehnici ca
Unified Modeling Language (UML) - Limbajul de Modelare Unificat (LMU); generat de
designerul produsului soft.
Analiza statică poate depista defectele dificil de depistat la executarea testului prin
analizarea codului programei, exemplu: instrucțiunile pot avea forma unui control flow graph
(cum se realizează controlul printre module) şi data flow ( asigurarea că datele sunt identificate
şi utilizate corect).

37
 Importanța analizei statice constă în:
• Detectarea defectelor înainte de executarea testului. Dar referindu-ne la revizuire cu cât
mai devreme se găseşte defectul, cu atât mai simplă şi mai ieftină este înlăturarea lui.
• Prevenirea unor aspecte suspicioase codului sau design-ului, prin calcularea datelor,
astfel ca măsurarea extra-complicată. Dacă codul e prea complex poate fi predispus
greşelilor sau mai puţin dependent de orientarea atribuită codului de către developator.
Dacă ei înţeleg 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 conţine defecte.
• Identificarea defectelor depistate cu greu de testarea dinamică, aşa ca dezvoltarea
standard a lacunelor. De asemenea detectarea dependenţelor şi inconsistenţelor în
modelele soft, aşa ca conexiunile şi corelaţiile de care nu se ştia sau erau incorecte până
la realizarea analizei statice.
• Îmbunătățirea întreținerii codului şi design-ului. Prin realizarea analizei statice se vor
înlătura defectele şi va spori mentenanța necesară după înființare. Pot recunoaşte de
asemenea un cod complex care corectat l-ar face mai simplu de înțeles şi mai uşor de
întreținut.
• Prevenirea defectelor. Prin identificarea defectelor în primele etape ale ciclului de
dezvoltare e cu mult mai uşor de identificat cauza originală (analiza cauzei de bază
( root cause analysis) decât în timpul execuţiei testului, astfel furnizând informaţie
despre posibilele îmbunătățiri ale procesului care ar putea preveni reapariția aceluiaşi
defect .
Descoperirea defectelor prin utilitarele analizei statice:

38
 • 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 foloseşte de ea, aceasta presupune ca unele
părţi necesare ale programei să fie întâmplător 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 programării, dacă standardele prevăd adăugarea
comentariilor doar la sfârșitul unei părţi a codului, dar există explicaţii prin tot codul,
aceasta va fi o violare a standardelor codului.
• Vulnerabilitatea securității, exemplu: structurile password care nu sunt sigure.
• Violarea sintaxei codului şi modelelor soft, de exemplu utilizarea incorectă a
limbajului de programare sau de modelare.
Mijloacele analizei statice au mai multă valoare utilizate împreună cu testarea
componentelor şi testarea de integrare. Aceasta presupune verificarea de către dezvoltatori
conform regulilor predefinite ori standardelor de dezvoltare şi de designeri în timpul modelării
soft-ului.
Mijloacele analizei statice se desfășoară automat şi raportează toate defectele identificate.
Unele dintre ele pot fi nesemnificative şi necesită puțin efort pentru rectificare, pe când altele
mai serioase solicită corectarea imediată. Aceste defecte necesită un important management
pentru a se asigura că s-a obținut un beneficiu deplin datorită utilizării mijloacelor în primul
rând. Compilatoarele soft-ului sunt programele computerului (sau un set de programe) care
traduc codul scris în unul din limbajul computerului (limbajul țintă). Ca parte a procesului de
compilare, desigur analiza statică întreprinde identificarea unor defecte şi va furniza calculele
metrice ale soft-ului.
După caracterul său erorile în cod se împart în: erori de sintaxă și erori de semantică
(logice);
Erorile de sintaxă – sunt neajunsuri, neclarități în scrierea codului, ce sunt legate du
introducerea eronată a instrucțiunilor, scrierea incorectă a identificatorilor și alte4 acțiuni
incorecte. Eroarea de sintaxă este găsită foarte rapid de către compilator, deoarece compilatorul
va genera produsul program doar în cazul înd în cod vor lipsi erorile de sintaxă. Deci, erorile de
sintaxă, în produsele program, sunt depistate în mod automat în procesul de compilare.
Erorile semantice – sunt erorile în logica lucrului programului. Codul produsului
program poate arăta absolut corect, dar în același timp să lucreze incorect. Astfel de erori sunt
depistate și corectate destul de dificil. Erorile logice deseori sunt legate cu realizarea incorectă a
algoritmului programului (de exemplu în loc de ”c+b” a fost scris ”c-b”, a fost admisă
39
necorespondența internă dintre variabile și operatori, cît și a regulilor generale de programare).
Formele de bază a erorilor logice:
• Programul într-un moment anumit nu mai poate prelungi executarea ( apare așa
numita întrerupere forțată a programului, de obicei cu indicarea locului în program,
care a generat această întrerupere);
• Programul funcționează, dar nu afișează toate rezultatele planificate sau nu se oprește
(are loc ”ciclarea” programului”);
• Programul afișează rezultatele și finisează lucrul, dar aceste rezultate corespund
parțial sau totalmente nu corespund cu
rezultatele de control;
Cele mai frecvente tipuri de erori pot fi depistate cu
ajutorul mediilor de programare. Pentru aceasta în setările
proiectului se stabilesc anumiți parametri: controlul ieșirii
indicilor din limitele masivului, controlul erorilor de
intrare/ieșire, adăugarea informației de depănare,
vizualizarea structurii codului ș.a. De exemplu fereastra
opțiunilor proiectului în mediul DELPHI:

După identificarea erorilor logice și eliminarea cauzelor apariției acestora în program se

efectuează corecțiile corespunzătoare, și depanare continuă din nou. Și acest lucru este repetat de
mai multe ori. Cu toate acestea, chiar și în procesul de depanare nu este întotdeauna posibil să se
identifice toate erorile.
În prezent pentru reducerea timpului ți a costurilor pentru desfășurarea testării se folosesc
mijloace speciale de testare (de exemplu: generatoare de date de testare) și metode de depănare
(cum ar fi trasarea programului, ce permite să verificam, dacă toate ramurile programului au fost
implicate în rezolvarea problemei cu setul de date inițial).
În mediul Visual Studio (redacția Ultimate) există instrumentul de analiză arhitecturală:
Arhitecture Explorer, care permite crearea și vizualizarea grafurilor diagramelor aplicației.
Analiza metricilor codului aplicației și multe alte facilități pentru analiza statică a codului
aplicației.

TEMA 8: Mentenanța și documentarea procesului de testare

Unitatea de învățare : Descrierea tipurilor de testare
Mentenanța produsului soft presupune finalizarea dezvoltarii produsului prin predarea
documentației, soluționarea disfuncționalităților sesizate în etapa anterioară, sesiuni de training
cu viitori utilizatori sau realizarea de tutoriale pentru a crește gradul de accesibilitate al
produsului. De asemenea, dezvoltatorii unui produs soft vor oferi suport celor care îl utilizează
40
de-a lungul timpului pentru a asigura buna sa funcționare și a repara eventualele erori apărute. În
plus, este posibilă îmbunătățirea unui produs soft, caz în care documentația originală va fi
necesară.

Cauze ce pot duce la apariția defectelor in produsul soft:

● Nimeni nu este perfect, oricine poate face greșeli
● Presiunea crescută poate duce la greșeli
● Restricțiile de timp și buget
● Pregatirea slabă, comunicarea ineficientă
● Cerințe slabe
● Specificații incomplete
Dacă se oprește testarea prea devreme, se riscă apariția de erori la rularea propriu-zisă a
sistemului. Dacă testarea continuă pentru o perioadă prea lungă se poate amîna lansarea
produsului, fapt ce poate duce la degradarea imaginii companiei sau chiar pierderi de venituri.
Corectarea erorilor descoperite pe parcursul integrării necesită repetarea procesului de
proiectare, codificare și testare a modulelor. Principalele erori de proiectare sunt descoperite de
abia la sfîrșit, cînd sunt testate modulele principale ale programului, ceea ce conduce la
reproiectare și reimplementare. Scopul primordial pentru procesul de testare este identificarea
erorilor de produse soft, izolarea și corectarea defectelor care au cauzat aceste erori. Este un
exercițiu non-trivial, deoarece testarea nu poate demonstra cu certitudine de 100 % că produsul
funcționează corect în orice condiții; testarea doar poate demonstra că produsul nu funcționează
corect în anumite condiții.
Testarea regresivă prezintă testele executate după corectarea erorilor, pentru a se verifica dacă
în cursul corectării nu au fost introduse alte erori. Aceste teste sunt efectuate de regulă în timpul
întreținerii. Pentru ușurarea lor este necesar să se arhiveze toate testele efectuate în timpul
dezvoltării programului, ceea ce permite, în plus, verificarea automată a rezultatelor testelor
regresive. Testarea regresiei reprezintă testarea unui program testat anterior care a suferit
modificări pentru a se asigura că nu au fost introduse sau ascunse defecte ca rezultat a
modificarilor făcute. Acest tip de testare este realizat atunci cînd este schimbat soft-ul sau
mediul. Măsura în care se realizează testarea regresiei este bazată pe riscul negăsirii defectelor în
soft-ul care a funcționat anterior. Acest tip de testare este la toate nivele de testare. Testările sunt
necesar de reluat atunci cînd se verfică actualizările soft-ului. Aceste teste trebuie reluate atunci
cînd se semnalează o modificare în produs soft sau mediu și sunt utilizate pentru a se dovedi că
nu au fost schimbate aspecte ale sistemului sau componentelor. Selecția cazurilor de test pentru
testarea regresiei cuprinde:

41
 ● Teste care acoperă funcții critice de securitate
● Teste pentru arii care se schimbă în mod regulat
● Teste ale funcțiilor care au nivel mare de defecte
*Testarea regresiei reprezintă un candidat ideal pentru Automatizare.
Testarea regresiva se efectueaza pentru a ne da seama daca o schimbare aplicata unui produs soft
reprezinta un pas inapoi sau un pas inainte.
Ea se foloseste pentru a determina daca o schimbare nu cumva aduce mai mult rau decat bine:
daca acea schimbare duce la regres sau, dimpotriva, la progres.
Testarea regresiva se efectuează pentru a vedea dacă schimbările aduse unei componente a
produsului soft au creat noi defecte sau au redus fiabilitatea, performanta sau funcționalitatea
produsului soft din care face parte componenta respectiva.
BUG (defect, greșeală, problemă) - este un defect într-un sistem sau o componentă care cauzează
ca sistemul sau componentele respective să nu reușească să își îndeplinească funcția. Un defect,
dacă este întîlnit la execuție, poate avaria întregul sistem.
Termenul de “bug” este adesea folosit pentru a descrie o problemă într-un calculator. Există două
tipuri de bug-uri: cele de produs soft și cele de hardware. În această privință testarea produsului
soft nu ar trebui asociată cu debugging. Debugging-ul este procesul de analiză și localizare a
bugului atunci cînd produsul nu se comportă conform așteptărilor. Erorile de programare în
produsul soft, aşa-numitele bug-uri, au cauzat de-a lungul timpului pagube uriaşe, de la pierderea
de vieţi omeneşti în aplicaţii militare până la milioane şi miliarde de dolari pe bursă sau în
misiuni de explorare a spaţiului.
Managementul proiectelor reprezintă o nouă știință, rezultat al sintezei unor domenii diferite,
avînd ca obiectiv maximizarea eficienței sociale, indiferent de produsul/serviciul ce trebuie
realizat.
Obiectivul de baza al managementului de proiect este minimizarea risipei generate de serviciile
asupra unor operații încheiate, inserarea de operații noi între operații executate, repetarea
execuției de operații, gestiunea riscului și menținerea sub control a elementelor de noncalități.
Toate acestea se concretizează prin definirea de termene, durate, cantități, niveluri de calitate,
momente de start și de finiș, durate și obiective de stationare.
În dezvoltarea unui proiect, se iau în considerare aspectele structurilor organizaționale,
constituirea echipelor, funcțiile de management, aspectele conflictuale, tehnicile de planificare și
variabilele care intervin, alocarea, nivelarea și încărcarea resurselor pe traseul de tip graf și
abordările în plan economic prin intermediul prețurilor estimate, controlului costurilor și, mai
ales, prin dezvoltarea unor tehnici de analiză.
Realizarea unui proiect și managementul acestuia sunt procese dinamice, care se conectează și a
căror eficiență trebuie urmarită continuu, analizîndu-se latura calitativă și latura cantitativă a
procesului de desfășurare, în raport cu conținutul contractelor încheiate.
Planificarea testelor se realizează în strânsă legătură cu planificarea derulării proiectului. In faza
de planificare a proiectului pentru testare se alocă resurse, specificându bugetul și perioada de
timp în care se va derula testarea. Pe baza acestora se realizează planificarea detaliată a
procesului de testare. Planificarea testării are scopul de a determina ce să testeze și cât să testeze,
astfel încât procesul de testare să se încadreze în limitele resurselor alocate.
Istrumente de urmărire a bug-urilor

42
Sistem de bug tracking - O aplicație soft care are ca rol ușurarea bug tracking-ului (este o metodă
eficientă centralizată și ușor utilizabilă.) Există soluții gratuite, dar și soluții enterprise cu prețuri
foarte ridicate. Un sistem de bug tracking este un subtip de sistem de issue tracking.
Sistem de issue tracking - O aplicație soft care are ca rol centralizarea și adresarea tuturor
cererilor legate de unul sau mai multe produse, de la probleme la schimbări de design și aplicări
de patch-uri. Cele mai multe sunt în același timp și bug trackere. În general, sunt mai complexe
decât bug trackerele.
TEMA 9: Testarea non-funcțională
Unitatea de învățare : Descrierea tipurilor de testare
Calitatea unui produs este uneori definita ca “ totalitatea caracteristicilor sale prin care el
satisface o serie de necesitati definite sau impuse”.
Calitatea unui produs soft este data de « capacitatea sa de a putea fi utilizat eficient, efectiv si
confortabil, de catre un set de utilizatori, pentru un set de scopuri, in conditii specificate ».
Caracteristicile de calitate ale unui produs soft sunt proprietati ale produsului la care utilizatorii
sunt sensibili. De exemplu : usurinta de utilizare, fiabilitatea, timpul de raspuns, s. a.
Exista diferite modele de clasificare a caracteristicilor (atributelor) de calitate ale unui produs
soft. Modelele includ adesea si masuri pe baza carora se stabileste gradul in care produsul
intruneste fiecare atribut de calitate. Fiecare model poate avea un set de atribute diferit la nivelul
cel mai inalt al clasificarii, de asemenea selectia si definitiile atributelor pot sa difere la toate
nivelele.
Calitatea ceruta pentru un produs soft trebuie sa fie definita in documentul de definitie a
cerintelor către produsul soft (SRD). De asemenea, trebuie specificate definitiile atributelor de
calitate, metodele de masurare si criteriile de acceptare pentru atribute.
1. Caracteristici de calitate ale produselor soft
Incercarile de standardizare a terminologiei referitoare la calitatea produselor soft au condus la
standardul ISO 9126 (InformationTechnology Sofware Product Quality, Part 1: Quality Model,
1998). Standardul contine definitii in special pentru produsul final.
Sunt definite 6 caracteristici de calitate, impartite in 21 de subcaracteristici.
1) Functionalitatea: realizarea scopului de baza pentru care a fost realizat produsul
● Oportunitatea: prezenta unui set de functii adecate pentru tascuri specificate
● Precizia: furnizarea unor rezultate sau efecte corecte sau agreate
● Interoperabilitatea: capacitatea produsului de a interactiona cu sisteme specificate
● Securitatea: capacitatea de a preveni accesul neautorizat, accidental sau deliberat, la
programe sau date
● Conformitatea: adeziunea la standarde, conventii, legi si protocoale

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

definite, pentru o perioada de timp definita.
● Maturitatea: atribut bazat pe frecventa caderilor datorate greselilor in produsul soft

43
 ● Toleranta la defecte (robustetea): capacitatea de a-si mentine un nivel de perfomanta
specificat in cazuri de caderi a produsului soft sau intrari neasteptate
● Restabilirea dupa caderi: capacitatea si efortul necesar pentru restabilirea nivelului de
performanta, recuperarea datelor afectate, dupa posibile caderi
● Conformitatea

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

● Usurinta de intelegere: efortul solicitat unui utilizator de a recunoaste conceptul logic si
aplicabilitatea sa
● Usurinta de invatare : efortul solicitat unui utilizator de a invata aplicatia, operarea,
intrarile si iesirile
● Operabilitatea: usurinta de operare si de control de catre utilizatori
● Puterea de atractie: capacitatea produsului de a fi atragator pentru utilizatori
● Conformitatea
4) Eficienta: relatia intre nivelul de performanta al produsului si cantitatea de resurse utilizate,
in conditii definite
● Timp la executie: viteza de raspuns, timpi de prelucrare, rata iesirilor la realizarea
functiilor
● Utilizarea resurselor: cantitatea de resurse utilizate si durata utilizarii pentru realizarea
functiilor sale
● Conformitatea
5) Usurinta de intretinere: efortul necesar pentru efectuarea modificarilor, inclusiv corectii,
imbunatatiri sau adaptari ale produsului la schimbari ale mediului de functionare, a cerintelor si
schimbarilor functionale
● Usurinta de analiza: efortul necesar pentru diagnoza defectelor, a cauzelor caderilor,
pentru identificarea partilor care trebuie sa fie modificate
● Usurinta de modificare: efortul necesar pentru inlaturarea defectelor sau schimbari
● Stabilitatea: riscul efectelor neasteptate in urma modificarilor
● Usurinta de testare: efortul necesar pentru a valida produsul modificat
● Conformitatea
6) Portabilitatea: capacitatea produsului de a fi transferat de la o organizatie sau platforma soft/
hardware la o alta
● Adaptabilitatea: capacitatea de adaptare la diferite medii specificate
● Usurinta de instalare: efortul necesar pentru instalarea produsului intr-un mediu
specificat
● Co-existenta: capacitatea de a co-exista cu alte produse independente in acelasi mediu
● Oportunitatea si efortul necesar pentru a folosi produsul in locul altui produs intr-un
mediu particular
● Conformitatea
44
Tipuri speciale de sisteme si cerintele de calitate
Exista multe cerinte de calitate particulare care se incadreaza sau nu in cele din ISO 9126.
Anumite clase speciale de aplicatii pot avea si alte atribute de calitate de considerat.
Exemple :
Sisteme ale caror caderi pot avea consecinte extrem de severe:
● Gradul de incredere al sistemului in ansamblul sau (hardware, software, oameni) este
scopul principal, in plus fata de cel de realizare a functiilor de baza
Un grad inalt de incredere include atribute ca: toleranta la defecte, siguranta I functionare,
securitatea, utilizabilitatea.
Sisteme inteligente si bazate pe cunostinte:
● Proprietatea “oricand” (garanteaza raspunsul cel mai bun care poate fi obtinut intr-un
timp dat daca se cere un raspuns in intervalul de timp respectiv)
● Capacitatea de explicare ( explica procesul de gandire la furnizarea unui raspuns).

● Sisteme de interfata cu omul si de interactiune

o Usurinta de adaptare la trasaturile si interesele utilizatorilor, Help inteligent,
s.a.
● Sisteme informationale
o Usurinta de interogare
o Precizie in furnizarea raspunsurilor (numai informatia relevanta)
Caracteristici de calitate a produsului soft, care afecteaza procesul de inginerie a
produsului
● Stilul codului
● Reutilizabilitatea codului
● Modularitatea codului si independenta modulelor
2. Asigurarea calitatii produselor soft
Rolul activitatilor de asigurare a calitatii produseelor soft este de a stabili ca produsele si
procedurile sunt in conformitate cu standardele si planurile.
In proiectele mici asigurarea calitatii poate fi efectuata de echipa de dezvoltare, dar in proiectele
mari trebuie sa fie realizata de o echipa speciala.
Activitatile de asigurare a calitatii sunt documentate in Planul de Asigurare a Calitatii (Software
Quality Assurance Plan (SQAP).
Prin activitatile de asigurare a calitatii se urmareste:
● Concordanta planurilor cu standardele
● Realizarea proceselor in concordanta cu planurile
● Implementarea produselor in concordanta cu planurile
Verificarea si validarea produsului soft sunt de asemenea activitati de asigurare a calitatii.
Ce este un sistem de asigurare a calităţii
45
Ansamblul activităţilor care trebuie întreprinse pentru ca un produs să fie de calitate

● Ce acoperă un Sistem de Asigurare a Calităţii:

a) Activităţile propriuzise de inginerie
- analiza;
- proiectarea (concepţia);
- codificarea
- testarea (metode şi instrumente)
b) Reviziile aplicate la fiecare pas al proiectului,
c) Strategiile de testare,
d) Controlul documentaţiei a produsului soft şi a susţinerii ei actuale,
e) Compatibilitatea cu standardele (dacă este cazul),
f) Mecanismele de măsurare şi raportare (pentru a avea o măsură cantitativă a calităţii)
TEMA 10: Tehnica de testare Black Box
Unitatea de învățare: Particularitățile testărilor
Tehnicile de proiectare a cazurilor de teste (case test) sunt grupate în trei categorii:
● Cele bazate pe cazuri de testare care rezultă direct dintr-o specificație, cum ar fi tehnici
black-box;
● Cele bazate pe cazuri de testare care derivă direct din structura unei componente sau a
unui sistem, cunoscut sub numele de tehnici de structură white-box;
● Cele bazate pe cazuri de testare care rezultă din experiența testerului, sistemelor similare
și experiența generală de testare, cunoscut sub numele de tehnici bazate pe experiență.
Black Box
Testarea domeniilor de valori, testarea funcțională, testarea bazată pe specificații, testarea axată
pe riscuri, testarea la limită, testarea de regresie, testarea bazată pe scenarii.
Este o tehnică de testare a produsului soft care se bazează în întregime pe cerinţele față de
produs şi specificaţiile acestuia.
Tipuri de testare Black Box
● Testarea funcțiilor (function testing);
● Testarea domeniilor de valori (domain testing);
● Testarea bazată pe specificații;
● Testare axată pe riscuri (risk-based testing);
● Testarea la limita (stress testing);
● Testarea de regresie;
● Testarea de către utilizatori;
● Testarea bazata pe scenarii;
● Testarea bazata pe stări (state-model-based testing);
● Testarea automata de volum ridicat;
● Testarea prin explorare;
Partiționarea în clase de echivalență

46
 ● Intrările sistemului sau al produsului soft sunt împărțite în grupuri pentru care se așteaptă
un comportament similar;
● Identificarea de partiții echivalente (sau clase) pentru: date valide și date invalide;
● Se aplică și pentru: ieșiri, valori interne, valori cu referire la timp (ce se modifică înainte
sau după apariția unui eveniment), parametri ai interfeței;
● EP este utilizată la toate nivelele de testare;
● Pentru un interval: va avea o clasă de valori valide(în interior) și două clase de valori
invalide(din ambele părți);
● Pentru un număr specificat: un caz valid și două cazuri invalide(mai mare, mai mic)
Testarea prin analiza valorilor marginale
● Se analizează comportamentul la marginea fiecărei partiții de echivalență.
● Testele trebuie create atât pentru valorile limită valide cât și invalide!
● Tehnica poate fi aplicată la toate nivele de testare.
Testarea prin utilizarea tabelului decizional;
Definiție: Un tabel de decizie este formularea cazurilor de test bazată pe deciziile luate; rezultă
astfel un proces de lucru cu un grad ridicat de acuratețe și completitudine.
Funcționalitatea sistemului este verificată de cazurile de test bazate pe logica de decizie din
cadrul sistemului. Numărul cazurilor de test depinde de cerințe.
Utilizare: Unit testing, Integration testing, System testing, Functional acceptance testing
Pasul 1: Determinarea condițiilor. Acestea se trec în subtabelul A a tabelului.
Pasul 2: Definirea acțiunilor. Acestea se trec în subtabelul B.
Pasul 3: Completarea subtabelului C – fiecare condiție devine adevarat o data și falsă o dată.
Pasul 4: Completarea subtabelului D – determinarea deciziilor care sunt imposibile și
combinarea cazurilor de test duble.
Pasul 5: Dacă este necesar, descrierea în limbaj natural a cazurilor de test.
Testarea prin tranziția stărilor;
● Sistemul este reprezentat printr-o diagramă de tranziție a stărilor;
● Stările sistemului sunt finite și identificabile.
Testarea folosind cazuri de utilizare
● Teste specificate în cazuri de utilizare sau scenarii business;
● Un caz de utilizare descrie interacțiunea între actori - utilizatori și sistem, ce produce un
rezultat cu o anumită valoare pentru utilizator;
TEMA 11: Tehnica de testare white-box
Unitatea de învățare: Tehnici de realizare a testării
TEMA 11: Tehnica de testare white-box.
Competențe elementare formate în cadrul modului:
Tehnici de realizare a testării.

47
 Abilități formate:
A15. Verificarea datelor de intrare.
A16. Verificarea corectitudinii procesării datelor;
A17. Verificarea datelor de ieşire;
A18. Verificarea completitudinii prelucrării datelor;
A19. Verificarea funcţionării corecte a ansamblului;
A20. Verificarea compatibilităţii componentelor;
A21. Depistarea erorilor de depănarea a programelor;
A22. Verificarea mecanismelor de protecţie.
A23. Verificarea stabilităţii produselor-program.
A24. Întocmirea documentaţiei rezultatelor testării;
A25. Verificarea performanţelor produsului-program;
A26. Verificarea funcţionalităţii produselor-program pe diverse platforme;
Termeni cheie:
Testare structurală;
Testare Whte-Box;
Graf;
Controlul fluxului;
Complexitatea ciclomatică;
Formula lui McCabe.
Obiective: Realizarea testării prin metoda White-Box.
Tehnica de testare White-Box (mai este numită cutie transparentă,) este o tehnică de
testare complementară metodei cutiei negre. În principiu, prin această metodă testul se
elaborează examinând detaliile programului: instrucţiuni, date etc. Ea poate fi utilizată
independent sau împreună cu metoda cutiei negre.
Dificultăţile în aplicarea acestei strategii sunt legate de prezenţa instrucţiunilor de decizie
(if, case etc.), a celor iterative (while, repeatj sau a celor de transfer (goto). Acestea determină
apariţia unui mare număr de combinaţii în care instrucţiunile elementare ale programului
(atribuiri, instrucţiuni de intrare/ieşire, apeluri de proceduri) pot fi executate. Ideal ar fi ca testul
să solicite executarea fiecărei combinaţii posibile cel puţin o dată. Din punct de vedere practic
acest lucru nu este realizabil, chiar în cazul programelor de dimensiune relativ mică. De pildă, în
cazul
while a do
if b then M
else P
dacă se execută n iteraţii, sunt posibile 2n combinaţii în care se execută instrucţiunile M şi P. În
48
testare exhaustivă ar trebui ca setul de date să conţină 2n eşantioane.
În realitate nu se testează decât un număr limitat de astfel de combinaţii, considerate mai
importante. În stabilirea acestui număr de combinaţii se utilizează diferite criterii de acoperire,
dintre care cele mai importante sunt:
1) acoperirea tuturor instrucţiunilor;
2) acoperirea tuturor ramurilor;
3) testarea condiţiilor:
● testarea condiţiilor de ramificare;
● testarea combinaţiilor condiţiilor de ramificare;
4) acoperirea tuturor căilor.
1.1. Acoperirea tuturor instrucțiunilor:
Acest criteriu se bazează pe observaţia evidentă că o eroare nu va fi descoperită dacă nu
se execută deloc instrucţiunile ce o conţin. Prin urmare, testul trebuie să fie astfel ales încât
pentru fiecare instrucţiune elementară a programului să existe un eșantion de date care să
provoace executarea sa.
Este clar însă că testul nu garantează semnalarea erorii.

Testele ce satisfac acest criteriu sunt în general

neconcludente deoarece același eșantion de date poate provoca executarea mai multor
instrucţiuni; este deci foarte probabil să putem minimiza numărul eşantioanelor din test,
menținând criteriul de acoperire a instrucţiunilor.
Pentru a trece prin toate nodurile, laturile grafului vor trebui traversate în următoarea
ordine:
a, b, f, g, h, d, e
Criteriul de completitudine a testului:
Acoperirea_instrucţiunilor = (număr_instrucţiuni_executate/număr_total_instrucţiuni)*100%
49
 Este cel mai slab dintre testele white-box deoarece poate lăsa nedetectate multe
defecte.
1.2 Acoperirea tuturor ramurilor.
Condiţiile din instrucţiunile de decizie şi iterative provoacă ramificări la executarea
programului. După cum acestea sunt adevărate sau false. Aceste ramificări pot fi puse în evidenţă
prin aşa numitul graf de control al programului. Acest graf poare fi construit inductiv pentru
programe ce conţin instrucţiuni elementare (adică atribuiri, instrucţiuni de intrare/ieşire, apeluri
de proceduri), instrucţiuni de decizie (if - then - else, if - then) şi instrucţiuni iterative (while,
repeat etc.).
Criteriul de acoperire a tuturor arcelor cere ca testul să fie astfel ales încât pentru orice
arc din graf (multigraf) să existe eșantioane care să provoace parcurgerea ramului la executarea
programului.
Observaţie 1. Criteriul de acoperire a tuturor arcelor este mai tare decât criteriul de
acoperire a tuturor instrucţiunilor.
Observaţie 2. Criteriul de acoperire a tuturor arcelor are calitatea că impune alegerea
unui test care să provoace evaluarea fiecărei condiţii cel puţin o dată atât cu rezultatul true cât şi
cu rezultatul false.
Exemplu:
- se observă că în testul din exemplul precedent ramurile c, i, k nu au fost testate;
- pentru a acoperi şi aceste ramuri, este necesar să mai fie executate următoarele teste:
• a, b, c, d, e;
• a, b, f, g, i, h, d, e;
• a, k, e.
Apare o anumită redundanţă datorită necesităţii de a parcurge anumite ramuri în cadrul
mai multor teste, dar acest lucru nu poate fi în general evitat;
Acoperirea_ramurilor =(Numărul_ramurilor_testate/Numărul_total_al_ramurilor)*100%
Este un criteriu mai bun decât acoperirea instrucţiunilor deoarece garantează şi acoperirea
acestora, dar preţul de cost este mai mare.
Permite testarea tuturor condiţiilor simple dar nu implică neapărat testarea condiţiilor
complexe.
1.3 Acoperirea tuturor condiţiilor simple
În cazul când în program există condiţii compuse de forma C and D sau C or D,
acoperirea tuturor arcelor nu conduce totdeauna la evaluarea condiţiilor C şi D atât cu rezultatul
false cât şi cu rezultatul true.
Este util prin urmare să considerăm un criteriu mai tare decât cel al acoperirii tuturor arcelor, prin
care se cere ca testul să acopere toate arcele şi să asigure evaluarea tuturor condiţiilor simple
atât cu rezultatul true cât şi cu rezultatul false. Acest criteriu este echivalent cu acoperirea
50
tuturor arcelor, dacă programul conţine doar condiţii simple, în care nu apar operatorii logici and
sau or.
Cazuri particulare:
1. Se formulează următorul criteriu, numit acoperire multiplă a tuturor condiţiilor
simple: testul trebuie să asigure evaluarea condiţiilor simple cu rezultatul true şi false în toate
combinaţiile cerute de structura condiţiei compuse în care ele apar. De pildă, în cazul C and D se
obţine pentru perechea de condiţii simple (C, D) patru combinaţii: (false, false) , (false, true) etc.
Acest criteriu este strict mai tare decât acoperirea tuturor condiţiilor simple.
Exemplul. Fie instrucţiunile
if (x <> 0) and (y <> 0) then
z := 1 else z := 1 / (xy + x
+ y)
Testul { (x = l, y = 0) ; (x = 0, y =1); (x =l, y =l)} acoperă toate condiţiile simple dar nu
provoacă evaluarea (false; false). El este de altfel neconcludent. Eroarea este descoperită chiar
prin eşantionul (x = 0, y = 0) care adăugat la testul considerat acoperă multiplu toate condiţiile
simple. Pentru acest program, acest criteriu este mai bun decât acoperirea tuturor condiţiilor
simple.
2. Se consideră un program P în care executarea este dirijată doar prin expresii logice
(condiţii), alte mecanisme (precum instrucţiunea case) sunt excluse. Fie C1, ..., C« toate
condiţiile care apar în P. Se consideră toate sistemele de valori logice w = (v1, ., v«), unde vi e
{true, false} pe care le pot lua aceste condiţii. Se formulează următorul criteriu, numit
acoperirea tuturor atribuirilor logice: testul trebuie să asigure evaluarea condiţiilor astfel încât
să se obţină toate sistemele w. Acest criteriu este strict mai tare decât acoperirea tuturor arcelor.
Exemplul 2. Fie instrucţiunile
if x = 0 then z : = 0 else z := l;
if y = 0 then z := 0 else z := l / (x + y)
Testul { (x = 0, y = l) ; (x = l, y = 0) } acoperă toate arcele dar nu acoperă toate atribuirile
logice; sistemele (true, true) şi (false, false) nu sunt evaluate. Testul trebuie completat cu alte
două eşantioane, de pildă (x = 0, y = 0) şi (x = 1, y = l). Primul face ca testul să devină
concludent (criteriul este mai bun).
1.4 Acoperirea tuturor drumurilor
În conformitate cu acest criteriu, pentru fiecare drum al grafului de control testul
conţine eşantioane prin prelucrarea cărora executarea programului să urmeze drumul ales.
Acest criteriu este strict mai tare decât cele prezentate înainte şi exprimă un deziderat
greu de realizat în practică datorită instrucţiunilor iterative. Criteriul poate fi însă aplicat în forme
mai slabe, selectând pentru testare doar anumite drumuri considerate critice. Deşi această selecţie
este dependentă de problemă, ea poate fi totuşi ghidată de sugestia ca datele de test să provoace
parcurgerea unor drumuri ce corespund:
● numărului minim de iteraţii (adică nici o iteraţie în cazul while şi o iteraţie în cazul
repeat);
● numărului maxim de iteraţii;
● numărului mediu de iteraţii, dacă acesta poate fi stabilit într-un fel oarecare; în caz
contrar se acceptă o executare cu un număr semnificativ de iteraţii.
Exemplul 3. Să considerăm cazul unui algoritm de căutare secvenţială a unei valori x
printre componentele v[i] , . . .v[n] ale vectorului v. Se presupune 0 < n < dmax.
const dmax =100;
type index = 1..dmax;
51
 numar_componente = 0..dmax;
element = integer;
vector = array[index] of element;
function secvential ( x : element; v : vector; n : numar_componente ) : boolean;
var gasit : boolean;
pozitie : index;
begin
gasit := false; pozitie := 1;
while (not gasit) and (pozitie < n) do
begin
gasit := (v[pozitie] = x ) ;
pozitie := pozitie + 1 ;
end;

while (not gasit) and (pozitie < n)

Fig. 1.
Graful asociat acestui algoritm este prezentat în figura 1.
TESTARE: Este important ca setul de date de test să asigure:
- parcurgerea drumului în care instrucţiunea while nu este executată (n = 0);
- parcurgerea unui drum în care instrucţiunea while se execută în zero iteraţii (n = i);
- parcurgerea unui drum în care instrucţiunea while se execută în câteva iteraţii, distingînd
situaţiile în care x face sau nu parte din secvenţa v[1]. . .v [n] .
Considerăm testul :

Nr. x v n Rezultat
1 10 () 0 0
2 10 (10) 1 0
3 10 (10, 20, 30) 3 1
4 20 (10, 20, 30) 3 2
5 30 (10, 20, 30) 3 0
6 0 (10, 20, 30) 3 0
7 0 (10) 1 0

Acesta este un test concludent, deoarece în cazurile 2 şi 5 este semnalată o eroare. Aceste
eşantioane au valoarea x pe ultima poziţie a vectorului. Depanarea algoritmului constă în
înlocuirea condiţiei (poziţie < n) prin (poziţie <=n).
52
 2. Numărul ciclomatic al grafului fluxului de control
Nici o discuţie la testarea fluxului de control poate fi încheiată fără a prezenta testarea
structurilor, cunoscută şi sub numele de testarea căilor principale. Testarea structurată este bazată
pe munca de pionier al lui Tom McCabe. Aceasta foloseşte analiza topologiei grafului fluxului de
control pentru a identifica cazuri de teste.
Procesul de testare structurală constă din următorii paşi:
1. Extragem graful fluxului de control din modelul produsului soft;
2. Calculam numărul ciclomatic al grafului (C);
3. Selectăm un set de C căi de bază;
4. Cream un caz de testare pentru fiecare cale de bază;
5. Executam aceste teste.
Complexitatea ciclomatică, calculată cu formula lui McCabe:
V(G)=E-N+2
unde:
E - numărul ramurilor din graf;
N - numărul nodurilor grafului.
Numărul Ciclomatic este exact numărul minim de căi independente, căi fără bucle
(numite căi de bază) care pot, în combinaţie lineară, să genereze toate căile posibile dintr-un
modul. În termeni de flux grafic, fiecare cale de bază traversează măcar o ramură pe care no
traversează celelalte căi.
Tehnica de testare McCabe creează C cazuri de testare, câte unul pentru fiecare cale.
Acest set de teste garantează atât acoperirea pe instrucţiuni cât şi pe ramuri. Seturile de căi de
bază nu sunt neapărat unice.
Exemplu Acoperirea căilor.
Fie că avem o funcţie ce calculează preţul în baza mai multor criterii: discount, cantitate.
function calculare_pret(baseprice, specialprice, extraprice, discount: real;
extras: integer): real;
var
addon_discount, res: real;
begin
if (extras >= 3) then addon_discount := 10 else
if (extras >= 5) then addon_discount := 15 else
addon_discount := 0;
res := baseprice / 100.0 * (100 - discount) +
specialprice + extraprice / 100.0 * (100 - addon_discount);
calculare_pret := res;
end;

53
 V(G)=14-12+2=4

1. a-b-c-j-k-l-n

2. a-b-c-j-m-n

3. a-d-e-f-i-j-m-n

4. a-d-g-h-i-j-m-n
//testcase 01

price=calculate_price(10000.00, 2000.00,

1000.1. 3.0);

test_ok=test_ok&&(abs(price-12900.00)<0.01); a,
b, c, j, m, n

//testcase 02

price=calculate_price(25500.00, 3450.00,

6000.1. 6.0);

test_ok=test_ok&&(abs(price-12900.00)<0.01);

a, b, c, j, m, n

acoperire_ramuri=6/14*100%=43%
//testcase 03

price=calculate_price(10000.00, 2000.00,
1000.00,0,10);

test_ok=test_ok&&(abs(price-12900.00)<0.01);

a, d, g, h, i, j, k, l, n

//testcase 04

price=calculate_price(25500.00, 3450.00,

6000.00, 6,0);

test_ok=test_ok&&(abs(price-12900.00)<0.01);

a, b, c, j, k, l, n

acoperire_ramuri=12/14*100%=86%

Observaţie! Ramurile e şi f nu pot fi testate

deoarece nu este posibil ca simultan extras<3 şi
extras>=5
Testarea ciclurilor:
Dacă ciclul are de la 0 la n iteraţii, cazurile de test dezvoltate vor fi:
54
 ➢ 0 iteraţii;
➢ iteraţie;
➢ două iteraţii;
➢ k iteraţii k<n;
➢ n iteraţii
➢ n+1 iteraţii (dacă este posibil).
➢ Dacă ciclul are de la ni la n2 iteraţii, se va testa şi pentru k=n1 -1.
➢ Dacă este posibil, se va testa şi pentru n2+1.
➢ Se vor avea în vedere şi valori negative ale variabilei de ciclare.
Concluzii:
AVANTAJE DEZAVANTAJE

Avantajul principal – încrederea, că ● Numărul drumurilor poate fi foarte mare

fiecare ramură a codului va fi testată. (ciclurile!) și el nu pot fi testate toate.
● Testele selectate pot să nu conțină datele
Trebuie numai să selectăm datele
specifice:
corespunzătoare.
✓ p=q/r – se execută corect pentru
Acest lucru nu este realizabil la toate valorile, î afară de r=0;
✓ y=2*x în loc de y=x^2. Vor trece
testarea black-box. Este imposibil doar
doare testele: x=0,y=0 și x=2, y=4;
numai după cerințele programului să ghicim ● Testarea White-box este bazată pe
toate stările posibile ale programului. afirmația, că graful fluxului de date este
corect. Testarea verifică numai căile
existente în graf. Dacă în graf calea
lipsește, atunci ea nu va fi testată;
● Este necesară calificarea corespunzătoare a
testorului pentru înțelegerea codului inițial
al programului;
● Testarea exhaustivă a căilor nu garantează
corespunderea programului cerințelor
specificate.

55
Exerciţii:
Exerciţiul 1:
Fie este dat următoarea secvenţă de cod:
1. void foo(int a,b,x);
2. {
3. if (a>1 && b==0)
4. x/=a;
5. if (a==2 || x>1)
6. x++;
7. }
Care dintre grafurile reprezentate mai jos corespunde acestei secvențe de cod?

56
Exerciţiul 2.
Pentru algoritmul de mai jos indicaţi toate ramurile posibile şi toate căile posibile:

57
RAMURI CALE

58
59
Răspuns:
Exerciţiu 1:

60
RAMURI CALE
1-3-2 1-2-4
1-2 1-3-2-4
2-5-4 1-2-5-4
2-4 1-3-2-5-4

Tema 12: Instrumente de comunicare și planificare a activităților de testare

Unitatea de învățare 7: Automatizarea testelor. Utilitare pentru automatizarea testelor
Risc - un factor care ar putea duce la viitoarele consecințe negative, de obicei, exprimat în
portabilitate și impact.
Riscul se calculează:
Nivelul de risc = probabilitatea apariției riscului * impactul producerii lui
Riscurile proiectului:
● Factori organizaționali;
● Legate de furnizori;
● Legate de specialiști;
● Riscurile produsului:
● Livrarea produsului cu erori;
● Specificații incomplete;
● Probabilitatea că un defect poate cauza dezastre unei companii/ persoane;
61
 ● Aplicație lipsită de calități/atribute( funcționalități, securitate, performanță).
Managementul testării
Testarea independentă
Cauza:
● Este mai ușor de găsit greșelile altora decât cele proprii;
● Puncte de vedere diferite: Un dezvoltator percepe rezultatul final ca fiind corect, pe când
un tester, va considera că orice produs final are greșeli și va căuta cu sârguință
identificarea și localizarea lor.
Nivele ale testării independente
● Dezvoltatorii;
● Testeri independenți ce fac partee din echipa de dezvoltatori;
● O echipă de testare independentă, dintr-un centru de excelență, din aceeași organizație;
● Testeri independenți sau un grup de testeri din mediul de afaceri;
● Testeri specialiști, testeri de securitate, testeri de performanță;
● Testarea în afara proiectului: altă companie, prin contract.
Testarea în companii specializate se face cu scopul de a:
● Verifica dacă produsul respectă specificațiile și standardele prestabilite;
● Demonstra eficiența și eficacitatea soluțiilor propuse de ingineri;
● De a face comparație obiectivă a mai multor produse;
● Verifica utilitatea produsului pentru uz comercial;
● Pentru a identifica modalități de a îmbunătăți performanța produsului soft, optimizarea
serviciilor și altele.
Sarcinile unui Test-Lider:
● Stabilirea strategiilor de testare și planificare;
● Întocmirea strategiilor de inspecție;
● Planificarea cerințelor: riscurile, ciclurile, nivelele, tehnicile, obiectivele, estimările în
timp și bani;
● Coordonarea pregătirilor, implementărilor și executărilor testelor;
● Decide ce trebuie automatizat, stabilește limite și cum se va face;
● Repartizarea activităților în echipă;
● Scrierea de rapoarte;
Sarcinile unui tester:
● Inspecția și contribuția la planificare;
● Setarea mediului de testare;
● Pregătirea/copierea/crearea datelor pentru testare;
● Implementarea de teste, executarea, evaluarea rezultatelor și documentarea;
● Automatizarea testelor;
62
 ● Rularea de teste și măsurarea performanței componentelor sistemului;
● Revizuirea testelor implementate de alți testeri;
Strategii de testare
● O abordare a atestării include toate deciziile luate cu privire la modul de desfășurare a
testării;
● Pe baza testării se definesc scopurile și obiectivele proiectului, precum și evaluarea
riscurilor;
● Este un punct de pornire pentru planificarea testării prin tehnici de proiectare, tipuri de
testare și angajații ce vor fi implicați;
● De asemenea se definesc criterii de intrare și de ieșire.
Există mai multe abordări:
1. Abordări analitice - testarea bazată pe riscuri;
2. Abordări bazate pe model – pe baza informațiilor statistice;
3. Abordări metodice - bazate pe eșec;
4. Abordări specificate de standardele specifice industriei(Standardele căilor ferate);
5. Abordări dinamice și euristice – testarea de exploatare ș. a.
Estimarea și plănuirea testării
Factorii ce influențează la plănuirea procesului de testare: Risc, constrângeri, resurse, criterii,
politici de testare, scopul testării, obiectivele testării, testabilitate.
Pentru memorarea celor 16 secțiuni ale Planului de testare IEEE829 se folosește acronimul
”SPACEDIRT”
Criteriile de finisare a testării:
● Toate testele planificate au fost executate cu succes;
● mare parte din cerințe au fost acoperite;
● Nu sunt defecte de severitate critica;
● Toate defectele de severitate înalta au fost testate
● Când bugetul s-a epuizat;
● Orarul a fost bine îndeplinit și produsul este gata de utilizare.
Instrumente
Definiție – Un produs soft care realizează una sau mai multe activități de testare cu ar fi:
planificarea și controlul, întocmirea specificațiilor, elaborarea fișierelor inițiale, execuția și
analiza testării.
Tipuri de instrumente:
● Incident management tool;
● Requirements management tool;
● Configuration management tool;
● Instrumente pentru inspecție;

63
 ● Instrumente de analiză statică;
● Instrumente de modelare;
● Instrumente tipice de testare;
● Instrumente de evaluare a calității datelor;
● Instrumente de monitorizare ș. a.
TEMA 13: Automatizarea procesului de testare. Istrumente de jurnalizare a procesului de
testare. Automatizarea testelor
Unitatea de învățare : Automatizarea testelor. Utilitare pentru automatizarea testelor
Testarea automată presupune:
1. existenţa unui produs soft complex care să dezvolte astfel de procese;
2. definirea la intrare a programului care face obiectul testării;
3. realizarea unei varietăţi de mecanisme de testare care să acopere o gamă cât mai variată
de programe;
4. identificarea de criterii de evaluare a rezultatului testării care să stea la baza revizuirilor
ulterioare;
5. prezentarea de procese ale prelucrărilor inverse care să permită verificarea în mod
independent a calităţii soluţiilor produsului testat.
Avantaje:
1. Daca trebuiesc repetate aceleasi teste de multe ori automatizarea prezinta un mare
avantaj
2. Ajuta la executarea de teste de compatibilitate a programelor dvs pe mai multe
configuratii
3. Permite executarea scenariilor de testare ajutand la testele de regresie
4. Permite rularea mai multor teste de regresie pe un cod care se schimba des
5. Pot fi rulate simultan pe mai multe masini astfel scazand timpul de testare
6. Costurile pe termen lung sunt reduse
Dezavantaje:
1. E mult mai scump sa automatizezi, Investitiile initiale sunt mai mari decat in cazul
testarii manuale
2. Nu se poate automatiza totul, anumite teste trebuiesc facute manual
Testarea regresivă
Testarea regresivă reprezintă o treaptă deosebit de importantă pentru echipele care doresc să
dezvolte procese accelerate. Ca modalitate de lucru, prevede repetarea testării cu date de test şi în
condiţii identice, pentru fiecare nouă versiune internă a unui produs soft. Prin compararea
rezultatelor testării şi identificarea diferenţelor se depistează erorile nou apărute; acest lucru este
deosebit de util pentru maniera actuală de dezvoltare a aplicaţiilor RAD - Rapid Application
Development, care implică utilizarea instrumentelor vizuale de programare şi se caracterizează
prin apariţia unui număr mare de modificări într-un interval scurt de timp.

64
 Se apreciază că utilizarea instrumentelor de testare aduce beneficii comparativ cu
efectuarea manuală a testelor, deoarece:
● testarea manuală, chiar în cazul unei planificări riguroase, prezintă riscul neidentificării
erorilor din neatenţie sau din cauza nerespectării riguroase a cazurilor de test prevăzute;
● testarea manuală solicită un consum intens de resurse umane, care sunt costisitoare şi nu
întotdeauna disponibile;
● testarea manuală este înceată comparativ cu testarea automatizată; adesea apare problema
dezvoltării unor noi versiuni interne ale componentelor înainte de testarea completă a
versiunilor precedente;
Categorii de instrumente pentru asistarea testării
● Instrumente de capturare/redare înregistrează o sesiune de testare întrun fişier script,
permiţând repetarea acesteia şi sunt efectuate teste multiple în manieră automată cu
efectuarea de comparaţii asupra rezultatelor, aceste instrumente sunt eficiente în testarea
regresivă;
● Instrumente de execuţie automată a testelor asemănătoare cu cele de mai sus, dar
cazurile de test sunt specificate de utilizator în fişiere script;
● Aanalizor de acoperire evaluează gradul în care structura codului testat a fost acoperită
prin cazurile de test, astfel de instrumente sunt utile pentru identificarea porţiunilor de
cod netestate;
● Generator de cazuri de test este un instrument care, pe baza unor informaţii precum
cerinţe, modele ale datelor, modele obiectuale; generază cazuri de test semnificative,
avantajul este eliminarea redundanţei în testare, prin determinarea cazurilor de test care
asigură acoperirea cât mai mare a codului; această activitate, executată manual, este
dificilă;
● Generator de date de test este un instrument care foloseşte la popularea fişierelor şi
bazelor de date în vederea testării, popularea se face în general cu date aleatoare, dar
unele instrumente prevăd şi posibilitatea specificării unor condiţii; instrumentele sunt
utilizate în general pentru popularea cu volume mari de date, necesare testărilor
operaţionale şi la capacitate maximă;
● Analizor logic / de complexitate serveşte la cuantificarea complexităţii unor porţiuni de
cod; multe astfel de instrumente oferă şi reprezentări grafice ale căilor posibile în
structura codului; sunt utile pentru determinarea cazurilor de test necesare pentru
atingerea anumitor puncte din cod din rutine complexe.
● Instrumente de trasare a erorilor permit gestiunea informaţiilor privitoare la erorile
detectate şi stadiul corectării lor şi centralizarea acestor informaţii pentru urmărirea
tendinţelor acestor defecte; pe baza acestor tendinţe se efectează îmbunătăţiri în procesele
de dezvoltare şi/sau mentenanţă ale organizaţiei;
● Instrumente de gestionare a testării au rolul de a asista planificarea şi organizarea
elementelor implicate în testare precum fişiere script, cazuri de testare, rezultate
Instrumente Case
Prin instrumente CASE înţelegem aplicaţiile soft care-i sprijină pe analişti, proiectanţi,
programatori, inclusiv personalul de testare şi întreţinere, să analizeze, să proiecteze, să

65
implementeze (cel puţin parţial), să modifice (extindă), respectiv să construiască teste pentru
sistemele informatice.
Un produs de tip CASE reprezintă, aşadar, o colecţie de metode, instrumente şi procese utilizate
în ingineria soft-ului asistată de calculator. Aceste produse oferă suport pentru automatizarea
metodelor şi tehnicilor folosite pe parcursul ciclului de dezvoltare de sisteme informatice, de
aplicaţii, de programe.
Utilizarea instrumentelor CASE nu este astăzi o problema de modă, ci de eficienţă în activitatea
de proiectare, realizare şi/sau dezvoltare de produse soft. Într-un domeniu dinamic si inovator
apare permanenta nevoie de adaptare a proceselor de desfăşurare a afacerilor şi a soluţiilor care
le implementează. Menţinerea sistemelor existente devine din ce în ce mai costisitoare, mai
riscantă şi mai ineficientă.

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

Unitatea de învățare: Automatizarea procesului de testare
TEMA 14: Aplicarea instrumentelor de automatizare la realizarea test case-urilor.

Competențe elementare formate în cadrul modului:

Automatizarea procesului de testare
Abilități formate:
A27. Instalarea instrumentelor de automatizare a procesului de testare;
A28. Construirea şabloanelor de test în baza specificaţiilor.
A29. Utilizarea instrumentelor de automatizare a testării;
A30. Rularea unui caz de testare automatizat;
A31. Rularea unui scenariu de testare automatizat
A32. Utilizarea instrumentelor de automatizare a testării;
Termeni cheie:
Testare automatizată
Script de testare
Instrument specific de testare (Test Tool)
Coded UI
Selenium IDE

Cerințele moderne față de elaborarea produselor program constau în:

● Elaborare în termeni minimali;
● Elaborare cu resurse minimale;
Investește cît mai puțin => Venituri cît mai mari
Acest deziderat aduce la aceea că:
● 90% din proiecte nu sunt finisate la timp;

66
 ● 67% de dezvoltatori regulat nu se includ în termeni;
● în 91% din cazuri se reduce din funcționalitate, pentru a se încadra în termenii
stabiliți.
Acest lucru impune micșorarea cheltuielilor și optimizarea procesului de elaborare a
produsului program. Una din căile de optimizare a acestui proces – automatizarea acestui proces.
Bineînțeles vom analiza testarea automatizată a produselor program.
Testare automatizată – gestionarea și efectuarea lucrărilor de testare, ce includ în sine
elaborarea și executarea scripturilor de testare cu utilizarea instrumentelor specifice de testare.
Script de testare – set de instrucțiuni pentru verificarea automatizată a unei anumite părți
ale produsului program;
Instrument specific de testare (Test Tool) – Produs program, cu ajutorul căruia testorul
efectuează crearea, depănarea, executarea și analiza rezultatelor lansării scripturilor de testare.
Testarea automată este caracteristica unei etape superioare a producției de produse soft.
Testarea automată presupune:
● existența unui produs soft complex care să dezvolte astfel de procese;
● definirea la intrare a programului care face obiectul testării;
● realizarea unei varietăți de mecanisme de testare care să acopere o gamă cât mai
variată de programe;
● identificarea de criterii de evaluare a rezultatului testării care să stea la baza
revizuirilor ulterioare;
● prezentarea de procese ale prelucrărilor inverse care să permită verificarea în mod
independent a calității soluțiilor produsului testat.
Mecanismele de testare vizează:
● numărul seturilor de date de test;
● diversitatea seturilor de date de test;
● soluţiile iniţiale, exacte, recunoscute ca fiind corecte;
● definirea sistemului de generare a datelor de bază;
● recrearea de seturi de date derivate care se concatenează cu datele de bază şi devin
în totalitate componentele seturilor de date;
● integrarea în procesul de testare automată a programului care face obiectul
testării;
● includerea unui sistem de indicatori de apreciere a rezultatului testării;
● agregarea de indicatori privind comportamentul de ansamblu a procesului de
testare automată.
Testarea automata este un deziderat. Maximizarea gradului de generalitate trebuie inclusă
în categoria dezideratelor majore. Daca se începe cu testarea automată a programelor aparţinând
unei clase de aplicaţii se obţin concluzii valoroase care stau la baza trecerii la produse soft cu
grad de complexitate ridicat. Prin paşi succesivi se creează premisele favorabile fundamentării
unei teorii coerente a testării automate. Creşterea gradului de generalitate este o chestiune legată
de experienţa acumulata în procesul testării, coroborată cu utilizarea unor tehnici şi metode
67
evoluate de extragere a informaţiilor dintr-un text sursa devenit intrare pentru un produs soft
orientat pe testare automată.
Mecanismele necesare testării automate vizează de la problemă la problemă realizarea
unor componente care să efectueze şi prelucrările inverse proceselor pentru care s-a elaborat
produsul soft. În aceste situaţii speciale, mecanismul de testare automată este cel prezentat în
figura alăturată.

Din figură se identifică următoarele elemente care apar în testarea automată a produselor
soft specializate:
● G – generatorul de date de intrare;
● D – datele de intrare generate;
● P – programul supus testării;
● R – rezultate obținute prin programul P cu datele de intrare D;
● P’ – programul care implementează un algoritm invers celui implementat în
programul P sau un algoritm pentru verificare;
● D’ –rezultate obținute de programul P’;
● V – program care compară rezultatele generate cu rezultatele obținute.
În funcție de specificul aplicației, fluxurile prezentate în figura dată variază, însă
principiul acestui mecanism de testare automată rămîne același.
Cele mai importante întrebări la automatizarea testelor:
● De ce să automatizăm?
● Ce să automatizăm;
● Cum să automatizăm.
Automatizarea testării ridică calitatea testării, deoarece:
● Instrumentele de testare totdeauna vor executa precis scripturile de testare și nu
vor greși niciodată;
● Instrumentele de testare acoperă un diapazon mai mare de testare;
Automatizarea testării reduc cheltuielile de resurse pentru testare, deoarece:
68
 ● Instrumentele de testare execută scripturile de testare cu mult mai rapid decît
omul;
● În timpul lucrului scriptului de testare, testorul poate efectua alte activități;
DAR!
Pentru a obține aceste avantaje, testarea automatizată trebuie integrată în proiect corect și
cu foarte multă atenție.
Pentru integrarea cu succes a testării automatizate se folosește metodologia cilcului de
viață a testării automatizate (Automated Testing Lifecycle Metodology, ATML).
ATML – este o abordare structurală pentru implementare și executarea testelor
automatizate la toate etapele elaborării produsului program;
ATML reflectă avantajele includerii testării timpurii în lucrările asupra proiectului;
ATML – reprezintă o iterație, formată di șase etape, ce urmează una după alta:

Erorile tipice comise în procesul de testare automatizată:

● Implementarea instrumentului de testare fără prezența procesului de testare, este
creată o programă de testare, car nu poate fi repetată și evaluată.
● Realizarea proiectului de testare fără evidența standardelor de proiectare. Sînt
elaborate scripturi de testare, care nu pot fi folosite pentru următoarele versiuni
ale produsului program;
● Încercarea de a automatiza 100% de testare, cînd instrumentul de testare nu
susține automatizarea tuturor testelor necesare;
● Alegerea incorectă a instrumentului de testare;
● Implementarea tîrzie a instrumentului de testare, fără asigurarea timpului necesar
pentru instalare, instruire obținerea prototipului;

69
AVANTAJE

Testare Automata Testare Manuala

Daca trebuie repetate aceleași teste de multe Daca Test Case-urile trebuie rulate de un
ori automatizarea prezinta un mare avantaj număr mic de ori e mult mai probabil sa se
prefere testarea manuala

Ajută la executarea de teste de Permite testor-ului să facă mai multe teste

compatibilitate a produsului program pe mai ad-hoc
multe configurații;

Permite executarea scenariilor de testare Costurile pe termen scurt sunt reduse;

ajutând la testele de regresie;

Permite rularea mai multor teste de regresie Cu cat un testor petrece mai mult timp
pe un cod care se schimbă des; verificînd un modul cu atît cresc șansele de
a găsi mai multe defecte și posibile greșeli
de utilizare;

Pot fi rulate simultan pe mai multe mașini

astfel scăzând timpul de testare;

Costurile pe termen lung sunt reduse.

DEZAVANTAJE

Testare Automata Testare Manuala

E mult mai scump sa automatizezi, Testele manuale pot fi mari consumatoare

Investițiile inițiale sunt mai mari decît în de timp;
cazul testării manuale;

Nu se poate automatiza totul, anumite teste Pentru fiecare release trebuie rulate aceleași
trebuie făcute manual. seturi de teste ceea ce poate deveni monoton

În ultimul timp pentru testarea automatizată se folosesc tot mai des izatăse folosesc tot
mai des așa-numitele xUnit frameworks, Coded UI din Visual Studio, Selenium.
Detaliat vor fi analizate framweork-urile Coded UI din Visual Studio și Selenium.
Coded UI – reprezintă un instrument de automatizare a testării interfețelor WEB, WPF,
XAML și Windows Forms în mediul de dezvoltare Visual Studio. Acest instrument este accesibil
doar în versiunile Ultimate, Premium și Professional (doar rularea testelor).
Crearea unui test cu ajutorul coded UI:
1. Lansați Visual Studio și creați un nou proiect Coded UI Test Project:

70
2. În generatorul de cod alegem opțiunea – Record actions …

Apare instrumentul de înregistrare a testului:

71
3. Apăsăm pe pătrățelul roșu pentru a începe înregistrarea, lansăm aplicația calculator –
win+R, ”calc” apăsăm pe butonul pauză, și generăm metoda de test
”openapplication”:

72
A fost generată metoda UIMap.openapplication()
4. Pornim înregistrarea din nou și cream o nouă metodă de testare pentru adunarea a
două numere – adunare2numere. Pentru această metodă vom crea verificare (assert)

5. Adăugăm metoda de testare pentru închiderea aplicației ”Calculator”: vom avea

următoarele metode:

73
6. Crearea și adăugarea sursei de date:

7. Cream fișierul data.csv, îl deschidem și întroducem datele pentru testare:

74
 8. Modificăm proprietatea ”Copy to output
Directory” a fișierului data.csv:
9. Adăugăm în partea de sus a codului rîndul:
using

Microsoft.VisualStudio.TestTools.UITesting.WinControls;

10. Modificăm metodele de testare:

[DataSource("Microsoft.VisualStudio.TestTools.DataSource.CSV", "|
DataDirectory|\\data.csv", "data#csv", DataAccessMethod.Sequential),
DeploymentItem("data.csv"), TestMethod]
public void CodedUITestMethod1()
{

75
 this.UIMap.UICalculatorWindow.UIItemWindow.UIItem7Button.SearchProperties[Win
Button.PropertyNames.Name] = TestContext.DataRow["Num1"].ToString();
this.UIMap.UICalculatorWindow.UIItemWindow2.UIItem8Button.SearchProperties[Wi
nButton.PropertyNames.Name] = TestContext.DataRow["Num2"].ToString();
this.UIMap.AddTwoNumbers();
this.UIMap.ValidateSumTwoNumbersExpectedValues.UIItem15TextDisplayText1 =
TestContext.DataRow["Sum"].ToString();
this.UIMap.ValidateSumTwoNumbers();
}
11. Lansăm în executie testul, și obținem rezultatulm pentru trei iterații:

Instrumentele pentru testarea performanţelor aplicaţiilor web sunt folosite pentru a testa
aplicații web și interfețe legate de web. Aceste instrumente sunt folosite pentru performanță,
sarcină, și teste de stres pentru aplicaţii web, site-uri web, servere web și alte interfețe web.
Instrumentele pentru testarea performanţelor aplicaţiilor web simulează utilizatori virtuali.
Astfel, instrumentul este util pentru a verifica strangulării în trafic și probleme de performanță
ale site-ului sau aplicaţiei web în curs de testare.
Un astfel de instrument se confruntă cu diverse provocări în timpul testării și ar trebui să
fie în măsură să efectueze teste pentru:

● Compatibilitate browser
● Compatibilitate sistem de operare
● Compatibilitate aplicație Windows, în cazul în care este necesar
Selenium IDE (Integrated Development Environment) este un utilitar folosit la dezvoltarea
cazurilor de test Selenium. Este un plug-in pentru Firefox, eficient în dezvoltarea cazurilor de
testpentru testarea aplicațiilor web.
Cele mai folosite comenzi în Selenium IDE sunt:
76
open deschide o pagină folosind un URL

click/clickAndWait execută o acțiune de apăsare și opțional, așteaptă încărcarea unei noi

pagini

verifyTitle/assertTitle verifică titlul unei pagini

verifyTextPresent verifică prezența unui text undeva în pagină

verifyElementPresent verifică prezența unui element al interfeței grafice în pagină, definit

prin tag HTML

verifyText verifică prezența unui text și a unui tag HTML în pagină

verifyTable verifică conținutul așteptat al unui table

waitForPageToLoad amână execuția până când o pagină așteptată se încarcă. Este chemată
automat când se folosește clickAndWait

waitForElementPresent amână execuția până când un element al interfeței grafice, definit prin
tag HTML, este prezent în pagină.

Vom realiza testarea automatizată a conectării în contul skype de pe web: skype.com

1. Verificăm comportamentul aplicației web

de autentificare în cazul cînd nu se
introduce nimic în cîmpurile nume și
parola;
2. Verificăm în cazul cînd numele și parola
este corectă;
3. Verificăm deconectarea contului.
4. Salvăm suita de cazuri de testare în
formatul HTML .și eventual pentru C#
pentru testarea în WEBDRIVER/ Nunit.

77
 Obiectivele specifice și realiste reprezintă fundația care stă la baza oricărei testări
automatizate de succes.
Testarea automatizată aduce multe beneficii, dar doar în anumite condiții:
● când este aplicată în contextul potrivit;
● când acest proces este abordat într-un mod corect;
● când obiectivele urmărite sunt specifice și măsurabile;
● când factorii de decizie conștientizează că această inițiativă este una care va aduce
avantaje pe termen lung.

78
 Test: "Evaluare sumativă: Testarea Produselor Program".

Item №1
Pe imaginea de mai jos este reprezentată schema generalizată a mediului de
testare. Această schemă conține următoarele blocuri: driverul de testare, modulul
testat, stub-uri, rezultate așteptate, rezultate reale, date de intrare și prelucrarea
rezultatelor.
Pentru fiecare din tehnicile de testare această schemă poate varia puțin.
Indicați pe această imagine blocul care lipsește în cazul testării prin metoda
cutiei negre:
Indicați locul pe imagine

Item №2
Selectați etapa de proiectare a cazurilor de testare:
Selectați unul din 4 variantele de răspuns:
1) configurarea testării
2) specificarea testării
3) înregistrarea testării
4) planificarea testării

Item №3
Completați spațiul omis (prin sublinierea noțiunii din paranteza patrată) în
definirea uneia din fazele de testare:
Completați spațiile libere:
[------|Planificarea testării|Analiza şi proiectarea|Implementarea testelor|
Rezultatele execuţiei secvenţelor de test] sunt evaluate pentru a determina dacă
produsul a trecut testul cu succes.

Item №4
Dintre afirmațiile de mai jos selectați afirmația corectă ce descrie diferența
dintre retestare și testarea de regresie:
Selectați unul din 5 variantele de răspuns:

79
1)
retestare se face de către dezvoltatori; testarea de regresie se face
prin testori independenți
2)
retestare execută din nou un test; testarea de regresie caută efecte
secundare neașteptate
3)
retestare folosește diferite medii; testarea de regresie utilizează
același mediu
4)
retestare se face după ce greșelile sunt fixate; testarea de regresie se
face mai devreme
5)
retestare caută efecte secundare neașteptate; testarea de regresie
execută un test nou

Item №5
Indicați pe imaginea de mai jos, pe ce buton trebuie să apăsăm pentru a începe
înregistrarea unui nou caz de testare.
Indicați locul pe imagine

Item №6
Cînd într-un caz de testare, un careva pas nu poate fi redat, ce rezultat va fi
atribuit acestui caz de testare? (Selectați unul din răspunsurile propuse mai
jos)
Selectați unul din 4 variantele de răspuns:
1) Invalid
2) Fail
3) Blocat
4) Pass

80
 Item №7
Faceți referire la imaginea alăturată.
Un testor a primit sarcina să testeze un cod de program. În urma analizei acestui
cod au fost elaborate seturi de cazuri de testare.
Completați spațiile omise în cazurile de testare de mai jos:

Completați spațiile libere:

prima și a doua condiție se îndeplinesc pentru: [--|34|101|9|1];
prima condiție nu se îndeplinește, a doua condiție se îndeplinește: [2|97|100|10];
prima condiție se îndeplinește, a doua condiție nu se îndeplinește: [120|99|9|2];

Item №8
Care dintre următoarele sarcini sunt atribuite unui testor?
Slectați cîteva din 6 variantele de răspuns
1) Corectarea erorilor găsite
2)
Implementarea de teste, executarea, evaluarea rezultatelor și
documentarea;
3) Modificarea specificației produsului program
4) Automatizarea testelor;
5) Pregatirea/copierea/crearea datelor pentru testare;
6) Coordonarea pregătirilor, implementărilor și executărilor testelor;

Item №9
Selectați afirmația corectă ce descrie principiul de divizare a procesului de
81
testare în etape distincte:
Selectați unul din 4 variantele de răspuns:
1) cu cît mai multe etape avem, cu atât mai bună este testarea
2) este mai ușor de a gestiona testarea pe etape
3) putem rula teste diferite în diferite medii
4) fiecare etapă de testare are un scop diferit

Item №10
Dintre instrumentele propuse mai jos, selectați instrumentele utilizate pentru
testarea automatizată:
Slectați cîteva din 5 variantele de răspuns
1) nUnit
2) Selenium
3) Coded UI
4) TestTopia
5) Visio

Item №11
Dintre grafurile fluxului de date, propuse mai jos, selectați graful pentru
următoarea secvență de cod:
/* Funcția calculează puterea nenegativă n a numărului x */
1 double Power (double x, int n) {
2 double z= 1; int i;
3 for ( i = 1;
4 i <= n;
5 i++ )
6 {z = z * x;}// intoarcere la rindul 4
7 return z;
}
Selectați unul din 5 variantele de răspuns:

1)

2)

3)

82
4)

5)

Item №12
Care dintre următoarele modele ale ciclului de viață a dezvoltării produslui
program reprezintă un exemplu de abordare de dezvoltare secvențială:
Selectați unul din 5 variantele de răspuns:
1) Programare extremală
2) Agile
3) Code-and-Fix
4) Spirall
5) Waterfall

Item №13
Care dintre fazele ciclului de viață a produsului program enumerate mai jos
urmează după etapa de proiectare a produsului program:
Selectați unul din 5 variantele de răspuns:
1) întreţinere
2) analiză
3) implementare
4) specificarea cerinţelor
5) testare
Item №14
Indicați corespondența corectă dintre criteriile calității ți caractersiticile lor:
Indicați corespondența dintre 4 variante de răspuns:
1) Funcționalitate 1) Maturitate
2) Fiabilitate 2) Securitate
3) Eficiență 3) Timp de execuție
4) Portabilitate 4) Co-existență
5) Putere de atracție
Item №15
Care dintre următoarele modele de testare ale produsului program sunt
modele iterative de testare?
83
 Slectați cîteva din 4 variantele de răspuns
1) Waterfall
2) Spirală
3) Agile
4) V-model
Item №16
Indicați corespondența corectă dintre clasificarea cazului de testare și
descrierea lui:
Indicați corespondența dintre 2 variante de răspuns:
Verificare că produsul Negativ
1) realizează ceea ce trebuie să 1)
realizeze
Verificarea situațiilor de Pozitiv
2) excepție ale produsului 2)
program.
3) Excepțional
Item №17
Dintre metodele de mai jos selectați metodele de prevenire a erorilor:
Slectați cîteva din 5 variantele de răspuns
1) Metodele de copiere și restanilire a datelor;
2) Metodele de îmbunătățire a schimbului de informație;
3) Metodele de prelucrare a deficiențelor dispozitivelor tehnice;
4)
Metodele de inspecție și înlăturare a erorilor la fiecare etapă a
proiectului;
5)
Metode de asigurare a corectitudinii a procesului de traducere a
informației
Item №18
Indicați corespondența dintre 7 variante de răspuns:
1) Analiza cerințelor 1) Metode statice de testare
2) Realizarea testelor 2) Metode dinamice de testare
3) Testare de sistem
4) Depănarea testelor
5)
Planificarea
verificărilor
6)
Exploatare și
mentenanță
7) Proiectarea testelor
Item №19
Dintre afirmațiile de mai jos selectași de către cine este efectuată testarea
Beta?
Selectați unul din 4 variantele de răspuns:

84
1) Efectuată de către o echipă de test independentă
2) Efectuată de către dezvoltatorul software-ul lui
3) Efectuată de către clienți
4) Efectuată de către testorul principal din proiect
Item №20
Selectați neajunsurile testării prin metoda cutiei negre
Slectați cîteva din 4 variantele de răspuns

1)
Volum foarte mare: chiar și pentru aplicații cu complexitate medie,
numărul de căi posibile poate ajunge la zeci de mii
2)
Greutatea găsirii și a reproducerii erorilor, ce apar destul de rar (erori
de lucru cu memoria)
3) Imposibilitatea determinării eorirlor ce se distrug reciproc
4) Complexitatea urmăririi calclulelor timpului testării

85
 Rapunsuri:

#1 (2 p.)

#2 (1 p.) 2
#3 (1 p.) [Rezultatele execuţiei secvenţelor de test] sunt evaluate pentru a
determina dacă produsul a trecut testul cu succes.
#4 (1 p.) 2
#5 (1 p.)

#6 (1 p.) 3
#7 (3 p.) prima și a doua condiție se îndeplinesc pentru: [34];
prima condiție nu se îndeplinește, a doua condiție se îndeplinește: [2];
prima condiție se îndeplinește, a doua condiție nu se îndeplinește:
[120];
#8 (3 p.) 2, 4, 5
#9 (1 p.) 4
#10 (1 p.) 1, 2, 3
#11 (2 p.) 4
86
#12 (1 p.) 5
#13 (1 p.) 3
#14 (1 p.) 1=2, 2=1, 3=3, 4=4
#15 (2 p.) 2, 3
#16 (2 p.) 1=2, 2=1
#17 (1 p.) 2, 4, 5
#18 (3 p.) 1=1, 2=2, 3=2, 4=2, 5=1, 6=2, 7=1
#19 (1 p.) 3
#20 (1 p.) 2, 3

87