fbpx

Inkrementaalinen testaus on ohjelmistotestauksessa menetelmƤ, jonka avulla tiimit voivat pilkkoa yksittƤisiƤ moduuleja, testata niitƤ erikseen ja integroida ne vaiheittain. Se auttaa lƶytƤmƤƤn virheet varhaisessa vaiheessa, vƤhentƤƤ monimutkaisuutta ja lisƤƤ testien kattavuutta.

TƤssƤ artikkelissa sukelletaan syvƤlle inkrementaaliseen testaukseen, selitetƤƤn, mitƤ se on, ja tutkitaan erilaisia tyyppejƤ, prosesseja, lƤhestymistapoja, tyƶkaluja ja muita tƤhƤn hyƶdylliseen menetelmƤƤn liittyviƤ asioita.

 

MitƤ on inkrementaalinen testaus?

MitƤ inkrementaalinen testaus on ohjelmistotestauksessa?

Testaus on yksi ohjelmistokehityksen elinkaaren (SDLC) tƤrkeimmistƤ vaiheista. Aivan kuten SDLC:ssƤ, myƶs testauksessa testaus on jaettu eri loogisiin vaiheisiin. Inkrementaalinen testaus on yksi nƤistƤ vaiheista, ja se tapahtuu tyypillisesti seuraavien vaiheiden aikana.
integraatiotestaus
ja heti sen jƤlkeen
yksikkƶtestauksen jƤlkeen
.

Inkrementaalinen testaus on kƤytƤnnƶllinen ohjelmistotestauksen lƤhestymistapa, jossa suuret tai monimutkaiset ohjelmat pilkotaan hallittaviin, pieniin palasiin. Sen sijaan, ettƤ koko ohjelmistojƤrjestelmƤ integroitaisiin ja testattaisiin kerralla, inkrementaalisessa testauksessa tarkastellaan moduuleja ja toteutetaan vaiheittainen verifiointiprosessi.

Ohjelmistomoduulit ovat yleensƤ itsenƤisiƤ koodin yksikƶitƤ, jotka suorittavat tiettyjƤ tehtƤviƤ tai toimintoja. NƤiden moduulien rakeisuus riippuu monista tekijƶistƤ, kuten koodauskƤytƤnnƶistƤ, kehitysmenetelmistƤ tai jopa kƤyttƤmƤstƤsi ohjelmointikielestƤ.

Yksikkƶtestauksessa moduulit testataan itsenƤisesti. Integrointitestauksen aikana kukin moduuli integroidaan sitten pala palalta – tai vaiheittain. TƤllƤ prosessilla varmistetaan, ettƤ jokainen moduuli toimii hyvin yhdessƤ. Kunkin moduulin tƤydellistƤ todentamista varten testaajien on kuitenkin simuloitava komponentteja, joita ei ole vielƤ toteutettu, tai ulkoisia jƤrjestelmiƤ. TƤtƤ varten he tarvitsevat apuna kantoja ja ajureita.

 

MitƤ stubs ja driverit ovat inkrementaalisessa testauksessa?

Stubit ja ajurit ovat kriittisiƤ ohjelmistotestausvƤlineitƤ. NƤitƤ tilapƤisiƤ koodinpƤtkiƤ kƤytetƤƤn integrointitestauksessa, koska ne tarjoavat tiimeille mahdollisuuden jƤljitellƤ eri moduulien tai komponenttien kƤyttƤytymistƤ ja rajapintoja.

1. Kannat:

Stubit jƤljittelevƤt moduuleja, joita ei ole vielƤ kehitetty ja joita ei siten voida testata. Niiden avulla testattava moduuli (MUT) voi kƤyttƤƤ epƤtƤydellisiƤ moduuleja. TƤstƤ seuraa, ettƤ MUT voidaan testata erillisenƤ, vaikka siihen liittyviƤ moduuleja ei olisikaan saatavilla.

2. Kuljettajat:

Ajurit puolestaan simuloivat MUT:ia kutsuvien moduulien kƤyttƤytymistƤ. TestausympƤristƶssƤ nƤmƤ ohjaimet voivat lƤhettƤƤ MUT-testitietoja. TƤmƤkin helpottaa moduulien testaamista erillƤƤn ilman ulkoisia riippuvuuksia.

Stubien tai ajureiden kƤyttƶ vƤhentƤƤ kehitysaikaa, parantaa koodin laatua ja lisƤƤ tiimin tuottavuutta. Se, mitƤ niistƤ kƤytetƤƤn, riippuu kuitenkin siitƤ, mikƤ testausmenetelmƤ on sopivin. Tarkennamme tƤtƤ jƤljempƤnƤ olevassa osiossa, jossa kƤsitellƤƤn eri tyyppisiƤ inkrementaalisia integrointitestejƤ.

 

Erilaiset inkrementaaliset

integraatiotestaus

Erilaiset inkrementaalisen integrointitestauksen tyypit

Inkrementaaliset testaustyypit voidaan jakaa karkeasti kolmeen luokkaan. Tutustutaanpa kuhunkin niistƤ.

 

1. YlhƤƤltƤ alaspƤin tapahtuva asteittainen integrointi

 

YlhƤƤltƤ alaspƤin tapahtuva inkrementaalinen integrointi aloitetaan testaamalla jƤrjestelmƤn korkeimman tason moduuleja. TƤmƤn jƤlkeen se integroi ja testaa asteittain alemman asteen moduuleja.YlhƤƤltƤ alaspƤin suuntautuvassa inkrementaalisessa integroinnissa on kaksi pƤƤasiallista skenaariota. Ne ovat:

  • Kun jƤrjestelmƤ on hyvin suuri tai erittƤin monimutkainen
  • Kun kehitystiimi tyƶskentelee useiden moduulien parissa samanaikaisesti.

YlhƤƤltƤ alaspƤin etenevien asteittaisten integraatioiden vaiheet

  • Kriittisten moduulien tunnistaminen
  • Luo tynkiƤ jƤljittelemƤƤn alemman asteen moduuleja.
  • KehitetƤƤn ajureita, jotka ovat vuorovaikutuksessa ylemmƤn tason moduulien kanssa, jotta niille voidaan lƤhettƤƤ tietoja ja tulkita moduulien tuotoksia.
  • Kriittisten moduulien yksikkƶtestaaminen ajureiden ja stubien avulla
  • Integroidaan alemman asteen moduuleja ja korvataan vƤhitellen tynkƤtoteutukset todellisilla toteutuksilla.
  • Muokkaa ajurit uusien moduulien mukaisiksi.
  • Toista, kunnes kaikki alemman asteen moduulit on integroitu ja testattu.

 

2. Alhaalta ylƶspƤin tapahtuva asteittainen integrointi

 

Alhaalta ylƶspƤin suuntautuvat inkrementaaliset integraatiot kulkevat pƤinvastaiseen suuntaan. TƤssƤ lƤhestymistavassa testataan jƤrjestelmƤn alemman asteen (tai vƤhiten kriittiset) moduulit ja lisƤtƤƤn asteittain ylemmƤn asteen moduuleja. TƤmƤ lƤhestymistapa soveltuu erilaisiin tilanteisiin, kuten:

  • Kun olet tekemisissƤ pienempien jƤrjestelmien kanssa
  • Kun jƤrjestelmƤ on modulaarinen
  • Kun olet huolissasi tyngƤn tarkkuudesta tai tƤydellisyydestƤ.

Alhaalta ylƶspƤin suuntautuvan asteittaisen integroinnin vaiheet

  • Alemman asteen moduulien tunnistaminen
  • Alemman asteen moduulien yksikkƶtestaus niiden yksittƤisten toimintojen tarkistamiseksi.
  • KehitetƤƤn ohjaimia, jotka toimivat vƤlittƤjinƤ alemman tason moduulien kanssa.
  • Luo tynkiƤ simuloidaksesi korkeamman asteen moduulien kƤyttƤytymistƤ.
  • Integroi seuraavat moduulit alemmasta korkeampaan jƤrjestykseen ja korvaa vƤhitellen tynkƤtoteutukset todellisilla toteutuksilla.
  • Muokkaa ajurit uusien moduulien mukaisiksi.
  • Toista, kunnes kaikki korkeamman asteen moduulit on integroitu ja testattu.

 

3. Toiminnallinen asteittainen integrointi

 

Toiminnon inkrementaalinen integrointitestaus on seuraava yleinen inkrementaalisen testauksen tyyppi ohjelmistotestauksessa. Kun kahdessa edellisessƤ lajissa keskityttiin ylemmƤn ja alemman tason moduuleihin, toiminnallinen inkrementaalinen testaus perustuu tietyn moduulin toiminnallisuuteen.

Toiminnallista inkrementaalista integrointia kƤytetƤƤn
KetterissƤ/DevOps-menetelmissƤ
, ja se on erinomainen valinta sovelluksille, joissa on monimutkaisia riippuvuuksia moduulien tai komponenttien vƤlillƤ.

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

Toiminnallisen vaiheittaisen integroinnin vaiheet

  • YksittƤisten moduulien ja komponenttien tunnistaminen, joilla on hyvin mƤƤritellyt rajapinnat.
  • Varmista kunkin moduulin toimivuus yksikkƶtestauksen avulla.
  • Integroi jƤrjestelmƤn minimaaliset ydinmoduulit ja varmista, ettƤ se toimii.
  • LisƤƤ vƤhitellen yksittƤisiƤ moduuleja ja testaa toiminnallisuutta jokaisessa vaiheessa.
  • Muokkaa koodia sitƤ mukaa, kun kukin moduuli lisƤtƤƤn.
  • Kun kaikki moduulit on lisƤtty, testaa toimivuus ja suorituskyky.

 

Inkrementaalisen testauksen hyvƤt ja huonot puolet

haasteet kuormitustestaus ja RPA

Nyt sinulla pitƤisi olla jo jonkinlainen kƤsitys siitƤ, miksi inkrementaalinen testaus on suosittu lƤhestymistapa. Kuten kaikilla ohjelmistotestausmenetelmillƤ, myƶs sillƤ on kuitenkin etunsa ja haittansa. Tutkitaanpa joitakin nƤistƤ eduista ja haitoista.

 

Inkrementaalisen testauksen edut

 

1. Joustavuus

Kuten kaikki ohjelmistokehittƤjƤt ja -testaajat tietƤvƤt liiankin hyvin, vaatimukset voivat muuttua ja kehittyƤ SDLC:n aikana, joskus hyvinkin dramaattisesti. Inkrementaalinen testaus on riittƤvƤn dynaamista, jotta tiimit voivat mukautua testausprosessin aikana ja sisƤllyttƤƤ siihen uusia suunnitelmia ja suuntia.

 

2. Varhainen vikojen havaitseminen

Paras aika havaita virhe tai vika on mahdollisimman varhaisessa vaiheessa. Kun kehittƤjƤt tarkistavat yksitellen palasiksi koottuja moduuleja, ongelmien tunnistaminen ja korjaaminen on paljon helpompaa. LisƤksi se auttaa vƤhentƤmƤƤn suurten ongelmien esiintymisen todennƤkƶisyyttƤ kehityksen loppuvaiheessa.

 

3. Yksinkertaisuus

Ohjelmistotestaus voi olla erittƤin monimutkainen prosessi. Yksi inkrementaalisen testauksen kiehtovimmista puolista on se, miten se pilkkoo testauksen kaupungin toimiviin osiin. Sen sijaan, ettƤ testaajat joutuisivat kƤsittelemƤƤn ylivoimaisen monimutkaisuutta, he voivat keskittyƤ tiettyihin moduuleihin ja jopa priorisoida niitƤ. TƤmƤ etu on jumalan lahja suurille ja monimutkaisille sovelluksille.

 

4. Pienempi regressioriski

Regressio on aikaa vievƤ ja monimutkainen asia ohjelmistokehityksessƤ. Inkrementaalisella testauksella voidaan vƤhentƤƤ taantumasta aiheutuvia riskejƤ, koska sen avulla tiimit voivat testata moduuleja yksitellen ja puuttua ongelmiin sitƤ mukaa, kun niitƤ ilmenee. Kun kƤytetƤƤn kiinteƤn
regressiotestaus
, tiimit voivat sƤƤstƤƤ paljon aikaa ja tuskaa.

 

5. Palautteenantomahdollisuudet

Inkrementaalisen testauksen usein unohdettu etu on se, ettƤ se antaa tiimeille liikkumavaraa prototyyppien ja MVP:iden laatimiseen. SidosryhmƤt ja sijoittajat voivat arvioida prosessin perustoiminnallisuutta ja antaa arvokasta palautetta. TƤmƤ tilanne voi sƤƤstƤƤ paljon aikaa ja rahaa ja johtaa vankempiin tuotteisiin.

 

Inkrementaalisen testauksen haitat

 

1. Integrointikysymykset

Moduulien testaaminen erikseen on suotavaa, koska se pilkkoo monimutkaisen sovelluksen hallittaviin osiin. NƤiden moduulien integrointi voi kuitenkin aiheuttaa uusia ja odottamattomia virheitƤ. NƤin ollen inkrementaalinen testaustapa on suunniteltava huolellisesti ja harkitusti.

 

2. Testisarjan monimutkaisuus

Kun jokaiselle moduulille on useita testitapauksia ja niiden vuorovaikutus toistensa kanssa, testisarjojen seuranta ja hallinta voi olla monimutkaista. Suurissa ja monimutkaisissa sovelluksissa perusteellinen dokumentointi tai testienhallintatyƶkalut ovat vƤlttƤmƤttƶmiƤ.

 

3. LisƤƤ tyƶtƤ

Monoliittinen testaus on monimutkaisempaa, mutta vaatii vƤhemmƤn testausta. Koska inkrementaalinen testaus testaa monia moduuleja erikseen, se vaatii enemmƤn tyƶtƤ. Inkrementaalisen testauksen edut, kuten virheiden varhainen lƶytƤminen, merkitsevƤt kuitenkin sitƤ, ettƤ ylimƤƤrƤinen tyƶ on aikaa sƤƤstƤvƤ investointi. Totta kai,
ohjelmistotestauksen automatisointi
voi auttaa vƤhentƤmƤƤn nƤitƤ ponnistuksia.

 

4. LisƤƤntyneet johtamisvaatimukset

Inkrementaalinen testaus edellyttƤƤ useiden tiimien yhteistyƶtƤ. Esimerkiksi kehitys-, testaus- ja DevOps-tiimien on tyƶskenneltƤvƤ yhdessƤ. TƤmƤ tilanne luo lisƤƤ johtamistarpeita ja edellyttƤƤ hyvƤƤ viestintƤƤ nƤiden tiimien vƤlillƤ, jotta voidaan varmistaa, ettƤ ne keskittyvƤt ja pyrkivƤt samoihin tavoitteisiin.

 

Esimerkki inkrementaalisesta testauksesta

Esimerkki inkrementaalisesta testauksesta

EhkƤ helpoin tapa ymmƤrtƤƤ inkrementaalista testausta on miettiƤ esimerkkiƤ. Seuraavassa on yksinkertainen tilanne, joka auttaa havainnollistamaan prosessia.

 

1. Esimerkki mobiilipankkisovelluksen inkrementaalisesta testauksesta

Skenaario: Tiimi rakentaa mobiilipankkisovellusta. Sovellus koostuu useista eri moduuleista, jotka mahdollistavat:

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

  • 2FA ja biometrinen kƤyttƤjƤvarmennus
  • Tapahtumien kƤsittely
  • Rahoitustietojen hallinnoinnin kojelauta

 

Tavoite: RyhmƤ haluaa testata kunkin moduulin integrointia ja selvittƤƤ, toimivatko ne hyvin yhteen. TƤmƤn tuloksena he rakentavat kolme testitapausta.

 

Testitapaus 1

EnsimmƤisessƤ testitapauksessa tiimi haluaa varmistaa, ettƤ syƶttƤmƤllƤ biometriset tiedot tai salasanan kƤyttƤjƤ saa pƤƤsyn sekƤ tapahtumien kƤsittelyyn ettƤ taloushallinnon kojelautaan.

Sovellus lƤpƤisee testin, jos kƤyttƤjƤ voi syƶttƤƤ tietonsa ja pƤƤstƤ kƤsiksi maksutapahtumiin.

 

Testitapaus 2

Seuraavassa testitapauksessa selvitetƤƤn, miten sovellus kƤsittelee luvattomia tapahtumia.

Sovellus lƤpƤisee testin, jos luvattoman maksutapahtuman yritys estetƤƤn ja sovellus antaa virheilmoituksen.

 

Testitapaus 3

ViimeisessƤ integrointitestissƤ validoidaan, voiko sovellus suorittaa tapahtumia samanaikaisesti.

Sovellus lƤpƤisee testin, jos kƤyttƤjƤ voi aloittaa maksutapahtuman ja kƤyttƤƤ taloudellisia tietojaan samaan aikaan ilman, ettƤ tietojen vƤlillƤ on epƤjohdonmukaisuuksia tai ongelmia.

 

Onko inkrementaalinen testaus lƤhestymistapa

sama kuin inkrementaalinen testaus?

alfa-testaus vs. beta-testaus

Ei. Inkrementaalisuustestaus viittaa tilastolliseen markkinointimenetelmƤƤn, joka tunnetaan ehkƤ parhaiten attribuutiomallinnuksena. Lyhyesti sanottuna se auttaa markkinointitiimejƤ ymmƤrtƤmƤƤn mainoskampanjoiden, markkinointikanavien tai tiettyjen strategioiden vaikutusta.

Vaikka kiinnostus tƤllaista mallinnusta kohtaan on kasvanut viime vuosina evƤsteiden ja kolmansien osapuolten tietojen ”kuoleman” ansiosta, ainoa yhteys inkrementaaliseen testaukseen on yhteinen sana.

 

3 parasta tyƶkalua inkrementaaliseen testaukseen

ZAPTEST RPA + Testausautomaatio-sarja

#1. ZAPTEST

Ensiluokkaisen palvelun lisƤksi
RPA
ZAPTEST tarjoaa valikoiman ohjelmistotestauksen automatisointityƶkaluja, jotka soveltuvat erinomaisesti inkrementaaliseen testaukseen. Joitakin ominaisuuksia ovat:


  • Testidatan hallinta
    : VƤhentƤƤ inkrementaaliseen testaukseen kuluvaa aikaa ja vaivaa antamalla tiimeille mahdollisuuden kƤyttƤƤ testidataa uudelleen.
  • KƤsikirjoituksen tallennus ja toisto: TƤmƤn koodittoman tyƶkalun avulla tiimit voivat tallentaa ja suorittaa skriptejƤ ja sƤƤstƤƤ paljon aikaa inkrementaalisen testauksen aikana.
  • UudelleenkƤytettƤvƤt testimoduulit: ZAPTEST on erittƤin modulaarinen, ja sen avulla tiimit voivat luoda ja kƤyttƤƤ testimoduuleja uudelleen ja sƤƤstƤƤ huomattavasti aikaa testausprosessista.

Kaiken kaikkiaan ZAPTEST tarjoaa tehokkaan ja monipuolisen testiautomaatiopaketin, joka soveltuu kaikenlaiseen testaukseen, myƶs inkrementaaliseen testaukseen.

 

#2. Seleeni

Selenium on avoimen lƤhdekoodin testiautomaatioalusta, joka on rakennettu helpottamaan mobiilisovellusten testausta. Tyƶkalut tukevat useita mobiilialustoja (Android, iOS, Windows) ja kƤyttƤvƤt moduulien simulointiin stubeja ja ajureita.

 

#3. Testsigma

Testsigma on pilvipohjainen testiautomaatioalusta. SitƤ voidaan kƤyttƤƤ web- ja mobiilisovellusten testaamiseen, ja se soveltuu inkrementaaliseen testaukseen koodittoman testinluonnin ja CI/CD-putkiin integroinnin ansiosta.

 

Lopulliset ajatukset

Ohjelmistotestauksessa inkrementaalinen testaus on tƤrkeƤ osa integrointitestausta. Sen avulla tiimit voivat pilkkoa moduulit helposti testattaviin osiin ennen kuin ne integroidaan hitaasti. TƤstƤ on se hyƶty, ettƤ jokainen moduuli voidaan tarkistaa vikojen varalta ja sen jƤlkeen sen osalta, miten se integroituu siihen liitettyihin osiin.

Luokkansa parhaana pidetyn
RPA
tyƶkaluista, ZAPTEST tarjoaa kooditonta ohjelmistotestausautomaatiota, joka on sekƤ alustojen ettƤ sovellusten rajat ylittƤvƤƤ. LisƤksi testauspakettimme sisƤltƤƤ ominaisuuksia, kuten CI/CD-integraation, vankan raportoinnin ja analytiikan sekƤ ensiluokkaisen tuen ja asiakaspalvelun.

Download post as PDF

Alex Zap Chernyak

Alex Zap Chernyak

Founder and CEO of ZAPTEST, with 20 years of experience in Software Automation for Testing + RPA processes, and application development. Read Alex Zap Chernyak's full executive profile on Forbes.

Get PDF-file of this post

Virtual Expert

ZAPTEST

ZAPTEST Logo