Mis on komponentide testimine? Tehnikad, katsejuhtumite näidised

Autor: Thomas Hamilton Thomas Hamilton
Hours Ajakohastatud

⚡ Nutikas kokkuvõte

Komponentide testimine kontrollib rakenduse iga üksikut osa eraldi, ilma seda ülejäänud osaga integreerimata, nii et defektid leitakse ja parandatakse ühe mooduli sees enne kokkupaneku alustamist.

  • 🧩 Reguleerimisala: Üks komponent korraga, isoleerituna ümbritsevatest komponentidest.
  • 👥 omanik: Testijad käivitavad selle pärast seda, kui arendajad on ühiktestimise lõpetanud.
  • 🔬 CTIS: Väikeste komponentide testimine isoleerib komponendi täielikult.
  • 🔗 CTIL: Komponentide testimine suurtes kogustes hoiab sõltuvused reaalsetena või simuleerituna.
  • 🧱 Doubles: Draiver kutsub komponenti; see kutsub välja tüve.
  • ✅ Välju: Logis ei ole ühtegi kriitilist, kõrget ega keskmist defekti lahtiselt.
Loe rohkem

Komponentide testimise tehnikad ja näidistestid

Mis on komponentide testimine?

Komponentide testimine on tarkvara testimise tüüp, mille puhul testitakse iga üksikut komponenti eraldi, ilma seda teiste komponentidega integreerimata. Arhitektuuri seisukohast nimetatakse seda ka moodulite testimineja mõned viited nimetavad seda programmi testimiseks.

Iga tarkvara tervikuna koosneb mitmest komponendist ja komponentide tasemel testimine tegeleb nende komponentide eraldi testimisega. See on üks sagedasemaid musta kasti testimine kvaliteedikontrolli meeskonna teostatavad tüübid.

Nimetamise kohta tasub varakult märkus teha. ISTQB sõnastik käsitleb komponentide testimist ja üksuse testimine sama testimistaseme sünonüümidena. Paljud tarkvaraarendusmeeskonnad ja ka see artikkel hoiavad praktikas neid kahte lahus: arendajad käivitavad oma koodil ühiktestid ja testijad seejärel käivitavad tarnitud versioonil komponenttestid. Selle artikli lõpus olev võrdlustabel toob selle praktilise erinevuse välja.

Nagu allolev diagramm näitab, on komponentide testimisel oma testimisstrateegia ja testimisplaan, milles tarkvara või rakenduse iga osa käsitletakse eraldi. Iga komponendi jaoks on testistsenaarium on määratletud, mis seejärel jaotatakse kõrgetasemelisteks testideks ja lõpuks madala taseme detailseteks testideks testjuhtumid eeltingimustega.

Komponentide testimise hierarhia testimisstrateegiast kuni madala taseme testide juhtumiteni

Mõiste „komponenttestimine” kasutusviis on valdkonnast ja organisatsioonist olenevalt erinev. Selle arusaamade erinevuse kõige levinumad põhjused on toodud allpool kolmes.

  1. Valitud arendustsükli mudeli tüüp
  2. Testitava tarkvara või rakenduse keerukus
  3. Kas testimine toimub rakenduse teistest komponentidest isoleeritult või ilma

Tarkvara testimise elutsükkel loob palju testiartefakte, st dokumente, mis luuakse ja kasutatakse testimistegevuste käigus. Nende hulgas on testimispoliitika ja testimisstrateegia, mis määravad, millist tüüpi testimist kasutatakse ja kui sügavale testimine antud projektis läheb.

Kes teeb komponentide testimist

Komponentide testimist teostavad testijad. Ühiktestimist teostavad arendajad, kes testivad üksikut funktsiooni või protseduuri. Kui ühiktestimine on lõppenud, järgneb komponentide testimine, mille eest vastutavad testijad.

Millal komponentide testimist teha

Komponentide testimine viiakse läbi varsti pärast seda, kui arendajad on ühiktestimise lõpetanud ja järgu testimismeeskonnale avaldanud. Seda järku nimetatakse UT-järguks ehk ühiktestimise järguks. Selles etapis testitakse iga komponendi peamist funktsionaalsust.

Komponentide testimise sisenemise kriteeriumid

  • UT-komplekti kuuluvate komponentide minimaalne komplekt on välja töötatud ja ühiktestitud.

Komponentide testimise väljumiskriteeriumid

  • Iga komponendi funktsionaalsus töötab vastavalt kirjeldusele.
  • Kriitilist, kõrge või keskmise raskusastmega või prioriteetset defekti pole jäänud lahendamata. defektide logi.

Komponentide testimise tehnikad

Testimistaseme sügavuse põhjal liigitatakse komponentide testimine kahte tüüpi.

  1. CTIS – komponentide testimine väikeses
  2. CTIL – komponentide testimine suurtes kogustes

CTIS – komponentide testimine väikeses

Komponentide testimist võib teha testitava rakenduse teistest komponentidest isoleeritult või isoleerimata. Kui seda tehakse teiste komponentidega isoleeritult, nimetatakse seda väiksemateks komponentide testimiseks.

Näide 1: Viie erineva veebilehega veebisaidil on iga veebilehe eraldi ja teistest komponentidest isoleeritult testimine lühidalt komponentide testimine.

Näide 2: Allpool näidatud guru99.com avalehel on palju komponente, näiteks Avaleht, Testimine, SAP, Veeb, Peab õppima!, Suurandmed, reaalajas projektid ja blogi.

Guru99 avalehe navigeerimismenüüd käsitletakse eraldi testitavate komponentidena

Iga tarkvara koosneb paljudest komponentidest ühtemoodi ja igal komponendil on oma alamkomponendid. Näites 2 loetletud iga mooduli eraldi testimine, arvestamata selle integratsiooni teiste komponentidega, on lühidalt komponentide testimine.

Testimise rippmenüü avamine kuvab testimise komponendi alamkomponendid: Käsitsi testimine, SOAPUI, QTP, JUnit, Selenium, Testihaldus ja Mobiilne testimineAlloleval hetktõmmisel on need alamkomponendid punasega esile tõstetud.

Testimise rippmenüü, mille alamkomponendid on punasega esile tõstetud

SEOTUD ARTIKLID

CTIL – komponentide testimine suurtes kogustes

Komponentide testimist, mis tehakse testitava rakenduse teistest komponentidest isoleerimata, nimetatakse laiemas mõttes komponentide testimiseks.

Näide teeb erinevuse selgemaks. Oletame, et rakendus koosneb kolmest komponendist: komponent A, komponent B ja komponent C.

Arendaja on loonud komponendi B ja soovib seda testida. Komponendi B täielikuks testimiseks sõltub osa selle funktsionaalsusest komponendist A ja osa komponendist C, nagu allolev diagramm illustreerib.

Komponent B testiti komponendi A asemel draiveriga ja komponendi C asemel modifitseeritud mooduliga.

Funktsionaalsusvoog on A → B → C, mis tähendab, et komponent B sõltub nii A-st kui ka C-st. Selles voos on tstub kutsutav funktsioon ja draiver on kutsuv funktsioon.

Komponente A ja C pole veel välja töötatud. Komponendi B täielikuks testimiseks asendatakse A ja C vastavalt vajadusele draiveri ja tüvega, seega toimivad kaks puuduvat osa näidisobjektidena kuni päris komponentide olemasoluni.

  • Tükk: Testitav komponent kutsub välja tüve. Komponent C pole valmis, seega asendab seda tüvi, mis tagastab B oodatavad vastused.
  • Juht: Draiver kutsub testitavat komponenti. Komponent A pole veel valmis, seega asendab draiver seda ja käivitab komponenti B vajalike sisenditega.

Näidiskatsejuhtumid komponentide testimiseks

Kaks allolevat veebilehte on funktsionaalsuse seisukohast omavahel seotud, mis teeb neist kasuliku komponentide paari testimiseks.

Veebileht 1 on demopanganduse saidi sisselogimisleht.

Sisselogimislehe komponent kasutajanime ja parooli väljadega

Kui kasutaja sisestab kehtiva kasutajatunnuse ja parooli ning klõpsab nuppu „Esita“, suunatakse leht järgmisena kuvatavale demopanga veebisaidi avalehele.

Halduri avalehe komponent navigeerimislinkide ja piltidega

Siin on sisselogimisleht üks komponent ja avaleht teine. Iga lehe funktsionaalsuse eraldi testimine on komponentide testimine.

Komponentide testimise stsenaariumid veebilehel 1:

  • Sisestage sobimatu kasutajatunnus ja veenduge, et lõppkasutajale kuvatakse kasutajasõbralik hoiatus.
  • Sisestage kehtetu kasutajatunnus ja parool, klõpsake nuppu Lähtesta ja veenduge, et kasutajatunnuse ja parooli väljad on tühjendatud.
  • Sisestage kehtiv kasutajanimi ja parool ning klõpsake nuppu Logi sisse.

Komponentide testimise stsenaariumid veebilehel 2:

  • Veenduge, et avalehel kuvatakse halduri lehe tervitussõnum.
  • Veenduge, et kõik veebilehe vasakul küljel olevad lingid oleksid klõpsatavad.
  • Veenduge, et halduri ID kuvatakse avalehe keskel.
  • Kontrollige avalehel kolme erineva pildi olemasolu vastavalt skeemile.

Ühiku testimine vs komponentide testimine

Allolev tabel võtab kokku, kuidas need kaks taset igapäevapraktikas erinevad.

Üksuse testimine Komponentide testimine
Üksikute programmide ja moodulite testimine, et näidata, kas programm töötab vastavalt spetsifikatsioonile. Iga objekti või tarkvaraosa eraldi testimine, teistest objektidest isoleeritult või isoleerimata.
Valideeritud projekteerimisdokumentide alusel. Valideeritud testimisnõuete ja kasutusjuhtude suhtes.
Arendajate tehtud. Testijate tehtud.
Esmalt tehtud. Tehtakse pärast seda, kui arendajate poolel on ühiktestimine lõppenud.
Defektid parandatakse tavaliselt kohapeal ja neid ametlikult ei registreerita. Defektid logitakse ja tracläbi defektide haldamise protsessi.

KKK

Riski vähendamine, komponendi funktsionaalse ja mittefunktsionaalse käitumise kontrollimine, usalduse loomine selle kvaliteedi suhtes, defektide leidmine ja nende defektide tekkimise ennetamineping kõrgematele testitasemetele.

Mudelid loevad komponendikontratracja pakuvad välja sobimatud sisendid, piirväärtused ja veateed, mida käsitsi sooritamine kipub mööda vaatama. Testija kinnitab enne käivitamist ikkagi iga oodatava tulemuse.

Jah. Etteantud vastuseid tagastav tüvi ja fikseeritud sisendeid edastav draiver on valemlik kood, mille assistent kiiresti kirjutab. Realistlike vastuste otsustamine jääb inimese teha.

Komponentide testimine uurib ühte komponenti eraldi. Komponent integratsiooni testimine uurib komponentide vahelisi liideseid ja interaktsioone ning käivitatakse pärast komponentide testimist.

Codetaseme raamistikud, näiteks JUnit, TestNG, NUnit ja pytest, lisaks kasutajaliidese komponentide käivitajad, näiteks Cypress Komponentide testimine, Storybook ja Jest. Kõik need sobivad ühte kategooriasse automaatika torujuhe.

Topeltkomponentide loomine ja hooldamine. Päriskomponendist eemalduv tüvi peidab defekte kuni integreerimiseni, seega tuleb iga simuleeritud vastust pärast päris komponendi saabumist uuesti läbi vaadata.

See pöörab järjekorra vastupidiseks. Juhtumid kirjutatakse ja automatiseeritakse enne komponendi olemasolu, seejärel lisatakse koodi, kuni need läbivad. Komponent saabub juba olemasoleva testimiskomplektiga.

Mõlemad, olenevalt sellest, kes seda haldab. Testijad töötavad musta kasti abil komponendi spetsifikatsiooni vastu, samas kui koodile juurdepääsuga arendajad rakendavad valge kast katvus sama komponendi sees.

Võta see postitus kokku järgmiselt: