Facultatea de InformaticUniversitatea Al.I.Cuza - Iai

Ingineria Programrii Laborator 3

Adrian Iftene adiftene@infoiasi.ro

Introducere n Testare

CuprinsUnde ne aflm?Definiia i Scopurile Testrii SoftwareFapte i Numere

Dilema Calitii Software

CuprinsUnde ne aflm?Definiia i Scopurile Testrii SoftwareFapte i Numere

Testare Software - Definiie The process of exercising or evaluatinga system by manual or automatedmeans to verify that it satisfies specifiedrequirements or to identify differencesbetween expected and actual results.(IEEE Standard Glossary, 1983)

Testare SoftwareTestarea Software NU este o fazEste un proces care trebuie integrat n toate fazele construciei produsului softwareExist documente de testare asociate la fiecare faz a dezvoltrii

Care sunt Scopurile Testrii?De a localiza i preveni bugs ct mai curnd posibilDe a efectua toate Testele corespunztor Cerinelor, ntr-un mod ct mai eficient i mai economicDe a aduce produsul software la un nivel de calitate ct mai ridicat (pentru client) Toate acestea se execut folosind Metodologile de Implementare

De ce avem Bugs n Software?Comunicarea deficitar sau Blocajele de comunicarenelegerea deficitarPresiunea TimpuluiNivelul Programatorului este Sczut

Comunicare Deficitar

Comunicare Deficitar n tratarea Cerinelor

CuprinsUnde ne aflm?Definiia i Scopurile Testrii SoftwareFapte i Numere

De unde vin Problemele Software?Cerine definite Incomplet50%Modelare Ambigu sau Insuficient30%Erori de Programare 20%

Bugs - Costul FixriiCerineModelareImpl.Test. Int.Test.sist.Client

AtenieGsirea trzie a bugs un cost ct mai mare pentru a le fixa

Erori? Trebuie fixate ct mai Devreme Posibil CERINE MODELARE IMPLEM. TESTARE CLIENT

Testare ProfesionalProfesionalismul n testare const n abilitatea de a selecta numrul minim de cazuri de testare eficient ce va fi capabil s verifice numrul maxim de funcii ale sistemului.

Cnd Oprim Testarea? Niciodat Cnd numrul de erori gsite ntr-un ciclu de testare este mai mic dect un numr stabilitCnd nu mai sunt gsite defecte critice i majoreCnd timpul a expirat

Schema unui Sistem de TestareEchipa de TestMediul de TestareProcese de TestTestwareDesigns Acquires Configures Utilizes SupportProvides a Platform for the operation ofDetermine the usage ofDesigns Acquires Configures Utilizes SupportCreate Articulates Trains Applies Internalize

Metodologii de Testare

Coninut Diferena dintre testare SW i debug SWNivele de TestClase de TestConinutul TestriiTestare i Dezvoltare SW

Diferena dintre Testare SW & DebugTestare

Verificarea respectrii cerinelor

De regul e fcut de o entitate extern i neutr

Este un proces planificat i controlatDebug

Verificarea validitii seciunilor

E fcut de programator

E un proces aleator

Nivele de TestUnitate sau Debug.Modul/Sub-Sistem.Integrare.Sistem.Acceptare.

Clase de TestRegresie.Efecte Laterale.Redundan.Stres i Suprancrcare.Refacere.

BLACK BOX

WHITE BOX

STRExecuieSTDTRDSTP - Software Test Plan.TRD- Test Requirement Definition.STD - Software Test Description.Tests Execution or Test Cycles.STR - Software Test Report.Coninutul TestriiSTP

Coninutul Testrii - DetaliiSTP - Un plan ce detaliaz: scopul testrii, planificarea n timp, cerinele ce se testeazTRD - Specific ce cazuri trebuie testate pentru fiecare cerin (TC - Test Case)STD - Specific step-by-step ce se execut i ce rezultat se ateapt pentru fiecare TCSTR - Sumarizeaz rezultatele ciclurilor de testare i concluziile despre calitatea sistemului testat

Unit TestingTestarea unei funcii, a unui program, a unui ecran, a unei funcionalitiSe face de ctre programatoriPredefinit.Rezultatele trebuie documentateSe folosesc simulatoare pentru Input i Output

Testare la IntegrareTestarea funcionrii unor module n acelai timpTestarea coexisteneiSe execut de ctre programatori sau de ctre testri analitiTestare pre-planificatRezultatele se documenteaz

Testare Manual - Scenariu de TestSTP: Definirea structurii testrii, Se mparte sistemul ntr-o structur ierarhic, Se descriu resursele necesare pentru testare, Se planific testareaTRD:mprirea n pai se face innd cont de cerine, Se descrie ce va fi testat pentru componente i funcii, Include o mulime de cerine de testare ntr-un format stabilitSTD: Descrie CUM s testm sistemul

Testare AutomatPresupunea s crem n paralel clase de test pentru a testa clasele de bazvoid CElevatorTest::GoToFloorTest1() { CElevator Elevator; Elevator.GoToFloor( 5 );assert( Elevator.GetFloor() == 5 ); Elevator.GoToFloor( 0 ); assert( Elevator.mFloor == 0 ); }

Testare Automat vs Testare ManualSe gsesc rapid problemeleSe ctig timp cnd e nevoie s repetm testeleProcesul de scriere a codului e mult mai flexibilReduce volumul de testare manualDezvoltarea software devine previzibil i repetabilRezolv problemele de interfa: scrierea corect a textelor, mesajelor, aranjarea corect n pagin, n ordinea care trebuie, sunt vizibile, etc.Realizarea Scenariilor de test poate fi o treab de durat i anevoioas i implic o cunoatere temeinic a ntregului sistem

Linkshttp://www.automatedqa.com/techpapers/testing.asphttp://www.codeproject.com/tools/tilo.asphttp://www.parasoft.com/jsp/products/home.jsp?product=Cpphttp://www.verifysoft.com/en_ctapp.htmlhttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncdev00/html/vc00f6.asphttp://www.codeproject.com/gen/design/autp5.asp http://www.codeproject.com/cpp/UnitTestsReporter.asphttp://www.codeproject.com/gen/design/onunittesting.asphttp://www.code-agazine.com/Article.aspx?quickid=0411031

Coding Style MotivaieConveniile de programare sunt importante deoarece:80% din timpul alocat unei componente software este ntreinereFoarte rar un produs software este ntreinut pe toat durata folosirii lui de ctre aceeai persoanConveniile de cod mbuntesc lizibilitatea produsului, i permite inginerilor software s neleag rapid un program nou

Coding Style - CerineFolosirea fr rezerve a Comentariilor: ce fac procedurile, ce reprezint variabilele, explicarea pailor algoritmului, etc.Folosirea numelor sugestive pentru variabile si proceduriScrierea modulara a proiectuluiFolosirea perechilor de tip set/get, start/stop, adauga/sterge, salvare/incarcare

Coding Style - LinksC++:http://www.chris-lott.org/resources/cstyle/http://geosoft.no/development/cppstyle.htmlJava:http://java.sun.com/docs/codeconv/http://geosoft.no/development/javastyle.html

1Requirements analysis is the determination of what an application should do. requirements should be clear, complete, reasonably detailed, attainable, and testable. A non-testable requirement would be, for example, 'user-friendly' (too subjective). A testable requirement would be something as if 'the user must enter their previously-assigned password to access the application.SQC is part of the SQA.This is the control procedures BUT there should be some understanding of the framework which is set in the SQA level.To explain that:We need not only to find bugs but also to prevent them (which is better)To know when to stop because effectiveness and economics of the process is essential.To know that not all system requires the same level of quality (mission critical against IT).Testing is not only for the SOFTWARE it is for all DELIVERABLES.

Miscommunication - between the customer and the system annalist / programmerMisunderstanding - between the customer and the system annalist / programmerLow professional manpower - that cause more bugs than the same work under a professional programmerTime pressures - scheduling of software projects is difficult, often requiring a lot of guesswork. When deadline becomes close a lot of mistakes will be made.

Attention - The majority of the system defects comes from the stage of requirements in the life cycle. Attention - The majority of the system defects comes from the stage of requirements in the life cycle. The cost of fixing bugs escalates as we move towards operation.Notice that there are more benefits from early detection, like: No Patch - maintainability Less time spent on corrections - the programmers are still working on the same project, application Corrections are done on schedule and on budget

1