Ingineria Programarii: Faza de Testare 2

Ingineria programrii
13. Faza de testare (II)
Florin Leon
Universitatea Tehnic Gheorghe Asachi din Iai
Facultatea de Automatic i Calculatoare
http://florinleon.byethost24.com/curs_ip.htm
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
Faza de testare (II)

1. Testarea de nivel nalt
2. Testarea sistemului
3. nregistrarea i urmrirea defectelor
4. Analiza i prevenirea defectelor
5. Testarea extrem
6. Principii de testare
7. Concluzii

5. Testarea extrem
7. Concluzii
Testarea de nivel nalt
Chiar dac s-ar putea realiza

testarea perfect a modulelor, tot
nu s-ar putea garanta lipsa
erorilor
Este nevoie de testarea de nivel nalt
O eroare se manifest atunci

cnd programul nu face ceea ce
se ateapt utilizatorul, n mod
rezonabil, s fac
4
Dezvoltarea
i testarea
1. Nevoile utilizatorilor sunt
transformate n cerine
(scopuri)
2. Cerinele sunt
transformate n obiective
specifice (fezabilitate, cost,
compromisuri, prioriti)
3. Obiectivele sunt
transformate n specificaii
externe (sistemul e vzut ca
o cutie neagr, se iau n
calcul doar interfeele i
interaciunile cu utilizatorul)
5
Dezvoltarea
i testarea
Fiecare faz a procesului de
testare se concentreaz pe
un anumit pas al procesului
de dezvoltare i pe o anumit
clas de erori
La sfritul fiecrei faze
exist un pas separat de
verificare pentru a detecta
ct mai multe erori nainte de
a trece la faza urmtoare (de
exemplu inspecii ale codului)
Corespondene
Scopul testrii modulelor / unitilor este de a

gsi discrepanele dintre modulele programului
i specificaiile interfeelor acestora
Scopul testrii funcionale este de a arta c
programul nu respect specificaiile externe
Scopul testrii sistemului este de a arta c
produsul nu respect obiectivele stabilite iniial
Testarea funcional
Specificaiile externe reprezint o descriere precis a

comportamentului sistemului din perspectiva utilizatorului
Descriu toate intrrile i ieirile posibile ale produsului
Specific toate caracteristicile i combinaiile de caracteristici
Testarea funcional este o activitate de tip cutie neagr
Partiionarea n clase de echivalen
Analiza valorilor limit
Grafurile cauz-efect
Ghicirea erorilor
Se bazeaz pe diagramele cazurilor de utilizare,

diagramele de stri etc.
8
Tipuri de testare funcional
Testarea navigrii utilizatorului
Testarea ecranelor de tranzacii
Testarea fluxurilor de tranzacii
Testarea ecranelor de rapoarte
Testarea fluxurilor de rapoarte
Testarea operaiilor cu bazele de date

(Create/Retrieve/Update/Delete)
Exemplu: dac un raport arat pe ecran ntr-un anumit

mod, trebuie s arate la fel i n forma tiprit
9
Testarea sistemului
Este de obicei cel mai dificil proces de testare

Scopul este compararea comportamentului
sistemului cu obiectivele sale iniiale
ncearc s demonstreze n ce fel sistemul nu i

ndeplinete obiectivele
Testarea sistemului este imposibil dac nu exist
obiective scrise msurabile ale produsului
Nu se refer la testarea funciilor sistemului

complet ( testarea funcional)
10
Proiectarea testelor
Testarea sistemului se
proiecteaz analiznd obiectivele
Cazurile de test se formuleaz
prin analiza documentaiei
utilizatorului
Pentru fiecare linie din enunul

obiectivelor, ar trebui s
demonstreze c produsul nu se
comport corect
Nu exist metodologii de
proiectare a acestor teste
Necesit creativitate
Specificaiile externe corespund

testrii funcionale
11
Exemplu: enun de obiective

pentru comanda display
12

5. Testarea extrem
7. Concluzii
Tipuri de testare a sistemului
Testarea caracteristicilor
Testarea configuraiei
Testarea ncrcrii
Testarea compatibilitii
Testarea la stress
Testarea instalabilitii
Testarea volumului
Testarea ncrederii
Testarea utilizabilitii
Testarea recuperrii
Testarea securitii
Testarea documentaiei
Testarea stocrii
Testarea procedurilor
14
Testarea caracteristicilor
engl. facility testing

Parcurgerea obiectivelor i testarea dac
produsul ndeplinete fiecare obiectiv
Compararea mental a obiectivelor cu
documentaia utilizatorului este deseori
suficient
15
Testarea ncrcrii
engl. load testing

Presupune operarea sistemului n condiii normale sau cu
vrfuri anticipate de sarcin i observarea comportamentului
acestuia
Ajut la identificarea capacitii operaionale maxime a
sistemului
Mediul de test este asemntor cu mediul n care va rula
sistemul n producie
Relevant n special pentru sisteme multi-user, client-server
sau pentru servicii cu SLA (service level agreement)
Util i pentru alte tipuri de produse software: procesoare de
text sau grafice, aplicaii cu generatoare de rapoarte etc.
16
Testarea ncrcrii
Poate ajuta la depistarea cauzelor care scad

performanele, de exemplu:
Servere de aplicaii sau alte componente software

Servere de baze de date
Latena sau congestia reelei
Prelucrrile n partea clientului
Echilibrarea ncrcrii ntre mai multe servere
17
Testarea la stress
Ajut la estimarea robusteii, disponibilitii i modului de

tratare a erorilor printr-o ncrcare dincolo de limitele
normale de operare
Foarte important mai ales pentru sistemele critice
Chiar dac testele simuleaz condiii care nu vor aprea

niciodat, comportamentul sistemului poate da informaii
importante despre erorile care ar putea aprea n situaii
reale de funcionare
18
Testarea la stress motivaie
Defectarea unui sistem critic poate avea consecine dezastruoase

Timpul i resursele dedicate testrii tradiionale nu sunt suficiente
Nu se pot determina toate modurile n care va fi folosit sistemul,
de exemplu un sistem de operare va rula aplicaii care nici nu exist
n momentul testrii
Utilizatorii vor rula sistemul pe calculatoare cu mai puine resurse
dect cele folosite pentru testare
Concurena este dificil de testat cu metode tradiionale, de exemplu
race conditions, deadlocks
Serverele web pot fi supuse atacurilor de tip denial of service
Testarea la stress pentru un timp scurt poate simula operarea
normal pentru un timp ndelungat, de exemplu poate pune n
eviden scurgerile de memorie sau folosirea incorect a resurselor
19
Discuie
Testarea la ncrcare variaz condiiile de operare,

de exemplu numrul de utilizatori, de tranzacii etc.,
meninnd constant configuraia
Numrul de tranzacii cu 2000, 3000, 4000 de utilizatori

concureni
Testarea la stress presupune condiii extreme sau

anormale, de exemplu resurse diminuate sau prelucrri
intense
Numrul de tranzacii cu 2000, 3000, 4000 de utilizatori

concureni, cu memorie foarte puin pe server, vitez mic a
reelei etc.
20
Testarea volumului
Presupune expunerea produsului la un volum mare

de date
Exemple:
Un compilator care primete un fiier surs de 1 MB
Un simulator de circuite electronice care primete un circuit

cu 1000 de componente
Un procesor de test care primete un document cu 2000

de pagini
Scopul este s arate c programul nu poate

gestiona volumul de date specificat n obiective
21
Accepiuni alternative
Testarea la stress implic un element de timp: supunerea

sistemului la o ncrcare foarte mare pentru o perioad scurt
de timp
Aplicabil mai ales pentru programele care opereaz la ncrcri

variabile, interactive, n timp real: aplicaii web, programe de control etc.
Exemple:
Dac un sistem poate gestiona maximum 15 task-uri simultan, testarea

la stress implic rularea a 15 task-uri
Dac un sistem de control al traficului aerian poate gestiona 200 de
avioane simultan, se testeaz cu 200 sau 201 avioane sau se simuleaz
intrarea simultan a unui numr mare de avioane n raza sa de aciune
Pentru un sistem de control al proceselor, toate procesele monitorizate
genereaz semnale simultan
22
Accepiuni alternative
Analogie: evaluarea unei dactilografe
Testarea volumului: dac poate face fa unui

raport de 100 de pagini
Testarea la stress: dac poate scrie la o rat de
50 de cuvinte pe minut
23
engl. usability testing

ncercarea de a descoperi probleme legate de factorul
uman, de utilizarea sistemului
Consideraii:
Interfeele cu utilizatorul trebuie s fie potrivite pentru profilul

acestuia
Ieirile trebuie s fie uor de neles
Mesajele de eroare nu trebuie s reflecte detalii interne de
programare
Interfeele trebuie s aib integritate conceptual, coeren
24
Consideraii:
Cnd acurateea este vital, intrrile trebuie s aib suficient de

multe elemente redundante, de exemplu numr cont, nume
titular, PIN etc.
Sistemul nu trebuie s conin un numr excesiv de opiuni.
Accesarea lor trebuie s fie logic i intuitiv. Se pot prezenta
doar opiunile folosite frecvent
Sistemul trebuie s prezinte notificri pentru primirea intrrilor.
Dac o operaiune este de durat, utilizatorul trebuie informat
Sistemul trebuie s fie uor de folosit. De exemplu, dac intrrile
sunt case-sensitive, utilizatorul trebuie s cunoasc acest lucru,
sau ntr-o succesiune de meniuri sau ferestre, utilizatorul trebuie
s tie cum s se ntoarc la meniul principal
25
Testarea securitii
engl. security testing

Trebuie imaginate cazuri de test care s corup
sistemul de securitate
Se pot studia probleme de securitate cunoscute
ale altor sisteme i se ncearc demonstrarea
existenei lor n sistemul testat
Aplicaiile web necesit n general un nivel
superior de securitate, mai ales site-urile de
comer electronic
26
Testarea stocrii
engl. storage testing

Unele programe au obiective de stocare,
referitoare de exemplu la volumul de memorie
folosit sau la dimensiunea fiierelor temporare
Trebuie imaginate cazuri de test care arat c
programul nu ndeplinete aceste obiective
27
Testarea configuraiei
engl. configuration testing
Sistemele de operare, sistemele de management al bazelor

de date, aplicaiile de transmitere de mesaje/pachete trebuie
s suporte o mulime de configuraii hardware
Dispozitive de intrare-ieire
Linii de comunicaie
Dimensiuni diferite ale memoriei
De multe ori, numrul configuraiilor posibile este prea mare

pentru a fi testat fiecare combinaie n parte
Trebuie testat sistemul cu fiecare tip de dispozitiv hardware i

cu configuraiile minime i maxime
28
Testarea compatibilitii
engl. compatibility testing

Multe sisteme nu sunt complet noi, ci trebuie s
nlocuiasc sisteme mai vechi sau cu probleme
Pot exista obiective specifice privind
compatibilitatea cu sistemele existente, sau
procedurile de conversie a datelor
De exemplu actualizarea unui sistem de management

al bazelor de date
29
Testarea instalabilitii
engl. installability testing

Unele sisteme software au proceduri complicate
de instalare
Instalarea este primul contact al utilizatorului cu
sistemul. O instalare defectuoas l poate
mpiedica s foloseasc n mod adecvat
produsul software, s aib ncredere n el, sau l
poate determina s aleag un alt produs
30
Testarea ncrederii
engl. reliabiliy testing

n general, scopul tuturor tipurilor de testare este creterea
ncrederii
Testarea ncrederii poate fi dificil
Un WAN sau un ISP pot avea ca obiectiv un timp de funcionare de

99,97% (engl. uptime)
Este greu de imaginat cum s-ar putea testa sistemul timp de cteva
luni sau ani
Se poate calcula timpul mediu ntre defectri

Exist metode formale de demonstrare a corectitudinii unui
program. Trebuie demonstrat i c programul se va termina.
n cazul general demonstrarea este imposibil, dar se poate
realiza pentru anumite cazuri particulare
31
Testarea recuperrii
engl. recovery testing

Sistemele de operare, sistemele de management al
bazelor de date, programele de teleprocesare au de
obicei obiective de recuperare, care arat cum trebuie s
reporneasc sistemul dup defeciuni legate de
programare, de hardware sau de date
Testarea presupune crearea (simularea) unor condiii de
eroare n mediul extern de execuie
Testarea i propune s arate c:
Funciile de recuperare nu lucreaz corect

Sistemul nu respect timpul mediu pentru recuperare asumat
32
Testarea documentaiei
engl. documentation testing

Documentaia este folosit ca un ghid pentru
scrierea cazurilor de test la testarea sistemului
Documentaia utilizatorului trebuie s fie
inspectat (ca i codul), analizndu-i-se
acurateea i claritatea
33
Testarea procedurilor
engl. procedure testing

Multe produse software sunt parte a unor
sisteme mai mare, incomplet automatizate, care
implic proceduri urmate de oameni
Toate procedurile trebuie testate, de exemplu
cele pentru operatorii de sistem, administratorul
de baze de date sau utilizatorii finali
34
Executarea testrii sistemului
Cine trebuie s testeze sistemul
Pe ct posibil, nu programatorii
Pe ct posibil, nu organizaia dezvoltatoare
O echip format din: experi n testare, inginer de factori

umani (human factors engineer), 1 sau 2 utilizatori
reprezentativi, analistul sau proiectantul aplicaiei
Aceasta nu are de fapt motivaia s demonstreze c produsul
nu ndeplinete obiectivele
Cel mai economic mod de a realiza testarea sistemului
(gsirea numrului maxim de erori cu un anumit cost sau un
cost mai mic pentru descoperirea aceluiai numr de erori)
este subcontractarea ctre o alt organizaie
vezi i principiile 2 i 3 spre sfritul cursului

35

5. Testarea extrem
7. Concluzii
Ciclul de via al unui defect
De cele mai multe ori, persoana care raporteaz

un defect este diferit de cea care l repar
Un proiect mare poate include mii de defecte
n astfel de situaii, raportarea i repararea

nu pot fi fcute informal: un defect ar putea
fi uitat i/sau redescoperit ulterior cu un efort
suplimentar
37
Formal, cnd un defect este descoperit de ctre oricine este

nregistrat (logged) ntr-un sistem de control al defectelor
Repararea defectului este atribuit unei persoane, de obicei

programatorul iniial, care realizeaz depanarea (debugging)
Defectul este n starea trimis (submitted)
Defectul este n starea reparat (fixed)
Se verific dac defectul a fost reparat cu succes
Defectul este n starea nchis (closed)
38
Ciclul de via poate fi mrit sau micorat n funcie de

natura proiectului
Pentru proiecte mici, un defect poate fi doar deschis

sau nchis
Pentru proiecte critice, un defect poate trece prin mai

multe faze de urmrire
Defectele sunt deseori clasificate, pentru a le nelege

mai bine natura
De exemplu: logic, standarde, interfaa cu utilizatorul,

interfaarea componentelor, performane, documentaie
39
Clasificarea dup severitate
n multe organizaii se folosete o clasificare a

defectelor pe 4 niveluri:
Defecte critice: afecteaz muli utilizatori, pot ntrzia

proiectul
Defecte majore: au un impact puternic, necesit un volum

mare de lucru pentru a le repara, dar nu afecteaz
substanial graficul de lucru al proiectului
Defecte minore: izolate, care se manifest rar i au un

impact minor asupra proiectului
Defecte cosmetice: mici greeli care nu afecteaz

funcionarea corect a produsului software
40
Exemplu: descoperirea i
nchiderea defectelor
n figur, distana dintre numrul

total de defecte i numrul
defectelor nchise crete
Activitatea de dezvoltare trebuie
ncetinit i trebuie alocate mai
multe resurse reparrii defectelor
Pentru un proiect gestionat
corespunztor, numrul de
defecte deschise ar trebui s se
reduc spre sfritul proiectului,
chiar dac nu este obligatoriu ca
variaia s fie monoton
descresctoare
41

5. Testarea extrem
7. Concluzii
Analiza i prevenirea defectelor
La nivel organizaional, analiza defectelor poate

mbunti listele de verificare, procesele sau
instruirea personalului
La nivelul proiectului, se nva din defectele

descoperite pn la un moment dat pentru a preveni
pe ct posibil defectele din restul proiectului
Prevenirea defectelor
Crete calitatea: sistemul final va avea mai puine defecte
Crete productivitatea: se consum mai puin efort pentru

repararea defectelor
43
Analiza Pareto
Se bazeaz pe aa-numita regul 80-20:
80% din probleme vin din 20% din sursele posibile

80% din efecte sunt determinate de 20% din cauze
Pentru un produs software: 80% din defecte apar din

20% din cauzele eseniale sau 80% din defecte se
gsesc n 20% din cod
Se realizeaz o diagram Pareto cu numrul de defecte
de diferite tipuri
Diagrama identific tipurile principale de defecte
descoperite, care au o mare probabilitate de a se regsi
i n restul proiectului, dac nu se iau unele msuri
44
Exemplu: diagram Pareto
Primele 3 categorii de defecte reprezint mai mult de 88% din total

Aceste categorii ar trebui s fie inta prevenirii defectelor ulterioare
45
Analiza cauzal
Diagrama Pareto identific tipurile principale de defecte

(pot fi considerate efecte)
Analiza cauzal are scopul de a identifica principalele cauze

ale acestor efecte
nelegerea cauzelor ajut la identificarea soluiilor pentru

eliminarea lor
Cauze majore tipice: procese, oameni, tehnologie, instruire
Cauzele i sub-cauzele se determin prin brainstorming.

Dac se identific mai multe, acestea se prioritizeaz
Aceast metod de analiz se bazeaz pe diagrama Ishikawa

(diagrama cauz-efect)
46
Exemplu: diagram Ishikawa

sub-cauze
efectul
cauze
47
Dezvoltarea i implementarea
soluiilor
n aceast faz, se gsesc soluii pentru

atenuarea cauzelor descoperite, tot prin
brainstorming
Soluiile gsite trebuie apoi implementate
Trebuie tratate ca activiti ale proiectului
Este important verificarea efectelor soluiilor,

pentru a vedea dac sunt eficiente
Oamenii sunt convini dac vd rezultate

De exemplu, analiza defectelor dup implementarea
soluiilor
48
Exemplu
49
Intensitatea defectrilor n timp
0 = intensitatea iniial a defectrilor

0 = numrul total de defectri
Dac nu se cunosc aceste valori, nu se poate
estima ncrederea produsului software
50

5. Testarea extrem
7. Concluzii
Testarea extrem
eXtreme Programming (XP), Kent Beck, 1996, Daimler-Chrysler
Metodologie agil de dezvoltare software
A facilitat adoptarea noilor limbaje de programare, precum

Java i C#, pentru dezvoltarea rapid de aplicaii
Aplicaiile se creeaz mai uor i mai rapid, ns nu este

garantat calitatea
Scopul XP: programe de calitate ntr-un timp scurt
Se bazeaz pe testarea unitilor i pe testarea de recepie

(acceptance): cazurile de test se realizeaz naintea codului
propriu-zis
52
Caracteristicile XP
Arhitecturi simple, comunicare ntre dezvoltatori i clieni,

testare permanent, refactorizare
XP funcioneaz bine pentru proiecte mici i medii,
cu schimbri frecvente ale specificaiilor i unde
comunicarea rapid este posibil
Evit stabilirea tuturor detaliilor de la nceput, permite
schimbrile cerinelor
Se evit funcionalitile care nu sunt absolut necesare
la un moment dat
Accentul cade pe funcionalitatea ce aduce valoare
pentru client
53
Testarea extrem
Reguli:
Dificulti:
Toate modulele trebuie s aib testele nainte de scrierea codului

Toate modulele trebuie s treac toate testele nainte de a fi lansat
sistemul
Cum poate fi scris un test pentru un cod inexistent

Cum afecteaz scrierea acestor teste termenul limit
Beneficii:
ncrederea c programul va respecta specificaiile

Exprimarea rezultatului final nainte de implementare
nelegerea mai bun a cerinelor i specificaiilor
Se poate ncepe cu o arhitectur mai simpl i apoi codul se poate
refactoriza fr teama nerespectrii specificaiilor
Automatizarea testrii (de exemplu cu NUnit, JUnit etc.)
54
Exemplu
55
Cazuri de test
56
57
58
59
60
1
61
62
Rezultatele testrii cu NUnit
63

5. Testarea extrem
7. Concluzii
Principii de testare
1. O parte necesar a unui caz de test este
definirea ieirii sau rezultatului ateptat
Dac nu este definit rezultatul ateptat, un rezultat

plauzibil, dar greit, poate fi interpretat drept corect
Ochiul vede ce vrea s vad dorin subcontient
de a vedea un rezultat corect
Un caz de test trebuie s aib:
O descriere a datelor de intrare

O descriere precis a rezultatului corect corespunztor datelor
de intrare respective
65
2. Programatorii nu ar trebui s-i testeze
propriile programe
Programatorul tie ce ar trebui s fac o secven de cod i nu i d

seama cnd face altceva
Programatorul are o perspectiv constructiv (proiectare/implementare);
testarea necesit o perspectiv destructiv
Programatorul poate evita n mod subcontient gsirea erorilor, de frica
efului/colegilor/clientului etc.
Programul poate conine erori deoarece programatorul nu a neles
specificaiile i testele vor suferi de pe urma acestor nenelegeri
Principiul nu spune c un programator nu i poate testa propriul cod,
ci c testarea este fcut mai eficient de altcineva
Depanarea (debugging) este fcut mai eficient de programatorul iniial
66
3. Organizaiile nu ar trebui s-i testeze
propriile programe
Performanele organizaiei i ale managerului de proiect sunt

deseori msurate drept capacitatea de a termina proiectul la o
dat limit i cu o limit de cost
Timpul i costul sunt uor cuantificabile, ns ncrederea
programului nu
Testarea corect scade probabilitatea atingerii obiectivelor de
cost i de timp
Nu este imposibil ca organizaiile s-i testeze propriile
programe, ns o testare obiectiv, independent, poate crete
calitatea programului
67
4. Rezultatele fiecrui test trebuie inspectate
amnunit
Numeroase experimente au artat c unele erori nu

sunt detectate, dei simptomele lor puteau fi clar
observate n testele anterioare
Multe erori descoperite la un moment dat ar fi putut fi
detectate din rezultatele testelor anterioare
68
5. Trebuie scrise cazuri de test att pentru
condiii de intrare invalide i neateptate, ct i
pentru condiii de intrare valide i ateptate
Exist o tendin natural ca testerii s se

concentreze pe condiiile de intrare valide i ateptate
(scenariile normale de funcionare ale programului)
Multe erori apar dup livrare din cauza utilizrii
programului ntr-un mod neateptat
Testarea condiiilor neateptate detecteaz mai multe
erori dect testarea condiiilor ateptate
69
6. Programul trebuie examinat pentru a vedea
dac nu face ce trebuie; de asemenea, trebuie
examinat pentru a vedea dac face ce nu
trebuie
Programele trebuie examinate pentru detectarea

efectelor secundare
De exemplu, un program de salarii care produce rapoarte

pentru salariai inexisteni sau terge prima nregistrare din
baza de date a personalului
70
7. Cazurile de test abandonabile trebuie evitate
dac programul nu este abandonabil
Test abandonabil (engl. throwaway): o persoan

ruleaz programul manual, cu diferite date de intrare
Testele dispar dup ce testarea a fost terminat
Cazurile de test trebuie salvate i re-executate dup

efectuarea unor schimbri n program: testarea de
regresiune
71
8. Efortul de testare nu trebuie planificat cu
presupunerea tacit c nu se vor descoperi erori
Presupunerea greit c testarea arat c programul

funcioneaz corect
72
9. Probabilitatea s existe erori suplimentare ntr-o
seciune a programului este proporional cu numrul de
erori deja descoperite n acea seciune
Erorile tind s apar n grupuri

Unele seciuni ale programului sunt mai predispuse la erori dect
altele pot fi seciuni mai dificile sau seciuni unde a lucrat o
persoan mai puin pregtit
De exemplu, un program are 2 module, A i B. n modulul A s-au
descoperit 5 erori iar n B doar 1 eroare. Dac A nu a fost supus
unei testri mai riguroase, atunci probabilitatea de a gsi mai
multe erori n A este mai mare dect probabilitatea de a gsi mai
multe erori n B
73
9. Probabilitatea ca mai multe erori s existe ntr-o
seciune a programului este proporional cu numrul de
erori deja descoperite n acea seciune
Relaia surprinztoare
dintre numrul de erori
rmase i numrul de
erori descoperite
74
10. Testarea este un proces definit de
creativitate i provocri intelectuale
Creativitatea necesar pentru testare probabil

depete creativitatea necesar pentru proiectare
75
Concluzii
Testarea detecteaz nu numai erorile de implementare,

ci i pe acelea de analiz i proiectare
Testarea este o metod dinamic de verificare i
validare, unde un element (un modul sau sistemul ntreg)
este executat i i se observ comportamentul
Testarea se bazeaz pe un plan, care ghideaz ntregul
proces:
Specific nivelurile testrii i elementele testate

Cazurile de test specificate sunt inspectate i apoi executate
Rezult raportul de testare (cazurile executate) i raportul erorilor
descoperite
76
Concluzii
Niciodat nu putem fi siguri c specificaiile sunt 100%

corecte
Niciodat nu putem fi siguri c un instrument de testare
este corect
Niciun instrument de testare nu poate fi folosit pentru
toate produsele software
Testerii nu pot fi niciodat siguri c neleg complet un
produs software
Niciodat nu putem fi siguri c testarea unui produs
software este complet
77

Ingineria Programarii: Faza de Testare 2

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Ingineria Programarii: Faza de Testare 2

Încărcat de

Drepturi de autor:

Formate disponibile

Ingineria programrii

13. Faza de testare (II)

Faza de testare (II)

Faza de testare (II)

Testarea de nivel nalt

Chiar dac s-ar putea realiza

Este nevoie de testarea de nivel nalt

O eroare se manifest atunci

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Scopul testrii modulelor / unitilor este de a

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Specificaiile externe reprezint o descriere precis a

Descriu toate intrrile i ieirile posibile ale produsului

Specific toate caracteristicile i combinaiile de caracteristici

Testarea funcional este o activitate de tip cutie neagr

Partiionarea n clase de echivalen

Analiza valorilor limit

Se bazeaz pe diagramele cazurilor de utilizare,

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Tipuri de testare funcional

Testarea navigrii utilizatorului

Testarea ecranelor de tranzacii

Testarea fluxurilor de tranzacii

Testarea ecranelor de rapoarte

Testarea fluxurilor de rapoarte

Testarea operaiilor cu bazele de date

Exemplu: dac un raport arat pe ecran ntr-un anumit

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Este de obicei cel mai dificil proces de testare

ncearc s demonstreze n ce fel sistemul nu i

Nu se refer la testarea funciilor sistemului

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Pentru fiecare linie din enunul

Specificaiile externe corespund

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Exemplu: enun de obiective

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Faza de testare (II)

Tipuri de testare a sistemului

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

engl. facility testing

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

engl. load testing

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Poate ajuta la depistarea cauzelor care scad

Servere de aplicaii sau alte componente software

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Ajut la estimarea robusteii, disponibilitii i modului de

Foarte important mai ales pentru sistemele critice

Chiar dac testele simuleaz condiii care nu vor aprea

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testarea la stress motivaie

Defectarea unui sistem critic poate avea consecine dezastruoase

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Testarea la ncrcare variaz condiiile de operare,

Numrul de tranzacii cu 2000, 3000, 4000 de utilizatori

Testarea la stress presupune condiii extreme sau

Numrul de tranzacii cu 2000, 3000, 4000 de utilizatori

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Presupune expunerea produsului la un volum mare

Un compilator care primete un fiier surs de 1 MB