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?
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
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.
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
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
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:
- 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?
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
#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.
