Lista figurilor …… 4 [623581]

2
Cuprins

Cuprins …………………………………………………………………………………………………….… 2
Lista figurilor ………………………………………………………………………………………………… 4
Lista tabelelor ………………………………………………………………………………………………… 5
Introducere …………………………………………………………………………………………………… 6
Subiectele testării software …………………………………………………………………………….. 7
1. Etape de realizare ale produsului software ………………………………………………………………. 9
1.1 Faza de analiză ………………………………………………………………… .………… …………… 9
1.2 Faza de proiectare …………………………………………… ..………………………………………. 9
1.3 Faza de implementare ……………………………………………………… ..……………………… 10
1.4 Faza de testare ………………………………………………………………………………………. 10
2. Implementarea produselor software ……………………………………………………………………… 12
2.1 Codul sursă ………………………………………………………………………………………..… 12
2.2 Scopul ………………………………………………………………………………………… .……. 12
2.3 Organizarea …………………………………………………………………………………………. 13
2.4 Calitatea ……………………………………………………………………………………………… 13
2.5 Licențierea …………………………………………………………………………………………… 13
2.6 Calitatea produselor software ……………………………………………………………………….. 13
2.6.1 Corectitudinea (reliability) ………………………………………………………………………. 14
2.6.2 Robustețe (robustness) …………………………………………………………………………. 14
2.6.3 Utilizabilitate (usability) ………………………………………… .…………………………..… 14
2.6.4 Portabilitate (portability) ………………………………………………………………… .…..… 14
2.6.5 Mentenabilitate (maintainability) ………………………………………………………………. 15
2.6.6 Eficiență/ performanță (efficiency/performance) ………………………………… …..………… 15
2.7 Limbajul de programare ……………………………………………………………………………… 15
2.7.1 Compilarea si interpretarea …………………………………………………………………..… 15
2.7.2 Limbaje procedurale vs limbaje obiect -orientate …………………………………………….… 16
2.8 Reguli de scriere a unui cod de calitate …………………………………………………………….. 17
2.9. Documentarea codului ……………………………………………………………………………… 17
2.9.1 Pseudocod ………………………………………………………………………………………. 18
2.9.2 Organigrame ……………………………………………………………………………………. 18
2.9.3 UML …………………………………………………………………………………………….. 19
3. Testarea produselor software ……………………………………………………………………………. 21
3.1 Scopul testării ….……………………………………………………………………………………. 21

3
3.2 Fazele procesului de testare software ……………………………………………………………….. 22
3.2.1 Testarea functionala …………………………………………………………………………….. 22
3.2.2 Testarea Non -functiona la……………………………………………………………………….. 24
3.3 Instrumente pentru testarea performanțelor aplicațiilor web ………………………………………… 25
3.3.1 Instrumente de testare web în sursă deschisă ……………………………………………………. 26
3.3.2 Instrumente de testare web pe bază de Windows ………………………………………………. 26
3.3.3 Instrumente de testare pe bază de cloud ……………………… ………………………………… 26
4. Verificarea si validarea produsului …………………………………………… ………………………… 28
5. Exemple de utilizare a metodelor de testare …………………………………………………………….. 33
5.1 Testarea sistemelor distribuite bazate pe componente ………………..……………………………… 33
5.2 Testarea pe baza de Windows ……………………………………………………………………..… 34
5.3 Testarea in sursa deschisa ……………………………………………………………………………. 36
5.4 NetSparks ………………………………………………………………………………………….… 42
Concluzii …………………………………………………………………………………………………… 46
Bibliografie …………………………………………………………………………………………………. 47

4
Lista figurilor

Figure 1 – Schema aplicatie web ………………………….. ………………………….. ………………………….. ……………….. 7
Figure 2 – Modelul conceptul al couplingului ………………………….. ………………………….. …………………………. 17
Figure 3 – Exemplu organigrama ( elemente principale ) ………………………….. ………………………….. …………. 18
Figure 4 – Diagrama de clasa ………………………….. ………………………….. ………………………….. …………………… 19
Figure 5 – Diagrama use case ………………………….. ………………………….. ………………………….. …………………… 20
Figure 6 – Modelul clasic de dezvoltare software ………………………….. ………………………….. ……………………. 21
Figure 7 – Testarea software in ciclul de dezvoltare ………………………….. ………………………….. ……………….. 22
Figure 8 – Fazele procesului de testare ………………………….. ………………………….. ………………………….. ………. 24
Figure 9 – Object Management Group Reference Model Architecture ………………………….. ……………………. 33
Figure 10 – Fișierul html.html cu erori ………………………….. ………………………….. ………………………….. ………. 34
Figure 11 – Afișarea erorilor ………………………….. ………………………….. ………………………….. ……………………. 35
Figure 12 – Rezolvarea erorilor ………………………….. ………………………….. ………………………….. ………………… 35
Figure 13 – Fișierul deschis în notepad ………………………….. ………………………….. ………………………….. ……… 36
Figure 14 – Lansare aplicatie ………………………….. ………………………….. ………………………….. …………………… 36
Figure 15 – Introducere link ………………………….. ………………………….. ………………………….. ……………………. 37
Figure 16 – Pornire buton ………………………….. ………………………….. ………………………….. ……………………….. 37
Figure 17 – Verificare titlu aplicatie ………………………….. ………………………….. ………………………….. …………. 38
Figure 18 – Comenzi Selenium ………………………….. ………………………….. ………………………….. ………………… 38
Figure 19 – Introducere mail și parola ………………………….. ………………………….. ………………………….. ……….. 38
Figure 20 – Oprire buton Record ………………………….. ………………………….. ………………………….. ……………… 39
Figure 21 – Pornire buton Redare ………………………….. ………………………….. ………………………….. …………….. 39
Figure 22 – Verificare Test 1 ………………………….. ………………………….. ………………………….. ……………………. 40
Figure 23 – Verificare Test 2 ………………………….. ………………………….. ………………………….. ……………………. 41
Figure 24 – Introducere site ………………………….. ………………………….. ………………………….. ……………………… 42
Figure 25 – Scanare in derulare ………………………….. ………………………….. ………………………….. ………………… 43
Figure 26 – Scanare completă ………………………….. ………………………….. ………………………….. ………………….. 43
Figure 27 – Afișare timp scanare ………………………….. ………………………….. ………………………….. ………………. 44
Figure 28 – Site Map ………………………….. ………………………….. ………………………….. ………………………….. ….. 44
Figure 29 – Afișare indici vulnerabilitate ………………………….. ………………………….. ………………………….. …… 45
Figure 30 – Tabul Issues ………………………….. ………………………….. ………………………….. ………………………….. 45
Figure 31 – Prezentarea erorii ………………………….. ………………………….. ………………………….. …………………… 45

5
Lista tabelelor

Tabel 1 – Diferentele dintre verificare si validare………… …………………………….. …………. ……………. ………27
Tabel 2 – Verificare si validare – standard ISO/ IEC 12207:2008…………… ………… .….………… .….28
Tabel 3 – Grey -Box ………… ………………………………………………………… …………… .……… 30
Tabel 4 – Diferente metode de t estare…………………………………………………………… ..…… …..31

6
Introducere

“Aplicații Web  sisteme software complexe, în evoluție permanent
Aplicațiile web sunt programe web -based, executate într -un browser web și implementate folosind
tehnologii precum: PHP, ASP, PEARL, PYTHON,HTML, CSS, JAVASCRIPT, etc. Popularitatea acestora
se află într-un trend ascendent, tot mai mulți utilizatori îndreptându -se spre acest tip de aplicații datorită
avantajelor pe care le oferă comparativ cu programele clasice (instalate și rulate).
După părerea mea, testarea est e coloana vertebrală a industriei soft ware, deoarece fiecare scoatere
pe pia ță a produsului se face după testare.
Prin efectuarea testelor se poate considera că produsul este lipsit de defecte / bug -uri, livrand
clientilor un produs fara erori, lucru ce c ontribuie la satisfacția clienților.
In aceasta lucrare am incercat ca cuprind toate ariile de testare si toate ideile principale.
In primul capitol sunt prezentate etapele de realizare ale unui produs software. In capitolul al doilea
vorbim despre tehnic ile de implementare a produselor software . In capitolul al treilea sunt prezentate
metodele si tehnicile de testare, precum si instrumentele de testare. In capitolul al patrulea avem prezentate
doua etape importante in realizarea unui test software, valida rea si verificarea, iar in ultimul capitol, am
realizat tutorial alea unor programe cu ajutorul carora putem testa un software.
Testarea software pune la dispoziție o viziune obiectivă și independentă asupra produsului în
dezvoltare, oferind astfel busine ssului posibilitatea de a înțelege și evalua riscurile asociate cu
implementarea produsului soft.
Metodologiile moderne, precum Agile, Scrum, eXtreme Programming și altele pun un accent
deosebit pe procesul de testare pe care îl integrează în profunzime c u celelalte activități care țin de
dezvoltarea programelor informatice: planificare, proiectare, programare, evaluare și control. [45]

Testarea software cuprinde avantaje si dezavantaje.
Avantajele sunt independente de sistemul de operare. Pot fi rulate aproape de pe orice sistem de
operare prin intermediul unui browser web:
• Nu necesită instalare, fiind necesară doar existența unui browser web
• Actualizări / upgrade foarte ușor de făcut. Practic modificările se fac într -un singur loc (pe ser ver),
ele propagându -se automat către toți utilizatorii, nemaifiind necesară instalarea/reinstalarea
aplicației pe computerul acestora.
• În cazul aplicațiilor client -server clasice interfața cu utilizatorul este asigurată prin intermediul unui
program clien t instalat pe computerul fiecărui utilizator. Un upgrade la codul server de obicei
presupune și un upgrade la codul de client, caz în care este necesară reinstalarea aplicației client pe
fiecare computer utilizator.
• Backup -ul este foarte simplu de realizat , datele fiind stocate centralizat.
• Pot fi rulate de pe orice computer care dispune de un browser web. Practic poate fi accesată din
orice punct de pe glob.
Dezavantajele – poate fi dificil sau chiar imposibil de realizat o conexiune cu hardware -ul local a l
client ului (imprimante, scanner, etc)

7
Schema unui aplicatii web
În figura de mai jos este redată schema de principiu a unei aplicații web. Browserul utilizatorului
trimite o cerere http/https către serverul web iar acesta trimite clientului un răspuns p rin cod html, css,
javascript, etc. După cum se observă este același principiu de funcționare ca în cazul afișarii unei pagini
web oarecare.

Figure 1 – schema aplicatie web

Subiectele testării software
• Scopul
Scopul primordial pentru procesul de testare este (1) identificarea erorilor de software, (2) izolarea
și fixarea/corectarea defectelor care au cauzat aceste erori. Deseori este un exercițiu non -trivial, deoarece
testarea nu poate demonstra cu certitudine de 100% ca produsul funționează corect în orice condiții;
testarea doar poate demonstra că produsul nu funcționează corect în anumite condiții. [1] În scopul testării
deseori se include atât examinarea statică a codului sursă, cât și examinarea codului în execuție în diferite
împrejurări și sub diferite condiții. Informația obținută în urma procesului de testare poate fi folosită pentru
corectarea și îmbunătățirea procesului conform căruia se dezvoltă produsul software. [2]

• Defecte și eșuări
Nu toate defe ctele software sunt cauzate de greșeli în cod. O sursă răspândită de defecte
costisitoare sunt lacunele și neclaritățile la nivel de cerințe, de exemplu, cerințele "ascunse" sau incomplete
pot să rezulte într -un set de erori introduse încă în faza de proie ctare de către designerul programului. [3]
Defectele software se manifestă ca rezultat al următorului proces: un programator comite
o eroare (greșeală), care la rândul ei rezultă într -un defect (bug) la nivel de codul sursă al programului;
dacă acest defect este executat, în anumite condiții sistemul va produce un rezultat greșit, ceea ce ulterior
va duce la o eșuare a programului. Nu toate defectele pot duce la eșuarea programului. De exemplu,
defectele ce se conțin într -o secțiune de cod "mort" niciodată nu vor duce la eșuarea programului.

8
• Compatibilitatea
Deseori aplicațiile software cad din cauza problemelor de compatibilititate cauzate atât de
interacțiunea lor cu alte aplicații sau sisteme de operare, cât și de non -conformitățile ce apar de la o
versiune a programului la alta într -un proces inceremental de dezvoltare a produsului. Incompatibilitățile
ce apar între versiuni se datorează faptului că la momentul scrierii codului programatorul a considerat, sau
a testat, produsul doar pentru un singur sistem de operare (sau un set restrâns de sisteme de opera re), fară a
lua în calcul problemele ce pot apărea la sc himbarea contextului de execuție. [4]
• Combinări de date de intrare și precondiții
O problema fundamentală a testării software a fost și rămâne imposibilitatea de a testa un produs
utilizând toate com binațiile posibile de date de intrare și precondiții (starea inițială). Aceasta este adevărat
chiar și în cazul produselor simple . [5]

9
1. E tape de realizare ale produsului software

Realizarea unui produs software (program) presupune implicarea mai multor etape. Aceste etape
sunt independente de limbajul de programare utilizat și implică existență câtorva restricții cu privire la
computerul utilizat.
Există patru faze fundamentale ale metodologiilor ingineriei programării:
– analiza ( ce dorim să construim);
– proiectarea (cum vom construi);
– implementarea (construirea propriu -zisă);
– testarea (asigurarea calității).
Deși aceste faze se referă în mod special la ciclul de viață al produsului software, ele pot fi aplicate
și altor stadii de existență prin care trece un program de la „naștere” până la „moarte”: lansare, întreținere,
ieșire din uz. [35]
1.1 Faza de analiză

Această fază definește cerințele sistemului, independent de modul în care acestea vor fi
îndeplinite. Aici se defi nește problema pe care clientul dorește să o rezolve. Rezultatul acestei faze este
documentul cerințelor, care trebuie să preci zeze clar ce trebuie construit.
Documentul cerințelor poate fi realizat într -o manieră formală, bazată pe logică matematică, sau
poate fi exprimat în limbaj natural. În mod tradițional, el descrie obiectele din sistem și acțiunile care pot fi
realizate cu ajutorul obiectelor. Aici noțiunea de „obiect” nu trebuie confundată cu obiectul din
programarea orientată obiect.
Descrierea obiectelor și acțiunilor trebuie să fie generală și să nu depindă de o anumită tehnologie.
Desigur, într -o abordare POO, descrierile vor lua forma obiectelor și metodelor, însă în alte abordări,
obiectele pot fi de exemplu servicii care accesează baze de d ate. În general, documentul cerințelor descrie
ontologia proiectului, adică vocabularul de cuvinte cheie (în special construcții substantivale și verbale)
care va fi utilizat pentru definirea protocolului specific aplicației. [43]
Descrierile acestea nu i mplică proiectarea arhitecturii aplicației, ci enumerarea părților componente
și a modului în care acestea se comportă. Mai târziu, în faza de proiectare, acestea vor fi transformate în
primitive informatice, precum liste, stive, arbori, grafuri, algoritmi și structuri de date.

1.2 Faza de proiectare

Pe baza cerințelor din faza de analiză, acum se stabilește arhitectura sistemului: componentele
sistemului, interfețele și modul lor de comportare:
– Componentele sunt blocurile de construcție ale produsu lui. Acestea pot fi create de la zero sau reutilizate
dintr -o bibliotecă de componente. Componentele rafinează și capturează semnificația detaliilor din
documentul cerințelor;

10
– Interfețele ajută la îmbinarea componentelor. O interfață reprezintă granița dintre două componente,
utilizată pentru comunicarea dintre acestea. Prin intermediul interfeței, componentele pot interacționa;
– Comportamentul, determinat de interfață, reprezintă răspunsul unei componente la stimulii acțiunilor
altor componente. Docume ntul de proiectare descrie planul de implementare a cerințelor. Se identifică
detaliile privind limbajele de programare, mediile de dezvoltare, dimensiunea memoriei, platforma,
algoritmii, structurile de date, definițiile de tip globale, interfețele, etc. [ 41]

1.3 Faza de implementare

In această fază, sistemul este construit, ori plecând de la zero, ori prin asamblarea unor componente
pre-existente. Pe baza documentelor din fazele anterioare, echipa de dezvoltare ar trebui să știe exact ce
trebuie să co nstruiască, chiar dacă rămâne loc pentru inovații și flexibilitate .
De exemplu, o componentă poate fi proiectată mai restrâns, special pentru un anumit sistem, sau
mai general, pentru a satisface o direcție de reutilizare.
Echipa trebuie să gestioneze problemele legate de calitate, performanță, biblioteci și debug. Scopul
este producerea sistemului propriu -zis. O problemă importantă este îndepărtarea erorilor critice. Într -un
sistem există trei tipuri de erori:
– Erori critice: Împiedică si stemul să satisfacă în mod complet scenariile de utilizare. Aceste erori trebuie
corectate înainte ca sistemul să fie predat clientului și chiar înainte ca procesul de dezvoltare ulterioară a
produsului să poată continua;
– Erori necritice: Sunt cunoscute , dar prezența lor nu afectează în mod semnificativ calitatea observată a
sistemului. De obicei aceste erori sunt listate în notele de lansare și au modalități de ocolire bine cunoscute;
– Erori necunoscute: Există întotdeauna o probabilitate mare ca sist emul să conțină un număr de erori
nedescoperite încă. Efectele acestor erori sunt necunoscute. Unele se pot dovedi critice, altele pot fi
rezolvate cu patch -uri sau eliminate în versiuni ulterioare. [38,42]

1.4 Faza de testare

Calitatea produsului softwa re este foarte importantă. Multe companii nu au învățat însă acest lucru
și produc sisteme cu funcționalitate extinsă, dar cu o calitate scăzută. E mai simplu să -i explici clientului
de ce lipsește o anumită funcție decât să -i explici de ce produsul nu est e performant.
Un client satisfăcut de calitatea produsului va rămâne loial firmei și va aștepta noile funcții în
versiunile următoare. În multe metodologii ale ingineriei programării, faza de testare este o fază separată,
realizată de o echipă diferită d upă ce implementarea s -a terminat. Motivul este faptul că un programator
nu-și poate descoperi foarte ușor propriile greșeli. O persoană nouă care privește codul poate descoperi
greșeli evidente care scapă celui care citește și recitește materialul de mult e ori. Din păcate, această
practică poate determina o atitudine indiferentă față de calitate în echipa de implementare.
Tehnicile de testare sunt abordate preponderent din perspectiva producătorului sistemului. În mod
ideal, și clientul trebuie să joace un rol important în această fază. [38]

11
Testele de regresiune (engl. „regression test”) sunt colecții de programe care testează una sau mai
multe trăsături ale sistemului. Rezultatele testelor sunt adunate și dacă există erori, bug -ul este corectat. Un
test de regresiune valid generează rezultate verificate, numite „standardul de aur”.
Validitatea rezultatului unui test ar trebui să fie determinată de documentul cerințelor. În practică,
echipa de implementare este responsabilă de inter pretarea validități i. [6]

12
2. Implementarea produselor software

Implementarea reprezintă realizarea unei aplicații sau execuția unui pla n, unei idei, unui model,
etc. În știința calculatoarelor implementarea reprezintă realizarea unui algoritm sub formă de program.
Există numeroase aplicați care pot utiliza diferite standarde. Spre exemplu, la browser -ele web este
de recomandat să conțină implementări ale World Wide W eb Consortium, iar sistememele de dezvoltare
conțin implementări ale limbajelor de programare.
Este cunoscut faptul că prezența unuia sau a mai multor utilizatori în cadrul tuturor etapelor de
realizare a produsului este una benefică. De exemplu prezența utilizatorului la realizarea designului
sistemului, li se oferă posibilitatea să modeleze sistemul în conformitate cu prioritățile lor și li se oferă
posibilitatea să adapteze produsul final conform cerințelor lor. În plus există o probabilitate ca să
reacționeze mult mai ușor la schimbări.
Implementarea unui produs software reprezintă munca în echipă a unui numar mare de dezvoltatori
de programe de multe ori aflați în locații diferite (ex: tări diferite). Astfel este necesară folosirea unor
metode de im plementare a produsului software. O metodă de implementare a produsului software
reprezinta o abordare sistematică structurata pentru a integra efectiv un serviciu software de bază sau o
componentă în s tructura întregului produs. [7]

2.1 Codul sursă

Codul sursă reprezintă reprezintă textul scris folosind formatul și sintaxa u nui limbaj de
programare ales. Codul este special conceput pentru a facilita munca unui programator, astfel oferind
posibilitatea acestuia să specifice operatiile ce vor fi realiza te de către calculator. El poate fi văzut ca o
modalitate prin care utilizatorul informează calculatorul ce și cum are de făcut în scopul manipulării
anumitor date.
Odată ce un program a fost realizat el va fi convertit în cod binar numit cod mașină, car e poate apoi
fi citit si executat. Prin scrierea de cod utilizatorul informează un compilator sau interpretor cum să
realizeze codul binar folosit pentru rularea programului.
Majoritatea aplicațiilor sunt distribuite într -un format de tip executabil, car e nu conține cod sursă.
Utlizatorul nu trebuie să cunoască modul cum a fost implementat programul, ci numai ce face programul.
În caz contrar acesta ar putea modifica codul sursă sa u înțelege cum funcționează. [8]

2.2 Scopul

Codul implementat are 2 roluri ce trebuie avute în vedere
– pentru a putea fi rulat de sistemul de calcul pentru care a fost destinal;
– pentru a fi inteles de programatorii care citesc codul, inclusiv cel care l -a conceput initial. [8]

13
Codul sursă este în primul rând folosit pentru a comunica unui sistem de calcul ce are de făcut.
Un alt scop este acela ca odată realizat un cod sursă într -o aplicație cu o anumită funcție, acesta să
poată fi utilizat în multiple alte situații ale aceluiași program sau a unui alt program care care are de
realizat aceiași funcție.
Această tehnică est e folosită de către programatori atât pentru economisirea de timp cât și pentru
învătarea de tehnici noi de implementare a unui program.

2.3 Organizarea

Codul sursă al unui program poate fi conținut de către un singur fișier sau de către mai multe
fisiere.
Deși este de dorit evitarea acestei situații, în anumte cazuri este necesară scrierea codului sursă în
limbaje de programare diferite. Spre exemplu limbajul de programare C poate conține și linii de cod scrise
în limajul assembler. [8]

2.4 Calit atea

Calitatea unui produs software este data de modul în care acesta este implementat și are implicații
puternice în care ulterior, un alt programator poate înțelege testa și modifica codul inițial.
Calitatea produsului software este dată de anumite caracteristici care au fost prezentate mai sus.
Pentru ca un produs să fie considerat de calitate sunt necesare respectarea anumitor reguli de
implementare.

2.5 Licențierea

Un produs software odată realizat poate fi de 2 tipuri: free software sau propr ietary software.
Prin free software se întelege acel software care poate fi folosit, distribuit, modificat, sau studiat de
către oricine fără a fi nevoie să plătească pentru el.
În al doilea caz codul sursă este ținut secret, utilizatorul putând să aib ă numai posibilitatea de
utilizare a lui numai pe bază de licență.

2.6 Calitatea produselor software

Un produs software pentru a putea fi considerat funcțional este suficient să îndeplinească cerințele
de realizare.
Un produs software pentru a putea fi considerat de calitate pe lângă faptul că este funcțional el
trebuie să respecte și o serie de alte cerințe.

14
Nu există produse software lipsite de erori. Un produs nu este finalizat odată cu lansarea sa pe piată
deoarec e ulterior pot fi oricând adăugate funcționalități noi.
Un produs software trebuie astfel conceput încât să poată fi înțeles, testat, corectat și modificat cu
ușurință și cu riscuri cît mai mici de generare de noi erori.
Produsele software sunt caracterizate de o serie de calități care au implicații atât în ceea ce privește
implementarea codului sursă al produsului, cât și al altor operații cum ar fi testarea, verificarea, validarea,
mentenanța, debugging, integrarea.
Caracteristicile necesare pordusului software pentru a putea fi considerat de calitate sunt:

2.6.1 Corectitudinea (reliability)

Prin corectitudine se exprimă cât de des rezultatul dat de program este corect. Reliability se referă
la corectitudinea algorit milor. Scopul este de a minimiza greșelile de program datorate managementului
resurselor și erorilor logice.

2.6.2 Robustețe (robustness)

Prin robustețe se intelege cât de bine reușeste programul să anticipeze probelemele apărute în
cadrul manipulării datelor. Acesta se referă la detecția unor situații cum ar fi date incorecte, nepotrivite,
distruse, nedisponibilitatea lor la un moment dat, probleme legate de indisponibilitatea de memorie, de
servicii oferite de sistemul de operare, conexiune prin rețe a sau probleme datorate utilizatorului și intr ărilor
introduse de acesta.

2.6.3 Utilizabilitate (usability)

Utilizabilitatea se referă la ușurința cu care o persoană poate folosi un anumit program în scopul
rezolvarii problemelor pentru care a fost realizat p rogramul, sau în anumite cazuri și a unor probleme
neanticipate. Aceasta implică o gamă largă de elemente atât de tip software ce țin de aspectul grafic al
aplicației și de controlul produsului software, cât si de partea hardware a mașinii de cal cul pe car e rulează
aplicația.

2.6.4 Portabilitate (portability)

Prin portabilitate se înțelege gama de sisteme hardware și sisteme de operare pe care se poate
interpreta sau compila și rula programul. Aceasta se referă la adaptabilitatea facilităților oferite de program
la multitudinea de sisteme har dware și sisteme de operare.

15
2.6.5 Mentenabilitate (maintainability)

Această proprietate se referă la ușurința cu care programul poate fi modificat de către programatorii
prezenți și viitori cu scopul de a co recta buguri, de a face modificări, de a reliza facilități suplimentare sau
de a-l adapta la alte sisteme hardware sau sisteme de operare. În acest caz trebuie luat în calcul modul cum
a fost proiec tat și implementat produsul.
2.6.6 Eficiență/ perfor manță (efficiency/performance)

De multe ori un program este conceput în anumite scopuri pe baza cărora se alege și configurează
sistemul de calcul pe care va funcționa programul respectiv. Astfel structura acestui sistem trebuie astfel
aleasă încât costurile de cumpărare ale hardului să fie orientate către cresterea performanței produsului
software prin creșterea performanțelor componentelor hardware folosite mai intens (ex: în cazul serverelor
folosite intens pentru stocarea de date să se pună mai mult accent ul pe viteza de stocare a datelor decât pe
cea de procesare). Astfel componeta software este în strânsă legătură cu cea hardware. [9]

2.7 Limbajul de programare

Codul sursă este diferit în funcție de limbajul de programare ales. În plus putem avea diferite
limbaje de programare folosite în cadrul aceluiași proiect în funcție de aplicația dorită. Există limbaje de
programare procedurale și limbaje de programare obiect -orientate. Putem folosi în cazul aplicațiilor Web
limbaje de programare destinate b rowser -elor (Web development): JSP, JavaScript, HTML. În cazul
serverelor de multe ori trebuie stocată o cantitate mare de informație, caz în care vom folosi aplicații si
limbaje de programare destinate realizării și gestiunii unor baze de date: SQL, Oracl e.
Spre exemplu, putem folosi o aplicație care foloseste o interfață web scrisă în JSP care folosește
diferite clase Java și cu ajutorul căreia se conectează la un server ce are o bază d e date realizată folosind
MySQL. [10]

2.7.1 Compilarea si interpre tarea

În principiu, limbajele de nivel înalt pot fi grupate în 2 categorii: compilatoare și interptretoare. În
realitate există rar programe care pot fi asociate exclusiv uneia din cele 2 categorii.
Compilarea reprezintă o metodă prin care calculatorul convertește codul sursă scris într -un limbaj
de programare numit sursă (de cele mai multe ori un limbaj high -level cum ar fi c++, Java) într -un limbaj
de calculator numit limbaj țintă (cod mașină sau as sembler). Sursa inițială se numește cod sursă iar
rezultatul cod obiect. În urma realizării acestei operații se obține un fișier executabil ce poate fi înțeles și
rulat de către mașina sau mașinile pentru care a fost conceput. [10]
Un program care face op erația inversă poată numele de decompilator.

16
Comilatoarele oferă posibilitatea de dezvoltare a unor porgrame care sunt independente de mașina
pe care acestea sunt rulate. În cazul programelor scrise în assembler codul trebuia modificat dacă era
schimbată mașina pe care era rulat programul. [11]
Un compilator pur este folosit numai în cazul limbajelor de tip low -level, deoarece este m ai natural
și mai eficient.
Interpretorul reprezintă o metodă prin care mașina convertește codul sursă în cod mașină la
momentul în care acesta este rulat.
Interpretorul poate fi:
– un program care execută codul sursă direct
– un program care transoformă codul inițial într -un cod intermediar, iar acesta va fi încărcat pentru execuție
– un program care interpretează codul care anterior a fost compilat de către un compilator care face parte
din sistemul de interpretare.
Principalul dezavantaj al unui interpretor este că acesta este mult mai lent. Spre exemplu un
program interpretat poate fi de 10 ori mai lent decât cel co mpilat. De aceea nu este niciodată folosit un
interpretor pur. În schimb precompilarea programului si apoi interpretarea noului cod la rulare reduce
puternic timpul de rulare, păstrând avantaj ele oferite de interpretare.

2.7.2 Limbaje procedurale vs limbaje obiect -orientate

Limbajul Procedural

Limbajul procedural folosește o listă de instrucțiuni pentru a spune computerului ce trebuie făcut
pas cu pas. Acesta se bazează pe procedurile cunoscute și sub denumirea de rutine sau subrutine. Procedura
conține o serie de etape de calcul care trebuie efectuate. Acest limbaj este intuitiv , în sensul că este foarte
asemănătot cu modul în care un program funcționeză.

Limbajul orientat pe obiecte

Programarea orientată pe obiecte, sau OOP, reprezintă o abor dare a rezolvării problemelor în
care toate calculele sunt realizate folosind obiecte. Un obiect este o componentă a unui program care
știe să efectueze anumite acțiuni și cum să interacționeze cu alte elemente ale programului. Obiectele
sunt unitățile de bază ale programării orientate pe obiecte. Un exemplu simplu al unui obiect ar fi o
persoană.
O metodă în programarea orientată obiect este ca o procedură în programarea procedurală.
Principala diferență aici este că metoda face parte dintr -un obiect. În programarea orientată pe obiecte,
vă organizați codul prin crearea de obiecte, apoi puteți face proprietățile acelor obiecte și le puteți face
anumite lucruri.

Un aspect cheie al programării orientate pe obiecte este utilizarea de clase. O clasă este un
model al unui obiect. [42, 11]

17
2.8 Reguli de scriere a unui cod de calitate

Când un program complex este realizat există mai mulți programatori care lucrează la acel proiect.
De multe ori un program este realizat de o anumită echipă de programatori, iar la un moment dat anumiți
membrii sau chiar întreaga echipă trebuie să preia proiectul pentru a -l finaliza. Noii programatori care se
ocupă de proiect trebuie să înteleagă liniile de cod scrise pentru a putea finaliza proiectul. Astfel codul
trebuie astfel realizat încât să fie usor de inteles de către alte persoane. Trebuie realizat un program cu o
complexitate cât mai scăzută.
Termenul de coupling (cuplarea) se referă la gradul de dependenț a dintre 2 subsisteme, adică la
modul în care fiecare modul al unui porgram se bazează pe modul de funcționare al unui alt modul al
aceluiași program sau al altuia și vice versa. [15]
Coupling poate fi definit ca fiind cantitatea de informație pe care un subsistem o are despre alt
subsistem .

Figure 2 – Modelul conceptul al couplingului

2.9 Documentarea codului

Fiecare etapă a realizarii produsului software presupune realizarea unei documentații
corespunzătoare. Simpla impl ementare a codului nu este suficientă deoarece complexitatea unui program
este foarte mare. Astfel atât utilizatorul cât și cei ce se ocupă de etapele urmatoare au nevoie de informații
suplimentare, care să usureze munca acetora.
O altă problemă este ace ea că un program presupune utilizarea mai multor limbaje de programare.
Există programatori care nu cunosc unele limbaje folosite. Astfel pentru ințelegerea intregului program de
către aceștia pot fi folosite alte metode. O variantă este scrierea de pseudo cod. Realizarea acestor
documente presupune și utilizarea unor forme grafice cum ar fi organigramele sau schite UML. [8]

18
2.9.1 Pseudocod

Pseudocodul nu este un limbaj de programare, ci pur și simplu o modalitate informală de a descrie
un program. Nu ne cesită o sintaxă strictă, ci o reprezentare generală a funcțiilor unui program. Deoarece
nu este un limbaj de programare real, pseudocodul nu poate fi compilat într -un program executabil. Prin
urmare, pseudocodul trebuie să fie convertit într -un limbaj de programare specific pentru a deveni o
aplicație utilizabilă.
Sintaxa generală a pseudocodului este următoarea:
algorithm <nume_algoritm>
<declarare_variabile> {tipul variabilelor}
<declarare_proceduri> {definirea de proceduri/functii}
begin
<procesul_de_calcul_P> {instructiunile algoritmului}
end

2.9.2 Organigrame

În locul scrierii de pseudocod se poate opta pentru folosirea unei reprezentări grafice a algoritmului
numită organigramă.
O organigrama este o diagrama care arata o ierarhi e de rapoarte sau relatii. Poate fi folosita pentru
a arata structura unei afaceri, a unui organizatii sau a unei aplicatii.
In dezolvatarea unui program software, o organigrama este un grafic ce apartine unui pro gram sau
altgoritm pentru a fi implementat pe o masina de calcul.
Elementele principale ale unui organigrame sunt :
– Blocurile de start si stop
– Blocul de insctructiuni
– Blocul de decizie
– Legaturile intre blocuri

Figure 3 – Exemplu organigrama ( elemente principale )
START
INSTRUCTIUN
CONDITIE
STOP

19
2.9.3 UML

UML (Unified Modeling Language) este o notație standard pentru modelarea obiectelor din
lumea reală ca un prim pas în dezvoltarea unei metodologii de proiectare orientate pe obiecte.

UML este un limbaj folosit pentru a defini un produs software din punct de vedere al entitaților
participante, al fluxului de operații și al relațiilor dintre entitațile participante.
UML nu este un limbaj de programare, dar pot fi folosite diferite instrumente ce genereaza cod din
diagramele UML.
Exista mai multe tipuri de diagrame
– Diagrama de activitate – folosita pentru a prezenta desfasurarea activitatii in rularea unui program
– Digrama de componente – folosita in proiectarea unei arhitecturi de system
– Diagram a de clasa – folosita pentru prezentarea vizuala a claselor
– Diagrama package – folosita pentru reprezentarea relatiilor dintre pachetele ce formeaza un
program
– Diagrama de secventa – identificarea relatiilor dintre obiecte
– Diagrama use case – reprezinta interactiunea dintre elementele exterioare si system
– Diagrama deployment – folosita in proiectarea arhitecturii de system.

Figure 4 – Diagrama de clasa

20

Figure 5 – Diagram a use case

21
2. Testarea produselor software

Testarea reprezintă o etapă importantă în procesul de realizare a produselor software. Ponderea
cheltuielilor cu testarea reprezintă între 30% și 50% din totalul cheltuielilor pentru dezvoltarea unei
aplicații software. [39]
Tehnicile și metodele moderne de elaborare a produselor software acordă o importanță deosebită
efortului de înlăturare a erorilor de analiză, proiectare și programare prin folosirea uno r mijloace evoluate
de testare. [14]

Figure 6 – Modelul clasic de dezvoltare software

3.1 Scopul testării

Scopul principal este detecția erorilor, corecția celor care pot fi eliminate, minimizarea acelora care
nu pot fi eliminate sau ignorarea ei în cazul în care eroarea nu poate fi eliminată sau costul remedierii erorii
este mai mare decât costul datorat ei. [17]
De asemenea scopul testării este acela de a oferi utilizatorului siguranța că pr odusul este conform
cerințelor.
În general scopurile testării performanțelor produsului software sunt:
• cerceterea calității produsului software
• testarea si validarea acestuia.

22

Figure 7 – Testarea software in ciclul de dezvoltare
3.2 Fazele procesului de testare software

Nivelurile de testare includ metodologii diferite care pot fi utilizate în timpul efectuării testelor
software. Nivelurile principale de testare a software -ului sunt:
➢ Testarea funcțională
➢ Testarea non – funcțională

3.2.1 Testarea functionala

Acest este un tip de testare black -box care se bazează pe specificații le software -ului c e urmează să
fie testat. Aplicația este testată prin furnizarea de informații și apoi sunt examinate rezultatele care trebuie
să se conformeze funcționalității pentru care a fost destinată. Testarea funcțională a unui software este
realizată pe un sistem complet, integrat pentru a evalua conformitatea sistemului cu cerințele specificate.
Există cinci etape care sunt implicate în timp ce testați o aplicație pentru funcționalitate .
Există patru etape principale de testare funcțională pe care un program trebuie sa le îndeplinească
pentru a putea fi folosit :
– unit testing
– integration testing
– system testing
– acceptance testing

23
Unit testing
În această primă faza , programul este supus evaluaril or care se concentreaza pe unităț i sau
compone nte specific e ale programul ui, pentru a determina ce este și ce nu este funcț ional. Scopu l principal
este de a vedea dacă aplicația functionează așa cum a fost proiectată . Unul dintre cele mai mari beneficii
ale acestei faze de testare este că poate fi rul at de fiecare dată când este modificată o secvența de cod,
permițând soluț ionarea pr oblemelor câ t mai repede posibil. D ezvoltatorii software efectuează teste de tip
“black -box”. [22]
Integration testing
Integration test permite combinarea tuturor unită ților executâ ndu-le ca un intreg. Acest n ivel de
testare este destinat gă sirii defect elor de interfață între module si funcț ii. Acest lucru e ste important
deoarece determină cât de eficient funcționează unitățile împreună . Pentru a executa aceste teste,
dezvol tatorii pot efectua o mulț ime de metode de testa re, dar metoda cea mai specifică pentru a realiza
aceste teste depinde în mare măsură de modul ân care sunt definite unităț ile.[25]

System testing
Testarea sistemului este primul nivel în care aplicația completă este testată ca un întreg. Scopul
acestui nivel este de a evalua dacă sistemul a respectat toate cerințele prezentate și pentru a vedea că
respectă standardele de calitate. Testarea sistemului este efectuată de test eri independenți care nu au jucat
un rol în dezvoltarea programului. Această testare este efectuată într -un mediu care reflectă îndeaproape
producția. Testarea sistemului este foarte importantă deoarece verifică dacă aplicația îndeplinește cerințele
tehnic e, funcționale și de afaceri stabilite de client. [21][23]

Acceptance testing
Nivelul final, acceptance testing (sau User Acceptance Testing ), este efectuat pentru a determina
dacă sistemul este gata de lansare. În timpul ciclului de viață al dezvoltării software -ului, modificările
cerințelor pot fi uneori interpretate greșit într -o manieră care nu corespunde nevoilor intenționate ale
utilizatorilor. În această fază finală, utilizatorul va testa sistemul pentru a afla dacă aplicația satisface
nevoile aface rii. Odată ce acest proces a fost finalizat și software -ul a trecut, programul va fi apoi livrat la
producție. [21][34]

24

Figure 8 – Fazele procesului de testare

3.2.2 Testarea Non -functionala

Această secțiune se bazează pe testarea unei aplicații din atributele sale non -funcționale. Testarea
non-funcțională implică testarea unui software din cerințele care nu sunt funcționale, dar sunt importante,
cum ar fi performanța, securitatea, interfața cu utilizatorul etc.
Testul de p erformanta
Aces at este folosit în principal pentru a identifica blocaje sau probleme de performanță. Există
diferite cauze care contribuie la scăderea performanței unui software:
➢ Întârzierea rețelei
➢ Procesarea tranzacțiilor bazei de date
➢ Redarea datelor
Testarea performanțelor este considerată ca fiind unul dintre tipurile de testare importante și
obligatorii în ceea ce privește următoarele aspecte:
➢ Viteza (adică timpul de răspuns, redarea și accesarea datelor)
➢ Capacitate
➢ Stabilitate
➢ Scalabilitate

25
Testarea performanțelor poate fi calitativă sau cantitativă și poate fi împărțită în diferite subtipuri,
cum ar fi load testing și stress testing.

Load Testing

Este un proces de testare a comportamentului unui software prin aplicarea unei încărcări maxi me în
ceea ce pr ivește accesarea și manipularea datelor de intrare mari. Se poate face atât în condiții normale, cât
și în condiții de încărcare maximă. Acest tip de testare identifică capacitatea maximă a software -ului și
comportamentul acestuia . De cele mai multe ori, testarea încărcării este efectuată cu ajutorul unor
instrumente automate cum ar fi Load Runner, AppLoader, IBM Rational Performance Tester, Apache
JMeter, Silk Performer, Visual Studio Load Test etc. Utilizatorii virtuali sunt definiți în in strumentul de
testare automată și s criptul este executat pentru a verifica testarea încărcării pentru software. Numărul de
utilizatori poate fi mărit sau micșorat simultan sau incremental pe baza cerințelor.

Stress Testing

Testarea la stres include test area comportamentului unui software în condiții anormale. De
exemplu, poate include îndepărtarea unor resurse sau aplicarea unei sarcini dincolo de limita de încărcare
reală. Scopul testelor de stres este de a testa software -ul prin aplicarea sarcinii în s istem și preluarea
resurselor utilizate de software pentru a identifica punctul de rupere. Această testare poate fi efectuată prin
testarea unor scenarii diferite, cum ar fi:
➢ Oprirea sau repornirea porturilor de rețea aleatoriu
➢ Activarea sau dezactivarea b azei de date
➢ Rularea diferitelor procese care consumă resurse precum procesorul, memoria, server, etc. [46]

3.3 Instrumente pentru testarea performanțelor aplicațiilor web

O aplicatie trebuie sa indeplineasca urmatoarele conditii pentru a a avea o perfo rmanta buna :
• Sub 100 milisecunde este perceput ca instantaneu
• Este detectabilă o întârziere de la 100 ms la 300 ms
• O secundă este aproximativ limita pentru fluxul de gândire al utilizatorului să rămână neîntrerupt
• Utilizatorii se așteaptă ca un site să se încarce în 2 secunde
• După 3 secunde, 40% dintre vizitatori vor abandona site -ul dvs.
• 10 secunde reprezintă limita pentru a menține atenția utilizatorului
• Echipele de inginerie trebuie să trateze performanța ca o caracteristică. [21]
Scopul testelor de performanță este de a înțelege modul în care aplicațiile se comportă în condiții
de încărcare grea. Pentru a începe, trebuie înțelasă performanța de bază a aplicației și faptul că
performanța fiecărei tranzacții este unică. De exemplu, într-o aplicație de comerț electronic, o tranzacție de

26
pagină de pornire este probabil foarte rapidă, în timp ce o tranzacție de plată este mai complicate.Trebuie
testate cele mai frecvente fluxuri pentru utilizatori și înțelasă performanța atât în browse r, cât și pe
server. [21] Pentru a face acest lucru, este nevoie de instrumente de la partea de server, de client și de
performanță.

3.3.1 Instrumente de testare web în sursă deschisă

• Apache JMeter : instrument de tastare construit pe platform Java . Acest instrument de testare este
dezvoltat pentru a testa comportamentul funcțional și testarea performanțelor. Deși a fost proiectat
inițial pentru a testa aplicații web, astăzi domeniul său de aplicare a crescut și la alte domenii de
testare.
• Load UI : este un instrument pentru testarea performantelor web. Acesta susține testarea a
numeroase protocoale web, cum ar fi AMF, REST, JMS, JDBC și site -uri web. Mulți testeri sunt
de acord că LoadUI este unul dintre cele mai interactive și mai ușor de utilizat ins trumente de
testare. În timpul fazei de testare permite testerelor să creeze, să configureze și să actualizeze
testele. LoadUI dispune de o interfață grafică ridicată care facilitează testarea.
• Selenium IDE: suită de instrumente pentru automatizarea browse relor web. Disponibil in mai
multe limbi. [29]
• Open STA (Open System Testing Architecture) – testele sunt realizate folosind scripturi simple,
înregistrări și iau în considerare și diverse rezultate și statistici. [30]

3.3.2 Instrumente de testare web pe b ază de Windows

• CSE HTML Validator – Testează HTML (inclusiv HTML5), XHTML, CSS (inclusiv CSS3),
accesibilitatea – software -ul de la AI Internet Solutions LLC.
• TestStack.White – este o bibliotecă pentru automatizarea aplicațiilor desktop. A început ca un m ic
proiect open source și apoi a devenit o parte din TestStack, care constă într -o varietate de proiecte
cu cod sursă deschisă pentru testarea automată și manuală. White susține o varietate de tehnologii
de automatizare: Silverlight, WPF, WinForms, Win32 ș i SWT în Java. Este posibil să scrieți teste
alb în orice limbă suportată de .NET. [19]
• LDTP (Linux Desktop Testing Project) – Desi proiectul a inceput pentru Linux, in zilele noastre
sustine versiunea MAC (PyATOM) si Windows (versiunea Cobra). LDTP vine alături de un editor
propriu, iar printre alte activități suportă și înregistrări. [20]

3.3.3 Instrumente de testare pe bază de cloud

• LoadStorm – este un instrument de testare a încărcării pentru aplicații web și mobile. Este ușor de
utilizat și eficient din punct de vedere al costurilor. Este ideal pentru a verifica performanța în
condiții de trafic excesiv sau de utilizare. Este foarte scalabil și poate simula cât mai mulți
utilizatori virtuali, după cum este necesar, pentru a găsi punctul de rupere al unui site sau al unei
aplicații. Sunt disponibile diferite scenarii de testare a încărcării, care sunt, de asemenea,
personalizabile. [19]

27
• BlazeMeter – se utilizează pentru performanța end -to-end și testarea încărcării aplicațiilor, site –
urilor web și API -urilor mobile. Este compatibil cu JMeter și poate simula până la 1 milion de
utilizatori. Facilitează testele de încărcare realiste și mo nitorizarea performanțelor combinate cu
raportarea în timp real.
• Xamarin test cloud – este un instrument de testare pentru aplicatii mobile. Acesta permite scrierea
de teste în C # folosind biblioteca de testare NUnit prin cadrul UITest sau în Ruby prin ca drul
Calabash. Instrumentul execută testul pe mai mult e dispozitive fizice și afișează fotografii de ecran
cu rezoluție completă pentru fiecare pas, inclusiv date relevante cum ar fi CPU și utilizarea
memoriei și timpul de testare. Acesta poate fi integrat în construcții automate pentru integrare
continua.[24]

3.3.4 Intrumente de testare – Link Manager

• Spring Trax – Monitorizează fiecare vizitator folosind codul de urmărire JavaScript și analizează
instantaneu fiecare eroare de 404.
• Link Tiger – este de as emenea un link checker, funcționează pe alerte de e -mail, dashboard și
rapoarte personalizate. Suportă platforme Linux, Mac, Windows și Windows Phone. Funcțiile de
scanare pot scana fișiere PDF, CSS, Flash și MS Office, animație flash.

3.3.5 Instrumente de testare a securității web

• NTOSpider – este un instrument de securitate web bazat pe Windows, oferă securitate completă
aplicațiilor / serviciilor web, mobilului și aplicațiilor Internet bogate (RIA's). Cel mai important
lucru este că vă scanează cerere a pe deplin în mai puțin timp, asigură o securitate completă a
sistemului la un cost mult mai mic.
• Netsparker – Un scanner de securitate pentru aplicații web cross -platform , este util pentru
detectarea și raportarea vulnerabilităților aplicațiilor web / we b (SQL Injection și Cross -site
Scripting (XSS)) și probleme de securitate, indiferent de platforma și tehnologia pe care a fost
construit.

28
4. Verificarea si validarea produsului

Exista 2 aspecte generale ale verificarii si validarii produsului :
• Confirmarea cerintelor
• Potrivit pentru utilizare

Ce este verificarea ?

Verificare a este p rocesul de evaluare a software -ului pentru a determina dacă produsele unei faze
de dezvoltare date îndeplinesc condițiile impuse la începutul acel ei faze.
Verificarea este o practică statică de verificare a documentelor, design, cod și program. Acesta
include toate activitățile asociate cu producerea de software de înaltă calitate: inspecție, analiză de
proiectare și analiză de specificații. Este u n proces r elativ obiectiv.
Verificarea va determina dacă software -ul este de înaltă calitate, dar nu va asigura că sistemul este
util. Verificarea se referă la faptul dacă sistemul este bine proiectat și fără erori. [37]

Ce este validarea ?

Validarea este procesu l de evaluare a software -ului în timpul sau la sfârșitul procesului de
dezvoltare pentru a determina dacă acesta înde plinește cerințele specificate.
Validarea este procesul de evaluare a produsului final pentru a verifica dacă programul respectă
așteptări le și cerințele clienților. Este un mecanism dinamic de validare și testare a produsului real. [18]

Verificare Validare
Verificarea este o practică statică de verificare a
documentelor, a design ului, a codului și a
program ului. Este u n mecanism dinamic de validare și testare a
produsului real.
Nu implica executarea codului. Implica intotdeauna executia codului.
Utilizează met ode precum inspecții, recenzii și
vizionări Utilizează metode cum ar fi testul black -box
(funcțională ) și testul white -box (struc tura) etc.
Verifica daca softul corespunde cu specificatiile. Verifica daca programul corespunde cu nevoile si
specificatiile clientului
Poate gasi erori pe care validarea nu le gaseste. Identifica erori pe care verificarea nu le gaseste.
Obiectivul est e specificarea cerințelor, arhitectura
aplicațiilor și software -ului, nivel înalt, proiectare
completă și proiectarea bazelor de date etc. Se desfasoara cu implicarea echipei de testare.
De obicei verificarea se face inaintea validarii. De obicei validare a are loc dupa verificare.
Tabel 1 – Diferentele dintre verificare si validare

29
Verificarea si validarea in div erse standarde :
ISO / IEC 12207:2008
Verificare Validare
Verificarea cerințelor – Implică revizuirea cerințelor Pregăteste documentele de testare, cazurile de
testare și alte specificații ale testelor pentru a
analiza rezultatele testelor.
Verificarea designului – Implică revizuirea tuturor
documentelor de proiectare, inclusiv HLD și LDD Evalu eaza dacă aceste cerințe, cazuri le de testare și
alte specificații reflectă cerințele și sunt adecvate
pentru utilizare.
Verificarea codului – Revizuire a Codului Teste aza valorile stresului și a funcționalităților
Verificarea doc umentației – Verificarea manualelor
de utilizare și a alt or documente conexe. Verific ă dacă software -ul îndeplinește cerințele de
afaceri și este potrivit pentru utilizare. [44]
Tabel 2 – verificare si validare – standard ISO/ IEC 12207:2008

IEEE 1012
Obiectivele activităților de verificare și validare sunt următoarele:
• Facilitează depistarea precoce și corectarea erorilor.
• Încurajează și îmbunătățește intervenția de management și în interiorul riscurilor de proces și
produs.
• Furnizeaz ă măsuri de susținere pentru procesul de ciclu de viață al software -ului, pentru a
îmbunătăți respectarea cerințelor programelor și a bugetului. [32]

Verificarea si validarea cuprind mai multe etape :
➢ Planificare:
 Verificarea contractului
 Evaluarea docume ntului initial
 Efectuarea analizei de risc

➢ Faza de cerințe
 Evaluarea cerințelor software
 Evaluarea / analiza interfețelor generarea planului de testare a sistemelor
 Generarea planului de testare a acceptării

➢ Faza de proiectare
 Evaluarea designului de sof tware
 Evaluarea / analiza interfețelor (UI)
 Generarea planului de testare pentru integrare
 Generarea planului de testare a componentelor
 Generarea designului de testare

30
➢ Faza de implementare
 Evaluarea codului sursă
 Evaluarea documentelor
 Generarea de cazuri de testare
 Generarea procedurii de testare
 Executarea cazurilor de testare a componentelor

➢ Faza de instalare și checkout
 Audit de instalare și configurare
 Testul final al construirii candidatului de instalare.
 Generarea raportului final de testare

➢ Faza de operare
 Evaluarea noii constrângeri
 Evaluarea propunerii de modificare

➢ Faza de întreținere
 Evaluarea anomaliilor
 Evaluarea migrației
 Evaluarea caracteristicilor de rejudecare
 Evaluarea modificării propuse.
 Validarea problemelor de producție.

Testarea Black -box
Black Box Testing, cunoscut și sub numele de Test de comportament, este o metodă de testare a
software -ului în care structura internă / proiectarea / implementarea elementului testat nu este cunoscută de
tester. Aceste teste pot fi fun cționale sau nefuncționale, deși, de obicei, funcționale. [16]
Această metodă încearcă să găsească erori în următoarele categorii:
• Funcții incorecte sau lipsă
• Erori de interfață
• Erori în structurile de date sau în accesarea bazei de date externe
• Comportame nt sau erori de performanță
• Eroare de inițializare și terminare

Testarea White -box
Este o metodă de testare a software -ului în care structura internă / proiectarea / implementarea
elementului testat este cunoscută de tester. Testerul alege intrările pen tru a exercita căile prin cod și
determină ieșirile corespunzătoare. Know -how-ul de programare și cunoștințele de implementare sunt
esențiale. [36]

31
Avantaje

• Testarea poate fi începută într -o etapă anterioară. Nu trebuie să așteptați ca GUI să fie disponib il.
• Testarea este mai amănunțită, cu posibilitatea de a acoperi majoritatea traseelor.

Dezavantaje

• Deoarece testele pot fi foarte complexe, sunt necesare resurse foarte calificate, cu cunoștințe
aprofundate de programare și implementare.
• Testul de întreținere a unui script poate fi o povară dacă implementarea se schimbă prea des.
• Deoarece această metodă de testare este strâns legată de aplicația c e este testată, este posibil ca
instrumentele care răspund la orice tip de implementare / platformă să n u fie disponibile. [16]

Testarea Grey -Box
Testul Grey -Box este o tehnică de testare a aplicației, având o cunoaștere limitată a funcționării
interne a unei aplicații.
Stăpânirea domeniului unui sistem oferă întotdeauna testerului un avantaj față de cineva cu
cunoștințe de domeniu limitate. Spre deosebire de testarea black -box, unde testerul testează numai interfața
de utilizator a aplicației; În testarea grey -box, testerul are acces la proiectare, documente și baza de date.
Având ace ste cunoștințe, un tester poate pregăti date de testare mai bune și scenarii de testare în timp ce
face un plan de testare.
Avantaje Dezavantaje
Oferă avantaje combinate ale testării blackbox și
whitebox ori de câte ori este posibil . Deoarece accesul la c odul sursă nu este disponibil,
abilitatea de a trece peste cod și acoperirea testelor
este limitată.
Echipamentele de testare grey -box nu se bazează pe
codul sursă; În schimb se bazează pe definiția
interfeței și pe specificațiile funcționale . Testele pot fi redundante dacă proiectantul de
software a executat deja un test.
Pe baza informațiilor limitate disponibile, un tester
cu grey-box poate proiecta scenarii de testare
excelente, în special în ceea ce privește protocoalele
de comunicare și manipularea tipurilor de date . Testarea fiecărui flux de intrare posibil este
nerealistă, deoare ce ar lua un timp nerezonabil; p rin
urmare, multe părți din program nu vor fi testate.
Testul se face din punc tul de vedere al utilizatorului.
Tabel 3 – Grey -Box
Diferen te dintre metodele de testare black -box, white -box si grey -box.
Testarea Black -Box Testarea White -Box Testarea Grey -Box
Lucrările interne ale unei aplicații
nu trebuie să fie cunoscute. Testerul are cunoștințe limitate
privind funcționarea internă a
aplic ației. Testerul cunoaște pe deplin
funcționarea internă a aplicației.
Realizate de utilizatorii finali, dar
și de testeri și dezvoltatori. Realizate de utilizatorii finali, dar
și de testeri și dezvoltatori. În mod normal, efectuate de
testeri și dezvoltatori.

32
Testarea se bazează pe așteptările
externe – comportamentul intern
al aplicației nu este cunoscut. Testarea se face pe baza
diagramelor bazelor de date la
nivel înalt și a diagramelor de
fluxuri de date. Lucrările interne sunt pe deplin
cuno scute și testerul poate
proiecta datele de testare în
consecință.
Este cel mai complet și cel mai
puțin consumator de timp. Parțial consumatoare de timp și
exhaustiv. Cel mai exhaustiv și cu cel mai
mare timp de testare.
Nu este potrivit pentru testarea
algoritmilor. Nu este potrivit pentru testarea
algoritmilor. Este potrivit pentru testarea
algoritmilor. [46]
Tabel 4 – Diferente metode de testare

33
5. Exemple de utilizare a metodelor de testare

5.1 Testarea sistemelor distribuite bazate pe component e

CORBA – Common Object Request Broker Architecture – Este un standard definit de Object
Management Group (OMG) destinat să faciliteze comunicarea sistemelor care sunt implementate pe
diverse platforme. CORBA permite colaborarea între sisteme pe di ferite sisteme de operare, limbaje de
programare și hardware d e calcul. CORBA utilizează un model orientat pe obiecte, deși sistemele care
utilizează CORBA nu trebuie să fie orientate pe obiecte.
CORBA permite comunicarea între software -ul scris în diferite limbi și care rulează pe diferite
computere. Detaliile de implementare din anumite sisteme de operare, limbi de programare și platforme
hardware sunt eliminate din responsabilitatea dezvoltatorilor care folosesc CORBA.
CORBA utilizează un limbaj de definire a interfeței (IDL) pentru a specifica interfețele pe ca re le
prezintă obiectele existente în lumea exterioară. CORBA specifică apoi o mapare din IDL în tr-un limbaj de
implementare specific , cum ar fi C ++ sau Java. Există mapări standard pentru Ada, C ++, C ++ 11,
COBOL, Java, Lisp, PL / I, Object Pascal, Pyth on, Ruby și Smalltalk. [27]

Figure 9 – Object Management Group Reference Model Architecture
Etape de dezvoltare a unei aplicatii CORBA:
➢ Definirea interfetei ( IDL );
➢ Maparea IDL (idlj compiler);
➢ Implementarea interfetei;
➢ Scrierea codului Server;
➢ Scrierea codului Client;
➢ Rularea aplicatiei.

34
5.2 Testarea pe baza de Windows

CSE HTML Validator este un editor HTML pentru Windows, care ajută dezvoltatorii web să
creeze documente HTML, XHTML și CSS (inclusiv HTML5 și CSS3) corecte și accesibile prin
identificarea erorilor, a posibilelor probleme și a greșelilor comune. Este, de asemenea, capabil de a
verifica link -rile, de a sugera îmbunătățiri, de a avertiza de zvoltatorii web de exist enta tag-urilor,a
atributelor și a proprietăților CSS depreciate, învechite sau protejate, și pentru a găsi probleme care pot
afecta optimizarea motorului de căutare. [26]
Există patru ediții importante ale CSE Validator HTML – Enterprise, Professional, Standard și Lite.
În timp ce aplicația este, în general, un produs comercial (cu excepția ediției lite), o versiune gratuită a
ediției standard este disponibilă pentru utili zare personală, necomercială. [31]
Începem prin a crea un fișier .html pe care î l scriem cu erori :

Figure 10 – Fișierul html.html cu erori

Rulă m CSE HTML Validator și deschidem fiș ierul html. html pentru a -l verifica. Pentru a
verifica erorile, apasam F6. Imaginea de mai jos ne arata erorile pe care le -am adăugat în mod special în
cod pentru a vedea dacă sunt identificate de că tre program.

35

Figure 11 – Afișarea erorilor

Rezolvăm fiecare eroare și a păsăm din nou F6. Programul ne arată că toate erorile au fost
rezolvate iar rularea programului a fost realizata cu success.
Figure 12 – Rezolvarea erorilor

36
Deschidem din nou fișierul html.html î n NotePad pentru a veri fica dacș a fost salvat corect fisierul.

Figure 13 – Fișierul deschis î n notepad

5.3 Testarea in sursa deschisa

Selenium IDE – este un instrument de testare folosit pentru a dezvolta diferite case -uri. Este un
plug-in Firefox ușor de folosit și poate cel mai ef icient mod de a dezvolta case -urile de testare. De
asemenea, conț ine un meni u contextual care permite selecția unui UI din pagina afisată și apoi puteț i
selecta dintr -o listă de comenzi un parametru predefinit în functie de conte xtul elementului UI selectat. [29]
Pasul 1 – Înregistrarea unui test
a. Lansăm Firefox ș i deschidem Selenium

Figure 14 – Lansare aplicatie
Buton lasare Selenium IDE

37
b. Introducem link -ul “https://accounts.google.com “ in textbox -ul BASE URL.

Figure 15 – Introducere link

c. Pornim butonul de record ș i introducem link -ul in browser.

Figure 16 – Pornire buton

d. Verific ăm dacă titlul aplicației este corect. Pentru a face acest lucru, face m click dreapta oriunde pe
pagină, cu excepția hiper linkurilor sau a imaginilor. Click dreapt deschide meniul contextual al
Selenium IDE care conține câteva comenzi. Pentru a obț ine o listă completă, select ăm opțiunea
"Show Available Commands". Aceasta va deschide un alt meniu care conține restul comenzilor
disponibile și aplicabile. Select ăm "assertTitle Sign in – Conturi Google" pentru a verifica titlul
paginii.
Buton RECORD

38

Figure 17 – Verificare titlu aplicatie

De îndată ce facem clic pe opțiunea "assertTitle Sign in – Google Accounts", se va include / adăuga
un test în editorul Selenium IDE.

Figure 18 – Comenzi Selenium
e. Introduce m un mail valid ș i o parolă validă

Figure 19 – Introducere mail ș i parola

39
f. La sfârș it, oprim butonul de record.

Figure 20 – Oprire buton Record

Pasul 2 – Redarea ș i executarea testului

Acum că am creat un test in Selenium IDE , vrem sa îl redăm pentru a vedea dacă este corect.
Pentru a face acest lucru, apăsă m butonul de redare.

Figure 21 – Pornire buton Redare

Buton RECORD oprit
Buton redare

40
Toți pașii de testare vor fi evidențiați cu verde dacș rularea a fost facuta cu success, iar cu roșu dacă
sunt erori.

Figure 22 – Verificare Test 1

41

Figure 23 – Verificare Test 2

42
5.4 NetSparks

Netsparker Desktop este disponibil ca aplicație pentru Windows și este un scaner de securitate
pentru aplicații web ușor de folosit, care utilizează tehnologia avansată de scanare a vulnerabilităților și are
instrumentele de testare și raportare încorporate. Netsparker exploatea ză în mod automat vulnerabilitățile
identificate într -un mod care permite citirea și siguranța și produce o dovadă a exploatării.
Tehnologia unică de scanare a vulnerabilităților Netsparker are o acoperire mai bună și găsește mai
multe vulnerabilități de cât orice alt scanner.
Descărcăm aplicaț ia de pe https://www.netsparker.com/web -vulnerability -scanner/download/ și o
instală m.
Lasăm aplicația, apăsă m “New Test”, iar in ferea stra deschisă introducem site -ul pe care dorim să
il testăm și apăsă m “Start S can”.

Figure 24 – Introducere site

43

Figure 25 – Scanare in derulare

Figure 26 – Scanare completă

44

Figure 27 – Afișare timp scanare

Figure 28 – Site Map

45
Vulnerabilităț ile site -ului sunt evidentiate cu stegulețe, colorate diferit, in funcție de imporț anta lor.

Figure 29 – Afișare indici vulnerabilitate

Erorile sunt afiș ate in partea de jos in tabul “Issues”.

Figure 30 – Tabul Issues

Pentru a verifica fiecare vulnerabilitate ș i pentr u a vedea cum poate fi remediată, apăsă m dublu –
click pe una din el e și ni se deschide o nouă fereastră. În această fereastră ne este prezentată eroarea,
impactul asupra site -ului ș i modalitatea de remediere.

Figure 31 – Prezentarea erorii
Important Mediu
m Low Critical

46
Concluzii

Implementarea unui produs software este o etapă dificilă prin faptul că în cadrul programelor
complexe poate fi realizată numai de către un grup de oameni. Astfel se pune accentul pe lucrul în echipă.
Implem entarea unui produs software reprezintă etapa de scriere efectivă a codului. Codul
reprezintă atât un limbaj de comunicare între programator și calculator cât și unul folosit între mai mulți
programatori. Astfel codul trebuie astfel realizat și organizat î ncât să poată fi ințeles și modificat sau
utilizat de către un alt programator care ulterior va citi codul.
Există un număr mare de limbaje de programare. Alegerea limbajului de programare folosit este
dependentă de caracteristicile programului. Deși est e de preferat să fie folosit un singur limbaj de
programare în cadrul realizării unui produs de cele mai multe ori este imposibil deoarece funcțiile necesare
produsului nu pot fi acoperite de către un singur limbaj de programare.
Calitatea codului este e sențială. Nici un cod nu este lipsit de erori. Astfel prin respectarea unor
reguli elementare de scriere a codului se permite corectarea cu usurință a bug -urilor fără a duce la
generarea de erori noi. În plus complexitatea este redusă fiind mult mai ușor d e înțeles, modificat iar
erorile sunt mai usor de detectat.
Metodele formale fac posibile ințelegerea și punerea in discuție a problemelor, descoperirea
contradicțiilor, prin notații clare și precise.
Ele sunt o modalitate prin care se verificǎ pǎrți d e o importanțǎ majorǎ din programe cu ajutorul
unui studiu abstract, deoarece notațiile matematice au o semanticǎ precisǎ care poate fi ințeleasǎ intr -un
context internațional, inlǎturȃnd ambiguitǎțile.
Testarea software -ului este o parte importantă a pr ocesului de dezvoltare a software -ului. Nu este o
singură activitate care are loc după implementarea codului, ci face parte din fiecare etapă a ciclului de
viață. O strategie de succes a testului va începe cu luarea în considerare în timpul specificării ce rințelor.
Detaliile de testare vor fi elaborate prin desenele de sistem de nivel ridicat și scăzut, iar testarea va fi
efectuată de către dezvoltatori și grupuri de testare separate după implementarea codului.

.

47
Bibliografie

s[1] Kaner, Cem ; Falk, Jack and Nguyen, Hung Quoc, Testing Computer Software, 2nd Ed.. New York,
et al: John Wil ey and Sons, Inc.., 1999 .
[2] Kolawa, Adam; Huizinga, Dorota , Automated Defect Prevention: Best Practices in Software
Management . Wil ey-IEEE Computer Society Press, 2007.
[3] Kolawa, Adam; Huizi nga, Dorota, Automated Defect Prevention: Best Practices in Software
Management . Wiley-IEEE Computer Society Press, 2007.
[4] Gelperin, D.,The Growth of Software Testing, CACM 31, 1988.
[5] Principle 2, Section 1.3, Certified Tester Foundation Level Syllabus .
[6] http://andrei.clubcisco.ro/cursuri/f/f -sym/4idp/1_Etapele_dezvoltarii_doc.pdf
[7] The National Implementation Research Network .
[8] Spinellis, D: Code Reading: The Open Source Perspective. Addison -Wesley Professional, 2003 .
[9] Shaun Bebbington, What is programming , 2014.
[10] P. Biggar, E. de Vries, D. Gregg, A Practical Solution f or Scripting Language Compilers , submission
to Science of Computer Programming, 2009 .
[11] Stevenson, Josep h, Procedural programming vs object oriented programming , 1999.
[12] https://techbeacon.com/web -performance -testing -top-12-free-open -source -tools -conside r
[13] Yourdon, Edward ; Constantine, Larry L. , Structured Design: Fundamentals of a Dis cipline of
Computer Program and Systems Design. Yourdon Press , 1975 -1977.
[14] Kshirasagar Naik, Priyadarshi Tripathy – SOFTWARE TESTING AND QUALIT Y ASSURANCE
Theory and Practice.
[15] Software Engineering — Guide to the Software Engineering Body of Knowledge (SWEBOK) , 2007.
[16] Beizer, B., Software Testing Techniques. Boston, Intern ational Thompson Computer Press, 1990.
[17] Andrei Jechiu – Tehnici de testare, http://www.slideshare.net/andreijechiu/tehnici -detestare –
19909961
[18] http://www.softwaretestinghelp.com/what -is-verification -and-validation/
[19] http://www.softwar eqatest.com/qatweb1.html
[20] https://blog.testproject.io/2016/12/22/open -source -test-automation -tools -for-desktop -applications/
[21] http://www.seguetech.com/the -four-levels -of-software -testing/
[22] Kolawa, Adam , Unit Testing Best Practices , 2009.
[23] IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries .

48
[24] http://www.webperformancetoday.com/2011/01/10/future -of-website -performance -optimization/
[25] Martyn A Ould & Charles Unwin (ed), Testing in Softwa re Development, BCS , 1986 , p71.
[26] https://www.htmlvalidator.com/about.html
[27] Chappel, David, Trouble with CORBA , 1998.
[28] Z ahavi, Ron. Enterprise Application Integration with CORBA: Component and Web -Based Solutions.
John Wiley & Sons , 2014.
[29] Evans, Jim, Selenium Users – Selenium IDE seems dated and lacks features , 2010.
[30] http://www.webperformancetoday.com/2011/01/10/future -of-website -performance -optimization/
[31] https://www.htmlvalidator.com/whats -new.php
[32] IEEE, IEEE Standard, IEEE Standard Glossary of S oftware Engineering Terminology , 1990.
[33] Patton, Ron, Software Testing (2nd ed.) . Indianapolis: Sams Publishing, 2005.
[34] Don Wells, Acceptance Tests , Extremeprogramming.org., 2011 .
[35] http://www.cs.jcu.edu.au/ftp/web/teaching/Subjects/cp1500/1995/foils/may26/may26.html
[36] Williams, Laurie , White -Box Testing , 2003.
[37] Tran, E., Verification/Validation/Certification , In Koopman, P. Topics in Dependable Embedded
Systems. Carnegie Mellon Universit y, 1990.
[38] Elfriede Dustin: Effective Software Testing – 50 Specific Ways to Improve Your Testing .
[39] Pressman, R., Software Engineering: A Practitioner's Approach. Boston, McGraw Hill , 2001.
[40] http://www.seguetech.com/key -phases -software -developm ent/
[41] The Next Generation, Lexicon A to Z, Next Generation . No. 15, 1996.
[42] Kshirasagar Naik, Priyadashi Tripathy: Software Testing and Qualit y Assurance , 2005.
[43] SCJP (Sun Certified Programmer for Java 6) – Kathy Sierra & Bert Bates editura Mc Graw Hill, 2010.
[44] McCabe, T., A Software Complexity Measure , IEEE Transactions on Sof tware Engineering SE -2:
308-320, 1976.
[45] https://www.mountaingoatsoftware.com/blog/differences -between -scrum -and-extreme -programming
[46] https://www.tutorialspoint.com/software_testing/software_testing_tutorial.pdf