I dette afsnit skal vi forstå de forskellige typer softwaretest, som kan bruges på tidspunktet for softwareudviklingens livscyklus.
Som vi ved, software test er en proces til at analysere en applikations funktionalitet i henhold til kundens forudsætning.
Hvis vi vil sikre, at vores software er fejlfri eller stabil, skal vi udføre de forskellige typer softwaretest, fordi test er den eneste metode, der gør vores applikation fejlfri.
De forskellige typer softwaretest
Kategoriseringen af softwaretest er en del af forskellige testaktiviteter, som f.eks teststrategi, testleverancer, et defineret testmål mv . Og softwaretest er udførelsen af softwaren for at finde defekter.
Formålet med at have en testtype er at bekræfte AUT (Ansøgning under test).
For at begynde at teste, bør vi have en krav, applikationsklare, nødvendige ressourcer til rådighed . For at opretholde ansvarlighed bør vi tildele et respektive modul til forskellige testingeniører.
Softwaretestningen er hovedsageligt opdelt i to dele, som er som følger:
Hvad er manuel test?
At teste enhver software eller en applikation i henhold til kundens behov uden at bruge noget automatiseringsværktøj er kendt som manuel test .
Med andre ord kan vi sige, at det er en procedure af verifikation og validering . Manuel test bruges til at verificere adfærden af en applikation eller software i modstrid med kravspecifikationen.
Vi kræver ikke noget præcist kendskab til noget testværktøj for at udføre de manuelle testcases. Vi kan nemt udarbejde testdokumentet, mens vi udfører manuel test på enhver applikation.
For at få detaljerede oplysninger om manuel testning, klik på følgende link: https://www.javatpoint.com/manual-testing.
Klassificering af manuel testning
Ved softwaretestning kan manuel test klassificeres yderligere i tre forskellige typer test , som er som følger:
For at få en bedre forståelse, lad os se dem én efter én:
White Box Test
I white-box test, vil udvikleren inspicere hver linje kode, før den overdrages til testteamet eller de berørte testingeniører.
Efterfølgende er koden mærkbar for udviklere under hele testen; det er derfor denne proces er kendt som WBT (White Box Testing) .
Med andre ord kan vi sige, at Udvikler vil udføre den komplette white-box-test for den pågældende software og sende den specifikke applikation til testteamet.
Formålet med at implementere white box-testen er at understrege strømmen af input og output over softwaren og øge sikkerheden i en applikation.
White box test er også kendt som åben boks test, glas boks test, strukturel test, klar box test og transparent box test .
For at få den dybdegående viden om white box-test henvises til nedenstående link: https://www.javatpoint.com/white-box-testing.
Black Box test
En anden type manuel test er black-box test . I denne test vil testingeniøren analysere softwaren i forhold til kravene, identificere defekterne eller fejlen og sende den tilbage til udviklingsteamet.
Derefter vil udviklerne rette disse defekter, lave en runde White box-test og sende det til testteamet.
Her betyder reparation af fejlene, at defekten er løst, og den særlige funktion fungerer i henhold til det givne krav.
Hovedformålet med at implementere black box-testen er at specificere virksomhedens behov eller kundens krav.
Med andre ord kan vi sige, at black box test er en proces til at kontrollere funktionaliteten af en applikation i henhold til kundens krav. Kildekoden er ikke synlig i denne test; det er derfor det er kendt som black-box test .
For mere information om Black box-test henvises til nedenstående link: https://www.javatpoint.com/black-box-testing.
Typer af Black Box-test
Black box-testning kategoriserer yderligere i to dele, som er som diskuteret nedenfor:
Funktionstest
Testingeniøren vil kontrollere alle komponenter systematisk i forhold til de kravspecifikationer, som er kendt som funktionstest . Funktionel test er også kendt som Komponenttestning .
Ved funktionel test testes alle komponenter ved at angive værdien, definere output og validere det faktiske output med den forventede værdi.
Funktionel testning er en del af black-box-testning, da den lægger vægt på applikationskrav snarere end faktisk kode. Testingeniøren skal kun teste programmet i stedet for systemet.
For at få detaljerede oplysninger om funktionel test henvises til nedenstående link: https://www.javatpoint.com/functional-testing .
Typer af funktionstest
Ligesom en anden type test er opdelt i flere dele, er funktionel test også klassificeret i forskellige kategorier.
Det mangfoldige typer af funktionstest indeholde følgende:
Lad os nu forstå dem én efter én:
1. Enhedstest
Enhedstest er det første niveau af funktionel test for at teste enhver software. I dette vil testingeniøren teste modulet af en applikation uafhængigt eller teste alle modulets funktionalitet kaldes enhedstest .
Det primære formål med at udføre enhedstesten er at bekræfte enhedskomponenterne med deres ydeevne. Her defineres en enhed som en enkelt testbar funktion af en software eller en applikation. Og det er verificeret i hele den specificerede applikationsudviklingsfase.
Klik på nedenstående link for at få den komplette information om enhedstest: https://www.javatpoint.com/unit-testing.
min live cricket
2. Integrationstest
Når vi har implementeret enhedstesten med succes, går vi til integrationstest . Det er det andet niveau af funktionel test, hvor vi tester dataflowet mellem afhængige moduler eller interface mellem to funktioner kaldes integrationstest .
Formålet med at udføre integrationstesten er at teste erklæringens nøjagtighed mellem hvert modul.
Typer af integrationstest
Integrationstest er også yderligere opdelt i følgende dele:
Inkrementel integrationstest
Når der er et klart forhold mellem moduler, går vi til inkrementel integrationstest. Antag, at vi tager to moduler og analyserer datastrømmen mellem dem, om de fungerer fint eller ej.
Hvis disse moduler fungerer fint, kan vi tilføje et modul mere og teste igen. Og vi kan fortsætte med den samme proces for at få bedre resultater.
Med andre ord kan vi sige, at trinvis tilføjelse af modulerne og test af dataflowet mellem modulerne er kendt som Inkrementel integrationstest .
Typer af inkrementel integrationstest
Inkrementel integrationstest kan yderligere klassificeres i to dele, som er som følger:
Lad os se en kort introduktion af disse typer integrationstest:
1. Top-down inkrementel integrationstest
I denne tilgang vil vi tilføje modulerne trin for trin eller trinvist og teste datastrømmen mellem dem. Vi skal sikre, at de moduler, vi tilføjer, er barn af de tidligere .
2. Bottom-up inkrementel integrationstest
I bottom-up tilgangen vil vi tilføje modulerne trinvist og kontrollere dataflowet mellem modulerne. Og sørg også for, at det modul, vi tilføjer, er forælder til de tidligere .
Ikke-inkrementel integrationstest/ Big Bang-metode
Når datastrømmen er kompleks og meget vanskelig at klassificere en forælder og et barn, vil vi gå efter den ikke-trinvise integrationstilgang. Den ikke-inkrementale metode er også kendt som Big Bang-metoden .
For at få den komplette information om integrationstest og dens type henvises til følgende link: https://www.javatpoint.com/integration-testing.
3. Systemtest
Når vi er færdige med enheds- og integrationstesten, kan vi fortsætte med systemtesten.
Ved systemtest er testmiljøet parallelt med produktionsmiljøet. Det er også kendt som ende til ende afprøvning.
I denne type test vil vi gennemgå hver egenskab af softwaren og teste, om slutfunktionen fungerer i overensstemmelse med forretningskravene. Og analyser softwareproduktet som et komplet system.
Klik på nedenstående link for at få den komplette information om systemtest: https://www.javatpoint.com/system-testing.
Ikke-funktionstest
Den næste del af black-box test er ikke-funktionel test . Den giver detaljerede oplysninger om softwareproduktets ydeevne og brugte teknologier.
Ikke-funktionel test vil hjælpe os med at minimere risikoen for produktion og relaterede omkostninger til softwaren.
Ikke-funktionel test er en kombination af ydeevne, belastning, stress, brugervenlighed og kompatibilitetstest .
For mere information om ikke-funktionel testning, se følgende link: https://www.javatpoint.com/non-functional-testing.
Typer af ikke-funktionel test
Ikke-funktionel test kategoriseret i forskellige dele af test, som vi vil diskutere yderligere:
1. Ydelsestest
Ved præstationstestning vil testingeniøren teste en applikations funktion ved at påføre en vis belastning.
I denne form for ikke-funktionel test vil testingeniøren kun fokusere på flere aspekter, som f.eks Responstid, belastning, skalerbarhed og stabilitet af softwaren eller en applikation.
Klassificering af præstationstest
Ydelsestest omfatter de forskellige typer af test, som er som følger:
Mens vi udfører ydelsestesten, vil vi påføre en vis belastning på den bestemte applikation for at kontrollere applikationens ydeevne, kendt som belastningstest . Her kan belastningen være mindre end eller lig med den ønskede belastning.
Det vil hjælpe os med at opdage softwarens højeste driftsvolumen og flaskehalse.
For at få den komplette information relateret til belastningstesten henvises til nedenstående link:
https://www.javatpoint.com/load-testing.
Det bruges til at analysere softwarens brugervenlighed og robusthed ud over de almindelige funktionsgrænser.
Primært bruges stresstest til kritisk software, men det kan også bruges til alle typer softwareapplikationer.
Henviser til nedenstående link for dybdegående viden om stresstest: https://www.javatpoint.com/stress-testing.
Til analyse er applikationens ydeevne ved at forbedre eller reducere belastningen i bestemte balancer kendt som skalerbarhedstest .
I skalerbarhedstest kan vi også kontrollere system, processer eller databases evner at imødekomme et opadgående behov. Og i dette Test Cases er designet og implementeret effektivt.
Klik på følgende link for at få de detaljerede oplysninger relateret til skalerbarhedstestningen:
https://www.javatpoint.com/scalability-testing.
Stabilitetstest er en procedure, hvor vi evaluerer applikationens ydeevne ved at påføre belastningen i en præcis tid.
Det kontrollerer hovedsageligt applikationens konstante problemer og effektiviteten af et udviklet produkt. I denne type test kan vi hurtigt finde systemets defekt selv i en stresset situation.
For at få detaljerede oplysninger om stabilitetstesten henvises til nedenstående link:
https://www.javatpoint.com/stability-testing.
2. Usability Test
En anden type ikke-funktionel test er usability test . I usability test, vil vi analysere brugervenligheden af en applikation og opdage fejlene i softwarens slutbrugergrænseflade.
Her udtrykket brugervenlighed definerer følgende aspekter af en ansøgning:
- Applikationen skal være let at forstå, hvilket betyder, at alle funktionerne skal være synlige for slutbrugerne.
- Applikationens udseende og følelse skal være god, hvilket betyder, at applikationen skal være behagelig at se og give slutbrugeren en fornemmelse for at bruge den.
For mere information om usability test, kan vi henvise til følgende link:
https://www.javatpoint.com/usability-testing.
3. Kompatibilitetstest
Ved kompatibilitetstestning vil vi kontrollere funktionaliteten af en applikation i specifikke hardware- og softwaremiljøer. Når først applikationen er funktionelt stabil, går vi efter kompatibilitetstest .
Her, software betyder, at vi kan teste applikationen på de forskellige operativsystemer og andre browsere, og hardware betyder, at vi kan teste applikationen i forskellige størrelser.
For at få et grundigt kendskab til kompatibilitetstest henvises til nedenstående link:
https://www.javatpoint.com/compatibility-testing .
Test af grå boks
En anden del af manuel test er Grå boks test . Det er en samarbejde mellem black box og white box test .
Siden inkluderer den grå boks-test adgang til intern kodning til design af testcases. Gray box test udføres af en person, der kan kodning såvel som test.
Med andre ord kan vi sige, at hvis et enkeltmandshold gjorde begge dele hvid boks og sort boks test , betragtes det test af grå boks .
For at få detaljerede oplysninger om Gray box-testning kan vi henvise til nedenstående link:
https://www.javatpoint.com/grey-box-testing.
Test af automatisering
Den vigtigste del af softwaretest er automatiseringstest. Den bruger specifikke værktøjer til at automatisere manuelle designtestsager uden menneskelig indblanding.
Automationstest er den bedste måde at forbedre effektiviteten, produktiviteten og dækningen af softwaretest.
Det bruges til at køre testscenarierne igen, som blev udført manuelt, hurtigt og gentagne gange.
Med andre ord kan vi sige, at når vi tester en applikation ved at bruge nogle værktøjer er kendt som automatiseringstest .
Vi vil gå til automatiseringstest, når forskellige udgivelser eller flere regressionscyklusser går på applikationen eller softwaren. Vi kan ikke skrive testscriptet eller udføre automatiseringstesten uden at forstå programmeringssproget.
For mere information om automatiseringstest, kan vi henvise til nedenstående link:
https://www.javatpoint.com/automation-testing.
Nogle andre typer softwaretest
Inden for softwaretest har vi også nogle andre typer test, som ikke er en del af nogen ovennævnte test, men disse test er påkrævet, mens du tester enhver software eller en applikation.
Lad os forstå disse typer test én efter én:
I røgtest , vil vi teste en applikations grundlæggende og kritiske funktioner, før vi laver en runde dyb og streng test.
Eller før kontrol af alle mulige positive og negative værdier er kendt som røgtest . At analysere arbejdsgangen for applikationens kerne- og hovedfunktioner er hovedformålet med at udføre røgtestningen.
For mere information om røgtest henvises til følgende link:
https://www.javatpoint.com/smoke-testing.
Sanitetstest
Det bruges til at sikre, at alle fejlene er blevet rettet, og at der ikke opstår yderligere problemer på grund af disse ændringer. Sanitetstest er uscriptet, hvilket betyder, at vi ikke kan dokumentere det. Det kontrollerer rigtigheden af de nyligt tilføjede funktioner og komponenter.
For at få detaljerede oplysninger om fornuftstest, kan vi henvise til nedenstående link:
https://www.javatpoint.com/sanity-testing.
Regressionstest
Regressionstest er den mest anvendte type softwaretest. Her udtrykket regression indebærer, at vi er nødt til at teste de dele af en upåvirket applikation igen.
Regressionstest er den bedst egnede test til automatiseringsværktøjer. I henhold til projekttypen og tilgængeligheden af ressourcer kan regressionstest ligne Gentestning .
Hver gang en fejl rettes af udviklerne og derefter tester de andre funktioner i applikationerne, der kan simuleres på grund af fejlrettelsen, er kendt som regressionstest .
Med andre ord kan vi sige, at når der er en ny udgivelse til et eller andet projekt, så kan vi udføre regressionstest, og på grund af en ny funktion kan det påvirke de gamle funktioner i de tidligere udgivelser.
For at få grundig viden relateret til regressionstest, se nedenstående link:
https://www.javatpoint.com/regression-testing .
Brugeraccepttest
Brugeraccepttesten (UAT) udføres af det individuelle team kendt som domæneekspert/kunde eller klient. Og at kende ansøgningen, før du accepterer det endelige produkt, kaldes som test af brugeraccept .
I brugeraccepttest analyserer vi forretningsscenarier og realtidsscenarier i det særskilte miljø kaldet UAT miljø . I denne test tester vi applikationen før UAI til kundegodkendelse.
For mere information om brugeraccepttesten, klik på nedenstående link:
https://www.javatpoint.com/acceptance-testing.
Udforskende afprøvning
Når kravet mangler, kræves tidlig iteration, og testteamet har erfarne testere, når vi har en kritisk applikation. Ny testingeniør kom ind i holdet, så går vi efter undersøgende test .
For at udføre den sonderende test vil vi først gennemgå applikationen på alle mulige måder, lave et testdokument, forstå applikationens flow og derefter teste applikationen.
Klik på følgende link for at få den komplette information om eksplorativ test:
https://www.javatpoint.com/exploratory-testing.
Adhoc test
At teste applikationen tilfældigt, så snart bygningen er i den kontrollerede sekvens, kaldes Adhoc test .
Det kaldes også Abetest og Gorilla test . I Adhoc test vil vi kontrollere applikationen i modstrid med kundens krav; derfor er det også kendt som negativ test .
Når slutbrugeren bruger applikationen tilfældigt, og han/hun kan opdage en fejl. Alligevel bruger den specialiserede testingeniør softwaren grundigt, så han/hun muligvis ikke identificerer en lignende detektion.
Henviser til følgende for at få detaljerede oplysninger om Adhoc-test:
https://www.javatpoint.com/adhoc-testing.
Sikkerhedstest
Det er en væsentlig del af softwaretest, der bruges til at bestemme svaghed, risici eller trusler i softwareapplikationen.
Udførelsen af sikkerhedstest vil hjælpe os med at undgå det grimme angreb fra udenforstående og sikre vores softwareapplikationers sikkerhed.
Med andre ord kan vi sige, at sikkerhedstest hovedsageligt bruges til at definere, at dataene vil være sikre og tåle softwarens arbejdsproces.
For at få alle detaljer om sikkerhedstest, se nedenstående link: https://www.javatpoint.com/security-testing.
Globaliseringstest
En anden type softwaretest er Globaliseringstest. Globaliseringstest bruges til at kontrollere den udviklede software for flere sprog eller ej. Her ordene globalisering betyder at oplyse applikationen eller softwaren til forskellige sprog.
Globaliseringstest bruges til at sikre, at applikationen understøtter flere sprog og flere funktioner.
I de nuværende scenarier kan vi se forbedringen i flere teknologier, da applikationerne er forberedt til at blive brugt globalt.
Se følgende link for at få den udfyldte information relateret til globaliseringstesten:
https://www.javatpoint.com/globalization-testing.
Konklusion
I vejledningen har vi diskuteret forskellige typer softwaretest. Men der er stadig en liste over mere end 100+ kategorier af test. Hver form for test bruges dog ikke i alle typer projekter.
Vi har diskuteret de mest almindeligt anvendte typer softwaretest som f.eks black-box test, white box test, funktionel test, ikke-funktionel test, regressionstest, Adhoc test, osv. .
Der er også alternative klassifikationer eller processer, der bruges i forskellige organisationer, men det generelle koncept er ens overalt.
Disse testtyper, processer og udførelsestilgange bliver ved med at ændre sig, når projektet, kravene og omfanget ændres.