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}, {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}

Tabele de decizie
Regula 1 Conditii Cond1 Cond 2 Cond Y Actiuni Act1 Regula 2 Regula X

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 Actiuni Echilateral Isoscel Triunghi Nu e triunghi Imposibil * * * * * * * * * * * * * y y y y y N y Y y y N y y Y Y N Y N N Y Y N Y N Y Y N N Y N N N N N N N

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

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

Vizualizare data

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

Cum se creaza un scenariu de testare bun?

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