C7: 1

Testarea produselor software

Investete n oameni !
Proiect cofinanat din FONDUL SOCIAL EUROPEAN
prin Programul Operaional Sectorial Dezvoltarea Resurselor Umane 2007 2013
Axa prioritar 1: EDUCAIA I FORMAREA PROFESIONAL N SPRIJINUL CRETERII ECONOMICE I DEZVOLTRII SOCIETII
BAZATE PE CUNOATERE
Domeniul major de intervenie 1.2 Calitate n nvmntul superior
Cerere de propuneri de proiecte: nr. 86 Universitate pentru viitor
Titlul proiectului: Reea naional de centre pentru dezvoltarea programelor de studii cu rute flexibile i a unor instrumente didactice la specializarea de
licen i masterat, din domeniul Ingineria Sistemelor
Numrul de identificare al contractului: POSDRU/86/1.2/S/63806
Gabriela Varvara
Testarea produselor software
Curs 7
Testare structurala.
Metrici pentru testare
Partener P4
Obiective
Dezvoltarea de competente
analitice generale referitoare la
Concepte definitorii ale tehnicilor de testare whitebox
Concepte definitorii ale masurilor si metricilor din testare,
Metode de masurare a complexitatii codului,
Metode de estimare a parametrilor de fiabilitate
Metode de determinare a gradului de acoperire a testarii
aplicative referitoare la
deducerea cazurilor de testare bazate pe tehnici de testare structurala
determinare a complexitatii unui cod dat
determinare a gradului de acoperire a testarii
raportarea la standardele specifice de lucru si utilizarea corecta a acestora
2
C7: 2
Testarea produselor software
Cazurile de testare sunt deduse din specificatii (de cod, structura de
date)
Scopul nu il reprezinta validarea proiectului sau a implementarii
Scopul este validarea logicii de implementare
3
Testare structurala (white-box, glassbox)
Testare structurala pentru aceste tehnici proiectarea cazurilor de
testare se bazeaza pe structura interna a componentei verificate
Tehnicile de testare structurala 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
4
C7: 3
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
5
Testarea instructiunilor
Foloseste un model al controlului fluxului de executie
Cazurile de testare vor trebui proiectate astfel incat sa permita executia tuturor instructiunilor selectate 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
6
C7: 4
Testarea produselor software
Exemplu
7
float foo (int a, int b, int c, int d, float e)
{
float e;
if (a == 0) {
return 0;
}
int x = 0;
if ((a==b) OR ((c == d) AND bug(a) )) {
x=1;
}
e = 1/x;
return e;
}
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 functie
de 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, respectiv false
pentru punctele de decizie selectate
8
C7: 5
Testarea produselor software
Exemplu
A = false and (B or C) = false
A = true and (B or C) = true
9
Case A B C Output
1 0 1 1 0
2 1 0 1 1
if A and (B or C)
Combinatii conditie/ramura
Foloseste un model al controlului executiei in care fiecare combinatie
de intrari de tip decizie/conditie trebuie testate pentru a verifica daca
fiecare ramura este acoperita
Pentru fiecare caz de testare se va specifica:
Intrarea/intrarile componentei
Iesirea asteptata a cazului de testare care poate arata ce ramura a
fost acoperita
Criteriu de finalizare a testului pentru o conditie ce contine n
operatori booleeni, rezulta 2
n
pentru a garanta o acoperire de 100%
10
A 0 0 0 0 1 1 1 1
B 0 0 1 1 0 0 1 1
C 0 1 0 1 0 1 0 1
Iesire bloc
decizie
0 0 0 0 0 1 1 1
C7: 6
Testarea produselor software
Rezumat testare white-box
Testarea instructiunilor
Foloseste un model al controlului executiei programului
Proiectarea va urmari executia tuturor instructiunilor selectate din codul testat
Testare ramura/decizie
Foloseste un model al controlului executiei programului
Proiectarea va urmari executia fiecarei iesiri a tuturor punctelor de decizie selectate din
cadrul codului testat
Combinatie ramura conditie
Foloseste 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
11
Metoda modificata de testare a combinatiilor de conditii
Foloseste un model al controlului fluxului de executie a codului in
care fiecare conditie atomica este testata independent pentru a analiza
cum afecteaza decizia globala
Cazurile de testare sunt proiectate pentru a pune in evidenta modul
cum este afectata iesirea de conditiile independente
Pentru fiecare caz de testare se va specifica:
Intrarea / intrarile componentei
Iesirea asteptata
12
C7: 7
Testarea produselor software
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
13
Metoda modificata de testare a combinatiilor de conditii
Exemplu
14
Case A B B or C C Outcome
1 1 1 1 0 1
2 0 0
3 1
1
1 1 0
0
1
4 0 0 0
5 1 0 1 1 1
6 0 0 0
if (A and (B or C))
C7: 8
Testarea produselor software
Testarea instructiunilor repetitive
15
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 proces
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
16
C7: 9
Testarea produselor software
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
17
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)
18
C7: 10
Testarea produselor software
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
19
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:
Dimensiunea numar 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, )
20
C7: 11
Testarea produselor software
Masurarea dimensiunii codului
Masuri folosite:
LOC numar linii cod
SLOC numar linii fizice ale codului activ
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
21
Punct functional
Notare FP (function point)
Masoara dimensiunea unui program independent de dimensiunea
fizica curenta
Reprezinta o suma ponderata a:
Numar intrari/iesiri/interogari utilizator, numar fisiere, numar 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
22
C7: 12
Testarea produselor software
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 date
unde g este graful asociat controlului executiei codului modul.
23
Complexitatea ciclomatica algoritm
V(g) = E-N+2P unde: g
(graf control executie)
E - numarul de ramuri
N numarul de noduri
V(g) numarul ce cai liniar independente din g
Cu cat v(g) este mai mic, modulul este mai simplu.
Pentru v(g)>10 testarea pe modul devine dificila
24
C7: 13
Testarea produselor software
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
25
Complexitatea modulului in raport cu datele globale/specifice
Cuantifica complexitatea structurala a modulului din punct de vedere
al datelor specifice/globale si parametrice:
Date globale ce pot fi accesate de mai multe module
Date specifice sunt specificate de utilizator
Reprezinta:
o masura a efortului de testare in raport cu datele globale/specifice
o masura a contributiei fiecarui modul la cuplarea datelor sistemului
26
C7: 14
Testarea produselor software
Implicatiile utilizarii complexitatii ciclomatice in testare
Ajuta in determinarea numarului de cazuri de testare necesare pentru
a atinge gradul maxim de acoperire pentru un modul particular.
Numarul de cai dintr-un graf de control al executiei reprezinta un
numar maxim al cazurilor de testare (asigura acoperire 100%).
Numarul efectiv de cai de testat poate fi diminuat, unele din cai fiind
imposibil de urmat.
acoperirea ramificatiilor<=complexitatea ciclomatica <=numar cai
27
Analiza structurala bazata pe complexitatea ciclomatica
In raport cu complexitatea exista urmatoarele riscuri majore
adresabile in cod:
Garantarea fiabilitatii:
1<=v(g)<=10 complexitate redusa, risc minim
11<=v(g)<=20 complexitate medie, risc moderat
21<=v(g)<=50 complexitate mare, risc mare
v(g)>50 risc foarte mare
Probabilitatea de a nu remedia erorile:
1<=v(g)<=10 5%
20<=v(g)<=30 20%
v(g)>50 40%
Intretinere: 1<=ev(g)<=4 risc mic
ev(g)>4 risc mare
28
C7: 15
Testarea produselor software
Defecte clasificari, statistici
Pentru cresterea eficacitatii testarii se impune cunoasterea tipurilor si
frecventei de aparitie a defectelor din program.
Aceste sunt utile si pentru:
Predictii ale indicatorilor de calitate
Imbunatatirea proceselor
Standard de clasificare defecte IEEE 1044-2009 defineste criteriile
de clasificare in raport cu:
Proprietatile defectelor
Proprietatile caderilor
29
Tipuri de atribute ale defectelor
De identificare identificator
De localizare
Versiune detectata locatia unde a fost identificat
Versiune corectata
Document suport
Descriere
Stare
Prioritate
Severitate
Probabilitate de cadere
Tipul de activitate in care a fost inserat/detectat
Cadere cauzata
Identificator cerere corectiva
30
C7: 16
Testarea produselor software
Densitatea defectelor
Metrica determinata prin raportul dintre:
Numarul total de defecte identificate
Dimensiunea programului (LOC/FP)
Perioadele de timp ce pot fi luate in considerare:
De la creare modul pana la momentul curent
Perioada unei inspectii
De la data livrarii la beneficiar pana la momentul curent, etc
Utilitate metrica:
Compara numarul relativ de defecte in componente software diferite se pot identifica
module/versiuni/produse ce trebuie inspectate/retestate/supuse procesului de
reinginerie/schimbate
Permite, pentru cazul resurselor limitate, concentrarea efortului pe zonele expuse
defectelor.
Compara lansari succesive evidentiaza reducerea defectelor
31
Metrici pentru fiabilitatea software
Masurarea fiabilitatii software
dificila (intelegere vaga a naturii produselor software)
prin testare operationala
Folosita pentru:
Evaluare produs testat
Stabilire criterii de oprire a testarii
Masurarea fiabilitatii se realizeaza indirect cu ajutorul metricilor pe:
Produs (LOC/FP, complexitate McCabe, de acoperire, ..)
Proces (metrici calitate proces -> nivel de maturitate)
Proiect (legate de metrici de procese din cadrul proiectului)
Erori/caderi au la baza numararea erorilor in unitatea structurala/timp si stabilirea
unei valori relative ce se compara cu date cunoscute
32
C7: 17
Testarea produselor software
Fiabilitate software masuratori si metrici bazate pe defect
Masuratori:
Numar caderi pentru un numar precizat intrari in sistem (POFOD)
Timp (sau numar de tranzactii) intre 2 caderi succesive (ROCOF si MTTF)
Timp de repornire dupa cadere (AVAIL)
Metrici:
Media timpului de functionare (intre 2 caderi observate) relevant pentru sisteme cu
tranzactii lungi (ex. sisteme CAD)
Disponibilitatea masoara, procentual, timpul in care sistemul este functional
(nefunctional -> defect, reparatie, in proces de restart) relevanta pentru sistemele cu
functionare neintrerupta (ex. de timp real)
Unitatile temporale de masura difera in functie de sistem:
Timpul de executie brut pentru sisteme cu functionare non stop
Timpul din programarea calendaristica pentru sisteme cu model folosire cunoscut (ex.
executie intotdeauna o data pe zi)
33
Perceptii ale fiabilitatii
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 folsirea 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
34
C7: 18
Testarea produselor software
Realizari ale fiabilitatii
Evitarea defectiunilor tehnicile de dezvoltare vor urmari
minimizarea sau reducerea greselilor inainte ca acestea sa introduca
defectiuni in sistem
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
Toleranta le defecte se 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
35
Modelarea fiabilitatii
Se poate recurge la un model intrare-iesire al sistemului, unde unele
intrari vor produce iesiri eronate
Fiabilitatea sistemului reprezinta probabilitatea ca o intrare
particulara sa apartina domeniului de intrari ce produc functionare
defectuoasa
Deoarece sistemul poate fi folosit diferit de diferiti utilizatori, aceasta
probabilitate nu este un atribut static al sistemului, depinzand de
mediul acestuia
36
C7: 19
Testarea produselor software
Imbunatatirea fiabilitatii
Inlaturarea a X% din erorile sistemului nu va determina in mod
necesar cresterea fiabilitatii cu X% ( de ex. un studiu IBM a
demonstrat ca eliminarea a 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 utilizatorii sai.
37
Modele de crestere a fiabilitatii
Model matematic al modificarii unui produs software ca urmare a testarii si
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
momente neegale de timp
Simplu, nerealist
Crestere aleatoare fiabilitate prin variatii ROCOF aleatoare (cresteri si descresteri)
ROCOF
are descresteri eliminare erori cu imbunatatire
fiabilitate
are cresteri procesul de reparare erori poate
insera noi erori
38
t1 t2 t3 t4 t5
C7: 20
Testarea produselor software
Metrici pentru masurarea rezultatelor testarii
Masoara eficacitatea rezultatelor:
Meticulozitatea testarii gradul de acoperire al testarii
Folosesc criterii de testare ce solicita exersarea sistematica a anumitor tipuri de elemente din
program/specificatie
Se vor utiliza masuri relative ale elementelor acoperite in raport cu numarul total de elemente
Introducerea artificiala de erori
Introducerea precede testarea; aceasta va pune in evidenta atat erori insamantate cat si alte
erori
Eficacitatea este data de numarul de erori introduse si depistate
Este folosita pentru estimarea erorilor program ce vor ramane nedepistate
Scorul de mutatie
Presupune introducerea de modificari in cod
Eficacitatea testarii este masurata prin raportul dintre mutantii introdusi/mutantii eliminati
39
Acoperirea testarii pe instructiuni
Presupune exersare tuturor instuctiunilor
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
40
C7: 21
Testarea produselor software
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.
41
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 testului
In 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.
42
C7: 22
Testarea produselor software
Acoperirea tuturor cailor de executie
Criteriu de acoperire:
Exersarea tuturor cailor identificate in fluxul de control al executie.
Criteriul este nerealizabil in prezenta buclelor (loops).
Se defineste un criteriu modificat ce permite tratarea tuturor buclelor
ca avand 2 cai:
Calea de executie normala - o singura data
Calea in care bucla este sarita
Unele cai pot sa nu fie parcurse, deoarece nu exista o combinatie de
valori de intrare care sa permita exersarea lor.
Acoperirea pe conditii multiple nu implica acoperirea tuturor cailor si reciproc (ex.
conditii puse secvential de tipul a<=1 si a>4 sunt logic imposibile si determina
cai nepermise greseli de logica in program)
43
Acoperirea bazata pe fluxul de date (1)
Criteriile au la baza urmatoarele definitii:
D-definitie locul unde o variabila primeste o valoare (atribuire, data intrare, fisier,
retea, tastatura, valoare a unui parametru de apel functie)
U-utilizare loc in care valoarea unei variabile este folosita (expresie, instructiune
iesire catre ecran, fisier, retea, valoare de retur dintr-o functie).
Utilizarea se poate realiza in urmatoarele modalitati:
Ca predicat (p-use) o utilizare a valorii ce afecteaza fluxul de control al executiei (ex. atribuire in
instructiuni if, switch)
In scop computational (c-use) utilizarea nu afecteaza imediat fluxul de control (atribuiri in expresii,
iesiri, etc.)
Subcale componenta a grafului de control a executiei ce nu se extinde in mod
necesar de la intrare la iesire.
Subcale fara definitie in care o variabila primeste o valoare (d) foloseste valoarea
primita (u).
44
C7: 23
Testarea produselor software
Acoperirea bazata pe fluxul de date (2)
Criteriu de acoperire:
Pentru toate definitiile - trebuie exersata macar o subcale fara definitie din orice
definitie pana la o folosire a acelei valori
pentru toate utilizarile sa se includa in executie macar o subcale fara definitie
a fiecarei definitii pentru acea utilizare
Pentru toate caile du pentru fiecare utilizare sa se includa in executie toate
subcaile fara definitie fezabile din fiecare definitie a acelei utilizari.
45
Metrica de acoperire pentru mutanti
Se aplica in testarea cu mutatie
Determina gradul de acoperire
Principiu:
M numar de mutanti generati pentru un program
K - numar de mutanti stersi de un set de T cazuri de testare
Q numarul de mutanti echivalenti (identici din punct de vedere al
testarii cu sursa din care provin nu permit generare unui caz nou de
testare)
Atunci scorul de mutatie MS are forma analitica:
MS= K/(M-Q)
46
C7: 24
Testarea produselor software
Metrici asociate procesului de introducere de erori (1)
Metoda introducerii de erori (default seeding):
Estimeaza numarul de erori ce nu a putut fi detectat dintr-un program
Injecteaza in sistem un numar mic de erori
Masoara procentul de defecte ce nu poate fi acoperit de echipa de testare
Principiu: fie un produs cu N defecte, pentru care se injecteaza K
defecte. La sfarsitul testarii vor fi determinate n defecte proprii
programului si k defecte injectate
Teoretic: k n
=
K N
De unde rezulta ca N=n(K/k)
47
Metrici asociate procesului de introducere de erori (2)
In cazul injectiei in cod de erori va trebui sa se considere ca:
Injectia se produce in faza X
Inlaturarea erorii injectate se realizeaza in faza Y
a ciclului de dezvoltare.
Cu cat diferenta Y-X este mai mare cu atat costul inlaturarii este mai mare.
O metoda de testare eficienta va realiza inlaturarea rapida a defectelor injectate.
O masura de eficacitate a metodei este varsta defectului (PhAge)=Y-X
O alta metrica utila Spoilage:
Spoilage=(numar defecte descoperite x PhAge defecte descoperite)/numar total defecte
Masoara tendinta pe termen lung a eficacitatii testarii intr-o organizatie.
48
C7: 25
Testarea produselor software
Metrici de monitorizare a executiei testelor
Utile, de regula, in activitati de management:
Numar de iesiri neasteptate din executia cazurilor de testare deficienta
proiectare
Raportul intre frecventa planificata si cea executata a testelor
Starea testelor executate este monitorizata periodic
Failed
Passed
Blocked uneori se tine evidenta si pe categorii de erori
Invalid
Untested
49
Metrici de monitorizare bazate pe rapoarte de defect
Numarul de functii din proiectare
Numar defecte identificate/inlaturate/inchise/spectaculoase/crash
Frecventa de identificare/inlaturare/inchidere defecte
Eficienta de inlaturare a defectelor:
numar defecte din testare (masurat)
DRE (defect removal efficiency) =
numar total defecte (estimat)
50
C7: 26
Testarea produselor software
Rezumat prelegere
Testarea structurala (white-box):
Definitie si arie de acoerire
Deducerea cazurilor de testare pentru
Executie instructiuni
Parcurgere ramuri/blocuri decizionale
Executie conditie de ramificatie
Executie conditii combinate
Concepte si definitii fundamentale referitoare la evaluarea:
Programului supus testarii sub aspectul
Masuratorilor pe cod necesare in planificarea testarii
Defecte tipuri, clasificari, stari
Densitatea defectelor
Modele de crestere a fiabilitatii
Rezultatelor testarii:
Gradul de acoperire al testarii
Metrici asociate defectelor
51