1. Adrian Iftene adiftene@infoiasi.ro
Facultatea de Informatică Universitatea “Al.I.Cuza” - Iaşi Tehnologii de Elaborare a Proiectelor - Curs 2 – - partea 2 -
Adrian Iftene

2. Introducere în Testare1

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

4. Dilema Calităţii Software
Calitate
Timp
Preţ

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

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’.

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

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.

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.

10. Comunicare Deficitară

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

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

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.

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

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

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

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.

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

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

20. Metodologii de Testare1

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

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

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

24. BLACK BOX
Input
Output
Spec

25. WHITE BOX IF DO
END

26. 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

27. 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ă

28. Testare Manuală - Scenariu de Test
Definirea structurii testării
Se împarte sistemul într-o structură ierarhică
Se descriu resursele necesare pentru testare
Se planifică testarea
Î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
Descrie CUM să testăm sistemul

29. 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 ); }

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

31. Links http://www.automatedqa.com/techpapers/testing.asp

32. 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

33. 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

34. Coding Style - Links C++: Java:
Java: