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