View
252
Download
2
Category
Preview:
DESCRIPTION
f
Citation preview
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
Recommended