ingineria programarii: faza de testare 2

7/30/2019 Ingineria programarii: Faza de testare 2

1/77

Ingineria programrii

13. Faza de testare (II)

Florin LeonUniversitatea TehnicGheorgheAsachi din IaiFacultatea de Automatici Calculatoare

http://florinleon.byethost24.com/curs_ip.htm

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


2/77

Faza de testare (II)

1. Testarea de nivel nalt2. Testarea sistemului3. nregistrarea i urmrirea defectelor4. Analiza i prevenirea defectelor

5. Testarea extrem6. Principii de testare7. Concluzii



3/77






4/77

Testarea de nivel nalt

Chiar dac s-ar putea realizatestarea perfect a modulelor, totnu s-ar putea garanta lipsa

erorilor Este nevoie de testarea de nivel nalt

O eroare se manifest atunci

cnd programul nu face ceea cese ateapt utilizatorul, n modrezonabil, s fac

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


5/77

Dezvoltarea

i testarea

5

1. Nevoile utilizatorilor sunttransformate n cerine(scopuri)

2. Cerinele sunttransformate n obiectivespecifice (fezabilitate, cost,compromisuri, prioriti)

3. Obiectivele sunt

transformate n specificaiiexterne (sistemul e vzut cao cutie neagr, se iau ncalcul doar interfeele iinteraciunile cu utilizatorul)



6/77

Dezvoltarea

i testarea

6

Fiecare faz a procesului detestare se concentreaz peun anumit pas al procesuluide dezvoltare i pe o anumitclas de erori

La sfritul fiecrei fazeexist un pas separat de

verificare pentru a detectact mai multe erori nainte dea trece la faza urmtoare (deexemplu inspecii ale codului)



7/77

Corespondene

Scopul testrii modulelor / unitilor este de agsi discrepanele dintre modulele programuluii specificaiile interfeelor acestora

Scopul testrii funcionale este de a arta cprogramul nu respect specificaiile externe

Scopul testrii sistemului este de a arta c

produsul nu respect obiectivele stabilite iniial



8/77

Testarea funcional

Specificaiile externe reprezint o descriere precis acomportamentului sistemului din perspectiva utilizatorului Descriu toate intrrile i ieirile posibile ale produsului

Specific toate caracteristicile i combinaiile de caracteristici Testarea funcional este o activitate de tip cutie neagr

Partiionarea n clase de echivalen

Analiza valorilor limit

Grafurile cauz-efect Ghicirea erorilor

Se bazeaz pe diagramele cazurilor de utilizare,diagramele de stri etc.



9/77

Tipuri de testare funcional

Testarea navigrii utilizatorului

Testarea ecranelor de tranzacii

Testarea fluxurilor de tranzacii

Testarea ecranelor de rapoarte

Testarea fluxurilor de rapoarte

Testarea operaiilor cu bazele de date

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

mod, trebuie s arate la fel i n forma tiprit



10/77

Testarea sistemului

Este de obicei cel mai dificil proces de testare

Scopul este compararea comportamentuluisistemului cu obiectivele sale iniiale ncearc s demonstreze n ce fel sistemul nui

ndeplinete obiectivele

Testarea sistemului este imposibil dac nu existobiective scrise msurabile ale produsului

Nu se refer la testarea funciilor sistemuluicomplet ( testarea funcional)



11/77

Proiectarea testelor

Testarea sistemului seproiecteaz analiznd obiectivele

Cazurile de test se formuleazprin analiza documentaiei

utilizatorului Pentru fiecare linie din enunul

obiectivelor, ar trebui sdemonstreze c produsul nu secomport corect

Nu exist metodologii deproiectare a acestor teste

Necesit creativitate

Specificaiile externe corespundtestrii funcionale



12/77

Exemplu: enun de obiective

pentru comanda display



13/77






14/77

Tipuri de testare a sistemului

Testarea caracteristicilor

Testareancrcrii

Testarea la stress

Testarea volumului

Testarea utilizabilitii

Testarea securitii

Testarea stocrii

Testarea configuraiei

Testarea compatibilitii

Testarea instalabilitii

Testarea ncrederii

Testarea recuperrii

Testarea documentaiei

Testarea procedurilor



15/77

Testarea caracteristicilor

engl. facility testing

Parcurgerea obiectivelor i testarea dacprodusul ndeplinete fiecare obiectiv

Compararea mental a obiectivelor cudocumentaia utilizatorului este deseorisuficient

15



16/77

Testareancrcrii

engl. load testing

Presupune operarea sistemului n condiii normale sau cuvrfuri anticipate de sarcin i observarea comportamentuluiacestuia

Ajut la identificarea capacitii operaionale maxime asistemului

Mediul de test este asemntor cu mediul n care va rulasistemul n producie

Relevant n special pentru sisteme multi-user, client-serversau pentru servicii cu SLA (service level agreement)

Util i pentru alte tipuri de produse software: procesoare detext sau grafice, aplicaii cu generatoare de rapoarte etc.

16



17/77

Testareancrcrii

Poate ajuta la depistarea cauzelor care scadperformanele, de exemplu: Servere de aplicaii sau alte componente software

Servere de baze de date Latena sau congestia reelei

Prelucrrile n partea clientului

Echilibrarea ncrcrii ntre mai multe servere

17



18/77

Testarea la stress

Ajut la estimarea robusteii, disponibilitii i modului de

tratare a erorilor printr-o ncrcare dincolo de limitele

normale de operare

Foarte important mai ales pentru sistemele critice

Chiar dac testele simuleaz condiii care nu vor aprea

niciodat, comportamentul sistemului poate da informaii

importante despre erorile care ar putea aprea n situaiireale de funcionare

18



19/77

Testarea la stressmotivaie

Defectarea unui sistem critic poate avea consecine dezastruoase

Timpul i resursele dedicate testrii tradiionale nu sunt suficiente

Nu se pot determina toate modurile n care va fi folosit sistemul,de exemplu un sistem de operare va rula aplicaii care nici nu exist

n momentul testrii Utilizatorii vor rula sistemul pe calculatoare cu mai puine resurse

dect cele folosite pentru testare

Concurena este dificil de testat cu metode tradiionale, de exemplurace 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 neviden scurgerile de memorie sau folosirea incorect a resurselor

19



20/77

Discuie

Testarea la ncrcare variaz condiiile de operare,de exemplu numrul de utilizatori, de tranzacii etc.,meninnd constant configuraia

Numrul de tranzacii cu 2000, 3000, 4000 de utilizatoriconcureni

Testarea la stress presupune condiii extreme sauanormale, de exemplu resurse diminuate sau prelucrriintense Numrul de tranzacii cu 2000, 3000, 4000 de utilizatori

concureni, cu memorie foarte puin pe server, vitez mic areelei etc.

20



21/77

Testarea volumului

Presupune expunerea produsului la un volum marede date

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

cu 1000 de componente

Un procesor de test care primete un document cu 2000

de pagini Scopul este s arate c programul nu poate

gestiona volumul de date specificat n obiective

21



22/77

Accepiuni alternative

Testarea la stress implic un element de timp: supunereasistemului la o ncrcare foarte mare pentru o perioad scurtde timp Aplicabil mai ales pentru programele care opereaz la ncrcri

variabile, interactive, n timp real: aplicaii web, programe de control etc. Exemple:

Dac un sistem poate gestiona maximum 15 task-uri simultan, testareala 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 simuleazintrarea simultan a unui numr mare de avioane n raza sa de aciune

Pentru un sistem de control al proceselor, toate procesele monitorizategenereaz semnale simultan

22



23/77

Accepiuni alternative

Analogie: evaluarea unei dactilografe Testarea volumului: dac poate face fa unui

raport de 100 de pagini

Testarea la stress: dac poate scrie la o rat de50 de cuvinte pe minut

23



24/77


engl. usability testing

ncercarea de a descoperi probleme legate de factoruluman, de utilizarea sistemului

Consideraii: Interfeele cu utilizatorul trebuie s fie potrivite pentru profilul

acestuia

Ieirile trebuie s fie uor de neles

Mesajele de eroare nu trebuie s reflecte detalii interne de

programare Interfeele trebuie s aib integritate conceptual, coeren

24



25/77


Consideraii: Cnd acurateea este vital, intrrile trebuie s aib suficient de

multe elemente redundante, de exemplu numr cont, numetitular, PIN etc.

Sistemul nu trebuie s conin un numr excesiv de opiuni.Accesarea lor trebuie s fie logic i intuitiv. Se pot prezentadoar opiunile folosite frecvent

Sistemul trebuie s prezinte notificri pentru primirea intrrilor.Dac o operaiune este de durat, utilizatorul trebuie informat

Sistemul trebuie s fie uor de folosit. De exemplu, dac intrrilesunt case-sensitive, utilizatorul trebuie s cunoasc acest lucru,sau ntr-o succesiune de meniuri sau ferestre, utilizatorul trebuies tie cum s se ntoarc la meniul principal

25



26/77

Testarea securitii

engl. security testing

Trebuie imaginate cazuri de test care s corupsistemul de securitate

Se pot studia probleme de securitate cunoscuteale altor sisteme i se ncearc demonstrareaexistenei lor n sistemul testat

Aplicaiile web necesit n general un nivelsuperior de securitate, mai ales site-urile decomer electronic

26



27/77

Testarea stocrii

engl. storage testing

Unele programe au obiective de stocare,referitoare de exemplu la volumul de memorie

folosit sau la dimensiunea fiierelor temporare Trebuie imaginate cazuri de test care arat c

programul nu ndeplinete aceste obiective

27



28/77

Testarea configuraiei

engl. configuration testing

Sistemele de operare, sistemele de management al bazelorde date, aplicaiile de transmitere de mesaje/pachete trebuies suporte o mulime de configuraii hardware

Dispozitive de intrare-ieire

Linii de comunicaie

Dimensiuni diferite ale memoriei

De multe ori, numrul configuraiilor posibile este prea marepentru a fi testat fiecare combinaie n parte

Trebuie testat sistemul cu fiecare tip de dispozitiv hardware icu configuraiile minime i maxime

28



29/77

Testarea compatibilitii

engl. compatibility testing

Multe sisteme nu sunt complet noi, ci trebuie snlocuiasc sisteme mai vechi sau cu probleme

Pot exista obiective specifice privindcompatibilitatea cu sistemele existente, sauprocedurile de conversie a datelor

De exemplu actualizarea unui sistem de managemental bazelor de date

29



30/77

Testarea instalabilitii

engl. installability testing

Unele sisteme software au proceduri complicatede instalare

Instalarea este primul contact al utilizatorului cusistemul. O instalare defectuoas l poate

mpiedica s foloseasc n mod adecvat

produsul software, s aib ncredere n el, sau lpoate determina s aleag un alt produs

30



31/77

Testarea ncrederii

engl. reliabiliy testing

n general, scopul tuturor tipurilor de testare este cretereancrederii

Testarea ncrederii poate fi dificil Un WAN sau un ISP pot avea ca obiectiv un timp de funcionare de

99,97% (engl. uptime)

Este greu de imaginat cum s-ar putea testa sistemul timp de ctevaluni sau ani

Se poate calcula timpul mediu ntre defectri Exist metode formale de demonstrare a corectitudinii unui

program. Trebuie demonstrat i c programul se va termina.n cazul general demonstrarea este imposibil, dar se poaterealiza pentru anumite cazuri particulare

31



32/77

Testarea recuperrii

engl. recovery testing

Sistemele de operare, sistemele de management albazelor de date, programele de teleprocesare au de

obicei obiective de recuperare, care arat cum trebuie sreporneasc sistemul dup defeciuni legate deprogramare, de hardware sau de date

Testarea presupune crearea (simularea) unor condiii deeroare n mediul extern de execuie

Testarea i propune s arate c: Funciile de recuperare nu lucreaz corect

Sistemul nu respect timpul mediu pentru recuperare asumat

32



33/77

Testarea documentaiei

engl. documentation testing

Documentaia este folosit ca un ghid pentruscrierea cazurilor de test la testarea sistemului

Documentaia utilizatorului trebuie s fieinspectat (ca i codul), analizndu-i-seacurateea i claritatea

33



34/77

Testarea procedurilor

engl. procedure testing

Multe produse software sunt parte a unorsisteme 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



35/77

Executarea testrii sistemului

Cine trebuie s testeze sistemul Pe ct posibil, nu programatorii

O echip format din: experi n testare, inginer de factori

umani (human factors engineer), 1 sau 2 utilizatorireprezentativi, analistul sau proiectantul aplicaiei

Pe ct posibil, nu organizaia dezvoltatoare Aceasta nu are de fapt motivaia s demonstreze c produsul

nu ndeplinete obiectivele

Cel mai economic mod de a realiza testarea sistemului(gsirea numrului maxim de erori cu un anumit cost sau uncost mai mic pentru descoperirea aceluiai numr de erori)este subcontractarea ctre o alt organizaie

vezi i principiile 2 i 3 spre sfritul cursului35



36/77






37/77

Ciclul de via al unui defect

De cele mai multe ori, persoana care raporteazun defect este diferit de cea care l repar

Un proiect mare poate include mii de defecte

n astfel de situaii, raportarea i reparareanu pot fi fcute informal: un defect ar puteafi uitat i/sau redescoperit ulterior cu un efort

suplimentar

37



38/77


Formal, cnd un defect este descoperitde ctre oricine estenregistrat (logged) ntr-un sistem de control al defectelor

Defectul este n starea trimis(submitted)

Repararea defectului este atribuit unei persoane, de obicei

programatorul iniial, care realizeaz depanarea (debugging) Defectul este n starea reparat (fixed)

Se verific dac defectul a fost reparat cu succes

Defectul este n starea nchis (closed)

38



39/77


Ciclul de via poate fi mrit sau micorat n funcie denatura proiectului

Pentru proiecte mici, un defect poate fi doar deschis

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

multe faze de urmrire

Defectele sunt deseori clasificate, pentru a le nelege

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

interfaarea componentelor, performane, documentaie

39



40/77

Clasificarea dup severitate

n multe organizaii se folosete o clasificare adefectelor pe 4 niveluri: Defecte critice: afecteaz muli utilizatori, pot ntrzia

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

mare de lucru pentru a le repara, dar nu afecteazsubstanial graficul de lucru al proiectului

Defecte minore: izolate, care se manifest rar i au unimpact minor asupra proiectului

Defecte cosmetice: mici greeli care nu afecteazfuncionarea corect a produsului software

40


E l d i i


41/77

Exemplu: descoperirea i

nchiderea defectelor

n figur, distana dintre numrultotal de defecte i numruldefectelornchise crete

Activitatea de dezvoltare trebuie

ncetinit i trebuie alocate maimulte resurse reparrii defectelor

Pentru un proiect gestionatcorespunztor, numrul dedefecte deschise ar trebui s se

reduc spre sfritul proiectului,chiar dac nu este obligatoriu cavariaia s fie monotondescresctoare

41



42/77






43/77

Analiza i prevenirea defectelor

La nivel organizaional, analiza defectelor poatembunti listele de verificare, procesele sauinstruirea personalului

La nivelul proiectului, se nva din defecteledescoperite pn la un moment dat pentru a prevenipe ct posibil defectele din restul proiectului

Prevenirea defectelor

Crete calitatea: sistemul final va avea mai puine defecte Crete productivitatea: se consum mai puin efort pentru

repararea defectelor

43



44/77

Analiza Pareto

Se bazeaz pe aa-numita regul 80-20: 80% din probleme vin din 20% din sursele posibile

80% din efecte sunt determinate de 20% din cauze

Pentru un produs software: 80% din defecte apar din20% din cauzele eseniale sau 80% din defecte segsesc n 20% din cod

Se realizeaz o diagram Pareto cu numrul de defectede diferite tipuri

Diagrama identific tipurile principale de defectedescoperite, care au o mare probabilitate de a se regsii n restul proiectului, dac nu se iau unele msuri

44



45/77

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



46/77

Analiza cauzal

Diagrama Pareto identific tipurile principale de defecte(pot fi considerate efecte)

Analiza cauzal are scopul de a identifica principalele cauzeale acestor efecte

nelegerea cauzelor ajut la identificarea soluiilor pentrueliminarea 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



47/77

Exemplu: diagram Ishikawa

47

cauze

efectul

sub-cauze


D lt i i l t


48/77

Dezvoltarea i implementarea

soluiilor

n aceast faz, se gsesc soluii pentruatenuarea cauzelor descoperite, tot prinbrainstorming

Soluiile gsite trebuie apoi implementate Trebuie tratate ca activiti ale proiectului

Este important verificarea efectelor soluiilor,

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

De exemplu, analiza defectelor dup implementareasoluiilor

48



49/77

Exemplu

49



50/77

Intensitatea defectrilor n timp

50

0= intensitatea iniial a defectrilor

0

= numrul total de defectri

Dacnu se cunosc aceste valori, nu se poateestima ncrederea produsului software



51/77






52/77

Testarea extrem

eXtreme Programming (XP), Kent Beck, 1996, Daimler-Chrysler

Metodologie agilde dezvoltare software

A facilitat adoptarea noilor limbaje de programare, precumJava i C#, pentru dezvoltarea rapid de aplicaii

Aplicaiile se creeaz mai uor i mai rapid, ns nu estegarantat calitatea

Scopul XP: programe de calitate ntr-un timp scurt

Se bazeaz pe testarea unitilor i pe testarea de recepie(acceptance): cazurile de test se realizeaz nainteacoduluipropriu-zis

52



53/77

Caracteristicile XP

Arhitecturi simple, comunicare ntre dezvoltatori i clieni,testare permanent, refactorizare

XP funcioneaz bine pentru proiecte mici i medii,cu schimbri frecvente ale specificaiilor i undecomunicarea rapid este posibil

Evit stabilirea tuturor detaliilor de la nceput, permiteschimbrile cerinelor

Se evit funcionalitile care nu sunt absolut necesarela un moment dat

Accentul cade pe funcionalitatea ce aduce valoarepentru client

53



54/77

Testarea extrem

Reguli: Toate modulele trebuie s aib testele nainte de scrierea codului

Toate modulele trebuie s treac toate testele nainte de a fi lansatsistemul

Dificulti: Cum poate fi scris un test pentru un cod inexistent

Cum afecteaz scrierea acestor teste termenul limit

Beneficii: ncrederea c programul va respecta specificaiile

Exprimarea rezultatului final nainte de implementare nelegerea mai bun a cerinelor i specificaiilor

Se poate ncepe cu o arhitectur mai simpli apoi codul se poaterefactoriza fr teama nerespectrii specificaiilor

Automatizarea testrii (de exemplu cu NUnit, JUnit etc.)54



55/77

Exemplu

55



56/77

Cazuri de test

56



57/77



58/77



59/77



60/77



61/77

61

1

1



62/77



63/77

Rezultatele testrii cu NUnit

63



64/77






65/77

Principii de testare

1. O parte necesara unui caz de test estedefinirea ieirii sau rezultatului ateptat Dac nu este definit rezultatul ateptat, un rezultat

plauzibil, dar greit, poate fi interpretat drept corect Ochiul vede ce vrea s vad dorin subcontient

de a vedea un rezultat corect

Un caz de test trebuie s aib:

O descriere a datelor de intrare O descriere precis a rezultatului corect corespunztor datelor

de intrare respective

65



66/77


2. Programatorii nu ar trebui s-i testezepropriile programe Programatorul tie ce ar trebui s fac o secven de cod i nu i d

seama cnd face altceva

Programatorul are o perspectiv constructiv (proiectare/implementare);testarea necesit o perspectiv destructiv

Programatorul poate evita n mod subcontient gsirea erorilor, de fricaefului/colegilor/clientului etc.

Programul poate conine erori deoarece programatorul nu a neles

specificaiile i testele vor suferi de pe urma acestor nenelegeri Principiul nu spune c un programator nu i poate testa propriul cod,

ci c testarea este fcut mai eficient de altcineva

Depanarea (debugging) este fcut mai eficient de programatorul iniial

66



67/77


3. Organizaiile nu ar trebui s-i testezepropriile programe Performanele organizaiei i ale managerului de proiect sunt

deseori msurate drept capacitatea de a termina proiectul la odat limit i cu o limit de cost

Timpul i costul sunt uor cuantificabile, ns ncredereaprogramuluinu

Testarea corect scade probabilitatea atingerii obiectivelor decost i de timp

Nu este imposibil ca organizaiile s-i testeze propriileprograme, ns o testare obiectiv, independent, poate cretecalitatea programului

67



68/77


4. Rezultatele fiecrui test trebuie inspectateamnunit Numeroase experimente au artat c unele erori nu

sunt detectate, dei simptomele lor puteau fi clarobservate n testele anterioare

Multe erori descoperite la un moment dat ar fi putut fidetectate din rezultatele testelor anterioare

68



69/77


5. Trebuie scrise cazuri de test att pentrucondiii de intrare invalide i neateptate, ct ipentru condiii de intrare valide i ateptate

Exist o tendin natural ca testerii s seconcentreze pe condiiile de intrare valide i ateptate(scenariile normale de funcionare ale programului)

Multe erori apar dup livrare din cauza utilizrii

programului ntr-un mod neateptat Testarea condiiilor neateptate detecteaz mai multe

erori dect testarea condiiilor ateptate

69



70/77


6. Programul trebuie examinat pentru a vedeadac nu face ce trebuie; de asemenea, trebuieexaminat pentru a vedea dac face ce nu

trebuie Programele trebuie examinate pentru detectarea

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

pentru salariai inexisteni sau terge prima nregistrare dinbaza de date a personalului

70



71/77


7. Cazurile de test abandonabile trebuie evitatedac 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 dupefectuarea unor schimbri n program: testarea deregresiune

71



72/77


8. Efortul de testare nu trebuie planificat cupresupunerea tacit c nu se vor descoperi erori Presupunerea greit c testarea arat c programul

funcioneaz corect

72



73/77


9. Probabilitatea s existe erori suplimentare ntr-oseciune a programului este proporional cu numrul deerori deja descoperite n acea seciune Erorile tind s apar n grupuri

Unele seciuni ale programului sunt mai predispuse la erori dectaltelepot fi seciuni mai dificile sau seciuni unde a lucrat opersoan mai puin pregtit

De exemplu, un program are 2 module, A i B. n modulul A s-audescoperit 5 erori iar n B doar 1 eroare. Dac A nu a fost supus

unei testri mai riguroase, atunci probabilitatea de a gsi maimulte erori n A este mai mare dect probabilitatea de a gsi maimulte erori n B

73



74/77


9. Probabilitatea ca mai multe erori s existe ntr-oseciune a programului este proporional cu numrul deerori deja descoperite n acea seciune

74

Relaia surprinztoaredintre numrul de erorirmase i numrul deerori descoperite



75/77


10. Testarea este un proces definit decreativitate i provocri intelectuale Creativitatea necesar pentru testare probabil

depete creativitatea necesar pentru proiectare

75



76/77

Concluzii

Testarea detecteaz nu numai erorile de implementare,ci i pe acelea de analiz i proiectare

Testarea este o metod dinamic de verificare ivalidare, unde un element (un modul sau sistemul ntreg)este executat i i se observ comportamentul

Testarea se bazeaz pe un plan, care ghideaz ntregulproces: Specific nivelurile testrii i elementele testate

Cazurile de test specificate sunt inspectate i apoi executate Rezult raportul de testare (cazurile executate) i raportul erorilor

descoperite

76



77/77

Concluzii

Niciodat nu putem fi siguri c specificaiile sunt 100%corecte

Niciodat nu putem fi siguri c un instrument de testareeste corect

Niciun instrument de testare nu poate fi folosit pentrutoateprodusele software

Testerii nu pot fi niciodat siguri c neleg complet unprodus software

Niciodat nu putem fi siguri c testarea unui produssoftware este complet

ingineria programarii: faza de testare 2

Documents