ACADEMIA DE STUDII ECONOMICE DIN MOLDOVA

COALA MASTERAL DE EXCELEN

N ECONOMIE I BUSINESS
CATEDRA CIBERNETIC I INFORMATIC ECONOMIC
C.Z.U.: 004.415.53(478)(043)

Burleai Daria

INSTRUMENTE SI METODE DE TESTARE AUTOMAT

N CADRUL COMPANIEI EST-COMPUTER
TEZA DE MASTER
Domeniul general de studii: 44. tiine exacte
Domeniul de formare profesional: 444.1 Informatic
Programul de masterat: 444.2 Managementul Informaional

Autor:
masterand gr. MI-141m,

Admis la susinere
ef catedr:

Burleai Daria

prof. univ. Ion BOLUN

Conductor tiinific:

________________________
_________________20__

Cotelea Vitalie, prof. univ., doctor habilitat n informatic

CHIINU 2016

Declaraia pe propria rspundere

Subsemnata, Burleai Daria, absolvent a Academiei de Studii Economice din Moldova,
specializarea Management Informaional declar pe propria rspundere c teza de master
pe tema Intrumente i tehnici de testare automat n cadrul companiei Est-Computer a
fost elaborat de mine i nu a mai fost prezentat nici o dat la alt facultate sau instituie
de nvmnt superior din ar sau din strintate.
De asemenea, declar c sursele utilizate n tez, inclusiv cele din Internet, sunt indicate cu
respectarea regulilor de evitare a plagiatului:
- fragmentele de text sunt reproduse ntocmai i sunt scrise n ghilimele, deinnd
referina precis sursei;
- redarea/reformularea n cuvinte proprii a textelor altor autori conine referin
precis;
- rezumarea ideilor altor autori conine referina precis a originalului.

Daria Burleai

Contents
Lista abrevierilor..................................................................................................... 5
2

Introducere.............................................................................................................. 6
CAPITOLUL I. Scopul testrii automate a produselor software.......................7
1.1 Obiectivele testrii automate a produselor software.............................7
1.2 Tipuri de testare. Comparaie dintre testarea manual i cea
automat
11
1.3 Etapele ciclului de via a testrii automate........................................16
CAPITOLUL II. Metode si tehnici de testare automat....................................19
2.1 Descrierea procesului de testare ENR.....................................................19
2.2Tehnici utilizate n cadrul testrii..............................................................25
2.3Instrumente de testare

30
2.4 Infrastructura ENR ......................................................................33
CAPITOLUL III. Analiza i evaluarea rezultatelor n cadrul procesului de
testare automat.................................................................................................. 51
3.1Evaluarea eficienei economice.................................................................51
3.2 Factorii de returnare a investiiilor..........................................................55
3.3 Calcularea costurilor i beneficiilor..........................................................58
Bibliografie............................................................................................................. 71
nluzii................................................................................................................. 72

Lista abrevierilor
ATML - Automatic Test Markup Language - Ciclul de via a testrii automate
EDI - Electronic data interchange - Schimb electronic de date
ENR- Enrollment Management
ROI- Return of investments- Factorii de returnare a investitiilo
IEEE- Institute of Electrical and Electronics Engineers
ECF- Edifecs Common Format
ANSI American National Standards Instituite
ISO - International Organization for Standardization
XML - eXtensible Markup Language
RIM Referance Implementation Model
CS - Client Services
STD-Standard

Introducere
Nivelul de dezvoltare rapid a produselor software a condus la mrirea impactului i a
importanei testrii n ultimii ani. Testarea joac un rol important cadrul oricrei companii IT,
deoarece prin intermediul acestui proces se reduce riscul n cadrul afacerii, se protejeaz de unele
pierderi i duce la stabilizarea produselor software.
Prin definiie, testarea software reprezint un proces de validare i verificare a faptului c un
program/aplicaie/produs software corespunde cerinelor care au ghidat proiectarea i
implementarea acestuia. [1.1].
Lund n consideraie concurena sporit, un rol important n meninerea locului pe pia
constituie calitatea produsului. Aceasta asigur pstrarea imaginii companiei salvnd clienii de
la pierderi materiale.
Noile funcii implementate n sistem care sunt dictate de cererea pieei sau a clientului trebuie
supuse unui proces eficient i minuios de testare. Eficiena testrii const n utilizarea i
aplicarea tehnicilor i metodelor optime a etapelor ciclului de via software prin detectarea
erorilor critice i majore la etapele timpurii. Testarea web aplicaiilor necesit cerine de testare
speciale. Astfel, setul de cerine speciale de testare, i structura special a web aplicaiilor
necesit la rndul su o mbuntire a procesului de testare. O metod destul de eficient n
mbuntirea procesului de testare este testarea automat.
Prin definiie, testarea automat este procesul prin care se pot rula automat, fr intervenia
uman, diverse scenarii de testare [3.2]. De obicei, este necesar testarea repetat a produselor
pe diverse platforme software i hardware, la fel n rezultatul schimbrilor anterioare sau la
lansarea noilor versiuni de proiecte. n consecin, prin utilizarea testrii automate, se reduc la
zero costurile testrilor repetate.
n prezenta lucrare, s-au abordat, s-au analizat i s-au comparat un ansamblu de metode, tehnici
i instrumente de testare automat, n contextul unor exemple, utilizate la diferite etape a ciclului
de testare, s-au propus soluii n urma analizei acestora pentru problemele existente n prezent la
acest capitol, pentru a mbunti eficiena procesului de testare i a asigura realizarea
obiectivului principal al oricrei companii productoare de software : prestarea produselor
calitative i asigurarea costurilor optime.

CAPITOLUL I. Scopul testrii automate a produselor software

1.1 Obiectivele testrii automate a produselor software
Testarea software poate fi definit ca un proces de validare i verificare a faptului c un
program/aplicaie/produs software corespunde business cerinelor i cerinelor tehnice care au
ghidat proiectarea i implementarea acestuia i ruleaz i se comport corespunztor ateptrilor ,
specificaiilor [1.1]
5

n urmtoarea lucrare a fost propus crearea unei abordri sistemice, n baza materialelor
studiate, a ansamblului de obiective, ce urmeaz s fie atinse n procesul de testare automat i
tratarea fiecrui obiectiv n parte, pentru alegerea celei mai eficiente metode de testare la diverse
nivele i etape de testare a ciclului de via software.
Obiectul primordial al testrii automate este de a simplifica ct de mult posibil efortul de
testare, cu un set minim de scripturi.
Voi distinge urmtoarele obiective care le-a menionat Dorothy Graham n cartea sa Software
Test Automation. S ncercm s analizm obiectivele:
-

Automatizarea trebuie s gseasc mai multe defecte.

Aceasta presupune executarea ansamblului de teste, scopul crora const n dezvluirea mulimii
de defecte existente n produsul software.
De fapt, este cert faptul c testarea buna nu const n numrul de rulri a testelor de caz, dar n
calitatea rulrii acestora.
Factorul ce determin gsirea mai multor defecte const n calitatea testelor de caz, nu n
cantitatea acestora.
n concluzie am putea spune c automatizarea testrii ar trebui s urmreasc acel obiectiv de a
a asigura o acoperire a tuturor testelor care pot gsi defecte n produs, i de a nu permite
mascarea acel probleme care deja exist n scripturi n produsul software testat.
-

Automatizarea trebuie s reduca personalul de testare.

Persoanele cu abiliti n dezvolatarea de test scripting ar trebui fi nlocuite cu persoanele cu

abiliti obinuite de testare.
Automatizarea sprijin activitile de testare, dar nu le nlocuiete pe acestea. Instrumentele de
testare nu pot lua decizii inteligente n privinta la ce teste vor fi rulate i cnd, deasemenea nu pot
investiga problemele aprute i analiza rezultatele.
-

Automatizarea ar trebui s reduc timpul i cheltuielile de testare.

Principalul lucru care determin creterea timpului de testare consituie calitatea software-ului,
numrului de defecte care sunt deja acolo, calitatea software-ului este n mare msur
responsabilitatea dezvoltatorului, nu a testerului sau a instrumentelor de testare automat.
6

Respectiv, testele automate optime ar trebui s reduc acel timp de testare prin gsirea defectelor
ntr-un numr maxim i ntr-o perioad ct mai scurt.
Descoperirea acestor defecte ntr-un timp ct mai scurt duce la scderea sau evitarea cheltuielilor
de testare. n caz contrar, gsirea problemelor n etapele de dezvoltare trzii duc la majore
cheltuieli de a elimina erorile gasite.
-

Automatizarea ar trebui s asigure rularea a mai multor teste, ceea ce acoper o

poriune mai mare de testare a produsului.

A calcula numrul de teste automate nu este o msurare util ce contribuie n procesul de testare.
Dac echipa de testare ncheie cu un set de teste care sunt greu de rulat i condus, atunci
problema nu const n instrumentul de testare automat. Vina const n alegerea greit ctre
testeri de a automatiza aceste cazuri de test.
Din aceast cauz este foarte important de a alege corect cazurile de test. Cum pot fi alese
cazurile? Testele care sunt efectuare doar de cteva ori, mai bine de pstrat pentru testarea
manual. Cazurile bune de teste automate sunt cele care se repet frecvent i necesit cantit i
mari de date pentru a efectua aceeai actiune. Iat unele exemple de teste care ar trebui
automatizate:

Testele repetitive care se execut pentru mai multe prototipuri de aplicaie.

Teste care tind s provoace erori umane.

Teste care necesit seturi de date multiple.

Teste care sunt imposibil de efectuat manual.

Teste care ruleaz pe mai multe platforme i configuraii diferite hardware i software.

Testele care iau o mulime de efort i timp n cazul testrii manuale.

Noi ar trebui s automatizm X% din testele noastre.

Deseori se ntmpl ca automatizarea a 2 % din majoritatea testelor importante pot acoperi cu

mult mai mult dect automatizarea a 50 % din teste care nu ofera valori.
De asemenea, exist o categorie de teste care nu pot fi automatizate. i unele din acestea sunt
incluse n urmtoarea diagram.

Ce nu poate fi
automatizat?

Aplicaie instabila

Teste de tipul Once in

a Blue Moon

Revizuiri de cod i
documentaie

Figura 1.1 Categoria de teste ce nu pot fi automatizate

Aplicaie instabil: Dac software-ul este n curs de dezvoltare i supus multor schimbri,
testarea automat nu va fi att de eficient.

Teste de tipul Once in a Blue Moon: Nu este eficient de a automatiza scripturi de

testare care vor fi rulate foarte rar.

Codul i documentaia revizuit: Nu trebuie de ncercat de a automatiza revizuirile de cod

i de documentaie, acestea pot cauza doar probleme.

Realizarea obiectivului respectiv ar ajuta la detectarea erorilor n fazele timpurii, astfel

prentmpinnd defectele din producie i deasemenea, economisirea resurselor.
Lund cunotin cu obiectivele analizate vom incerca s enumerm principiile procesului de
testare automat. Printre ele s-ar distinge:

Verificarea unei condiii pentru un singur test automat - crearea testelor ct mai
laconice, dar care s acopere funcionalitatea. Deseori n cazul testelor automate, se
utilizeaz scripturile de verificare, care duc la ncetinirea verificrii produsului, deoarece
n caz c o verificare cade, se blocheaz rularea i a urmtoarelor scripturi, dificultnd
astfel localizarea defectului. Verificarea mai multor condiii ntr-un singur test are sens n
cazul executrii manuale a testelor.

Dependena testelor fa de cerinele clientului - reprezint un principiu care ar trebui

luat n vedere n primele faze de creare a testelor automate. Acestea trebuie s corespund
cu cerinele i specificaiile propuse de ctre client. n cazul nerespectrii cu
specificaiile, testele create nu au nici un sens. Principiul dat este destul de important din

mai multe puncte de vedere, deseori anume prin estimarea rulrii acestor teste automate,
care corespund cerinelor, clientul i-ar putea crea o imagine a calitii produsului.

Independena testelor acest principiu const n crearea testelor automate independente

unul fa de altul. Deseori, la etapa de scriere a unui test, in cazul mai multor pa i, se
creeaz cte un test la fiecare pas. Astfel, cnd acestea se ruleaz ele sunt dependente ntre
ele, ceea ce n multe cazuri duce la imposibilitatea rulrii fiecrui test. Pentru a evita
acest lucru, este nevoie ca testerul s urmreasc i s se asigure c testele sunt
independente i vor putea fi rulate fr blocarea vreo unuia dintre acestea.

Rezistena testelor testele ar trebui sa fie rezistente la schimbrile funcionale ce au loc

n cadrul produsului. Este nevoie de a actualiza informaia la o singur metod central,
fr a fi nevoie de a modifica coninutul datelor a mii de alte teste individuale.

Paradoxul Pesticide- acest principiu const n executarea acelorai cazuri de teste de mai
multe ori, care duce la micorarea numrului de probleme gsite. Din acest motiv cazurile
de test ar trebui revizuite uneori, pentru adugarea unor condiii de verificare, tergerea
unor teste redundante, pentru meninerea testelor actualizate ultimelor cerine i ct mai
eficiente.
Analiznd acest principiu, am determinat o evaluare a unor cazuri de test ce au fost rulate
ntr-o anumit perioad de timp pe parcursul mai multor etape a proiectului Enrollment
Management(release-ul mai multor componente din acest proiect). Rezultatele le putem
urmri n urmtorul tabel. (1.1)
Tabelul 1.1 Rezultatele executrii testelor automate la etapa de regresie

Versiunea
produsului

Nr. de teste
executate

Nr. de teste
executate cu
succes

Nr. de teste
care nu au
trecut

Nr de teste
care nu sau rulat

8.3.0

250

208

21

21

8.3.1

218

206

8.4

837

820

Din acest tabel observm micorarea numrului de teste automate care nu au trecut cu
succces la
etapa de regresie pe parcursul mai multor versiuni a proiectului.

1.2 Tipuri de testare. Comparaie dintre testarea manual i cea automat

Totalitatea operaiunilor i activitilor care au caracteristici, subiect i obiective comune se
grupeaz ntr-un tip de testare.
Exist numeroase tipuri de testare. Vom incerca sa analizm unele dintre acestea, dar mai nti s
comparm testarea manual de cea automat, care au fost repartizate astfel dup modul de
derulare a testrii.
Testarea manual reprezint procesul n care echipa de testeri joac rolul utilizatorului final
utiliznd aplicaia n mai multe moduri posibile pentru a determina comportamentul corect al
acesteia. Pentru a fi sigur de completitudinea testrii, testerul deseori urmeaz un plan de test
scris ce conine un set de cazuri de test (test case-uri). Acesta, de fapt, joac rolul unui ghid n
procesul de testare pentru a asigura o acoperire complet de testare. Dup ce testarea a fost deja
pornit, cazurile de test proiectate i scenariile de testare sunt executate, astfel orice diferen
dintre rezultatele reale i cele ateptate sunt raportate ca defecte. Dup raportarea i fixarea
defectelor, testerii retesteaz aceeai arie pentru a se asigura c defectele au fost fixate.
n urmatoarea schem vom observa tehnicile de testare efectuate manual pe ntreaga durat a
ciclului de via a produsului.

10

Testarea
de
acceptan

Testarea
de tip
White
Box

Testar
ea
manu
al

Testare
de tip
Black
Box

Testarea
unitar

Testarea
de
integrare

Figura 1.2 Tipuri de testare manual

S ncercm s constatm esena fiecreia dintre ele.
o Testarea de acceptan este o tehnic de testare efectuat pentru a determina dac
sistemul ndeplinete condiiile conform specificaiilor. Scopul principal al acestei
tehnici const n evaluarea sistemului n conformitate cu cerin ele de afaceri i
verificarea acestuia n ndeplinirea criteriilor necesare pentru livrare catre
utilizatorii finali.
n urmtoarea diagram 1.3 vom observa echiparea testrii de acceptan pe
parcursul ciclului de via al produsului software.
Cazurile de test sunt executate cu datele de testare sau folosind un script de test, iar
apoi rezutatele fiind comparate cu cele atepate.

11

Figura 1.3 Echiparea testrii de acceptan pe parcursul ciclului de via al

produsului
o Testarea de tip White Box tehnic de testare ce examineaz structura programului
i datele de testare provin din logica de cod.
o Testare de tip Black Box este o metod de testare ce analizeaz funcionalitatea
unei cereri bazate pe specificaii. Metoda dat poate fi aplicat la orice nivel de
testare software.
o Testarea unitar este o tehnic ce folosete testarea modulelor individuale,
determinnd de asemenea dac exist probleme de ctre dezvoltator. Scopul
principal este de a izola fiecare unitate a sistemului i de a identifica, analiza i
rezolva defectele.
o Testarea de integrare tehnica ce are ca drept scop verificarea funional, de
performan, fiabilitate ntre modulele deja integrate.
i totui, toate aceste proceduri de testare manual nu reuesc s descopere toate defectele
produselor. Astfel, ca o mbuntire a procesului de testare i revin testrii automate.
Testarea automat asigur executarea unor secvene de aciuni fr intervenia uman, totodat
simulnd utilizarea unei aplicaii n condiii de simultaneitate ridicat.
Una din problemele frecvente n companie este luarea deciziei de a automatiza sau nu testele. La
baza acestei decizii stau urmtorii factori:

12

 Riscuri
Costuri
Timp
Calitate

Urmatoarea problem care apare se reduce la ntrebarea Cnd se automatizeaz testele?

Analiznd rspunsul la ntrebare, au fost evideniai urmtorii pai cnd testele pot fi
automatizate:
n primul rnd n urma specificaiilor definite i scrise.
Corespunztor specificaiilor, testele pot fi dezvoltate i planificate nainte de
implementarea lor.
Echipa de testeri trebuie s cunoasc software-ul de automatizare, s fie
familiarizai cu acesta verificnd astfel compatibilitatea cu aplica ia ce urmeaz a fi
testat.
Toate componentele aplicaiei trebuie s fie recunoscute de ctre software-ul de
testare.
Analiznd att testarea manual ct i cea automat, se relev faptul c fiecare din ele au att
avantaje, ct i dezavantaje.
Unele din avantajele testrii automate sunt:
o Testarea produsului n mod repetat
o Programatorii obin un rspuns ntr-un interval scurt de timp ce ine de calitatea
produsului.
o Iteraiile de testare au o posibilitate nelimitat
o Raportarea defectelor n mod automat
o Sunt gsite defecte ce nu pot fi uor detectate de testarea manual
Dar, totui, n unele cazuri testarea automat ne dezavantajeaza, fiind indicat testarea manual.
n cazul schimbrii dese a interfeei grafice a aplicaiei, testele automate de asemenea vor trebui
modificate. Astfel, se necesit un timp mai ndelungat ce deseori este un punct slab. Atunci cind
13

proiectul este determinat pe o perioad lung de timp, este indicat utilizarea testrii automate,
deoarece este suficient timp de a pregti testele automate, altfel, la proiecte cu o durat scurt de
timp e convenit mai mult testarea manual. Testarea manual e avantajoas de asemenea n
cazul unor teste specifice i destul de limitate, care necesit un rspuns rapid i se reduce la
costuri mai mici. n diagrama 1.4 se observ o dependen ntre timp i costurile suportate de
ctre testarea automat i cea manual pe o anumit perioad de timp.

Figura 1.4 Dependea Timp- Cost ntre testarea automata i cea manual

Dar, totui, pe o perioad mai mare de timp, alocarea in testarea manual devine destul de
costisitoare, i anume n resursele umane si resursele hard.
S-a constatat faptul c riscul apariiei erorilor este amplificat de factorul uman. Pe lng acestea,
testarea automat necesit la etapa iniial un efort mai mare, anume la planificare, organizare si
producerea testului. Anume aceast etap decide calitatea si corectitudinea viitoarelor rezultate.

Analiznd metodele de testare descrise este cert faptul, indifenrent de tehnica de testare utilizat,
cn final produsul trebuie s corespund specificaiilor si cerinelor ce au fost determinate din
start. Testarea este o etap foarte important n ciclul de via al produsului, de aceea trebuie
gestionat corect, pentru a evita surplusurile de resurse, de timp i costurile excesive.
14

1.3 Etapele ciclului de via a testrii automate

Asigurarea calitii este n sine un proces destul de complex, n care etapele sunt definite
strict pentru asigurarea unei caliti optime n restriciile de timp i bani.
Aceast funcie redirecioneaz companiile de a atinge scopurile din punct de vedere a unui
produs calitativ utiliznd astfel testarea automat. n ciuda faptului c metoda necesit metode i
tehnici care ar mbunti procesul de testeare.
n diagrama 1.5 sunt indicate etapele ciclului de via a testrii automate n cadrul
proiectului.

Figura 1.5 Etapele ciclului de via a testrii automate

1. Analiza cerinelor i specificaiilor (BRD) aceasta reprezint prima etap n procesul
de testare. La aceast etap se iau deciziile referitoare la ceea ce sistemul ar trebui s
ndeplineasc, respectiv ce instrumente de testare se vor utiliza pentru fiecare arie.
2. Urmtoarea etap const n aflarea raspunsului la ntrebarea Este sau nu nevoie de
automatizat aceast arie? Respectiv, de-a lungul acestei etape se planific ateptrile
15

de la procesul de testare, de a gsi avantajele tehnicii alese. La acest moment se decide

calitatea viitorului produs, aici intervin cele mai multe ntrebri i dezbateri referitor la
alegerea cazurilor de test ce vor fi automatizate, dac testele automate create vor
acoperi un procentaj ct mai mare de testare a produsului, dac aceste teste vor crete
viteza de testare.
n urma gsirii raspunsurilor la ntrebri se stabilete sau se estimeaz procentual rezultatele
ateptate n urma rulrii testelor automate.
Urmtoarea etap const n gsirea uneltelor de testare ceea ce const n alegerea anume acelor
instrumente care vor fi compatibile cu produsul testat, cum este reprezentat n figura 1.6.

Figura 1.6 mpnente e intervin n presul de testare autmat

Toate instrumentele alese trebuie s convin anumitor standarde, iar n alegerea acestora
sunt urmrite unele condiii cum ar fi:

S fie compatibil pentru diverse aplicaii i platforme n acest sens este recomandat de a
alege acel instrument care va fi suportat de majoritatea aplicaiilor.

16

fie compatibil cu diferite sisteme de operare la etapa dat trebuia alese

instrumentele care vor fi compatbile cu acele sisteme de operare care reprezint suport
pentru apliicaiile din companie ct i cele ale clientului.

S fie compatibill pentru diferite tipuri de testare.

n urma gsirii instrumentelor necesare de testare, urmeaz etapa de planifiare a testrii

automate. La etapa dat se evalueaz sarcinile existente, metodele de testare, stretegia care
va fi folosit i obiectivele propuse. Se ia n cosiderare de asemena timpul alocat pentru
fiecare sarcin, aproximarea costurilor penrtu perioada de testare, evaluarea unor riscuri care
pot aprea pe parcursul perioadei de testare.
Urmtoarea etap const n determinarea funionalitilor acoperite de procesul de testare
automat corespunztor cu resursele alocate.
Astfel, determinnd funcionalitile procesului de testare, urmeaz realizarea procesului de
testare automat. La etapa dat, echipa de testeri, unii programatori se ocup de crearea
propriu zis a terstelor automate i executarea acestora. Dac n urma executrii testelor apar
anumite defecte, funcionalitatea realizat de dezvoltator nu satisface cerinelor stabilite i
specificaiilor propuse acestea urmeaz s fie raportate, apoi fixate. Pentru asigurarea fixrii
corecte a problemelor aprute, testerii verific aceste arii, prin procesul numit regresie.
De asemenea o etap destul de

important revine managerilor de proiecte i anume

monitorizarea procesului de testare automat si revizuirea acestuia. La aceast etap se

realizeaz o revizuire a procesului de testare, evalundu-se rezultatele primite i comparndule cu cerinele ateptate. n cazul necorespunderii acestora, se ntreprind anumite msuri
pentru mbuntirea procesului de testare, i anume se achiziioneaz instrumente
suplimentare sau nlocuirea acestora, se repartizeaz sarcinile n ciclu, i anume testerii
primesc sarcini deja verificate de alte persoane i invers, deoarece n urma schimbrii
sarcinilor ntre testeri deseori se gsesc probleme majore, fiecare persoan verificnd din
diferite puncte de vedere, astfel asigurndu-se o verificare mai complet a componentei
supuse testrii. Deseori la aceast etap managerii adaug fore de munc sau n caz c
produsul nu are multe lacune, unele persoane sunt distribuite ctre alte proiecte.
Analiznd etapele procesului de testare automa, s-ar putea concluziona faptul c fiecare
etap corect proiectat i stabilit conform cerinelor i specificaiilor, duce la dezvoltarea
unui produs fr greeli si scpri majore.
17

CAPITOLUL II. Metode si tehnici de testare automat

2.1 Descrierea procesului de testare ENR
Procesul de testare include n sine mai multe activiti. Acest proces ncepe de la planificarea de
testare, care continu cu pregatirea pentru executarea i evaluarea statutului pn la finalizarea
testului. Astfel analiznd putem diviza procesul fundamental de testare n 5 etape principale:
-

planificare i monitorizare,
analiz i design,
implementarea i execuia,
evaluarea criteriilor de ieire i de raportare,
activiti de testare spre finisare.

Figura 2.1 Etapele procesului de testare

Analiznd figura 2.1, vom ncerca s caracterizm fiecare etap a procesului de testare.
1.
2.
3.

Etapa de planificare cuprinde o serie de sarcini majore:

Determinarea domeniului de aplicare i a riscurilor, identificarea obiectivelor de testare.
Determinarea abordrii de testare.
Implementarea politicii i strategiei de testare.

Strategia de testare este o schi care descrie poriunea de testare ce include dezvoltarea
software, este creat pentru a informa managerii de proiecte, testerii, i dezvoltatorii cu
privire la unele aspecte cheie ale procesului de testare. Aceasta include obiectivele de testare,
metodele de testare, timpul total i resursele necesare pentru proiect i medii de testare.
4. Determinarea resurselor necesare de testare, cum ar fi resursele umane, mediile de
testare.

18

5. Programarea analizei testelor, sarcinilor de proiectare, implementare, execu ie i

evaluarea testelor.
6. Determinarea criteriilor de ieire (Exit Criteria), cum ar fi criterii de acoperire( procentul
de aciuni care trebuie executat n timpul testrii).
Etapa de monitorizare a testelor la rndul su include urmtoarele sarcini:
1.
2.
3.
4.

Msurarea i analizarea rezultatelora procesului de testare.

Monitorizarea i documentarea progresului cazurilor de acoperire i cazurilor de ieire.
Iniierea aciunilor corespunztoare rezultatelor.
Luarea deciziilor.

-Etapa de analiz i design

Analiza testelor este procesul de cutare a informaiilor care poate fi folosit la crearea
informaiilor de testare. Aceasta reprezint etapa de baz pentru crearea cazurilor de testare
proprii. Practic, este informaia de baz din care putem extrage informaia pentru cazurile de test,
cum ar fi: cerinele, caietul de sarcini, analiza riscurilor, arhitectura i interfaa. Aceste
documente (baza de testare) se pot utiliza pentru a nelege cum va lucra sistemul n final.
Din perspectiva procesului de testare, analizm baza de testare pentru a determina ce poate fi
testat, acestea fiind condiiile de testare. Condiia de testare reprezint ceva simplu ce poate fi
testat. Avnd aceste condiii, se selecteaz acele ce pot fi combinate n cazurile de testare. Dup
ce au fost identificate condiiile de testare este important s le prioritizm pentru gsirea celor
mai importante. Condiiile de testare pot fi identificate pentru datele de testare, att pentru cele
de intrare, ct i pentru cele de ieire (ex: tipuri de fiiere, tipuri de tranzacii electronice, tipuri de
pli). Condiiile de testare sunt documentate conform standardului IEEE 829- Test Design
Specification.
Prin noiunea de design se nelege crearea planului de implementare a unei idei. Aadar, la etapa
de design se creeaz o serie de intrri pentru aplica ie care vor genera setul de rezultate a teptate.
Ideea const n asigurarea funcionrii bune a sistemului conform standardelor. Distingem 2
tehnici de testare a designului din figura 2.2:
* static poate fi utilizat pentru a testa orice tip de document, incluznd codul surs,
specificaii, modelele i cerinele de specificaii. Procesul are loc prin inspectare, revizuire i
parcurgere vizual.
19

* dinamic- necesit execuia aplicaiei n sine pentru testarea acesteia (ex: testarea unitar,
testare de integrare, testare de sistem).

Figura 2.2 Tehnici de testare a designului

- Etapa de implementare i execuie
n timpul implementrii testelor i execuiei acestora, se iau condiiile de testare drept cazuri de
testare i restul instumentelor cum ar fi: scripturi de automatizare, medii de testare i alte
infrastructuri. Implementarea testelor are urmtoarele sarcini de baz:
-

Dezvoltarea i prioritizarea cazurilor de testare, utiliznd tehnici de testare i crend date

de intrare pentru acestea.

Crearea suitelor de teste din cazurile de teste pentru eficientizarea execuiei.
Crearea mediilor de testare i verificarea lor.

Etapa de execuie cuprinde alte sarcini majore:

-

Executarea suitelor de teste i testelor individuale urmnd procedurile de testare;

Retestarea testelor cu erori pentru confirmarea defectelor. Aceasta este cunoscut ca i

confirmatea testelor;
Logarea rezultatelor testelor. Rezultatele execuiei vor delimita testele cu erori de cele
executate cu succes;
20

Compararea rezultatelor actuale cu cele ateptate. Dac sunt diferen e ntre rezultatele
actuale i cele ateptate, aceastea se raporteaz ca incidente;

-Evaluarea criteriilor de ieire i raportare

innd cont de evaluarea riscurilor din proiect pentru fiecare nivel de testare vor fi setate criterii
de ieire, ceea ce va nsemna testarea suficient. Aceste criterii variaz de la un proiect la altul.
Criteriile de ieire sunt valabile atunci cnd:
-

Un procent din teste au fost executate cu succes;

Procentajul defectelor este sub o anumit limit;
S-a ajuns n momentul de lansare a proiectului.

-Activiti de testare spre finisare

Aceast eta cuprinde urmtoarele sarcini de baz:
1. S se verifice dac planul de livrare a fost respectat i toate problemele au fost raportate
i rezolvate;
2. De a se finaliza i arhiva toate instrumentele de testere folosite pentru utilizarea
ulterioar;
3. De a evalua procesul de testare i a trage concluzii pentru proiectele viitoare.
Aceste activiti au loc atunci cnd aplicaia a fost lansat. Testarea poate fi ncheiat din
urmtoarele motive rezonabile:
-

Cnd toat informaia testrii a fost generat cu succes;

Cnd proiectul a fost nchis;
Cnd anumite inte au fost atinse;
Cnd aciunile de mentenan sau rennoire au fost ncheiate cu succes.

Analiznd procesul general de testare descris anterior, se va urmri procesul de testare a aplicaiei
ENR.
Etapa de planificare ncepe cu crearea unui plan de test, care descrie modul de testare pentru
proiectul Enrollment Management.
Strategia de testare cuprinde toate tipurile de testare care sunt aplicate in cadrul acestui proiect.
Testarea unitar este prima etap din procesul de testare care este meninut de ctre echipa de
programatori. Testele unitare sunt executate pe parcursul crerii fiecrei distribuii. Toate testele
21

unitare trebuie s fie executate cu succes, n caz contrar acestea trebuie fixate. Cnd se adaug o
poriune de cod nou n aplicaie aceasta trebuie s fie nsoit de un test unitar. Echipa de
programatori sunt resposabili de meninerea i monitorizarea rezultatelor testelor unitare. Unul
din riscurile care pot aprea la crearea acestor teste este timpul limitat accordat pentru crearea
lor, ceea ce sporete probabilitatea c nu toate ariile vor fi acoperite de teste unitare.
Urmtoarea etap este testarea funcional, la aceasta etap echipa de testare trebuie s se
asigure c toat funcionalitatea care este n scop a fost implementat corect i funcioneaz
conform scenariilor de acceptan propuse. Ca parte din testarea funcional putem distinge trei
tipuri de testri:
1. Testarea pozitiv - toat funcionalitatea care este acoperit trebuie verificate pe scenarii
pozitive i reale (din producie), conform specificaiilor;
2. Testarea negativ echipa de testare trebuie s acopere i scenarii negative al crui scop
const n asigurarea funcionrii sigure a aplicaiei n cazul intrrilor neprevzute;
3. Automatizarea testrii funcionale - pe parcursul testrii funcionale echipa de testare
trebuie s execute cazuri de test automatizate utiliznd frame-workul de testare existent
E2E.
Ca parte din testarea funcional testerii au responsabilitatea de a verifica c fiecare
implementare are scenarii de acceptan cu date valide, descrierea fiecrei implementri trebuie
s conin detalii destule pentru a fi neles scopul. Odat ce a fost implementat, echipa de
dezvoltare trebuie s aduc la cunotin detalii despre schimbrile aplicate, iar testerii au timp
alocat pentru nsuirea schimbrilor i automatizarea acestora. Pe parcursul acestei etape pot
aprea unele riscuri cum ar fi: testerii nu pot automatiza toate cazurile de test, din cauza
volumului mare de noi implementri unele componente pot ramne netestate.
Odat ce testarea funcional a fost incheiat cu succes urmeaz etapa testrii de
integrare. A crui scop const n asigurarea integrrii produsului de baz cu implementrile
costumizate ale clienilor. Produsul ENR trebuie s fie uor integrat cu schimbrile aplicate de
ctre echipa CS care avind un contact direct cu clienii deine toate costumizrile i specificaiile
lor.
n cadrul testarii de sistem aplicaia trebuie s fie testat pe diverse platforme. Produsul
ENR trebuie s fie suportat pe urmtoarele platforme:
22

1.
2.
3.
4.

Sistem de operare: Windows Server 2008/Linux

Baz de date : MSSQL Server 2008/ Oracle 11g
JMS : ActiveMQ 5.9.1
Limbaj de programare : Java 1.8

Aplicaia trebuie testat deasemenea n distribuie unic i multipla. Carateristica principal a

distribuiei unice este c pe acelai server sunt instalate i ruleaz toate serviciile. Prin
comparaie, distribuia multipl ofer posibilitatea de fi folosite mai multe servere pe care pot
rula unul sau mai multe servicii ale aplicaiei ENR.
ENR, fiind un produs care este capabil sa proceseze volume mari de date, testarea de
performan este o etap destul de important a procesului de testare. Ca parte a acestei etape
trebuie verificat c noile implementri au un impact pozitiv asupra performanei, iar n unele
aspecte, indicatorii de performan nu s-au inrutait. Deasemenea, n cazul volumului mare de
date parametrii de performan nu trebuie s descreasc. Specificaiile de performan sunt
asigurate de ctre echipa de proiectare. Pe parcursul testrii de performan trebuie de
indentificat numrul maxim de tranzacii ce poate fi procesat de ctre client i trebuie estimat
volumul de date procesate zilnic.
Pe parcursul testrii de integritate echipa de testare trebuie s se asigure c la un volum mare de
date procesate nu sunt pierderi sau corupte, datele sunt procesate corespunztor, iar acestea pot fi
accesate cu uurin prin intermediul intefeei de utilizator.
Ca parte din testarea regresiv sunt incluse verificarea defectelor gsite, completarea testrii
finale, i verificarea succint repetat a tuturor ariilor implementate sau celor supuse
modificrilor. Pe parcursul acestei etape trebuie s fie asigurat c toate defectele gsite n timpul
testrii au fost fixate, identificarea ariilor afectate sau supuse unui risc cauzate de schimbri
recente ale codului.
Potenialele riscuri care pot aprea n timpul testrii regresive sunt: fixarea unor defecte
poate genera alte probleme neprevzute, deacea procesului de fixare trebuie acordat o atenie
deosebit, fiind una din etapele finale ale testrii, implicit a apropierii de data lansrii produsului
timpul rmas ar putea fi insuficient pentru a acoperi toate ariile cu testarea final.
Ultima etap a planului de testare poate fi definit ca testarea de migrare i de upgrade. Aceasta
presupune posibilitatea ca versiunile anterioare de produs pot fi portate la noua versiune fr ca
23

funcionalitatea s fie afectat. Deasemenea procesul de testare a migrrii presupune verificarea

datelor deja existene n baza de date dac sunt eligibile pentru versiunea recent lansat de
produs. Pentru a migra datele, echipa de dezvoltare ofer o suit de instrumente pentru aceasta.
Rolul echipei de testare const n a verifica dac aceste instrumente funcioneaz corespunztor.
Migrarea trebuie s fie suportat n mediile descrise n etapa testrii de sistem. Ca i la orice
etap de testare exist unele riscuri cum ar fi :
1.
2.
3.
4.

Indentificarea ntrziat a datelor care trebuie migrate;

Migrarea unui volum mare de date (mii/milione de tranzactii);
Scenariile din productie pot s nu fie acoperite pe parcursul testrii;
Mediile din producie - alte probleme pot fi cauzate din cauza datelor deja existene n
baza de date a clientului.

Pentru ca planul de testare s fie executat cu succes este necesar de a distribui eficient resursele
existente.

2.2Tehnici utilizate n cadrul testrii

n orice proiect sunt utilizate anumite tehnici de testare, alese n dependen de componentele i
domeniul ce urmeaz a fi supus testrii. Vom analiza urmtoarele tehnici care au fost folosite n
cadrul testrii automate a proiectului Enrollment Management.
Tehnicile de testare pot fi clasificate din punct de vedere a mai multor criterii. Vom examina
unele din aceste criterii.
1. Tehnici bazate pe echipa de testare :
a. Testarea de utilizator - acest tip de testare are loc cu categoria de persoane care
vor utiliza produsul dat. Testarea de utilizator poate fi efectuat oricnd pe parcusul
dezvoltrii produsului;
b. Testarea Alpfa se efectueaz de ctre ntreaga echip de testare;
c. Testarea Beta tipul de testare utilizeaz testeri care nu fac parte din organizaie
dar sunt membri a grupului int de utilizare a produsului;
d. Bug Bushes - acest tip de testare utilizeaz programatori, secretari i oricine este
disponibil, procedura de testare dureaz o jumtate de zi i se efectueaz cnd
produsul este gata de a fi realizat;
e. Testarea n perechi - cte doi testeri lucreaz mpreun pentru a gsi defectele.

24

2. Tehnici bazate pe aria de acoperire, unele din aceste tehnici utilizate n cadrul companiei
pot fi :
a. Testarea de funciune - se testeaz fiecare funcie n parte pn la momentul cnd
testerul poate confirma c aceasta lucreaz corect. Testarea white-box de obicei
numit testarea unitar se concentrez pe funciile ce le putem vedea n cod.
Testarea block-box se focuseaz pe comenzi, lucruri pe care utilizatorul le poate
gsi sau selecta. Este destul de important de efectuat testarea funcional nainte
de a realiza alte teste mai complexe. ntr-un test complex prima func ie defectat
stopeaz i blocheaz gsirea altor funcii care sunt deasemnea defectate. De
aceea este important de a testa fiecare funcie n parte individual. Pentru a reduce
att costul ct i micora probabilitatea scprii mai multor defecte.
b. Testarea de integrare - testeaz cteva funcii mpreun pentru a analiza cum
acestea lucreaz n grup.
c. Menu tur - acest tip de testare permite exploatarea tuturor meniurilor i
ferestrelor de dialog a interfeei de utilizator, prin accesarea oricrui buton i
combinaii posibile. n cadrul proiectului, acest tip de tehnic a fost utilizat la
crearea unui test automat pentru verificarea paginii web Accounts a aplica iei
ENR (vezi fig.2.3). Prin rularea acestui test automat, se acceseaz pagina
Accounts, selectnd un anumit cont se verific corectitudinea datelor prezentate
i funcionarea corect a fiecrui buton. n cazul funcionrii incorecte a
butoanelor, testul automat nu trece cu succes, aruncnd erorile ce determin
urmtoarele defecte aprute sau scpate n program.

Figura 2.3 Pagina web Accounts

d. Analiza claselor de echivalen - O clas de echivalen reprezint un set de
valori pentru o variabil

pe care utilizatorul o consider

25

echivalent. Spre

exemplu cazurile de test sunt echivalente dac testerul consider c ele verific
aceleai lucruri. Din aceasta rezult dac unul din cazurile de test prinde un defect
celelalte deasemenea vor gsi defecte. i dac unul din acestea nu gsete
problema celelalte cel mai probabil nu vor gasi nici ele. Odat ce testerul a gsit o
clas de echivalen el testeaz doar unul sau dou cazuri. n cazul proiectului au
fost adaugate numeroase teste automate ce verific diverse scenarii detaliate. Un
exemplu de cazuri de test echivalente putem urmri n figura 2.4. Scenariul de
baz const n adugarea/expirarea/reintegrarea unei polie de asigurare a unui
membru. n cazul dat diferena dintre scenarii const doar n adugarea sau
expirarea poliei n zile diferite, modificarea datelor personale n fiecare scenariu
n parte. n final, rezultatul cazurilor de test au drept scop verificarea
corectitudinii reintegrrii poliei de asigurri. Deci putem spune c aceste cazuri
de test sunt echivalente.

Figura 2.4 Suita de teste echivalente

3. Tehnici bazate pe intuiia i experiena programatorului:
Testarea Add- Hoc - cazurile de test se realizeaz pe baza experienei, cunotinelor i

intuiiei programatorilor cu alte programe similare;

Testarea de explorare - reprezint un tip de nvare continu, ce reprezint c testele se

implementeaz, execut, modific n mod dinamic.

4. Tehnici bazate pe specificaii:
26

Tabel de decizii - reprezint relaii logice ntre datele de intrare i cele de ieire (condiii

i aciuni), deci cazurile de test reprezint orice combinaie posibil de intrri i ieiri;
Testarea din specificaii formale - specificaiile oficiale furnizeaz derivarea automat a
cazurilor de testare funcional i o ieire de referin pentru verificarea rezultatelor

testelor;
Testarea aleatoare - punctele aleatorii se aleg din datele de intrare care sunt deja

cunoscute, astfel cazurile de test sunt bazate pe nite date aleator alese.
5. Tehnici bazate pe cod:
Criteriul bazat pe fluxul de control - se determin procesul de testare logic al
expresiilor (deciziilor) ntr-un program. Deciziile se consider funcii logice a unor
condiii logice elementare. Definiia fiecrei criterii a fluxului de control include o cerin
de acoperire ca o parte component: fiecare cerin n program se execut cel puin o
dat. Criteriul fluxului de control este considerat baza unui program i este util pentru

testarea white-box.
Modele de referin pentru testarea codului controlul structurii unui program este

reprezentat sub form grafic.

6. Tehnici bazate pe greeli:
Ghicitul erorilor - cazurile de test sunt executate de ctre echipa de programatori
ncercnd s gseasc cele mai frecvente erori ce apar n program. n aceste situaii,
programatorii compar greelile gsite anterior n proiectele precedente cu acele gsite la

moment, i analizndu-le pot gsi componenta sau partea de cod ce a fost afectat.
Testarea mutaional - Mutant reprezint o versiune modificat a unui program pe
parcursul testrii. Acesta difer de programul iniial prin schimbri sintactice. Fiecare caz
de test exerseaz ambele tipuri de programe, att cele originale, ct i cele mutante.
Cazurile de test sunt dezvoltate pentru a distruge programele mutante ce au rmas

neafectate.
7. Tehnici bazate pe utilizare:
Profil operaional - n cadrul acestei tehnici se poate prognoza fiabilitatea programului
n urma analizei rezultatelor testelor.
8. Tehnici bazate pe natura aplicaiei:
Testarea orientat pe obiect - ca parte din aceast tehnic de testare se gsete poziia
elementului n test ce nu corespunde cu specificaiile. Scopul acestei tehnici const n
selectarea, structurarea i organizarea testelor n aa mod de a gsi erori ct de devreme e
posibil.
27

Testarea bazat pe componente - tehnica e bazat pe ideea crerii cazurilor de test din
componente de testare reutilizabile. O component de test reprezint o unitate

independent i reutilizabil de test, ce furnizeaz servicii prin intermediul interfeei sale.

Testarea Web - reprezint testarea prin intermediul internetului i scris n limbajul
HTML, consolidat prin scripturi. Testul este localizat ca o pagin web pe serverul
testerului, unde aceasta poate fi accesat de ctre calculatorul clientului. Browserul
clientului afieaz testul, persoana ce execut testul l completeaz i poate trimite

raspunsurile napoi la server, de unde testerul le poate descrca i nscrie.

Testarea GUI - procesul de testare a produsului care utilizeaz interfaa grafic de

utilizator, pentru a se asigura c acesta corespunde caietului de sarcini propus.

Testarea sistemelor n timp real - mai mult de o treime din resurele proiectului sunt
utilizate pentru testarea integrat i sistemele n timp real. Sistemele integrate necesit o
atenie deosebit ce trebuie acordat n timpul testrii. Testarea n timp real este definit
ca evaluarea sistemului la frecvena normal de funcionare, vitez i sincronizare.
Cazurile de test pot fi generate n mod offline sau online. Generarea cazurilor de test n
mod offline este deseori bazat pe un criteriu de acoperire a modelului, pe scopul testului
sau pe un model de eroare. Testarea online combin att generarea testului ct i
executarea acestuia. n cadrul aplicaiei ENR aceast tehnic se aplic pentru testarea
sistemului care este configurat asemenea unor condiii reale de utilizare (Benchmark).
Sunt create nite cazuri de utilizare asemenea celor prezente n producie. n baza acestor
se creaz fiiere cu anumite date de intrare. Acestea sunt procesate n sistemul configurat
cu parametrii clientului. Dup procesare, se colecteaz datele care informeaz dac
sistemul funcioneaz conform ateptrilor.

2.3Instrumente de testare
1. Selenium- suit de instrumente pentru automatizarea interfeelor web. Pn n present
acest instrument avanseaz n lumea testrii datorit suportului celor mai mari furnizori de
browser care i-au luat responsabilitatea de a face Selenium o parte nativ din browser-ul
lor. Este cunoscut pentru a excela n perioada de testare timpurie, n special le convine
testerilor ce scriu script-uri de testare n paralel cu dezvoltarea aplicaiilor sale, i folosesc
aceste script-uri pentru testarea regresiv.

28

Pe parcursul perioadei de testare, script-urile adugate n Selenium pot fi reutlizate. Dar,

daca aplicaia este supus unor schimbri permanente, unele din script-uri pot cdea.
Anume acest lucru cauzeaz confuzia testerilor n privina erorii aprute, nu se tie exact
cauza erorii, problema e n aplicaie sau un defect n scriptul de testare. n caz c aplica ia
se schimb de multe ori i este meninut de aceleai scripturi, pot aprea astfel de
probleme. Cu toate acestea, Selenium e axat doar pe aplicaii bazate pe web, de aceea
pentru a spori eficiena testrii, este nevoie i de alte instrumente de testare pentru
efectuarea testelor complete E2E pe sistemele enterprise.
2. Un alt instrument utilizat n cadrul testrii aplicaiei ENR este limbajul Groovy. Este
utilizat pentru platforma Java viznd mbuntirea productivitii printr-o sintax concis
i familiar. Se integreaz uor cu orice program Java, oferind aplicaiei o mulime de
caracterisitici, ca abilitile de scripting i programarea funcional. Dispune de o
bibliotec implicit foarte larg, cu majoritatea lucrurilor suplimentare de care avem
nevoie. Groovy este un limbaj de scripting dinamic i mai rapid pentru a scrie cod.
n calitate de framework de testare se utilizeaz Spock, a crui platform este Groovy.
Ceea ce l face s ias n eviden dintre alte frameworkuri de testare este expresivitatea
caeietului de sarcini DSL. Practic, specificaiile Spock sunt scrise ca ni te clase Groovy.
Cu toate acestea, specificaiile pot fi folosite i pentru a testa clase Java. Spock poate fi
utilizat pentru testarea unitar, testarea integrat i de comportament.
Pentru a crea distribuia automat de teste se folosete instrumentul Gradle, care suport
dependene ntr-un sistem de fiiere, dependente din repozitoriul Maven i poate face
sarcinile dependente unele de altele. Nu este nevoie de a construi o alt infrastructur
deoarece Gradle utilizeaz Maven i alte arhive. Acesta este programabil, dat fiind faptul
c sarcinile sunt scrise pe Groovysi pot fi refolosite. Flexibilitatea acestuia const n
posibilitatea crerii propriului proiect de configurare. Un alt avantaj de care dispune
Gradle este biblioteca larg de sarcini proprii. Gradle dispune de un limbaj specific
(DSL) bazat pe groovy, acesta ofer aplica ii declarative cu elemente ale limbajului
declarativ care uor pot fi utilizate n orice aplicaie. Aceste elemente ofer suport pentru
Java, Groovy, Web i proiecte Scala. Mai mult de att accest limbaj declarativ poate fi
extins. n interiorul unei distribuii gradle unitatea fundamental a activitaii de distribuii
este task-ul. Taskurile sunt nite colecii ale instruciunilor distribu iilor care le execut
29

gradle, taskurile gradle sunt primele obiecte clas disponibile ntr-un program. Taskurile
pot fi scrise de ctre utilizator, dar sunt i cteva implicite: de copiere, jar crearea
librariilor din fiierele surs, javaexec- ruleaz o clas java utiliznd methoda main().
Instrumentul de creare a distribuiilor este necesar de a fi organizat ntr-un format u or de
citit i interpretat. Formatul XML a fost o alegere uoara pentru crearea distribuiilor, i
este utilizat cu succes de mai bine de zece ani. Dezvoltatorii erau entuziasma i de noua
tehnologie, netiind c mai trziu citirea fiierelor mari va fi o problem. Cu toate acestea
un deceniu de experien au demonstrat c fiierele XML mari i complexe sunt uor de
citit doar de maini, nu i de oameni. Deasemnea structura XML strict ierarhic limiteaz
expresivitatea formatului. Este uor de a arta nite relaii in XML ,dar este greu de a
nelege paii de execuie a crerii distribuiei i accesul la date. Deci putem spune c
formatul XML este greit folosit pentru crearea unei distribuii. Prin compara ie noua
tehnologie de construire a distribuiilor Gradle, folosete pentru descrierea pailor de
execuie limbajul de programare Groovy. Acest limbaj este foarte popular n ecosistemul
Java, deaaceea construirea unei distribuii devine foarte simpl folosind Gradle+Groovy.
Pentru a distribui i testa aplicaia continuu se utilizeaz Jenkins, ce reprezint o
aplicaie care ruleaz pe mai multe platforme destinat integrrii i dezvoltrii continue i
contribuind la creterea productivitii procesului de testare. Acest instrument uureaz
posibilitatea de a integra schimbrile n proiect oferind posibilitatea de a ob ine mereu
cea mai nou distribuie. Poate fi integrat uor deasemenea cu un numr mare de tipuri de
testri i tehnici de dezvoltare. Posibilitile care ni le ofer Jenkins sunt:
1. Instalare rapid i uoar;
2. Configurare simpl;
3. Un ecosistem de plug-in bogat :
4. Flexibilitate unele pri ale Jenkins pot fi extinse i modificate oferind posibilitatea
de a crea noi plug-inuri.
Acesta este o punte ntre instrumentul de creare a distribuiilor (Maven, Ant, Gradle), sistemele
de control a versiunilor (SVN, GIT) i sistemul de stocare a distribu iilor (Sonatype Nexus). Prin
intermediul acestui instrument se poate uor de observat statisitici despre procesul de dezvoltare
a unui produs software. Sunt indicatori pe care Jenkins i pune la dispoziie i care descriu
procesul de dezvoltare. Numrul de defecte raportate, numrul de teste executate cu succes i
cele care au czut nsoite de informaia detaliat, Numrul de distribuii create cu succes - to i

30

aceti indicatori sunt folosii pentru luarea deciziilor n vederea mbuntirii procesului de
dezvoltare i testare.

2.4 Infrastructura ENR

Figura 2.6 Reprezentarea grafic a infrastructurii Enrollment Management

31

Edifecs Enrollment Mangment (ENR) reprezint o aplicaie ce utilizeaz resursele Edifecs n

vederea informatiilor polielor medicale i proceseaz tranzaciile electronice de la angajai i
companiile de asigurri. Folosind aplicaia Enrollment Management se reduce timpul n
adugarea noilor membri i renoirea detaliilor despre aceti membri. Adugarea polielor
medicale se efectueaz automat cu ajutorul acestei aplicaii care asigur pstrarea
confidenialitii informaiilor personale persoanelor ce au aplicat pentru un anumit program de
asigurare. Odat ce a nceput procesul de prelucrare a tranzaciilor electronice, acestea sunt
verificate conform unor standarde (GuideLines), validate, confirmate i trimise ctre repozitoriul
Edifecs. Funcionalitatea de procesare a tranzaciilor are loc mai ntii prin intermediul profilelor
XEngine Server, majoritatea acestor profile conin componente ale procesului enrolment
management i nu au nevoie de alte modificri dup ce au fost instalate. Unul din profilele
specifice ale aplicaiei (Referance Implementation Model -RIM) servete drept referin pentru
integrarea tuturor profilelor ENR n sistemul integru. La rndul su profilele con in rute XEngine
Server, care pot fi create i editate dup specifica ile cerute. Instrumentul pentru configurarea i
editarea rutelor este Edifecs Application Manager, care ofer o interfa de utilizator pentru
serverul XEngine Server i profilelor sale. Din punct de vedere funcional rutele sunt acele
componente ce proceseaz mesajele. Toate mesajele (messages) conin corpul (datele tranzac iei)
i proprietile (message header). Aceste proprieti sunt date de insoire a tranzaciei coninute n
mesajul corp (message body). Majoritatea proprietilor utilizate de ctre aplicaia ENR sunt
denumite cu prefixul EUO_. Rutele sunt asamblate din componente de rutare Standartd precum
i costumizate, care contribuie la manipularea att a proprietilor ct i a corpului mesajului,
componentele de rutare pot crea proprieti, asigna valori acestora i citirea lor. Acestea pot de
asemenea trimite/primi mesaje de la un fiier stocat pe disc, o coad JMS sau un Email.
Pentru mai multe detalii putem urmri urmtorul tabel care descrie entit ile de baz ce
particip n procesarea tranzaciilor electronice
Tabelul 2.1 Entitaile de baz a tranzaciilor electronice
Entitate

Descriere

Account

Descrie o entitate ce reprezint o organizaie

care este o surs de membri pentru planul de
asigurri medicale. Entitatea cuprinde grupuri
32

de angajatori, sindicate, companii de asigurri.

Message

Un mesaj reprezint un document business sau

un fiier care este procesat prin intermediul
XEngine Server.

message header

Capul mesajului reprezint segmental care

indentific unic nceputul unui mesaj. El se
genereaz separat de mesajul corp i are
extensia fisierului .properties

message body

Mesajul corp reprezint un set de segmente ce

constituie datele sau cuprinsul, i nu cuprinde
mesajul cap.

message property

Proprietatea mesajului este perechea de numevaloare care se conine n mesajul cap.

Proprietile pot afecta calea de procesare a
mesajelor.

Policy Unit

Polia unitar reprezint o entitate de afaceri

pentru toate activitile tranzacionale. Aceasta
cuprinde informaia curent despre deintorul
poliei i membrii acesteia.

Profile

Un profil Xengine Server conine ruta i

configuraiile. Profilele pot fi utilizate n
scopul de a organiza rutele n dependen de
funcionalitate, exporta/ importa rutele pentru
instalare distribuit.

RIM

Profilul Referance Implementation Model

prezint o simpl implementare ce ilustreaz
utilizarea

ENR

rezolvarea

scenariilor

business. Acesta include procesele XEngine

Server, proprietile guidelines din Enrollment
Management, crearea i utlizarea corelaiei
dintre identificatori i proprietile implicite,
33

doumente

tracking

info

ce

rspund

de

modificarea statutului i dispoziia tranzaciei

procesate, i raportarea de erori i evenimente
aprute pe parcursul procesrii.
Route

O rut reprezint o reprezentare grafic a

proceselor XEngine Server. Rutele pot fi create
i

editate

intermediul

utiliznd

Route

aplicaiei

Edifecs

Editor

prin

Application

Manager.
Content Packs

Un pachet de coninut reprezint totalitatea

schemelor,

guidelines

proprieti

ale

aplicaiei ENR. Acesta conine un set de

definiii

prestabilite,

informaii.

Pachetul

utilizatorului

configuraii
de

coninut

urmreasc

alte

permite

procesarea

tranzaciilor comerciale de diferite tipuri.

Fiind o aplicaie de procesare a tranzaciilor electronice pot fi descrise cteva abiliti de baz pe
care le suport:
Tabelul 2.2 Abiliti de baz in cadrul tranzaciilor electronice
Abilitatea

Procesul

Abilitatea de a suporta tranzaciile electronice Mapele standarde sunt o parte din ENR,
n orice format (834EDI, ECF, PPR).

acestea au rolul de a converti informaia dintrun iniial format n altul standartizat ECF
(Edifecs

Common

Format).

Mapele

costumizate care sunt create n dependen de

cerine pot deasemnea converti transmisiunile
eletronice n Formatul ECF. Astfel abilitatea
de procesare a tranzaciilor eletronice n orice
format asigur consistena procesrii datelor.
34

Aceasta reduce timpul de a nrola noi membri

a

programului

de

asigurri

medicale

automatizat.
Abilitatea de a grupa informaiile electronice O unitate familiar reprezint deintorul
n uniti familiare

poliei i ali membri ai familiei acestuia. Cu

toatea acestea o unitate familiar poate avea
doar un deintor. n termenii aplicaiei ENR
o familie unitar reprezint o poli unitar
(Policy Unit).

Crearea de entiti business care conin Exist un numr de entiti tranzacionale

informaii pe care utilizatorul le poate create pe parcursul ntregului ciclu de via a
vizualiza la

fiecare etap a

procesrii procesrii

tranzaciei electronice

tranzaciilor.

Fiecare

entitate

business corespunde unei etape de procesare.

Utilizatorul poate vizualiza o entitate astfel
determinnd statutul unei nregistrri n
procesul de adugare a tranzaciei eletronice.
De ex: dac o poli unitar are statutul
Channel Distribution Pend i dispoziia In
Progress, utilizatorul poate determina c pe
parcursul fazei iniiale de procesare s-a
produs o excepie care ateapt revizuirea
acesteia

aplicarea

corespunztoare

acelei

unei
etape.

rezoluii
Odat

ce

excepia este rezolvat i inchis statutul i

dispoziia

poliei

sunt

schimbate

corespunztor urmtoarei etape de procesare.

Abilitatea de a compara schimbrile aplicate Un exemplu de anomalie de schimbare poate
n

faza iniial

cu Polia

unitar

din fi descris n urmtorul exemplu: La polia

Repozitoriul Edifecs, polia deja existent n Unitar deja Existent in Repozitoriul de

system i identificarea anomaliilor aprute.

membri se mai adaug un membru activ dar

deja existent in Repozitoriu. Aceast anomalie
35

este depistat prin intermediul unei Excepii

care conine informaie despre problema
aprut.
Abilitatea de a specifica polia unitar

i n dependen de configurarea sistemului,

membrii abseni

dac o poli unitar sau un membru nu sunt

prezeni

corespunztoare

tranzacia

de

acestei

polite,

schimbri
automat

membri poliei sunt exclui.Aceast anomalie

este identificat deasemenea prin apariia unei
excepii n list.
Abilitatea de a procesa o transmisiune Audit.

ENR poate procesa transmisiuni audit i

compara fiecare poli unitar deja existent
cu acei membri ce conin discrepane.

Abilitatea de a valida o tranzacie prin Regulile de validare standarde sunt o parte

intermediul regulilor Business prestabilite.

din ENR i alte reguli costumizate pot fi

create, pentru a asigura procesarea corect a
datelor

electronice

sistemul

poate

fi

configurat de aciona autoamat n cazul unor

erori ce sunt detectate de ctre regulile de
validare. Prin generarea unei excepii ce
conine infomaii despre eroarea de validare.
Abilitatea de a detecta procentajul nalt de De ex: Dac n sistem este configurat c
aciuni

adiionale

aplicate

transmisiunii procentajul lunar de procesare a polielor

eletronice i detectarea acestora prin excepii unitare ntr-o transmisiune nu trebuie s

la nivel de transmisiune.

depeasc 5% dar transmisiunea conine un

numr de polie unitare ce depete aceast
cifr se genereaz o excepie la nivel de
transmisiune

care

oprete

procesarea

incorect n etapa urmtoare, ateptnd din

partea utilizatorului o revizuire i aplicarea
unei rezoluii din cele existente, (oprete
36

procesarea tranzaciei definitive, purcede

procesarea la urmtoarea etap, corectez
eroarea aprut).
Abiliti de cutare i filtrare

Aplicaia ENR distribuie un numr mare de

opiuni de cutare i filtrare a entitilor
business sau excepiilor utiliznd unul sau mai
multe criterii de utilizare. Utilizatorul poate
deasemenea s i creeze cutri costumizate
specifice fiecrui client dup necesiti.

Abilitatea de a stoca Excepii

Excepiile sunt generate atunci cnd este

detectat o problem pe parcursul procesrii
tranzaciei eletronice sau cnd o regul de
validare este nclcat. Cnd aceasta este
depistat se genereaza Excepia i este plasat
n stocul de excepii pentru revizuire i
intervenii.

Abilitatea de a monitoriza modulul de Modulul Accounts al ENR ofer posibilitatea

utilizatori ai sistemului.

de

vizualizare

utilizatorilor

cureni,

permind accesul rapid la sarcinile deschise i

la transmisiunile recent procesate.

O distribuie ENR este o colecie de fiiere cod-surs compilate, fisiere de configurare,

documentaie, profile XES, schema bazei de date (CP), mape, guidelines, i alte resurse
indispensabile pentru aplicaie.
Toate aceste resurse sunt mpachetate ntr-o arhiv de ctre un instrument de creare automat a
distribuiilor. Distribuia ENR este creat la cererea utilizatorului prin intermediul instrumentului
de integrare continu Jenkins. O dat ajuns la un numr de schimbri a fi ierelor din proiectul
surs este pornit crearea unei distribuii. n cadrul acestui proces sunt compilate fi ierele surs,
sunt executate testele unitare ale echipei de dezvoltare. Procesul de mpachetare a distribu iei
decurge mai multe etape, dac fiecare din ele s-a executat cu suces ntr-un final vom ob ine
37

distribuia sub forma unei arhive n care vom avea fiierul cu documentaie, fiierul cu schema
bazei de date, fiierul de configurare a aplicaiei i artifactul cu resusrse, (figura 2.2) care poate fi
folosit la instalarea i ulterior folosirea aplicaiei ENR. Fiecare versiune de distribu ie este
stocat ntr-un repozitoriu unic, de unde poate fi descrcat pentru utilizare.

Figura 2.2 Distribuia ENR

Avind creat distribuia, care este descrcat automat prin execuia taskului gradle enrUnPack
se poate parcurge la urmtoarea etap de configurare i instalare a aplicaiei ENR propriu-zis.
Instalarea aplicaiei reprezint procesul de pregtire a programului pentru execuie.
1. Fiierul de proprieti a distribuiei config.properties se configureaz automat prin
apelarea taskului enrPrepare. Acest task preia valorile configurate pentru instalare i le
nlocuiete pe cele implicite din distribuie.
Se configureaz n dependen de mai muli factori: Baza de Date utilizat SQL/Oracle,
profilele care vor fi instalate, etc.
2. O alt component indispensabil pentru rularea aplicaiei ENR sunt ContentPacks, prin
intermediul crora se desfoara schema bazei de date. Dac au fost gsite schimbri
atunci se va apela taskul enrdeployCP, care n baza unui algoritm prestabilit va
transforma fisierele XML n schema final. Schema bazei de date conine entitile
business ale aplicaiei ENR, este descris reprezentarea vizual a fiecrei entiti.
Deasemenea, este descris modul de vizualizare a datelor prin definirea criteriilor de
filtrare i a proprietilor. Acest task va aduna resursele necesare pentru ContentPacks i
le va expedia ctre instrumentul extern care va efectua instalarea. Schema bazei de date
conine entitile business ale aplicaiei ENR, este descris reprezentarea vizual a
38

fiecrei entiti. Deasemenea, este descris modul de vizualizare a datelor prin definirea
criteriilor de filtrare i a proprietilor.
3. Dac etapele precedente au fost trecute cu succes : configurarea aplicaiei, determinarea
schemei bazei de date, se poate efectua instalarea aplicaiei. Prin instalarea aplicaiei se
intelege extragerea tuturor resurselor n locaia aleas pentru instalare. Deasemenea sunt
rulate instrumente de sistem care configureaz aplicaia ENR pentru utilizare: importarea
partenerilor, importarea exepiilor configurate, importarea configurrilor pentru
VIPSecurity i configurarea aplicaiei Web. Pentru a instala automat s-a creat taskul
gradle installENR. Mai jos este reprezentat secvena de cod:
task installENR(description: "Installs latest ENR no matter what", group: "enr",
dependsOn: [deployEnrCp, enrUnpack, enrPrepare, killBuildBlockers,
enrInstall, replaceFFTemplate,
enrPartners, changeProperties, enrStart
]) {
tmSyncTpm.mustRunAfter tmStartSmService
enrClean.mustRunAfter killBuildBlockers
enrInstall.mustRunAfter tmSyncTpm
enrInstall.mustRunAfter deployEnrCp
changeProperties.mustRunAfter enrInstall
replaceFFTemplate.mustRunAfter enrInstall
customAccounts.mustRunAfter enrPartners
enrStart.mustRunAfter replaceFFTemplate
enrStart.mustRunAfter changeProperties}

4. Pentru ca aplicaia s fie funcional i s fie posibil procesarea fiierelor este necesar de
a porni toate serviciile aplicaiei. Printre serviciile aplicaiei se enumer serviciile
profilelor ENR, serviciul aplicaiei Web, i alte servicii adiionale: serviciul de cutare, de
arhivare, serviciul Tracking Info - prin intermediul cruia se aplic schimbrile asupra
entitilor din baza de date. Pornirea serviciilor se execut prin intermediul taskului
startEnrServices, prin intermediul cruia se incearc startarea fiecrui serviciu
enumerat. Acest task execut comanda de startare, ateapt un timp de startare a fiecrui
serviciu, iar dup expirarea acestuia se verific daca serviciul a fost pornit cu succes.
Pentru a procesa fisierele avem nevoie de parteneri, care se afl n fiierul enrPartners.
Importul acestora presupune ncrcarea n sistem a proprietilor despre partenerii care
folosesc aplicaia ENR. n producie aceasta se execut manual prin executarea comenzii
de importare a partenerilor. n cadrul proiectului de testare pentru a eficientiza i exclude
factorul uman a fost creat un task automat gradle importPartners care efectueaza
aceast operatiune.
39

Testarea iniial a distribuiei

Pentru a verifica daca aplicaia i toi parametrii acesteia au fost instalai cu succes se
apeleaz la testul BVT care reprezint un complex de scenarii de baz ce urmeaz a fi
rulate n cadrul fiecrei distribuii noi create. Acestea verific dac distribuia este
testabil nainte de a o elibera ctre echipa de testare pentru alte teste suplimentare. De
obicei, n cadrul oricrei aplicaii, testul BVT este automatizat. n cazul n care BVT
eueaz, distribuia este supus retestrii de ctre echipa de programatori pentru a fixa
erorile depistate. Avantajele acestui test const n salvarea efortului echipei de testare de a
verifica ntreaga funcionalitate a produsului, n cazul c acesta conine defecte majore
sau critice. Timpul estimat de rulare a unui test BVT nu dureaza mai mult de 30 min. n
momentul n care testarea BVT trece cu success (figura ), se poate parcurge la
urmtoarele scenarii de testare suplimentar.

Figura 2.3 Rezultatul rulrii testului BVT

Tipuri de testare
Dup efectuarea testrii senariilor de baz asupra aplicaiei, sistemul este supus testrii de
acceptan. Prin intermediul testrii de aceptan se evalueaz conformitatea sistemului
cu cerinele consumatorului i acceptabilitatea acestuia pentru livrare. Testele de
acceptan se creeaz pe baza la User Stories- care prezinta descrierea succint a
cerinelor consumatorului, o informaie suficient pentru ca programatorii s-i estimeze
efortul n punerea n aplicare a cerinelor cerute. Scenariile sunt specificate de ctre client
pentru testare, n momentul cnd a fost definit corect un User Story. Pe baza unui user
story pot fi create una sau mai multe teste de acceptan, n dependen de complexitatea
funcionalitii. n cadrul aplicaiei ENR, testele de acceptan sunt automatizate,
deoarece acestea trebuie rulate de multe ori, iar rezultatul rulrii acestora este publicat
echipei de testare, a crei responsabilitate este de a rezolva testele euate la fiecare
40

iteraie. Acestea sunt grupate dup mai multe criterii: n funcie de componenta testat,
tipul fiierelor procesate, etc. Pentru nelegerea modului de funcionare, vom ncerca s
analizm un exemplu de test: Scenariu de reactivare a unei polie medicale
Scenariul const n parcurgerea mai multor etape:

Pregtirea parametrilor de executare a testului

class Scenario15_Reinstatement_SubscriberOnly extends AcceptanceScenario {
@Shared
def testcaseFolder = findFile('/testcases/acceptance/ENR_84/US_74673')
@Shared
def prefix = generator.generateString(3) + '-' + uploader.randomSuffix(6)
@Shared
def testFolder = new File(testcaseFolder, 'Scenario1')
@Shared
def datFileAdd = new File(testFolder, 'transmission/Add.dat')
@Shared
def datFileTerm = new File(testFolder, 'transmission/Term.dat')
@Shared
def datFileReinstate= new File(testFolder,
'transmission/REINSTATEMENT15.dat')
@Shared
def datasetFile = new File(testFolder, 'expected/DbUnit.xml')

Procesarea fiierului care adaug o poli medical

def '1. Process Add file'() {
def desiredStatus = 'Channel Distribution'
log.debug "The file prefix is:$prefix"
when:
uploadEnrDat(map, prefix, datFileAdd)
then:
desiredStatus == check.transmissionActivityState(desiredStatus)}

Procesarea unui fiier ce determin expirarea poliei medicale

def ' Process Term file'() {
def desiredStatus = 'Channel Distribution'
log.debug "The file prefix is:$prefix"
when:
uploadEnrDat(map, prefix, datFileTerm)
then:
desiredStatus == check.transmissionActivityState(desiredStatus)
}

Procesarea fiierului care reactiveaz polia medical.

def ' Process Reinstatement file'() {
def desiredStatus = 'Channel Delivery'
log.debug "The file prefix is:$prefix"

41

when:
uploadEnrDat(map, prefix, datFileReinstate)
then:
desiredStatus == check.transmissionActivityState(desiredStatus)
}

Verificarea datelor ateptate, care sunt nregistrate ntr-un fiier xml- DbUnit, cu cele
curente din baza de date.
def 'Test all expected data in table #table should be present'() {
def status = compareDatasets(prefix, selectsMap, datasetFile, table)
expect:
status
where:
table << [
'enrmember',
'enrpolicyunit',
'enrcoverage', ] }

Putem observa etapele rulrii acestui test n figura 2.5:

Figura 2.5 Etapele rulrii scenariului de reactivare a unei polite medicale

n cadrul aplicaiei, o alt categorie de teste ce au fost automatizate sunt testele bazate pe
specificaiile maprii, care constituie din 2 pri, generarea fiierelor i rularea acestora.
Testele sunt generate doar o dat, iar testarea maprii acestora se execut de fiecare dat cnd
sunt aplicate careva schimbri.
nainte de a crea testele, este nevoie de luat cunotin cu specifica iile maprii. Scriptul
curent accept fiiere Excel, salvate n formatul XML. Mai nti este nevoie de deshis
specificaiile maprii n formatul Excel. Cazurile de test care urmeaz s fie testate sunt deja

42

incluse n suita de teste mpreun cu specifica ia acestora i transformate n formatul XML.

n cazul cnd specificaiile sunt supuse unor schimbri acestea trebuie indicate n script.
Generarea fiierului conine un test cu structura:
1. Definirea variabilelor include declararea directoriilor unde se afl fiierele de intrare i
mapele propriu-zise, condiiile de mapare i rezultatele ateptate.
2. Etapele de generare se parseaz toat informaia din fiierul de specifica ii ntr-un
format accesibil pentru testare. Apoi se parseaz fiierul de intrare n format XData. Se
genereaz fiierele de iniializare conform unui fiier model, dup care se ruleaz fiierul
test data generat.
Rularea fiierelor de teste presupune verificarea fiierului de intrare cu rezultatele ateptate
n fiierul de control.
Exemplu de generare a sursei i fiierului de control a testului:
-

class GenerateTestFiles834toEEHCFMap extends Specification {

def testDir = "C:\\TestData\\ATC1"
def "Generate test source and expected results"() {
setup:

Declararea condiiilor de intrare

ArrayList<MapSpec> inputConditions = [new MapSpec(sourceNodeLoop: "2750",

sourceNodeSegment: "DTP", sourceNodeIndex: 3, possibleValues:
["20150701","20150701-20150702"], conditionSegment: "DTP", conditionMark: "=",
conditionValues: ["D8","RD8"], conditionIndex:2) ]

Declararea rezultatelor ateptate

def inputExpected = ["PolicyUnit/\${Member}/Coverage/RelatedProviders/\$

{ProvRole}/Maintenance/ActionType":["2":"change", "1":"add","rx":"replace"],
"PolicyUnit/\$
{Member}/Coverage/IdentificationCard/Maintenance/ActionType":["2":"change",
"1":"add","rx":"replace"],
"PolicyUnit/\${Member}/Maintenance/ActionType/Value":
["2":"change", "1":"add","rx":"replace"]]
SpecColumnDescription columns = new SpecColumnDescription(condtionColumn: 14,
possibleValuesColumn: 12, pathColumn: 15, expectedValueColumn: 16, loopColumn: 2,
segmentColumn: 3, compositeColumn: 4, indexColumn: 5)

Declararea variabilelor

def inputExpected = ["PolicyUnit/\${Member}/Coverage/RelatedProviders/\$

{ProvRole}/Maintenance/ActionType":["2":"change", "1":"add","rx":"replace"],
"PolicyUnit/\$
{Member}/Coverage/IdentificationCard/Maintenance/ActionType":["2":"change",
"1":"add","rx":"replace"],
"PolicyUnit/\${Member}/Maintenance/ActionType/Value":
["2":"change", "1":"add","rx":"replace"]]

43

SpecColumnDescription columns = new SpecColumnDescription(condtionColumn: 14,

possibleValuesColumn: 12, pathColumn: 15, expectedValueColumn: 16, loopColumn: 2,
segmentColumn: 3, compositeColumn: 4, indexColumn: 5)

Declararea fiierului de intrare

def sourceData = new
File(getClass().getResource("/834FileTemplate.dat").getPath());

Declararea specificaiei mapei

def mapSpecFile = new

File(getClass().getResource("/FS_834X220A1_EEHCF.xml").getPath())

Crearea fiierului cu rezultatele ateptate

XEActions xeActions = new XEActions()

String xdata = xeActions.nativetoXData(sourceData)
expectedResults = XMLTool.populateSourceValuesEDI(expectedResults, xdata, true)
XMLTool.saveSourceTemplateEDI(expectedResults,xdata,sourceData.getParentFile().absolut
ePath + "/tmp_xml.xml", inputConditions)

Crearea fiierului model

String template = xeActions.xDataToNative(new File

(sourceData.getParentFile().absolutePath + "/tmp_xml.xml").text)
FileGenerator fg = new FileGenerator(testDir, template, expectedResults,
inputConditions, inputExpected, pathVariables, ignoreList)
fg.generateTestData()}}

Din punct de vedere al utilizatorului, interfaa reprezint modul prezentrii unui software
n faa calculatorului. [1] De aceea este important ca produsul realizat s aib o interfa
user- friendly. Pentru mbuntirea modului de testare a interfeei de utilizator, n cadrul
proiectului au fost elaborate un ir de teste automate, care acoper funcionalitatea de baz
n verificarea interfeei.
Testele au fost adugate n baza modulului nou, recent adugat: modulul Accounts, care
prezint totalitatea utilizatorilor adugai mpreun cu poliele procesate corespunztor
fiecrui utilizator n parte. Automatizarea testelor UI acoper o verificare de 80% din
funcionalitatea de baz. n modelul de test de mai jos se va putea urmri verificarea
corectitudinii unui utilizator adugat recent n modulul Accounts. (vezi Anexa 1)
- Generarea raporatelor prin Jenkins
Raportarea rezultatelor reprezint un mecanism de prezentare a strii produsului din
diferite unghiuri la un anumit moment de dezvoltare a acestuia. Orice raport generat
trebuie s conin destul informaie despre produsul testat astfel ca oricine vizualizndu-l
s se afle n poziia de a nelege produsul, scopul i starea curent a acestuia.
Formatul raportrii depinde de mai muli factori:
44

Starea testrii n cadrul procesului de dezvoltare a produsului;

Audiena la care se adreseaz ;
Transparena invocat n cadrul procesului de testare (Testarea White Box/Black Box);
Tipul testrii invocate: funcional, de performan, de acceptan, de ncrcare.
Aa cum se tie, testarea unui produs este un process anevoios i de durat, iar acesta
poate ocupa de la 20% pn la 50% din timpul alocat dezvoltrii.
Desigur, cu ct produsul este testat mai mult n timp, acesta va avea o calitate mai bun.
n aceste condiii, raportarea rezultatelor testelor constituie aproximativ 5-10% din efortul
alocat procesului de testare. Este oare suficient ca s comunicm clientului este bun sau
nu de utilizat? Nu neaprat. Clientul poate cere un set de informaii despre starea
produsului dezvoltat care i-ar fi utile: performana, platformele dependente, timpul de
via, costurile de ntreinere, etc.
Oferind informaii neprtinitoare despre produs i analiza detaliat ajut clientul s-i
creeze o imagine obiectiv despre produsul software.

Un raport detaliat aduce

transparen procesului de testare, astfel nct s fi luate cele mai bune decizii la fiecare
etap de dezvoltare. Orice reprezentare grafic a unui raport ajut la o n elegere mai
bun a informaiilor prezentate. Pentru a vizualiza rapoartele testelor din cadrul
proiectului Enrollment Management se folosesc cteva instrumente, printre care se
enumer i Jenkins. Acesta are abilitatea ca dup rularea testelor s creeze rapoarte
succinte despre rata de success a execuiei testelor (vezi fig. 2.6) .

Figura 2.6 Raportul testelor ce au trecut cu succes i cele cu defecte

45

n raportul prezentat pot fi identificate testele care au trecut cu success i cele care au
defecte i urmeaz a fi fixate sau investigate. Deasemenea, raportul prezint evolu ia
-

testelor n timp. Se poate observa c numrul testelor adugate noi crete constant.
Msuri ntreprinse pentru mbuntirea procesului de testare automat
Analiznd rezultatele obinute n urma generrii rapoartelor trebuie ntreprinse cteva
msuri de fixare/mbuntire a procesului de testare automat. Vom analiza unele msuri
de mbuntire care au fost aplicate n cadrul proiectului ENR:
Implicarea membrilor n echipa de testare n procesul de automatizare fiecrui
membru al echipei i sunt alocate ore suplimentare pentru a automatiza scenarii
executate anterior manual. Acest exerciiu crete rata de automatizare a testelor.
Dac pin acum 1 an erau implicate doar cteva persoane n automatizare,
numrul testelor erau de orinul sutelor, odat cu implicarea tuturor membrilr

echipei acest numr a depit cifra de 2000.

Studierea noilor tehnologii de testare automata - domeniul TIC este unul inovator
n care schimbrile i noutile ptrund cel mai uor. Pentru a fi competitiv n

permanen trebuie urmrite ultimele tendine din domeniul testrii automate.

Acoperirea ariilor netestate automat pn n momentul de fa acest proces este
extrem de important pentru a avea toate ariile acoperite cu teste. Beneficiul cel
mai important n urma automatizrii ariilor ce au fost testate anterior manual este

simplificarea procesului de testare a regresiei.

Crearea scripturilor de testare i a celor care nlocoiesc pai manuali din procesul
testrii- aa cum a fost descris anterior, aceste scripturi sunt buc i de cod care pot
fi executate independent pentru a acoperi paii manuali. De ex: instalarea
automata a distribuiei, copeierea distribuiilor de pe maina de creare a
distribuiilor, crearea instrumentelor de generare a fiierelor, etc.

Raportarea rezultatelor ctre manager

Managerii de proiect care sunt responsabili de calitatea produsului sunt extremi de
interesai ca rapoartele trimise ctre ei s fie ct mai detaliate i s descrie cu exactitate
starea produsului care urmeaz a fi livrat. Aceasta este important pentru a estima ct mai
exact timpii rmai, limitrile i obstacolele aprute n procesul de testare. Rapoartele de
performan sunt importante pentru a putea fi comparate cu timpii ateptai. n urma
analizei tuturor informaiilor extrase din generarea rapoartelor, managerul creeaz un
46

raport Exit Criteria, ce cuprinde estimarea aproximativ a fiecrei arii testate din produsul
ce urmeaz a fi livrat. Se poate analiza urmtorul exemplu de raport n care sunt
enumerate ariile testate i importana fiecrei arii in diferite perioade. (fig 2.7) Culorile
delimitate exprim riscul ariei de a fi nefuncional:
culoarea roie- risc nalt, aceast arie a fost implementat mai tirziu, conine defecte
critice si este probabilitatea ca aria s nu fie livrat ctre client;
culoarea galben- risc mediu, este n process de testare, defecte au fost gsite, dar nu sunt
critice i se fixeaz pn la momentul livrarii, iar rata redeschiderii defectelor este mica;
culoarea verde- risc minor, aria este testat complet, iar defectele gsite au fost fixate i
nu prezint risc pentru livrarea produsului.

Exit Criteria ENR

8.5.0

Curren
t
4/8/20 4/1/20 3/25/20 3/18/20 2/26/20
16
16
16
16
5/4/20 16
16

Release Build
Bugs

HIGH

HIGH MEDIU
MEDIUM MEDIUM MEDIUM
M

HIGH

HIGH MEDIU
MEDIUM MEDIUM MEDIUM
M

LOW

MEDIU MEDIU
MEDIUM MEDIUM MEDIUM
M
M

HIX Flows
Add/Change/Term
Reconciliation

HIGH

HIGH

Group XML and SHOP

processing

HIGH

HIGH MEDIU
MEDIUM MEDIUM MEDIUM
M

Pre-Audit
Inbound Baseline
Response and
Baseline Outbound
PPR

HIGH

HIGH

HIGH

HIGH

MEDIU MEDIU MEDIU

MEDIUM MEDIUM MEDIUM
M
M
M
MEDIU MEDIU
MEDIU
M
M
MEDIUM MEDIUM MEDIUM
M
LOW

MEDIU MEDIU MEDIUM MEDIUM MEDIUM

47

Account Module

LOW

LOW

LOW

LOW

MEDIUM MEDIUM

NFR

MEDIU MEDIU MEDIU

MEDIUM MEDIUM MEDIUM
M
M
M

Performance

MEDIU
HIGH
M

HIGH

HIGH

HIGH

HIGH

Primary Customer

LOW

LOW

LOW

LOW

LOW

LOW

Reporting

LOW

LOW

LOW

LOW

LOW

LOW

Figura 2.7 Exemplu de raport Exit Criteria ENR 8.5.0

CAPITOLUL III. Analiza i evaluarea rezultatelor n cadrul procesului de

testare automat
3.1 Evaluarea eficienei economice
Muli manageri se ateapt ca testarea automat a produsului program s fie cea mai sigur
metod de testare, micornd problemele ce in de timpul testrii, minimiznd costurile testrii
raportarea defectelor, etc. Testarea automat poate avea impact pozitiv n multe domenii i sunt
nregistrate multe cazuri cu succes ce demonstreaz c testarea automat salveaz bani i rezolv
multe probleme de testare. Cu prere de ru sunt deasemenea i multe cazuri de insucces. Scopul
n acest capitol este de a urmri i de a nelege costurile i beneficiile testrii automate.
Pentru a planifica i implementa testarea automat trebuie s lum n calcul un numr de factori
care vor contribui la acest proces. Automatizarea schimb complexitatea testrii i organizarea ei
ncepind cu faza de planificare i finisnd cu cea de execuie. Aceasta are un impact major asupra
echipei de testare, cum ar fi: execuia taskurilor, abordarea testrii i chiar modul de func ionare
a produsului. Exist elemente tangibile i intangibile despre beneficiile i posibilit ile testrii
48

automate. Este foarte important de a nelege costul potenial i beneficiile nainte de a ncepe
procesul de testare automat. Impactul organizaional include elemente cum ar fi: cunotine
aprofundate de planificare i implementare a testelor automate, crearea instrumentelor de testare
automat i pregtirea platformelor pentru testare. Dezvoltarea i mentenana testrii automate
difer esenial de cea manual. Cunotinele aprofundate sunt necesare pentru a ine pasul cu
schimbrile procesului de testare. Echipa de testare trebuie s fie pregtit pentru a schimba
testele rapid. Judecnd realistic ateptrile, managementul trebuie s neleag care vor fi
beneficiile testrii automate pentru ca aceasta s fie cheia succesului. Se poate u or de justificat
costurile pentru procesul de testare dac managementul o vrea. Dar aceast justificare trebuie n
permanen corelat cu potenialele beneficii. Este foarte important s se memoreze c testarea
automat vine s mbunteasc ntreg procesul. Automatizarea este doar o metod prin care
putem mbunti considerabil ntreg ciclul de via al produsului. Testarea automat n sine, nu
aduce un beneficiu real companiei mai mult dect testarea manual.
Analiza costului beneficiilor furnizeaz informaie util despre modul cum se vor face investiiile
n testarea automat.
Exist multiple arii unde automatizarea poate furniza beneficii reale, iar n alte cazuri
dezavantaje. Totul depinde de implementarea procesului, de exemplu: testele automate pot
reduce o mulime de pai manuali sau de a executa acelai test de mai multe ori, dar de asemenea
testele automate pot genera muni de rezultate care vor fi greu de analizat i vor implica costuri
suplimentare, costuri care potenial vor fi mai mari dect o simpl rulare a unui test manual. De
obicei, informaia obinut n urma rulrii testelor automate este ascuns i doar n urma unei
analize se pot gsi realele defecte. De aceea, este important ca rapoartele testrii automate s fie
ct mai succinte i uor de analizat.
Tehnicile existente de msurare cum ar fi : acoperirea de cod poate fi utilizat pentru a estima
eficacitatatea testelor nainte i dup automatizare. Testele automate pot fi foarte efective
acoperind mult cod i supunnd vizibilitii produsul prin procesul de testare. Deasemenea,
testele automate ofer oportunitatea de a testa unele arii care sunt imposibil de testat manual, dar
metricile convenionale nu vor arta nici un beneficiu. Testele automate pot gsi defecte chiar i
n codul care este deja acoperit de teste prin generarea de multiple evenimente ntmpltoare.
Unele teste pot fi acoperite doar de testarea automat, de exemplu simularea logrii a mii de
49

utilizatori n aceli n acelasi timp. Testarea lipsei de memorie, verificarea strii variabilelor sau
monitorizarea unor apeluri neprevzute ctre produsul program pot fi fcute doar prin testele
automate.
Exist cteva arii unde managementul trebuie s-i inteasca ateptrile: costurile intangibile si
beneficiile, ateptrile beneficiilor nendeplinite, factorii comuni ale testrii manuale i automate
i impactul organizaional. Deasemenea, trebuie s fie ateni cum contabilizeaz i msoar
aceste lucruri. Costurile intangibile realistic sunt greu de evaluat, acolo unde pot fi msurate este
o variaie bun pe plan financiar. Exist probleme n a captura msurtori ct de mult se va
schimba pe parcursul automatizrii. Careva din costurile intangibile pot fi pozitive, altele
negative, acestea pot fi mixate pentru un rezultat ateptat.

Echipajul de testare

Dei costurile resurselor umane e uor de msurat, orice valoare n plus din partea calculatoarelor
este dificil de cuantificat.

mbuntirea profesionalismului testrii n organizaii

Aceasta deseori mrete motivarea, productivitatea, vine cu o disciplin nou i se aliniaz la

taskurile de automatizare cerute.

O imediat reducere a percepiei productivitii n organizaia de testare

Aceasta apare n timpul unei pauze de testare, echipa fiind ocupat cu crearea testelor automate,
crearea instrumentelor de testare i instalarea acestora.

Nu toi membrii echipei de testare sunt flexibili la schimbri

O parte a echipei va accepta schimbrile i va contribui deplin la crearea testelor, cealalt va

continua s testeze manal.

Schimbarea calitii testelor

Calitatea testelor poate s creasc sau poate s devin mai slab.

Numrul de iteraii de testare nainte de livrarea produsului

Automatizarea deseori determin o confirmare rapid a distribuiilor i ncurajeaz utilizarea lor.

50

Acoperirea cu teste

Poate fi mbuntit sau nrutit depinznd de eficacitatea testrii manuale, instrumentelor de

testare automat i testele automate n sine.
** Unele teste pot fi executate doar automatizat;
** O bun exploatare a testelor poate acoperi multe scenarii interesante;
** Testele manuale dificile pot ncuraja crearea de teste automate.
Ateptrile manageriale deseori sunt setate n urma participrii la diverse conferin e, lecturrii
crilor de specialitate care explic virtuile testrii automate. Unele informa ii sunt valide i
aplicabile, dar o mare parte descriu rezultate prea optimiste. Rezultatele ateptate depind de
modul de aplicare a tehnologiei de testare automat i de particularit ile proiectului. Pentru a
avea rezultatele ateptate, planificarea i realizarea testrii automate trebuie s respecte toate
cerinele pentru a obine rezultatul scontat. Setarea ateptrilor trebuie s fie bine coordonat cu
resursele existente, timpii de execuie pentru a evita un eec major. Putem descrie cteva dintre
ateptrile false:

Toate testele vor fi automatizate- uneori aceasta nu este practic, iar alte teste nu se merit

a fi automatizate din cauza costurilor mari;

Rasplata imediat a automatizrii- rezultate imediate pot aprea n cazul unor anumite
teste (teste unitare), dar de obicei, rezultatele apar mult mai trziu n urma investi iilor. Se
necesit mult munc de a crea multe teste automate i costurile vor scdea abia dup ce

testele se vor rula n mai multe iteraii;

Automatizarea testelor manuale existente;
Automatizarea cuprinztoarea a planului de test- instrumentele automate care analizeaz
codul surs nu acoper tot. Analiza automat deseori scap din vedere elemente

importante ale produsului program i posibile erori;

Utilizarea nregistrrilor pentru testele de regresie- aceasta se utilizeaz doar n cazul n

care produsul este att de stabil nct testele existente vor trebuie modificate pe parcurs;
Instrumentul de testare care se pliaz perfect cu produsul- multe instrumente automatizate
comerciale de testare i merit costurile i au o rat de rentoarcere a investi iilor foarte

rapid, ar aceasta este aplicabil doar anumitor tipuri de produs i organizaii;

Raportarea automatizat a defectelor (fr intervenia uman)- aceasta este dezastruos
pentru echipa de testare i cea de dezvoltare; problemele care apar sunt: duplicitatatea
51

raportrii erorilor, detectarea fals a erorilor,

erorile n cascad i erorile

nereproductibile. Analiza acestor rapoarte poate costa mai mult dect se presupune a fi
economisit.
Este util de remarcat cteva lucruri suplimentare pentru gestionarea ce prive te costul de
automatizare.

Cele mai multe dintre beneficii vin din testarea automat, din disciplina aplicat analizei
produsului testat i planificrii testrii. Aceste beneficii nu sunt direct legate de

automatizare, dar pot fi benefice pentru testele manuale.

Introducerea testrii automate de multe ori impulsioneaz profesionalismul echipei de
testare. Aceasta conduce ctre o testare mai bun, o colaborare mai strns cu echipa de

dezvoltare i expansiunea n multiple arii ale produsului testat.

De cele mai multe ori recuperarea investiiei din automatizare nu se va produce n timpul
testrii proiectului curent, de obicei, aceasta se ntmpl la testarea proiectelor urmtoare.

Aceasta poate dura luni, i chiar ani de la momentul investiiei.

Exist semnale semnificative c performana va scdea la momentul introducerii

automatizrii.
Scrierea de teste automate este mult mai dificil dect rularea unor teste manuale, aceasta
necesit cunotine noi i experiena testrii manuale. Nu to i membrii echipei de testare

sunt pregtii pentru asemenea schimbri.

Testele automate necesit adesea mentenana substanial. n unele cazuri ciclul de via
al testelor este de cteva iteraii i costurile lor pentru planificare i creare vor fi cu mult
mai mari dect simpla rulare a unor teste manuale.

3.2 Factorii de returnare a investiiilor

Returnarea investiiilor (ROI) de obicei este compus din divindele obinute ca rezultat din
investiiile fcute ntr-un anumit lucru. Dac se starteaz un proiect nou am putea calcula
valoarea de testare i s se mpart la costul de testare pentru a calcula randamentul. Cteodat
automatizarea este introdus dup ce o perioad lung produsul a fost testat manual. n acest caz
costul beneficiilor automatizrii paote fi privit ca o comparaie cu testarea manual.
Costurile financiare asociate cu testarea automat pot fi descrise ca costuri fixe i variabile.
Costurile fixe ale autoamtizrii sunt cele pentru echipament, instrumente, instruire i costuriel
care nu sunt afectate de numrul de teste create i rularea acestora. Costurile variabile pot cre te
52

sau scdea bazndu-se pe numarul de teste create i rulate. Vom analiza urmtorul tabel al
costurilor de testare (tab. 3.1)
Tabelul 3.1 Costurile de testare

Costuri fixe

Costuri variabile

Hardware (adugarea sau renoirea celor Proiectarea

cazurilor

de

testare

existente)

automatizare

Licenele instrumentelor de testare

Implementarea cazurilor de testare

Suportul intrumentelor de testare

Mentenana testelor

Determinarea echipamentului de testare

Execuia testelor

Mententana echipamentelor de testare

Analiza rapoartelor

Instrumente de scripting

Raportarea defectelor

pentru

Instrumente i licenele aplicaiilor de baz Salvarea execuiei testelor

(Windows, MSSQL, Tableau)
Instruirea personalului cu instrumentele de Crearea scripturilor de testare
testare

Careva din factori sunt comuni testrii manuale i celei automate. Aceti factori n general cresc
o dat cu introducerea testrii automate, dar aceast cretere va scdea costurile testrii manuale
astfel crendu-se un beneficiu. Putem distinge civa factori comuni:

Analiza SUT
Planul de test
Proiectarea testrii de baz
Raportarea defectelor
Managementul raportrii rezultatelor

Impactul financiar din automatizare poate fi calculat comparnd-l cu unul din cele dou
alternative: testarea manual sau netestarea. Prima alternativ este simpl de calculat pentru teste
spcifice dup ce a fost definit costurile factorilor implicai. Cu toate acestea, este foarte dificil
de identificat costurile factorilor care includ calcularea. Devine ns mai dificil cnd un test
automat nu face acelai lucru ca un test manual. De asemenea, sunt nite costuri i beneficii care
pot fi asociate numai cu testarea automat, n special comparnd eficacitatea testelor. Unele teste
automate au costuri asociate cu noi capabiliti de a exersa i analiza produsul program prin
53

intermediul testelor. Aici se compar costurile automatizrii cu beneficiile riscurilor reduse.

(informaia adiional care este luat din testele automate). Trebuie de avut grij cum se n elege,
cuantific i calific orice valoare asignat factorilor de testare. Daca beneficiul este obligatoriu,
atunci calcularea ROI nu este necesar, investiia este necesar oricum.
Trebuie de ales perioada de timp (t) n timpul cruia vor fi calculate beneficiile. n cadrul
proiectului ENR analizat a fost aleas perioada de 1 an i 4 ani. De obicei perioada se alege
bazndu-ne pe versiunea de lansare a produsului. innd cont c beneficiile vor fi vzute n
urmtoarea versiune este natural de a alege perioada pentru calcul o nou versiune de produs.
Calcularea returnrilor pentru ambele perioade poate fi privit ca beneficii pe termen scurt i
lung.
Costurile fixe asociate cu testarea automat nu sunt valori absolute. Ace ti factori trebuie s fie
amortizai pe perioada utilizrii i ajustai pentru perioada de timp t. Valoarea lui t trebuie s fie
selectat bazndu-se pe factorii manageriali cum ar fi: perioadele contabile de returnare a plilor,
timpul dintre dou versiuni de produs, timpul de via a instrumentelor de testare i a testelor,
etc.i de a face calculri rezonabile, utile i simple. Amortizarea acestor costuri este facut prin
multiplicare costului cu t i mprirea la utilitate. De exemplu: dac un instrument cost 2500$ i
este ateptat de a fi utilizat pe 2 ani, atunci costul pentru primul an de utilizare este de 1250$ pe
an. De asemenea, avnd cheltuieli de 5000$ pe o perioad de 4 ani. Costurile investi iilor sunt
valabile pe toat perioada de utilziare a serviciului. Dac instrumentul de testare nu mai este
utilizat pin la sfritul primului an atunci ntreaga sum de 2500$ se vor socoti ca cheltuieli.
Similar, dac membrii echipei prsesc echipa dup instruire, ntregile costuri de instruire nu vor
fi amortizate n perioada ateptat.
Cel mai mare avantaj al testelor automate comparativ cu testele manuale sunt costurile mici de
rulare. Aceasta face ca numrul ateptat de rulri a testelor automate (n1) i numrul manual de
rulare a testelor (n2) n timpul perioadei t este un factor critic pentru calcularea ROI. Dei n1 este
ntodeauna mai mare ca n2 atunci cnd testele automate sunt construite corect, sunt i cazuri cnd
n1 poate fi mai mic ca n2. Aceti factori trebuie alei realistic dac se vor rezultate utile.
Testele automate necesit de a fi meninute. Aa deci, numrul de teste revizuite nainte de rulare
este de asemenea important.

54

Factorii urmtori pot fi divizai n costuri comune att testrii manuale ct i celei automate.
Aceti factori care sunt comuni nu trebuie de luat n consideraie cnd se calculeaz beneficiile
testrii automate. Acei factori care cresc sunt costurile automatizrii, iar cei care scad sunt
beneficiile. Unii factori pot crete sau descrete imediat, dintre acetia pot fi plasai ca costuri sau
beneficii, depinznd ns de tipul de automatizare i eficacitatea ateptat. n lista urmatoare
sunt cteva exemple din ambele categorii:
Exemple de factori care se schimb (pot fi att beneficii ct i costuri ale automatizrii):

Mentenana platformei de automatizare

Execuia cazurilor de testare
Analiza rezultatelor testrii
Raportarea defectelor
Raportarea rezultatelor testelor
Generarea datelor pentru teste

Exemple de beneficii ale automatizrii:

Salvarea timpului de execuie

Testarea peste program de ctre sistem
Acumularea de noi cunotine in domeniul testrii

Exemple de costuri ale automatizrii:

Hardware- adugarea sau rennoirea celor existente

Licenele instrumentelor de testare
Suport pentru instrumentele de testare
Planificarea platformei de testare
Implementarea platformei de testare
Instrumente de scripting
Instruirea cu instrumentele de testere
Planificarea cazurilor de testare automatizat
Implementarea cazurilor de testare
Mentenana testelor

3.3 Calcularea costurilor i beneficiilor

Procesul de testare automat presupune suportarea mai multor costuri, printe care cheltuielile
pentru software, un personal specializat n domeniu i diverse consumuri de resurse. Costul
testrii are o pondere destul de important n costul total al aplicaiilor informatice. Pentru a
echilibra i micora costul testrii sunt elaborate diverse modele de estimare a efortului de
55

testare, lundu-se n considerare nivelul estimat al complexitii programului i structura

proiectului. n urma estimrilor efortului de testare sunt identificate diferite modalitati de a
optimiza acest cost al testrii.
Cheltuieli cu personalul
n orice domeniu sunt angajate persoane specializate n domeniu i care pot face fa sarcinilor
asignate. Nu mai puin i n domeniul testrii software orientat pe obiect este cutat un personal
calificat i pasionat de domeniul dat. Pentru a determina dac persoana se va putea integra n
colectiv, aceasta este supus s parcurg unele faze de testare, iar fiecare membru al echipei
primete anumite sarcini de lucru. Printre sarcinile echipei de testare se enumer: [9]

stabilirea i definirea obiectivelor testrii;

colectarea informaiei necesare pentru elaborarea unor exemple de test;
extragerea informaiei din specificaiile produsului a elementelor ce vor forma nite

puncte cheie n procesul de testare software;

alegerea metodelor i tehnicilor de testare corespunztoare produsului testat i

obiectivelor urmrite;
structurarea procesului de testare n mai multe etape ;
lansarea n execuie a produsului supus testrii;
analiza comportamentului real al produsului implementat cu comportamentul definit n

specificaii;
elaborarea unui raport de testare care include rezultatele procesului de testare, defectele
gsite n produs i elementele de baz care vor defini respingerea sau acceptarea
produsului. Sub acest aspect realizm importana procesului de testare, care are drept
scop urmrirea strii produsului la un anumit moment de timp.

Pentru a asigura eficiena procesului de testare sunt necesare anumite costuri n instruirea
personalului de testare cu tehnicile utilizate n procesul de testare i deasemenea salariile
acestora. Eficiena procesului de testare este determinat de anumii factori, cum ar fi:
-

durata procesului de testare (se estimeaz timpul alocat pentru testarea fiecrei arii);
numrul de iteraii necesar pentru evidenierea integral a comportamentului produsului

supus testrii;
concordana dintre rezultatul testarii produsului i situaia actual la moment a
produsului, n urma cruia se stabilete dac produsul coincide cerinelor clientului i este
acceptabil de livrat, sau nu corespunde anumitor cerine i trebuie fixat.
56

Eficiena testrii ntr-o mare msur depinde de personalul ce testeaz produsul, acesta fiind
factorul de baz, deoarece prin aciunile sale el poate dirija ntreg procesul de testare.
Cheltuieli de asistare
Orice proces se execut n anumite condiii corespunztoare complexitii procesului.
Testarea software, fiind un proces destul de complex i cu o importan major, este necesar
s fie executat n anumite condiii dotate cu instrumente i echipamente speciale. Testarea
complet a unui produs nu poate fi realizat n cazul cnd echipa de testare nu dispune de tot
echipamentul de resurse necesare. n cazul testrii automate a produsului, echipa de testare
are nevoie i de alte instrumente specializate n automatizarea acestui proces. n cadrul
procesului de testare asistat se verific msura concordanei dintre specificaii i program.
Printre cheltuielile de asistare se enumer: cotele pri repartizate din amortizrile pentru
echipamentele i instrumentele software, cheltuielile de ntreinere a instrumentelor i
echipamentelor utilizate, cheltuieli privind instruirea presonalului n utilizarea acestor
instrumente i cheltuielile necesare analizei de comportament a produsului actual cu
rezultatul testrii din etapele anterioare.
Pe lng cheltuielile enumerate se specific nc cheltuielile pentru elaborarea sistematizat a
documentaiei, cheltuieli suportate pentru fixarea bugurilor depistate n faze trzii, aceste
defecte sunt mult mai costisitoare dect la momentul n care puteau fi determinate n fazele
nceptoare. O anumit parte din cheltuieli se utilizeaz n automatizarea testelor, proces ce
dureaz foarte mult de la nceput compoarativ cu procesul de testare manual. Estimativ 1030 teste automate pot fi echilibrate cu 100 teste manuale.
Lund cunotin cu anumite cheltuieli suportate n cadrul procesului de testare automat,
vom ncerca s analizm unele modele de estimare a costului testarii.
Pentru determinarea duratei testrii, rezultatele acesteia i costurile suportate este necesar mai
nti de a determina complexitatea produsului ce urmeaza a fi testat
Eficiena echipei de testare poate fi estimat conform raportului 3.5, unde n este lungimea
procesului de testare ca numr de iteraii:

57

S analizm modelul dat n cadrul proiectului Enrollment Management. Produsul este supus
testrii ntr-un anumit numr de iteraii. Testele automate sunt rulate succesiv la fiecare
distribuie nou creat. Graficul evoluiei programului exprimat prin numrul de erori gsite de la
o iteraie la alta este descresctor. (figura 3.2)

Figura 3.2 Graficul evoluiei programului

Sunt muli ali factori n afar de costurile financiare i beneficii, maurrile financiare sunt
utilizate pentru calcularea ROI n urmtoarele patru ecuaii. Primele 2 exemple arat procentajul
eficienei testelor automate comparativ cu testele manuale. Celelalte 2 arat procentajul de
rentoarcere a banilor pentru fiecare dolar investit.
V
V
( m+nDm)
4
( a+ nDa )

A
En = a =
Am
V
V
( m+n2D m)
( a+n 1Da )

A
Enc = a =
Am

(1)

(2)

58

ROI automation ( time t ) =

Ba
(Beneficiile automatizrii)
=
(Costurile automatizrii)
Ca

ROI automation ( time t )=

(3)

( Beneficiile automatizrii asupra testrii manuale)

(Costurile automatizrii asupra testrii manuale) =

Ba
Ca

(4)

Unde:

En - reprezint raportul costurilor automate asupra consturilor manuale pentru acelai numr de teste dezvoltate
i acelai numr de teste rulate.

Enc - represint raportul dintre costurile automate i manuale pentru un numr difetrit de teste.
innd cont c a este automat, iar m este manual avem:

V a - cheltuieli pentru specificaile testarii i implementare

V m - cheltuieli pentru specificaii
D a - cheltuieli pentru integrarea testelor dup automatizarea lor
Dm - chletuieli pentru executarea unui test manual
n- numrul de teste automate (manuale) executate

n1 - numrul de rulri a testelor automate

n2 -numrul de rulri a testelor manuale
N- numrul mediu de rulri a testelor nainte de a fi necesar o ntreinere a testelor

B a - beneficiile n urma testrii automate

C a -costurile testrii automate
Ba diferena pozitiv a beneficiului testrii automate asupra testrii manuale

59

 Ba ( time t) =

mbuntiri ale costului fix testrii automate n timp

( Usefult Life ))+ ( costuri variabile arulrii testelor ma

C a - diferena pozitiv a costului testrii automate asupra testrii manuale

C a ( timet ) =

*(

mriri ale costului fix testrii automaten timp

( Usefult Life ))+ ( costuri variabileale crerii testelor autom

n1
N )

Trei dintre cele 4 ecuaii calculeaz valoarea de baz a comparaiei dintre testele manuale i
automate. n cele mai multe situaii beneficiile testrii automate poate fi calculat ca mrirea lor
bazndu-ne pe mrirea investiiilor. Numrul testelor manuale sunt baza costurilor de testare n
cadrul organizaiei. Acest volum de bani va fi oricum investit indiferent c este sau nu
automatizarea. Automatizarea testrii implic costuri suplimentare, dar ateptnd de asemenea
creterea beneficiilor. A treia ecuaie exprim ROI conceptual n termeni de costuri i beneficii.
Prima ecuaie compar costurile de creare i rulare a testelor manuale cu acelai numr de
rulri a unui test automat. Acesta calculeaz raportul din costul crearii i rulrii unui test automat
de n ori asupra costului crerii i rulrii unui test manual de n ori. O valoare mai mic ca unu ca
rezultat este avantajos pentru automatizare deaorece acesta arat costul testului auotmatizat ca
fraciune din testul manul. Valorile utilizate n ecuaie (1) sunt bazate pe cteva predefini ii care
nu sunt aplicabile pentru toate organizaiile. Trei dintre aceste predefiniii sunt importante n
particular. Adesea testele manuale i automate nu sunt rulate de acelai numr de ori. Fiecare
rulare a unui test nu are un rezultat egal. Deasemnea mule organizaii nu au suficiente resurse
pentru a crea teste automate ct i manuale. Deaceea de obicei testele automate sunt mai pu ine.
n al treilea rind multe teste automate necesit mentenant n timp pentru a asigura execu ia
acestora, dea accea pot aprea costuri adiionale nainte ca testul automat sa fie rulat de n ori.
60

Ecuaia (2) se contabilizeaz pentru un numrr diferit de rulri a testelor manuale i

automate. Aceasta deasemenea exprim costul automatizrii fracionat la costurile manuale. Deci
rezultatul mai mic ca 1 arat ca automatizarea este avanatjoas. Pentru a reprezenta raportul de
seturi de teste ecuaia exprim c toate testele automate sunt rulate de n 1 ori i cele manuale de n2
ori.
Ecuaia (3) arat cum ROI poate fi exprimat printr-o formul general. Aceasta reprezint
raportul dintre beneficiile automatizrii i costurile acestora. Un rezultat mai mare ca 1 indic c
beneficiile sunt mai mari ca costurile. Aceasta ne arat c pentru fiecare dolar investit n
automatizare noi vom avea ROI de dolari ca profit a beneficiilor.
Ecuaia (4) reprezint un ROI relativ de comparare a beneficiilor adugate de
automatizare cu costurile adugate. Cu toate c ecuaia este foarte general este mai rezonabil de
reprezentat valoarea automatizrii n raport cu testarea manual. Ecuaia poate fi aplicat uor la
proiecte i grupuri de teste i poate fi utilizat pentru a arta beneficiile testurilor individuale.
Anume aceast ecuatie va fi explicat si utilizat n exemplele urmtoare. Pentru a utiliza acast
ecuaie mai ntii de toate este necesar de a identifica toate costurile si beneficiile relevante.
Valorile trebuie s fie determinate att pentru testarea manual ct i pentru cea automat. Unele
itemuri pot fi aplicate doar unui tip de testare iar altele altora. De exemplu o investi ie n
hardware poate fi obligatorie pentru automatizare fr vreo atribuie ctre testarea manual. n alt
caz un instrument comparat pentru testarea automat poate necesita oameni suplimentari care
sunt implicai in testarea manual, astfel schimbnd costul variabil al testrii manuale la un cost
fix a testrii automate.
Dou exemple simple vor fi analizate pentru a determina tipul returnului care se vede din testele
automate, primul exemplu este despre automatizarea testelor de acceptan. Acestea sunt frecvent
rulate i testele sunt relativ simple i stabile. Al doilea exemplu este bazat pe automatizarea
testelor UI, care tinde sa fie o alt extrem i o plat mai mic.
Automatizarea testelor de acceptan
Valorile presupuse i calculate:

Construciile zilnice i rularea testelor (5 ori pe saptamn);

Testele manuale ocup 5 zile de proiectare i 2 ore de rulare;

61

Doar jumate din testele manuale vor fi rulate n prima zi(1 or), cealalt urmnd a fi

execuate pentru ziua urmatoare;

Testele automate vor necesita 15 zile de proiectare i implementare, vor fi rulate automat

(costuri=0);
Automatizarea se face prin scripturi integrate n procesul de creare a distribu iei. Aceasta

necesit 500 $ pentru a adauga componente hardware care va funciona minim 3 ani;
Testele automate trebuie meninute la fiecare a 25-a rulare. Aceasta necesit 8 ore de

lucru;
Perioada selectat 6 luni (125 zile) i 18 luni (375 zile);
Costuri cu personalul (10000$ pe an)= 40$ pe zi= 5$ pe ora.

Ba ( time t) =

mbuntiri ale costului fix testrii automate n timp

( Usefult Life ))+ ( costuri variabile arulrii testelor ma

Ba (n 6 luni) = 0+ (1 ora *125) (0 *125)= 5$ * 125= $625

Ba (n 18luni) = 0+ (1 ora *375) (0 *375)= 5$ * 375= $1875
C a ( time t ) =

*(

mriri ale costului fix testrii automate n timp

( Usefult Life ))+ ( costuri variabileale crerii testelor autom

n1
N )
C a (n 6 luni) = (500* 6/36) + (15*40) (5*40) + (40*125/25) = $84 + $600 -$200 + $200= $684
C a (n 18 luni) = (500* 18/36) + (15*40) (5*40) + (40*375/25) = $250 + $600 -$200 + $600= $1250

ROI automation ( n 6 luni ) = 625/684=0.91 [costuri mai mari ca beneficii]

62

ROI automation ( n 8 luni ) =1875/1250=1.5 [50 % beneficii]

Beneficiile n primele 6 luni vor fi mici, iar costurile vor fi substaniale, abia dup 18 luni rata
beneficiilor crete cu 50%.

Automatizarea testelor UI:

Valorile presupuse i calculate:

Produs nou i teste noi;

2 persoane pentru crearea testelor manuale si 5 persoane pentru crearea testelor automate;
1 persoan pentru mentenana dup primul an de automatizare cu norma de 8 ore;
4 persoane pentru rularea testelor manuale i 1 persoan pentru rularea testelor automate;
Costuri fixe pentru automatizare- 150$ cu termen de utilizare 3 ani;
Perioade de timp selectate: 12 luni (250 zile) i 24 luni (500 zile);
Costuri cu personalul (10000$ pe an)= 40$ pe zi= 5$ pe ora.
Ba ( timet ) =

mbuntiri ale costului fix testrii automate n timp

( Usefult Life ))+ ( costuri variabile a rulrii testelo

Ba (n 12luni) = 0+ (4 *10000) (1 *10000)= $30000

Ba (n 24 luni) = 0+ (4 *2*10000) (1 *2*10000)= $70000
C a ( timet ) =

*(

mriri ale costului fix testrii automaten timp

( Usefult Life ))+ ( costuri variabileale crerii testelor autom

n1
N )
C a (n 12 luni) = (150* 1/3) + (5*10000) (2*10000) + 0 = $300+ $50000 -$20000= $30300

63

 C a (n 24 luni) = (150* 2/3) + (5*10000) (2*10000) + 1*10000 = $100 + $50000 -$20000 +

$10000= $40100

ROI automation ( n 12luni ) = 30000/30300=0.99 [costuri mai mari ca beneficii]

ROI automation ( n 24 luni ) =70000/40100=1.74 [75 % beneficii]

64

Anexa 1
Exemplu de test a verificrii modulului Accounts
class AccountCompletTest extends LoginClass {
def 'setupSpec'(){
sleep 1000
Browser.drive() {
log.debug "AccountCompletTest initialization"
withFrame(config.frame.top){
$("a", title: "Accounts").click()
sleep 2000
}
withFrame(config.frame.display){
log.debug "Press All acounts"
$("a", title: "All Accounts").click()
sleep 3000
log.debug "Press CMSFFM"
$("a", id: "{CMSFFM}").click()
sleep 3000
}
}
expect:
true
}
def 'Contacts Tab'(){
Browser.drive() {
withFrame(config.frame.display) {
log.debug "Press Contacts"
$("div", id: startsWith("tabbar-"), "data-ref":"targetEl").find("a")[1].click()
sleep 2000
//get elements GeneralContainer
def generalTab = $("div", id:"accountContacts-body")
//press add External Contacts
generalTab.$("div", id:startsWith("toolbar-"), "role":"presentation")[0].find("a")[0].click()
sleep 2000
//close add External Contacts
def general = $("div", id:"accountExternalContact-body")
general.$("div", id:startsWith("container-"), "data-ref":"targetEl").find("a")[2].click()
//Click Assign Contact
generalTab.$("a", title:"Assign").click()
sleep 2000
//close Assign Contact
general = $("div", id:"accountInternalContact-body")
general.$("div", id:startsWith("container-"), "data-ref":"targetEl").find("a")[2].click()
}
}
sleep 4000
expect:
true
}
def 'Trade Relationships'(){
Browser.drive() {
withFrame(config.frame.display) {
log.debug "Press Trade Relationships"
$("div", id: startsWith("tabbar-"), "data-ref": "targetEl").find("a")[2].click()
sleep 2000
//press Add
def general = $("div", id:"accountSetupTradeRelationships-body")
general.$("a", title:"Add").click()

65

//

sleep 1000
//Close Addd
def tab = $("div", id:"addTradeRelationshipPopup-body")
tab.$("div", id:startsWith("container-"), "data-ref":"targetEl").find("a")[0].click()
//close Add
general = $("div", id:"addTradeRelationshipPopup-body")
general.$("div", id:startsWith("toolbar-"), "data-ref":"targetEl").find("a")[1].click()
}
}
sleep 3000
expect:
true
}
def 'Tasks'(){
Browser.drive(){
withFrame(config.frame.display){
log.debug "Press Tasks(1)"
$("div", id: startsWith("tabbar-"), "data-ref":"targetEl").find("a")[3].click()
sleep 2000
//Click ComboBox
def generalTab = $("div", id:"accountTasks-body")
generalTab.$("input", value:"My Tasks").click()
def explicit = generalTab.$("div", id:startsWith("basesearch-"), "data-ref":"targetEl")
//Click Select ComboBox
explicit.$("input", value:"--Select--").click()
sleep 1000
//CLick Input
explicit.$("input",role:"textbox").click()
sleep 1000
//Click Search
explicit.find("a")[0].click()
sleep 1000
//Click Close
explicit.find("a")[1].click()
sleep 1000
}
}
sleep 3000
expect:
true
}
def 'Notes'(){
Browser.drive() {
withFrame(config.frame.display) {
log.debug "Press Notes"
$("div", id: startsWith("tabbar-"), "data-ref": "targetEl").find("a")[4].click()
def generalTab = $("div", id:"accountNotes-body")
def explicit = generalTab.$("div", id:startsWith("basesearch-"), "data-ref":"targetEl")
//Click Select ComboBox
explicit.$("input", value:"--Select--").click()
sleep 1000
//CLick Input
explicit.$("input",role:"textbox").click()
sleep 1000
//Click Search
explicit.find("a")[0].click()
sleep 1000
//Click Close
explicit.find("a")[1].click()
sleep 1000
sleep 2000

66

}
}
expect:
true
}
def 'Transmission'(){
Browser.drive(){
withFrame(config.frame.display){
log.debug "Press Transmission"
$("div", id: startsWith("tabbar-"), "data-ref": "targetEl").find("a")[5].click()
//Click ComboBox
def generalTab = $("div", id:"accountTransmissions-body")
generalTab.$("input", value:"All").click()
def explicit = generalTab.$("div", id:startsWith("basesearch-"), "data-ref":"targetEl")
//Click Select ComboBox
explicit.$("input", value:"--Select--").click()
sleep 1000
//CLick Input
explicit.$("input",role:"textbox").click()
sleep 1000
//Click Search
explicit.find("a")[0].click()
sleep 1000
//Click Close
explicit.find("a")[1].click()
sleep 1000
}
}
expect:
true
}
def 'Policy Units'(){
Browser.drive(){
withFrame(config.frame.display){
log.debug "Press PolicyUnits"
$("div", id: startsWith("tabbar-"), "data-ref": "targetEl").find("a")[6].click()
def generalTab = $("div", id:"accountPolicyUnits-body")
def explicit = generalTab.$("div", id:startsWith("basesearch-"), "data-ref":"targetEl")
//Click Select ComboBox
explicit.$("input", value:"--Select--").click()
sleep 1000
//CLick Input
explicit.$("input",role:"textbox").click()
sleep 1000
//Click Search
explicit.find("a")[0].click()
//Click Close
explicit.find("a")[1].click()
}
}
expect:
true
}
def 'History'(){
Browser.drive(){
withFrame(config.frame.display) {
log.debug "History"
$("div", id: startsWith("tabbar-"), "data-ref": "targetEl").find("a")[7].click()
def generalTab = $("div", id: "accountHistoryEvents-body")
def explicit = generalTab.$("div", id: startsWith("basesearch-"), "data-ref": "targetEl")

67

//Click Select ComboBox

explicit.$("input", value: "--Select--").click()
sleep 1000
//CLick Input
explicit.$("input", role: "textbox").click()
sleep 1000
//Click Search
explicit.find("a")[0].click()
//Click Refresh
explicit.find("a")[1].click()
def tabSort = generalTab.$("div", id:startsWith("headercontainer-"), "dataref":"innerCt")
//sort by id up
tabSort.find("span")[0].click()
//sort by id down
tabSort.find("span")[0].click()
//sort by severity up
tabSort.find("span")[1].click()
//sort by severity down
tabSort.find("span")[1].click()
//sort by date&time up
tabSort.find("span")[2].click()
//sort by date&time down
tabSort.find("span")[2].click()
//sort by date&time up
tabSort.find("span")[4].click()
//sort by date&time down
tabSort.find("span")[4].click()
//sort by type up
tabSort.find("span")[5].click()
//sort by type down
tabSort.find("span")[5].click()
//sort by topic up
tabSort.find("span")[6].click()
//sort by topic down
tabSort.find("span")[6].click()
tabSort.find("span")[7].click()
//sort by message down
tabSort.find("span")[7].click()
def close = $("div", id:startsWith("accountheaderpanel-"), "role":"presentation")
close.$("div", id:startsWith("container-")).find("a")[1].click()
}
}
expect:
true
}
def 'cleanupSpec'(){
Browser.drive(){
withFrame(config.frame.top){
$("a", title:"Transactions").click()
}}}}

68

Bibliografie
Surse internet:
1. https://controlultehnic.wordpress.com/2011/10/27/ce-este-un-testcase/
2. http://istqbexamcertification.com/what-is-fundamental-test-process-in-softwaretesting/
3. http://www.academia.edu/7336420/TEHNICI_DE_TESTARE_SOFTWARE_Banu_
Alexandru_Grupa_441A_Cuprins_Definitie_Testare_Software_1_Generalitati_1
4. http://tir.ipsitransactions.org/2009/January/Paper%2006.pdf
5. http://www.tricentis.com/solutions/testing-with-selenium/
6. https://www.packtpub.com/sites/default/files/downloads/Testingwithgroovy.pdf
7. http://www.softwaretestinghelp.com/bvt-build-verification-testing-process/
8. http://incepator.pinzaru.ro/abc/interfata-cu-utilizatoru/
9. http://www.testare-software.ase.ro/toc/cost_testare.html

Surse bibliografice:

[1] ASEM Ghid privind elaborarea i susinerea tezei de masterat.,Chiinau

ASEM 2015
[2]Costa

I.

Managementul

calitii

tehnologiilor

sistemelor

informaionale(notie de curs), Chiinau, ASEM, 2012

[3] Douglas Hoffman, Software Quality Methods, Cost Benefits Analysis of Test
Automation, California, Saratoga, 2003

69

nluzii
n realizarea sistemului informatic de succes este necesar depunerea unui efort i timp
considerabil. ntru rlizr unui subsistm infrmti r s rsund l rinl
bnfiirului, st nvi d unt ndr mnismul d funinr sistmului,
iruitul infrmii, rsl r u l rursul tivitii. Studierea, analiza i testarea
sistemului este destul de important pentru realizarea funcional a acestuia.
Este important de menionat c testarea automat reprezint cea mai bun soluie n cazul n care
procesul de testare a aplicaiei devine ineficient i cheltuielile pentru fixarea defectelor scad
considerabil profitul companiei n urma implementrii acestui produs n lumea real.
L nut nd s- us srin rlizrii stui sistm, s-u stbilit bitivl r
trbui s l ndlins lii nstruit. bitivl u fst ndlinit u sus. n l
st mmnt s-au analizat mdull r constituie lii d tstr finl.
Mdull r sunt rznt ndlins dlin sul rus ntru fir n rt i sunt
imlmntt dirt ntru ndlinir rslr r l utmtizz.
Sul proiectului de testare st d jut hi n ntrg rsul d tstr, de
idntifi sibill rblme, d f rgrsi ntr-un ritm lrt i r s nu imli
mult rsurs.

70

DNTR

l Tz d masterat INSTRUMENTE SI METODE DE TESTARE AUTOMAT N

CADRUL COMPANIEI EST-COMPUTER "
studnti gr. MI-141m, silitt Management Informaional"
Burli Dri

Tz d lin st rftt 72 d gini frmtul 4 i urind 13 figuri, 3 tble, 3 surs

bibligrfi i 4 gini d n.
uvint hi:Tstr, tsts , rul, utmtizr .
Tstr st rsul rin r tr ric rdus, inlusiv unul sftwr. Tstr st
t d dzvltr n r s t d rizt grdul d mtivitt, litt, sigurn
rdusului finl. st dmniu st rsndit n tt rmuril nmi, ri rdus su
srviiu trbui s fi tstt. n drul sti subt s vr timiz lmntl d intrf u
utiliztrul (frmt vid, dilguri, sistm d hl), s vr un l unt rduril d
rntminr i rtr rrilr invluntr l rr, s lbrz dumnti d
rlizr, mnulul d rzntr i mnulul d utilizr i ltr.
Tz nst din intrdur, 3 itl, nluzii i 1 n. n rimul itl sunt
dsris niunil d bz rfritr l tstr, nliz sistmului infrm inl istnt i
scopul general al testrii automate. l dil itl st ddit dsririi d nsmblu
liii r urmz fi testat, i num infrastructura sistemului, metodele i tehnicile de
testare aplicate. Digrml r dsriu rin imgini thni numit tiviti l rsului
sunt rzntt d smn n st itl. n l d l tril itl este descris analiza i
evaluarea rezultatelor obinute n cadrul testrii automate, calcularea costurilor i beneficiilor.
Sunt propuse soluii pentru problemele procesului de testare automat din cadrul companiei
Edifecs i a produsului Enrollment Management.

71