1. Adrian Iftene adiftene@infoiasi.ro
Facultatea de Informatică Universitatea “Al.I.Cuza” - Iaşi - Practică – Cursul 1 continuare
Adrian Iftene
Adrian Iftene - Practică

2. Introducere în Testare1

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

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

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

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 - Practică

7. Adrian Iftene - Practică
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 - Practică

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 - Practică

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 - Practică

10. Adrian Iftene - Practică
Comunicare Deficitară
Adrian Iftene - Practică

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 - Practică

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

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 - Practică

14. Adrian Iftene - Practică
Bugs - Costul Fixării
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 - Practică

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 - Practică

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

17. Adrian Iftene - Practică
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 - Practică

18. Adrian Iftene - Practică
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 - Practică

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 - Practică

20. Metodologii de Testare
Adrian Iftene - Practică 1

21. Adrian Iftene - Practică
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 - Practică

22. Diferenţa dintre testare software & 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 - Practică

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

24. Adrian Iftene - Practică
BLACK BOX
Input
Output
Spec
Adrian Iftene - Practică

25. Adrian Iftene - Practică
WHITE BOX IF DO
END
Adrian Iftene - Practică

26. Adrian Iftene - Practică
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 - Practică

27. Adrian Iftene - Practică
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 - Practică

28. 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 - Practică

29. Adrian Iftene - Practică
Links
Adrian Iftene - Practică

30. 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 - Practică

31. Adrian Iftene - Practică
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 - Practică

32. Adrian Iftene - Practică
Coding Style - Links
C++:
Java:
Adrian Iftene - Practică

33. Adrian Iftene - Practică
Complexitatea proiectului
A: 2p 
B: 1p 
C: 0p
Un proiect care necesită o cantitate mai mare de muncă va fi recompensat mai bine. Se ia in calcul şi originalitatea ideii precum şi alegerea corespunzătoare a tehnologiei de implementare. Acolo unde este cazul se ia in considerare munca necesara implementării interfeţei si calitatea rezultatului.
Fişa cerinţelor, raportul final, activitate
Se punctează modul în care a fost realizată fişa cerinţelor şi felul în care studentul a interacţionat cu conducătorul de laborator ("clientul"). Un punctaj bun se acordă dacă clientului îi este clar cu ce se ocupă proiectul şi i-a fost prezentată evoluţia proiectului.
Stil de programare
A: 1p 
B: 0.5p 
C: 0p
Se punctează aderarea la stilul de programare menţionat în fişierul raport.html, denumirea auto-descriptivă a variabilelor etc. In aceasta categorie intra si folosirea adecvata a unui sistem de generare automata a documentaţiei (javadoc, doxygen etc.)
Proiectare şi modularitate
B: 0.5p
Se punctează modul în care este structurat proiectul, posibilitatea de a reutiliza cod în alte proiecte.
Scenarii de Test
B: 0.5 
Se punctează folosirea unităţilor de testare automată în cadrul proiectului (JUnit, cppunit, NUnit, phpunit ...)
Adrian Iftene - Practică