what is integration testing
Kaj je integracijsko testiranje: Naučite se na primerih integracijskega testiranja
Integracijsko testiranje se opravi za testiranje modulov / komponent, ko so integrirani, da se preveri, ali delujejo po pričakovanjih, tj.za testiranje modulov, ki delujejo v redu posamezno, pri integraciji ni težav.
Ko govorimo o preizkušanju velike aplikacije s tehniko preizkušanja črne škatle, vključuje kombinacijo številnih modulov, ki so tesno povezani med seboj. Za preizkušanje tovrstnih scenarijev lahko uporabimo koncepte tehnike integracijskega testiranja.
Seznam vadnic, zajetih v tej seriji:
Vadnica št. 1: Kaj je integracijsko testiranje? (Ta vadnica)
Vadnica # 2: Kaj je inkrementalno testiranje
Vadnica št. 3: Kaj je preizkušanje komponent
Vadnica # 4: Stalna integracija
Vadnica št. 5 Razlika med preskušanjem enote in integracijo
Vadnica # 6: 10 najboljših orodij za testiranje integracije
Kaj se boste naučili:
- Kaj je integracijsko testiranje?
- Zakaj integracijski test?
- Prednosti
- Izzivi
- Vrste integracijskega preskušanja
- Preskusni integracijski pristopi
- Preizkus integracije aplikacije GUI
- Koraki za začetek integracijskih testov
- Merila za vstop / izstop za integracijsko preskušanje
- Primeri integracijskih preizkusov
- Je integracija tehnika bele ali črne škatle?
- Orodja za testiranje integracije
- Testiranje sistemske integracije
- Razlika med integracijskim in sistemskim testiranjem
- Zaključek
- Priporočeno branje
Kaj je integracijsko testiranje?
Pomen integracijskega testiranja je povsem enostaven - Integrirajte / združite enoto preizkušeni modul enega za drugim in preizkusite vedenje kot kombinirana enota.
Glavna naloga ali cilj tega testiranja je preizkus vmesnikov med enotami / moduli.
Običajno integracijsko testiranje opravimo po »enotnem testiranju«. Ko so vse posamezne enote ustvarjene in preizkušene, začnemo kombinirati te module 'Unit Tested' in začnemo izvajati integrirano testiranje.
Glavna naloga ali cilj tega testiranja je preizkus vmesnikov med enotami / moduli.
Posamezne module najprej preizkusimo ločeno. Ko so moduli enotno preizkušeni, jih integriramo enega za drugim, dokler niso vsi moduli integrirani, da preverijo kombinacijsko vedenje in preverijo, ali se zahteve izvajajo pravilno ali ne.
Tu bi morali razumeti, da se integracijsko testiranje ne zgodi na koncu cikla, temveč se izvaja hkrati z razvojem. Tako v večini primerov vsi moduli dejansko niso na voljo za preizkušanje in tukaj je izziv preizkusiti nekaj, kar ne obstaja!
Zakaj integracijski test?
Menimo, da je integracijsko testiranje zapleteno in zahteva nekaj razvojnih in logičnih spretnosti. To je res! Kaj je potem namen vključitve tega testiranja v našo strategijo testiranja?
Nekaj razlogov:
- V resničnem svetu se aplikacije razvijajo na manjše module in posamezni razvijalci dobijo 1 modul. Logika, ki jo izvaja en razvijalec, se precej razlikuje od drugega, zato je pomembno preveriti, ali je logika, ki jo izvaja razvijalec, v skladu s pričakovanji in ali upodablja pravilno vrednost v skladu s predpisanimi standardi.
- Velikokrat se spremeni obraz ali struktura podatkov, ko potujejo od enega modula do drugega. Nekatere vrednosti so dodane ali odstranjene, kar povzroča težave v poznejših modulih.
- Moduli sodelujejo tudi z nekaterimi orodji ali API-ji tretjih oseb, ki jih je treba tudi preizkusiti, ali so podatki, ki jih ta API / orodje sprejme, pravilni in da je ustvarjeni odziv tudi pričakovan.
- Zelo pogosta težava pri testiranju - pogoste spremembe zahtev! :) Razvijalec velikokrat uporabi spremembe, ne da bi jih enota preizkusila. Takrat postane pomembno integracijsko testiranje.
Prednosti
Prednosti tega testiranja je več, nekaj pa jih je naštetih spodaj.
- To testiranje zagotavlja pravilno delovanje integriranih modulov / komponent.
- Integracijsko testiranje se lahko začne, ko so na voljo moduli, ki jih je treba preskusiti. Za testiranje ni treba dokončati drugega modula, saj se lahko za isti uporabljajo Stubs in Drivers.
- Zazna napake, povezane z vmesnikom.
Izzivi
Spodaj je navedenih nekaj izzivov, ki jih vključuje Integracijski test.
# 1) Integracijsko testiranje pomeni testiranje dveh ali več integriranih sistemov, da se zagotovi pravilno delovanje sistema. Preizkusiti je treba ne samo integracijske povezave, temveč je treba izvesti tudi izčrpno preskušanje, da bi zagotovili pravilno delovanje integriranega sistema.
Za preizkušanje integriranega sistema se lahko uporabljajo različne poti in permutacije.
#two) Upravljanje integracijskega testiranja postane zapleteno zaradi nekaj dejavnikov, kot so baza podatkov, platforma, okolje itd.
# 3) Medtem ko integrira kateri koli nov sistem s starejšim sistemom, zahteva veliko sprememb in preizkusov. Enako velja pri integraciji katerega koli starega sistema.
# 4) Integriranje dveh različnih sistemov, ki sta jih razvili dve različni podjetji, je velik izziv, saj vprašanje, kako bo eden od sistemov vplival na drugi sistem, če bodo v katerem koli sistemu izvedene kakršne koli spremembe, ni prepričan.
Da bi pri razvoju sistema zmanjšali učinek, je treba upoštevati nekaj stvari, kot je možna integracija z drugimi sistemi itd.
Vrste integracijskega preskušanja
Spodaj je vrsta integracije preizkusov, skupaj s svojimi prednostmi in slabostmi.
Pristop velikega poka:
Pristop Big Bang integrira vse module naenkrat, torej ne gre za integracijo modulov enega za drugim. Preveri, ali sistem deluje po pričakovanjih ali ni enkrat integriran. Če je v popolnoma integriranem modulu zaznana kakršna koli težava, je težko ugotoviti, kateri modul je povzročil težavo.
Pristop velikega poka je dolgotrajen postopek iskanja modula, ki ima samo napako, saj bi to trajalo nekaj časa in ko bi napako odkrili, bi odprava iste stala visoko, kot da bi napako odkrili pozneje.
Prednosti pristopa Big Bang:
- To je dober pristop za majhne sisteme.
Slabosti pristopa velikega poka:
- Težko je zaznati modul, ki povzroča težavo.
- Pristop Big Bang za testiranje zahteva vse module, kar posledično vodi do manj časa za testiranje, saj bi načrtovanje, razvoj in integracija vzela večino časa.
- Testiranje poteka le naenkrat, zato ni časa za preskušanje kritičnih modulov ločeno.
Koraki za preskušanje integracije:
- Pripravite integracijo Testni načrt.
- Pripravite scenarije integracijskih preizkusov in testne primere.
- Pripravite skripte za avtomatizacijo preskusov.
- Izvedite testne primere.
- Prijavite napake.
- Izsledite in znova preizkusite napake.
- Ponovno testiranje in testiranje se nadaljuje, dokler se integracijsko testiranje ne konča.
Preskusni integracijski pristopi
Obstajata v bistvu 2 pristopa za izvajanje testne integracije:
- Pristop od spodaj navzgor
- Pristop od zgoraj navzdol.
Za preizkus pristopov si oglejmo spodnjo sliko:
Pristop od spodaj navzgor:
Preskušanje od spodaj navzgor, kot že ime pove, se začne od najnižje ali najbolj notranje enote aplikacije in se postopoma premika navzgor. Preizkušanje integracije se začne od najnižjega modula in postopoma napreduje proti zgornjim modulom aplikacije. Ta integracija se nadaljuje, dokler se vsi moduli ne integrirajo in celotna aplikacija ni preizkušena kot ena enota.
V tem primeru so moduli B1C1, B1C2 in B2C1, B2C2 najnižji modul, ki je enotno preizkušen. Modula B1 in B2 še nista razvita. Funkcionalnost modulov B1 in B2 je v tem, da pokliče module B1C1, B1C2 in B2C1, B2C2. Ker B1 in B2 še nista razviti, bi potrebovali program ali 'stimulator', ki bi poklical module B1C1, B1C2 in B2C1, B2C2. Ti stimulacijski programi se imenujejo VOZNIKI .
Z enostavnimi besedami VOZNIKI so navidezni programi, ki se uporabljajo za klicanje funkcij najnižjega modula v primeru, ko klicna funkcija ne obstaja. Tehnika od spodaj navzgor zahteva, da gonilnik modula napaja vnos testnega primera v vmesnik preskušanega modula.
Prednost tega pristopa je, da če obstaja večja napaka na najnižji enoti programa, jo je lažje odkriti in je mogoče sprejeti korektivne ukrepe.
Pomanjkljivost je, da glavni program dejansko ne obstaja, dokler ni zadnji modul integriran in preizkušen. Posledično bodo napake pri oblikovanju višje ravni zaznane šele na koncu.
Pristop od zgoraj navzdol
Ta tehnika se začne od zgornjega modula in postopoma napreduje do spodnjih modulov. Samo zgornji modul je enotno preizkušen. Po tem se spodnji moduli integrirajo en za drugim. Postopek se ponavlja, dokler niso vsi moduli integrirani in preizkušeni.
sql test vprašanja in odgovori pdf
V okviru naše slike se testiranje začne z modulom A, spodnja modula B1 in B2 pa sta integrirana eden za drugim. Zdaj spodnja modula B1 in B2 dejansko nista na voljo za integracijo. Torej, da bi preizkusili najvišje module A, smo razvili “ ŠTUBE '.
'Stubs' lahko imenujemo delček kode, ki sprejema vhode / zahteve zgornjega modula in vrne rezultate / odgovor. Tako kljub spodnjim modulom ne obstajamo, lahko preizkusimo zgornji modul.
V praktičnih scenarijih vedenje škrbine ni tako preprosto, kot se zdi. V tej dobi kompleksnih modulov in arhitekture, imenovani modul, večino časa vključuje zapleteno poslovno logiko, kot je povezava z bazo podatkov. Kot rezultat, ustvarjanje Stub-ov postane tako zapleteno in dolgotrajno kot pravi modul. V nekaterih primerih se lahko izkaže, da je modul Stub večji od stimuliranega modula.
Tako Stubs kot gonilniki so lažni del kode, ki se uporablja za testiranje 'neobstoječih' modulov. Sprožijo funkcije / metodo in vrnejo odziv, ki se primerja s pričakovanim vedenjem
Zaključimo nekaj razlike med Škrbine in voznik :
Škrbine | Voznik |
---|---|
Uporablja se pri pristopu od zgoraj navzdol | Uporablja se pri pristopu od spodaj navzgor |
Najbolj modul je najprej preizkušen | Najprej se preizkusijo najnižji moduli. |
Spodbuja nižjo raven komponent | Spodbuja višjo raven komponent |
Lažni program komponent nižje ravni | Lažni program za komponento višje stopnje |
Edina sprememba je Constant na tem svetu, zato imamo še en pristop, imenovan ' Preskus sendviča ”, Ki združuje značilnosti pristopa od zgoraj navzdol in od spodaj navzgor. Ko preizkušamo ogromne programe, kot so operacijski sistemi, moramo imeti še nekaj tehnik, ki so učinkovite in povečujejo zaupanje. Preskus sendviča ima tukaj zelo pomembno vlogo, kjer se hkrati začneta testiranje od zgoraj navzdol in od spodaj navzgor.
Integracija se začne s srednjo plastjo in se hkrati premika navzgor in navzdol. V primeru naše številke se bo naše testiranje začelo od B1 in B2, kjer bo ena roka preizkusila zgornji modul A, druga roka pa spodnje module B1C1, B1C2 & B2C1, B2C2.
Ker se oba pristopa začneta sočasno, je ta tehnika nekoliko zapletena in zahteva več ljudi skupaj s posebnimi sklopi spretnosti in s tem povečuje stroške.
Preizkus integracije aplikacije GUI
Zdaj pa se pogovorimo o tem, kako lahko impliciramo integracijsko testiranje v tehniki Black box.
Vsi vemo, da je spletna aplikacija večstopenjska aplikacija. Imamo prednji del, ki je viden uporabniku, imamo srednji sloj, ki ima poslovno logiko, imamo še nekaj srednjega sloja, ki opravi nekatera preverjanja veljavnosti, integrira nekatere API-je tretjih oseb itd., Nato imamo zadnji sloj, ki je zbirke podatkov.
Primer integracijskega testiranja:
Preverimo spodnji primer:
Sem lastnik oglaševalskega podjetja in oglase objavljam na različnih spletnih mestih. Konec meseca želim videti, koliko ljudi je videlo moje oglase in koliko ljudi je kliknilo moje oglase. Za prikazane oglase potrebujem poročilo in strankam zaračunam v skladu s tem.
Programska oprema GenNext ta izdelek razvil zame in spodaj je bila arhitektura:
ČEBULA - Uporabniški vmesniški modul, ki je viden končnemu uporabniku, kjer so podani vsi vhodi.
BL - Je modul Business Logic, ki vsebuje vse izračune in poslovne metode.
VAL - Ali je modul za preverjanje veljavnosti, ki vsebuje vsa preverjanja pravilnosti vnosa.
CNT - Ali je vsebinski modul, ki ima vso statično vsebino, specifičen za vnose, ki jih vnese uporabnik. Ta vsebina je prikazana v poročilih.
IN - Je modul Engine, ta modul bere vse podatke, ki prihajajo iz modulov BL, VAL in CNT, izvleče poizvedbo SQL in jo sproži v bazo podatkov.
Načrtovalec - Je modul, ki načrtuje vsa poročila na podlagi izbire uporabnika (mesečno, četrtletno, polletno in letno)
DB - Je baza podatkov.
Zdaj, ko smo arhitekturo celotne spletne aplikacije videli kot eno samo enoto, se bo testiranje integracije v tem primeru osredotočilo na pretok podatkov med moduli.
Tukaj so vprašanja:
- Kako bodo moduli BL, VAL in CNT brali in interpretirali podatke, vnesene v modul UI?
- Ali modul BL, VAL in CNT prejema pravilne podatke od uporabniškega vmesnika?
- V kateri obliki se podatki iz BL, VAL in CNT prenesejo v modul EQ?
- Kako bo EQ prebral podatke in izvlekel poizvedbo?
- Ali je poizvedba pravilno izvlečena?
- Ali načrtovalec dobi pravilne podatke za poročila?
- Ali je nabor rezultatov, ki ga EN prejme iz baze podatkov, pravilen in po pričakovanjih?
- Ali lahko EN pošlje odgovor nazaj na module BL, VAL in CNT?
- Ali lahko modul UI bere podatke in jih ustrezno prikaže vmesniku?
V resničnem svetu se sporočanje podatkov izvaja v obliki XML. Torej, katere koli podatke uporabnik vnese v uporabniški vmesnik, se pretvorijo v format XML.
V našem primeru se podatki, vneseni v modul UI, pretvorijo v datoteko XML, ki jo interpretirajo 3 moduli BL, VAL in CNT. Modul EN prebere nastalo datoteko XML, ki so jo ustvarili 3 moduli, iz nje izvleče SQL in poizveduje v bazo podatkov. Modul EN prav tako prejme nabor rezultatov in ga pretvori v datoteko XML ter vrne nazaj v modul UI, ki rezultate pretvori v uporabniško berljivo obliko in prikaže.
Na sredini imamo modul razporejevalnika, ki sprejema nabor rezultatov od modula EN, ustvarja in načrtuje poročila.
Torej, kje se pojavi integracijsko testiranje?
No, preizkušanje, ali informacije / podatki tečejo pravilno ali ne, bo vaše integracijsko testiranje, ki bi v tem primeru potrdilo datoteke XML. Ali so datoteke XML pravilno ustvarjene? Ali imajo pravilne podatke? Ali se podatki pravilno prenašajo z enega modula na drugega? Vse te stvari bodo preizkušene v okviru testiranja integracije.
Poskusite ustvariti ali pridobiti datoteke XML, posodobiti oznake in preveriti vedenje. To je nekaj zelo drugačnega od običajnega testiranja, ki ga preizkuševalci običajno izvajajo, vendar bo to dodalo vrednost znanju in razumevanju aplikacije.
Nekaj drugih pogojev preskusa vzorca je lahko naslednjih:
- Ali možnosti menija ustvarjajo pravilno okno?
- Ali lahko okna prikličejo testno okno?
- Za vsako okno določite klice funkcij za okno, ki naj ga aplikacija dovoli.
- Ugotovite vse klice iz okna do drugih funkcij, ki jih mora aplikacija omogočati
- Prepoznavanje povratnih klicev: zapiranje poklicanega okna se mora vrniti v okno klica.
- Ugotovite nepovratne klice: klicanje oken se zapre, preden se pokliče okno.
- Preizkusite različne načine izvajanja klicev v drugo okno, npr. - meniji, gumbi, ključne besede.
Koraki za začetek integracijskih testov
- Razumevanje arhitekture vaše aplikacije.
- Določite module
- Razumevanje, kaj počne vsak modul
- Razumevanje načina prenosa podatkov z enega modula na drugega.
- Razumevanje načina vnosa in sprejemanja podatkov v sistem (vstopna in izstopna točka aplikacije)
- Ločite aplikacijo glede na potrebe testiranja.
- Ugotovite in ustvarite preskusne pogoje
- Vzemite en pogoj naenkrat in zapišite testne primere.
Merila za vstop / izstop za integracijsko preskušanje
Kriteriji za vstop:
- Dokument načrta integracijskega preskusa je podpisan in odobren.
- Pripravljeni so primeri integracijskih testov.
- Ustvarjeni so bili preskusni podatki.
- Enotno testiranje razvitih modulov / komponent je končana.
- Vse kritične in prednostne napake so zaprte.
- Testno okolje je nastavljeno za integracijo.
Merila izstopa:
- Izvedeni so bili vsi primeri integracijskega preskusa.
- Kritične in prednostne napake P1 in P2 niso odprte.
- Pripravljeno je poročilo o preskusu.
Primeri integracijskih preizkusov
Integracijski testni primeri se osredotočajo predvsem na vmesnik med moduli, integrirane povezave, prenos podatkov med moduli kot moduli / sestavni deli, ki so že preizkušeni na enoto, tj. funkcionalnost in drugi vidiki preskušanja so že zajeti.
Glavna ideja je torej preizkusiti, ali integracija dveh delovnih modulov deluje po pričakovanjih, ko je integrirana.
Primeri integracijskih testnih primerov za aplikacijo Linkedin vključujejo:
- Preverjanje vmesniške povezave med prijavno stranjo in domačo stranjo, tj.Ko uporabnik vnese poverilnice in se prijavi, naj bo usmerjen na domačo stran.
- Odpre se preverjanje vmesniške povezave med domačo stranjo in stranjo profila, tj. Stran profila.
- Preverite vmesniško povezavo med omrežno stranjo in vašimi stranmi s povezavo, tj. Če kliknete gumb za sprejem na povabilih na omrežni strani, bi moralo biti prikazano sprejeto povabilo na vaši strani s povezavo, ko enkrat kliknete.
- Preverite vmesniško povezavo med stranmi z obvestili in izgovorite gumb Čestitamo, tj. Če kliknete gumb Čestitke, se usmerite v novo okno s sporočilom.
Za to spletno mesto je mogoče napisati veliko primerov za integracijo. Zgornje štiri točke so le primer za razumevanje, kateri primeri integracije so vključeni v testiranje.
Je integracija tehnika bele ali črne škatle?
Tehniko integracijskega preskušanja lahko štejemo v obe črni škatli, pa tudi tehnika bele škatle . Tehnika črne škatle je, če preizkuševalec ne potrebuje notranjega znanja o sistemu, tj. kodiranje ni potrebno, medtem ko tehnika belega polja potrebuje notranje znanje o aplikaciji.
Med izvajanjem integracijskega testiranja bi lahko vključeval testiranje dveh integriranih spletnih storitev, ki bosta podatke zajemali iz baze podatkov in po potrebi zagotavljali podatke, kar pomeni, da bi jih bilo mogoče preizkusiti s tehniko testiranja belega polja, medtem ko je mogoče preizkusiti vključitev nove funkcije v spletno stran z uporabo tehnike črne škatle.
Torej ni specifično, da je integracijsko testiranje tehnika črne ali bele škatle.
Orodja za testiranje integracije
Za to testiranje je na voljo več orodij.
Spodaj je seznam orodij:
- Tester racionalne integracije
- Kotomer
- Steam
- TESSY
Za več podrobnosti o zgornjih orodjih si oglejte to vadnico:
10 najboljših orodij za integracijsko testiranje za pisanje integracijskih testov
Testiranje sistemske integracije
Test sistemske integracije se opravi za preizkus popoln integriran sistem .
Moduli ali sestavni deli se pred vgradnjo komponent preskusijo posamezno.
Ko so testirani vsi moduli, se z integracijo vseh modulov opravi testiranje sistemske integracije in sistem kot celota se preskusi.
Razlika med integracijskim in sistemskim testiranjem
Integracijsko testiranje je testiranje, pri katerem sta za preskušanje integrirana en ali dva modula, ki sta enotno preizkušena, in preverjanje se izvede, da se preveri, ali integrirani moduli delujejo po pričakovanjih ali ne.
Testiranje sistema je preskušanje, kjer sistem kot celota vsi moduli / komponente so integrirani skupaj, da se preveri, ali sistem deluje po pričakovanjih in zaradi integriranih modulov ne pride do težav.
Zaključek
To je vse o integracijskem testiranju in njegovi izvedbi v tehniki White box in Black box. Upam, da smo to jasno pojasnili z ustreznimi primeri.
Preizkusna integracija je pomemben del preskusnega cikla, saj olajša iskanje napake, ko sta integrirana dva ali več modulov, da se vsi moduli integrirajo v prvem koraku.
Pomaga pri odkrivanju napak v zgodnji fazi, kar prihrani tudi trud in stroške. Zagotavlja, da integrirani moduli delujejo pravilno, kot je bilo pričakovano.
Upam, da bi vam ta informativni vodič o integracijskem testiranju obogatil znanje o konceptu.
Priporočeno branje
- Kaj je testiranje komponent ali testiranje modulov (naučite se s primeri)
- Najboljša orodja za testiranje programske opreme 2021 [QA Test Automation Tools]
- Spock za integracijo in funkcionalno testiranje s selenom
- Razlike med preskušanjem enot, preskušanjem integracije in funkcionalnim preskušanjem
- Integracija selena z JMeter
- Preizkus eBook Prenos knjige
- Funkcionalno testiranje vs nefunkcionalno testiranje
- Vadnica za testiranje v parih ali za vse pare z orodji in primeri