Documente Academic
Documente Profesional
Documente Cultură
Coordonator,
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
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
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)
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
Da
CONDIIE?
STOP
Nu
INSTRUCTIUNE
Exemplu:
START
a=2
b=7
STOP
Da
a>b?
Nu
b=b-a
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.
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
Evidenta cosultatii
medicale
administrator
medic
- Diagram de secvent:
sd Vizualizare medici
Persoana
Sistem
Baza de date
- Diagram de activitate:
Vizualizare medici
Cerere vizualizare medici
Mesaj eroare
Nu
Da
Trimite cerere
- 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.
1) Identificarea
obiectivelor
2) Selectarea
intrrii
3) Calcului ieiriii
estimate
4) Pregtrirea mediului de execuie
Mediu de execuie
Program
5) Executarea programului
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:
Intrrile testului
Rezultatele testrii
Precondiiile dateor
Postcondiiile datelor
Sistemul
supus testului
(SUT)
Precondiiile strii
programului
Postcondiiile strii
programului
Intrrile sistemului
User
GUI
Remote GUI
User
GUI
API
GUI
Motorul de
funcionare
Set de
date
GUI
SUT
GUI
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%2051_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]
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
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]
IV.
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
Planificare
Recapitulare
Pregtire
Intlnire
Aplicare
Finalizare
Dec\\
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]
Model checking
Inferena logic
Derivarea de program
3.4.
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}.
{P}S{Q},{Q}T {R}
- se aplic
{P}S ; T {R}
programelor executate secvenial S i T, unde S se execut inaintea lui T.
T:
{y=43}z:=y{z=43},
atunci
Regula consecinei:
P` P,{P}S{Q}, Q Q`
{P`}S{Q`}
{P B}S{P}
, unde P
{P}while B do S done{B P}
corectitudine
total:
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.