Testarea Software Ului

  • View
    772

  • Download
    6

Embed Size (px)

DESCRIPTION

Managementul proiectelor software (cursuri si lab)

Text of Testarea Software Ului

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 fundamentaleTestarea 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 264cazuri 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 criterionTest 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:Mrimi cresctoare Mrimi descresctoare Cea mai mare a doua

Caz de test(3,4,5 oarecare) (5,4,3 oarecare) (4,5,3 oarecare)

Isoscel:a=b i c mai mare a=c i b mai mare b=c i a mai mare a=b i c mai mic a=c i b mai mic b=c i a mai mic (5,5,8 isoscel) (5,8,5 isoscel) (8,5,5 isoscel) (8,8,5 isoscel) (8,5,8 isoscel) (5,8,8 isoscel)

Echilateral:a=b=c (5,5,5 echilateral)

Nu e triunghi:a cea mai mare b cea mai mare c cea mai mare (6,4,2 nu e triunghi) (4,6,2 nu e triunghi) (1,2,3 nu e triunghi)

Intrri greite:1 greit 2 greite 3 greite (-1,2,4 date greite) (3,-2,-5 date 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 testareO 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 23=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) a0. 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 structuralTestarea structural se bazeaz pe structura codului. Cel mai simplu criteriu este every statement coverage, cunoscut drept C0 coverage.

3.4.1 C0 coverageAcest 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-BranchPentru modelarea programului cu triunghiul folosind un control flow graph, acest criteriu necesit acoperirea fiecrui arc din digram.

3.4.3 Testarea Every-PathO 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 CoverageAcest 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 C0Exemplu. 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 testingEste 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-dupaths, care necesit toate def-free paths de la fiecare definiie la fiecare folosire posibil. Exemplu. Data flow testing pentru problema triunghiului. dcu singura c-us