Testarea si asigurarea calitatii

Teste de sistem. Teste

functionale

Cuprins

De ce sa testam?
Teste de sistem, clasificare si definitii
Teste functionale
Teste nefunctionale prezentare
Crearea cazurilor de test
Black box testing categorii de tehnici de
testare

De ce testam?

Ca sa gasim defecte!
Pentru a reduce impactul defectelor aparute la client, pentru a
nu afecta costurile si profiturile .
Pentru a creste fiabilitatea sistemului.
Pentru a creste calitatea produsului.
Pentru a ne asigura ca un produs este conform cu cererile
clientilor.
Cand sa ne oprim din testare?

Am acoperit ceea ce ne stabilisem.

Rata de gasire a defectelor a scazut sub o rata stabilita.
Echipele implicate in proiect cad de acord ca produsul poate fi
livrat.
Managementul decide ca produsul sa fie livrat.

Glosar de termeni

Conditie de testat = eveniment, atribut al unui modul sau sistem care

poate fi verificat (de exemplu: structura, tranzactie, functionalitate)
Date de test = date care afecteaza sau sunt afectate de executia unui
modul specific
Caz de testare (conform IEEE) = un set de valori de intrare, preconditii
de executie, rezultate asteptate si postconditii de executie, dezvoltate
pentru un anume obiectiv sau conditie de testat, pentru a exercita o
anumita cale a programului sau pentru a verifica corespondenta cu o
cerinta.
Specificatia cazului de testare (conform IEEE) = un document
specificand un set de cazuri de testare pentru o conditie de test.
Procedure de testare = un document ce specifica o secventa de
actiuni pentru executia unei serii de cazuri de testare.

Teste de sistem. Clasificare

Teste de baza
Teste functionale
Teste de interoperabilitate
Teste de performanta
Teste de scalabilitate
Teste de stress
Teste de incarcare si stabilitate
Teste de fiabilitate (reliability)
Teste de regresie
Teste de documentatie

Teste nefunctionale

Teste de baza. Teste functionale

Testele de baza se asigura ca sistemul poate

fi instalat, configurat si adus intr-o stare
functionala.
Testele functionale ofera testare
acoperitoare peste toate cerintele, precizate
in documentul de specificatii ale sistemului.
Scopul: testarea functionalitatii sistemului.

Teste functionale

Bazate pe specificatii :

folosesc scenarii (cazuri de testare) derivate din

specificatiile functionale (cazuri de utilizare)

Sunt concentrate pe verificarea sistemului fata de

specificatiile tehnice.
Se pot efectua la orice nivel al testarii.
Testarea securitatii este o parte a testarii functionale,
legata de detectarea defectelor.
Elemente ce vor fi testate: sisteme de comunicatie,
logare, GUI, securitate, caracteristici tehnice, etc.

Teste nefunctionale. Teste de

interoperabilitate

Teste nefunctionale testeaza atributele unei componente sau

ale unui sistem care nu sunt legate de functionalitate (de ex.
Eficienta, mentenanta, portabilitate, fiabilitate etc.)
Teste de interoperabilitate: combina diferite elemente ale
sistemului intr-un singur mediu de testare, pentru a asigura
functionarea lor corecta impreuna.
Sunt create pentru a asigura ca sistemul poate fi interconectat
cu alte sisteme si va continua sa functioneze corect.
Doua tipuri de teste: de compatibility si de backward
compatibility. Verifica functionarea versiunii actuale a sistemului
in cadrul unei platforme mai vechi, precum si mentinerea
vechilor functionalitati.

Teste de performanta

Scop: masoara performantele reale ale sistemului, comparate

cu cele teoretice. Metrica performantelor ce trebuie masurate
variaza de la aplicatie la aplicatie.
Exemplu: timpul de raspuns trebuie sa fie de mai putin de 1
secunda in 90% din cazuri la o aplicatie de genul Calculator
matematic simplu.
Performanta poate fi masurata, urmarind:

Timpul de raspuns
Iesirile sistemului
Utilizarea resurselor

Daca masuratorile de performanta sunt nemultumitoare, atunci

se iau masuri pentru imbunatatire (rescrierea codului, alocarea
mai multor resurse, redesign de sistem ).

Teste de scalabilitate

Scopul: verifica sistemul pentru a isi atinge limitele sale

tehnologice. Un sistem poate functiona intr-un scenariu cu
utilizare limitata, dar nu poate fi extins uneori.
Timpul de rulare al unui sistem poate creste exponential, in
functie de cerinte si poate ceda dupa o anumita limita.
O aplicatie este scalabila daca o crestere a incarcarii
sistemului necesita doar resurse aditionale, fara modificari
extensive ale aplicatiei.
Limitele tehnologice sunt de obicei:

Limitari de stocare a datelor

Limitari de bandwidth
Limitari de viteza - CPU

Teste de stress

sau cum sa facem produsul sa cedeze?

Scop: evaluarea si gasirea comportamentului unei componente
software, la limita sau in afara limitelor sale specificate tehnic.
Sistemul este in mod intentionat stresat, prin impingerea lui dincolo de
limitele specificate. Testele includ asigurarea de resurse putine si
testarea pentru incompatibilitati.
Testele de stress se asigura ca sistemul se comporta acceptabil in
cele mai rele conditii. Daca limitele sunt depasite si sistemul cedeaza,
ar trebui sa intre un mecanism de revenire.
In testele de stress, trebuie urmarita stricarea aplicatiei si
expunerea defectelor ce pot aparea in conditii de stress.

Coruperea datelor
Buffer overflow
Alocarea proasta a resurselor
Deadlocks etc.

Teste de incarcare si stabilitate

Scop: asigurarea stabilitatii sistemului pe o perioada lunga de

timp cu incarcare completa (load).
Un sistem poate functiona foarte bine cand este testat de cativa
ingineri, care il folosesc in mod corect. Totusi, cand intervin un
numar mai mare de utilizatori, care nu cunosc sistemul, si
aplicatii care ruleaza luni fara repornire, se pot intalni diverse
probleme:

Sistemul incetineste
Probleme de functionare
Sistemul se opreste treptat
Sistemul cedeaza complet.

Acest tip de teste ne ajuta sa intelegem cum se va comporta

sistemul in viata reala. Trebuie testate scenarii cat mai realiste.

Teste de fiabilitate

Scop: masurarea capacitatii sistemului de a ramane

operational pentru perioade lungi de timp.
Fiabilitatea sistemului se exprima de obicei in
termeni de timp mediu pana la cedare mean time
to failure (MTTF).
Pe masura ce testam sistemul, observam erorile,
incercam sa indepartam defectele si sa continuam
testarea. Pe masura ce avanseaza testarea, se
inregistreaza duratele de timp intre esecuri
succesive.

Teste de regresie. Teste de

documentatie

Nu se creeaza teste noi la nivel de regresie. Se selecteaza teste dintre

cele existente si sunt executate pentru a asigura ca nu este nimic
defect in noua versiune a produsului software.
Principala idee a testarii pentru regresie este verificarea faptului ca nici
un defect nu a fost introdus in portiunea nemodificata a sistemului,
datorita schimbarilor aduse in alte parti ale sistemului. In timpul testarii
sistemului, multe defecte sunt descoperite si codul este modificat
pentru a repara aceste defecte.
Testele de regresie se efectueaza cand produsul sau mediul sau au
fost schimbate:
Se pot executa la orice nivel de testare
Pot fi automatizate (din motive de costuri si de program)
Testele de documentatie
Scop: verificarea acuratetii tehnice si a lizibilitatii manualelor de
utilizare, inclusiv tutoriale si on-line help.

Procesul de dezvoltare a testelor

Principalele puncte ale testarii functionale sunt:

Identificarea variabilelor de intrare si de iesire ale

programului si domeniile lor de date.
Calcularea rezultatelor asteptate pentru anumite valori de
intrare.
Determinarea valorilor de intrare va face ca programul sa
produca valorile de iesire asteptate.

Primul pas consta in identificarea conditiilor de

testare (constrangeri, limitari, interfete cu alte
produse, reguli de comportament, starile produsului,
etc.).

Procesul de dezvoltare a testelor

A doilea pas este dezvoltarea cazurilor de testare.

Cazurile de utilizare sunt folosite ca input. Pasii de urmarit
pentru obtinerea cazurilor de testare:

Identificarea cazurilor de utilizare.

Pentru fiecare, se identifica unul sau mai multe cazuri de testare.
Pentru fiecare caz de testare, se identifica conditiile de executie.
Adaugarea valorilor datelor.

Prioritatile cazurilor de testare ar trebui stabilite.

Se mentine o matrice de urmarire traceability matrix.

Procesul de dezvoltare a testelor

Al treilea pas este cel de dezvoltare a

procedurilor de testare.
Se grupeaza cazurile de testare in suite de executie.
Factori care trebuie luati in consideratie in
dezvoltarea testelor:

Prioritizare
Dependente logice
Teste de regresie

Analiza riscurilor

Categorii de tehnici de testare

Black box: nici o cunostiinta depsre structura interna nu va fi folosita

White box: bazata pe analiza structurii interne
Fiecare dintre tehnicile de testare black box sau white box are:
O metoda (cum sa executam?)
O abordare a crearii cazului de testare (cum sa cream un caz de testare
folosind aceasta abordare?)
O tehnica de masurare (procentul de acoperire)
Alti termeni:
Bazat pe specificatii: cazurile de testare sunt construite de la specificatiile
modului.
Bazat pe structura: informatii despre modul (design, code) sunt folosite pentru a
crea cazuri de testare.
Bazat pe experienta: cunostiintele testerului despre domeniul specific, despre
defecte probabile etc.

Testarea black box impartirea dupa

echivalente

Pentru a minimiza testarea, impartiti valorile de intrare sau

iesire in grupuri de valori echivalente.

Selectati o valoare din fiecare clasa de echivalenta ca fiind valoare

reprezentativa

Daca o intrare este un interval continuu de valori, atunci exista

de obicei o clasa de valori valide si doua clase de valori
invalide, una inaintea clasei valide si una dupa clasa valida.
Exemplu:
Intr-un magazin, un calculator poate avea o cantitate intre -500
si +500. Care sunt clasele de echivalenta?
Clasa valida: [-500, 500]
Clase invalide: cantitatea < -500, cantitatea > 500.

Testarea black box impartirea dupa

echivalente

Al doilea exemplu: contul bancar poate fi intre 500 si

1000, sau intre 0 si 499, sau 2000. Care sunt clasele
de echivalenta?
Clase valide:

0-499
500-1000
2000-2000

Clase invalide:

Cont < 0
1001-1999
Cont > 2000

Testare all-pairs

In practica, exista situatii cand un numar mare de combinatii trebuie testat. De

exemplu, un website trebuie sa functioneze corect cu mai multe browsere IE
6.0, 7.0, Mozilla 3.5, Google Chrome; folosind diferite plug-in-uri RealPlayer,
Media Player sau deloc; ruland pe diferite sisteme de operare Windows 2000,
XP, Vista; primind pagini de la diferite servere IIS, Apache; ruland pe diferite
sisteme de operare ale servelor Windows 2000, Linux.
Combinatii pentru mediul de testare
4 browsere
3 plug-ins
3 sisteme de operare
2 servere
2 sisteme de operare ale servelor
144 de combinatii posibile
Solutia: testare all-pairs testeaza un subset semnificativ al perechilor de
variabile

http://www.satisfice.com/tools.shtml

Analiza valorilor limita

Limite = capetele claselor de echivalenta

Valori limita = valori la capetele sau aproape de
capetele claselor de echivalenta
Pasii pentru folosirea valorilor limita:

Mai intai, identificarea claselor de echivalenta.

Al doilea pas, identificarea limitelor fiecarei clase de
echivalenta
Al treilea pas, crearea cazurilor de testare pentru fiecare
valoare limita, alegand un punct pe limita, un punct
imediat sub limita si un punct chiar deasupra limitei.
Termenii de sub si deasupra sunt termeni relativi, si
depind de unitatile de masura ale datelor.

Analiza valorilor limita - exemplu

Exemplu: regula de angajare a unei persoane, dupa

varsta:

0-15: nu se angajeaza
16-17: part time
18-54: full time
55-99: nu se angajeaza

Valorile limita sunt: {-1,0,1},

{14,15,16},{15,16,17},{16,17,18}{17,18,19},
{54,55,56},{98, 99, 100}
Daca omitem valorile duplicate:
{-1,0,1,14,15,16,17,18,19,54,55,56,98,99,100}

Tabele de decizie
Regula 1

Regula 2

Regula X

Conditii
Cond1
Cond 2

Cond Y
Actiuni
Act1

Conditiile reprezinta diverse conditii de intrare.

Actiunile sunt actiuni ce se executa, depinzand de diversele combinatii de
conditii de intrare.
Fiecare regula defineste o combinatie unica de conditii care rezulta in executie
si actiuni asociate cu regula.
Actiunile nu depind de ordinea de evaluare a conditiilor, ci doar de valorile lor
Actiunile nu depind de conditiile anterioare de intrare sau de starea sistemului

Tabele de decizie

Exercitiu: sunt a, b, c
laturile unui triunghi?
Conditii
a,b,c formeaza un
triunghi

b=c

a=b

a=c

Isoscel

Triunghi

Actiuni
Echilateral

Nu e triunghi
Imposibil

*
*

Tabele de tranzitii de stare

Permit inginerului sa
interpreteze sistemul in termeni
de:

Stari
Tranzitii intre stari
Evenimente care declanseaza
tranzitii
Actiuni rezultate din tranzitii

Tabela de stare arata ca in

figura.
Se recomanda crearea unui set
de teste care sa acopere
fiecare tranzitie cel putin o data
in testare.

Tabele de tranzitii de stare

Vizualizare data

schimba

schimba

schimba

Exemplu: un ceas electronic cu 4 moduri: vizualizare ora, schimba ora,

vizualizare data, schimba data. Trei butoane: schimba (intre
vizualizare ora si vizualizare data), reset si set.
Exercitiu: tabela de stare
reset
Schimbare ora
Vizualizare ora
set
schimba

Schimbare data

Testarea bazata pe cerinte

Cele mai bune practici:

Validarea cererilor (ce?) in fata obiectivelor (de ce?)

Aplicarea cazurilor de utilizare comparativ cu cerintele
Se fac examinari de ambiguitate
Crearea diagramelor cauza-efect
Verificarea consistentei logice a scenariilor de testare
Scenarii pas cu pas, comparate cu documentele de design
Scenarii pas cu pas, comparate cu codul produsului

Testarea bazata pe scenariu

Atributele unui scenariu bun:

Este bazat pe un scenariu real

Este motivant pentru tester
Este credibil
Implica o utilizare suficient de complexa a mediului si a datelor
Este usor de evaluat

Cum se creaza un scenariu de testare bun?

Scrieti scenarii din viata reala

Listati utilizatorii posibili, analizati interesele si obiectivele lor
Considerati si utilizatori fara experienta
Listati beneficiile sistemului si creati cai de a accesa aceste caracteristici
Urmariti cum utilizatorii folosesc versiuni mai vechi ale sistemului sau un
sistem asemanator
Studiati plangeri sau alte sisteme asemanatoare

Testare bazata pe cazuri de utilizare

Pasi:

Identificarea scenariilor
testelor de utilizare.
Pentru fiecare scenariu, se
identifica unul sau mai
multe cazuri de testare.
Pentru fiecare caz de
testare, se identifica
conditiile care il vor
determina sa se execute.
Se completeaza cazurile
de testare, prin adaugarea
valorile datelor.

Testare bazata pe cazuri de utilizare

Exemplu practic: aplicatie bancara de retragere de numerar de la un bancomat.

Flux de baza: bancomatul este in starea OK.

Initierea retragerii numerarului: se introduce cardul bancar.

Verificarea cardului se citeste banda magnetica si se verifica codul contului.

Se introduce codul PIN din 4 cifre (fara greseli).

Se verifica codul PIN contul este valid si codul PIN introdus este corect si atasat
contului.

Optiunile bancomatului se selecteaza Retragere

Se introduce suma dorita din sumele predefinite (50, 100, 150, 200).

Se verifica in sistemul bancar cardul, pin-ul, suma si informatiile contului. Sistemul

bancar raspunde autorizand retragerea si modifica balanta contului corect.

Suma ceruta este oferita.

Cardul se returneaza.

Chitanta este returnata

Bancomatul revine in stare initiala (OK).

Flux alternativ: la verificarea in sistemul bancar, suma ceruta e mai mare decat soldul
contului. Bancomatul revine la starea de la pasul anterior (introducerea sumei).
Alte exemple de fluxuri alternative?

Testarea bazata pe sintaxa

Testarea bazata pe sintaxa = utilizeaza un model al

sintaxei definite anterior a intrarilor
Se foloseste pentru:

Aplicatii si produse software command-driven.

Aplicatii GUI, care de obicei au campuri cu sintaxa precisa
(de exemplu, numar de telefon, email etc.)
Fisiere XML/HTML
Limbaje de scripting
Limbaje de query pentru baze de date (de exemplu, SQL
are o gramatica precisa).

Testarea dupa sintaxa este singura tehnica black

box fara o metrica de acoperire.

Bibliografie

Curs ISTQB
KSHIRASAGAR N., PRIYADARSHI T., Software
Testing and Quality Assurance: Theory and Practice,
2008 Willy, ISBN 78-0-471-78911-6
Jeff Tian, Software Quality Engineering Testing,
Quality Assurance and Quantifiable Improvement,
ISBN 0-471-71345-7,Wiley-Interscience 2005
www.kaner.com

THE END