Capitolul 3: Metode, tehnici

Problematica activit asocia

testare

a constituit decembrie 1999 subiectul Association of Computing Machinery (ACM), care s-au ocupat de principiile, standardele, metodele, instrumentele, -lui presupune ca:

procesul de dezvoltare eles; proiectele s planificate; modelele ciclului de viata sunt definite; standardele s definite at t pentru produs c t i pentru proces; unit ile de m sur sunt definite pentru evaluarea produsul izare a componentelor; procesele de validare calitatii; i verificare in asigurarea calit , training-ul si certificarile necesare. rocesul de dezvoltare a software-ului se poate

Pe scur

Figura 3

-lui

Dup

i curente generate de Activit de verificare programare specifice derulate anterior sPrin validare constate dac

3.1.

Elemente conceptuale al

. Prin testare (IEEE) unui set de unul sau mai multe cazuri de testare (test cases) 2

e conformitate1 . activit de verificare i de validare. plu: procesul executarii unui program sau sistem cu intentia de a gasi erori (Myers, 1979), procesul de stabilire a itatii un program sau sistem face ceea ce ar trebui ice (Hetzel, 1984),

procesul de operare asupra unui sistem nd sau nregistr i f nd o evaluare a unor aspecte ale sistemului (IEEE, 1990), procesul rii, pr rii pentru a stabili caracteristicile un i pentru a determina diferenta dintre i cel solicitat de beneficiar (Pol, Van Veenendaal, 1995), procesul prin care se demonstrea (Evans, Mills, Warden, 1996), un siste u

procesul care const din toate activit ciclului de via al produsului n leg tur cu verificarea software-ului a produselor auxiliare (Hetzel and Gelperin, 1997), procesul utiliz rii aplica iilor informatice pentru a verifica c satisface anumite solicit ri specifice i pentru a detecta erorile (BS7925-1, 1998).

Dictionary, a verific rturie; (2) s

. Conform Webster's New World sa dovedesti ca este adevarat prin demons verifici acuratetea sau corectitudinea prin investigare, comparare cu .

Cu alte cuvinte, verificarea este procesul de evaluare a unui sistem software sau a unei componente n timpul sau la sf r itul ciclului de dezvoltare,

1 Hutchenson, M., Software Testing Fundamentals: Methods and Metrics, John Wiley & Sons, 2003, pg 17

cerintele codului cu cazuri de test. verificarea de fapt conformarea la specifica ntrebarea: Face sistemul ceea ce ar trebui sa faca? sau Dezvolt m noi produsul n modul potrivit? Webster's New World Dictionary defineste validarea ca fiind starea, calitatea sau faptul de a fi valid in conformitate cu o lege printro argumentare logic. Validarea este procesul prin care testerul confirm c un lucru este executat cum trebuie. Aceasta validare din partea testerului roprie. ... Prin validare se r spunde rile: Este corect ceea ce face sistemul? sau Dezvolt m noi produsul potrivit ? Cu alte cuvinte, validarea este procesul evalu rii unui sistem sau componente software pentru a determina dac rezultatul u plineste conditiile impuse la inceputul acelei faze. Ea este asociat de obicei cu activitati ca inspec i revizuirile nformatice.

Testarea versus Debugging. estare i debugging-ul. Debugginglocalizare a gre elilor procesului de testare (

sau late la primul nivel de organizare a )

au 1. localizarii greselii sau defectului, 2. repararea codului 3. retestarea codului.

ncepe d ioneaza cum s-

iar testerii . Astfel, debugging-ul

ctivitatea de debugging apare n testarea structural (de tip white box) a tre programatori. Pentru a fac ia suporte mai multe n particular un mod de debug pentru a ajuta programatorii sau uneori testerii s problema c nt lnesc. Exista mai multe tipuri de debugging iilor informatice, astfel: 4

1. inspectarea codului, 2. configurarea log-urilor in modul DEBUG, 3. debugging real (de exemplu in Visual Fox Pro, Visual Basic). : Pentru tipul 3 de debugging este nevoie de anumite unelte de debugging, in cazul in care aplicatia nu are integrata o astfel de unealta. Aceste unelte permit programatorilor ie, 2 examineze variabilele programului . Principii de testare. este necesar a se respecta o serie de principii,

1. 2. Principiul . 3. 4. 5. . 6. Rezultatele asteptate trebuie definite de la inceput. Astfel, chiar daca nu stim ce comportament al aplicatiei asteptam de la bun inceput. 7. Principiul complementar invalide, deoarece Comportamentul neasteptat poate produce bug-uri neasteptate. 8. Principiul rerebu dac cazurile de test sunt reutilizabile sau nu test rii regresive. 9. 10. Daca activitatea de testare vor costa mai putin (costul testarii creste direct proportional cu avansarea produsului de-a lungului ciclului sau de viata). Tipuri de neconform cu clasificarea urmatorii termeni :
3

lor,

te astfel

2 pg 96 3

Elfriede D., Effective software testing : 50 specific ways to improve your testing, Addison-Wesley, 2003, Jorgensen, P., Software Testing: A Craftman's Approach, CRC Press, 1995, pg 7

1. Eroare (Error). Programatorii numesc erorile se propage cerin cand trece n faza de proiectare i se amplific mult n rii. 2. Defect, vinovatie (Fault) Defectul este rezultatul unei erori. Putem vorbi despre defect datorat comiterii i defect datorat omiterii. Defectul datorat comiterii apare cand date) este incorect . zator care subscribe. Concret: s-au parcurs toate

(ulterio

Defectul datorat omiterii apare c nd ca

, iar . Spre exemplu, i

0 sau 18), ceea ce va conduce la un defect prin omitere la introducerea datelor. Defectul datorat omiterii este dificil de localizat. 3. Insucces (Failure) nd vina -a proiectat din Insuccesul mod vizibil ca urmare conduce la prevenirea unor asemenea insuccese. 4. Incidentele (Failure) Un incident este o simpt ui insucces. evizuirile cod pot

cu

folosi o serie de standarde Exista o varietate de surse pentru norme, standarde si ghiduri: Standardele interne ale companiilor Cele mai bune practici (best practices) Standarde de management al calitatii: ISO 9001; ISO/IEC 12207 (adoptat ulterior IEEE) Standardele de ramura: FDA, US Dep. Of. Defense Mil STD 498:1994, DO 178B... Standarde de testare a software-ului: BS 7925-2 (The Software Component Testing Standard), IEEE 828 (Plan de configurare); IEEE 829 (Documentatie), IEEE 730 (SQA Plan), ISO/IEC 11504; ISO/IEC 9003; ISO 9646, TMM, TickIT(UK la nivel national: metodologie la ISO 9001)

3.2.Etapele activit ii de testare

Activitatea propriue pent ce s-a realizat efectiv. - comparare identificare problem. Spre exemplu, de testare efectiv din momentul n care testerul

etape4: 1. Planificarea testarii 2. Specificatiile testarii 3. Executarea testarii 4. Evaluarea testarii 5. nregistrarea testarii 3.2.1. Planificarea testarii

4 Ratzman, Manfred, De Young, Clinton, Software testing and Internalization, Lemoine Internationa l and the Localization Industry Standards Association (LISA), 2003, pg 30

In etapa de planificare a test

se planific

componentele unui proiect de testare i de Testare

1. 2. 3. 4. 5. 6. 7.

Identificare i introducere Elemente de testare, cum sunt: obiecte de testare, nivelul de risc, documentatia testat; Criteriile de testare; Criteriile de finanlizare cu succes/insucces; Criteriile de suspendare/reluare a testului; Teste livrabile (de distribuit);

8. Necesit ile mediului; 9. Organiza ia (personal, pregatire, planificare responsabili); 10. i program; 11. Riscurile proiectului de testare. Tot idei cadru: p rii a n testare, la nivel organizational un aspect deosebit de

Fiecare proiectant functional proietant de teste executant de teste verificator de teste

de testare este un avantaj in cele mai multe cazuri din punct de companiile mici cu un grad mare de complexitate, uneori o echipa integrala de testeri este mai potrivita; Pentru un proiect parametrizabil subcontractarea este cea mai adecvata metoda de testare; Nu exista modele standard de utilizat pentru estimare; Efortul alocat pentru teste, de obicei este de cele mai multe ori subevaluat; 8

un procent din efortul de dezvoltare; Putine date istorice pot deveni precise;

Cazurilor de test ce trebuie rulate; Testerilor care vor rula cazurile de test; Momentelor de rulare a testelor.

3.2.2
In timpul acestei etape se va

Cu alte cuvinte, testele trebuie organizate pornind de la (feature). estele pot -au acoperit cu cazuri de test

nu

rezultatele ulterioare.

de testare vor diferi. 1. Proiectarea cazurilor de test 2. iile cazurilor de test 3. iile regulilor 4. Selectarea tehnicilor de design

1. Proiectarea cazurilor de test test case-urilor) se poate folosi metoda standard (Tmap, 1995), prin care se deriv cazurile de test . metoda -zise a cazurilor de test, metoda folosita pentru a deriva sau a selecta cazurile de test (BS 7925-1: Glossary of Software Testing Terms Source : BS 7925-1: Glossary of Software Testing Terms http://www.vietnamesetestingboard.org/zbxe/) 2. Specificatiile cazurilor de test Specificatiile cazurilor de test Cazurile de test stabilite sunt incluse n STP (Planul de Testare a Softwarea. b. Se stabilesc elementele de acoperire a testului pentru toate cazurile la care face referire acel test; c. Se stabilesc datele de intrare ale testului; d. ; e. f. 3. Specificarea regulilor presupune definirea urmatoarelor aspecte: Criteriile clare pentru stabilirea st rii zut (pass/fail) Metoda pentru masurarea rezultatelor; Rezultatele asteptate bazate pe cerintele clientului; Numarul minim de cazuri de test necesar ca s e: Acelasi caz de test nu trebuie scris de mai multe ori; Cazurile de test trebuie s Cazurile de test trebuie prioritizate; Cazurile de test treb fie clare i repetabile; ele sistemu

4. Stabilirea tehnicii de design (BS 7925-2 (The Software Component Testing Standard)) 10

a. Tehnica de design aferenta metodei Black-box: (boundary value), Graficele cauza-efect. b. Tehnica de design aferenta metodei White-box: ilor, Acoperirea ramurei decizionale, pe valori limit Acoperire structural ,

Testare pozitiva si negativa a Testarea poziti ? Verificarea acoperirii cerintelor, Verificarea disponibilitatii facilitatilor (feature-rilor) din sistem. Testarea negativa se focalizeaz pe Ce nu sunt acoperite? Unde se pot identifica greseli (localizarea erorilor) ? Acoperire structural a testului Tehnicile de acoperire structural n selectarea cazurilor de test cu obiectivul de a ine acoperirea testului. Astfel, se o parte din software-ul care a fost testat/executat. Zonele din program pentru care se calculeaz acoperirea sunt zonele: declarative, de decizie, de scriere, de memorare etc. fiecare declara o toate iesirile posibile ale fiecarei decizii vor acoperite prin cazuri de testate Acoperirea (ramurei)decizionale reprezinta un punct din program la care are 2 sau mai multe rute. Astfel, acoperirea decizionala reprezinta procentul rezultatelor decizionale care au de cazuri de test. 11

Design testare

Codificare

Caz Test

Fig 3.2 Tehnica de acoperire pentru a se lua decizii bine fundamentate iilor, trebuie studiate cu atentie toate aceste tehnici, tipurile de i riscurile).

sistem

tepta

3.2.3. Executarea testului

Etapa de executare a unui test 1. Pregatirea mediului de testare; 2. Completarea rezultatelor; 3. Determinarea rezultatelor testului. i:

Mediul de testare este un factor important are se un test trebuie repetat frecvent, spre exemplu

snimic). Atunci pentru a conduce testul ntrun mod

12

interactiv

testarea doar prin intermediul GUI-ului n cele mai multe cazuri. Este posibil, ca -

ului sau

Spre exemplu, pentru programele care info a (prin intermediul testel grafic elei

o baz de date se impune distribuit pot necesita

de cele mai multe ori cazurile de test simple sunt cele mai

a. Testarea static : Examinari informale a codului, b. - testarea non; - re-testarea. Testarea non-formal - testarea sintaxei; - gasirea erorilor; - testarea de tip random.

formale (treceri in revista, inspectii tehnice

);

(load, stress etc)

3.2.4
inclusiv proceduri manuale. Rezultatul asteptat (corect) ar trebui sa fie usor de inregistrat pentru acest scop. Este necesar a se face se prezinte un rezultat corect. 13

acesteia. ap includ descrierea sarcinilor de dezvoltare (programare), precum i modelele de afaceri, graficele tranzactiilor din sistem i descrierile textuale ale sc ii de proiectare a GUI-ului, rapoarte listate, help on-line, manuale utilizator, manuale de instalare i alte materiale legate de acest subiect. Orice comportament care este documentat, poate fi testat direct.

a. Utilizarea unui expert acuratetea, n contextul unui domeniu specializat, fie f pentru acest scop. Astfel, aspectele so n descrierea sarcinilor, a help-ului on-line sau a manualelor utilizator unt tratate n detaliu. Spre exemplu, manualul de utiliza -contabil nu este proiectat cu scopul de a ne utilizarea acestei aplicatii specifice. b. Utilizarea unui soft de validare Este posibil sa avem un

atelor

test

creeaza un fisier XML, nu putem verifica

XML pentru a verifica daca este (well-formed). Este important ca programul de validare sa nu fie prea tolerant o eroare n documentul care este testat tolerat sau trecut cu vederea, deoarece aceasta va afecta negativ si evaluarea rezultatelor finale. c. Testul de verificare sesiunii de test avem doar output-uri din programul care este testat. comportament. trecut cu vederea daca instrument diferit. 14 mpurilor unei bazei de date poate fi programatorul nu va efectua un test de verificare a valorilor aferente e utilizeze un

3.2.5.

test rii

STP- software test plan (plan de testare a software-ului) STD- software test description (descrierea testarii software-ului) STR- software test result (rezultatul testarii software-ului) Documentul STP contine urmatoarele sectiuni: 1. 2. Elemente de testat, cum sunt: obiecte de testare, nivelul de risc, documentatia 3. 4. Criteriile de testare; 5. Criteriile de finanlizare cu succes/insucces; 6. Criteriile de suspendare/reluare a testului; 7. Teste livrabile (de distribuit); 8. Necesit ile mediului; 9. 10. 11. Riscurile proiectului de testare.

SQAP- software quality assurance plan (plan de asigurare a calitatii software-ului) ATP- automatic test plan (plan de testare automata) SPR- software problem report (raport in legatura cu problemele software-ului)

necesar Un incident de test este un eveniment care apare deie; 15

inci apar; Trebuie scris un singur incident de test ntrun raport ; Raportul trebuie sa fie concret; Esecurile ne costa (clienti nemultumiti, corectarea defectelor).

o str ii de testare; Nume SoftwareEviden raport); te ori se repet i statutul problemei detectate; Prioritatea i severitatea defectului. ierii raportului; i mediul de testare; (ecrane/log-uri ri) ate la

Explicarea elementelor care apar de obicei intr-un raport initiat cu ocazia aparitiei unui defect: Clasa defectului: eroare (proiectare, cerinte, manual), greseala (cod, BD), problema hardware; Status-ul greselii: nou, desc Prioritatea a pentru client (definit de catre managerul echipei de dezvoltare); Severitatea. Impactul potential al defectului (definit de catre managerul echipei de asigurare a calitatii). : Status-ul defectului, prioritatea i

3.3. Metode de testare

Procedurile de test difera in masura mare intre testele functionale si cele structurale. Denumirea traditionala pentru testele functionale este Black Box si pentru cele structurale White Box. Intre cele doua categorii care nu pot fi incadrate n nici una din cele dou categorii. Aceste teste angajeaz 16

i structural Gray Box. 3.3.1.

teste

Black Box -

formu Cu metoda Black Box, persoane din exterior vin n contact cu elementul de testat - un program/modul sau o unitate a unui program a. a propriuaplicatiei; b. a interna a modulului; c. descrierea INTRARE/IESIRE a unui proces ce functioneaza pe loturi de inregistrari (batch process). Cu alte cuvinte, testele de tip func Black Box) verifi

e, , i prin ghicirea Testele de acceptare ale produsului completate de client sunt de asemenea teste de tip Black Box. Ele verifica daca produsul este conform cu toate cerintele stabilite. Cazurile de test sunt create bazate pe descrierea sarcinilor. programatorului produsului p responsabilitatea a s acest proces de test nainte de lansarea In acest mod, se pot gasi greseli inainte de a le gasi clientul.

3.3.2 Testele de tip White Box(structurale) In cazul metodei White Box, mecanismele interne ale elementului de testat sunt cunoscute . implementa cel putin o data comportament corect. Examinarea rezultatelor testelor de tip White Box poate fi facuta pornind de la specificatiile sistemului in minte. Testele White Box inlocuiasca testele Black Box, ci doar sa elimine cea mai mare parte din erorile ce s17

3.3.3. Testele de tip Gray Box(functional-structurale) Testarea Gray Box a mediului cu care interactioneaza5 . Testarea Gray Box, la fel ca testarea Black Box, este concentrata pe acuratetea si dependenta intrarilor si iesirilor unui program sau modul.

de date. Testele de tip Gray Box folosesc adesea aceleasi unelte prin ca sa descopere erorile, ca cele pe care programatorii le folose vizualiarea structurii interne a programului. Testele Gray Box capata o importanta tot mai mare pe segmentul testarii componentelor, segment pe care nici testele Black Box, nici cele White Box nu il trateaza.

3.4. Strategii de testare

dezvoltare, este independent sau este organizat pe seama utilizatorilo cuvinte, depi dezvoltare sau independent.

. Cu alte n procesul de

3.4.1 Testarea exploratorie sau de explorare Daca nu suntem familiari cu programul care trebuie testat, atunci -numita metod rii Particularitatea acestei s cazurile de test Astfel, rezultatele obtinute din primul caz de test ne vor ajuta s definim cazurile de test ulterioare.

rategie de testare exploratorie, procesul de cunoa a programului, de

Lemoine International and the Localization Industry Standards Association (LISA), 2003

18

nu ie impresie la prima vedere ca i unui utilizator final.

te

testat aceeasi

t pentru un . Eventualele probleme identificate la procesarea datelor blocajele ap rute pe tea testerului. Pe

testarea de guerilla care /modul /modului astfel . testare. 3.4.2 Strategia de t ire/reglare Din practica de specialitate seconstat presupune ca testarea si corectarea erorilor u fie separate estare

a subiect al

estarea i dezvoltare. probleme identifica nici o ne fie lansat, dezvoltatorul testeaz /

de totul se , defect sau

3.4.3 Strategia de testare prin utilizare Strategia de testare prin utilizare constituie una din cele mai prolifice strategii de testare, proces adaptativ de dezvoltare de software,

19

determinate n cea mai mare m sur de aspecte de continut. Strategiile utilizate pentru a testa de cele folosite pentru a testa aspectele formale. a fost declarat relativ robust erori, aceasta poate fi folosit . Astfel, doar prin utilizare, ri importante care ar putea n timpul unui proces adaptativ, cum sunt: Este rat folositoare ? it gradul de utilizare ? i (feature) lipse i care dintre acestea ar putea face din aceast rat deosebit ? software-ul toate (sau macar cele mai importante) workflow-uri ? Sunt termenii de speciali Este i domeni i? i plictisitor ? n software ?

i sau sunt plicti i ? Strategia de testare prin utilizare trebuie sa se desf un mediu de exploatare propriunuit nu un laborator de specialitate. un proiect rii live sau a testarii beta este in mod normal planificat nainte de lansarea produsului. In proiecte mai mici, dar la fel de riscante pentru dezvoltatori, ramas ntr faz de testare beta. estarea prin utiliza i n cadrul urmatoarelor faze ale proiectului: faza de modul sau de componenta. ester-ul s fie prea familiarizat cu modul de dezvoltare al aplicatiei care este testata acum. Ca sa evalueze o idee, cineva de a ce ia programului. De aceea este mai simplu si mai efectiv, sa existe oameni pe proiect, concentrati in mod principal pe testare. Aceasta nu inseamna ca testerii nu pot avea si alte roluri in proiect. Analiza si relatiile cu clientii sunt responsabilitati care se pot suprapune foarte bine cu indatoririle unui tester. Pe de alta parte, testerii trebuie sa se distanteze cat mai mult posibil de design si de activitatea de codare a produsului. 3.4.4 Testare prin documentare Scriind documentatia utilizatorului avem o alta oportunitate sa aplicam testarea prin utilizare. Crearea documentatiile utilizator nu ar trebui sa treaca in responsabilitatea programatorului, ci mai de graba cuiva care a experimentat programul ca si utilizator. Facand aceasta vor creste sansele ca documentatia utilizator sa raspunda intrebarilor care chiar ii intereseaza pe utilizatori. Persoana care scrie documentatia trebuie sa cunoasca programul inainte de a scrie documentatia si sa primeasca tot ajutorul necesar de la programatori. Acest proces 20

reuneste indeaproape testarea de explorare, acest lucru in cazul in care documentatia nu se bazeaza pe descrierea sarcinilor sau pe alte documente de analiza. Intr-adevar, cel care scrie documentatia ar trebui sa intrebe aceeasi intrebare de fiecare documentatia trebuie deci sa fie in stare sa execute o secventa completa de comenzi. Deci este mai bine ca ei sa aiba la dispozitie o versiune functionabila a programului mai de graba decat o serie de screenshot-uri. Ei trebuie sa fie gata recunoasca problemele si li se permita sa le investigheze. Pe langa la a avea acces deschis la programatori, ei trebuie sa aiba un cuvant de spus si de fiecare data cand programul pe care il documenteaza este evaluat. Cu alte cuvinte ei trebuie sa fie spre exemplu, cei care sa le spuna programatorilor de ce nu au facut functionabila combinatia de taste CTRL+C pentru a copia text. 3.4.5 Testare regresiva Cand comportamentul unui program se schimba in rau dupa o modificare sau o adaugare, aceasta se numeste regresie. Scopul testelor de regresie este de a aduce la lumina o astfel de schimbare in rau. Scopul principal al testarii regresive este de a asigura ca toate facilitatile fara bug-uri raman in acelasi fel. In plus, bug-urile care au fost fixate odata ar trebui sa nu se intoarca in versiunile ulterioare ale programului. Deoarece testarea regresiva ar trebui sa se repete dupa fiecare modificare a software-ului, sau in cele din urma, inaintea urmatoarei lansari a produsului dorinta de automatiza aceste teste este puternica. Cem Karner si altii puncteaza in Lessons Learned in Software Testing [Kaner et. Din cauza cheltuielilor mari, nu este o idee buna ca toate testele care au descoperit vreodata vreo eroare, sa fie promovate la nivelul testarii regresive. O metoda mai simpla si mai buna de a reduce riscul ca o eroare sa apara intr-o versiune ulterioara este de a folosi Sistemele de Control a Codului Sursa (Source Code Control Systems SCCS). Testele bune de regresie acopera un numar mare de facilitati externe si interne. Testele de verificare a punctelor cheie, (Spot check test- descrise intr-o sectiune de mai jos) functioneaza bine ca si teste de regresie cand acopera o arie larga de intrari de date validate. Daca tipurile de date procesate fara dificultate in versiunile anterioare cauzeaza acum probleme, acest comportament ne ofera indicii pretioase pentru a gasi potentialele erori din programe. Testele de performanta de asemenea se apropie de testele regresive. Daca timpul de executie al unei tranzactii pe acelasi computer deviaza semnificativ in sus sau in jos in noua
6

6 Op cit in Ratzman, M., De Young, C., Software testing and Internalization, Lemoine International and the Localization Industry Standards Association (LISA), 2003, pg.46

21

versiune a programului, de exemplu cand programul devine dramatic mai rapid sau mai incet in realizarea unui anumit pas, atunci acest comportament trebuie analizat si cauza lui investigata. 3.4. a programului. Ele si-au luat numele de la fumul care se ridica metaforic din computer cand software-ul esueaza la una din aceste teste. Este vorba despre o serie limitata de teste regresive care se concentreaza pe functionalitatea de baza a programului. Daca software-ul nu trece aceste teste, nu este acceptabil si nu este lansat pentru nici un alt tip de testare ulterioara. Testele care produc fum sunt deseori automatizate. Ele apartin categoriei de teste pozitive, ele dorind sa dovedeasca ca o anumita functionalitate a programului exista si nici o eroare nu survine in acest caz. tot codul sursa lansat de catre programatori este combinat unui test fumigen automatizat. Alta varianta este de a delega de teste, direct programatorilor pentru a o folosi inainte programatori. Aceasta abordare este tot timpul atractiva dispersata de-a lungul a mai multe locatii. intr-un singur build si este subiectul aceasta responsabilitate a acestui tip de a-si lansa codul lor catre alti cand echipa de programatori este

3.4.7 Testarea n Embedded Testing) Testele care scot fum- sau mai general testele regresive pot fi incastrate direct in codul sursa. In multe limbaje de programare, in codul sursa exista niste declaratii care au rol de a testa preconditiile. Apoi departe sunt testate si postconditiile unei metode care devin preconditii pentru metoda urmatoare. Testand cu atentie precoditiile tuturor rutinelor sau metodelor este echivalent cu a conduce o regresie permanenta. Driverele de test sunt folosite pentru a ne asigura ca toate functiile care sunt testate au fost invocate.Driverele de test inregistreaza valorile returnate sau expresiile de tip catch. In legatura cu documentatia, testand preconditiile la inceputul unei functii ofera oportunitatea de a documenta corect aceste preconditii, informatiile oferite fiind mai multe decat simplele comentarii ale codului, ci descrierea comportamentului real al aplicatiei (fiind citibile cel putin pentru programatori). 3.4.8 Testarea in direct (Live Testing) Testarea in direct a sistemului este condusa de utilizatorii prospectivi, utilizatorii initiali, precum si de experti, programatori interesati de acest produs informatic etc. Cea mai cunoscuta 22

forma de testare live este testarea beta facuta inainte de lansarea oficiala a produsului. Insa avand in vedere modul in care sunt lansate produsele astazi, ar fi corect sa includem prima versiune oficiala in faza de testare in direct. Aceste teste masoara calitatea software-ului intr-un mod diferit fata de testele formale. In plus, testarea in direct, se concentreaza pe varietate- varietatea in diferitele moduri in care produsul este utilizat, in conditiile de mediu si in potentialele erori de operare pe care doar utilizatorii pot sa izbuteasca sa le faca. Acest nivel de varietate cu greu poate fi atins in laboratoarele de testare.

3.4.9. Testarea automata si uneltele de testare utilizate

ce activitatii de testare a produselor informatice. Sistemele software devin tot mai interesante de construit. Ele vor juca un rol tot mai important in societate. Noi metode, tehnici si unelte devin disponibile pentru a sustine dezvoltarea si sarcinile de mentenanta a acestuia.

cazul descoperirii efectelor laterale

fiind

. Testele ardware,

23

3.5. A. Testarea Introdu

1. 2. 3. 4. 5. 6.

P E E E C

r impuse de beneficiar (RB);

intrare Sold_in T, N, D, ... 8.2

RB

RF

RP

RC

AR

M1 C1, C2

M2 -

... ...

Mk Ck Ck+1

M7.

B. Analiza traiectoriilor de date dependente

Expresie Sold_fin_D SFD=SID+RD-RC

Date de intrare Nume TC SID C1..C k+1

Date intermediare Nume TC RD Crd1 RC Crc2

Machete Nume TC

Liste Nume Bal

Altele TC Cbal1

Nota 1

fiecare caz C. Analiza datelor prin tehnica valorilor l

func 24

acesta trebuie pentru toate valorile de mijloc.

cardului de credit. Pen trebuie efectuate pe ace a. T b. T corect. ;

teste ce

sursele serverului pentru alte sarcini mai importante. Visa sau MasterCard i

i. Validarea unui c Ca prim exemplu, vom folosi TVL pentru a ne

Set de date bazat pe BVA ={0,1,2,11,12,13} (6 puncte de date) 3.

testat un singur punct de mijloc, 6.

* valorile

25

2010 20 Set de date pe an bazat pe BVA = {2009,2010,2011,2019,2020,2021} Voi aplica din nou o pres *Presupunerea 3. Una dintre valori, 2011 sau 2019 doar punctul de mijloc, 2016, va fi testat. Set de date pe an bazat pe BVA = {2009,2010,2016,2020,2011}

-un proces de autorizare a creditului. continua cu acest exemplu, trebuie

ii. Tehnici de Reducere a Datelor Matriciale

utilizat

-ar putea ca reducerea

datelor. T 1. Nu ci doar pentru seturi de date. 2. Se folosesc suite de teste pentru a documenta reducerile de date.

n testarea efectua

s-a constatat

Pentru matricea de reducere a datelor, vom au fost create pentru a face un set de c . testa Vom crea o o matrice de seturi de date care va permite o telor pentru seturile de teste. 26

iii. Teste pe seturi de date

9,2010,2016,2020,2011}

Luna/ An 0 1 6 12 13

2009 2010 2016 2020 2021 FF AF AF AF FF FA AA AA AA FA FA AA AA AA FA FA AA AA AA FA FF F F F FF

Figura de mai sus control. m

ultatele lor din tabelul de

testelor pe seturile de date. Cu alte cuvinte, prin aplicarea acestei tehnici de reducere a datelor s-au redus testele BVA cu 31 de procente.

muchii De

date. Ne vom ad-

dorim

em

Putem utem

AA, AF, FA m -l , prin selectarea

testelor reprezentative.

27

Alegem Iar pentru 9 / 2 = 4,5 (rotunjind la 5) seturi care trec testul

2 seturi FT.

}, {12,2010}, {1,2020}, {12,2020 din centrul matricei {6,2016}.

documenta toate seturile de date.

. d se

iv. Tabel de control al seturilor de date 4.1

este posibil, voi construi seturile de date pentru a verifica autorizarea cardului de credit cu

Tabelul 4.1 Set de date 1 setul Este o valoare Este un tuturor datelor valabile, membru minim valabil al date acestui set de testat date Nume titular card 1. Prenume 1 2. Nume 1

de minim de de seturi de date de testat 1

1 28

4. Stat

1 1 1 1 1 1 1 1 1 1 10 1

6. Tip card

rat card REZULTAT:

Ipoteze de lucru

presupus acest lucru, dar s-

are loc validarea. Am fi testat astfel un s

-au

fi prelucrat cu ajutorul unei rutine

29

Toate aceste teste trebuie realizate pentru ambele carduri de credit:

alori de date

valabilitatea setului de date.

date. Amestecarea de data valabile din mai multe seturi conduce la invalidarea setului de date, cu -

putea valabil.

Avertismente

acest lucru. Tabelul 4.2 Tabel de validare a seturilor Set de date Card de credit # 1 1. (Toate valabile & set) 2. (Toate datele nevalabile) de date Rezultate test Date Valabile Nevalabile 30

set

Valabile Nevalabile

Rezultate teste seturi de date Valabile Nevalabile

3. Tip card set 4. # card set set 6. # verificare card

set

Valabile Valabile Valabile Nevalabile

Nevalabile Nevalabile Nevalabile Nevalabile

Nevalabile Nevalabile Nevalabile Nevalabile

4 acestui tabel, avem ceea ceocesul de validare a cardului, m

Procesul de construire

te ce

se utilizeaz frecvent: 1. em testarea celor mai importante trasee comp

2. construiesc rapid

3.

verific traseele

(1 set de data valabile + 5 seturi de date nevalabile) x 2 carduri de credit = 12 seturi de date rare: care nu este

31

Conform apro

4 mostre de teste. Tabelul 4.3 Inventar mostre teste 3 WebStore

Seturi date

Teste date Teste existente sistem 7 4 0 0

date

Rezolvare eroare # 123 Rezolvare eroare # 124 Meniu principal al Cel mai bun simulator de sistem Dispozitiv verificare flux date mesaj vizualizare pixeli

0 0

dispozitive Vizualizare monitor sistem portabil

traseu) 12 (seturi de date) 50 unele state (date) 3 Confirmarea comenzii Revenire la meniul principal Anulare 1 sesiuni Totaluri Total teste date 32 65 77 11 1

v. Avertismente

A at de probleme legate de profilul utilizatorilor.

Drop-Down
drop-down drop-down ca aceasta au contri panaceu. Recent, proprietarul unui magazin web pe care-l cunosc mdrop-down

site-am dat S-

putul de utilizator.

33

puncte de eroare din cadr verificarea pe profil, pe fiecare

construim seturile de date pornind de la ba

Ne folosim

-o bine

34