Tipuri de teste

Modul stub este o secventa de cod care simuleaza comportamentul unei componente
neimplementate inca.
Modul driver este o secventa de cod care conduce integrarea astfel incat unitatea
testata poate primi datele de la componentele neimplementate inca, sau pot fi preluate dintrun fisier.
Teste de integrare
Sunt dedicate verificarii interactiunilor dintre module, grupuri de module, subsisteme, pana
la nivel de sistem.
Exista mai multe metode de realizare a testelor de integrare.
Este necesara implementarea de module "stub" si module "driver".
Numarul de module "driver" si de module "stub" necesare in testele de integrare depinde de
ordinea in care sunt integrate modulele.
Testele de integrare necesita, de asemenea, instrumente de gestiune a versiunilor si a
configuratiilor.
Teste de integrare
Metoda "big-bang"
Sunt integrate intr-un program executabil toate modulele existente la un moment dat.
Modulele "driver " si "stub" necesare sunt de asemenea integrate.
Metoda este periculoasa caci toate erorile apar in acelasi timp si localizarea lor este dificila.
Integrare progresiva
In fiecare pas se adauga ansamblului de module integrate numai un singur modul.
Erorile care apar la un test provin din ultimul modul integrat.
2 metode:
Integrare ascendenta
Integrare descendenta
Teste de sistem
Sunt teste ale sistemului de programe si echipamente complet.
Sistemul este instalat si apoi testat in mediul sau real de functionare.
Sunt teste de conformitate cu specificatia cerintelor software :
teste functionale, prin care se verifica satisfacerea cerintelor functionale
teste prin care se verifica satisfacerea cerintelor ne-functionale :
de performanta,
de fiabilitate,
de securitate, etc.
Adesea, testele de sistem ocupa cel mai mult timp din intreaga perioada de testare.
Tipuri de teste. Teste de acceptare
Sunt teste de conformitate cu produsul solicitat, conform contractului cu clientul (>Specificatia cerintelor utilizatorilor).
Aceste teste sunt uneori conduse de utilizator.
Pentru unele produse software, testarea de acceptare are loc in doua etape:
1.Testarea alfa: se efectueaza folosindu-se specificatia cerintelor utilizator
2.Testarea beta: programul este distribuit unor utilizatori selectionati, realizandu-se astfel
testarea lui in conditii reale de utilizare.

Tipuri de teste. Teste regressive

Teste executate dupa corectarea erorilor, pentru a se verifica daca in cursul corectarii nu au
fost introduse alte erori.
Aceste teste sunt efectuate de regula in timpul intretinerii.
Pentru usurarea lor este necesar sa se arhiveze toate testele efectuate in timpul dezvoltarii
programului, ceea ce permite, in plus, verificarea automata a rezultatelor testelor regresive
Testarea, verificarea si validarea produselor
_ Efectuate pe tot parcursul ciclului de viata
_ Obiectivul: de a reduce erorile software la un nivel acceptabil
_ Cauza/sursa erorilor:
_ Cele mai multe sunt cauzate de deficiente in specificatii
_ Urmeaza cele rezultate in urma erorilor de proiectare
_ Relativ putine (sub 15%) sunt erori directe de programere
_ Efortul necesar: 30-90% din efortul total al proiectului, in functie de complexitatea si gradul
de risc al functionarii necorespunzatoare a software-ului.
_ Organizarea activitatilor de verificare si validare este inclusa in activitatile de management
ale proiectului software si specificate in Planul de Verificare si Validare

Testare structurala (white-box, glassbox)

Testare structuralapentru aceste tehnici proiectarea cazurilor de testare se bazeaza pe
structura interna a componentei verificate
Tehnicile de testare structural au la baza:
Exersarea elementelor de control ale fluxului de executie:
Testare instructiuni
Testare ramuri executie/decizii
Testare conditii de ramificare
Testarea combinatiilor de conditii
Exersarea elementelor de control ale fluxului de date
Testarea produselor software
Cazuri de testare
Drept consecinta, utilizarea tehnicilor de testare white-box permite testerului sa proiecteze
cazuri de testare care:
Exerseaza caile independente de executie dintr-un modul/unitate
Exerseaza toate deciziile logice, atat pe partea de ramura true cat si pe ramura false
Exerseaza buclele atat pe valorile de frontiera cat si pe valorile din intervalul operational
Exerseaza structurile de date interne
Testarea instructiunilor
Foloseste un model al controlului fluxului de executie
Cazurile de testare vor trebui proiectate astfel incat sa permita executia tuturor
instructiunilorselectate din cadrul aplicatiei
Instructiune entitate de executie indivizibila minima in cadrul unui limbaj de programare

Pentru fiecare caz de testare se va specifica:

Intrarea/intrarile componentei
Instructiunile ce vor fi exersate
Iesirea asteptata
Criteriu de finalizare a testarii realizarea unui procent specificat de instructiuni executate
macar o singura data
Executia unei instructiuni inseamna intalnirea si evaluarea instructiunii
Pentru executie instructiuni in procent de 100% este desemnat criteriul de acoperire pe cod in
executie pe instructiune

Testare ramuri/instructiuni decizie

Folosesc un model de control a executiei aplicatiei
Este proiectata astfel incat sa se execute fiecare iesire a tuturor punctelor de decizie
selectate din cadrul programului supus testarii
O decizie este o instructiune executabila ce poate transfera controlul altei instructiuni in
functiede logica unei instructiuni de decizie
Pentru fiecare caz de testare se va preciza:
Intrarea(intrarile) componentei
Identificarea iesirii(iesirilor) decizionale ce vor fi verificate de prezentul caz Iesirea preconizata
Criteriu de finalizare: atingerea unui nivel de 100% in executia ramurilor true, respective
false pentru punctele de decizie selectate.

Combinatii conditie/ramura
1Foloseste un model al controlului executiei in care fiecare combinative de intrari de tip
decizie/conditie trebuie testate pentru a verifica daca fiecare ramura este acoperita
2Pentru fiecare caz de testare se va specifica:
1 Intrarea/intrarile componentei
2 Iesirea asteptata a cazului de testare care poate arata ce ramura a fost acoperita
3Criteriu de finalizarea testuluipentru o conditie ce contine n operatori booleeni, rezulta
2n pentru a garanta o acoperirede 100%

Rezumat testare white-box

1Testarea instructiunilor
1Foloseste un model al controlului executiei programului
2Proiectarea va urmari executia tuturor instructiunilor selectate din codul testat
1Testare ramura/decizie
1Foloseste un model al controlului executiei programului
2Proiectarea va urmari executia fiecarei iesiri a tuturor punctelor de decizie selectate
din cadrul codului testat
1Combinatie ramura conditie
1Foloseste un model al controlului executiei programului pentru care fiecare
combinatie de intrari pentru o decizie/conditie trebuie testata pentru a verifica daca
fiecare ramura este acoperita.
2

Metoda modificata de testare a combinatiilor de conditii

1
2Foloseste un model al controlului fluxului de executiea codului in care fiecare conditie
atomic este testate independent pentru a analiza cum afecteaza decizia globala
3Cazurile de testare sunt proiectate pentru a pune in evident modul cum este afectata
iesirea de conditiile independente.
4Pentru fiecare caz de testare se va specifica:
1 Intrarea/ intrarile componentei
2 Iesirea asteptata
5
Criteriu de finalizare a testarii
Pentru o conditie ce contine n operatori booleeni, pentru atingerea unei acoperiri de
100% sunt necesare :
Minim n + 1 cazuri de testare
Maxim 2n cazuri de testare
Exemplu: pentru 3 operatori booleeni, pentru a atinge un grad de acoperire de 100%
sunt necesare:
Minim 4 cazuri de testare
Maxim 6 cazuri de testare

Testarea instructiunilor repetitive

Ciclul simplu:
'n' este numarul maxim permis de treceri prin ciclu
Se sare complet bucla
Se trece o singura data prin bucla
Se trece de 2 ori prin bucla
Se trece de m ori prin bucla, unde m<n
Se trece de n-1,n,n+1 prin bucla
Cicluri incorporate unele in altele
Se porneste cu bucla cea mai interioara. Se seteaza toate celelalte cicluri pe
valoarea de control minima.
Se testeaza prin crestere cu 1 a contorului buclei interioare, dar cu mentinerea
celorlalte bucle exterioare tot pe valoarea minima a contorului de iteratii
Se continua pana ce toate buclele au fost testate

Masuratori metrici indicatori

Masura =Indicator cantitativ al unui atribut asociat unui produs sau process
Masuratoare= Proces prin care se obtin masuri
Metrica = Indice cantitativ obtinut prin corelarea unor masuri individuale
Indicator=Combinatie de metrici ce ofera o perspectiva asupra unor caracteristici de
produs sau de proces
Metrici software
Refera masuri legate de:
procese ofera o imagine despre sarcini, jaloane, rezultatele efortului
produse -specificatii, modele, cod, testware, etc.
resurse hardware, software, umane folosite in dezvoltarea software.
Scop:
Contribuie la imbunatatirea proceselor
Evalueaza calitatea produselor
Asista controlul de calitate
Asista in luarea unor decizii tactice
Motivatie metrici din perspectiva testarii
Directa: -Determina imbunatatirea calitatii software
-Anticipeaza si reduce nevoile viitoare de cercetare
Indirecta: -Tendinte de evolutie a productivitatii, estimare costuri/calendar pentru proiecte
viitoare, informatii pentru prognoza nevoilor de resurse, favorizeaza evaluarea impactului
asupra productivitatii a introducerii de noi utilitare, etc.
O metrica ideala este:Simpla, aplicabila, valida, robusta
Ex. Frecventa erorilor, numar linii cod (LOC)
Metrici in testarea software
Clasificare:
Metrici de produs refera calitatea produsului testat sau a rezultatelor testarii
Metrici de proces utilizate pentru evaluarea eficacitatii procesului de testare
Metrici pentru produsele software
Tipuri de produse ce pot fi masurate:Produse de analiza, de design, cod, sisteme de
productie
Ce se masoara la aceste produse:
Dimensiuneanumar linii cod, puncte functionale (FP), subsisteme, pagini, documente)
Densitatea de greseli/defecte (masurata ca nr./nr. linii cod sau FP sau propozitii sau
instructiuni, etc.)
Calitatea (corectitudinea, testabilitatea, portabilitatea, fiabilitatea, eficienta, uzabilitatea,
)
Masurarea dimensiunii codului
Masuri folosite:
LOC numar linii cod

SLOC numar linii fizice ale codului active

In general, cu cat SLOC este mai mare pentru un modul, cu atat mai dificil va fi de
inteles si de intretinut acel modul.
Probleme cu folosirea LOC:
Linii executabile sau neexecutabile (comentarii)
Cazuri testare si alte tipuri de aplicatii suport
Declaratii de date/fisiere
Linii fizice versus linii logice
Numarul difera de la un limbaj la altul
Punct functional

Notare FP (function point)

Masoara dimensiunea unui program independent de dimensiunea fizica curenta
Reprezinta o suma ponderata a numarului intrari/iesiri/interogari utilizator,
numarului de fisiere, numarului interfete externe
Independent de limbaj
Metricile bazate pe LOC sau FP masoara complexitatea codului.
Raport LOC/FP determinat empiric pentru diferite limbaje: asamblare -320,
Visual Basic -32, limbaje grafice -4
Metrici McCabe de complexitate a codului intr-un modul

Refera complexitatea sub urmatoarele aspecte:

Complexitate ciclomatica v(g)
Masoara comprehensibilitatea, efortul de testare si fiabilitatea
Complexitatea esentiala ev(g)
Masoara gradul de structurare, maintenabilitatea, efortul de reinginerie
Complexitatea design modul iv(g)
Masoara efortul de integrare
Complexitatea globala date gdv(g)
Masoara cuplarea modulului la datele externe
Complexitatea specifica date sdv(g)
Masoara structura in corelatie cu un anumit tip de dateunde g este graful
asociat controlului executiei codului modul.
Complexitatea designului modul
Modulele:
Nu exista in conditii de izolare
Apeleaza module derivate
Depind de serviciile furnizate de alte module
Complexitatea pe design:
Reflecta interactiunea modulului cu alte module subordonate in conditii de
revizuire din punct de vedere al securitatii
Indicator al efortului de testare de securitate necesara pentru a integra modulul
cu restul sistemului
Masura a structurii de decizie ce controleaza invocarile modulelor imediat
subordonate

Este complexitatea ciclomatica a grafului redus obtinut prin inlaturarea deciziilor si altor noduri
ce nu afecteaza controlul apelului modulului subordonat

Complexitatea modulului in raport cu datele globale/specific

1Cuantifica complexitatea structurala a modulului din punct de vedere al datelor
specifice/globale si parametrice:
1 Date globale ce pot fi accesate de mai multe module
2 Date specifice sunt specificate de utilizator
2Reprezinta:
1 o masura a efortului de testare in raport cu datele globale/specifice
2 o masura a contributiei fiecarui modul la cuplarea datelor sistemului

3
4 Implicatiile utilizarii complexitatii ciclomatice in testare
5 Ajuta in determinarea numarului de cazuri de testare necesare pentru a atinge
gradul maxim de acoperire pentru un modul particular.
6 Numarul de cai dintr-un graf de control al executiei reprezinta un numar maxim
al cazurilor de testare (asigura acoperire 100%).
7 Numarul efectiv de cai de testat poate fi diminuat, unele din cai fiind imposibil de
urmat.
8 acoperirea ramificatiilor<=complexitatea ciclomatica <=numar cai

9 Analiza structurala bazata pe complexitatea ciclomatica

In raport cu complexitatea exista urmatoarele riscuri majore adresabile in cod:
10 Garantarea fiabilitatii:
11
12 1<=v(g)<=10 complexitate redusa, risc minim
13 11<=v(g)<=20 complexitate medie, risc moderat
14 21<=v(g)<=50 complexitate mare, risc mare
15 v(g)>50 risc foarte mare
16 Probabilitatea de a nu remedia erorile:
17
18 1<=v(g)<=10 5%
19 20<=v(g)<=3020%
20 v(g)>50 40%
21 Intretinere: 1<=ev(g)<=4 risc mic
22
23 ev(g)>4 risc mare
24 Perceptii ale fiabilitatii
25
Definitiile formale ale fiabilitatii nu reflecta, adesea, perceptia utilizatorului
Ipotezele presupuse pentru mediul de evolutie a sistemului pot fi incorecte (folosirea unui
sistem intr-un birou este probabil foarte diferita de folosirea lui intr-un mediu universitar)
Consecintele caderii sistemului afecteaza perceptia asupra fiabilitatii
Caderea motorului unui autovehicul este perceputa cu o pondere sporita in raport cu alte
caderi
Realizari ale fiabilitatii
26 Evitarea defectiunilor tehnicile de dezvoltare vor urmari minimizarea sau
reducerea greselilor inainte ca acestea sa introduca defectiuni in sistem
27 Detectarea si inlaturarea defectelor folosirea acelor tehnici de verificare si
validare ce cresc probabilitatea de detectie si corectare a erorilor inainte de
livrarea pe piata a produsului
28 Toleranta le defectese foloseste in dezvoltare de tehnici runtime ce impiedica
defectele sistemului sa determine aparitia de rezultate eronate si/sau erorile
sistemului sa conduca la caderea acestuia
29
30 Modelarea fiabilitatii
31 Se poate recurge la un model intrare-iesire al sistemului, unde unele intrari
vor produce iesiri eronate
32 Fiabilitatea sistemului reprezinta probabilitatea ca o intrare particulara sa
apartina domeniului de intrari ce produc functionare defectuoasa
33 Deoarece sistemul poate fi folosit diferit de diferiti utilizatori, aceasta
probabilitate nu este un atribut static al sistemului, depinzand de mediul
acestuia
34
35 Imbunatatirea fiabilitatii
36 Inlaturarea a X% din erorile sistemului nu va determina in mod necesar
cresterea fiabilitatii cu X% (de ex. Un studio IBM a demonstrate ca eliminarea a

38
39
40
41
42

60% din defectele unui produs va imbunatati fiabilitatea acestuia doar cu

3%)Defectele dintr-un program pot sa existe in zone rar executate, astfel incat
sa nu fie intalnite de utilizatori. Eliminarea acestor erori nu va fi perceputa ca o
crestere a fiabilitatii. Un program cu erori cunoscute poate totusi sa fie acceptat
ca fiabil de catre utlizatorii sai.
37 Modele de crestere a fiabilitatii
Model mathematic al modificarii unui produs software ca urmare a testarii s
inlaturarii defectelor Folosit ca predictor de fiabilitate prin extrapolari bazate pe
date curente.
Depinde de modul cum sunt folosite statistic datele de testare in vederea
masurarii fiabilitatii unei anumite versiuni de program.
Clasificare:
Crestere fiabilitate prin descrestere (ROCOF rate of fault occurrence) cu pasi
egali la moment neegale de timp Simplu, nerealist
Crestere aleatoare fiabilitate prin variatii ROCOF aleatoare(cresteri si
descresteri)

43
3

1
Metrici pentru masurarea rezultatelor testarii
Masoara eficacitatea rezultatelor:
Meticulozitatea testarii gradul de acoperire al testarii
1 Folosesc criterii de testare ce solicita exersarea sistematica a
anumitor tipuri de elemente din program/specificatie
2 Se vor utiliza masuri relative ale elementelor acoperite in raport cu numarul total
de elemente
Introducerea artificiala de erori
3 Introducerea precede testarea; aceasta va pune in evidenta atat erori
insamantate cat si alte erori
4 Eficacitatea este data de numarul de erori introduse si depistate
5 Este folosita pentru estimarea erorilor program ce vor ramane nedepistate
6 Scorul de mutatie
7 Presupune introducerea de modificari in cod
8 Eficacitatea testarii este masurata prin raportul dintre mutantii introdusi/mutantii
eliminati
9
10 Acoperirea testarii pe instructiuni
11 Presupune exersare tuturor instuctiunilor
12 Calculul acoperirii pe instructiuni presupune:

Reprezentarea grafului de control al executie in care:

Nod intrari, iesiri, decizii, instructiuni din program
Ramificatie puncte decizionale in executie
Cale o conectare start stop prin noduri si ramuri
Acoperirea instructiunilor (statement coverage SC) reprezinta numarul minim de cai ce
trebuie parcurse astfel incat sa se asigure trecerea prin toate nodurile
Cea mai slaba forma de acoperire
Atinge 100% acoperire la sfarsitul testarii
Acoperirea testarii pe ramificatii
Se vor exersa toate blocurile decizionale cu toate valorile asociate (true, false), toate cazurile
pentru switch
Acoperirea pe ramificatii (BC branch covering) reprezinta numarul minim de cai intrare-iesire
ce asigura parcurgerea completa a tuturor ramurilor.
Acoperirea ramificatiilor include obligatoriu acoperirea pe instructiuni.
Acoperirea conditiilor multiple
Criteriu de acoperire:
Orice conditie atomica (ce nu include OR sau AND) trebuie sa fie True, respectiv False
intr-un anumit moment al executiei testuluiIn cazul unei conditii multiple (include AND, OR)
orice combinatie de conditii atomice trebuie indeplinita pe perioada executiei testului
Se vor da valori variabilelor de intrare care sa asigure ca toate conditiile atomice sunt
executate.Atingerea criteriului de acoperire pe conditii multiple determina satisfacerea
criteriului de acoperire pe instructiuni, respectiv pe ramificatii.Cazurile de testare reprezinta
toate situatiile de acoperire a conditiilor atomice individuale si din conditiile multiple.
13