Ce este un exemplu de testare a integrării sistemului (SIT).

Ce este testarea integrării sistemului?

Sistem Testare de integrare este definit ca un tip de testare software efectuată într-un mediu hardware și software integrat pentru a verifica comportamentul întregului sistem. Este testarea efectuată pe un sistem complet integrat pentru a evalua conformitatea sistemului cu cerințele specificate.

Testarea de integrare a sistemului (SIT) este efectuată pentru a verifica interacțiunile dintre modulele unui sistem software. Acesta se ocupă de verificarea cerințelor software de nivel înalt și scăzut specificate în Specificația/Date privind cerințele software și în Documentul de proiectare a software-ului. De asemenea, verifică coexistența unui sistem software cu altele și testează interfața dintre modulele aplicației software. În acest tip de testare, modulele sunt mai întâi testate individual și apoi combinate pentru a realiza un sistem. De exemplu, componentele software și/sau hardware sunt combinate și testate progresiv până când întregul sistem a fost integrat.

De ce testează integrarea sistemului?

În ingineria software, testarea integrării sistemului se face deoarece,

• Ajută la detectarea Defect devreme
• Va fi disponibil feedback anterior cu privire la acceptabilitatea modulului individual
• Programarea remedierii defectelor este flexibilă și poate fi suprapusă cu dezvoltarea
• Fluxul corect de date
• Fluxul de control corect
• Timpul corect
• Utilizarea corectă a memoriei
• Corect cu cerințele software

Cum se face testarea integrării sistemului

Este o tehnică sistematică pentru construirea structurii programului în timp ce se efectuează teste pentru a descoperi erorile asociate cu interfațarea.

Toate modulele sunt integrate în prealabil, iar întregul program este testat ca întreg. Dar în timpul acestui proces, este probabil să apară un set de erori.

Corectarea unor astfel de erori este dificilă deoarece cauzele de izolare sunt complicate de extinderea vastă a întregului program. Odată ce aceste erori sunt rectificate și corectate, va apărea una nouă, iar procesul continuă fără probleme într-o buclă nesfârșită.. Pentru a evita această situație, se folosește o altă abordare, Integrarea incrementală. Vom vedea mai multe detalii despre o abordare incrementală mai târziu în tutorial.

Există câteva metode incrementale, cum ar fi testele de integrare care sunt efectuate pe un sistem bazat pe procesorul țintă. Metodologia folosită este Negru Box Testarea. Se poate folosi fie integrarea de jos în sus, fie de sus în jos.

Cazurile de testare sunt definite numai folosind cerințele software de nivel înalt.

Integrarea software-ului poate fi realizată în mare măsură în mediul gazdă, unitățile specifice mediului țintă continuând să fie simulate în gazdă. Repetarea testelor în mediul țintă pentru confirmare va fi din nou necesară.

Testele de confirmare la acest nivel vor identifica probleme specifice mediului, cum ar fi erori de alocare și dezalocare a memoriei. Practicitatea conducerii integrare software în mediul gazdă va depinde de cât de multă funcționalitate specifică țintă există. Pentru unele sisteme încorporate, cuplarea cu mediul țintă va fi foarte puternică, ceea ce face imposibilă realizarea integrării software în mediul gazdă.

Dezvoltarile software mari vor împărți integrarea software-ului pe mai multe niveluri. Nivelurile inferioare de integrare software s-ar putea baza preponderent în mediul gazdă, nivelurile ulterioare de integrare software devenind mai dependente de mediul țintă.

Notă: Dacă doar software-ul este testat, atunci se numește Software Software Integration Testing [SSIT] și dacă atât hardware-ul, cât și software-ul sunt testați, atunci se numește Hardware Software Integration Testing [HSIT].

Criterii de intrare și ieșire pentru testarea integrării

De obicei, în timpul efectuării testării de integrare, este utilizată strategia ETVX (criterii de intrare, sarcină, validare și criterii de ieșire).

Criterii de intrare:

• Finalizarea Testarea unității

Intrări:

• Date despre cerințele software
• Document de proiectare software
• Planul de verificare a software-ului
• Documente de integrare software

Activitati:

• Pe baza cerințelor de nivel înalt și scăzut, creați cazuri și proceduri de testare
• Combinați module de nivel scăzut care implementează o funcționalitate comună
• Dezvoltați un ham de testare
• Testați construcția
• Odată ce testul este trecut, construcția este combinată cu alte versiuni și testată până când sistemul este integrat ca întreg.
• Executați din nou toate testele pe platforma bazată pe procesor țintă și obțineți rezultatele

Criterii de ieșire:

• Finalizarea cu succes a integrării modulului Software pe Hardware-ul țintă
• Performanța corectă a software-ului conform cerințelor specificate

ieşiri

• Rapoarte de testare de integrare
• Cazuri și proceduri de testare software [SVCP].

Testarea integrării software-ului hardware

Testarea integrării software-ului hardware este un proces de testare a componentelor software pentru computer (CSC) pentru funcționalități de nivel înalt în mediul hardware țintă. Scopul testării integrării hardware/software este de a testa comportamentul software-ului dezvoltat integrat pe componenta hardware.

Testare de integrare hardware-software bazată pe cerințe

Scopul testării integrării hardware/software bazate pe cerințe este de a se asigura că software-ul din computerul țintă va satisface cerințele de nivel înalt. Erorile tipice relevate de această metodă de testare includ:

• Erori interfețe hardware/software
• Încălcări ale partiționării software.
• Incapacitatea de a detecta defecțiunile prin testul încorporat
• Răspuns incorect la defecțiuni hardware
• Eroare cauzată de secvențiere, sarcini tranzitorii de intrare și tranzitorii de putere de intrare
• Feedback-ul are un comportament incorect
• Control incorect sau necorespunzător al hardware-ului de gestionare a memoriei
• Problemă de disputa magistrală de date
• Funcționarea incorectă a mecanismului pentru a verifica compatibilitatea și corectitudinea software-ului care poate fi încărcat pe teren

Hardware Software Integration se ocupă de verificarea cerințelor de nivel înalt. Toate testele la acest nivel sunt efectuate pe hardware-ul țintă.

• Testarea cutie neagră este metodologia de testare principală utilizată la acest nivel de testare.
• Defini cazuri de testare numai din cerințele de nivel înalt
• Un test trebuie executat pe hardware standard de producție (la țintă)

Lucruri de luat în considerare atunci când proiectați cazuri de testare pentru integrarea HW/SW

• Achiziția corectă a tuturor datelor de către software
• Scalarea și gama de date conform așteptărilor de la hardware la software
• Ieșirea corectă a datelor de la software la hardware
• Date în cadrul specificațiilor (interval normal)
• Date în afara specificațiilor (interval anormal)
• Date limită
• Întrerupe procesarea
• Sincronizare
• Utilizarea corectă a memoriei (adresare, suprapuneri etc.)
• Tranziții de stat

Notă: Pentru testarea întreruperilor, toate întreruperile vor fi verificate independent de solicitarea inițială, până la întreținerea completă și la finalizare. Cazurile de testare vor fi concepute special pentru a testa în mod adecvat întreruperile.

Testare de integrare software la software

Este testarea componentei software pentru computer care operează în computerul gazdă/țintă

Mediul, în timp ce simulează întregul sistem [alte CSC-uri] și pe funcționalitatea de nivel înalt.

Se concentrează pe comportamentul unui CSC într-un mediu gazdă/țintă simulat. Abordarea utilizată pentru integrarea software poate fi o abordare incrementală (de sus în jos, o abordare de jos în sus sau o combinație a ambelor).

Abordare incrementală

Testarea incrementală este o modalitate de testare a integrării. În acest tip de metodă de testare, mai întâi testați fiecare modul al software-ului individual și apoi continuați testarea prin adăugarea altor module la acesta, apoi altul și așa mai departe.

Integrarea incrementală este contrastul cu abordarea big bang. Programul este construit și testat în segmente mici, unde erorile sunt mai ușor de izolat și corectat. Este mai probabil ca interfețele să fie testate complet și poate fi aplicată o abordare sistematică de testare.

Există două tipuri de testare incrementală

• Abordare de sus în jos
• Abordarea de jos în sus

Abordare de sus în jos

În acest tip de abordare, individul începe prin a testa doar interfața cu utilizatorul, cu funcționalitatea de bază simulată de stub-uri, apoi vă deplasați în jos integrând straturile inferioare și inferioare așa cum se arată în imaginea de mai jos.

• Începând cu modulul de control principal, modulele sunt integrate prin deplasarea în jos prin ierarhia de control
• Sub-modulele la modulul de control principal sunt încorporate în structură fie într-o manieră pe lățime, fie pe adâncime.
• Integrarea depth-first integrează toate modulele pe o cale de control majoră a structurii, așa cum este afișat în următoarea diagramă:

Procesul de integrare a modulelor se realizează în felul următor:

1. Modulul de control principal este folosit ca un driver de testare, iar stub-urile sunt înlocuite pentru toate modulele direct subordonate modulului de control principal.
2. Stub-urile subordonate sunt înlocuite pe rând cu module reale, în funcție de abordarea selectată (în primul rând lățimea sau adâncimea).
3. Testele sunt executate pe măsură ce fiecare modul este integrat.
4. La finalizarea fiecărui set de teste, un alt stub este înlocuit cu un modul real la finalizarea fiecărui set de teste.
5. Pentru a vă asigura că nu au fost introduse noi erori Testarea regresiei poate fi efectuat.

Procesul continuă de la pasul 2 până când este construită întreaga structură a programului. Strategia de sus în jos sună relativ necomplicată, dar în practică apar probleme logistice.

Cele mai frecvente dintre aceste probleme apar atunci când procesarea la niveluri joase din ierarhie este necesară pentru a testa în mod adecvat nivelurile superioare.

Stub-urile înlocuiesc modulele de nivel scăzut la începutul testării de sus în jos și, prin urmare, nicio dată semnificativă nu poate curge în sus în structura programului.

Provocări cu care se poate confrunta Tester:

• Întârzieți multe teste până când stub-urile sunt înlocuite cu module reale.
• Dezvoltați stub-uri care îndeplinesc funcții limitate care simulează modulul real.
• Integrați software-ul din partea de jos a ierarhiei în sus.

Notă: Prima abordare ne face să pierdem un anumit control asupra corespondenței dintre testele specifice și încorporarea unor module specifice. Acest lucru poate duce la dificultăți în determinarea cauzei erorilor, care tinde să încalce natura extrem de restrânsă a abordării de sus în jos.

A doua abordare este viabilă, dar poate duce la cheltuieli generale semnificative, deoarece stub-urile devin din ce în ce mai complexe.

Abordarea de jos în sus

Integrarea de jos în sus începe construcția și testarea cu module la cel mai de jos nivel din structura programului. În acest proces, modulele sunt integrate de jos în sus.

În această abordare, procesarea necesară pentru modulele subordonate unui anumit nivel este întotdeauna disponibilă și necesitatea stub-urilor este eliminată.

Acest proces de testare a integrării se realizează într-o serie de patru pași

1. Modulele de nivel scăzut sunt combinate în clustere care efectuează o subfuncție software specifică.
2. Este scris un driver pentru a coordona intrarea și ieșirea cazului de testare.
3. Clusterul sau build-ul este testat.
4. Driverele sunt eliminate, iar clusterele sunt combinate deplasându-se în sus în structura programului.

Pe măsură ce integrarea crește, este nevoie de lecții separate pentru șoferii de testare. De fapt, dacă primele două niveluri ale structurii programului sunt integrate de sus în jos, numărul de drivere poate fi redus substanțial, iar integrarea clusterelor este mult simplificată. Integrarea urmează modelul ilustrat mai jos. Pe măsură ce integrarea crește, este nevoie de lecții separate pentru șoferi de testare.

Notă: Dacă primele două niveluri ale structurii programului sunt integrate de sus în jos, numărul de drivere poate fi redus substanțial, iar integrarea versiunilor este mult simplificată.

Abordarea Big Bang

În această abordare, toate modulele nu sunt integrate până când și cu excepția cazului în care toate modulele sunt gata. Odată ce sunt gata, toate modulele sunt integrate și apoi sunt executate pentru a ști dacă toate modulele integrate funcționează sau nu.

În această abordare, este dificil să cunoaștem cauza principală a eșecului din cauza integrării totul simultan.

De asemenea, vor exista șanse mari de apariție a erorilor critice în mediul de producție.

Această abordare este adoptată numai atunci când testarea integrării trebuie făcută imediat.

Rezumat

• Integrarea se realizează pentru a verifica interacțiunile dintre modulele unui sistem software. Ajută la detectarea precoce a defectelor
• Testarea integrării se poate face pentru integrarea hardware-software sau hardware-hardware
• Testarea integrării se face prin două metode
  • Abordare incrementală
  • Abordarea big bang
• În timpul efectuării testării de integrare, se utilizează în general strategia ETVX (criterii de intrare, sarcină, validare și criterii de ieșire).