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 dintr-un 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 utilizator2.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 structurala–pentru aceste tehnici proiectarea cazurilor de testare se bazeaza pe structura interna a componentei verificateTehnicile de testare structural au la baza:Exersarea elementelor de control ale fluxului de executie:Testare instructiuniTestare ramuri executie/deciziiTestare conditii de ramificareTestarea combinatiilor de conditiiExersarea elementelor de control ale fluxului de date

Testarea produselor softwareCazuri 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/unitateExerseaza 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 operationalExerseaza structurile de date interne

Testarea instructiunilorFoloseste un model al controlului fluxului de executie Cazurile de testare vor trebui proiectate astfel incat sa permita executia tuturor instructiunilorselectate din cadrul aplicatieiInstructiune –entitate de executie indivizibila minima in cadrul unui limbaj de programare

Pentru fiecare caz de testare se va specifica:Intrarea/intrarile componenteiInstructiunile ce vor fi exersateIesirea asteptataCriteriu de finalizare a testarii –realizarea unui procent specificat de instructiuni executate macar o singura dataExecutia 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 decizieFolosesc un model de control a executiei aplicatieiEste proiectata astfel incat sa se execute fiecare iesire a tuturor punctelor de decizie selectate din cadrul programului supus testariiO decizie este o instructiune executabila ce poate transfera controlul altei instructiuni in functiede logica unei instructiuni de deciziePentru fiecare caz de testare se va preciza:Intrarea(intrarile) componenteiIdentificarea iesirii(iesirilor) decizionale ce vor fi verificate de prezentul caz Iesirea preconizataCriteriu de finalizare: atingerea unui nivel de 100% in executia ramurilor “true”, respective “false” pentru punctele de decizie selectate.

Combinatii conditie/ramuraFoloseste un model al controlului executiei in care fiecare combinative de intrari de tip decizie/conditie trebuie testate pentru a verifica daca fiecare ramura este acoperitaPentru fiecare caz de testare se va specifica:

Intrarea/intrarile componenteiIesirea asteptata a cazului de testare care poate arata ce ramura a fost acoperita

Criteriu de finalizarea testului–pentru o conditie ce contine n operatori booleeni, rezulta 2n pentru a garanta o acoperirede 100%

Rezumat –testare white-boxTestarea instructiunilorFoloseste un model al controlului executiei programuluiProiectarea va urmari executia tuturor instructiunilor selectate din codul testat

Testare ramura/decizieFoloseste un model al controlului executiei programuluiProiectarea va urmari executia fiecarei iesiri a tuturor punctelor de decizie selectate din cadrul codului testat

Combinatie ramura –conditieFoloseste 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.

Metoda modificata de testare a combinatiilor de conditii

Foloseste un model al controlului fluxului de executiea codului in care fiecare conditie atomic este testate independent pentru a analiza cum afecteaza decizia globalaCazurile de testare sunt proiectate pentru a pune in evident modul cum este afectata iesirea de conditiile independente.Pentru fiecare caz de testare se va specifica:

Intrarea/ intrarile componenteiIesirea asteptata

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 testareExemplu: 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 repetitiveCiclul simplu: 'n' este numarul maxim permis de treceri prin cicluSe sare complet buclaSe trece o singura data prin bucla Se trece de 2 ori prin bucla Se trece de m ori prin bucla, unde m<nSe 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 iteratiiSe continua pana ce toate buclele au fost testate

Masuratori –metrici –indicatori

Masura =Indicator cantitativ al unui atribut asociat unui produs sau processMasuratoare= Proces prin care se obtin masuriMetrica = Indice cantitativ obtinut prin corelarea unor masuri individualeIndicator=Combinatie de metrici ce ofera o perspectiva asupra unor caracteristici de produs sau de proces

Metrici softwareRefera masuri legate de:

procese –ofera o imagine despre sarcini, jaloane, rezultatele efortuluiproduse -specificatii, modele, cod, testware, etc.resurse –hardware, software, umane folosite in dezvoltarea software.

Scop:Contribuie la imbunatatirea proceselorEvalueaza calitatea produselorAsista controlul de calitateAsista 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, robustaEx. Frecventa erorilor, numar linii cod (LOC)

Metrici in testarea softwareClasificare:Metrici de produs –refera calitatea produsului testat sau a rezultatelor testariiMetrici de proces –utilizate pentru evaluarea eficacitatii procesului de testare

Metrici pentru produsele softwareTipuri de produse ce pot fi masurate:Produse de analiza, de design, cod, sisteme de productieCe 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, …)

Masurarea dimensiunii coduluiMasuri 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 suportDeclaratii de date/fisiereLinii fizice versus linii logiceNumarul 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 fiabilitateaComplexitatea esentiala ev(g)

Masoara gradul de structurare, maintenabilitatea, efortul de reinginerie Complexitatea design modul iv(g)

Masoara efortul de integrareComplexitatea globala date gdv(g)

Masoara cuplarea modulului la datele externeComplexitatea specifica date sdv(g)

Masoara structura in corelatie cu un anumit tip de dateunde g este graful asociat controlului executiei codului modul.

Complexitatea designului modulModulele:

Nu exista in conditii de izolareApeleaza module derivateDepind 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 securitatiiIndicator al efortului de testare de securitate necesara pentru a integra modulul

cu restul sistemuluiMasura 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

Cuantifica complexitatea structurala a modulului din punct de vedere al datelor specifice/globale si parametrice:

Date globale –ce pot fi accesate de mai multe moduleDate specifice –sunt specificate de utilizator

Reprezinta:o masura a efortului de testare in raport cu datele globale/specificeo masura a contributiei fiecarui modul la cuplarea datelor sistemului

Implicatiile utilizarii complexitatii ciclomatice in testareAjuta 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

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 minim11<=v(g)<=20 –complexitate medie, risc moderat21<=v(g)<=50 –complexitate mare, risc marev(g)>50 –risc foarte mareProbabilitatea de a nu remedia erorile:

1<=v(g)<=10 5%20<=v(g)<=3020%v(g)>50 40%Intretinere: 1<=ev(g)<=4 –risc mic

ev(g)>4 –risc mare

Perceptii ale fiabilitatii

Definitiile formale ale fiabilitatii nu reflecta, adesea, perceptia utilizatoruluiIpotezele 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 fiabilitatiiEvitarea defectiunilor –tehnicile de dezvoltare vor urmari minimizarea sau reducerea

greselilor inainte ca acestea sa introduca defectiuni in sistemDetectarea 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 produsuluiToleranta 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

Modelarea fiabilitatiiSe poate recurge la un model intrare-iesire al sistemului, unde unele intrari vor

produce iesiri eronateFiabilitatea sistemului reprezinta probabilitatea ca o intrare particulara sa apartina

domeniului de intrari ce produc functionare defectuoasaDeoarece sistemul poate fi folosit diferit de diferiti utilizatori, aceasta probabilitate nu

este un atribut static al sistemului, depinzand de mediul acestuia

Imbunatatirea fiabilitatii

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 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.

Modele de crestere a fiabilitatiiModel 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, nerealistCrestere aleatoare fiabilitate prin variatii ROCOF aleatoare(cresteri si descresteri)

Metrici pentru masurarea rezultatelor testarii

Masoara eficacitatea rezultatelor:

Meticulozitatea testarii –gradul de acoperire al testariiFolosesc criterii de testare ce solicita exersarea sistematica a anumitor tipuri de

elemente din program/specificatieSe vor utiliza masuri relative ale elementelor acoperite in raport cu numarul total de

elementeIntroducerea 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 depistateEste folosita pentru estimarea erorilor program ce vor ramane nedepistateScorul de mutatiePresupune introducerea de modificari in codEficacitatea testarii este masurata prin raportul dintre mutantii introdusi/mutantii

eliminati

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 programRamificatie –puncte decizionale in executieCale –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 acoperireAtinge 100% acoperire la sfarsitul testarii

Acoperirea testarii –pe ramificatiiSe vor exersa toate blocurile decizionale cu toate valorile asociate (true, false), toate cazurile pentru switchAcoperirea 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 multipleCriteriu 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 testuluiSe 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.