Testarea de acceptare

Testarea de acceptare are loc dup ce toate erorile de

interfa descoperite n cadrul testrii de integrare au fost
corectate. De ex., testarea de acceptare poate evalua starea de
pregtire a sistemului pentru desfurare i utilizare.
Testarea de acceptare este o responsabilitate a beneficiarului
sau utilizatorului, ns pot fi implicai i ali membri ai echipei.
Formele tipice ale testrii de acceptare includ urmtoarele:
Testarea de acceptare a utilizatorului - testarea de ctre
reprezentanii utilizatorilor pentru a verifica dac sistemul
satisface cerinele de business.
Testarea de acceptare a funcionalitii - denumit deseori
testarea pregtirii pentru activitate. Aceasta presupune
verificarea dac procesele i procedurile sunt n ordine i
pot asigura utilizarea i stabilitatea sistemului. Activitatea
include:
- Posibilitile de back-up
- Procedurile pentru restabilire dup eecuri
- Instruirea utilizatorilor
- Procedurile de stabilitate
- Procedurile de securitate
Testarea de acceptare a contractului i reglementrilor
- Testarea de acceptare a contractului - uneori criteriile
de acceptare ale unui sistem sunt consemnate n contract.
Testarea se efectueaz nainte de validarea sistemului, pentru
confirmarea respectrii criteriilor solicitate.
- Testarea de acceptare a reglementrilor - n unele
industrii sistemul trebuie s respecte unele standarde
guvernamentale, legale sau de securitate.
Proiectnd i rulnd cazurile Dvs. de test, aplicai mai nti
testele de acceptare. Este important de a vedea dac softul
funcioneaz fundamental, nainte de a turna murdria peste el.
Putei fi surprins de numrul de neajunsuri gsite doar la o
utilizare normal.

Dup ce v-ai asigurat c softul funcioneaz cum este specificat

n circumstane ordinare, este timpul s v punei la btaie
mijloacele josnice, irete i ocoliurile, cu scopul de a depista
neajunsuri ncercnd lucrurile, care ar fora apariia acestora.

Metodologia spiral, propus tot de Boehm, este un alt

exemplu bine cunoscut de metodologie a ingineriei programrii.
Acest model ncearc s rezolve problemele modelului n cascad,
pstrnd avantajele acestuia: planificare, faze bine definite,
produse intermediare. El definete urmtorii pai n dezvoltarea
unui produs:

studiul de fezabilitate;

analiza cerinelor;

proiectarea arhitecturii software;

implementarea.
Modelul n spiral recunoate c problema principal a
dezvoltrii programelor este riscul. Riscul nu mai este eliminat
prin aseriuni de genul: n urma proiectrii am obinut un model
corect al sistemului, ca n modelul cascad. Aici riscul este
acceptat, evaluat i se iau msuri pentru contracararea efectelor
sale negative. Exemple de riscuri:

n timpul unui proces ndelungat de dezvoltare, cerinele

noi ale clientului sunt ignorate;

clientul schimb cerinele;

o firm concurent lanseaz un program rival pe pia;

un dezvoltator/arhitect prsete echipa de dezvoltare;

o echip nu respect un termen de livrare pentru o

anumit component.
n modelul spiral se consider c fiecare pas din dezvoltare
conine o serie de activiti comune:

pregtirea: se identific obiectivele, alternativele,

constrngerile;

gestionarea riscului: analiza i rezolvarea situaiilor de

risc;

activiti de dezvoltare specifice pasului curent (de

exemplu analiza specificaiilor sau scrierea de cod);

planificarea urmtorului stadiu: termenele limit,

resurse umane, revizuirea strii proiectului.

Metodologia spiral cuprinde urmtoarele etape, grupate pe

patru cicluri:

Figura 5. Metodologia spiral

Ciclul 1 Analiza preliminar:

1.
2.
3.
4.
5.
6.

Obiective, alternative, constrngeri

Analiza riscului i prototipul
Conceperea operaiilor
Cerinele i planul ciclului de via
Obiective, alternative, constrngeri
Analiza riscului i prototipul

Ciclul 2 Analiza final:

7.
8.
9.
10.
11.

Simulare, modele, benchmark-uri

Cerine software i validare
Plan de dezvoltare
Obiective, alternative, constrngeri
Analiza riscului i prototipul

Ciclul 3 Proiectarea:
12.
13.
14.
15.

Simulare, modele, benchmark-uri

Proiectarea produsului software, validare i verificare
Integrare i plan de test
Obiective, alternative, constrngeri

16.

Analiza riscului i prototipul operaional

Ciclul 4 Implementarea i testarea:

17.
Simulare, modele, benchmark-uri
18.
Proiectare detaliat
19.
Cod
20.
Integrarea unitilor i testarea acceptrii
21.
Lansarea produsului
Procesul ncepe n centrul spiralei. Fiecare ciclu terminat
reprezint o etap. Pe msur ce spirala este parcurs, produsul
se maturizeaz. Cu fiecare ciclu, sistemul se apropie de soluia
final. Dei este considerat ca un exemplu generic pentru
metodologia ciclic, metoda are i elemente secveniale, puse n
eviden de evoluia constant de la o etap la alta.
Testarea de module
n cadrul testrii de module se realizeaz verificarea celor
mai mici uniti software care pot fi compilate i link-editate
independent. n programarea clasic un modul este un
subprogram (funcie sau procedur). n cadrul programelor
orientate obiect, cea mai mic unitate testabil este clasa.
Testarea de module se concentreaz asupra verificrii
interfeelor modulelor, structurilor de date locale, condiiilor de la
limite, cilor independente i cilor de tratare a erorilor.
Deoarece modulele nu sunt programe de sine stttoare,
este necesar s se construiasc programe sau funcii care s
ajute la testarea de module.
O prim categorie o reprezint programele conductoare
(drivers) care apeleaz modulele supuse testrii cu datele de test
construite i preiau rezultatele execuiei.
O alt categorie este reprezentat de funciile sau
procedurile apelate de ctre modulul de testat. Acestea sunt
substituite cu subprograme care au acelai prototip, ns cu
funcionalitate redus la minim, denumite module vide (stubs).
Modulele vide sunt funcii sau proceduri simple care nu fac nimic
n afara returnrii controlului, sau sunt funcii sau proceduri

complexe, care simuleaz efectul apelrii modulelor reale. n cele

mai multe cazuri, modulele vide simple sunt nepotrivite. Un efort
considerabil este necesar pentru implementarea de module vide
complexe.
Exist multe abordri i strategii care pot fi utilizate:
Strategia analitic care ca i tehnicile risk - based testeaz
ariile cu risc sporit (vezi mai trziu o privire general a tehnicilor
risk - based).
Abordarea model - based ca testarea stohastic care
utilizeaz informaii statistice despre defectele omise (aa ca
sigurana modelelor dezvoltate) i utilizarea (profilul operaional).
Abordarea metodic, ca failure - based (inclusiv ghicirea
erorilor i asaltarea defectelor), check-list based i bazat pe
calitatea caracteristicilor.
Abordarea conform standardelor, stabilite de industria
specific standardelor aa ca The Railway Signaling Standarts
(care stabilete nivelele de testare) sau MISRA (care definete
cum s proiectezi, s construieti i s testezi sigur software
pentru motor industry).
Process compliant approaches (abordarea conform
procesului), care ader la procesul de dezvoltare cu o varietate de
metodologii sau cu strategiile tradiionale cascad.
Abordri dinamice i euristice, ca testarea de explorare (vezi
cap.4), unde testele sunt mai reactive la evenimente dect este
prevzut, i cnd executarea i evaluarea reprezint sarcini
concurente.
Abordarea consultativ, ca acelea unde acoperirea testului
este condus de indicaiile i ghidarea tehnologiei i /sau de
experii din domeniul businessului din echipa de testare sau din
exterior.
Abordarea
regression
averse include reutilizarea
materialele de testare existent, automatizarea vast a testelor
funcionale regresive i a test suitelor standarde.