I denne delen skal vi forstå de ulike typene programvaretesting, som kan brukes på tidspunktet for programvareutviklingens livssyklus.
Som vi vet, programvaretesting er en prosess for å analysere en applikasjons funksjonalitet i henhold til kundens forutsetning.
Hvis vi ønsker å sikre at programvaren vår er feilfri eller stabil, må vi utføre ulike typer programvaretesting fordi testing er den eneste metoden som gjør applikasjonen vår feilfri.
De forskjellige typene programvaretesting
Kategoriseringen av programvaretesting er en del av ulike testaktiviteter, som f.eks teststrategi, testleveranser, et definert testmål osv . Og programvaretesting er utførelse av programvaren for å finne defekter.
Hensikten med å ha en testtype er å bekrefte AUT (Søknad under test).
For å begynne å teste, bør vi ha en krav, applikasjonsklare, nødvendige ressurser tilgjengelig . For å opprettholde ansvarlighet bør vi tildele en respektive modul til forskjellige testingeniører.
Programvaretestingen er hovedsakelig delt inn i to deler, som er som følger:
Hva er manuell testing?
Testing av programvare eller applikasjoner i henhold til kundens behov uten å bruke noe automatiseringsverktøy er kjent som manuell testing .
Med andre ord kan vi si at det er en prosedyre av verifisering og validering . Manuell testing brukes til å verifisere oppførselen til en applikasjon eller programvare i strid med kravspesifikasjonen.
Vi krever ingen nøyaktig kunnskap om noe testverktøy for å utføre de manuelle testsakene. Vi kan enkelt forberede testdokumentet mens vi utfører manuell testing på alle applikasjoner.
For å få detaljert informasjon om manuell testing, klikk på følgende lenke: https://www.javatpoint.com/manual-testing.
Klassifisering av manuell testing
I programvaretesting kan manuell testing klassifiseres ytterligere i tre forskjellige typer testing , som er som følger:
For bedre forståelse, la oss se dem én etter én:
White Box Testing
I white-box-testing vil utvikleren inspisere hver linje med kode før den overleveres til testteamet eller de berørte testingeniørene.
Deretter er koden merkbar for utviklere gjennom hele testingen; det er derfor denne prosessen er kjent som WBT (White Box Testing) .
Med andre ord kan vi si at utvikler vil utføre den komplette white-box-testingen for den aktuelle programvaren og sende den spesifikke applikasjonen til testteamet.
Hensikten med å implementere white box-testingen er å understreke flyten av innganger og utganger over programvaren og forbedre sikkerheten til en applikasjon.
White box testing er også kjent som testing av åpen boks, testing av glassbokser, strukturell testing, testing av klar boks og testing av transparente bokser .
For å få dybdekunnskap om testing av hvite bokser, referer til lenken nedenfor: https://www.javatpoint.com/white-box-testing.
Black Box-testing
En annen type manuell testing er black-box testing . I denne testen vil testingeniøren analysere programvaren opp mot kravene, identifisere defektene eller feilen og sende den tilbake til utviklingsteamet.
Deretter vil utviklerne fikse disse defektene, gjøre en runde med White Box-testing og sende den til testteamet.
Her betyr å fikse feilene at defekten er løst, og den spesielle funksjonen fungerer i henhold til det gitte kravet.
Hovedmålet med å implementere black box-testingen er å spesifisere forretningsbehovene eller kundens krav.
Med andre ord kan vi si at black box-testing er en prosess for å sjekke funksjonaliteten til en applikasjon i henhold til kundens krav. Kildekoden er ikke synlig i denne testen; det er derfor det er kjent som black-box testing .
For mer informasjon om Black box-testing, referer til lenken nedenfor: https://www.javatpoint.com/black-box-testing.
Typer Black Box-testing
Black box-testing kategoriserer videre i to deler, som er som diskutert nedenfor:
Funksjonstesting
Testingeniøren vil kontrollere alle komponentene systematisk mot kravspesifikasjoner som kalles funksjonstesting . Funksjonstesting er også kjent som Komponenttesting .
Ved funksjonell testing testes alle komponentene ved å gi verdien, definere utgangen og validere den faktiske utgangen med forventet verdi.
Funksjonell testing er en del av black-box-testing da den legger vekt på applikasjonskrav i stedet for faktisk kode. Testingeniøren må kun teste programmet i stedet for systemet.
For å få detaljert informasjon om funksjonell testing, referer til lenken nedenfor: https://www.javatpoint.com/functional-testing .
Typer funksjonstesting
Akkurat som en annen type testing er delt inn i flere deler, er funksjonell testing også klassifisert i ulike kategorier.
Det mangfoldige typer funksjonstesting inneholder følgende:
La oss nå forstå dem én etter én:
1. Enhetstesting
Enhetstesting er det første nivået av funksjonell testing for å teste programvare. I dette vil testingeniøren teste modulen til en applikasjon uavhengig eller teste all modulfunksjonaliteten som kalles enhetstesting .
Hovedmålet med å utføre enhetstesten er å bekrefte enhetskomponentene med deres ytelse. Her er en enhet definert som en enkelt testbar funksjon av en programvare eller en applikasjon. Og det er verifisert gjennom den angitte applikasjonsutviklingsfasen.
Klikk på lenken nedenfor for å få fullstendig informasjon om enhetstesting: https://www.javatpoint.com/unit-testing.
min live cricket
2. Integrasjonstesting
Når vi har implementert enhetstesten, vil vi gå i integrasjonstesting . Det er det andre nivået av funksjonell testing, hvor vi tester dataflyten mellom avhengige moduler eller grensesnitt mellom to funksjoner kalles integrasjonstesting .
Hensikten med å utføre integrasjonstestingen er å teste setningens nøyaktighet mellom hver modul.
Typer integrasjonstesting
Integrasjonstesting er også videre delt inn i følgende deler:
Inkrementell integrasjonstesting
Når det er et klart forhold mellom moduler, går vi for inkrementell integrasjonstesting. Anta at vi tar to moduler og analyserer dataflyten mellom dem om de fungerer bra eller ikke.
Hvis disse modulene fungerer bra, kan vi legge til en modul til og teste på nytt. Og vi kan fortsette med den samme prosessen for å få bedre resultater.
Med andre ord kan vi si at det å legge sammen modulene trinnvis og teste dataflyten mellom modulene er kjent som Inkrementell integrasjonstesting .
Typer inkrementell integrasjonstesting
Inkrementell integrasjonstesting kan videre klassifiseres i to deler, som er som følger:
La oss se en kort introduksjon av disse typene integrasjonstesting:
1. Top-down inkrementell integrasjonstesting
I denne tilnærmingen vil vi legge til modulene trinn for trinn eller trinnvis og teste dataflyten mellom dem. Vi må sørge for at modulene vi legger til er barn av de tidligere .
2. Inkrementell integrasjonstesting nedenfra og opp
I bottom-up-tilnærmingen vil vi legge til modulene trinnvis og sjekke dataflyten mellom moduler. Og sørg også for at modulen vi legger til er forelder til de tidligere .
Ikke-inkrementell integrasjonstesting/ Big Bang-metode
Når dataflyten er kompleks og svært vanskelig å klassifisere en forelder og et barn, vil vi gå for den ikke-inkrementelle integreringstilnærmingen. Den ikke-inkrementelle metoden er også kjent som Big Bang-metoden .
For å få fullstendig informasjon om integrasjonstesting og dens type refererer til følgende lenke: https://www.javatpoint.com/integration-testing .
3. Systemtesting
Når vi er ferdige med enhets- og integrasjonstestingen, kan vi fortsette med systemtestingen.
Ved systemtesting er testmiljøet parallelt med produksjonsmiljøet. Det er også kjent som ende til ende testing.
I denne typen testing vil vi gjennomgå hver egenskap ved programvaren og teste om sluttfunksjonen fungerer i henhold til forretningskravene. Og analysere programvareproduktet som et komplett system.
Klikk på lenken nedenfor for å få fullstendig informasjon om systemtesting: https://www.javatpoint.com/system-testing .
Ikke-funksjonstesting
Den neste delen av black-box-testingen er ikke-funksjonell testing . Den gir detaljert informasjon om programvareproduktytelse og brukte teknologier.
Ikke-funksjonell testing vil hjelpe oss med å minimere risikoen for produksjon og relaterte kostnader til programvaren.
Ikke-funksjonell testing er en kombinasjon av ytelse, belastning, stress, brukervennlighet og kompatibilitetstesting .
For mer informasjon om ikke-funksjonell testing, se følgende lenke: https://www.javatpoint.com/non-functional-testing .
Typer ikke-funksjonell testing
Ikke-funksjonell testing kategorisert i ulike deler av testing, som vi skal diskutere videre:
1. Ytelsestesting
I ytelsestesting vil testingeniøren teste funksjonen til en applikasjon ved å bruke en viss belastning.
I denne typen ikke-funksjonell testing vil testingeniøren kun fokusere på flere aspekter, som f.eks Responstid, belastning, skalerbarhet og stabilitet av programvaren eller en applikasjon.
Klassifisering av ytelsestesting
Ytelsestesting inkluderer de ulike typene testing, som er som følger:
Mens vi utfører ytelsestesten, vil vi bruke en viss belastning på den aktuelle applikasjonen for å sjekke applikasjonens ytelse, kjent som belastningstesting . Her kan belastningen være mindre enn eller lik ønsket belastning.
Det vil hjelpe oss å oppdage det høyeste driftsvolumet av programvaren og flaskehalser.
For å få fullstendig informasjon relatert til lasttestingen, referer til lenken nedenfor:
https://www.javatpoint.com/load-testing.
Den brukes til å analysere brukervennligheten og robustheten til programvaren utover de vanlige funksjonsgrensene.
Primært brukes stresstesting for kritisk programvare, men den kan også brukes til alle typer programvareapplikasjoner.
Refererer til lenken nedenfor for dybdekunnskap om stresstesting: https://www.javatpoint.com/stress-testing.
For analyse er applikasjonens ytelse ved å forbedre eller redusere belastningen i bestemte balanser kjent som skalerbarhetstesting .
I skalerbarhetstesting kan vi også sjekke system, prosesser eller databases evner for å møte et oppadgående behov. Og i dette Testtilfeller er designet og implementert effektivt.
Klikk på følgende lenke for å få detaljert informasjon relatert til skalerbarhetstesten:
https://www.javatpoint.com/scalability-testing.
Stabilitetstesting er en prosedyre hvor vi evaluerer applikasjonens ytelse ved å påføre belastningen for en nøyaktig tid.
Den kontrollerer hovedsakelig konstansproblemene til applikasjonen og effektiviteten til et utviklet produkt. I denne typen testing kan vi raskt finne systemets defekt selv i en stressende situasjon.
For å få detaljert informasjon om stabilitetstestingen, referer til lenken nedenfor:
https://www.javatpoint.com/stability-testing.
2. Brukbarhetstesting
En annen type ikke-funksjonell testing er brukervennlighetstesting . I brukervennlighetstesting vil vi analysere brukervennligheten til en applikasjon og oppdage feilene i programvarens sluttbrukergrensesnitt.
Her, begrepet brukervennlighet definerer følgende aspekter ved en applikasjon:
- Applikasjonen skal være lett å forstå, noe som betyr at alle funksjonene må være synlige for sluttbrukere.
- Applikasjonens utseende og følelse skal være bra, det betyr at applikasjonen skal se behagelig ut og gi en følelse for sluttbrukeren å bruke den.
For mer informasjon om brukervennlighetstesting kan vi referere til følgende lenke:
https://www.javatpoint.com/usability-testing.
3. Kompatibilitetstesting
I kompatibilitetstesting vil vi sjekke funksjonaliteten til en applikasjon i spesifikke maskinvare- og programvaremiljøer. Når applikasjonen er funksjonelt stabil, går vi for kompatibilitetstesting .
Her, programvare betyr at vi kan teste applikasjonen på de forskjellige operativsystemene og andre nettlesere, og maskinvare betyr at vi kan teste applikasjonen på forskjellige størrelser.
For å få en grundig kunnskap om kompatibilitetstesting, se lenken nedenfor:
https://www.javatpoint.com/compatibility-testing .
Testing av grå boks
En annen del av manuell testing er Grå boks testing . Det er en samarbeid med testing av svart boks og hvit boks .
Siden inkluderer testing av grå boks tilgang til intern koding for utforming av testtilfeller. Gråbokstesting utføres av en person som kan koding så vel som testing.
Med andre ord kan vi si at hvis et enkeltmannsteam gjorde begge deler testing av hvit boks og svart boks , det er vurdert testing av grå boks .
For å få detaljert informasjon om testing av grå bokser, kan vi referere til lenken nedenfor:
https://www.javatpoint.com/grey-box-testing.
Testing av automatisering
Den viktigste delen av programvaretesting er automatiseringstesting. Den bruker spesifikke verktøy for å automatisere manuelle designtestsaker uten menneskelig innblanding.
Automatiseringstesting er den beste måten å forbedre effektiviteten, produktiviteten og dekningen av programvaretesting.
Den brukes til å kjøre testscenariene på nytt, som ble utført manuelt, raskt og gjentatte ganger.
Med andre ord kan vi si at når vi tester en applikasjon ved å bruke noen verktøy er kjent som automatiseringstesting .
Vi vil gå for automatiseringstesting når ulike utgivelser eller flere regresjonssykluser går på applikasjonen eller programvaren. Vi kan ikke skrive testskriptet eller utføre automatiseringstesten uten å forstå programmeringsspråket.
For mer informasjon om automatiseringstesting kan vi referere til lenken nedenfor:
https://www.javatpoint.com/automation-testing.
Noen andre typer programvaretesting
I programvaretesting har vi også noen andre typer testing som ikke er en del av noen ovenfor diskuterte testing, men disse testingene kreves mens du tester programvare eller applikasjoner.
La oss forstå disse typene testing en etter en:
I røyktesting , vil vi teste en applikasjons grunnleggende og kritiske funksjoner før vi gjør en runde med dyp og streng testing.
Eller før du sjekker alle mulige positive og negative verdier er kjent som røyktesting . Å analysere arbeidsflyten til applikasjonens kjerne- og hovedfunksjoner er hovedmålet med å utføre røyktestingen.
For mer informasjon om røyktesting, se følgende lenke:
https://www.javatpoint.com/smoke-testing.
Sanitetstesting
Den brukes til å sikre at alle feilene er fikset og at ingen ekstra problemer oppstår på grunn av disse endringene. Sanitetstesting er uskriptet, noe som betyr at vi ikke kan dokumentere det. Den kontrollerer riktigheten av de nylig lagt til funksjonene og komponentene.
For å få detaljert informasjon om tilregnelighetstesting, kan vi referere til lenken nedenfor:
https://www.javatpoint.com/sanity-testing.
Regresjonstesting
Regresjonstesting er den mest brukte typen programvaretesting. Her, begrepet regresjon innebærer at vi må teste de delene av en upåvirket applikasjon på nytt.
Regresjonstesting er den best egnede testen for automatiseringsverktøy. I henhold til prosjekttype og tilgjengelighet til ressurser, kan regresjonstesting ligne på Tester på nytt .
Når en feil rettes av utviklerne og deretter teste de andre funksjonene til applikasjonene som kan simuleres på grunn av feilrettingen, er det kjent som Regresjonstesting .
Med andre ord kan vi si at når det er en ny utgivelse for et eller annet prosjekt, kan vi utføre regresjonstesting, og på grunn av en ny funksjon kan det påvirke de gamle funksjonene i de tidligere utgivelsene.
For å få grundig kunnskap relatert til regresjonstesting, se lenken nedenfor:
https://www.javatpoint.com/regression-testing .
Brukeraksepttesting
Brukeraksepttestingen (UAT) utføres av det individuelle teamet kjent som domeneekspert/kunde eller klient. Og å kjenne søknaden før du godtar det endelige produktet kalles som brukeraksepttesting .
I brukeraksepttesting analyserer vi forretningsscenariene og sanntidsscenarier på det distinkte miljøet som kalles UAT miljø . I denne testen vil vi teste applikasjonen før UAI for kundegodkjenning.
For mer informasjon om brukeraksepttestingen, klikk på lenken nedenfor:
https://www.javatpoint.com/acceptance-testing.
Utforskende testing
Når kravet mangler, kreves tidlig iterasjon, og testteamet har erfarne testere når vi har en kritisk applikasjon. Ny testingeniør kom inn i teamet, så går vi for utforskende testing .
For å utføre den utforskende testingen vil vi først gå gjennom applikasjonen på alle mulige måter, lage et testdokument, forstå flyten av applikasjonen og deretter teste applikasjonen.
Klikk på følgende lenke for å få fullstendig informasjon om utforskende testing:
https://www.javatpoint.com/exploratory-testing.
Adhoc testing
Å teste applikasjonen tilfeldig så snart bygget er i den sjekkede sekvensen kalles Adhoc testing .
Det kalles også Apetesting og Gorillatesting . I Adhoc-testing vil vi sjekke applikasjonen i strid med kundens krav; det er derfor det også er kjent som negativ testing .
Når sluttbrukeren bruker applikasjonen tilfeldig, og han/hun kan oppdage en feil. Likevel bruker den spesialiserte testingeniøren programvaren grundig, slik at han/hun kanskje ikke identifiserer en lignende deteksjon.
Refererer til følgende for å få detaljert informasjon om Adhoc-testing:
https://www.javatpoint.com/adhoc-testing.
Sikkerhetstesting
Det er en viktig del av programvaretesting, brukt til å bestemme svakheten, risikoene eller truslene i programvareapplikasjonen.
Utførelsen av sikkerhetstesting vil hjelpe oss å unngå det ekle angrepet fra utenforstående og sikre sikkerheten til våre programvareapplikasjoner.
Med andre ord kan vi si at sikkerhetstesting hovedsakelig brukes til å definere at dataene skal være trygge og tåle programvarens arbeidsprosess.
For å få fullstendig informasjon om sikkerhetstesting, se lenken nedenfor: https://www.javatpoint.com/security-testing.
Globaliseringstesting
En annen type programvaretesting er Globaliseringstesting. Globaliseringstesting brukes til å sjekke den utviklede programvaren for flere språk eller ikke. Her, ordene globalisering betyr å opplyse applikasjonen eller programvaren for forskjellige språk.
Globaliseringstesting brukes for å sikre at applikasjonen støtter flere språk og flere funksjoner.
I dagens scenarier kan vi se forbedringen i flere teknologier ettersom applikasjonene er forberedt for bruk globalt.
Se følgende lenke for å få fullført informasjon relatert til globaliseringstestingen:
https://www.javatpoint.com/globalization-testing.
Konklusjon
I opplæringen har vi diskutert ulike typer programvaretesting. Men det er fortsatt en liste over mer enn 100+ kategorier av testing. Hver type testing brukes imidlertid ikke i alle typer prosjekter.
Vi har diskutert de mest brukte typene programvaretesting som black-box-testing, white box-testing, funksjonell testing, ikke-funksjonell testing, regresjonstesting, Adhoc-testing, etc. .
Det er også alternative klassifiseringer eller prosesser som brukes i forskjellige organisasjoner, men det generelle konseptet er likt overalt.
Disse testtypene, prosessene og utførelsestilnærmingene endres stadig når prosjektet, kravene og omfanget endres.