Curs8 - 9 - Testarea Automata Versus Testarea Manuala

Testarea produselor software
UNIUNEA EUROPEANĂ GUVERNUL ROMÂNIEI Fondul Social European Instrumente Structurale OIPOSDRU UNIVERSITATEA
MINISTERUL MUNCII, PSD DRU 2007 - 2013 2007 - 2013 TEHNICĂ DE
FAMILIEI ŞI CONSTRUCŢII DIN
PROTECTIEI SOCIALE BUCUREŞTI
Investeşte în oameni ! AMPOSDRU
Proiect cofinanţat din FONDUL SOCIAL EUROPEAN

prin Programul Operaţional Sectorial Dezvoltarea Resurselor Umane 2007 – 2013
Axa prioritară 1: „EDUCAŢIA ŞI FORMAREA PROFESIONALĂ ÎN SPRIJINUL CREŞTERII ECONOMICE ŞI DEZVOLTĂRII SOCIETĂŢII BAZATE
PE CUNOAŞTERE”
Domeniul major de intervenţie 1.2 „Calitate în învăţământul superior”
Cerere de propuneri de proiecte: nr. 86 „Universitate pentru viitor”
Titlul proiectului: Reţea naţională de centre pentru dezvoltarea programelor de studii cu rute flexibile şi a unor instrumente didactice la specializarea de licenţă şi
masterat, din domeniul Ingineria Sistemelor
Numărul de identificare al contractului: POSDRU/86/1.2/S/63806
Gabriela Varvara
Testarea Produselor Software
Curs 8 -9 – Testarea automata versus testarea manuala

Partener P4
MINISTERUL EDUCAŢIEI, UNIVERSITATEA UNIVERSITATEA TEHNICĂ UNIVERSITATEA TEHNICĂ UNIVERSITATEA SC ASTI AUTOMATION SRL
CERCETĂRII, TINERETULUI ”POLITEHNICA” DIN ”GHEORGHE ASACHI” ”POLITEHNICA”
ŞI SPORTULUI DIN CLUJ-NAPOCA DIN DIN
BUCUREŞTI IAŞI TIMIŞOARA
<Testarea Produselor Software>

Obiective curs :
<Gabriela Varvara>
Obiectivul 1: necesitatea automatizarii testarii
Obiectivul 2: testare manuala versus testare automata
Obiectivul 3: elemente de baza in testarea automata:
Obiectivul 3.1: despre cele 2 discipline implicate – testare si automatizare
Obiectivul 3.2: capacitatea de intretinere a testelor automate
Obiectivul 3.3: optimizarea procesului de creare a testelor automate
Obiectivul 3.4: independenta cazurilor de testare
Obiectivul 3.5: modularitatea scripturilor de testare
Obiectibul 3.6: sincronizarea intre executia testelor si cea a aplicatiei
Obiectiv 3.7: documentare testware
Subiecte tratate: necesitatea automatizarii procesului de testare, testare automata – aplicare si

restrictii, concepte fundamentale legate de testarea automata
C8-9: 1

Necesitatea automatizarii testarii <Gabriela Varvara>
Presiunea pietii referitoare la livrarea de noi functionalitati si aplicatii software

implica imbunatatirea gradului de acoperire in testare cu respectarea
Termene de predare din ce in ce mai stranse
In contextul unor resurse fixe sau chiar in diminuare
Testarea manuala, vazuta mult timp ca singura solutie in asigurarea calitatii

software:
Intarzie lansarea pe piata a produsului
Induce cheltuieli semnificative, mai ales pentru descoperirea efectelor laterale
Nu reuseste descoperirea tuturor defectelor
Nu poate simula conditii de utilizare concurenta, intensiva a unei aplicatii

Necesitatea automatizarii testarii <Gabriela Varvara>
Automatizarea testarii reprezinta una din cele mai eficiente cai de imbunatatire a
testarii manuale
Majoritatea produselor software necesita testare
repetata, pe multiple platforme software/hardware,
dupa schimbari ulterioare, la lansarea unei noi versiuni pe piata
Testele automate
Executa o secventa de actiuni fara interventie umana
Pot simula utilizarea aplicatiei in conditii de simultaneitate ridicata cu costuri

extrem de scazute
C8-9: 2

Cateva observatii importante legate de testarea automata <Gabriela Varvara>
Desi este costisitor sa livrezi un produs pe piata cu intarzieri datorate

perioadelor lungi de testare manuala, este catastrofic sa lansezi pe piata un
produs cu erori critice.
Costul unei singure erori ce determina caderea aplicatiei costa extrem de mult
Consecinta:
Daca nu exista resursa umana si de timp pentru a demara o testare adecvata,

automatizarea nu va reduce instabilitatea software si erorile.
Prima atentie a producatorului de software este sa livreze produse fiabile.
Odata atins acest obiectiv, focusul poate fi orientat spre optimizarea timpului
si costurilor.
Daca un produs nu merge nu conteaza cat de repede sau de ieftin il livrezi!

Beneficiile testarii automate <Gabriela Varvara>
Acoperirea tuturor etapelor de testare de la conceptie pana la lansare
Posibilitatea simularii testarii cu mai multi utilizatori
Posibilitatea repetarii testelor
Acoperire cumulativa in detectia erorilor
Cresterea sigurantei in produs
Observatie:
Trebuie avut in vedere ca un proces de testare automata presupune un ciclu de testare ce incepe
cu automatizarea, deci nu trebuie contat pe scurtarea timpului dedicat testarii – miza este
atingerea termenului de livrare cu un produs fiabil.
Automatizarea reduce
Costurile pentru activitati suport si pentru reluare activitati
Probabilitatea de producere de erori critice
C8-9: 3

Testarea automata recomandata pentru: <Gabriela Varvara>
Acoperirea cumulata pentru testele executate
Pe perioada ciclului de viata aplicatiile devin din ce in ce mai complexe prin
extinderea setului de caracteristici – numarul de teste necesar pentru o
acoperire adecvata este in continua crestere
Chiar daca aplicatia isi schimba codul doar cu 10%, tot va trebui testat tot produsul
– testarea manuala nu va tine pasul decat in conditiile cresterii constante a
resurselor si a timpului dedicat testarii –automatizarea ajuta la cumularea cazurilor
de testare de-a lungul ciclului de dezvoltare a aplicatiei – permite testare de
caracteristici initiale sau dobandite pe parcurs
Observatie: riscul maxim intr-o aplicatie il reprezinta, paradooxal, caracteristicile

existente si nu cele nou adaugate, desi la timpi de testare scurti celor din urma li se
da o atentie speciala in defavoarea testarii de regresie. Pierderea, ca o consecinta a
testarii, a unei caracteristici noi poate fi frustranta, dar nu este devastatoare.
Beneficiile automatizarii, in acest caz, se pierd pentru teste automate ce nu

sunt proiectate sa fie usor de intretinut pe masura ce aplicatia se modifica

Generarea si executia sistematica a unui numar extrem de mare de teste –

parghia fundamentala a testarii automate
Un proces de automatizare a testarii permite crearea si rularea a mii de teste si

chiar mai mult, in timp ce testarea manuala are limita superioara la ordinul a sute
de teste
Pentru garantarea succesului va trebui:
 proiectarea adecvata a testelor si scripturilor de testare pentru a permite

folosirea de fisiere externe si de constructii specifice
C8-9: 4

Scurtarea timpului pana la punerea pe piata a produsului software
Uneori timpul de livrare este mai critic pentru produsele IT decat costul
Executia testelor se face in regim 24x7
Imediat ce biblioteca de testare este automatizata – executia este mai rapida

si poate dura mult mai mult decat testarea manuala
Reducerea costurilor legate de caderea aplicatiei
In anumite situatii costul unei singure caderi este mai mare decat tot bugetul
testarii pentru perioade lungi de timp
Automatizarea testarii intervine prin garantarea unui grad sporit de acoperire
Ce nu este un beneficiu al testarii automate – reducerea resurselor de testare

Testarea automata NU este recomandata pentru: <Gabriela Varvara>
Aplicatii instabile prin design

Sisteme ce se bazeaza pe date in timp real sau sisteme de tip harta de
prognoza meteo, etc. nu au rezultate suficient de predictibile spre a se preta
automatizarii. Cu exceptia cazurilor cand exista simulatoare ce controleaza
intrarile, automatizarea este dificila deoarece rezultatele nu sunt cunoscute.
Atunci cand datele si mediul de testare al unei aplicatii nu poate fi controlat,

automatizarea devine imposibila. Efortul de dezvoltare si intretinere a testelor
automate nu este compensat de beneficii in conditia unei repetabilitati
indoielnice.
Pentru aplicatii puternic configurabile sau cu design bazat pe atribute

variabile, fie se automatizeaza profile de configuratie selectate, fie se renunta
la automatizare. In orice caz nu se recomanda reproducerea configurabilitatii
in biblioteca de teste deoarece se va atinge o complexitate excesiva cu
maxima probabilitate de cadere a testelor si costuri excesive de intretinere
O premiza de baza in aplicarea tesarii automate – comportamentul asteptat al

aplicatiei este cunoscut.
10
C8-9: 5

Testarea automata NU este recomandata pentru: <Gabriela Varvara>
Testeri fara experienta sau implicati temporar intr-o aplicatie

Daca testerul nu este familiarizat cu aplicatia spre a sti care este iesirea
asteptata, nici automatizarea propusa de acesta nu reflecta cu acuitate un
comportament corect.
Se spune ca un test automatizat este tot atat de bun pe cat este creatorul
acestuia.
 Testerii cu putina experienta creaza cele mai bune teste manuale deoarece ei
fac, cu maxima probabilitate, aceleasi greseli pe care le fac utilizatorii.
Pentru automatizare se recomanda lucrul cu experti.
Timp si resurse insuficiente

Cand criza de resurse nu permite testarea, nici un utilitar nu va putea sa fie
de ajutor; planificarea, antrenarea si implementarea testelor automate va fi
costisitoare si va dura in timp.
Se depaseste criza curenta si se orienteaza spre automatizare pe termen lung
11

Cum NU trebuie facuta automatizarea: <Gabriela Varvara>
Simpla distribuire a unui utilitar de automatizare testerilor nu ii va determina pe

acestia sa automatizeze procesul de testare.
Trebuie inteles ca utilitarele de automatizare a testarii sunt limbaje de

programare specializate ce implica abilitati in folosire.
Crearea unei biblioteci de teste automatizate este similara unui proiect de

dezvoltare software.
Automatizarea este mai mult decat inregistrare, executie si re-executie de teste

(capture/replay)
Realizarea unei biblioteci de teste robuste, usor de intretinut si de transferat

pe masura ce apar modificari implica decizii legate de strategie si metoda
12
C8-9: 6

Cum NU trebuie facuta automatizarea: <Gabriela Varvara>
La extremitatea cealalta se afla programarea pura – se scriu scripturi pentru

toate raspunsurile potentiale ale aplicatiei (don’t write a program to test a
program!)
Se va realiza, in fapt, un duplicat al aplicatiei. Si cine testeaza testele?

Pragmatic nu exista resurse pentru o astfel de strategie
Automatizarea reprezinta mai mult decat executia de teste
Pentru automatizare e nevoie de un proces complet si de un mediu pentru

crearea, executia, inregistrarea rezultatelor si documentarea testelor ce
trebuie gestionat si intretinut.
13

Stabilirea unor asteptari realiste <Gabriela Varvara>
In stabilirea unor asteptari realiste legate de automatizarea testarii trebuie avute
in vedere urmatoarele aspecte fundamentale:
Trebuie facute investitii in planificare, antrenare, si dezvoltare inainte ca orice

beneficiu sa fie posibil
Economia de timp se produce doar atunci cand testele automate pot fi

executate mai mult decat o singura data, de mai mult decat o persoana si fara
cerinte de intretinere exagerate
Nici un utilitar nu poate compensa lipsa de experienta in procesul de testare
14
C8-9: 7

Asteptari realiste legate de automatizarea testarii <Gabriela Varvara>
Automatizarea testarii este un obiectiv strategic – achizitia unui utilitar de

automatizare a testarii nu reprezinta nimic in sine. Trebuie investit mult timp si
efort pana la obtinerea unui beneficiu.
O regula empirica buna de urmat – sa se calculeze cerintele necesare iterarii

testelor manuale si apoi sa se inmulteasca cu 5 pentru o interfata text si 10
pentru o interfata grafica, la care sa se adauge timpul pentru antrenare testeri
si planificare – rezulta timpul necesar automatizarii testelor manuale
Nu orice activitate din procesul de testare poate fi automatizat
Nu sunt automatizate activitati precum - descoperirea de noi cerinte pentru

testare, definirea cazurilor de testare, intretinerea bibliotecii de testare,
administrarea mediului de testare, revizuirea si analiza rezultatelor testarii,
adaugarea de noi cazuri de testare pentru modificari ulterioare, sau in urma
identificarii defectelor
Acceptarea unui progres gradual - se demareaza cu zonele unde castigul este

maxim, apoi se reinvesteste timpul economisit in celelalte zone pana la
automatizare completa
15

Planifica pastrarea personalului
Existenta unui utilitar nu este un motiv sa micsorezi echipa de testare
Automatizarea ajuta echipa sa fie mai productiva dar nu produce miracole
In fazele de inceput e nevoie de o echipa consistenta intotdeauna
Echipa proprie elimina dependenta de asistenta temporara venita de la alte

departamente sau firme
Justificarea unui utilitar prin necesitatea diminuarilor de personal este

riscanta si nu atinge esenta testarii
Cel mai important scop al automatizarii testarii trebuie sa fie cresterea acoperirii
testarii, nu diminuarea costurilor de testare.
O singura cadere in unele sisteme costa mai mult decat bugetul de testare pe
perioade lungi
Scopul nu este sa eliminam si asa un personal putin ci sa reducem riscurile
produse de caderea aplicatiei
16
C8-9: 8

Reinvestirea timpului economisit
Timpul economisit din automatizare trebuie reorientat catre alte tipuri de teste de care
nu a fost timp inainte ( de configurare, de stress)
Daca calendarul ofera spatiu eliberat prin automatizare – trebuie incercata testarea pe
un numar mai mare de utilizatori si tranzactii, sau pe diferite platforme de configurare
Testarea nu se termina niciodata!!

Ce trebuie retinut despre setarea asteptarilor este ca veti fi masurat de management in
raport cu acestea
daca promiteti taierea bugetului de testare cu ½ prin achizitia unui utilitar si se

reduce in fapt doar ¼ - esecul este garantat.
Abordati o metoda conservativa in stabilirea obiectivelor
Daca se poate demonstra cresterea acoperirii testarii prin automatizare – se

reduc costuri indirecte rezultate din calitate imbunatatita
17

Obtinerea si pastrarea angajamentului cu managementul <Gabriela Varvara>
Este legat de 3 aspecte fundamentale: bani, timp si resurse
Angajamente legate de bani – achizitionarea unui utilitar de automatizare

implica cheltuieli legate de software, cursuri de formare si consultanta. La
cumpararea unui utilitar sa aveti in minte ca usor de utilizat nu e totuna cu
usor de implementat
Realizeaza proiect pilot – chiar daca primiti toti banii intr-o singura transa nu
trebuie cheltuiti tot asa. La prima incercare de automatizare se recomanda un
mic proiect pilot pe post de “proof of concept” (poate fi o parte din aplicatie
cu univers restrans care sa fie terminat in 2-4 saptamani). In aceasta perioada
trebuie documentate investitiile si beneficiile alaturi de o estimare pentru tot
proiectul.
Angajamente legate de timp – rezultatele automatizarii nu vin imediat.

Managementul trebuie educat asupra timpului in care vor aparea beneficiile.
Poate fi folosit pentru estimare proiectul pilot
18
C8-9: 9

Obtinerea si pastrarea angajamentului cu managementul <Gabriela Varvara>
Angajamentele legate de resurse – pe termen scurt, automatizarea solicita mai multe

resurse, desi pe termen lung face economie. Trebuie reflectat asupra faptului ca, cel
mai adesea, introducerea unui nou utilitar cere expertiza suplimentara pentru grupul
de testare
Inregistrarea progresului – chiar daca beneficiile apar dupa mai multe luni, progresul
trebuie demonstrat prin raportare macar o data pe luna. Comunicati vestile proaste cat
se poate de repede si cele bune imediat ce aveti garantia ca le puteti mentine.
Ajustare pe parcurs - daca una din ipoteze se modifica, se va modifica calendarul si

asteptarile si se va anunta managementul imediat.
Planificare pe termen lung - sa se aiba in vedere ca procesul de testare automata a

unei aplicatii dureaza termen lung – toata perioada de intretinere a aplicatiei
Pentru o sustinere pe termen lung, managementul trebuie informat pas cu pas asupra
ceea ce se intampla pentru a sti la ce sa se astepte.
Nimanui nu ii plac surprizele!!
19

<Gabriela Varvara>
Elemente de baza in automatizarea testarii
Automatizarea testarii este mai mult decat simpla captura si reluare a procesului
de testare manual.
Nici un proces de automatizare a testarii nu va renunta complet la testarea

manuala
Automatizarea impune predictabilitate, in timp ce utilizatorii sunt , inerent,

impredictibili
Se va folosi automatizarea pentru a cauta rezultatul asteptat si testarea manuala

pentru cel neasteptat
Succesul automatizarii testarii depinde de intelegerea urmatoarelor aspecte

fundamentale:
Procesul de testare trebuie sa fie bine definit – complet definit, formalizat si bine
documentat
Testware este software – ce se testeaza si cum se testeaza este impachetat intr-o

aplicatie creata intr-un mediu specializat
20
C8-9: 10

Elemente de baza in automatizarea testarii <Gabriela Varvara>
Automatizarea testarii este constituita din 2 discipline:

Testarea
Automatizarea – calculatorul este instruit sa execute anumite sarcini ce anterior erau

executate manual, Aceste instructiuni sunt memorate intr-un script (are caracteristicile
unui program sursa)
21

Maintenabilitatea testelor automate – capacitatea de a intretine in timp

testele cu integrarea modificarilor ce apar pe parcurs
Caracteristici ale procesului de intretinere:
Aplicatiile trebuie intretinute in mod permanent – in medie 25%

dintr-o aplicatie este rescrisa in fiecare an
Testele vor trebui sa tina pasul schimarilor din aplicatie
Practica arata ca in loc sa se imbunatateasca gradul de acoperire

prin noi si noi teste, unele din cele vechi vor fi inlaturate si vor
aparea altele noi
Mai mult, fiecare noua versiune de aplicatie vine cu functionalitati

noi pentru care trebuie noi teste
22
C8-9: 11

Schimbarile trebuie cunoscute in avans
Orice modificare in biblioteca de testare trebuie stiuta inainte de a rula testele.
Erorile nu dau intotdeauna informatii despre posibilele schimbari ale aplicatiei.
Mai mult, uneori un test esuat poate fi un rezultat corect
De regula codul sursa al aplicatiei este gestionat de sistemul de management al

configuratiei ce inregistreaza toate schimbarile
Referentierea incrucisata a testelor la aplicatie
Identificarea schimbarilor necesare in testware se realizeaza prin referentierea

la elementele aplicatiei (folosind conventii si standarde de asignare consistenta
de nume)
De ex. Folosind consecvent acelasi nume pentru o fereastra oriunde in

biblioteca de teste, orice schimbare a sa se poate reflecta in intreaga
biblioteca
23

Proiectare cu evitarea regresiei
Schimbarile nu trebuie sa aiba un impact neprevazut asupra altor zone

ale aplicatiei
Impactul nedorit poate fi rezultatul unei proiectari defectuase a testarii

sau a implementarii (de ex. un script de testare ce selecteaza un
element dintr-o lista de optiuni bazat pe pozitia relativa a acestuia in
lista va esua daca ordinea sau numarul elementelor din lista esueaza. In
acest caz un script valid va cere introducerea optiunii selectate sau se
va baza pe valoarea sa text – “select list box item XYZ” si nu “click
window @451,687”)
Maintenabilitatea poate fi proiectata in cazurile de testare si scripturi

prin adoptarea unui intreg cadru de testare.
24
C8-9: 12

Optimizarea
La proiectarea testelor trebuie avut in vedere ca mai mult nu inseamna neaparat si
mai bine
Cu cat sunt mai multe teste, cu atat va dura mai mult sa le dezvoltam, executam si
intretine
Optimizarea garanteaza ca avem suficiente teste pentru a face treaba dar nu

avem excesiv de multe de intretinut
Elemente cheie:
1 test – 1 cerinta
Un test nu trebuie sa adreseze decat o zona controlata din aplicatie
In mod ideal, el trebuie sa acceseze o cerinta specifica de business sau de proiectare, sau
un defect raportat anterior
Permite executia selectiva a testelor
25

Lipsa cerintelor nu este o scuza
Absenta accesului la cerinte exprimate formal trebuie inlocuita cu un proces de

identificare a acestora
Se examineaza fiecare test si se stabileste ce caracteristica sau functionalitate o verifica –

acesta va fi considerata drept cerinta
Acest proces de asignare este important pentru ca trebuie identificate cazurile de testare
ce sunt afectate de modificarea unei anumite cerinte din aplicatie
Nu este deloc practic sa se revizuiasca fiecare caz de testare pentu a vedea care ramane
valid dupa schimbare
Intelegerea rezultatelor testarii
Un alt motiv de a preciza exact ce acopera fiecare caz de testare este ca daca un caz
esueaza el va reduce capacitatea de diagnosticare a cauzei erorii
 De ex. un test ce acopera mai multe caracteristici poate esua din multe cauze – timpul necesar
analizei caderii este direct proportional cu complexitatea cazului de testare in sine
26
C8-9: 13

Cerintele masoara disponibilitatea pentru lansare pe piata
Odata stabilite, cerintelor li se pot atribui prioritati si pot fi folosite pentru a masura cat de
pregatita este aplicatia pentru lansare pe piata
Legarea cerintelor de teste va micsora, de asemeni, confuzia - ce cerinte au fost

indeplinite sau nu in functie de rezultatele testarii. Va rezulta o simplficare a raportarii
logului pe erori.
Matricea cerintelor este o modalitatea manuala de a corela cerintele cu testele

asociate
O cerinta ce are prea multe teste este definita prea general si va trebui divizata in
mai multe cerinte, sau pur si simplu, are prea multe teste definite
Un test asociat la prea multe cerinte este prea complex si trebuie impartit in mai
multe teste care sa tinteasca mai precis cerinte specifice
27

Optimizarea numarului de cazuri de testare este facilitata de

utilitare ce genereaza cazurile de testare bazate pe cerinte
Exista 2 metode de abordare:
Sa se adreseze toate combinatiile posibile – permite

definirea facila a cerintelor, dar numarul de teste este mare
Sa se adrseze numarul minim de combinatii – produce

putine teste, dar solicita metode sofisticate de definire a
cerintelor cu specificarea relatiilor dintre acestea sub forma
analitica precisa pentru a permite optimizarea numarului de
cazuri de testare
28
C8-9: 14

Independenta cazurilor de testare – refera masura in care testele nu sunt

corelate, adica
Depinde succesul/esecul unui caz de testare de alt caz de testare si care este
impactul asupra secventei de executie?
Aceasta este o problema, deoarece ar trebui uneori sa se execute numai o parte

din cazurile de testare intr-un anume ciclu de testare
Daca exista corelatii, planificarea ordinii de executie devine un proces complex
Elemente cheie ale independentei:
Date independente – nici un caz de testare nu face referire la altul
Ex. testarea capabilitatii de stergere a unei inregistrari dintr-un fisier nu trebuie sa

depinda de cazul precedent ce testa crearea inregistrarii. In caz contrar, daca primul caz
de testare esueaza sau nu este executat, cele de-al doilea esueaza
 Solutie – fie starea de start a bazei de date trebuie sa contina inregistrarea sau ultimul test mai
intai adauga inregistrarea si apoi testeaza stergerea.
29

Context independent – la fel de importanta ca si independenta datelor
De ex. daca un test incepe dintr-o stare a aplicatiei in care s-a ajuns dupa
parcurgerea unui test preedent, acesta din urma poate esua daca precedentul
esueaza sau nu se executa
Cadrul de testare trebuie sa prevada puncte comune de intrare/iesire in diferitele zone ale
aplicatiei cu verificarea faptului ca testele corelate incep si se termina in aceste puncte
Independenta rezultatelor – rezultatul unui caz de testare nu trebuie sa depinda de

succesul unui alt caz
De ex. un caz de testare ce verifica absenta unui mesaj de eroare trebuie sa ofere garantia
ca nu a fost emis nici un alt fel de mesaj. In caz contrar trebuie sa prevada pasi de
stergere explicita a mesajului. Un caz de testare ce va urma si care presupune ca aplicatia
este gata pentru o operatie de intrare, desi ea este in stare de eroare, va da rezultate
eronate.
Atunci cand independenta totala nu este posibila sau de dorit , dependentele

trebuie bine documentate
30
C8-9: 15

Modularitatea – se refera la scripturile de testare si desemneaza o asamblare

eficienta a acestora in cadrul mediului de testare pentru a produce un sistem
unificat fara omisiuni sau elemente redundante
Elemente cheie:
Legarea proiectarii scriptului de proiectarea aplicatiei – structura scriptului

trebuie sa corespunda in linii mari cu structura modulelor din aplicatie.
Astfel, la modificarea aplicatiei, sa se poata localiza cat se poate de mult
schimbarea din script.
In functie de metoda de automatizare aleasa, acest lucru poate sa

insemne un script pentru fiecare fereastra sau fiecare tip de control ce
interactioneaza cu o fereastra, etc.
Modularitatea nu trebuie sa fie un scop in sine – se pierde semnificatia

individuala a scriptului
31

Identificarea scripturilor comune – functionalitatile comune in scripturi nu

trebuie duplicate in fiecare script ci partajate de intreg mediul de testare
Context – garanteaza ca executia testarii nu devanseaza executia aplicatiei
Verificarea contextului – deoarece testarea lucreaza cu intrari si verifica

iesiri, este imperativ ca intrarile sa se aplice locatiei adevate in aplicatie si
iesirile sa apara la locul asteptat.
La rularea in secventa a unor teste multiple rezultatul unui test poate
afecta testele urmatoare – de ex. daca un test incepe in meniul principal
si se termina intr-un submeniu al acestuia, testul urmator va trebuie sa
inceapa in submeniu pentru a nu risca esecul
32
C8-9: 16

Metoda meniului principal – cea mai simpla solutie de rezolvare a contextului este
sa se proiecteze toate testele sa inceapa si sa se termine in acelasi punct al
aplicatiei.
Acest punct trebuie sa fi o zona din care aplicatia poate fi accesata, in majoritatea
cazurilor meniul principal sau zona SIGNON
Proiectate cu start/stop in punct comun, testele pot fi rulate in orice ordine, fara a se lua
in considerare contextul
Facilitarea recuperarii din eroare – la esecul unui test, dupa inregistrarea erorii,
acesta poate apela o functie comuna de recuperare ce returneaza contextul intr-o
stare adecvata, pentru a permite executia urmatorului test.
Exista aplicatii complexe pentru care folosirea unui singur punct de context
ar complica prea mult scrierea testelor individuale
In acest caz se pot folosi mi multe puncte intermediare, dar functia de recuperare
se va complica prin introducerea logicii de localizare a punctului de context
La suite de testare acestea vor trebui combinate si pe criteriul punctului de context
comun
33

Diagrama recuperarii din eroare
34
C8-9: 17

Puncte cheie legate de context:
Testele automate, spre deosebire de testele manuale, nu pot emite judecati

despre pasul ce trebuie executat in secventa
Fara o logica consistenta de ghidare intre diferitele teste, ele nu isi vor
putea atinge scopul
Prin proiectare adecvata se poate
minimiza impactul unui test esuat asupra altora
Simplifica organizarea testelor in suite si cicluri
Observatie – prin test se intelege o combinatie de cazuri de testare si un

script de testare aferent
35

Sincronizarea intre testare si aplicatie – implica executia ambelor cu aceeasi

frecventa
Perfecta coincidenta nu este posibila deoarece conditiile de la reluarea

testelor sunt cel mai probabil diferite de cele de la crearea lor
De ex. daca traficul de date intr-un sistem se intensifica, timpul de

procesare creste si timpul de raspuns creste fata de un moment
anterior.
Daca testarea nu are mijloace sa compenseze fluctuatiile timpilor de

raspuns ai aplicatiei , orice test ce asteapta un raspuns intr-un anumit
orizont de timp va esua.
Sincronizarea se complica atunci cand sunt implicate in testare mai multe

masini de calcul- sincronizarea cu masina locala difera de sincronizarea
cu o masina remote sau cu un server de retea
36
C8-9: 18

Puncte cheie ale sincronizarii:
Indicatori globali – sincronizarea locala poate fi realizata prin introducerea unui

timp de asteptare pana ce aplicatia opreste procesarea
In Windows se poate astepta pana ce un cursor de scurgerea timpului afiseaza sfarsitul
unei operatii – din nefericire multe aplicatii nu au prevazute astfel de cursoare in diferite
puncte de executie
In alte situatii utilitarul de testare verifica daca aplicatia nu mai proceseaza – se
recomanda introducerea in mediul de testare a abilitatii de verificare a sincronizarii cu
diferite subseturi ale aplicatiei in circumstante diferite, inainte de a dezvolta un numar
insemnat de teste
Indicatori locali – exista utilitare ce permit inserarea de stari WAIT intre ferestre
sau chiar intre controale, determinand scriptul sa isi suspende reluarea pana la
afisarea unei anume ferestre sau control.
Metoda este mai fiabila - nu se bazeaza pe comportamentul global ce poate sa nu fie

consistent
Implica disponibilitatea unui mecanism de determinare scurgerii unui interval de timp
37

Indicatori remote - cand se lucreaza cu masini de calcul in retea sincronizarea se

realizeaza la alta dimensiune
De ex. aplicatia locala trimite o cerere de date catre server - in timp ce asteapta ea nu
este in starea “busy” si poate produce un indicator ca si-a terminat executia sau este gata
pentru o intrare.
Rezolvarea consta in folosirea unor drivere specifice protocoalelor de comunicatie ce

monitorizeaza direct starea masinii locale.
Daca utilitarul de testare nu poate monitoriza direct aplicatia locala, trebuie modificate
scripturile astfel incat sa detecteze starea aplicatiei prin mijloace specifice cum ar fi
asteptarea producerii unei anumite date.
Sincronizarea este proprie testarii automate.
Daca se testeaza manual, operatorul va astepta instinctiv aplicatia sa devina

pregatita pentru urmatoarea testare
Testarea automata are nevoie de tehnici de luare a unei astfel de decizii intr-o
maniera consistenta in raport cu situatiile ce pot aparea.
38
C8-9: 19

Documentarea testarii – reprezinta, ultimativ, informatia necesara executiei

manuale a testelor in conditii de criza.
Poate fi sub forma de comentarii extensive introduse in scripturi si cazuri de

testare sau descrieri narative memorate in teste sau in fisiere de documentare
separate
In functie de metoda de automatizare aleasa, tipul de documentare poate varia
Puncte cheie referitoare la documentare:
Documentare pentru trasferabilitate – simpla citire a scripturilor nu indica toate

actiunile din testare
De ex. n script capture/playback poate sa nu indice ca o fereastra este asteptata intr-un
anume punct. Scriptul indica doar ca un click pe mouse este efectuat intro anume locatie.
Trecerea de la un tester ce a creat si cunoaste scriptul la altul devine dificila
39

Acumularea testelor “misterioase” – paradoxal, cand nu se stie ce face un

test si de ce, exista tendinta de a nu fi sters. Aceasta determina ajungerea
la volume mari de teste ce nu sunt folosite, dar trebuie memorate,
gestionate si intretinute.
“Mai mult inseamna mai bine” – cu exceptia folosirii de elemente de

testare de biblioteca, cu cat documentarea este mai extensiva cu atat mai
bine.
Documentare in context – cea mai buna forma de documentare este cea

plasata direct in teste. Exista utilitare ce permit documentarea chiar si la
creare scripturi capture/playback
40
C8-9: 20

Curs8 - 9 - Testarea Automata Versus Testarea Manuala

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Curs8 - 9 - Testarea Automata Versus Testarea Manuala

Încărcat de

Drepturi de autor:

Formate disponibile

Testarea produselor software

Investeşte în oameni ! AMPOSDRU

Proiect cofinanţat din FONDUL SOCIAL EUROPEAN

Testarea Produselor Software

Curs 8 -9 – Testarea automata versus testarea manuala

<Testarea Produselor Software>

Obiectivul 2: testare manuala versus testare automata

Obiectivul 3: elemente de baza in testarea automata:

Obiectivul 3.1: despre cele 2 discipline implicate – testare si automatizare

Obiectivul 3.2: capacitatea de intretinere a testelor automate

Obiectivul 3.3: optimizarea procesului de creare a testelor automate

Obiectivul 3.4: independenta cazurilor de testare

Obiectivul 3.5: modularitatea scripturilor de testare

Obiectibul 3.6: sincronizarea intre executia testelor si cea a aplicatiei

Obiectiv 3.7: documentare testware

Subiecte tratate: necesitatea automatizarii procesului de testare, testare automata – aplicare si

<Testarea Produselor Software>

Presiunea pietii referitoare la livrarea de noi functionalitati si aplicatii software

Termene de predare din ce in ce mai stranse

In contextul unor resurse fixe sau chiar in diminuare

Testarea manuala, vazuta mult timp ca singura solutie in asigurarea calitatii

Intarzie lansarea pe piata a produsului

Induce cheltuieli semnificative, mai ales pentru descoperirea efectelor laterale

Nu reuseste descoperirea tuturor defectelor

Nu poate simula conditii de utilizare concurenta, intensiva a unei aplicatii

<Testarea Produselor Software>

Majoritatea produselor software necesita testare

repetata, pe multiple platforme software/hardware,

dupa schimbari ulterioare, la lansarea unei noi versiuni pe piata

Executa o secventa de actiuni fara interventie umana

Pot simula utilizarea aplicatiei in conditii de simultaneitate ridicata cu costuri

<Testarea Produselor Software>

Desi este costisitor sa livrezi un produs pe piata cu intarzieri datorate

Daca nu exista resursa umana si de timp pentru a demara o testare adecvata,

Prima atentie a producatorului de software este sa livreze produse fiabile.

Daca un produs nu merge nu conteaza cat de repede sau de ieftin il livrezi!

<Testarea Produselor Software>

Acoperirea tuturor etapelor de testare de la conceptie pana la lansare

Posibilitatea simularii testarii cu mai multi utilizatori

Posibilitatea repetarii testelor

Acoperire cumulativa in detectia erorilor

Cresterea sigurantei in produs

Costurile pentru activitati suport si pentru reluare activitati

Probabilitatea de producere de erori critice

<Testarea Produselor Software>

Acoperirea cumulata pentru testele executate

Observatie: riscul maxim intr-o aplicatie il reprezinta, paradooxal, caracteristicile

Beneficiile automatizarii, in acest caz, se pierd pentru teste automate ce nu

<Testarea Produselor Software>

Generarea si executia sistematica a unui numar extrem de mare de teste –

Un proces de automatizare a testarii permite crearea si rularea a mii de teste si

Pentru garantarea succesului va trebui:

 proiectarea adecvata a testelor si scripturilor de testare pentru a permite

<Testarea Produselor Software>

Scurtarea timpului pana la punerea pe piata a produsului software

Executia testelor se face in regim 24x7

Imediat ce biblioteca de testare este automatizata – executia este mai rapida

Reducerea costurilor legate de caderea aplicatiei

Automatizarea testarii intervine prin garantarea unui grad sporit de acoperire

Ce nu este un beneficiu al testarii automate – reducerea resurselor de testare

<Testarea Produselor Software>

Aplicatii instabile prin design

Atunci cand datele si mediul de testare al unei aplicatii nu poate fi controlat,