1. Testarea si asigurarea calitatii software. Scop si importanta.

T=proc de descop a evid defectelor si src lor, dif depanare si corect+verif calitati sw.
S=scrierea de sw mai mentenabil, reutilizabil, flexibil.
I=sw face ceea ce trebuie s fac i nimic n plus,asigurarea utilizatorilor mpotriva
cderilor sw ce pot duce la pierderi de timp, proprieti, clieni, sau chiar viei.
2. Testarea intr-un proces iterativ si incremental de dezvoltare.
TpI=Analizeaz puin / Creeaz puin din design / Implementeaz puin / T ce poi.
IdD=Dac un sistem sw poate fi dezvoltat incremental, T se poate face la sfritul fiecrei
etape (adic, n etape cresctoare de funcionalitate)
3. Specificarea claselor. Preconditiile si postconditiile operatiilor. Invarianti.
SpC=trebuie s conin o descriere a ce reprezint clasa + ataare un neles i nite
constrngeri (fiecare operaie>specificaie>descrie ce face cls).
PrC=descriu condiii ce trebuie s fie ndeplinite nainte ca operaia s se poat executa.
Se exprim n termenii atributelor obiectului ce conine ; atributele parametrilor actuali ai
mesajului ce solicit execuia operaiei;
PoC=descriu condiii ce trebuie s fie ndeplinite dup execuia operaiei
Se exprim n termeni atributelor obiectului ce conine operaia; atributele parametrilor
actuali ai mesajului ce solicit execuia operaiei; o valoare de rspuns a operaiei i/sau
excepiilor ce pot apare
Inv=Descriu cond ce trebuie ndep ct pe parcursul duratei de via a obiectului. Un
invariant de cls descrie o mulime de granie operaionale pentru o instan a unei cls. Un
invariant de cls este o PoC implicit pentru fiecare operaie dar invarianii pot fi nclcai
n timpul execuiei. Se exprim n termeni de atribute/stri ale obiectului.
4. Surse de erori in implementarea claselor.
Atributele noilor instane nu sunt iniializate corect.
Colaborarea cu alte clase n implementarea codului unei clase(implementare incorecta).
Implementarea cls satisf specif, dar nu avem garania c specificaia este corect .
Implementarea nu conine toate operaiile sau definete incorect operaiile.
Clasa nu ofer o modalitate de verificare a precondiiilor de ctre transmitor.
5. Comparati programarea contractuala si programarea defensiva.
6.. Mostenirea din perspectiva testarii.
Erorile se propag de la o clas la descendenii si- prevenire: testarea unei clase imediat
ce a fost dezvoltat . Permite reutilizarea cazurilor de test.
Constrngerea modificrilor de comportament de la clas la subclas un mod de a fora
substitutabilitatea. Comportamentul unei subclase se poate defini n termenii schimbrilor
incrementale ale strilor observabile i operaiilor definite de clasa de baz.

7. Testarea modelului de analiza si design. Diagramele UML- descrierea si utilitatea lor.

Analiza cuprinde acele activiti din cadrul unui proces de dezvoltare sw al cror scop
este definirea problemei i determinarea cerinelor pentru soluie (CE face).
Dou tipuri de analiz: Analiza domeniului/Analiza aplicaiei.
Reprezint sistemul din perspectiva a ce trebuie s fac (din perspectiva dezvoltatorilor,
nu a clienilor- modelul obiectelor)
Scopul modelului de analiz este s ofere dezvoltatorilor i clienilor o viziune unitar
asupra cerinelor (problem i soluii)
Diagrama de clase: Specificatori de acces:+public/- private/#protected.
Relaii ntre clase: Relaia de compunere/Relaia de motenire/Relaia de agregare/Relaia
de asociere/Relaia de dependen.
Modelul dinamic: Diagrame de interaciune:
Diagrama de colaborare/Diagrama de secvene/Diagrama de stare.
Ambele descriu fluxul de mesaje ntre obiecte (conin aceeai informaie), se pot
transforma una ntr-alta automat.
Diagrama de activitati:Decizi/procesari/Emitere+receptare semnal/initiere si oprire.

8. Analiza riscului ca instrument de testare.

Analiza riscului este o parte a planificrii oricrui efort de dezvoltare.
Foarte util n a determina ce s testm i ct de mult.
Concepte de baz n analiza riscului i aplicarea lor n testare.
Comparaie: testarea bazat pe risc cu testarea pe baza frecvenei de utilizare a
funcionalitii.
Risc= orice amenin atingerea cu succes a scopului proiectului un eveniment cu o
oarecare probabilitate de apariie, care duce la anumite pierderi dac apare.
Ierarhizarea riscurilor: n funcie de probabilitatea de apariie i de gravitatea/ impactul
pierderilor produse.
Clasificarea riscurilor: Riscuri de proiect/Riscuri de business/Riscuri tehnice.
Ieirea analizei riscului este lista de riscuri ierarhizate, folosit n alocarea resurselor i
prioritizarea deciziilor.
Grade de risc: Cobort, mediu, ridicat.
Lista de cazuri de utilizare ordonat n funcie de risc:
Folosit de manageri pentru a asigna cazurile de utilizare incrementelor
Folosit pentru a determina necesarul de testare pentru fiecare item.

9. Planificarea testarii=T proiectului, componentelor, standardul de testare IEEE829.

Planificarea testarii Obiectivele aplicatiei/Cerintele impuse/Creare si mentineare testarii
de suita/Testare pe baza de specificatie/Implementarea pe baza de teste/Testarea
interactiunilor/Testare pe baza de stare

Standardul de testare IEEE829:

Caracteristici netestate Pentru testarea la nivel de clas; se raporteaz rezultatele analizei
HIT. Analiza HIT cuprinde trsturi ce au fost testate i necesit re-testare, i trsturi
programate pentru dezvoltare n iteraii/ incremente urmtoare
Criterii de suspendare a testului Testarea se suspend cnd numrul de erori gsite pe or
scade sub criteriul (pragul) setat n aceast seciune
Seciunea e important n dezvoltarea iterativ: vor exista criterii diferite pentru iteraiile
timpurii fa de cele trzii
Riscuri i contingene, n acest context, un risc identific potenialele probleme n
ghidarea testului:
Erori posibile legate de rspunsurile corecte n mulimi mari de date i posibilitatea ca
platforme diferite s duc la rezultate diferite
Testarea componentelor:
Scop: definirea strategiei globale i a cazurilor de test specifice ce vor fi folosite pentru a
testa o anume component
Criteriile proiectului = standarde legate de ct de aprofundat vor fi testate componentele
+ criterii de acoperire
Exemplu: 100% din postcondiiile metodelor modificator s fie testate
Procedurile proiectului: = tehnici alese pentru o sarcin anume
Exemplu: -Construirea unei clase PACT pentru fiecare component ce va fi testat
-Dau detaliile pentru strategiile de testare
Obiectivele clasei=Lista prioritizat de obiective:
Cazuri de test funcionale/ Cazuri de test structurale/Cazuri de test pe baz de stri/Cazuri
de test pentru interaciuni.
10. Cele 5 dimensiuni ale testarii claselor- descriere detaliata. (Curs 4, de la pag 44 )
Cine testeaz? Ce pri vor fi testate?
Cnd se va face testarea? Cum se va face testarea? Ct este suficient s testm?
11. Testarea claselor de tip colaborare.

12. Testarea ierarhiilor de clase.

Cum se testeaz o subclas pornind de la testarea superclasei sale (cu metodele din
cursurile anterioare):
Testarea adecvat a subclaselor. Refolosirea cazurilor de test ale superclasei .
Implementarea driverelor de testare pentru subclase.
PACT: arhitectura paralel pentru testarea claselor:
Mod de organizare a claselor Tester ntr-o ierarhie de motenire.
Testarea claselor abstracte.

13. Testarea sistemelor.

Se refer la testarea unei aplicaii complete pentru a verifica dac ofer toate
comportamentele solicitate.
n stadiul testrii sistemului se caut mai ales apropierea dintre operarea real i cerine.
Testarea n stadiul de analiz i design scade probabilitatea unui comportament diferit de
cel ateptat.
14. Testarea pe baza de model.
Model= metod de reprez a comport sw.
Testarea pe baz de model: genereaz teste din descrierea explicit a aplicaiei- mai uor
de generat i meninut teste utile i flexibile.
Testarea pe baz de model este o tehnic black-box cu urmtoarele avantaje asupra
testrii tradiionale:
-Construcia modelelor de comportament poate ncepe devreme n ciclul de dezvoltare.
-Modelarea descoper ambiguitile din specificarea i design-ul software.
-Modelul cuprinde informaii comportamentale ce pot fi refolosite n testrile viitoare,
chiar dac specificaia se modific.
-Modelul e mai uor de actualizat dect o suit de teste individuale.
-Modelul furnizeaz informaii ce se pot combina cu teoria grafurilor pentru generarea
automat a diverselor scenarii de testare.