1. Ce este testarea software? Generalitati Testarea este un proces de evaluare a unui sistem ori a unei componente a unui sistem pentru a se vedea… [603423]

1. Ce este testarea software? Generalitati

Testarea este un proces de evaluare a unui sistem ori a unei componente a unui sistem
pentru a se vedea daca acesta indepliniste cerintele clientului. In consecinta, in timpul procesului
de testare, practic se cauta in aplicatia aflata sub control, defecte, inconsistente, devieri de la
cerintele clientului sau furnizeaza informatii despre riscul implementarii software.
Testarea implica verificarea si validarea unui sistem sau al unei componente software.
Aceasta poate determina corectitudinea softului sub presupunerea ipotezelor specifice.
In urma procesului de testare nu vor putea fi identificate toate erorile si defectele deoarece nu se
poate testa pentru toate combinatiile de intrari si preconditii.

2. Cand se incepe procesul de testare?

Procesul de testare este recomandat sa se inceapa cat mai devreme. Cu cat un defect este gasit
mai repede cu atat se reduc costurile si timpul necesar fixarii acestuia.
Momentul inceperii testarii depinde si de modelul de lucru folosit pentru dezvoltarea software
ului.

3. Cand se poate opri procesul de testare?

Este greu de realizat cand procesul de testare poate lua sfarsit. In general nu este nimeni care
poate declara ca un software a fost 100% testat. Mereu pot exista scenarii noi la care un tester nu
s-a gandit. Dar, intr-un mediu de lucru testare trebuie sa ia sfarsit la un moment dat, daca sunt
indeplinte unele dintre criterii :
1. Ajungerea la termenul limita a perioadei de testare.
2. Executarea tuturor cazurilor de test care sunt scrise.
3. Rata de defecte scade sub nivelul impus de catre client.

4. Verificare versus validare

Acestia sunt doi termeni care in general produc confuzii in randul oamenilor.
Verificarea este realizata de developeri (cei care dezvolta produsul). Aceasta este facuta in
primul rand pentru a raspunde la intrebarea : ‘Construiesti produsul corect?’. Prin verificare
developerii se asigura ca sistemul intruneste toate cerintele prin verificarea documentatiei si a
codului scris de catre ei.

Validarea este realizata de catre cei care testeaza produsul. Aceasta este facuta in primul rand
pentru a raspunde la intrebarea: ’Construiesti produsul corect?’ . Este un proces care implica
activitati dinamice cum ar fi executarea cazurilor de test cu multa atentie pentru a se descoperi
daca produsul intruneste cerintele clientuli si daca functioneaza corect.

5. Testare vs debugging.

Testarea implica doar indentificarea si raportarea unui defect sau al unei erori insa fara
corectarea acesteia.
Debugging – Implica identificarea, izolarea si fixarea problemelor. Developerii care dezvolta
produs conduc si actiunea de debugging. Aceasta actiune face parte din testarea white box si din
testarea de tip unit.

6. Testarea manuala. Generalitati

Testarea manuala este un tip de testare unde testerii executa manual cazuri de test fara a se folosi
de instrumente de automatizare. Orice aplicatia trebuie in primul rand testata manual, inainte de a
se incepe automatizarea daca este cazul. Unele erori aparute, pot avea severitatea atat de mare
incat pot impiedica pe deplin automatizarea.
Practic, persoana care face testarea manuala se pune in locul unui utilizator normal si foloseste
aplicatia astfel incat sa vada daca totul merge conform cerintelor.

Un prim pas pe care un tester manual trebuie sa il faca este acela de a intelege care sunt cerintele
si dorintele clientului in ceea ce priveste functionarea aplicatiei. Astfel, se poate identifica mai
usor ce si cum trebuie testat si daca un anumit comportament al aplicatiei poate fi clasat ca si
defect sau nu. Se poate spune ca aceasta este una dintre cele mai importante parti ale procesului
de testare. Cu cat persoana in cauza a inteles mai bine modul corect de functionare a aplicatiei si
cerintele clientului cu atat este mai probabil ca softul rezultat la final sa fie mai calitativ.

Un al doilea pas al procesului de testare manuala este acela de scriere a cazurilor de test (test
cases). O data ce cerintele si specificatiile au fost intelese, se poate incepe scrierea propriu-zisa a
cazurilor de test.
Un test case este un set de conditii si variabile cu ajutorul caruia testerul determina daca sistemul
indeplineste toate cerintele si daca este lipsit de erori.
Cu alte cuvinte, acestea sunt scenarii pe care un utilizator normal le-ar putea face si au rolul de a
ghida testerul prin functionalitatile aplicatiei si de a garanta faptul ca testarea a avut o acoperire
mare in aplicatie. De asemenea scrierea de cazuri de test are rolul de a ghida viitori testeri prin
aplicatie, de a le usura munca si de a asigura intelegere.
Continutul unui test case :

1. ID-ul proiectului din care face parte.
2. Numarul test case ului: Acesta ar trebui sa fie unic in cadrul proiectului pentru care este
scris.
3. Rezumatul testului (poate fi considerat ca si titlu).
Din acest sumar al test case ului este necesar sa se inteleaga clar si concis la ce
componenta/functionalitate se refera si ce se testeaza.

5. Preconditiile necesare pentru a putea fi executat testul.
In cazul in care testul nostru necesita o conditie diferita pentru a putea fi executat decat testele
precedente acest lucru trebuie specificat la inceputul test case ului.
Ca exemple de preconditii intalnite des putem enumera: un anumit de cont, GPS- ul dispozitivul
pornit sau oprit, diferite tipuri de conexiune la internet (date mobile, WI-FI, 3G, 4G), diferite
dimensiuni ale ecranelor dispozitivelor etc.
Nu este obligatoriu ca un test sa aiba preconditii.

5. Pasii de executare.
Acest pas este unul foarte important. Testerul ar trebui sa descrie cu exactitate pasii pe care ii
face pentru a ajunge la un rezultat. Decrierea exacta si la obiect a pasilor faciliteaza executarea
pe viitor a acolor teste si de catre alti testeri.

6. Rezultatele asteptate.
In aceasta rubrica, se descrie rezultatul care este asteptat in urma executarii testului.

7. Rezultatele reale
In cazul in care rezultatul testului nu indeplineste rezultatele asteptate, atunci se mai adauga o
rubrica in care se noteaza rezultatele reale obtinute cu descrierea exacta a comportamentului
inadecvat al programului.

8. Statusul testului.
Dupa executarea testului se trece in aceasta rubrica ‘Passed’ in cazul in care rezultatele obtinute
corespund asteptarilor, sau ’Failed’ in cazul in care rezultatele reale nu corespund cu rezultatele
asteptate. In acest caz, mai exista insa si optiunea ca testul sa fie trecut ‘Blocked’ in cazul in care
exista un impediment in executarea acestuia.

9. Comentarii
In cazul in care este nevoie sa se specifice ceva in legatura cu un test, se folosete rubrica cu
comenatrii. Aici se poate explica sucit spre exemplu, de ce testului i s-a pus un anumit status sau
daca exista ceva ce ar putea fi important de luat la cunostinta cu privire la acesta.

10. Numele celui care a creat testul.
11. Data in care a fost creat testul.
12. Numele celui care a executat testul.
De cele mai multe ori, creatorul testului si executantul testului pot fi persoane diferite.
13. Data executarii.
14. Mediul de test.
Este foarte important sa cunoastem aceasta informatie, deoarece indiferent de ce tip de aplicatie
se testeaza, ar trebui sa fie testata in mai multe medii. Spre exempu o aplicatie WEB nu este
suficient sa fie testata pe un singur motor de cautare sau pe o singura versiune a acestuia. Ar
trebui sa fie acoperite cat mai multe, spre exemplu: Mozila, Firefox, Chrome, Internet Explorer,
Safari etc.
In cazul testarii aplicatiilor mobile, ideal ar fi sa fie acoperite toate tipurile de dispozitive. Cum
acest lucru este aproape imposibil deoarece exista foarte multe tipuri de telefoane, se urmareste
testarea pe sistemele principale de operare (Android, iOS, Windows Phone) dar un aspect
important este si tesarea pe dispozitive care au dimensiuni diferite de ecran.

Al treilea pas este testarea propriu-zisa. O data test case urile scrise si mediul de testare pregatit,
se incepe efectiv testarea. Acest procedeu, in general, consta in urmarirea fiecarui test case in
parte si se marcharea lor ca ‘Passed’, ‘Failed’ sau ‘Blocked’ in functie de situatie. In timpul
testarii manuale, este foarte important sa se tina notite cu ceea ce se intampla cand un test
esueaza.

Un al patrulea pas in procesul de testare este raportatrea defectelor si erorilor gasite in urma
procesului de testare. Acest lucru este facut cu ajutorul instrumentelor si platformelor
specializate in gestionarea rapoartelor defectelor.
Un raport corect contine :
1. Titlul – trebuie sa fie scurt si la obiect dar ar trebui sa se inteleaga doar din citirea lui atat
zona afectata a a plicatiei cat si problema.
2. Pasii de reprodcere
Avand in vedere ca acest raport al defectului va ajunge la developer, totul trebuie descris pas cu
pas si cu toate amanuntele necesare pentru ca developerul sa il poata reproduce cu usurinta. 3.
Rezultatele asteptate
In acest pas se descrie care ar trebui sa fie comportamentul aplicatiei sau care ar trebui sa fie
rezultatul unei anumite actiuni facute asupra sistemului aflat sub test.
4. Rezultatele actuale
In acest pas se descrie comportamentul deficitar al aplicatiei. De asemenea este recomandat sa se
ataseze capturi de ecran, inregistrai sau documente aditionale care au rolul de a ajuta intelegerea
exacta a problemei.

In general, testarea manuala necesita un efort mare, oamenii fiind predispusi sa sara
anumite parti, sau sa incerce mereu sa automatizeze totul. Dar adevrul este ca desi testarea
automata este foarte utila si ajuta foarte mult, nu putem acoperi tottul cu ajutorul ei. In fond,
oameni reali vor fi cei care vor folosi aplicatia, de eceea este indicat existenta macar unei
persoane care face testare manuala intr-un proiect. O persoana care se ocupa de acest tip de
testare, de cele mai multe ori va gasi anumite tipuri de defecte care in urma testarii automate nu
vor fi gasite.

7. Testare automata
Testarea automata este testarea facuta cu ajutorul unui soft special care ajuta la
exacutarea automata a testelor si compararea rezultatelor actuale cu cele reale, rezultate in urma
testarii.
Desi unele intrumente folosite in procesul de testare automata pot fi scumpe, acest tip de tesare
este unul foarte util, deoarece o data scrise testele automate, ele pot fi rulate oricand din nou (ex:
in cazul testelor de regresie), fara vreun alt efort suplimentar.
Cand vine vorba de proiecte complexe este imposibil ca totul sa fie automatizat. In
primul rand, este recomandat ca testele automate sa se concentreze pe partile cele mai utilizate
ale aplicatiei si pe cele pe care exista sansa sa le folosesaca multi utilizatori simultan (paginile de
logare, paginile de creare conturi, functionalitatile principale ale aplicatiei etc.)
Testarea automata ar trebui sa fie pusa in practica in urmatoarele situatii :
1. Cand se dezvolta procese complexe
2. Cand se lucreaza la proiecte care necesita testarea acelorasi functionalitati frecvent.
3. Cerintele clientului cu privire la arhitectura si interfata aplicatiei nu se schimba frecvent
4. Cand softul este stabil si a fost testat manual precedent.
5. In momentul in care se dispune de suficient timp.

7. Clasificarea generala a tipurilor de testare.

Domeniul testarii este unul desosebit de complex. Exista numeroase tipuri de testare care se
clasifica dupa urmatorele criterii :

1. Daca privim care este obiectivul testarii avem urmatoarele tipuri: functional testarea
functionala si testare non functionala.
2. In functie de tipul de cunoastere pe care il avem asupra sistemului : white box testing,
black box testing, grey box testing.
3. In functie de metoda de executie: manuala, automata, semi automata.
4. In functie de nivelul la care este testata aplicatia: component testing, integration testing,
system testing.

5. In functie de nivelul de dezvoltare al proiectului in care este facuta testarea : alpha
testing, beta testing, regression testing, acceptance testing, smoke test.
6. In functie de tipul de scenariu : testare cu scenarii pozitive si testare cu scenarii negative
7. In functie de gradul de pregatire pentru tesatre : documentation testing, exploratory
testing, ad-hoc testing.
8. In functie de baza pe care este facuta testarea : testare bazata pe test case-uri si testare
bazata pe experienta.

https://www.utest.com/articles/the-classification-of-types-of-software-testing

8. Testarea de tip “Black box”.
In cadrul testarii de tip black box, nu este cunoscut codul sursa al programului. In timpul
acestui tip de testare se interactioneaza cu interfata sistemului, facand actiuni pe care un
utilizator normal le-ar putea face si examinand rezultatele. In cele mai multe cazuri, acest tip de
testare se bazeaza pe test case-uri. In aceasta categorie putem incadra si testarea functionala si
non functionala.

8.1 Tehnici de testare black box
Aceste tehnici au rolul de a ajuta testarea produsului si de a minimiza numarul de test case-uri.
1. Tehnica partitiilor echivalente (equivalence partitioning)
Utilizand aceasta tehnica se reduce foarte mare parte din munca. Procesul consta in gruparea
conditiilor de test in grupuri mai mici, astfel incat sa fie testata doar o singura valoare din cadrul
unei partitii, nu toate.
2. Analiza valorilor limita (boundary value analysis)
In cazul acestei tehinici, la fel ca la tehnica precedenta se impart conditiile de test in partitii,
diferenta fiind ca aici se testeaza doar valorile limita (superioara si inferioara) si o valoare de
mijloc. Spre exemplu, daca un utilizator are dreptul sa isi aleaga o parola care poate avea intre 6
si 10 caractere, se va testa in primul rand cazul in care se introduce o parola mai mica de 6
caractere (nu ar trebui sa fie permis si in general va fi afisat un mesaj de eroare), cazul in care
care se introduce o parola mai mare de 10 caractere (la fel nu ar trebui sa fie permis) si inca un
caz in care se va introduce o parola care este intre 6 si 10 caractere, teoretic, acest lucru fiind
permis. Aceasta tehnica este folosita atunci cand exista mult prea multe cazuri de testat
individual.
3. Tehnica tablei de decizii (decision table testing)
Aceasta tehnica este folosita pentru softurile in care exista combinatii complexe de intrari
(input-uri) care cumulate pot duce la decizii diferite. Este de altfel cunoscuta ca si tabelul ‘cauza
efect’.
4. Testarea tranzitiilor (state transition table)

Orice sistem aflat sub test poate sa genereze rezultate diferite pentru aceeasi intrare, totul
depinzand de conditiile exterioare, asta insemnand ca s-a trecut la alta stare de tranzitie.
5. Testarea exploratorie (exploratory testing)
Partea de exploratory testing se face de catre un tester care se transpune in locul unui utilizator
normal si face anumite actiuni strategice pentru a maximiza ariile acoperite de teste.
Acest tip de testare se poate considera de tip black box deoarece nu este necesara cunoasterea
codului sursa ci a cerintelor clientului si al comportamentului normal al aplicatiei.

6. Ghicirea erorilor (error guessing testing)
Acest tip de testare este facut de obicei doar de testerii cu experienta. O astfel de persoana
intuieste usor care parti ale aplicatiei sunt afectate de anumite schimbari, care sunt componentele
in care apar cel mai des erorile dar si partile sensibile ale unei aplicatii.

9. White box testing
Acest tip de testare se ocupa cu testarea si analizarea structurii interne a programului, ceea ce
inseamna ca avem acces la codul sursa. Se aplica pentru unit testing, integration testing si system
testing.
Ca si tehnici principale ale testarii de tip white box putem aminti:
1. Statement coverage
Scopul acestui tip de testare este de a asigura fiecare instructiune din cod este executata macar o
data.
2. Decision coverage
Scopul acestui tip de testare este de a asigura ca fiecare decizie (if, elese, for) a fost executata
macar o data.
3. Condition coverage
In aceasta etapa fiecare conditie din cod este executata macar o data.

Ca si tehnici secundare ale testarii de tip white box putem amninti:
1. Api Testing
Este testarea aplicatiei folosind API (aplication programing interface) public si privat. API este
un set de subrutine, protocoale si instrumente pentru construirea aplicatilor software. Aceasta se
poate considera si o metoda de comunicare dintre mai multe componente software.
2. Code coverage
Se creaza teste pentru a se observa daca codul satisface toate crietriile.
3. Fault injection
Aceasta tehnica consta in introducerea intentionata a unor greseli in cod pentru a se observa
eficacitatea tehnicilor de testare.
4. Mutation testing

Acesata tehnica consta in modificarea programului in mici moduri. Fiecare versiune se numeste
‘mutant’, iar testele ar trebui sa respinga aceste versiuni datorita comportamentului codului
original. Scopul este de a ajuta testerul sa localizeze slabiciunile in sectiuni de cod neaccesate in
timpul executiei.
5. Static testing
Implica analiza softului si a codului fara a fi executat.

10. Testare functionala
Testarea functionala verifica fiecare parte dintr-un program software pentru a se asigura
ca cerintele sunt implementate corect si sistemul functioneaza adecvat. Cu alte cuvinte, se
verifica daca ce ar trebui sa faca sistemul aflat sub test chiar face.

Atunci cand sunt facute teste de tip functional trebuie avut in vedere :
1. Se identifica datele pentru intrari
2. Se determina care ar trebui sa fie rezultatul asteptat bazat pe acele intrari
3. Rularea de cazuri de test cu intrarile propriu zise.
4. Compararea rezultatelor asteptate cu rezultatele actuale.
Urmand acesti pasi si comparand la final rezultatele asteptate cu rezultatele actuale, daca acestea
corespund testului i se va putea atribui statusul de ‘Passed’. In cazul in care rezultatele actuale si
rezultatele asteptate nu se potrivesc, astea inseamna ca exista o eroare in software.

10.1 Tipuri de testare functionala
● Unit Testing
Testele de tip unit sunt facute da catre developeri. Acestia isi testeaza codul, prin rularea unor
teste scrise de ei, pentru a observa daca indeplineste cerintele si face ceea ce ar trebui sa faca.
Acest tip de testare apartine si de ‘Black box testing’.
● Regression Testing
Acest tip de testare este unul amanuntit si este facut pentru a observa ca anumite schimbari in
cod, cum ar fi adaugarea de noi componente sau fixarea unor probleme nu au afectat si alte parti
deja existente ale aplicatiei sau nu au cauzat instabilitate. Acest tip de testare ar trebui facut
frecvent pentru a se asigura stabilitatea sistemului.
● Smoke testing
Acest tip de testare este rulata pentru functionalitatile principale. Este facuta inainte de a incepe
orice alt timp de testare, pentru a observa daca are sau nu rost sa se continue cu celelate tipuri de
testare.
● Sanity testing
Acest tip de testare este asemanator cu smoke testing. Este un subset al regression testing. Este
folosit cand timpul nu este de ajuns pentru a rula toate testele de tip regression sau cand au fost

facute doar schimbari minore in cod. Se testeaza doar partile majore ale aplicatiei pentru a se
observa daca schimbarile nu au afectat alte componente deja existente.
● Integration Testing
In cadrul acestui tip de testare, multiple module ale unui sistem care au fost dezvoltate separat
sunt considerate un intreg si sunt testate ca atare.
● Interface Testing.
Interfata este o conexiune care uneste doua sau mai multe componente. Acest tip de testare este
facuta pentru a asigura faptul ca doua sau mai multe sisteme sau componente controleaza si
transfera corect datele de la una la alta. In timpul rularii acestui tip de teste trebuie sa ne
asiguram ca : toate componentele software/hardware suportate au fost testate, comunicarea dintre
componente se face corect, orice documente astasat poate fi deschis si este suportat de toate
platformele, etc.
● System Testing
Acest tip de testare verifica comportamentul sistemului complet integrat, insa de cele mai multe
ori nu avem o interfata reala a produsului. Daca la integration testing atentia se concentreaza pe
gasirea problemelor cauzate de integrarea a doua sau mai multe module, in aceasta faza scopul
este gasirea problemelor sau a defectelor in comportamentul general aplicatiei si de asemenea se
doreste sa se observedaca aplicatia indeplineste cerintele specificate. Datele folosite in testare
sunt prefabricate, ne fiind folosite datele reale din productie pentru acest tip de testare. System
testing este de tip black box dar se poate incadra atat la functional testing cat si la non functional
testing.
● UAT (user acceptance testing)
UAT este facut dupa system testing. In acest tip de testare se verifica comportamentul aplicatiei,
dupa ce toate modulele au fost unite, utilizandu-se date reale, din productie. Testerul trebuie sa se
comporte ca un utilizator real pentru a valida faptul ca aplicatia indeplineste cerintele clientului.
Apartinand de black box testing, acest timp implica toate multe tehnici de tesatre cum ar fi
boundary value analysis, equivalence partitoring and decision table testing. De asemenea se
testeaza sistemul si cu intrari intamplatoare, iar defectele gasite sunt considerate esecuri ale
produsului.

11. Testare non-functionala
Testarea de tip non-functional verifca aspectele care nu tin de functionalitatile aplicatiei
cum ar fi securitatea, perforamanta, scalabilitatea, etc. Este important ca cerintele pentru testare
sa fie prioritizate si atributele calitatii sa fie identificate corect.
Un prim scop al testarii de tip non functional este acela de a reduce riscurile gasirii
punctelor slabe ale aplicatiei in productie si a cheltuielilor asociate acestora.

Un al doilea scop este de a ajuta optimizarea produsului in aspectele esentiale oricarui
soft cum ar fi instalarea, executarea, gestionarea si monitorizarea.
De asemenea un al treila scop este colectarea datelor si efectuarea de masuratori pentru
cercetare si dezvoltare interna si de asemenea pentru a imbunatati comportamentul si tehnologiile
produsului aflat in uz.
Nu in ultimul rand, testarea de tip non functional are rolul de a creste performanta la
utilizare, mentenabilitatea, eficienta si portabilitatea produsului.

● Performance testing
Este executat pentru a determina cum un sistem functioneaza in ceea ce priveste
stabilitatea, capacitatea si viteza de reactie, stabilitatea in cadrul unui anumit volum de munca si
date sau cum utilizeaza resursele. Dupa rulea acestor tipuri de teste se poate determina spre
exemplu ​ numărul de utilizatori virtuali, accesările pe secundă, erorile pe secundă, timpul de
răspuns, laten ț a ș i octe ț ii pe secundă (capacitatea de transfer), precum ș i corela ț iile dintre
acestea.
Fiind un tip de testare complex, acesta cuprinde inca doua tehnici de testare.
Prima tehnica este ‘load testing’ aceasta fiind recomandata sa se faca atunci cand se
doreste determinarea numarului de utilizatori pe care sistemul ii poate gestiona si a capacitatii
maxime de operare a unei aplicatii. Se pot stabili diferite scenarii de test pentru concentrarea pe
anumite functionalitati ale aplicatiei pe care exista posibilitatea sa fie multi utilizatori simultan
pentru a determina cata memorie CPU este cosnumata si care este timpul de raspuns al retelei.
De asemenea se poate determina modul in care se incarca aplicatia, asta diferind de la dispozitiv
la dispozitiv sau cum se sutine sistemul per total.
Acest tip de testarea poate fi facut sub conditii controlate pentru a compara capabilitatile
si performantele diferitelor tipuri de sisteme sau a determina cu exactitate capacitatea unui singur
sistem.
Scopul principal al acestui tip de sistem este de a determina capacitatea maxima de
munca pe care un sistem o poate face, insa fara o degradarea semnificativa a performantei.
Ca si exemple de load testing ar fi : ​ descărcarea unei serii de fi ș iere de dimensiuni mai mari,
rularea simultan a mai multor aplicatii, atribuirea mai multor lucrări unei imprimante într-o serie,
supunerea unui server la o cantitate mare de trafic, scrierea ș i citirea datelor de pe un hard disk
continuu.
Acesta este tipul de testare care ar trebui reluat frecvent, pentru a se asigura ca
performanta sitemului aflat sub test nu a scazut in urma unor modificari.
A doua tehnica de testare este ‘Stress testing’. Acest tip de testare implica verificarea
functionarii unui sistem dincolo de capacitatile normale ale acestuia, pana se ajunge la un punct
in care aplicatia esueaza. In acest punct scopul este de a determina stabilitatea unui sistem dat. ​ Se
pune un accent mai mare pe partea de disponibilitate ș i tratare a erorilor sub o sarcină grea sau
sub un volum mare de date.

Pentru a efectua aceste tipuri de teste se utilizeaza seturi de date masive care se pot pierde
în timpul testelor. Obiectivele acestor tipuri de teste sunt asigurarea faptului că software-ul nu se
prăbu ș e ș te în condi ț ii de r esurse insuficiente de calcul (cum ar fi memoria sau spa ț iul de pe disc),
de asemenea determinarea punctului critic de operare si modul cum un sistem se recupereaza
dupa ce esueaza in cadrul unei sarcini.

● Failover Testing
Acest tip de testare validează capacitatea unui sistem de a aloca resurse suplimentare ș i
de a muta opera ț iile în sis teme de back up in cazul unei caderi a sistemului. De asemenea, se
folosete pentru a verifica capacitatea sistemului aflat sub test de a continua opera ț iunile în timp
ce capacitatea de procesare este transferată într-un sistem de back-up. Nu in ultimul rand se,
determină dacă un sistem poate aloca resurse suplimentare, cum ar fi memorie CPU sau servere
suplimentare, în timpul unor defec ț iuni critice sau în momentul în care sistemul atinge un prag
prestabilit de performan ț ă.
● Security Testing.
Acest tip de testare este unul foarte important deoarece evaleaza pragul de siguranta sau
eventualele vulnerabilitati ale aplicatiei care pot duce la spargerea sistemului de catre o persoana
neautorizata.
Scopul acestui tip de testare este de a gasi si masura potentialele vulnerabilitati pentru a
pute fi fixate de catre developeri.
Fiind un tip de testare foarte complex care implica multe portiuni de verificat, acesta
implica mai multe sub-tipuri de testare.
Un prim sub tip este ‘Vulnerability scanning’. In aceasta etapa codul sursa este scanat
automat printr-un program special care descopera unele vulerabilitati.
Un a doilea sub tip de testare este ‘Security scanning’. Acest sub tip de testare implica
identificarea deficientelor atat de retea cat si de sistem. Scanarea poate fi facuta atat manual cat
si automat.
Un al treilea sub tip de testare este ‘Penetration testing’. Acest sub-tip de testare, practic
se simuleaza un atac al unui hecker. Se analizeaza vulnerabilitatile sistemului afalt sub test in
timpul unei incercari de atac asupra sistemului(hacking).
Un al patrulea sub-tip de testare este ‘ ​ Risk Assessment ​ ’. Acest sub tip de testare implica
analiza riscurilor de securitate observate în cadrul organiza ț iei. Riscurile sunt clasificate ca
‘scăzut’,’ Mediu’ ș i ’Înalt ’. In urma acestui tip de testare se recomanda controale ș i măsuri
pentru reducerea riscului.
Un al patrulea sub tip de testare este ‘Security auditing’.
● Compatibility Testing
● Usability Testing
● Maintainability Testing
● Scalability Testing

● Volume Testing
● Security Testing
● Disaster Recovery Testing
● Compliance Testing
● Usability Testing
● Portability Testing
● Efficiency Testing
● Reliability Testing
● Baseline Testing
● Endurance Testing
● Documentation Testing
● Recovery Testing
● Internationalization Testing
● Localization Testing
● Instalation testing
Majoritatea produselor software au nevoie de instalare pentru a functiona si proceduri diferite in
acest scop. Acest tip de testare verifica daca produsul se instaleaza, dezinstaleaza si actualizeaza
corect. Exista multe medii de operare, cee ce inseamna ca este un proces complex. Un program
se poate instala in diferite moduri, poate adauga diferite fisiere pe drive si poate face anumite
schimbari in sistemul de operare sau poate avea acces la anumite date (locatie, camera, microfon
etc.)