CORECTITUDINEA APLICAŢIILOR

Corectitudinea aplicaţiilor se împarte în patru categorii:

- corectitudinea sintacticǎ ce presupune cǎ programul este corect atunci când el
se compileazǎ fǎrǎ erori; cu alte cuvinte când ruleazǎ; când un program este
corect sintactic, el este restricţionat la codul şi limbajul folosit;
- corectitudinea funcţionalǎ presupune cǎ un program este corect când satisface
cerinţele din specificaţii;
- corectitudinea designului, spre deosebire de celelalte categorii, presupune cǎ
programul este corect structurat astfel încât sǎ permitǎ extensibilitatea; în acest
caz, experinţa în proiectarea aplicaţiilor este principala cheie cǎtre o structurǎ
corectǎ de program;
- corectitudinea performanţei şi validarea intrǎrilor şi ieşirilor presupune cǎ
programul trebuie sǎ furnizeze ieşiri adecvate pentru intrǎri invalide şi
trebuie sǎ fie de asemenea optimizat cu privire la lungimea codului şi
rapiditatea sa de execuţie.

O clasificare a metodelor de verificare a corectitudinii programelor este evidenţiatǎ în

[MILI84] dupǎ mai multe axe, figura 1:
- axa evaluare versus inducţie; unele metode de verificare a corectitudinii
programelor evalueazǎ mai întâi funcţia calculatǎ într-un program şi pe
urmǎ demonstreazǎ proprietǎţile programului utilizând funcţia obţinutǎ, în
timp ce altele demonstreazǎ proprietǎţile programului prin inducţie
împreunǎ cu una din multele dimensiuni ale complexitǎţii programului;
- axa static versus dinamic; câteva metode de verificare considerǎ un
program ca un obiect static şi se bazeazǎ pe textul lor sursǎ, în timp ce
altele considerǎ programul ca un obiect dinamic şi se bazeazǎ pe execuţia
lui;
 - axa structurǎ de control versus structurǎ de date; unele metode se bazeazǎ
pe structura de control a programului în timp ce altele se bazeazǎ pe
structura de date a programului;
- axa lungimea execuţiei versus urmǎrirea execuţiei; unele metode mǎsoarǎ
comportamentul dinamic al programului prin lungimea sa (numǎrul de
iteraţii) în timp ce altele mǎsoarǎ programul prin urma sa (succesiunea
etichetelor atinse în timpul execuţiei);
- axa iteraţie versus recursivitate; unele metode de verificare sunt aplicabile
în primul rând pe programe iterative în timp ce altele sunt aplicabile pe
programe recursive.
Spaţiu
Recursivitate

Metoda inducţiei structurale

Adâncime

Metoda inducţiei calculate

Lungime
Inducţie

Dinamic

Metoda inducţiei subgrupǎ

Iteraţie

Urma

Metoda aserţiunilor inductive

Verificare

Static

Date

Metoda aserţiunilor
intermitente
Evaluare

Iteraţie

Metoda execuţiei
Control

simbolice Metoda aserţiunilor invariante

Recursivitate

Teoria punctului fix

Figura 1. Clasificarea metodelor de verificare a corectitudinii aplicaţiilor informatice

[MILI84]
 Se considerǎ programul PRG cu structura arborescentǎ datǎ în figura 2.
Programul PRG include urmǎtoarele componente:
MO – modul principal
MI – grup de module pentru managementul datelor de intrare
MC – grup de module pentru managementul prelucrǎrilor
MR – grup de module pentru managementul rezultatelor finale
MII1 – modul pentru utilizarea datelor de test
MII2 – modul pentru iniţializarea datelor de la tastaturǎ
MII3 - modul pentru iniţializarea datelor din fişiere
MCC1 – modul calcul medie aritmeticǎ
MCC2 – modul sortare elemente dintr-un şir
MCC3 – modul calcul produs scalar a doi vectori
MCC4 – modul calcul inversǎ matrice
MRR1 – modul de afişare rezultat sub forma unui numǎr
MRR2 – modul de afişare rezultat sub forma unui şir
MRR3 – modul de afişare rezultat sub forma unui tablou

MO

MI MC MR

MII1 MII2 MII3 MCC1 MCC2 MCC3 MCC4 MRR1 MRR2 MRR3

Figura 2. Structurǎ arborescentǎ a programului PRG

 Se presupune existenţa unui instrument care permite demonstrarea corectitudinii
întregului program.
Rezultatul procesului de demonstrare a corectitudinii este concis. Programul este
corect.
În caz contrar, rezultatul concis este: programul nu este corect.
Suplimentar, instrumentul furnizeazǎ informaţii ce stabilesc locurile unde apar
cauze din care programul îşi pierde caracteristica de corectitudine. Programatorii
opereazǎ modificǎri în acele puncte ale programului şi reitereazǎ activarea
instrumentului pentru demonstrarea corectitudinii. Procesul se încheie dacǎ s-a obţinut
rezultatul: programul este corect.
Procesul de demonstrare a corectitudinii se încheie şi în cazul în care numǎrul de
iteraţii depǎşeşte un anumit prag chiar dacǎ la fiecare demonstrare a corectitudinii
rezultatul obţinut aratǎ cǎ programul nu este corect. În acest caz programul este
abandonat şi se considerǎ o cheltuialǎ inutilǎ de resurse pentru realizarea lui.
În cazul în care instrumentele de demonstrare a corectitudinii au un nivel de
performanţǎ mai scǎzut, operând numai la nivel de modul, se identificǎ urmǎtoarele
situaţii:
- se demonstreazǎ rând pe rând cǎ toate modulele programului sunt corecte, în
acest caz se acceptǎ afirmaţia cǎ programul are toate modulele corecte, fǎrǎ a
concluziona cǎ programul în totalitatea lui este corect;
- se demonstreazǎ corectitudinea pentru o parte dintre module restul fiind
considerate ca incorecte; un astfel de program posedǎ module ce sunt
caracterizate prin corectitudine parţialǎ, adicǎ unele module sunt corecte,
altele nu;
- se demonstreazǎ cǎ toate modulele sunt incorecte
În cazul corectitudinii parţiale este necesar sǎ se stabileascǎ ponderea modulelor
corecte faţǎ de întregul program.
Se calculeazǎ complexitatea fiecǎrui modul.
Complexitatea întregului program se obţine în ipoteza de liniaritate, ca sumǎ a
complexitǎţilor modulelor.
 Se calculeazǎ complexitatea modulelor pentru care a fost evidenţiatǎ
caracteristica de calitate corectitudinea.
Indicatorul nivel relativ de corectitudine, RNC, este dat de relaţia:

SMC
RNC =
SMT
unde:
SMC – suma complexitǎţii modulelor înzestrate cu caracteristica corectitudine
SMT – suma complexitǎţii tuturor modulelor care alcǎtuiesc programul
Deci,
NM

∑α C
i =1
i i
RNC = NM

∑C
i =1
i

1, DA
αi = 
0, NU
unde:
NM – reprezintǎ numǎrul total de module
Ci – complexitatea asociatǎ modului i
α i = 1 - înseamnǎ cǎ modul i este înzestrat cu caracteristica de corectitudine
α i = 0 - înseamnǎ cǎ modul i nu este înzestrat cu caracteristica de corectitudine
 TESTAREA APLICAŢIILOR INFORMATICE

Testarea este una dintre etapele deosebit de importante din ciclul de dezvoltare a
aplicaţiilor pentru cǎ:
- aplicaţia opereazǎ independent de elaborator; elaboratorul o implementeazǎ
şi în cazul apariţiei de erori se declanşeazǎ modificǎri în baze de date,
eronate, se acceseazǎ eronat resurse, se traverseazǎ eronat fluxul de
prelucrare, utilizatorul nu are posibilitatea sǎ intervinǎ cel puţin sǎ stopeze
anomaliile în timp real, ceea ce îi creazǎ un nivel foarte ridicat de
insatisfacţie în raport cu modul anterior de soluţionare a problemelor sale,
mod neinformatizat sau slab informatizat;
- utilizatorul foloseşte direct aplicaţia în comparaţie cu operatorii specializaţi
care ştiu sǎ interpreteze coduri, mesaje, care ştiu când sǎ reia şi cum sǎ reia
anumiţi paşi ai rezolvǎrii problemei; utilizatorii în mod natural
interacţioneazǎ cu aplicaţia informaticǎ şi acceseazǎ fǎrǎ artificii strict
resursele pe care aplicaţia i le pune la dispoziţie;
- existǎ o separare exactǎ a rolului pe care-l au utilizatorii de ceea ce
efectueazǎ administratorii de aplicaţii şi de ceea ce oferǎ asistenţa
elaboratorului; o aplicaţie informaticǎ care include erori genereazǎ costuri de
depanare foarte mari la nivelul elaboratorului şi pierderi prin nefuncţionare,
la nivelul beneficiarului;
Testarea programelor software este acţiunea de a pune în practică unul sau mai
multe teste, unde un test este o operaţie tehnică care determină una sau mai multe
caracteristici ale unui element sau sistem software dat, în conformitate cu o procedură
specificată.
Totalitatea activităţilor de testare software sunt de obicei referite ca fazele sau
stagiile testării software.
O fază de testare software este un proces în care se garantează că unele aspecte
ale produsului, sistemului sau elementului software funcţionează corespunzător.
 Numărul fazelor testării software întrebuinţate variază foarte mult în funcţie de
companii şi aplicaţii. Numărul fazelor conform [JONE97] variazǎ între 1 şi 16. Pentru
aplicaţiilor software mari, companiile folosesc în mod tipic un proces de 12 faze care
sunt unite în trei categorii:
- fazele testării generale includ testarea subrutinelor, testarea elementelor,
testarea noilor funcţii, testarea regresivă, integrarea şi testarea sistemului;
- fazele testării specializate constau în testarea calităţii sau solicitărilor, testarea
performanţei, testarea platformei şi testarea protecţiei;
- fazele testării prin implicarea utilizatorilor încorporează testarea utilităţii şi
testarea pe teren.
După ce programul software ajunge într-o fază operaţională, începe faza de
mentenanţă în care se fac îmbunătăţiri şi reparaţii asupra programului software. În
timpul acestei faze, unele sau toate fazele testării software sunt repetate. Multe din
aceste faze sunt comune şi foarte bine înţelese de industria de software comercial, dar
nu toate companiile utilizează acelaşi vocabular pentru a le descrie.
Fazele testării generale sunt fundamentale în testarea software şi au loc pentru
toate programele. Urmatoarele faze sunt considerate ca fiind fazele testării software
generale:
- testarea subrutinelor / unităţilor
- testarea noilor funcţiuni
- testarea regresiei
- testarea integrării
- testarea sistemului
În faza de testare a subrutinelor unităţilor se execută testarea subrutinelor, cea
mai de jos formă de testare, în timpul scrierii programului. Programatorii testează o
subrutină terminată pentru a vedea dacă ea îndeplineşte funcţia aşteptată.
Testarea unităţilor reprezintă testarea modulelor complete sau a programelor
mici care, în mod normal, au între 100 şi 1000 de linii de cod. Cu toate că testarea
unităţilor este adesea efectuată informal, este faza unde începe planificarea testului şi
construirea cazurilor de test.
 Testarea noilor funcţiuni valideazǎ noile caracteristici care au fost adăugate la
pachetul software. Folosită adesea în conjuncţie cu testarea regresivă, testarea noilor
funcţiuni este utilizată în mod comun când aplicaţiile existente încep să fie actualizate şi
modificate.
Testarea regresivă este utilizată pentru a se asigura că funcţiile existente ale
unui produs software nu au fost alterate accidental prin adăugarea de noi caracteristici
software. În timp ce programul software se dezvoltă, testarea regresivă devine una
dintre cele mai importante şi întinse forme ale testării deoarece librăria cazurilor de test
disponibile de la lansarea anterioară continuă să crească.
Testarea integrării se concentrează pe testarea grupurilor de module, programe,
aplicaţii sau sisteme pe care programatorii le combină pentru a forma un sistem mai
mare. Ea se bazeazǎ pe testarea interoperabilităţii dintre elementele integrate în produsul
software.
Testarea sistemului implică testarea sistemului ca un întreg. Este executată de
dezvoltatorii de software şi de obicei este ultima formă de testare internă înainte ca
persoanele care cumpǎrǎ produsul să fie implicate în testarea câmpurilor, testarea beta.
Fazele testării specializate apar mai puţin frecvent decât fazele testării generale
şi sunt mult mai comune pentru programele software cu criterii foarte bine specificate.
Următoarele faze sunt considerate ca fiind fazele testarării software specializate:
- testarea stresului, capacităţii sau încărcării
- testarea supravieţuirii/ tratării erorilor
- testarea recuperării
- testarea securităţii
- testarea platformei
- testarea protecţiei virale
Testarea stresului, capacităţii sau încărcării apreciază abilitatea unei aplicaţii
sau unui sistem de a funcţiona aproape sau dincolo de limitele capacităţilor sau
cerinţelor specificate. Faza de testare a stresului, încărcării sau capacităţii este adesea
considerată sinonimă cu faza de testare a performanţei.
 Testarea stresului încearcă să întrerupă sistemul prin supraîncărcarea lui cu
volume mari de date. Este de obicei realizată de dezvoltatorul de software după, sau în
conjuncţie cu, testarea integrării sau sistemului. Testarea stresului nu este realizată mai
devreme deoarece întreaga aplicaţie este de obicei necesară.
Testarea supravieţuirii / tratării erorilor evaluează abilitatea produsului
software de a prelucra corect tranzacţiile incorecte şi de a depăşi condiţiile de eroare
într-o manieră rezonabilă.
Testarea recuperării estimează abilitatea produsului software de a restarta
operaţiile după ce integritatea aplicaţiei a fost pierdută.
Testarea securităţii este utilizată pentru a evalua dacă un produs software
previne în mod corespunzător accesul nepotrivit la informaţie.
Testarea securităţii este de obicei realizată înainte şi după ce produsul a fost
lansat prin testare personală sau prin consultanţi extrem de specializaţi angajaţi de
utilizator [PERRY95].
Testarea performanţei este utilizată pentru a determina dacă o aplicaţie
împlineşte propriile scopuri de performanţă [JONE97]. În mod tipic faza de testare a
performanţei este executată de dezvoltatorul de software în timpul, sau în conjuncţie cu,
testarea sistemului. Evaluarea performanţelor sunt standarde pe care alte măsuri le
adreseazǎ şi sunt utilizate pentru a furniza analize competitive, informaţii pe care
personalul de la marketing şi vânzări le utilizeazǎ pentru a da consumatorilor măsuri ale
calităţii produsului software relativ la alte produse [WILS95].
Consumatorii utilizează marketingul evaluării performanţelor pentru a compara
performanţele înainte de a cumpăra, în timp ce proiectanţii şi arhitecţii de sisteme
utilizează evaluarea performanţelor tehnice pentru a caracteriza performanţa înainte de
fabricaţie[WILS95].
Testarea platformei, cunoscută şi sub numele de faza de testarea a
compatibilităţii, evaluează abilitatea programului software de a opera pe mai multe
platforme harware sau pe mai multe sisteme de operare sau în interconexiune cu mai
multe produse software [JONE97].
 Majoritatea dezvoltatorilor de software comercial în mod specific dirijează
testarea protecţiei virale către asigurarea ca primele copii ale pachetelor software să nu
conţină virusuri [JONE97].
Fazele testării prin implicarea utilizatorilor
Pentru multe proiecte software, utilizatorii şi consultanţii lor sunt participanţi
activi la diferitele faze de-a lungul procesului de dezvoltare software, incluzând diferite
faze ale testării.
Utilizatorii participă în general la următoarele testări:
- testarea utilităţii
- testarea beta
- testarea alfa
- testarea acceptării
Testarea utilităţii, cunoscută şi ca testarea factorilor umani, este directată către
identificarea operaţiilor care sunt dificile sau incomode pentru utilizatori. Testarea
utilităţii este în general realizată înainte de testarea beta. Ea implică observarea
clienţilor actuali care utilizează produsul software sub situaţii controlate sau
instrumentate.
Testarea beta este un test extern ce implică cumpărătorii. Testarea beta se face
în mod uzual după testarea sistemului.
Testarea beta (externă) şi testarea utilităţii (internă) se fac concurent. Testarea
beta cuprinde înţelegeri speciale cu clienţii pentru a evita riscul proceselor dacă
produsul software are probleme serioase [JONE97].
Următoarele două activităţi de testare sunt asociate cu, sau au scopuri similare
cu, testarea pe teren.
Activitǎţile pentru testarea alfa sunt utilizate în mod propriu când sunt implicate
laboratoare specializate pentru a construi produse hardware/software complexe noi pe
care viitori clienţi le testeazǎ.
Cumpărătorii testează aceste produse sub condiţii controlate înainte de a avea
aceste sisteme software instalate pe propriile lor calculatoare.
 Dezvoltatorii de software care construiesc sisteme de software complexe
utilizează în primul rând testarea în laborator.
În aceste cazuri testarea beta este imposibilă datorită constrângerilor de
hardware şi software.
Testarea acceptării este utilizatǎ pentru a determina dacă un produs satisface
criteriul de acceptare predefinit. Este o combinaţie de alte tipuri de testări pentru a
demonstra dacă produsul satisface cerinţele utilizatorului.
Testul acceptării cumpărătorului este în mod normal realizat pentru programele
software realizate prin contract şi pentru sistemele software foarte mari, dar el este
foarte rar utilizat în volumul ridicat ale produselor software comerciale.
Uneori testările alfa şi beta sunt considerate ca fiind parte ale testării acceptării
[JONE97], [KIT95].

GENERATOARE DE DATE DE TEST

Generatoarele de seturi de date de test sunt programe. Dacǎ aplicaţia lucreazǎ

cu matrice, generatorul de date de test genererazǎ matricea. Dacǎ aplicaţia software
lucreazǎ cu fişiere, generatorul de seturi de date de test creeazǎ fişierul.
Generatoare de matrice au ca intrǎri:
- numǎrul de linii şi numǎrul de coloane;
- tipul de matrice (oarecare, simetricǎ, bandǎ, rarǎ, triunghiularǎ, diagonalǎ,
unitate);
- intervalul de apartenenţǎ al elementelor.
Se genereazǎ numere pseudo-aleatoare apaţinând intervalului şi se atribuie
conform tipului de matrice specificat

Pentru generarea fişierelor de test se parcurg etapele, figura 3:

- se citeşte numele fişierului;
- se descrie structura articolului;
 - se dǎ tipul câmpurilor din articol;
- se definesc restricţiile asupra valorilor câmpurilor din articol (litere mari,
litere mici, limita inferioarǎ, limita superioarǎ);
- se specificǎ numǎrul de articole;
- se genereazǎ valori pentru câmpurile articolului;
- se scrie articolul în fişier;
- se repetǎ pentru numǎrul de articole.

Se citeşte
nume fişier

Tip
Se descrie
articol
Restricţii

Se citeşte nr. de
articole

Se genereazǎ
articol

Se scrie articol
în fişier

NU Se verificǎ dacǎ
s-au generat toate

DA

Figura 3. Etapele generǎrii fişierelor de test

Generatoarele definite îşi dovedesc utilitatea pentru programatorii care doresc sǎ

testeze independent modulele.
 În funcţie de fiecare aplicaţie informaticǎ în parte costurile asociate fazelor
specifice de dezvoltare software variazǎ.
Costurile testǎrii în [JONE86] sunt împǎrţite în:
- costuri de pregǎtire ce includ: scrierea cazurilor de test, încǎrcarea cazurilor
de test într-o bibliotecǎ şi pregǎtirea scenariilor de test;
- costuri de execuţie care include: rularea şcenariilor de test şi scrierea
rapoartelor pentru erorile descoperite în timpul testǎrii.
În [IVAN99] costul testǎrii presupune cheltuieli pentru:
- resursele consumate;
- personalul specializat ce includ salariile şi cheltuieli cu instruirea;
- echipamentele de asistare a testǎrii.
Ponderea cea mai mare din totalul cheltuielilor pentru testare o au cheltuielile cu
personalul. Pentru aplicaţii informatice distribuite este necesarǎ specializarea
personalului.
Personalul este împǎrţit în echipe în care fiecare membru are sarcini precise.
Sarcinile echipei de testare sunt urmǎtoarele:
- definirea obiectivelor testǎrii;
- colectarea şi construirea cazurilor de test;
- construirea arhivei pentru compararea comportamentului produsului
software şi definirea corectǎ a contextului plasǎrii produsului de test;
- definirea specificaţiilor de testare prin extragerea din specificaţiile
produsului a elementelor cheie în procesul de testare;
- alegerea tehnicii adecvate de testare în raport cu obiectivele urmǎrite;
- structurarea în etape a procesului de testare;
- lansarea produsului în execuţie;
- compararea comportamentului real al produsului software în raport cu
comportamentul definit în specificaţii;
- elaborarea raportului de testare ce constituie baza certificǎrii sau respingerii
produsului.
Rolul testǎrii asistate este de a se testa concordanţa dintre specificaţiile
programului şi ceea ce face programul.
Cheltuielile de asistare includ:
- cheltuieli pentru întreţinerea echipamentelor şi instrumentelor de asistare;
- cheltuieli cu instruirea în vederea utilizǎrii echipamentelor şi instrumentelor;
- cheltuieli pentru analiza comportamentului produsului software în baza
datelor de test generate sau a rezultatelor testǎrii din faze anterioare.
Prin creşterea automatizǎrii testǎrii, în momentul achiziţionǎrii instrumentelor se
înregistreazǎ cheltuieli mai mari pe o perioadǎ dar care se amortizeazǎ rapid prin
scǎderea perioadei necesare realizǎrii anumitor teste.
Automatizarea devine eficientǎ dacǎ se respectǎ etapele ce trebuie urmate pentru
trecerea de la testarea manualǎ la cea automatǎ.
Cheltuielile pentru achiziţionarea de consumabile utilizate pentru elaborarea
sistematizatǎ a documentaţiei intrǎ în categoria cheltuielilor indirecte.
Testarea include şi elemente de consultanţǎ specializatǎ din domenii
complementare ariei de cuprindere pentru care sunt specializaţi membrii echipei de
testare. În anumite situaţii aceste cheltuieli de consultanţǎ devin destul de ridicate.
Durata testǎrii, resursele angrenate în testare şi rezultatele obţinute în urma
procesului de testare depind de complexitatea produsului software.
Modul de obţinere al costului efectiv de testare Cef este dat de relaţia:
Cef = Cp + Ce + Cia + Ca
unde:
Cp – reprezintǎ cheltuielile cu personalul
Ce – reprezintǎ cheltuielile cu echipamentele
Cia – reprezintǎ cheltuielile cu instrumentele de asistare
Ca – reprezintǎ alte cheltuieli
Deoarece testarea este un proces iterativ şi costurile testǎrii se înregistreazǎ
pentru fiecare iteraţie în parte, costul total al testǎrii CTT este dat de expresia:
n
CTT = ∑ CTi
i =1

unde:
 CTi – reprezintǎ costul testǎrii la iteraţia i
n – este numǎrul total de iteraţii
Eficienţa echipei de testare ef este datǎ de raportul:
1
ef =
n
unde n reprezintǎ lungimea procesului de testare ca numǎr de iteraţii.
Pentru fiecare echipǎ este necesar sǎ se înregistreze consumuri de performanţǎ
pentru a putea obţine în timp util baza de date solicitatǎ în procesul de estimare a
coeficienţilor pentru modelele testǎrii.