Mitä on moduulitestaus? Määritelmä, esimerkkejä

by: Thomas Hamilton Thomas Hamilton
Hours Päivitetty

⚡ Älykäs yhteenveto

Moduulitestaus tarkistaa yksittäisiä aliohjelmia, alirutiineja, luokkia ja proseduureja kootun ohjelman sijaan, joten viat tulevat esiin pienessä, hyvin ymmärrettävässä koodilohkossa, jossa ne ovat edullisia paikantaa ja korjata.

  • 🎯 Tavoite: Tavoitteena on paljastaa moduulin virheet, ei osoittaa, että moduuli toimii.
  • ⚪ Suuntautuminen: Tekniikka on pääosin white box -menetelmää, jota täydentävät spesifikaatiosta johdetut black box -tapaukset.
  • ⏩ yhdensuuntaisuus: Useita moduuleja voidaan testata samanaikaisesti, mikä lyhentää kokonaistestausaikaa.
  • 🔗 Kaksi tapaa: Moduulit yhdistetään joko inkrementaalisesti, askel askeleelta tai ei-inkrementaalisesti yhdellä kertaa.
  • 🧰 Rakennustelineet: Ajurit toimittavat testidataa moduulille, kun taas tynkät korvaavat kutsutut moduulit.
  • 🆚 Omistus: Testaajat kirjoittavat moduulitestit koodauksen jälkeen, kun taas kehittäjät kirjoittavat yksikkötestit koodauksen aikana.
  • ⚠️ haasteet: Ei-inkrementaalinen työ, väärinymmärretyt testituplaukset ja tiheä virheenkorjaus vievät suurimman osan työstä.
Lue lisää

Moduulitestaus selitettynä menetelmien, ajureiden, tynkien ja vertailujen avulla

Mitä on moduulitestaus?

Moduulien testaus on ohjelmistotestaustyyppi, joka tarkistaa ohjelman yksittäisiä aliohjelmia, alirutiineja, luokkia tai proseduureja. Koko ohjelmiston kerralla testaamisen sijaan moduulitestaus suosittelee ohjelman pienempien rakennuspalikoiden testaamista.

Moduulitestaus on pitkälti white box -painotteista. Moduulitestauksen tavoitteena ei ole osoittaa moduulin asianmukaista toimintaa, vaan osoittaa siinä olevan virheen olemassaolo. Tällä käänteisellä tavalla on merkitystä: ajo, joka ei löydä mitään, on vahvistanut hyvin vähän, kun taas ajo, joka paljastaa vian, on tehnyt tehtävänsä.

Moduulitason testaus mahdollistaa myös rinnakkaisuuden lisäämisen testausprosessiin, koska se luo mahdollisuuden testata useita moduuleja samanaikaisesti sen sijaan, että odotettaisiin koko koontia.

Miksi tehdä moduulitestaus

Moduulitestausta suositellaan, koska se muuttaa vikojen havaitsemisen taloudellisuutta.

  • Todennäköisyys virheiden tai vikojen tunnistamiseen ohjelman pienemmissä osissa kasvaa.
  • Useita moduuleja voidaan testata samanaikaisesti, ja siksi lähestymistapa tukee rinnakkaistestausta.
  • Testauksen monimutkaisuus on helposti hallittavissa, koska jokainen moduuli perustellaan erikseen.
  • Yhden moduulin sisältä löytyvä vika on tracpystyy käsittelemään pienen määrän koodia, joten virheenkorjausaika lyhenee jyrkästi.

Kuinka tehdä moduulitestaus?

Suunnittelu a testitapaus on moduulitestauksen tärkeä osa. Suunnitellessaan testitapauksia moduulitestiä varten testaajan on otettava huomioon kaksi asiaa.

  • Moduulin erittely
  • Moduulin lähdekoodi

Analysoi moduulin logiikkaa käyttämällä yhtä tai useampaa seuraavista valkoinen laatikko menetelmiä ja täydennä sitten näitä testitapauksia soveltamalla musta laatikko menetelmät moduulispesifikaatioon. Realistiset arvot ovat yhtä tärkeitä kuin valitut polut, joten valmistele testitiedot tapausten rinnalla eikä jälkikäteen.

Kun testitapaukset on suunniteltu, seuraava vaihe on moduulien yhdistäminen testausta varten. Käytetty menetelmä on joko inkrementaalinen tai ei-inkrementaalinen menetelmällä.

  • Ei-inkrementaalinen menetelmä — kaikki moduulit testataan erikseen. Ensin yhdistetään kaikki moduulit ja sitten testataan koko ohjelma.
  • Inkrementaalinen menetelmä — jokainen moduuli testataan ensin ja lisätään sitten vähitellen testattavaan kokoelmaan. Se suorittaa vaiheittaisen uudelleentestauksen.
  • Inkrementaalisessa testauksessa on kaksi lähestymistapaa, ylhäältä alas ja alhaalta ylöspäin testaus.
  • Moduulin suorittamiseksi valituilla tiedoilla tarvitaan ajuri testidatan syöttämiseen, suorituksen valvontaan ja tulosten tallentamiseen.

Näiden kahden menetelmän välinen valinta on kompromissi asennustyön ja diagnostiikan tehokkuuden välillä.

Aspect Inkrementaalinen menetelmä Ei-inkrementaalinen menetelmä
Yhdistelmä Yksi moduuli kerrallaan, lisätään testattuun kokoelmaan Kaikki moduulit yhdistetty ja sitten testattu yhdessä
Rakennustelineitä tarvitaan Lisää ajureita ja tynkiä, kirjoitettuna asteittain Vähemmän kaksoistestejä, koska läsnä on oikeita moduuleja
Virheen rajaaminen Vahva — vika osoittaa juuri lisättyyn moduuliin Heikko – vika voi syntyä mistä tahansa
Soveltuu parhaiten Suuret rakenteet, joissa on paljon vuorovaikutteisia moduuleja Pienet ohjelmat, joissa on vähän moduuleja ja vähän kytkentää

AIHEESEEN LIITTYVÄT ARTIKKELIT

Ajurit ja tynkät moduulitestauksessa

Yllä mainittu ajuri on parin toinen puolisko. Koska testattava moduuli sijaitsee harvoin puheluketjun ylä- tai alapäässä, testaajat korvaavat puuttuvan koodin kummallakin puolella.

  • kuljettaja — korvaa kutsuvan moduulin testattavan yläpuolella. Se toimittaa testidatan, käynnistää moduulin, valvoo suoritusta ja tallentaa tulokset. Alhaalta ylöspäin suuntautuva testaus on riippuvainen ajureista, koska alemmat moduulit ovat valmiita ennen ylempiä.
  • Tynkä — korvaa kutsutun moduulin testattavan moduulin alapuolella. Se hyväksyy kutsun ja palauttaa kiinteän, tunnetun vastauksen, jotta testattava moduuli voi suorittaa polkunsa loppuun. Ylhäältä alas -testaus perustuu tynkiin, koska ylempänä olevat moduulit ovat valmiita ensin.

Työstetty tapaus tekee parittelusta konkreettista. Jos maksulaskentamoduuli on valmis, mutta sitä kutsuva kassanäyttö ei ole, ajuri syöttää moduulille joukon tilaussummia ja kirjaa takaisin saadut summat. Jos moduulin kutsuma verohakupalvelu on myös kesken, tynkä palauttaa kiinteän veroprosentin, joten laskenta suoritetaan edelleen. Kumpaakaan rakennustelineiden osaa ei lähetetä; molemmat hylätään, kun varsinaiset moduulit saapuvat, minkä vuoksi testituplausten väärinkäsitys mainitaan myöhemmin toistuvana haasteena.

Esimerkkivinkkejä moduulitestaukseen

Tässä on muutamia vinkkejä, jotka kannattaa ottaa huomioon ennen moduulitestauksen suorittamista.

  • Revtutustu testitapauksiin ennen niiden käyttöä.
  • Vältä epäselvyyksiä ristiriitojen lähteestä.
  • Käytä automatisoituja testaustyökaluja.
  • Tarkastele muuttujia, joiden tulisi pysyä muuttumattomina.
  • Vaihda moduuleja testaajien välillä välttääksesi itsetestauksia.
  • Käytä testitapauksia uudelleen.

Viidennellä vinkillä on enemmän painoarvoa kuin sen pituus antaa ymmärtää. Kehittäjä, joka testaa vain juuri kirjoitettua moduulia, toistaa samoja oletuksia, jotka tuottivat vian, joten moduulien kierrättäminen käyttäjien välillä on yksi edullisimmista saatavilla olevista laadunparannuksista.

Yksikkötestaus vs moduulitestaus

Näitä kahta termiä käytetään monissa tiimeissä keskenään, mutta niiden laatija ja laajuus eroavat toisistaan.

Moduulien testaus Yksikkötestaus
Moduulitestit ovat kokoelma testejä, jotka testaaja on kirjoittanut sen jälkeen, kun kehittäjä on kirjoittanut jonkin koodin Yksikkötestejä ovat kokoelma testejä, jotka kehittäjä kirjoittaa ohjelmistokehitysprosessin aikana
Moduulitestaus voi sisältää yksikkötestien yhdistämistä Yksikkötestaus voi testata yksiköitä erikseen

Moduulitestaus vs. komponenttitestaus vs. integraatiotestaus

Moduulitestaus sijaitsee myös kahden vierekkäisen tason vieressä, jotka on helppo sekoittaa siihen. Taulukko erottaa ne sen mukaan, mitä testataan ja kuka sen normaalisti suorittaa.

Aspect Moduulien testaus Komponenttien testaus Integrointitestaus
Testattavana Yksi aliohjelma, luokka tai proseduuri Yksi itsenäinen komponentti välittömine riippuvuuksineen Yhdistettyjen moduulien väliset rajapinnat
Tavallinen omistaja Testaaja, koodin kirjoittamisen jälkeen testaaja Integraatiotestaaja
Rakennustelineet Ohjaimet ja tynkät Ulkoisten riippuvuuksien tynkät Asteittain vähemmän testituplauksia
Vika paljastunut Logiikkavirhe moduulin sisällä Komponentin toimintavirhe Rajapinta- ja tiedonsiirtovirhe

Arkikäytössä komponenttien testaus ja moduulitestausta käsitellään usein samana toimintana, kun taas integraatiotestaus alkaa vasta, kun yksittäiset moduulit ovat läpäisseet kukin omat kokeensa.

Haasteita moduulitestauksessa

Nämä ovat haasteita, joita tiimit kohtaavat useimmiten, kun moduulitestaus otetaan käyttöön.

  • Ei-inkrementaalinen testaus vaatii enemmän työtä — Kaiken yhdistäminen ensin tarkoittaa, että yksittäinen vika voi lähettää testaajat takaisin koko ohjelman läpi.
  • Väärinkäsitystesti kaksinkertaistuu — epärealistisen arvon palauttava tynkä tuottaa vihreän ajon, joka ei todista mitään.
  • Virheenkorjaustestit usein — scaffolding-koodissa on omat virheensä, ja ajurin korjaamiseen käytetty aika ei ole moduulin testaamiseen käytettyä aikaa.
  • Pitää ymmärtää koodi — Valkoisen laatikon suunta tarkoittaa, että testaaja, joka ei osaa lukea moduulia, ei voi suunnitella sille mielekkäitä tapauksia.

UKK

xUnit-perhe kattaa useimmat kielet, ja siinä on mallikirjastot, jotka tarjoavat tynkät, sekä kattavuustyökalu, joka näyttää, mihin polkuihin on päädytty. Valinta seuraa moduulin kieltä, ei testaustasoa.

Malli lukee moduulin lähdekoodin, luetteloi haarat ja ehdottaa jokaiselle tapausta, mukaan lukien raja-arvot, jotka manuaalinen läpikäynti usein ohittaa. Review on edelleen välttämätön, koska luodut tapaukset väittävät, mitä koodi tekee, eivätkä sitä, mitä spesifikaatio vaatii.

Kyllä, ja scaffolding on se alue, jossa tällaiset avustajat toimivat parhaiten, koska ajuri tai tynkä on toistuvaa koodia, jolla on tunnettu muoto. Palautetut arvot vaativat silti ihmisen päätöksen, koska uskottavan näköinen tynkä voi piilottaa etsittävän vian.

Riittää, että jokaista haaraa ja jokaista rajaa moduulissa on kokeiltu ainakin kerran. Pelkkä prosenttiosuustavoite on harhaanjohtava, koska korkea lausekattavuus voi silti jättää kokonaisia ​​päätöstuloksia kokeilematta.

Kun moduuli on käännetty ja ennen kuin sen rajapintoja on harjoiteltu yhdessä, se on ensimmäinen testaustaso, jota sovelletaan toimitettuun koodiin, minkä vuoksi tässä havaitut viat eivät koskaan saavuta integrointi- tai järjestelmävaiheita.

Noudata olemassa olevaa koodia. Ylhäältä alas sopii projekteihin, joissa ohjauslogiikka kirjoitetaan ensin ja alemmat moduulit jätetään pois; alhaalta ylös sopii projekteihin, joissa apuohjelmamoduulit kirjoitetaan ensin ja ajurit kutsuvat niitä.

Moduuli käännetään siististi, sen määrittely on saatavilla, sen riippuvuudet ovat joko läsnä tai tynkämuodossa ja testidata on valmis. Aloittaminen ilman määrittelyä muuttaa harjoituksen koodin kuvaukseksi.

Testaus ei voi koskaan todistaa, että moduulissa ei ole vikoja, ainoastaan ​​sen, että se on selvinnyt kokeilluista tapauksista. Moduulin rikkomiseen tähtäävien testiajojen suunnittelu palauttaa siksi enemmän tietoa kuin testiajojen suunnittelu, joiden odotetaan läpäisevän testit.

Tiivistä tämä viesti seuraavasti: