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

Universitatea Politehnica, Bucuresti

Facultatea de Electronica, Telecomunicatii si Tehnologia Informatiei

Tema de curs Inginerie Software

Implementare, testare, verificare şi validare de programe

Studenți: BUȘCĂ Tudor Ștefan TOADER Lucian Alexandru

DINICA Mihai Andrei

Grupa: 442A

Ianuarie, 2016

Cuprins

Capitolul 1: Implementarea produselor software – BUȘCĂ Tudor Ștefan

1.Obiectivele implementării

2.Caracteristicile de calitate

3.Resurse

4.Limbaje de programare

4.1.Compilatoare și interpretoare

4.2.Limbaje procedurale și obiect-orientate

5.Organizarea codului

5.1.Pseudocod

5.2.Organigrame

5.3.UML
Capitolul 2: Testarea programelor – TOADER Lucian Alexandru

1. 
   Generalități
   
2. 
   Testarea de sistem
   
   1. 
      Testarea de integrare
      
   2. 
      Testarea la lansare
      
   3. 
      Testarea de performanță
      
3. 
   Testarea pe componente
   
   1. 
      Testarea de interfață
      
4. 
   Proiectarea cazurilor de test
   
   1. 
      Testarea bazată pe cerințe
      
   2. 
      Testarea pe partiții
      
   3. 
      Testarea structurală
      
   4. 
      Testarea de cale
      
5. 
   Automatizarea testării
   
6. 
   Concluzii
   

Capitolul 3: Verificare şi validare de programe – DINICĂ Mihai Andrei
3.1 Planificarea verificarii si validării

3.2 Inspecțiile software

3.3 Analiza statica automată

3.4 Metode formale și de verificare

3.5 Puncte cheie

CAPITOLUL 1: IMPLEMENTAREA PRODUSELOR SOFTWARE

1.Obiectivele implimentării

Prin implementare se înțelege construirea unei aplicații sau execuția unui model/plan . În IT , implementarea se referă la realizarea unui algoritm sub formă de program , standardele implementării putând să varieze in funcție de aplicație.

Un punct forte în realizarea unei aplicații îl constituie prezența în timpul dezvoltării a unor utilizatori. Spre exemplu, designul sistemului poate fi modelat în funcție de prioritățile utilizatorului precum și adaptat cerințelor lui .

Pentru implementarea unui produs software este nevoie de o echipă mare de dezvoltatori care, de multe ori, nu provin din aceeași locație . Astfel trebuie urmate niște metode de implementare a produsului software .Metoda de implementare este dată de abordarea structurată pentru a integra un serviciu software de bază sau o componentă În structura produsului . [1.1]

Principalele roluri pe care trebuie să le îndeplinească codul implementat sunt:

• 
  Buna funcționare pe sistemul de calcul predestinat ;
  
• 
  Lizibilitatea codului ( înțeles ușor de către alți programatori);
  

2.Caracteristicile de calitate

Pentru a putea fi considerat funcțional , un produs software trebuie sa îndeplinească toate cerințele impuse de către utilizatori. Calitatea unui produs software este reprezentată atât prin funcționalitatea programului cât și prin respectarea unor cerințe/caracteristici. Astfel acest set de caracteristici constituie o bază universală de comparabilitate.

Categoriile principale de caracteristici de calitate software sunt [1.1] :

• 
  Eficiența : capacitatea produsului software de a realiza un consum optim de resurse hardware și software pentru a rezolva cu un anumit nivel de performanță o problemă de complexitate cunoscută;
  

• 
  Funcționalitatea : gradul în care produsul software pune la dispoziția utilizatorului funcții și instrumente care să conducă la îndeplinirea cerințelor acestuia și a obiectivelor pentru care a fost creat;
  

• 
  Fiabilitatea : toleranța la erori a produsului software, probabilitatea apariției unor întreruperi de execuție datorate unor evenimente particulare;
  

• 
  Portabilitatea : posibilitatea instalării și rulării produsului software pe platforme hardware și software diferite de cele pe care a fost creat fără a necesita modificări majore;
  

• 
  Mentenanța : costul actualizării rapide și facile , având ca obiectiv realizarea funcțiilor de prelucrare în condiții superioare , cât și costul implementării unor noi funcții. Cu cât costul este mai mic cu atât produsul software este mai ușor mentenabil;
  

• 
  Utilizabilitatea : gradul de cunoștiințe , echipament și efort necesare utilizatorului pentru a utiliza în condiții optime produsu software;
  

• 
  Corectitudinea : cât de des rezultatul returnat de catre produsul software este și corect. Scopul corectitudinii este de a minimiza greșelile de program datorate managementului resurselor și erorilor logice.
  

• 
  Lizibiliatea : ușurința cu care operațiile și fluxul de informație sunt înțelese de către programator;
  

• 
  Complexitatea algoritmilor: alegerea dintr-o mulțime vastă de algoritmi cu aceeași funcționalitate a algoritmului cel mai eficient în cadrul programului software ce trebuie dezvoltat;
  

3.Resurse

În procesul de analiză și proiectare a produsului software , producătorul nu trebuie sa fie limitat de lipsa ideilor inovatoare ci doar de cantitatea finită a unor resurse vitale precum [1.2] :

• 
  Resurse financiare : susținerea costurilor pentru a asigura continuitatea producției;
  

• 
  Deadline (termenul limită) : reprezintă momentul în care produsul software este oferit utilizatorilor. Nerespectarea deadline-ului duce la consecințe pe piața software ducând la avantajul concurențial ;
  

• 
  Forța de lucru :reprezinta colectivitatea specialiștilor sau numărul persoanelor implicate în dezvoltarea produsului software cât și gradul de calificare al acestora. Aceștia trebuie să îndeplinească următoarele condiții: - experiență suficientă în domeniul informaticii; - rezultate concrete evidențiate în proiecte și produse realizate; - capacitate de evaluare corectă; - lipsa dominării de subiectivism prin abordare argumentată a deciziilor;
  

Producătorul este obligat să ia în considerare dezvolarea doar a anumitor caracteristici de calitate către care își îndreaptă majoritatea resurselor . Alegerea acestora este impusă de către utilizatorii finali care achiziționează produsul cât și de piața actuală.

Prioritar alegerii este punctul de vedere al celor care studiază comparativ piața produselor software, apoi urmând „retușurile” utilizatorilor. Asemenea producătorului de software, aceştia trebuie să aibă o situaţie reală a ierarhiei caracteristicilor de calitate în funcţie de importanţa acordată de utilizatori, pentru a alege baza procesului de comparaţie a produselor software. [1.2]

4. Limbaje de programare

În informatică, „codul sursă” (en: „source code”) reprezintă un set de instrucțiuni, specific unui anumit limbaj de programare. Codul sursă permite programatorului să comunice cu computerul folosind un număr bine definit de instrucțiuni. [1.3]

Acesta îi oferă programatorului posibilitatea de a specifica operațiile pe care sistemul de calcul le va realiza, fiind o modalitate prin care utilizatorul informează calculatorul ce și cum are de făcut în scopul manipulării anumitor date.

La limbajele de nivel înalt , instrucțiunile codului sursă au nume comune , ușor de înțeles și reținut de către om decât instrucțiunile propriu zise ale hardware-ului (care sunt alcătuite din cifre si litere fără un înteles evident).

Codul sursă trebuie transpus în „cod mașină” deoarece el nu este înțeles direct de către calculator. Transpunerea se face prin asamblare, compilare sau interpretare , ca mai târziu aplicațiile să fie distribuite într-un format de tip executabil (.exe) care nu conține codul sursă.

Principalul scop al codului sursă este de a comunica calculatorului ce are de făcut. Pentru economisirea de timp, programatorii organizează codul sursă pe funcții pentru ca ulterior să poata fie folosit atât în cadrul aceluiași program cât și în alt program. O principală problemă care se vrea a fi evitată o reprezintă multitudinea de fișiere în care este scris codul sursă (implicând astfel diferite limbaje de programare). Deși se doreste evitarea scrierii în limbaje diferite, acest lucru este momentan imposibil deoarece anumite funcții pot fi implementate cel mai bine doar într-un anumit limbaj. [1.1]

Există limbaje de programare procedurale și limbaje de programare obiect-orientate. În cazul produselor Web , principalele limbaje de programare destinate browser-elor sunt : HTML, JavaScript, JSP , iar pentru servere , unde avem de a face cu o cantitate mult mai mare de informație se vor folosi aplicații destinate gestiunii bazelor de date , precum Oracle,SQL,MySQL. Un exemplu de legătura între categoriile prezentate de mai sus îl constituie creearea unei interfețe grafice ( scrisă în JSP) cu ajutorul căreia se va face conexiunea la un server ce conține o bază de date implementată în Oracle.În acest capitol vor fi prezentate diferențele dintre :

1. 
   Compilatoare și interpretoare;
   
2. 
   Limbaje procedurale și obiect-orientate;
   

1. 
   Compilatoare și interpretoare
   

Se poate face o împărțire a limbajelor de programare în 2 categorii: compilatoare și interpretoare ; însă sunt foarte rare programele care îndeplinesc exclusiv una din cele 2 categorii.

Un compilator este un program (sau set de programe) care traduce textul unui program scris într-un limbaj de programare „sursă” într-un alt limbaj de calculator, numit limbaj „țintă”. Sursa originală se numește de obicei cod sursă iar rezultatul cod obiect. Sursa inițiala se numește cod sursă iar rezultatul cod obiect . Rezultatul compilării este un fișier de tip executabil (.exe) care este ulterior rulat de către sistemele de calcul pentru care a fost destinat. [1.2]

Un avantaj al compilatoarelor este prosibilitatea de dezvoltare a unor programe independente de mașina pe care rulează. În assambler codul este modificat dacă mașina diferă de cea inițială.

Interpretorul este cel ce transformă codul sursă în cod mașină în momentul în care acesta este rulat. El poate fi fie un program care execută direct codul sursa . fie un program care transforma codul într-unul intermediar ce va fi rulat ulterior , sau un program care interpreteaza un cod precompilat de către un compilator aflat în sistemul de interpretare.

Dezavantajul interpretorului este timpul de execuție , el ajungând să fie chiar și de 10 ori mai lent decât un program compilat. Această problemă este rezolvată cu ajutorul unui precompilator. Acesta reduce timpul de rulare foarte mult păstrând astfel avantajele oferite de interpretare. [1.3]

2.Limbaje procedurale și obiect-orientate

Procedura reprezintă o funcție , rutină sau metodă alcatuită dintr-un număr de pași care trebuie parcurși. Apelul la această procedură se poate face la orice moment de timp , chiar și prin autoapelare. Scopul programelor procedurale este de a împărții funcția acestuia într-o colecție de variabile, structuri de date și subrutine. [1.1]

Programarea obiect-orientată urmărește creearea unor obiecte care interacționează între ele pentru a realiza anumite funcții. Programarea procedurală este echivalentă cu o clasă care este formată dintr-un singur obiect. Astfel programarea obiect-orientată are un avantaj principal : organizarea mult mai ușoară (prin încapsulare de date , moșteniri, polimorfism ) care duce către simplificarea codului și a complexității crescând astfel siguranța datelor.

Un rol important în dezvoltarea limbajelor de programare l-a avut apariția internetului și odată cu el extinderea limbajelor existente pentru a oferii posibilitatea de comunicare între calculatoare. Înainte de apariția internetului , calculatoarele funcționau independent , rulau programe simple și procesau cantități mici de informație. Un răspuns la problema comunicării au fost aplicațiile web.(browserele) ce au dezvoltat limbaje de programare precum HTML,JSP,JavaScript sau PHP. Rolul aplicațiilor web era acela de a face comunicarea posibilă pentru un număr mare de utilizatori , rezultând la apariția serverelor pentru stocarea informațiilor . Stocarea se realiza prin intermediul bazelor de date. [1.2]

5.Organizarea codului

Cum am spus și mai sus, unele programe nu pot fi scrise într-un singur limbaj de programare , iar dezvoltarea programului necesită o echipă formată din mai mulți programatori . Problema apare când unii programatori nu cunosc toate limbajele de programare utilizate în dezvoltarea programului. Astfel pentru înțelegerea întregului program trebuie folosite alte metode. Aceste metode pot fi :

1. 
   Pseudocod
   
2. 
   Organigrame
   
3. 
   UML
   

1.Pseudocod

Un limbaj pseudocod este o scriere intermediară, menită să simplifice scrierea unui algoritm într-un limbaj de programare și să ajute la realizarea clarității algoritmului, în timp scurt. Cu alte cuvinte, este un limbaj cât mai apropiat de cel uman, pentru a putea fi înțeles de oricine.

În general, un algoritm prezentat sub formă de pseudocod este alcătuit din 2 secțiuni:

• 
  Secțiunea de declarații: locul unde se definesc variabilele și tipurile de date ce vor fi utilizate ulterior;
  
• 
  Secțiunea de calcul : locul unde se citesc datele de intrare , se apelează funcțiile declarate și se afișează datele de ieșire.
  

Sintaxa generală a pseudocodului :

algorithm

{tipul variabilelor}

{definirea de proceduri/functii}

begin


{instructiunile algoritmului}

End

Elemente lexicale:

• 
  cuvinte cheie : sunt folosite într-un anumit context și sunt utilizate pentru a defini o anumită instrucțiune;
  
• 
  identificatori : nume de variabile prin care se face apelarea;
  
• 
  expresiile : forme lexicale alcătuite din operatori sau operanzi; [1.1]
  

Tabelul 1. Descriere în pseudocod

2.Organigrame

Organigrama este o structură a unei organizații care se poate reprezenta grafic printr-o schemă în nodurile căreia sunt posturile iar liniile care unesc nodurile sunt relațiile (de ordonare sau subordonare) dintre membri. [1.2]

În informatică , organigrama este o alternativă a pseudocodului și reprezintă un grafic al unui algoritm sau program ce trebuie implementat pe un sistem de calcul.




Figura 1. Structura unei organigrame

Elementele principale:

• 
  blocuri start,stop ;
  
• 
  blocul de instrucțiuni ;
  
• 
  blocuri de decizie ;
  
• 
  legăturile aferente (săgeți)
  

Exemplu



Figura 2. Exemplu de organigramă

3.UML

Unified Modeling Language (prescurtat UML) este un limbaj standard pentru descrierea de modele și specificații pentru software. Modelul reprezintă abstractizarea unui sistem cu un obiectiv bine definit. Modelul înglobează conceptele importante ale sistemului și totodată le ignoră pe cele nefundamentale. [1.3]

În cazul sistemelor software mai complexe, există mai multe mai multe tehnologii și limbaje care să susțină metodologiile sistemelor. Pentru a avantaja schimburile de idei și proiecte, a fost impusă o reuniune a acestor tehnologii , rezultatul fiind apariția UML-ului.

Deși el a fost proiectat și dezvoltat pentru a modela sisteme software, este folosit și în alte domenii de proiectare precum hardware,arhitectură,etc..

Limbajul UML se bazează pe mai multe tipuri de diagrame (modele) care pot fi utilizate în cadrul oricărei faze de dezvoltare, oferind mai multe puncte de vedere pentru sistemul în curs de dezvoltare.

În cadrul UML se definește semantica (intelesul) și notațiile acestor diagrame, care pot fi folosite într-un mod foarte flexibil, în funcție de necesitătile particulare de dezvoltare, fără a avea nici o restricţie asupra acestora.

La definirea cerințelor si la dezvoltarea unui sistem complex colaborează maimulte categori de specialisti și fiecare dintre aceste categorii sunt interesate de anumite aspecte diferite ale proiectului. Fiecare dintre categoriile de specialişti beneficiază de cel puţin o vedere a sistemul reprezentată sub formă unei diagrame UML. [1.1]

Principalele diagrame din cadrul limbajului UML care sunt cel mai des folosite sunt:

1. 
   Class Diagram (Diagrama claselor);
   
2. 
   Component Diagram (Diagrama componentelor);
   
3. 
   Deployment Diagram (Diagrama de desfășurare);
   
4. 
   Object Diagram (Diagrama obiectelor);
   
5. 
   Use Case Diagram (Diagrama de cazuri de utilizare);
   
6. 
   Sequence Diagram (Diagrama secvențelor);
   

1. Class Diagram (Diagrama claselor);

Este punctul forte în proiectele de dezvoltare software bazate pe programarea obiect-orientată și reprezintă modelul conceptual al sistemului ( fixează structura întregului sistem). Acest tip de diagrama este prezent atât în faza de analiză cât și în etapele proiectării , având nivele diferite de detaliere în funcție de necesitățile programatorilor. [1.1]

Proprietăți :

• 
  Modelează vocabularul sistemului ce trebuie dezvoltat;
  
• 
  Surprinde conexiunile semantice sau interacţiunile care se stabilesc între elementele componente;
  
• 
  Folosită pentru a modela structura unui program;
  

Figura 3. Diagrama claselor

2.Component Diagram (Diagrama componentelor)

Diagrama componentelor arată structura relațiilor dintre componentele unui sistem software. Sunt adesea folosite când se lucreaza cu sisteme complexe unde numărul componentelor este foarte mare. Componentele comunică între ele prin intermediul interfețelor. [1.1]

Figura 4. Diagrama componentelor

3.Deployment Diagram (Diagrama de desfășurare);

Diagramele de desfășurare arată legăturile dintre software și hardware. Ele sunt utile atunci când soluția software este implementată pe mai multe dispozitive , fiecare având o configurație unică.

Figura 5. Diagramă de desfășurare

4. 
   Object Diagram (Diagrama obiectelor);
   

Diagramele obiectelor, cateodată referite ca și diagramele cazurilor sunt foarte similare cu diagramele claselor. Ca și diagrama claselor, diagrama obiectelor arată relația dintre obiecte însă se folosesc exemple din lumea reala. Sunt folosite pentru a demonstra cum un sistem va arăta la un moment dat. Deoarece există date disponibile în obiectele definite , sunt adesea folosite pentru a explica relații complexe dintre aceste obiecte. [1.2]



Figura 6. Diagrama obiectelor

5.Use Case Diagram (Diagrama de cazuri de utilizare);

Diagramele Use-Case sunt cele mai cunoscut tip de diagramă UML comportamentală. Diagrama Use-Case ofera o imagine de ansamblu a ”actorilor” implicați într-un sistem, a diferitelor funcții necesare acelor ”actori” și modul ăn care aceste funcții interacționează.

Figura 7. Diagramă de cazuri de utilizare

6.Sequence Diagram (Diagrama secvențelor)

Diagramele de secvență din UML arată cum un obiet interacționează cu altul și ordinea acestor interacțiuni. Este important de știut ca ele arată interacțiile unui scenariu anume și nu al întregului sistem. Procesele sunt reprezentate vertical iar interacțiunile sunt săgețile care le leagă. [1.3]

Figura 8. Diagrama secvențelor

CAPITOLUL 2: Testarea programelor

1) Generalități

Testarea software reprezintă o metodă obiectivă și independentă de a oferi informații cu privire la calitatea produsului sau serviciului ce este supus testării, permițând astfel aprecierea și înțelegerea riscurilor aferente implementării programului. [2.1]

Testarea software implică execuția unei componente software sau a unui sistem pentru a evalua una sau mai multe proprietăți ce prezintă interes. În general, aceste proprietăți indică măsura în care componenta sau sistemul supus testării:

• 
  întrunește cerințele care i-au ghidat proiectarea și dezvoltarea
  
• 
  răspunde corect la diverse forme de input
  
• 
  își execută funcțiile într-un timp acceptabil
  
• 
  este utilizabil
  
• 
  poate fi instalat și rulat pe mediile pentru care a fost proiectat
  
• 
  atinge rezultatele generale dorite
  

O procedură generală de testare începe cu testarea unităților individuale ale programului, precum funcții sau obiecte. Acestea sunt apoi integrate în sub-sisteme și sisteme, iar interacțiunile dintre aceste unități sunt supuse testelor. În final, după livrarea sistemului, clientul poate susține o serie de teste de acceptare pentru a verifica dacă sistemul rulează în parametrii specificați. [2.1]

Acest model este potrivit pentru dezvoltarea unui sistem complex, însă pentru sisteme simple, sau sisteme care sunt dezvoltate prin scriptare sau reutilizare, sunt adesea mai puține etape distincte ale procesului.

Cele două etape fundamentale ale testării sunt:

• 
  testarea pe componente ( testarea unităților componente ale sistemului )
  
• 
  testarea de sistem ( testarea sistemului ca întreg )
  

Procesul de testare software are două obiective distincte:

• 
  Să demonstreze dezvoltatorului și clientului că programul întrunește cerințele
  

Pentru software pe comandă, trebuie să existe cel puțin un test pentru fiecare cerință din documentele de utilizare. Pentru produse software generice, trebuie să existe teste pentru toate capabilitățile incorporate. Unele sisteme pot avea o faza de acceptare explicită, în care clientul verifică faptul că produsul este conform cu specificațiile. [2.1]

• 
  Să descopere defecte ale programului ce duc la comportament incorect, nedorit sau neconform cu specificațiile.
  

Testarea defectelor are ca scop eliminarea oricăror tipuri de comportament nedorit al sistemului, precum crash-uri de sistem, interacțiuni nedorite cu alte sisteme, calcule incorecte și coruperea datelor.

Primul obiectiv implică testarea de validare, în care este de așteptat funcționarea corectă a sistemului folosind un set dat de cazuri de test, care reflectă utilizarea dorită a sistemului. Cel de-al doilea obiectiv implică testarea de defecte, în care cazurile de test sunt proiectate pentru a expune defectele. În primul caz, un test de succes este cel în care sistemul performează conform așteptărilor, iar în cel de-al doilea caz, un test de succes este cel care expune un defect ce duce la un comportament defectuos al sistemului. [2.1]

Testarea nu poate demonstra cu certitudine faptul că software-ul este fără defecte sau că se va comporta ideal în orice situație. De aceea, testarea are rolul de a convinge dezvoltatorii și clienții că produsul este suficient de bun pentru utilizare.

Un model general al procesului de testare este prezentat în Fig. 2. Cazurile de test sunt specificații ale intrărilor de test și ale ieșirilor dorite de la sistem împreună cu o enunțare a ceea ce este testat. Datele de test sunt intrări care au fost proiectate pentru a testa sistemul și pot fi uneori generate automat. Generarea automata a cazurilor de test nu este posibilă, deoarece rezultatele testelor pot fi prezise numai de persoanele care înteleg funcționarea sistemului. Din moment ce nici testarea exhaustivă nu este o opțiune, testarea trebuie să fie bazată pe un subset de cazuri posibile de test [2.2] . În mod ideal, subsetul trebuie sa fie generat pe baza unor politici de alegere, ca de exemplu:

1. 
   Toate funcțiile sistemului care sunt accesate prin meniuri trebuie testate.
   
2. 
   Combinații de funcții care sunt accesate prin același meniu trebuie testate.
   
3. 
   Când utilizatorul oferă input, toate funcțiile trebuie testate cu input atât corect, cât și incorect.
   

Când capabilități ale produsului sunt folosite izolat, aceste funcționează în general conform așteptărilor. Problemele apar atunci când sunt combinate capabilități ce nu au fost testate impreună.

Pentru majoritatea sistemelor, programatorii preiau responsabilitatea testării componentelor pe care le-au dezvoltat. Odată finalizată această etapă, o echipa de integrare preia și integrează modulele de la dezvoltatori diferiți, construiește programul și testează sistemul ca întreg. Testarea pe componente de către dezvoltatori se bazează pe o înțelegere intuitivă a funcționării componentelor. Testarea de sistem, pe de altă parte, trebuie să fie bazată pe specificații scrise. Specificațiile pot fi cerințe de sistem detaliate sau o reprezentare abstractizată orientată către utilizator a capabilităților ce trebuie implementate de către sistem. O echipă separată este în mod normal responsabilă pentru testarea de sistem. [2.4]

2) Testarea de sistem

Testarea de sistem implică integrarea a două sau mai multe componente care implementează funcții sau capabilități și apoi testarea acestui sistem integrat. Într-un proces de dezvoltare iterativ, testarea de sistem implică testarea unei iterații care trebuie livrată către client; într-un proces de tip cascadă, implică testarea întregului sistem. [2.1]

Pentru majoritatea sistemelor complexe, există două etape distincte ale testării:

1. 
   Testarea de integrare, în care echipa de test are acces la codul sursă al sistemului. Când o problemă este descoperită, echipa de integrare încearcă să găsească sursa erorii și să identifice componentele ce trebuie reparate. Testarea de integrare se ocupă cu găsirea defectelor din sistem.
   
2. 
   Testarea de lansare, în care o versiune a sistemului care ar putea fi lansată către utilizatori este testată. Echipa de test urmărește validarea faptului că sistemul întrunește cerințele și este fiabil. Aceasta este o testare de tip “black-box” în care echipa de test doar demonstrează funcționarea corectă sau defectuoasă a sistemului. Problemele sunt raportate către echipa de dezvoltare pentru soluționare. Atunci când este implicat și clientul, poartă numele de testare de acceptare. Dacă versiunea este suficient de bună, clientul o va accepta pentru utilizare.[2.2]
   

Fundamental, testarea de integrare reprezintă testarea unor sisteme incomplete compuse din grupuri de componente. Testarea de lansare urmărește testarea unei versiuni a sistemului care trebuie livrată clientului. Cele două se suprapun, mai ales în cazul dezvoltării incrementale. În general, prioritatea în testarea de integrare este descoperirea de defecte și prioritatea în testarea de lansare este verificarea faptului că sistemul întrunește cerințele. În practică însă, cele două împrumută una de la cealaltă. [2.3]