Mitä on komponenttien testaus? Tekniikat, esimerkkitestitapaukset

by: Thomas Hamilton Thomas Hamilton
Hours Päivitetty

⚡ Älykäs yhteenveto

Komponenttitestaus tarkistaa sovelluksen jokaisen osan erikseen integroimatta sitä muihin osiin, jotta viat löydetään ja korjataan yhden moduulin sisältä ennen kokoamisen aloittamista.

  • 🧩 Soveltamisala: Yksi komponentti kerrallaan, erillään sitä ympäröivistä komponenteista.
  • 👥 Omistaja: Testaajat ajavat sen kehittäjien suoritettua yksikkötestauksen.
  • 🔬 CTIS: Pienessä komponenttitestauksessa komponentti eristetään kokonaan.
  • 🔗 CTIL: Komponenttitestaus suurissa yksiköissä pitää riippuvuudet, olivatpa ne todellisia tai simuloituja.
  • 🧱 Doubles: Ajuri kutsuu komponenttia; se kutsuu tynkää.
  • ✅ Exit: Lokissa ei ole auki yhtäkään kriittistä, korkeaa tai keskitasoa olevaa vikaa.
Lue lisää

Komponenttitestaustekniikat ja esimerkkitestitapaukset

Mitä on komponenttien testaus?

Komponenttien testaus on ohjelmistotestaustyyppi, jossa testaus suoritetaan jokaiselle yksittäiselle komponentille erikseen integroimatta sitä muiden komponenttien kanssa. Arkkitehtuurin näkökulmasta sitä kutsutaan myös moduulitestaus, ja joissakin lähteissä sitä kutsutaan ohjelmatestaukseksi.

Mikä tahansa ohjelmisto kokonaisuutena koostuu useista komponenteista, ja komponenttitason testaus käsittelee näiden komponenttien testaamista erikseen. Se on yksi yleisimmistä musta ruutu testaus laadunvarmistustiimin suorittamat tyypit.

Nimeämisestä kannattaa tehdä huomautus etukäteen. ISTQB-sanasto käsittelee komponenttitestausta ja yksikkötestaus saman testitason synonyyminä. Monet toimitustiimit ja tämä artikkeli pitävät nämä kaksi käytännössä erillään: kehittäjät suorittavat yksikkötestejä omalle koodilleen ja testaajat suorittavat sitten komponenttitestejä toimitetulle koonnille. Tämän artikkelin lopussa oleva vertailutaulukko havainnollistaa tätä käytännön eroa.

Kuten alla oleva kaavio osoittaa, komponenttitestauksella on oma testausstrategiansa ja testaussuunnitelmansa, jossa jokaista ohjelmiston tai sovelluksen osaa tarkastellaan erikseen. Jokaiselle komponentille on testiskenaario on määritelty, joka sitten jaetaan korkean tason testitapauksiin ja lopulta matalan tason yksityiskohtaisiin testitapauksiin testitapaukset edellytysten kanssa.

Komponenttitestauksen hierarkia testausstrategiasta alas matalan tason testitapauksiin

Termin ”komponenttitestaus” käyttötapa vaihtelee toimialasta ja organisaatiosta toiseen. Yleisimmät syyt tähän käsityseroon ovat seuraavat kolme.

  1. Valitun kehityssyklimallin tyyppi
  2. Testattavan ohjelmiston tai sovelluksen monimutkaisuus
  3. Suoritetaanko testaus eristäen se sovelluksen muista komponenteista vai ilman eristystä

Ohjelmistotestauksen elinkaari tuottaa useita testiartefakteja eli testaustoimintojen aikana luotuja ja käytettyjä dokumentteja. Näihin kuuluvat testauspolitiikka ja testausstrategia, jotka määrittelevät käytettävät testaustyypit ja kuinka syvälle testaus menee tietyssä projektissa.

Kuka tekee komponenttien testauksen

Komponenttitestauksen suorittavat testaajat. Yksikkötestauksen suorittavat kehittäjät, jotka testaavat yksittäistä funktiota tai proseduuria. Kun yksikkötestaus on valmis, seuraa komponenttitestaus, josta testaajat ottavat vastuun.

Milloin komponenttitestaus suoritetaan

Komponenttitestaus suoritetaan pian sen jälkeen, kun kehittäjät ovat tehneet yksikkötestauksen ja koontiversio on julkaistu testaustiimille. Tätä koontiversiota kutsutaan UT-koontiversioksi eli yksikkötestauskoontiversioksi. Tässä vaiheessa testataan jokaisen komponentin päätoiminnallisuus.

Komponenttien testauksen osallistumiskriteerit

  • UT-kokoonpanoon sisällytettävien komponenttien vähimmäismäärä on kehitetty ja yksikkötestattu.

Komponenttien testauksen poistumiskriteerit

  • Jokaisen komponentin toiminnallisuus toimii määritellyllä tavalla.
  • Kriittisiä, korkean tai keskitason vakavuusasteen tai prioriteetin vikoja ei ole enää avoinna. vikaloki.

Komponenttien testaustekniikat

Testaustason syvyyden perusteella komponenttitestaus luokitellaan kahdella tavalla.

  1. CTIS — Component Testing in Small
  2. CTIL tarkoittaa komponenttien testausta suurissa

CTIS — Component Testing in Small

Komponenttitestaus voidaan suorittaa eristäen se testattavan sovelluksen muista komponenteista tai eristämättä sitä. Kun se suoritetaan muiden komponenttien ollessa eristettyinä, sitä kutsutaan suppeammin komponenttitestaukseksi.

Esimerkki 1: Verkkosivustolla, jolla on viisi eri verkkosivua, jokaisen verkkosivun testaaminen erikseen ja erillään muista komponenteista on pienimuotoisesti komponenttitestausta.

Esimerkki 2: Alla oleva guru99.com-sivuston kotisivu sisältää useita komponentteja, kuten Etusivu, Testaus, SAP, Verkko, Pakko oppia!, Big Data, Live-projektit ja Blogi.

Guru99 kotisivun navigointivalikkoa käsitellään erillisinä testattavina komponentteina

Mikä tahansa ohjelmisto koostuu monista komponenteista samalla tavalla, ja jokaisella komponentilla on omat alikomponenttinsa. Esimerkissä 2 lueteltujen moduulien testaaminen erikseen ottamatta huomioon sen integrointia muihin komponentteihin on pienimuotoista komponenttitestausta.

Testaus-pudotusvalikon avaaminen paljastaa Testaus-komponentin alikomponentit: Manuaalinen testaus, SOAPUI, QTP, JUnit, Selenium, Testien hallinta ja Mobiili testausAlla olevassa kuvakaappauksessa kyseiset alikomponentit on korostettu punaisella.

Testaus-pudotusvalikko, jonka alikomponentit on korostettu punaisella

AIHEESEEN LIITTYVÄT ARTIKKELIT

CTIL tarkoittaa komponenttien testausta suurissa

Komponenttitestausta, joka tehdään eristämättä sitä testattavan sovelluksen muista komponenteista, kutsutaan laajasti komponenttitestaukseksi.

Esimerkki selventää eroa. Oletetaan, että sovellus koostuu kolmesta komponentista: komponentista A, komponentista B ja komponentista C.

Kehittäjä on rakentanut komponentin B ja haluaa sen testattavan. Komponentin B täydellisen testaamisen edellytyksenä on, että osa sen toiminnallisuudesta riippuu komponentista A ja osa komponentista C, kuten alla oleva kaavio havainnollistaa.

Komponentti B testattiin ajurin korvaaessa komponentin A ja tynkän korvaaessa komponentin C

Toiminnallisuusvuoto on A → B → C, mikä tarkoittaa, että komponentti B on riippuvainen sekä A:sta että C:stä. Tässä vuossa tynkä on kutsuttu funktio ja ajuri on kutsuva funktio.

Komponentteja A ja C ei ole vielä kehitetty. Komponentin B täydelliseksi testaamiseksi A ja C korvataan tarvittaessa ajurilla ja tynkällä, joten kaksi puuttuvaa osaa toimivat valeobjekteina, kunnes oikeat osat ovat olemassa.

  • Tynkä: Testattava komponentti kutsuu tynkää. Komponentti C ei ole valmis, joten tynkä korvaa sen ja palauttaa B:n odottamat vastaukset.
  • kuljettaja: Ajuri kutsuu testattavaa komponenttia. Komponentti A ei ole valmis, joten ajuri korvaa sen ja kutsuu B:tä tarvittavilla syötteillä.

Esimerkki testitapauksista komponenttien testaamiseen

Alla olevat kaksi verkkosivua ovat toiminnallisesti yhteydessä toisiinsa, mikä tekee niistä hyödyllisen komponenttiparin testattavaksi.

Verkkosivu 1 on demopankkisivuston kirjautumissivu.

Kirjautumissivun komponentti, jossa on käyttäjätunnus- ja salasanakentät

Kun käyttäjä syöttää kelvollisen käyttäjätunnuksen ja salasanan ja napsauttaa lähetyspainiketta, sivu siirtyy seuraavaksi näkyvälle demopankin verkkosivuston kotisivulle.

Päällikön kotisivukomponentti navigointilinkeillä ja kuvilla

Tässä kirjautumissivu on yksi komponentti ja kotisivu toinen. Kunkin sivun toimivuuden testaaminen erikseen on komponenttitestausta.

Komponenttitestausskenaariot verkkosivulla 1:

  • Anna virheellinen käyttäjätunnus ja varmista, että loppukäyttäjälle näytetään käyttäjäystävällinen varoitus.
  • Anna virheellinen käyttäjätunnus ja salasana, napsauta Palauta ja varmista, että käyttäjätunnus- ja salasanakentät on tyhjennetty.
  • Anna kelvollinen käyttäjätunnus ja salasana ja napsauta Kirjaudu sisään -painiketta.

Komponenttitestausskenaariot verkkosivulla 2:

  • Varmista, että esimiessivun tervetuloviesti näkyy aloitussivulla.
  • Varmista, että kaikki verkkosivun vasemmalla puolella olevat linkit ovat klikattavia.
  • Varmista, että pääkäyttäjän tunnus näkyy etusivun keskellä.
  • Tarkista, että kotisivulla on kolme eri kuvaa kaavion mukaisesti.

Yksikkötestaus vs komponenttien testaus

Alla oleva taulukko havainnollistaa, miten nämä kaksi tasoa eroavat toisistaan ​​​​jokapäiväisessä käytännössä.

Yksikkötestaus Komponenttien testaus
Yksittäisten ohjelmien ja moduulien testaaminen sen osoittamiseksi, että ohjelma toimii spesifikaation mukaisesti. Kunkin ohjelmiston objektin tai osan testaaminen erikseen, eristäen tai eristämättä muista objekteista.
Validoitu suunnitteluasiakirjoja vasten. Validoitu testivaatimuksia ja käyttötapauksia vasten.
Kehittäjien tekemä. Testaajien tekemä.
Valmis ensin. Tehdään sen jälkeen, kun kehittäjien yksikkötestaus on valmis.
Viat korjataan yleensä paikan päällä eikä niistä kirjata virallista muistiinpanoa. Viat kirjataan muistiin ja trackäyty läpi vianhallinnan prosessin.

UKK

Riskien vähentäminen, komponentin toiminnallisen ja ei-toiminnallisen käyttäytymisen varmentaminen, luottamuksen rakentaminen sen laatuun, vikojen löytäminen ja niiden poistumisen estäminenping korkeammille testitasoille.

Mallit lukevat komponenttikonversiontracja ehdota virheellisiä syötteitä, reuna-arvoja ja virhepolkuja, jotka manuaalinen suoritus yleensä ohittaa. Testaaja vahvistaa silti jokaisen odotetun tuloksen ennen suoritusta.

Kyllä. Valmiita vastauksia palauttava tynkä ja kiinteitä syötteitä syöttävä ajuri ovat kaavamaista koodia, jonka assistentti kirjoittaa nopeasti. Realististen vastausten päättäminen on edelleen ihmisen tehtävä.

Komponenttitestaus tutkii yhtä komponenttia erikseen. integraatiotestaus tutkii komponenttien välisiä rajapintoja ja vuorovaikutuksia ja suoritetaan komponenttitestauksen jälkeen.

Code-tason viitekehykset, kuten JUnit, TestNG, NUnit ja pytest, sekä käyttöliittymäkomponenttien suorittajat, kuten Cypress Komponenttitestaus, Storybook ja Jest. Ne kaikki sopivat yhteen automaatio putki.

Tuplakomponenttien rakentaminen ja ylläpito. Varsinaisesta komponentista poispäin ajautuva tynkä piilottaa vikoja integrointiin asti, joten jokainen simuloitu vastaus on tarkasteltava uudelleen, kun varsinainen riippuvuus toimitetaan.

Se kääntää järjestyksen päinvastaiseksi. Testitapaukset kirjoitetaan ja automatisoidaan ennen komponentin olemassaoloa, ja sitten koodia lisätään, kunnes ne läpäisevät testin. Komponentti saapuu testisarja valmiiksi asennettuna.

Molemmat, riippuen siitä, kuka sen suorittaa. Testaajat työskentelevät mustalla laatikolla komponenttispesifikaatiota vastaan, kun taas kehittäjät, joilla on koodin käyttöoikeus, hakevat sitä. valkoinen laatikko peitto saman komponentin sisällä.

Tiivistä tämä viesti seuraavasti: