-
Facultatea de InformaticUniversitatea Al.I.Cuza - Iai
Ingineria Programrii Laborator 3
Adrian Iftene [email protected]
-
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