C12 Testarea sSistemelor Software

  • View
    221

  • Download
    0

Embed Size (px)

Text of C12 Testarea sSistemelor Software

  • 1

    TESTAREA TESTAREA TESTAREA TESTAREA SISTEMELOR SOFTWARESISTEMELOR SOFTWARESISTEMELOR SOFTWARESISTEMELOR SOFTWARE

    Testarea software determin dac un sistem software este gata de livrare i estimeaz nivelul de performan al acestuia. Testarea furnizeaz o baz pentru interaciunea cu persoanele implicate n proiect. Creterea complexitii sistemelor software a dus la o cretere a bugetului alocat acestei faze din procesul de dezvoltare al unui proiect (ntre 30 i 50%). O mare parte a efortului necesar realizrii sistemelor software este alocat dezvoltrii modelelor de testare i a aplicaiilor de testare automat. Testarea este procesul execuiei programului cu scopul de a pune n eviden erorile. Detectarea erorilor este scopul principal al testrii. n acelai timp, prezint interes att dezvoltarea unor seturi de date de test adecvate care s conduc la activarea erorilor precum i modalitile de alocare a timpului necesar testrii, n special n sistemele de mare complexitate. n mod obinuit, spunem c un sistem software eueaz atunci cnd nu ndeplinete cerinele impuse. Funcionarea defectuoas poate fi rezultatul unuia dintre urmtoarele motivele:

    Specificaiile sunt greite sau unele cerine ale clienilor nu sunt specificate; Specificaiile pot conine cerine care nu pot fi implementate cu softul disponibil; Proiectarea sistemului poate fi greit. Implementarea codului are defecte; unii algoritmi sunt greit sau incomplet implementai.

    Experiena acumulat de-a lungul timpului n domeniul testrii software a dus la elaborarea unor politici de testare. Spre exemplu, Myers (1976) a propus urmtoarele reguli de baz pentru realizarea testrii sistemelor software:

    Se determin momentul n care se oprete testarea; Responsabilitatea testrii programului revine unui tester, nu celui ce realizat programul; Se descriu rezultatele ateptate pentru fiecare caz de test; Se scriu cazuri de test pentru condiii de intrare valide i nevalide; Se verific rezultatele fiecrui test. Testarea se atribuie celor mai creative persoane din echip

    Pentru proiectele complexe, specificaiile de test pentru sistem i pentru acceptarea acestuia nu trebuie scrise de ctre analiti, proiectani i programatori care au lucrat la proiectul respectiv (pentru sistemele mici i medii e acceptabil ca aceste specificaii s fie scrise de ctre cei ce dezvolt sistemul) ci de ctre utilizatorii sistemului.

    Testarea software cuprinde o multitudine de strategii de testare. n general, metodele de testare sunt specializate, n sensul c cele mai multe proiecte creeaz propriile metode de testare depinznd de produsul respectiv.

    Metodele de testare dinamic presupun executarea programului folosind aa numitele date de test. Datele de test se construiesc conform cerinelor funcionale specificate iar rezultatele furnizate de program se compar cu cele prezentate n specificaii.

    Metodele de testare static cuprind verificarea programului, analiza anomaliilor, inspecia codului. Verificarea programului necesit specificarea precondiiilor la intrare i a postcondiiilor la ieire. Analiza anomaliilor caut eventuale comportri anormale ale programului (spre exemplu, poriuni de cod care nu sunt executate niciodat). Scopul testrii statice este de a analiza sistemul software i de a deduce operaiile sale curente ca o consecin logic a deciziilor de proiectare. Aceast modalitate de testare nu necesit execuia programului.

    1. Clasificarea metodelor de testare

    Metodele de testare pot fi clasificate n dou mari categorii: Testarea black box (cutie neagr). Aceast abordare se concentreaz asupra intrrilor,

    ieirilor i funcionalitii modulelor software.

  • 2

    Testarea white box (cutie alb). Aceast abordare presupune inspectarea structurii codului modulelor software.

    Testarea black box se mai numete testare funcional. Punctul de plecare este fie o specificaie, fie codul. n cazul codului, datele de test trebuie s permit verificarea funcionalitii programului. Testerul nu este interesat de modul n care este implementat programul respectiv, ci de modul n care acesta furnizeaz rspunsul dorit.

    Testarea white box, cunoscut i sub numele de testare structural, presupune analizarea implementrii programului (modulului). Se verific executarea corect a tuturor cilor i ramurilor codului programului testat. n tabelul 1 se prezint cteva metode de testare ce fac parte din cele dou mari categorii prezentate mai sus, metode ce vor fi prezentate pe larg n seciunile ulterioare.

    Tabelul 1 Clasificarea formelor de testare Testare funcional Testare structural Dinamic Testare aleatoare

    Testare pe domenii Graf cauz-efect

    Testare computaional Testare pe domenii Testare ci Generare date Analiza schimbrilor

    Static Verificare specificaii Inspectare cod Verificare program Execuie simbolic Analiz anomalii

    n cazul testrii sistemelor software exist i probleme ce nu in de tehnic. Spre exemplu, se pot pune urmtoarele ntrebri: Cine face testarea? Testarea poate fi realizat de un programator care a fost implicat n scrierea codului? Se apeleaz la un tester independent, se schimb poriuni de cod ntre membrii aceleiai echipe sau se las testarea n seama utilizatorului final? Fiecare dintre alternativele propuse are argumente pro i contra.

    O alt problem fundamental este legat de durata activitilor de testare, cnd apar dou puncte de vedere cel puin contradictorii care trebuie luate n considerare. Primul este al proiectanilor care fac tot posibilul pentru a realiza un produs fr defecte. Cel de-al doilea este al managerilor de proiect care iau n considerare constrngerile de timp impuse proiectului.

    nainte de a intra ntr-o prezentare mai detaliat a diferitelor variante de testare, este important precizarea pailor principali care intervin n orice schem de testare.

    Etapele principale ale unei scheme de testare Selectai ce trebuie msurat (cuantificat) de testul respectiv. nainte de realizarea testului, trebuie identificate scopurile acestuia. Scopurile pot fi diferite (spre exemplu, testarea fiabilitii, testarea completitudinii cerinelor). Decidei cum facei testarea a ceea ce trebuie testat. Dup ce ai stabilit ce este de testat, trebuie s decidei cum realizai testele relevante. Dezvoltai cazurile de test. Pentru tipurile de testare deja acceptate, trebuie creat o colecie de cazuri de test (situaii de test) pentru antrenarea sistemului supus testrii. Determinai rezultatele ateptate ale testului respectiv. Executai cazurile de test.

    Comparai rezultatele obinute cu cele ateptate.

    2. Niveluri ale testrii software

    Testarea software se realizeaz la diferite nivele de-a lungul ntregului ciclu de via al produsului. Testarea ncepe la nivel de componente software individuale. Se verific funcionalitatea i structura fiecrei componente, dup care se face testarea la integrare a componentelor. Standardul IEEE de verificare i validare software (IEEE Std. 1059-1993) identific patru nivele de testare, dup cum se poate observa n tabelul 2. Corespondena ntre nivelele de testare i etapele ciclului de via a sistemului este prezentat n figura 1.

  • 3

    Tabel 2 Testare Definiie Scop Component Se verific implementarea elementelor

    software (ex. Funcii, module). Logica programului este complet i corect. Componentele funcioneaz conform proiectrii.

    Integrare Componentele software i hardware sunt combinate i testate pn la integrarea ntregului sistem

    Obiectivele proiectrii sunt satisfcute

    Sistem Se testeaz sistemul integrat Proiectul software este o entitate complet n concordan cu cerinele operaionale.

    Acceptare Se verific dac rezultatele testelor satisfac criteriile de acceptare ale clienilor

    Obiectivele clienilor sunt satisfcute

    Figura 1. Nivele de observabilitate a testrii

    3. Activiti de test

    n cadrul testrii software se pot delimita urmtoarele activiti cheie: Elaborarea planului de testare Proiectarea testului Stabilirea cazurilor de test Determinarea procedurii de testare Executarea testului Realizarea raportului de testare Planul de testare trebuie s precizeze scopul, tipul abordrii, resursele necesare i un orar al

    activitii de testare. Este necesar de asemenea identificarea surselor i nivelelor de risc i stabilirea persoanele ce realizeaz testarea. Planificarea testrii poate ncepe din momentul n care cerinele sistemului sunt complete. Este dificil determinarea momentului n care se oprete testarea. Din acest motiv trebuie introduse criterii pentru a stabili dac un test este complet sau nu.

    Proiectarea testului rafineaz abordarea propus n planul de testare. n aceast etap se identific principalele caracteristici ce trebuie testate i se definesc cazurile de test asociate. Este recomandat ca proiectarea testelor s se fac pentru o testare de regresiune (testele executate anterior s poat fi repetate la un punct ulterior n procesul de dezvoltare i ntreinere).

    Cazurile i procedurile de test se construiesc n faza de implementare. Se urmrete realizarea unei colecii de cazuri de test ct mai redus care s poat duce la ndeplinirea scopurilor propuse. Cazurile de test bine realizate au o mare probabilitate de a detecta erorile. Procedura de testare identific toi paii necesari operrii sistemului i rulrii cazurilor de test ce implementeaz proiectul de test obinut n etapa anterioar.

    Executarea testului ncepe la nivel de componente i continu cu testarea la integrare, testarea sistemului i testarea de acceptare.

    Raportul de testare rezum toate ieirile testului i subliniaz discrepanele detectate. Activitile de testare se distribuie de-a lungul ntregului ciclu de via al produsului.

    4. Tipuri de teste software

    innd cont de multitudinea metodelor de testare existente este avantajoas luarea n

  • 4

    considerare a testelor n funcie de modalitatea n care acestea