Šajā sadaļā mēs izpratīsim dažādus programmatūras testēšanas veidus, kurus var izmantot programmatūras izstrādes dzīves cikla laikā.
Kā mēs zinām, programmatūras testēšana ir lietojumprogrammas funkcionalitātes analīzes process atbilstoši klienta priekšnoteikumam.
Ja vēlamies nodrošināt, ka mūsu programmatūra ir bez kļūdām vai stabila, mums ir jāveic dažāda veida programmatūras testēšana, jo testēšana ir vienīgā metode, kas padara mūsu lietojumprogrammu bez kļūdām.
Dažādi programmatūras testēšanas veidi
Programmatūras testēšanas kategorizēšana ir daļa no dažādām testēšanas darbībām, piemēram, testa stratēģija, testa rezultāti, definēts testa mērķis utt . Un programmatūras testēšana ir programmatūras izpilde, lai atrastu defektus.
Testēšanas veida mērķis ir apstiprināt AUT (Pieteikums tiek pārbaudīts).
Lai sāktu testēšanu, mums vajadzētu būt a prasība, gatavs lietošanai, pieejami nepieciešamie resursi . Lai saglabātu atbildību, mums ir jāpiešķir attiecīgs modulis dažādiem testēšanas inženieriem.
Programmatūras testēšana galvenokārt ir sadalīta divās daļās, kas ir šādas:
Kas ir manuālā pārbaude?
Jebkuras programmatūras vai lietojumprogrammas testēšana atbilstoši klienta vajadzībām, neizmantojot nevienu automatizācijas rīku, ir pazīstama kā manuāla pārbaude .
Citiem vārdiem sakot, mēs varam teikt, ka tā ir procedūra pārbaude un apstiprināšana . Manuālā testēšana tiek izmantota, lai pārbaudītu lietojumprogrammas vai programmatūras uzvedību pretrunā ar prasību specifikāciju.
java apakšvirknes piemērs
Mums nav nepieciešamas precīzas zināšanas par kādu testēšanas rīku, lai veiktu manuālās pārbaudes gadījumus. Mēs varam viegli sagatavot testa dokumentu, vienlaikus veicot manuālu testēšanu jebkurai lietojumprogrammai.
Lai iegūtu detalizētu informāciju par manuālo testēšanu, noklikšķiniet uz šīs saites: https://www.javatpoint.com/manual-testing.
Manuālās testēšanas klasifikācija
Programmatūras testēšanā manuālo testēšanu var iedalīt sīkāk trīs dažādi pārbaudes veidi , kas ir šādi:
Lai mēs labāk saprastu, apskatīsim tos pa vienam:
Baltās kastes pārbaude
Baltās kastes testēšanā izstrādātājs pārbaudīs katru koda rindiņu pirms tās nodošanas testēšanas komandai vai attiecīgajiem testēšanas inženieriem.
Pēc tam kods ir pamanāms izstrādātājiem visā testēšanas laikā; tāpēc šis process ir pazīstams kā WBT (baltās kastes pārbaude) .
Citiem vārdiem sakot, mēs varam teikt, ka izstrādātājs veiks pilnu baltās kastes testēšanu konkrētajai programmatūrai un nosūtīs konkrēto pieteikumu testēšanas komandai.
Baltās kastes testēšanas ieviešanas mērķis ir uzsvērt ieejas un izvades plūsmu pār programmatūru un uzlabot lietojumprogrammas drošību.
Baltās kastes testēšana ir pazīstama arī kā atvērtās kastes testēšana, stikla kastes testēšana, strukturālā pārbaude, caurspīdīgās kastes pārbaude un caurspīdīgās kastes testēšana .
Lai iegūtu padziļinātas zināšanas par balto kastīšu testēšanu, skatiet tālāk norādīto saiti: https://www.javatpoint.com/white-box-testing.
Melnās kastes pārbaude
Cits manuālās pārbaudes veids ir melnās kastes pārbaude . Šajā testēšanā testēšanas inženieris analizēs programmatūru atbilstoši prasībām, identificēs defektus vai kļūdu un nosūtīs to atpakaļ izstrādes komandai.
Pēc tam izstrādātāji novērsīs šos defektus, veiks vienu White box testēšanas kārtu un nosūtīs to testēšanas komandai.
Šeit kļūdu labošana nozīmē, ka defekts ir novērsts, un konkrētā funkcija darbojas atbilstoši norādītajai prasībai.
Melnās kastes testēšanas ieviešanas galvenais mērķis ir precizēt biznesa vajadzības vai klienta prasības.
Citiem vārdiem sakot, mēs varam teikt, ka melnās kastes testēšana ir process, kurā tiek pārbaudīta lietojumprogrammas funkcionalitāte atbilstoši klienta prasībām. Avota kods šajā pārbaudē nav redzams; tāpēc tas ir pazīstams kā melnās kastes pārbaude .
Lai iegūtu papildinformāciju par melnās kastes testēšanu, skatiet šo saiti: https://www.javatpoint.com/black-box-testing.
Melnās kastes testēšanas veidi
Melnās kastes testēšana tālāk tiek iedalīta divās daļās, kas ir aprakstītas tālāk:
Funkcionālā pārbaude
Testēšanas inženieris sistemātiski pārbaudīs visus komponentus, lai tie atbilstu prasībām, kas pazīstamas kā funkcionālā pārbaude . Funkcionālā pārbaude ir pazīstama arī kā Komponentu pārbaude .
Funkcionālajā testēšanā visas sastāvdaļas tiek pārbaudītas, norādot vērtību, definējot izvadi un apstiprinot faktisko izvadi ar paredzamo vērtību.
Funkcionālā pārbaude ir daļa no melnās kastes testēšanas, jo tā uzsver lietojumprogrammas prasības, nevis faktisko kodu. Testēšanas inženierim ir jāpārbauda tikai programma, nevis sistēma.
Lai iegūtu detalizētu informāciju par funkcionālo testēšanu, skatiet tālāk norādīto saiti: https://www.javatpoint.com/functional-testing .
Funkcionālās pārbaudes veidi
Tāpat kā cita veida testēšana ir sadalīta vairākās daļās, arī funkcionālā pārbaude tiek klasificēta dažādās kategorijās.
Daudzveidīgais funkcionālās pārbaudes veidi satur sekojošo:
Tagad sapratīsim tos pa vienam:
1. Vienības pārbaude
Vienības testēšana ir pirmais funkcionālās pārbaudes līmenis, lai pārbaudītu jebkuru programmatūru. Šajā testēšanas inženieris neatkarīgi pārbaudīs lietojumprogrammas moduli vai pārbaudīs visu moduļa funkcionalitāti vienību pārbaude .
Vienības testēšanas galvenais mērķis ir pārbaudīt vienības komponentus ar to veiktspēju. Šeit vienība ir definēta kā viena programmatūras vai lietojumprogrammas pārbaudāma funkcija. Un tas tiek pārbaudīts visā norādītajā lietojumprogrammas izstrādes posmā.
Noklikšķiniet uz tālāk esošās saites, lai iegūtu pilnīgu informāciju par vienību testēšanu: https://www.javatpoint.com/unit-testing.
2. Integrācijas pārbaude
Kad būsim veiksmīgi ieviesuši vienību testēšanu, mēs sāksim integrācijas testēšanu . Tas ir otrais funkcionālās pārbaudes līmenis, kurā mēs pārbaudām datu plūsmu starp atkarīgiem moduļiem vai saskarni starp divām funkcijām sauc. integrācijas testēšana .
Integrācijas testēšanas mērķis ir pārbaudīt paziņojuma precizitāti starp katru moduli.
Integrācijas testēšanas veidi
Integrācijas testēšana ir arī sadalīta šādās daļās:
Inkrementālās integrācijas pārbaude
Ja starp moduļiem ir skaidra saistība, mēs veicam pakāpeniskas integrācijas testēšanu. Pieņemsim, ka mēs ņemam divus moduļus un analizējam datu plūsmu starp tiem, vai tie darbojas labi vai nē.
Ja šie moduļi darbojas labi, mēs varam pievienot vēl vienu moduli un pārbaudīt vēlreiz. Un mēs varam turpināt to pašu procesu, lai iegūtu labākus rezultātus.
Citiem vārdiem sakot, mēs varam teikt, ka moduļu pakāpeniska saskaitīšana un datu plūsmas pārbaude starp moduļiem ir pazīstama kā Inkrementālās integrācijas pārbaude .
kas ir ymail
Inkrementālās integrācijas pārbaudes veidi
Inkrementālās integrācijas testēšanu var iedalīt divās daļās, kas ir šādas:
Apskatīsim īsu ievadu par šiem integrācijas testēšanas veidiem:
1. No augšas uz leju pakāpeniskā integrācijas pārbaude
Šajā pieejā mēs pievienosim moduļus soli pa solim vai pakāpeniski un pārbaudīsim datu plūsmu starp tiem. Mums ir jānodrošina, lai pievienotie moduļi būtu tādi agrāko bērnu bērns .
2. Augšupēja pakāpeniskā integrācijas pārbaude
Izmantojot augšupēju pieeju, mēs pakāpeniski pievienosim moduļus un pārbaudīsim datu plūsmu starp moduļiem. Un arī pārliecinieties, ka modulis, ko pievienojam, ir vecāks no agrākajiem .
Neinkrementālās integrācijas pārbaude/Lielā sprādziena metode
Ikreiz, kad datu plūsma ir sarežģīta un ļoti grūti klasificēt vecākus un bērnus, mēs izmantosim nepakāpeniskas integrācijas pieeju. Neinkrementālā metode ir pazīstama arī kā Lielā sprādziena metode .
Lai iegūtu pilnīgu informāciju par integrācijas testēšanu un tās veidu, skatiet šo saiti: https://www.javatpoint.com/integration-testing.
3. Sistēmas pārbaude
Ikreiz, kad esam pabeiguši vienības un integrācijas testēšanu, mēs varam turpināt sistēmas testēšanu.
Sistēmas testēšanā testa vide ir paralēla ražošanas videi. Tas ir pazīstams arī kā no gala līdz galam testēšana.
Šāda veida testēšanā mēs veiksim katru programmatūras atribūtu un pārbaudīsim, vai gala funkcija darbojas atbilstoši biznesa prasībām. Un analizējiet programmatūras produktu kā pilnīgu sistēmu.
Noklikšķiniet uz tālāk esošās saites, lai iegūtu pilnīgu informāciju par sistēmas testēšanu: https://www.javatpoint.com/system-testing.
Nefunkcionāla pārbaude
Nākamā melnās kastes testēšanas daļa ir nefunkcionāla pārbaude . Tajā ir sniegta detalizēta informācija par programmatūras produkta veiktspēju un izmantotajām tehnoloģijām.
Nefunkcionālā testēšana mums palīdzēs samazināt programmatūras ražošanas risku un ar to saistītās izmaksas.
Nefunkcionālā pārbaude ir kombinācija veiktspējas, slodzes, stresa, lietojamības un saderības pārbaude .
Lai iegūtu papildinformāciju par nefunkcionālo testēšanu, skatiet šo saiti: https://www.javatpoint.com/non-functional-testing.
Nefunkcionālās pārbaudes veidi
Nefunkcionālā testēšana ir iedalīta dažādās testēšanas daļās, kuras mēs apspriedīsim tālāk:
1. Veiktspējas pārbaude
Veiktspējas pārbaudē testa inženieris pārbaudīs lietojumprogrammas darbību, pieliekot zināmu slodzi.
Šāda veida nefunkcionālajā testēšanā testa inženieris koncentrēsies tikai uz vairākiem aspektiem, piemēram Reakcijas laiks, slodze, mērogojamība un stabilitāte programmatūras vai lietojumprogrammas.
Veiktspējas testēšanas klasifikācija
Veiktspējas testēšanā ietilpst dažādi testēšanas veidi, kas ir šādi:
Veicot veiktspējas testēšanu, mēs pieliksim zināmu slodzi konkrētajai lietojumprogrammai, lai pārbaudītu lietojumprogrammas veiktspēju, ko sauc par slodzes pārbaude . Šeit slodze varētu būt mazāka par vēlamo slodzi vai vienāda ar to.
Tas mums palīdzēs noteikt programmatūras lielāko darbības apjomu un vājās vietas.
Lai iegūtu pilnīgu informāciju par slodzes pārbaudi, skatiet tālāk norādīto saiti:
https://www.javatpoint.com/load-testing.
To izmanto, lai analizētu programmatūras lietotājam draudzīgumu un robustumu, kas pārsniedz kopējās funkcionālās robežas.
Galvenokārt stresa testēšanu izmanto kritiskai programmatūrai, taču to var izmantot arī visu veidu programmatūras lietojumprogrammām.
Lai iegūtu padziļinātas zināšanas par stresa testēšanu, skatiet tālāk norādīto saiti: https://www.javatpoint.com/stress-testing.
Lai analizētu, lietojumprogrammas veiktspēja, palielinot vai samazinot slodzi noteiktos līdzsvaros, ir pazīstama kā mērogojamības pārbaude .
Mērogojamības pārbaudē mēs varam arī pārbaudīt sistēmas, procesu vai datu bāzes iespējas lai apmierinātu augšupejošu vajadzību. Un šajā, Pārbaudes gadījumi ir izstrādāti un efektīvi īstenoti.
Noklikšķiniet uz šīs saites, lai iegūtu detalizētu informāciju par mērogojamības testēšanu:
https://www.javatpoint.com/scalability-testing.
Stabilitātes pārbaude ir procedūra, kurā mēs novērtējam lietojumprogrammas veiktspēju, pieliekot slodzi uz noteiktu laiku.
Tas galvenokārt pārbauda lietojumprogrammas noturības problēmas un izstrādātā produkta efektivitāti. Šāda veida testēšanā mēs varam ātri atrast sistēmas defektu pat stresa situācijā.
Lai iegūtu detalizētu informāciju par stabilitātes pārbaudi, skatiet tālāk norādīto saiti:
https://www.javatpoint.com/stability-testing.
2. Lietojamības pārbaude
Cits veids nefunkcionāla pārbaude ir lietojamības pārbaude . Lietojamības testēšanā mēs analizēsim lietojumprogrammas lietotājam draudzīgumu un atklāsim kļūdas programmatūras galalietotāja saskarnē.
Lūk, termins lietotājam draudzīgums definē šādus pieteikuma aspektus:
- Lietojumprogrammai jābūt viegli saprotamai, kas nozīmē, ka visām funkcijām jābūt redzamām galalietotājiem.
- Lietojumprogrammas izskatam un darbībai ir jābūt labam, kas nozīmē, ka lietojumprogrammai ir jāizskatās patīkami, un tiešajam lietotājam vajadzētu to lietot.
Lai iegūtu papildinformāciju par lietojamības testēšanu, mēs varam izmantot šo saiti:
https://www.javatpoint.com/usability-testing.
3. Saderības pārbaude
Saderības testēšanā mēs pārbaudīsim lietojumprogrammas funkcionalitāti noteiktās aparatūras un programmatūras vidēs. Tikai tad, kad lietojumprogramma ir funkcionāli stabila, mēs turpināsim saderības pārbaude .
Šeit, programmatūra nozīmē, ka mēs varam pārbaudīt lietojumprogrammu dažādās operētājsistēmās un citās pārlūkprogrammās, un aparatūra nozīmē, ka mēs varam pārbaudīt lietojumprogrammu dažādos izmēros.
Lai iegūtu pamatīgas zināšanas par saderības testēšanu, skatiet tālāk norādīto saiti:
https://www.javatpoint.com/compatibility-testing .
Pelēkās kastes pārbaude
Vēl viena daļa no manuāla pārbaude ir Pelēkās kastes testēšana . Tas ir melnās kastes un baltās kastes testēšanas sadarbība .
Tā kā pelēkās kastes testēšana ietver piekļuvi iekšējai kodēšanai testa gadījumu izstrādei. Pelēkās kastes testēšanu veic persona, kas zina gan kodēšanu, gan testēšanu.
Citiem vārdiem sakot, mēs varam teikt, ka, ja viena cilvēka komanda izdarīja abus baltās kastes un melnās kastes testēšana , tiek uzskatīts pelēkās kastes pārbaude .
Lai iegūtu detalizētu informāciju par Grey box testēšanu, mēs varam atsaukties uz tālāk esošo saiti:
https://www.javatpoint.com/grey-box-testing.
Automatizācijas pārbaude
Programmatūras testēšanas nozīmīgākā daļa ir automatizācijas testēšana. Tas izmanto īpašus rīkus, lai automatizētu manuālas projektēšanas pārbaudes gadījumus bez cilvēka iejaukšanās.
java concat virknes
Automatizācijas testēšana ir labākais veids, kā uzlabot programmatūras testēšanas efektivitāti, produktivitāti un pārklājumu.
To izmanto, lai atkārtoti palaistu pārbaudes scenārijus, kas tika izpildīti manuāli, ātri un atkārtoti.
Citiem vārdiem sakot, mēs varam teikt, ka ikreiz, kad mēs testējam lietojumprogrammu, izmantojot dažus rīkus, sauc par automatizācijas testēšana .
Mēs dosimies uz automatizācijas testēšanu, kad lietojumprogrammai vai programmatūrai tiks veikti dažādi laidieni vai vairāki regresijas cikli. Mēs nevaram uzrakstīt testa skriptu vai veikt automatizācijas testēšanu, nesaprotot programmēšanas valodu.
Lai iegūtu papildinformāciju par automatizācijas testēšanu, mēs varam skatīt tālāk norādīto saiti:
https://www.javatpoint.com/automation-testing.
Daži citi programmatūras testēšanas veidi
Programmatūras testēšanā mums ir arī daži citi testēšanas veidi, kas neietilpst nevienā iepriekš apspriestajā testēšanā, taču šī pārbaude ir nepieciešama, testējot jebkuru programmatūru vai lietojumprogrammu.
Izpratīsim šos testēšanas veidus pa vienam:
In dūmu pārbaude , mēs pārbaudīsim lietojumprogrammas pamata un kritiskās funkcijas pirms vienas padziļinātas un stingras testēšanas kārtas.
Or pirms visu iespējamo pozitīvo un negatīvo vērtību pārbaudes ir pazīstama kā dūmu pārbaude . Dūmu pārbaudes veikšanas galvenais mērķis ir lietojumprogrammas pamatfunkciju un galveno funkciju darbplūsmas analīze.
Lai iegūtu papildinformāciju par dūmu pārbaudi, skatiet šo saiti:
https://www.javatpoint.com/smoke-testing.
Saprāta pārbaude
To izmanto, lai nodrošinātu, ka visas kļūdas ir novērstas un šo izmaiņu dēļ nerodas nekādas papildu problēmas. Saprāta pārbaude ir bez skripta, kas nozīmē, ka mēs to nevaram dokumentēt. Tas pārbauda tikko pievienoto līdzekļu un komponentu pareizību.
Lai iegūtu detalizētu informāciju par saprāta pārbaudēm, mēs varam atsaukties uz tālāk norādīto saiti:
https://www.javatpoint.com/sanity-testing.
Regresijas pārbaude
Regresijas testēšana ir visizplatītākais programmatūras testēšanas veids. Lūk, termins regresija nozīmē, ka mums ir atkārtoti jāpārbauda neskartās lietojumprogrammas daļas.
Regresijas testēšana ir vispiemērotākā automatizācijas rīku pārbaude. Atkarībā no projekta veida un resursu pieejamības regresijas pārbaude var būt līdzīga Atkārtota pārbaude .
Ikreiz, kad izstrādātāji izlabo kļūdu un pēc tam pārbauda citas lietojumprogrammu funkcijas, kuras varētu tikt simulētas kļūdu labošanas dēļ, tiek sauktas par regresijas pārbaude .
Citiem vārdiem sakot, mēs varam teikt, ka ikreiz, kad kādam projektam ir jauns laidiens, mēs varam veikt regresijas testēšanu, un jaunas funkcijas dēļ tas var ietekmēt vecās funkcijas iepriekšējos laidienos.
Lai iegūtu pamatīgas zināšanas par regresijas testēšanu, skatiet tālāk norādīto saiti:
https://www.javatpoint.com/regression-testing .
Lietotāju pieņemšanas pārbaude
Lietotāja pieņemšanas testēšanu (UAT) veic atsevišķa komanda, kas pazīstama kā domēna eksperts/klients vai klients. Un zinot pieteikumu pirms gala produkta pieņemšanas sauc par lietotāja pieņemšanas pārbaude .
Lietotāju pieņemšanas testēšanā mēs analizējam biznesa scenārijus un reāllaika scenārijus atsevišķā vidē, ko sauc par UAT vide . Šajā testēšanā mēs pārbaudīsim lietojumprogrammu pirms UAI, lai saņemtu klienta apstiprinājumu.
Lai iegūtu papildinformāciju par lietotāja pieņemšanas testu, noklikšķiniet uz tālāk esošās saites:
https://www.javatpoint.com/acceptance-testing.
Izpētes pārbaude
Ikreiz, kad prasības nav, ir nepieciešama agrīna iterācija, un testēšanas komandai ir pieredzējuši testētāji, ja mums ir svarīga lietojumprogramma. Komandā iestājās jauns testa inženieris, tad mēs ejam uz pētnieciskā pārbaude .
Lai veiktu pētniecisko testēšanu, mēs vispirms iziesim cauri lietojumprogrammai visos iespējamos veidos, izveidosim testa dokumentu, izpratīsim lietojumprogrammas plūsmu un pēc tam pārbaudīsim lietojumprogrammu.
Noklikšķiniet uz šīs saites, lai iegūtu pilnīgu informāciju par izpētes testēšanu:
https://www.javatpoint.com/exploratory-testing.
Adhoc testēšana
Lietojumprogrammas testēšana nejauši, tiklīdz būvēšana ir pārbaudītajā secībā, ir pazīstama kā Adhoc testēšana .
To sauc arī Pērtiķu pārbaude un Gorilla testēšana . Adhoc testēšanā mēs pārbaudīsim pieteikumu pretrunā ar klienta prasībām; tāpēc to sauc arī par negatīva pārbaude .
Kad galalietotājs nejauši izmanto lietojumprogrammu, un viņš/viņa var atklāt kļūdu. Tomēr specializētais testēšanas inženieris rūpīgi izmanto programmatūru, tāpēc viņš/viņa var neatpazīt līdzīgu atklāšanu.
Lai iegūtu detalizētu informāciju par Adhoc testēšanu, skatiet tālāk sniegto informāciju.
java hasnext
https://www.javatpoint.com/adhoc-testing.
Drošības pārbaude
Tā ir būtiska programmatūras testēšanas sastāvdaļa, ko izmanto, lai noteiktu programmatūras lietojumprogrammas vājās vietas, riskus vai draudus.
Drošības testu veikšana palīdzēs mums izvairīties no nepatīkamiem uzbrukumiem no nepiederošām personām un nodrošinās mūsu programmatūras lietojumprogrammu drošību.
Citiem vārdiem sakot, var teikt, ka drošības testēšana galvenokārt tiek izmantota, lai noteiktu, vai dati būs droši un izturēs programmatūras darba procesu.
Lai iegūtu pilnīgu informāciju par drošības testēšanu, skatiet tālāk norādīto saiti: https://www.javatpoint.com/security-testing.
Globalizācijas pārbaude
Cits programmatūras testēšanas veids ir Globalizācijas testēšana. Globalizācijas testēšana tiek izmantota, lai pārbaudītu izstrādāto programmatūru vairākās valodās vai nē. Lūk, vārdi globalizācija nozīmē lietojumprogrammas vai programmatūras apgaismošanu dažādās valodās.
Globalizācijas testēšana tiek izmantota, lai pārliecinātos, ka lietojumprogramma atbalstīs vairākas valodas un vairākas funkcijas.
Pašreizējos scenārijos mēs varam redzēt uzlabojumus vairākās tehnoloģijās, jo lietojumprogrammas ir sagatavotas lietošanai visā pasaulē.
Lai iegūtu pilnīgu informāciju par globalizācijas testēšanu, skatiet šo saiti:
https://www.javatpoint.com/globalization-testing.
Secinājums
Apmācībā mēs esam apsprieduši dažādus programmatūras testēšanas veidus. Bet joprojām ir saraksts ar vairāk nekā 100+ testēšanas kategorijām. Tomēr katrs testēšanas veids netiek izmantots visu veidu projektos.
Mēs esam apsprieduši visbiežāk izmantotos programmatūras testēšanas veidus, piemēram melnās kastes testēšana, baltās kastes testēšana, funkcionālā pārbaude, nefunkcionālā pārbaude, regresijas pārbaude, Adhoc testēšana utt. .
Ir arī alternatīvas klasifikācijas vai procesi, ko izmanto dažādās organizācijās, taču vispārējā koncepcija ir līdzīga visur.
Šie testēšanas veidi, procesi un izpildes pieejas turpina mainīties, kad mainās projekts, prasības un darbības joma.