Particularitatile Testarii Automate a Sistemelor Informationale

CUPRINS

Introducere

Testarea reprezintă o activitate critică privind calitatea sistemelor, ea reprezentând o ultimă ocazie pentru revizuirea cerințelor sistemului, a specificațiilor de proiectare și a programelor sursă. Obiectivul general al fazei de testare îl reprezintă identificarea numărului maxim de erori cu efort minim.

Programele trebuie testate pentru a avea încredere că vor funcționa cum trebuie. Erorile pot provoca pierderi catastrofale. Personal calificat trebuie să asigure dezvoltarea la timp a produselor software, încadrarea în buget și faptul că sunt de cea mai înaltă calitate în ceea ce privește corectitudinea, siguranța, utilizarea și capabilitatea de a întruni toate specificațiile clienților.

Ca răspuns la cerințele de calitate superioară pentru produsele software și nevoia de profesioniști au apărut în noiembrie-decembrie 1999 standardele IEEE Software. Pregătirea inginerilor se face bazându-se pe principii, standarde, metode, instrumente și pe practică. Dezvoltarea produselor software trebuie văzută ca o disciplină de inginerie, iar calitatea atât în ceea ce privește procesele cât și produsele este de primă importanță pentru profesioniștii din acest domeniu.

Folosind apropierea de inginerie, dezvoltarea programelor presupune ca:

• procesul de dezvoltare să fie bine înțeles;

• proiectele să fie planificate;

• modelele pentru ciclurile de viață să fie bine definite și aplicate;

• standardele să fie aplicate pentru produse și procese;

• să fie luate măsuri pentru verificarea calității produselor și proceselor;

• componentele să fi reutilizate;

• procesele de validare și verificare să joace un rol cheie în determinarea calității;

• inginerii să aibă o educație potrivită și certificări.

Testarea automată poate reduce semnificativ efortul cerut pentru găsirea testelor potrivite, pentru descoperirea erorilor și, de asemenea, timpul necesar pentru testare. Testele, care manual pot dura câteva ore pentru a fi executate, pot fi rulate automat în câteva minute. Folosind testarea automată, organizațiile pot economisi mulți bani și aproximativ 80% din efortul depus în testarea manuală. Testele automate sunt repetabile, folosesc exact aceleași date de intrare, putând fi testate și cele mai mici schimbări cu efort minim. De asemenea, cu cât testarea este mai plictisitoare și presupune același lucru, cu atât este mai necesară folosirea instrumentelor pentru testare automată.

La o primă vedere pare foarte ușor să se realizeze automatizarea testelor: trebuie doar cumpărat unul din cele mai populare instrumente de testare automată, înregistrate testele manuale și apoi rulate atunci când este nevoie. Din păcate, în practică nu funcționează deloc în acest mod. Așa cum proiectarea unui sistem informațional înseamnă mai mult decât doar scrierea codului, așa și testarea automată înseamnă mai mult decât cunoașterea unui instrument de testare manuală.

În lucrare se urmărește detalierea procesului de testare automată și prezentarea instrumentelor cu care se realizează acesta. În acest sens, lucrarea este structurată pe trei capitole:

Capitolul 1 – Fundamentele testării sistemelor informaționale – realizează o prezentare a activității de testare, a principiilor și standardelor ce trebuie respectate în procesul testării. Sunt descrise documentele testării ce cuprind planul de test, definiția cerințelor, descrierea testului și raportul rulării testului. Acest capitol conține și o prezentare a tehnicilor de testare și a nivelurilor de test pentru înțelegerea procesului de testare.

Capitolul 2 – Particularitățile testării automate a sistemelor informaționale– conține o prezentare a tipurilor de testare automată, a avantajelor și limitărilor testării automate. Sunt prezentate cazurile în care este necesară automatizarea testării în cadrul unei organizații și cum se efectuează procesul automat de testare.

Capitolul 3 – Instrumente de testare automată – sunt prezentate cele mai importante instrumente existente pe piață și ce activități automatizează acestea.

Capitolul 1. Fundamentele testării sistemelor informaționale

1.1. Introducere în activitatea de testare

Activitățile de testare sunt realizate într-o mare varietate de moduri în funcție de fiecare organizație. Unele organizații desfășoară aceste activități în mod formal, altele informal până la punctul de a fi aproape haotic. În orice caz, activitățile se desfășoară mai mult sau mai puțin după secvența descrisă în figura 1.1.

Figura 1.1 Activitățile de testare

(după: Fewster, M., Graham, D. – Software Test Automation, Effective use of test execution tools Addison-Wesley, New York 2000, p. 30)

Într-o lume ideală, testarea ar trebui să înceapă cu stabilirea obiectivelor testului la nivelul organizației și politicilor de test, stabilirea strategiilor de testare pentru realizarea obiectivelor. Planificarea testării la nivel managerial ar trebui să includă timpul estimat pentru toate activitățile de testare, resursele necesare, monitorizarea progresului testării și luarea oricăror măsuri necesare pentru urmărirea întregului efort de testare. Aceste activități trebuie făcute la începutul proiectului și continuate pe tot parcursul dezvoltării lui. Cele cinci activități de dezvoltare sunt secvențiale pentru fiecare caz de test, condițiile de test trebuie identificate înaintea proiectării cazului de test, cazul de test trebuie proiectat înainte de a putea fi creat, creat înainte de a putea fi rulat și rulat înainte ca rezultatele să poată fi comparate. Acești cinci pași pot fi executați în mod formal, cu documentarea fiecărui pas sau în mod informal fără documentare.

1.1.1. Definiția formală a “erorii”

Pentru industria software o “eroare” apare când una sau mai multe din următoarele cinci reguli este adevărată:

Programul nu respectă o anumită cerință din specificațiile produsului.

Programul face anumite acțiuni pe care nu trebuie să le facă conform specificațiilor.

Programul face anumite acțiuni pe care specificațiile nu le prevăd.

Programul nu face anumite acțiuni pe care ar trebui să le facă, chiar dacă specificațiile nu le prevăd, deși ar trebui.

Programul este dificil de înțeles, greu de utilizat, încet și, din punctul de vedere al testerilor, ca și al utilizatorilor finali va fi văzut ca și cum nu ar fi fost bine analizat și modelat.

În 1947 calculatoarele erau de dimensiunile unei camere, funcționând cu releuri mecanice și tuburi luminoase. Piesa de rezistență la acea vreme era Mark II, construit la Universitatea Harvard. Când tehnicienii au încercat să pună în funcțiune noua mașină, ea s-a oprit brusc. Ei s-au concentrat să descopere problema și au găsit prins între un set de releuri, în interiorul calculatorului un fluture de molie. Așa s-a născut “bugul” (în traducere insectă) pentru calculatoare.

Erori celebre provocate de “buguri”

În zilele noastre, calculatorul face parte din viața noastră de zi cu zi. În 1947 o persoană obișnuită nu concepea că într-o zi va avea propriul calculator acasă. Acum majoritatea oamenilor își verifică zilnic emailul sau navighează pe internet. Software-ul este peste tot, dar cu toate acestea el este creat de oameni, așa că nu este întotdeauna perfect.

Dispariția navetei NASA's Mars Polar Lander în 1999 în încercarea de aterizare pe Marte s-a dovedit a fi datorată unui bit setat greșit și care a determinat disfuncționalitatea, alarmant fiind faptul că eroarea nu a fost depistată de testele efectuate. Rezultatul a fost catastrofal, iar motivul destul de simplu. Aterizarea a fost testată de mai multe echipe. Una dintre echipe a testat procedura de lansare a trenului de aterizare, iar cealaltă echipă, procedura de aterizare de după acel moment. Prima echipă nu s-a uitat niciodată să vadă dacă bitul de atingere a solului a fost setat, nu era zona lor, a doua echipă reseta tot timpul calculatorul și curăța bitul înainte să înceapă testul. Amândouă etapele lucrau perfect individual, dar puse împreună nu.

Eroarea anului 2000 datorată faptului că programatorul Dave, pentru a salva resurse de memorie, a decis să scurteze datele din formatul de 4 cifre în format de 2 cifre, astfel anul 1973 a devenit 73. El a putut salva importante resurse de memorie, dar nu s-a gândit la problemele care vor apărea când se va ajunge în anul 2000 și programele lui vor face calcule pentru anii 00 sau 01. Remedierea acestei erori a costat câteva sute de miliarde de dolari în întreaga lume pentru calculatoarele care foloseau programele Dave.

De ce apar erorile

Majoritatea erorilor care apar nu sunt cauzate de probleme de programare. După numeroase studii, atât pe proiecte mari, cât și de dimensiuni reduse, s-a demonstrat că majoritatea erorilor sunt cauzate de specificațiile produsului. Sunt câteva motive pentru care specificațiile produc cel mai mare număr de erori. În multe cazuri nu sunt scrise specificații simple și clare, specificațiile se schimbă frecvent și nu se comunică suficient între departamentele de programare și de testare. Planificarea sistemului este fundamentală, deoarece, dacă nu este corect făcută vor apărea multe erori.

A doua mare sursă de erori este proiectarea, schița sistemului. Erorile apar aici din același motiv ca la specificații, proiectarea este făcută în grabă, modificată des și nu există comunicare între echipe.

1.1.2. Costul erorilor

Costurile sunt logaritmice, cresc de zece ori pe măsură ce trece timpul până să fie găsită eroarea. O eroare găsită și fixată într-o fază incipientă, când specificațiile sunt abia scrise, costă foarte puțin sau 1$ cel mult. Aceeași eroare, dacă nu este găsită până în momentul în care softul este codat și testat, costurile pot ajunge la 10$ sau 100S$. Dacă eroarea este descoperită de un client, atunci costurile pot ajunge chiar la milioane de dolari.

Definirea standardelor ca cerințe pentru comunicare, conduce la necesitatea testării produselor relativă la acestea. Standardizarea la nivelul metodologiilor conduce la necesitate modelării, concomitente, atât a cerințelor funcționale, cât și a celor pentru testarea produsului. Din această perspectivă, dezvoltarea software-ului necesită furnizarea unei estimări cât mai realiste asupra efortului necesar pentru îndeplinirea scopurilor propuse și implicit a efortului pentru testare încă din primele cicluri de viață ale produsului. Este demonstrat că 60% dintre proiecte depășesc semnificativ termenele temporale, 50% dintre acestea depășesc costurile, iar 45% sunt inutilizabile la momentul livrării.

Erorile sunt foarte răspândite și dăunătoare încât ele produc pierderi în economia Statelor Unite estimate la aproximativ 59,5 miliarde dolari anual. Studiile au descoperit că, chiar dacă erorile nu pot fi înlăturate total, mai mult de trei sferturi din costuri, aproximativ 22,2 miliarde dolari, pot fi eliminate de o infrastructură mai bine pusă la punct pentru testare, care să permită găsirea mai repede și mai eficientă a erorilor. Impactul erorilor software este enorm deoarece toate afacerile din Statele Unite depind acum de programe destinate dezvoltării, producției, distribuției și suportului după vânzare al produselor și serviciilor.

1.1.3. Definiția testării

Procesul de dezvoltare al software-ului este descris ca o serie de faze, proceduri și pași care trebuie urmați. În procesul de dezvoltare al sistemului sunt incluse și alte procese, inclusiv cel de testare. Câteva din aceste procese sunt prezentate în figura 1.2. Testarea este, la rândul ei, legată de alte două procese verificare și validare.

Validarea este procesul de evaluare a unui sistem software sau a unei componente în timpul sau la sfârșitul ciclului de dezvoltare pentru a determina dacă este în concordanță cu cerințele specificate.

Validarea este asociată frecvent cu testarea bazată pe execuție.

Verificarea este procesul de evaluare a sistemului software sau a componentelor pentru a determina dacă produsul aflat într-o anumită fază de dezvoltare satisface condițiile impuse la începutul fazei respectrii produselor relativă la acestea. Standardizarea la nivelul metodologiilor conduce la necesitate modelării, concomitente, atât a cerințelor funcționale, cât și a celor pentru testarea produsului. Din această perspectivă, dezvoltarea software-ului necesită furnizarea unei estimări cât mai realiste asupra efortului necesar pentru îndeplinirea scopurilor propuse și implicit a efortului pentru testare încă din primele cicluri de viață ale produsului. Este demonstrat că 60% dintre proiecte depășesc semnificativ termenele temporale, 50% dintre acestea depășesc costurile, iar 45% sunt inutilizabile la momentul livrării.

Erorile sunt foarte răspândite și dăunătoare încât ele produc pierderi în economia Statelor Unite estimate la aproximativ 59,5 miliarde dolari anual. Studiile au descoperit că, chiar dacă erorile nu pot fi înlăturate total, mai mult de trei sferturi din costuri, aproximativ 22,2 miliarde dolari, pot fi eliminate de o infrastructură mai bine pusă la punct pentru testare, care să permită găsirea mai repede și mai eficientă a erorilor. Impactul erorilor software este enorm deoarece toate afacerile din Statele Unite depind acum de programe destinate dezvoltării, producției, distribuției și suportului după vânzare al produselor și serviciilor.

1.1.3. Definiția testării

Procesul de dezvoltare al software-ului este descris ca o serie de faze, proceduri și pași care trebuie urmați. În procesul de dezvoltare al sistemului sunt incluse și alte procese, inclusiv cel de testare. Câteva din aceste procese sunt prezentate în figura 1.2. Testarea este, la rândul ei, legată de alte două procese verificare și validare.

Validarea este procesul de evaluare a unui sistem software sau a unei componente în timpul sau la sfârșitul ciclului de dezvoltare pentru a determina dacă este în concordanță cu cerințele specificate.

Validarea este asociată frecvent cu testarea bazată pe execuție.

Verificarea este procesul de evaluare a sistemului software sau a componentelor pentru a determina dacă produsul aflat într-o anumită fază de dezvoltare satisface condițiile impuse la începutul fazei respective.

Fig. 1.2. Procesele incluse în dezvoltarea unui sistem

(după: Fewster, M., Graham, D. – Software Test Automation, Effective use of test execution tools, Addison-Wesley, New York 2000, p. 30)

Verificarea este frecvent asociată cu activități ca revizuirea și inspecția softului.

Activitatea de testare este definită în multe moduri, dar două definiții sunt mai elocvente:

Testarea este un grup de proceduri menite să evalueze unele aspecte dintr-o componentă software.

Testarea poate fi descrisă ca un proces folosit pentru a descoperi erori în software și de a stabili că programul a atins un anumit grad al calității în raport cu atributele alese.

Aceste definiții includ în domeniul testării următoarele: revizuirile tehnice, planificarea testării, proiectarea cazurilor de test, testarea componentelor, a modulelor, a sistemului, teste de acceptanță și de utilizare. Testarea este definită ca un proces cu două scopuri – unul pentru găsirea erorilor, iar altul pentru evaluarea atributelor de calitate ale soft-ului precum securitate, corectitudine, exactitate și utilitate. De asemenea, testarea și localizarea erorilor sunt două activități foarte diferite. Procesul de localizare al erorilor începe după ce testarea s-a terminat și testerul a semnalat problemele care au apărut.

Testarea ca proces cuprinde aspecte economice, tehnice și manageriale. Aspectele economice sunt legate de faptul că resursele și timpul disponibil este limitat și din acest motiv testarea completă de multe ori nu este posibilă. Organizațiile trebuie să-și structureze procesul de testare astfel încât să poată livra programul la timp și să se încadreze în bugetul stabilit și de asemenea să satisfacă cerințele clientului. Testarea este un proces și de aceea trebuie gestionat. Succint aceasta înseamnă că politicile de testare din organizație trebuie definite și documentate. Testarea trebuie plănuită, testerii trebuie pregătiți, procesul trebuie să aibă asociate scopuri cuantificabile ce pot fi măsurate și monitorizate. Testarea ca proces trebuie să evolueze până la un nivel în care să existe mecanisme pentru a face îmbunătățiri continue.

1.2. Principiile testării sistemelor informaționale

Principiile joacă un rol important în toate disciplinele ingineriei și sunt introduse ca parte a unui fundament educațional în fiecare ramură a ingineriei. Principiile de testare sunt foarte importante pentru inginerii specialiști în testare, deoarece oferă baza dezvoltării cunoștințelor și acumulării de experiență în testare.

Principiile ingineriei software se referă la reguli, legi sau doctrine legate de sistemele informaționale, cum sunt ele construite și cum se comportă. Testarea, ca o componentă a ingineriei software, are un set specific de reguli care servesc drept indicator pentru testeri. Aceste reguli ghidează testerii în definirea testelor pentru sistemului informațional.

Glenford Myers în cartea sa “Arta testării software” (The Art of Software Testing), a evidențiat un set de principii ale testării bazate pe execuție.

Principiul 1. Testarea este procesul de utilizare a unor componente software pe baza unui set de cazuri de test cu intenția de a descoperi erorile și de a evalua calitatea.

Inginerii software au făcut mari progrese în dezvoltarea unor metode pentru prevenirea și eliminarea erorilor. Cu toate acestea, erorile apar și au un impact negativ asupra calității sistemelor informaționale. Testerii trebuie să depisteze aceste erori înainte ca sistemul să devină operațional. Acest principiu asigură că testarea este o activitate bazată pe execuție pentru descoperirea erorilor și de asemenea asigură separarea testării de depanare (debugging), deoarece aceasta din urmă are rolul de a localiza erorile și de a le repara.

Principiul 2. Când scopul testului este detectarea de erori, atunci un bun caz de test este acela care are o mare probabilitate de a descoperi erorile necunoscute până acum.

Acest principiu sprijină pregătirea cu atenție a cazurilor de test și oferă un criteriu pentru evaluarea lor și eficacitatea efortului de testare atunci când obiectivul este detectarea erorilor. La sfârșitul testului, rezultatele sunt interpretate și comparate cu cele așteptate pentru a vedea dacă ipoteza este aprobată sau nu.

Principiul 3. Rezultatele testului trebuie analizate cu atenție.

Testerii trebuie să investigheze și să interpreteze cu mare atenție rezultatele testului. Altfel se pot strecura erori care duc mai târziu la costuri mari pentru repararea lor. De exemplu:

O eroare poate fi trecută cu vederea iar testul poate fi trecut în starea “pass” (succes) când în realitate sistemul are erori și nu a trecut testul, a dat “fail”. Testul poate continua bazându-se pe rezultate greșite. Eroarea poate fi depistată mai târziu într-o fază mai târzie a testării, dar în acest caz este mai costisitor să fie localizată și reparată.

În unele cazuri poate fi suspectată existența unei erori când de fapt ea nu există în realitate și în acest caz testul este trecut în starea “fail”. Se va cheltui astfel mult timp și efort în căutarea unei erori care nu există de fapt. O reexaminare atentă a rezultatelor testului va indica în final că nu a apărut nici o eroare.

Rezultatele unui test de calitate pot fi uneori neînțelese, rezultând necesitatea unui efort suplimentar pentru rezolvarea unei probleme critice.

Principiul 4. Un caz de test trebuie să conțină rezultatul așteptat.

Rezultatul așteptat permite testerului să determine dacă a descoperit o eroare și care va fi starea testului “pass” (succes) sau “fail” (eroare). Este foarte important ca rezultatul așteptat să fie trecut corect pentru a nu se mai pierde timp suplimentar datorat unei înțelegeri greșite a rezultatului. Specificațiile intrărilor și ieșirilor testului trebuie să facă parte din activitatea de creare a test planului. În cazul unor teste de calitate, este folositor să fie trecut cantitativ gradul calității ce se dorește să fie obținută.

Principiul 5. Cazurile de test trebuie concepute atât pentru intrările valide cât și pentru cele invalide.

Testerul nu trebuie să presupună că sistemul informațional testat va da întotdeauna rezultate valide. Folosirea cazurilor de test bazate pe intrări invalide este foarte eficientă pentru descoperirea de erori deoarece, se pot descoperi comportamente neașteptate ale programelor. De asemenea, aceste teste ajută programatorii și testerii să evalueze rezistența programului și anume abilitatea lui de a reveni după erori neașteptate prin mecanismul de recuperare.

Principiul 6. Probabilitatea existenței unor erori adiționale în componentele software este proporțională cu numărul de erori deja detectate în componenta respectivă.

Cu cât numărul de erori descoperite deja într-o componentă este mai mare, cu atât este mai probabil descoperirea unor erori adiționale la testele mai aprofundate. Principiul se bazează pe ideea că erorile apar adesea împreună, în codul cu o complexitate mare și o proiectare slabă. Această problemă este deosebit de importantă pentru modulele ce implementează funcții critice cum ar fi salarizare, buget etc.

Principiul 7. Testarea trebuie făcută de o echipă separată de echipa de programare.

Acest principiu se bazează atât pe motive psihologice, cât și practice. Este dificil pentru un programator să admită că programul creat de el poate conține erori. Testerii trebuie să realizeze faptul că programatorii pun multă mândrie în munca lor și la un nivel practic le vine greu să realizeze unde pot fi erori. De multe ori, chiar și atunci când testul eșuează, programatorilor le vine greu să localizeze eroarea deoarece au o altă reprezentare a codului decât este el în realitate. De asemenea pot exista și erori datorate neînțelegerii cerințelor. Un grup de testare poate exista în organizație fie ca o entitate separată sau testerii pot fi membri ai grupului de asigurare a calității din organizație. O independență între grupul testerilor și cel al programatorilor nu înseamnă lipsa colaborării între cele două grupuri, dimpotrivă, grupurile ar trebui să coopereze astfel încât sistemul informațional să aibă o calitate superioară în momentul în care va fi livrat clientului.

Principiul 8. Testele trebuie să poată fi repetate și reutilizate.

Repetarea și reutilizarea testelor este necesară în cazul testelor de regresie, retestarea programului după ce acesta a fost modificat, în cazul unor noi lansări ale programului.

Principiul 9. Testarea trebuie planificată.

Planurile de test trebuie dezvoltate pentru fiecare nivel de test și obiectivele pentru fiecare nivel trebuie descrise în planul asociat. Planurile, cu obiectivele lor specificate, sunt necesare pentru a asigura alocarea unui timp și unor resurse adecvate pentru sarcina de testare și pentru ca testul să poată fi monitorizat.

Activitatea de planificare a testării trebuie să facă parte din ciclu de viață al programului și trebuie să fie coordonată cu planificarea proiectului. Testerii nu pot să planifice testarea unei componente la o anumită dată decât dacă programatorii o au gata la data respectivă. Trebuie evaluat riscul testului, de exemplu cât de probabile sunt întârzierile în livrarea componentei software, care sunt componentele complexe și dificil de testat și dacă testerii au nevoie de pregătire suplimentară pentru noile utilitare.

O planificare atentă a testului duce la evitarea testelor eronate și la înlăturarea testelor neprevăzute care conduc la o slabă calitate a softului și la incapacitatea de a-l livra la timp și în bugetul stabilit inițial.

Principiul 10. Activitățile de testare trebuie integrate în ciclul de viață al softului.

Nu mai este convenabil ca activitățile de testare să fie amânate până după momentul scrierii codului. Planificarea activităților de testare trebuie integrate în ciclul de viață al sistemului informațional începând chiar cu etapa de analiză și continuând în paralel cu activitățile de programare. În plus, pe lângă planificarea testării, și alte tipuri de activități de testare, cum ar fi testele de utilitate, pot fi de asemenea realizate în fazele de început pe prototipuri. Aceste activități pot continua până când softul este livrat la clienți.

Principiul 11. Testarea este o sarcină creativă și provocatoare.

Dificultățile și provocările pe care testerii le întâlnesc includ următoarele:

Testerul trebuie să aibă cunoștințe vaste despre ingineria software;

Testerul trebuie să dețină cunoștințe atât din experiență cât și din educație despre specificațiile, proiectarea și dezvoltarea unui program;

Testerul trebuie să aibă abilitatea de a lucra cu multe detalii;

Trebuie să dețină cunoștințe despre tipurile de erori și unde poate să apară un anumit tip de eroare în structura codului;

Testerul trebuie să propună ipoteze relaționate cu anumite tipuri de erori ce pot să apară;

Testerul trebuie să creeze și să documenteze cazurile de test;

Trebuie să planifice testarea și să aloce resursele potrivite;

El trebuie să execute testele și este responsabil de înregistrarea rezultatelor;

Testerul analizează rezultatele și decide dacă testul a trecut sau nu. Acest lucru implică înțelegerea și păstrarea unei cantități mari de informații;

Testerul trebuie să coopereze cu programatorii, analiștii, proiectanții și de multe ori chiar și cu unii clienți.

1.3. Standardele testării

Datorită importanței crescânde a testării în cadrul ciclului de dezvoltare al programelor, a fost necesară introducerea unor standarde pe care activitățile de testare să le urmeze. Cele mai cunoscute standarde ale testării sunt: standardul IEEE 829, pentru documentele testării și standardul ISO/IEC 9126, pentru calitatea programelor.

1.3.1. Standardul IEEE 829

În decursul timpului au fost create un număr de documente pentru controlul testării. Ele se aplică testării de toate tipurile, de la testarea componentelor, la testele de acceptanță. Fiecare organizație dezvoltă singură aceste documente cu diferite denumiri, iar în unele cazuri le confundă scopul. Din această cauză IEEE a dezvoltat standardul 829 pentru documentația testării software, pentru orice tip de test, inclusiv cel de acceptanță la client.

În standardul IEEE 829 sunt șapte tipuri de documente care pot fi folosite în trei faze distincte ale testării software:

1. Pregătirea testului

Planul de test: planifică cum se va face testarea.

Specificațiile de proiectare ale testului: se decide ce trebuie testat.

Specificațiile cazurilor de test: creează testele ce trebuie rulate.

Specificațiile procedurilor de testare: descrie cum vor fi rulate testele.

2. Rularea testului

Jurnalele testului: înregistrează detaliile testelor în ordine cronologică.

Raportul incidentelor testului: înregistrează detaliile despre evenimentele ce trebuie investigate.

3. Terminarea testării

Raportul final al testului: Rezumă și evaluează testele.

Pregătirea testului este cea mai importantă parte a oricărui proiect de testare și care necesită cea mai multă documentare. Scopul acestei etape este de a pregăti un set de teste eficiente și de a crea mediul în care vor fi rulate.

IEEE 829 – Planul de test

Test planul este documentul principal în jurul căruia se învârt toate celelalte proiecte de test. El descrie:

ce trebuie făcut,

conform cărui standard al calității,

cu ce resurse,

în ce timp,

subliniază riscurile și cum pot fi ele înlăturate.

IEEE 829 – Specificațiile proiectării testului

Proiectarea testului este prima etapă în dezvoltarea testului. Se înregistrează ceea ce trebuie să fie testat, în funcție de documentația care a fost primită la începutul etapei de testare, cum ar fi cerințele și proiectarea. Se înregistrează ce caracteristici trebuie testate și cum va fi recunoscut un test care se termină cu succes.

Proiectarea testului nu furnizează valorile ce trebuie introduse în test, dar descrie cerințele pentru găsirea acelor valori. Acest document este foarte important, dar lipsește frecvent din multe proiecte. Motivul ar fi faptul că se începe direct scrierea cazurilor de test înainte de a decide ce trebuie testat.

IEEE 829 – Specificațiile cazurilor de test

Cazurile de test specifică pentru fiecare test următoarele cerințe:

valorile exacte ale intrărilor și valorile oricăror date individuale care sunt cerute;

valorile exacte ale ieșirilor și schimbările valorilor interne ale stării sistemului dacă sunt așteptate;

și orice pas special pentru test.

IEEE 829 – Specificațiile procedurilor de testare

Procedurile sunt dezvoltate atât din proiectarea testului, cât și din specificațiile cazurilor de test. Documentul descrie cum va fi rulat fizic testul, cerințele fizice și procedurile ce trebuie urmate. Standardul definește zece proceduri care pot fi aplicate la rularea testului.

După ce testele au fost create, ele pot fi rulate. Programarea cazurilor de test pentru rulare este definită în planul de test. Rezultatele testului sunt înregistrate în jurnalele testului și în raportul incidentelor testului.

Testarea va fi terminată pe baza criteriilor specificate în test plan, când se decide dacă testul s-a terminat cu succes sau nu, pe baza rezultatelor obținute. Raportul final al testului înregistrează aceste informații și este cel mai important document pe baza căruia se decide dacă sistemul este de calitate bună și se poate trece la următoarea etapă în dezvoltarea lui.

1.3.2. ISO/IEC 9126

Obiectivul acestui standard este de a oferi un cadru pentru evaluarea calității softului. ISO/IEC 9126 nu furnizează cerințe pentru software, dar definește un model al calității, aplicabil oricărui soft. Definește șase caracteristici ale calității plus subcaracteristicile acestora.

1.4. Clasificarea tehnicilor de testare

Tehnicile de testare au un caracter preponderent euristic și empiric, mai puțin fundamentate teoretic, ceea ce explică multitudinea tehnicilor prezentate în literatura de specialitate. Importantă este alegerea unei strategii prin care să se selecteze tehnicile cele mai adecvate pentru atingerea obiectivelor definite în faza de planificare a testării. Pentru a fi în măsură de a alege cele mai potrivite tehnici de testare este necesară cunoașterea modalităților de clasificare a lor.

Un prim criteriu de clasificare îl reprezintă modul de efectuare a testării, conform căruia există două categorii de tehnici:

tehnici de testare automată care presupun testarea programelor sub controlul calculatorului și

tehnici de testare manuală, prin care testarea este efectuată sub controlul omului.

Un criteriu de clasificare asemănător se referă la execuția sau nu a programelor pe parcursul testării. În funcție de acest criteriu, tehnicile de testare se împart tot în două categorii:

testarea statică presupune verificarea programelor sursă fără ca acestea să fie lansate în execuție. Multe din aceste tehnici sunt aplicate la testarea rezultatelor fazelor de analiză și proiectare sau a documentației sistemului;

testarea dinamică implică execuția programelor. Pornind de la un set de date de intrare se va lansa în execuție programul și se vor compara rezultatele execuției programului cu rezultatele scontate.

Cele două moduri de clasificare sunt relativ redundante, în sensul că majoritatea tehnicilor de testare manuală se regăsesc și în categoria tehnicilor de testare statică, atât timp cât, în general, tehnicile manuale nu implică execuția programelor, iar tehnicile de testare automată presupun de cele mai multe ori execuția programelor, deci ele sunt considerate tehnici de testare dinamică.

În funcție de sursele de informații utilizate pentru generarea cazurilor de test, un sistem informatic poate fi testat în două moduri complementare:

Testarea de tip „cutia albă”, spre deosebire de tipul anterior de testare, presupune concentrarea atenției asupra logicii interne a programelor, respectiv asupra detaliilor procedurale. Ea presupune identificarea cazurilor de test care permit execuția tuturor ramurilor programului, derivate din structurile de control alternative și/sau repetitive. Prin urmare, acest tip de testare presupune identificarea tuturor ramurilor logice ale programului, definirea cazurilor de test, execuția lor și evaluarea rezultatelor.

Testarea de tip „cutia neagră”, prin care se urmărește să se verifice dacă fiecare funcție a programului este operațională, precum și să se identifice eventualele erori în realizarea unei funcții. Acest tip de testare include testele efectuate asupra interfețelor programului, vizând intrările (dacă datele acceptate spre prelucrare sunt corecte), ieșirile (dacă ieșirile obținute prin prelucrarea datelor de intrare sunt corecte) și baza de date (dacă este asigurată consistența bazei de date). Cu alte cuvinte, prin acest tip de testare sunt examinate aspectele fundamentale ale programului, acordându-se o atenție mai mică logicii interne a programului.

Testarea de tip “cutie albă” (white box)

După cum a fost definită anterior, testarea de tip „cutia albă” presupune analiza structurilor de control din specificațiile procedurale de proiectare în vederea definirii cazurilor de test. S-ar putea crea impresia că aplicarea acestui tip de testare ar conduce inevitabil către obținerea de programe 100% corecte și că testarea de tip „cutia neagră” ar fi total inutilă. Ar putea fi adevărat dacă ar fi posibilă testarea exhaustivă a programelor.

Problema poate fi formulată și din cealaltă perspectivă: de ce trebuie să cheltuim atâta timp și energie cu testarea la nivelul detaliilor programelor, în loc să ne concentrăm atenția asupra testelor care să arate dacă programele corespund cerințelor formulate? Altfel formulată întrebarea, de ce să ne complicăm cu testarea de tip „cutia albă” în loc să ne consumăm toate resursele cu testarea de tip „cutia neagră”?

Răspunsurile sunt numeroase și derivă din natura erorilor întâlnite în programe. Multe erori apar atunci când se proiectează și implementează funcții, condiții sau structuri de control care privesc cazurile speciale ale problemei tratate și care nu fac parte din fluxul logic principal al programului. În acest sens, se estimează că numărul erorilor logice este invers proporțional cu probabilitatea de execuție a unei ramuri logice a programului. Erorile de scriere a programelor sursă pot apare oriunde în programe, atât în ramurile logice principale cât și în cele care tratează cazurile speciale. Chiar dacă unele din erorile de scriere a programelor sunt depistate cu ocazia compilării programelor sursă, multe din aceste erori rămân nedescoperite, ceea ce justifică necesitatea tehnicilor de testare de tip „cutia albă”.

Pe de altă parte, aplicarea tehnicilor de testare de tip „cutia albă” permite identificarea și localizarea mai ușoară a erorilor, tocmai datorită faptului că acest tip de testare se desfășoară la nivelul detaliilor procedurale. Acesta este unul din motivele pentru care, de regulă, strategia de testare a programelor presupune aplicarea mai întâi a tehnicilor de testare de tip „cutia albă” și apoi a celor de tip „cutia neagră”.

Tehnicile de testare de tip „cutia albă” urmăresc generarea cazurilor de test astfel încât:

Să se garanteze că toate ramurile independente dintr-un modul vor fi executate cel puțin o dată;

Execuția fiecărei structuri de control alternative pe ambele ramuri;

Execuția fiecărei structuri de control repetitive atât la numărul minim cât și maxim al iterațiilor, dar și un număr intermediar.

Verificarea validității structurilor de date interne ale programelor.

Testarea de tip “cutie neagră” (black box)

Testarea de tip „cutia neagră”, prin testele proiectate, urmărește să ofere răspunsuri la următoarele întrebări: Cum poate fi testată validitatea funcțională a aplicației? Cum pot fi testate performanțele aplicației? Ce clase de intrări sunt necesare pentru o bună testare a sistemului? Ce volum de date și ce rată a intrărilor poate accepta sistemul? Ce efect va avea asupra modului de funcționare a sistemului o anumită combinație a datelor de intrare?

Tehnicile de testare mai pot fi clasificate și în funcție de obiectivele urmărite la generarea cazurilor de test se face pe trei categorii:

Testarea bazată pe gradul de acoperire, în care cerințele testării sunt specificate prin gradul de acoperire a produsului ce trebuie testat. Prin noțiunea de produs se face referire la programe, documente ce conțin specificații de proiectare sau cerințele funcționale structurate în faza de analiză. De exemplu, se poate solicita: generarea cazurilor de test astfel încât prin execuția lor să se garanteze că toate instrucțiunile din program sau un anumit procent din instrucțiuni vor fi executate cel puțin o dată; toate cerințele elementare ale sistemului, formulate în faza de analiză, să fie exersate cel puțin o dată.

Testarea axată pe greșeli include tehnicile orientate spre detectarea greșelilor. Spre deosebire de categoria anterioară, când se pornea de la premisa că o arie cât mai mare de acoperire a produsului de testat este cea mai bună strategie de testare, tehnicile de testare din această categorie urmăresc să identifice setul de teste cu cea mai mare capacitate de detectare a greșelilor. Prin urmare, nu mai sunt avute în vedere produsele de testat ci chiar seturile de teste ce vor fi utilizate la testarea produselor respective. De exemplu, se pot introduce în mod intenționat un număr de greșeli într-un program, după care se va verifica dacă un anumit set de teste va detecta un procent minim din greșelile introduse; dacă nu, atunci se renunță la setul de date de intrare respectiv. În concluzie, trebuie reținut că aceste tipuri de tehnici nu sunt utilizate la generarea seturilor de teste, ci la validarea și alegerea celor mai potrivite seturi de teste scopurilor propuse.

Testarea axată pe erori este orientată spre depistarea erorilor, pornindu-se de la erorile tipice întâlnite la proiectarea și scrierea programelor.

Din perspectiva planificării și desfășurării activității de testare, o importanță deosebită o prezintă clasificarea tehnicilor de testare în funcție de momentul sau etapa în care ele sunt invocate. Astfel, ele pot fi grupate în:

Testarea modulelor,

Testarea integrării modulelor,

Testarea sistemului și

Testarea de acceptare din partea utilizatorilor.

În final, trebuie menționat că nu există o tehnică de testare sau o categorie de tehnici care să fie catalogată drept cea mai bună. Fiecare tehnică este orientată spre detectarea anumitor tipuri de erori sau satisfacerii anumitor obiective. Din acest motiv, descoperirea cât mai multor erori necesită utilizarea mai multor tehnici, în funcție de obiectivele propuse pentru faza de testare, strategia de testare, complexitatea sistemului informatic, resursele alocate testării etc.

Teste aleatorii

Fiecare modul sau sistem are un domeniu de valori de intrare din care datele de intrare în test sunt selectate. Dacă un tester selectează la întâmplare valori din domeniu, această metodă este denumită testare aleatorie. De exemplu, dacă valorile de intrare valide pentru un modul sunt toate numerele întregi între 1 și 100, testerul care folosește această tehnică va selecta aleator valori în acest interval, cum ar fi 55, 23, 3. Folosind această tehnică rămân unele probleme cum ar fi:

Sunt aceste trei valori adecvate pentru a demonstra că modulul îndeplinește specificațiile? Trebuie luate în considerare și alte valori?

Sunt alte valori în afara celor alese mai relevante pentru a găsi erori? De exemplu, ar fi mai relevante valorile de la începutul și de la sfârșitul intervalului considerat.

Ar trebui luate în considerare și valori din afara intervalului? De exemplu valori cu virgulă, negative sau valori întregi mai mari decât 100.

Folosirea testelor aleatorii poate salva o parte din efortul de selectare a datelor de intrare, totuși, această selecție are foarte puțin succes în obținerea unui set efectiv de date.

Există instrumente care generează automat date de intrare aleator mai ales pentru testele de solicitare, acest tip de test fiind foarte folosit la nivelul sistemului.

1.5. Obiectivele, planificarea și documentația procesului de testare

Planificarea este ghidată de politici, obiective de atins și reprezintă o parte vitală a tuturor activităților din industria software. În acest domeniu, planificarea de a obține anumite obiective asociate cu un proiect este realizată de managerul de proiect. În domeniul testării, planurile de test conțin de asemenea obiectivele urmărite și sunt realizate fie de managerul de proiect ca o parte a întregului plan de proiect sau de un tester specializat în concordanță cu planul întregului proiect. Planificarea testării presupune ca cel care o planifică să accentueze scopul testului pentru proiectul respectiv, să selecteze instrumentele și tehnicile necesare pentru atingerea scopului și să estimeze timpul și resursele necesare pentru sarcina de testare astfel încât testarea să fie eficientă, la timp și să se încadreze în buget.

Procesul testării se bazează pe cinci activități consecutive:

Identificarea condițiilor de test, planificarea testului

Proiectarea cazurilor de test

Crearea, construirea cazurilor de test

Execuția testului

Compararea rezultatului așteptat cu cel real, evaluarea execuției bazată pe criteriile de intrare și ieșire ce cuprind gradul de acoperire a testului, procentul de descoperire a erorilor, timpul și bugetul consumat.

Documentația testării cuprinde patru componente majore:

Fig. 1.5. Etapele testării

STP – planul de test (vezi anexa A)

TRD – definirea cerințelor testului

STD – descrierea testului (vezi anexa B)

STR – rezultatele testului.

1.5.1 Planul de test (Software Test Plan – STP)

Cea mai importantă etapă a testării este planificarea. O planificare a testării potrivită presupune înțelegerea perfectă a procesului de dezvoltare a softului, pentru a putea veni cu sugestii cu privire la îmbunătățirea procesului de dezvoltare, atunci când este cazul. Planificarea testării trebuie să aibă loc cât mai repede, în primele etape ale ciclului de viață al programului în dezvoltare, pentru a permite implementarea corectă a planului. O planificare timpurie permite să fie estimate și aprobate sarcinile și bugetele pentru testare și apoi integrate în planul general de dezvoltare al softului.

Un plan de test este un document care descrie strategia ce va fi urmată pentru activitatea de testare și se folosește ca un acord între testeri și programatori. Planul de test trebuie să fie creat de timpuriu în primele etape ale ciclului de dezvoltare și să ajute la interacțiunea activităților de analiză, proiectare și scriere a codului. Planul de test definește obiectivele testului, scopul, strategia, procedurile de test, mediul de test, criteriile de terminare ale testului, cazurile de test, ce trebuie testat, testele care trebuie efectuate, resursele de personal necesare, procedurile de raportare, riscurile și planificarea cheltuielilor neprevăzute.

Când se creează un plan de test, trebuie să fie simplu, complet, accesibil și ușor de înțeles de cel care-l va aproba. Un plan de test bun reduce cazurile redundante, acoperă complet funcțiile, are proceduri pentru monitorizarea și raportarea stării testului, conține o definiție clară a rolurilor și responsabilităților celor implicați în test și documentarea clară a rezultatelor testului.

Există două metode de creare a unui plan de test. Prima abordare este un plan de test principal care conține o privire de ansamblu asupra planului de test detaliat. Acesta din urmă verifică o fază particulară din ciclul de dezvoltare. Planul de test include testarea modulelor, integrării, a sistemului și de acceptanță. Testele pentru module sunt orientate pe testarea codului și sunt scurte, dar foarte detaliate. Planul de test pentru sistem și acceptanță sunt orientate pe testarea funcționalității (cutia neagră) întregului sistem, nu doar a unui modul.

A doua abordare este crearea unui singur plan de test ce include toate tipurile de test și este denumit adesea test de acceptanță/sistem.

Componenta majoră a unui plan de test este cazul de test ce definește pas cu pas procesul ce trebuie realizat. El include obiectivul și condițiile de test, pașii necesari pentru realizarea testului, datele de intrare, rezultatul așteptat și rezultatul real obținut. Alte informații, cum ar fi mediul, versiunea, ID testului, tipul testului, sunt de asemenea precizate.

Pașii principali în dezvoltarea unui plan de test

Planul de test este baza pentru realizarea testării și trebuie modificat pe măsură ce aplicația se modifică. Un plan de test bun încurajează atitudinea “calitatea înaintea proiectării și codului”.

Pentru crearea unui plan de test bun trebuie urmați pașii conform standardului IEEE 829:

1.  Definirea obiectivelor testului. Primul pas în planificarea oricărui test este de a stabili ce trebuie obținut ca rezultat al testării. Acest pas asigură că toți testerii responsabili contribuie la definirea criteriilor testului ce vor fi folosite. Cel care creează planul de test va determina ce trebuie să se obțină în urma testului, testele specifice ce trebuie executate, rezultatele așteptate, constrângerile, scopul testului, raportul final și aprobarea finală.

2.  Abordarea testului. Cel care dezvoltă planul de test punctează cum va fi executat fiecare test. Aceasta include tehnica de testare care va fi folosită, criterii de intrare și de ieșire ale testului, procedurile pentru coordonarea activității de testare cu programarea, modul de raportare al erorilor, resursele necesare, riscurile și definirea bazelor testului (specificațiile funcționale).

3.  Definirea mediului testării. Trebuie examinate facilitățile fizice ale testului, definite resursele hardware, software și de rețea, determinate care instrumente de testare automată sunt necesare, definit suportul necesar și toate acestea trebuie incluse în planul de test.

4.  Dezvoltarea specificațiilor testului. Echipa de testare documentează specificațiile testului pentru fiecare program principal, în concordanță cu specificațiile de funcționalitate. De asemenea, se identifică interdependențele specificațiilor de test și se împart sarcinile între membrii echipei.

5.  Programarea testului. Cel care creează planul de test programează testul pentru execuție, bazându-se pe resursele disponibile, compară programarea cu termenele limită, echilibrează resursele și cerințele de lucru și dezvoltă planul de contingență.

6.  Revizuirea și aprobarea planului de test. Managerul planifică o ședință pentru revizuirea planului de test în detaliu, pentru a se asigura că este complet și poate obține aprobarea pentru a putea începe testarea.

1.5.2 Definirea cerințelor testului (Test Requirement Definitions – TRD)

Definiția cerințelor testului detaliază subiectele ce urmează a fi testate și permite clientului să evalueze acoperirea testului conform cu specificațiile software.

Componentele unui TRD sunt:

Scopul – realizează o identificare a documentului și a sistemului.

Documente la care se face referință – conține o listă a tuturor documentelor relevante pentru definirea cerințelor testului cu număr, titlu, dată.

Condiții prealabile – cerințele hardware și software, accesul la baza de date, inițializarea fișierelor.

Cerințele testului – identificarea cerințelor testului, condițiile inițiale, descrierea stării inițiale a sistemului, descrierea acțiunilor de testat, descrierea generală a rezultatelor așteptate.

Pentru sisteme complexe, definiția cerințelor testului simplifică procesul de planificare a testării și permite clientului să controleze și să evalueze acoperirea testării.

1.5.3 Descrierea testului (Software Test Description – STD)

Documentul STD descrie cum trebuie testat sistemul și conține o descriere operativă a procesului de testare. Componenta majoră a unui document STD este cazul de test ce definește pas cu pas procesul ce trebuie realizat. El include condițiile de test, pașii necesari pentru realizarea testului, datele de intrare, rezultatul așteptat și rezultatul real obținut.

Componentele unui STD sunt:

1. Scopul – realizează o identificare a sistemului și a componentelor hardware și software necesare pentru test: numărul versiunii, numărul de lansare, titlul.

2. Documente la care se face referință – conține o listă a documentelor relevante cu număr, titlu, dată.

3. Condiții prealabile – identificarea condițiilor necesare pentru executarea cazurilor de test. Pot cuprinde: configurația hardware și software, parametrii de control, datele ce trebuie setate înainte de începerea testului.

4. Intrările testului – descrie intrările necesare pentru cazurile de test: numele, scopul, descrierea pentru fiecare intrare, sursa intrărilor testului și metoda folosită pentru selectarea lor.

5. Rezultatele așteptate – identifică toate rezultatele așteptate pentru cazurile de testare.

6. Criterii de evaluare a rezultatelor – identificarea criteriilor ce vor fi folosite pentru evaluarea rezultatelor cazurilor de test conform cărora testul “a trecut” sau “a eșuat”.

7. Procedurile de test – pentru cazurile de test. Aceste proceduri sunt o serie de pași individuali numerotați secvențial în ordinea în care sunt executate cazurile de test. Un exemplu de procedură de test este:

8. Constrângeri – identificarea limitărilor impuse în descrierea cazurilor de test datorate sistemului sau condițiilor de test cum ar fi limitările de timp, interfețe, echipament, personal, baze de date.

9. Cerințe de corespondență – include corespondența fiecărui caz de test identificat în descriere cu cerințele pe care le adresează.

10. Rezultatele testului – pentru fiecare caz de test se trec problemele găsite. (vezi anexa B – STD-template)

1.5.4. Raportul testului (Software Test Report – STR)

În STR sunt sumarizate conținutul fiecărui ciclu de test, rezultatele testului și sunt stabilite o serie de concluzii cu privire la calitatea sistemului testat.

Componentele unui raport de test (STR) sunt:

1. Scopul – realizează o identificare a sistemului și a componentelor hardware și software necesare pentru test: numărul versiunii, numărul de lansare, titlul.

2. Documente referite – conține o listă a documentelor referite cu număr, titlu, dată.

3. Rezumat al rezultatelor testului – se vor identifica problemele rămase nerezolvate, limitările și constrângerile detectate de testele realizate. Pentru fiecare problemă nerezolvată, trebuie propusă o soluție de rezolvare.

4. Rezultatul testului detaliat – vor fi detaliate problemele întâlnite pe cazuri de test, se va face identificarea procedurilor în care apar aceste probleme, numărul de repetări ale procedurii în încercarea de a repara problema.

5. Jurnalizarea (logurile) testului – va include data, timpul și locul unde s-a făcut testul, configurația hardware și software a mașinii pe care s-a rulat.

Tabelul 1.1. Exemplu de jurnal de test

(adaptat după: Software Test Description and Results, http://sunset.usc.edu/classes/cs577b_97/projdocs/team1/tst_dr.html)

6. Note – va conține informații generale care ajută la înțelegerea documentului cum ar fi: o listă cu toate acronimele folosite, o listă cu toți termenii necesari pentru a înțelege documentul.

7. Anexe – vor fi referite în cadrul documentului.

1.5.5. Matricea corespondențelor cu specificațiile

Matricea corespondențelor este un document care urmărește cerințele utilizatorilor de la etapa analizei până la implementare. Este folosită pentru a verifica faptul că toate cerințele sunt prezente sau că nu există funcționalități în plus față de cele cerute și, de asemenea, drept un ghid pentru angajații noi. La fiecare etapă din ciclul de dezvoltare, cerințele, codul și cazurile de test asociate sunt înregistrate pentru a asigura faptul că în final sistemul va adresa toate cerințele clientului.

1.6. Niveluri ale testării

Testarea bazată pe funcționalitate a sistemelor informatice mari este de obicei împărțită pe mai multe niveluri. În majoritatea cazurilor sunt 3-4 niveluri ori faze majore de testat: test al modulelor, test de integrare, test al sistemului și o serie de teste de acceptanță. Fiecare din acestea pot avea subniveluri sau faze. La fiecare nivel sunt anumite obiective pe test. De exemplu, la testul pe unitate, o singură componentă este testată. Un scop principal este să fie descoperite erorile de funcționalitate și structură din unitatea respectivă. La nivelul testului de integritate sunt testate o serie de componente ca un grup, iar testerul investighează interacțiunea dintre ele. La nivelul sistemului se testează sistemul ca un întreg și principalul scop este evaluarea atributelor precum utilitate, siguranță și performanță.

Testarea sistemului începe când toate componentele au fost integrate cu succes. Pentru această testare este nevoie de echipament de laborator atât software cât și hardware, în special pentru sistemele în timp real sau cele distribuite.

Dacă sistemul este personalizat pentru un client, atunci pasul următor după testarea sistemului este testul de acceptanță. Acesta este foarte important pentru programatori, deoarece, în această fază trebuie să arate că sistemul informațional întrunește toate cerințele clientului. De obicei, sistemele dezvoltate pentru piețe mari realizează o serie de teste numite alfa și beta. Testele alfa pun la dispoziția potențialilor clienți un site unde pot să utilizeze aplicația și să semnaleze eventualele probleme. Testele beta trimit programul la clienți și aceștia pot să-l folosească în condiții reale și să raporteze problemele care apar.

Implementarea tuturor nivelurilor de test necesită o investiție substanțială de timp și resurse ale organizației. Organizațiile cu un proces al testării slab doresc să economisească resurse, ignoră planificarea testării până în momentul în care codul este terminat și omit una sau mai multe etape de test. Sistemul informațional produs în asemenea condiții este de slabă calitate, iar costurile adiționale pentru repararea erorilor care apar sunt de obicei foarte mari.

Strategia testării sistemelor informatice integrează diferitele metode de concepere a cazurilor de test într-o succesiune de pași bine planificați, astfel încât să fie asigurată dezvoltarea unui sistem informatic de calitate. De asemenea, strategia testării include detalii privind resursele de timp și financiare necesare realizării testării. Prin urmare, strategia testării va include: planificarea testării, conceperea cazurilor de test care vor forma setul de teste, execuția setului de teste, colectarea rezultatelor testării și evaluarea acestor rezultate.

Orice strategie de testare trebuie să aibă următoarele caracteristici generale:

Testarea începe de jos, de la nivelul modulelor, și se încheie prin validarea sistemului informatic ca un tot. O strategie de testare trebuie să garanteze atât verificarea corectitudinii implementării modulelor de program, cât și validarea principalelor funcții ale sistemului informatic, în conformitate cu cerințele utilizatorilor.

În faza de proiectare, sistemul este descompus în mai multe module organizate ierarhic, ceea ce constituie de fapt arhitectura sistemului. În faza de testare va fi urmată aceeași arhitectură. Astfel, se va începe cu testarea modulelor, care presupune testarea fiecărui modul în parte. Apoi, testarea va viza modul de integrare a modulelor pentru obținerea sistemului, conform arhitecturii definite în faza de proiectare. Această etapă este denumită testarea integrării. După testarea integrării, o dată ce sistemul a fost refăcut prin integrarea modulelor, urmează testarea sistemului, moment în care programele și alte elemente componente ale sistemului sunt testate ca un tot, în funcție de cerințele funcționale și restricțiile definite în faza de analiză, specificațiile generale de proiectare. Se încheie cu testarea de acceptare, realizată sub supravegherea și cu participarea directă a utilizatorilor.

Fig. 1.2. Nivele de test

(după: Burnstein, I. – Practical Software testing, A process-oriented approach, p. 157)

Diferitele tehnici de testare trebuie aplicate la anumite momente ale testării. De exemplu, la testarea modulelor se utilizează cu precădere tehnicile de tip „cutia albă”, care vor fi realizate cu precădere de programatori, prin care se va urmări execuția fiecărei căi din fluxul logic de control al modulelor, testarea variabilelor de memorie și a structurilor logice de control. În timpul testării integrării vor fi utilizate mai mult tehnicile de tip „cutia neagră” și mai puțin cele de tip „cutia albă”. Testarea sistemului și testarea de acceptare implică aproape în exclusivitate apelarea la tehnicile de tip „cutia neagră”, pentru a se verifica funcționalitatea, comportamentul și performanțele sistemului, precum și dacă sistemul corespunde exigențelor utilizatorilor.

Testarea este realizată de către o echipă independentă, în cazul proiectelor mari sau de membrii echipei de dezvoltare a sistemului, în cazul proiectelor de mai mică amploare. Pentru orice proiect de dezvoltare a sistemelor informatice, faza de testare implică anumite conflicte de interese inerente. Pe de o parte, pare evident că cei mai potriviți pentru a realiza testarea sunt proiectanții și programatorii, adică cei care cunosc cel mai bine sistemul. Pe de altă parte, aceștia vor încerca să demonstreze că programele nu conțin erori, iar prin testele proiectate vor demonstra că sistemul funcționează conform cu cerințele formulate.

Din punct de vedere psihologic există două puncte de vedere: unul consideră dezvoltarea sistemului ca o activitate constructivă, în urma căreia sunt create specificațiile de proiectare, programele, documentația etc., de care în mod evident membrii echipei de dezvoltare se simt mândri; celălalt punct de vedere consideră testarea ca o activitate distructivă, atât timp cât ea identifică erorile și demonstrează că programele nu sunt tocmai așa cum credeau cei care le-au realizat. De aceea, de multe ori se greșește atunci când se consideră că proiectanții și programatorii nu trebuie implicați în faza de testare sau că testerii vor fi implicați numai atunci când începe faza de testare.

În general, proiectanții și programatorii sunt responsabili atât pentru testarea modulelor cât și pentru testarea integrării modulelor, iar după ce aceste două etape s-au încheiat, testarea va fi realizată de o echipă independentă. Rolul unei astfel de echipe constă în eliminarea conflictului de interese amintit anterior, ea fiind de fapt plătită pentru a găsi erori. Oricum, echipa de testare va colabora strâns cu echipa de proiectare și programare care trebuie să rezolve eventualele erori.

1.6.1 Testarea componentelor

Principalul scop în testarea componentelor este de a asigura faptul că fiecare componentă software funcționează conform cu specificațiile. Resursele trebuie alocate și cazurile de test trebuie dezvoltate folosind atât tehnica cutie albă, cât și cea cutie neagră în proiectarea testelor. Componentele trebuie testate de o persoană diferită de programator, iar rezultatele testului și erorile trebuie înregistrate și păstrate.

Din păcate, în multe cazuri acest test este realizat în mod informal de cel care a programat componenta respectivă. Erorile găsite nu sunt înregistrate de către programator. Dacă erorile nu sunt descoperite în testarea componentelor, ele vor apărea cu siguranță în testul de integrare al sistemului sau de acceptanță, unde este mult mai costisitoare localizarea și repararea lor.

Pentru a pregăti testarea componentelor programatorii/testerii trebuie să realizeze următoarele sarcini:

(i) să planifice abordarea generală a testării componentelor;

(ii) să proiecteze cazurile de test și procedurile de test ce vor fi atașate planului de test;

(iii) să definească relațiile dintre teste;

(iv) să pregătească codul auxiliar necesar testului.

1.6.2 Testarea modulelor

Scopul principal urmărit prin testarea la nivelul modulelor constă în identificarea și corectarea unui număr cât mai mare de erori înainte de integrarea modulelor în unități de program mai complexe, în care erorile sunt mult mai greu de depistat, localizat și corectat.

În acest moment al testării sunt implicate mai multe tehnici de testare, în funcție de aspectele urmărite. De regulă, se începe cu testarea interfețelor modulului pentru a se asigura că intrările și ieșirile în/din modul sunt corespunzătoare, înainte de a se efectua alte teste asupra modulului. Dacă interfețele modulului sunt necorespunzătoare, atunci toate celelalte teste sunt inutile.

Urmează testarea structurilor de date locale, prin care se verifică integritatea datelor stocate temporar de-a lungul tuturor ramurilor de execuție a algoritmului transpus în modulul respectiv.

Cele mai importante teste dintre cele efectuate la nivelul modulelor sunt cele care vizează căile de execuție a programului. Prin testarea căilor de execuție a programului se urmărește depistarea erorilor legate de calcule greșite, comparații greșite în expresiile logice, controlul logic al execuției necorespunzător etc. Foarte utile în acest scop sunt tehnica testării căilor de bază și testarea structurilor de control repetitive.

Testarea modulelor se încheie cu analiza valorilor limită. Deși sunt puține explicații, majoritatea erorilor apar la extremitățile domeniului de valori pentru datele de intrare și nu în mijlocul acestui domeniu. De exemplu, apar erori la execuție atunci când se invocă ultima iterație dintr-o structură repetitivă, se prelucrează ultimul element dintr-un tablou de date etc. Din acest motiv se impune reluarea testelor privind structurile de date și fluxul logic de control, însă vor fi utilizate alte cazuri de test prin care se va urmări exersarea valorilor limită ale domeniului.

Analiza valorilor limită este considerată de mulți specialiști o tehnică de testare. Aplicarea ei presupune:

Dacă printr-o condiție se specifică un domeniu de valori cuprins între un minim (a) și un maxim (b), atunci trebuie concepute cazuri de test în care valorile să fie a, b, a+1, b+1, a-1 și b-1;

Dacă domeniul unei condiții va fi specificat printr-un număr de valori, vor fi generate cazuri de teste pentru situațiile în care domeniul conține numărul minim de valori, numărul minim + 1, numărul maxim de valori și numărul maxim – 1;

Dacă pentru o structură de date locală a fost definită o restricție (dimensiunea unui vector a fost declarată ca fiind 10), atunci se vor testa situațiile când vectorul conține un singur element, respectiv 10 elemente.

Testarea modulelor mai are o particularitate. După cum se știe, un modul nu este de sine-stătător, el fiind plasat undeva în structura ierarhică a programului de unde este apelat de modulele de pe nivelul ierarhic superior, după cum, la rândul său, poate apela unele module situate pe nivelul ierarhic inferior pentru a-și putea realiza funcția. Ori, în aceste condiții, aplicarea tehnicilor de testare dinamică este de cele mai multe ori imposibilă. Pentru a se evita acest neajuns, pentru fiecare modul testat se vor concepe două tipuri speciale de module: module ciot (stub) și module directoare (drive).

Un modul director este văzut ca un program principal al cărui rol constă în a simula condițiile normale de exploatare a programului în care va fi executat modulul testat. Funcțiile lui privesc acceptarea datelor de test, transmiterea lor către modulul ce trebuie testat și afișarea rezultatelor relevante ale testării. Un modul ciot are rolul de a înlocui un modul invocat de modulul testat, el fiind un subprogram care va avea aceeași interfață ca și modulul pe care-l înlocuiește, va realiza un minim de prelucrări, va semnala faptul că el a fost apelat după care va reda controlul modulului testat.

La nivelurile inferioare, fiecare modul are nevoie de propriul modul director pentru a putea fi testat, ceea ce implică un consum mare de resurse pentru scrierea de cod suplimentar și, în același timp, o sursă suplimentară de erori. Modulele director și modulele ciot nu vor face parte din sistemul informatic, nu vor fi livrate beneficiarului, deci ele trebuie proiectate și implementate suplimentar. În cazul în care pentru testarea unui modul sunt necesare astfel de module mai complexe, atunci se va amâna testarea modulului respectiv pentru pasul următor, respectiv testarea integrării, când de asemenea se apelează la astfel de module speciale, dar într-un număr mai redus.

1.6.3 Testarea integrării

Această etapă a procesului de testare urmărește testarea grupurilor de module în vederea identificării erorilor ce nu au fost descoperite sau nu pot fi descoperite prin testarea la nivelul modulelor sau al componentelor. Într-adevăr, anumite date se pot pierde prin transmiterea lor de la un modul la altul sau execuția unui modul poate avea efecte negative asupra altui modul. De asemenea, integrarea subfuncțiilor realizate de diferite module poate să nu ducă la obținerea funcției dorite sau pot apare unele probleme la utilizarea structurilor de date globale.

Integrarea modulelor se poate face treptat, modul cu modul, sau deodată. Strategia integrării treptate presupune construirea și testarea programului în pași mici, astfel încât erorile să fie ușor de localizat și corectat, interfețele să fie cât mai complet testate, iar întreaga activitate de testare a integrării modulelor să fie desfășurată într-o manieră sistematică. În opoziție cu această strategie, integrarea deodată a modulelor presupune construirea programului prin integrarea modulelor componente urmată de testarea programului ca un tot. Această strategie nu este recomandată deoarece face dificilă corectarea erorilor. În primul rând, datorită amplorii programului, erorile sunt greu de localizat. În al doilea rând, tot procesul de testare va fi unul greoi deoarece după identificarea și corectarea unei erori poate să apară alta, ceea ce face necesară reluarea testării până când nu mai apare altă eroare.

1.6.3.1 Integrarea top-down

Integrarea și testarea modulelor începe cu modulul principal, după care se continuă prin parcurgerea în jos a structurii ierarhice a programului în una din următoarele două modalități posibile: integrarea orientată în adâncime sau integrarea orientată pe lățime.

Integrarea orientată în adâncime presupune integrarea tuturor modulelor componente pe câte o ramură importantă a structurii ierarhice. Alegerea ramurilor logice importante este oarecum arbitrară, ea depinzând de caracteristicile sistemului informatic.

Integrarea orientată pe lățime presupune integrarea mai întâi a modulelor situate pe nivelul ierarhic imediat inferior modulului principal și se continuă în acest mod cu fiecare nivel ierarhic.

Aplicarea integrării top-down impune utilizarea modulelor ciot. Se începe prin testarea modulului principal, considerat ca un modul director, iar modulele subordonate direct vor fi înlocuite cu module ciot. Apoi, în funcție de maniera de integrare (în adâncime sau pe lățime), modulele ciot vor fi înlocuite pe rând cu modulele adevărate. După înlocuirea unui modul ciot se vor executa toate testele planificate și numai apoi se va trece la înlocuirea următorului modul ciot. Se reia acest proces până la integrarea tuturor modulelor programului.

1.6.3.2 Integrarea bottom-up

După cum îi spune și numele, acest tip de integrare presupune construirea și testarea treptată a programului, începând cu modulele de pe ultimele niveluri ierarhice. În acest caz nu mai sunt necesare modulele ciot, deoarece în momentul testării unui modul, toate modulele subordonate au fost deja integrate și testate. În schimb, sunt necesare modulele director.

Integrarea și testarea bottom-up se desfășoară după următorul scenariu: modulele situate pe ultimele niveluri ierarhice sunt grupate astfel încât fiecare grup de module să realizeze o subfuncție a programului; apoi se creează câte un modul director pentru fiecare grup de module și pe baza căruia se va testa fiecare grup în parte; după ce testarea fiecărui grup de module s-a încheiat, se elimină modulele director și se regrupează modulele prin înglobarea modulelor situate pe nivelul imediat superior. Acest proces va fi reluat până la construirea și testarea întregului program.

Pe măsură ce se înaintează în ierarhie, numărul modulelor director se micșorează. Dacă s-ar aplica integrarea top-down pentru primele două niveluri ierarhice din structura programului, atunci numărul modulelor director necesare s-ar reduce substanțial, iar integrarea grupurilor de module ar fi mult simplificată. De aceea, în practică se îmbină cele două tipuri de testări, respectiv integrarea top-down și bottom-up, fiecare prezentând avantaje și dezavantaje specifice.

De pildă, integrarea top-down permite testarea principalelor puncte decizionale încă din primele momente ale testării, dacă arhitectura programului a fost proiectată conform cerinței înglobării principalelor decizii din logica programului în modulele situate pe nivelurile superioare ale structurii programului. De asemenea, prin integrarea orientată în adâncime, programul poate fi asamblat și testat pe funcțiile sale, ceea ce facilitează ulterior testarea sistemului și testarea de acceptare.

1.6.4 Testarea la nivelul sistemului

După testarea integrării, urmează testarea întregului sistem. Deși testarea sistemului este similară cu testarea integrării, ea diferă totuși prin orientarea testelor spre acele caracteristici nespecifice componentelor programului cum ar fi: performanțele sistemului, securitatea, refacerea în cazul apariției unor căderi ale sistemului etc. De asemenea, testarea sistemului diferă de testările anterioare prin luarea în considerare și a celorlalte componente ale sistemului, în afară de programe. Aceste teste vor verifica dacă elementele componente ale sistemului – hardware, software, oameni și date – sunt integrate corespunzător și realizează funcțiile prevăzute.

Testele concepute în această fază pot fi împărțite în patru categorii, în funcție de scopul urmărit:

Testarea refacerii urmărește să forțeze căderea sistemului din diferite cauze și să verifice dacă refacerea este realizată corespunzător.

Testarea securității urmărește să verifice dacă mecanismele de protecție ale sistemului funcționează corespunzător împotriva încercărilor de atac asupra sistemului sau a accesării neautorizate. În timpul acestei testări, testerul va juca rolul celui care dorește să atace sistemul, încercând diverse posibilități de spargere a acestuia. Rolul proiectanților sistemului este de a concepe sistemul astfel încât costurile accesării neautorizate a sistemului să fie mai mari decât valoarea informațiilor care ar putea fi astfel obținute sau valoarea pagubelor care ar putea fi produse.

Testarea solicitării sistemului presupune confruntarea sistemului cu situații anormale, testările anterioare verificând modul de funcționare a programelor în condiții normale de lucru. Prin testele concepute, execuția programelor va solicita resurse în cantități, volume sau frecvențe anormale.

Testarea performanțelor sistemului verifică performanțele obținute în momentul execuției programelor în contextul integrării tuturor componentelor sistemului.

În principiu, testarea sistemului va include toate activitățile specifice testării de acceptare, însă ea va fi realizată fără implicarea utilizatorilor. Astfel, ea oferă ocazia ultimelor verificări și modificări înainte de prezentarea sistemului în fața beneficiarului.

1.6.4.1. Test de funcționalitate

Testele de funcționalitate la nivelul sistemului sunt folosite să asigure că sistemul se comportă conform cu specificațiile. Toate cerințele funcționale ale sistemului trebuie să fie îndeplinite.

Testele de funcționalitate sunt de tip cutie neagră. Focusul este pe intrările și pe ieșirile corecte pentru fiecare funcție. Intrările incorecte trebuie de asemenea să fie tratate de sistem și comportamentul lui trebuie observat. Multe din testele de la nivelul sistemului, inclusiv cel de funcționalitate, trebuie proiectate în faza de creare a cerințelor și incluse în planul de test. Din moment ce testarea funcțională este de tip cutie neagră, clasele de echivalență pentru partiționarea și analiza valorilor de la margine pot fi folosite în generarea cazurilor de test. Testele ar trebui să se axeze pe următoarele obiective:

Toate tipurile de intrări corecte trebuie acceptate de sistem.

Toate tipurile de intrări incorecte trebuie respinse, iar sistemul trebuie să rămână disponibil.

Toate clasele de ieșiri posibile ale sistemului trebuie examinate.

Toate stările sistemului și tranzițiile trebuie examinate.

Toate funcțiile trebuie testate.

Rezultatele testului de funcționalitate cât și alte teste ale sistemului trebuie definite și documentate. Dacă se descoperă o eroare trebuie completat un raport formal al incidentului și transmis programatorilor pentru repararea codului. Managerii țin evidența acestor rapoarte cât și a progresului procesului de testare.

1.6.4.2. Test de performanță

Scopul testului de performanță la nivelul sistemului este de a vedea dacă întrunește cerințele de performanță specificate. De asemenea, testerii urmăresc dacă performanța este influențată de factori hardware sau software. Acest test permite testerilor să optimizeze alocarea resurselor sistemului. De exemplu, testerii descoperă că trebuie să realoce memoria sau să modifice nivelul de prioritate pentru anumite operații ale sistemului. Obiectivele acestui test trebuie definite clar de clienți în documentul de specificații și trebuie să fie inclus în planul de test. Obiectivele trebuie să fie cuantificate. La sfârșitul testului testerul va ști, de exemplu, numărul de cicluri CPU folosite, timpul de răspuns real în secunde. Resursele necesare pentru testul de performanță trebuie alocate în planul de test al sistemului.

Această testare este adesea combinată cu testarea solicitării sistemului și ia în considerare, în general, performanțele tehnice ale hardware-ului și software-ului.

1.6.4.3. Test de solicitare

Testul de solicitare constă în testarea sistemului încărcat astfel încât să producă alocarea resurselor la maximum. De exemplu, dacă un sistem de operare trebuie să reziste la 10 întreruperi pe secundă, iar încărcarea produce 20 întreruperi pe secundă, atunci sistemul este solicitat. Scopul testului de solicitare este să întrerupă funcționarea normală a sistemului și să găsească circumstanțele sub care el nu mai funcționează. Testul de solicitare este important deoarece poate descoperi defecte în timp real cât și puncte slabe unde proiectarea slabă pot face serviciul indisponibil. Acest test este important pentru sistemele în timp real, unde evenimente neașteptate pot să apară ducând la încărcarea intrărilor peste cele descrise în specificații. Interacțiunea hardware și software este întinsă la limită. Toate aceste condiții pot descoperi erori care nu pot fi găsite în condiții normale de test.

Testul de solicitare este realizat cu o parte din resursele utilizate la testul de performanță, inclusiv generatorul de încărcare care este setat la parametrii care provoacă stresul la nivelul sistemului.

Testul de solicitare este important din punctul de vedere al clientului. Atunci când sistemul funcționează corect și în condiții de solicitare, clientul are încredere că va funcționa și în condiții normale.

1.6.4.4. Testarea configurației

Sistemele software interacționează cu dispozitive hardware, imprimante sau cu mai multe procesoare. Testarea configurației permite testerilor să evalueze performanțele sistemului și disponibilitatea atunci când se schimbă configurația hardware.

Obiectivele acestui tip de test sunt:

Să arate că toate comenzile și meniurile funcționează corect pe noua configurație;

Să arate că toate dispozitivele care pot fi interschimbabile se pot într-adevăr înlocui unul cu altul;

Să arate că este păstrat același nivel de performanță când dispozitivele sunt interschimbate.

1.6.4.5. Test de securitate

Proiectarea și testarea sistemelor software pentru a se asigura că sunt securizate este o mare preocupare a programatorilor și testerilor. Testul de securitate evaluează caracteristicile sistemului legate de disponibilitate, integritate și confidențialitate.

Sistemul și datele pot fi compromise de:

(i) acțiuni ce au scopul de a produce pagube sau de a fura date confidențiale;

(ii) erori din partea programatorilor care modifică, șterg sau compromit datele din cauza unor neînțelegeri ale cerințelor sau lipsei de experiență;

Distrugerile pot fi provocate prin mai multe metode: viruși, cai troieni, capcane, canale ilegale.

Efectele acestor pătrunderi în sistemul de securitate pot fi foarte costisitoare și pot provoca:

(i) pierderea de informații;

(ii) coruperea unor informații;

(iii) informare greșită;

(iv) violare a confidențialității datelor.

Programatorii încearcă să realizeze securitatea sistemelor folosind mecanisme de protecție cum ar fi parole, criptări, anti-viruși.

În timpul testelor de securitate se verifică următoarele:

Verificarea parolelor—Testarea parolelor pentru a asigura faptul că utilizatorii vor selecta o parolă care îndeplinește toate condițiile descrise în specificații. Clasele de echivalență, analiza valorilor marginale și condițiile ce specifică o parolă corectă pot fi folosite în proiectarea cazurilor de test.

Intrarea legală și ilegală cu parole—Testarea accesului legal și ilegal la sistem și la date prin parole.

Expirarea parolelor—Dacă se hotărăște expirarea parolelor după o anumită perioadă de timp, testele vor trebui create astfel încât să asigure faptul că expirarea parolelor este suportată și utilizatorii pot intra cu parolele noi.

Criptarea—Proiectarea cazurilor de test pentru a evalua corectitudinea algoritmilor de criptare și decriptare ai sistemului.

Navigare—Evaluarea privilegiilor de navigare pentru a asigura că nu apare nici un acces neautorizat. Testerii trebuie să navigheze ilegal și să observe cum răspunde sistemul.

Viruși—Proiectarea cazurilor de test pentru a asigura că anti-virusul previne și oprește intrarea virușilor în sistem. Testerii pot încerca să infecteze sistemul cu diferiți viruși și să observe cum va răspunde sistemul. Dacă un virus pătrunde în sistem, testerii vor determina ce pagube a produs.

Cu toate acestea, chiar și după teste de securitate foarte costisitoare, nu se poate ști cu siguranță dacă un sistem software este sigur în totalitate.

1.6.4.6. Test de refacere după dezastru

Testul de recuperare verifică dacă sistemul își poate reveni normal după pierderea unor resurse. Acest tip de test este important în special pentru sisteme tranzacționale cum ar fi un sistem bancar în timp real. Un scenariu de test ar putea fi simularea pierderii unui dispozitiv în timpul unei tranzacții. Testele vor determina dacă sistemul a putut să revină la starea bună de funcționare și că nici o tranzacție nu a fost compromisă. Sistemele cu recuperare automată sunt proiectate în acest scop. Ele au un punct de verificare al sistemului care înregistrează tranzacțiile și starea sistemului periodic pentru a fi restabilite în caz de eșec. Aceste informații permit sistemului să se întoarcă într-o stare cunoscută după eșec. O bună metodă de a testa recuperarea după dezastru este de a rula aceste teste într-un mediu solicitant pentru sistem.

Unele sisteme informatice sunt concepute ca fiind tolerante la erori, adică apariția unor erori nu determină întreruperea funcționării sistemului, iar altele presupun întreruperea temporară a funcționării sistemului și rezolvarea problemelor într-o anumită perioadă de timp. Dacă refacerea este realizată automat de către sistemul însuși, vor fi verificate reinițializarea sistemului, refacerea datelor și alte aspecte ale sistemului. Dacă refacerea implică intervenția beneficiarului, va fi evaluată perioada de timp necesară pentru repunerea sistemului în funcțiune, apreciindu-se dacă este în limitele acceptate.

1.6.5. Test de acceptare

Testarea de acceptare reprezintă ultima ocazie de verificare a sistemului informatic, iar dacă aceste ultime teste sunt trecute cu bine, atunci sistemul informatic va fi livrat la clienți. Spre deosebire de testele anterioare, testarea de acceptare trebuie să se desfășoare într-un mediu similar celui în care va fi pus în funcțiune și de către persoanele care îl vor utiliza. Ea este realizată din perspectiva utilizatorului, ceea ce înseamnă că prin testele concepute vor fi exersate funcțiile aplicației orientate spre utilizator.

Testarea de acceptare trebuie planificată încă din primele faze ale dezvoltării sistemului, începând cu analiza. Planul testării de acceptare trebuie să constituie în fapt strategia de testare a principalelor componente sau funcții ale sistemului care să garanteze exploatarea ulterioară a sistemului în condițiile cele mai bune. Analiștii trebuie să colaboreze cât mai strâns cu utilizatorii în definirea obiectivelor și conținutului planului testării atât timp cât ei sunt cei care vor decide acceptarea sau respingerea sistemului. Prin urmare, analiștii trebuie să ia împreună cu utilizatorii decizia asupra testelor minime care trebuie realizate.

Testarea de acceptare presupune, de regulă, două etape: testarea alfa și testarea beta. Testarea alfa este realizată de client la sediul producătorului, sub supravegherea specialiștilor din echipa de dezvoltare a sistemului, și sunt utilizate date fictive dar reprezentative. În schimb, testarea beta se desfășoară la sediul clientului, fără ca utilizatorii să mai fie supravegheați de membrii echipei de dezvoltare a sistemului, utilizându-se date reale. De fapt, testarea beta reprezintă un fel de repetiție generală înaintea exploatării propriu-zise a sistemului. Testele beta constau în trimiterea la utilizatori a programului. Aceștia îl instalează și îl folosesc în condiții reale. Clienții trimit un raport cu problemele apărute organizației dezvoltătoare a softului, acestea urmând a fi reparate și incluse într-o nouă versiune.

Un test de acceptare poate avea ca rezultat trei posibilități: reușit, rezervat sau eșec. Pentru fiecare test se va specifica rezultatul minim acceptat, iar dacă pentru toate testele s-au obținut rezultatele minime, atunci sistemul poate fi acceptat.

1.6.6. Test de regresie

Testul de regresie nu este un nivel propriu-zis de test, dar reprezintă retestarea programului după ce s-au făcut modificări pentru a asigura că noua versiune a păstrat toate facilitățile vechii versiuni și că nu au apărut noi erori datorate schimbărilor. Testul de regresie poate să apară la orice nivel de test, de exemplu când este rulat un test pe componente, acestea pot să meargă până la un pas când apare o eroare. Componenta este reparată și testul este rulat cu toate cazurile vechi pentru a verifica dacă schimbarea nu i-a afectat funcționalitatea. Aceste teste sunt foarte importante când sunt folosite mai multe versiuni alea unui program. Utilizatorii vor să beneficieze de noile utilități ale versiunii, dar se așteaptă ca și vechile funcționalități să meargă corect. Cazurile de test, procedurile de test din versiunile anterioare trebuie să fie păstrate și disponibile pentru a putea rula cu noua versiune. Instrumentele de testare automată intervin aici pentru a ajuta testerii în aceste activități care consumă foarte mult timp.

Există două tipuri de teste de regresie: progresivă și corectivă. Testarea progresivă este realizată când versiunea modificată a programului implică o schimbare în specificații, în timp ce testarea corectivă este realizată când modificările nu implică modificări în specificațiile programului. Testele de regresie pot fi mari consumatoare de timp și destul de scumpe. Dacă aceste teste sunt realizate automat, atunci costurile de menținere ale sistemului informațional pot fi reduse semnificativ.

1.6.7. Test de întreținere

În timpul etapei de întreținere, sistemele informaționale se pot modifica. Există trei tipuri de întreținere a software-ului:

menținere corectivă pentru a corecta erorile care au fost descoperite în unele părți ale programului.

menținere adaptabilă este folosită când programul este modificat pentru a-i asigura compatibilitatea cu noul mediu în care va funcționa.

menținerea performanțelor este realizată atunci când sunt introduse noi module în sistem pentru a îmbunătăți performanțele sistemului.

Un studiu realizat indică faptul că probabilitatea apariției unei erori în timpul modificărilor programului este între 50% și 80%. De aceea, în toate tipurile de întreținere sunt realizate teste de regresie.

Capitolul 2 – Particularitățile testării automate a sistemelor informaționale

În noua economie, producătorii de soluții IT sunt confruntați cu o nouă cerință care îi obligă să schimbe total modul de construcție a unui produs, fără a face compromisuri de calitate. A fi primul pe piață cu ultimele tehnologii este mai important ca oricând. Lucrând cu o infrastructură software și hardware din ce în ce mai complexă, confruntați cu creșterea continuă a cerințelor de calitate și cu necesitatea reducerii costurilor, firmele de software încep să prețuiască tot mai mult soluții solide, inginerești, de dezvoltare de software. Testarea produsului software este o componentă majoră în procesul de dezvoltare. În limbaj de specialitate se discută despre asigurarea calității (Quality Assurance). Firmele din industria tradițională – de ex. industria de mașini, de construcții, de produse electronice sau alimentare au de zeci de ani departamente de testare și verificare a calității. În materie de software, organizarea și automatizarea muncii de testare și verificare a produselor a început din motive istorice evidente abia în anii '80.

Testarea manuală, mult timp văzută ca singura soluție de a descoperi eventualele defecte, întârzie foarte mult lansarea pe piață a produsului și induce cheltuieli semnificative mai ales în cazul descoperirii efectelor laterale – atât în procesul dezvoltării unei aplicații, cât și în cazul de schimbări ulterioare. Totodată procedurile de testare manuală, prin natura lor limitată, nu reușesc să descopere toate defectele și nu au nici o șansă să simuleze condiții de utilizare simultană, intensivă, a unei aplicații. Există numeroase căi de a îmbunătăți procesul de testare, una dintre cele mai eficiente fiind testarea automată.

Două din cele mai folosite definiții ale testării automate ar fi:

(1) Executarea automată a unor teste care altfel ar fi executate manual.

(2) Metoda creativă de a combina programarea cu testarea.

Testele automate execută o secvență de acțiuni fără intervenție umană și pot simula utilizarea unei aplicații în condiții de simultaneitate ridicată. În general, majoritatea produselor necesită să fie testate de mai multe ori, pe mai multe platforme software și hardware, ca și după schimbările ulterioare sau la lansarea unei noi versiuni de produs, prin folosirea testării automate, costurile testărilor repetate se reduc aproape la zero.

Cele mai importante beneficii sunt:

acoperirea tuturor etapelor de testare de la concepție până la lansare

posibilitatea simulării testării cu mai mulți utilizatori

posibilitatea repetării testelor

creșterea siguranței în produs.

Un sistem de testare automată trebuie să aibă la bază două caracteristici principale:

module reutilizabile

întreținerea și urmărirea activității dintr-un singur punct de control.

De aceea, una din calitățile care trebuie să le aibă un astfel de sistem este capabilitatea de a fi ușor configurat și adaptat în același ritm cu software-ul ce se testează. Sistemele de testare automată sunt o tehnologie în plină dezvoltare care au ca scop descoperirea și raportarea eventualelor defecte, mărirea longevității produsului și reducerea procesului de întreținere.

Testarea automată înseamnă mai mult decât o simplă captură de ecran și răspunsul la câteva scripturi: ea trebuie să înceapă cu planificarea și proiectarea procedurii de testare, să conțină o serie de teste repetabile, o interfață de management al scenariilor de test și un mecanism de raportare și gestionare a erorilor descoperite în urma testării. Un sistem de test evoluat sprijină utilizatorii printr-un sistem de documentare pe tot parcursul acestui proces.

2.1. Tipuri de testare automată

1. structurală (white-box testing) – se verifică structura software-ului și necesită acces complet la codul sursă. Acest tip de testare verifică dacă structura codului este eficientă: bucle complicate, zone de date comune, mii de linii de cod încurcate sunt numai câteva din problemele care pot fi îndepărtate. Scopul acestui test este mărirea performanței aplicației și a lizibilității codului.

2. funcțională (black-box testing) – se definesc așteptările clientului de la aplicație și se verifică automat dacă software-ul se comportă conform acestor așteptări. Prin testele ce se execută se observă comportamentul aplicației, evidențiat prin datele de ieșire, fără a se face referire la funcțiile interne.

3.regresivă (regression testing) – se verifică dacă s-a modificat neașteptat comportamentul aplicației în urma implementării unor noi cerințe/schimbări (change requests).

4. negativă (negative testing) – se solicită aplicația, producând deliberat cazuri complicate, neobișnuite sau particulare pentru a forța apariția erorilor.

5. de solicitare (stress testing) – se determină capacitățile absolute ale aplicației și ale infrastructurii pe care este implementată; cu ajutorul acestui tip de test se dezvăluie caracteristicile de performanță ale unui sistem menținut în condiții de încărcare totală, adică sunt pornite și rulate toate serviciile care în mod normal ar fi fost rulate separat în timp și independent.

6. de performanță (performance testing) – în urma acestui tip de testare se verifică dacă performanța aplicației este adecvată pentru cerințele stabilite, în termeni de viteză de acces, resurse de sistem utilizate și procesarea cererilor de acces.

7. de încărcare (load testing) – se determină punctele slabe ale aplicației și dacă sunt necesare îmbunătățiri ale infrastructurii hardware sau software prin măsurarea caracteristicilor de performanță și scalabilitate a principalelor componente ale aplicației; de regulă aceasta se realizează prin creșterea numărului de sesiuni utilizator sau a conexiunilor TCP/IP.

2.2. Avantajele și limitele testării automate

Testarea manuală consumă mult timp cerând multe investiții în resurse umane. De cele mai multe ori, din cauza timpului, nu pot fi testate manual toate funcționalitățile sistemului înainte ca acesta să fie lansat. Din acest motiv pot să nu fie descoperite unele erori.

2.2.1 Avantajele testării automate

Testarea automată urmărește rezolvarea acestor probleme crescând vizibil viteza procesului de testare. Pot fi create teste care verifică toate aspectele unei aplicații și apoi testele pot fi rulate de fiecare dată când aplicația se modifică la o nouă versiune. Unele instrumente automate atunci când rulează simulează exact acțiunile unui tester manual, mișcând cursorul, apăsând pe obiectele din interfața grafică (GUI) și toate acestea mai repede decât testerul manual.

Câteva dintre avantajele utilizării testării automate pe categorii sunt:

a) avantaje privind eficiența și costurile

• prevenirea erorilor prin abordarea structurată a procesului de dezvoltare a proiectului

• detecția erorilor care au ajuns până în faza de producție (prin teste de regresie automată)

• reutilizarea informației acumulate (condiții de test, scripturi)

• reducerea creării de noi scripturi (refolosindu-le și adaptându-le pe cele vechi)

• execuția automată a testelor de performanță în fazele de început ale proiectului poate evita eforturile de reproiectare în fazele ulterioare

• odată ce scripturile de testare automată sunt implementate, o parte din personal poate fi redirecționat către alte necesități

b) avantaje privind economia de timp

• analiză rapidă și exactă în cazul schimbării parametrilor sistemului

• durată scurtă a ciclurilor de testare

• estimări mai exacte pentru procesul de planificare a testului

• posibilitatea efectuării mai multor teste (scripturile de testare pot fi rulate și după orele de program economisind astfel timp)

• generarea rapidă a condițiilor de testare

c) avantaje privind calitatea

• o mai bună înțelegere a scopului testării

• o acoperire mai mare a elementelor de testat

• rezultate mai consistente datorită repetabilității testelor

• compararea automată a rezultatelor.

2.2.2. Limitele testării automate

Sunt multe lucruri pe care instrumentele de testare automată nu le pot face și este important să se cunoască aceste limitări. Un sistem de testare automată nu poate spune când ceva "arată bine" pe ecran sau când o poză sau fereastră nu este bine încadrată. De asemenea, un test automat nu poate decide dacă logica programului are lipsuri funcționale decât în măsura în care au fost definite complet cerințele aplicației respective. Unele teste, mai ales pentru aplicații mici și pentru aplicații care se concentrează mai ales pe grafică și nu pe logica aplicației, sunt mult mai ușor realizabile de către operatorul uman decât de către un calculator. De aceea trebuie alcătuit un plan bine definit al procedurii de testare, când, unde și în ce condiții este fiabilă introducerea automatizării.

Există o serie de probleme care pot fi întâlnite atunci când se încearcă automatizarea testării:

1. Așteptări nerealiste. Dacă așteptările conducerii nu sunt realiste, atunci indiferent cât de bine este implementat din punct de vedere tehnic, instrumentul de testarea automată nu va întâlni așteptările.

2. Experiență slabă în testare. Dacă experiența în testare este slabă, testele sunt prost organizate, cu o documentație puțină, atunci automatizarea lor nu este o idee bună deoarece automatizarea haosului generează mai repede haos.

3. Așteptarea ca testele automate să găsească multe erori. Un test găsește cele mai multe erori prima dată când este rulat. Dacă un test a fost deja rulat și a trecut atunci este foarte puțin probabil că atunci când este rulat din nou va găsit noi erori, decât dacă a avut loc o schimbare în sistem sau se rulează pe într-un alt mediu. Instrumentele automate de test sunt instrumente de redare. Ele sunt folosite pentru a repeta unele teste care au fost rulate deja.

4. Menținerea testelor automate. Atunci când programul se schimbă este necesar să se facă modificări în scripturile testelor automate pentru a putea fi rulate cu succes. Atunci când cere mai mult efort actualizarea testelor decât durează rularea lor manual, testarea automată este abandonată.

Trebuie de reținut faptul că testarea automată nu va înlocui niciodată definitiv testarea manuală.

Este imposibil ca toate testele să fie automatizate. Întotdeauna vor exista teste care sunt mult mai ușor de făcut manual decât automat sau teste pentru care nu este economic să se automatizeze pentru că este prea greu și durează prea mult timp. Testele care nu ar trebui automatizare sunt:

» teste care sunt rulate foarte rar. De exemplu dacă un test este rulat odată pe an nu se merită efortul de a-l automatiza;

» acolo unde sistemul este foarte instabil. De exemplu, dacă interfața și funcționalitatea se schimbă foarte des de la o versiune la alta, efortul de a schimba testele automate să fie în corespondență cu schimbările vor fi foarte costisitoare;

» teste unde rezultatul este ușor de verificat manual dar este dificil automat; de exemplu potrivirea culorilor dintr-o schemă de culori;

» teste care implică interacțiune fizică, cum ar fi interschimbarea unui card, deconectarea unor echipamente, întreruperea curentului etc.

Nu toate testele manuale trebuie automatizate ci doar cele mai bune și cele care sunt rulate mai des. Atunci când sistemul este instabil testarea manuală va găsi foarte repede problemele.

Testele automate țin de infrastructură mai mult decât de proiect. Dacă o organizație dorește să folosească testarea automată doar pentru un singur proiect atunci costurile nu sunt justificate. Chiar și problemele administrative minore, cum ar fi faptul că nu există suficiente licențe cu care testerii să lucreze poate avea un impact serios asupra succesului și costurilor testării automate. De asemenea în testarea automată se schimbă modul de lucru. Astfel dacă un test este lăsat să ruleze peste noapte, în dimineața următoare testerii trebuie să analizeze rezultatele lucru care ia mult timp. De multe ori, această analiză a testelor nu este percepută ca o activitate separată, mai ales în cazul testării manuale, unde are loc odată cu activitatea de execuție a testelor.

2.3. Comparație între testarea manuală și automată

Testarea manuală și testarea automată sunt mai degrabă două procese diferite, decât două căi diferite de a executa același proces: dinamica lor este diferită precum și modul de a releva erorile. Testarea manuală este mai folositoare în situațiile în care este nevoie urgent de rezultatele unor tipuri de teste specifice și limitate, când se dorește ca timpul de răspuns să fie foarte scurt, iar costurile să fie relativ mici. Cum îmbunătățirea calității produsului implică costuri adiționale pentru găsirea erorilor și gestionarea acestora până la repararea lor definitivă, testarea manuală s-a dovedit a fi în timp extrem de costisitoare. Testarea manuală pe scară largă presupune alocarea de resurse hardware și umane destul de mari, iar riscul să apară erori este amplificat de factorul uman.

Testarea automată necesită un efort inițial mai mare pentru planificarea, organizarea și producerea testului, criteriul principal în obținerea de rezultate bune fiind planificarea atentă, amănunțită și precisă a acestuia.

O alternativă interesantă este așa-numita "testare parțială". Această soluție este combinație de jumătate testare manuală și jumătate testare automată, aceasta din urmă fiind folosită numai acolo unde se pot obține beneficii maxime.

Testarea automată se dorește a fi soluția ideală pentru reducerea timpului de dezvoltare și a costurilor. O echipă de testeri poate să pornească instrumentele de testare automată, să le lase să ruleze și în final să colecteze și analizeze rezultatele. Timpul este astfel mai bine organizat și poate fi petrecut pentru izolarea și raportarea erorilor. În zilele noastre sunt multe instrumente pe piață care pot ajuta la planificarea, execuția și crearea de rapoarte în activitatea de testare. Majoritatea acestor instrumente necesită cunoștințe de specialitate pentru a le implementa și utiliza corespunzător. De asemenea, este bine de știut, că suitele profesionale de instrumente specializate în asigurarea calității oferă întotdeauna un produs de sine stătător care preia partea de management de proiect și pe cea de raportare a erorilor și de avertismente în timp real – “bug reporting/ticketing“. Un asemenea produs este de exemplu TestDirector de la firma Mercury Interactive – primul pe piață în materie de produse pentru asigurarea calității. Acest produs poate fi imaginat ca o sumă între un program de management de proiect de nivelul lui MS Projects și a unui sistem de avertismente în timp real (“ticketing”) profesional. El poate fi corelat cu diverse sisteme de gestiune a versiunilor folosite în implementare (de ex. CVS) și poate fi configurat în așa fel, încât rapoartele automate create de instrumentele de testare și/sau monitorizare a aplicațiilor să fie preluate automat în sistemul de “ticketing”, astfel că citirea și interpretarea manuală a rapoartelor de testare nu mai este necesară. Erorile sunt procesate de către TestDirector, care generează pe baza rapoartelor de testare email-uri, sms sau alte modalități de atenționare a echipei de implementare. Este de menționat că un sistem ca TestDirector poate fi folosit pentru partea de management de proiect și “ticketing” și în combinație cu testarea manuală, caz în care informațiile despre ceea ce trebuie testat se formalizează drept scripturi sau scenarii de testare, iar rezultatele testului manual trebuiesc introduse de către tester manual în sistem.

Soluțiile elegante pentru testarea sistemelor sofisticate sunt adesea limitate numai de imaginația testerilor.

2.4. Sfera de cuprindere a automatizării activităților de testare

Există numeroase instrumente de testare, fiecare pentru obiective specifice. Selectarea celui mai bun instrument de testare pentru un anumit sistem este critică pentru succesul activității de testare. Totuși dacă nu este selectat cel mai bun instrument de testare acesta poate fi personalizat și trebuie integrat în metodologia de dezvoltare a firmei.

2.4.1. Factorii de decizie în automatizarea testării

Contrar convingerilor majorității specialiștilor, nu este întotdeauna indicat să se folosească un instrument de testare automată. Factorii care limitează folosirea instrumentelor automate sunt:

costurile – un instrument de testare uneori nu este indicat pentru organizație datorită balanței cost – performanță.

cultură – echipa de programare poate să nu fie pregătită pentru un instrument de testare automată, deoarece necesită cunoștințe suplimentare și asigurarea calității pe o perioadă lungă de timp.

testarea ușurinței în utilizare – nu există instrumente care să testeze acest lucru.

testarea o singură dată – dacă testul va fi executa doar o singură dată, un instrument de testare nu se merită a fi folosit deoarece necesită timp și costuri mari.

timpul fragmentat – dacă există presiuni pentru a se termina o sarcină într-un anumit timp fix, folosirea unui instrument de testare nu este indicată, deoarece ia mult timp să se învețe cum să se utilizează, să fie instalat și integrat cu sistemul și cu metodologia de testare.

rezultate previzibile – dacă testele nu au rezultate previzibile, un instrument de testare pentru regresie ar fi nefolositor.

instabilitate – dacă sistemul se schimbă rapid în timpul fiecărei spirale de testare se va pierde mai mult timp pentru menținerea unui test de regresie.

În cele mai multe cazuri de la testarea automată se așteaptă să dureze foarte puțin timp, să consume puține resurse și să ceară puțină experiență. Din acest motiv testarea automată este dezamăgitoare pentru unele organizații, dar acestea ar trebui să-și stabilească așteptări realistice pentru a putea fi mulțumite de instrumentele de testare automată. Sunt trei lucruri importante când se stabilesc așteptările de la testele automate: în primul rând, trebuie făcută o investiție inițială în planificare, pregătire și programare până a se obține beneficii; în al doilea rând, economisirea de timp este posibilă dacă testele automate sunt rulate de mai multe ori și fără a fi nevoie de menținere; în al treilea rând nici un instrument de testare nu poate compensa lipsa de experiență în procesul testării.

Un instrument de testare automată trebuie folosit atunci când procesul de testare manuală nu este adecvat. De exemplu, când trebuie realizat un test de solicitare asupra sistemului, un grup de testeri pot să se logheze simultan în sistem și să încerce să solicite sistemul. Totuși această abordare are limitări. Nu toți testerii pot realiza exact aceleași acțiuni cu aceeași precizie. Pentru acest caz un instrument de testare pentru încărcare poate simula câțiva utilizatori virtuali sub condiții de stres controlate.

Un instrument de testare automat pentru regresie este necesar în următoarele situații:

testele trebuie rulate la fiecare versiune nouă a aplicației ceea ce necesită mult timp și resurse în cazul testării manuale.

sunt necesare teste care au nevoie de multe date de intrare pentru aceeași acțiune.

testele necesită informații detaliate despre sistem, cum ar fi interogări SQL sau atribute din interfață.

necesitatea realizării unui test de solicitare asupra sistemului.

Testele automate au trei beneficii majore: repetabilitate, putere și acumulare.

Repetabilitatea – înseamnă faptul că testele automate pot fi executate de mai multe ori complet de fiecare dată, astfel duce la economisirea de timp. Dar, pentru a se putea obține benificii, aplicația trebui să fie destul de stabilă astfel încât aceleași teste să poată fi repetate fără a necesita modificări majore.

Putere – adevărata putere a testelor automate vine nu doar din faptul că un test care a fost realizat manual poate fi repetat de multe ori automat, ci din faptul că pot fi rulate teste care nu au fost realizate manual deloc. De exemplu, dacă se generează cazurile de test prin program pot fi găsite mii de cazuri pe când manual doar câteva sute sunt posibile.

Acumulare – al treilea beneficiu, acumularea este cel mai important pe termen lung. Aplicațiile se schimbă permanent și devin din ce în ce mai complexe în timpul vieții lor din acest motiv numărul de teste necesare pentru a acoperi întregul sistem crește permanent. Din acest motiv testele automate trebuie create astfel încât să poată fi menținute cu ușurință de-a lungul ciclului de viață al aplicației.

2.4.2. Activitățile ce pot fi automatizate

Identificarea condițiilor de test și proiectarea cazurilor de test sunt activități ce țin mai mult de testarea manuală, de experiență testerului, se execută o singura dată și astfel ele nu vor fi automatizate. În schimb, execuția cazurilor de test și compararea rezultatelor așteptate cu cele reale țin de partea de laborator, vor fi executate de multe ori și din acest motiv se merită a fi automatizate. Activitățile care se repetă des sunt bune candidate pentru a fi automatizate.

2.4.2.1. Automatizarea proiectării cazurilor de test

Pot fi automatizate activitățile de proiectare a cazurilor de test? Există posibilități prin care un instrument de testare automată poate să automatizeze o parte a proiectării cazurilor de test. Aceste instrumente sunt numite generatoare de date de intrare pentru test și pot fi utile câteodată, dar nu vor înlocui niciodată proiectarea manuală.

O problemă este faptul că instrumentele automate generează un număr foarte mare de teste și nu pot alege care din acestea sunt cele mai importante, lucru realizabil doar prin testarea manuală. Toate instrumentele de testare automate se bazează pe algoritmi de generare a testelor astfel rezultatele lor pot fi mai corecte decât ale unui tester care folosește același algoritm. Totuși un tester se poate gândi la cazuri de test adiționale, poate identifica cerințe ce lipsesc sau identifica unde specificațiile sunt incorecte.

Există trei tipuri de instrumente de generare a intrărilor de test bazate pe cod, interfață și specificații:

bazate pe cod – generează intrările testului prin examinarea structurii codului. O cale în cod este compusă din segmente determinate de ramificații la fiecare nod de decizie. Un profil al condițiilor logice cerute pentru fiecare cale de segment poate fi produsă automat. Există dezavantaje deoarece această metodă automată nu poate identifica ieșirile așteptate, de asemenea testează doar codul care există și nu poate identifica codul care lipsește.

bazate pe interfață – poate genera cazuri de test bazate pe o interfață, GUI sau interfață web. Dacă o pagină conține meniuri, butoane, check boxuri un instrument de testarea automată poate crea un caz de test care folosește fiecare din aceste componente

bazate pe specificații – poate genera intrări de test și ieșirile așteptate doar dacă specificațiile pot fi analizate de instrumentul de testare automată. Specificațiile pot conține structuri în limbaj natural, cum ar fi reguli de afaceri (“bussiness rules”) sau pot conține date tehnice cum ar fi stări și tranziții. De exemplu, dacă intervalele acceptabile pentru câmpurile de intrare sunt definite corect, un instrument poate genera valori la graniță atât valide cât și invalide în clasele de echivalență. Un avantaj ar fi faptul că testele se acsează pe ce trebuie să facă sistemul nu pe ce face el. Ieșirile așteptate pot fi generate dacă sunt în specificații, presupunând că specificațiile sunt corecte.

Automatizarea generării cazurilor de test și a proiectării lor este mult mai greu de realizat decât automatizarea execuției cazurilor de test și compararea rezultatelor. De aceea, când se face referire la automatizarea testării, se referă la automatizarea execuției testelor și a comparării rezultatelor, nu la automatizarea generării cazurilor de test și a proiectării lor.

2.5. Procesul testării automate

Într-o abordare mai detaliată testarea automată înseamnă:

1. planificare

1.1. identificarea cerințelor și a funcționalităților

1.2. gruparea acestora în condiții de test

1.3. crearea cazurilor de test pentru aceste condiții

2. design

2.1. construcția scripturilor de test

2.2. generarea testelor de rulare

3. execuție

3.1. crearea scenariului de rulare a scripturilor

3.2. rularea instrumentelor de monitorizare pentru înregistrarea datelor

3.3. înregistrarea rezultatelor pentru fiecare rulare

3.4. raportarea și gestionarea erorilor

4. management

4.1. generarea rapoartelor și graficelor

4.2. controlul dintr-un singur punct de comandă

4.3. documentarea permanentă a stadiului curent al proiectului.

Majoritatea instrumentelor de testare automată sunt compatibile cu entitățile software ce intervin pe traseul de la clienți la furnizorul de aplicații. În orice punct de pe traseu se pot face teste si evaluări de performanță. În diagrama de mai jos sunt prezentate cele mai cunoscute și utilizate componente software ce intervin într-un astfel de proces.

Fig 2.1. Componente software

(sursa: Eftimescu, D., Ilioiu, Al. – Introducere în testarea automată, martie 2002, p. 4)

Procesul de testare automată presupune un efort de management deosebit. Acest proces începe încă din faza de analiză a aplicației și continuă în toate etapele de dezvoltare. În diagrama următoare se pot observa etapele procesului, ordinea și frecvența acestora, precum și locul central pe care îl ocupă managementul defectelor și serviciile. Un factor important este menținerea centrală a comunicării între etape pentru managementul erorilor.

Fig. 2.2. Procesul testării automate

(sursa: Eftimescu, D., Ilioiu, Al. – Introducere în testarea automată, martie 2002, p. 4)

2.5.1. Nivelurile automatizării testelor

Automatizarea este un proces cu mai multe niveluri. Pentru orice proiect trebuie să se decidă ce nivel de automatizare dorește să fie atins prin luarea în considerare a mai multor factori. Astfel atingerea unui nivel superior de automatizare implică ca nivelurile inferioare să fie deja atinse.

Nivelurile diferite de automatizare sunt:

Nivelul 1: Acest nivel de automatizare înseamnă faptul că toate mesajele sunt disponibile testerului și nu trebuie să mai creeze noi mesaje în timpul execuției testului. Acesta este un nivel de bază și ar trebui atins de toate tipurile de teste.

Nivelul 2: Atingerea acestui nivel presupune ca toate scripturile pentru testele generice cât și cele pentru testele de regresie să fie disponibile, iar testerul trebuie să facă modificări în timpul execuției pentru alte cazuri de test. Nu există un criteriu de interpretare a rezultatelor în scripturi, testerul este cel care trebuie să decidă dacă testul a trecut sau nu.

Nivelul 3: Acest nivel de automatizare este atins dacă nivelul 2 este atins iar scripturile sunt în starea trecut sau eșuat. Decizia dacă testul a trecut sau nu, cere un mare efort și nu este tot timpul ușor de luat.

Nivelul 4: Este un nivel extrem al testării automate unde verdictul dacă testul a trecut sau nu, bazat pe scripturi, este disponibil pentru toate cazurile de test.

Nivelurile de automatizare trebuie decise în funcție de costuri și eficiență.

Productivitatea automatizării este egală cu unu atunci când efortul necesar pentru a automatiza testul este egal cu efortul economisit datorită folosirii automatizării. Valoarea productivității ar trebui să fie cât mai mare pentru a obține beneficii din urma testării automate.

2.5.2. Testarea automată: o procedura completă

Activitatea automată de testare trebuie să înceapă chiar din prima etapă a dezvoltării sistemului informațional ca orice activitate de testare manuală. Diferitele activități automate trebuie alăturate activităților de testare manuală. În tabelul următor sunt descrise etapele de parcurs pentru activitățile de testare manuală și automată.

Tabelul 2.1. Etapele procedurii de testare

(sursa: Fewster, M., Graham, D. – Software Test Automation, Effective use of test execution tools, Addison-Wesley, New York 2000, p. 123)

Odată ce decizia cu privire la automatizarea testelor a fost luată următorul pas este implementarea soluției și personalizarea instrumentelor de testarea automată.

Capitolul 3 – Instrumente de testare automată

Selectarea instrumentelor este un factor critic în succesul automatizării testelor. Necesită studierea scopului testării, a strategiei de testare și apoi selectarea unui produs cât mai potrivit. Atunci când se alege un instrument de testare reutilizarea, siguranța și costurile sunt principalele criterii pentru a obține beneficiile maxime de pe urma folosirii instrumentului de testare ales.

Un instrument de testare trebuie să suporte câteva cerințe esențiale:

Interfețe de toate tipurile;

Ușurința de a da intrări invalide;

Ușurința de a controla implementarea sub test ;

Compararea rezultatelor și ușurarea procesului de luare a deciziilor cu privire la rezultatele testului;

Ușurința de a crea fișiere de jurnalizare.

Înainte ca o organizație să decidă ce instrument de testare să folosească trebuie realizată o analiză pentru a determina care din instrumente va fi mai productiv pentru un anumit proces de testare. Capacitățile unui instrument sunt examinate comparând problemele curente ce trebuie rezolvate cu o soluție țintă, evaluarea potențialului de îmbunătățire și analizând raportul cost beneficii.

3.1. Tipuri de instrumente pentru testarea automată

Sistemele de testare automată pot include instrumente de genul:

instrumente de testare a interfeței GUI, prin folosirea metodei "înregistrare/redare". Scripturile rezultate în urma înregistrării trebuie să fie modificate pentru a se crea proceduri de test reutilizabile și care pot fi menținute. Scripturile pot fi rulate pe noi versiuni ale softului pentru a compara rezultatele cu cele așteptate. Un instrument care folosește metoda de "înregistrare/redare" are și un comparator ce realizează automat compararea rezultatelor așteptate cu rezultatele reale obținute.

analizoare de cod – analizează complexitatea codului scris și urmărește respectarea unor standarde de scriere a codului. Instrumentele din această categorie pot cuantifica complexitatea proiectării, ajută la producerea testelor de integrare.

analizoare de memorie – detectează depășirea memoriei alocate, suprascrieri în zone nealocate și zone rămase nedealocate. Instrumentele din această categorie sunt folosite cu un scop precis: să verifice dacă o aplicație folosește bine resursele sale de memorie. Aceste instrumente arată dacă aplicație nu eliberează memoria ce i-a fost alocată și ajută la depistarea erorilor de la rulare.

testare de solicitare/performanță – pentru testarea aplicațiilor web și client/server în diferite scenarii de solicitare. Aceste teste permit testerului să examineze timpul de răspuns și capacitatea de încărcare ale sistemului. Instrumentele pot fi programate să ruleze simultan pe un număr mare de mașini, să măsoare timpul de răspuns de la client la server când e accesat de mai mulți utilizatori odată.

testare servere web – verifică validitatea și integritatea link-urilor, a codului html, programe client-side și server-side, securitatea transmiterii datelor

pentru generarea procedurilor de test. Un instrument de management a cerințelor poate fi folosit împreună cu un instrument specific de generare a procedurilor de test bazat pe specificații. Instrument de management a cerințelor este folosit pentru a culege informații despre cerințe și apoi acestea sunt procesate de generatorul de proceduri de test. Generatorul creează procedurile de test din punct de vedere statistic, algoritmic sau euristic. În generarea procedurilor de test statistic, instrumentul alege structura intrărilor și valorile într-un mod statistic aleator.

instrumente de măsurare a utilizabilității. Testarea utilizabilității este în mare măsura un proces manual de determinare a ușurinței în utilizarea fiecărei componente și a interfeței sistemului. Totuși există instrumente care pot să realizeze acest proces, dar care totuși nu trebuie să înlocuiască verificarea manuală.

generatoare de date. Generează automat datele de test. Aceste instrumente pot popula baza de date repede bazându-se pe un set de reguli, fie că datele sunt necesare pentru testarea funcționalității, a încărcării sau a solicitării.

instrumente de management al testării. Susțin planificarea, managementul și analiza tuturor aspectelor din ciclul de viață al testării. Unele din aceste instrumente cum ar fi Rational's TestStudio, sunt integrate cu instrumente de raportare a erorilor și management al configurației.

alte instrumente – pentru managementul documentației, raportării erorilor, configurației, etc.

3.2. Piața instrumentelor de testare automată

Există numeroase soluții pentru implementarea unui sistem de testare automată, majoritatea companiilor din acest domeniu oferind atât pachete software cât și servicii. Prima pe piață este firma Mercury Interactive a cărei concurentă directă este firma Rational. Ambele firme oferă atât produse de testare automată cât și pentru organizarea centralizată a procesului de testare, management de proiect și monitorizare de rețele, baze de date și aplicații în timpul utilizării productive a acestora. Alte firme (Compuware, Segue, etc.) oferă o gamă de produse similare, de obicei incompletă. Prețurile produselor de testare și monitorizare profesionale sunt deseori foarte mari (prețuri de 250.000 USD nu sunt neobișnuite). De aceea firmele producătoare oferă și servicii, cu ajutorul cărora se pot testa / monitoriza aplicațiile fără să fie nevoie de achiziționarea programelor și/sau licențelor respective.

Există de asemenea și produse freeware sau open source ca de exemplu Cactus de la Jakarta. Firme importante ca de exemplu SAP au de obicei pentru produsele lor instrumente de testare și monitorizare integrate. Dat fiind că domeniul testării automate este extrem de vast și complex, asemenea firme nu dezvoltă propriile lor programe pentru aceste funcționalități ci se bazează pe colaborări cu firme specializate (în cazul SAP – Compuware pentru testare și Mercury Interactive pentru monitorizare), creând doar interfețele de integrare către produsele respective.

Tabel nr. 3.1. Instrumente de testare automată ale firmei Mercury Interactive

Fig 3.1.Fereastra de gestiune a planurilor de test în Test Directory

Fig 3.2. Fereastra de gestiune a execuției testelor în Test Directory

Mercury TestDirector™ ajută la dezvoltarea unor aplicații de înaltă calitate, repede și eficient prin oferirea unui proces consistent și repetabil pentru strângerea cerințelor, planificarea și programarea testelor, analiza rezultatelor și administrarea erorilor. TestDirector este o singura aplicație bazată pe web ce cuprinde toate aspectele esențiale pentru managementul testelor — Managementul cerințelor, Planul de Test, Laboratorul Testului, și Managementul erorilor.

TestDirector suportă un nivel înalt de comunicare și colaborare între echipele IT indiferent de răspândirea geografică a organizației. Folosind acest instrument, mai multe grupuri dintr-o organizație pot contribui la asigurarea calității:

Analiștii definesc cerințele aplicației și obiectivele testării

Managerii de test și cei de proiect proiectează planul de test și dezvoltă cazurile de test

Inginerii de testare automată creează scripturile automate și le stochează în repozitoriu

Testerii QA rulează manual și automat testele, raportează rezultatele execuțiilor și notează erorile

Programatorii fixează erorile pe care le găsesc în baza de date

Managerul de proiect creează un raport cu starea aplicației și administrează alocarea resurselor

Managerul de proiect decide dacă aplicația este stabilă și pregătită pentru lansare.

Fig. 3.3. Fereastra pentru maparea componentelor din interfață în QuickTest Professional

QTP – QuickTest Professional facilitează crearea testelor prin înregistrarea operațiilor pe măsura ce sunt executate în aplicație. Pe măsură ce se navighează în aplicație QTP înregistrează fiecare pas executat și generează un script care detaliază pașii parcurși. De exemplu, accesarea unui link, selectarea unui check box sau trimiterea unui formular sunt toate înregistrate în test. După ce s-a terminat înregistrarea QTP poate verifica proprietățile unui anumit obiect din aplicație, de exemplu să verifice dacă un text apare într-o anumită locație a unei ferestre de dialog. După ce testul a fost rulat se pot vedea rezultatele în fereastra de rezultate sub forma unui raport detaliat sau a unui sumar pentru a putea fi analizate. Erorile găsite pot fi raportate fie manual fie prin intermediul Quality Center.

Procesul de testare în QTP se face în 7 etape:

Pregătirea înregistrării – se verifică dacă aplicația și QTP sunt setate pentru testul respectiv.

Înregistrarea unei sesiuni din aplicație – pe măsură ce se navighează în aplicație QTP transcrie fiecare acțiune ca un pas în script

Intensificarea testului – prin inserarea de puncte de verificare în test prin care se poate determina dacă aplicația funcționează corect sau nu.

Depanarea testului – pentru a asigura funcționarea fără întreruperi.

Rularea testului – QTP deschide aplicația și execută toți pașii din test.

Analiza rezultatelor testului – pentru a identifica erorile din aplicație.

Raportarea erorilor – se poate face prin Quality Center direct în baza de date.

Fig. 3.4 Fereastra principală de lucru în WinRunner

WinRunner – permite crearea de scripturi care verifică toate aspectele dintr-o aplicație, iar testele pot fi rulate pe fiecare versiune nouă. Atunci când rulează testele WinRunner simulează acțiunea umană, cum ar fi mutarea cursorului, selectarea unităților grafice din interfață, introducerea de valori, dar rulează mult mai repede acțiunile decât ar fi ele executate manual. Testarea cu WinRunner are loc în 7 etape aceleași ca și în cazul QTP.

Tabel nr. 3.2. Instrumente de testare automată ale firmei Compuware Corporation

Tabel nr. 3.3. Instrumente de testare automată ale firmei Segue

Tabel nr. 3.4. Instrumente de testare automată ale firmei Rational

Fig. 3.5. Ferestrele de lucru în Rational TestManager

Rational® TestManager este consola centrală pentru managementul activității de testare, execuție și raportare a problemelor găsite. Oferă suport total, de la testarea manuală până la diferite tehnici de testare automată, inclusiv testarea componentelor și teste de performanță. Rational TestManager poate fi accesat de toți membrii echipei care lucrează la un proiect asigurând vizibilitatea mare a informațiilor, ușurința utilizării și găsirea defectelor.

Fig. 3.6. Fereastra principală de lucru în Rational Robot

IBM Rational® Robot automatizează testele de regresie, funcționalitate și configurație pentru aplicații e-commerce, client/server și ERP. Este folosit pentru testarea de aplicațiile bazate pe o mare varietate de tehnologii și este integrat cu IBM Rational® TestManager® care este o soluție pentru managementul tuturor activităților de testare. Rational Robot rulează automat scripturi ce simulează acțiunile unui utilizator uman în ce privește interacțiunea cu interfața aplicației la fel ca și WinRunner de la firma Mercury.

Tabel nr. 3.5. Intrumente de testare automată Cactus – produs gratuit Jakarta

O atenție deosebită este îndreptată către produsul gratis Cactus, proiect “open source” dezvoltat de organizația jakarta.apache.org. Cactus este un framework destinat testării codului java pe partea de server (Servlet, EJB, TagLibs, etc.). Modulul de bază al produsului este JUnit. Utilizarea produsului presupune programarea în Java a scenariilor de testare, Cactus neoferind o interfață grafică pentru înregistrarea fluxului ce urmează a fi testat. De aceea acest produs se adresează unor utilizatori cu pregătire solidă în informatică.

Concluzii

Testarea automată nu va putea înlocui în întregime testarea manuală și nici nu trebuie. Testerii pot să observe cum un utilizator poate interacționa cu produsul, în timp ce un sistem de testare automată nu poate întotdeauna să prevadă aceste acțiuni sau să găsească cea mai bună cale de a le testa. Dacă sunt bine folosite, programele de testare automată măresc considerabil productivitatea QA, economisesc costuri, măresc semnificativ consistența și calitatea produsului și ajută la optimizarea și accelerarea procesului de dezvoltare al unei aplicații. Deja în țările cu tradiție în dezvoltarea de software există cerința ca toate produsele software din sectorul militar, medical, guvernamental și financiar să fie testate cu unul din sistemele recunoscute de testare automată, iar rapoartele automate asupra felului cum a decurs testarea constituie baza acceptării unei aplicații de către client.

Instrumentele de testare automată nu sunt magice, dar, implementate corect pot face minuni. Testarea trebuie inclusă în toate etapele procesului de dezvoltare a unui sistem, cazurile de test trebui identificate și create cât mai devreme, dar vor fi rulate după ce sistemul este disponibil pentru test. Instrumentele de testare automată sunt disponibile pentru toate tipurile de activități de testare din cursul ciclului de viață al sistemului informațional, dar nici unul din ele nu poate face nici o activitate de testare complet automat.

Automatizarea testelor oferă beneficii importante cum ar fi repetarea consistentă a testelor de regresie, testarea unor atribute ce sunt greu de testat manual, o mai bună folosire a resurselor, reutilizarea testelor și creșterea încrederii. Totuși, multe probleme apar în încercarea de automatizare a testelor cum ar fi așteptări nerealiste, o slabă experiență în testare, costurile de menținere și alte probleme tehnice și organizaționale.

Deși există modalități pentru a proiecta cazurile de test automat, totuși automatizarea rulării testelor și a comparării rezultatelor oferă beneficii mai mari decât automatizarea activităților de testare bazate mai mult pe experiența umană, cum ar fi creare cazurilor de test.

Totuși trebui reținut că testarea automată are limitele ei. Instrumentele de testare nu au imaginație și nu sunt deloc flexibile, totuși pot crește foarte mult calitatea și productivitatea sistemului testat.

Bibliografie

1. Avram, Gh., A. – Sisteme informaționale, Aisteda, 2002

2. Burnstein, I. – Practical Software testing, A process-oriented approach, Springer, 2002

3. Dustin, E. – Effective Software testing, 50 Specific ways to improve your testing, Pearson Education, Inc. 2002

4. Dustin, E., Rashka, J. – Automated Software Testing, Addison Wesley Longman Inc., 1999

5. Eftimescu, D., Ilioiu, Al. – Introducere în testarea automată, martie 2002

6. Fewster, M., Graham, D. – Software Test Automation, Effective use of test execution tools, Addison-Wesley, New York 2000

7. Hendrickson, E. – Test automation advice, http://www.qualitytree.com/autotest/autotest.htm

8. Isenberg, H., M. – The practical organization of automated software testing, http://www.automatedtesting.com/PATfinal.htm

9. Jones, T.C., Programming productivity: Issues for the 80s, IEEE Computer Society Press, 1981, citat în Presmann, R.S

10. Korel, B., AI-Yami, Ali M. – Automated Regression Test Generation, ACM Press   New York, NY, USA, 1998

11. Marick, B. – When Should a Test Be Automated?, http://www.io.com/%7Ewazmo/papers/

12. Myers, G. – The Art of Software Testing, Second edition, John Wiley, New York, 2004

13. Patton, R. – Software Testing, Sams Publishing, 2005

14. Pettichord, B. – Success with test automation, http://www.io.com/~wazmo/succpap.htm

15. Pettichord, B. – Are You Ready to Automate?, http://www.io.com/%7Ewazmo/papers/are_you_ready_to_automate.html

16. Vliet, V. – Software Engineering. Principles and Practicies, John Wiley & Sons, 2000

17. ***, ISO 9126: The Standard of Reference, http://www.cse.dcu.ie/essiscope/sm2/9126ref.html

18. ***, Mercury Interactive – white papers, http://www.mercuryinteractive.com

19. ***, http://www.coleyconsulting.co.uk/IEEE829.htm

20. ***, http://jakarta.apache.org

Bibliografie

1. Avram, Gh., A. – Sisteme informaționale, Aisteda, 2002

2. Burnstein, I. – Practical Software testing, A process-oriented approach, Springer, 2002

3. Dustin, E. – Effective Software testing, 50 Specific ways to improve your testing, Pearson Education, Inc. 2002

4. Dustin, E., Rashka, J. – Automated Software Testing, Addison Wesley Longman Inc., 1999

5. Eftimescu, D., Ilioiu, Al. – Introducere în testarea automată, martie 2002

6. Fewster, M., Graham, D. – Software Test Automation, Effective use of test execution tools, Addison-Wesley, New York 2000

7. Hendrickson, E. – Test automation advice, http://www.qualitytree.com/autotest/autotest.htm

8. Isenberg, H., M. – The practical organization of automated software testing, http://www.automatedtesting.com/PATfinal.htm

9. Jones, T.C., Programming productivity: Issues for the 80s, IEEE Computer Society Press, 1981, citat în Presmann, R.S

10. Korel, B., AI-Yami, Ali M. – Automated Regression Test Generation, ACM Press   New York, NY, USA, 1998

11. Marick, B. – When Should a Test Be Automated?, http://www.io.com/%7Ewazmo/papers/

12. Myers, G. – The Art of Software Testing, Second edition, John Wiley, New York, 2004

13. Patton, R. – Software Testing, Sams Publishing, 2005

14. Pettichord, B. – Success with test automation, http://www.io.com/~wazmo/succpap.htm

15. Pettichord, B. – Are You Ready to Automate?, http://www.io.com/%7Ewazmo/papers/are_you_ready_to_automate.html

16. Vliet, V. – Software Engineering. Principles and Practicies, John Wiley & Sons, 2000

17. ***, ISO 9126: The Standard of Reference, http://www.cse.dcu.ie/essiscope/sm2/9126ref.html

18. ***, Mercury Interactive – white papers, http://www.mercuryinteractive.com

19. ***, http://www.coleyconsulting.co.uk/IEEE829.htm

20. ***, http://jakarta.apache.org