Manuālā testēšana ir programmatūras testēšanas process, kurā testa gadījumi tiek izpildīti manuāli, neizmantojot nevienu automatizētu rīku. Visas pārbaudes lietas, ko testētājs veic manuāli atbilstoši gala lietotāja perspektīvai. Tas nodrošina, vai lietojumprogramma darbojas, kā minēts prasības dokumentā. Testa gadījumi ir plānoti un ieviesti, lai pabeigtu gandrīz 100 procentus no lietojumprogrammas. Pārbaudes gadījumu pārskati tiek ģenerēti arī manuāli.

Manuālā testēšana ir viens no vissvarīgākajiem testēšanas procesiem, jo ​​tā var atrast gan redzamus, gan slēptus programmatūras defektus. Programmatūras norādītā atšķirība starp paredzamo izvadi un izvadi tiek definēta kā defekts. Izstrādātājs novērsa defektus un nodeva testētājam atkārtotai pārbaudei.

Manuāla pārbaude ir obligāta katrai jaunizveidotajai programmatūrai pirms automatizētās testēšanas. Šī pārbaude prasa lielas pūles un laiku, taču tā nodrošina programmatūru bez kļūdām. Manuālajai testēšanai ir nepieciešamas zināšanas par manuālās testēšanas paņēmieniem, bet ne par jebkuru automatizētu testēšanas rīku.

Manuāla pārbaude ir būtiska, jo viens no programmatūras testēšana pamatprincips ir '100% automatizācija nav iespējama.'

Kāpēc mums nepieciešama manuāla pārbaude

Ikreiz, kad tirgū nonāk kāda lietojumprogramma un tā ir nestabila vai tajā ir kļūda vai problēmas vai rodas problēmas, kamēr galalietotāji to izmanto.

Ja nevēlamies saskarties ar šāda veida problēmām, mums ir jāveic viena testēšanas kārta, lai lietojumprogramma būtu brīva un stabila un piegādātu klientam kvalitatīvu produktu, jo, ja lietojumprogramma ir bez kļūdām, gala lietotājs izmantos aplikāciju ērtāk.

Ja testēšanas inženieris veic manuālu testēšanu, viņš/viņa var pārbaudīt lietojumprogrammu kā galalietotāja skatījumu un vairāk iepazīties ar produktu, kas palīdz viņiem uzrakstīt pareizos lietojumprogrammas testēšanas gadījumus un sniegt ātru atsauksmi par lietojumprogrammu.

Manuālās pārbaudes veidi

Manuālai pārbaudei tiek izmantotas dažādas metodes. Katra tehnika tiek izmantota atbilstoši tās pārbaudes kritērijiem. Manuālās pārbaudes veidi ir norādīti zemāk:

• Baltās kastes pārbaude
• Melnās kastes pārbaude
• Pelēkās kastes pārbaude

Baltās kastes pārbaude

Baltās kastes testēšanu veic izstrādātājs, pārbaudot katru koda rindiņu pirms tā nodošanas testēšanas inženierim. Tā kā kods ir redzams izstrādātājam testēšanas laikā, tāpēc to sauc arī par baltās kastes testēšanu.

Lai iegūtu papildinformāciju par baltās kastes testēšanu, skatiet tālāk norādīto saiti:

https://www.javatpoint.com/white-box-testing

Melnās kastes pārbaude

Melnās kastes testēšanu veic testēšanas inženieris, kurā var pārbaudīt lietojumprogrammas vai programmatūras funkcionalitāti atbilstoši klienta/klienta vajadzībām. Šajā gadījumā kods nav redzams, veicot testēšanu; tāpēc to sauc par melnās kastes testēšanu.

Lai iegūtu papildinformāciju par melnās kastes testēšanu, skatiet tālāk norādīto saiti:

https://www.javatpoint.com/black-box-testing

Grey Box testēšana

Pelēkās kastes testēšana ir baltās kastes un melnās kastes testēšanas kombinācija. To var veikt cilvēks, kurš zināja gan kodēšanu, gan testēšanu. Un, ja viena persona veic baltās kastes, kā arī melnās kastes testēšanu lietojumprogrammai, to sauc par pelēkās kastes testēšanu.

Lai iegūtu sīkāku informāciju par pelēkās kastes testēšanu, skatiet tālāk norādīto saiti:

https://www.javatpoint.com/grey-box-testing

Kā veikt manuālo testēšanu

• Pirmkārt, testētājs novēro visus ar programmatūru saistītos dokumentus, lai izvēlētos testēšanas apgabalus.
• Testētājs analizē prasību dokumentus, lai aptvertu visas klienta norādītās prasības.
• Testētājs izstrādā testa gadījumus atbilstoši prasību dokumentam.
• Visi testa gadījumi tiek izpildīti manuāli, izmantojot melnās kastes testēšanu un baltās kastes testēšanu.
• Ja radušās kļūdas, testēšanas komanda informē izstrādes komandu.
• Izstrādes komanda izlabo kļūdas un nodod programmatūru testēšanas komandai atkārtotai pārbaudei.

Programmatūras izveides process

• Kad prasība ir apkopota, tā tiks nodrošināta divām dažādām komandu izstrādes un testēšanas komandām.
• Pēc prasības saņemšanas attiecīgais izstrādātājs sāks rakstīt kodu.
• Un tikmēr testēšanas inženieris saprot prasību un sagatavo nepieciešamos dokumentus, līdz šim izstrādātājs var aizpildīt kodu un uzglabāt Kontroles versijas rīks .
• Pēc tam kods mainās lietotāja saskarnē, un šīs izmaiņas apstrādā viena atsevišķa komanda, kas ir pazīstama kā veidot komandu .
• Šī izveides komanda paņems kodu un sāks tā kompilēšanu un saspiešanu, izmantojot veidošanas rīku. Kad esam ieguvuši kādu izvadi, izvade nonāk zip failā, kas ir pazīstams kā Būvēt (lietojumprogramma vai programmatūra). Katrai būvei būs kāds unikāls numurs, piemēram, (B001, B002).
• Pēc tam šī konkrētā Build tiks instalēta testa serverī. Pēc tam testa inženieris piekļūs šim testa serverim ar testa URL palīdzību un sāks lietojumprogrammas testēšanu.
• Ja testēšanas inženieris atklāj kļūdu, viņš/viņa par to tiks informēts attiecīgajam izstrādātājam.
• Pēc tam izstrādātājs reproducēs kļūdu testa serverī un izlabos kļūdu un atkal saglabās kodu kontroles versijas rīkā, un tas instalēs jauno atjaunināto failu un noņems veco failu; šis process tiek turpināts, līdz mēs iegūstam stabilu Build.
• Kad būsim ieguvuši stallis Build, tas tiks nodots klientam.

Piezīme1

• Kad mēs apkoposim failu no vadības versijas rīka, mēs izmantosim veidošanas rīku, lai apkopotu kodu no augsta līmeņa valodas uz mašīnas līmeņa valodu. Pēc kompilācijas, ja faila lielums palielināsies, mēs saspiedīsim konkrēto failu un ievietosim testa serverī.
• Šo procesu veic Veidojiet komandu , izstrādātājs (ja izveides komandas nav, to var izdarīt izstrādātājs) vai testa vads (ja izveides komanda tieši apstrādā zip un instalē lietojumprogrammu testa serverī un informē testa inženieri).
• Parasti mēs nevaram iegūt jaunu Build katrai kļūdai; pretējā gadījumā lielākā daļa laika tiks tērēta tikai būvju veidošanai.

2. piezīme

Veidojiet komandu

Veidošanas komandas galvenais darbs ir lietojumprogrammas vai Build izveide un augsta līmeņa valodas konvertēšana zema līmeņa valodā.

Būvēt

Tā ir programmatūra, ko izmanto, lai pārvērstu kodu lietojumprogrammas formātā. Un tas sastāv no dažām funkcijām un kļūdu labojumiem, kas tiek nodoti testēšanas inženierim testēšanas nolūkos, līdz tas kļūst stabils.

Kontroles versijas rīks

Tā ir programmatūra vai lietojumprogramma, kas tiek izmantota šādiem mērķiem:

• Šajā rīkā mēs varam saglabāt dažāda veida failus.
• Tas vienmēr ir aizsargāts, jo mēs piekļūstam failam no rīkiem, izmantojot tos pašus pieteikšanās akreditācijas datus.
• Rīku galvenais mērķis ir izsekot esošajos failos veiktajām izmaiņām.

Veidošanas procesa piemērs

Apskatiet vienu piemēru, lai saprastu, kā veidot procesa darbu reālos scenārijos:

Tiklīdz testēšanas inženieris saņem kļūdu, viņš to nosūtīs izstrādātājiem, un viņiem ir nepieciešams laiks, lai analizētu; pēc tam viņš/viņa tikai izlabo kļūdu (Testēšanas inženieris nevar sniegt kļūdu kolekciju).

Izstrādātājs izlemj, cik kļūdu viņš var labot atbilstoši viņu laikam. Un testēšanas inženieris ir nolemts, kura kļūda ir jāizlabo vispirms atbilstoši viņu vajadzībām, jo ​​testa inženieri nevar atļauties pārtraukt testēšanu.

Un testa inženieris, kurš saņem pastu, var zināt tikai to, kuru kļūdu ir izlabojis kļūdu labojumu saraksts .

Laiks palielināsies, jo pirmajā Build un izstrādātājiem vajadzētu rakstīt kodu dažādās funkcijās. Un beigās viņš/viņa var veikt tikai kļūdu labojumus, un dienu skaits tiks samazināts.

3. piezīme

Pārbaudes cikls

Testa cikls ir laika ilgums, kas testa inženierim ir dots katras konstrukcijas testēšanai.

Atšķirības starp abām konstrukcijām

Kļūdas, kas atrastas vienā būvējumā, un tās var novērst jebkurā no turpmākajām būvēm, kas ir atkarīgas no testētāja prasībām. Katra jauna Build ir modificēta vecā versija, un šīs modifikācijas var būt kļūdu labojumi vai jaunu funkciju pievienošana.

Cik bieži mēs saņēmām jauno Build

Sākumā mēs saņēmām iknedēļas būvējumus, bet jaunākajā testēšanas posmā, kad lietojumprogramma kļuva stabila, mēs izmantojām jauno Build reizi 3 dienās, divās dienās vai arī katru dienu.

Cik daudz būvju mēs iegūstam

Ja ņemam vērā vienu gadu no jebkura projekta ilguma, mēs saņēmām 22–26 būves.

Kad saņemsim kļūdu labojumus

Parasti mēs saprotam kļūdu labojumus tikai pēc tam, kad ir pabeigts testa cikls vai kļūdu kolekcija ir novērsta vienā būvējumā un nodošana nākamajās versijās.

Manuālās testēšanas priekšrocības

• Lietojot Black box metodi, tam nav nepieciešamas programmēšanas zināšanas.
• To izmanto, lai pārbaudītu dinamiski mainīgos GUI dizainus.
• Testētājs mijiedarbojas ar programmatūru kā īsts lietotājs, lai viņi varētu atklāt lietojamības un lietotāja saskarnes problēmas.
• Tas nodrošina, ka programmatūra ir simtprocentīgi bez kļūdām.
• Tas ir rentabls.
• Viegli iemācīties jauniem testētājiem.

Manuālās testēšanas trūkumi

• Tas prasa lielu skaitu cilvēkresursu.
• Tas ir ļoti laikietilpīgi.
• Testētājs izstrādā testa gadījumus, pamatojoties uz savām prasmēm un pieredzi. Nav pierādījumu, ka tie ir aptvēruši visas funkcijas vai nē.
• Pārbaudes gadījumus nevar izmantot atkārtoti. Katrai jaunai programmatūrai jāizstrādā atsevišķi testa gadījumi.
• Tas nenodrošina testēšanu visos testēšanas aspektos.
• Tā kā divas komandas strādā kopā, reizēm ir grūti saprast vienam otra motīvus, tas var maldināt procesu.

Manuālie testēšanas rīki

Manuālajā testēšanā, dažāda veida testēšanā, piemēram, vienību, integrācijas, drošības, veiktspējas un kļūdu izsekošanas laikā, mums ir pieejami dažādi rīki, piemēram, Jira , Bugzilla , Mantis, Zap, NUnit, Tessy, LoadRunner, Citrus, SonarQube utt. tirgus. Daži no rīkiem ir atvērtā pirmkoda, un daži ir komerciāli.

Lai iegūtu papildinformāciju par testēšanas rīkiem, skatiet tālāk norādīto saiti:

https://www.javatpoint.com/software-testing-tools

Sapratīsim tos pa vienam:

kad iznāca Windows 7

LoadRunner

Tas ir visbiežāk izmantotie veiktspējas pārbaudes rīki. LoadRunner galvenokārt tiek izmantots, lai atbalstītu veiktspējas testēšanu plašam procedūru klāstam, pieeju skaitam un lietojumprogrammu vidēm.

LoadRunner rīka izpildes galvenais mērķis ir ātri klasificēt visbiežāk sastopamos veiktspējas problēmu avotus.

LoadRunner funkcijas

• LoadRunner rīks satur n-skaitu lietojumprogrammu, kas samazina laiku, lai saprastu un aprakstītu pārskatus.
• Mēs varam iegūt detalizētus veiktspējas testu pārskatus, izmantojot LoadRunner rīku.
• Tas samazinās sadalītās slodzes testēšanas izmaksas un piedāvās arī darbības rīku izvietošanas izsekošanai.

Citrusaugļi

Citrus ir integrācijas testēšanas rīks, kas ir visbiežāk izmantotā testa sistēma. Tas ir ierakstīts Java programmēšana valodu. To galvenokārt izmanto, lai pieprasītu un atbildētu uz servera un klienta puses, kā arī apstiprinātu XML JSON failus.

Lai veiktu pilnīgas lietošanas gadījumu testēšanu, citrusaugļi atbalsta vairākus HTTP, JMS un SOAP protokolus.

Citrusaugļu īpašības

Tālāk ir norādītas dažas no svarīgām Citrus rīka funkcijām:

• To izmanto, lai nosūtītu un saņemtu ziņas.
• Citrus ir pieejams gan kā atvērtā koda, gan kā licencēts tirgū.
• Tas nodrošina zemu izmaksu risinājumu.
• Mēs varam autentificēt datu bāzi, izmantojot citrusaugļu rīku.
• Tajā tiks aprakstīta ziņojumu secība, piedāvāts pārbaudes plāns un dokumentēts testa pārklājums.
• Tas izveido ziņojumu un pārbauda atbildes.

ZAP

ZAP ir atvērtā pirmkoda tīmekļa lietojumprogrammu drošības skeneris. Tas apzīmē Zed Attack starpniekserveris . Tāpat kā daži citi rīki, tas ir rakstīts arī JAVA programmēšanas valoda . Tas ir visefektīvākais Atveriet tīmekļa lietojumprogrammu drošības projektus [OWASP].

ZAP iezīmes

atzīmes pasvītrojums

• Tā atbalsta daudzas operētājsistēmas, piemēram, Windows, Linux, OS X.
• Tam ir uz spraudņiem balstīta arhitektūra.
• Tajā ir tiešsaistes tirgus, kas ļauj mums pievienot jaunas vai atjauninātas funkcijas.
• ZAP GUI vadības panelis ir viegli lietojams.

Mūķene

NUnit ir viens no visbiežāk izmantotajiem vienību testēšanas rīkiem. Tas ir atvērtā pirmkoda rīks un galvenokārt iegūts no JUnit .

Tas bija pilnībā uzrakstīts C# programmēšanas valoda un piemērots visiem .Tīkla valodas .

Citiem vārdiem sakot, mēs varam teikt, ka NUnit rīks ir pilnībā pārveidots, lai kļūtu par daudzu .Net valodas īpašību priekšrocību. Piemēram:

Ar refleksiju saistītas spējas. Citi pielāgoti atribūti.

NUnit īpašības

• Tas pieļauj apgalvojumus kā priekšrocību klases statisku metodi.
• Tas atbalsta uz datiem balstītus testus.
• Tā atbalsta vairākas platformas, piemēram, .NET core Xamarin mobile, Silverlight un efektīvu sistēmu.
• NUnit spēja palīdz mums veikt testus vienlaicīgi.
• Tas izmanto konsoles skrējēju, lai ielādētu un izpildītu testus.

JIRA

Visbiežāk izmantotais kļūdu izsekošanas rīks ir JIRA , kas ir atvērtā pirmkoda rīks. To izmanto kļūdu izsekošanai, projektu vadībai un problēmu izsekošanai.

Izmantojot šo rīku, mēs varam viegli izsekot visu veidu kļūdām vai defektiem, kas saistīti ar programmatūru un ko radījuši testēšanas inženieri.

JIRA iezīmes

• Tas ir laika taupīšanas rīks.
• Jira tiek izmantota, lai izsekotu defektiem un problēmām.
• To izmanto, lai noteiktu dokumentācijas uzdevumus.
• Jira ir ļoti noderīgs rīks, lai izsekotu mūsu dokumentācijas uzlabošanai.

Lai iegūtu pilnīgu informāciju par Jira rīku, skatiet tālāk norādīto saiti: https://www.javatpoint.com/jira-tutorial.

SonarQube

Vēl viens manuālās testēšanas testēšanas rīks ir SonarQube, kas uzlabo mūsu darbplūsmu ar nepārtrauktu koda kvalitāti un koda drošību. Tas ir elastīgs, izmantojot spraudņus.

Tas ir pilnībā uzrakstīts JAVA programmēšanas valodā. Tas piedāvā pilnībā automatizētu novērtēšanu un integrāciju ar Ant, Maven, Gradle, MSBuild un pastāvīgiem integrācijas rīkiem. SonarQube ir iespēja ierakstīt metrikas vēsturi un sniedz evolūcijas grafiku.

Sonarqube iezīmes

Tālāk ir norādītas dažas no svarīgākajām SonarQube rīka funkcijām.

• Tā atbalsta vairākas programmēšanas valodas, piemēram, C, C++, Python, JAVA, HTML, CSS, VB.NET, PHP, COBOL, PL/SQL utt.
• Saskaņā ar GNU Lesser General Public License Sonarqube ir brīvi pieejama.
• SonarQube ir saistīts ar dažiem svarīgiem ārējiem rīkiem, piemēram, GitHub, Active Directory, LDAP un citiem.
• SonarQube apvienojās ar Visual Studio, Eclipse un IntelliJ IDEA izstrādes vidēm, jo SonarLint spraudņi.

JMeter

JMeter ir atvērtā koda rīks, ko izmanto, lai pārbaudītu gan statisko, gan dinamisko resursu un dinamisko tīmekļa lietojumprogrammu veiktspēju.

Tas ir pilnībā izstrādāts JAVA lietojumprogrammai, lai ielādētu funkcionālās pārbaudes uzvedību un novērtētu lietojumprogrammas veiktspēju.

Tas ļauj lietotājiem vai izstrādātājiem izmantot pirmkodu citu lietojumprogrammu izstrādei.

JMeter funkcijas

Tālāk ir norādītas dažas no galvenajām JMeter īpašībām:

• Tas ir no platformas neatkarīgs, kas pieņem līdzīgu JVM Windows, Mac un Linux utt.
• Tā atbalsta lietotājam draudzīgu GUI, kas ir interaktīva un vienkārša.
• Veiktspējas testu ielādēšana vairāku veidu serveros ir neticami paplašināma.

Lai iegūtu papildinformāciju par JMeter, skatiet tālāk norādīto saiti:

https://www.javatpoint.com/jmeter-tutorial.

Ar Bugz

Vēl viens kļūdu izsekošanas rīks, ko izmanto manuālajā testēšanā, ir Ar Bugz .

To visplašāk izmanto daudzas organizācijas, lai izsekotu dažādām lietojumprogrammas kļūdām.

Bugzilla ir atvērtā koda rīks, kas palīdz klientam un klientam sekot līdzi defektiem. Bugzilla tiek uzskatīta arī par testa pārvaldības rīku, jo ar to mēs varam viegli saistīt citus testa gadījumu pārvaldības rīkus, piemēram, ALM, kvalitātes centru utt.

Bugzilla iezīmes

Bugzilla ir dažas papildu funkcijas, kas palīdz mums viegli ziņot par kļūdu:

• Tā atbalsta dažādas operētājsistēmas, piemēram, Windows, Linux un Mac.
• Ar Bugzilla palīdzību mēs varam uzskaitīt kļūdu vairākos formātos.
• Lietotāja preferences var novērtēt e-pasta paziņojumus.
• Bugzilla ir uzlabotas meklēšanas iespējas.

Mantis

Mantis ir tīmekļa kļūdu izsekošanas sistēma. ManitsBT apzīmē Mantis kļūdu izsekotājs . To izmanto programmatūras defektu izsekošanai un veic PHP programmēšanas valodā. Tas ir arī atvērtā koda rīks.

Mantis iezīmes

Dažas no konkrētā rīka standarta funkcijām ir šādas:

• Ar šī rīka palīdzību mums ir pieejama pilna teksta meklēšana.
• Problēmu izmaiņu audita pēdas.
• Tas nodrošina pārskatīšanas kontroles sistēmas integrāciju.
• Teksta lauku un piezīmju pārskatīšanas kontrole

Lai iegūtu plašāku informāciju par kļūdu izsekošanas rīkiem, skatiet šo saiti: https://www.javatpoint.com/defect-or-bug-tracking-tool .

Tesija

Vēl viens integrācijas testēšanas rīks ir Tesija , ko izmanto, lai veiktu iegultās programmatūras integrāciju un vienību testēšanu. Tas arī palīdz mums atklāt programmatūras vai lietojumprogrammas koda pārklājumu.

Tas var viegli pārvaldīt visu testēšanas organizāciju, tostarp biznesa vajadzības, testu pārvaldību, pārklājuma daudzumu un izsekojamību.

Tessy satur trīs galvenās funkcijas, kas ir šādas:

• Testa interfeisa redaktors (TIE)
• Testa datu redaktors (TDE)
• Darbvieta.

TESSY iezīmes

TESSY standarta funkcijas ir šādas:

• Tas sagatavo testa ziņojumu par testa izpildes rezultātiem.
• Tā atbalsta dažādas programmēšanas valodas, piemēram, C un C++.
• Tessy tiek izmantots, lai novērtētu funkcijas saskarni, un tas apraksta šīs funkcijas izmantoto mainīgo.

Lai iegūtu papildinformāciju par integrācijas testēšanas rīkiem, skatiet šo saiti: https://www.javatpoint.com/integration-testing-tools.

Pārskats

Šajā rakstā mēs esam redzējuši detalizētu informāciju par Manuālā testēšana, kas ietver manuālās testēšanas definīciju, manuālās testēšanas nepieciešamību, manuālās testēšanas veidu, manuālās testēšanas rīkus, manuālās testēšanas procesu un dažus svarīgus tā ieguvumus un trūkumus.

Visbeidzot, mēs varam teikt, ka tas ir process, kurā testa inženierim ir jābūt ļoti neatlaidīgam, novatoriskam un atsaucīgam.

Manuālajā testēšanā testa inženierim ir jādomā un jādarbojas kā galalietotāja interpretācijai.

Lai īstenotu manuālo testēšanu, testēšanas inženierim ir vajadzīgas produktīvas prasmes un iztēle. Un viņiem ir jādomā par vairākām situācijām vai scenārijiem, lai pārbaudītu konkrētu lietojumprogrammu.

Lai gan šobrīd ar automatizācijas testēšanas palīdzību varam pārbaudīt gandrīz visas lietojumprogrammas, tomēr manuālā testēšana ir nepieciešama, jo tā ir programmatūras testēšanas pamats.