Testarea Sistemelor de Calcul Si A Retelelor

TSCR -curs- Ionescu Augustin-Iulian 2010 3-1
CAPITOLUL 3
TSCR -curs- Ionescu Augustin-Iulian 3-2

2010
Ce este testarea ?
Prin model vom ȋntelege o reprezentare abstractă, simplificată, generalizată,
codificată a unei clase de obiecte, fenomene, concepte, procese.
Procesele de proiectare/implementare ale unui produs implică o serie de
transformări de modele.
Ideal, transformările se realizează fără pierdere de informație.
În realitate transformarea unui model ȋn altul implică o interpretare a
modelului sursă, ceea ce poate duce la neȋnțelegeri, simplificări neinspirate,
neglijarea unor aspecte particulare dar importante etc.
Rolul verificării/testării este de a pune de acord cerințele implicate de
modelul sursă cu caracteristicile modelului rezultat (Fig. 3.0)
Analiza interpretare Specificatii de proiectare codificare

Pseudocod Program
cerintelor proiect
verificare verificare testare
Fig. 3.0
3-3
2010 TSCR -curs- Ionescu Augustin-Iulian
Ce este testarea ?
Nu există o definiţie propriuzisă a testării.
Practic, fiecare persoană sau echipă implicată în activitatea de dezvoltare a

unui sistem poate să adopte propria definiţie a testării în funcţie de
obiectivele urmărite, de experienţă şi de cultura în domeniu.
Pot fi puse în evidenţă câteva trăsături specifice ale activităţii cunoscută sub
numele de testare.
Testarea nu permite să tragem concluzii definitive privind inexistenţa oricărei

erori în sistemul testat.
Testarea nu trebuie confundată cu depanarea.
Testarea trebuie să pună în evidenţă situaţiile în care sistemul nu

funcţionează corect, nu să demonstreze că sistemul este funcţional.
Testarea trebuie să aibă ca obiectiv creşterea calităţii sistemului testat prin

eliminarea erorilor, reducerea timpului de dare în folosinţă, reducerea
cheltuielilor legate de mentenanţă, eliminarea insatisfacţiilor utilizatorilor.
3-4
Ce este testarea ?
Bill Hetzel, unul dintre fondatorii meseriei de tester considera (Complete
Guide to Software Testing Processes) că:
“Testarea este orice activitate avînd ca obiectiv evaluarea unui atribut ori a
funcţionalităţii unui program sau sistem şi determinarea măsurii în care
acesta realizează cerinţele impuse.”
Problema dificilă este de a şti ce înseamnă că un sistem îndeplineşte

cerinţele impuse. Pot să apară două concepţii:
Se iau în considerare numai cerinţele impuse prin specificaţiile de proiect.
Pe lângă specificaţiile de proiect (dacă există) se iau în considerare şi cerinţele
presupuse pe baza experienţei celui ce testează precum şi nivelul de satisfacţie al
utilizatorilor.
3-5
Ce este testarea ?
Bill Hetzel, unul dintre fondatorii meseriei de tester considera (Complete
Guide to Software Testing Processes) că:
“Testarea este orice activitate avînd ca obiectiv evaluarea unui atribut ori a
funcţionalităţii unui program sau sistem şi determinarea măsurii în care
acesta realizează cerinţele impuse.”
Problema dificilă este de a şti ce înseamnă că un sistem îndeplineşte

cerinţele impuse. Pot să apară două concepţii:
Se iau în considerare numai cerinţele impuse prin specificaţiile de proiect.
Pe lângă specificaţiile de proiect (dacă există) se iau în considerare şi cerinţele
presupuse pe baza experienţei celui ce testează precum şi nivelul de satisfacţie al
utilizatorilor.
Testarea este procesul prin care un program este executat ȋn scopul
depistării unor erori.
3-6
Testarea ca disciplină a ingineriei
Abordarea inginerească a testării software implică:
procesul de dezvoltare este bine ințeles;

sunt definite modele ale ciclului de viață ale proiectului;
sunt disponibile standarde;
se utilizează aprecieri cantitative pentru evaluarea calității;
este posibilă reutilizarea componentelor;
validarea şi verificarea proceselor joacă un rol cheie ȋn determinarea calității;
inginerii capătă o educație, antrenament şi certificare specifice.
3-7
Testarea ca disciplină a ingineriei
Inginerie electrica
testare
Ingineria
calculatoarelor
principii fundamentale testare
procese
standarde
masuratori
unelte
metode
practici recomandate
cod de etica
Cunostinte specifice
testare
Ingineria software
Fig. 3.1
3-8
Termeni specifici
Dezvoltator (developer) – persoane implicate direct ȋn proiectarea,
implementarea şi darea ȋn folosință a unui produs software (analişti, ingineri
software, programatori).
Eroare (error) – o greşeală, neȋnțelegere sau concepție greşită din partea unui
dezvoltator.
Defect (fault, bug) – o anomalie datorată unei erori, care poate conduce la
evoluția greşită a softwareului sau ȋn neconcordanță cu specificațiile.
Defecte pot fi găsite şi ȋn cereri sau documente de proiectare. Astfel de defecte sunt
depistate ȋn timpul reviziilor.
Eşec/cădere (failure) - incapacitatea unui sistem software sau a unei
componente a acestuia de a realiza funcția solicitată conform performanțelor
specificate ȋn cerințe.
O comportare a softwareului diferită de cea estimată reprezintă ȋn general un
simptom al unui defect. În anumite situații, un anumit tip de simptom indică un anumit
tip de defect. Un dezvoltator cu experiență construieşte o bază de cunoştințe pentru
defecte/simptome/eşecuri (modele ale defectelor).
Pe durata dezvoltării unui produs, eşecurile sunt de obicei observate de către testori
iar defectele care le-au generat sunt localizate şi rezolvate de către dezvoltatori.
Dacă softwareul este operațional, eşecurile sunt observate de utilizatori care le
raportează organizației care a lansat produsul.
3-9
Termeni specifici
Un defect ȋn cod nu produce ȋntotdeauna un eşec, fiind necesare anumite
condiții pentru ca defectul să provoace un eşec sesisabil. În literatura de
specialitate sunt puse ȋn evidență condițiile:
trebuie sa fie introduse acele date care implică execuția secvenței de cod ȋn care
este localizat defectul;
pentru datele considerate trebuie ca rezultatul obținut să difere de cel corect;
starea internă incorectă trebuie să se propage la ieşire astfel ȋncât rezultatul
defectului să fie observabil.
Cu cât softwareul transformă mai repede defectele dintr-un program ȋn eşecuri,
spunem că softwareul are un nivel mai ridicat de testabilitate, ceea ce convine
echipei de testare.
Pentru a obține produse cu un grad ȋnalt de testabilitate este necesară o
colaborare strȋnsă ȋntre testori şi dezvoltatori ȋncă de la ȋnceputul ciclului de viață
al produsului.
3-10
Termeni specifici
Proces – setul de metode, practici, standarde, documente, activități, strategii
şi proceduri pe care inginerii software le utilizeaza pentru dezvoltarea şi
mentenanța unui sistem software şi a artefactelor asociate (documente de
proiectare, cod, manuale, planificarea testelor etc.).
Validarea – procesul de evaluare a unui sistem sau a unor componente ale
acestuia, pe durata sau la sfarşitul ciclului de dezvoltare, cu scopul de a
determina ȋn ce măsură acestea satisfac cerințele specificate.
Verificare – procesul de evaluare a unui sistem sau a unei componente cu
scopul de a determina dacă rezultatul unei faze de dezvoltare satisface
cerințele impuse la ȋnceputul fazei.
Testarea – un grup de proceduri create ȋn scopul evaluării unor caracteristici
ale unui produs.
Testarea – un proces utilizat pentru a pune ȋn evidență eşecurile unui produs
şi a stabili dacă acesta a atins un anumit nivel al calității ȋn conformitate cu
atributele selectate.
Depanarea (localizarea unui defect) – procesul prin care:
se localizează sursa unui defect;
se repară codul;
se repune ȋn funcțiune programul.
3-11
Termeni specifici
Procesul de
dezvoltare a
Procesul de analiza a cerintelor softwareului
Procesul de generare a
specificatiilor
Procesul de proiectare
Procesul de codificare
Procesul de testare
Procesul de Procesul de
verificare validare
Fig. 3.2
3-12
Termeni specifici
Caz de test (test case) – o entitate care conține minim următoarele informații:
un set de date de test (a set of test input) - date primite de codul testat de la o
sursă externă (umană, software, hardware);
condiții de execuție (execution conditions) – condițiile impuse pentru executarea
unui test (o stare particulară a bazei de date, setările sistemului de operare sau ale
altor programe auxiliare, configurarea unui dispozitiv hardware etc);
ieşirile estimate (expected outputs) – rezultatele aşteptate ca urmare a execuției
codului cu datele de test şi ȋn condițiile specificate.
Fiecare organizație poate decide introducerea ȋn cazul de test a unor informații
adiționale pentru a-i creşte valoarea ca obiect reutilizabil sau pentru a oferi
informații detaliate testorilor şi dezvoltatorilor.
Un caz de test este proiectat pe baza specificațiilor cazului de test.
Conținutul şi formatul documentelor pentru testare vor fi cuprinse ȋn
standardele organizației pentru documentație.
Test – poate fi redefinit ca un grup de cazuri de test corelate sau grup de cazuri
de test corelate şi proceduri.
3-13
Termeni specifici
Procedura (procedure) – specifică paşii necesari pentru realizarea unui test.
Oracol al testului (test oracle) – un document sau o secvență de program care
permite testorului să determine dacă un test este trecut sau nu.
Platforma de testare (test bed) – mediul care conține tot softwareul şi
hardwareul necesare testării unei componente software sau unui sistem software.
Grupul de asigurare a calitatii softwareului (software quality assurence
group SQAG) – o echipă de oameni cu pregătirea şi ȋndemânarea cu care să
asigure toate acțiunile necesare pe durata procesului de dezvoltare, astfel incât
softwareul rezultat să fie conform tuturor cerințelor tehnice stabilite.
Revizia (review) – o intâlnire a unui grup format din manageri, dezvoltatori,
testori şi alte persoane, cu scopul de a evalua un artefact software sau un set de
artefacte software. Reviziile sunt un tip de tehnică de testare software ce poate fi
utilizată pentru evaluarea calității unui artefact software (specificația cerințelor,
documente de proiectare, planuri de test, cod sursă).
Auditul (audit) – un caz particular de revizie , condus de obicei de SQAG, cu
scopul de a asigura compatibilitatea cu specificații/standarde/ȋnțelegeri
contractuale.
3-14
Surse ale defectelor
* lacune in pregatirea inginerilor

* slaba comunicare intre dezvoltatori
* neglijenta
* greseli de operare
* planificare proasta a proceselor Impactul asupra produselor
* erori
* defecte
* esecuri/caderi
Impactul asupra
utilizatorului
* software de proasta calitate

* insatisfactia utilizatorului
Fig. 3.3
3-15
lacune ȋn pregătirea inginerilor software – nu se cunosc bine limbajele
folosite, efectele colaterale ale unor instrucțiuni, modul de conectare la o bază
de date, folosirea diverselor unelte etc.
slaba comunicare ȋntre membrii echipei de dezvoltare – unul dintre
programatori nu informează pe ceilalți de modificările făcute ȋntr-o componentă
sau beneficiarul nu explică clar ce vrea şi nu se asigură că proiectantul a ȋnțeles
exact ce i s-a spus ,etc.
neglijența – un membru al echipei uită să realizeze o etapă importantă, cum
ar fi inițializarea unei variabile sau un parametru la apelul unei funcții, sau a
copiat o secvență ȋn diverse locuri fără să mai facă toate modificările necesare.
codificare greşită – de exemplu numele unei variabile este scris greşit sau nu
se ține cont de precedența operatorilor, etc.
procese prost planificate – neȋnțelegerea fluxului informațional ȋn mediul
real având drept consecință neȋnțelegerea priorităților ȋn dezvoltarea unor
componente şi subsisteme, neglijarea unor etape, alocarea unui timp insuficient
pentru redactarea specificațiilor de proiect ceea ce pune presiune pe cel care le
elaborează şi acesta va fi tentat să treacă cu vederea anumite detalii care ulterior
se pot dovedi foarte importante etc.
3-16
Abordări ale testării
Abordarea 1: Activitatea de testare este o activitate experimentală.
Rezultatele experimentului sunt analizate pentru a pune ȋn evidență
corectitudinea comportării sistemului.
În acest scenariu experimental testorul dezvoltă ipoteze despre posibile defecte.
Cazurile de test sunt proiectate pe baza acestor ipoteze. Testele sunt executate
iar rezultatele obținute sunt analizate pentru a confirma sau infirma ipotezele.
Abordarea 2: Testorul acționează ca un doctor care pe baza datelor inițiale
despre pacient emite o serie de ipoteze legate de bolile posibile ale acestuia.
Urmează investigații suplimentare care confirmă sau infirmă diagnosticul.
Ca şi medicul, testorul trebuie să posede anumite cunoştințe despre diversele
defecte (boli) pentru a putea face ipoteze pertinente ce vor fi utilizate ȋn:
proiectarea cazurilor de test;
proiectarea procedurilor;
asamblarea seturilor de teste;
selectarea nivelului de testare (componentă, integrare, …);
evaluarea rezultatelor testului.
3-17
Modelul unui defect
Prin modelul unui defect vom ȋnțelege legătura ce poate fi stabilită ȋntre
realizarea unei erori şi apariția unui defect ȋn softwareul creat.
Modelele defectelor sunt frecvent utilizate pentru a genera un dicționar de
defecte.
Eficiența unui test poate fi evaluată ȋn contextul unui model al defectului şi se
calculează ca raportul ȋntre numărul de defecte puse ȋn evidență de test şi numărul
de defecte semnalate de model.
3-18
Clase de defecte
Pentru a beneficia de toate avantajele experienței acumulate şi pentru a putea
reutiliza cazurile de test ȋn cât mai multe proiecte, organizația trebuie să decidă
asupra unei anumite scheme de clasificare a defectelor şi să o aplice ȋn toate
proiectele.
Tipul defectelor şi frecvența apariției lor ghidează planificarea testelor şi
proiectarea acestora, permițând selectarea acelor strategii de testare care au cele
mai mari şanse să detecteze anumite tipuri de defecte.
Testele pentru softwareul nou vor fi proiectate pentru a detecta ȋn primul rând
cele mai frecvent ȋntâlnite defecte.
Majoritatea defectelor se detectează prin teste bazate pe execuție dar şi
reviziile pot să se dovedească deosbit de utile.
3-19
Clase de defecte
Clasa defectelor in cerinte/specificatii
* descriere functionala raportarea/analiza defectului
* caracteristici
* interactiunea caracteristicilor
* descrierea interfetelor
Clasa defectelor in proiectare raportarea/analiza

defectului
* algoritmi si procese
* control, logica, succesiune
* date Baza de date a defectelor
* descrierea functionala a modulelor
* descrierea interfetelor intre module * clasa de defecte
* descrierea interfetelor cu mediul extern * severitatea
* numarul de aparitii
Clasa defectelor in codificare
* algoritmi si procese raportarea/analiza
* control, logica, succesiune defectului
* date
* interfete intre module
* interfete cu mediul extern
* documentarea codului
Clasa defectelor in testare

* constrangeri asupra testelor raportarea/analiza defectului
* proiectarea testelor Fig. 3.4
* proceduri de testare
3-
20
Clasa defectelor ȋn cerințe/specificații
Primele etape ale ciclului de viață al unui produs sunt critice pentru asigurarea
unei calități superioare a acestuia. Defectele introduse ȋn această fază pot persista
pe durata ȋntregului ciclu şi sunt greu de eliminat.
Consemnarea cerințelor se face ȋn limbaj natural ceea ce conduce frecvent la

ambiguități, contradicții, redundanță şi imprecizie.
În multe organizații specificațiile sunt formulate tot ȋntr-un limbaj natural deci
apar aceleaşi probleme.
În ultimii ani au fost introduse limbaje formale pentru formularea specificațiilor

şi unelte software pentru manipularea acestora.
3-21
1) Defecte ale descrierii funcționale – descrierea generală a ceea ce face
produsul şi comportamentul său (relația intrare/ieşire) este incorectă, ambiguă
şi/sau incompleta.
2) Defecte ale unor caracteristici
O caracteristică (feature) poate fi descrisă ca o proprietate distinctă a unui
sistem sau unei componente a acestuia şi se referă la aspectele funcționale ale
softwareului, care se suprapun peste cerințele funcționale descrise de
utilizatori/clienti. Caracteristicile se referă şi la cerințe de calitate cum ar fi
performanța sau siguranța ȋn funcționare. Defectele caracteristicilor pot fi lipsa
unei caracteristici, ambiguitatea, incorectitudinea, redundanța.
3) Defecte ale interacțiunii ȋntre caracteristici – datorate unei descrieri
incorecte/incomplete a modului ȋn care diverse caracteristici interactionează.
Exemplu: clasificarea unui pacient după tipul de asigurare impune un anumit
pachet de servicii gratuite acordate pacientului.
3-22
4) Defecte ale descrierii interfețelor – se referă la defecte ce apar ȋn descrierea

modului ȋn care interacționează sistemul analizat cu alte sisteme software,
hardware sau cu utilizatorii.
Exemplu: un editor de scheme logice poate să interacționeze cu un editor
de stimuli şi un program de simulare sau de generare a cablajelor.
Pentru depistarea defectelor de tipul celor descrise anterior se utilizează pe
scară largă tehnici black box ȋn care se exploatează descrierea funcțională a
produsului testat fară referiri la detalii de implementare.
Multe dintre aceste defecte pot fi puse ȋn evidență ȋn fazele timpurii ale
ciclului de viață cu ocazia unei recenzii corect planificate.
Testele de tip black box pot fi planificate la nivel de componentă, integrare,
sistem sau acceptanță.
Defectele de interacțiune sunt puse ȋn evidență prin tehnicile black box ȋn
etapa de integrare sau testare a sistemului.
3-23
Clasa defectelor de proiectare
Apar atunci când componente ale sistemului, interacțiunea ȋntre componentele
sistemului, interacțiunea cu softwareul extern, cu hardwareul sau cu utilizatorii nu
sunt corect proiectate adică pot fi reliefate greşeli ȋn proiectarea algoritmilor,
structurilor de date, logicii de control, interfețelor ȋntre module sau cu alte
programe/hardware.
În cazul ȋn care nu se utilizează pseudocodul ȋn descrierea detaliată a tuturor
elementelor produsului program, defectele de proiectare se vor propaga ȋn codul
dezvoltat.
1) Defecte ȋn algoritmi şi procese.

expresii greşite;
ordinea greşită a operațiilor ȋntr-un proces;
paşi lipsă sau duplicați;
omiterea unor verificări cum ar fi divizarea cu 0;
neluarea ȋn considerare a unor cazuri particulare;
algoritmul ales nu este cel potrivit.
3-24
2) Defecte logice şi ȋn controlul fluxului prelucrărilor – atunci când expresiile
logice şi/sau fluxul prelucrărilor nu sunt prezentate corect ȋn pseudocod:
utilizarea unei condiții greşite ȋntr-o instrucțiune de ramificare;
plasarea greşită a ramificării;
utilizarea greşită a ciclurilor ;
neacoperirea unor căi;
neȋnțelegerea formulării unor condiții cu expresii booleene care folosesc şi valoarea
nulă;
etc.
3) Defecte ale datelor – asociate cu proiectarea greşită a structurilor de date:
lipseşte un câmp ȋntr-o ȋnregistrare;
se asignează greşit tipul de dată al unei variabile sau al unui câmp al unei ȋnregistrări;
un vector/tablou nu are un număr corespunzător de elemente;
spațiul de stocare nu este asignat corespunzător.
Pentru relevarea unor astfel de defecte se recomandă revizii corect planificate şi
utilizarea unui dicționar al datelor.
3-25
4) Defecte ale descrierii funcționale – includ elemente incorecte, lipsă sau
ambigue ale descrierii funcționale a unui modul.
Se depistează cel mai bine cu ocazia unei revizii a proiectării.
5) Defecte ale descrierii interfeței ȋntre module – utilizarea unui tip al
parametrilor incorec/inconsistent, un număr greşit de parametri, ordine greşită a
parametrilor.
6) Defecte ale descrierii interfețelor externe – derivă din proiectarea greşită a
interfețelor cu sisteme software externe, cu bazele de date sau diverse
componente hardware, descrierea necorespunzătoare a interfeței cu utilizatorul,
lipsa unor comenzi, lipsa unor mesaje adecvate pentru utilizator.
Sunt puse ȋn evidență cu ocazia unor revizii ale proiectului.
Observație! Daca nu se utilizează pseudocodul ȋn faza de proiectare, multe dintre
defectele enumerate apar direct ȋn faza de elaborare a codului.
3-26
Clasa defectelor ȋn cod
1) Defecte ȋn algoritmi şi procese
lipsa unor teste de depăşire şi subdepăşire;
comparări ȋntre date de tipuri incompatibile sau cu operatori inadecvați;
ordinea greşită ȋn executarea unor operații;
lipsa parantezelor;
utilizarea greşită a semnului;
utilizarea unui tip de variabilă nepotrivit (exemplu: simplă precizie ȋn loc de dublă
precizie).
2) Defecte ȋn logica de control a ordinei operațiilor
expresii incorecte ȋntr-o instrucțiune if ori case;
greşeli ȋn utilizarea ciclurilor;
neacoperirea cu cod a unor ramuri ale programului.
3) Defecte de editare
scrierea greşită a numelui unei variabile;
scrierea greşită a valorii unei constante;
lipsa unei paranteze;
operator greşit.
3-27
4) Defecte de inițializare
lipseşte inițializarea;
inițializare cu valoare incorectă.
5) Defecte in fluxul de prelucrare a datelor
inițializări multiple;
eliminarea unei variabile inăinte de a fi utilizată.
6) Defecte ale datelor
omisiunea unui câmp ȋntr-o ȋnregistrare;
utilizarea unui tip de dată greşit;
un tabel cu un număr greşit de elemente;
definirea incorectă a unor constante.
7) Defecte ale interfețelor ȋntre module
număr incorect de parametri;
tipul parametrilor este inconsistent;
ordinea greşită a parametrilor;
apel la module inexistente.
3-
28
8) Defecte ale documentației codului
nu reflecta cee ce face programul;
este incompletă, ambiguă, incorectă, neactualizată.
Afectează eforturile de testare putând duce la proiectarea unor teste inadecvate.
Astfel de defecte sunt descoperite pe durata reviziei codului.
9) Defecte ale interfețelor cu softwareul extern şi hardwareul
conexiuni la baze de date;
operații de intrare/ieşire;
utilizarea memoriei;
comunicații cu dispozitive externe pe baza unor protocoale;
accesul la fişiere de date;
etc.
Se detectează cel mai bine utilizând tehnici glass box care implică cunoaşterea
structurii .
Anumite tehnici black box sunt foarte utile pentru a depista defecte cum ar fi cele
din expresii booleene.
3-
29
Defecte ȋn teste
1) Defecte ȋn softwareul auxiliar (test hardness, scafolding cod) – apar datorită
neȋnțelegerii codului testat sau neglijenței ȋn proiectarea şi implementarea
testelor.
Toate tipurile de defecte discutate anterior pot să apară şi ȋn codul auxiliar.
Se impune o proiectare foarte atentă şi testarea /validarea separată a acestui cod.
2) Defecte ȋn cazurile şi procedurile de test – se materializeaza prin cazuri şi
proceduri de test incorecte, incomplete, inadecvate sau lipsă.
Se depistează atât pe durata reviziilor cât şi ȋn procesul de testare, printr-o analiză
atentă a condițiilor de test şi a rezultatelor obținute.
Eliminarea acestor defecte este obligatorie.
3-30
Principiile testării
1. Toate testele trebuie sa fie legate de cerințele (explicite şi implicite)
impuse produsului. Acest principiu ne arată ca ȋn primul rând este necesar
să fie puse ȋn evidență şi eliminate acele defecte care ȋmpiedică produsul să
satisfacă cerințele utilizatorilor. Dacă ȋn urma testelor efectuate sunt puse ȋn
evidență şi alte defecte/anomalii, se va analiza cu atenție ȋn ce măsură ele
pot fi acceptate, cel puțin momentan.
2. Testele trebuie sa fie planificate cu mult ȋnainte de efectuarea lor.
Planificarea testelor pentru o componentă a produsului poate să ȋnceapă
imediat după ȋncheierea formulării specificațiilor pentru acea componentă.
Această abordare corespunde modelelor V şi W de dezvoltare a unui proiect
şi este necesară deoarece pregătirea testelor este ȋn general laborioasă,
implicând scrierea unui cod special pentru testare şi eventual chiar crearea
unor platforme hardware adecvate.
3. Principiul lui Pareto. Formularea adaptată a acestui principiu ȋn
programare este: “80% dintre defectele descoperite sunt concentrate ȋn 20%
din componentele testate”. Un corolar al acestui principiu ar putea fi
formulat ȋn felul următor: “probabilitatea descoperirii de noi defecte este mai
mare ȋn modulele ȋn care au fost deja descoperite defecte”.
3-31
4. Testarea ȋncepe de la “simplu” şi evoluează către “complex”. Acest
principiu ne arată că primele teste planificate şi executate se referă la
componente de complexitate cât mai mică (uneori doar câteva linii de cod
care realizează o funcție bine precizată) pentru a permite localizarea cât mai
rapidă a defectelor. Numai după ce defectele de la acest nivel au fost
eliminate, se trece la testarea unor grupe de module şi ȋn final la testarea
ȋntregului produs.
5. Atunci când definim un test, este esenţial să precizăm la ce rezultate
trebuie să ne aşteptăm.
6. Testarea exhaustivă nu este posibilă adică niciodată nu putem garanta
că dintr-un produs au fost eliminate toate defectele. Acest lucru se
datorează faptului că activitatea de testare este o activitate economică cu
resurse limitate şi care trebuie să se desfăşoare ȋntr-un interval de timp
acceptabil pentru toți partenerii la proiect iar numărul total de teste necesare
pentru a acoperi toate situațiile posibile poate fi foarte mare chiar ȋn cazul
unor componente relativ simple.
3-32
7. Se vor interpreta cu grijă rezultatele tuturor testelor.
8. Trebuie să testăm cu aceaşi atenţie atât situaţiile normale de funcţionare
cât şi pe cele anormale sau chiar inacceptabile.
9. Nu este suficient să punem în evidenţă că un produs nu realizează ceea
ce se presupune că trebuie să realizeze. Este necesar să verificăm şi dacă
nu cumva realizează ceea ce nu trebuie să realizeze.
10. Nu vom distruge datele şi/sau echipamentele de testare utilizate, până
când nu renunţăm la produsul testat.
11. Nu evaluăm efortul de testare bazându-ne pe ipoteza că nu vor apare
noi eşecuri.
12. Pentru a fi cu adevarat eficiente, testele trebuie realizate de o altă
echipă decât cea care a dezvoltat produsele testate deoarece ȋn timp ce
dezvoltatorul este orientat pe reducerea timpului de dare ȋn folosință, testorul
este orientat pe asigurarea calității produsului.
13. Testarea este o activitate creativă de un înalt nivel intelectual.
3-33
Concluzii
Scopul oricărui test este descoperirea de noi eşecuri ale produsului testat.
Un test este considerat cu atât mai bun cu cât asigură o probabilitate mai
mare de depistare a unui nou eşec.
Un test are succes (test pozitiv) dacă a depistat un eşec ce nu a fost pus ȋn
evidență de testele anterioare.
Testarea se face printr-un proces de comparare ȋntre rezultatul obținut
şi rezultatul estimat ca fiind corect (ca ȋn figura 3.5). Descoperirea unei
diferențe implică ȋn primul rând verificarea răspunsului presupus corect şi
numai apoi, dacă este necesar, modificarea codului.
oracolul
testului
rezultatul
caz de test testului
comparator
componenta
testata
Fig. 3.5
3-34
3-35

Testarea Sistemelor de Calcul Si A Retelelor

Î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

Testarea Sistemelor de Calcul Si A Retelelor

Încărcat de

Drepturi de autor:

Formate disponibile

TSCR -curs- Ionescu Augustin-Iulian 2010 3-1

TSCR -curs- Ionescu Augustin-Iulian 3-2

Analiza interpretare Specificatii de proiectare codificare

verificare verificare testare

Practic, fiecare persoană sau echipă implicată în activitatea de dezvoltare a

Testarea nu permite să tragem concluzii definitive privind inexistenţa oricărei

Testarea nu trebuie confundată cu depanarea.

Testarea trebuie să pună în evidenţă situaţiile în care sistemul nu

Testarea trebuie să aibă ca obiectiv creşterea calităţii sistemului testat prin

Problema dificilă este de a şti ce înseamnă că un sistem îndeplineşte

Problema dificilă este de a şti ce înseamnă că un sistem îndeplineşte

procesul de dezvoltare este bine ințeles;

* lacune in pregatirea inginerilor

* software de proasta calitate

Clasa defectelor in proiectare raportarea/analiza

Clasa defectelor in testare

Consemnarea cerințelor se face ȋn limbaj natural ceea ce conduce frecvent la

În ultimii ani au fost introduse limbaje formale pentru formularea specificațiilor

4) Defecte ale descrierii interfețelor – se referă la defecte ce apar ȋn descrierea

1) Defecte ȋn algoritmi şi procese.

S-ar putea să vă placă și