Ingineria programarii: Faza de testare 2

Ingineria programării

13. Faza de testare (II)

Florin Leon
Universitatea Tehnică „Gheorghe Asachi” din Iaşi
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 urmărirea defectelor
4. Analiza şi prevenirea defectelor
5. Testarea extremă
6. Principii de testare
7. Concluzii
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 urmărirea defectelor
4. Analiza şi prevenirea defectelor
5. Testarea extremă
6. Principii de testare
7. Concluzii
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

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
când programul nu face ceea ce
se aşteaptă utilizatorul, în mod
rezonabil, să facă
4

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

Dezvoltarea
şi testarea
1. Nevoile utilizatorilor sunt
transformate în cerinţe
(scopuri)
2. Cerinţele sunt
transformate în obiective
specifice (fezabilitate, cost,
compromisuri, priorităţi)
3. Obiectivele sunt
transformate în specificaţii
externe (sistemul e văzut ca
o cutie neagră, se iau în
calcul doar interfeţele şi
interacţiunile cu utilizatorul)
5

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

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 sfârşitul fiecărei faze
există un pas separat de
verificare pentru a detecta
cât mai multe erori înainte de
a trece la faza următoare (de
exemplu inspecţii ale codului)

6

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

Corespondenţe

Scopul testării modulelor / unităţilor este de a
găsi discrepanţele dintre modulele programului
şi specificaţiile interfeţelor acestora
Scopul testării funcţionale este de a arăta că
programul nu respectă specificaţiile externe
Scopul testării sistemului este de a arăta că
produsul nu respectă obiectivele stabilite iniţial

7

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

Testarea funcţională

Specificaţiile externe reprezintă o descriere precisă a
comportamentului sistemului din perspectiva utilizatorului

Descriu toate intrările şi ieşirile posibile ale produsului

Specifică toate caracteristicile şi combinaţiile de caracteristici

Testarea funcţională este o activitate de tip cutie neagră

Partiţionarea în clase de echivalenţă

Analiza valorilor limită

Grafurile cauză-efect

„Ghicirea erorilor”

Se bazează pe diagramele cazurilor de utilizare,
diagramele de stări etc.
8

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

Tipuri de testare funcţională

Testarea navigării utilizatorului

Testarea ecranelor de tranzacţii

Testarea fluxurilor de tranzacţii

Testarea ecranelor de rapoarte

Testarea fluxurilor de rapoarte

Testarea operaţiilor 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 tipărită
9

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

Testarea sistemului

Este de obicei cel mai dificil proces de testare
Scopul este compararea comportamentului
sistemului cu obiectivele sale iniţiale

Încearcă să demonstreze în ce fel sistemul nu îşi
îndeplineşte obiectivele
Testarea sistemului este imposibilă dacă nu există
obiective scrise măsurabile ale produsului

Nu se referă la testarea funcţiilor sistemului
complet (≠ testarea funcţională)
10

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

Proiectarea testelor

Testarea sistemului se
proiectează analizând obiectivele
Cazurile de test se formulează
prin analiza documentaţiei
utilizatorului

Pentru fiecare linie din enunţul
obiectivelor, ar trebui să
demonstreze că produsul nu se
comportă corect
Nu există metodologii de
proiectare a acestor teste
Necesită creativitate

Specificaţiile externe corespund
testării funcţionale
11

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

Exemplu: enunţ de obiective
pentru comanda “display”

12

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 urmărirea defectelor
4. Analiza şi prevenirea defectelor
5. Testarea extremă
6. Principii de testare
7. Concluzii
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Tipuri de testare a sistemului

Testarea caracteristicilor

Testarea configuraţiei

Testarea încărcării

Testarea compatibilităţii

Testarea la stress

Testarea instalabilităţii

Testarea volumului

Testarea încrederii

Testarea utilizabilităţii

Testarea recuperării

Testarea securităţii

Testarea documentaţiei

Testarea stocării

Testarea procedurilor

14

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

Testarea caracteristicilor

engl. “facility testing”
Parcurgerea obiectivelor şi testarea dacă
produsul îndeplineşte fiecare obiectiv
Compararea mentală a obiectivelor cu
documentaţia utilizatorului este deseori
suficientă

15

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

Testarea încărcării

engl. “load testing”
Presupune operarea sistemului în condiţii normale sau cu
vârfuri anticipate de sarcină şi observarea comportamentului
acestuia
Ajută la identificarea capacităţii operaţionale maxime a
sistemului
Mediul de test este asemănător cu mediul în care va rula
sistemul în producţie
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, aplicaţii cu generatoare de rapoarte etc.
16

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

Testarea încărcării

Poate ajuta la depistarea cauzelor care scad
performanţele, de exemplu:



Servere de aplicaţii sau alte componente software
Servere de baze de date
Latenţa sau congestia reţelei
Prelucrările în partea clientului
Echilibrarea încărcării între mai multe servere

17

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

Testarea la stress

Ajută la estimarea robusteţii, disponibilităţii şi modului de
tratare a erorilor printr-o încărcare dincolo de limitele
normale de operare

Foarte importantă mai ales pentru sistemele critice

Chiar dacă testele simulează condiţii care nu vor apărea
niciodată, comportamentul sistemului poate da informaţii
importante despre erorile care ar putea apărea în situaţii
reale de funcţionare

18

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

Testarea la stress – motivaţie



Defectarea unui sistem critic poate avea consecinţe dezastruoase
Timpul şi resursele dedicate testării tradiţionale nu sunt suficiente
Nu se pot determina toate modurile în care va fi folosit sistemul,
de exemplu un sistem de operare va rula aplicaţii care nici nu există
în momentul testării
Utilizatorii vor rula sistemul pe calculatoare cu mai puţine resurse
decât cele folosite pentru testare
Concurenţa este dificil de testat cu metode tradiţionale, 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

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

Discuţie

Testarea la încărcare variază condiţiile de operare,
de exemplu numărul de utilizatori, de tranzacţii etc.,
menţinând constantă configuraţia

Numărul de tranzacţii cu 2000, 3000, 4000 de utilizatori
concurenţi

Testarea la stress presupune condiţii extreme sau
anormale, de exemplu resurse diminuate sau prelucrări
intense

Numărul de tranzacţii cu 2000, 3000, 4000 de utilizatori
concurenţi, cu memorie foarte puţină pe server, viteză mică a
reţelei etc.
20

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

Testarea volumului

Presupune expunerea produsului la un volum mare
de date
Exemple:

Un compilator care primeşte un fişier sursă de 1 MB

Un simulator de circuite electronice care primeşte un circuit
cu 1000 de componente

Un procesor de test care primeşte un document cu 2000
de pagini

Scopul este să arate că programul nu poate
gestiona volumul de date specificat în obiective
21

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

Accepţiuni alternative

Testarea la stress implică un element de timp: supunerea
sistemului la o încărcare foarte mare pentru o perioadă scurtă
de timp

Aplicabilă mai ales pentru programele care operează la încărcări
variabile, interactive, în timp real: aplicaţii 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 număr mare de avioane în raza sa de acţiune
Pentru un sistem de control al proceselor, toate procesele monitorizate
generează semnale simultan
22

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

Accepţiuni 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

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

Testarea utilizabilităţii

engl. “usability testing”
Încercarea de a descoperi probleme legate de factorul
uman, de utilizarea sistemului
Consideraţii:


Interfeţele cu utilizatorul trebuie să fie potrivite pentru profilul
acestuia
Ieşirile trebuie să fie uşor de înţeles
Mesajele de eroare nu trebuie să reflecte detalii interne de
programare
Interfeţele trebuie să aibă integritate conceptuală, coerenţă

24

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

Testarea utilizabilităţii

Consideraţii:

Când acurateţea este vitală, intrările trebuie să aibă suficient de
multe elemente redundante, de exemplu număr cont, nume
titular, PIN etc.
Sistemul nu trebuie să conţină un număr excesiv de opţiuni.
Accesarea lor trebuie să fie logică şi intuitivă. Se pot prezenta
doar opţiunile folosite frecvent
Sistemul trebuie să prezinte notificări pentru primirea intrărilor.
Dacă o operaţiune este de durată, utilizatorul trebuie informat
Sistemul trebuie să fie uşor de folosit. De exemplu, dacă intrările
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

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

Testarea securităţii

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
existenţei lor în sistemul testat
Aplicaţiile web necesită în general un nivel
superior de securitate, mai ales site-urile de
comerţ electronic
26

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

Testarea stocării

engl. “storage testing”
Unele programe au obiective de stocare,
referitoare de exemplu la volumul de memorie
folosit sau la dimensiunea fişierelor temporare
Trebuie imaginate cazuri de test care arată că
programul nu îndeplineşte aceste obiective

27

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

Testarea configuraţiei

engl. “configuration testing”

Sistemele de operare, sistemele de management al bazelor
de date, aplicaţiile de transmitere de mesaje/pachete trebuie
să suporte o mulţime de configuraţii hardware

Dispozitive de intrare-ieşire

Linii de comunicaţie

Dimensiuni diferite ale memoriei

De multe ori, numărul configuraţiilor posibile este prea mare
pentru a fi testată fiecare combinaţie în parte

Trebuie testat sistemul cu fiecare tip de dispozitiv hardware şi
cu configuraţiile minime şi maxime
28

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

Testarea compatibilităţii

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

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

Testarea instalabilităţii

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

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

Testarea încrederii

engl. “reliabiliy testing”
În general, scopul tuturor tipurilor de testare este creşterea
încrederii
Testarea încrederii poate fi dificilă


Un WAN sau un ISP pot avea ca obiectiv un timp de funcţionare de
99,97% (engl. “uptime”)
Este greu de imaginat cum s-ar putea testa sistemul timp de câteva
luni sau ani

Se poate calcula timpul mediu între defectări
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

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

Testarea recuperării

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ă defecţiuni legate de
programare, de hardware sau de date
Testarea presupune crearea (simularea) unor condiţii de
eroare în mediul extern de execuţie
Testarea îşi propune să arate că:

Funcţiile de recuperare nu lucrează corect
Sistemul nu respectă timpul mediu pentru recuperare asumat
32

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

Testarea documentaţiei

engl. “documentation testing”
Documentaţia este folosită ca un ghid pentru
scrierea cazurilor de test la testarea sistemului
Documentaţia utilizatorului trebuie să fie
inspectată (ca şi codul), analizându-i-se
acurateţea şi claritatea

33

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

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

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

Executarea testării sistemului

Cine trebuie să testeze sistemul

Pe cât posibil, nu programatorii

Pe cât posibil, nu organizaţia dezvoltatoare

O echipă formată din: experţi în testare, inginer de factori
umani (“human factors engineer”), 1 sau 2 utilizatori
reprezentativi, analistul sau proiectantul aplicaţiei
Aceasta nu are de fapt motivaţia să demonstreze că produsul
nu îndeplineşte obiectivele
Cel mai economic mod de a realiza testarea sistemului
(găsirea numărului maxim de erori cu un anumit cost sau un
cost mai mic pentru descoperirea aceluiaşi număr de erori)
este subcontractarea către o altă organizaţie

vezi şi principiile 2 şi 3 spre sfârşitul cursului
35

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 urmărirea defectelor
4. Analiza şi prevenirea defectelor
5. Testarea extremă
6. Principii de testare
7. Concluzii
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

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 situaţii, raportarea şi repararea
nu pot fi făcute informal: un defect ar putea
fi uitat şi/sau redescoperit ulterior cu un efort
suplimentar

37

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

Ciclul de viaţă al unui defect

Formal, când un defect este descoperit – de către oricine – este
înregistrat (“logged”) într-un sistem de control al defectelor

Repararea defectului este atribuită unei persoane, de obicei
programatorul iniţial, 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

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

Ciclul de viaţă al unui defect

Ciclul de viaţă poate fi mărit sau micşorat în funcţie 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 urmărire

Defectele sunt deseori clasificate, pentru a le înţelege
mai bine natura

De exemplu: logică, standarde, interfaţa cu utilizatorul,
interfaţarea componentelor, performanţe, documentaţie
39

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

Clasificarea după severitate

În multe organizaţii se foloseşte o clasificare a
defectelor pe 4 niveluri:

Defecte critice: afectează mulţi utilizatori, pot întârzia
proiectul

Defecte majore: au un impact puternic, necesită un volum
mare de lucru pentru a le repara, dar nu afectează
substanţial graficul de lucru al proiectului

Defecte minore: izolate, care se manifestă rar şi au un
impact minor asupra proiectului

Defecte cosmetice: mici greşeli care nu afectează
funcţionarea corectă a produsului software
40

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

Exemplu: descoperirea şi
închiderea defectelor

În figură, distanţa dintre numărul
total de defecte şi numărul
defectelor închise creşte
Activitatea de dezvoltare trebuie
încetinită şi trebuie alocate mai
multe resurse reparării defectelor
Pentru un proiect gestionat
corespunzător, numărul de
defecte deschise ar trebui să se
reducă spre sfârşitul proiectului,
chiar dacă nu este obligatoriu ca
variaţia să fie monoton
descrescătoare
41

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 urmărirea defectelor
4. Analiza şi prevenirea defectelor
5. Testarea extremă
6. Principii de testare
7. Concluzii
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Analiza şi prevenirea defectelor

La nivel organizaţional, analiza defectelor poate
îmbunătăţi listele de verificare, procesele sau
instruirea personalului

La nivelul proiectului, se învaţă din defectele
descoperite până la un moment dat pentru a preveni
pe cât posibil defectele din restul proiectului

Prevenirea defectelor

Creşte calitatea: sistemul final va avea mai puţine defecte

Creşte productivitatea: se consumă mai puţin efort pentru
repararea defectelor
43

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

Analiza Pareto

Se bazează pe aşa-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 esenţiale sau 80% din defecte se
găsesc în 20% din cod
Se realizează o diagramă Pareto cu numărul de defecte
de diferite tipuri
Diagrama identifică tipurile principale de defecte
descoperite, care au o mare probabilitate de a se regăsi
şi în restul proiectului, dacă nu se iau unele măsuri
44

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

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

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

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

Înţelegerea cauzelor ajută la identificarea soluţiilor 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

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

Exemplu: diagramă Ishikawa
sub-cauze

efectul
cauze

47

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

Dezvoltarea şi implementarea
soluţiilor

În această fază, se găsesc soluţii pentru
atenuarea cauzelor descoperite, tot prin
brainstorming
Soluţiile găsite trebuie apoi implementate

Trebuie tratate ca activităţi ale proiectului

Este importantă verificarea efectelor soluţiilor,
pentru a vedea dacă sunt eficiente

Oamenii sunt convinşi dacă văd rezultate
De exemplu, analiza defectelor după implementarea
soluţiilor
48

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

Exemplu

49

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

Intensitatea defectărilor în timp

λ0 = intensitatea iniţială a defectărilor
ν0 = numărul total de defectări
Dacă nu se cunosc aceste valori, nu se poate
estima încrederea produsului software

50

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 urmărirea defectelor
4. Analiza şi prevenirea defectelor
5. Testarea extremă
6. Principii de testare
7. Concluzii
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

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 aplicaţii

Aplicaţiile se creează mai uşor şi mai rapid, însă nu este
garantată calitatea

Scopul XP: programe de calitate într-un timp scurt

Se bazează pe testarea unităţilor şi pe testarea de recepţie
(“acceptance”): cazurile de test se realizează înaintea codului
propriu-zis

52

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

Caracteristicile XP

Arhitecturi simple, comunicare între dezvoltatori şi clienţi,
testare permanentă, refactorizare
XP funcţionează bine pentru proiecte mici şi medii,
cu schimbări frecvente ale specificaţiilor şi unde
comunicarea rapidă este posibilă
Evită stabilirea tuturor detaliilor de la început, permite
schimbările cerinţelor
Se evită funcţionalităţile care nu sunt absolut necesare
la un moment dat
Accentul cade pe funcţionalitatea ce aduce valoare
pentru client
53

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

Testarea extremă

Reguli:

Dificultăţi:

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 specificaţiile
Exprimarea rezultatului final înainte de implementare
Înţelegerea mai bună a cerinţelor şi specificaţiilor
Se poate începe cu o arhitectură mai simplă şi apoi codul se poate
refactoriza fără teama nerespectării specificaţiilor
Automatizarea testării (de exemplu cu NUnit, JUnit etc.)
54

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

Exemplu

55

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

Cazuri de test

56

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

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

57

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

58

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

59

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

60

1

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

61

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

62

Rezultatele testării cu NUnit

63

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 urmărirea defectelor
4. Analiza şi prevenirea defectelor
5. Testarea extremă
6. Principii de testare
7. Concluzii
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Principii de testare
1. O parte necesară a unui caz de test este
definirea ieşirii sau rezultatului aşteptat

Dacă nu este definit rezultatul aşteptat, un rezultat
plauzibil, dar greşit, poate fi interpretat drept corect
„Ochiul vede ce vrea să vadă” – dorinţă subconştientă
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 corespunzător datelor
de intrare respective
65

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

Principii de testare
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 când face altceva
Programatorul are o perspectivă constructivă (proiectare/implementare);
testarea necesită o perspectivă destructivă
Programatorul poate evita în mod subconştient găsirea erorilor, de frica
şefului/colegilor/clientului etc.
Programul poate conţine erori deoarece programatorul nu a înţeles
specificaţiile – şi testele vor suferi de pe urma acestor neînţelegeri
Principiul nu spune că un programator nu îşi poate testa propriul cod,
ci că testarea este făcută mai eficient de altcineva
Depanarea (“debugging”) este făcută mai eficient de programatorul iniţial
66

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

Principii de testare
3. Organizaţiile nu ar trebui să-şi testeze
propriile programe

Performanţele organizaţiei şi ale managerului de proiect sunt
deseori măsurate drept capacitatea de a termina proiectul la o
dată limită şi cu o limită de cost
Timpul şi costul sunt uşor cuantificabile, însă încrederea
programului – nu
Testarea corectă scade probabilitatea atingerii obiectivelor de
cost şi de timp
Nu este imposibil ca organizaţiile să-şi testeze propriile
programe, însă o testare obiectivă, independentă, poate creşte
calitatea programului
67

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

Principii de testare
4. Rezultatele fiecărui test trebuie inspectate
amănunţit

Numeroase experimente au arătat că unele erori nu
sunt detectate, deşi 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

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

Principii de testare
5. Trebuie scrise cazuri de test atât pentru
condiţii de intrare invalide şi neaşteptate, cât şi
pentru condiţii de intrare valide şi aşteptate

Există o tendinţă naturală ca testerii să se
concentreze pe condiţiile de intrare valide şi aşteptate
(scenariile normale de funcţionare ale programului)
Multe erori apar după livrare din cauza utilizării
programului într-un mod neaşteptat
Testarea condiţiilor neaşteptate detectează mai multe
erori decât testarea condiţiilor aşteptate
69

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

Principii de testare
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 salariaţi inexistenţi sau şterge prima înregistrare din
baza de date a personalului

70

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

Principii de testare
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 schimbări în program: testarea de
regresiune

71

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

Principii de testare
8. Efortul de testare nu trebuie planificat cu
presupunerea tacită că nu se vor descoperi erori

Presupunerea greşită că testarea arată că programul
funcţionează corect

72

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

Principii de testare
9. Probabilitatea să existe erori suplimentare într-o
secţiune a programului este proporţională cu numărul de
erori deja descoperite în acea secţiune

Erorile tind să apară în grupuri
Unele secţiuni ale programului sunt mai predispuse la erori decât
altele – pot fi secţiuni mai dificile sau secţiuni unde a lucrat o
persoană mai puţin pregătită
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 testări mai riguroase, atunci probabilitatea de a găsi mai
multe erori în A este mai mare decât probabilitatea de a găsi mai
multe erori în B
73

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

Principii de testare
9. Probabilitatea ca mai multe erori să existe într-o
secţiune a programului este proporţională cu numărul de
erori deja descoperite în acea secţiune

Relaţia surprinzătoare
dintre numărul de erori
rămase şi numărul de
erori descoperite
74

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

Principii de testare
10. Testarea este un proces definit de
creativitate şi provocări intelectuale

Creativitatea necesară pentru testare probabil
depăşeşte creativitatea necesară pentru proiectare

75

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

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 testării şi elementele testate
Cazurile de test specificate sunt inspectate şi apoi executate
Rezultă raportul de testare (cazurile executate) şi raportul erorilor
descoperite
76

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

Concluzii

Niciodată nu putem fi siguri că specificaţiile 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ă înţeleg complet un
produs software
Niciodată nu putem fi siguri că testarea unui produs
software este completă
77

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

Sign up to vote on this title
UsefulNot useful