Ce este testarea integrării? (Exemplu)

Ce este testarea integrării?

Testare de integrare este definit ca un tip de testare în care modulele software sunt integrate logic și testate ca un grup. Un proiect software tipic constă din mai multe module software, codificate de diferiți programatori. Scopul acestui nivel de testare este de a expune defectele interacțiunii dintre aceste module software atunci când sunt integrate.

Testarea integrării se concentrează pe verificarea comunicării datelor între aceste module. Prin urmare, este denumit și ca 'ACEASTA' (Integrare și testare), „Testarea șirurilor” si cateodata „Testarea firelor”.

De ce faceți teste de integrare?

Deși fiecare modul software este testat unitar, defecte există încă din diverse motive, cum ar fi

• Un modul, în general, este proiectat de un dezvoltator individual de software a cărui înțelegere și logică de programare pot diferi de alți programatori. Testarea de integrare devine necesară pentru a verifica dacă modulele software funcționează în unitate
• În momentul dezvoltării modulelor, există șanse mari de schimbare a cerințelor de către clienți. Este posibil ca aceste noi cerințe să nu fie testate unitar și, prin urmare, testarea integrării sistemului devine necesară.
• Interfețele modulelor software cu baza de date pot fi eronate
• Interfețele hardware externe, dacă există, ar putea fi eronate
• Gestionarea inadecvată a excepțiilor poate cauza probleme.

Clic aici dacă videoclipul nu este accesibil

Exemplu de caz de testare de integrare

Integrare Caz de testare diferă de alte cazuri de testare în sensul în care aceasta se concentrează în principal pe interfețele și fluxul de date/informații între module. Aici trebuie acordată prioritate legături de integrare mai degrabă decât funcțiile unității care sunt deja testate.

Exemple de cazuri de testare de integrare pentru următorul scenariu: Aplicația are 3 module spun „Pagină de conectare”, „Mailcasetă” și „Șterge e-mailuri” și fiecare dintre ele este integrat logic.

Aici nu vă concentrați prea mult pe testarea paginii de conectare, deoarece a fost deja făcută Testarea unității. Dar verificați cum este legat de Mail Box Pagină.

asemănător Mail Box: Verificați integrarea acestuia în Delete Mails Modulul.

ID caz de testare	Obiectivul cazului de testare	Caz de testare Description	rezultat asteptat
1	Verificați legătura de interfață dintre Login și Mailmodul cutie	Introduceți datele de conectare și faceți clic pe butonul Conectare	Pentru a fi direcționat către Mail Box
2	Verificați legătura de interfață dintre Mailcasetă și Șterge Mails Modulul	De la Mailselectați e-mailul și faceți clic pe un buton de ștergere	E-mailul selectat ar trebui să apară în folderul Șters/Coș de gunoi

Tipuri de testare de integrare

Ingineria software definește o varietate de strategii pentru a executa testarea de integrare, adică.

• Abordarea Big Bang:
• Abordare incrementală: care este împărțită în continuare în următoarele
  • Abordare de sus în jos
  • Abordarea de jos în sus
  • Abordare sandwich – Combinație de sus în jos și de jos în sus

Mai jos sunt diferitele strategii, modul în care sunt executate și limitările acestora, precum și avantajele.

Testarea Big Bang

Testarea Big Bang este o abordare de testare a integrării în care toate componentele sau modulele sunt integrate împreună simultan și apoi testate ca o unitate. Acest set combinat de componente este considerat ca o entitate în timpul testării. Dacă toate componentele din unitate nu sunt finalizate, procesul de integrare nu se va executa.

avantaje:

• Convenabil pentru sisteme mici.

Dezavantaje:

• Localizarea defecțiunilor este dificilă.
• Având în vedere numărul mare de interfețe care trebuie testate în această abordare, unele linkuri de interfețe care trebuie testate ar putea fi ratate cu ușurință.
• Deoarece testarea de integrare poate începe numai după ce „toate” modulele sunt proiectate, echipa de testare va avea mai puțin timp pentru execuție în faza de testare.
• Deoarece toate modulele sunt testate simultan, modulele critice cu risc ridicat nu sunt izolate și testate cu prioritate. De asemenea, modulele periferice care se ocupă de interfețele utilizator nu sunt izolate și testate cu prioritate.

Testare incrementală

În Testare incrementală abordare, testarea se face prin integrarea a două sau mai multe module care sunt legate logic între ele și apoi testate pentru buna funcționare a aplicației. Apoi celelalte module aferente sunt integrate incremental și procesul continuă până când toate modulele legate logic sunt integrate și testate cu succes.

Abordarea incrementală, la rândul său, este realizată prin două metode diferite:

• De jos în sus
• De sus în jos

Stub-uri și șoferi

Stub-uri și șoferi sunt programele fictive în testarea de integrare utilizate pentru a facilita testare software activitate. Aceste programe acționează ca înlocuitori pentru modelele lipsă din testare. Ele nu implementează întreaga logică de programare a modulului software, dar simulează comunicarea de date cu modulul apelant în timpul testării.

Ciot: este apelat de modulul aflat în testare.

Şofer: Apelează modulul care urmează să fie testat.

Testarea integrării de jos în sus

Testarea integrării de jos în sus este o strategie în care modulele de nivel inferior sunt testate mai întâi. Aceste module testate sunt apoi utilizate în continuare pentru a facilita testarea modulelor de nivel superior. Procesul continuă până când toate modulele de la nivelul superior sunt testate. Odată ce modulele de nivel inferior sunt testate și integrate, se formează următorul nivel de module.

Reprezentare schematică:

avantaje:

• Localizarea defecțiunilor este mai ușoară.
• Nu se pierde timp în așteptarea ca toate modulele să fie dezvoltate, spre deosebire de abordarea Big-bang

Dezavantaje:

• Modulele critice (la nivelul superior al arhitecturii software) care controlează fluxul aplicației sunt testate ultimele și pot fi predispuse la defecte.
• Un prototip timpuriu nu este posibil

Testare de integrare de sus în jos

Testarea integrării de sus în jos este o metodă în care testarea integrării are loc de sus în jos în urma fluxului de control al sistemului software. Modulele de nivel superior sunt testate mai întâi și apoi modulele de nivel inferior sunt testate și integrate pentru a verifica funcționalitatea software-ului. Stub-urile sunt folosite pentru testare dacă unele module nu sunt gata.

Reprezentare schematică:

avantaje:

• Localizarea defecțiunilor este mai ușoară.
• Posibilitatea de a obține un prototip timpuriu.
• Modulele critice sunt testate cu prioritate; defecte majore de proiectare ar putea fi găsite și remediate mai întâi.

Dezavantaje:

• Are nevoie de multe stub-uri.
• Modulele de la un nivel inferior sunt testate inadecvat.

Cum se face testarea integrării?

Procedura de testare a integrării, indiferent de strategiile de testare a software-ului (discutate mai sus):

1. Pregătiți integrarea Planul de teste
2. Proiectați scenariile de testare, cazurile și scripturile.
3. Executarea cazurilor de testare urmata de raportarea defectelor.
4. Urmărirea și re-testarea defectelor.
5. Pașii 3 și 4 se repetă până când integrarea este finalizată cu succes.

Breviar Description a planurilor de testare de integrare

Include următoarele atribute:

• Metode/abordări ale testării (așa cum sa discutat mai sus).
• Domenii și elemente în afara domeniului de aplicare ale testării de integrare.
• Roluri si responsabilitati.
• Cerințe preliminare pentru testarea integrării.
• Mediul de testare.
• Planuri de risc și atenuare.

Criteriile de intrare și de ieșire ale testării integrării

Criterii de intrare și ieșire în faza de testare a integrării în orice model de dezvoltare software

Criterii de intrare:

• Componente/Module testate în unitate
• Toate erorile cu prioritate ridicată au fost remediate și închise
• Toate modulele vor fi codificate și integrate cu succes.
• Teste de integrare Plan, caz de testare, scenarii care urmează să fie semnate și documentate.
• Necesar Mediu de testare să fie configurat pentru testarea integrării

Criterii de ieșire:

• Testarea cu succes a aplicației integrate.
• Cazurile de testare executate sunt documentate
• Toate erorile cu prioritate ridicată au fost remediate și închise
• Documentele tehnice vor fi depuse urmate de Note de lansare.

Cele mai bune practici/Orientări pentru testarea integrării

• Mai întâi, determinați integrarea Strategia de testare care ar putea fi adoptate și ulterior să pregătească cazurile de testare și datele de testare în consecință.
• Studiază Archiproiectarea tecturii aplicației și identificarea modulelor critice. Acestea trebuie testate cu prioritate.
• Obțineți modelele de interfață de la Archiechipa tehnică și creați cazuri de testare pentru a verifica toate interfețele în detaliu. Interfața cu baza de date/hardware extern/aplicație software trebuie testată în detaliu.
• După cazurile de testare, datele de testare joacă rolul critic.
• Pregătiți întotdeauna datele simulate, înainte de execuție. Nu selectați datele de testare în timp ce executați cazurile de testare.