FUNKCIONĀLĀ PĀRBAUDE - PROGRAMMATŪRAS TESTĒŠANA

Pirms pāriet uz funkcionālo testēšanu, mums būtu jāzina par testēšanu, kas ir testēšana?

Kas ir testēšana?

Vienkārši izsakoties, testēšana ir faktiskā rezultāta salīdzināšana ar paredzamo rezultātu. Testēšana tiek veikta, lai noteiktu, vai visas funkcijas darbojas kā paredzēts.

Kas ir programmatūras testēšana?

Programmatūras testēšana ir paņēmiens, lai pārbaudītu, vai faktiskais rezultāts atbilst sagaidāmajam, un lai pārliecinātos, ka programmatūrai nav defektu vai kļūdu.

Programmatūras testēšana nodrošina, ka lietojumprogrammai nav nekādu defektu vai prasības neatbilst faktiskajai nepieciešamībai. Programmatūras testēšanu var veikt manuāla vai automatizācijas testēšana.

Programmatūras testēšana tiek definēta arī kā testējamās lietojumprogrammas pārbaude (AUT).

Ir divu veidu pārbaudes:

Funkcionālā pārbaude:

Tas ir programmatūras testēšanas veids, ko izmanto, lai pārbaudītu lietojumprogrammas funkcionalitāti, vai funkcija darbojas saskaņā ar prasību specifikāciju. Funkcionālajā testēšanā katra funkcija tiek pārbaudīta, norādot vērtību, nosakot izvadi un pārbaudot faktisko izvadi ar paredzamo vērtību. Funkcionālā pārbaude tiek veikta kā melnās kastes testēšana, kas tiek parādīta, lai apstiprinātu, ka lietojumprogrammas vai sistēmas funkcionalitāte darbojas, kā mēs sagaidām. Tas tiek darīts, lai pārbaudītu lietojumprogrammas funkcionalitāti.

Funkcionālo testēšanu sauc arī par melnās kastes testēšanu, jo tā koncentrējas uz lietojumprogrammas specifikāciju, nevis uz faktisko kodu. Testētājam ir jāpārbauda tikai programma, nevis sistēma.

Funkcionālās pārbaudes mērķis

Funkcionālās pārbaudes mērķis ir pārbaudīt primāro ievades funkciju, obligāti lietojamo funkciju, ekrāna GUI plūsmu. Funkcionālā pārbaude parāda kļūdas ziņojumu, lai lietotājs varētu viegli pārvietoties visā lietojumprogrammā.

Kāds ir funkcionālās pārbaudes process?

Funkcionālajā pārbaudē testētāji veic šādas darbības:

Testētājs lietojumprogrammā pārbauda prasību specifikāciju.
Pēc analīzes prasību specifikācijas testētājs sastādīs plānu.
Pēc testu plānošanas testētājs izstrādās testa gadījumu.
Pēc testa izstrādes gadījuma testētājs izveidos izsekojamības matricas dokumentu.
Testētājs izpildīs testa gadījuma dizainu.
Aptvēruma analīze, lai pārbaudītu lietojumprogrammas aptverto testēšanas apgabalu.
Defektu pārvaldība jāveic, lai pārvaldītu defektu novēršanu.

Ko pārbaudīt funkcionālajā testēšanā? Paskaidrojiet

Funkcionālās pārbaudes galvenais mērķis ir programmatūras sistēmas funkcionalitātes pārbaude. Tas koncentrējas uz:

Pamata lietojamība:Funkcionālā pārbaude ietver sistēmas lietojamības pārbaudi. Tā pārbauda, vai lietotājs var brīvi un bez grūtībām pārvietoties pa ekrāniem.Pieejamība:Funkcionālā pārbaude pārbauda funkcijas pieejamību.Galvenās līnijas funkcija:Tas koncentrējas uz galvenās funkcijas pārbaudi.Kļūdas stāvoklis:Funkcionālā pārbaude tiek izmantota, lai pārbaudītu kļūdas stāvokli. Tas pārbauda, vai tiek parādīts kļūdas ziņojums.

Izskaidrojiet visu funkcionālās pārbaudes veikšanas procesu.

Lai veiktu funkcionālo pārbaudi, ir jāveic šādas darbības:

Ir jāsaprot programmatūras prasības.
Identificējiet testa ievades datus
Aprēķiniet paredzamo rezultātu ar atlasītajām ievades vērtībām.
Izpildīt pārbaudes gadījumus
Salīdzinājums starp faktisko un aprēķināto rezultātu

Izskaidrojiet funkcionālās pārbaudes veidus.

Funkcionālās pārbaudes galvenais mērķis ir pārbaudīt komponenta funkcionalitāti.

Funkcionālā pārbaude ir sadalīta vairākās daļās.

Šeit ir norādīti šādi funkcionālās pārbaudes veidi.

Vienības pārbaude: vienību pārbaude ir programmatūras testēšanas veids, kurā tiek pārbaudīta atsevišķa programmatūras vienība vai komponents. Vienības testēšana, pārbaudīt dažādas lietojumprogrammas daļas, ar vienību testēšanu veikta arī funkcionālā pārbaude, jo vienības testēšana nodrošina, ka katrs modulis darbojas pareizi.

Izstrādātājs veic vienību testēšanu. Vienību testēšana tiek veikta lietojumprogrammas izstrādes fāzē.

Dūmu pārbaude: funkcionālā pārbaude ar dūmu pārbaudi. Dūmu pārbaude ietver tikai sistēmas pamata (funkciju) funkcionalitāti. Dūmu testēšana ir pazīstama kā ' Būvējuma verifikācijas pārbaude .' Dūmu pārbaudes mērķis ir nodrošināt vissvarīgāko funkciju darbību.

Piemēram, dūmu testēšana pārbauda, vai lietojumprogramma tiek palaists veiksmīgi, pārbaudīs, vai GUI ir atsaucīga.

Saprāta pārbaude: Saprāta pārbaude ietver visu augsta līmeņa biznesa scenāriju, kas darbojas pareizi. Saprāta pārbaude tiek veikta, lai pārbaudītu funkcionalitāti / izlabotās kļūdas. Saprāta pārbaude ir tikai neliela attīstība nekā dūmu pārbaude.

Piemēram, pieteikšanās darbojas labi; visas pogas darbojas pareizi; pēc noklikšķināšanas uz pogas navigācija lapā ir pabeigta vai nē.

Regresijas pārbaude: Šāda veida testēšana koncentrējas, lai pārliecinātos, ka koda izmaiņām nevajadzētu negatīvi ietekmēt sistēmas esošo funkcionalitāti. Regresijas testēšana norāda, kad pēc kļūdas novēršanas sistēmā rodas kļūda, regresijas testēšana koncentrējas uz to, vai visas daļas darbojas vai nē. Regresijas testēšana koncentrējas uz to, vai ir kāda ietekme uz sistēmu.

Integrācijas pārbaude: integrācijas pārbaude apvienotas atsevišķas vienības un pārbaudītas kā grupa. Šīs pārbaudes mērķis ir atklāt traucējumus mijiedarbībā starp integrētajām vienībām.

Izstrādātāji un testētāji veic integrācijas testēšanu.

Baltās kastes testēšana: Baltās kastes testēšana ir pazīstama kā Clear Box testēšana, uz kodu balstīta pārbaude, strukturālā pārbaude, plaša pārbaude un stikla kastes testēšana, caurspīdīgās kastes testēšana. Tā ir programmatūras testēšanas metode, kurā testētājam ir zināma iekšējā struktūra/dizains/ieviešana.

Baltās kastes testēšanai nepieciešama komponenta vai sistēmas iekšējās struktūras analīze.

string.valueof java

Melnās kastes pārbaude: To sauc arī par uzvedības testēšanu. Šajā testēšanā iekšējā struktūra/dizains/ieviešana testētājam nav zināma. Šis pārbaudes veids ir funkcionālā pārbaude. Kāpēc mēs nosaucām šāda veida testēšanu, ir melnās kastes testēšana, šajā testēšanas ierīcē nevar redzēt iekšējo kodu.

Piemēram, testētājs bez zināšanām par vietnes iekšējām struktūrām pārbauda tīmekļa lapas, izmantojot tīmekļa pārlūkprogrammu, kas nodrošina ievadi un pārbauda iznākumu pret gaidīto rezultātu.

Lietotāja pieņemšanas pārbaude: Tas ir testēšanas veids, ko veic klients, lai sertificētu sistēmu atbilstoši prasībām. Pēdējais testēšanas posms ir lietotāja pieņemšanas testēšana pirms programmatūras izlaišanas tirgū vai ražošanas vidē. UAT ir sava veida melnās kastes testēšana, kurā iesaistīsies divi vai vairāki galalietotāji.

Atkārtota pārbaude: atkārtota pārbaude ir testēšanas veids, kas tiek veikts, lai pārbaudītu, vai galīgajā izpildē neveiksmīgie testa gadījumi ir veiksmīgi izturēti pēc defektu novēršanas. Parasti testētājs piešķir kļūdu, kad to atrod, pārbaudot produktu vai tā komponentu. Izstrādātājam piešķirta kļūda, un viņš to izlabo. Pēc labošanas kļūda tiek piešķirta testētājam tās pārbaudei. Šī pārbaude ir pazīstama kā atkārtota pārbaude.

Datu bāzes pārbaude: Datu bāzes testēšana ir testēšanas veids, kas pārbauda pārbaudāmās datu bāzes shēmu, tabulas, trigerus utt. Datu bāzes testēšana var ietvert sarežģītu vaicājumu izveidi, lai ielādētu / stresa testu datubāzi un pārbaudītu tās atsaucību. Tas pārbauda datu integritāti un konsekvenci.

Piemērs: aplūkosim bankas lietojumprogrammu, ar kuras palīdzību lietotājs veic darījumu. Tagad, ņemot vērā datu bāzes testēšanu, lietas ir svarīgas. Viņi ir:

Lietojumprogramma saglabā darījumu informāciju lietojumprogrammu datu bāzē un pareizi parāda to lietotājam.
Šajā procesā informācija netiek zaudēta
Lietojumprogramma nesaglabā informāciju par daļēji veiktajām vai pārtrauktajām darbībām.
Personām nav atļauts piekļūt lietotāja informācijai

Ad-hoc testēšana: Ad-hoc testēšana ir neformāls testēšanas veids, kura mērķis ir izjaukt sistēmu. Šāda veida programmatūras testēšana ir neplānota darbība. Lai izveidotu testa gadījumus, netiek ievērots neviens testa dizains. Ad-hoc testēšana tiek veikta nejauši jebkurā lietojumprogrammas daļā; tas neatbalsta nevienu strukturētu testēšanas veidu.

Atkopšanas pārbaude: atkopšanas pārbaude tiek izmantots, lai noteiktu, cik labi lietojumprogramma var atkopties pēc avārijām, aparatūras kļūmēm un citām problēmām. Atkopšanas testēšanas mērķis ir pārbaudīt sistēmas spēju atgūties no atteices pārbaudes punktiem.

Statiskā pārbaude: Statiskā pārbaude ir programmatūras testēšanas tehnika, ar kuras palīdzību mēs varam pārbaudīt programmatūras defektus, to faktiski neizpildot. Statiskā pārbaude tiek veikta, lai izvairītos no kļūdām agrīnā izstrādes stadijā, jo agrīnā stadijā ir vieglāk atrast neveiksmi. Statiskā pārbaude, ko izmanto, lai atklātu kļūdas, kuras var neatklāt dinamiskajā testēšanā.

Kāpēc mēs izmantojam statisko testēšanu?

Statiskā pārbaude palīdz atrast kļūdu agrīnā stadijā. Izmantojot statisko testēšanu, tas samazinās izstrādes laiku. Tas samazina pārbaudes izmaksas un laiku. Statiskā pārbaude tiek izmantota arī izstrādes produktivitātei.

Komponentu pārbaude: komponentu pārbaude ir arī programmatūras testēšanas veids, kurā testēšana tiek veikta katram komponentam atsevišķi, neintegrējot to ar citām daļām. Komponentu testēšana ir arī melnās kastes testēšanas veids. Komponentu testēšana tiek saukta arī par vienības testēšanu, programmu testēšanu vai moduļu testēšanu.

Pelēkās kastes pārbaude: pelēkās kastes pārbaude definēts kā baltās kastes un melnās kastes testēšanas kombinācija. Grey Box testēšana ir testēšanas metode, kas tiek veikta ar ierobežotu informāciju par sistēmas iekšējo funkcionalitāti.

Kādi ir funkcionālās pārbaudes rīki?

Funkcionālo testēšanu var veikt arī dažādi, izņemot manuālo testēšanu. Šie rīki vienkāršo testēšanas procesu un palīdz iegūt precīzus un noderīgus rezultātus.

Tas ir viens no nozīmīgākajiem un prioritārajiem paņēmieniem, kas tika izlemts un precizēts pirms izstrādes procesa.

Funkcionālajai pārbaudei tiek izmantoti šādi rīki:

Rīki	Īpašības/īpašības
Patiesībā	Tas ir atvērtā pirmkoda un automatizācijas testēšanas rīks, kas izdots saskaņā ar Apache License atvērtā pirmkoda licenci un tiek izmantots tīmekļa lietojumprogrammas testēšanai. Sahi ir rakstīts Java un JavaScript valodā, un tas tiek uzskatīts par lielāko daļu testēšanas metožu. Tas darbojas kā starpniekserveris; tas ir neatkarīgs no pārlūkprogrammas.
SoapUI	Tas ir atvērtā pirmkoda funkcionālās testēšanas rīks, ko izmanto tīmekļa lietojumprogrammu testēšanai. Tas ir vienkārši un viegli projektējams. Tā atbalsta vairākas vides, t.i., mērķa vidi var iestatīt jebkurā gadījumā.
ūdens	Watir ir saīsināts tīmekļa lietojumprogrammu testēšanas veids rubīnā, ir atvērtā koda rīks tīmekļa pārlūkprogrammas automatizēšanai./li> Tas izmanto ruby skriptu valodu, kas ir kodolīga un viegli lietojama./li> Watir atbalsta vairākas pārlūkprogrammas dažādās platformās.
Selēns	Atvērtā pirmkoda rīks, ko izmanto funkcionālai pārbaudei gan tīmekļa lietojumprogrammās, gan darbvirsmas lietojumprogrammās.
	Tas automatizē pārlūkprogrammas un tīmekļa lietojumprogrammas testēšanas nolūkos. Tas nodrošina elastību, lai pielāgotu automatizēto testa gadījumu Nodrošina pārbaudes skriptu rakstīšanas priekšrocības atbilstoši prasībām, izmantojot tīmekļa draiveri.
Canoo WebTest	Atvērtā pirmkoda rīks tīmekļa lietojumprogrammas funkcionālās pārbaudes veikšanai. Platformas neatkarīga Viegli un ātri Viegli pagarināms, lai apmierinātu pieaugošās un ienākošās prasības.
Gurķi	Cucumber ir atvērtā pirmkoda testēšanas rīks, kas rakstīts rubīna valodā. Šis rīks vislabāk darbojas testu vadītai izstrādei. To izmanto, lai pārbaudītu daudzas citas valodas, piemēram, java, c# un python. Gurķi testēšanai, izmantojot kādu programmēšanu.

Kādas ir funkcionālās pārbaudes priekšrocības?

Funkcionālās pārbaudes priekšrocības ir:

Tas ražo produktu bez defektiem.
Tas nodrošina, ka klients ir apmierināts.
Tas nodrošina visu prasību izpildi.
Tas nodrošina pareizu visas lietojumprogrammas/programmatūras/produkta funkcionalitātes darbību.
Tas nodrošina, ka programmatūra/produkts darbojas, kā paredzēts.
Tas nodrošina drošību un drošību.
Tas uzlabo produkta kvalitāti.

Piemērs: šeit mēs sniedzam banku programmatūras piemēru. Bankā, kad nauda tiek pārskaitīta no bankas A uz banku B. Un banka B nesaņem pareizo summu, tiek piemērota maksa vai nauda nav konvertēta pareizajā valūtā, vai nepareizs pārskaitījums vai banka A nesaņem izraksta padomu no bankas B, ka maksājums ir saņemts. Šīs problēmas ir kritiskas, un no tām var izvairīties, veicot atbilstošu funkcionālo pārbaudi.

Kādi ir funkcionālās pārbaudes trūkumi?

Funkcionālās pārbaudes trūkumi ir:

Funkcionālā pārbaude var palaist garām kritisku un loģisku kļūdu sistēmā.
Šī pārbaude negarantē, ka programmatūra darbosies tiešsaistē.
Funkcionālajā pārbaudē ir liela iespēja veikt lieko testēšanu.

Satīt

Šeit mēs varam viegli secināt, ka, lai izveidotu spēcīgu augstākās klases programmatūras produkta pamatu, funkcionālā pārbaude ir būtiska. Tas darbojas kā struktūras pamats, un tā ir katras pārbaudes rutīnas būtiska sastāvdaļa.