testarea blak-box
DESCRIPTION
lucrare de cursTRANSCRIPT
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
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
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
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
"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
Î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
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
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
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
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
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
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
- 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
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
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
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
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