Testarea sistemelor de calcul ş i a re ț elelor

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

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

Ce este testarea ?

2010 3-3TSCR -curs- Ionescu

Augustin-Iulian

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 cerintelor

Specificatii de proiect

Pseudocod Programinterpretare codificareproiectare

verificare verificare testare

Fig. 3.0

Ce este testarea ?


Augustin-Iulian

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.

Ce este testarea ?


Augustin-Iulian

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.

Ce este testarea ?


Augustin-Iulian

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.

Testarea ca disciplină a inginerieiAbordarea 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.


Augustin-Iulian

Testarea ca disciplină a ingineriei


Augustin-Iulian

principii fundamentaleprocese

cod de eticapractici recomandate

metodeunelte

masuratoristandarde

Cunostinte specifice

Inginerie electrica

Ingineria calculatoarelor

Ingineria software

testare

testare

testare

Fig. 3.1

Termeni specificiDezvoltator (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.


Augustin-Iulian

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.

2010

3-10

TSCR -curs- Ionescu Augustin-Iulian

Termeni specificiProces – 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.

2010

3-11


Termeni specifici

2010

3-12


Procesul de dezvoltare a softwareuluiProcesul de analiza a cerintelor

Procesul de generare a specificatiilor

Procesul de proiectare

Procesul de verificare

Procesul de validare

Procesul de codificare

Procesul de testare

Fig. 3.2

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.

2010

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.

2010

3-14


Surse ale defectelor

2010

3-15


* lacune in pregatirea inginerilor* slaba comunicare intre dezvoltatori* neglijenta* greseli de operare* planificare proasta a proceselor

* erori* defecte* esecuri/caderi

* software de proasta calitate* insatisfactia utilizatorului


Impactul asupra produselor

Impactul asupra utilizatorului

Fig. 3.3


2010

3-16


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.

Abordări ale testării

2010

3-17


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.

Modelul unui defect

2010

3-18


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.

Clase de defecte

2010

3-19


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.

Clase de defecte

2010

3-20


* descriere functionala* caracteristici* interactiunea caracteristicilor* descrierea interfetelor

Clasa defectelor in cerinte/specificatii

* algoritmi si procese* control, logica, succesiune* date* descrierea functionala a modulelor* descrierea interfetelor intre module* descrierea interfetelor cu mediul extern

Clasa defectelor in proiectare

* algoritmi si procese* control, logica, succesiune* date* interfete intre module* interfete cu mediul extern* documentarea codului

Clasa defectelor in codificare

* constrangeri asupra testelor* proiectarea testelor* proceduri de testare

Clasa defectelor in testare

* clasa de defecte* severitatea* numarul de aparitii

Baza de date a defectelor

raportarea/analiza defectului




Fig. 3.4

Clasa defectelor ȋn cerințe/specificații

2010

3-21


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.


2010

3-22


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.


2010

3-23


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.

Clasa defectelor de proiectare


Augustin-Iulian

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.



Augustin-Iulian

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.



Augustin-Iulian

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.

Clasa defectelor ȋn cod

2010

3-27


1) Defecte ȋn algoritmi şi proceselipsa 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țiilorexpresii incorecte ȋntr-o instrucțiune if ori case;greşeli ȋn utilizarea ciclurilor;neacoperirea cu cod a unor ramuri ale programului.

3) Defecte de editarescrierea greşită a numelui unei variabile;scrierea greşită a valorii unei constante;lipsa unei paranteze;operator greşit.


2010

3-28


4) Defecte de inițializarelipseşte inițializarea;inițializare cu valoare incorectă.

5) Defecte in fluxul de prelucrare a datelorinițializări multiple;eliminarea unei variabile inăinte de a fi utilizată.

6) Defecte ale dateloromisiunea 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 modulenumăr incorect de parametri;tipul parametrilor este inconsistent;ordinea greşită a parametrilor;apel la module inexistente.


2010

3-29


8) Defecte ale documentației coduluinu 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 hardwareulconexiuni 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.

Defecte ȋn teste

2010

3-30


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.

Principiile testării

2010

3-31


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”.


2010

3-32


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.


2010

3-33


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.

Concluzii

2010

3-34


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

componenta testata

caz de testcomparator

rezultatul testului

Fig. 3.5

2010

3-35


Testarea sistemelor de calcul ş i a re ț elelor

Documents

Transcript of Testarea sistemelor de calcul ş i a re ț elelor