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 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 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 interoperabilitateTeste 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.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)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 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 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 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 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 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 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, 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.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. 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. 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 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 reprezentativareprezentativa

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

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

Cond 2

Cond Y

Actiuni

Act1

Tabele de decizie

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

Tabele de tranzitii de stare

Permit inginerului sa interpreteze sistemul in termeni de: Stari 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

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 Exercitiu: tabela de stare

Vizualizare ora

Vizualizare data

Schimbare ora

Schimbare data

reset

set

s

c

h

i

m

b

a

s

c

h

i

m

b

a

s

c

h

i

m

b

a

s

c

h

i

m

b

a

Testarea bazata pe cerinte

Cele mai bune practici:

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

Aplicarea cazurilor de utilizare comparativ cu cerintele 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 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 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 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 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, 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