Što je integracijsko testiranje? (Primjer)

Što je integracijsko testiranje?

Ispitivanje integracije definira se kao vrsta testiranja gdje su softverski moduli logički integrirani i testirani kao grupa. Tipičan softverski projekt sastoji se od više softverskih modula koje su kodirali različiti programeri. Svrha ove razine testiranja je otkriti nedostatke u interakciji između ovih softverskih modula kada su integrirani

Testiranje integracije usredotočeno je na provjeru podatkovne komunikacije između ovih modula. Stoga se naziva i kao 'Ja i T' (Integracija i testiranje), 'Testiranje nizova' i ponekad 'Testiranje niti'.

Zašto raditi integracijsko testiranje?

Iako je svaki softverski modul jedinično testiran, nedostaci i dalje postoje iz raznih razloga kao što su

• Modul, općenito, dizajnira pojedinačni programer softvera čije se razumijevanje i logika programiranja mogu razlikovati od ostalih programera. Integracijsko testiranje postaje neophodno kako bi se provjerilo da softverski moduli rade u jedinstvu
• U vrijeme razvoja modula, postoje velike šanse za promjenu zahtjeva od strane klijenata. Ovi novi zahtjevi možda neće biti jedinično testirani i stoga testiranje integracije sustava postaje neophodno.
• Sučelja softverskih modula s bazom podataka mogu biti pogrešna
• Vanjska hardverska sučelja, ako postoje, mogu biti pogrešna
• Neadekvatno rukovanje iznimkama može uzrokovati probleme.

Kliknite ovdje ako video nije dostupan

Primjer testnog slučaja integracije

Integracija Testni slučaj razlikuje se od ostalih testnih slučajeva u smislu da fokusira se uglavnom na sučelja i protok podataka/informacija između modula. Ovdje prednost treba dati integrirajući poveznice nego funkcije jedinice koje su već testirane.

Primjeri testnih slučajeva integracije za sljedeći scenarij: Aplikacija ima 3 modula recimo 'Stranica za prijavu', 'Mailbox' i 'Delete emails' i svaki od njih je logički integriran.

Ovdje se nemojte puno koncentrirati na testiranje stranice za prijavu jer je to već učinjeno Ispitivanje jedinice. Ali provjerite kako je to povezano s Mail Box Stranica.

slično Mail Box: Provjerite njegovu integraciju u Delete Mails Modul.

ID testnog slučaja	Cilj testnog slučaja	Testni slučaj Description	očekivani rezultat
1	Provjerite vezu sučelja između Login i Mailmodul kutije	Unesite vjerodajnice za prijavu i kliknite na gumb Prijava	Biti usmjeren na Mail Box
2	Provjerite vezu sučelja između Mailokvir i Delete Mails Modul	Od Mailodaberite e-poštu i kliknite gumb za brisanje	Odabrana e-pošta trebala bi se pojaviti u mapi Izbrisano/Smeće

Vrste integracijskog testiranja

Softversko inženjerstvo definira različite strategije za izvođenje integracijskog testiranja, tj.

• Pristup Velikom prasku:
• Inkrementalni pristup: koji se dalje dijeli na sljedeće
  • Pristup odozgo prema dolje
  • Pristup odozdo prema gore
  • Sendvič pristup – kombinacija odozgo prema dolje i odozdo prema gore

Ispod su različite strategije, način na koji se provode i njihova ograničenja kao i prednosti.

Testiranje velikog praska

Testiranje velikog praska je pristup testiranju integracije u kojem se sve komponente ili moduli integriraju zajedno i zatim testiraju kao cjelina. Ovaj kombinirani skup komponenti smatra se entitetom tijekom testiranja. Ako sve komponente u jedinici nisu dovršene, proces integracije se neće izvršiti.

Prednosti:

• Pogodno za male sustave.

Nedostaci:

• Lokalizacija kvara je teška.
• S obzirom na veliki broj sučelja koje je potrebno testirati u ovom pristupu, neke veze sučelja koje treba testirati mogle bi se lako propustiti.
• Budući da integracijsko testiranje može započeti tek nakon što su "svi" moduli dizajnirani, tim za testiranje će imati manje vremena za izvođenje u fazi testiranja.
• Budući da se svi moduli testiraju odjednom, visokorizični kritični moduli nisu izolirani i testirani po prioritetu. Periferni moduli koji se bave korisničkim sučeljima također nisu izolirani i testirani su prioritetno.

Inkrementalno testiranje

u Inkrementalno testiranje pristupu, testiranje se provodi integracijom dva ili više modula koji su međusobno logički povezani, a zatim se testira ispravnost rada aplikacije. Zatim se postupno integriraju drugi povezani moduli i proces se nastavlja dok se svi logički povezani moduli ne integriraju i uspješno testiraju.

Inkrementalni pristup se pak provodi pomoću dvije različite metode:

• Odozdo prema gore
• Odozgo dolje

Stubovi i vozači

Stubovi i vozači su lažni programi u integracijskom testiranju koji se koriste za olakšavanje testiranje softvera aktivnost. Ovi programi djeluju kao zamjena za modele koji nedostaju u testiranju. Oni ne implementiraju cjelokupnu programsku logiku softverskog modula, ali simuliraju podatkovnu komunikaciju s pozivnim modulom tijekom testiranja.

iskrčiti: Poziva ga modul koji se testira.

vozač: Poziva modul koji treba testirati.

Integracijsko testiranje odozdo prema gore

Integracijsko testiranje odozdo prema gore je strategija u kojoj se prvo testiraju moduli niže razine. Ovi testirani moduli se zatim dalje koriste za olakšavanje testiranja modula više razine. Proces se nastavlja dok se ne testiraju svi moduli na najvišoj razini. Nakon što se moduli niže razine testiraju i integriraju, formira se sljedeća razina modula.

Dijagramski prikaz:

Prednosti:

• Lakše je lokalizirati kvar.
• Ne gubi se vrijeme čekajući da se svi moduli razviju za razliku od Big-bang pristupa

Nedostaci:

• Kritični moduli (na najvišoj razini softverske arhitekture) koji kontroliraju tijek aplikacije testiraju se zadnji i mogu biti skloni kvarovima.
• Rani prototip nije moguć

Top-down integracijsko testiranje

Testiranje integracije odozgo prema dolje je metoda u kojoj se testiranje integracije odvija odozgo prema dolje prateći kontrolni tok softverskog sustava. Prvo se testiraju moduli više razine, a zatim se testiraju i integriraju moduli niže razine kako bi se provjerila funkcionalnost softvera. Stubovi se koriste za testiranje ako neki moduli nisu spremni.

Dijagramski prikaz:

Prednosti:

• Lokalizacija greške je lakša.
• Mogućnost dobivanja ranog prototipa.
• Kritični moduli se testiraju po prioritetu; glavni nedostaci dizajna mogu se prvo pronaći i popraviti.

Nedostaci:

• Treba mnogo Stubova.
• Moduli na nižoj razini su neadekvatno ispitani.

Kako napraviti integracijsko testiranje?

Postupak testiranja integracije bez obzira na strategije testiranja softvera (o kojima se govori gore):

1. Pripremite integraciju Plan testiranja
2. Dizajnirajte testne scenarije, slučajeve i skripte.
3. Izvršavanje testnih slučajeva nakon čega slijedi prijava nedostataka.
4. Praćenje i ponovno testiranje nedostataka.
5. Koraci 3 i 4 se ponavljaju sve dok završetak integracije ne bude uspješan.

Kratak Description planova testiranja integracije

Uključuje sljedeće atribute:

• Metode/pristupi testiranju (kako je gore navedeno).
• Opsezi i stavke izvan opsega integracijskog testiranja.
• Uloge i odgovornosti.
• Preduvjeti za integracijsko testiranje.
• Okruženje za testiranje.
• Planovi rizika i ublažavanja.

Ulazni i izlazni kriteriji integracijskog testiranja

Ulazni i izlazni kriteriji za fazu testiranja integracije u bilo kojem modelu razvoja softvera

Kriteriji ulaska:

• Jedinično testirane komponente/moduli
• Sve greške s visokim prioritetom ispravljene su i zatvorene
• Svi moduli moraju biti dovršeni kodom i uspješno integrirani.
• Integracijski testovi Plan, test slučaj, scenariji koje treba potpisati i dokumentirati.
• potreban Ispitna okolina biti postavljen za integracijsko testiranje

Kriteriji za izlaz:

• Uspješno testiranje integrirane aplikacije.
• Izvršeni testni slučajevi su dokumentirani
• Sve greške s visokim prioritetom ispravljene su i zatvorene
• Tehnički dokumenti koje treba dostaviti praćeni napomenama o izdanju.

Najbolje prakse/smjernice za integracijsko testiranje

• Prvo odredite integraciju Strategija testiranja koji bi se mogli usvojiti i kasnije pripremiti testne slučajeve i testne podatke u skladu s tim.
• Proučite Archistrukturni dizajn aplikacije i identificiranje kritičnih modula. Njih je potrebno prioritetno testirati.
• Nabavite dizajn sučelja od Architectural team i izraditi testne slučajeve za detaljnu provjeru svih sučelja. Sučelje s bazom podataka/vanjskom hardverskom/softverskom aplikacijom mora se detaljno testirati.
• Nakon testnih slučajeva, testni podaci igraju ključnu ulogu.
• Prije izvođenja uvijek pripremite lažne podatke. Ne birajte testne podatke tijekom izvođenja testnih slučajeva.