Introducere în Testare

1. Introducere în Testare

2. Dilema Calităţii Software

Calitate
Preţ
Timp
24.03.2007
Adrian Iftene - Practică
2/37

3. 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)
24.03.2007
Adrian Iftene - Practică
3/37

4. 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
24.03.2007
Adrian Iftene - Practică
4/37

5. 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
24.03.2007
Adrian Iftene - Practică
5/37

6. De ce avem “bugs” în Software?

•Comunicarea deficitară sau blocajele de
comunicare
•Înţelegerea deficitară
•Presiunea timpului
•Nivelul programatorului este scăzut
24.03.2007
Adrian Iftene - Practică
6/37

7.

Comunicare Deficitară
24.03.2007
Adrian Iftene - Practică
7/37

8. Comunicare deficitară – În tratarea cerinţelor

24.03.2007
Adrian Iftene - Practică
8/37

9. Cuprins

• Unde ne aflăm?
• Definiţia şi Scopurile Testării Software
• Fapte şi Numere
24.03.2007
Adrian Iftene - Practică
9/37

10. De unde vin Problemele Software?

•Cerinţe definite incomplet
50%
•Modelare ambiguă sau insuficientă 30%
•Erori de programare
20%
24.03.2007
Adrian Iftene - Practică
10/37

11. Bugs - Costul Fixării

100
80
60
40
20
0
24.03.2007
Cerinţe Modelare
Impl.
Test. Int. Test.sist.
Adrian Iftene - Practică
Client
11/37

12. Atenţie

Găsirea târzie a bugs un
cost cât mai mare pentru a
le fixa
24.03.2007
Adrian Iftene - Practică
12/37

13. Erori? Trebuie fixate cât mai Devreme Posibil

CERINŢE MODELARE IMPLEM.
24.03.2007
Adrian Iftene - Practică
TESTARE CLIENT
13/37

14. 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.
24.03.2007
Adrian Iftene - Practică
14/37

15. 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
24.03.2007
Adrian Iftene - Practică
15/37

16. Schema unui Sistem de Testare

Mediul de Testare
Designs
Acquires
Configures
Utilizes
Support
Determine the
usage of
Procese
de Test
24.03.2007
Create
Articulates
Trains
Applies
Internalize
Echipa
de Test
Provides a
Platform
for the
operation of
Designs
Acquires
Configures
Utilizes
Support
Testware
Adrian Iftene - Practică
16/37

17. Metodologii de Testare

24.03.2007
Adrian Iftene - Practică

18. Conţinut

•Diferenţa dintre testare SW şi debug SW
•Nivele de Test
•Clase de Test
•Conţinutul Testării
•Testare şi Dezvoltare SW
24.03.2007
Adrian Iftene - Practică
18/37

19. Diferenţa dintre testare software & debug

Diferenţa dintre testare
software & debug
Testare
Debug
•Verificarea respectării
cerinţelor
•Verificarea validităţii
secţiunilor
•De regulă e făcută de o
entitate externă şi neutră
•Este un proces
planificat şi controlat
24.03.2007
Adrian Iftene - Practică
•E făcută de
programator
•E un proces aleator
19/37

20. Nivele de Test

•Unitate sau Debug.
•Modul/Sub-Sistem.
•Integrare.
•Sistem.
•Acceptare.
24.03.2007
Adrian Iftene - Practică
20/37

21. BLACK BOX

Input
Output
Spec
24.03.2007
Adrian Iftene - Practică
21/37

22. WHITE BOX

END
24.03.2007
DO
Adrian Iftene - Practică
22/37

23. 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
24.03.2007
Adrian Iftene - Practică
23/37

24. 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ă
24.03.2007
Adrian Iftene - Practică
24/37

25. 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ă
24.03.2007
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ă
25/37

26. Links

• http://www.automatedqa.com/techpapers/testing.asp
• http://www.codeproject.com/tools/tilo.asp
• http://www.parasoft.com/jsp/products/home.jsp?product=
Cpp
• http://www.verifysoft.com/en_ctapp.html
• http://msdn.microsoft.com/library/default.asp?url=/library/
en-us/dncdev00/html/vc00f6.asp
• http://www.codeproject.com/gen/design/autp5.asp
• http://www.codeproject.com/cpp/UnitTestsReporter.asp
• http://www.codeproject.com/gen/design/onunittesting.asp
• http://www.codeagazine.com/Article.aspx?quickid=0411031
24.03.2007
Adrian Iftene - Practică
26/37

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

28. 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
24.03.2007
Adrian Iftene - Practică
28/37

29. Coding Style - Links

• C++:
• http://www.chris-lott.org/resources/cstyle/
• http://geosoft.no/development/cppstyle.ht
ml
• Java:
• http://java.sun.com/docs/codeconv/
• http://geosoft.no/development/javastyle.ht
ml
24.03.2007
Adrian Iftene - Practică
29/37

30.

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
A: 2p
B: 1p
C: 0p
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
Se punctează aderarea la stilul de programare
B: 0.5p menţionat în fişierul raport.html, denumirea autoC: 0p
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
A: 1p
Se punctează modul în care este structurat proiectul,
B: 0.5p posibilitatea de a reutiliza cod în alte proiecte.
C: 0p
Scenarii de
Test
A: 1p
B: 0.5
C: 0p
24.03.2007
Se punctează folosirea unităţilor de testare automată
în cadrul proiectului (JUnit, cppunit, NUnit, phpunit
...)
Adrian Iftene - Practică
30/37