Meniu

Ce este testarea integrării (Tutorial cu exemplu de testare a integrării)

what is integration testing

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Ce este testarea integrării: învățați cu exemple de testare a integrării

Testarea integrării se face pentru a testa modulele / componentele atunci când sunt integrate pentru a verifica dacă acestea funcționează conform așteptărilor, adică pentru a testa modulele care funcționează bine individual nu are probleme atunci când sunt integrate.

Când vorbiți în ceea ce privește testarea aplicațiilor mari folosind tehnica de testare a cutiei negre, implică combinarea mai multor module care sunt strâns legate între ele. Putem aplica conceptele tehnicii de testare a integrării pentru testarea acestor tipuri de scenarii.

Lista tutorialelor acoperite în această serie:

Tutorial nr. 1: Ce este testarea integrării? (Acest tutorial)
Tutorial nr. 2: Ce este testarea incrementală
Tutorial nr. 3: Ce este testarea componentelor
Tutorial # 4: Integrare continuă
Tutorial # 5 Diferența dintre testarea unitară și integrare
Tutorial nr. 6: Top 10 instrumente de testare a integrării

ce este testarea integrării

Ce veți învăța:

Ce este testarea integrării?

Semnificația testării integrării este destul de simplă - Integrați / combinați modulul testat de unitate unul câte unul și testați comportamentul ca unitate combinată.

Funcția principală sau scopul acestui test este de a testa interfețele dintre unități / module.

În mod normal, facem teste de integrare după „Testarea unității”. Odată ce toate unitățile individuale sunt create și testate, începem să combinăm acele module „Unit Tested” și începem să facem testarea integrată.

Funcția principală sau scopul acestui test este de a testa interfețele dintre unități / module.

Modulele individuale sunt testate mai întâi izolat. Odată ce modulele sunt testate în unitate, acestea sunt integrate unul câte unul, până când toate modulele sunt integrate, pentru a verifica comportamentul combinațional și pentru a valida dacă cerințele sunt implementate corect sau nu.

Aici ar trebui să înțelegem că testarea integrării nu are loc la sfârșitul ciclului, ci mai degrabă este efectuată simultan cu dezvoltarea. Deci, de cele mai multe ori, toate modulele nu sunt de fapt disponibile pentru testare și iată ce provocare vine să testeze ceva care nu există!

De ce testul de integrare?

Considerăm că testarea integrării este complexă și necesită o anumită dezvoltare și abilități logice. Este adevărat! Atunci care este scopul integrării acestor teste în strategia noastră de testare?

Iată câteva motive:

  1. În lumea reală, atunci când aplicațiile sunt dezvoltate, acestea sunt împărțite în module mai mici, iar dezvoltatorilor individuali li se atribuie 1 modul. Logica implementată de un dezvoltator este destul de diferită de un alt dezvoltator, deci devine important să verificați dacă logica implementată de un dezvoltator este conform așteptărilor și redă valoarea corectă în conformitate cu standardele prescrise.
  2. De multe ori, fața sau structura datelor se schimbă atunci când se deplasează de la un modul la altul. Unele valori sunt adăugate sau eliminate, ceea ce cauzează probleme în modulele ulterioare.
  3. Modulele interacționează, de asemenea, cu unele instrumente terțe sau API-uri care trebuie, de asemenea, să fie testate dacă datele acceptate de acel API / instrument sunt corecte și că răspunsul generat este, de asemenea, așa cum era de așteptat.
  4. O problemă foarte frecventă la testare - Schimbarea frecventă a cerințelor! :) De multe ori dezvoltatorul implementează modificările fără ca unitatea să le testeze. Testarea integrării devine importantă în acel moment.

Avantaje

Există mai multe avantaje ale acestei testări și câteva dintre acestea sunt enumerate mai jos.

  • Această testare asigură faptul că modulele / componentele integrate funcționează corect.
  • Testarea integrării poate fi pornită odată ce sunt disponibile modulele de testat. Nu este necesar ca celălalt modul să fie finalizat pentru testare, deoarece Stubs și Drivers pot fi folosiți pentru același lucru.
  • Acesta detectează erorile legate de interfață.

Provocări

Mai jos sunt enumerate câteva provocări implicate în testul de integrare.

# 1) Testarea integrării înseamnă testarea a două sau mai multe sisteme integrate pentru a se asigura că sistemul funcționează corect. Ar trebui testate nu numai legăturile de integrare, ci trebuie efectuată o testare exhaustivă, având în vedere mediul, pentru a se asigura că sistemul integrat funcționează corect.

S-ar putea să existe diferite căi și permutări care pot fi aplicate pentru a testa sistemul integrat.

#Două) Gestionarea testării integrării devine complexă din cauza puțini factori implicați în aceasta, cum ar fi baza de date, platforma, mediul etc.

# 3) În timp ce integrează orice sistem nou cu sistemul vechi, acesta necesită multe schimbări și eforturi de testare. Același lucru se aplică la integrarea oricăror două sisteme vechi.

# 4) Integrarea a două sisteme diferite dezvoltate de două companii diferite este o mare provocare în ceea ce privește modul în care unul dintre sisteme va avea impact asupra celuilalt sistem dacă se fac modificări în oricare dintre sisteme, nu este sigur.

Pentru a minimiza impactul în timpul dezvoltării unui sistem, ar trebui luate în considerare câteva lucruri, cum ar fi posibila integrare cu alte sisteme etc.

Tipuri de testare a integrării

Mai jos este prezentat un tip de integrare a testelor, împreună cu avantajele și dezavantajele sale.

Abordarea Big Bang:

Abordarea Big Bang integrează toate modulele dintr-o singură mișcare, adică nu merge pentru integrarea modulelor unul câte unul. Verifică dacă sistemul funcționează conform așteptărilor sau nu odată integrat. Dacă se detectează o problemă în modulul complet integrat, atunci devine dificil să aflăm care modul a cauzat problema.

Abordarea Big Bang este un proces care necesită mult timp pentru a găsi un modul care are un defect în sine, deoarece ar fi nevoie de timp și odată ce defectul este detectat, remedierea acestuia ar costa foarte mult, deoarece defectul este detectat în etapa ulterioară.

Abordare Big Bang

Avantajele abordării Big Bang:

  • Este o abordare bună pentru sistemele mici.

Dezavantaje ale abordării Big Bang:

  • Este dificil să detectați modulul care cauzează o problemă.
  • Abordarea Big Bang necesită toate modulele împreună pentru testare, ceea ce, la rândul său, duce la mai puțin timp pentru testare, deoarece proiectarea, dezvoltarea, integrarea ar dura mai mult timp.
  • Testarea are loc simultan, ceea ce nu lasă timp pentru testarea modulului critic izolat.

Pași de testare a integrării:

  1. Pregătiți integrarea Planul de testare.
  2. Pregătiți scenarii de testare de integrare și cazuri de testare.
  3. Pregătiți scripturile de automatizare a testelor.
  4. Executați cazuri de testare.
  5. Raportați defectele.
  6. Urmăriți și re-testați defectele.
  7. Re-testarea și testarea continuă până la finalizarea testelor de integrare.

Abordări de integrare a testelor

Există fundamental 2 abordări pentru realizarea integrării testelor:

  1. Abordarea de jos în sus
  2. Abordare de sus în jos.

Să luăm în considerare figura de mai jos pentru a testa abordările:

Integrare 1

Abordarea de jos în sus:

Testarea de jos în sus, așa cum sugerează și numele, începe de la cea mai mică sau cea mai interioară unitate a aplicației și se deplasează treptat în sus. Testarea integrării începe de la cel mai mic modul și progresează treptat către modulele superioare ale aplicației. Această integrare continuă până când toate modulele sunt integrate și întreaga aplicație este testată ca o singură unitate.

În acest caz, modulele B1C1, B1C2 și B2C1, B2C2 sunt cel mai mic modul testat pe unitate. Modulul B1 și B2 nu sunt încă dezvoltate. Funcționalitatea modulelor B1 și B2 este că apelează modulele B1C1, B1C2 și B2C1, B2C2. Deoarece B1 și B2 nu sunt încă dezvoltate, am avea nevoie de un program sau un „stimulator” care va numi modulele B1C1, B1C2 și B2C1, B2C2. Aceste programe stimulatoare sunt numite ȘOFERE .

Cu cuvinte simple, ȘOFERE sunt programele fictive care sunt folosite pentru a apela funcțiile celui mai jos modul într-un caz când funcția de apelare nu există. Tehnica de jos în sus necesită driverul modulului pentru a alimenta intrarea cazului de testare în interfața modulului testat.

Avantajul acestei abordări este că, dacă există o defecțiune majoră la cea mai mică unitate a programului, este mai ușor de detectat și pot fi luate măsuri corective.

Dezavantajul este că programul principal nu există de fapt până când ultimul modul nu este integrat și testat. Ca urmare, defectele de proiectare de nivel superior vor fi detectate numai la sfârșit.

Abordare de sus în jos

Această tehnică începe de la modulul cel mai de sus și progresează treptat către modulele inferioare. Doar modulul de sus este testat separat. După aceasta, modulele inferioare sunt integrate unul câte unul. Procesul se repetă până când toate modulele sunt integrate și testate.

top 5 downloader mp3 pentru Android

În contextul figurii noastre, testarea începe de la modulul A, iar modulele inferioare B1 și B2 sunt integrate unul câte unul. Acum, modulele inferioare B1 și B2 nu sunt de fapt disponibile pentru integrare. Deci, pentru a testa cele mai de sus module A, dezvoltăm „ STUBS ”.

„Stubs” poate fi denumit cod un fragment care acceptă intrările / cererile din modulul de sus și returnează rezultatele / răspunsul. În acest fel, în ciuda modulelor inferioare, nu există, putem testa modulul superior.

În scenariile practice, comportamentul tulpinilor nu este atât de simplu pe cât pare. În această eră a modulelor și arhitecturii complexe, modulul numit, implică de cele mai multe ori logică complexă de afaceri, cum ar fi conectarea la o bază de date. Ca rezultat, crearea Stub-urilor devine la fel de complexă și necesară timp ca modulul real. În unele cazuri, modulul Stub se poate dovedi a fi mai mare decât modulul stimulat.

Atât butoanele, cât și driverele sunt o piesă de cod falsă, care este utilizată pentru testarea modulelor „inexistente”. Acestea declanșează funcțiile / metoda și returnează răspunsul, care este comparat cu comportamentul așteptat

Să concluzionăm o diferență între Butoane și șofer :

CioturiConducător auto
Folosit în abordarea de sus în josFolosit în abordarea de jos în sus
Primul modul de top este testat mai întâiCele mai mici module sunt testate mai întâi.
Stimulează nivelul inferior al componentelorStimulează nivelul mai ridicat al componentelor
Program fals al componentelor de nivel inferiorProgram fals pentru componenta de nivel superior

Singura schimbare este constantă în această lume, așa că avem o altă abordare numită „ Testarea sandwich-ului ”Care combină caracteristicile abordării de sus în jos și de jos în sus. Când testăm programe uriașe precum sistemele de operare, trebuie să avem mai multe tehnici care sunt eficiente și sporesc mai multă încredere. Testarea sandwich-ului joacă un rol foarte important aici, unde ambele teste de sus în jos și de jos în sus sunt pornite simultan.

Integrarea începe cu stratul de mijloc și se deplasează simultan în sus și în jos. În cazul figurii noastre, testarea noastră va începe de la B1 și B2, unde un braț va testa modulul superior A și un alt braț va testa modulele inferioare B1C1, B1C2 și B2C1, B2C2.

Deoarece ambele abordări încep simultan, această tehnică este puțin complexă și necesită mai mulți oameni, împreună cu seturi de abilități specifice și, astfel, adaugă la cost.

Test de integrare a aplicației GUI

Acum să vorbim despre modul în care putem implica testarea integrării în tehnica Black Box.

Cu toții înțelegem că o aplicație web este o aplicație pe mai multe niveluri. Avem un front-end care este vizibil pentru utilizator, avem un layer de mijloc care are logică de afaceri, mai avem un layer de mijloc care face unele validări, integrează niște API-uri ale unor terțe părți etc. Bază de date.

Exemplu de testare a integrării:

Să verificăm exemplul de mai jos:

Sunt proprietarul unei companii de publicitate și postez reclame pe diferite site-uri web. La sfârșitul lunii, vreau să văd câți oameni mi-au văzut anunțurile și câte persoane au dat clic pe anunțurile mele. Am nevoie de un raport pentru anunțurile mele afișate și încarc în mod corespunzător clienților mei.

Software-ul GenNext am dezvoltat acest produs pentru mine și mai jos a fost arhitectura:

Integrare 2

CEAPĂ - Modulul Interfață utilizator, care este vizibil pentru utilizatorul final, unde sunt date toate intrările.
BL - Este modulul Business Logic, care are toate calculele și metodele specifice afacerii.
VAL - Este modulul de validare, care are toate validările corectitudinii intrării.
CNT - Este modulul de conținut care conține tot conținutul static, specific intrărilor introduse de utilizator. Aceste conținuturi sunt afișate în rapoarte.
ÎN - Este modulul Motor, acest modul citește toate datele care provin din modulele BL, VAL și CNT și extrage interogarea SQL și o declanșează în baza de date.
Programator - Este un modul care programează toate rapoartele pe baza selecției utilizatorilor (lunar, trimestrial, semestrial și anual)
DB - Este baza de date.

Acum, după ce am văzut arhitectura întregii aplicații web, ca o singură unitate, testarea integrării, în acest caz, se va concentra pe fluxul de date între module.

Întrebările aici sunt:

  1. Cum vor citi și interpreta modul BL, VAL și CNT datele introduse în modulul UI?
  2. Modulul BL, VAL și CNT primește datele corecte de la interfața de utilizare?
  3. În ce format datele din BL, VAL și CNT sunt transferate în modulul EQ?
  4. Cum va citi EQ datele și va extrage interogarea?
  5. Interogarea este extrasă corect?
  6. Planificatorul primește datele corecte pentru rapoarte?
  7. Setul de rezultate primit de EN, din baza de date este corect și așa cum era de așteptat?
  8. Este EN capabil să trimită răspunsul înapoi la modulele BL, VAL și CNT?
  9. Este modulul UI capabil să citească datele și să le afișeze corespunzător pe interfață?

În lumea reală, comunicarea datelor se face într-un format XML. Deci, orice date pe care le introduce utilizatorul în interfața de utilizare, acestea sunt convertite într-un format XML.

În scenariul nostru, datele introduse în modulul UI sunt convertite în fișier XML care este interpretat de cele 3 module BL, VAL și CNT. Modulul EN citește fișierul XML rezultat generat de cele 3 module și extrage SQL din acesta și interogă în baza de date. Modulul EN primește, de asemenea, setul de rezultate și îl convertește într-un fișier XML și îl returnează înapoi la modulul UI, care convertește rezultatele în formă lizibilă de utilizator și îl afișează.

În mijloc avem modulul de planificare care primește setul de rezultate de la modulul EN, creează și programează rapoartele.

Deci, unde apare testarea integrării?

Ei bine, testarea dacă informațiile / datele curg sau nu corect va fi testarea integrării dvs., care în acest caz ar fi validarea fișierelor XML. Fișierele XML sunt generate corect? Au datele corecte? Datele sunt transferate corect de la un modul la altul? Toate aceste lucruri vor fi testate ca parte a testării integrării.

Încercați să generați sau să obțineți fișiere XML și să actualizați etichetele și verificați comportamentul. Acesta este ceva foarte diferit de testarea obișnuită pe care o fac testerii în mod normal, dar acest lucru va adăuga valoare cunoștințelor și înțelegerii testerilor a aplicației.

Puține alte condiții de testare a probelor pot fi următoarele:

  • Opțiunile meniului generează fereastra corectă?
  • Ferestrele sunt capabile să invoce fereastra testată?
  • Pentru fiecare fereastră, identificați apelurile funcționale pentru fereastra pe care aplicația ar trebui să o permită.
  • Identificați toate apelurile din fereastră către alte caracteristici pe care aplicația ar trebui să le permită
  • Identificați apelurile reversibile: închiderea unei ferestre apelate ar trebui să revină la fereastra de apelare.
  • Identificați apelurile ireversibile: fereastra de apel se închide înainte de a apărea fereastra apelată.
  • Testați diferitele moduri de executare a apelurilor către o altă fereastră, de ex. - meniuri, butoane, cuvinte cheie.

Pași pentru a începe testele de integrare

  1. Înțelegeți arhitectura aplicației dvs.
  2. Identificați modulele
  3. Înțelegeți ce face fiecare modul
  4. Înțelegeți cum sunt transferate datele de la un modul la altul.
  5. Înțelegeți modul în care datele sunt introduse și primite în sistem (punctul de intrare și punctul de ieșire al aplicației)
  6. Separați aplicația pentru a se potrivi nevoilor dvs. de testare.
  7. Identificați și creați condițiile de testare
  8. Ia o condiție pe rând și notează cazurile de testare.

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

Criterii de intrare:

  • Documentul planului de testare a integrării este semnat și aprobat.
  • Au fost pregătite cazuri de testare a integrării.
  • Datele de testare au fost create.
  • Testarea unității a modulelor / componentelor dezvoltate este completă.
  • Toate defectele critice și prioritare sunt închise.
  • Mediul de testare este configurat pentru integrare.

Criterii de ieșire:

  • Toate cazurile de testare a integrării au fost executate.
  • Nu sunt deschise defecte critice și prioritare P1 și P2.
  • Raportul de testare a fost pregătit.

Cazuri de testare a integrării

Testele de integrare se concentrează în principal pe interfață între module, legături integrate, transfer de date între module ca module / componente care sunt deja testate pe unitate, adică funcționalitatea și celelalte aspecte de testare au fost deja acoperite.

Deci, ideea principală este să testăm dacă integrarea a două module de lucru funcționează așa cum era de așteptat atunci când este integrată.

Pentru exemplele de teste de integrare, cazurile pentru aplicația Linkedin vor include:

  • Verificarea legăturii interfeței dintre pagina de conectare și pagina de pornire, adică atunci când un utilizator introduce acreditările și jurnalele, ar trebui să fie direcționat către pagina de pornire.
  • Verificarea legăturii interfeței dintre pagina de pornire și pagina de profil, adică pagina de profil ar trebui să se deschidă.
  • Verificați legătura de interfață dintre pagina de rețea și paginile dvs. de conexiune, adică făcând clic pe butonul Acceptare pe Invitații ale paginii de rețea, trebuie să afișați invitația acceptată în pagina de conexiune după ce ați făcut clic.
  • Verificați legătura interfeței dintre paginile de notificare și spuneți butonul „Felicitări”, adică făcând clic pe butonul „Felicitări” ar trebui să se îndrepte către noua fereastră a mesajului.

Multe cazuri de testare a integrării pot fi scrise pentru acest site specific. Cele patru puncte de mai sus sunt doar un exemplu pentru a înțelege ce cazuri de testare a integrării sunt incluse în testare.

Integrarea este o tehnică cutie albă sau cutie neagră?

Tehnica de testare a integrării poate fi numărată atât în ​​casetele negre, cât și în tehnica cutiei albe . Tehnica cutiei negre este cazul în care un tester nu trebuie să aibă cunoștințe interne despre sistem, adică nu este necesară cunoașterea codării, în timp ce tehnica cutiei albe are nevoie de cunoștințe interne ale aplicației.

Acum, în timp ce efectuați testarea integrării, ar putea include testarea celor două servicii web integrate care vor prelua datele din baza de date și vor furniza datele după cum este necesar, ceea ce înseamnă că ar putea fi testate folosind tehnica de testare a cutiei albe, în timp ce integrarea unei noi caracteristici în site-ul web poate fi testată folosind tehnica cutiei negre.

Deci, nu este specific faptul că testarea integrării este o tehnică de cutie neagră sau de cutie albă.

Instrumente de testare a integrării

Există mai multe instrumente disponibile pentru această testare.

Mai jos este o listă de instrumente:

  • Tester de integrare rațională
  • Raportor
  • Aburi
  • TESSY

Pentru mai multe detalii despre instrumentele de mai sus, verificați acest tutorial:

Top 10 instrumente de testare a integrării pentru a scrie teste de integrare

Testarea integrării sistemului

Testul de integrare a sistemului se face pentru a testa sistem integrat complet .

Modulele sau componentele sunt testate individual în testarea unității înainte de integrarea componentelor.

Odată ce toate modulele sunt testate, testarea integrării sistemului se face prin integrarea tuturor modulelor și sistemul în ansamblu este testat.

Diferența dintre testarea integrării și testarea sistemului

Testarea integrării este o testare în care unul sau două module care sunt testate în unitate sunt integrate pentru testare și verificarea se face pentru a verifica dacă modulele integrate funcționează conform așteptărilor sau nu.

Testarea sistemului este o testare în care sistemul în ansamblu este testat, adică toate modulele / componentele sunt integrate împreună pentru a verifica dacă sistemul funcționează conform așteptărilor și nu apar probleme din cauza modulelor integrate.

Concluzie

Este vorba despre testarea integrării și implementarea acesteia atât în ​​tehnica White Box, cât și în tehnica Black Box. Sper că am explicat-o clar cu exemple relevante.

Integrarea testelor este o parte importantă a ciclului de testare, deoarece face mai ușoară găsirea defectului atunci când două sau mai multe module sunt integrate pentru a integra toate modulele împreună în primul pas în sine.

Ajută la găsirea defectelor într-un stadiu incipient, ceea ce la rândul său economisește efortul și costurile. Se asigură că modulele integrate funcționează corect așa cum era de așteptat.

Sper că acest tutorial informativ privind testarea integrării v-ar fi îmbogățit cunoștințele despre concept.

Lectură recomandată

^