Testarea software-ului

1. Introducere
Testarea software-ului se face rulnd software-ul cu date de test. Se
mai numete testare dinamic a software-ului (dynamic software
testing), pentru a se deosebi de analiza static (static analysis), numit
uneori i testare static, care presupune analizarea codului surs
pentru identificarea problemelor.
Dei exist diverse tehnici pentru validarea software-ului, executarea
datelor cu date de test reprezint un pas necesar.
2. Noiuni fundamentale
Testarea exhaustiv este executarea fiecrui caz de test posibil, dar se
face rar, pentru c i la sistemele simple exist foarte multe cazuri de
testare posibile (Exemplu: un program cu 2 intrri de tip ntreg pe 32
bii conduc la un numr de 2
64
cazuri de testare posibile).
Exist dou criterii de baz privind testarea software:
1. ce cazuri de testare s folosim (test case selection)
2. cte cazuri de testare sunt necesare (stopping criterion)
Test case selection se poate baza pe:
specificaii (functional);
structura codului (structural);
fluxul datelor (data flow);
o selecie aleatoare a cazurilor de testare (random).
Obs. Test case selection poate fi vzut ca o ncercare de dimensionare
a cazurilor de testare prin intermediul intrrilor.
Stopping criterion se poate baza pe:
criteriu de acoperire (coverage criterion), cum ar fi executarea a n
cazuri de testare n fiecare subdomeniu;
criterii comportamentale (behavior criteria), cum ar fi testarea pn o
rat a erorilor e mai mic dect un prag impus.
Un program poate fi gndit ca o mapare a spaiului domeniu la un
spaiu al rspunsurilor. Dndu-se o intrare (input), care e un punct n
spaiul domeniu, programul produce o ieire (output), care e un punct
n spaiul rspunsurilor.
Un caz de testare trebuie s includ totdeauna ieirea ateptat
(expected output).
3. Test coverage criterion
Test coverage criterion e o regul despre cum s selectm cazuri de
testare i cnd s ne oprim. Abordarea standard o constituie folosirea
relaiei subsumes.
3.1 Subsumes (includeri)
Un criteriu de testare A subsumeaz criteriul de acoperire a testrii B
dac orice test care satisface criteriul A satisface de asemenea criteriul
B. Asta nseamn c criteriul de acoperire a testrii A include ntr-un fel
criteriul B.
Exemplu. Dac un criteriu de acoperire a testrii necesit ca fiecare
instruciune s fie executat i alt criteriu de acoperire a testrii
necesit ca fiecare instruciune s fie executat plus alte teste
adiionale, atunci al doilea criteriu subsumeaz primul criteriu.
Obs. O mulime bine aleas de cazuri de testare ce satisfac un criteriu
mai slab poate fi mult mai bun dect o mulime aleas mai ru care s
satisfac un criteriu mai puternic.
3.2 Testare funcional (functional testing)
Unul din primii pai este generarea unui caz de testare pentru fiecare
tip distinct de ieire a programului. De exemplu, fiecare mesaj de
eroare trebuie generat. Apoi fiecare caz special ar trebui s aib un caz
de test. Situaiile ce ne pot induce n eroare (tricky situations) ar trebuie
testate. Greelile comune ar trebui testate.
Exemplu. Unul dintre exemplele clasice este urmtorul: pentru trei
numere date la intrare, verificai dac aceste numere pot reprezenta
laturile unui triunghi i n caz afirmativ precizai natura triunghiului.
Soluie. mprim spaiul domeniu n 3 subdomenii, unul pentru fiecare
tip de triunghi: oarecare (scalen), isoscel (2 laturi egale) i echilateral
(toate laturile egale). Identificm dou situaii de eroare: un
subdomeniu cu intrri greite i un subdomeniu n care laturile nu pot
forma un triunghi. Fiecare caz de testare trebuie s specifice valoarea
output-ului.
Subdomeniu
Oarecare:
Caz de test
Mrimi cresctoare (3,4,5 oarecare)
Mrimi descresctoare (5,4,3 oarecare)
Cea mai mare a doua (4,5,3 oarecare)
Isoscel:
a=b i c mai mare (5,5,8 isoscel)
a=c i b mai mare (5,8,5 isoscel)
b=c i a mai mare (8,5,5 isoscel)
a=b i c mai mic (8,8,5 isoscel)
a=c i b mai mic (8,5,8 isoscel)
b=c i a mai mic (5,8,8 isoscel)
Echilateral:
a=b=c (5,5,5 echilateral)
Nu e triunghi:
a cea mai mare (6,4,2 nu e triunghi)
b cea mai mare (4,6,2 nu e triunghi)
c cea mai mare (1,2,3 nu e triunghi)
Intrri greite:
1 greit (-1,2,4 date greite)
2 greite (3,-2,-5 date greite)
3 greite (0,0,0 date greite)
Obs. Lista subdomeniilor poate fi extins. Un caz de testare n fiecare
subdomeniu e soluia minimal, dar acceptabil.
3.3 Matrici de testare
O metod de formalizare a identificrii subdomeniilor este construirea
unei matrici folosind condiiile pe care le identificm din specificaie i
apoi s identificm toate combinaiile acestor condiii ca fiind adevrate
sau false. Se vor folosi toate combinaiile valide de T i F. Dac sunt 3
condiii, vor fi 2
3
=8 subdomenii (coloane). Liniile vor fi folosite pentru
valorile lui a, b i c i pentru ieirile prognozate (expected output)
pentru fiecare subdomeniu.
Exemplu. Condiiile din problema triunghiului pot fi : (1) a=b sau a=c
sau b=c, (2) a=b i b=c, (3) a<b+c i b<a+c i c<a+b, (4) a>0 i b>0 i
c>0. Coloanele matricii vor reprezenta un subdomeniu. Pentru fiecare
subdomeniu, vom plasa un T n fiecare rnd n care condiia e
adevrat i F cnd condiia e fals.
3.4 Testare structural
Testarea structural se bazeaz pe structura codului. Cel mai simplu
criteriu este every statement coverage, cunoscut drept C0 coverage.
3.4.1 C0 coverage
Acest criteriu presuppune c fiecare instruciune a codului ar trebui
executat se un caz de testare. Abordarea normal pentru obinerea
C0 coverage este selectarea cazurilor de testare pn cnd un
instrument de acoperire (coverage tool) indic faptul c toate
instruciunile din cod au fost executate.
Exemplu. Urmtorul pseudocod implementeaz problema triunghiului.
Matricea arat ce linii sunt executate n fiecare caz de test. Primele trei
instruciuni (A, B i C) pot fi considerate pri ale aceluiai nod.
3.4.2 Testarea C1-Every-Branch
Pentru modelarea programului cu triunghiul folosind un control flow
graph, acest criteriu necesit acoperirea fiecrui arc din digram.
3.4.3 Testarea Every-Path
O cale (path) e o secven unic a nodurilor programului care sunt
executate de un caz de testare. n matricea de testare (exemplul de
mai sus), erau 8 subdomenii. Fiecare dintre ele se ntmpl s fie o
cale. n acel exemplu, exist 16 combinaii diferite de T i F. Totui, 8
dintre aceste combinaii sunt ci nerealizabile (infeasible paths), adic
nu exist combinaii de T i F pentru deciziile din program. Poate fi
extrem de dificil s determinm dac calea e nerealizabil, precum i
s gsim un caz de testare care execut acea cale.
Multe programe cu bucle vor avea un numr infinit de ci. n general,
testarea every-path nu e rezonabil.
3.4.4 Multiple-Condition Coverage
Acest criteriu de testare necesit ca fiecare condiie de relaie primitiv
(primitive relation condition) s fie evaluat true i false. n plus, trebuie
ncercate toate combinaiile de T/F pentru relaiile primitive ntr-o
condiie. E de notat c evaluarea lazy a unei expresii (un compilator e
lazy dac, de exemplu, ntr-o expresie cu or prima relaie e true, a doua
nu mai e testat) va elimina anumite combinaii. De exemplu, ntr-un
and dintre dou relaii primitive, a doua nu va mai fi evaluat dac
prima e fals.
Exemplu. n pseudocodul din exemplul de la C0, sunt mai multe
condiii multiple. Primitivele care nu se execut din cauza evalurii lazy
sunt marcate mai jos cu un X.
3.4.5 Subdomain testing (testarea de subdomeniu)
Se bazeaz pe idee partiionrii domeniul de intrare (input domain) n
subdomenii ce sunt mutual excluse i impunerea unui numr de cazuri
de testare egal din fiecare subdomeniu. O idee similar se ntlnea n
cazul matricii de testare. n acest caz ns nu se restricioneaz modul
n care sunt selectate domeniile.
Every-statement coverage i every-branch coverage nu sunt
subdomain tests. Nu sunt subdomenii mutual excluse n ceea ce
privete executarea diferitelor instruciuni sau ramuri. Every-path
coverage este un subdomain coverage.
Exemplu. Pentru problema triunghiului, putem ncepe cu un
subdomeniu pentru fiecare ieire. Acestea se pot subdiviza ulterior n
noi subdomenii, n funcie de faptul dac cel mai mare sau elementul
greit introdus este n prima poziie, a doua poziie sau a treia poziie.
3.4.6 C1 subsumeaz C0
Exemplu. Pentru problema triunghiului, am selectat cazurile de testtare
bune pentru a obine C0 coverage. Cazurile erau:
(3,4,5 oarecare),
(3,5,3 isoscel),
(0,1,0 intrri greite),
(4,4,4 echilateral)
Aceste teste acopereau 4 din 5 ieiri.
Putem obine C1 coverage cu dou cazuri de testare:
(3,4,5 oarecare) i
(0,0,0 intrri greite).
Testul nu este probabil la fel de bun ca primul. Dar obinem astfel att
C1 coverage, ct i C0 coverage.
4. Data flow testing
Este testarea bazat pe fluxul datelor (data flow) ntr-un program.
Datele curg din locul unde sunt definite pn n locul unde sunt folosite.
O definiie de date (sau def.) este atunci cnd o valoare e asignat
unei variabile.
Computation use (sau c-use) este atunci cnd o variabil apare n
membrul drept al unei instruciuni de atribuire. c-use se spune c apare
ntr-o instruciune de atribuire.
Predicate use (sau p-use) este atunci variabila este utilizat n
condiia unei instruciuni de decizie. p-use e asignat ambelor ramuri
ale instruciunii de decizie.
Definition free path (sau def-free) e o cale de la definiia unei
variabile la folosirea acelei variabile care nu include alt definiie a
variabilei.
Exemplu. Pentru problema triunghiului, reprezentm control flow
graph.
Sunt multe criterii de testare a fluxului datelor.
Criteriile de baz includ dcu, care necesit o def-free de la fiecare
definiie pn la c-use; dpu, care necesit o def-free de la fiecare
definiie pn la p-use; du, care necesit o def-free de la fiecare
definiie la orice folosire posibil. Cele mai extinse criterii sunt all-du-
paths, care necesit toate def-free paths de la fiecare definiie la
fiecare folosire posibil.
Exemplu. Data flow testing pentru problema triunghiului.
dcu singura c-use este pentru variabila din nodul k (instruciunea de
ieire)
de la def type n nodul abc la nodul k calea abc,e,g,i,k
de la def type n nodul d la nodul k calea d,e,g,i,k
de la def type n nodul f la nodul k calea f,g,i,k
de la def type n nodul h la nodul k calea h,i,k
de la def type n nodul j la nodul k calea j,k
Exemplu (continuare)
dpu singura p-use este pentru variabilele a,b,c i singura def este
nodul abc
de la nodul abc la arcul abc-d
de la nodul abc la arcul abc-e
de la nodul abc la arcul e-f
de la nodul abc la arcul e-g
de la nodul abc la arcul g-h
de la nodul abc la arcul g-i
de la nodul abc la arcul i-j
de la nodul abc la arcul i-k
du toate defs la toate folosirile
toate cazurile de testare ale dcu i dpu combinate.
all-du-paths toate def-free paths de la toate defs la toate folosirile.
toate cazurile de testare ale dcu i dpu combinate.
5. Testarea aleatoare (random testing)
Se realizeaz prin selectarea aleatoare a cazurilor de testare. Are
avantajul c este rapid. n plus, inferena statistic e mai uoar cnd
testele sunt selectate aleator.
Exemplu. Pentru problema triunghiului, putem folosi un generator de
numere aleatoare i s grupm fiecare mulime de trei numere ca o
mulime de testare. Va trebui s determinm n plus expected output. O
problem ar putea fi faptul c probabilitatea s generm un caz de
testare a echilateralitii e foarte mic.
5.1 Profilul operaional (operational profile)
Testarea n mediul de dezvoltare (development environment) e adesea
diferit de executarea n mediul operaional (operational environment).
O cale de a le face pe acestea similare ar fi s avem o specificare a
tipurilor i probabilitile ca aceste tipuri s se ntlneasc n operaiile
normale. Aceast specificare se numete operational profile.
Prin desenarea cazurilor de testare ale profilului operaional, cel care
face testul va avea mai mult ncredere c acea comportare a
programului n timpul testrii e mai predictiv despre cum se va
comporta n timpul funcionrii.
Exemplu. Un posibil profil operaional pentru problema triunghiului:
Pentru aplicarea testrii aleatoare, se poate genera un numr pentru
selectarea categoriei dup probabiliti i apoi generarea unor numere
suficiente pentru a crea cazul de testare. Dac cumva categoria
selectat a fost cazul echilateral, se va folosi acelai numr pentru
toate cele trei intrri. Un isoscel drept va necesita un numr aleator
pentru lungimea a dou laturi i apoi se poate calcula cealalt latur.
5.2 Inferen statistic la testare
Dac testarea aleatoare a fost fcut prin selectarea aleatorie a
cazurilor de testare dintr-un profil operaional, atunci comportarea
software-ului n timpul testrii ar trebui s fie aceeai cu comportarea
sa n mediul operaional.
Exemplu. Dac selectm 1000 cazuri de testare aleator, folosind
profilul operaional i gsind 3 erori, putem prezice c software-ul va
avea o rat a erorilor mai mic de 3 defeciuni (failures) la 1000 de
execuii n mediul operaional.
5. Boundary testing (testarea de frontier)
De multe ori erorile apar la frontierele dintre domenii. n cod,
instruciunile condiionale determin frontierele domeniilor. Dac avem
o condiie x<=1, atunci frontiera x=1 este n domeniul true. n termeni
de boundary testing, spunem c on tests sunt n domeniul true i off
tests sunt valori ale lui x mai mari dect 1 i sunt n domeniul fals. Dac
o condiie e scris x<1 n loc de x<=1, aunci frontiera x=1 este acum n
domeniul fals.
Boundary testing e fcut cu scopul de a ne asigura c frontiera
adevrat, real (actual) dintre domenii e apropiat pe ct se poate de
frontiera specificat. De aceea, cazurile de testare sunt selectate pe
frontier i n afara frontierei, ct mai apropiat cu putin de frontier.
Testul de frontiera standard const n efectuarea a dou on tests ct
mai departe posibil pe frontier i un off test aproape de mijlocul
frontierei.
Figura de mai jos arat o frontier simpl. Sgeata indic faptul c on
tests ale frontierei sunt n subdomeniul de sub frontier. Cele dou on
tests sunt la captul frontierei i off test-ul chiar deasupra jumtii.
Exemplu. n exemplul cu triunghiul, condiiile primitive, a>=b+c or
b>=a+c or c>=a+b, determin o frontier. Deoarece depinde de trei
variabile, frontiera e un plan n spaiul 3D. On testele ar trebui s fie 2
(sau mai multe) teste separate care au egalitate (de exemplu 8,1,7 i
8,7,1). Acestea sunt amndou adevrate. Off testul va fi n domeniul
false i va fi aproape de mijloc (de exemplu 7.9,4,4).