Testare software Lecturer Cristian Gavril Obiective De a

Testare software Lecturer: Cristian Gavrilă

Obiective De a introduce conceptele de verificare şi validare software De a descrie principiile testării sistem şi a testării componentelor De a descrie strategii pentru generarea testelor de sistem De a înţelege caracteristicile esenţiale uneltelor folosite pentru automatizarea testelor

Cuprins 1. Verificare şi validare 2. Testarea sistemului şi a componentelor 3. Proiectarea cazurilor de testare 4. Automatizarea testelor

Verificare vs Validare Verificare: "Are we building the product right? ” Programul software trebuie să fie conform specificaţiilor. Validare: "Are we building the right product? ” Programul software trebuie să fie ceea ce utilizatorul are cu adevărat nevoie.

Procesul V & V Este un proces ce se întinde pe întreaga durată de viaţă software V & V trebuie aplicată în fiecare etapă a procesului software. Are două obiective principale Descoperirea defectelor din sistem; Evaluarea dacă sistemul este util şi utilizabil în situaţii de operare reală.

Scopul V & V Verificarea şi validarea trebuie să stabilească încredere că sistemul software poate fi folosit. Aceasta NU înseamnă fără nici un defect. Mai degrabă, trebuie să fie suficient de bun pentru ceea ce este folosit.

Verificare statică şi dinamică Inspecţii software. Se ocupă cu analiza reprezentărilor statice ale sistemului pentru descoperirea unor probleme (verificare statică) Testare software. Se ocupă cu observarea comportamentului produsului software (verificare dinamică) Sistemul este rulat cu date de test şi se observă comportamentul operaţional.

Planificarea V & V Este nevoie de o planificare atentă pentru a folosi eficient procesele de testare şi inspecţie. Planificarea trebuie să înceapă devreme în procesul de dezvoltare şi să ofere un echilibru între verificare statică şi testare. Planificarea testării înseamnă mai degrabă a stabili standarde pentru procesul de testare decât a descrie testele de produs.

Testarea în procesul de dezvoltare

Structura planului de testare Procesul de testare O descriere a fazelor importante din procesul de testare. Urmărirea cerinţelor Utilizatorii sunt interesaţi ca sistemul software să îşi indeplinească cerinţele, deci testele trebuie planificate în aşa fel încât fiecare cerinţă să fie testată individual. Elementele ce vor fi testate Planificarea activităţilor Activităţile şi alocarea resurselor integrate în planul general de dezvoltare. Procedurile de înregistrare a testelor Nu este sufucientă doar testarea unui sistem, ci rezultatele testelor trebuie înregistrate sistematic. Cerinţe hardware şi software Constrângeri

Procesul de testare Testarea componentelor individuale de program; De obicei este responsabilitatea dezvoltatorilor de componente (cu unele excepţii pentru sistemele critice); Testele sunt derivate din experienţa dezvoltatorului. Testarea sistemului Testarea unui grup de componente integrate pentru a crea un sistem sau sub-sistem; Este responsabilitate unei echipe de testare independente; Testele sunt bazate pe specificaţiile sistemului.

Testarea defectelor Scopul testării defectelor este de a descoperi defecte în programe Un test are succes atunci când determină programul să aibă un comportament anormal Testele arată prezenţa nu absenţa defectelor

Scopurile procesului de testare Testarea de validare De a demonstra dezvoltatorului şi clientului că sistemul software îndeplineşte cerinţele; Un test are succes dacă arată că sistemul se comportă aşa cum s-a cerut. Testarea de defecte De a descoperi defecte în sistemul software unde comportamentul este incorect sau neconform cu specificaţiile; Un test are succes dacă provoacă sistemul să se comporte incorect şi astfel expune un defect în sistem.

Procesul de testare software

Politici de testare Doar testarea completă poate arăta că un program nu are defecte, dar testarea completă este imposibilă Politicile de testare definesc abordarea folosită în selectarea testelor de sistem: Toate funcţiile accesate din meniuri trebuie testate; Combinaţii ale funcţiilor accesate prin acelaşi meniu trebuie testate; Acolo unde sunt introduse date de către utilizator (tastare), toate funcţiile trebuie testate cu intrări corecte şi incorecte.

Testarea sistemului Implică integrarea componentelor pentru a crea un sistem sau sub-sistem. Poate implica testarea unui increment ce va fi livrat la client. Are două faze: Testarea de integrare – echipa de testare acces la codul sursă al sistemului. Sistem este testat pe măsură ce componentele sunt integrate. Testarea de versiune (release) – echipa de testare testează sistemul complet ce va fi livrat, privindu-l ca o cutie neagră.

Testarea de integrare Implică construirea sistemului din componente şi testarea problemelor ce pot să apară din interacţiunile componentelor. Integrare Top-down (de sus în jos) Dezvoltarea unui schelet al sistemului şi popularea lui cu componente. Integrare Bottom-up (de jos în sus) Integrarea componentelor de infrastructură şi adăugarea componentelor funcţionale. Pentru a simplica localizarea erorilor, sistemele trebuie integrate incremental.

Testarea de integrare incrementală

Testare de versiune (release) Este procesul de testare a unei versiuni de sistem care va fi distribuită la clienţi. Scopul principal este să crească încrederea plătitorilor că sistemul îndeplineşte cerinţele. Testarea de versiune este de obicei o testare tip “cutie neagră” sau o testare funcţională Este bazată doar pe specificaţiile de sistem; Testorii nu au cunoştinţe de implementare a sistemului.

Testare tip “cutie neagră”

Sfaturi de testare Sfaturile de testare sunt idei pentru echipa de testare pentru a-i ajuta să aleagă teste care vor descoperi defecte în sistem Alege date de intrare care forţează sistemul să genereze toate mesajele de eroare; Alege date de intrare care provoacă depăşirea unor buffer-e; Repetă aceleaşi date de intrare sau aceleaşi serii de câteva ori; Forţează generarea datelor de ieşire invalide; Forţează ca rezultatele unor calcule să fie prea mari sau prea mici.

Scenariu de testare Un student din Scoţia studiază istoria Americii şi i s-a cerut să scrie un eseu despre ‘Mentalitatea în America de Vest între anii 1840 şi 1880’. Pentru acest lucru, trebuie să găsească surse din mai multe biblioteci. Se autentifică în sistemul LIBSYS şi foloseşte căutarea pentru a descoperi dacă poate accesa documente originale din acea perioadă. Descoperă surse în diferite biblioteci din SUA şi aduce copii ale unora. Totuşi, pentru un document, are nevoie de confirmare de la universitatea în care studiază că este cu adevărat student şi că nu va folosi articolul pentru scopuri comerciale. Studentul foloseşte sistemul LIBSYS pentru a solicita o astfel de permisiune. Dacă I se acordă permisiunea, documentul va fi trimis serverului oficial din bilblioteca universităţii şi va fi tipărit. Studentul primeşte un mesaj prin care i se comunică faptul că va primi un e-mail când documentul tipărit poate fi ridicat.

Teste de sistem Testarea mecanismului de login folosind date corecte şi incorecte pentru a verifica dacă utilizatori reali sunt acceptaţi şi dacă utilizatori falşi sunt respinşi. Testarea serviciului de căutare folosind diferite texte de căutare după cocumente cunoscute pentru a verifica dacă sistemul de căutare găseşte documentele dorite. Testarea serviciului de prezentare pentru a verifica faptul că informaţiile şi documentele sunt afişate corespunzător. Testarea mecanismului de solicitare a permisiunii de download. Testarea răspunsului prin e-mail care indică faptul că un document este disponibil.

Use cases Cazurile de utilizare pot fi baza pentru a deriva testele pentru un sistem. Ele ajută la identificare operaţiilor ce trebuie testate şi ajută la realizarea cazurilor de testare necesare. Din diagrama de secvenţă următoare, pot fi identificate intrările şi ierişirile necesare pentru teste.

Colectarea datelor meteo

Testare de performanţă Parte din testarea de versiune poate implica testarea unor proprietăţi de sistem, cum ar fi performanţa şi fiabilitatea. Testele de performanţă de obicei implică planificarea unor serii de teste unde încărcarea sistemului este crescută până când performanţele sistemului devin inacceptabile.

Testarea la stres Solicită sistemul dincolo de încărcarea maximă proiectată. “Stresarea” sistemului de obicei provoacă defectele să apară. “Stresarea” sistemului testează comportamentul la eşec. Sistemele nu trebuie să eşueze catastrofic. Testarea la stres verifică pierderi inacceptabile de servicii sau date. Testarea la stres este foarte relevantă pentru sisteme distribuite care pot prezenta o degradarea drastică a performanţei la încărcarea reţelei.

Testarea componentelor (unit testing) este procesul de testare a componentelor individuale izolate. Este un proces de testare a defectelor. Componentele pot fi: Funcţii individuale sau metode dintr-un obiect; Clase de obiecte cu câteva atribute şi metode; Componente compuse cu o interfaţă definită pentru accesarea funcţionalităţii.

Testarea claselor de obiecte Teste cu acoperire (covarage) completă a unei clase implică Testarea tuturor operaţiilor asociate cu un obiect; Setarea şi interogarea tuturor atributelor de obiect; Testarea obiectului în toate stările posibile. Moştenirea face mai dificilă proiectarea testelor pentru că informaţia ce trebuie testată nu este localizată.

Interfaţa obiectului Staţie meteo

Testarea staţiei meteo Trebuie să definim cazuri de testare pentru metodele report. Weather, calibrate, test, startup şi shutdown. Folosind un model de stare, se identifică secvenţele de tranziţii de stare ce trebuie testate şi evenimentele ce produc acele tranziţii De exemplu: Waiting -> Calibrating -> Testing -> Transmitting -> Waiting

Proiectarea cazurilor de testare Scopul proiectării testelor este de a creat o mulţime de teste care sunt eficiente în testarea defectelor. Abordări de proiectare a testelor: Testare bazată pe cerinţe; Testare partiţionată; Testare structurală.

Testare bazată pe cerinţe Un principiu de bază în ingineria cerinţelor este faptul că cerinţele trebuie să poată fi testate. Testarea bazată pe cerinţe este o tehnică de testare de validare în care se are în vedere fiecare cerinţă şi se construieşte un set de teste pentru acea cerinţă.

Cerinţe LIBSYS Utilizatorul trebuie să poată căuta în toate bazele de date sau într-un subset din acestea. Sistemul trebuie să ofere intstrumente de vizualizare potrivite pentru ca utilizatorul să citească documentele. Fiecare comandă trebuie să aibă alocat un identificator unic (ORDER_ID).

Teste LIBSYS Iniţiază căutare pentru elemente care se ştie că există sau că nu există, incluzând o singură bază de date în căutare. Iniţiază căutare pentru elemente care se ştie că există sau că nu există, incluzând două baze de date în căutare. Iniţiază căutare pentru elemente care se ştie că există sau că nu există, incluzând mai mult de două baze de date în căutare.

Testare partiţionată De obicei datele de intrare şi datele de ieşire se grupează în diferite categorii de date. Fiecare din aceste categorii este o partiţie de echivalenţă sau un domeniu în care programul are un comportament asemănător. Cazurile de testare trebuie alese din fiecare partiţie.

Partiţionare a datelor

Partiţionare a datelor

Testare structurală Uneori este numită testare tip “cutie albă”. Construirea cazurilor de testare în funcţie de structura programului. Sunt necesare cunoştiinţe interne de program pentru a identifica teste. Obiectivul este să fie testate toate instrucţiunile programului (nu toate combinaţiile de ramuri).

Algoritmul de căutare binară

Automatizarea testării Testarea este o fază de proces costisitoare. Mediile de testare oferă o gamă de instrumente pentru a reduce timpul necesar şi costurile totale de testare. Sisteme cum ar fi JUnit suportă execuţia automată a testelor. Mediile de testare sunt deseori greu de integrat cu medii de proiectare şi analiză.

Concluzii Testarea poate arăta prezenşa erorilor întrun sistem; nu poate demonstra că nu au mai rămas erori. Dezvoltatorii de componente sunt responsabili de testarea componentelor; testarea sistemului este responsabilitatea unei echipe separate. Testarea de integrare este testarea incrementelor de sistem; testarea de versiune implică testarea sistemului ce va fi livrat la client. Folosiţi experienţe pentru crearea cazurilor de testare în testarea defectelor.

Concluzii Testarea partiţionată este o metodă de a descoperi cazurile de testare – toate cazurile dintr-o partiţie se comportă la fel. Testarea structurală se bazează pe analizarea programului şi derivarea testelor din această analiză. Automatizarea testării reduce costurile testării prin folosirea unor unelete software în procesul de testare.