Sunteți pe pagina 1din 51

FACULTATEA DE ELECTRONICA, TELECOMUNICATII SI TEHNOLOGIA INFORMATIEI

Implementarea, testarea, verificarea i


validarea produselor software





Coordonator,
Conf. Dr. Ing. tefan Stncescu

Lecu Radu erban
Tic Andra Maria
Vidracu Mihai
442A
-2011-

Cuprins

I. Etapele de realizare ale produselor software Lecu Radu erban
1. Introducere
2. Etapele de realizare ale unui produs software

II. Implementarea produselor software
1. Introducere
2. Scopul
3. Codul surs
3.1. Scopul
3.2. Organizarea
3.3. Calitatea
3.4. Licenierea
4. Calitatea produselor software
5. Limbajul de programare
5.1. Compilarea i interpretarea
5.2. Limbaje procedurale vs. limbaje obiect-orientate
5.3. Alte limbaje de programare folosite
6. Reguli de scriere a unui cod de calitate
7. Documentarea codului
7.1. Pseudocod
7.2. Organigrame
7.3. UML
8. Concluzii

III. Testarea produselor software
1. Introducere
2. Scopul testrii
3. Realizarea unui test software
4. Automatizarea testrii

Bibliografie

5. Tipuri de teste software Vidracu Mihai
5.1. Testare prin metoda cutiei negre (Black-box)
5.2. Testare white-box
5.3. Testare gray-box
5.4. Testarea funcional
5.5. Testarea nefuncional
5.5.1. Testare de compatibilitate
5.5.2. Testare de anduran
5.5.3. Testare de incrcare
5.5.4. Testare de localizare
5.5.5. Testarea de performan
5.5.6. Testare de securitate
5.5.7. Testare de utilizabilitate
5.6. Concluzii
Bibliografie

IV. Verificarea i validarea produselor software Tic Andra Maria
1. Introducere
2. Recenzii
3. Verificri formale
3.1. Model checking
3.2. Inferena logic
3.3. Derivarea de program
3.4. Verificare prin demonstrare de teoreme
4. Concluzii
5. Bibliografie

V. Concluzii






Implementarea, testarea, verificarea i validarea produselor
software


I. Etapele de realizare ale produselor software

Lecu Radu erban

1) Introducere

Dezvoltarea unui produs software presupune etape de analiz, proiectare,
scriere, testare, debugging i mentenan a codului surs al programelor.
Dezvoltarea unui produs software poate fi folosit pentru a face referire la
programarea calculatoarelor, nsa ntr-un sens mai extins reprezint totalitatea
activitailor de realizare ale unui produs software (= programarea calculatorarelor) ideal
ntr-un proces planificat i structurat.
Scopul final este de a obine o soluie software eficient i care poate evolua n
timp. [4]

2) Etapele de realizare ale unui produs

Implementarea, testarea, verificarea i validarea produsului software sunt cele
mai importante etape de realizare ale unui produs software. Pentru nelegerea lor este
ns nevoie de cunoasterea tuturor etapelor. Dei sunt considerate etape separate, intre
ele exist o puternic relaie de interdependen.

2.1) Analiza cerinelor
Analiza cerinelor este prima etap a ciclului de realizare a unui produs n care
se stabilesc cerinele aplicaiei, pornind de la cerinele utilizatorului final, se identific
funciile viitorului produs software precum i datele implicate. Aceast etap rspunde
la ntrebarea ce se va realiza prin dezvoltarea produsului software.[17]

2.2) Proiectarea arhitecturii software
Proiectarea reprezint acea etap a ciclului de realizare a unui produs n care se
stabilete modul de realizare a cerinelor identificate n etapa de analiz, adic trebuie
s raspund la ntrebarea cum se vor realiza aceste cerine att la nivel global ct i la
nivel de detaliu. Aceast etap pornete deci de la cerinele i specificaiile definite
anterior i continu cu detalierea i transformarea acestora pn la definirea structurii
unei soluii care s fie reprezentat folosind un limbaj grafic, textual sau mixt. Proiectul
astfel obinut trebuie s poata fi utilizat mai departe la construirea sau elaborarea
produsului software (codificare, testare, integrare).[17]

2.3) Implementarea codului
Implementarea codului reprezint scrierea textului folosind formatul i sintaxa
unui limbaj de programare ales.
Codul este special conceput pentru a facilita munca unui programator, astfel
oferin posibilitatea acestuia s specifice operaiile ce vor fi realizate de ctre calculator.
Odat ce un program a fost realizat el va fi convertit n cod binar numit cod
main, care poate apoi fi citit si executat.[5]

2.4) Compilarea si interpretarea
Compilarea reprezint o metod prin care calculatorul convertete codul surs
scris ntr-un limbaj de programare (de cele mai multe ori un limbaj de nivel nalt cum ar
fi c++, Java) ntr-un limbaj de nivel jos (cod main sau assembler). n urma realizrii
acestei operaii se obine un fiier executabil ce poate fi neles i rulat de ctre maina
sau mainile pentru care a fost conceput.[6]
Interpretorul reprezint o metod prin care maina convertete codul surs n
cod main la momentul n care acesta este rulat. Interpretorul poate fi un program care
fie execut codul surs direct, fie transform codul iniial ntr-un cod intermediar, iar
acesta va fi ncrcat pentru execuie, fie interpreteaz codul care anterior a fost
compilat de ctre un compilator care face parte din sistemul de interpretare.[7]
Fiecare din cele 2 variante are avantajele si dezavantajele sale. Spre exempul un
compilator este mai rapid n momentul execuiei, nsa interpretorul folosete principiul
mainii virtuale care ofer avantajul siguranei datelor.

2.5) Documentarea
n general documentarea se refer la procesul de a oferi dovezi.
Documentarea software sau documentarea codului surs reprezint text scris
care exprim modul de implementare al programului, modul de folosire al acestuia,
informaii legate de testarea programului, modificri aduse unei noi versiuni sau orice
alte informaii legate de programul respectiv.[8]
Exist diferite tipuri de documente:
- Documente de cerine software;
- Documente de arhitectur i design;
- Documente tehnice;
- Documente ale utilizatorului.



2.6) Integrarea
Integrarea se refer la faptul c un modul poate fi integrat n interiorul unui alt
modul mai complex, sau c un modul mai complex poate fi realizat din mai multe
module simple.
Prin integrare, datele sau informaiile oferite la ieire de primul modul pot fi
folosite de ctre un al doilea modul ca valori de intrare cu condiia ca ambele module s
respecte acelasi format la ieire, respectiv intrare. [9]

2.7) Testarea software
Testarea software reprezint o investigatie dirijat n scopul de a obine informaii
legate de calitatea produsului software realizat n etapele anterioare.

2.8) Debugging
Debugging-ul reprezint o metod prin care se detecteaz i se elimina bug-urile
(erorile) unui program (sau, general vorbind, n orice component electronic), n scopul
de a-l face s funcioneze pe msura ateptrilor.
Aparent debug este echivalent cu testarea, ns prin termenul de debug se
intelege testarea, descoperirea cauzelor de eroare i rezolvarea acestor erori.
Debuggingul este puternic dependent de modul n care codul este implementat.
Principala problem este aceea c orice modificare adus codului poate s duc la
modificarea funcionalitii ntregului program.
Astfel este foarte important modul n care codul este realizat pentru a facilita
rezolvarea unor astfel de buguri. De aceea este necesar respectarea unor reguli de
scriere a liniilor de cod cum ar fi: coupling, ncapsularea datelor, cohesion. [10]

2.9) Verificarea i validarea software
Verificarea asigur c produsul e construit n concordan cu cerinele,
specifcaiile i standardele specificate. Validarea asigur c produsul va fi utilizabil pe
pia.
2.10) Mentenana
Odat lansat pe pia un produs software nu nseamn c este lipsit de erori. Mai
mult, dei produsul este funcional, pot fi aduse nbuntiri ulterioare.
Astfel dupa apariia versiunii iniiale procesele de implementare, testare, debug
pot fi continuate. [11]

2.11) Specificarea
Specificarea (spec) reprezint un set explicit de cerine ce trebuiesc satisfacute
de un material, produs, sau serviciu. Astfel putem spune c specificarea reprezint un
standard.

II. Implementarea produselor software

1) Introducere

Implementarea reprezint realizarea unei aplicaii sau execuia unui plan, unei
idei, unui model, etc.
n tiina calculatoarelor implementarea reprezint realizarea unui algoritm sub
form de program.
Exist numeroase aplicai care pot utiliza diferite standarde. Spre exemplu, la
browser-ele web este de recomandat s conin implementri ale World Wide Web
Consortium, iar sistememele de dezvoltare conin implementri ale limbajelor de
programare.
Este cunoscut faptul c prezena unuia sau a mai multor utilizatori n cadrul
tuturor etapelor de realizare a produsului este una benefic. De exemplu prezena
utilizatorului la realizarea designului sistemului, li se ofer posibilitatea s modeleze
sistemul n conformitate cu prioritile lor i li se ofer posibilitatea s adapteze produsul
final conform cerinelor lor. n plus exist o probabilitate ca s reacioneze mult mai uor
la schimbri.
Implementarea unui produs software reprezint munca n echip a unui numar
mare de dezvoltatori de programe de multe ori aflai n locaii diferite (ex: tri diferite).
Astfel este necesar folosirea unor metode de implementare 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
structura ntregului produs. [5]

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 iniial.





3) Codul surs

Codul surs reprezint reprezint textul scris folosind formatul i sintaxa unui
limbaj de programare ales.
Codul este special conceput pentru a facilita munca unui programator, astfel
oferind posibilitatea acestuia s specifice operatiile ce vor fi realizate de ctre
calculator. El poate fi vzut ca o modalitate prin care utilizatorul informeaz calculatorul
ce i cum are de fcut n scopul manipulrii anumitor date.
Odat ce un program a fost realizat el va fi convertit n cod binar numit cod
main, care 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 aplicaiilor sunt distribuite ntr-un format de tip executabil, care nu
conine 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 sau nelege cum funcioneaz.[12]

3.1) Scopul
Codul surs este n primul rnd folosit pentru a comunica unui sistem de calcul
ce are de fcut.
Un alt scop este acela ca odat realizat un cod surs ntr-o aplicaie cu o
anumit funcie, acesta s poat fi utilizat n multiple alte situaii ale aceluiai program
sau a unui alt program care care are de realizat aceiai funcie.
Aceast tehnic este folosit de ctre programatori att pentru economisirea de
timp ct i pentru nvtarea de tehnici noi de implementare a unui program.

3.2) Organizarea
Codul surs al unui program poate fi coninut de ctre un singur fiier sau de
ctre mai multe fisiere.
Dei este de dorit evitarea acestei situaii, n anumte cazuri este necesar
scrierea codului surs n limbaje de programare diferite. Spre exemplu limbajul de
programare C poate conine i linii de cod scrise n limajul assembler.

3.3) Calitatea
Calitatea unui produs software este data de modul n care acesta este
implementat i are implicaii puternice n care ulterior, un alt programator poate nelege
testa i modifica codul iniial.
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.
3.4) Licenierea
Un produs software odat realizat poate fi de 2 tipuri: free software sau
proprietary software.
Prin free software se ntelege acel software care poate fi folosit, distribuit,
modificat, sau studiat de ctre oricine fr a fi nevoie s plteasc pentru el.
n al doilea caz codul surs este inut secret, utilizatorul putnd s aib numai
posibilitatea de utilizare a lui numai pe baz de licen.

4)Calitatea produselor software

Un produs software pentru a putea fi considerat funcional este suficient s
ndeplineasc cerinele de realizare.
Un produs software pentru a putea fi considerat de calitate pe lng faptul c
este funcional el trebuie s respecte i o serie de alte cerine.
Nu exist produse software lipsite de erori. Un produs nu este finalizat odat cu
lansarea sa pe piat deoarece ulterior pot fi oricnd adugate funcionaliti noi.
Un produs software trebuie astfel conceput nct s poat fi neles, testat,
corectat i modificat cu uurin i cu riscuri ct mai mici de generare de noi erori.
Produsele software sunt caracterizate de o serie de caliti care au implicaii att
n ceea ce privete implementarea codului surs al produsului, ct i al altor operaii
cum ar fi testarea, verificarea, validarea, mentenana, debugging, integrarea.

Caracteristicile necesare pordusului software pentru a putea fi considerat de
calitate sunt:

4.1) Corectitudinea (reliability)
Prin corectitudine se exprim ct de des rezultatul dat de program este corect.
Reliability se refer la corectitudinea algoritmilor. Scopul este de a minimiza greelile de
program datorate managementului resurselor i erorilor logice. [4]

4.2) Robustee (robustness)
Prin robustee se intelege ct de bine reueste programul s anticipeze
probelemele aprute n cadrul manipulrii datelor. Acesta se refer la detecia unor
situaii 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 reea sau probleme datorate utilizatorului i intrrilor introduse
de acesta. [4]

4.3) Utilizabilitate (usability)
Utilizabilitatea se refer la uurina cu care o persoan poate folosi un anumit
program n scopul rezolvarii problemelor pentru care a fost realizat programul, sau n
anumite cazuri i a unor probleme neanticipate. Aceasta implic o gam larg de
elemente att de tip software ce in de aspectul grafic al aplicaiei i de controlul
produsului software, ct si de partea hardware a mainii de calcul pe care ruleaz
aplicaia.
Elementele de tip grafic se refer la influena aspectului grafic al programului
asupra utilizatorului, la intuitivitatea i coerena programului, iar celelalte elemente se
refer la funcionalitatea programului adic la probleme care duc la stri de asteptare
mult prea mari datorate implementrii sau chiar la blocarea programului. [4]

4.4) Portabilitate (portability)
Prin portabilitate se nelege gama de sisteme hardware i sisteme de operare pe
care se poate interpreta sau compila i rula programul. Aceasta se refer la
adaptabilitatea facilitilor oferite de program la multitudinea de sisteme hardware i
sisteme de operare. [4]

4.5) Mentenabilitate (maintainability)
Aceast proprietate se refer la uurina cu care programul poate fi modificat de
ctre programatorii prezeni i viitori cu scopul de a corecta buguri, de a face modificri,
de a reliza faciliti 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 proiectat i implementat
produsul.[4]

4.6) Eficien/ performan (efficiency/performance)
Prin aceste caracteristici se nelege cantitatea de resurse folosite de ctre
program. Cu ct sunt folosite mai puine resurse cu att eficiena este mai mare.
Aceastea includ distribuirea corect de resurse cum ar fi tergerea de fiiere temporare
sau de date stocate inutil n memorie, folosirea inutil a reelei.
O importan deosebit n acest caz o are i structura hardware. De multe ori un
program este conceput n anumite scopuri pe baza crora se alege i configureaz
sistemul de calcul pe care va funciona programul respectiv. Astfel structura acestui
sistem trebuie astfel aleas nct costurile de cumprare ale hardului s fie orientate
ctre cresterea performanei produsului software prin creterea performanelor
componentelor hardware folosite mai intens (ex: n cazul serverelor folosite intens
pentru stocarea de date s se pun mai mult accentul pe viteza de stocare a datelor
dect pe cea de procesare). Astfel componeta software este n strns legtur cu cea
hardware. [4]

Alte caracteristici:

4.7) Lizibilitatea codului sursa
Prin lizibilitatea codului surs se nelege usurina cu care scopul, fluxul de
informaie i operaiile codului surs pot fi nelese de ctre un programator. Aceasta
are implicaii asupra unor caliti menionate mai sus cum ar fi portabilitatea,
utilizabilitatea sau mentenabilitatea.


4.8) Complexitatea algoritmilor
Complexitatea algoritmilor se refer la alegerea dintr-o mulime de algoritmi care
au aceiai funcionalitate ns care pot fi mai eficieni sau nu. Eficiena se poate face pe
diferite criterii: timp, resurse folosite, dificultate de implementare.
Programatorii experimentai au sarcina de a alege cel mai eficient algoritm
corespunztor aplicaiei pe care o implementeaz.

5) Limbajul de programare

Codul surs este diferit n funcie de limbajul de programare ales. n plus putem
avea diferite limbaje de programare folosite n cadrul aceluiai proiect n funcie de
aplicaia dorit. Exist limbaje de programare procedurale i limbaje de programare
obiect-orientate. Putem folosi n cazul aplicaiilor Web limbaje de programare destinate
browser-elor (Web development): JSP, JavaScript, HTML. n cazul serverelor de multe
ori trebuie stocat o cantitate mare de informaie, caz n care vom folosi aplicaii si
limbaje de programare destinate realizrii i gestiunii unor baze de date: SQL, Oracle.
Spre exemplu, putem folosi o aplicaie care foloseste o interfa web scris n
JSP care folosete diferite clase Java i cu ajutorul creia se conecteaz la un server
ce are o baz de date realizat folosind MySQL

5.1) Compilarea si interpretarea
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 convertete 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 main sau
assembler). Sursa iniial se numete cod surs iar rezultatul cod obiect. n urma
realizrii acestei operaii se obine un fiier executabil ce poate fi neles i rulat de ctre
maina sau mainile pentru care a fost conceput.
Un program care face operaia invers poat numele de decompilator.
Comilatoarele ofer posibilitatea de dezvoltare a unor porgrame care sunt
independente de maina pe care acestea sunt rulate. n cazul programelor scrise n
assembler codul trebuia modificat dac era schimbat maina pe care era rulat
programul.
Un compilator pur este folosit numai n cazul limbajelor de tip low-level, deoarece
este mai natural i mai eficient. [6]
Interpretorul reprezint o metod prin care maina convertete codul surs n
cod main la momentul n care acesta este rulat.
Interpretorul poate fi:
- un program care execut codul surs direct
- un program care transoform codul iniial ntr-un cod intermediar, iar acesta va
fi ncrcat pentru execuie
- un program care interpreteaz codul care anterior a fost compilat de ctre 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 dect cel compilat. 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, pstrnd avantajele
oferite de interpretare.[7]

5.2) Limbaje procedurale vs limbaje obiect-orientate
Printr-o procedur se nelege o rutin, subrutin, metod sau funcie care
conine o serie de pai ce trebuiesc parcuri. Orice procedur poate fi apelat la orice
moment de timp, n timpul execuiei programului respectiv, inclusiv oferindu-se
posibilitatea ca o procedur s se autoapeleze.
Scopul programelor procedurale este de a mprii funcia acestuia ntr-o colecie
de variabile, structuri de date i subrutine.[13]
n cazul programrii obiect-orientate, se folosesc obiecte, care interacioneaz n
scopul de a realiza o anumit funcie.
Principalul avantaj al programrii obiect orientate este acela c un program este
mult mai usor de organizat. Un limbaj de programare procedural poate fi vzut ca o
clas care conine un singur obiect. n cazul programrii obiect orientate acest obiect
poate fi divizat n mai multe obiecte. Dup aceea putem introduce interefee prin care
obiectele pot interaciona.
Programarea obiect orientat ofer avantaje cum ar fi ncapsularea datelor,
motenire, polimorfism, date abstracte care duc la simplificarea codului i a
complexitii acestuia, n acelai timp introducnd avantajul securitii ridicate ale
datelor. [14]

5.3) Alte limbaje de programare folosite (limbaje de programare pentru
aplicaii web i limbaje de programare folosite pentru baze de date).
Iniial calculatoarele au fost realizate pentru a funciona independent. Ele rulau
programe simple care procesau cantiti mici de informaie. Dup apariia internetului a
fost necesar extinderea acestor limbaje pentru a oferii posibilitatea de comunicare
ntre calculatoare. Aplicaiile web i stocarea unor cantiti foarte mari de informaie stau
la baza acestei dezvoltri.
Apariia browserelor web a dus la realizarea de limbaje de programare folosite de
acestea. Au fost astfel realizate limbaje de programare cum ar fi HTML, JSP,
JavaScript, PHP.
Prin Web development se nelege procesul de realizare a unui site web. Acesta
presupune aceleai etape ca in cazul orcrui alt tip de program.
Aplicaiile web au fost destinate a fi folosite de un numr mare de utilizatori din
ntreaga lume. Astfel a fost necesar realizarea unor servere pe care s fie stocate
informaiile. Stocarea poate fi realizat folosind baze de date.
Bazele de date reprezint o modalitate prin care o cantitate mare de informaie
poate fi organizat pentru ca datele s fi stocate, citite i modificate independent. De
cele mai multe ori bazele de date ofer att posibilitate de realizare i gestionare
grafic, ct i sub form de linii de cod.


6) Reguli de scriere a unui cod de calitate

Pe lng faptul c programul trebuie bine documentat, un programator trebuie s
aib n vedere c scrierea unui program este numai una din multiplele etape de
realizare ale unui program software profesional, iar programarea unui software complex
presupune munca n echip a unui numar mare de oameni.
Cnd un program complex este realizat exist mai muli programatori care
lucreaz la acel proiect. De multe ori un program este realizat de o anumit echip de
programatori, iar la un moment dat anumii 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 nct s fie usor de inteles de ctre alte persoane. Trebuie realizat un program
cu o complexitate ct mai sczut.
Un alt lucru ce nu trebe neglijat este c odat realizat un program, sau un modul
al unui program cu o anumit fucionalitate, cu ct este mai bine organizat, cu att poate
fi mai usor integrat n cadrul altor aplicaii care necesit aceiai funcionalitate fr sau
cu un numr mic de modificri necesare.

Modelul conceptula al couplingului (wikipedia)
n plus dup etapa de implementare a codului urmeaz etape de debugging,
testare, verificare, validare, mentenant, etc. care sunt puternic dependente de modul
n care este scris codul
Termenul de coupling (cuplarea) se refer la gradul de dependena dintre 2
subsisteme, adic la modul n care fiecare modul al unui porgram se bazeaz pe modul
de funcionare al unui alt modul al aceluiai program sau al altuia i vice versa. [15]
Coupling poate fi definit ca fiind cantitatea de informaie pe care un subsistem o
are despre alt subsistem
Se disting 7 tipuri de coupling care sunt prezentate n figura de mai sus:
-Content coupling (Tight coupling) - un modul se bazeaz pe modul de
funcionare al altuli modul (ex. accesul la datele din acel modul).
- Common coupling - dou module mpart aceiai dat.
- Controll coupling - 2 module folosesc date, protocoale, sau interfa care au
acelai format.
- Stamp coupling - 2 module folosesc acelai set de flaguri (steaguri) astfel
influenndu-se unul pe cellalt.
- Data coupling - 2 module mpart aceleai date care sunt transmise de la unul la
cellalt.
- Message coupling - comunicarea dintre cele 2 module se face pe baz de
mesaje sau transmiterea de parametrii.
- No coupling - modulele nu comunic unul cu cellalt.
Micorarea gradului de coupling se poate face prin interfee. Interfaa reprezint
un contract prin care un modul cunoate numai informaiile oferite prin contract de
cellalt modul.
Coupling este n general pus n contrast cu cel de cohesion (coesiune). Dac
coupling se refer la modul n care 2 module sunt legate ntre ele, coesiunea se refer
la modul de implementare al unui singur modul.
Termenul de coesiune se refer la modul n care un modul are un scop bine
definit.[16]
Se disting 7 tipuri de coesiune:
- Coincidental cohesion (lowest) - apare cnd pri ale unui modul sunt grupate
arbitrar, singura relaie dintre ele fiind c au fost grupate.
- Logical cohesion - apare cnd pri ale unui modul sunt grupate deoarece ele
din punct devedere logic fac acelai lucru.
- Temporal cohesion - apare cnd pri ale unui modul sunt gurpate deoarece ele
sunt rulate cu aproximaie n aceiai perioad de timp.
- Procedural cohesion - apare cnd pri ale unui modul sunt gurpate deoarece
ele urmresc aceiai secven de instruciuni.
- Communicational cohesion - apare cnd pri ale unui modul sunt gurpate
deoarece folosesc aceleai date.
- Sequential cohesion - apare cnd pri ale unui modul sunt gurpate deoarece o
ieire a unei pri este intrare a altei pri.
- Functional cohesion - apare cnd pri ale unui modul sunt gurpate deoarece
ele contribuie la o singur funcie bine definit.
De ce este important s folosim coupling i cohesion?
Cei 2 termeni fac referire la complexitatea i modul n care este structurat un
program. Principiul aplicat este Divide et impera (Dezbin i cucerete). n primul rnd
prin coeziune se divid module complexe n mai multe module mai simple cu
funcionaliti bine definite. n al doilea rnd se micoreaz gradul de coupling ct mai
mult posibil astfel nct singurele dependene ntre module s fie cele necesare (ex:
cnd 1 modul este dependent de functionarea altuia putem fi nevoii s folosim stamp
coupling n loc de no coupling).

7) Documentarea codului
Fiecare etap a realizarii produsului software presupune realizarea unei
documentaii corespunztoare. Simpla implementare a codului nu este suficient
deoarece complexitatea unui program este foarte mare. Astfel att utilizatorul ct i cei
ce se ocup de etapele urmatoare au nevoie de informaii suplimentare, care s
usureze munca acetora.
O alt problem este aceea c un program presupune utilizarea mai multor
limbaje de programare. Exist programatori care nu cunosc unele limbaje folosite. Astfel
pentru inelegerea intregului program de ctre acetia pot fi folosite alte metode. O
variant este scrierea de pseudocod. Realizarea acestor documente presupune i
utilizarea unor forme grafice cum ar fi organigramele sau schite UML.



7.1) Pseudocod
Un limbaj pseudocod este o scriere intermediar, menit s simplifice scrierea
unui algorit ntr-un limbaj de programare i s ajute la realizarea claritii algoritmului n
timp scurt.
Pseudocodul poate fi vazut ca un limbaj de programare, menit nu pentru a fi
introdus pe un calculator, ci utilizat ca o forma simplificat de scriere a unui algoritm
folosit n cadrul unui program.
Pseudocodul este un limbaj apropiat de limbajul uman, astfel putnd fi utilizat de
ctre orice programator.
Sintaxa general a pseudocodului este urmtoarea:
algorithm <nume_algoritm>
<declarare_variabile> {tipul variabilelor}
<declarare_proceduri> {definirea de proceduri/functii}
begin
<procesul_de_calcul_P> {instructiunile algoritmului}
end
Elemente lexicale ale limbajului:
- Cuvinte cheie - cuvinte care au un anumit neles i se folosesc numai ntr-un
anumit context care sunt utilizate pentru a defini o anumit instruciune.
- Identificatori - nume de variabile (constante, variabile sau funcii) care sunt
folosite pentru aplelarea acestora, n timpul desfaurrii procedeului de calcul
- Expresiile - forme lexicale, asemntoare operaiilor matematice, alcatuite din
operatori i operanzi

7.2 Organigrame
n locul scrierii de pseudocod se poate opta pentru folosirea unei reprezentri
grafice a algoritmului numit organigram.
n cazul dezvoltrii unui program software, organigrama este un grafic aparinnd
unui program sau algoritm destinat a fi implementat pe o main de calcul.
Elementele principale ale unei organigrame sunt:

- blocurile de start si stop
- blocul de scriere a unei
instruciuni sau secvene de instructiuni
- bloc de decizie
- legturi intre blocuri (realizate
printr-o sgeat de legatur)




START
INSTRUCTIUNE
CONDIIE?
Da Nu
STOP
Exemplu:










7.3 UML
UML este un limbaj folosit pentru a defini un produs software din punct de vedere
al entitailor participante, al fluxului de operaii i al relaiilor dintre entitaile participante.
Un model este o abstractizare a unui sistem, ntr-un anumit context, pentru un
scop bine precizat. Un model capteaz conceptele relevante ale acelui sistem (din
punct de vedere al scopului pentru care a fost conceput), ignornd aspectele
neeseniale. In cursul etapelor de dezvoltare a aplicaiilor software (analiza, proiectare,
implementare, testare) se creeaz mai multe modele ale produsului, care capteaz
diferite aspecte ale acestuia (structura, comportarea, instalarea, distribuirea, utilizarea).
Pentru modelarea sistemelor complexe (n special a sistemelor software) au fost
concepute un numr mare de modalitai (tehnologii) i limbaje care sa sustin aceste
metodologii. Unificarea acestora s-a impus din necesitatea de a facilita schimburile de
idei si proiecte si a fost susinut de personaliti marcante din domeniul ingineriei
software (Software Engineering), iar rezultatul l-a reprezentat limbajul UML.
UML (Unified Modeling Language) este un limbaj pentru construirea,
specificarea, vizualizarea i documentarea modelelor. El a fost conceput i standardizat
pentru modelarea sistemelor software, dar poate fi folosit i n alte domenii de
proiectare (hardware, construcii etc.).
Limbajul UML definete mai multe tipuri de diagrame (modele) care pot fi folosite
pe parcursul oricrei etape (faze, iteratii) de proiectare (software sau alte domenii),
oferind mai multe vederi ale sistemului dezvoltat. In UML sunt definite semantica
(intelesul) i notaiile acestor diagrame, care pot fi folosite ntr-un mod foarte flexibil, n
funcie de necesittile particulare de dezvoltare, fr s se prevada nici o restricie
asupra modului de utilizare a diagramelor
La definirea cerinelor si la dezvoltarea unui sistem complex colaboreaza mai
multe categorii de specialiti i fiecare dintre aceste categorii sunt interesate de aspecte
diferite ale sistemului dezvoltat. Fiecare dintre categoriile de specialiti beneficiza de
cel puin o vedere a sistemul reprezentata sub form unei diagrame UML.
STOP
Nu
a>b?
Da
START
a=2
b=7
b=b-a
Cele mai importante diagrame specificate n limbajul UML sunt: diagrame ale
claselor, diagrama secvenelor, diagrama de colaborare, diagrame de stare, diagrame
de utilizare.
Diagrama claselor este partea esentiala a limbajului UML, n special in proiectele
dezvoltate n abordarea obiect orientat. Diagrame ale clasele se dezvolt atat n
etapele de analiz cat si in etapele de proiectare, cu diferite niveluri de detaliere si ele
reprezinta modelul conceptual al sistemului, care stabilete structura sistemului.
Diagramele de colaborare, diagramele secventelor si diagramele de stare
reprezinta comportarea sistemului, in diferite faze de executie. Se folosesc In principal
in proiectare si implementare.
Diagramele de cazuri de utilizare (Use Case) sunt diagrame de descriere a
comportrii sistemelor din punct de vedere al utilizatorului. Aceste diagrame sunt simplu
de neles, astfel ncat cu ele pot lucra att dezvoltatorii (proiectantii sistemelor) ct i
clienii acestora. Se folosesc n special n etapa de analiz, dar i n etapele de
proiectare i testare.
Mai exist i alte diagrame: diagrama componentelor, diagrame de instalare
(deployment), diagrama pachetelor (package).
Toate aceste diagrame se reprezint folosind elemente ale limbajului (simboluri)
care sunt figuri geometrice simple (linii, dreptunghiuri, ovale). Exista unele simboluri
care se pot folosi n orice tip de diagram (de exemplu simbolurile de documentare), iar
alte simboluri sunt specifice diagramei n care se folosesc. Mai mult, unele simboluri (de
exemplu o linie cu sageata la capat) poate avea diferite semnificaii, n funcie de
diagrama n care se folosesc.
Exist posibilitatea de a genera cod pe baza unui proiect UML, pentru diferite
limbaje de programare: c#, java, folosind unelte de generare de cod. Astfel se poate
accelera faza de implementare de cod, oferind avantajul eliminrii erorilor de scriere a
codului.
Exemple:
- Diagrama de context static

medic administrator
Evidenta cosultatii
medicale
- Diagram de secvent:
sd Vizualizare medici
Persoana Sistem Baza de date
1: Alegere vizualizare medici
2: Verificare drepturi de vizualizare
3: Cerere lista medici
4: returneaza lista medici


- Diagram de activitate:
Vizualizare medici
Trimite cerere Mesaj eroare
Are drept de vizualizare?
Cerere vizualizare medici
Vizualizare lista medici
Da Nu









- Diagram a claselor:


8) Concluzii
Implementarea unui produs software este o etap dificil prin faptul c n cadrul
programelor complexe poate fi realizat numai de ctre un grup de oameni. Astfel se
pune accentul pe lucrul n echip.
Implementarea unui produs software reprezint etapa de scriere efectiv a
codului. Codul reprezint att un limbaj de comunicare ntre programator i calculator
ct i unul folosit ntre mai muli programatori. Astfel codul trebuie astfel realizat i
organizat nct s poat fi ineles i modificat sau utilizat de ctre un alt programator
care ulterior va citi codul.
Exist un numr mare de limbaje de programare. Alegerea limbajului de
programare folosit este dependent de caracteristicile programului. Dei este de
preferat s fie folosit un singur limbaj de programare n cadrul realizrii unui produs de
cele mai multe ori este imposibil deoarece funciile necesare produsului nu pot fi
acoperite de ctre un singur limbaj de programare.
Calitatea codului este esenial. 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 fr a duce la generarea de erori noi. n plus complexitatea este
redus fiind mult mai uor de neles, modificat iar erorile sunt mai usor de detectat. n
al treilea rnd modificarea codului pentru realizarea de noi versiuni este mult mai
usoar, fr a fi necessare modificri majore ale vresiunii curente.
Pentru a simplifica munca celor ce preiau programul n cadrul urmtoarelor
etape, documentarea are un rol important. Aceasta presupune cunoasterea si utilizarea
diferitelor moduri de reprezentare a liniilor de cod, pseudocod, organigrame, UML.

III. Testarea produselor software

1) Introducere

Testarea software reprezint o investigaie dirijat n scopul de a obine informaii
legate de calitatea produsului software realizat n etapele anterioare. Testarea
reprezint rularea programului n scopul de a descoperi bug-uri software.
Testarea este o etap puternic dependent de contextul operaional n care
programul va fi folosit. Testarea produselor software reprezint o etap important n
dezvoltarea produsului software deoarece, 40-50 % din eforturi sunt directionate n
aceast direce, mai ales pentru produsele software care necesit un grad mare de
siguran.
O analogie interesant este similaritatea dintre testarea software i pesticide,
care poart numele de Pesticide Paradox. Orice metod este folosit pentru gsirea si
eliminarea gndacilor va lsa n urm anumite categorii de gndaci care sunt imuni la
acea metod. Astfel orice metod este folosit pentru detecia si corecia erorilor nu
duce la dispariia n totalitate a tuturor erorilor. Din acest motiv defectele software sunt
denumite bugs iar testarea i rezolvarea acestor defecte poat numele de debugging.
Complexitatea i varietatea erorilor este att de mare nct este imposibil minii umane
s rezolve toate aceste erori. Eliminarea erorilor este atat de dificil nct n timpul
necesar pentru eliminarea tuturor acestora apar noi erori.
n urma testrii se poate, sau nu, confirma faptul ca produsul software supus
testrii corespunde cerinelor care au dus la crearea acestui produs i ca functioneaz
corespunztor asteptrilor.
Este evident c dei testarea reprezint o etap separat. Ea este puternic
dependent de etapa de dezvoltare i are la baz metodele de dezvoltare ale
produlsului software.
Un produs software este diferit de orice alt sistem fizic cu intrri i ieiri. Un
produs software nu sufer defecte datorate trecerii timpului (ex: coroziunea n cazul
unor componente electrice ale unui circuit). Singurele tipuri de defecte pe care le poate
suferii un produs software sunt date de proiectare i implementre. Un produs software
odat realizat, nu va mai suferi modificri dect n urma realizrii unei noi versiuni a
acelui program. Astfel, dac un produs este declarat funcional momentul n care are loc
finalizarea testrii el va fi funcional la orice alt moment de timp ulterior.
Principala cauz a erorilor unui produs software este dat de complexitatea
acestuia. Oamenii au o capacitate limitat de procesare n cazul unei complexiti
ridicate. Din acest motiv defectele de proiectare sunt inevitabile. De aceea este
imposibil de conceput un produs software care sa nu conin erori i nu exist nici o
modalitate de testare a produsului software care s elimine sau cel puin s detecteze
toate aceste defecte.
Exist situaii cnd rezolvarea unei erori s duca la apariia unora noi. Astfel,
dac este detectat o anumit eroare n faza de testare, se poate ncerca remedierea
ei. Este totui posibil ca acea remediere s nu duc la rezolvarea erorii, sau chiar s
duc la apariia unora noi. Dup realizarea coreciei trebuie reluat faza de testare
pentru a avea sigurana c modificarea realizat a dus la rezolvarea problemei fr
introducerea unora noi. Este important de neles c orice modificare adus unui
program software trebuie nsoit de un set de teste care s asigure funcionalitatea noii
versiuni nainte de a fi dat utilizatorilor. Cea mai mic modificare poate duce chiar la
schimbarea total a modului de funcionare a produsului software.
O alt situaie este n cazul n care eroarea apare pentru un numr foarte
restrns de valori de intrare. Acesta poate fi un lucru favorabil dac eroarea este
neglijabil (ex: dei nu se obine rezultatul dorit pentru acel domeniu de valori, apariia
acestor erori nu duce la pierderi seminificative). n acelai timp, poate fi i un lucru
nefavorabil deoarece aceast eroare este greu de detectat i e posibil s nu fie
detectat n faza de testare. Dei probabilitatea de apariie a acestei erori este mic, n
anumite situaii efectele aprute n urma acestei erori pot fi devastatoare (ex: costuri
mari, pierderi de viei umane).
Testarea nu poate oferii o garanie de 100% c produsul funcioneaz corect n
orice condiii ci numai n acele condiii pentru care a fost testat. Astfel alegerea
intrrilor folosite este esenial pentru acoperirea unei game ct mai largi de posibile
erori.
Informaia obinut n urma testrii este esenial pentru remedierea defectului
respectiv. n momentul n care se detecteaz o eroare, este posibil s nu se cunoasc
i cauza care a generat acea eroare. Programatorul trebuie ca dup detecia erorii s
identifice pe baza acesteia instruciunea sau secvena de instruciuni care a dus la
apariia erori.
n unele situaii erorile pot s apar, nu din cauz de cod greit, ci datorat unor
lacune, neclariti la nivel de cerine sau cerine incomplete. Acestea pot duce la erori
care apar nc din faza de proiectare de ctre designerul programului. Acestea poart
numele de cerinte non-funcionale.
O alt cauz important care poate duce la apariia unei erori este aceea de
compatibilitate, ce poate fi cauzat att de inteaciunea lor cu alte aplicaii, cu diferite
sisteme de operare sau prin rularea acestora pe sisteme hardware diferite, ct i din
cauza nonconformrilor ce apar de la o versiune la alta ntr-un proces incremental de
dezvoltare al produsului.
Dac de exemplu produsul software a fost testat numai pe un singur sistem de
operare se poate oferii sigurana n urma testtii produsului ca acesta funcioneaz
corect numai pentru acest sistem de operare. Similare este i n cazul testarii produsului
software pe o singur arhitectur hardware.
De la o versiune la alta a unui singur program, dei versiunea nou nu are erori
de funcionare, aceasta a suferit modificri care au dus la incompatibilitatea cu alte
programe cu care versiunea anterioar putea interaciona fr probleme. Foarte
posibil este i apariia incompatibilitii dintre 2 subdiviziuni ale aceluiai program.

2) Scopul testrii

Ideal scopul testrii este de a detecta i elimina toate erorile dintr-un program.
Acest lucru este inposibil.
n realitate, scopul principal este detecia erorilor, corecia celor care pot fi
eliminate, minimizarea acelora care nu pot fi eliminate (rezolvarea parial a erorii, sau
remedierea acelei erori dei se tie c vor aprea erori noi dar care pot fi ignorate) sau
ignorarea ei n cazul n care eroarea nu poate fi eliminat sau costul remedierii erorii
este mai mare dect costul datorat ei.
De asemenea scopul testrii este acela de a oferi utilizatorului sigurana c
produsul este conform cerinelor.
n general scopurile testrii performanelor produsului software sunt:
- cerceterea calitii produsului software
- testarea si validarea acestuia.
Deoarece produsele software sunt folosite n aplicaii critice, urmarile unui bug
pot si dezastroase. ntr-o lume n care aproape orice produs are i o component
software testarea produselor software n scopul creterii calitii lor este esenial.
innd cont i de imperfeciunea naturii umane, a fost necesar realizarea de tehnici,
algoritmi i unelte pentru testarea produselor software.

3) Realizarea unui test software

Pentru testarea unui produs trebuie realizat o secven de activitate de testare.

1) Identificarea
obiectivelor
3) Calcului ieiriii
estimate
2) Selectarea
intrrii
4) Pregtrirea mediului de execuie
5) Executarea programului
Mediu de execuie

Program
6) Analiza rezultatului
testrii
7) Verdict asociat
testului

4) Automatizarea testrii

Scopul testrii automate este de a minimiza cantitatea de munc manual n
executara testului i acoperirea unei game mai mari de valori pentru a face testul prin
aplicarea unui numr mai mare de teste. Testara automat are un impact major asupra
metodelor de testare concepute i al uneltelor folosite pentru testare. Prin testarea
automat se detecteaz blocrile programelor i operaiile curente oferind informaii de
diagnosticare.
Un model de testare poate fi reprezentat astfel:

Un tester poate s identifice componentele unui program cum ar fi GUI (Graphic
user interface) i poate deasemenea realiza anumite funcionaliti cum ar fi calcule
aritmetice, concatenri de stringuri, sau integrri de baze de date.
Sistemul supus testului (SUT) joac un rol important n arhitecura uneltelor de
test. Sistemul de test necesit introducerea de valori de intrare care pot fi alese numai
n urma cunoaterii modului de funcionare al SUT-ului.
n cazul testrii manuale utilizatorul aplic valori la intrare. La iesirea SUT-ului
vom avea valori de ieire care sunt comparate cu valorile dorite.
Un SUT poate fi reprezentat astfel:
Sistemul
supus testului
(SUT)
Intrrile testului
Precondiiile dateor
Precondiiile strii
programului

Intrri ale mediului
Rezultatele testrii
Postcondiiile datelor
Postcondiiile strii
programului


Intrrile sistemului
Motorul de
funcionare
Remote GUI GUI
Set de
date
SUT
GUI

User
GUI

User
GUI

API
GUI


Pornind de la aceast structur putem proiecta un sistem de testare astfel nct
utilizatorul este inlocuit de unealta de testare. Acesta introduce valorile de intrare pentru
fiecare intrare de test definit i preia valorile de ieire corespunztoare. Prin
compararea valorilor de ieire obinute de la SUT cu cele dorite se obin rezultatele
testrii.[18]

Bibliografie
- [1]Head First Software Development - Dan Pilone & Russ Miles- editura
OREILLY
- [2]Software Development and Professional Practice
- [3]SCJP (Sun Certified Programmer for Java 6) - Kathy Sierra & Bert Bates
editura Mc Graw Hill
- [4]http://en.wikipedia.org/wiki/Computer_programming
- [5] http://en.wikipedia.org/wiki/Implementation
- [6] http://en.wikipedia.org/wiki/Compiler
- [7] http://en.wikipedia.org/wiki/Interpreter_(computing)
- [8] http://en.wikipedia.org/wiki/Documentation
- [9] http://en.wikipedia.org/wiki/Digital_integration
- [10] http://en.wikipedia.org/wiki/Debugging
- [11] http://en.wikipedia.org/wiki/Software_maintenance
- [12] http://en.wikipedia.org/wiki/Source_code
- [13] http://en.wikipedia.org/wiki/Procedural_language
-[14] http://en.wikipedia.org/wiki/Object-oriented_programming
-[15] http://en.wikipedia.org/wiki/Coupling_(computer_programming)
- [16] http://en.wikipedia.org/wiki/Cohesion_(computer_science)
- [17] http://www.progapl.ase.ro/ps-id/Cap%205-
1_4%20Metode%20de%20proiectare%20clasice.pdf
- [18]
http://www.testingeducation.org/course_notes/hoffman_doug/test_automation/auto8.pdf
-[19] http://education.yahoo.com/reference/encyclopedia/entry/computer-prog
- [20] http://searchsoa.techtarget.com/definition/source-code
- [21] http://c2.com/cgi/wiki?WhatIsSoftwareDesign
- [22] http://www.inventoryops.com/software_selection.htm
-[23]
http://www.shiva.pub.ro/PDF/TEST/Testarea%20software%20si%20asigurarea%20calit
atii%20-%20curs2.pdf
- [24] http://www.chillarege.com/authwork/TestingBestPractice.pdf
- [25]
http://www.comp.lancs.ac.uk/computing/resources/IanS/SE7/Presentations/PDF/ch23.p
df


Mihai Vidracu

5. Tipuri de teste software

5.1. Testarea prin metoda cutiei negre (black box)

Aceasta metod testeaz funcionalitatea aplicaiei, nu abordeaz deloc codul i
procesele interne ale aplicaiei. Tester-ul nu trebuie s tie decat ceea ce trebuie s
faca programul, nu i cum face. Se urmrete funcia de transfer a programului: se
dau date de intrare i se verific datele de ieire, fr a se tii cum se face prelucrarea
lor. Cazuri de testare se construiesc n jurul cerinelor i specificaiilor. Aceste teste pot
fi funcionale (cele mai multe) sau nefuncionale. Aceasta metod se poate aplica la
toate nivelele de testare: de unitate, de integrare, de sistem i de acceptare. [8]
Deci se testeaz:
- Funcionalitatea
- Validarea datelor de intrare (s nu se accepte date de intrare neconsistente,
ca-1 la data naterii)
- Datele de ieire
- Trecerea dintr-o stare n alta a sistemului (de exemplu la programul de
instalare, componentele unei aplicaii se instaleaz intr-o anumita ordine, sau la
realizarea unei conexiuni).[3]

5.2. Testarea white-box

Testarea prin metoda cutiei albe (sau cutiei de sticl/transparenta), sau testarea
structural este o tehnic de testare care verific structura intern i modul de
prelucrare a datelor (n opozitie cu testarea black-box descrisa mai sus). Pentru a
efectua o astfel de testare, evaluatorul trebuie s tie cum a fost fcut programul i s
aiba experienta n programare. Testerii introduc elemente de testare n cod care i ajuta
s determine dac instruciunile s-au executat corect pnn punctele introduse. Este
similar cu testarea unui circuit electronic n care se masoara din loc n loc parametrii
pentru a evalua funcionarea corecta.
Se poate aplica la nivelul de unitate, de integrare i de sistem, dar cel mai des se
folosete la nivelul unitii. Dei astfel se descopera multe erori i probleme, nu se
detecteaz partile neimplementate sau specificaii i cerine lipsa.[8], [5]
n categoria cutiei albe sunt incluse:
- Testarea fluxului de control
- Testarea cailor pe care le poate lua programul
- Testarea cii de date
- Testarea tratrii corecte a erorilor [3]
5.3. Testarea gray-box

Testarea prin metod cutia cutiei gri presupune ca testerul s cunoasc algoritmii
i structurile de date din interiorul programului, dar s testeze ca un utilizator (ca la
black-box). Nu are nevoie de acces la codurile sursa. Manipularea datelor de intrare i
de ieire nu se calific n testarea gray-box, intruct acestea se afla inafar sistemului
(cutiei), insa modificarea structurii de date se incadreaza n aceasta categorie, pentru
c, n mod normal, un utilizator nu ar putea schimba datele dinafara sistemului.
Testarea gray-box poate include i ingineria inversa pentru a determina, de pild,
valorile maxime i mesajele de eroare.
Cunoscand conceptele din spatele produsului software, un tester poate face
alegeri mai bune i n cunostinta de cauza n ceea ce priveste tipurile de teste care
trebuie efectuate. n general, unui astfel de tester i se permite pregtirea unui mediu de
test propriu (de exemplu, sa adauge propriile date intr-o baza de date i apoi s creeze
propriile scripturi SQL pentru a vedea rspunsurile).
n concluzie, testarea grey-box implementeaz teste inteligente, bazate pe
cantiti limitate de informaie.[8], [3]


5.4. Testarea funcional

Testarea funcional se aplic pentru a verific dac un produs software se
comporta i funcioneaz corect, conform specificaiile din proiect. O specificare
funcional este o descriere a comportamentului asteptat de la program. Indiferent de
ce form o ia, formal sau informal, specificarea funcional este cea mai important
sursa de informaii pentru proiectarea testelor. Crearea de cazuri de testare din
specificarile de program se numete testare funcional.
Testarea funcional, sau, mai precis, proiectarea funcional de cazuri de
testare, incearca s raspunda intrebarii: Face programul ceea ce trebuie ? ,
considernd numai specificaiile programului, nu i designul lui sau structurea de
implementare. Fiind bazat pe specificaiile de program i nu pe cod, testarea
funcional se mai numete i testare black-box (metod cutiei negre). Testarea
funcional este n general tehnica de baza pentru proiectarea de cazuri de testare.
Proiectarea de teste poate incepe ca parte a procesului de specificare a cerinelor i
poate continua prin fiecare nivel de proiectare i de interfata a specificaiilor; este
singura metod de testare care se poate aplic atat de devreme i atat de larg. n plus,
testarea funcional este eficient n detectarea unor clase de defecte care de obicei
trec de testarea white-box (sau glass box) sau de testarea bazat pe defecte (detaliate
n capitolele urmatoare).
Tehnicile de testare funcional se pot aplic pentru orice descriere a
comportamentului programului, de la descrierea informal parial pn la descrierea
formal, i la orice nivel de granularitare, de la un singur modul la ntregul sistem. De
asemenea, proiectarea testelor n acest mod este mai ieftin i mai usor de executat de
cat n cazut testrii white-box.
n testarea i analiza aplicate n scopul verificrii (adic a descoperirii oricaror
discrepante intre ceea ce face un program i ceea ce ar trebui s faca), trebuie fcuta
referire la cerine, exprimate de de utilizatori, i specificate de inginerii software. O
specificare funcional (adic o descriere a comportamentului esteptat al
programului)este sursa primar de intormatii pentru czurile de test. Testarea
funcional, cunoscuta i ca testare black-box (sau testare bazat pe specificaii)
implic tehnici care creaza cazuri pentru testare derivate din specificaiile funcionale. n
general, aceste tehnici produc specificaii pentru czurile de test care identifica anumite
clase de teste, i care sunt instantiate pentru a produce teste individuale.
Principiul care st la baza proiectrii cazurilor de test este partitionarea
posibilelor comportamente ale programului intr-un numar finit de clase omogene, unde
fiecare clasa poate fi considerata corecta sau incorecta. Practic, proiectantul de cazuri
de test trebuie s formlizeze specificaiile suficient de mult, astfel incat acestea s
poata servi ca baza de identificare a claselor de comportamente. Un avantaj al
proiectrii de teste este acela ca scoate n evidenta slabiciunile i inconsistenta
specificaiilor.
Crearea de cazuri de teste funcionale este un proces analitic care descompune
specificaiile n cazuri. Multitidinea de aspecte care trebuie luate n considerare n timpul
testrii funcionae face ca procesul s fie predispus la erori. Chiar i proiectantii cu
experienta pot omite cazuri importante de testare. O metodologie pentru proiectarea
testelor funcionale ajuta la descompunerea design-ului de testare n pasi elementari.
Astfel se poate controla complexitaea procesului i se pot separa activitatile umane de
cele care pot fi automatizate.
Uneori, testarea funcional poate fi complet automata. Este posibil atunci cand
specificaiile sunt date sub form unui model forml (de exemplu, la un procesor de text,
regulile gramaticale, sau starile n cazul unui automat). n aceste cazuri exceptionale,
etapa de lucru efectiv are loc n simpul specificarii i proiectrii software-ului. Treaba
proiectantului de teste se limiteaza la alegerea criteriilor de test, care definesc strategia
de generare a specificaiilor cazurilor de test. n majoritatea cazurilor insa, testarea
funcional este o activitate intensicv umana. Designer-ii trebuie s porneasca de la
specificaiile informle scrise n limbaj natural i s le structureze astfel incat s
identifice cazurile de test.[4], [1]

5.5. Testarea nefuncional
Testarea nefuncional consta n testarea cerinelor nefuncionale alea
produsului software. Se mai numete i testare structural. O cerinta nefuncional este
un tip de cerinta care specifica criteriul ce poate fi folosit pentru a evalua operarea unui
sistem, n locul unor comportamente specifice (cerinele funcionale definesc funcii i
comportamente bine definite). Planul pentru implementarea cerinelor nefuncionale
este detaliat n arhitectura sistemului. Cerinele nefuncionale sunt adesea numite
calitati ale sistemului. Alti termeni care definesc acelasi lucru: constrangeri, atribute ale
calitatii, scopuri ale calitati, cerine ne-comportamentale.
Cerinele nefuncionale se impart n dou categorii:
Calitate n executie, ca securitatea i usurinta n utilizare, care se poate observa
n timpul rularii
Calitati de evolutie, ca testabilitate, mentenabilitate, extensibilitate i scalabilitate,
care sunt incluse n structura statica a produsului software.

Revenind la testarea nefuncional, aceasta include: testarea de compatibilitate,
testarea de conformitate, de anduran, de incarcare, de localizare, de performan, de
recuperare, de securitate, de scalabilitate, de stres, de utilizabilitate i testare de volum.
[8]
n continuare le vom detalia pe fiecare, prezentand caracteristicile fiecarui tip de
testare.

5.5.1. Testarea de compatibilitate
Acest tip de testare se aplic pentru a evalua compatibilitatea aplicaiei cu
sistemul de calcul. Testarea unei aplicaii pentru compatibilitate poate deveni o sarcina
foarte complicata. Exista multe sisteme de operare diferite, configuratii hardware i
software, deci se ajunge la un numar imens de combinatii. Nu exista o cale ocolitoare
pentru problema testrii compatibilitatii: aplicaia fie ruleaza cum a fost proiectata pe un
anumit sistem de calcul, fie nu ruleaza deloc. Un mediu potrivit pentru acest tip de
testare poate totusi usura acest proces i il poate face mai eficient.
Clientul care cere dezvoltarea unei aplicaii ar trebui s menioneze toate
sistemele de operare-tinta posibile pentru utilizatorul final (inclusiv sistemele de operare
pentru servere, dac este cazul) pa care aplicaia trebuie s ruleze. Exista i alte
cerine de compatibilitate care trebuie specificate: de exemplu, produsul de testat
trebuie s ruleze cu mai multe versiuni de browsere web, cu dispozitive ca imprimante
de toate felurile, sau cu alte componente software, ca programe de scanare antivirus
sau procesoare de text.
Compatibilitatea se poate extinde i asupra actualizarilor de la versiuni mai vechi
de software. Nu numai sistemul trebuie s poata fi actualizat corect de la o versiune mai
veche, trebuie luate n considerare i datele i alte informaii folosite n versiunile
precedente (ca preferinte de setari. etc). Uneori, aplicaia mai trebuie s fie compatibila
i n sens invers, adic datele prelucrate i salvate de versiunile anterioare trebuie s
poata fi accesate de versiunea noua i invers (datele noi trebuie s poata fi deschise pe
statii de calcul care au versiunea veche a aplicaiei). Acestea sunt situatii care trebuie
luate n calcul cand se pune problema compatibilitatii.
Data fiind diversitatea configuratiilor i potentialele probleme de compatibilitate,
este probabil imposibil de testat fiecare permutare. Tester-ii trebuie s ierarhizeze
configuratiile posibile n ordine, de la cele mai comune configuratii pnla cele mai rar
intalnite (de exemplu, dac majoritate utilizatorilor folosesc Windows 7 i browser-ul
Mozilla Firefox, aceasta configuratie ar trebui s fie prima n lista, punandu-se accent pe
aceasta). Pentru alte configuratii mai rare, se pot impune limite de timp i cost i se pot
face teste mai putn dure.
Pe langa selectarea celor mai importante configuratii, tester-ii trebuie s
identifice i cele mai potrivite cazuri de test i de date pentru aceasta testare. De obicei
nu este fezabila rularea ntregului set de cazuri de test pe fiecare configuratie de test
posibila (decat dac aplicaia este una mica), altfel ar dura prea mult timp. Deci, trebui
selectat cel mai reprezentativ set de cazuri , care s confirme ca aplicaia funcioneaz
corect pe o anumita platform.Pe langa acestea, tester-ii au nevoie i de date adecvate
pentru testare, care s suporte acel set de cazuri de test.
Este important actualizarea continua a cazurilor de test de compatibilitate i
datele pe masura ce sunt descoperite probleme n aplicaie, nu numai n timpul
dezvoltarii ei, ci i dupa livrare. Datele colectate de la utilizatori n cazul defectarii sunt o
sursa buna de informaii pentru crearea i adaugarea de noi teste n suita de testare.
Aceste date sunt utile i pentru determinarea celor mai potrivite configuratii pentru cre
s se faca teste de compatibilitate (se poate ajunge la refacerea ierarhiei de configuratii
folosita la testare). O alta sursa de informaii este programul lansat pentru beta-testing.
Pentru a testa aplicaia ca la carte, trebuie re-creat mediul n care ea va opera la
utilizatorul final. Pentru a indeplini aceste conditii, se instaleaz sistemul de operare,
hardware-ul i configuratia software, i abia atunci se executa testele pe diferite set-up-
uri. Cum pot exista nenumarate combinatii de setari, este cam scumpa achizitionarea
masinilor pe care le-ar putea avea utilizatorii. De asemenea, reinstalarea aplicaiei pe
fiecare ar dura prea mult pentru a fi o optiune viabila.
O abordare mai fezabila implic utilizarea de hard-disk-uri care se pot demonta
usor, n combinatie cu o unealta de gestiune a partitiilor. Astfel, pe un numar mic de
masini, se poate testa un numar mai mare de configuratii. Tester-ul doar plaseaza
discul care trebuie. Restarteaza masina i selecteaza configuratia dorita.
Alta solutie este aceea de a folosi programe care creaza imagini diferite pentru
hard-disk (ca Symantec GHOST). Astfel se creaza fisiere imagine pentru configuratiile
necesare, care pot fi folosite oentru a recrea configuratia pe alta masina (sau chiar pe
aceeasi) mai tarziu. Singurul dezavantaj este acela ca dureaza destul de mult timp
refacerea configuratiilor pe masina tinta folosind fisierele imagine (depinde de
dimensiune). n plus, i fisierele imagine sunt mari ca dimensiune, deci trebuie gasita o
cale usoara (si compatibila pentru fiecare computer) de transport de pe o masina pe
alta.
Indiferent de tehnic folosita pentru a gestiona partitiile, odata ce s-a setat mediul
necesar, testele pot fi rulate i se poate evalua compatibilitatea pe platform respectiva.
Este important i modul de instalare al aplicaiei pe configuratia setat anterior.
Este critica respectarea modului de instalare pe care il va folosi utilizatorul, folosind
aceleasi versiuni de componente i aceleasi proceduri de instalare. Aceasta
constrangere se respecta cel mai bine atunci cand un program de instalare este pus la
dispozitie devreme n fluxul de proiectare, i software-ul este predat echipei de testare
sub form instalabila, n loc de un pachet specializat. Dac o metod specializata sau
manuala este folosita la instalare, este posibil ca mediul de test s nu reflecte mediul
utilizatorului, i rezultatele testului de compatibilitate s fie imprecise.
Este important s nu existe unelte de dezvoltare pe platform de test, pentru c
ele pot interfera i mediu nu va mai fi atat de similar cu conditiile reale de
operare.[7],[4],[5]

5.5.2. Testarea de anduran (soak testing)
Acest tip de test se folosete pentru a determina dac o aplicaie face fata
incarcarii de procesare siipastreaza comportamentul corect o perioada lunga de timp.
n timpul testrii de anduran, se monitorizeaza atent consumul de resurse, mai ales
memoria, pentru a observa potentialele defecte. De exemplu, un program poate
funciona corect cand se testeaz 1 ora. Dar peste o zi, apar probleme, ca pierderi de
memorie, care schimba comportamentul n mod nedorit.
n timpul acestor teste se monitorizeaza i performan produsului. Observatiile
inregistrate n timpul soak-testing-ului se folosesc pentru a imbunatatii parametrii
elementului testat. De multe ori se urmrete ca parametrii s nu coboare sub un
anumit nivel dupa funcionarea prelungita.
Un sistem complet integrat trebuie s fie funcional continuu, saptamani (sau
chiar luni) ntregi fr a se bloca/intrerupe.[9]


5.5.3. Testarea de incarcare (load testing)
Testarea la sarcina consta n incarcarea aplicaiei cu cerine i masurarea
rspunsului i parametrilor ei. Se aplic pentru a determina comportamentul unui sistem
sub conditii normale de funcionare i n cazuri de supra-sarcina. Astfel se poate afla
care este capacitatea maxima de operare a aplicaiei, dar i unde se afla punctele slabe
(bottle-necks) care cauzeaza degradarea performntei. Uneori sarcina este pusa
intentionat mult peste capacitatiile aplicaiei pentru a se observa tipul de erori care pot
aparea i pentru a se crea solutii pentru ele (metode de scadere a incarcarii sau macar
de semnalare a limitarii).
n multe cazuri, n software, incarcarea inseamna acces concurent al mai multor
utilizatori. Situatia n care relevanta acestui test este maxima se intalneste la aplicaiile
multi-user, de tip client-server.
Exista i alte tipuri de software care pot fi testate prin incarcare. De exemplu, un
procesor de text sau un editor grafic pot fi fortate s citeasca un document extrem de
mare, sau un program din domeniul bancar, caruia i se poate cere s genereze un
raport folosind date distribuite pe mai multi ani. Cel mai precis test de sarcina este cel
care simuleaza lucrul n conditii normale (la capatul opus se afla testele folosind
modelarea teoretica sau analitica).
Pentru un website, testarea de incarcare poate ajuta la determinarea calitatii
serviciilor (QoS performnce) folosind comportamentul asteptat al clientului. Aproape
toate uneltele de testare prin incarcare urmaresc principiul clasic de testare. Cand
clientul viziteaza site-ul, un programel inregistreaza comunicarea i apoi creaza script-
urile de interactiune asociate. Apoi, un generator de sarcina incearca s redea
scripturile inregistrare, care pot fi modificate inainte de rulare, pentru a avea diferiti
parametrii i a simula mai multi clienti. La re-rularea procedurii, se monitorizeaza i se
colecteaza statistici hardware i software. Acestea includ starile procesorului, ale
memoriei, operatiile de intrare-ieire ale discului pentru servere, timpul de rspuns,
transferul sistemului de testat etc. La final, aceste statistici se vor analiza i se
intocmeste un raport de testare la incarcare.
Testele de sarcina analizeaza foarte precis aplicaiile care au fost proiectate
pentru mai multi utilizatori, prin incarcarea lor cu un numar divers de utilizatori virtuali i
reali i masurarea performntelor n acest conditii. Aceste teste se fac de obicei n medii
identice (sau cat mai apropiate) cu cele reale.
Exemplu: un site de tip magazin virtual. Se evalueaza funcionarea componentei
care se ocupa de cosul de cumparaturi. De pild, trebuie s suporte 100 de accese
concurente, de tipuri diferite: 25 de utilizatori virtuali (UV) se logheaza, se uita prin
catalog i apoi se de-logheaza. Alti 25 se locheaza, adauga produse n cos, le cumpara
i apoi pleaca. Inca 25 se locheaza, returneaza produsele cumparate anterior i pleaca,
i inca 25 se logheaza pentru prima data (nu au alte activitati anterioare).
Specificul unui plan de test sau script variaza n funcie de organizare. Pentur
exemplul de mai sus primii 25 de utilizatori virtuali ar putea cauta produse unice, sau
aleatoare, sau pot selecta dintr-un anumit set; depinde de planul de test dezvoltat
anterior. Oricum ar fi, toate testele de incarcare vor s simuleze performntele pe o
gama cat mai mare de varfuri de lucru.
O credinta gresita este aceea ca uneltele de testare ofera doar inregistrare i
redare (ca uneltele de testare prin regresie). De fapt, ele analizeaza intreaga stiva OSI
(uneltele de testare prin regresie se axeaza pe performan interferei grafice). De
exemplu, o unealta de regresie inregistreaza i reda un click pe un buton intr-un
browser, dar o unealta de testare prin incarcare trimite hipertext-ul (html) pe care
browser-ul il emite dupa ce utilizatorul apasa acel buton. Intr-un mediu multi-user,
uneltele de incarcare pot trimite comenzi pentru mai multi utiizatori, ficare cu ID, parola,
setari diferite.

Experienta utilizatorului la testul de incarcare

n exemplul de mai sus, 100 de utilizatori virtuali lucrau cu aplicaia de magazn
virtual. Performan se masoara aici din punctul de vedere al utilizatorului. Aceasta
descrevalueazaie cat de repede raspunde produsul software i cat de satisfcut este
user-ul (cum percepe el performan).

Unelte de testare prin incarcare

- AppLoader: solutie de testare de performnte i de incarcare. Se testeaz la
nivel de interfata grafica. Poate fi folosit i pentru testarea de unitate, de integrare i de
regresie.
- IBM Rational Performnce Tester: unealta de testare de scara larga, pe baza
ed Eclipse. Se folosete n principal pentru executia unui numar foarte mare de teste
pentru a masura timpul de rspuns al aplicaiilor pentru servere.
- Apache Jmeter: aplicaie desktop Java pentru testarea de incarcare i
masurarea performntelor.
- LoadTest: verific funcionalitatea i performan sub sarcina.
- LoadRunner: utilizata pentru executarea unui volum mare de teste concurente
- OpenSTA (Open System Testing Arhitecture): aplicaie de test prin incarcare,
open source.
- SilkPerformer: testare de performnte intr-un model deschis i partajabil, care
simuleaza un teste realistice de incarcare pentru mii de utilizatori, care ruleaza scenarii
de afaceri.
- SLAMD: open source, aplicaie web Java
- Visual Studio Load Test: unealta inclusa n Visual Studio, care permite
dezvoltatorilor s rulese un numar mare de teste cu o combinatie de configuratii care
simuleaza incarcarea reala de la utilizator.

Testare de incarcare se poate face n 2 feluri:
- testare de longevitate (sau de anduran, descrisa mai sus), care evalueaza
abilitatea sistemului de a suporta o sarcina moderata, costanta, timp indelungat.
- Testarea de volum, care supune aplicaia la sarcina maxima o perioada limitata
de timp.[8]

Testarea de sarcina difera de testarea prin stres (care evalueaza modul n care
produsul lucreaza sub sarcina extrema, peste cea maxima, specificata).[11]

5.5.4. Testarea de localizare
Testarea de localizare este axata pe aspectele de interntionalizarea i de
localizarea ale produsului software. Localizarea este procesul de adaptare a unei
aplicaii globalizate pentru o anumita cultura. Pentru a localiza o aplicaie este nevoie de
o intelegere de baza a seturilor de caractere i a problemelor asociate lor. Localizarea
include i traducerea interfetei cu utilizatorul i adaptarea graficii pentru zona n care va
fi distribuit produsul. De asemenea, i documentatia trebuie tradusa, inclusiv cea de
ajutor (help menu).
O atentie speciala trebuie acordata solutiilor pentru afaceri. Trebuie
implementate corect procesele tipice practicii locale. Diferentele legate de desfasurarea
afacerilor n anumite culturi sunt date de cerinele guvernamentale i legislative ale tarii
respective, deci localizarea produselor destinate afacerilor poate deveni o sarcina
dificila.
Testarea de localizare evalueaza cat de bine este localizat produsul intr-o
anumita limba-tinta. Acest test se bazeaza pe resultatele testrii globalizate, unde
suportul funcional pentru o anumita tara a fost deja verifict (se compara cu acesta).
Dac produsul nu este suficient de bine globalizat pentru a suporta o anumita limba,
mai bine se evita localizarea n acea tara decat as apara probleme aditionale, care pot
deveni greu de rezolvat (si cu costuri mai mari, pentru c, cu cat o problema este
descoperita mai tarziu, cu atat solutionarea este mai scumpa). La livrare, producatorul
trebuie s se asigura ca aplicaia funcioneaz corect pe piata pentru cre a fost
proiectat. Mai jos sunt cateva puncte pe care trebuie s se puna accent la testul de
localizare:

- Componente care se altereaza n timpul localizarii, ca interfata cu utilizatorul i
anumite fisiere:
- Sistemul de operare;
- Versiuni de tastaturi (pentru fiecare limba, accente, diacritice, caractere
speciale etc.);
- Filtre de text;
- Hot-key-uri (combinatii de taste);
- Reguli de verificre a scrierii;
- Reguli de sortare;
- Trecerea de la litere mai la litere mici (si invers) pentru anumite cuvinte;
- Imprimante;
- Diverse dimensiuni ale hartiei pentru imprimat;
- Mouse-ul;
- Formtul de data;
- Rigle i masuratori;
- Disponibilitate de memorie;
- Interfata vocala (accente) (unde este cazul);
- Continut video;[8]

5.5.5. Testarea de performan
Aceasta testare se folosete pentru estimarea comportamentului unui produs
software, n privinta rspunsului i stabilitatii, sub o anumita sarcina. Este utila i pentru
a investiga, masura, valida sau verific alte calitati ale sistemului, ca scalabilitatea,
fiabilitatea i utilizarea de resurse.
Testarea de performan este o categorie mai larga, car include alte subtipuri de
testare, dintre care unele vor fi abordate n paragrafele urmatoare, iar altele au fost deja
descrise:
- Testare la sarcina: cea mai simpla form de testare de performan. Evalueaza
comportamentul produsului la o anumita sarcina asteptata (exemplu: multiple tranzactii,
accesuri multiple de la utilizatori etc.). Evidentiaza foarte bine bottle-neck-urile (gatuirile
care limiteaza performntele).
- Testarea de anduran (soak testing): pentru determinarea comportamentului
aplicaiei la incarcare continua. Se urmrete gestionarea memoriei i degradarea
performntelor n raport cu timpul (exemplu: timpul de rspuns pentru o aplicaie server-
client, care nu trebuie s creasca peste o anumita valoare);
- Testarea de stres (stress testing): se folosete pentru determinarea limitelor
superioare ale capacitatii aplicaiei (pentru toti parametrii de masurat) i a robustetii ei la
incarcare extrema;
- Testarea n impulsuri (spike testing): dupa cum sugereaza i numele, se
realizeaza print simularea cresterii brutse a numarului de utilizatori (acolo unde se
aplic) i evaluarea comportamentului produsului.
- Testarea n configuratie: este o alta varianta clasica a testrii de performan.
n locul testrii performntei prin perspectiva incarcarii, se testeaz efectele schimbarii
de configuratie din mediul programului asupta comportamentului i performntei.
- Testarea de izolare: nu este un test unic de performan. Este mai mult un
termen folosit pentru a denumi repetarea unui anumit test n scopul evidentierii
defectului.

Scopurile testrii de performan:
- Demonstreaza ca aplicaiaiatinge performantele cerute.
- Poate fi folosita pentru compararea a dou solutii diferite.
- Poate determina care componenta din produs sau din setul de date duce la
comportamente neasteptate.

Conditii de test

n testarea de performan este important (si de cele mai multe ori i dificil) ca
mediul de test s fie similar cu cel asteptat la funcionarea normala, insa nu este
intotdeauna posibil n practica. Motivul este acela ca, n productie (adic n timpul
funcionarii), sarcina de lucru are o natura aleatoare, si, dei sarcinile de test fac tot
posibilul de a le imita pe cele reale, este imposibila replicarea exacta a variabilitatii din
realitate.
Implementarile arhitecturale slab legare au creat dificultati aditionale tester-ilor.
Serviciile pentru intreprinderi au nevoie de testare coordonata (cu toti consumatorii care
creaza volume de tranzactii similare cu cele din realitate) pentru a replica cat mai precis
starile care apar n funcionarea reala. Din cauza costurilor, complexitatii i a
constrangerilor legate de timp, majoritatea organizatiilor folosesc acum unelte care
monitorizeaza i creaza conditii similare cu cele reale (denumite i zgomot) n mediile
lor de test.
Este critic pentru costurile de dezvoltare ca testele de performan s aiba loc
cat mai repede. Cu cat un defect este descoperit mai devreme, cu atat este mai ieftn
de remediat.

Mituri ale testrii de performan:

1. Testarea de performan este folosita pentru a defecta produsul
Aceasta testare se face pentru a intelege punctul slab al produsului. Altfel,
testarea sub conditii normale de funcionare se aplic (pentru a determina
comportamentul sub sarcina asteptata de la utilizator). n funcie de cerine, se poate
face i testare pentru pike-uri, anduran sau de stres.
2. Testarea de performan ar trebui fcut numai dupa testarea de integrare
Dei asa se procedeaza de multe ori n industrie, testarea ed performan se
poate face i n timpul dezvoltarii. Se numete testare timpurie de performan. Astfel,
proiectarea se face cu cerinele de performan mereu n vedere; gasirea unui bug n
performnte ar fi mai usor de remediat n etapele de dezvoltare decat dupa
implementarea finala.
3. Testarea de performan implic numai crearea de script-uri i orice
schimbare a aplicaiei se poate reflecta prin modificarea script-urilor.
Procesul de testare este unul evolutiv. Dei scripting-ul este important, este doar
una din componentele testrii de performan. Cea mai mare provocare pentru tester-ul
de performan este aceea de a determina ce tip de test este necesar i de a analiza
indicatorii de performan pentru a afla unde se afla bottle-neck-ul.[8]

5.5.6. Testarea de securitate
Aceasta testare se aplic pentru a determina dac un produs software
protejeaza datele sii mentine funcionalitatea. Exista 6 concepte de baza legate de
cuvantul securitare n software: confidentialitate, integritare, autentificare,
disponibilitate, autorizare i non-repudiere.

Taxonomie
Termeni utilizati n securitare i explicatiile lor:
- Descoperire= are scopul de a identifica serviciile folosite de acel produs
software. Nu are sensul de descoperire a vulnerabilitatilor, ci doar o detectare a
versiunii, care evidentiaza versiuni depasite de software vulnerabile la atacuri noi.
- Scanare de vulnerabilitate = se cauta probleme cunoscute de securitate,
folosind unelte automate pentru a crea conditiile pentru vulnerabilitatiile stiute. Nivelul
de risc raportat este setat automat de unealta, fr verificre manuala sau interpretare.
- Estimarea vulnerabilitatiilor = se folosete descoperirea i scanarea pentru a
identifica vulnerabilitatile i de a plasa descoperirile n contextul mediului sub test.
Exemplu: eliminarea pozitivelor false din raport i deciderea nivelului de risc pentru
diecare descoperire.
- Estimarea securitatii = construita peste estimarea vulnerabilitatii prin adaugarea
de verificre manuala pentru confirmare. Nu include i exploatarea vulnerabilitatii.
Verificrea are form accesului autorizat pentru confirmarea setarilor i implic
examinarea fisierelor log, rspunsului, mesajelor de eroare, coduri etc. O estimare a
securitatii vrea s obtina o acoperire cat mai mare a sistemelor testate, dar nu intra n
specificul unei anumite vulnerabilitati.
- Testarea de penetrare: simuleaza un atac al unui program rau intentionat.
Implic exploatarea vulnerabilitatilor gasite pentru a obtine acces n continuare la
aplicaie. Astfel tester-ii inteleg cum poate un atacator s castige acces la informaii
confidentiale, s afecteze integritatea datelor sau disponibilitatea unui serviciu, i
impactul actiunilor lui.

Confidentialitate inseamna ca datele i procesele trebuie protejate de publicare
neautorizata.
Integritatea este cerinta ca datele i procesele s fie protejate de modificare
neautorizata.este o masura pentru asigurarea corectitudinii informaiei. Schemele de
integritate folosesc de obicei aceleasi tehnologii ca cele pentru confidentialitate, dar
implic adaugarea de informaii la o comunicare pentru a form baza unei verificri
algoritmice, n locul codarii ntregii comuncari.
Autentificarea se refera la confirmarea identitatii unei persoane, urmarirea sursei
de provenienta a unei informaii sau asigurarea ca o masina sau un program este de
incredere.
Non-repudierea consta n asigurarea ca un mesaj transferat a fost trimis i
receptionat de participantii la comunicare (si nu de altcineva). Este o cale de a garanta
ca emitatorul unui mesaj nu poate nega emiterea acelui mesaj i receptorul nu poate
nega receptia mesajului.
Disponibilitatea este cerinta ca datele i procesele s fie protejate de atacuri de
tipul refuz de acces pentru utilizatorii autorizati.[8]

5.5.7. Testarea de utilizabilitate
Aceasta testare este o tehnic de evaluare a produsului prin testarea lui pe
utilizatori. Ofera informaii directe despre cum folosesc utilizatorii reali aplicaia.
Testarea de utilizabilitate se concentreaza pe masurarea capacitatii produsului
de a indeplinii scopurile pentru cre a fost creat, si, mai precis, usurinta n utilizare
Se poate spune ca primul test de utilizabilitate a avut loc n anii 40 i a fost
efectuat de Henry Dreyfuss, care a proiectat cabinele pentru dou vase de croaziera
(Independence i Constitution). Mai intai a construit cateva prototipuri i a adus mai
multe persoane s locuiasca n ele. Astfel proiectantii si-au dat seama ca trebuie s
puna intrerupatoarele pentru iluminat langa pat, ca oamenii s nu se loveasca n
intuneric de alte obiecte, ca trebuie s lase spatiu pentru bagajele mari i alte astfel de
lucruri care par marunte.
Testarea de utilizabilitate este o metod de tip black-box. Scopul este acela de a
observa cum folosesc oamenii produsul, unde apar erori, i cum se pot remedia
acestea. Aceasta testare implic de obicei cum raspund subiectii n 4 zone de interes:
eficient, precizie, amintiri i rspuns emotional. Rezultatele primului test sunt folosite
ca baza, sau masuratoare de control. Celelalte teste pot fi comparate cu baza pentru a
indica o imbunatatire.
- Eficient: cat dureaza i cati pasi sunt necesari ca utilizatorul s indeplineasca
o anumita sarcina;
- Precizie: cate greseli fac oamenii, i cu ce consecinte
- Amintiri: cat de usoriaminteste utilizatorul aplicaia, dupa o perioada n care
nu a avut contact cu ea
- Raspuns emotional: ce senzatii i s utilizatorului indeplinirea unei sarcini
(stres, usurare, incredere)
Pregtirea unui test de utilizabilitate implic proiectarea atenta a unui scenariu
sau a unei situatii reaslistice, n care persoana executa o lista de sarcini folosind
produsul de testat timp ce observatorii iau notite. Alte instrumente de testare, ca
instruciuni din script-uri, prototipuri de pe hartie, i chestionare pre/post testare, sunt
folosite pentru a obtine feedback n legatura cu produsul testat. Scopul este acela de a
observa interactiunea cu utilizatorul, ce i place i ce il deranjeaza.
Testarea prin metod holului este una din tehnici. n locul unei echipe angajate,
specializate de testeri, sunt implicti doar 5 sau 6 oameni, alesi aleator, care s
simuleze utilizatorul final. De aici vine i numele metodei, adic se iau niste oameni la
intamplare de pe hol. Se folosesc oameni care nu au legatura cuproiectul, care nu stiu
detaliile interioare ale acestuia. Este eficient mai ales n stadiile timpurii ale proiectrii
design-ului, cand designerii cauta impasuri posibile n care se pot afla utilizatorii.
n situatii n care evaluatorii, dezvoltatorii i utilizatorii se afla n locatii diferite
(alte tari i alte fusuri orare), realizarea unui test n conditii de laborator poate fi o
provocare serioasa. Astfel se ajunge i la evaluarea utilizabilitatii a distanta, utilizatorii i
evaluatorii aflandu-se la mare departare unii de altii (atat spatial cat i temporal, adic
fusuri orare diferite). Testarea la distanta poate fi sincrona sau asincrona. Metod
sincrona implic video-conferinte i alte unelte de comunicare n timp real. n cazul
metodei asincrone, evaluatorul so tester-ul lucreaza separat. Metodele asincrone includ
urmarirea automata a click-urilor, fisiere log pentru incidente critice i feedback
subiectiv. Ca un studiu de laborator, un test de utilizabilitate la distanta se bazeaza pe
sarcini, i platform permite captura de click-uri i de alte activitati. Acest tip de test are
loc n mediul utilizatorului, fapt care ajuta i mai mult la simularea folosirii reale.
O alta metod de testare a utilizabilitatii este raportul expert. Se aduc experti cu
cunotiinte extinse n domeniul utilizarii unui produs.
Rapoartele expert pot fi fcute i automat, dar folosind programe carora li s-au
impus anumite reguli pentru un design corect. Dei nu ofera atatea detalii ca un raport
fcut de om, este mai rapid i mai ieftin.
Este important i numarul de oameni care testeaz. n 1990, Jakob Nielsen
propunea folosirea unui numar mare de teste, dar cu grupuri mici (de maxim 5 oameni).
El considera ca dac 2-3 oameni nu se descurca usor intr-o anumita interfata grafica,
nu are sens s observe i pe altii facand acelasi lucru. Argumentul lui a prmit i un
suport matematic:
U = 1 - ( 1 p )
n

U= numarul de probleme descoperite
P= probabilitatea ca un utilizator s decopere o problema
N= numarul de utilizatori
ns exista i dezavantaje ale metodei lui Nielsen:
- Din moment ce utilizabilitatea este legata de un set mic de testeri, un esantion
asa de mic nu este reprezentativ pentru intreaga populatie, deci rezultatele vor fi mai
mult legate de esantionul testat decat de populatia pe care o reprezinta (legea
numerelor mari)
- Problemele de utilizabilitate nu sunt toate la fel de usor de descoperit, deci cele
ascunse pot incetini procesul.

Nielsen nu se oprea la un singur test cu cei 5 utilizatori. Dupa testare i
decoperirea problemelor, acestea erau remediate pe loc i se faca un nou test cu alt
grup. Astfel a observat ca obtinea rezultate mai bune decat dac facea un singur test cu
10 oameni. n practica, testele se fac odata sau de 2 ori pe saptamana n timpul
dezvoltarii, folosind grupuri de 3-5 oameni, iar rezultatele se livreaza n cursul a 24 de
ore designer-ilor. Se poate ajunge la un numar total de 50 pnla 100 de subiecti care
au testat programul n timplu ciclului de dezvoltare.
n primele etape, n care probabilitatea de a descoperi probleme serioase este
mai mare, se pot folosi subiecti cu orice grad de inteligenta. n urmatoarele etape, se
aleg subiectii cu abilitati intr-o gama mai larga. S-a bservat ca cei cu experienta nu au
avut deloc problema la nici unul din teste, n timp ce incepatorii intalneau mai multe
obstacole. n urmatoarele etape, se recruteaza testeri din populatia tinta (carora le este
destinat produsul software).[8]

5.6.Concluzii

Dupa cum se poate vedea, testarea software reprezint o investigaie dirijat n
scopul de a obine informaii legate de calitatea produsului software, prin rularea
programului n scopul de a descoperi bug-uri software. Este o etap puternic
dependent de contextul operaional n care programul va fi folosit.
Testarea nu ofera garantia c produsul funcioneaz corect n orice condiii ci
numai n acele condiii pentru care a fost testat. Astfel alegerea dintre modalitatile de
testare folosite este esenial pentru acoperirea unei game ct mai largi de posibile
erori.
Informaia obinut n urma testrii este esenial pentru remedierea defectului
respectiv. n momentul n care se detecteaz o eroare, este posibil s nu se cunoasc
i cauza care a generat acea eroare. Programatorul este cel care trebuie ca dup
detecia erorii s identifice pe baza acesteia instruciunea sau secvena de instruciuni
care a dus la apariia erori.
Numai dupa remedierea defectelor se poate trece la etapa urmatoare de
dezvoltare a produsului software.

Bibliografie
- [1] Elfriede Dustin: Effective Software Testing - 50 Specific Ways to Improve
Your Testing
- [2] Paul Ammann, Jeff Offutt: Introduction To software testing
- [3] Dan Pilone, Russ Miles: Head First Software Development
- [4] Mauro Pezzand, Michael Young: Software testing and Analisys: Process,
Principles and Techniques
- [5] Kshirasagar Naik, Priyadashi Tripathy: Software Testing and Quality
Assurance
- [6] Gerald D. Everett, Raymond McLeod Jr: Software Testing: Testing Across
the Entire Software Development Life Cycle
- [7] Glenford J. Myers: The Art Of Software Testing, 2nd Edition (2004)
- [8] www.wikipedia.com
- [9] www.informit.com
- [10] www.calsoftlabs.com
- [11] www.searchsoftwarequality.techtarget.com
- [12]www.integrant.com
- [13] www.nresult.com



IV. Verificarea i validarea produselor software


Tic Andra Maria


1. Introducere
Prin activitile de verificare i validare se urmrete ca software-ul s satisfac
specificaiile sale in timpul fiecrei faze a ciclului su de dezvoltare. Se asigur faptul ca
fiecare articol software s fie verificat de o persoan diferit de aceea care l-a produs i
c efortul de verificare i validare este adecvat pentru ca fiecare articol software s fie
operaional.
Obiectivul activitilor de verificare i validare este de a reduce erorile software la
un nivel acceptabil. Efortul necesar poate reprezenta 30-90% din totalul resurselor
proiectului, in functie de complexitatea i gradul de risc al funcionrii
necorespunztoare a software-ului. Organizarea activitilor de verificare i validare
este inclus in activitile de management ale proiectului software.
Verificarea asigur c produsul este construit in concordan cu cerinele,
specificaiile i condiiile stabilite in etapele de proiectare i standardele in vigoare la
momentul punerii pe pia a acestuia. Este un proces de control al calitii folosit la
evaluarea conformitii i se desfasoar concomitent cu dezvoltarea software-ului
respectiv, fiind de cele mai multe ori un proces intern.[1],[9]
Verificarea inseamn stabilirea i documentarea faptului c articolele referitoare
la software, procesele i serviciile sunt in conformitate cu cerinele specificate.
Validarea asigur utilizabilitatea produsului pe piaa. Este procesul de a evalua
un sistem sau o component in timpul sau la sfritul procesului de dezvoltare pentru a
determina dac satisface cerinele specificate. Validarea este un proces extern de
asigurare a calitii. [1],[9]
Diferena dintre verificare i validare este important numai pentru teoreticieni. In
practic, verificarea i validarea se refer la toate activitile care asigur c software-ul
va funciona conform cerinelor. [1]
Validarea poate fi clasificat astfel:
Validare in perspectiv activitaile desfurate inainte ca noi articole s
fie lansate pentru a se asigura caracteristicile de interes care intrunesc
standarde de funcionare corecte si sigure.
Validare retrospectiv proces pentru articolele deja in uz, distribuie sau
producie. Se reia evaluarea specificaiilor i ateptrilor de la produs, iar
daca lipsesc date se sisteaz etapa curent. Acest proces se realizeaz
dac se constat lipsa realizrii unei validri de perspectiv, la
schimbarea unor legislaii sau standarde, la repunerea pe pia a unor
produse anterior excluse.
Validare curent are loc concomitent cu procesul de
proiectare/dezvoltare.[1]
Activitile de verificare includ recenzii si verificri formale.
Scopurile verificrii sunt acelea de a demonstra ca programul este corect (dac
metoda i programul permite) i de a gsi erori. Verificarea este consistent dac un
sistem raportat corect se dovedete a fi corect i complet, dac prin metoda respectiv
se poate determina corectitudinea fiecrui sistem. Detecia de erori este consistent
cnd erorile raportante sunt reale i complet cnd s-au gsit toate erorile. [2]
Metodele de verificare pot fi:
Statice, cnd se verific fr execuia codului i aici se inscriu analiza de fluxuri
de date si verificarea formal.
Dinamice, cnd se execut codul: rulare pe maina virtual, execuia simbolic.



2. Recenziile (Reviews) de software sunt reprezentate de intlniri pe parcursul
crora un produs este examinat de personalul care s-a ocupat de proiect,
manageri, utilizatori, clieni sau alte pri interesate s comenteze sau s
aprobe. [3]
Clasificare:
- Recenzii de la egal la egal, realizate de autorul proiectului sau de mai
muli colegi din echipa respectiv, cu scopul evalurii coninutului tehnic i
al calitii muncii depuse.
o Recenzia codului examinarea sistematic a codului surs.
o Programare in echip doi programatori dezvolt impreun un
produs software la aceeai staie de lucru.
o Inspecii se urmrete o procedur strict de depistare a
defectelor.
o Walkthrough autorii organizeaz pentru toate parile interesate o
prezentare a proiectului, participanii avnd oportunitatea s afle
rspunsuri, s sesizeze defecte sau neconcordane.
o Recenzii tehnice o echipa format din personal calificat
examineaz dac produsul este adecvat pentru uzul destinat i
identific discrepane cu standarde i specificaii.
- Recenzii la nivel de management, realizate de reprezentani ai nivelului
managerial al intreprinderii pentru a evalua activitatea curent i pentru a
lua decizii referitor la desfurarea urmtoarelor etape ale proiectului.
- Audituri, realizate de personal din exteriorul proiectului pentru a evalua
conformitatea produsului cu specificaiile, standardele i acordurile
contractuale iniiale.[3]
Procedura IEEE 1028, [3], pentru formalizarea recenziilor definete un set de
activiti bazate pe procesul de inspecie al lui Michael Fagan, dezvoltat pentru prima
dat la IBM. Paii urmtori sunt obligatorii:
0. Coordonatorul recenziei folosete o list standard de criterii de intrare care
asigur condiiile optime pentru succesul intregului proces.
1. Organizarea: invitarea personalului, informarea acestuia referitor la topic-ul
review-ului, a locaiei i a orei, asigurarea materialelor i dispozitivelor pentru
buna desfaurare a intlnirii.
2. Planificarea: coordonatorul identific i confirm obiectivele intlnirii,
organizeaz o echip care s realizeze discuia.
3. Recapitularea procedurilor: asigurarea faptului c toi participanii ineleg
scopul acestei dezbateri.
4. Pregtirea individual: fiecare parte a echipei se pregtete pentru
dezbaterea de grup, examinnd atent potenialele defecte luate in discuie.
5. Examinarea de grup: are loc intlnirea propriu-zis cu toi participanii unde
sunt expuse rezultatele individuale cu scopul ajungerii la un consens.
6. Aplicarea deciziilor: autorul produsului impreun cu echipa sa repar
defectele pentru a satisface cerinele exprimate in timpul intlnirii. Se verific
satisfacerea tuturor cerinelor.
7. Sfritul evalurii: coordonatorul verific finalizarea cu succes a intregului
proces.




Avantajul organizrii acestei recenzii este c se pot identifica probleme mult mai
ieftin dect dac identificarea acestora s-ar face in etapa de testare (proces de
detectare a erorilor). Mai mult, ele ofer oportunitatea autorilor tehnici de a inva s
dezvolte documentaie cu o marj de eroare foarte redus, putnd astfel s identifice
din timp i s renune la aspecte ale proiectului care pot duce la detectarea ulterioar
de defecte. Vorbim aici de un proces de prevenire a apariiei defectelor.[3]
Recenziile de cod constau in verificarea codurilor i inlturarea defectelor de
ctre membrii echipei proiectului. Un defect este reprezentat de un bloc de cod care nu
este implementat conform cerinelor, care nu funioneaz dup intenia programatorului
sau care nu este incorect dar poate fi perfecionat. Pe lng faptul c inltur bug-urile,
aceast tehnic este de asemenea benefic pentru dezvoltatorii inceptori care pot
inva in aceasta manier noi modaliti de programare.[3]
Inspeciile sunt cele mai folosite in proiectele software. Scopul inspectorilor este
ca acetia s ajung impreun la un consens asupra unui produs i s aprobe utilizarea
acestuia in cadrul proiectului. Scopul principal al inspeciei este identificarea defectelor.
[4]
Spre deosebire de restul recenziilor, walkthrough-urile au ca obiective
familiarizarea audienei cu coninutul proiectului i obinerea de rspunsuri despre
calitatea tehnic i despre coninuntul documentaiei acestuia. [5]

Planificare Recapitulare Aplicare
Dec\\
Intlnire Pregtire Finalizare
3. Verificrile formale sunt modalitile prin care se aprob sau dezaprob
corectitudinea algoritmilor care stau la baza unui sistem pe baza unor
specificaii sau proprieti, folosind metode formale, matematice. Deoarece
sistemul este modelat matematic, sunt posibile rezultate garantate in limitele
posibilitilor/presupunerilor de modelare. [8]
Verificrile formale sunt foarte folositoare la demonstrarea corectitudinii
sistemelor software exprimate prin codul lor surs. Acest tip de verificare const in
furnizarea unei dovezi formale asupra corectitudinii algoritmului pe baza modelrii
matematice abstracte a sistemului, corespondena dintre modelul matematic i natura
sistemului fiind cunoscute din etapa conceptual.
Verificarea formal pentru software cunoate mai multe abordri:
Abordarea tradiionala a anilor `70 cnd codul este mai inti scris si apoi
dovedit a fi corect intr-o etapa separat.
Programare scris in mod dependent, cnd scrierea codurilor se face
concomitent cu verificarea corectitudinii acestora. [8]

3.1. Model checking
Metoda model checking const in explorarea sistematic si exhaustiv a
modelului matematic. Acest lucru este posibil att pentru modelele finite ct i pentru
cele infinite unde seturile infinite de stri pot fi reprezenate in mod finit prin
abstractizare. De obicei aceast metod const in explorararea tuturor strilor i
tranziiilor din model, utiliznd tehnici de abstractizare pe domenii, care consider
grupuri intregi de stri intr-o singura operaie, reducnd astfel timpul de calcul.
Implementarea tehnicilor include enumerarea spaiului de stri, a spaiului simbolic de
stri, interpretarea abstract, simularea simbolic i rafinarea abstract. Proprietile
care vor fi verificate sunt descrise in logica temporal, precum LTL- linear temporal logic
si CTL- computational tree logic. [9]
Aceast metod rezolv urmatoarea problem: dndu-se modelul unui sistem, se
verific dac acesta indeplinete o anume specificaie dat. Pentru a rezolva aceast
problem dupa un algoritm, modelul sistemului i specificaiile acestuia vor fi formulate
intr-un limbaj matematic precis: se verific dac o structur dat satisface o formul
logic dat.
Model checking-ul este un automat cu stri finite. Spre deosebire de verificarea
prin demonstrare de teoreme, aceast metoda nu necesit o anotare a programului de
ctre utilizator, verificarea fcndu-se automat pentru toate execuiile posibile, in caz de
eroare generndu-se un contraexemplu.
Se urmeaz urmtorii pai:
Se face specificarea proprietilor i traducerea ei in limbajul C. Programul
original este instrumentat.
Deoarece programul poate fi complex, se folosete abstracia in verificare,
adic se dorete concentrarea asupra poriunii relevante din program.
Acest lucru se realizeaz prin tehnica program slicing - se determin
fragmentul de program care afecteaz o anumita proprietate a
programului.
Se genereaz programul boolean pornind de la predicatele din
specificaie.
Se analizeaz programul boolean: se calculeaz mulimea strilor atinse.
Dac se depisteaza erori se vor genera contraexemple i noi predicate:
o Dac contraexemplul este realizabil, atunci eroarea este real.
o Altfel, se pleac din nou din starea de eroare in programul abstract
i se parcurge calea de eroare inapoi pn cnd se gsete o
inconsisten. Dup aceea se genereaz predicatele
corespunztoare. Se regenereaz programul boolean i se reia
verificarea.

3.2. Inferena logic
O alt abordare este reprezentat de inferena logic care const in folosirea
unei versiuni formale a unui raionament matematic. Se folosesc de obicei teoreme
precum HOL, ACL2, Isabelle, Coq. Aceste teoreme sunt aplicate parial automat i sunt
conduse de inelgerea de ctre utilizator a sistemului de validat. Instrumentele mai noi
precum Perfect Developer i Escher C Verifier incearc s automatizeze complet
procesul. Logica liniar i cea temporal poate de asemenea fi folosit la inferena
logic i nu numai in cazul model checking-ului.
3.3. Derivarea de program
O alta metoda este reprezentata de derivarea de program, cnd producerea de
cod eficient se face plecnd de la specificaiile funcionale i se urmeaz o serie de pai
cu rolul de a conserva corectitudinea. Formalismul Bird-Meertens respect aceste
principii, fiind considerat ca o alt form de verificare concomitent cu construirea
codului.


3.4. Verificarea prin demonstrare de teoreme se realizeaz prin folosirea
unui demonstrator de teoreme, plecnd de la anumite condiii de
verificare. [10]
In anul 1967, in lucrarea sa intitulat Atribuirea de sensuri programelor, Robert
W. Floyd spunea c o baz adecvat pentru definirea formal a sensurilor programelor
trebuie sa fie in aa fel inct s stabileasc un standard riguros de dovezi. Mai mult, el
pleac de la ideea c dac valorile iniiale ale variabilelor programului satisfac relaia
R1, atunci valorile finale vor satisface relaia R2. Astfel, scopul lucrrii sale era s
formalizeze semantica limbajelor de programare. [8],[10]
Lucrarea lui Floyd dezvolt reguli generale pentru combinarea condiiilor de
verificare i reguli specifice pentru diferitele tipuri de instruciuni. Se introduc invarianii
pentru raionamentele despre cicluri i se trateaz terminarea folosind o masur
pozitiv de descrcare.
Metoda introdusa de Floyd poart numele de metoda anotrii unui program cu
aseriuni:
- Condiia de verificare: se consider o formula Vc(P,Q) astfel inct dac P
este adevrat inainte de a se executa c, atunci Q este adevrat la ieire.
- Cea mai verificabil consecin: avem un program i consideram o
condiie iniial. Dup execuia programului aceasta va fi cea mai
puternic proprietate valabil.
Aceste aseriuni au fost exprimate in logica predicatelor de ordinul I.
Mai trziu, in anul 1969, Floyd a conceput impreuna cu Hoare ceea ce se
numeste logica Floyd-Hoare sau regulile lui Hoare. Acesta este un sistem formal cu
un set de reguli logice pentru rationarea riguroas asupra corectitudinii programelor. Ei
au avut ca punct de plecare lucrarea lui Floyd. [6],[10]
In aceast lucrare au tratat precondiii i postcondiii pentru execuia unei
instruciuni, folosind notaia de triplet Hoare care pune mai clar in eviden relaia dintre
instruciune i cele doua aseriuni. De aceast dat au lucrat cu programe textuale i nu
cu scheme logice.
Cele doua notaii de triplet Hoare:
Corectitudinea parial: {P} S {Q} dac S este executat intr-o stare care
satisface P i execuia lui S se termin, atunci starea rezultant satisface
Q.
Corectitudinea total: [P] S [Q] daca S este executat intr-o stare care
satisface P , atunci execuia lui S se termin i starea rezutant satisface
Q.
Regulile lui Hoare sunt definite pentru fiecare tip de instruciune in parte, prin
combinaia lor putndu-se raiona programe intregi:
Axioma declaraiei goale: { } { } P sare peste P - declaraia sare peste nu
schimb starea programului aa c tot ceea ce este adevrat inainte de
sare peste va fi adevarat i dup.
Axioma pentru atribuire: { [ / ]} : { } P E x x E P = . Aici [ / ] P E x denot expresia
P in care toate apariiile variabilei x au fost inlocuite cu expresia E.
Aceast axiom afirm faptul c adevrul lui { [ / ]} P E x este echivalent cu
adevrul dupa asignare al lui {P}. Astfel, cnd { [ / ]} P E x este adevrat
inainte de asignare, atunci {P} este adevrat dup asignare i
dac{ [ / ]} P E x este fals inainte de asignare atunci {P} va fi de asemenea
fals.
Ex: {x=y-2}x:=x+2{x=y} in rezultat, x=y, substituim x cu expresia atribuit, x+2 i
se obine x+2=y de unde x=y-2.
Aceast axiom nu se aplic atunci cnd mai multe nume refer aceeai valoare
stocat.
Ex: {y=3}x:=2{y=3}.
Regula de compunere sau de secveniere:
{ } { },{ } { }
{ } ; { }
P S Q Q T R
P S T R
- se aplic
programelor executate secvenial S i T, unde S se execut inaintea lui T.
Ex: Pentru S: {x+1=43}y:=x+1{y=43} i T: {y=43}z:=y{z=43}, atunci
{x+1=43}y:=x+1;z:=y{z=43}.
Regula de decizie:
{ } { },{ } { }
{ } { }
B P S Q B P T Q
P if BthenS elseT endif Q
. .
.
Regula consecinei:
` ,{ } { }, `
{ `} { `}
P P P S Q Q Q
P S Q


Regula ciclului cu test initial while:
{ } { }
{ } { }
P B S P
P while BdoS done B P
.
.
, unde P
este testul iniial.
Regula ciclului cu test iniial while pentru corectitudine total:
,{ } { }
{ } { }
is well founded P B t z S P t z
P while BdoS done B P
< . . = . <
.
.
In continuare, in 1975, E.W.Dijkstra a reformulat regulile lui Hoare in lucrarea sa
intitulat Guarded commands, non-determinancy and formal derivation of programs.
Spre deosebire de Hoare i Floyd a cror logic este prezentat ca un sistem deductiv,
semantica transformrii bazata pe predicate a lui Dijkstra este o strategie complet
pentru a reduce problema verificrii tripletului Hoare la demonstrarea unei legi logice de
ordinul intai (concluzionare pe baza unui predicat considerat adevrat). [7],[10]
Abordarea lui Dijkstra folosete operatorul weakest precondition. Astfel,
pentru o instruciune S i o postcondiie dat Q pot exista mai multe precondiii P astfel
inct {P} S {Q} sau [P] S [Q]. Dijkstra calculeaz o precondiie necesar i sufiecient
wp(S,Q) pentru terminarea cu succes a lui S cu postcondiia Q. Wp este un
transformator de predicate care permite definirea unui calcul cu astfel de transformri.
[7],[10]
Preconditiile lui Dijkstra:
Salt peste (skip): wp(skip,R)=R.
Renun la (abort): wp(abort,R)=false.
Atribuire
o Var1: wp(x:=E,R)= y, y=E =>R[x<-y], unde y este o nou variabil
care stocheaz valoarea final a variabilei x.
o Var2: wp(x:=E,R)=R[x<-E].
Prima variant evit o potenial replicare a lui E in R, pe cnd a doua
variant este mult mai simpl, deoarece avem o singur apariie a lui x in
R.
Secveniere: wp(S1;S2,R)=wp(S1,wp(S2,R)).
Condiionare:
( 1 2 , ) ( ( 1, )) ( ( 2, )) wp if EthenS elseS elseend R E wp S R E wp S R = . .
Bucla while:
( , )
, (( ) ( , ))[ ]
, (( ) )[ ]
wp while EdoS done R I
y E I wp S I x y x y
y E I R x y
=
. . . <
. .


Y este un tuplu nou de variabile. Prima formul inseamn c invariantul I
trebuie s ramn neschimbat. A doua inseamn c S (corpul buclei while)
trebuie s pstreze invariantul i s micoreze variantul: aici variabila y
reprezint starea iniiala a blocului de execuie. Ultima formul inseamn c R
trebuie s fie stabilit la finalul buclei while.
In concluzie, la verificarea prin demonstrare de teoreme se urmeaz paii:
Se scriu tripletele Hoare sau precondiiile Dijkstra.
Se verific inlnuirea acestora cu un demonstrator de teoreme sau cu o
procedur de decizie.

4. Concluzii [8],[11]

Metodele formale fac posibile inelegerea i punerea in discuie a problemelor,
descoperirea contradiciilor, prin notaii clare i precise.
Ele sunt o modalitate prin care se verific pri de o importan major din
programe cu ajutorul unui studiu abstract, deoarece notaiile matematice au o
semantic precis care poate fi ineleas intr-un context internaional, inlturnd
ambiguitile.

5. Bibliografie
[1] http://en.wikipedia.org/wiki/Verification_and_validation
[2] http://en.wikipedia.org/wiki/Verification_and_Validation_(software)
[3] http://en.wikipedia.org/wiki/Software_review
[4] http://en.wikipedia.org/wiki/Software_inspection
[5] http://en.wikipedia.org/wiki/Software_walkthrough
[6] http://en.wikipedia.org/wiki/Hoare_triple
[7] http://en.wikipedia.org/wiki/Weakest_precondition
[8] http://en.wikipedia.org/wiki/Formal_verification
[9] http://en.wikipedia.org/wiki/Model_checking
[10] http://bigfoot.cs.upt.ro/~marius/curs/vvs/index.html
[11]
http://se.inf.ethz.ch/old/teaching/ws2006/0273/slides/outsourcing_20_requirements.pdf



V. Concluzii
Fiecare etap care are loc este puternic dependent de etapele realizate
anterior. Astfel anumite etape nu pot fi realizate dect n urma finalizirii alteia (ex:
Proiectarea nu poate s nceap decat dup finalizarea analizei). n plus nu exist o
divizare temporal exact a acestora, ele putnd s se suprapun (ex: Documentarea
se face pentru fiecare etap n parte). Astfel etapele nu pot fi tratate independent.
De asemenea, fiecare etap trebuie s respecte anumite reguli pentru a putea fi
considerat de calitate. Asigurarea calitii duce la minimizarea complexitii produsului
i deci la o mai bun organizare a sa, oferind posibilitatea de a obine un produs
performant.
Nerespecterea regulilor de calitate poate duce la realizarea unui produs
neperformant, la realizarea lui la costuri mult prea ridicare sau chiar la nefinalizarea
acestuia.

S-ar putea să vă placă și