Inginerie Software Implementare, testare, verificare şi validare de programe

2.1) Testarea de integrare

Procesul de integrare a sistemului implică construirea unui sistem din componentele sale și testarea sistemului rezultat pentru a releva orice defecte cauzate de interacțiunile între componente. Aceste componente pot fi componente gata făcute, componente reutilizabile ce au fost adaptate pentru un tip particular de sistem sau componente nou-dezvoltate. Pentru multe sisteme de mari dimensiuni, toate cele trei tipuri de componente au șanse mari să fie utilizate. Testarea de integrare verifică faptul că aceste componente funcționează împreună, sunt apelate corect și transferă datele corecte la momentele de timp dorite prin interfețele lor. [2.1]

Integrarea sistemului implică identificarea grupurilor de componente care oferă o capabilitate a sistemului și integrarea acestora prin adăugarea de cod ce le permite funcționarea împreună. Uneori, se dezvoltă întâi un schelet al sistemului, la care se adaugă componente. Acest tip de integrare se numeste top-down. Alternativ, se pot integra întâi componentele de infrastructură ce oferă servicii comune, precum accesul la rețea și la baza de date și apoi se pot adăuga componentele funcționale. Acest tip de integrare se numește bottom-down. În practică, pentru multe sisteme se folosește o combinație a celor două abordări. În cazul ambelor tipuri de integrare, este necesar cod adițional pentru a simula alte componente și a permite sistemului să ruleze. [2.4]

O problemă majoră în cadrul testării de integrare o reprezintă localizarea erorilor. Interacțiunile între componentele sistemului sunt complexe și atunci când se descoperă rezultate eronate, se poate dovedi dificilă indentificarea originii defectului. Pentru a ușura localizarea erorilor, este de preferat o abordare incrementală, pornind de la integrarea unei configurații minimale a sistemului și testarea acesteia. Se adaugă apoi componente la aceasta configurație și se testează dupa fiecare iterație.

În exemplul din Fig. 3, A, B, C și D sunt componente iar elementele de la T1 la T5 sunt seturi de teste incorporate în sistem. T1, T2 și T3 sunt rulate inițial pe un sistem compus din componenta A si componenta B ( sistemul minimal ). Dacă apar defecte, acestea sunt corectate. Componenta C este integrată și T1, T2, T3 sunt repetate pentru a asigura că nu au apărut interacțiuni neprevăzute cu A și B. Daca apar probleme în aceste teste, cel mai probabil sunt cauzate de interacțiunea cu noua componentă. Sursa problemei este localizată, astfel simplificând descoperirea și repararea defectului. Setul T4 este rulat pe sistem. În final, componenta D este integrată și testată utilizând testele deja existente și setul T5. [2.1]

Când se planifică integrarea, trebuie decis între ordinea integrării și ordinea componentelor. În cazul în care clientul este implicat în procesul de dezvoltare și decide ce funcționalitate trebuie inclusă la fiecare iterație a sistemului, integrarea sistemului se axează pe prioritățile clientului. În alte abordări ale dezvoltării, când sunt integrate componente gata făcute și componente dezvoltate special, clientul nu este implicat și echipa de integrare decide prioritățile.

În astfel de cazuri, o regulă generală este integrarea prioritară a componentelor care implementează funcționalitatea cea mai des utilizată. Astfel, cele mai utilizate componente vor fi testate cel mai mult. În practică însă, implementarea funcționalităților de sistem poate fi impărțită pe mai multe componente și pentru a testa o capabilitate nouă, vor trebui integrate multiple componente diferite. Testarea poate dezvălui erori în interacțiunile dintre aceste componente și alte părți ale sistemului, iar repararea se poate dovedi dificilă, deoarece un întreg grup de componente care implementează o funcționalitate a sistemului vor trebui schimbate. Mai mult, integrarea și testarea unei noi componente poate schimba tiparul interacțiunilor între componente care au fost deja testate. Pot apărea defecte care nu au fost expuse în testele efectuate pe configurația mai simplă. [2.3]

Astfel, la integrarea unei noi iterații, este important să se ruleze și testele din iterațiile anterioare precum și noile teste necesare pentru a verifica noua funcționalitate a sistemului. Rularea unui set existent de teste se numește testare de regresie. Daca aceasta expune probleme, trebuie verificat dacă problemele survin din iterația anterioară și pe care noua iterație le-a expus, sau dacă acestea sunt cauzate de incrementul de funcționalitate adăugat. [2.2]

Testarea de regresie este în mod evident un proces costisitor și este impractic fără automatizare. În combinație cu un framework de testare precum JUnit, testele pot fi rulate în mod automat.

2.2) Testarea la lansare

Testarea la lansare este procesul de testarea a unei versiuni a sistemului care va fi distribuită clienților. Principalul obiectiv al acestui proces este de creștere a încrederii dezvoltatorului în capacitatea sistemului de a întruni cerințele. Pentru a demonstra faptul că sistemul întrunește cerințele, trebuie arătat că acesta oferă funcționalitatea, performanța și fiabilitatea specificată și că nu cedează în condiții de utilizare normală.

Testarea la lansare este de obicei un proces de tip “black-box”, în care testele sunt derivate din specificațiile sistemului. Sistemul este tratat ca o cutie neagră, al cărei comportament poate fi determinat numai prin studierea intrărilor și ieșirilor sale. Alt nume folosit este cel de testare funcțională, deoarece tester-ul urmărește doar funcționalitatea și nu și implementarea software-ului. [2.2]

Fig. 4 ilustrează modelul unui sistem în testarea funcțională. Tester-ul oferă intrări către componentă sau sistem și examinează ieșirile corespunzătoare. Daca ieșirile nu sunt cele prezise ( ieșirile sunt în setul Oe), testul a detectat o problema cu produsul.

Atunci când se testează versiuni ale sistemului, trebuie încercat să se “strice” software-ul, alegând cazuri de test care se află în setul Ie din Fig. 4, adică intrări care au o probabilitate ridicată de a genera erori de sistem( ieșiri în setul Oe).

Există un set de reguli care crește probabilitatea ca testele de defecte să aibă succes:

1. 
   Se aleg intrări care forțează sistemul să genereze toate mesajele de eroare
   
2. 
   Se proiectează intrări care cauzează depășirea bufferelor de intrare
   
3. 
   Se repetă aceeași intrare sau set de intrări în repetate rânduri
   
4. 
   Se forțează generarea de ieșiri eronate
   
5. 
   Se forțează rezultatele calculelelor să fie prea mari sau prea mici