fbpx

Get your 6-month No-Cost Opt-Out offer for Unlimited Software Automation?

Inkrementaalne testimine tarkvara testimisel on metoodika, mis võimaldab meeskondadel jagada üksikuid mooduleid, testida neid eraldi ja integreerida neid etapiviisiliselt. See aitab leida defekte varakult, vähendab keerukust ja suurendab testide katvust.

Selles artiklis tehakse süvitsi sukeldumine inkrementaalsesse testimisse, selgitatakse, mis see on, ning uuritakse erinevaid tüüpe, protsesse, lähenemisviise, vahendeid ja muud, mis on selle kasuliku metoodikaga seotud.

 

Mis on inkrementaalne testimine?

Mis on inkrementaalne testimine tarkvara testimisel?

Testimine on tarkvaraarenduse elutsükli (SDLC) üks olulisemaid etappe. Nii nagu SDLC puhul, on ka testimine jaotatud erinevateks loogilisteks etappideks. Inkrementaalne testimine on üks neist etappidest ja see toimub tavaliselt ajal, mil
integratsioonitestimine
ja kohe pärast
ühiktestimine
.

Inkrementaalne testimine on pragmaatiline tarkvara testimise lähenemisviis, mis jaotab suured või keerulised programmid juhitavateks, väikesteks tükkideks. Selle asemel, et integreerida ja testida kogu tarkvarasüsteemi korraga, vaadeldakse inkrementaalses testimises mooduleid ja rakendatakse etapiviisilist kontrolliprotsessi.

Tarkvaramoodulid on tavaliselt iseseisvad koodiüksused, mis täidavad konkreetseid ülesandeid või funktsioone. See, kui üksikasjalikud need moodulid on, sõltub erinevatest teguritest, näiteks kodeerimistavadest, arendusmeetoditest või isegi kasutatavast programmeerimiskeelest.

Mooduleid testitakse sõltumatult ühiktestimise käigus. Seejärel integreeritakse integratsioonitesti käigus iga moodul tükkhaaval või osade kaupa. See protsess tagab, et iga moodul töötab hästi koos. Iga mooduli täielikuks kontrollimiseks peavad testijad siiski simuleerima veel rakendamata komponente või välissüsteeme. Selleks on neil vaja tüvede ja juhtide abi.

 

Mis on stubid ja draiverid inkrementaalses testimises?

Stubid ja draiverid on kriitilised tarkvara testimise vahendid. Neid ajutisi kooditükke kasutatakse integratsioonitestimise käigus, sest need pakuvad meeskonnale võimalust jäljendada erinevate moodulite või komponentide käitumist ja liideseid.

1. Kitsed:

Stubid jäljendavad mooduleid, mida ei ole veel välja töötatud ja mis seetõttu ei ole testimiseks kättesaadavad. Need võimaldavad testitaval moodulil (MUT) kasutada mittetäielikke mooduleid. Selle tulemuseks on, et MUTi saab testida eraldi, isegi kui seotud moodulid ei ole kättesaadavad.

2. Juhid:

Juhid seevastu simuleerivad MUTi kutsuvate moodulite käitumist. Testimiskeskkonnas saavad need draiverid saata MUT-testiandmeid. See hõlbustab jällegi moodulite testimist eraldi, ilma et oleks vaja väliseid sõltuvusi.

Stubide või draiverite kasutamine vähendab arendusaega, parandab koodi kvaliteeti ja suurendab meeskonna tootlikkust. Kuid selle üle otsustamine, millist neist kasutada, sõltub sellest, milline testimismeetod on kõige sobivam. Seda laiendame allpool olevas osas, mis käsitleb erinevaid integratsioonitesti tüüpe.

 

Erinevad täiendavad tüübid

integratsioonitestimine

Erinevad inkrementaalse integratsioonitesti tüübid

Inkrementaalse testimise tüübid võib laias laastus jagada kolme kategooriasse. Uurime igaüht neist.

 

1. Ülalt-alla järkjärguline integreerimine

 

Ülalt-alla inkrementaalne integreerimine algab süsteemi kõrgeima astme moodulite testimisega. Sealt edasi integreeritakse ja testitakse järk-järgult madalama astme mooduleid.On kaks peamist stsenaariumi, mille puhul kasutatakse ülalt-alla suunatud järkjärgulist integreerimist. Need on järgmised:

  • Kui süsteem on väga suur või väga keeruline
  • Kui arendusmeeskond töötab korraga mitme mooduli kallal.

Ülalt-alla suunatud järkjärgulise integreerimise sammud

  • Kriitiliste moodulite tuvastamine
  • Loo stubid madalama astme moodulite jäljendamiseks
  • Arendada draiverid, mis suhtlevad kõrgemate moodulitega, et saata neile andmeid ja tõlgendada mooduli väljundeid.
  • Kriitiliste moodulite ühiktestimine koos draiverite ja stubidega
  • Integreerige madalama astme moodulid ja asendage järk-järgult stubid reaalsete implementatsioonidega.
  • Uute moodulite kohandamine draiverite ümberkujundamiseks
  • Korrake seda, kuni kõik madalama astme moodulid on integreeritud ja testitud.

 

2. Bottom-up järkjärguline integratsioon

 

Bottom-up-inkrementaalsed integratsioonid toimivad vastupidises suunas. Selle lähenemisviisi puhul katsetatakse süsteemi madalama (või kõige vähem kriitilise tähtsusega) mooduleid, millele lisatakse järk-järgult kõrgema astme mooduleid. See lähenemisviis sobib erinevate stsenaariumide puhul, näiteks:

  • Kui tegelete väiksemate süsteemidega
  • Kui süsteem on moduleeritud
  • Kui teil on mõningaid kahtlusi kas täpsuse või täielikkuse osas.

Aluselt ülespoole suunatud järkjärgulise integreerimise sammud

  • Madalama astme moodulite tuvastamine
  • madalama astme moodulite üksustestimine nende individuaalse funktsionaalsuse kontrollimiseks
  • Töötada välja juhtseadmed, mis tegutsevad vahendajatena madalama astme moodulite vahel.
  • Loo stubs, et simuleerida kõrgema astme moodulite käitumist.
  • Integreerige järgmised moodulid, alates madalamast kuni kõrgema astme mooduliteni, ja asendage järk-järgult stubid reaalsete implementatsioonidega.
  • Uuendage draiverid, et need vastaksid uutele moodulitele.
  • Korrake seda, kuni kõik kõrgema astme moodulid on integreeritud ja testitud.

 

3. Funktsionaalne järkjärguline integreerimine

 

Funktsiooni inkrementaalne integratsioonitestimine on järgmine levinud inkrementaalse testimise tüüp tarkvara testimisel. Kui kaks eelmist liiki keskendusid kõrgemate ja madalamate moodulite testimisele, siis funktsionaalne täiendav testimine põhineb konkreetse mooduli funktsionaalsusel.

Funktsionaalset järkjärgulist integreerimist kasutatakse
Agile/DevOps metoodikad
ning see on suurepärane valik rakenduste puhul, millel on keerulised sõltuvused moodulite või komponentide vahel.

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

Funktsionaalse järkjärgulise integreerimise sammud

  • Määrata üksikud moodulid ja komponendid, millel on täpselt määratletud liidesed.
  • Iga mooduli funktsionaalsuse kontrollimine ühiktestimise abil
  • Integreerida süsteemi kõige minimaalsemad põhimoodulid ja tagada selle toimimine.
  • Lisage järk-järgult üksikuid mooduleid, testides funktsionaalsust igal sammul.
  • Muuda koodi iga mooduli lisamisel ümber.
  • Kui kõik moodulid on lisatud, testige funktsionaalsust ja jõudlust.

 

Inkrementaalse testimise eelised ja puudused

probleemid koormuse testimine ja RPA

Nüüdseks peaks teil olema mõningane ettekujutus sellest, miks inkrementaalne testimine on populaarne lähenemisviis. Kuid nagu kõigil tarkvara testimise meetoditel, on ka sellel omad eelised ja puudused. Uurime mõnda neist plussidest ja miinustest.

 

Inkrementaalse testimise eelised

 

1. Paindlikkus

Nagu kõik tarkvaraarendajad ja testijad väga hästi teavad, võivad nõuded SDLC käigus muutuda ja areneda, mõnikord üsna järsult. Inkrementaalne testimine on piisavalt dünaamiline, et võimaldada meeskondadel testimise käigus kohaneda ning lisada uusi plaane ja suundumusi.

 

2. Varajane vigade tuvastamine

Parim aeg vea või defekti avastamiseks on võimalikult varakult. Kui arendajad kontrollivad ükshaaval mooduleid, on probleemide tuvastamine ja parandamine palju lihtsam. Veelgi enam, see aitab vähendada tõenäosust, et suured probleemid tekivad hilisemas arengujärgus.

 

3. Lihtsus

Tarkvara testimine võib olla väga keeruline protsess. Üheks kõige veenvamaks aspektiks on see, kuidas see jaotab linna testimise töötavateks osadeks. Selle asemel, et tegeleda ülekaaluka keerukusega, saavad testijad keskenduda konkreetsetele moodulitele ja isegi seada need prioriteediks. See eelis on suurte ja keeruliste rakenduste puhul jumalateenistus.

 

4. Madalam regressioonirisk

Regressioon on aeganõudev ja keeruline küsimus tarkvaraarenduse raames. Inkrementaalne testimine võib vähendada regressioonist tulenevat sagedust ja riske, sest see võimaldab meeskondadel testida mooduleid eraldi ja tegeleda probleemidega nende ilmnemisel. Kui seda kasutatakse koos tahkete
regressioonitestimine
, võivad meeskonnad säästa palju aega ja südamevalu.

 

5. Tagasiside võimalused

Inkrementaalse testimise sageli tähelepanuta jäetud eelis on see, et see võimaldab meeskondadel koostada prototüüpe ja MVP-sid. Sealt edasi saavad sidusrühmad ja investorid hinnata protsessi põhifunktsionaalsust ja anda hindamatut tagasisidet. Selline olukord võib säästa palju aega ja raha ning tuua kaasa tugevamad tooted.

 

Inkrementaalse testimise miinused

 

1. Integratsiooniküsimused

Moodulite eraldi testimine on soovitav, sest see jaotab keerulise rakenduse hallatavateks tükkideks. Nende moodulite integreerimine võib aga põhjustada uusi ja ootamatuid vigu. Seega tuleb inkrementaalset testimist hoolikalt ja teadlikult kavandada.

 

2. Testikomplekti keerukus

Kuna iga mooduli jaoks on mitu testjuhtumit ja nende omavaheline suhtlus, võib testikomplektide jälgimine ja haldamine muutuda keeruliseks. Suurte ja keeruliste rakenduste puhul on seetõttu vaja põhjalikku dokumentatsiooni või testide haldamise vahendeid.

 

3. Rohkem tööd

Monoliitne testimine on küll keerulisem, kuid nõuab vähem testimist. Paljude moodulite eraldi testimisel nõuab inkrementaalne testimine rohkem tööd. Siiski tähendavad inkrementaalse testimise eelised, näiteks vigade varajane avastamine, et lisapingutused on aja kokkuhoiu investeering. Loomulikult,
tarkvara testimise automatiseerimine
aitab neid jõupingutusi vähendada.

 

4. Suurenenud juhtimisnõuded

Inkrementaalne testimine nõuab mitme meeskonna koostööd. Näiteks peavad arendus-, testimis- ja DevOps-meeskonnad tegema koostööd. Selline olukord tekitab täiendavat juhtimisvajadust ja nõuab head suhtlemist nende meeskondade vahel, et tagada nende keskendumine ja samade eesmärkide saavutamine.

 

Näide inkrementaalsest testimisest

Näide inkrementaalsest testimisest

Kõige lihtsam viis inkrementaalse testimise lähenemisviisi mõistmiseks on ehk mõelda ühe näite peale. Siin on lihtne olukord, mis aitab protsessi visualiseerida.

 

1. Mobiilipangarakenduse inkrementaalse testimise näide

Stsenaarium: Meeskond ehitab mobiilipangarakendust. Rakendus koosneb mitmest erinevast moodulist, mis võimaldavad:

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

  • 2FA ja biomeetriline kasutajakontroll
  • Tehingute töötlemine
  • Finantsandmete haldamise armatuurlaud

 

Eesmärk: Meeskond soovib testida iga mooduli integreerimist ja teha kindlaks, kas nad töötavad hästi koos. Selle tulemusena koostavad nad kolm testjuhtumit.

 

Katsejuhtum 1

Esimesel testjuhtumil soovib meeskond tagada, et biomeetriliste andmete või salasõna sisestamisel saab kasutaja juurdepääsu nii tehingutöötlusele kui ka finantsandmete haldamise armatuurlauale.

Rakendus läbib testi, kui kasutaja saab sisestada oma andmed ja saada juurdepääsu tehingutele.

 

Katsejuhtum 2

Järgmine testjuhtum on mõeldud selleks, et näha, kuidas rakendus käitleb volitamata tehinguid.

Rakendus läbib testi, kui volitamata tehingu tegemise katse blokeeritakse ja rakendus väljastab veateate.

 

Katsejuhtum 3

Viimane integratsioonitest hõlmab selle kontrollimist, kas rakendus saab teha samaaegselt tehinguid.

Rakendus läbib testi, kui kasutaja saab samal ajal alustada tehingut ja pääseda ligi oma finantsteabele ilma andmete vastuolude või probleemideta.

 

Kas inkrementaalse testimise lähenemisviis on

sama, mis inkrementaalne testimine?

alfa-testimine vs. beetatestimine

Ei. Inkrementaalsuse testimine viitab statistilisele turundusmeetodile, mis on ehk kõige paremini tuntud kui atributsiooni modelleerimine. Lühidalt öeldes aitab see turundusmeeskondadel mõista reklaamikampaaniate, turunduskanalite või konkreetsete strateegiate mõju.

Kuigi huvi sellise modelleerimise vastu on viimastel aastatel kasvanud tänu küpsiste ja kolmandate isikute andmete “surmale”, on selle ainus seos inkrementaalse testimisega ühine sõna.

 

3 parimat tööriista inkrementaalseks testimiseks

ZAPTEST RPA + Testautomaatika komplekt

#1. ZAPTEST

Lisaks esmaklassilise
RPA
ZAPTEST pakub mitmeid tarkvara testimise automatiseerimise vahendeid, mis sobivad suurepäraselt täiendavaks testimiseks. Mõned funktsioonid on järgmised:


  • Katseandmete haldamine
    : Vähendada inkrementaalse testimisega seotud aja- ja töömahtu, võimaldades meeskondadel testimisandmeid taaskasutada.
  • Stsenaariumi salvestamine ja taasesitus: See koodivaba tööriist võimaldab meeskondadel salvestada ja käivitada skripte ning säästa palju aega täiendava testimise ajal.
  • Taaskasutatavad testimoodulid: ZAPTEST on väga modulaarne ja võimaldab meeskondadel luua ja taaskasutada testimooduleid ning vähendada testimisprotsessi märkimisväärselt.

Kokkuvõttes pakub ZAPTEST võimsat ja mitmekülgset testide automatiseerimise komplekti, mis sobib igat tüüpi testimiseks, sealhulgas ka inkrementaalseks testimiseks.

 

#2. Seleen

Selenium on avatud lähtekoodiga testide automatiseerimise platvorm, mis on loodud mobiilirakenduste testimise hõlbustamiseks. Tööriistad toetavad mitmeid mobiiliplatvorme (Android, iOS, Windows) ning kasutavad moodulite simuleerimiseks stubisid ja draivereid.

 

#3. Testigma

Testsigma on pilvepõhine testide automatiseerimise platvorm. Seda saab kasutada veebi- ja mobiilirakenduste testimiseks ning see sobib inkrementaalseks testimiseks tänu koodita testide loomisele ja integreerimisele CI/CD-putkega.

 

Lõplikud mõtted

Inkrementaalne testimine on tarkvara testimisel oluline osa integratsioonitestimisest. See võimaldab meeskondadel jagada moodulid kergesti testitavateks osadeks enne nende aeglast integreerimist. Selle eelised seisnevad selles, et iga moodulit saab kontrollida vigade suhtes ja seejärel selle suhtes, kuidas see integreerub oma ühendatud osadega.

Lisaks meie klassi parimale
RPA
tööriistad, ZAPTEST pakub koodivaba tarkvara testimise automatiseerimist, mis on nii platvormi- kui ka rakendustevaheline. Lisaks on meie testimise pakett täis funktsioone, nagu CI/CD-integratsioon, usaldusväärne aruandlus ja analüüs ning esmaklassiline tugi ja klienditeenindus.

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