Teste de sistem, clasificare si definitii

Teste functionale
Teste nefunctionale prezentare
Crearea cazurilor de test
Black box testing categorii de tehnici
de testare

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.
Procedura de testare = un document ce specifica o secventa de
actiuni pentru executia unei serii de cazuri de testare.

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

Teste
functionale

Teste nefunctionale

Testele de baza se asigura ca sistemul poate fi instalat,

configurat si adus intr-o stare functionala in vederea inceperii
activitatii de testare.

Testele functionale ofera testare acoperitoare peste toate

cerintele, precizate in specificatiile functionale, in
specificatiile cerintelor sau in cazurile de utilizare a produsului.
Ce face sistemul?
Se pot efectua la orice nivel al testarii.
Elemente ce vor fi testate: sisteme de comunicatie, logare,
GUI, securitate, caracteristici tehnice, etc.
Se axeaza mai ales pe interoperabilitate, securitate,
acuratete si conformitate.

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.

Testele de securitate verifica functionalitatea unui sistem (de ex.

Firewall) legata de detectarea amenintarilor exterioare, cum ar fi
virusii.

Testeaza caracteristici de calitate sau atributele

nefunctionale ale unei componente sau ale unui sistem
(de ex. eficienta, mentenanta, portabilitate, fiabilitate
etc.)
Cat de rapid raspunde? sau Cat de bine raspunde?

Testarea nefunctionala (ca si cea functionala) se poate

realiza la orice nivel de testare.
Include (dar nu numai):

Performanta
Incarcare (load)
Stress
Usability
Fiabilitate
Portabilitate
Mentenabilitate

Scop: masoara performantele reale ale sistemului,

comparate cu cele teoretice. Metricile 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 ).
Pentru testarea de performanta este nevoie de un mediu de
test identic cu mediul de productie, precum si de utilitare
folosite pentru masurarea performantelor.

Scalabilitate: capacitatea unui produs software de a fi marit

pentru a face fata unei incarcari crescute.
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

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.

Scop: asigurarea stabilitatii sistemului pe o perioada lunga de

timp cu incarcare completa (load).
Verifica daca un sistem poate face fata la o crestere a
incarcarii sistemului.
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 de zile 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.

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.

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.
Testele de regresie se efectueaza cand produsul sau mediul
de test 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.

Cand un test pica si stabilim faptul ca un defect a

fost cauza, acesta este raportat si fixat.
Dupa fixarea defectului, trebuie sa re-executam
cazul de test, pentru ca confirma faptul ca
defectul a fost intr-adevar indepartat
teste
de confirmare.
Testul trebuie re-executat in exact aceleasi conditii,
cu aceleasi date de test, ca atunci cand s-a
executat prima data.
Nu este suficienta doar retestarea, trebuie
verificate si posibile efecte secundare introduse
prin fixare. Se ruleaza si teste de regresie.

Principalele puncte ale testarii functionale sunt:

Identificarea variabilelor de intrare si de iesire ale

programului si domeniile lor de date.

Determinarea valorilor de intrare care vor face ca
programul sa produca valorile de iesire asteptate.
Calcularea rezultatelor asteptate pentru anumite
valori de intrare.

In cazul testarii valorilor invalide, se

creeaza un caz de test pentru fiecare
valoare.

Primul pas consta in identificarea conditiilor de testare (constrangeri, limitari,

interfete cu alte produse, reguli de comportament, starile produsului, etc.).

Al doilea pas este dezvoltarea cazurilor de test.

Cazurile de utilizare sunt folosite ca punct de pornire, impreuna cu
specificatiile tehnice. Pasii de urmarit pentru obtinerea cazurilor de testare:

Se identifica si metodele folosite in 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 a acoperirii
functionalitatii prin cazuri de tes.
Al treilea pas este cel de dezvoltare a procedurilor de testare.

Se grupeaza cazurile de testare in suite de executie.

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.

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.

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

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 - James Bach
http://www.pairwise.org/tools.asp

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.

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}, {53,54,55},
{54,55,56},{98, 99, 100}
Daca omitem valorile duplicate:
{-1,0,1,14,15,16,17,18,19,53, 54,55,56,98,99,100}

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

Exercitiu: sunt a, b, c
laturile unui triunghi?

Conditii
a,b,c formeaza un
triunghi

b=c

a=b

a=c

Actiuni
Echilateral

Isoscel
Triunghi

Nu e triunghi
Imposibil

*
*

Permit inginerului sa
interpreteze sistemul in
termeni de:

Stari
Tranzitii intre stari
Evenimente care
declanseaza tranzitii
Actiuni rezultate din tranzitii
(ex. Mesaje de eroare)

Tabela de stare arata ca in

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

Stare
initiala

Eveniment

Actiune
(rezultat)

Stare
finala

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.
reset
Schimbare ora

Vizualizare ora

Vizualizare data

schimba

schimba

schimba

set
schimba

Schimbare data

Cele mai bune practici:

Validarea cererilor (ce?) in fata obiectivelor (de ce?)
Aplicarea cazurilor de utilizare comparativ cu cerintele
Se fac examinari de ambiguitate pe cerintele clientilor
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

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

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.

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

Foundations of Software Testing ISTQB

certification
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