Sunteți pe pagina 1din 12

MINISTERUL APARARII NATIONALE

ACADEMIA TEHNICA MILITARA

PROIECT
Testarea, evaluarea si certificarea
sistemelor tehnice

Coordonator: Student:

Prof. Grigore JELER Alexandru Mirela-Elena

2015
I.Introducere in fiabilitate

Din punct de vedere matematic, fiabilitatea unui obiect (o componenta sau un


sistem) este o functie de timp F(t), definita ca probabilitatea ca, in conditii de
mediu specificate, obiectul sa functioneze adecvat in intervalul de timp [0,t).

Astfel, fiabilitatea este o probabilitate, cuprinsa intre 0 si 1, insa nu se poate


spune cu exactitate ca exista un sistem perfect fiabil, pentru care F(t) = 1 daca t >
0. Functia de fiabilitate se poate define odata cu definirea mediului/sistemului pe
care aceasta functioneaza.

Ca in orice sistem ce evolueaza permanent, pot aparea diferite erori, aceste


putand fi clasificate astfel:

 Erori tranziente = erori care se manifesta printr-o defectiune temporara a


unei componente, insa nu prin defectarea ei definitive (in sistemele de
calcul, majoritatea erorilor care pot aparea sunt cele de tip tranzient)
 Erori permanente = se produc la un moment dat si vor continua sa apara
pina cind sistemul este reparat (ca si exemplu putem da defectele din
fabricatie).

Defectul constă într-o greșeală sau lipsa pregătirii corecte a unei componente.

Eroarea este deviația inițială de la starea sistemului care conduce la apariția


defecțiunii (constă într-un comportament neintenționat/neașteptat).

Defecțiunea este deviația de la funcționarea corectă a serviciului.

Punctul principal in teoria fiabilitatii (reliability theory) este obtinerea unor


sistemelor fiabile din componente nefiabile. Pentru un sistem care ar functiona
doar daca toate componentele sale ar fi functionale, fiabilitatea ar descreste
exponential cu numarul de componente, astfel neputandu-se realiza un sistem de o
complexitate crescuta.
O functie de fiabilitate foarte buna pentru dispozitivele hardware se poate
obtine folosind o combinatie de tehnici, cum ar fi implementarea unei forme de
redundanta, proiectare si fabricatie cu precizie foarte ridicata, si o faza agresiva de
testare si ``ardere'' (burn-in). Aceasta faza din etapa de dezvoltare si testare,
denumita si „burn-in'', reprezinta o faza de testare pentru determinarea maturitatii
componentelor, in acest fel, componentele cu mortalitate infantila ridicata putand fi
eliminate.

Cei mai mari fabricanti de ocmponente proiecteaza si testeaza astfel de sisteme


de calcul in conditii mai nefavorabile decit cele specificate. Un exemplu ar putea fi
realizarea unui proces de „overclocking'', in care este specificata frecventa de ceas
la care acesta poate opera. Insa, de cele mai multe ori, un procesor cu specificatie
de ceas de 1Ghz poate opera la 1.2Ghz, datorita marginilor de toleranta din
fabricatie.
Figura 1a) si b): Graficul ratei de eroare a unui dispozitiv in functie de virsta sa: dispozitivele
foarte noi si foarte vechi au o probabilitate mai mare de a se defecta, datrita unor defectiuni de
fabricatie sau datorita uzurii.

II.Fiabilitatea unui sistem software

Desi, din punctul de vedere al unui utilizator obisnuit, un program nu se


uzeaza, fiind considerat un obiect determinist, care va da acelasi rezultat pentru
aceleasi date de intrare, programele au o fiailitate mai scazuta decat sistemele
hardware. Cea mai importanta cauza a defectarii programelor sunt bug-urile, adica
implementari incorecte. Orice programator foarte priceput poate produce
programe cu defecte.

Complexitatea componentelor software actuale este prea mare pentru a putea


fi stapinita de catre un programator si , desi au aparut progrese substantiale in
tehnicile de programare, un exemplu fiind descompunerea programelor in module
mici, folosirea unor limbaje de programare evoluate si a unor unelte complexe
pentru dezvoltarea, testarea si analiza programelor, rezultatele nu sunt cele
scontate.

Figura 2: Graficul ratei de eroare a unui dispozitiv in functie de virsta sa: operațiile de
upgrade conduc la scăderea fiabilității
Mare parte din problemele rezolvate in software sunt atit de complicate incit
nu se pot evidentia in mod precis. De aceea, programatorii vor intalni o multime
de incertitudini la implementarea unei solutii. O cauza fundamentala a lipsei de
fiabilitate a programelor este specificatia incompleta si, de cele mai multe ori,
imprecisa.

Cele mai importante defectiuni software se manifesta atunci cand sunt


introduse ca si intrari anumite combinatii de valori pentru datele de intrare sau
pentru anumite succesiuni de evenimente externe, evenimente neprevazute de
programator. Aceste combinatii apar cu probabilitate foarte mica in timpul
procedurilor normale de testare, astfel nefiind depistate pana in faza operationala.

Orice program trece prin diferite etape de modificare si imbunatatire,


cunoscute ca si „upgrades''. Versiunile noi sunt construite pe baza celor vechi, fiind
reperate acele defectiuni descoperite si adaugandu-se noi functionalitati
programului. Insa, procesul repararii defectiunilor poate introduce noi defectiuni,
pentru ca efectele unei imbunatatiri au uneori consecinte nebanuite de catre
programator.

Odata cu scaderea costurilor si compactarii dispozitivelor hardware, acestea


pot fi integrate in dispozitive electronice mai mai avansate. Aceste dispozitive au
nevoie de un software nou cu care utilizatorul sa poata manipula sistemul. Pe
masura ce costul dispozitivelor de stocare a informatiei scade, noi tipuri de
informatii complexe pot fi stocate si prelucrate mai departe.

Astfel, datele stocate cu mult timp in urma nu mai pot fi folosite de noile
sisteme de calcul, datorita invechirii dispozitivelor periferice ce nu mai sunt
suportate de fabricanti, dar si datorita programelor vechi, ce incep sa manifeste
erori.

Domeniul ingineriei programelor sau software engineering se ocupa cu


implementarea de noi metode prin care sa se poate cuantifica si imbunatati
calitatea acestor programe. Bug-urile software sunt persistente: cu aceleasi conditii
programul se va comporta in acelasi fel.

O solutie ar putea fi programarea cu N versiuni, care se face prin executarea


in paralel a N programe diferite, scrise de echipe diferite de programatori, folosind
unelte si tehnologii diferite. Toate cele N programe vor rezolva aceeasi problema,
insa in moduri diferite.

Specificatiile imprecise ale problemei pot fi detectate prin utilizarea acestei


tehnici, deoarece implementarile diferite pot lua decizii diferite pentru cazurile
nespecificate. Insa, programarea cu N versiuni este o metodologie foarte scumpa,
folosita numai pentru aplicatii critice, unde siguranta este vitala functionarii
sistemului.

Un exemplu ar putea fi solutia gasita de utilizatorii sistemului de operare


Windows de la Microsoft: zona de reboot a calculatorului. Numele stiintific al
acestei solutii este reintinerirea programelor sau software rejuvenation.
Reintinerirea este cauzata de repornirea periodica a programelor. Acest proces de
repornire va duce la initializarea starii interne la o anumita valoare initiala.
Tehnica aceasta este aplicabila numai daca starea interna a programului nu este
importanta si poate fi pierduta, astfel, intinerirea trebuie sa fie combinata cu
checkpoint'-uri. Un checkpoint va salva informatia importanta pe un mediu de
memorie persistent si o va restaura odata ce programul este repornit.

Reintinerirea se aplica mai ales pentru programele de tip server, care


executa tot timpul o bucla, acceptind cereri de la clienti si raspunzand la ele. Multe
servere sunt lipsite de stare sau stateless, in sensul ca ele nu vor pastra nici o
informatie despre tranzactia efectuata cu un client dupa ce aceasta s-a consumat.

Reintinerirea este eficienta doar daca costul estimat repornirilor periodice


este mai redus decit cel al repornirii dupa o cadere catastrofica, care poate duce la
aplicarea unei proceduri sofisticate de recuperare a datelor pierdute. De asemenea,
este folosita si in cazul in care serverele care ofera serviciul au o rezerva sau
backup, astfel incit servere de rezerva sa poata raspunde clientilor in timp ce altele
se reinitializeaza.

Un alt concept este verificarea formala, reprezentata printr-o serie intreaga


de tehnici sofisticate care certifica corectitudinea, mai ales a sistemelor hardware,
dar si a unor sisteme software. Verificarea formala se ocupa de descoperirea si
eliminarea bug-urilor care pot aparea, insa poate fi considerata ca fiind o tehnica de
imbunatatire a fiabilitatii programelor.

Analiza, depistarea si corectarea erorilor din pachetele de programe, a bug-


urilor, este o activitate curenta in orice firma producatoare de soft. De-a lungul
anilor, au fost implementate si testate diferite procedee de automatizare a
depistarii si corectarii erorilor, pentru realizarea unor mecanisme de testare a
acestor programelor.

In cadrul firmelor de soft, sunt aplicate norme si proceduri legate de munca


de programare, dar si de conditiile de calitate, pentru a se putea determina o medie
a erorilor la mia de linii de cod, un numar mediu de erori care pot fi corectate in
etapele de testare, precum si procentul de eventuale erori nedepistate.

Gradul de acceptare al acestor erori depinde de destinatia sistemului si


influenteaza atat pretul de vanzare al produsului program, cat si cel al sistemului in
ansamblu, aceste cerinte fiind diferite pentru un calculator de proces, pentru un
software creat pentru monitorizarea unei centrale nucleare sau pentru un simplu
calculator personal.

Se poate vorbi despre siguranta functionarii unui program, dar si a


intregului sistem, acceptandu-se faptul ca un program are o durata de viata limitata,
de posibilitatea aparitiei unor erori, ce pot duce la crearea unor brese (incidente) de
securitate sau de aparitia unei versiuni noi, mai performante, care va inlocui
versiunea actuala.

III. Testarea fiabilitatii unui sistem software

Testarea fiabilitatii produselor software apartine domeniului de testare


software-ul, si anume a capacitatii software-ului de a functiona, in anumite
conditii, pentru o perioada anumita de timp. Testele de fiabilitate pentru produsele
software ajuta la descoperirea multor probleme in proiectarea si functionalitatea
lor.

Deoarece, de multe ori, aceste aplicatii sunt folosite in sisteme critice de


siguranta, fiabilitatea software-ul a devenit un domeniu important de cercetare.
Desi ingineria software a avut cea mai rapida dezvoltare in secolul trecut, pana la
acest moment nu exista o metoda stiintifica completa pentru evaluarea sistemelor
software. Testele de fiabilitate pentru componenta software sunt utilizate ca un
instrument pentru a ajuta la evaluarea acestor tehnologii de inginerie software.
Pentru a imbunatati performanta produsului software, dar si a procesului de
dezvoltare si implementare, este necesara crearea unei evaluari detaliate a
conceptului de fiabilitate.

Tipuri de testare a fiabilitatii:

 Testarea caracteristicilor: verificarea caracteristicilor oferite de software


prin urmatorii pasi:
o fiecare operatie este executata o data;
o interactiunea dintre doua operatii se reduce;
o fiecare instructiune se verifica pentru o executare
corespunzatoare;
 Test de incarcare: acest test este efectuat pentru verificarea performantei
sistemului software in sarcina maxima de lucru. Orice software se comporta
conform specificatiilor date de producator pana la o anumita cantitate a
volumului de munca, pentru ca apoi timpul de raspuns al software-ului sa se
degradeze. De exemplu, un site web poate fi testat pentru a se vedea cati
utilizatori poate sa sustina simultan, fara o degradare a performantei. Aceasta
testare ajuta la dezvoltarea aplicatiilor pentru baze de date si servere.
Testarea de incarcare necesita, de asemenea, teste de performanta asupra
software-ului, pentru verificarea modului in care acesta lucreaza un trafic
diferit facut de utilizatori .
 Teste de regresie: testarea de regresie este utilizata pentru verificarea
introducerii unor noi bug-uri, prin repararea bug-urilor anterioare. Testarea
de regresie este realizata dupa fiecare modificare sau actualizare in
caracteristicile software-ului. Aceasta testare este periodica, in funcție de
lungimea și caracteristicile software-ului.
 Stress test: testarea sistemului “la limită”, prin incercarea de fortare a
sistemului la granitele specificatiei initiale date de producator.

Figura 3 arata modul in care se poate aplica un stress-test pe o retea de


comunicatii, prin infuzia de sesiuni deschise de un numar mare de utilizatori,
oservandu-se modul in care componenetele acestui sistem, in special Firewall-ul si
Load-Balancer-ul vor raspunde la traficul venit de la utilizatori.
Figura 3 : Implementarea unui stress-test pentru o retea de comunicatii

Testarea securitatii

Testarea securitatii software investigheaza comportamentul software-ul si


verifica daca acesta este in conformitate cu cerintele de securitate. Testele de
securitate, in special, sunt efectuate in conformitate cu un plan de proceduri de
testare si de securitate. Testarea securitatii se concentreaza pe gasirea punctelor
slabe in sistemul software si identificarea situatiilor extreme sau neasteptate care ar
putea determina o incalcare a protocolului de securitate implementat. Eforturile de
testare de securitate sunt adesea limitate de cerintele software, clasificate ca fiind
elemente de securitate "critice".

Proiectantii de software de securitate realizeaza o multitudine de sarcini pentru a


putea administra riscurile de securitate pentru sistemul software:

a) crearea unor cazuri in care se produc incidente de securitate;

b) listarea necesitatilor de securitate ale sistemului;

c) analiza riscurilor arhitecturale;

d) crearea unor teste de securitate bazate pe riscuri;

e) folosirea unor instrumente statistice de analiza;


f) implementarea unor teste de securitate;

g) modificarea sistemului in functie de rezultatele obtinute dupa descoperirea


posibilelor brese de securitate.

Stress-Testing intr-un sistem software

Acest tip de testare este folosit pentru determinarea abilitatilor unui


calculator, retea sau dispozitiv pentru a mentine un anumit nivel de eficacitate in
conditii nefavorabile. Acest proces consta in aplicarea unor teste cantitative intr-un
laborator, cum ar fi masurarea frecventei erorilor sau caderi ale sistemului, dar si
evaluarea la atacuri de tip DoS (Denial-of-Service).

Figura 4 : Etapele implementarii unui stress-test

Pentru testare se folosesc scenarii aplicate pentru medii adverse, precum:

 rularea simultana a mai multor aplicatii consumatoare de resurse pe un


singur calculator;
 spargerea protectiei unui calculator si folosirea lui ca un „zombie” pentru a
raspandi mesaje spam in retea;
 inundarea unui server cu mesaje nefolositoare de tip e-mail;
 accesarea multipla a unui singur site Web;
 infectarea unui sistem cu virusi, Troieni, spyware sau alte programe de tip
malware.

Conditiile adverse sunt inrautatite progresiv si metodic, pana cand nivelul de


performanta va scadea sub cel minim sau pana cand sistemul va inceta sa
functioneze. Pentru obtinerea unor rezultate cat mai corecte, stresorii individuali
vor varia unul cate unul, ceilalti ramanand constanti. Insa acest tip de testate este
obositoare si consumatoare de timp.
Un software de testare este cel oferit de compania MindFireSolutions, denumit
Apache JMeter. Acesta este folosit pentru testarea retelelor clientilor de business
din domenii, precum cel bancar sau informational. Este un program de tip open
source si ofera:

 testarea performantelor;
 descoperirea punctului de intrerupere al unui sistem (breaking point);
 testarea scalabilitatii/capacitatii/ stress-testing;
 testarea sincronizarii si detectia de spike-uri;
 verificarea largimii de banda intr-o retea;
 imbunatatirea performantelor si diagnoza;
 teste de rezistenta
Figura 5a) si b) : Rezultatele obtinute folosind Apache JMeter