Testarea sistemelor de calcul ş i a re ț elelor

1. Testarea sistemelor de calcul şi a rețelelor TSCR -curs- Ionescu Augustin-Iulian

2. Introducere ȋn testarea software Capitolul 3 TSCR -curs- Ionescu Augustin-Iulian

3. 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) Fig. 3.0 TSCR -curs- Ionescu Augustin-Iulian

4. 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. TSCR -curs- Ionescu Augustin-Iulian

5. Ce este testarea ? • Bill Hetzel, unuldintrefondatoriimeseriei de tester considera (Complete Guide to Software Testing Processes) că: “Testareaesteoriceactivitateavînd ca obiectivevaluareaunuiatributori a funcţionalităţii unui program sausistemşideterminarea măsuriiîn care acestarealizeazăcerinţeleimpuse.” • Problema dificilăeste de a şticeînseamnă că un sistemîndeplineştecerinţeleimpuse. 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. TSCR -curs- Ionescu Augustin-Iulian

6. Ce este testarea ? • Bill Hetzel, unuldintrefondatoriimeseriei de tester considera (Complete Guide to Software Testing Processes) că: “Testareaesteoriceactivitateavînd ca obiectivevaluareaunuiatributori a funcţionalităţii unui program sausistemşideterminarea măsuriiîn care acestarealizeazăcerinţeleimpuse.” • Problema dificilăeste de a şticeînseamnă că un sistemîndeplineştecerinţeleimpuse. 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. • Testareaeste procesul prin care un program este executat ȋn scopul depistării unor erori. TSCR -curs- Ionescu Augustin-Iulian

7. 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. TSCR -curs- Ionescu Augustin-Iulian

8. Testarea ca disciplină a ingineriei Fig. 3.1 TSCR -curs- Ionescu Augustin-Iulian

9. 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. TSCR -curs- Ionescu Augustin-Iulian

10. 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. TSCR -curs- Ionescu Augustin-Iulian

11. 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. TSCR -curs- Ionescu Augustin-Iulian

12. Termeni specifici Fig. 3.2 TSCR -curs- Ionescu Augustin-Iulian

13. 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. TSCR -curs- Ionescu Augustin-Iulian

14. 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. • Platformade 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. TSCR -curs- Ionescu Augustin-Iulian

15. Surse ale defectelor Fig. 3.3 TSCR -curs- Ionescu Augustin-Iulian

16. Surse ale defectelor • 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. TSCR -curs- Ionescu Augustin-Iulian

17. 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. TSCR -curs- Ionescu Augustin-Iulian

18. Modelul unui defect • Prinmodelul 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. TSCR -curs- Ionescu Augustin-Iulian

19. 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. TSCR -curs- Ionescu Augustin-Iulian

20. Clase de defecte Fig. 3.4 TSCR -curs- Ionescu Augustin-Iulian

21. 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. TSCR -curs- Ionescu Augustin-Iulian

22. Clasa defectelor ȋn cerințe/specificații • 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. • 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. • 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. TSCR -curs- Ionescu Augustin-Iulian

23. Clasa defectelor ȋn cerințe/specificații • 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. TSCR -curs- Ionescu Augustin-Iulian

24. 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. • 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. TSCR -curs- Ionescu Augustin-Iulian

25. Clasa defectelor de proiectare • 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. TSCR -curs- Ionescu Augustin-Iulian

26. Clasa defectelor de proiectare 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. TSCR -curs- Ionescu Augustin-Iulian

27. Clasa defectelor ȋn cod • 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). • 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. • Defecte de editare • scrierea greşită a numelui unei variabile; • scrierea greşită a valorii unei constante; • lipsa unei paranteze; • operator greşit. TSCR -curs- Ionescu Augustin-Iulian

28. Clasa defectelor ȋn cod • Defecte de inițializare • lipseşte inițializarea; • inițializare cu valoare incorectă. • Defecte in fluxul de prelucrare a datelor • inițializări multiple; • eliminarea unei variabile inăinte de a fi utilizată. • 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. TSCR -curs- Ionescu Augustin-Iulian

29. Clasa defectelor ȋn cod • 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. TSCR -curs- Ionescu Augustin-Iulian

30. Defecte ȋn teste • 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. • 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. TSCR -curs- Ionescu Augustin-Iulian

31. Principiile testării • 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. • 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. • 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”. TSCR -curs- Ionescu Augustin-Iulian

32. Principiile testării • 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. • Atunci când definim un test, este esenţial să precizăm la ce rezultate trebuie să ne aşteptăm. • 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. TSCR -curs- Ionescu Augustin-Iulian

33. Principiile testării • Se vor interpreta cu grijă rezultatele tuturor testelor. • 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. • 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. • Nu vom distruge datele şi/sau echipamentele de testare utilizate, până când nu renunţăm la produsul testat. • Nu evaluăm efortul de testare bazându-ne pe ipoteza că nu vor apare noi eşecuri. • 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. • Testarea este o activitate creativă de un înalt nivel intelectual. TSCR -curs- Ionescu Augustin-Iulian

34. 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. Fig. 3.5 TSCR -curs- Ionescu Augustin-Iulian

35. Întrebări ? TSCR -curs- Ionescu Augustin-Iulian