1. Adrian Iftene adiftene@infoiasi.ro
Facultatea de Informatică Universitatea “Al.I.Cuza” - Iaşi Ingineria Programării Laborator 3
Adrian Iftene
Adrian Iftene - IP

2. Introducere în Testare1

3. Cuprins Unde ne aflăm? Definiţia şi Scopurile Testării Software
Fapte şi Numere
Adrian Iftene - IP

4. Dilema Calităţii Software
Calitate
Timp
Preţ
Adrian Iftene - IP

5. Cuprins Unde ne aflăm? Definiţia şi Scopurile Testării Software
Fapte şi Numere
Adrian Iftene - IP

6. Testare Software - Definiţie
“The process of exercising or evaluating
a system by manual or automated
means to verify that it satisfies specified
requirements or to identify differences
between expected and actual results.”
(IEEE Standard Glossary, 1983)
Requirements 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’.
Adrian Iftene - IP

7. Testare Software Testarea Software NU este o fază
Este un proces care trebuie integrat în toate fazele construcţiei produsului software
Există documente de testare asociate la fiecare fază a dezvoltării
Adrian Iftene - IP

8. Care sunt Scopurile Testării?
De a localiza şi preveni bugs cât mai curând posibil
De a efectua toate Testele corespunzător Cerinţelor, într-un mod cât mai eficient şi mai economic
De a aduce produsul software la un nivel de calitate cât mai ridicat (pentru client) Toate acestea se execută folosind Metodologile de Implementare
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.
Adrian Iftene - IP

9. De ce avem Bugs în Software?
Comunicarea deficitară sau Blocajele de comunicare
Înţelegerea deficitară
Presiunea Timpului
Nivelul Programatorului este Scăzut
Miscommunication - between the customer and the system annalist / programmer
Misunderstanding - between the customer and the system annalist / programmer
Low professional manpower - that cause more bugs than the same work under a professional programmer
Time pressures - scheduling of software projects is difficult, often requiring a lot of guesswork. When deadline becomes close a lot of mistakes will be made.
Adrian Iftene - IP

10. Comunicare Deficitară
Adrian Iftene - IP

11. Comunicare Deficitară – În tratarea Cerinţelor
Attention - The majority of the system defects comes from the stage of requirements in the life cycle.
Adrian Iftene - IP

12. Cuprins Unde ne aflăm? Definiţia şi Scopurile Testării Software
Fapte şi Numere
Adrian Iftene - IP

13. De unde vin Problemele Software?
Cerinţe definite Incomplet 50%
Modelare Ambiguă sau Insuficientă 30%
Erori de Programare %
Attention - The majority of the system defects comes from the stage of requirements in the life cycle.
Adrian Iftene - IP

14. Bugs - Costul Fixării Cerinţe Modelare Impl. Test. Int. Test.sist.
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
Cerinţe
Modelare
Impl.
Test. Int.
Test.sist.
Client
Adrian Iftene - IP

15. Găsirea târzie a bugs  un cost cât mai mare pentru a le fixa
Atenţie
Găsirea târzie a bugs  un cost cât mai mare pentru a le fixa
Adrian Iftene - IP

16. Erori? Trebuie fixate cât mai Devreme Posibil
CERINŢE MODELARE IMPLEM. TESTARE CLIENT
Adrian Iftene - IP

17. Testare Profesională
Profesionalismul în testare constă în abilitatea de a selecta numărul minim de cazuri de testare eficientă ce va fi capabil să verifice numărul maxim de funcţii ale sistemului.
Adrian Iftene - IP

18. Când Oprim Testarea? Niciodată
Când numărul de erori găsite într-un ciclu de testare este mai mic decât un număr stabilit
Când nu mai sunt găsite defecte critice şi majore
Când timpul a expirat
Adrian Iftene - IP

19. Schema unui Sistem de Testare
Mediul de Testare
Designs Acquires Configures Utilizes Support
Determine the usage of
Provides a Platform for the operation of
Echipa
de Test
Designs Acquires Configures Utilizes Support
Create Articulates Trains Applies Internalize
Procese
de Test
Testware
Adrian Iftene - IP

20. Metodologii de Testare
Adrian Iftene - IP 1

21. Conţinut Diferenţa dintre testare SW şi debug SW Nivele de Test
Clase de Test
Conţinutul Testării
Testare şi Dezvoltare SW
Adrian Iftene - IP

22. Diferenţa dintre Testare SW & Debug
Verificarea respectării cerinţelor
De regulă e făcută de o entitate externă şi neutră
Este un proces planificat şi controlat
Debug
Verificarea validităţii secţiunilor
E făcută de programator
E un proces aleator
Adrian Iftene - IP

23. Nivele de Test Unitate sau Debug. Modul/Sub-Sistem. Integrare. Sistem.
Acceptare.
Adrian Iftene - IP

24. Clase de Test Regresie. Efecte Laterale. Redundanţă.
Stres şi Supraîncărcare.
Refacere.
Adrian Iftene - IP

25. BLACK BOX
Input
Output
Spec
Adrian Iftene - IP

26. WHITE BOX IF DO
END
Adrian Iftene - IP

27. Conţinutul Testării STP - Software Test Plan.
TRD
STD
Execuţie
STR
STP - Software Test Plan.
TRD - Test Requirement Definition.
STD - Software Test Description.
Tests Execution or Test Cycles.
STR - Software Test Report.
Adrian Iftene - IP

28. Conţinutul Testării - Detalii
STP - Un plan ce detaliază: scopul testării, planificarea în timp, cerinţele ce se testează
TRD - Specifică ce cazuri trebuie testate pentru fiecare cerinţă (TC - Test Case)
STD - Specifică step-by-step ce se execută şi ce rezultat se aşteaptă pentru fiecare TC
STR - Sumarizează rezultatele ciclurilor de testare şi concluziile despre calitatea sistemului testat
Adrian Iftene - IP

29. Unit Testing
Testarea unei funcţii, a unui program, a unui ecran, a unei funcţionalităţi
Se face de către programatori
Predefinită.
Rezultatele trebuie documentate
Se folosesc simulatoare pentru Input şi Output
Adrian Iftene - IP

30. Testare la Integrare Testarea funcţionării unor module în acelaşi timp
Testarea coexistenţei
Se execută de către programatori sau de către testări analişti
Testare pre-planificată
Rezultatele se documentează
Adrian Iftene - IP

31. Testare Manuală - Scenariu de Test
STP:
Definirea structurii testării, Se împarte sistemul într-o structură ierarhică, Se descriu resursele necesare pentru testare, Se planifică testarea
TRD:
Împărţirea în paşi se face ţinând cont de cerinţe, Se descrie ce va fi testat pentru componente şi funcţii, Include o mulţime de cerinţe de testare într-un format stabilit
STD:
Descrie CUM să testăm sistemul
Adrian Iftene - IP

32. Testare Automată
Presupunea să creăm în paralel clase de test pentru a testa clasele de bază
void CElevatorTest::GoToFloorTest1() {
CElevator Elevator;
Elevator.GoToFloor( 5 );
assert( Elevator.GetFloor() == 5 );
Elevator.GoToFloor( 0 );
assert( Elevator.mFloor == 0 ); }
Adrian Iftene - IP

33. Testare Automată vs Testare Manuală
Se găsesc rapid problemele
Se câştigă timp când e nevoie să repetăm testele
Procesul de scriere a codului e mult mai flexibil
Reduce volumul de testare manuală
Dezvoltarea software devine previzibilă şi repetabilă
Rezolvă 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 cunoaştere temeinică a întregului sistem
Adrian Iftene - IP

34. Links http://www.automatedqa.com/techpapers/testing.asp
Adrian Iftene - IP

35. Coding Style – Motivaţie
Convenţiile de programare sunt importante deoarece:
80% din timpul alocat unei componente software este întreţinere
Foarte rar un produs software este întreţinut pe toată durata folosirii lui de către aceeaşi persoană
Convenţiile de cod îmbunătăţesc lizibilitatea produsului, şi permite inginerilor software să înţeleagă rapid un program nou
Adrian Iftene - IP

36. Coding Style - Cerinţe
Folosirea fără rezerve a Comentariilor: ce fac procedurile, ce reprezintă variabilele, explicarea paşilor algoritmului, etc.
Folosirea numelor sugestive pentru variabile si proceduri
Scrierea modulara a proiectului
Folosirea perechilor de tip set/get, start/stop, adauga/sterge, salvare/incarcare
Adrian Iftene - IP

37. Coding Style - Links C++: Java:
Java:
Adrian Iftene - IP