Inkrementālā testēšana programmatūras testēšanā ir metodoloģija, kas ļauj komandām sadalīt atsevišķus moduļus, testēt tos izolēti un integrēt pakāpeniski. Tas palīdz agrīni atrast defektus, samazina sarežģītību un palielina testu pārklājumu.
Šajā rakstā padziļināti aplūkosim inkrementālo testēšanu, izskaidrosim, kas tā ir, un izpētīsim dažādus veidus, procesus, pieejas, rīkus un citus ar šo noderīgo metodoloģiju saistītos aspektus.
Kas ir inkrementālā testēšana?
Testēšana ir viens no svarīgākajiem programmatūras izstrādes dzīves cikla (SDLC) posmiem. Tāpat kā SDLC, arī testēšana ir sadalīta dažādos loģiskos posmos. Inkrementālā testēšana ir viens no šiem posmiem, un tā parasti notiek, kad
integrācijas testēšana
un uzreiz pēc
vienības testēšana
.
Inkrementālā testēšana ir pragmatiska programmatūras testēšanas pieeja, kas lielas vai sarežģītas programmas sadala uz viegli pārvaldāmiem gabaliņiem. Tā vietā, lai integrētu un testētu visu programmatūras sistēmu uzreiz, inkrementālā testēšana aplūko moduļus un īsteno pakāpenisku pārbaudes procesu.
Programmatūras moduļi parasti ir patstāvīgas koda vienības, kas veic konkrētus uzdevumus vai funkcijas. Tas, cik detalizēti ir šie moduļi, ir atkarīgs no dažādiem faktoriem, piemēram, kodēšanas prakses, izstrādes metodoloģijām vai pat izmantotās programmēšanas valodas.
Vienības testēšanas laikā moduļi tiek testēti neatkarīgi. Pēc tam integrācijas testēšanas laikā katrs modulis tiek integrēts pa daļām vai pa posmiem. Šis process nodrošina, ka katrs modulis darbojas labi kopā. Tomēr, lai pilnībā pārbaudītu katru moduli, testētājiem ir jāimitē komponenti, kas vēl nav ieviesti, vai ārējās sistēmas. Lai to paveiktu, viņiem ir nepieciešama palīgierīču un draiveru palīdzība.
Kas ir stubi un draiveri inkrementālajā testēšanā?
Pamati un draiveri ir ļoti svarīgi programmatūras testēšanas rīki. Šos pagaidu koda fragmentus izmanto integrācijas testēšanas laikā, jo tie ļauj komandām imitēt dažādu moduļu vai komponentu uzvedību un saskarnes.
1. Stublāji:
Stubi imitē moduļus, kas vēl nav izstrādāti un nav pieejami testēšanai. Tie ļauj testējamajam modulim (MUT) izsaukt nepabeigtus moduļus. Rezultāts ir tāds, ka MUT var testēt izolēti, pat ja nav pieejami saistītie moduļi.
2. Vadītāji:
Savukārt draiveri simulē to moduļu uzvedību, kuri izsauc MUT. Testēšanas vidē šie draiveri var nosūtīt MUT testa datus. Tas atkal atvieglo izolētu moduļu testēšanu bez nepieciešamības pēc ārējām atkarībām.
Lietojot pakārtotās programmas vai draiverus, tiek samazināts izstrādes laiks, uzlabota koda kvalitāte un palielināta komandas produktivitāte. Tomēr lēmums par to, kuru no tām izmantot, ir atkarīgs no tā, kura testēšanas metodika ir vispiemērotākā. Mēs to sīkāk izvērsīsim tālāk sadaļā, kurā aplūkosim dažādus inkrementālās integrācijas testēšanas veidus.
Dažādu veidu inkrementālie
integrācijas testēšana
Inkrementālās testēšanas veidus kopumā var iedalīt trīs kategorijās. Izpētīsim katru no tiem.
1. Pakāpeniska integrācija no augšas uz leju
Inkrementālā integrācija “no augšas uz leju” sākas ar sistēmas augstākās kārtas moduļu testēšanu. Pēc tam tā pakāpeniski integrē un testē zemākas kārtas moduļus.Pastāv divi galvenie scenāriji, kuros tiek izmantota augšupēja inkrementāla integrācija. Tās ir:
- Ja sistēma ir ļoti liela vai ļoti sarežģīta
- Ja izstrādātāju komanda vienlaikus strādā pie daudziem moduļiem.
No augšas uz leju veicamas pakāpeniskas integrācijas posmi
- Noteikt kritiskos moduļus
- Izveidot pakārtotos moduļus, lai atdarinātu zemākas kārtas moduļus
- Izstrādāt draiverus, kas mijiedarbojas ar augstākas pakāpes moduļiem, lai nosūtītu tiem datus un interpretētu moduļa rezultātus.
- Kritiski svarīgu moduļu vienības testēšana ar draiveriem un pakārtotajiem moduļiem
- Zemākas kārtas moduļu integrēšana un pakāpeniska pakārtoto moduļu aizstāšana ar reālām implementācijām.
- Draiveru pārveidošana, lai pielāgotos jaunajiem moduļiem
- To atkārtojiet, līdz visi zemākas kārtas moduļi ir integrēti un pārbaudīti.
2. Pakāpeniska integrācija no apakšas uz augšu
Inkrementālā integrācija no apakšas uz augšu notiek pretējā virzienā. Izmantojot šo pieeju, tiek testēti sistēmas zemākās kārtas (vai vismazāk kritiskie) moduļi, pakāpeniski pievienojot augstākas kārtas moduļus. Šī pieeja ir piemērota dažādiem scenārijiem, piemēram:
- Strādājot ar mazākām sistēmām
- Ja sistēma ir modulāra
- Ja jums ir bažas par atvasinājumu precizitāti vai pilnīgumu.
Pakāpes augšupējai pakāpeniskai integrācijai
- Apzināt zemākas kārtas moduļus
- Zemākas kārtas moduļu vienības testēšana, lai pārbaudītu to individuālo funkcionalitāti.
- Izstrādāt draiverus, kas darbojas kā starpnieki ar zemākas kārtas moduļiem.
- Izveidot pakārtotās programmas, lai simulētu augstākas kārtas moduļu uzvedību
- Integrēt nākamos moduļus, sākot no zemākas uz augstāku kārtu, un pakāpeniski aizstāt pakārtotās moduļu daļas ar reālām implementācijām.
- Draiveru pārveidošana, lai pielāgotos jaunajiem moduļiem
- To atkārtojiet, līdz visi augstākā līmeņa moduļi ir integrēti un pārbaudīti.
3. Funkcionālā inkrementālā integrācija
Funkciju inkrementālā integrācijas testēšana ir nākamais izplatītākais inkrementālās testēšanas veids programmatūras testēšanā. Ja iepriekšējos divos veidos galvenā uzmanība tika pievērsta augstākas un zemākas kārtas moduļiem, tad funkcionālā inkrementālā testēšana ir balstīta uz konkrēta moduļa funkcionalitāti.
Funkcionālā inkrementālā integrācija tiek izmantota
Agile/DevOps metodoloģijās.
, un tā ir lieliska izvēle lietojumprogrammām ar sarežģītām atkarībām starp moduļiem vai komponentēm.
Funkcionālās inkrementālās integrācijas soļi
- Identificēt atsevišķus moduļus un komponentus ar precīzi definētām saskarnēm.
- Katra moduļa funkcionalitātes pārbaude, izmantojot vienības testēšanu.
- Integrēt minimālos sistēmas pamatmoduļus un nodrošināt to darbību.
- Pakāpeniski pievienojiet atsevišķus moduļus, katrā posmā testējot funkcionalitāti.
- Katra moduļa pievienošanas laikā pārveidojiet kodu.
- Kad visi moduļi ir pievienoti, pārbaudiet funkcionalitāti un veiktspēju.
Inkrementālās testēšanas pieejas plusi un mīnusi
Tagad jums jau būtu jāsaprot, kāpēc inkrementālā testēšana ir populāra pieeja. Tomēr, tāpat kā visām programmatūras testēšanas metodoloģijām, arī tai ir savas priekšrocības un trūkumi. Apskatīsim dažus no šiem plusiem un mīnusiem.
Inkrementālās testēšanas pieejas plusi
1. Elastība
Kā visi programmatūras izstrādātāji un testētāji ļoti labi zina, SDLC laikā prasības var mainīties un attīstīties, dažkārt diezgan krasi. Inkrementālā testēšana ir pietiekami dinamiska, lai ļautu komandām pielāgoties testēšanas procesa laikā un iekļaut jaunus plānus un virzienus.
2. Agrīna kļūdu atklāšana
Labākais laiks, lai atklātu kļūdu vai defektu, ir pēc iespējas agrāk. Ja izstrādātāji pārbauda atsevišķus moduļus, problēmu identificēšana un novēršana ir daudz vieglāka. Turklāt tas palīdz mazināt varbūtību, ka lielas problēmas varētu rasties izstrādes beigu posmā.
3. Vienkāršība
Programmatūras testēšana var būt ļoti sarežģīts process. Viens no pārliecinošākajiem inkrementālās testēšanas aspektiem ir tas, kā tā sadala testēšanas pilsētu praktiski izmantojamās daļās. Tā vietā, lai nodarbotos ar milzīgu sarežģītību, testētāji var koncentrēties uz konkrētiem moduļiem un pat noteikt to prioritātes. Šī priekšrocība ir dāvana lielām un sarežģītām lietojumprogrammām.
4. Zemāks regresijas risks
Regresija ir laikietilpīgs un sarežģīts jautājums programmatūras izstrādē. Inkrementālā testēšana var mazināt regresijas biežumu un riskus, jo tā ļauj komandām testēt moduļus individuāli un risināt problēmas, kad tās rodas. Lietojot kopā ar cietu
regresijas testēšana
, komandas var ietaupīt daudz laika un sirdssāpes.
5. Atgriezeniskās saites iespējas
Bieži vien netiek ņemta vērā inkrementālās testēšanas priekšrocība ir tā, ka tā ļauj komandām brīvi izstrādāt prototipus un MVP. No turienes ieinteresētās personas un investori var novērtēt procesa pamatfunkcionalitāti un sniegt nenovērtējamas atsauksmes. Šādā situācijā var ietaupīt daudz laika un naudas, kā arī radīt stabilākus produktus.
Pakāpeniskas testēšanas pieejas trūkumi
1. Integrācijas jautājumi
Atsevišķu moduļu testēšana ir vēlama, jo tā sarežģīto lietojumprogrammu sadala pa pārvaldāmiem gabaliņiem. Tomēr, integrējot šos moduļus, var rasties jaunas un neparedzētas kļūdas. Tāpēc ir rūpīgi un apzināti jāplāno pakāpeniska testēšanas pieeja.
2. Testu komplekta sarežģītība
Ja katram modulim ir vairāki testēšanas gadījumi un to savstarpējā mijiedarbība, testēšanas komplektu izsekošana un pārvaldība var kļūt sarežģīta. Lielu un sarežģītu lietojumprogrammu gadījumā ir nepieciešama rūpīga dokumentācija vai testēšanas pārvaldības rīki.
3. Vairāk darba
Lai gan monolīta testēšana ir sarežģītāka, tai nepieciešams mazāk testēšanas. Testējot daudzus moduļus atsevišķi, inkrementālā testēšana prasa vairāk darba. Tomēr inkrementālās testēšanas priekšrocības, piemēram, agrīna kļūdu atklāšana, nozīmē, ka papildu pūles ir ieguldījums, kas ietaupa laiku. Protams,
programmatūras testēšanas automatizācija
var palīdzēt samazināt šos pūliņus.
4. Paaugstinātas vadības prasības
Inkrementālā testēšana prasa vairāku komandu sadarbību. Piemēram, izstrādes, testēšanas un DevOps komandām būs jāstrādā saskaņoti. Šāda situācija rada papildu vadības pieprasījumu un prasa labu saziņu starp šīm komandām, lai nodrošinātu, ka tās ir koncentrētas un tiecas sasniegt vienus un tos pašus mērķus.
Inkrementālās testēšanas piemērs
Iespējams, visvienkāršākais veids, kā izprast inkrementālās testēšanas pieeju, ir aplūkot piemēru. Šeit ir vienkārša situācija, kas palīdzēs vizualizēt šo procesu.
1. Mobilās bankas mobilās lietotnes inkrementālās testēšanas piemērs
Scenārijs: Komanda izstrādā mobilo banku lietotni. Lietotne sastāv no vairākiem dažādiem moduļiem, kas ļauj:
- 2FA un biometriskā lietotāja verifikācija
- Darījumu apstrāde
- Finanšu datu pārvaldības paneļi
Mērķis: Komanda vēlas pārbaudīt katra moduļa integrāciju un noteikt, vai tie labi darbojas kopā. Rezultātā tiek izveidoti trīs testa gadījumi.
1. testa gadījums
Pirmajā testa gadījumā komanda vēlas nodrošināt, ka, ievadot biometriskos vai paroles datus, lietotājs iegūs piekļuvi gan darījumu apstrādei, gan finanšu datu pārvaldības panelim.
Programma izturēs testu, ja lietotājs varēs ievadīt savu informāciju un piekļūt darījumiem.
2. testa gadījums
Nākamais testa gadījums ir paredzēts, lai pārbaudītu, kā lietotne apstrādā nesankcionētus darījumus.
Programma iztur testu, ja mēģinājums veikt neatļautu darījumu tiek bloķēts un tiek parādīts kļūdas ziņojums.
3. testa gadījums
Pēdējais integrācijas tests ietver apstiprināšanu, vai lietotne var veikt darījumus vienlaicīgi.
Programma izturēs testu, ja lietotājs varēs uzsākt darījumu un vienlaikus piekļūt savai finanšu informācijai bez jebkādām datu neatbilstībām vai problēmām.
Vai inkrementālās testēšanas pieeja ir
tas pats, kas inkrementālā testēšana?
Nē. Inkrementalitātes testēšana attiecas uz statistisko mārketinga metodi, kas, iespējams, vislabāk pazīstama kā atribūcijas modelēšana. Īsāk sakot, tas palīdz mārketinga komandām saprast reklāmas kampaņu, mārketinga kanālu vai konkrētu stratēģiju ietekmi.
Lai gan interese par šāda veida modelēšanu pēdējos gados ir pieaugusi, pateicoties sīkfailu un trešo pušu datu “nāvei”, vienīgā saistība ar inkrementālo testēšanu ir kopīgs vārds.
3 labākie rīki inkrementālai testēšanai
#1. ZAPTEST
Kā arī nodrošina pirmās klases
RPA
ZAPTEST piedāvā virkni programmatūras testēšanas automatizācijas rīku, kas ir ideāli piemēroti inkrementālai testēšanai. Dažas no funkcijām:
Testa datu pārvaldība
: Samazināt laika patēriņu un pūles, kas saistītas ar inkrementālo testēšanu, ļaujot komandām atkārtoti izmantot testēšanas datus.- Scenāriju ierakstīšana un atskaņošana: Šis rīks bez kodēšanas ļauj komandām ierakstīt un izpildīt skriptus un ietaupīt daudz laika inkrementālās testēšanas laikā.
- Atkārtoti izmantojami testa moduļi: ZAPTEST ir ļoti modulārs un ļauj komandām izveidot un atkārtoti izmantot testēšanas moduļus, tādējādi ievērojami saīsinot testēšanas procesa laiku.
Kopumā ZAPTEST piedāvā jaudīgu un daudzveidīgu testēšanas automatizācijas komplektu, kas ir piemērots jebkura veida testēšanai, tostarp inkrementālai testēšanai.
#2. Selēns
Selenium ir atvērtā koda testēšanas automatizācijas platforma, kas ir izveidota, lai atvieglotu mobilo lietojumprogrammu testēšanu. Šie rīki atbalsta vairākas mobilās platformas (Android, iOS, Windows) un moduļu simulēšanai izmanto stubus un draiverus.
#3. Testsigma
Testsigma ir uz mākoņa balstīta testēšanas automatizācijas platforma. To var izmantot tīmekļa un mobilo lietojumprogrammu testēšanai, un tā ir piemērota inkrementālai testēšanai, pateicoties bezkodēšanas testu izveidei un integrācijai ar CI/CD cauruļvadiem.
Nobeiguma domas
Inkrementālā testēšana programmatūras testēšanā ir svarīga integrācijas testēšanas daļa. Tas ļauj komandām sadalīt moduļus viegli pārbaudāmās daļās, pirms tās lēnām integrēt. Priekšrocības ir tādas, ka katru moduli var pārbaudīt, vai tajā nav kļūdu, un pēc tam pārbaudīt, kā tas integrējas ar pievienotajām daļām.
Līdztekus mūsu labākajam savā klasē
RPA
rīki, ZAPTEST piedāvā programmatūras testēšanas automatizāciju bez kodēšanas, kas ir gan starpplatformu, gan starpprogrammu. Turklāt mūsu testēšanas komplekts ir aprīkots ar tādām funkcijām kā CI/CD integrācija, spēcīga atskaišu sagatavošana un analīze, kā arī augstākās klases atbalsts un klientu apkalpošana.
