UNIVERSITATEA DIN CRAIOVA

FACULTATEA DE AUTOMATIC, CALCULATOARE I ELECTRONIC

DEPARTAMENTUL DE AUTOMATIC I ELECTRONIC

REFERAT TESTARE SOFTWARE

STUDENT: BIVOLARIU Alina tefania
GRUPA: 10116 SAI

CRAIOVA, 2017

I. Ciclul de viata in procesul de testare

(Software Development Life Cycle SDLC)
1. Introducere

Testarea produselor software este un proces sau o serie de procese, menite s asigure ca
atunci cnd se execut un cod de program s fac ceea ce trebuie s fac i nimic altceva.
Produsul software trebuie s fie predictibil i consistent, s nu ofere nici o supriz unui utilizator.
Testarea software este uoar, n anumite metode, datorit faptului c multitudinea de
produse software i sisteme de operare sunt mult mai sofisticate dect niciodat, furniznd rutine
intrinsece bine testate care pot fi incorporate n aplicaie fr ajutorului unui programator care s
le construiasc de la nceput. Interfeele grafice (GUI), de exemplu, pot fi construite dintr-o
librrie a limbajului de dezvoltare i, dac aceastea sunt obiecte preprogramate care au fost
testate i corectate anterior, nevoia de a testa aceast parte a unei aplicaii personalizate este mult
mai redus.
Cu ct complexitatea dezvoltrii programelelor software a crescut, cu att cererile de
inginerie software, tehnologie informaional i calitate profesonial a unui software au crescut.
Se ateapt s se verifice dac programul software opereaz n concordan cu ceea a fost
proiectat s fac i s se descopere potenialele probleme care nu au fost anticipate n planul
proiectrii software-ului.
Grupurile de test sunt ateptate s ofere o continu evaluare a strii curente al unui
proiect aflat sub dezvoltare. La orice moment, ei trebuie s fie pregtii s raporteze detalii
explicite despre starea i acoperirea testului, precum i erori nerezolvate. Pe lng asta, testerii
sunt de ateptat s acioneze n calitate de nlocuitori ai utilizatorilor. Aceasta implic s
anticipeze probleme de utilizare cnd mai curnd posibil n procesul de dezvoltare pentru ca
problemele s fie rezolvate n timp util.

n anii anterior, pe sisteme mainframe, muli utilizatori erau conectai la un sistem

central. Rezolvarea de erori implica updatarea programului stocat central. Aceasta rezolvare
singur urma s servesc la sute de mii de utilizatori ai sistemului.
Pe msur ce calculatoarele au devenit mai descentralizate, minicomputerele i
microcomputerele erau utilizate ca sisteme de sine stttor sau pe reea mai mic. Erau multe
calculatoare independente sau reele locale i o rezolvare la un cod de program pe unul din acele
calculatoare nu era benefic dect pentru civa utilizatori. Companiile software de consum
cheltuiau cteodat milioane de dolari trimind dischete la clienii nregistrai pentru a rezolva
un defect serios.
Pe msur ce piaa a devenit mai accesibil, mult lume utilizeaz calculatorul pentru
multe lucruri, se bazeaz mult pe un calculator, i consecinele de defecte software cresc an de
an. Este imposibil s se gseasc toate problemele posibile doar testnd programul, dar cu ct
costul unei greeli a crescut, a devenit mai esenial s se fac un test pe baz de risc. ntr-o
abordare bazat pe risc, se pun urmtoarele ntrebri:
- Care zone ale produsului sunt semnificative pentru client sau care sunt predispuse la un eec
serios ca acestea s fie testate cu mare grij?
- Ct de mult testare este nevoie pentru anumite seciuni de program i pentru tot programul?
- Care este riscul implicat n lsarea unei anumite erori nerezolvate?
- Sunt anumite componente att de neimportante n ct s nu merite testate?
- n ce punct un produs poate fi considerat testat adecvat i pregtit pentru lansare?
- Ct de mult un produs poate fi amnat pentru testare i rezolvarea erorilor nainte ca viabilitatea
pieei s diminueze ntoarcerea investiiei?
Urmrirea erorilor i asignarea importanei lor sunt prioritare. Echipa de management
ateapt ca echipele de IT i dezvoltare, de testare i asigurarea calitii s ofere date cantitative
despre testele executate, starea defectelor nerezolvate i potenialul impact asupra amnarii
anumitor defecte. Pentru a ndeplini aceste condiii, cei care testeaz trebuie s neleag
produsul i tehnologia folosit. Ei au nevoie de modele pentru a comunica evaluri de ct de
multe testri au fost fcute pentru un anumit produs, pna la ce punct va ajunge testarea i n ce

moment produsul va fi considerat testat adecvat. Avnd informaiile din teste, se vor face
predicii despre riscul calitii.
n era internetului, conectivitatea ntre calculatoare a crescut. Calculatoarele personale
sunt conectate la internet. Rezolvri de erori i pachete de actualizri sunt disponibile, pe
ntreaga durata a unei zile, pentru descrcarea imediat din Internet. Caracteristicile care nu sunt
disponibile n momentul lansrii unui produs software sunt fcute disponibile mai trziu sub
forma de pachet de serviciu (service packs).
Cu toate c Internetul ofer conectivitate pentru calculatoare, acesta nu ofer i controlul
asupra mediului clientului care era disponibil n modelul mainframe. Provocrile dezvoltrii i
testrii cu interfaa grafic (GUI) i procesele pe baz de evenimente sunt enorme deoarece
clientul ncearc comenzi complexe remarcabile pe sistemele de operare diferite. Exist o
mulime nenumrabil de combinaii de procesoare, periferice i aplicaii software. Adiional,
testarea unui sistem client-server pentru ntrepindere poate necesita o mulime de mii de
combinaii de sisteme de operare, modemuri, routere i pachete software pentru servere.

Testarea software are rol proeminent n procesul de dezvoltare al unui produs software
mai mult dect acum muli ani. Companiile aloc mai muli bani i resurse pentru testare pentru
c ele consider c reputaia lor const n calitatea produselor lor.
Fiecare proiect trebuie s conin un plan amplu de testare care s cuprind toate
funcionalitile aplicaiei i s asigure funcionarea corect a ntregului produs. Strategiile de
testare se concentreaz pe funcionalitatea i utilizabilitatea produsului.
Exist cteva reguli care sunt considerate ca obiective ale testrii:
- testarea este un proces de execuie a unui program cu intenia de a gsi o eroare;
- un caz de test bun este unul care are probabilitate mare de a gsi o eroare nedescoperit nc;
- un test terminat cu succes este un test n care se descoper o eroare nedescoperit nc.
Metodele de verificare a corectitudinii unui produs se mpart n dou mari grupuri:
- metode statice de testare: constau n analiza unui program nainte de a fi lansat n execuie,
independent de datele de intrare;
- metode dinamice de testare: constau n execuia programului; aceast metod este cunoscut i
sub numele de testare structural.
Dintre cele mai familiare metode statice se amintesc: testarea specificaiei i examinarea
codului.
La examinarea codului este inclus i compilarea. Un compilator modern verific tot felul
de proprieti ale programului, i refuz programele care nu respect criteriile de corectitudine.
Alteori compilatorul d avertismente asupra unor construcii care genereaz probleme la
execuie, cum ar fi de pild variabile neiniializate.
Testarea sistemelor informatice complexe presupune testarea pe componente i pri ale
componentelor (funcii sau clase), dup un plan de test ce cuprinde toate cazurile de test. n
sistemele complexe componentele sunt strns legate ntre ele, iar funcionalitatea unui modul
este dependent de alte module i atunci testarea se complic.

n cazul testrii unui modul ce este dependent de informaiile din alte module se practic
scrierea diferitelor date de test n baza de date pentru a testa toate cazurile posibile i rezultatul
acestor teste se scrie n fiiere de log sau n baza de date.
Pentru un grup de module ce formeaz un subsistem se va descompune acest subsistem n
funcii si module, pentru a se putea realiza testarea prezent. Se testeaz mai nti funciile apoi
modulele i din aproape n aproape se agreg modulele i se obine testarea produsului finit.

2. Definitii ale SDCL

Procese sau metodologii diverse, selectate pentru dezvoltarea unui proiect n funcie de
obiectivele acestuia;

Mediu care descrie activitile realizate n cadrul fiecrei etape a procesului de dezvoltare
software

Plan detaliat, care descrie modul n care se va realiza dezvoltarea, ntreinerea i

nlocuirea software-ului specific (proces de dezvoltare software)

Standardul internaional SDLC ISO/IEC 12207

3. Ciclul de viata al produselor informatice

Ingineria a fost dintotdeauna preocupata de folosirea economica a resurselor limitate in
vederea satisfacerii utilizatorului. Fundamental pentru ingineria sistemelor informatice este
intelegerea procesului ciclului de viata al unui sistem/produs.
Ciclul de viata incepe prin identificarea unei nevoi si este extins prin proiectarea conceptuala
si preliminara, proiectarea de detaliu si dezvoltare, productie si/sau constructie, utilizarea
produsului si se termina cu retragerea produsului de pe piata.

 Ciclul de viata al unui produs: perioada de timp intre momentul aparitiei cererii prin care se
solicita realizarea unui produs si momentul scoaterii lui din exploatare.
Ciclul de realizare al unui produs: partea din ciclul de viata al unui produs in cadrul careia se
realizeaza respectivul produs.
Produs informatic: denumire generica prin care se refera sistemul informatic, o aplicatie
informatica sau produsul program.
Aplicatie informatica: utilizarea calculatorului in rezolvarea unui grup omogen de probleme
ale unui utilizator individual printre care distingem:
- aplicatii de gestiune;
- aplicatii stiintifice;
- aplicatii de birotica.
Produs program: sistem complet si documentat de programe, livrabil unui grup de utilizatori
care reprezinta:
- implementarea uneia sau mai multor aplicatii informatice la utilizatorii din grup;
- suportul de realizare si exploatare a produselor program aplicative de uz general sau dedicat.
Sistem informatic: ansamblu constituit din urmatoarele tipuri de elemente:
- echipamente, care pot fi: unul sau mai multe calculatoare, memorii, periferice;
- software compus din: soft de baza, soft de gestionare a bazelor de date, soft de aplicatie;
- personal de exploatare, utilizatori de specialitate pentru intretinere;

- organizarea activitatilor de pregatire a mediului de achizitiea datelor, de supraveghere a

exploatarii si intretinerii sistemului.

Componentele sistemului informatic [J. Schwarze, Einfuhrung in die Wirtschaftsinformatik, 1997]

4. Etape ale SDCL

 Analiza preliminara
Analiza preliminara este etapa in care sunt identificate nevoile si asteptarile pe care o
persoana le are cu privire la produsul software. Trebuie stabilit ce implica realizarea unui
asemenea produs, cum va putea fi utilizat si de ce resurse va fi nevoie. Dupa care se realizeaza
un plan de implementare bazat pe diagnosticul stabilit.

Dezvoltare si proiectare
E un lucru stiut ca, desi unele produse software pleaca de la premise dj existente,
acestea trebuie adaptate conform unor cerinte specifice. In aceasta etapa se va crea un document
cu specificatiile functionale ale produsului care va contine functionalitatea propriu-zisa,
importanta, impartirea pe categorii, interfata, utilizabilitatea. Functionalitatea propriu-zisa se
refera la operativitate (web, mobil, BackOffice, FrontOffice, interfata ERP, End User), rapoarte
precum si la configurare. In aceasta etapa se vor defasura activitati de programare si testare pe
baza documentului cu specificatii. Activitatile de programare presupun cunoasterea unor limbaje
de programare web sau de nivel inalt in functie de produsul software. Inainte de desfasurarea
efectiva a acestor activitati de programare se vor stabili cunostintele necesare realizarii si se va
conveni ce limbaje vor fi utilizate.

Instalare si evaluare
In aceasta etapa se desfasoara activitati care sa pemrita produsului software sa devina
operational. Aceste activitati pot presupune: - Instalarea unui mediu de lucru - Instalarea unei
aplicatii mobile - Instalarea unei aplicatii BackOffice - Instalarea unor component de integrare si
interfatare - Instalarea unei baze de date - Migrarea de fisiere, date si informatii - Traininguri
pentru utilizarea anumitor componente
Pentru a putea fi evaluata functionalitatea se vor face teste cu utilizatorii cheie ai produsului
software sau cu potentiali utilizatori. Acestia vor avea posibilitatea sa raporteze
disfunctionalitatile, erorile si eventualele sectiuni carora li se mai pot aduce imbunatatiri.

 Mentenanta si suport
Aceasta etapa finala presupune finalizarea dezvoltarii produsului software prin predarea
documentatiei, solutionarea disfunctionalitatilor sesizate in etapa anterioara, sesiuni de training
cu viitori utilizatori sau realizarea de tutoriale pentru a creste gradul de accesibilitate al
produsului. De asemenea, dezvoltatorii unui produs software vor oferi suport celor care il
utilizeaza de-a lungul timpului pentru a asigura buna sa functionare si a repara eventualele erori
aparute. In plus, este posibila imbunatatirea unui produs software, caz in care documentatia
originala va fi necesara.

Verificarea si intretinerea produselor software

Verificarea presupune actul de a stabili si documenta faptul ca articolele, procesele, serviciile sau
documentele sunt in conformitate cu cerintele specificate. Activitatile de verificare includ:

Revizii (Reviews)

Urmarire (tracing)

Demonstratii formale

Testare

5. Variatiile ciclului de viata al produselor software

Ciclul de viata poate diferii in functie de:

experienta, abilitatile si cunostintele membrilor echipei de dezvoltare

gradul de cunoastere a sistemului obiect

domeniul aplicatiei

schimbarile mediului exterior sistemului

schimbarile din interiorul sistemului dimensiunea proiectului

II. Modele ale procesului de dezvoltare

software

Un proces de dezvoltare a programelor se bazeaz pe o formalizare a activitilor

specifice, la care ne-am referit. Scopul formalizrii este obinerea unui ansamblu de mecanisme
care, n cazul n care sunt aplicate sistematic permit obinerea ntr-un mod repetitiv i fiabil de
produse software de calitate constant. Descrierea procesului rmne general, pentru c nu este
posibil s se defineasc un standard unic adaptat la toate tipurile de aplicaii i la toate
persoanele.
Dezvoltarea unui program poate fi vzut ca stabilirea unui ir de descrieri din ce n ce
mai precise i din ce n ce mai apropiate de un program executabil i de documentaia sa.
Trecerile de la o descriere la alta sunt deseori numite rafinri succesive. Aceasta este o vedere
simplificat, pentru ca nu ia n considerare natura iterativ a procesului de dezvoltare.
O dat dezvoltat un program, este pus n exploatare. Se pun atunci probleme de
ntreinere, de corectare a defectelor, de ameliorare a anumitor caracteristici sau de urmrire a
evoluiei cerinelor. Intreinerea poate impune modificarea funciilor sistemului i deci, un
proces de redezvoltare. Din aceasta cauz se vorbete despre ciclul de via al unui program,
cnd considerm exploatarea i ntreinerea n plus fa de dezvoltare.
Ce este ciclul de viata al unui program (Software life cycle)?

O secventa de etape in existenta produsului software. Sunt incluse toate activitatile

necesare pentru dezvoltarea produsului si relatiile temporale dintre ele.

Fiecare etapa din ciclul de viata este caracterizata prin activitati specifice si
produsele rezultate din activitatile respective.

Modele ale ciclului de viata software (Software development life cycle models or process
models):

Waterfall model (Modelul cascada)

V model (modelul in V)

ESA ( European Space Agency) model

Incremental model (Modelul iterativ si incremental)

Dezvoltarea agila

Prototyping (Dezv pe baza de prototip)

Spiral model (Modelul in spirala)

Modelul cascada

Numit si modelul clasic al ciclului de viata sau modelul liniar

Descris de Royce n 1970, a fost larg utilizat de atunci, pentru descrierea general a
procesului de dezvoltarea programelor.

Ciclul de via n cascad prezint dezvoltarea unui program ca o succesiune de faze ce se

nlnuie ntr-o derulare liniar, de la analiza cerinelor i pn la livrarea produsului ctre
client.

Fiecare faz corespunde unei activiti i trebuie s se termine la o anumit dat prin
producerea anumitor documente sau programe.

Rezultatele fazei sunt supuse unei revizii aprofundate i nu se trece la faza urmtoare dect
atunci cnd sunt considerate satisfctoare.

In prima sa versiune, modelul avea numai sgei descendente, care materializeaz nlnuirea
etapelor; el nu prevedea iteraii. Sgeile ascendente au fost adugate mai trziu pentru a
ilustra principiul c o etap repune n discuie numai etapa precedent.

Limitele modelului n cascad

Modelul n cascad se bazeaz pe o secven de faze bine delimitate. Documentele produse

de fiecare faz sunt evaluate n cadrul reviziilor care valideaz trecerea de la o faz la alta.
Din pcate, proba efectiv a bunei sau a proastei functionri a sistemului este realizat numai
n cadrul fazei de integrare, cnd este posibil evaluarea concret a programului. Inaintea
acestei faze au fost produse numai documente.

Abordarea n cascad d rezultate satisfctoare numai n cazul n care este efectiv posibil
nlnuirea fazelor fr prea multe probleme. Aceasta presupune ca ansamblul cerinelor s
fie perfect cunoscut i problema complet nteleas de analiti. Trebuie de asemenea ca soluia
s fie uor de determinat de proiectani i codificarea simpl - redus ideal la generarea
automat a codului plecnd de la documentele de proiectare.

In realitate se constat c partea de necunoscut poate fi nsemnat n anumite dezvoltri, n

special datorit:
- nenelegerii cerinelor de ctre client sau analist;
- instabilitii cerinelor;
-alegerilor tehnologice;
-schimbrilor de personal.

Din toate aceste motive sunt necesare reveniri n etape anterioare ale procesului de
dezvoltare. Aceste reveniri sunt de fapt o reflectare a realitii. Dac aceste reveniri sunt
ocazionale i limitate la faze adiacente, modelul n cascad este pertinent. In caz contrar,
modelul n cascad nu corespunde realitii.

Avantaje:
1. Sistemul este bine documentat
2. Permite un bun management al proiectului:

planificarea resurselor umane pe etape

estimari de cost mai exacte

Dezavantaje:
1. Un produs executabil, care sa demonstreze functionarea sistemului este disponibil destul
de tarziu, dupa integrare. Pana atunci s-au produs numai documente.
2. Deoarece modelul este secvential, exista numai uhn feedback local, la tranzitiile intre
faze.
3. Multe erori sunt descoperite tarziu cost crescut

4. Toate riscurile sunt incluse intr-un singur ciclu de dezvoltare

Adecvat pentru proiectele in care cerintele sunt bine intelese de la inceput si nu se modifica pe
parcursul procesului de dezvoltare.
Experienta ultimelor decenii a demonstrat ca modelul este valoros.
Este utilizat si in prezent de multe organizatii mari.

Modelul in V

Este o varianta a modelului cascada, care pune in evidenta corelarea dintre activitatile de
specificare si cele de testare, inlantuirea in timp a activitatilor fiind aceeasi.

Partea din stanga reprezinta lantul de specificare a sistemului iar cea din dreapta lantul de testare.
Partea de jos a v-ului reprezinta implementarea

In acest model exist dou tipuri de dependene ntre etape:

-cele reprezentate prin liniile care formeaza V-ul, care corespund nlanuirii i eventualei

iteraii din modelul cascad; etapele se deruleaz deci secvenial, urmnd V-ul de la stnga la
dreapta;
-cele reprezentate prin linii orizontale, care indic faptul c o parte din rezultatele etapei
din care pleac sgeata sunt utilizate direct n etapa int. De exemplu, la terminarea etapei de
proiectare arhitectural, cazurile de teste de integrare trebuie s fie complet descrise.

Prototiparea
Pentru sisteme noi, n mod special dac ele sunt mari i complexe este puin probabil s
se construiasc o specificaie complet, logic i valid nainte ca sistemul sa fie construit i
utilizat. Acest fapt a condus la ideea prototiprii. Ideea este de a permite viitorilor utilizatori s
exerseze cu o prim versiune a sistemului, care poate fi obinut rapid prin tehnici de simulare
i/sau de interpretare a specificaiilor. In acest ultim caz, limbajele logico-funcionale sunt n
mod sigur chemate s joace un rol important.
Prototipul este o schi a viitorului sistem: el nu are performanele i nu rspunde
exigenelor de calitate ale unui produs finit. Prototipul ofer clientului functionaliti (nu n
totalitate) ale viitorului sistem i interfaa sa utilizator. El este dezvoltat ntr-o manier iterativ.
Cerinele sunt extrase i validate iterativ prin utilizarea prototipului. In fiecare iteraie
specificaia sistemului este modificat i detaliat pn cnd prototipul satisface necesitile
utilizatorilor.
Un prototip care este utilizat pentru a desprinde cerinele viitorilor utilizatori, este o "machet
exploratoare".
Activitatea de prototipare poate interveni de asemenea n etapa de proiectare, pentru a
experimenta i compara diferite variante. Astfel de prototipuri se numesc "machete
experimentale".
Figura urmtoare red procesul de prototipare dedicat extragerii cerinelor:

Pentru dezvoltarea prototipului se folosesc limbaje de nivel foarte nalt: Smalltalk,

PROLOG, LISP, SETL i altele. In prezent exist limbaje i medii de dezvoltare specializate
pentru construirea prototipurilor. Astfel de limbaje sunt limbajele de generaia a 4-a (4GL).
Cu toate c se poate folosi acelai limbaj de programare, att

pentru realizarea

prototipului ct i pentru dezvoltarea aplicaiei, se recomand ca prototipul s fie considerat un

sistem "nchis", adic s nu fie folosit ca baz pentru dezvoltarea aplicaiei. Aceasta deoarece:
- prototipul a fost dezvoltat prin modificri succesive, de aceea arhitectura sa iniial a
fost alterat, ceea ce ngreuneaz ntreinerea;
- prototipul trebuie s corespund cerinelor utilizatorilor numai din punct de vedere funcional.
De aceea, n dezvoltarea sa sunt neglijate aspecte ca: eficiena, adaptabilitatea, compatibilitatea i
chiar fiabilitatea.

III. III.Concluzii
Fiecare etap a ciclului de viata al testarii 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.

Bibliografie
[1] http://en.wikipedia.org/wiki/Boundary_value_analysis
[2] http://www.aptest.com/testtypes.html
[3] http://www.softwaretestinghelp.com/types-of-software-testing/
[4] http://www.buzzle.com/articles/types-of-software-testing.html
[5] IEEE Std 829-2008 Standard for Software and System Test Documentation
[6] Matt Heusser Fundamental Strategies in Software Testing
[7] http://en.wikipedia.org/wiki/Verification_and_validation
[8]http://www.fda.gov/RegulatoryInformation/Guidances/ucm126954.htm#_Toc517237945
[9] http://www.fda.gov/RegulatoryInformation/Guidances/ucm126954.htm
[10] http://en.wikipedia.org/wiki/Verification_and_Validation_ (software)
[11] http://www.cs.toronto.edu/~campbell/340/05w/utm/lectures/19-VandV4-up.pdf
[12] Ian Sommerville - Software Engineering
[14] http://en.wikipedia.org/wiki/Software_testing
[15] http://www.softwaretestinghelp.com/application-testing-%E2%80%93-into-the-basics-ofsoftware-testing/
[16] http://www2.sas.com/proceedings/sugi30/141-30.pdf
[17] http://www.softwaretestinggenius.com/articalDetails.php?qry=970
[18] http://www.universalexams.com/category/general-software-testing
[19] http://www.softwaretestinggenius.com/articalDetails?qry=826