Testarea produselor software Testarea produselor software Testarea produselor software

<Testarea Produselor Software> <Testarea Produselor Software>

UNIUNEA EUROPEANĂ GUVERNUL ROMÂNIEI Fondul Social European Instrumente Structurale OIPOSDRU UNIVERSITATEA
Cadrul de testare – definitie <Gabriela Varvara> Functii comune <Gabriela Varvara>
MINISTERUL MUNCII, PSD DRU 2007 - 2013 2007 - 2013 TEHNICĂ DE
FAMILIEI ŞI CONSTRUCŢII DIN
PROTECTIEI SOCIALE BUCUREŞTI

Investeşte în oameni ! AMPOSDRU

¾Este asemanator arhitecturii software pentru o aplicatie ¾SETUP – pregateste mediul pentru executie
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 ¾Contureaza structura globala a mediului de testare automata ¾Executat la fiecare inceput de ciclu de testare
PE CUNOAŞTERE”
Domeniul major de intervenţie 1.2 „Calitate în învăţământul superior”
¾Defineste functiile comune si testele standard
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 ¾Verifica:
masterat, din
di domeniul
d i l Ingineria
I i i Sistemelor
Si l
Numărul de identificare al contractului: POSDRU/86/1.2/S/63806
¾Furnizeaza sabloane de structura pentru teste
¾Prezenta unei configuratii adecvate
¾Precizeaza regulile de baza de denumire, documentare si gestiune teste
Gabriela Varvara ¾Instalarea versiunii corecte a aplicatie
Testarea Produselor Software
¾Fisierele necesare sunt disponibile
¾Necesitate – in majoritatea situatiilor testerul nu are un background tehnic legat
Curs 10-12 – Testarea automata: de tehnicile de dezvoltare structurata a aplicatiilor software ¾Toate fisierele de lucru si temporare sunt sterse
Cadru de lucru
¾Cadrul prezentat in curs poate fi aplicat oricarei metode de automatizare; ¾Efectueaza taskuri de intretinere: backup pe fisiere permanente, initializeaza
Managementul bibliotecii de teste
diferenta de la o metoda la alta rezida in modul de structurare a cazurilor de valori ale datelor, realizeaza sortari ce imbunatatesc performantele bazei de
Selectia metodei de automatizare testare individuale si a scripturilor de testare. date, etc.
Procesul de automatizare
Partener P4 ¾Trebuie proiectata sa inceapa si sa se termine in punct cunoscut (ex.
Managerul de program sau la o comanda in linia de comanda)

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 3 5

<Testarea Produselor Software> <Testarea Produselor Software> <Testarea Produselor Software>

Obiective curs : <Gabriela Varvara> Functii comune <Gabriela Varvara> Functii comune <Gabriela Varvara>

Obiectivul 1: prezentare concepte legate de cadrul de testare ¾SIGNON – incarca aplicatia si verifica daca aceasta este disponibila pentru
¾Sunt
Definitii si functionalitati generale executie
¾Rutine ce automatizeaza sarcini comune tuturor testelor din biblioteca
Teste standard ¾Poate solicita ID si parola utilizator pentru acces la aplicatie dupa terminarea
¾Recuperare din erori neprevazute, inregistrare rezultate testare (log-uri), etc. rutinei SETUP
Sabloane de testare

Obiectivul 2: prezentare mecanisme de management a bibliotecii de teste

¾Sunt structurate ca subrutine – pot fi apelate din orice punct si vor avea return in ¾Opereaza aplicatia catre un alt punct cunoscut, cum ar fi zona de meniu
pasul urmator celui din care au fost apelate
principal
Controlul schimbarilor, versiunilor , managementul configuratiei
¾Scripturi utilitare
Obiectivul 3: notiuni de baza privind alegerea metodei de automatizare: ¾Poate fi folosita pentru pornirea unui timer ce masoara durata ciclului curent
¾refresh pe baza de date, popularea bazei de date cu seturi de inregistrari de testare
Metode: “capture/playback”, “data-driven”, “table-driven”
cunoscute, stergerea fisierelor temporare de lucru, gestiune mediu de testare
Obiectivul 4: procesul de automatizare a testari
¾Trebuie executata dupa SETUP la inceputul fiecarui ciclu de testare
¾Definirea si partajarea acestor scripturi
Echipa, plan ciclu de testare ¾Maii poate
¾M t fi apelata
l t ca parte
t a secventeit i de
d recovery in
i cazull in
i care un esec
¾Reduce si simplifica dezvoltarea si intretinerea testware al testului necesita terminarea si, apoi, restartarea aplicatiei.
Subiecte tratate: cadrul de testare, biblioteca de teste, selectia metodei de testare automatizata,
proiectare suita/ciclu testare ¾Trebuie gandite sa poata fi executate fie de sine statator, fie in conexiune
secventiala, ca parte componenta a unui ciclu de testare integrat.

2 4 6

C10-12: 1 C10-12: 2 C10-12: 3

Testarea produselor software Testarea produselor software Testarea produselor software

Functii comune <Testarea Produselor Software>

Functii comune <Testarea Produselor Software> <Testarea Produselor Software>
<Gabriela Varvara> <Gabriela Varvara> Teste standard <Gabriela Varvara>
¾DRIVER – apeleaza un numar de teste in forma unei suite sau a unui ciclu ¾SIGNOFF – actiune opusa SIGNON; termina aplicatia, comuta sistemul catre un ¾Extind conceptul de functie comuna:
punct cunoscut (manager programare sau prompter in linia de comanda)
¾Nu toate utilitarele furnizeaza aceasta facilitate – daca nu exista, trebuie
planificata si dezvoltata o astfel de functie. ¾O functie comuna este partajata intre teste
¾Trebuie folosit la sfarsitul ultimei suite de teste, inaintea executiei altor rutine
partajate, cum ar fi CLEANUP ¾Un test standard este partajat intre suitele de
¾Ideal, aceasta functie se bazeaza p
pe un fisier de date sau p
pe o alta modalitate
de memorare a listei testelor de executat impreuna cu ordinea de executie ¾Poate opri timerul ciclului de testare, oferind astfel o masura a duratei de testare, cicluri de testare sau chiar aplicatii
executie a ciclului curent
¾Daca se foloseste o functie DRIVER, fiecare test va fi proiectat sa ajunga in ¾Ex. Fiecare biblioteca de teste poate include un test
functia DRIVER cand se termina, pentru a permite apelul urmatorului test ¾LOGTEST – apelata la sfarsitul fiecarui caz de testare/script testare pentru
inregistrarea rezultatelor componentei executate standard care sa efectueze un walkthrough complet pe
¾MONITOR – verifica starea sistemului (mesaje/evenimente asincrone ce nu sunt
asteptate: caderi, exceptii, etc.) aplicatie (vizualizeaza, pe rand, fiecare meniu si in acesta
¾Poate returna pe langa starea pass/fail si intervale de timp de executie sau
alte masuri. fiecare fereastra sau componenta de control). Desi un astfel
¾Poate fi apelata
p dupa
p trimiterea oricarei tranzactii sau la intervale regulate
g
¾Rezultatele pot fi memorate intr-un fisier text, clipboard, sau orice alt mediu de test poate fi partajat intre toti testerii, nu este necesar sa
¾ poate fi
ce poate fi folosit ulterior pentru deducerea rapoartelor
fie dezvoltat de fiecare din acestia.
¾pentru aplicatii desktop – linia de stare
¾Poate fi integrata in utilitarul de testare; daca nu, trebuie dezvoltata si
¾Poate fi executat de sine statator sau ca parte a unei suite de testare
¾Pentu aplicatii de retea – zona broadcast pentru mesaje sistem implementata

7 9 11

<Testarea Produselor Software> <Testarea Produselor Software> <Testarea Produselor Software>

Functii comune <Gabriela Varvara> Functii comune <Gabriela Varvara> Teste standard <Gabriela Varvara>

¾RECOVER – poate fi apelata de functia LOGERROR sau orice script ce pierde ¾LOGERROR – functie apelata ori de cate ori un test esueaza ¾WALKTHRU – navigheaza prin aplicatie, verificand prezenta in starea implicita a
contextul in timpul executiei suitei de teste fiecarei componente de meniu, fereastra si control
¾Proiectata initial sa colecteze maximum de informatie despre starea aplicatiei
¾Incearca restaurarea contextului la o locatie cunoscuta, astfel incat testele la momentul erorii ( context actual versus context asteptat) ¾Se verifica de asemeni ca o versiune de lucru a aplicatiei sa fie instalata si ca
subsecvente sa poata fi executate nu exista obstacole majore in executia testelor functionale
i i maii sofisticate
¾Versiuni
¾V fi ti t pott pastra
t stiva
ti de
d apeluri
l i sau continutul
ti t l unor locatii
l tii
¾Permite ca executia testelor sa nu fie abandonata sau continuata cu de memorie pentru diagnosticare viitoare ¾Fiecare ciclu de testare poate beneficia de avantajele acestui test standard
producerea de si mai multe erori pentru a se asigura ca erorile operationale fatale sunt descoperite timpuriu si
¾Poate, de asemeni, sa apeleza functia RECOVER pentru restaurarea efortul de testare va fi orientat spre aspecte de detaliu.
¾Poate include un sistem de navigare prin aplicatie pentru regasirea unui contextului necesar urmatoarului test
punct predefinit ( ex. Meniul principal) sau poate opri si restarta aplicatia (caz ¾Poate fi executat de
in care RECOVER apeleaza scriptul SIGNON) ¾CLEANUP – asigura functionalitatea inversa SETUP, eliminand acumularea de
reziduuri generate de procesul de executie a testului ¾Grupul de dezvoltare dupa construirea sistemului si inainte de a fi inaintat grupului
¾Daca pasii de recuperare nu sunt standard se poate include mesaj vizual si/sau de testare
auditiv pentru alertare operator ¾Porneste dintr-un punct stabilit (manager program sau command promt) si
sterge mediul de testare (fisiere temporare sau de lucru), face backup pe ¾Grupul de suport productie dupa ce aplicatia a fost plasata pe mediul de productie
¾Proiectat corect, permite interventia operatorului fara a se interfera cu ciclul de fisierele rezultat
testare ce poate continua ( de ex. Mesajul afisat instruieste operatorul sa suspende
reluarea, sa comute contextul pe o fereastra particulara, sa reia executia) ¾Este eficient daca pastreaza mediul de testare organizat si eficace

8 10 12

C10-12: 4 C10-12: 5 C10-12: 6

Testarea produselor software Testarea produselor software Testarea produselor software

<Testarea Produselor Software> <Testarea Produselor Software> Exemplu de sablon completat ( din Lynda G. Hayes) <Testarea Produselor Software>
Teste standard <Gabriela Varvara> Sabloane de testare - definitie <Gabriela Varvara> <Gabriela Varvara>

¾STANDARDS – verifica aplicarea standardelor de proiectare pentru o ¾Furnizeaza structura dupa care vor fi dezvoltate testele individuale
componenta precizata
¾Sunt folosite pentru
¾Daca WALKTHRU verifica prezenta unor componente de meniu, ferestre si
controale grafice, STANDARDS verifica realizarea acestora conform ¾Cresterea vitezei de dezvoltare – un singur format ce poate fi copiat si
standardelor convenite a fi respectate anterior. completat
l t t rapid
id

¾Daca exista un criteriu de design ce solicita ca fiecare fereastra sa aiba buton ¾Promoveaza consistenta in dezvoltare si favorizeaza inlantuirea testelor in
de minimizare/maximizare, bara de derulare verticala si orizontala, butoane de mediul de testare
OK si CANCEL – acest lucru se va testa
¾De exemplu,
¾Acest tip de test poate fi executat de catre dezvoltatori in raport cu fiecare ¾Teste apelate ca subrutine de alte test trebuie sa permita revenirea in testul apelant
fereastra creata, ca parte a testarii pe modul/componenta.
¾Teste executate de pe un driver sau alt mecanism de control trebuie sa predea controlul
la sfarsitul executiei

¾Structura acestor sabloane difera de la o metoda de automatizare la alta

¾Exista, insa, elemente de structura comune indiferent de metoda abordata:

13 15 17

<Testarea Produselor Software> <Testarea Produselor Software> <Testarea Produselor Software>

Teste standard <Gabriela Varvara> Sabloane de testare – elemente comune <Gabriela Varvara> Harta aplicatiei <Gabriela Varvara>

¾TESTHELP – ca si STANDARDS poate fi folosit pentru fiecare ecran sau ¾HEADER – furnizeaza informatii de baza despre test pentru a permite executia ¾Numeste si descrie elementele constituente ale aplicatiei
fereastra. Verifica disponibilitatea functiei help in toate punctele aplicatiei . sau modificarea sa
¾Furnizeaza terminologia ce leaga testele de aplicatie
¾In raport de modul de actiune al functiei help (senzitiva pe context sau nu), ¾NEXT - pentru teste bazate pe fisiere externe – indica punctul in care se citeste
testul poate sa contina si logica suplimentara pentru a verifica raspunsul urmatoarea inregistrare din fisier ¾Cuprinde:
corect
¾Folosit ca punct de ramificare in test dupa terminarea executiei pentru o ¾Vocabular pentru testare
inregistrare
¾Precizeaza ce nume din aplicatie sunt folosite in testare si cu ce semnificatie

¾Daca in aplicatie exista mai multe zone cu o functionalitate similara, se pot ¾END – ultima sectiune executata inainte de terminare test ¾Conventii de nume – definire reguli de asignare a numelor
dezvolta si alte teste standard similare acestuia.
¾Pentru scripturi executate de sine statator poate fi doar STOP ¾Referinte incrucisate intre elementele de testare si cele din aplicatie
9Ca o concluzie, se justifica efortul si timpul in identificarea si dezvoltarea de
teste aplicabile
p cat mai extins p
pe aplicatie.
p ¾Pentru teste ce citesc fisiere externe – punct de ramificare pentru conditia ¾Orice modificare din aplicatie poate fi legata rapid de cazurile de testare potential afectate
EOF de modificare
9Prin dezvoltarea a cat mai multe functii si teste standard se faciliteaza
¾pentru teste partajate de alte rutine – comenzile necesare pentru a intoarce ¾Exemplu:
organizarea si standardizarea bibliotecii de teste
controlul catre apelant

14 16 18

C10-12: 7 C10-12: 8 C10-12: 9

Testarea produselor software Testarea produselor software Testarea produselor software

<Testarea Produselor Software> <Testarea Produselor Software> <Testarea Produselor Software>

Managementul bibliotecii de teste <Gabriela Varvara> Managementul bibliotecii de testare - Controlul versiunilor <Gabriela Varvara> Alegerea metodei de automatizare a testarii <Gabriela Varvara>

¾Pentru a avea valoare pentru o organizatie, toate scripturile de testare precum si ¾Impusa de: ¾Practica testarii a condus la formalizarea a 3 metode de baza in corelatie cu
alte date si informatii legate de o aplicatie se impun memorate intr-o biblioteca starea aplicatiei, a procesului de testare si cu expertiza echipei de testeri:
ce va completa biblioteca cu sursele aplicatiei ¾La un moment de timp mai mult decat o singura versiune a aplicatiei poate fi ¾Capture/Playback
supusa testarii
¾Managementul unei biblioteci de testare include: ¾Aplicatie in faza de testare sau intretinere – stare stabila
¾(corectii pot fi ada
adaugate
gate versiunii
ersi nii c
curente,
rente in timp ce imb
imbunatatiri
natatiri sunt
s nt ada
adaugate
gate versiunii
ersi nii
¾Documentare sumara sau inexistenta a procesului de testare
urmatoare)
1. Controlul schimbarilor – schimbarile se opereaza doar de catre persoane
¾Echipa de testare, majoritar netehnica
autorizate, sunt documentate si nu se realizeaza concurent in copii diferite ¾In orice moment va trebui aplicata versiunea corecta a bibliotecii de teste asupra
cu producere de suprascriere unei anumite versiuni a aplicatiei ¾Data-driven
¾Aplicatie in faza de codificare sau inceput de testare – stare oarecum stabila
2. Controlul versiunilor - asigura pastrarea separata a testelor pentru versiuni ¾Implica intretinerea unui numar crescut de versiuni pentru biblioteca de teste
diferite ale aceleasi aplicatii ¾Documentare sumara sau buna a procesului de testare
¾Echipa de testare mixta – tehnic/nontehnic
3. Managementul
g configuratiei
g – evidentiaza orice schimbare survenita in
mediul de testare ¾Table-Driven
¾Aplicatie in fazele de planificare, analiza sau proiectare – stare instabila
¾Documentare buna a procesului de testare
¾Echipa de testare in majoritate netehnica

19 21 23

<Testarea Produselor Software> <Testarea Produselor Software> <Testarea Produselor Software>

Managementul bibliotecii de testare - Controlul schimbarilor <Gabriela Varvara> Managementul bibliotecii de testare - managementul configuratiilor <Gabriela Varvara> Alegerea metodei de automatizare a testarii <Gabriela Varvara>

¾Desemneaza procesul ordonat de introducere de modificari in biblioteca de teste ¾Un test complet verifica mai mult decat aplicatia insasi – ultimativ testeaza intreg
mediul de executie, incluzand echipamentul suport si soft-ul conex
¾Schimbarea trebuie documentata pentru a se cunoaste natura acesteia, cine a ¾Metodele descriu optiuni posibile ce pot fi combinate spre a se raporta unei
facut-o, cand si de ce ¾Caracteristici de mediu precum –sistemul de operare de pe statia de lucru/server, situatii concrete
g
configuratia hardware,, protocolul
p de retea si conexiunile echipamentelor,
p , starea
t ad
¾Pentru
¾P documentat natura
t schimbarii
hi b ii se recomanda d includerea
i l d unuii fisier
fi i bazei de date – influenteaza derularea aplicatiei ¾O singura
i bibli t
biblioteca d teste
de t t poate
t contine
ti teste
t t ce au fost
f t proiectate
i t t prin
i
delta ce contine diferentele intre modulul vechi si cel nou metode diferite
¾Este riscanta testarea pe un mediu diferit de cel de productie
¾Un minim de explicatie asupra ceea ce s-a schimbat si unde trebuie furnizat
¾Reproducerea in conditii de duplicare perfecta este dificila – trebuie
¾Trebuie sa existe o inregistrare a schimbarilor (scrisa/electronic) cunoscute, insa, diferentele – ajuta in localizarea erorilor ¾Recomandari:

¾Operatiile de backup pot inlatura schimbarile neintentionate sau eronate ¾Drept consecinta, managementul configuratiei mediului de testare este crucial ¾Trebuie plecat de la starea curenta, indiferent de cat de departe se doreste
pentru pastrarea integritatii procesului de testare. implementarea automatizarii
¾Se verifica
erifica adaugarea
ada garea doar de teste ce a
au fost e
executate
ec tate c
cu s
succes
cces macar o data
¾Nu este suficienta cunoasterea versiunii de aplicatie ce este supusa testarii – ¾Cu ceva planificare apriorica, este posibil sa se migreze de la o metoda la
¾Trebuie sa existe o concordanta intre log-ul schimbarilor pe aplicatie si cel alta, in masura in care timpul si expertiza o permit
aferent testelor din biblioteca trebuie cunoscuta si versiunea configuratiei de operare

¾Ajuta la pastrarea integritatii bibliotecii

20 22 24

C10-12: 10 C10-12: 11 C10-12: 12

Testarea produselor software Testarea produselor software Testarea produselor software

<Testarea Produselor Software> <Testarea Produselor Software> <Testarea Produselor Software>

Automatizare prin metoda Capture/Playback <Gabriela Varvara> Automatizare prin metoda Capture/Playback <Gabriela Varvara> Automatizare prin metoda Capture/Playback <Gabriela Varvara>

¾Testele sunt executate mai intai manual in timp ce intrarile si iesirile sunt
capturate in background
¾Viata utila script scurta – desi nu este necesara cunoasterea limbajului de scriptare
¾Ulterior se reia in mod automat scriptul - acesta va face aceleasi actiuni asupra a utilitarului folosit cand se captureaza scripturi, e absoluta necesar sa fie
noilor intrari si va compara rezultatul curent cu rezultatele inregistrate anterior cunoscut cand se fac modificari in scripturi. Drept consecinta, testerii vor prefera
sa inlature un script vechi si sa recaptureze un nou script decat sa il modifice pe
¾Diferentele sunt raportate ca erori cel vechi. Rezulta astfel si o pierdere din punct de vedere al testarii cumulative.

¾Metoda este disponibila pentru aproape toate utilitarele de testare automata
¾Intrarile - selectii de meniuri, butoane radio, liste de selectie, cutii de verificare,
sau simple butoane, apasari/ridicari ale tastelor si iesirea asteptata – sunt
memorate in script
¾Avantaje: ¾Scripturile nu contin elemente decizionale – la momentul capturii unui script, toate
deciziile de urmat sunt luate de operatorul de testare si nu apar explicit in script.
¾Timp minim de antrenare pe metoda (chiar si pentru testeri non-tehnici) si de setup Drept consecinta, orice esec al testului, produs adesea de un context impropriu,
determina parasirea sesiunii curente cu invalidarea rezultatelor tuturor testelor
¾Testele pot fi dezvoltate din mers – permite utilizatorilor experimentati sa ulterioare. Va trebui timp si efort pentru revizuirea caderilor false.
contribuie in mod ad-hoc la procesul de testare

¾Furnizeaza un traseu excelent pentru auditare in cazul testarii ad-hoc si de

uzabilitate; daca apare o eroare, pasii ce au dus la aparitia ei pot fi capturati pentru
o diagnoza viitoare sau pentru reproducerea conditiilor de eroare

25 27 29

<Testarea Produselor Software> <Testarea Produselor Software> <Testarea Produselor Software>

Automatizare prin metoda Capture/Playback <Gabriela Varvara> Automatizare prin metoda Capture/Playback <Gabriela Varvara> Automatizare prin metoda Capture/Playback <Gabriela Varvara>

¾Pentru a facilita distributia unui script intre mai multi testeri, trebuie respectate
urmatoarele reguli :
¾1 script pentru o cerinta - permite corelarea numelui scriptului cu cel al
cerintei
¾Asocierea scripturilor de o anumita zona din aplicatie
¾Faciliteaza impachetarea acestor teste legate prin caracteristici comune intr-o suita de
teste
¾Permite orientarea unui tester catre anumite zone ale sistemului
¾Simplifica intretinerea ulterioara ori de cate ori sunt necesare schimbari
¾Scripturile sa fie apelabile
¾Daca utilitarul de automatizare nu are facilitatea de build-in (legarea scripturilor in suite
si/sau cicluri de testare), atunci fiecare script va trebui construit sa poata fi apelat de alt
script. Ulterior poate fi creat un script master (sau driver) care sa contina o serie de
apeluri de executie pentru scripturi individuale.
¾Dezavantaje:
¾Captura testelor se face prin executia manuala a acestora – nu exista avantaje
privind timpul de testare (in ex. prezentat, secventa de pasi trebuie repetata pentru
fiecare cont adaugat/actualizat/sters)
¾Aplicatia trebuie sa fie stabila – nu exista suport de detectarea timpurie a erorilor
¾Redundanta si omisiune – in lipsa unei strategii globale de testare, daca alegerea
functiilor de testat e lasata la alegerea testerilor, cu mare probabilitate vor fi zone
intens testate si altele neacoperite
¾Testele trebuie combinate – in absenta unor conventii pentru nume si a unor
standarde de dezvoltare a scripturilor, pot fi teste suprascrise ce aduc complicatii
cand se incearca executia lor in acelasi set
¾Maintenabilitate scazuta a scripturilor – deoarece intrarile si iesirile sunt codificate
la nivel de actiune fizica in scripturi, mici schimbari ale aplicatiei pot invalida
grupuri mari de teste (ex. daca se modifica numarul de secvente de control dintr-o
fereastra, poate fi afectat orice test ce o traverseaza – o fereastra ce are 100
tranzactii de testare de executat determina macar 100 de modificari in teste)
Consideratii privind modul de evaluare teste
¾Ipoteza asumata – comportamentul capturat la crearea scriptului reprezinta
rezultatul corect, deci cel asteptat.
¾Pentru a aplica aceasta ipoteza,
ipoteza trebuie in prealabil:
¾Sa se identifice ce rezultate vor fi verificate – pentru aplicatii cu ecran fix si
informatii afisate textual poate fi verificat tot ecranul; pentru aplicatii grafice doar o
zona selectata. In ambele cazuri e dificil de spus care este zona pertinenta a fi
comparata si care nu.
¾Sa se foloseasca, ori de cate ori este posibil, informatie text in locul formatului
bitmap – comparatiile intre ferestre in formatul bitmap sunt impractice (cantitate
mare de informatie, dependenta de rezolutie, caracterul volatil al plasarii imaginii
pe ecran de catre un manager de pozitionare)
¾Verificarea includerii in locul excluderii – sa se defineasca ce sa aiba rezultatul si
nu ce sa nu aiba. Rezulta teste simple si lipsite de ambiguitate in validare. Nu
trebuie cazut insa in extremitatea minimalismului, ce ar permite scaparea unor
erori

26 28 30

C10-12: 13 C10-12: 14 C10-12: 15

Testarea produselor software Testarea produselor software Testarea produselor software

<Testarea Produselor Software> <Testarea Produselor Software> <Testarea Produselor Software>

Automatizare prin metoda Capture/Playback <Gabriela Varvara> Automatizare prin metoda Data-Driven <Gabriela Varvara> Automatizare prin metoda Data-Driven - structura <Gabriela Varvara>

Consideratii privind datele – deoarece aceasta metoda presupune ca aceleasi
intrari produc aceleasi iesiri, starea datelor este critica:
¾Datele statice – ciclul de testare trebuie sa contina pasi care sa aduca baza de
date la o stare cunoscuta (reactualizare cu o copie noua sau populare cu
inregistrari cunoscute)
¾Datele dinamice – exista date ce sunt generate dinamic de aplicatie si care
vor avea o valoare la captura testului ce nu va mai fi reprodusa de aplicatie la
oricare alta reluare a sa. Se recomanda
¾Folosirea variabilelor – pentru lucrul cu date create dinamic. Acestea vor inlocui
datele fixe de la captura atunci cand se vor relua testele. Necesita un tester care sa
cunoasca ce valori dinamice ar trebui sa apara la fiecare reluare a executiei unui
test.
¾Exemplu : ¾Pentru a defini cazurile de testare ca inregistrari intr-un fisier cu date extern
scriptului , elementele de date din aplicatie asociate fiecarui proces trebuie
¾porneste de la scriptul capture/playback precedent modificat sa adauge un fisier cunoscute. Acest lucru se realizeaza prin intermediul hartii aplicatiei.
extern si sa inlocuiasca valorile fixe cu variabile
¾De asemeni trebuie sa se respecte urmatoarea structura:
¾1 script pentru 1 proces – metoda este legata de o singura secventa de procesare
ce suporta mai multe cazuri de testare
¾ 1 inregistrare din fisierul extern reprezinta un caz de test al carui identificator este
memorat in fisier. Permite unui script sa proceseze mai multe cazuri de test si sa
inregistreze rezultatele in fisierul log.
¾Aplicatia sa utilizeze datele in mod intensiv ( aceeasi pasi in aplicatie se repeta de
un numar mare de ori cu date diferite)
¾Nu exista diferente semnificative intre secventele de actiuni derulate pentru intrari
diferite. Daca un camp din intrare ar determina procesari diferite pentru fiecare
valoare a sa, volumul de logica necesar procesarii fiecarui caz de test ar creste
exponential.

31 33 35

<Testarea Produselor Software> <Testarea Produselor Software> <Testarea Produselor Software>

Automatizare prin metoda Data-Driven <Gabriela Varvara> Automatizare prin metoda Data-Driven <Gabriela Varvara> Automatizare prin metoda Data-Driven <Gabriela Varvara>

Avantaje in comparatie cu metoda Capture/Playback:

¾Daca in metoda Capture/Plaback intrarile si iesirile sunt fixe, la metoda Data- ¾Fisierul cu variabile fiind: ¾Permite crearea timpurie a cazurilor de testare
Driven ele sunt variabile.
¾Aplicatia nu trebuie sa ajunga la un anumit grad de stabilitate pentru a crea
¾Aceasta
¾A t este
t realizata
li t prini executiati manualal a testului
t t l i si,
i apoi,
i prin
i inlocuirea
i l i cazurile de testare sub forma de fisiere de date
date. Doar crearea scriptului curent
intrarilor capturate si iesirilor asteptate cu variabile ale caror valori sunt memorate trebuie sa astepte aplicatia.
in fisiere de date externe scriptului.
¾Flexibilitate in crearea cazurilor de testare
¾Secventa de actiuni ramane fixa si este memorata in scriptul de testare
¾Fisierul cu cazuri de testare poate fi in formate diferite ( foaie de calcul, word, baza
de date, etc). Crearea acestuia nu implica expertiza in lucrul cu utilitarul de testare

¾Metoda este disponibila pe majoritatea utilitarelor de testare ce folosesc un ¾Efort minim cu efect maxim
limbaj de scriptare cu facilitatea de date variabile,
variabile dar nu este posibila cu utilitare
¾Un singur script de testare poate aplica mai multe cazuri de test. Mai mult, cazuri
destinate exclusiv metodei Capture/Playback.
de testare pot fi adaugate ulterior fara modificarea scriptului de testare.

¾Costuri de intretinere reduse

¾Nu repeta secventele de actiuni si logica pentru fiecare caz de testare

32 34 36

C10-12: 16 C10-12: 17 C10-12: 18

Testarea produselor software Testarea produselor software Testarea produselor software

<Testarea Produselor Software> <Testarea Produselor Software> <Testarea Produselor Software>

Automatizare prin metoda Data-Driven <Gabriela Varvara> Automatizare prin metoda Table-Driven <Gabriela Varvara> Automatizare prin metoda Table-Driven <Gabriela Varvara>

¾Metoda impune

Dezavantaje: ¾Difera de metoda Data-Driven prin faptul ca setul de actiuni necesar procesarii ¾cunoasterea elementelor de tip date din aplicatie (similar cu Data-Driven)
datelor este si el memorat intr-un fisier extern si nu in script.
¾Implica expertiza in lucrul cu utilitarul de testare ¾Denumirea si definirea ferestrelor, meniurilor si tipurilor de obiectelor grafice de
¾C i t – parcurgerea testului
¾Consecinta t t l i este
t complet
l t automatizata
t ti t lucru precum si a metodelor ce pot fi aplicate pe acestea
¾Pentru a transforma un script spre al face sa proceseze date variabile integrate din
¾ in fazele incipiente de dezvoltare tipurile de obiecte si metodele pot sa nu fie cunoscute,
fisiere externe, trebuie ca macar un membru al echipei de testare sa aiba abilitati ¾Intrarile si iesirile asteptate si secventele de actiuni sunt create ca inregistrari de dar nu impiedica dezvoltarea cazurilor de testare sub forma de referinte catre intrari si
de lucru in aceasta directie date iesiri precizate ulterior

¾Implica expertiza in managementul fisierului ce contine cazurile de testare
¾Acest lucru poate insemna cunostinte in manipulare
¾macrouri Excel, sabloane de procesare word sau formulare de lucru cu bazele de date
¾operatii de export date in format compatibil cu utilitarul de testare
¾Drept consecinta, scripturile de testare sunt ¾Structura :
¾Rutine executate secvential ce au la baza date de test
¾1 fisier cu date de test si mai multe scripturi – un singur script poate fi procesat de mai
¾Reutilizabile pentru mai multe aplicatii multe scripturi (comune, standard, master, legate de o anumita metoda). Fiecare obiect si
metoda are un scriptp ce contine comenzile si logica
g de executie a acestuia
¾Complet generice – se bazeaza pe tip camp/obiect si actiunea de efectuat ; instanta
¾Mai multe inregistrari formeaza 1 caz de testare - un singur caz de testare este memorat
camp/obiect este definita in harta aplicatiei si furnizata rutinei cand este executat
testul. prin mai multe inregistrari, fiecare inregistrare reprezentand un singur pas. Identificatorul
cazului de testare trebuie memorat in fiecare inregistrare a sa ( vezi slide urmator). In
acest fel, un singur set de scripturi va putea procesa mai multe cazuri de testare.
Rezultatele testarii vor fi inregistrate dupa fiecare pas si nu la sfarsitul cazului de testare

37 39 41

<Testarea Produselor Software> <Testarea Produselor Software> <Testarea Produselor Software>

Automatizare prin metoda Data-Driven <Gabriela Varvara> Automatizare prin metoda Table-Driven <Gabriela Varvara> Automatizare prin metoda Table-Driven <Gabriela Varvara>

¾Exemplu:
Considerente privind datele:

¾deoarece datele de testare sunt memorate in fisiere externe , trebuie sa existe

un mecanism
i eficient
fi i t de
d crare/intretinere
/i t ti date
d t cu respectarea
t urmatoarelor
t l
reguli:

¾Lucrul cu 1 script – 1 fisier date

¾Continutul si formatul fisierului (macrouri, sabloane, formulare) trebuie definit pentru

creare/intretinere facila. Cu cat procesul de lucrul cu fisierele este mai simplu, cu atat
adaugarea/modificare cazurilor de testare este mai simpla

¾Folosirea fisierelor multiple

¾Un script poate prelua cazuri de testare din mai multe fisiere. In acest caz logica scriptului
se modifica cu includerea de cicluri de procesare pentru fiecare fisier extern de date.

Scriptul SELECT_MENU:

38 40 42

C10-12: 19 C10-12: 20 C10-12: 21

Testarea produselor software Testarea produselor software Testarea produselor software

<Testarea Produselor Software> <Testarea Produselor Software> <Testarea Produselor Software>

Automatizare prin metoda Table-Driven <Gabriela Varvara> Automatizare prin metoda Table-Driven <Gabriela Varvara> Procesul de automatizare a testarii <Gabriela Varvara>

Avantaje: Dezavantaje : Echipa de testare

¾Principalul avantaj – intretinere flexibila si completa ¾Cere cunostinte avansate si experienta de programare si expertiza in lucrul cu ¾Pe langa selectia unei metode de testare, este deosebit de importanta alegerea
utilitarul de testare echipei de testare
¾Dezvoltarea in faze incipiente ale dezvoltarii ale cazurilor de testare si scripturilor
¾Pentru proiectarea si construirea bibliotecii de scripturi modulare trebuie avute ¾M b ii trebuie
¾Membrii t b i sa aiba
ib
¾Cazurile de testare pot fi create chiar din faza de inginerie a cerintelor si memorate cunostinte de programare, de logica a legarii acestora impreuna si executie
in fisiere controlata cu ajutorul fisierelor externe ¾abilitatile cerute de rolul lor in echipa

¾Scripturile ce proceseaza datele pot fi create de indata ce obiectele ( ecran, ¾Managementul datelor este critic ¾autoritatea de a-si duce la bun sfarsit responsabilitatea
fereastra, controale) si metodele au fost definite (de exemplu seful echipei trebuie sa poata
¾Deoarece toate informatiile sunt memorate ca date, trebuie stabilite reguli precise
¾Intretinere cu efort minim de lucru cu acestea si creata o baza de management a acestora (astfel, desi pot fi Controla activitatile membrilor echipei)
folosite tabelele Excel, o baza de date este de recomandat )
¾Favorizata de existenta unei biblioteci de scripturi, modulare,reutilizabile

¾Arhitectura portabila intre aplicatii ¾Structura tipica a echipei:

¾Biblioteca de teste poate fi portata intre aplicatii deoarece mai toate aplicatiile sunt
formate din aceleasi elemente de baza (ecrane, campuri, taste pentru aplicatii bazate
pe lucrul cu caractere; ferestre si controale grafice pentru aplicatii GUI)

43 45 47

<Testarea Produselor Software> <Testarea Produselor Software> <Testarea Produselor Software>

Automatizare prin metoda Table-Driven <Gabriela Varvara> Procesul de automatizare a testarii <Gabriela Varvara> Procesul de automatizare a testarii <Gabriela Varvara>

Echipa de testare – responsabilitati

Avantaje: ¾In mod ideal ar trebui sa se deruleze in paralel cu procesul de dezvoltare:
¾Conducatorul echipei
¾Arhitectura portabila intre utilitare
¾Raspunde de dezvoltarea planului de testare
¾Atata timp cat se lucreaza cu limbaje de scriptare cu comenzi echivalente, cazurile ¾Managementul activitatilor echipei in raport cu planul
de testare pot fi executate in formatul dat,
dat pot fi executate de o biblioteca de
scripturi create cu alt utilitar. Exista, astfel, libertatea de a folosi utilitare diferite ¾Are autoritatea de a atribui sarcini si de a controla activitatea echipei de testare
pentru testare pe platforme diferite sau de a migra de la un utilitar la altul.
¾Dezvoltatori teste
¾Scrierea cazurilor de testare nu implica cunoasterea unui utilitar de testare ¾Experti in functionalitatea aplicatiei

¾logica este definita si memorata doar la nivelul metodei (script) ¾Dezvolta si executa cazuri de testare
¾Analizeaza si raporteaza rezultatele testarii
¾Scripturile contin suficienta logica pentru a verifica starea si contextul aplicatiei
asftel incat reluarea testelor sa se realizeze corect g
¾Pregatiti sa dezvolte teste (in
( fisiere sau sub forma de script)
p ) si sa utilizeze cadrul
de testare
¾Drept consecinta, testerii individuali pot crea cazuri de testare fara a cunoaste cum a fost
programata logica executiei ¾In realitate, dezvoltarea testware incepe mai tarziu (decalare spre dreapta), unele ¾Dezvoltatori scripturi
faze pot fi comprimate in timp, dar numarul si succesiunea lor trebuie sa se
¾Tot ce trebuie sa cunoasca un tester refera numele componentelor aplicatiei si metodele pastreze ¾Programatori cu experienta ce cunosc bine utilitarul de testare
si valorile aplicabile pentru acestea
¾Responsabili cu dezvoltarea si intretinerea cadrului de testare

44 46 48

C10-12: 22 C10-12: 23 C10-12: 24

Testarea produselor software Testarea produselor software Testarea produselor software

<Testarea Produselor Software> <Testarea Produselor Software> <Testarea Produselor Software>

Procesul de automatizare a testarii <Gabriela Varvara> Procesul de automatizare a testarii <Gabriela Varvara> Procesul de automatizare a testarii <Gabriela Varvara>

Echipa de testare – responsabilitati ¾Proiectarea unei suite de teste

¾Sectiunile planului de testare
¾Bibliotecarul de teste
¾Suita de teste
¾Responsabil cu management configuratie, si controlul versiunilor bibliotecii de ¾Document de control – controleaza adaugarile/modificarile din plan
testare ¾set de teste corelate prin functionalitate sau prin zona de aplicatie asupra
¾Defineste si impune aplicarea procedurilor de check in/check out pentru toate careia au impact ce sunt executate in grup intr-o anumita secventa
fi i l sii documentele
fisierele d l aferente
f
¾Executia suitelor poate fi o caracteristica a utilitarului de testare sau poate fi
¾Conexiunea cu clientul definita printr-un script al utilitarului
¾Comunitatea ce va utiliza aplicatia testata si care, ultimativ, o valideaza
¾Caracteristici:
¾Sunt ultimii ce aproba planul de testare
¾Au responsabilitati legate de comunicarea criteriilor de acceptare echipei de ¾Aplicatia – descrie aplicatia ce va fi testata ¾Testele au legatura unul cu altul - gruparea in suita poate fi legata de cerinta pe care o
verifica sau de tipul de cerinta verificata (ex. mesaj eroare, etc.)
testare
¾Acoperirea testarii automate – ce va fi testat si cine este responsabil
¾Conexiunea cu echipa de dezvoltare ¾Context comun – toate testele din suita partajeaza acelasi contex intrare/iesire, precum si
starea preconizata a bazei de date. Orice rutina RECOVERY inclusa va trebui sa aiba
¾Reprezinta dezvoltatorii in echipa de testare informand bibliotecarul despre acelasi context.
context Daca suita este impachetata spre a fi executata cu un script driver
driver,
modificari ale aplicatiei si ale mediului operational fiecare test din suita trebuie sa se termine cu revenire in driverul apelant
¾Au responsabilitati legate de dezvoltarea cazurilor de testare, livrarea aplicatiei cu ¾Documentare – contine context inceput/sfarsit, secventierea testelor, date si dependente
testarea pe modul efectuata si in stare stabila secventiale de alte teste
¾Conexiunea cu partea de suport sistem si retea
¾Asigura accesul la configuratia adecvata a platformei de lucru si a bazei de date

49 51 53

<Testarea Produselor Software> <Testarea Produselor Software> <Testarea Produselor Software>

Procesul de automatizare a testarii <Gabriela Varvara> Procesul de automatizare a testarii <Gabriela Varvara> Procesul de automatizare a testarii <Gabriela Varvara>

¾Planul de testare ¾Sectiunile planului de testare (continuare) ¾Proiectarea unui ciclu de testare
¾Descrie pasii necesari automatizarii testarii
¾Echipa de testare – nume si roluri ( va fi folosit pentru referinte incrucisate) ¾Exista mai multe tipuri de cicluri de testare necesare
¾Precizeaza
¾Ciclul de regresie – presupune executia intregii biblioteci de teste
¾de ce componente are nevoie biblioteca de teste
¾Ciclu fix – testeaza anumite zone ale aplicatiei, de regula unde s-au efectuat schimbari
¾Resursele necesare
¾Graficul calendaristic al activitatilor ¾Etc.,

¾Criteriile de intrare/iesire pentru executia fiecarui pas ¾Indiferent de tipul de ciclu de testare, anumite elemente vor trebui considerate
¾Este un document dinamic actualizat pe parcursul ciclului de testare ¾Calendar activitati in proiectare:

¾Planificarea ciclului de testare pentru un mediu automatizat va minimiza, pe cat ¾Setup – ciclul incepe intotdeauna cu setarea mediului de testare ( verifica
configuratii si variabile ce afecteaza executia)
posibil, supervizarea sau interactiunea directa.
¾Configurare adecvata a platformei de testare – hardware, sistem operare, utilitare,
¾In mod ideal, un ciclu de testare trebuie sa pregateasca si sa verifice mediul de sincronizare intre aplicatie si biblioteca de testare
testare, sa execute suitele de teste secvente individuale de teste, sa produca
rapoarte cu rezultatele testarii si sa elibereze resursele implicate – toate in mod ¾Unele portiuni din configurare pot fi automatizate, altele nu (incarcare software, etc.)
complet automatizat
¾Configuratia trbuie atent verificata si documentata

50 52 54

C10-12: 25 C10-12: 26 C10-12: 27

Testarea produselor software Testarea produselor software Testarea produselor software

<Testarea Produselor Software> <Testarea Produselor Software> <Testarea Produselor Software>

Procesul de automatizare a testarii <Gabriela Varvara> Procesul de automatizare a testarii <Gabriela Varvara> Procesul de automatizare a testarii <Gabriela Varvara>

¾Proiectarea unui ciclu de testare ¾Test log ¾Test log:

¾Context – contextul de inceput si de sfarsit trebuie sa fie in acelasi punct, de regula ¾Pass/fail – rezultatul executiei unui caz de testare
managerul de program sau prompterul din linia de comanda.
¾ Ideal, ar trebui sa se coreleze cu o cerinta ce are o anumita prioritate
¾Este importanta si initializarea starii bazei de date ( restaurare versiune curata,
curata sau a unui
subset adaugat sau rescris) ¾Performanta

¾Elementele de date, cum ar fi contorii de erori pot fi initializati pentru a garanta stergerea
rezultatelor precedente.
¾Planificarea executiei – adesea cuprinde programarea pentru un set de cicluri de
testare. Secventierea trebuie sa reflecte toate corelatiile pe context sau date, dar si
testele standard (ex. WALKTHRU). Folosirea unui sablon pentru planificarea
executiei testelor este util pentru a garanta includerea la fiecare executie a tuturor
testelor standard si a taskurilor.
¾Stergere – un ciclu trebuie sa se termine cu stergerea mediului de testare
¾pe langa timpul de executie al fiecarui test, daca se testeaza aplicatii de tranzactionare
intre server si masina client, vor trebui inregistrate valorile maxime si medii ale timpului
de raspuns. Adesea cerintele legate de aplicatiile de tranzactionare impun un timp maxim
de raspuns si/sau o valoare medie asteptata.
¾Masuratorile de performanta, pot sa includa timpul total de executie al unor functii
(update sau alte procese batch)
¾Stabilirea performantelor aplicatiei testate este un proces critic. Drept consecinta trebuie
garantata executia testelor necesare care sa garanteze daca cerintele sunt indeplinite in
fapt

( stergere fisiere de lucru, backup pe isiere, sinteza evolutiei rezultatelor, etc.)

55 57 59

<Testarea Produselor Software> <Testarea Produselor Software> <Testarea Produselor Software>

Procesul de automatizare a testarii <Gabriela Varvara> Procesul de automatizare a testarii <Gabriela Varvara> Procesul de automatizare a testarii <Gabriela Varvara>

¾Test log ¾Test log:

¾Executia testelor - pentru un ciclu de testare automatizat intr-o maniera ideala,
interventia sau supervizarea operatorului nu este deloc necesara. Procesul de
executie va produce si documenta rezultatele.
¾Aceasta documentatie ar trebui sa fie suficienta pentru a determina care teste
au esuat si care au trecut, ce performanta a fost atinsa, dar si orice alta
informatie necesara legata de diagnoza defectelor.
¾Inregistrarea rezultatelor testarii (test log) – raporteaza rezultatele executiei
testelor pentru fiecare caz de testare.
¾Configuratia – fiecare log de testare va indica precis ce configuratie exista la
executia sa (ori in antet ori ca un comentariu specific). Daca log-urile testelor
ulterioare denota rezultate de performanta complet diferite, atunci modificarea
configuratiei de executie poate fi cauza diferentelor.
diferentelor
¾Totaluri – numarul total de cazuri de testare, trecute sau nu, ca si timpul total
de testare, ar trebui furnizat la sfarsitul log-ului. Astfel, se va simplifica
actualizarea tendintelor istorice.

p de executie al fiecarui test poate

¾Timpul p fi adaugat
g si este o informatie utila ce
pune in evidenta probleme de performanta si nu numai

¾De ex. un test executat prea repede ar putea indica faptul ca nu parcurge tot
traseul executiei proprii. Un test executat prea lent ridica probleme legate de timpul
de rapuns al calculatorului gazda)

56 58 60

C10-12: 28 C10-12: 29 C10-12: 30

Testarea produselor software Testarea produselor software Testarea produselor software

<Testarea Produselor Software> <Testarea Produselor Software> <Testarea Produselor Software>

Procesul de automatizare a testarii <Gabriela Varvara> Procesul de automatizare a testarii <Gabriela Varvara> Procesul de automatizare a testarii <Gabriela Varvara>

Inregistrarea erorilor (error log) ¾Inregistrarea unui fals succes a testului

¾Se produce cand testul esueaza si totusi raporteaza succes
¾Pentru fiecare test esuat, va trebui sa existe o intrare in inregistrarea erorilor
¾Cadere falsa datorata mediului de testare ¾Posibile cauze:
¾Informatiile furnizate ofera detalii despre caderea produsa, diagnoza ¾Testul are un defect – se produce un bypass logic peste o anumita portiune din test.
acestora
t cu indicarea
i di cauzelor
l posibile
ibil ¾Nu este datorata unui defect in aplicatie Poate fi depistat prin timpul de executie al testului.

¾Poate aparea cand: ¾Etc. …

¾Continutul log-ului:
¾Succes fals prin ratarea unei erori
¾Cazul de testare si scriptul – cazul esuat si scriptul ce l-a executat vor fi documentate ¾Baza de date nu este in starea asteptata datorita executiei unui test precedent
pentru a permite un review ulterior al conditiilor erorii. Erorile nu indica, in mod necesar, ¾Poate aparea cand
un defec in aplicatie – cazul de testare sau scriptul pot fi eronate, contextul aplicatiei sau ¾Configuratia sau setup-ul mediului nu sunt adecvate
a datelor poate fi incorect. ¾Testul nu cauta decat existenta unui raspuns specific si nu interpreteaza un raspuns
incorect ce denota o eroare (de exemplu daca se asteapta raportarea unei erori printr-un
¾O alta eroare a determinat testul sa piarda contextul mesaj intr-o anumita zona a ecranului si ea apare in alt loc)
¾Starea aplicatiei – la aparitia unei erori trebuie sa se documenteze starea aplicatiei pentru
a o compara cu ceea ce se asteapta.
t t AAceastat poatet sa iinsemne o captura
t d
de ecran lla ¾Apare un mesaj de eroare asincron – mesaj broadcast de la baza de date sau retea – si
momentul caderii, data si timpul caderii, cazul de testare executat, rezultatul asteptat, ¾Un test bazat pe comparatii bitmap a fost capturat la o anumita rezolutie aecranului si
executat pentru alta testul nu il cauta.
daca a fost o tentativa de recuperare
¾Poate fi evitat prin folosirea unor teste standard cum ar fi MONITOR
¾Diagnostic – ori de cate ori este posibil, log-ul erorilor trebuie sa contina informatiile de
diagnostic disponibile pentru starea aplicatiei ( stiva, continutul memoriei, listing-uri de
fisiere)

61 63 65

<Testarea Produselor Software> <Testarea Produselor Software> <Testarea Produselor Software>

Procesul de automatizare a testarii <Gabriela Varvara> Procesul de automatizare a testarii <Gabriela Varvara> Procesul de automatizare a testarii <Gabriela Varvara>

¾Cadere falsa produsa de schimbari in aplicatie

¾S-a adaugat un nou camp sau control grafic in aplicatie, ce determina scriptul sa
paraseasca contextul si sa raporteze eroare pentru alte campuri si controale ce
Analiza rezultatelor sunt functionale ¾Inregistrarea defectelor

¾La sfarsitul fiecarui ciclu de testare inregistrarile despre executie,

executie ¾Cadere falsa datorita erorilor din teste ¾Odata ce se determina ca un esec al unui test s-a datorat unei erori in aplicatie – ea
performanta, erori aparute vor trebui analizate. devine defect si trebuie raportata echipei de dezvoltare pentru remediere.
¾Poate lipsi o inregistrare a unui caz de testare
¾Uneori modificarile din cazurile de testare si scripturi determinate de demersul de a ¾Fiecare defect raportat trebuie sa aiba:
¾Testarea automata poate produce rezultate ce nu sunt, in mod necesar,
rezolva o problema pot introduce noi erori
precise sau semnificative ( un log poate contine sute de erori, dar la o privire
¾ un identificator unic si legat de cazul de testare ce l-a identificat,
mai atenta se observa esecul unui test critic intr-o faza incipienta ce a pus in ¾Duplicarea caderii
pericol integritatea bazei de date pentru testele ulterioare) ¾ doua caderi sunt atribuite aceleasi cauze ¾data cand a fost inregistrat ca defect,

¾De ex. la scrierea gresita a numelui unei ferestre poate sa apara o singura eroare; daca
¾Despre rezultate neprecise – nu reflecta cu acuratete starea aplicatiei de o tato u caruia
¾dezvoltatorul ca u a ii este atribuit
at bu t si
s
testul face insa compararea numelui ferestrei de mai multe ori, atunci in mod nedorit
aceasi eroare este raportata de mai multe ori.
¾data cand a fost remediat.
¾Sunt trei tipuri de rezultate neprecise: cadere falsa, succes fals, caderi
¾Odata reparata eroarea numarul de erori va scadea dramatic.
duplicate:
¾Folosirea numarului de erori pentru a aprecia calitatea aplicatiei poate fi inselator –
aplicatia pare plina de defecte ce au fost corectate miraculos de catre testeri.

62 64 66

C10-12: 31 C10-12: 32 C10-12: 33