Ce este Testarea integrării sistemului (SIT) cu exemplu

Ce este testarea integrării sistemului?

Testarea integrării sistemului 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ța specificată.

Testarea integrării sistemului (SIT) este efectuată pentru a verifica interacțiunile dintre modulele unui sistem software. Se ocupă cu verificarea cerințelor software de nivel înalt și scăzut specificate în Specificația cerințelor software / date și în documentul de proiectare software.

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 crea un sistem.

De exemplu, componentele software și / sau hardware sunt combinate și testate progresiv până când întregul sistem a fost integrat.

În acest tutorial, veți învăța-

• Ce este testarea integrării sistemului?
• De ce se efectuează testarea integrării sistemului
• Cum se efectuează testarea integrării sistemului
• Criterii de intrare și ieșire pentru testarea integrării
• Testarea integrării hardware-software
• Testare integrare software-software
• Abordare de sus în jos
• Abordarea de jos în sus
• Abordarea Big Bang

De ce se efectuează testarea integrării sistemului

În ingineria software, testarea integrării sistemelor se face pentru că,

• Ajută la detectarea defectului devreme
• Vor fi disponibile feedback mai vechi cu privire la acceptabilitatea modulului individual
• Programarea remedierilor de defecte este flexibilă și poate fi suprapusă cu dezvoltarea
• Fluxul corect de date
• Debit de control corect
• Moment corect
• Utilizarea corectă a memoriei
• Corectați cerințele software-ului

Cum se efectuează testarea integrării sistemului

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

Toate modulele sunt integrate în avans și întregul program este testat în ansamblu. Dar în timpul acestui proces, este posibil să se întâmple 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 corectate ș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 utilizează 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 sunt efectuate pe un sistem bazat pe procesorul țintă. Metodologia utilizată este Black Box Testing. Se poate utiliza fie integrarea de jos în sus, fie de sus în jos.

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

Integrarea software-ului poate fi realizată, de asemenea, î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 problemele specifice mediului, cum ar fi erorile de alocare și de alocare a memoriei. Practicitatea realizării integrării software-ului în mediul gazdă va depinde de cât de multă funcționalitate specifică țintă este acolo. Pentru unele sisteme încorporate, cuplarea cu mediul țintă va fi foarte puternică, ceea ce face imposibilă realizarea integrării software-ului în mediul gazdă.

Dezvoltările software mari vor împărți integrarea software-ului în mai multe niveluri. Nivelurile inferioare de integrare software ar putea fi bazate predominant pe mediul gazdă, nivelurile ulterioare de integrare software devenind mai dependente de mediul țintă.

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

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

De obicei, în timp ce efectuați testarea integrării, se utilizează strategia ETVX (criterii de intrare, sarcină, validare și criterii de ieșire).

Criterii de intrare:

• Finalizarea testării unitare

Intrări:

• Date privind cerințele software
• Document de proiectare software
• Plan de verificare software
• Documente de integrare software

Activități:

• Pe baza cerințelor de nivel înalt și scăzut, creați cazuri și proceduri de testare
• Combinați construcții de module de nivel inferior care implementează o funcționalitate comună
• Elaborați un ham de testare
• Testați construcția
• Odată ce testul este trecut, versiunea este combinată cu alte versiuni și testată până când sistemul este integrat ca întreg.
• Executați din nou toate testele pe platforma țintă bazată pe procesor ș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 în conformitate cu cerințele 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-ului computerului (CSC) pentru funcționalități la nivel înalt pe mediul hardware țintă. Scopul testării integrării hardware / software este de a testa comportamentul software-ului dezvoltat integrat pe componenta hardware.

Testarea integrării hardware-software bazată pe cerințe

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

• Erori de interfețe hardware / software
• Încălcări ale partiționării software.
• Incapacitatea de a detecta eșecurile prin testul încorporat
• Răspuns incorect la defecțiunile hardware
• Eroare datorată secvențierii, încărcărilor tranzitorii de intrare și tranzitorilor puterii de intrare
• Feedback-ul buclă comportamentul incorect
• Control incorect sau necorespunzător al hardware-ului de gestionare a memoriei
• Problemă de contenție a magistralei de date
• Funcționarea incorectă a mecanismului pentru a verifica compatibilitatea și corectitudinea software-ului care poate fi încărcat pe teren

Integrarea software-ului hardware se ocupă cu verificarea cerințelor la nivel înalt. Toate testele de la acest nivel sunt efectuate pe hardware-ul țintă.

• Testarea cutiei negre este principala metodologie de testare utilizată la acest nivel de testare.
• Definiți cazurile de testare numai din cerințele de nivel înalt
• Trebuie executat un test pe hardware standard de producție (pe țintă)

Lucruri de luat în considerare atunci când se proiectează cazuri de testare pentru integrarea HW / SW

• Achiziționarea 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 întreruperii, toate întreruperile vor fi verificate independent de cererea inițială prin service complet și la finalizare. Cazurile de testare vor fi special concepute pentru a testa în mod adecvat întreruperile.

Testare integrare software-software

Este testarea componentei software pentru computer care funcționează în interiorul computerului gazdă / țintă

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

Se concentrează pe comportamentul unui CSC într-un mediu gazdă / țintă simulat. Abordarea utilizată pentru integrarea software-ului 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, testați mai întâi fiecare modul al software-ului individual și apoi continuați testarea prin adăugarea altor module la acesta, apoi la altul și așa mai departe.

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

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, începeți individual testând doar interfața cu utilizatorul, cu funcționalitatea de bază simulată de butoane, 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 principal de control, modulele sunt integrate prin deplasarea în jos prin ierarhia controlului
• Sub-module la modulul principal de control sunt încorporate în structură, fie într-o manieră de lățime-întâi, fie în adâncime.
• Integrarea în adâncime întâi integrează toate modulele pe o cale majoră de control a structurii așa cum este afișat în următoarea diagramă:

Procesul de integrare a modulului se realizează în modul următor:

1. Modulul principal de control este utilizat ca driver de testare, iar butoanele sunt substituite tuturor modulelor direct subordonate modulului principal de control.
2. Butoanele subordonate sunt înlocuite pe rând cu module reale în funcție de abordarea selectată (lățimea mai întâi sau adâncimea mai întâi).
3. Testele sunt executate pe măsură ce fiecare modul este integrat.
4. La finalizarea fiecărui set de teste, un alt butuc este înlocuit cu un modul real la finalizarea fiecărui set de teste
5. Pentru a vă asigura că nu au fost introduse erori noi, se poate efectua testarea de regresie.

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.

Cea mai comună dintre aceste probleme apare atunci când procesarea la niveluri scăzute în ierarhie este necesară pentru a testa în mod adecvat nivelurile superioare.

Butoanele înlocuiesc modulele de nivel scăzut la începutul testării de sus în jos și, prin urmare, nu pot fi transmise date semnificative în sus în structura programului.

Provocările pe care le poate întâmpina Testerul:

• Întârziați multe teste până când butoanele sunt înlocuite cu module reale.
• Dezvoltați butoane 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 constrânsă a abordării de sus în jos.

A doua abordare este funcțională, dar poate duce la o cheltuială semnificativă, deoarece tulpinile 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 scăzut 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 este eliminată necesitatea stuburilor.

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

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

Pe măsură ce integrarea se mișcă în sus, 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 driverelor poate fi redus substanțial, iar integrarea clusterelor este mult simplificată. Integrarea urmează modelul ilustrat mai jos. Pe măsură ce integrarea se mișcă în sus, este nevoie de lecții separate pentru șoferii de testare.

Notă: Dacă sunt integrate cele două niveluri superioare ale structurii programului 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ă ș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ă se cunoască cauza principală a eșecului din cauza integrării totul simultan.

De asemenea, va exista o mare șansă 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ă simultan.

Rezumat:

• Integrarea se realizează pentru a verifica interacțiunile dintre modulele unui sistem software. Ajută la detectarea defectului devreme
• Testarea integrării se poate face pentru integrarea hardware-software sau hardware-hardware
• Testarea integrării se face prin două metode
  • Abordare incrementală
  • Abordare Big Bang
• În timpul efectuării testelor de integrare, în general se folosește strategia ETVX (criterii de intrare, sarcină, validare și criterii de ieșire).