Meni

Kaj je dodatno testiranje: podrobna razlaga s primeri

what is incremental testing

Preizkusite Naš Instrument Za Odpravo Težav

S pomočjo tega članka bom predstavil enega pomembnih pristopov integracije - inkrementalno testiranje.

Do konca tega oddelka bo občinstvo dobro vedelo naslednje:

  • Kaj je dodatno testiranje?
  • Njegov cilj
  • Metodologije
  • Prednosti
  • Pomanjkljivosti

Kaj se boste naučili:

Kaj je inkrementalno testiranje

Inkrementalno testiranje, znano tudi kot Inkrementalno integracijsko testiranje, je eden od pristopov integracijskega testiranja in vključuje njegove temeljne koncepte.

To je kot test, ki združuje modul in integracijo preskusna strategija .

Dodatno testiranje

Pri tem preizkušanju preizkusimo vsak modul posebej v fazi preskušanja enot, nato pa se moduli postopoma integrirajo in preizkusijo, da se zagotovi nemoten vmesnik in interakcija med moduli.

Pri tem pristopu se vsak modul postopoma kombinira, torej eden za drugim, dokler se vsi moduli ali komponente logično ne dodajo, da se naredi zahtevana aplikacija, namesto da bi integrirali celoten sistem hkrati in nato izvedli preskušanje končnega izdelka. Integrirani moduli so preizkušeni kot skupina, da se zagotovi uspešna integracija in pretok podatkov med moduli.

Tako kot pri integracijskem testiranju je tudi pri tem testiranju glavni poudarek preverjanje vmesnika, integriranih povezav in pretoka informacij med moduli. Ta postopek se ponavlja, dokler se moduli ne kombinirajo in uspešno preizkusijo.

Primer

Razumimo ta koncept s primerom:

Sistemska ali programska aplikacija je sestavljena iz naslednjih modulov:

Programska aplikacija

Pristop pristopnega testiranja integracije

  • Vsak modul, tj. M1, M2, M3 itd., Se preizkusi posamično kot del enote
  • Moduli se kombinirajo postopoma, tj. Enega za drugim in preizkušajo za uspešno interakcijo
  • Na sliki 2 sta modula M1 in modul M2 združena in preizkušena
  • Na sliki 3 je dodan in preizkušen modul M3
  • Na sliki 4 je dodan modul M4 in opravljeno testiranje, da se prepriča, ali vse skupaj uspešno deluje
  • Preostali deli modulov se prav tako postopoma dodajajo v vsakem koraku in preizkušajo za uspešno integracijo

Slika2

Kombinirana dva modula

Slika3

Kombinirani 3 moduli

nedefinirano sklicevanje na c ++

Slika4

Kombinirani štirje moduli

Cilj dodatnega preizkusa

  • Za zagotovitev uspešnega sodelovanja različnih modulov po integraciji
  • Napake ugotovite prej in v vsaki fazi. To daje razvijalcem prednost, da prepoznajo, kje je težava. Tako kot če je testiranje po integraciji M1 in M2 uspešno, toda ko dodamo M3, test ne uspe; to bo razvijalcu pomagalo pri ločevanju težave
  • Težave je mogoče odpraviti v zgodnji fazi brez večje predelave in z nižjimi stroški

Metode preskušanja postopnega povezovanja

Preden začnemo s to temo, bi rad na kratko predstavil Škrbine in vozniki saj bomo te izraze pogosto uporabljali.

Zatiči in gonilniki so psevdo koda ali navidezna koda, ki se uporablja v Integraciji oz preskušanje komponent kadar eden ali več modulov ni razvitih, vendar so potrebni za preizkus drugega modula.

Škrbine se uporabljajo v pristopu od zgoraj navzdol in so znani kot 'imenovani programi'. Gredi pomagajo simulirati vmesnik med moduli spodnje ročice, ki niso na voljo ali razviti.

Vozniki se uporabljajo v pristopu od spodaj navzgor in so znani kot 'klicni programi'. Gonilniki pomagajo simulirati vmesnik med moduli najvišje ravni, ki niso razviti ali na voljo.

Vprašanje, ki bi se lahko pojavilo pri nekaterih izmed nas, je, zakaj pred začetkom testiranja ne počakajte, da se razvijejo vsi aplikacijski moduli, namesto da uporabite stub / gonilnik?

Preprost odgovor je, da povečuje čas izvedbe projekta, saj bodo preizkuševalci sedeli brez dela, dokler ne bodo razviti vsi moduli. To tudi otežuje analizo korenin napake. Ta vrsta preskusnega pristopa je znana kot integracija Big-Bang.

Zdaj, ko smo pokrili Stubs in voznike, pojdimo na različne metodologije postopnega testiranja:

# 1) Od zgoraj navzdol

Kot že ime pove, testiranje poteka od zgoraj navzdol, torej od osrednjega modula do podmodula. Moduli, ki uokvirjajo zgornjo plast aplikacije, se najprej preizkusijo.

Ta pristop sledi strukturnemu toku aplikacije, ki se preskuša. Nerazpoložljivi ali nerazviti moduli ali komponente so nadomeščeni s škrbinami.

Razumimo to na primeru:

  • Modul : Prijava na spletno stran aka L
  • Modul : Naročilo aka O
    • Povzetek naročila modula aka OS (še ni razvit)
  • Modul : Plačilo aka P
    • Modul Gotovinsko plačilo aka CP
    • Modul Debitno / kreditno plačilo aka DP (še ni razvito)
    • Module Wallet Payment aka WP (še ni razvito)
  • Modul: Poročanje aka R (še ni razvito)

Pristop od zgoraj navzdol

Pristop pristopnega testiranja od zgoraj navzdol

Izvedeni bodo naslednji testni primeri:

Testni primer 1: Modula L in O bosta integrirana in preizkušena
Testni primer2: Moduli L, O in P bodo integrirani in preizkušeni
Testni primer3: Moduli L, O, P in R bodo integrirani in preizkušeni.

In tako naprej izhajajo tudi drugi primeri.

Ta vrsta preskušanja, pri kateri so vsi moduli na plasti najprej integrirani in preizkušeni, je znana kot „širina najprej“. Druga kategorija je 'najprej globina'.

Za 'globino najprej' bodo izvedeni naslednji testni primeri:

Testni primer 1: Modula L in O bosta integrirana in preizkušena
Testni primer2: Moduli L, O in OS bodo integrirani in preizkušeni
Testni primer3: Modul L, O, OS, P bo integriran in preizkušen
Testni primer4: Modul L, O, OS, P, CP bo integriran in preizkušen

In tako naprej izhajajo tudi drugi primeri.

Zasluge metodologije od zgoraj navzdol

  • Zgodnja izpostavljenost arhitekturnih napak
  • Opisuje delovanje aplikacije kot celote v zgodnjih fazah in pomaga pri zgodnjem odkrivanju konstrukcijskih napak
  • Glavne kontrolne točke se preizkusijo zgodaj

Zasluge metodologije od zgoraj navzdol

  • Pomembni moduli se preizkusijo pozno v ciklu
  • Zelo zahtevno je pisati testne pogoje
  • Škrbina ni popolna izvedba povezanega modula. Samo simulira pretok podatkov med dvema moduloma

# 2) od spodaj navzgor

Pri tem pristopu testiranje poteka od spodaj navzgor, to pomeni, da se najprej integrirajo in preizkusijo moduli na spodnjem sloju, nato pa se zaporedoma integrirajo drugi moduli, ko gremo navzgor. Nerazpoložljivi ali nerazviti moduli so nadomeščeni z gonilniki.

Za boljše razumevanje si oglejmo spodnji primer:

Moduli Rank, Marks, Percentage in Sports Grade še niso razviti, zato bodo nadomeščeni s povezanimi gonilniki:

Pristop od spodaj navzgor

Pristop preizkušanja postopnega povečevanja od spodaj navzgor

Izvedeni bodo naslednji testni primeri:

Testni primer 1: Enotno preizkušanje modula Praktično in teorija
Testni primer2: Integracija in testiranje modulov Oznake-Praktična-teorija
Testni primer3 : Integracija in testiranje modulov Odstotek-Oznake-Praktična-teorija
Testni primer4: Enotno testiranje modula športne ocene
Testni primer5: Integracija in testiranje modulov Rank-Sports Grade-Percentage-Marks-Practical-Theory

Zasluge metodologije od spodaj navzgor

  • Ta metodologija je zelo uporabna za aplikacije, kjer se uporablja model zasnove od spodaj navzgor
  • Lažje je ustvariti preskusne pogoje s pristopom od spodaj navzgor
  • Začeti testiranje na spodnji ravni hierarhije pomeni preizkušanje kritičnih modulov ali funkcionalnosti v zgodnji fazi. To pomaga pri zgodnjem odkrivanju napak
  • Napake na vmesniku so odkrite v zgodnji fazi

Zasluge metodologije od spodaj navzgor

  • Gonilnike je težje pisati kot škrbine
  • Napake v zasnovi se zaznajo v kasnejši fazi
  • Pri tem pristopu nimamo delujoče aplikacije, dokler ni zgrajen zadnji modul
  • Gonilnik ni popolna izvedba povezanega modula. Samo simulira pretok podatkov med dvema moduloma.

# 3) Preskus sendviča

Ta pristop je hibrid metodologije od zgoraj navzdol in od spodaj navzgor. Stub in gonilniki se uporabljajo za nepopolne ali nerazvite module.

Pristop testiranja

  • Identificirana je srednja plast, na kateri se opravijo preskusi od spodaj navzgor in od zgoraj navzdol. Ta srednja plast je znana tudi kot ciljna plast
  • Ciljna plast je opredeljena v skladu s hevrističnim pristopom, tj. Izberite plast, ki omogoča minimalno uporabo Stubov in gonilnikov
  • Preskušanje od zgoraj navzdol se začne od srednjega sloja in se pomakne navzdol proti nižjim nivojem. Ta plast pod srednjo plastjo je znana kot spodnja plast
  • Testiranje od spodaj navzgor se začne tudi od srednjega sloja in se premakne navzgor proti modulom zgornjega sloja. Ta plast nad srednjo plastjo je znana kot zgornja plast
  • Z uporabo klinov in gonilnikov se preizkuša uporabniški vmesnik oziroma funkcije modulov nižje stopnje
  • Na koncu ostane le srednja plast za izvedbo končnega testa

Primer:

Primer testiranja sendviča

S strategijo testiranja sendvičev lahko izpeljemo naslednje primere:

Testni primer 1: Preskusite A, X, Y in Z posamično - kjer preizkus A spada pod preskus zgornje plasti, preskus X, Y in Z pa preskusi spodnjega sloja
Testni primer2: Preskus A, G, H in I
Testni primer3: Preizkusite G, X in Y
Testni primer4: Testna roka Z
Testni primer5: Preizkusite A, G, H, I, X, Y in Z

Zasluge metodologije preskušanja sendvičev

  • To je zelo koristno za velik projekt, ki ima različne podprojekte
  • Metodologija testiranja od zgoraj navzdol in od spodaj navzgor se lahko izvaja vzporedno

Zasluge metodologije preskušanja sendvičev

  • Pred poenotenjem modulov podsistemi in njihovi vmesniki niso temeljito preizkušeni
  • Višji stroški zaradi vključitve metodologije testiranja od zgoraj navzdol in od spodaj navzgor
  • Ta vrsta preskušanja ni priporočljiva za sistem, kjer so moduli zelo odvisni

Zaključek

Inkrementalno testiranje spada v okvir integracijskega testiranja. Pri tem pristopu testiranja se integracijsko testiranje opravi na posameznem modulu kot del enotnega testiranja, v naslednji fazi pa se moduli ali komponente aplikacije postopoma integrirajo in testiranje izvaja na kombiniranih modulih kot skupina.

Od treh metodologij testiranja inkrementalnega povezovanja je izbira, katero metodologijo izbrati, odvisna od strukture aplikacije in tudi od položaja modulov z visokim tveganjem.

Vse tri metodologije postopnega testiranja spadajo v kategorijo Horizontal zaradi naslednjih vedenjskih vidikov:

  • Vse tri metodologije se osredotočajo na testiranje slojev
  • Vsi upoštevajo strukturno ali hierarhično zasnovo
  • Vsi sloji postopoma integrirajo

Zasluge:

S tem pristopom testiranja je lažje zgodaj prepoznati napake, razvijalcu pa pomaga tudi pri ugotavljanju vzroka težave. Ker uporablja osnove strukturiranega testiranja, je ta pristop testiranja zelo učinkovit in natančen.

Pomanjkljivosti:

Ta vrsta preskusnega postopka je zamudna zaradi uporabe škrbine in gonilnikov. Prav tako se ponavlja.

O avtor: To koristno vadnico je napisala Neha B. Je pooblaščeni analitik kakovosti ISTQB z 8-letnimi izkušnjami.

Sporočite nam, če imate kakršna koli vprašanja / predloge.

Priporočeno branje

^