testarea blak-box

26
REPUBLICA MOLDOVA Ministerul Educatiei din R. Moldova Universitatea Liberă Internaționala din Moldova Facultatea: Informatică si inginerie Obiectul: Testarea produselor software Lucrare de curs Tema: “Testarea Black BoxEfectuat: semnătura Cazacu Victor

Upload: victor-cazacu

Post on 22-Dec-2015

44 views

Category:

Documents


4 download

DESCRIPTION

lucrare de curs

TRANSCRIPT

Page 1: testarea blak-box

REPUBLICA MOLDOVA

Ministerul Educatiei din R. Moldova

Universitatea Liberă Internaționala din Moldova

Facultatea: Informatică si inginerieObiectul: Testarea produselor software

Lucrare de cursTema: “Testarea Black Box”

Efectuat: semnătura Cazacu Victor

Verificat: semnătura

Chișinău 2014

Page 2: testarea blak-box

CUPRINS

1. INTRODUCERE.........................................................…………………...........................31.1. GENERATILĂȚI.........................................................................................................31.2. ISTORIC.......................................................................................................................41.3. METODOLOGIIMODERNE……………………………….......................................61.4. SUBIECTELE TESTĂRII SOFTWARE ....................................................................6

2. Determinarea cazurilor de test …………………………………………………………8 2.1Metoda Testarii “cutie neagră”…………………………………………………………9

2.2Tipuri de testare black-box …………………………………………………………….9

3. Concluzii……………..…………………………………………………..………………15

4. BIBLIOGRAFIE ………………………………………………………………….…….17

2

Page 3: testarea blak-box

1.INTRODUCERE

Testarea Software reprezintă o investigație empirică realizată cu scopul de a oferi

părților interesate informația vizavi de calitatea produsului sau serviciului supus testării, luând în

considerație contextul operațional în care acesta din urma va fi folosit. Testarea Software pune la

dispoziție o viziune obiectivă și independentă asupra produsului în dezvoltare, oferind astfel

businessului posibilitatea de a înțelege și evalua riscurile asociate cu implementarea produsului

soft. Tehnicile de testare includ, dar nu sunt limitate la, procesul de execuție a programului sau

aplicației în scopul identificării defectelor/erorilor de software.

Testarea automatizată - reprezintă o testare dinamică și analitică, care presupune utilizarea a

unui program pentru executarea procedurilor (test case) sau a întregilor scenarii de testare. În

ultimul timp pentru testarea automazizată se folosesc tot mai des așa-numitele xUnit frameworks,

din care fac parte JUnit și NUnit. Ele permit testarea codului de program pentru a verifica

programul în circumstanțe diferite. De exemplu, aceleași proceduri de testare se folosesc pentru a

testa comportamentul programului în diferite sisteme de operare.

Testarea Software mai poate fi definită ca un proces de validare și verificare a faptului că un

program/aplicație/produs software corespunde business cerințelor și cerințelor tehnice care au

ghidat proiectarea și implementarea lui; și rulează și se comportă corespunzător așteptărilor.

În dependență de metodologia de testare aleasa, Testare Software poate fi implementată la orice

etapă în cadrul procesului de dezvoltare, deși partea considerabilă a efortului de testare deobicei

este aplicată la etapa de după cizilarea/formalizarea cerințelor și finisarea implementării/codării

propriu-zise.

1.1Generalități

o Nu există un astfel de proces de testare ce ar permite identificarea tuturor defectelor

posibile ce le poate conține un produs software. În schimb, un astfel de proces poate

furniza o viziune critică sau comparativă, care vine sa contrapună unele aspecte ale

produsului (cum ar fi: starea și comportamentul actual) și metricile și constrângerile care

servesc drept criterii de acceptanță.

3

Page 4: testarea blak-box

o Aceste criterii pot fi derivate din specificații tehnice, produse asemănătoare comparabile,

versiuni anterioare ale aceluiași produs, așteptari față de produs enunțate de către

utilizator sau client, standarde relevante, legi în vigoare, etc.

o Fiecare produs software are o audiență caracteristică. De exemplu, audiența pentru un

produs din industria jocurilor video este complet diferită de audiența unui produs din

sistemul financiar-bancar. De aceea, când o organizație dezvoltă sau investește în

dezvoltarea unui produs software, ea trebuie să fie capabilă să evalueze acceptabilitatea

produsului din perspectiva utilizatorilor finali, audienței țintă, cumpărătorilor și altor părți

interesate. Testarea Software este procesul care vine sa facă această evaluare posibilă

într-un mod cât mai obiectiv.

o Un studiu efectuat în anul 2002 de către NIST a arătat că pierderile anuale pentru

economia S.U.A. cauzate de defecte de software se estimează la 59.5 miliarde de dolari.

Mai mult de o treime din aceste pierderi ar putea fi evitate dacă s-ar face investiții mai

serioase în implementarea procesului de testare.

1.2Istoric

Gelperin și Hetzel au analizat evoluția conceptului de testare a unui sistem informatic și

au împărțit evoluția acestuia în mai multe etape, în funcție de filozofia care a stat la baza

conceptului:

o 1945 - 1956 - Orientarea spre depanare

Testarea programelor informatice este o activitate care a apărut o dată cu procesul de dezvoltare

a acestora. În perioada apariției primelor sisteme informatice - 1945-1956, procesul de testare era

în special orientat către componentele hardware ale sistemului, iar defectele din software erau în

general considerate ca fiind mai puțin importante. Persoanele care elaborau codul se ocupau și de

partea de testare, deși nu o făceau într-o manieră metodică, și denumeau această activitate

verificare. Pentru mulți dintre oamenii de știință care se ocupau de scrierea programelor

informatice nu exista o distincție clară între activitățile de scriere a codului, testare și depanare.

Din această perioadă timpurie datează prima referire la conceptul de "bug" într-un sistem

informatic, când un operator al unui calculator descoperă pe un circuit electronic care funcționa

defectuos o molie, și o atașează în jurnalul de operațiuni, cu mențiunea ca a descoperit primul

4

Page 5: testarea blak-box

"bug" propriu-zis într-un calculator. Termenul de "bug" în sine este mai vechi, datând din

perioada lui Thomas Edison. Primul savant care s-a ocupat de noțiunea de testare a unui program

este Alan Turing care publică în 1949 un articol despre principiile teoretice ale verificării

corectitudinii funcționării unui program. În 1950, Turing publică un alt articol, în care ridică

problema inteligenței artificiale, și definește un test pe care sistemul informatic trebuie să îl

treacă, și anume răspunsurile oferite de către acesta la întrebările adresate de un operator

(testerul) să nu poată fi diferențiate de către răspunsurile oferite de un om (etalonul). Această

lucrare poate fi considerată a fi prima care se ocupă de conceptul de testare, considerat distinct

de activitățile de elaborare a codului respectiv de depanare.

o 1957 - 1978 - Orientarea spre demonstrație

Pe măsură ce sistemele informatice creșteau în număr, complexitate și cost, procesul de

testare a căpătat o importanță tot mai mare. Testarea pe scară largă a devenit necesară datorită

creșterea impactului economic pe care defectele nedetectate le puteau avea. De asemenea,

persoanele implicate în dezvoltarea de programe informatice au devenit mai conștiente de

riscurile asociate cu defectele din programe și au început să pună mai mult accent pe testarea și

remedierea defectelor înainte ca acestea să afecteze produsul livrat. În această perioadă, termenii

de testare și depanare se suprapuneau și se refereau la eforturile făcute în scopul descoperirii,

identificării și remedierii defectelor din sistemele informatice. Scopul procesului de testare era

demonstrarea corectitudinii funcționării programului, adică absența erorilor.

o 1979 - 1982 - Orientare spre defectare

Conceptele de depanare și testare devin mai riguros separate o dată cu publicarea de către

Glenford J. Myers a lucrării The Art of Software Testing, în 1979. Myers face distincția dintre

depanare care este o activitate care ține de dezvoltarea programului și testarea care este

activitatea de rulare a unui program cu scopul declarat de a descoperi erori. De asemenea, el

susține că în testarea bazată pe demonstrație există pericolul ca operatorul să aleagă în mod

inconștient acel set de parametri care ar asigura funcționarea corectă a sistemului, ceea ce

creează pericolul ca multe defecte să treacă neobservate. Myers propune în abordarea sa și o

serie de activități de analiză și control care împreună cu procesul de testare să crească nivelul de

calitate a sistemelor informatice.

o 1983 - 1987 - Orientarea spre evaluare

5

Page 6: testarea blak-box

În 1983, Biroul Național de Standarde din Statele Unite ale Americii publică un set de

practici adresate activităților de verificare, validare și testare a programelor de calculator.

Această metodologie, adresată în mod specific instituțiilor americane federale, cuprinde metode

de analiză, evaluare și testare care să fie aplicate de-a lungul ciclului de viață al aplicației. Ghidul

de bune practici sugerează alegerea unor diverse metode de verificare și validare, în funcție de

caracteristicile fiecărui proiect în scopul creșterii calității generale a produsului.

În anii '70 nivelul de profesionalism al persoanelor implicate în activitatea de testare a crescut

simțitor. Apar posturile dedicate de tester, manager de teste sau analist de teste. Apar de

asemenea organizații profesionale ale celor care activează în domeniul testării software, precum

și publicații specializate, cărți și articole de specialitate. Mai important, instituțiile americane

ANSI și IEEE încep elaborarea unor standarde care să formalizeze procesul de testare, efort

concretizat în standarde precum ANSI IEEE STD 829, în 1983, care stabilea anumite formate

care să fie utilizate pentru crearea documentației de testare.

o 1988 - în prezent - Orientarea spre prevenire

Standardele precedente sunt dezvoltate și îmbunătățite începând cu 1987 când IEEE

publică o metodologie comprehensivă care se aplică în toate fazele ciclului de viață a

programului. Testarea trebuie făcută în toate fazele de lucru, în paralel cu programarea și are

următoarele activități principale: planificare, analiză, proiectare, implementare, execuție și

întreținere. Respectarea acestei metodologii duce la scăderea costurilor de dezvoltare și de

întreținere a unui sistem prin scăderea numărului de defecte care ajung nedetectate în produsul

final.

1.3Metodologii moderne

Metodologiile moderne, precum Agile, Scrum, eXtreme Programming și altele pun un accent

deosebit pe procesul de testare pe care îl integrează în profunzime cu elelalte activități care țin

de dezvoltarea programelor informatice: planificare, proiectare, programare, evaluare și control.

1.4Subiectele Testării Software

Scopul

Scopul primordial pentru procesul de testare este identificarea erorilor de software, izolarea

și fixarea/corectarea defectelor care au cauzat aceste erori. Deseori este un exercițiu non-trivial,

deoarece testarea nu poate demonstra cu certitudine de 100% procente ca produsul funționează 6

Page 7: testarea blak-box

corect în orice condiții; testarea doar poate demonstra că produsul nu funcționează corect în

anumite condiții.În scopul testării deseori se include atât examinarea statică a codului sursă, cât

și examinarea codului în execuție în diferite împrejurări și sub diferite condiții. Aspectele de cod

ce rămân sub ochiul vigilent al test/software inginerului în timpul acestui exercițiu sunt codul

face lucrul care este presupus sa-l facă și codul face lucrul care trebuie sa-l facă. Informația

obținută în urma procesului de testare poate fi folosită pentru corectarea și îmbunătățirea

procesului conform căruia se dezvoltă produsul software.

Defecte și eșuări

Nu toate defectele software sunt cauzate de greșeli în cod. O sursă răspândită de defecte

costisitoare sunt lacunele și neclaritățile la nivel de cerințe, de exemplu, cerințele "ascunse" sau

incomplete pot să rezulte într-un set de erori introduse încă în faza de proiectare de către

designerul programului. Cerințele non-funcționale precum ar fi testabilitatea, scalabilitatea,

mentenabilitatea, usabilitatea, performanța și securitatea, sunt o sursă raspândită de astfel de

erori.

Defectele software se manifestă ca rezultat al următorului proces: un programator comite o

eroare (greșeală), care la rândul ei rezultă într-un defect (bug) la nivel de codul sursă al

programului; dacă acest defect este executat, în anumite condiții sistemul va produce un rezultat

greșit, ceea ce ulterior va duce la o eșuare a programului. Nu toate defectele pot duce la eșuarea

programului. De exemplu, defectele ce se conțin într-o secțiune de cod "mort" niciodată nu vor

duce la eșuarea programului. Defectele se pot manifesta ca eșuări la schimbarea împrejurimii în

care rulează programul. Exemplele de astfel de modificări includ: trecerea pe o platformă

hardware nouă, alterări în sursa de date sau interacțiunea cu software diferit. Un singur defect

poate rezulta într-un spectru larg de simptome prin care se manifestă căderile.

Compatibilitatea

Deseori aplicațiile software cad din cauza problemelor de compatibilititate cauzate atât de

interacțiunea lor cu alte aplicații sau sisteme de operare, cât și de non-conformitățile ce apar de la

o versiune a programului la alta într-un proces inceremental de dezvoltare a produsului.

Incompatibilitățile ce apar între versiuni se datorează faptului ca la momentul scrierii codului

programatorul a considerat, sau a testat, produsul doar pentru un singur sistem de operare (sau un

set restrâns de sisteme de operare), fară a lua în calcul problemele ce pot apărea la schimbarea

7

Page 8: testarea blak-box

contextului de execuție. Un rezultat nedorit al acestui fapt poate fi următorul: ultima versiune a

programului poate să nu mai fie compatibilă cu acea combinație de software/hardware folosită

mai devreme, sau poate să nu mai fie compatibilă cu un careva alt sistem, compatibilitatea cu

care este critic de importantă. Deci, testarea de compatibilitate este o "strategie orientată spre

prevenire", fapt ce clar o asociază cu ultima din fazele de testare propuse de Dave Gelperin și

William C. Hetzel.

Combinări de date de intrare și precondiții

O problema fundamentală a testării software a fost și rămâne imposibilitatea de a testa un

produs utilzând toate combinațiile posibile de date de intrare și precondiții (starea inițială).

Aceasta este adevărat chiar și în cazul produselor simple.

2. Determinarea cazurilor de test

Testarea unui modul, a unui subsistem sau chiar a întregului program presupune stabilirea

unui set de cazuri de test.

Un caz de test cuprinde:

- un set de date de intrare;

- funcția / funcțiile exersate prin datele respective;

- rezultatele (datele de ieșire) așteptate;

În principiu (teoretic) testarea ar trebui să fie exhaustivă, adică să asigure exersarea

tuturor căilor posibile din program. Adesea o astfel de testare este imposibilă, de aceea trebuie să

se opteze pentru anumite cazuri de test. Prin acestea trebuie s ă se verifice r ă spunsul programului

atât la intr ă ri valide cât ș i la intr ă ri nevalide .

Sunt două metode de generare a cazurilor de test, care nu se exclud, de multe ori fiind

folosite împreună. Ambele metode pot sta la baza unor instrumente de generare automată a

datelor (cazurilor) de test:

1. Cazurile de test se determin ă pe baza specifica ț iei componentei testate, fără cunoașterea

realizării ei; acest tip de testare se numește

testare “cutie neagra” (“black box”).

2. Cazurile de test se determin ă prin analiza codului componentei testate . Acest tip de testare se

mai numește și testare “cutie transparentă”, sau testare structurală .

8

Page 9: testarea blak-box

2.1Metoda Testarii “cutie neagră”.

Testarea prin metoda cutiei negre (black box)

Testarea “cutie neagră” se axează pe structura externă a programului, fără a ține seama de

structura logică internă, în special pentru interfețele de software și caracteristici software pentru

a fi testate.

Aceasta metodă testează funcționalitatea aplicației, nu abordează deloc codul și procesele interne

ale aplicației. Tester-ul nu trebuie să știe decat ceea ce trebuie să faca programul, nu și cum face.

Se urmărește „funcția de transfer” a programului: se dau date de intrare și se verifică datele de

ieșire, fără a se știi cum se face prelucrarea lor. Cazuri de testare se construiesc în jurul cerințelor

și specificațiilor. Aceste teste pot fi funcționale (cele mai multe) sau nefuncționale. Aceasta

metodă se poate aplica la toate nivelele de testare: de unitate, de integrare, de sistem și de

acceptare. [8]

Deci se testează:

- Funcționalitatea

- Validarea datelor de intrare (să nu se accepte date de intrare neconsistente,

ca”-1” la data nașterii)

- Datele de ieșire

- Trecerea dintr-o stare în alta a sistemului (de exemplu la programul de

instalare, componentele unei aplicații se instalează intr-o anumita ordine, sau la

realizarea unei conexiuni).

De ce testare black-box ?

- e aplicabilă oricărui produs

- nu necesită efort pentru examinarea / analiza sursei

- aplicabilă de la simplu la complex

- aplicabilă într-o varietate de contexte

2.2Tipuri de testare black-box

Sau: de unde începem testarea ?

9

Page 10: testarea blak-box

Testarea funcțiilor (function testing) fiecare funcție (caracteristică) separat; funcționalitate de

bază testează nu neapărat “dur”, suficient cît să releve erori serioase.

Testarea domeniilor de valori (domain testing)

- esenta: es,antionarea prin reprezentanți ai claselor de echivalență

- initial: pentru fiecare variabilă separat; eventuale combinații, valori alese judicios ⇒ teste

puternice; informative.

Testarea bazată pe specificații

- un fel de testare funcţională parcurge amănunţit specificaţiile -> cazuri de test

specificaţii amănunţite -> valoare ridicată a testării specificaţii vagi -> valoare scăzută a testării.

- teste pentru fiecare afirmație/proprietate din documente de specificație nu foarte

puternice (testează că funcționalitatea e satisfăcută) mai profund: caută

erori/omisiuni/ambiguități/cazuri limită în specificație.

Testare axată pe riscuri (risk-based testing)

- Testorul imaginează cazuri de test bazate pe risc (Ex.)

Gruparea testelor în funcţie de risc -> clasificare puternică

Uşurinţă în crearea testelor, cu focusare pe un anumit risc

Testorul gândeşte din perspectiva riscurilor, programatorul din perspectiva specificaţiilor

- se imaginează o modalitate de eșec și se generează teste pentru ea, testele trebuie să fie

puternice, credibile, motivatoare.

Testarea la limită (stress testing): exercită programul

1) la efort mare

2) la/dincolo de limitele specificate

3) pentru a vedea cum eșuează

- se urmăreşte depăşirea limitelor impuse (Ex.)

foarte importantă pentru aplicaţiile online, multiuser (nr. utilizatori, nr. conexiuni DB)

orice aplicaţie trebuie testată la limită (analogie cu testarea domeniului de valori) – se testează atât valorile limită specificate, cât şi valorile ce depăşesc aceste limite

10

Page 11: testarea blak-box

stabileşte stabilitatea sistemului.

Testarea de regresie

- necesită atenţie deosebită în crearea testelor (manual vs. automat)

refolosirea cazurilor de test în versiuni ulterioare

documentaţie foarte atentă pentru mentenanţă

verifică dacă modificările aduse proiectului au influenţat sau nu

funcţionalitatea conform specificaţiilor

- set de teste proiectate pentru refolosire (la fiecare modificare) bine documentate pentru

mentenanță

Testarea de către utilizatori reali, nu simulați (beta testing);

utilizatori reali

testarea: pe baza specificaţiilor

testele arată impactul asupra utilizatorilor finali – gradul de acceptanţă a acestora

majoritatea acestor teste vor fi simpliste

- pe scenarii specificate dinainte, sau “la liber” credibile, motivatoare, nu foarte puternice

Testarea bazată pe scenarii

- caz specific de utilizare; poate fi bazat pe model (use case) credibil, motivator, ușor de

evaluat, complex mai profund: scenariu de utilizare la limită / ostil.

Testarea bazată pe stări (state-model-based testing)

- modelul: automat cu stări finite

- analiza modelului; și a produsului cu teste bazate pe model

Testarea automată de volum ridicat

- număr mare de teste

rezultatele vor fi testate cu un oracol

rezultatele sunt executate şi interpretate de către calculator

Testare automată vs. Testare asistată de calculator

11

Page 12: testarea blak-box

Testarea prin explorare

- direcționeazî activ procesul de testare, proiectînd teste noi pe baza

informațiilor oferite de cele deja executate

Cazurile de test trebuie să asigure următoarele verificări:

- reacția componentei testate la intrări valide;

- reacția componentei la intrări nevalide;

- existența efectelor laterale la execuția componentei, adică a unor efecte care nu rezultă din

specificație;

- performanțele componentei (dacă sunt specificate).

Deoarece în marea majoritate a cazurilor testarea nu poate fi efectuată pentru toate

seturile de date de intrare (testare exhaustivă), în alegerea datelor de test plecînd de la specificații

se aplică unele metode fundamentate teoretic precum și o serie de euristici.

Alegerea cazurilor de test folosind clasele de echivalen ță

Cazurile de test pot fi alese partiționînd atît datele de intrare cît și cele de ieșire într-un

număr finit de clase de echivalență. Se grupează într-o aceeași clasă datele care, conform

specificației, conduc la o aceeași comportare a programului.

O dată stabilite clasele de echivalență ale datelor de intrare, se alege cîte un eșantion (de

date de test) din fiecare clasă. De exemplu, dacă o dată de intrare trebuie să fie cuprinsă între 10

și 19, atunci clasele de echivalență sunt:

1) valori < 10

2) valori între 10 și 19

3) valori > 19

Se pot alege ca date de test: 9, 15, 20.

Experiența arată că este util să se aleagă date de test care sunt la frontiera claselor de echivalență.

Astfel, pentru exemplul de mai sus ar fi util să se testeze programul pentru valorile de intrare 10

și 19.

Alte cazuri de test se aleg astfel încît la folosirea lor să se obțină eșantioane din clasele de

echivalență ale datelor de ieșire (dun interiorul si de la frontierele lor).

Exemplu:

Fie un program care trebuie să producă între 3 și 6 numere cuprinse între 1000 și 2500. Atunci se

vor alege intrări astfel încît ieșirea programului să fie:

12

Page 13: testarea blak-box

- 3 numere egale cu 1000

- 3 numere egale cu 2500

- 6 numere egale cu 1000

- 6 numere egale cu 2500

- rezultat eronat: mai puțin de 3 numere sau mai mult de 6 numere sau valori în afara intervalului

[1000..2500]

- între 3 și 6 numere cuprinse între 1000 și 2500

In alegerea datelor de test trebuie să se elimine redundanțele rezultate din considerarea

atât a claselor de echivalență de intrare cât și a celor de ieșire.

Unele programe tratează datele de intrare în mod secvențial. în aceste cazuri se pot

detecta erori în program testîndu-l cu diverse combinații ale intrărilor în secvență. Metoda de

partiționare în clase de echivalență nu ajută în alegerea unor astfel de combinații. Numarul de

combinații posibile este foarte mare chiar și pentru programe mici. De aceea nu pot fi efectuate

teste pentru toate combinațiile. în aceste cazuri este esențială experiența celui care alcătuiește

setul de cazuri de test.

Testarea "cutie neagră" este favorizată de existența unei specifiații formale a componentei

testate.

Exemplu:

Fie o funcție de căutare a unui număr întreg într-un tablou de numere întregi, specificată

astfel:

int cauta (int x[], int nrelem, int numar);

pre : nrelem > 0 and exist i in [0..nrelem-1] : x[i] = numar

post : x “[cauta(x,nrelem,numar)] = numar and x' = x’’

error : cauta(x,nrelem,numar) = -1 and x' = x’’

Intrările valide sunt cele care satisfac pre-condiția. Efectele laterale ale funcției "cauta"

s-ar putea reflecta în modificarea unor variabile globale. Pentru evidențierea lor ar trebui ca la

fiecare execuție de test a funcției să se vizualizeze valorile variabilelor globale înainte și după

apelul funcției. Aceste verificări pot fi limitate, înlocuindu-se cu inspectarea codului funcției, din

care rezultă evantualitatea modificării unor variabile globale.

Setul minim de date de test trebuie să verifice funcția în următoarele situații:

1) tablou vid (nrelem=0)

2) tablou cu un singur element (nrelem=1)

a) valoarea parametrului "numar" este în tablou

13

Page 14: testarea blak-box

b) valoarea parametrului "numar" nu este în tablou

3) tablou cu număr par de elemente ("nrelem" este un număr par)

a) "numar" este primul în tablou

b) "numar" este ultimul în tablou

c)"numar" este într-o poziție oarecare a tabloului

d)"numar" nu este în tablou

4) tablou cu număr impar de elemente ("nrelem" este impar)

și a,b,c,d ca la punctul 3.

Din specificație rezultă că funcția nu trebuie să modifice tabloul; de aceea, apelul său în

programul de test trebuie să fie precedat și urmat de vizualizarea parametrului tablou.

Setul cazurilor de test ar putea fi:

1) intrări: orice tablou

nrelem=0

orice număr

ieșiri : valoarea funcției = -1

tabloul nemodificat

2) intrări: x[0] = 10

nrelem=1

număr = 10

ieșiri : valoarea funcției = 0

tabloul nemodificat: x[0]= 10

3) intrări: x[0]= 10

nrelem=1

numr = 15

ieșiri : valoarea funcției = -1

tabloul nemodificat: x[0] = 10

4) intrări: x[0] = 10, x[1] = 20

nrelem=2

numr = 10

ieșiri : valoarea funcției = 0

tabloul nemodificat: x[0] = 10, x[1] = 20

............................................................................................................

In alegerea cazurilor de test s-au folosit următoarele euristici:

programele de căutare prezintă erori atunci când elementul căutat este primul sau ultimul in

structura de date;

14

Page 15: testarea blak-box

de multe ori programatorii neglijează situațiile în care colecția prelucrată în program are un

număr de elemente neobișnuit, de exemplu zero sau unu;

uneori, programele de căutare se comportă diferit în cazurile: număr de elemente din colecție

par, respectiv număr de elemente din colecție impar; de aceea sunt testate ambele situații.

Concluzii:

Dupa cum se poate vedea, testarea software reprezintă o investigație dirijată în

scopul de a obține informații legate de calitatea produsului software, prin rularea

programului în scopul de a descoperi bug-uri software. Este o etapă puternic

dependentă de contextul operațional în care programul va fi folosit.

Testarea nu ofera garantia că produsul funcționează corect în orice condiții ci

numai în acele condiții pentru care a fost testat. Astfel alegerea dintre modalitatile de

testare folosite este esențială pentru acoperirea unei game cât mai largi de posibile erori.

Informația obținută în urma testării este esențială pentru remedierea defectului

respectiv. În momentul în care se detectează o eroare, este posibil să nu se cunoască

și cauza care a generat acea eroare. Programatorul este cel care trebuie ca după

detecția erorii să identifice pe baza acesteia instrucțiunea sau secvența de instrucțiuni

care a dus la apariția erori.

Numai dupa remedierea defectelor se poate trece la etapa urmatoare de

dezvoltare a produsului software.

1. Setul de cazuri de test a fost determinat numai pe baza specifica ț iei componentei ș i a unor

euristici (este vorba de experien ț a celui care efectueaz ă testele) , deci fără să se cunoască

structura internă a componentei, care este tratată ca o “cutie neagră”. Eventuala examinare a

codului sursă nu urmărește analiza fluxului datelor și a căilor de execuție, ci doar identificarea

variabilelor globale cu care componenta interacționează.

2. Clasele de echivalen ță se determin ă pe baza specifica ț iei .

3. Se aleg drept cazuri de test eșantioane din fiecare clasă de echivalență a datelor de intrare.

Experien ț a arat ă c ă cele mai utile date de test sunt acelea aflate la frontierele claselor de

echivalen ță .

4. Cazurile de test alese verifică componenta doar pentru un număr limitat de eşantioane din

clasele de echivalență ale datelor de intrare; faptul că din testare a rezultat că ea funcționează

15

Page 16: testarea blak-box

corect pentru un membru al unei clase nu este o garanție că va funcționa corect pentru orice

membru al clasei.

5. Se determină de asemenea clasele de echivalență ale datelor de ieșire și se aleg pentru testare

datele de intrare care conduc la date de ieșire aflate la frontierele acestor clase.

6. Partiționarea în clase de echivalență nu ajută la depistarea erorilor datorate secvențierii datelor

de intrare. In aceste cazuri este utilă experiența programatorului. Reprezentarea comportării

programului printr-o diagramă de stări-tranziţii poate fi folositoare în determinarea secvențelor

de date de intrare de utlizat în testarea programului.

Testele “cutie neagră”, numite şi teste funcţionale sunt utile nu numai pentru testarea

programului. Ele pot fi utilizate (ca teste statice) pentru verificarea unei specificaţii intermediare

faţă de o specificaţie de nivel superior.

“Slăbiciunile” testelor funcţionale:

- Nu este suficient să se verifice că programul satisface corect toate funcţiile specificate; unele

proprietăţi interne, nespecificate, ca de exemplu timpul de răspuns, nu sunt verificate;

- Programul este testat pentru “ceea ce trebuie să facă” conform specificaţiilor şi nu şi pentru

ceea ce face în plus, de exemplu pentru ca implementarea să fie mai eficientă sau pentru a

facilita reutilizarea;

- In absenţa unui standard în privinţa specificaţiilor formale, tehnicile de testare functională

sunt eterogene

16

Page 17: testarea blak-box

Bibliografie:

- [1] Elfriede Dustin: Effective Software Testing - 50 Specific Ways to Improve

Your Testing- [2] Paul Ammann, Jeff Offutt: Introduction To software testing

- [3] Dan Pilone, Russ Miles: Head First Software Development

- [4] Mauro Pezzand, Michael Young: Software testing and Analisys: Process,

Principles and Techniques

- [5] Kshirasagar Naik, Priyadashi Tripathy: Software Testing and Quality

Assurance

- [6] Gerald D. Everett, Raymond McLeod Jr: Software Testing: Testing Across

the Entire Software Development Life Cycle

- [7] Glenford J. Myers: The Art Of Software Testing, 2nd Edition (2004)

- [8] www.wikipedia.com

- [9] www.informit.com

- [10] www.calsoftlabs.com

- [11] www.searchsoftwarequality.techtarget.com

- [12]www.integrant.com

- [13] www.nresult.com

-[14] http://bigfoot.cs.upt.ro

17