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

Introducere în Testare 1

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

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

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

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

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

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

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

Adrian Iftene - Practică Comunicare Deficitară 24.03.2007 Adrian Iftene - Practică

Comunicare deficitară – În tratarea cerinţelor Attention - The majority of the system defects comes from the stage of requirements in the life cycle. 24.03.2007 Adrian Iftene - Practică

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

De unde vin Problemele Software? Cerinţe definite incomplet 50% Modelare ambiguă sau insuficientă 30% Erori de programare 20% Attention - The majority of the system defects comes from the stage of requirements in the life cycle. 24.03.2007 Adrian Iftene - Practică

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

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

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

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

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

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

Metodologii de Testare 24.03.2007 Adrian Iftene - Practică 1

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

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

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

Adrian Iftene - Practică BLACK BOX Input Output Spec 24.03.2007 Adrian Iftene - Practică

Adrian Iftene - Practică WHITE BOX IF DO END 24.03.2007 Adrian Iftene - Practică

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

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

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

Adrian Iftene - Practică 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.code-agazine.com/Article.aspx?quickid=0411031 24.03.2007 Adrian Iftene - Practică

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ă

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

Adrian Iftene - Practică Coding Style - Links C++: http://www.chris-lott.org/resources/cstyle/ http://geosoft.no/development/cppstyle.html Java: http://java.sun.com/docs/codeconv/ http://geosoft.no/development/javastyle.html 24.03.2007 Adrian Iftene - Practică

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