Teme recapitulative

1. Programarea contractuala si defensiva prin perspectiva testarii.

Principiul substitutiei.

Programarea contractuala In aceasta tehnica de design propusa de

Bertrand Meyer, o interfata se defineste in termenii obligatiilor primitorului/
transmitatorului implicate intr-o interactiune.
Preconditiile descriu obligatiile transmitatorului.Cand construim designul
interfetei undei clase, preconditiile trebuie sa fie suficiente pentru:
-a permite primitorului sa ajunga la postconditii
-a permite transmitatorului sa determine daca toate preconditiile sunt indeplinite
inainte de trimiterea unui mesaj
Postconditiile descriu obligatiile primitorului. Trebuie ca postconditiile sa
acopere toate iesirile posobile ale unei operatii, in ipoteza ca preconditiile sunt
indeplinite
Este util sa definim metode accessor pentru verificarea conditiilor .

Programarea defensiva - n acest caz, interfaa se definete n primul rnd

din perspectiva primitorului, i a presupunerilor fcute de acesta asupra strii
sale, i asupra valorii intrrilor (argumente sau valori de date globale), la
momentulcererii. Operaiile ntorc o indicaie asupra strii cererii: succes/ eec
pentru un anumit motiv (valoare de intrare greit). Scopul principal al
programrii defensive este s determine garbage in pentru a elimina garbage
out. Dezavantajele acestei abordri sunt:

-mrete complexitatea software: transmitorul trebuie s corecteze n funcie

de ieirile posibile ale operaiei (lipsa de ncredere nu poate fi doar de partea
primitorului, ci i a transmitorului -care verific ieirile operaiei);

-crete dimensiunea codului i a timpului de execuie.

Deci, prin prisma testrii, programarea contractual simplific testarea claselor

dar complic testarea interaciunilor (trebuie s ne asigurm c fiecare
transmitor ndeplinete precondiiile), n timp ce programarea defensiv
complic testarea claselor (cazurile de test trebuie s acopere toate rezultatele
posibile) dar i testarea interaciunilor (trebuie s ne asigurm c se produc
toate rezultatele posibile i c sunt tratate corect de transmitor).

Principiul susbstituiei (Barbara Liskov) ne spune c instana unei

subclase D a lui C trebuie s poat fi folosit fr excepii/ erori oriunde
se folosete o instan a superclasei C (cu alte cuvinte, o subclas
trebuie s fie un subtip: specificaia subclasei trebuie s respecte complet
specificaia ancestorului direct; deci subclasa poate fi privit ca o submulime a
mulimii bazei conceptuale comune -clasa de baz-). Un mod de a fora
substitutabilitatea este s constrngem modificrile de comportament de la
clas la subclas.
Comportamentul unei clase se poate defini n termen
ii strilor observabile ale unei instane i a semanticii operaiilor definite pentru
o instan a clasei, iar comportamentul unei subclase se poate defini n
termenii schimbrilor incrementale ale strilor observabile i operaiilor
definite de clasa de baz.Principul care ne ajut s controlm modificrile
ce apar n clasa derivat spune c aceasta trebuie s nu cear mai mult,
i s nu promit mai putin (require no more, promise no less). Astfel,
pentru respectarea principiului substituiei, se admit doar urmtoarele
modificri n comportamentul unei subclase:

Precondiiile fiecrei operaii s fie aceleai sau mai slabe (-mai

puin restrictive din perspectiva clientului)
Postcondiiile fiecrei operaii s fie aceleai sau mai puternice (s fac
cel puin la fel de mult ca cele definite n superclas)
Invariantul de clas s fie la fel sau mai puternic (eventual s adauge
constrngeri noi)

2. Planificarea testarii. Analiza riscului. Acoperirea testarii.

Planificarea testrii implic rspunsul la ntrebarile cine, ce, i cnd testeaz.

La nivel tehnic planificarea foloseste abloane instaniate de dezvoltatori
dup necesiti. Vom descrie n continuare o ierarhie de planuri de testare, n
relaie cu abloanele standard de test (planul de test standard de la IEEE).

Analiza riscului este o parte a planificrii oricrui efort de dezvoltare,

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

Acoperirea specificaiei prin cazuri de test ne va garanta c programul face

ce trebuie, iar acoperirea implementrii va garanta c programul nu face nimic
din ce nu trebuie s fac. Pentru componentele cu risc ridicat este necesar
testarea pe baza implementrii (verificarea fiecrei linii de cod).
Testarea interaciunilor ntre componente se face n cadrul testrii
integrrii i trebuie s verifice posibilele erori de interfa i corectitudinea
polimorfismului. Cazurile de test pentru interaciuni se aleg prin metode speciale
pentru a limita numrul de cazuri folosite.

3. Inspectia dirijata. Testarea modelelor de analiza si design.

n consecin, i n cadrul inspeciei dirijate putem detalia urmtorii pai:

1. Stabilirea obiectului i a nivelului de detaliere al inspeciei

2. Identificarea bazei de creare a MUT (Model Under Test)
3. Dezvoltarea de cazuri de test plecnd de la con inutul modelului de baz
(scenariile cazurilor de utilizare sunt un bun punct de plecare pentru
multe cazuri de test)
4. Stabilirea de criterii de msurare a acoperirii testului (spre exemplu, o
diagram de clase este bine acoperit dac fiecare clas a fost mcar
parial acoperit/ atins de un caz de testare)
5. Executarea analizei statice cu o list de verificare corespunztoare;
compararea MUT cu modelul de baz pentru verificarea consistenei
6. Executarea cazurilor de test
7. Evaluarea eficienei testelor pe baza gradului de acoperire. ntruct
testarea analizei i design-ului sunt de nivel foarte nalt, ar trebui s existe
o acoperire de 100% a modelului.
8. Dac acoperirea este insuficient se extinde suita de teste: identificarea de
cazuri de testare noi pentru zona neacoperit. Se reia procesul.

Modelul de analiz cuprinde analiza domeniului i analiza aplicaiei.

Modelul de analiz al domeniului conine informaii despre domeniul
cunoaterii aplicaiei (derivat din literatur, experi etc.)

Figura . Criterii pentru inspectarea modelului domeniului

Exemplu. Caz de testare pentru modelul domeniului Grafic interactiv:

Presupunem c am creat un panou i i-am solicitat s afieze o form

geometric. Cum tie panoul unde s localizeze forma? Se ateapt ca un
mouseEvent s furnizeze coordonatele selectate de utilizator.

n Figura se regsesc criteriile de inspecie a modelului de analiz a

aplicaiei.

Figura .Criterii pentru inspecia modelului de analiz a aplicaiei

Exemplu. Caz de testare pentru modelul de analiz a aplicaiei:

Presupunem c a nceput un joc i s-a construit cmpul de joc. Cum va preveni

palet a mingea s ating podeaua? Se ateapt ca paleta s se mite n direcia
mingii i s o opreasc. Coliziunea va determina mingea s-i schimbe direcia
prin reflectarea sa de pe treimea din mijloc a paletei, sub acelai unghi ca
unghiul de impact.

Modelele de design se refer la design-ul arhitectural, dinamic

(mecanicist), i detaliat. Exist dou modele de design ce cuprind toate cele 3
nivele: modelul design-ului arhitectural i modelul de design detaliat a claselor.
Modelul arhitectural descrie structura de baz a aplicaiei definind modul de
relaionare i coninutul interfeelor, iar modelul detaliat al claselor descrie
semantica precis a fiecrei clase i identific apartenena acesteia la o interfa
arhitectural.

Modelul arhitectural este scheletul ntregii aplicaii, i mpletete cerinele

funcionale cu cele non-funcionale, prin aceasta permind utilizarea scenariilor
ca o baz pentru modelarea performanelor.

Caz de test pentru design-ul arhitectural

 Presupunem c s-au construit obiectele BricklesDoc si BricklesView.
Un mesajtick este trimis fiec rei MovablePiece.
Cum primete BricklesView informaia necesar pentru a actualiza
bitmapul de pe ecran? Se ateapt ca obiectul BricklesDoc s calculeze noua
poziie a fiecrui bitmap nainte de a notifica BricklesView c a aprut o
modificare
Obiectul BricklesView apeleaz metodele obiectului BricklesDoc pentru a
obine informaia necesar pentru a actualiza afiare

Arhitectura software este o structura de baz ce definete sistemul n

termeni de componente i interaciuni ntre componente. n reprezentarea
arhitecturii regsim urmtoarele componente: relaii, stri, i algoritmi.

Exist diverse instrumente de testare a arhitecturilor cum ar fi

(ObjectTime, BetterState) care dein faciliti de animare a diagramelor de
design i verificare automat a unor aspecte ale modelului. Acestea au un
mecanism de simulare ce poate fi folosit pentru executarea scenariilor:
diagramele sunt completate cu detalii ale scenariului i dezvoltatorul se poate
juca cu scenariul i descoperi defecte.

Limbajele de descriere a arhitecturii (spre exemplu Rapide) permit

reprezentarea sistemului la un nivel nalt de abstractizare. Dac se reprezint
modelul i cazurile de testare n limbajul respectiv, execuia testelor se poate
face automat, i nivelul de detaliere al prototipului va determina ct de specific
poate fi testarea.

Testarea arhitecturii software este un tip special de inspecie dirijat bazat pe

paii cunoscui:
(1) construirea cazurilor de test
(2) executarea testelor
(3) evaluarea rezultatelor testelor

Construirea cazurilor de test se face plecnd de la cazurile de utilizare (ca

ma i sus). Fiecare caz de utilizare descrie o familie de scenarii ce specific
diferite tipuri de rezultate ce pot apare ntr-o utilizare specific a sistemului, iar
rezultatele se folosesc pentru verificarea criteriilor din Figura ...
 Figura .Criterii pentru inspecia modelului de design arhitectural

Cazurile de test trebuie definite la un nivel ce exercit interfeele ntre

subsisteme. Spre exemplu, pentru jocul Brickles, interfaa esenial este cea ntre
Model i View (Figura , modelul conine clasele Puck, Paddle, BrickPile, iar
View clas a BricklesView).

n arhitectura Model/View cea mai mare parte a interaciunii e iniiat de View,

dar modelul notific view-ul cnd au ap rut modificri n cadrul su. ntruct
Brickles necesit animaie, am modificat arhitectura astfel nct atunci cnd o
biectul BricklesView e creat, i sunt trimise o serie de mesaje care i furnizeaz
datele necesare de la diferitele pri ale modelului. Odat analiza terminat, pot
fi selectate cazurile de test. Cele dou operaii de baz sunt (1) setup-ul
sistemului i (2) redesenarea ecranului dup fiecare micare. Spre deosebire de
alte sisteme construite cu Model/View, nu e nevoie s acordm atenie abilitii
de a aduga view-uri adiionale. S-ar putea defini un caz de test pentru fiecare
operaie, totui n cazul de fa est
suficient i un singur grand-tour (un caz de test care combin mai multe
cazuri de test separate ntr-o singur rulare). De obicei, grand-tour-urile sunt
prea mari i ofer prea puine informaii dac eueaz, dar n acest caz a
doua operaie nu se poate realiza fr prima (deci e o conjuncie natural).

Figura . Un model arhitectural pentru Brickles

Testele se execut specific pentru fiecare tip de reprezentare. Execuia se

face de obicei folosind diagrame de secvene ce reflect precondiiile unui
caz de test.

Figura . Executarea cazurilor de test

Verificarea rezultatelor este simpl pentru arhitecturi. Ieirea testului are

forma unei diagrame care e verificat de experii domeniului. Pentru ieirile
testului sub forma unei execuii, experii ar trebui s construiasc secvene
de evenimente care ar fi produse de o arhitectur ce funcioneaz corect.
 4. Testarea interactiunilor (Algoritmul OATS).
O interaciune ntre obiecte este o cerere din partea unui obiect
(transmitor) ctre altul (receptor) de a executa una dintre operaiile
receptorului, i toat procesarea efectuat de receptor pentru a
completa cererea

Presupunem:
interfaa clasei este format doar din operaii, nu i din date
Dac sunt accesibile date colaboratorilor, testarea acestui acces se face
ca i cum ar exista operaii set i get pentru valoarea acestor date
clasele sunt implementate corect (ex. au fost deja testate independent)

ntruct n procesarea unei singure metode pot aprea interaciuni cu

mai multe obiecte, dorim s vedem impactul acestor interaciuni
asupra strii interne a obiectului receptor i asupra obiectelor cu care
acesta este asociat
Efecte posibile:
Nici o modificare
Modificri ale valorilor atributelor (pentru un obiect sau mai multe)-
deci i strilor
Inclusiv crearea i tergerea obiectelor
Testarea interaciunilor pe baza specificaiei este mai direct
dect testarea pe baza implementrii
Vom limita testarea interaciunilor la obiecte asociate (studiind
interfaa public)
Selectm testele pe baza specificaiei fiecrei operaii din
interfaa public a clasei
Totui, trebuie s privim i dincolo de specificaie pentru a
vedea dac o metod a efectuat toate calculele necesare
Ex. Verificarea valorilor atributelor strii interne a receptorului,
inclusiv atributele care sunt la rndul lor obiecte

Tablourile ortogonale sunt o tehnic specific de eantionare care

urmrete limitarea exploziei cazurilor de test prin definirea de
perechi de obiecte ce interacioneaz
 majoritatea defectelor de interaciune provin de la interaciuni
n dublu sens (2 actori implicai)

tablou ortogonal tablou de elemente n care fiecare coloan

reprezint un factor, care este o variabil ntr-un experiment
n cazul nostru variabila va reprezenta o anume familie de clase
Fiecare variabil poate lua mai multe valori, denumite nivele
n testare, fiecare nivel va fi o anume clas a familiei
n paralel va exista un factor i o mulime de nivele ce
corespund strilor acestor clase
Valoarea dintr-o celul: o instan a unei clase sau o stare specific a
unui obiect

5. Testarea sistemelor. Testarea de stres si de securitate.

Testarea sistemelor se refer la testarea unei aplicaii complete pentru a
verifica dac ofer toate comportamentele solicitate.
Vom considera testarea sistemului dup fiecare increment ce
finalizeaz o funcionalitate pentru utilizatori
Vom considera
"sistem = "aplicaie= program + mediul de rulare (sistem de
operare, maini virtuale, browsere web i hardware).

Testarea este cutarea defectelor, dar nu numai...

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

Testarea stresului
Presupune operarea sistemului n condiii apropiate de epuizarea
resurselor necesare sistemului
Exemplu: aglomerarea RAM cu obiecte, umplerea discului cu
nregistrri, aglomerarea structurilor de date interne
Sistemele orientate obiect vor fi de obicei sub stres dac se creeaz un
numr mare de instane ale claselor
6. Testarea pe baza de model.

n ncercarea de a face testarea mai simpl i mai ieftin, s-a dorit ca

testarea s foloseasc informaii coninute n modele explicite (Beizer
1995, Apfelbaum 1997)
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

7. Notiuni fundamentale de fiabilitate software. Definitii.

Fiabilitatea a aprut ca efect al importanei deosebite pe care au
cptat-o problemele siguranei n funciune a echipamentelor
industriale, dispozitivelor i componentelor, constituind o tehnic de
vrf, indispensabil ingineriei.
Obiectivele fiabilitatii:
studiul defeciunilor, adic al cauzelor, al proceselor de apariie i al
metodelor de combatere a lor;
analiza fizic a defectelor;
aprecierea calitativ i cantitativ a comportrii produselor n timp n
funcie de factorii de solicitare interni i externi;
Se definete conceptul calitativ al fiabilitii, drept aptitudinea
unui sistem, bloc, produs, element etc. de a-i ndeplini corect
funciunile prevzute pe durata unei perioade de timp date, n condiii
de exploatare specificate.
n mod similar se definete conceptul cantitativ al fiabilitii, drept
probabilitatea ca un sistem, bloc, produs, element etc. s-i
ndeplineasc corect funciile prevzute, la un nivel de performan
stabilit, pe durata unei perioade de timp date, n condiii de exploatare
specificate.
 Studiul fiabilitii se bazeaz pe teoria probabilitii.
Indicatorii de fiabilitate sunt mrimi care exprim, sub o form
sau alta, calitativ i cantitativ, fiabilitatea produselor; indicatorii de
fiabilitate mai sunt denumii i parametri sau caracteristici de
fiabilitate.

8. Un model statistic de estimare si predictie a fiabilitatii (la alegere).

Estimarea. Determina fiabilitatea software actuala folosind inferenta
statistica asupra datelor obtinute in timpul testarii/ operarii sistemului.
Este utila pentru a verifica retrospectiv daca un anumit model de
fiabilitate este bun.
Predictia. Determina fiabilitatea viitoare a software-ului pe baza
masuratorilor si metricilor disponibile.

9. Criterii de selectare a modelelor (fractia precventiala, graficul u).

Fractia de verosimilitate precventiala
Metoda foarte generala de comparare a preciziei secventelor
predictive
Tehnica arata (cel putin asimptotic) care anume dintr-o pereche de
predictii e mai precisa, intr-un inteles foarte general (fara sa furnizeze
evidenta directa despre precizia absoluta a acesteia)
Graficul u
Graficul u: o prima tehnica generala de depistare a diferentelor
obiective dintre comportamentul de caderi prezis si cel real
Scopul graficului u este de a determina daca predictiile sunt,
in medie, aproape de distributiile reale Fj(t)
Se poate demonstra ca daca variabila aleatoare Tj are cu adevarat
distributia , cu alte cuvinte, daca predictia coincide cu realitatea,
atunci variabila aleatoare va fi uniform distribuita pe (0,1)
(transformarea integrala a probabilitatii, din statistica)

10.Testarea si fiabilitatea software.

Se presupune ca exista o relatie importanta intre estimarea fiabilitatii

unui program, structura sa, si cantitatea de testare la care acesta a
fost supus
Criteriile de acoperire a codului: cuantificatori posibili ai acestei
cantitati
 Acoperirea instructiunilor, a deciziilor, si a fluxului de date
(=cateva masuri ale acoperirii codului, bazate pe structura sa)
In viitor, ar putea fi posibil sa asociem un anumit model de fiabilitate
unui program pe baza caracteristicilor programului, sau poate chiar pe
baza metodologiei de dezvoltare software utilizate
In plus, importanta adaptarii testarii la mediul operational in care va fi
folosit programul este o tema centrala in estimarea fiabilitatii
Dificultatile in obtinerea unor profile de utilizare precise se
rasfrang asupra masuratorilor de fiabilitate, si aceasta metoda
are si dezavantajul ca nu ia in calcul structura programului (care
poate fi foarte utila in estimare)
Vom propune in continuare doua abordari de estimare a fiabilitatii
Folosesc explicit acoperirea codului in estimare (spre deosebire
de metodele analitice definite pe domeniul timpului)