Mis on integratsiooni testimine

Infotehnoloogia valdkonna edusammudega muutuvad asjad palju lihtsamaks nii meile, inimestele kui ka sõna otseses mõttes, kõike saab teha vaid ühe sõrmega. Kuid enne seda saab kõik ära teha palju rasket tööd ja kõige tähtsam „LOGIKA“ pannakse selle taha. Nüüd, mõnikord, oleme näinud, et mõned funktsioonid ei tööta täpselt ootuste kohaselt või tarkvarast saadud tulemused ei vasta meie ootustele, just seal mängib tarkvara testimine olulist rolli. Süsteemide tõrgete kõrvaldamiseks õigete / eeldatavate tulemuste saamiseks on tarkvara testimine.

Integreerimistestide mõistmiseks peame kõigepealt mõistma, mida tarkvara testimine tähendab! Tarkvara testimine on tegevus, mille eesmärk on kontrollida, kas testi väljund / tulemus on samaväärne eeldatava väljundiga / tulemusega, mis tähendab, et tarkvara töötab õigesti. Pärast teatud tarkvara / süsteemi käivitamist saadud tulemus peab ühtima tulemusega, mida eeldatakse tarkvara / süsteemi väljundina; kui see ei õnnestu, tuleb tarkvara ümber kirjutada või teha mõned muudatused koodi sees.

Tarkvara süsteemi tarkvara testimine toimub erinevatel tasanditel. Testimistasemeid on kujutatud järgmiselt:

Kronoloogiliselt tehakse integreerimistestid pärast esimest sammu, “Unit Testing”. Kuna nime integreerimine läheb, on integratsiooni testimise tekstiline määratlus “Individuaalseid tarkvara mooduleid ühendatakse ja testitakse koos, nagu gruppi”. See tähendab, et tarkvaras on palju komponente. Need paljud komponendid koos moodustavad koos tarkvara süsteemi. Seda tarkvarasüsteemi testitakse koos ja testimistaset, millel seda testitakse, nimetatakse integratsioonitestideks. Nii et kui neid mooduleid ühendada, peab sellest saadav tulemus olema võrdne eeldatava tulemusega - just seal on osa integratsioonitestidest. Integreerimistestide peamine eesmärk on kontrollida, kas üksikud moodulid töötavad koos õigesti.

Tuntud ka kui I & T (integreerimine ja testimine), võib aidata nii inimese testimisel kui ka mooduli täielikul testimisel. See on kaasatud nii musta kasti kui ka valge kasti testimisse. Enamik organisatsioone testib oma tarkvara ainult üksuse testimise ja funktsionaalse testimise metoodika abil.

Tüübid ja lähenemisviisid

Integreerimise testimist on neli tüüpi ja lähenemisviise, mida mainitakse allpool:

  1. Suure paugu lähenemine
  2. Alt üles lähenemine
  3. Ülalt-alla lähenemine
  4. Hübriid / võileib

1. Suure paugu lähenemisviis:

Tarkvara süsteemide väljatöötatud moodulid / komponendid on ühendatud. Neid üksikuid mooduleid katsetatakse ühendamisel koos. Pärast ühiku testimist testitakse neid mooduleid koos, moodustades tarkvarasüsteemi. Kuid mõnel meist võib tekkida see küsimus, et kuidas erinevad tarkvarasüsteemi testimine tervikuna ja integratsiooni testimine? Peamine, millest me siin aru saame, on see, et integratsioonitestides testitakse üksikuid mooduleid pärast ühiskatsete tegemist; ning tarkvarasüsteemi testimisel testitakse kogu süsteemi kõigi arvestatud parameetritega.

Järgmine diagramm kirjeldab täpselt, mida tähendab integratsiooni testimise Suure Paugu lähenemine:

Suure paugu lähenemisviisiga on seotud mõned eelised ja puudused:

Eelised:

  • Väga mugav on läheneda, kui süsteemid on väikesed. Kuna selle lähenemisviisi jaoks kulub rohkem aega, võivad suured süsteemid viia suurema ajakulu kasutamiseni.
  • Vigade tuvastamine on selle abil väga lihtne, arvestades väikeseid süsteeme

Puudused:

  • Kuna kõik moodulid on ühendatud, on süsteemides mingi tõrge, siis on seda raske märgata.
  • Mõned moodulid on väga olulised ja neid tuleb testida. Neid süsteeme tuleb enne süsteemis kasutamist testida. Kuid integratsiooni testimise ajal ei pruugi neid mooduleid tõhusalt testida, kuna kõik moodulid on omavahel ühendatud.
  • Kogu tarkvarasüsteemi jaoks kuluv aeg on palju rohkem kui teiste integratsiooni testimise lähenemisviiside jaoks.
  • Moodulite ühendamine võib võtta natuke aega, mille tulemuseks võib olla tarkvarasüsteemi kogu protsessiaja kulumine.
  • Selle lähenemisviisi jaoks kulub rohkem aega, kuna paljud moodulid on ühendatud ja iga mooduli katsetamine võtab rohkem aega.

2. Alt-üles lähenemine

Selle lähenemisviisi korral testitakse kõigepealt madala taseme mooduleid koos ja eraldi. Kõik alumise taseme moodulid on integreeritud, mis sisaldab funktsioone ja protseduure ning kõik on ühendatud ja testitud. See aitab kõrgema taseme moodulite testimisel, kuna see loob sellele aluse. Seda protseduuri korratakse põhjalikult kõigile moodulitele alates alumisest tasemest kuni kõrgema taseme mooduliteni. Lihtsamalt öeldes algab testimine sisemistest ja kõige madalamatest moodulitest ning järk-järgult ülespoole. Nagu skeemil öeldud, võetakse seda tehes juhil abi. Mis on draiver ja kuidas see aitab? Nagu vool näitab, ei saa kõrgema taseme mooduleid süsteemi integreerida enne ja kui ainult madala taseme moodulite testimine on läbi viidud ja ühendatud. Seega aitab juht siin ühendada madalama ja kõrgema taseme mooduleid ning töötab keskmise või tehnilises mõttes kõnefunktsioonina.

Eelised:

  • Üksikute moodulite arendamist saab teha alt-üles lähenemise integreerimise testimise ajal, kuna ühendamise ja integreerimise testimine toimub pärast kõige madalama taseme moodulite testimist.
  • Mingi tõrke olemasolul / ilmnemisel saab selle parandada samal ajal ja samal tasemel. Vea tuvastamine ja parandamine on palju lihtsam kui muude lähenemisviiside puhul.
  • Võrreldes teiste lähenemisviisidega on vea tuvastamiseks ja vea parandamiseks vaja palju vähem aega.
  • Vigu saab lahendada samal astme alumisel või ülemisel tasemel.

Puudused:

  • Kogu protsessi jaoks kulub rohkem aega, testimisprotsess ei lõpe enne, kui kõik moodulid, nii ülemine kui ka alumine, on kaasatud ja testitud.
  • Draiverid on vajalikud, et helistada kõrgetasemelistele moodulitele
  • Kui tarkvarasüsteem sisaldab üha enam väikeseid, kuid keerukaid mooduleid, võib tarkvara testimise lõpuleviimine võtta rohkem aega.

3. Ülalt-alla lähenemine

See lähenemisviis on alt üles suunatud lähenemisviisiga täpselt vastupidine. Kõigepealt testitakse kõrgema taseme mooduleid ja seejärel samaaegselt ka teisi madalama taseme mooduleid. Kõige kõrgemaid mooduleid testitakse esmalt individuaalselt, nagu näiteks kõrgeima mooduli jaoks tehakse spetsiaalseid üksuseteste ning lõpuks võetakse arvesse ja testitakse teisi mooduleid. Ülalt-alla lähenemine nõuab helistamisfunktsiooni, nagu ka alt üles suunatud lähenemine, mida nimetatakse Stubs. Tüved on lühikoodiloogika väljavõtted, mida kasutatakse sisendite vastuvõtmiseks kõrgema taseme moodulitest ja lõpuks kutsutakse madalama taseme moodulid integreerimiseks ja testimiseks.

Eelised:

  • Selle lähenemisviisi abil saab hõlpsalt tuvastada rikkeid või vigu.
  • Üliolulisi mooduleid testitakse põhjalikult ja enne teisi mooduleid.
  • Tarkvara süsteemiintegratsiooni testimist saab teha vähem aega, kui võrrelda teiste lähenemisviisidega.

Puudused:

  • Põhjatasapinnalisi mooduleid ei pruugita testida oodatud tasemeni või neid ei tohi katsetada vastavalt nõuetele.
  • Tükke on vaja ja neid on vaja testimisprotsessi edasiseks kulgemiseks.

4. Hübriidne / võileiva lähenemine

Tuntud ka kui segaintegratsiooni testimine. Nii lähenemisviis alt-üles kui ka ülalt-alla on lähenemine. Seega tuntud kui hübriid- või võileiva- või segaintegratsiooni testimismeetod. Seda lähenemisviisi kasutatakse nii individuaalselt lähenemiste katmiseks. Ülaosast moodulit testitakse ühikutes ning samal ajal integreeritakse ja testitakse madalama taseme mooduleid ka kõrgeima taseme moodulitega.

Eelised:

  • Enamasti kasutatakse suurtes projektides ja mille valmimine nõuab palju aega.

Puudused:

  • Seda tüüpi testimise kulud on üsna suured, kuna testimise lõpuleviimisel kasutatakse mõlemat lähenemisviisi.

Integratsiooni testimise eelised

  1. Erinevate moodulite integreerimise testimine samal ajal on lihtne.
  2. Saab kasutada nii katsetamise alguses kui ka hilisemas etapis.
  3. Koodi pikkuse katvus on võrreldes muude tarkvara testimise tehnikatega rohkem, kuna kasutada saab nii alt üles kui ka ülalt alla lähenemist.
  4. Nõuete muudatuste kohaselt on areng erinev, mistõttu muutub oluliseks moodulite testimine erinevatel tasanditel, mille jaoks saab integratsioonitesti hõlpsalt kasutada.

Miks kasutatakse integratsiooni testimist?

  • Inimesed, kes on asunud IT-tööstusesse, teavad pidevalt toimuvatest muutustest. Iga päev muutub vastavalt vajadusele teatud tarkvarasüsteemi arendamise vajadus, seetõttu töötatakse iga päev välja uusi koodipaiku. Nüüd, kui need plaastrid on ühendatud, moodustades ühe tarkvara. Niisiis, selle kontrollimiseks on vaja integratsioonitesti ja selle lähenemisviise.
  • Kui keeruline või tohutu tarkvara kodeeritakse või ehitatakse, liigitatakse see eraldi mooduliteks. Paljud inimesed töötavad nende moodulitega samal ajal, kuid kui need moodulid on integreeritud, tehakse testimine. Enamikul juhtudel nõuab moodulite integreerimine enne edasist töötlemist selle integreerimise testimist.
  • Enamik tarkvararakendusi nõuab, mõned toetavad raamatukogusid. Integratsiooni testimine toimub siis, kui neid teeke kasutatakse koos väljatöötatud koodiga.
  • Integreerimine muutub tarkvara väljatöötamisel kohustuslikuks, kuna vead võidakse ettenähtud tasemel parandada. Nüüd, kui me teame lähenemisviisidest, võib selle jaoks kasutada ühte lähenemisviisi.

Integratsiooni testimise juhtumid

Mõelge sellele, et ehitame ühe töötaja haldustarkvara. Sellel tarkvaral on kolm peamist aspekti:

  1. Töötaja sisselogimine
  2. Töötaja aruanne
  3. Töötaja palga määramise leht ja palgatase

Arvestades ülaltoodud juhtumit, töötatakse kõigepealt välja tarkvara ja voog peaks olema Töötajate registreerimine (Väärtuste sisestamine, nt töötaja ID, nimi, telefoninumber jne). Pärast õigeid sisestusi peaks see ümber suunama selle töötaja aruande lehe netilehele. Kui siin ei suunata töötajat aruannete lehele ega suunata otse palgateabe lehele, siis on see viga. Niisiis, selle parandamiseks tehakse voog, tegevuste jada, integreerimise testimine.

Teine näide integratsioonitestidest oleks:

Kontrollime iga päev oma e-kirju. Kõik e-posti teenuse pakkujad pakuvad meile samu funktsioone.

Login-> Inbox->Send / Delete Mail-> Logout

Nüüd, kui logime sisse nende serveritesse, kontrollitakse kõigepealt väärtuste õigsust, st ühiku testimist. Niisiis, nüüd pärast mandaadi vasteid peaks sisselogimisleht meid üle viima postkasti lehele. See on oodatud tulemus. Kui see ei vii meid sisendkausta lehele, selle asemel, et meid mingisse rämpskausta viia, siis saab sellest integratsiooni testimise juhtum. Sama kehtib ka meilide saatmise ja kustutamise kohta.

Muud juhtumid võivad olla:

  • Pärast edukat registreerimist mis tahes veebis / võrguühenduseta rakenduses peaks kasutaja ette ilmuma kuvasõnum.
  • Pangarakendused peaksid suunama kasutajad vajalikule konto kokkuvõtte lehele.
  • Pärast edukat sisselogimist sotsiaalmeediarakendustesse peaks ilmuma vaikeleht, nt: Avaleht / Facebooki profiil.

Järeldus

Nii palju edusamme IT valdkonnas, iga päev kui ka nii palju arendajaid, kes istuvad erinevates kohtades ja töötavad sama tarkvara kallal, on integratsiooni testimine muutunud kohustuslikuks. Selle lähenemisviiside abil saab integratsioonitesti kasutada nii väikeste kui ka suurte tarkvararakendustega. Integreerimistestid, mis asuvad tarkvara testimise keskel ja millel on nii palju eeliseid, muutuvad kommertstasemel klientidele üha olulisemaks ja regulaarne kontroll aitab tarkvara puutumatuna hoida.

Soovitatavad artiklid

See on olnud integratsiooni testimise juhend. Siin arutasime mõningaid põhimõisteid, määratlust, tüüpe ja lähenemisviisi koos eeliste ja puudustega. Lisateavet leiate ka meie muudest soovitatud artiklitest -

  1. Karjäär tarkvara testimisel
  2. Tarkvaraarendajate karjäär
  3. Mis on musta kasti testimine
  4. Kasulik karjäär tarkvarainsenerina

Kategooria:

Tarkvaraarendus