Testare???

Asigurare a calitatii???

1/31/2021 1
 Testare:
este procesul de folosire a unui produs software
pentru a verifica faptul ca respecta cerinte
specifice si pentru a detecta erori.

1/31/2021 2
 Asigurare a calitatii:
Calitate?
• Este un concept complex, care depinde de context si
semnifica lucruri diferite pentru persoane diferite.
• Pentru utilizator, inseamna satisfacerea nevoilor si
cerintelor sale.
• Pentru producator, inseamna conformarea cu
specificatiile tehnice.
• Cu alte cuvinte, calitatea inseamna valoare adusa
produsului pentru cineva.
• Testarea nu aduce automat calitate! Ea măsoară nivelul
calității unui produs.

1/31/2021 3
 Atributele calitatii:

???
1/31/2021 4
 Atributele calitatii:
Fiabilitatea
Fiabilitatea unui obiect(unei componente, unui proces, unui sistem) sau a unei
persoane exprimă siguranța sa în funcționare. Este o funcție de timp F(t), definită drept
probabilitatea ca, în condiții înconjurătoare specificate, obiectul (componenta, procesul,
sistemul) să funcționeze adecvat, menținându-și parametrii prestabiliți în intervalul de timp [0,t).
Practic fiabilitatea este o probabilitate (de bună funcționare) , cu o valoare cuprinsă între 0 și 1.
Eficiența
Capacitatea produsului software de a avea performante corespunzatoare, relative la
resursele si conditiile date.
Portabilitatea
Usurinta prin care un produs software poate fi transferat de pe un echipament pe altul sau
dintr-un mediu in altul.
Folosință (usability)
Capacitatea produsului software de a fi inteles, invatat, utilizat si atractiv pentru utilizator
atunci cand este folosit in anumite conditii.
Mentenabilitate
Usurinta prin care un produs software poate fi modificat pentru a se corecta anumite
defecte, pentru a avea noi cerinte, pentru a face ca in viitor mentenata sa fie mai usoara sau pentru a se
adapta la un mediu schimbat.

1/31/2021 5
 Asigurarea calitatii:
Quality Assurance:
Oбеспечение качества:

Modulul 1:
Bazele testării produselor-program - 10 ore

Modulul 2:
Strategii de testare - 20 ore

1/31/2021 6
 Lectia 1:
• Procesul de dezvoltare ale produselor
program.
• Terminologia din domeniul testării
produselor-program
• Ciclul de viaţă al dezvoltării produselor-
program
• Modele ale ciclului de dezvoltare ale
produselor-program.

1/31/2021 7
Procesul de dezvoltare ale produselor
program:
clasic

Planificare

Implementa
re

Testare

1/31/2021 8
Procesul de dezvoltare ale produselor
program:
modern
Design/
proiectare

Realise/ Build/
versiune implemetare

Configure/
Test/ testare
configurare

1/31/2021 9
 Terminologia din domeniul testării
produselor-program
• Bug - O problemă, eroare, defect, posibilitate nedocumentată, greșeală într-
un sistem software care împiedică sistemul să funcționeze așa cum este de
așteptat este un bug.
• Bug report - Un raport care detaliază un bug într-un program, adică cum se
manifestă, când și care parte a codului este responsabilă, eventual și o
soluție posibilă.
• Bug tracking - Bug tracking-ul este un mod organizat de a ține evidența
bugurilor și a stărilor acestora (deschis, rezolvat, testat, închis). Acesta
poate varia de la forme neorganizate (întâlniri în echipă) la forme organizate
(liste de discuții, mail-uri, soluții specializate).
• Sistem de bug tracking - O aplicație software 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 software 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.

1/31/2021 10
 Ciclul de viaţă al dezvoltării
produselor-program:
Ciclul de viaţă al unui produs software
reprezintă intervalul de timp de la momentul deciziei
de realizare şi până la retragerea sau înlocuirea
totală a acestuia cu un nou produs software,
reprezentând orizontul de timp în care operează şi
evoluează produsul program. După glosarul de
termeni -terminologie software - ai IEEE (Institute of
Electric and Electronic Engineering), ciclul de
viaţă reprezintă o abordare sistemică începând cu
dezvoltarea, utilizarea, mentenanţă şi până la
retragerea software-lui

1/31/2021 11
 Ciclul de viaţă al dezvoltării
produselor-program:
Etape Obiective Produse finale
Cerinte utilizator Definirea problemei Specificatii cerinte utilizator

Cerinte software Analiza problemei Cerinte si specificatii software

Proiectarea Solutii de ansamblu Proiect ansamblu

arhitecturii
Productie Implemetare Proiect de detaliu,
Software testat
Transfer Instalare Software instalar, training clienti,
debugging
Mentenanta Evolutie produs software Software intretinut si dezvoltat

1/31/2021 12
 Modele ale ciclului de dezvoltare ale
produselor-program:

• Clasice – modelul spirala( spiral), modelul

cascada( waterfall), modelul V

• Moderne – agile (sprinten), continuous

integration (integrare continua).

1/31/2021 13
 Modelul spirala:

1/31/2021 14
 Modelul cascada:

1/31/2021 15
 Modelul V :

1/31/2021 16
 Agile:

1/31/2021 17
 Integrarea continua:
• Integrarea continua (Continuous integration -
CI) este practica/tehnologia/modelul din ingineria
software de unificare a spațiilor de lucru ale
dezvoltatorilor într-un depozit comun de mai multe
ori pe zi.
• Scopul său principal este cel de a evita
problemele de integrare, denumite „integration
hell”. CI poate fi văzut ca o intensificare a
practicilor de integrare periodică promovate de
metodele deja publicate ale dezvoltării de software
prin proces incremental-iterativ

1/31/2021 18
 Integrarea continua:

1/31/2021 19
 Controlul versiunilor:
• (din engleză: version control sau revision control) este
un domeniu software care se ocupă cu gestionarea
mai multor versiuni (numite și revizii) ale unor fișiere.
Este aplicată cu predilecție în programare, cu scopul
de a păstra versiuni succesive ale codului sursă al
unui program de calculator. O soluție ar fi arhivarea
separată și completă a fiecărei versiuni a programului
într-o bază de date (pe un purtător de date extern), dar
această metodă ar necesita în general prea mult
spațiu de memorie. În locul ei se utilizează tehnici
speciale, care reduc memoria totală necesară și care
facilitează reconstrucția „în zbor”, la cerere, a oricărei
versiuni din istoria programului.

1/31/2021 20
 Controlul versiunilor - Terminologie:
• repository„depozitul“ în care sunt păstrate fișierele curente și versiunile
anterioare. Deseori acest depozit este o bază de date găzduită pe
un server.
• working copy (copie de lucru)copie a fișierelor din repository pe
calculatorul de lucru al unui dezvoltator (de unde și numele). Acestea sînt
fișierele pe care lucrează un dezvoltator în mod obișnuit.
• check-out operația de creare a unei copii de lucru luate din repository
• commit sau check-in operația de introducere în repository a schimbărilor
din copia de lucru
• update (actualizare)introducerea în copia de lucru a schimbărilor făcute de
alte persoane (colegi la același proiect)
la repositorybranch (ramificare)bifurcarea unui set de fișiere în două căi de
dezvoltare distincte
• merge (integrare, împletire)unirea a două versiuni diferite ale unui aceluiași
fișier într-o singură versiune
• Tag o „etichetă“ aplicată fișierelor din repository la un anumit moment
important din "viața" programului, de exemplu la lansarea unui produs
1/31/2021 21
 Controlul versiunilor – aplicatii:
• SVN – necomerciala, interfata prietenoasa
• TFS - comerciala
• Source Safe – recomandata programatorilor
• Bazaar – necomerciala, interfata
neprietenoasa
• CVS – interfata neprietenoasa, incorporata in
NetBeans

1/31/2021 22
 Recapitulare:
• Procesul de dezvoltare ale produselor
program.
• Terminologia din domeniul testării
produselor-program
• Ciclul de viaţă al dezvoltării produselor-
program
• Modele ale ciclului de dezvoltare ale
produselor-program.

1/31/2021 23
 Lectia 2
Organizarea testarii:
1. Riscurile testarii
2. Repartizarea rolurilor
3. Planificari si estimari

9/2/2020 1
 Riscurile testarii:
Risc?
Un factor ce poate provoca pe viitor probleme,
de multe ori exprimat in probabilitate si impact

Riscul = probabilitatea ca problema va aparea *

impactul creat de problema
***calificative: sigur, foarte inalt, inalt, mediu,
joasa sau note 1..10, 1..4
9/2/2020 2
 Riscuri:
Riscurile proiectului: Riscurile produsului
1. Factori organizationali 1. Livrarea produsului cu erori
1. Limitarea personalului 2. Specificatii incomplete
2. Necesitatea instruirii
personalului 3. Probabilitatea ca un defect
3. Schimbari politice( poate cauza dezastre unei
schimbarea conducerii, companii/persoane
conflicte intre tari)
4. Aplicatie lipsita de
2. Legate de furnizori
calitati/atribute( functionalitati,
1. Neincadrarea in timp
securitate, performanta)
2. Criteriile de acceptanta
3. Legate de specialisti
1. Definirea incorecta a
specificatiilor
2. Calitatea arhitecturii, softului,
testerilor

9/2/2020 3
 Independenta in testare:
• De programare si de testare se ocupa 2 echipe
total diferite ce nu comunica direct intre ele
De ce?
1. mai usor de gasit greselile altora decit cele
proprii
2. puncte de vedere diferite

9/2/2020 4
 Nivelul de independenta:
Testeaza programistii

Testeri independenti alesi din echipa de Mica

programisti

Testeri independenti, fara organizatie

Testeri independenti, ce provin din business Medie

Testeri de securitate, testeri de performanta

Testare inafara proiectului: alta companie, Inalta

prin contract

9/2/2020 5
 Structura echipei:
• Project manager – manager de proiect
• Business analitic – analistii
• Developers – programistii
• Quality assurance – asigurarea calitatii
• Support – suportul tehnic

9/2/2020 6
 Repartizarea rolurilor:
Lider/manager/coordonator
(test lider)
• Stabilirea strategiilor de testare si
planificare
• Scrierea strategiilor de revizuire
• Planificarea cerintelor: riscurile,
ciclurile, nivelele, tehnicile,
obiectivele, estimarile in timp si
bani
• Coordonarea pregatirilor,
implementarilor si executarilor
testelor
• Hotaraste ce trebuie automatizat,
in ce limite si cum
• Repartizarea activitatilor in
echipa
• Scrierea de rapoarte
9/2/2020
Tester (tester)
• Revizuirea si contributia la
planificare
• Setarea mediului de testare
• Pregatirea/copierea/crearea
datelor pentru testare
• Implementarea de teste,
executarea, evaluarea
rezultatelor si documentarea
• Automatizarea testelor
• Rularea de teste si masurarea
performantei componentelor
sistemului
• Revizuirea testelor
implementate de alti testeri
7
 *Exceptii:
• Testarea unitara si de integrare - fac
programistii
• Testarea de sistem si de acceptanta - fac
cineva din business sau din utilizatori

9/2/2020 8
 Strategii de testare:
• Prin analiza riscurilor
• Bazat pe model
• Bazat pe standarte
• Bazat pe experienta(testare exploratorie)
• Bazat pe consultatii
• Regresiv
***Care? Riscuri??? Personal??? obiective???
Natura proiectului???

9/2/2020 9
 Planificarea in modelul V :

Politica
Riscuri Constringeri Resurse Scop Obiective
testarii

Planificarea
testarii de
acceptanta

Planul - master Planificarea

testarii testarii de sistem
Planificarea
testarii de
integrare
Planificarea
testarii
componentelor

9/2/2020 10
 Structura planului:
Nr. Sectiune Titlul rubricii Descriere
1 Id planului
2 Introducerea
3 Itemii testului
4 Cerinte ce vor fi testate
5 Cerinte ce nu vor fi testate
6 Tehnici
7 Cerintele pt testare
8 Cazuri de suspensie
9 Livrari
10 Procesele testarii
11 Mediul necesar
12 Responsabilitati
13 Necesitatea instruirii pesonalului
14 Orar
15 Riscuri
16 Liste cu aprobari
9/2/2020 11
 Criterii de finisare a testarii:
• Toate testele au fost executate cu succes
• O mare parte din cerinte au fost acoperite
• Nu sunt defecte de severitate critica
• Toate defectele de severitate inalta au fost
testate
• Cind bugetul s-a epuizat
• Orarul a fost bine indeplinit si produsul este
gata de utilizare
9/2/2020 12
 Estimari:
Metrici de baza: Metrici stabilite de experti:
• Numarul de conditii in test • Analisti
• Numarul de teste scrise • Consultantii proiectului
• Numarul de teste executate • Programisti
• Timpul necesar pt • Suportul tehnic
constructia cazurilor de – Caracteristicile productului
testare – Dezvoltarea productului
• Numarul de defecte gasite

9/2/2020 13
 Raportarea:
Nr. Sectiune Titlul sectiunii Detalii
1 Id raportului
2 Sumarul
3 Devieri
4 Rezultate
5 Evaluari
6 Activitati
7 Multumiri, laude, etc

9/2/2020 14
 Lectia 2
Organizarea testarii:
1. Riscurile testarii
2. Repartizarea rolurilor
3. Planificari si estimari

9/2/2020 15
Tehnici de proiectare a testarii:
1. Tehnica bazata pe
specificatii / functionalitati (black-
box)
2. Tehnica bazata pe structura (white-
box)
3. Tratare exploratorie și experimentală
 Introducere:
• Proiectarea testarii presupune 3 etape:
– Identificarea conditiilor(stare) de testare – un
element, item sau eveniment al unui careva component ce trebuie
verificat prin unul sau mai multe cazuri de utilizare(ex. Functie,
tranzactie, un atribul al calitatii, un element structural) .
– Specificarea cazurilor de testare – un set de multimi de
intrare, ‘conditii de pre-executie’, rezultate asteptate, ‘conditii de post-
executie’, create special pentru un obiectiv sau stare, ce seamna mult
cu un exercitiu.
– Specificarea procedurilor de testare – o secventa de
actiuni pentru executia unui test.
Reprezentare schematica:
Alcatuirea unui caz de testare de
baza:
• Valori permise : 20 litere, “-”.
Datele sunt case-sensitive
validate cind se tasteaza Enter.
Daca datele sunt corecte se
schimba fereastra pentru
introducerea unei cereri, daca nu
sunt valide datele apare un mesaj
de eroare pe pagina curenta.
• Cazuri valide:
Mr Ion Craciun
Ms Ana-Maria Gutu
• Cazuri invalide:
Mr George1 Graf
Ms “Cort” Alina
Ms Popescu ‘Ana’
 Tehnica bazata pe
specificatii/functionalitati (black-box)
 ‘Mini- tehnici’ bazate pe specificatii”
• Stabilirea claselor de valori – equivalence
partitioning
• Stabilirea limitelor claselor – boundary value
analysis
• Alcatuirea tabelelor de decizii – decision table
testing
• Alcatuirea starilor – state transition testing
• Stabilirea cazurilor de testare – use case
testing
Cazuri de utilizare:
 Tehnica bazata pe structura
(white-box):
• Diagrame de flux - Flow charts
– Secvente
– Selectie
– Iteratii
• Stabilirea cailor programului
 Diagramele de flux:
• Componentele:
– Secventa - o asfel de structura de control se
compune din pasi care se inlantuie unul dupa
altul, in ordinea in care apar in algoritm.

Read(a);
Writeln(b);
C=a+b;
 Diagramele de flux:
• Componentele:
– Selectia – permite alegerea unui cai din mai multe
posibile in dependenta de conditia stabilita.

If a>b then writeln(a)

else writeln(b)
 Diagramele de flux:
• Componentele:
– Iteratia – permite repetarea unei secvente de mai
multe ori.

X=15
Count=0
While x<20 do
x:=x+1
count=count+1
End do
Exemplu:
Exemplu:
Diagrama:
Tratare exploratorie și experimentală
Se remarca două abordări de testare utilizate. Prima
dintre ele se numește testare experimentală și
presupune definirea unui test case, efectuarea
testului propriu zis și verificarea rezultatului. În
cazul în care rezultatele nu sunt conforme cu ceea
ce este specificat în test cazuri în rubrica de
rezultate așteptate, tester-ul completează un raport
prin care se raportează defectul echipei de
dezvoltare. Metoda este foarte utilă pentru a
asigura funcționalitățile de baza negociate cu
clientul.
Cea de a doua metoda de testare este testarea
exploratorie. Aceasta reprezintă de cele mai multe ori
rularea unor teste pe care le execută un tester fără a avea
un plan stabilit. Nu este necesară elaborarea unui caz de
testare, ci se urmărește tocmai testarea aplicației în
situații speciale. Scopul acestei metode este acela de a
îmbunătăți calitatea generală a produsului și de a învăța
mai multe despre acesta. De asemenea, poate fi îmbinată
și cu rezolvarea defectelor descoperite pe parcursul
testelor, ceea că mărește eficiența etapei de lucru. De
cele mai multe ori, utilitatea testării exploratorii depinde
de calitățile tester-ului care o efectuează. Un angajat bine
pregătit va fi capabil să inventeze situații mai diverse și să
observe bug-uri mai greu de depistat. Un dezavantaj al
acestei metode este dat de faptul că, de cele mai multe
ori, procedurile se execută manual și nu pot fi
automatizate, așa cum se poate face în cadrul testării
experimentale.
Scopul acestei metode este acela de a imbunatati
calitatea generala a produsului si de a invata mai
multe despre acesta. De asemenea, poate fi
imbinata si cu rezolvarea defectelor descoperite pe
parcursul testelor, ceea ca mareste eficienta etapei
de lucru. De cele mai multe ori, utilitatea testarii
exploratorii depinde de calitatile tester-ului care o
efectueaza. Un angajat bine pregatit va fi capabil sa
inventeze situatii mai diverse si sa observer bug-uri
mai greu de depistat. Un dezavantaj al acestei
metode este dat de faptul ca, de cele mai multe ori,
procedurile se executa manual si nu pot fi
automatizate, asa cum se poate face in cadrul
testarii experimentale.
Scenarii de testare
 Scenariu de testare?
• Este un set de instructiuni ce urmeaza sa fie
efectuate pentru a verifica functionalitatea
unei parti a produsului.
• Scenariul de testare – este o activitate ce
utilizeaza scenarii, ce ajuta testerii la
implementarea testelor.
 Scenariu de testare:
Structura

Test script

Test case1 Test case2

Test step1 Test step2 Test step3 Test step4 Test step1 Test step2 Test step3 Test step4
Caz de testare
Erori???
Caracteristicile statistice ale erorilor pot servi drept ghid pentru dezvoltatori în distribuirea
eforturilor de creare a programelor. În plus, caracteristicile erorilor din procesul de proiectare a
programului ajută la:
1) evaluarea stării reale a proiectului, planificarea intensității și duratei muncii până la finalizarea
acestuia;
2) calcularea eficacitatății necesare a mijloacelor de protecție operațională împotriva erorilor
primare nedetectate;
3) evaluarea resursele informatice necesare în termeni de memorie și performanță, luând în
considerare costul eliminării erorilor;
4) Efectuarea cercetării și alegerii adecvate a indicatorilor de complexitate a componentelor și
tehnicii de calcul, precum și a altor indicatori de calitate.
Analiza erorilor primare din programe se efectuează la două niveluri:
diferențial - luând în considerare tipurile de erori, complexitatea și gradul de automatizare a
detectării lor, costul ajustărilor și etapele celei mai probabile eliminării
generalizate - în funcție de caracteristicile sumare ale detectării lor, în funcție de durata
dezvoltării, funcționării și întreținerii pachetului software.

Erorile tehnologice din documentație și programele de remediere din memoria tehnicii de calcul
reprezintă 5 ... 10% din numărul total de erori detectate în timpul testării. Majoritatea erorilor
tehnologice sunt detectate automat prin metode standartizate.
Erorile software după număr și tipuri sunt determinate în primul rând de gradul de
automatizare a programării și de profunzimea testării programelor/aplicațiilor.
Numărul de erori software depinde de calificările dezvoltatorilor, de volumul total al
pachetului software, de profunzimea interacțiunii logice și informaționale a modulelor
și de o serie de alți factori. Când se dezvoltă programe complexe, erorile de program
pot fi clasificate în funcție de tipurile de operații utilizate în următoarele grupuri: erori
de tipuri de operații; erori variabile; erori de control și cicluri ș.a.
În complexul de programe și sisteme de referință, sunt utilizate diferite metode pentru a
automatiza detectarea erorilor. La etapele inițiale de dezvoltare și de testare a modulelor,
erorile de program reprezintă aproximativ 1/3 din toate erorile. Erorile în utilizarea
operațiunilor în etapele inițiale a dezvoltatorului de program ajung la 14% și apoi scad
rapid pe măsură ce programatorii își îmbunătățesc abilitățile.
Erorile algoritmice sunt mult mai dificil de detectat prin metode de control automatizate
standardizate decât tipurile anterioare de erori. Erorile algoritmice ar trebui să includă, în
primul rând, erorile cauzate de formularea incorectă a sarcinilor funcționale, atunci când
specificațiile nu stipulează pe deplin toate condițiile necesare pentru a obține rezultatul
corect. Aceste condiții sunt formate și rafinate în mare măsură în procesul de testare și
identificare a erorilor în rezultatele funcționării programelor. Erorile cauzate de luarea în
considerare incompletă a tuturor condițiilor pentru rezolvarea problemelor sunt cele mai
frecvente în acest grup și reprezintă până la 70% din toate erorile algoritmice sau
aproximativ 30% din numărul total de erori la etapele inițiale de proiectare.
La erorile algoritmice ar trebui să să se alăture și erori în legăturile dintre module
și grupurile funcționale de programe. Ele pot fi clasificate ca erori de setare
incorectă a problemei. Erorile algoritmice se manifestă în contabilizarea
incompletă a intervalelor de variație a variabilelor, în evaluarea incorectă a
acurateței valorilor utilizate și obținute, în contabilizarea incorectă a relației dintre
diferite variabile, în reprezentarea inadecvată a condițiilor formalizate pentru
rezolvarea unei probleme în specificații sau schemele care urmează să fie
programate etc. Aceste circumstanțe sunt motivul faptului că pentru a corecta
fiecare eroare algoritmică este necesar să se schimbe mult mai mult decât în ​cazul
erorilor software.

O parte specială a erorilor algoritmice este alcătuită din calcule greșite în

utilizarea resurselor disponibile. Dezvoltarea simultană a mai multor module de
către diferiți specialiști face dificilă alocarea optimă a resurselor informatice
limitate pentru toate sarcinile, deoarece nu există date fiabile despre resursele
necesare pentru rezolvarea fiecăruia dintre ele. Ca rezultat, există fie o sub-
utilizare, fie (în majoritatea covârșitoare a cazurilor) o penurie a unor resurse
computerizate pentru rezolvarea problemelor în versiunea originală. Cele mai
mari erori de calcul apar de obicei la evaluarea timpului de implementare a
diferitelor grupuri de programe și la distribuirea performanței sistemului
Erorile de sistem din pachetele software complexe sunt determinate în primul
rând de informații incomplete despre procesele reale care apar în surse și
receptori de informații. În plus, aceste procese depind adesea de algoritmii
înșiși și, prin urmare, nu pot fi suficient definite și descrise în prealabil fără a
studia funcționarea complexului de aplicații software în interacțiune cu
mediul extern. La etapele inițiale de proiectare, nu este întotdeauna posibil să
se formuleze cu acuratețe sarcina țintă a întregului sistem, precum și sarcinile
țintă ale principalelor grupuri de programe, iar aceste sarcini sunt clarificate
în timpul procesului de proiectare. În conformitate cu aceasta, sarcinile
tehnice sau specificațiile pentru proiecte individuale sunt clarificate și
concretizate și sunt identificate abateri de la sarcina specificată, care pot fi
calificate drept erori de sistem.
În timpul funcționării, erorile de sistem sunt predominante (aproximativ 80%
din toate erorile). De asemenea, trebuie remarcat faptul că există un număr
mare corectări pentru fiecare eroare.
Scăderea erorilor în complexul de programe și intensitatea detectării
lor nu este nelimitată. După o anumită perioadă de testare,
intensitatea detectării erorilor în timpul celei mai active testări scade
atât de mult, încât echipa de dezvoltare se încadrează într-o zonă de
insensibilitate la erori și eșecuri. Cu o astfel de rată de eșec, este dificil
să se prevadă timpul necesar pentru a detecta următoarea eroare. Se
creează o idee că nu există deloc erori, cu privire la imposibilitatea și
lipsa scopului de a le găsi, prin urmare, eforturile de testare sunt
reduse și intensitatea detectării erorilor este redusă în continuare.
Această rată limitativă de detectare a defecțiunilor corespunde
timpului de funcționare pentru eroarea detectată, la care se oprește
îmbunătățirea caracteristicilor aplicației complexe în etapele de
testare.
Eșec (eng. failure) - orice deviere a
comportamentului observat de la cel
specificat/așteptat;
Eroare/stare de eroare (eng. erroneous state) -
orice stare a sistemului în care procesările
ulterioare ar conduce la eșec;
Defect (eng. fault /defect /bug) - cauza mecanica
sau algoritmică a unei stari de eroare.
 Modulul 2:
Strategii de testare.
 Termenul de strategie:
• STRATEGIE - Parte componentă a artei militare,
care se ocupă cu problemele pregătirii, planificării
și ducerii războiului și operațiilor militare. (DEX)
• STRATEGIA DE TESTARE - descrie modul în
care riscurile sunt atenuate la nivel de testare,
care tipuri de teste trebuie să fie efectuate, care
sunt criteriile de incepere si finisare a testarii.
Acestea sunt create pe baza unor documente de
proiectare. Pentru fiecare etapă de proiectare se
creaza o strategie de testare corespunzătoare
pentru a testa noile seturi de caracteristici.
 Clasificari ale strategiilor:
• Dupa obiectul testarii;
• Dupa cunoasterea structurii interne a
produsului;
• Dupa nivelul de automatizare;
• Dupa gradul de izolare a componentelor;
• Dupa perioada de testare;
• Dupa caracterul pozitiv al scenariilor;
• Dupa nivelul de pregatire pentru testare;
 Dupa obiectul testarii:
• Testarea functionalitatii (functional testing)
• Testarea performantei (performance testing)
– Testarea incarcarii - lansarii(load testing)
– Testarea de stres (stress testing)
– Testarea stabilitatii (stability / endurance / soak testing)
• Testarea utilizabilităţii (usability testing)
• Testarea interfetei (UI testing)
• Testarea securitatii/sigurantei (security testing)
• Testarea localizarii (localization testing)
• Testarea compatibilitatii (compatibility testing)
 Testarea functionalitatii
(functional testing):
• Verificarea functionalitatii unui produs se poate face atât prin
metode statice cât si dinamice. Cele statice se refera la verificarea
documentelor de cerinte , de analiza si respectiv documentele
tehnice.
• Dupa verificarea tuturor documentelor se poate spune ca ceea ce a
intrat ca input în etapa de dezvoltare este corect, si se trece efectiv
la metoda dinamic a de testare a functionalitatii. Scopul final al test
arii functionalitatii este de a confirma încrederea ca sistemul
software este exact ceea ce s-a cerut (fit for purpose). Aceasta
presupune ca sistemul sa fie complet fara defecte, cu alte cuvinte,
sistemul trebuie sa fie bun de utilizat.
• În timpul verificarii si validarii, defectele descoperite trebuie
rezolvate, ceea ce conduce la modificarea programului iar sistemul
trebuie reverificat si revalidat. Toate acestea se fac într-un ciclu
repetitiv numit regression test.
 Testarea functionalitatii
(functional testing):
• Testarea functionalitatii este cunoscuta si sub denumirea de black -
box testing deoarece se testeaza comportamentul cu datele de
intrare si rezultatul lor la iesire. Pe lânga incorectitudinea sistemului
sau lipsa unor functionalitati, în timpul testarii operationalitatii se
pot descoperi si erori de interfata, erori de date sau de
performanta, care vor fi contorizate si plasate la testele
corespunzatoare atributelor operationalitatii.
• Erorile descoperite pe parcursul testarii pot fi cauza diferitelor faze
ale dezvoltarii unui produs si pot fi descoperite în:
– specificatie - erori în documentele de specificatie primite.
– proiectare - erori generale sau particulare în solutiile de proiectare
adoptate;
– dezvoltare - erori în scrierea efectiva a codului;
– altele (configurare, etc.)
 Testarea functionalitatii
(functional testing):
• O mare parte a erorilor sunt în specificatie , deoarece aceasta poate
fi insuficienta (nu s-au atins anumite puncte), se schimba continuu
sau se datoreaza unei comunicari insuficiente cu echipa de
dezvoltare. Dupa erorile de specificatie pot urma, din punct de
vedere al numarului, atât scrierea de cod cât si de proiectare,
aceasta depinzând de complexitatea proiectului, de tipul de proiect
si de echipa cu care se realizeaza produsul.
• Validarea este terminata când software-ul functioneaza într-o
maniera rezonabila acceptata de client. Acceptarile rezonabile sunt
definite în documentul ce cuprinde specificatia cerintelor, în care se
descriu toate atributele cerute de client. Specificatiile contin o
sectiune numita criterii de validare care reprezinta baza testului de
validitate.
 Testarea performantei
(performance testing):
• efectuate pentru a determina cât de repede un sistem sau o
parte din el realizeaza o anumită sarcină in careva conditii.
Se cunosc 3 directii ale testarii performantei:
– Testarea incarcarii – lansarii – supraincarcarii -
presupune testarea in careva cazuri speciale: numar mare
useri, tranzactii cu frecventa mare.
– Testarea de stres -Presupune execuţia sistemului într-o
manieră anormală. Adică se testează confruntarea
software cu situaţi anormale (multiple tranzacţii, memorie
insuficientă, spaţiu liber mic pe disk, blocarea perifericelor
cu care lucrează aplicaţia)
– Testarea stabilitatii - presupune verificarea timpului in
care sistemul va rezista intr-o careva incarcatura.
 Testarea utilizabilităţii
(usability testing):
• Studiu care are ca scop verificarea utilizabilitatii interfetei unei
careva aplicatii.
• Rezultatele sunt deduse din parerile utilizatorilor ce au rolul
testerilor.
• Cum anume???????
– Se filmeaza mimica utilizatorului;
– Se filmeaza ecranul ;
– Se diferite actiuni legate de utilizator:
• Miscarile mouse-ului;
• Apasarea pe taste;
 Testarea interfetei
(UI testing):
• Presupune verificarea aplicatiei daca coincide
cu standartele cerute, daca coincid stilurile,
etc.
– Verificarea proportiei;
– Verificarea in cazul redimensionarii ferestrei;
– Compatibilitatea cu diferite browsere;
 Testarea securitatii/sigurantei
(security testing):
• Siguranta unui sistem presupune atât captarea, transferul si
retinerea datelor în conditii de siguranta cât si securitatea
sistemului în ansamblu. Securitatea sistemului este data în special
de domeniul de activitate al produsului. Astfel, securitatea poate fi
de la „foarte mic a” pâna la „foarte mare”.
• Domeniul bancar este un domeniu unde securitatea trebuie sa fie
spre nivelul maxim. Trebuie tinut cont ca sporirea securitatii este
proportionala cu costurile necesare implementarii acestei securitati.
Daca crestem costurile de securitate pentru a fi convinsi ca sistemul
final o sa fie sigur, s-ar putea ca sistemul sa nu mai îndeplineasca alt
atribut al operationalitatii (cel al eficientei).
• Nivelul la care un sistem este sigur poate fi stabilit si din alt punct
de vedere: un sistem este sigur atunci când efortul pentru
spargerea sistemului este mai mare decât rezultatele obtinute prin
spargere.
 Testarea securitatii/sigurantei
(security testing):
• O particularitate importanta pentru aceasta testare o au
sistemele critice , ale caror erori duc la o pierdere economica
semnificativa, o deteriorare fizica sau afecteaza sanatatea
umana.
• Testarea sigurantei la aceste sisteme este foarte importanta
din doua motive:
– accidentele sunt evenimente rare în sistemele critice si ele practic sunt
imposibil de simulat în timpul testarii sistemului;
– exista cerinte care sunt nesigure si acestea sunt imposibil de
demonstrat prin testare sau alte operatii de validare.
Dupa cunoasterea structurii interne a
produsului:
• Testarea bazata pe specificatii – black box( stabilirea claselor de
valori, stabilirea limitelor claselor, alcatuirea tabelelor de decizii,
diagramei de stari, cazurilor de testare/utilizare)

• Testarea bazata pe structura – white box;

• Testarea mixta – grey box;

 Dupa nivelul de automatizare:
• Teste automatizate – presupune utilizarea
instrumentelor pentru rularea aplicatiei si verificarea
rezultatelor.
– La nivel de cod – testarea modulara
– La nivel de interfata – imitarea actiunilor utilizatorului.
• Teste manuale – realizarea si verificarea testelor se
executa repetat de oameni.
• Teste semiautomate
 Dupa gradul de izolare a
componentelor:
• Testarea componentelor (component/unit testing) – verifica fiecare
modul aparte cu scopul de a verifica daca modificarile efectuate nu
au creat defecte in partea existenta.

• Testarea integrarii (integration testing)

• Testarea de sistem (system/end-to-end testing) – se realizeaza cind

tot sistemul este gata cu scopul de a verifica integritatea si
compatibilitatea componentelor. Face parte din testarea
specificatiilor si nu cere cunoasterea codului.
 Dupa perioada de testare:
• Testare alfa (alpha testing) – realizeaza programatorii
sau echipa pentru asigurarea calitatii
– “testarea de fum” (smoke testing) – realizeaza
programatorii pina sa fie transmisa pentru testare, se
verifica instalarea, conexiunile cu BD, etc.
– Testarea noii functionalitati (new feature testing) – se
verifica functionalitatea noua adaugata.
– Testarea pentru confirmare (confirmation testing)
– Testarea regresiva (regression testing) – dupa ce a fost
adaugata o noua functionalitate se verifica si cele vechi.
– Testarea de acceptanta(acceptance testing)
• Testare beta (beta testing) – realizeaza un grup de
utilizatori in conditii reale.
 Dupa caracterul pozitiv al scenariilor:
• Testare pozitiva – se elaboreaza date si scenarii ce corespund
utilizarii corecte a programului. Scopul acestei testari este de a
verifica functionalitatea produsului.

• Testare negativa – elaborarea de date si scenarii ce nu corespund

utilizarii corecte a aplicatiei: provocarea unor mesaje de eroare,
situatii extreme etc. Scopul acestei testari este de a vedea
rezistenta produsului in asa conditii(date incorecte, tratarea
exceptiilor etc)
 Dupa nivelul de pregatire pentru
testare:
• Testare bazata pe documentatie(formal
testing) – se implementeaza planuri
• Testare ad-hoc sau intuitiva (ad hoc testing) –
conform metodologiei Agile.
 Indicatori de testare:
• În cadrul etapei de testare se calculează diferiţi indicatori care
dau o imagine a procesului de testare cât şi o imagine asupra
calităţii sistemului testat.
• Complexitatea testării reprezintă numărul de cazuri de test
necesare raportat la volumul aplicaţiei. Complexitatea testării
se calculează atât pentru întregul produs dar şi pe o anumită
parte sau unitate de produs. Mai exact complexitatea
testării Ct reprezintă numărul cazurilor de test raportate la
unitatea testată dată de relaţia:

unde: CT – Cazuri de test; UT – Unitatea testată;

• Cazurile de test sunt raportate la nu anumit număr de
tranzacţii, un modul, un grup de module sau întregul sistem.
 Indicatori de testare:
• Calitatea defectelor raportate - Raportul dintre defectele
efective si totalul defectelor raportate este numită calitatea
defectelor raportate Cd dat de relaţia: unde: TDunice -
totalul defecte unice; TD – totalul defectelor raportate.
• Rata defectelor - Numărul de defecte efective descoperite
relative la numărul cazurilor de test reprezintă rata
defectelor Rd.
• Rata incidentelor - numărul de incidente în exploatarea
sistemului - Prin incident înţelegem acele erori care apar
din exploatarea sistemului cum ar fi: afişarea şi imprimarea
rezultatelor, întreruperea programului, blocarea programului,
resetări de funcţii şi de stări şi alte comportamente
neprevăzute. Acest indicator ne relevă eficienţa măsurilor
de întreţinere şi de corectare după implementare a
produsului-program. Contorizarea acestor incidente se face
pentru a calcula o rată a incidentelor Ri prin raportarea
numărului de incidente la numărul de ore de funcţionare sau
la numărul de tranzacţii efectuate date de relaţia:
unde: NI – număr de incidente;
NT – număr de tranzacţii;
Testarea Orientată
Obiect
Generaţia a patra de software este rezultatul analizei,
proiectării şi programării orientate obiect. Tehnologiile
orientate obiect generează particularităţi care se reflectă
în toate etapele ciclului de viaţă software, inclusiv în
testare. Pornind de la testarea empirică, până la utilizarea
unor tehnici şi metode moderne, viziunea orientată
obiect generează noi abordări. Testarea se face atât
pentru un produs software luat ca un întreg, cât şi pentru
componentele acestuia. Dacă se testează sistemul de
programe procesul se desfăşoară da la simplu spre
complex. Se testează mai întâi modulele apoi programul
şi în final sistemul de programe ca ansamblu complex.
Rezultatele asamblării, software integrat, este testat în
continuare (integration testing).
Programarea orientată obiect pesupune definire de
clase şi referire de obiecte.
Clasele sunt definite, caz în care reutilizarea
generează efecte pozitive. Când clasele sunt
subdefinite este necesară construirea de clase
derivate de completare. Când clasele sunt
supradefinite apar restricţii de referire şi de
reutilizare. Testarea claselor este permisă reutilizării
necondiţionate. Testarea claselor evidenţiază
raportul operanzi–operatori, gradul de moştenire şi
de acoperire probabilă a tipologiilor de clase de
probleme prin constructori/destructori(în
dependență de limbaj) definiţi. Programarea
orientată obiect este caracterizată printr-un nivel
foarte ridicat al reutilizării software.
Numeroase aplicaţii complexe se prezintă sub
forma unor programe apelatoare (main) care
conţin lungi secvenţe de directive şi ca
instrucţiuni, structuri liniare de expresii cu
referire la funcţiile(metodele) membre ale
obiectelor folosite.
Testarea software orientat obiect presupune
două planuri:
• testarea construcţiilor proprii;
• testarea construcţiilor incluse pentru
reutilizare.
Testarea software-ului orientat obiect are pe lângă
obiectivul general al stabilirii măsurii în care
produsul software realizează sarcinile date în
specificaţii, obiective specifice legate de:
• testarea funcţiilor(metodelor) membre ale
fiecărei clase;
• testarea gradului de încapsulare şi a efectelor
acestuia;
• testarea efectelor induse de nivelele de
moştenire şi de derivare;
• testarea efectelor induse de polimorfismul
funcţiilor membre.
• testarea interacţiunilor dintre clase.
Spre deosebire de software-ul dezvoltat prin alte metode, în
cazul programării orientate obiect, testarea vizează şi măsura în
care clasele sunt proiectate în vederea reutilizării. Adică, se
evidenţiază gradul de generalitate şi mai ales concordanţa
dintre specificaţiile fiecărei metode(funcţii) şi ceea ce efectiv
metoda(funcţia) realizează.
Rezultatul testării vizează două aspecte şi anume:
• secvenţa referirilor determină pentru exemplele de test
rezultate acceptabile sau nu ceea ce se răsfrânge asupra
produsului ca atare;
• rezultate privind măsura în care clasele definite sau referite
acoperă cerinţele unei reutilizări confortabile, fără nevoia de
a construi interfeţe sau de a realiza derivări(extinderi) în
obţinerea de clase noi cu un nivel de saturare redus, create
în mod special şi destinate unor utilizări cu totul particulare.
Dacă produsul poate fi acceptat pentru calităţile lui în raport cu
problema de rezolvat, nu este obligatorie şi acceptarea claselor
definite. În acelaşi fel, clasele definite pot îndeplini condiţiile de
reutilizare, fără ca programul să fie acceptat în urma testării.
Metoda de testare ierarhică stă la baza sistemului de testare
orientat obiect. Această metodă de testare utilizează şi
construieşte pe baza unor tehnici de testare cunoscute,
legându-le împreună într-un sistem de testare corespunzător.
Metoda defineşte şi aplică standarde de testare pentru câteva
nivele ale componentelor software: obiecte, clase,
componente de bază şi sisteme.
Metoda de testare ierarhică indică ca fiind "sigure" acele
componente care îndeplinesc standardele de testare pentru
tipul respectiv de componentă. Odată ce o componentă a fost
desemnată ca "sigură", ea poate fi integrată cu alte
componente "sigure" pentru a realiza împreună
componentele de pe nivelul următor.
"Sigur" este o stare relativă. Depinde în întregime de:
• standardele alese pentru realizarea aplicaţiei;
• atitudinea faţă de risc;
• riscurile specifice şi practicile de management al riscului
adoptate în proiect.
Metoda de testare ierarhică se axează pe componentele
de bază. O componentă de bază poate fi o ierarhie
completă de clase sau anumite clustere de clase care
realizează o funcţie de bază sau care reprezintă o
componentă arhitecturală logică sau fizică.
După ce este testată o componentă de bază la un nivel
"sigur", ea poate fi integrată cu alte componente de bază.
Testarea de integrare a componentelor de bază "sigure"
necesită accesarea doar a interconexiunilor dintre
componentele de bază şi orice funcţionalitate complexă
nouă. Metoda ierarhică elimină obligativitatea testării
tuturor combinaţiilor de stări în timpul testării de
integrare, ceea ce duce la creşterea productivitaţii.
În figura 1 este indicat un model de reprezentare grafică a
metodei ierarhice.
 Fig. 1. Metoda ierahică de testare

La baza piramidei sunt testate complet metodele

individuale pentru a fi denumite "sigure". Metodele se
integrează în clase şi se va testa întreaga ierahie de clase
pentru a se atinge un nivel "sigur". Colecţia de clase
"sigure" (componentele de bază) formează baza
produsului final. Aria largă de integrare a piramidei este
locul în care se integrează componentele de bază in
diferite structuri arhitecturale, funcţionale şi logice. Ele
formează un sistem.
Vârful piramidei este un test de sistem scurt şi concentrat.
Următoarea suită de teste completează structura piramidei:
• suita de teste condiţionale testează clasele utilizând
modelul de testare condiţională şi aserţiunile, excepţiile,
operaţiile de testare concurente adiţionale;
• suita de teste ierarhice incrementale testează
componentele de bază utilizând diverse modele de testare
şi scenarii;
• suita de teste de integrare testează combinaţii de
componente de bază utilizând modelul ierarhic incremental
cu scenarii care utilizează toate componentele, nu
doar stub-uri;
• suita de teste de sistem testează sistemele componentelor
de bază utilizând modele de testare pentru sisteme;
• suita de teste de regresie testează componentele de bază
şi sistemul.
Suita de teste ierarhice incrementale este cea mai complexă
dintre suitele de testare. Se poate construi suita utilizând
oricare din următoarele modele de testare:
• modelul de testare bazat pe stări de tranziţie;
• modelul de testare bazat pe fluxul de tranzacţii;
• modelul de testare bazat pe excepţii;
• modelul de testare bazat pe fluxul de control;
• model de testare bazat pe fluxul datelor.
Suita de teste ierahice incrementale este un set de scenarii de
test, care tratează obiectele ca instanţe ale claselor şi ca parte
a unui sistem corelat cu alte sisteme. Termenul ierahice şi
incrementale exprimă scopul de a testa obiectul în contextul
ierahiei de moşteniri şi a piramidei sistemului. Astfel orice
obiect nu constă numai în proprietăţile care i se atribuie, dar
de asemenea şi în acelea pe care le moşteneşte de la
ascendenţii săi mai generali şi mai abstracţi. Trebuie deci ca
operaţiunea de testare a obiectului să aibă în vedere acest
lucru.
La o extremă poate exista o singură serie de test ierarhice şi incrementale pentru
întregul sistem; la cealaltă extremă o suită pentru fiecare clasă. Soluţia optimă
este undeva la mijloc.
O modalitate potrivită de a începe este aceea de concentrare asupra sistemului,
acesta conţinând de obicei toate clasele ce pot fi subiectul unui singur grup de
teste. Este mai logic în unele cazuri să se lucreze cu subseturi de clase într-un
sistem, acest lucru fiind similar cu conceptul de testare a clusterelor în timpul
integrării.
Este important să se facă diferenţa dintre clasele concrete şi cele abstracte.
Putem testa clasele concrete direct, lucru pe care nu îl putem face în cazul
claselor abstracte datorită faptului că acestea nu pot fi instanţiate. Structural,
scenariile se construiesc separat pentru clasele abstracte, dar se rulează
împreună cu testele pentru subclase concrete. Păstrarea scenariilor de testare
separat permite reutilizarea testelor pentru subclase diferite profitând din plin de
moştenire pentru reutilizarea lor. Când se instanţează un obiect şi se execută
teste asupra sa, acestea testează şi clasa a cărei instanţă este obiectul şi
superclasa sa urcând în piramidă.
Esenţa metodei ierarhice şi incrementale de testare este ansamblul de relaţii
dintre clase. În lumea orientat obiect, când se testează o clasă se testează în
acelaşi timp şi clasele părinte, construind teste, acestea pot fi reutilizate ulterior
şi pentru testarea subclaselor.
Fiecare subclasă este rezultatul combinării structurii
şi comportamentului claselor părinţi cu atribute şi
metode noi. În figura 2 este o reprezentare grafică
din care se observă cum prin moştenire, clasa
derivată D se obţine prin combinarea clasei de bază
B cu un modifcator, M, ce cuprinde metodele şi
proprietăţile specifice clasei derivate. Astfel se
poate scrie că D = B M

Fig. 2. Moştenirea, o tehnică de modificare incrementală

În cadrul unei clase derivate au fost distinse trei metode:
• metode noi, în subclase, incluzându-le pe acelea cu acelaşi nume ca
metoda din superclasă dar cu parametri diferiţi;
• metode recursive, definite într-o superclasă şi care nu sunt
supradefinite sau supraîncărcate în subclasă;
• metode redefinite, definite într-o superclasă şi supradefinită sau
supraîncărcată într-o subclasă.
Metodele abstracte sunt metode de orice tip asociate cu clase abstracte.
Metodele abstracte pot sau nu să aibă o implementare. Dacă nu au,
subclasle trebuie să redefinească metoda, supraîncărcând-o. Fiecare din
aceste metode are o cerinţă diferită de testare în contextul clasei, de
aceea este importantă această tipologie. Astfel:
• metodele noi – necesită o testare completă;
• metodele recursive – necesită o retestare limitată dacă metoda
interacţionează cu funcţii membre noi sau redefinite. Este nevoie
doar să fie retestat obiectul care interacţionează, nu toate obiectele;
• metodele redefinite – se retestează prin reutilizarea modelelor de
teste şi obiecte dezvoltate din specificaţii mai degrabă decât din
controlul logic intern.
Acest lucru înseamnă că nu este nevoie să se testeze fiecare tip de obiect
în parte dacă acesta ar fi unul complet nou; va fi nevoie să se testeze doar
părţile într-adevăr noi. Acest lucru creşte simţitor productivitatea testării,
precum şi productivitatea programării şi a proiectării.
Reutilizarea structurală a acestui tip este partea cheie a paradigmei
orientării obiect.
Planul de testare ar trebui să corespundă listei detaliate de clase şi
metodele de testare.
Moştenirea multiplă face clasificarea mai dificilă, dar nu afectează
categoriile în sine. Anumite modele de moştenire multiplă, cum ar fi cele
din C++, fac să existe aceeaşi superclasă în două sau mai multe instanţe,
în obiect, creând astfel mai mult decât o metodă recursivă. Astfel se poate
numi metodă "diferită" o metodă care este de fapt aceeaşi doar
atribuind-i calea superclasei. Atâta timp cât metoda este recursivă nu este
nevoie ca acest lucru să fie testat. Dacă metoda este redefinită, nu va mai
fi nevoie să fie testate cele ale superclaselor, ci doar redefinirea. Singura
situaţie în care ar putea fi nevoie de o testare a mai multor căi diferite cu
aceeşi metodă este atunci când metoda interacţionează cu metode
virtuale redefinite într-o subclasă.
Este de remarcat faptul că legarea dinamică joacă un rol în
determinarea cerinţelor testării, dar numai în contextul testării
de integrare. Legarea dinamică creează posibilitatea unui set de
mesaje (combinaţii de obiecte emiţătoare şi receptoare de
mesaje), ceea ce înseamnă că va fi nevoie de mai multe teste în
locul unuia singur pentru a testa un mesaj specific. Când doar
se testează metode, ca fiind opuse mesajelor, nu prezintă
interes altceva decât varietatea de valori posibile ale datelor pe
care mesajele le pot introduce în metode.
În funcţie de tipul modelului de test utilizat şi de dezvoltarea
suitei de test, ar putea fi necesară adăugarea unor obiecte de
test condiţilor testelor care apar în metodele recursive. De
exemplu dacă o metodă recursivă utilizează unele atribute şi
subclasele adaugă o nouă serie de valori acelor atribute, ar
trebui adăugate obiecte de testare şi scenarii pentru a testa
noua serie ca parte a unui model de flux de control sau model
de flux de date. Această situaţie nu este tocmai obişnuită, dar
întotdeauna trebuie reexaminate modelele de testare pentru
superclase pentru a fi sigur faptul că acoperirea este adecvată.