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 nefunctionale

Teste functionale

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 atributelenefunctionale ale unei componente sau ale unui sistem(de ex. eficienta, mentenanta, portabilitate, fiabilitateetc.)› “Cat de rapid raspunde?” sau “Cat de bine raspunde?”

Testarea nefunctionala (ca si cea functionala) se poaterealiza 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.).› Se identifica si metodele folosite in testare.

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:› 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}

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

Regula 1 Regula 2 … Regula X

Conditii

Cond1

Cond 2

…

Cond Y

Actiuni

Act1

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

Conditii

a,b,c formeaza un triunghi

y y y y Y Y Y Y N

b=c y N y Y N N Y N N

a=b y y N Y N Y N N N

a=c y Y y N Y N N N N

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.

Vizualizare ora

Vizualizare data

Schimbare ora

Schimbare data

reset

set

schi

mba

schi

mba

schi

mba

schi

mba

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