Topp 25 Funksjonstesting Intervju Spørsmål og svar

top 25 functional testing interview questions

Ofte stilte spørsmål og svar om funksjonstestintervju:

Som selve navnet definerer, er funksjonell testing prosessen med å teste en applikasjon med hensyn til kravspesifikasjonene.

Funksjonell testing kan utføres enten manuelt eller gjennom automatisering, men hver prosess inkluderer testing av applikasjonen ved å gi et sett med innganger og bestemme eller verifisere resultatet / utgangen ved å sammenligne det faktiske resultatet med de forventede resultatene.

Funksjonell testing har forskjellige faser som skal vurderes under testing. I denne artikkelen vil vi se flere intervjuspørsmål og svar som vil hjelpe deg å forberede deg godt.

De mest populære spørsmålene om funksjonstesting

Q # 1) Hva forstår du med begrepet ‘Funksjonstesting’?

Svar: En svart boks testteknikk, der funksjonaliteten til en applikasjon blir testet for å generere ønsket output ved å levere visse input kalles ‘Functional testing’.

Funksjonstestingens rolle er ikke bare å validere oppførselen til applikasjonen i henhold til kravspesifikasjonene, men er også å verifisere om applikasjonen er klar til å bli frigitt i det levende miljøet eller ikke.

Nedenfor er noen funksjonelle testteknikker som ofte brukes:

• Enhetstesting
• Røykprøving
• Integrasjonstesting
• Systemtesting
• Brukervennlighetstesting
• Regresjonstesting
• Brukeraksept testing

Q # 2) Hva er de viktige trinnene som dekkes i funksjonstesting?

Svar: Følgende er trinnene som skal dekkes som en del av funksjonstesting:

• Forstå kravspesifikasjonene og fjerne tvil og spørsmål i form av gjennomgangskommentarer.
• Skrive testsaker med hensyn til kravspesifikasjonen ved å huske på alle scenariene som bør vurderes for alle sakene.
• Identifisere testinngangene og be om testdataene som kreves for å utføre testsakene, samt for å sjekke funksjonaliteten til applikasjonen.
• Bestem de faktiske resultatene i henhold til inngangsverdiene som skal testes.
• Utfør testsakene som avgjør om applikasjonsatferd er som forventet eller om det har oppstått en feil.
• Sammenlign det faktiske resultatet og det beregnede resultatet for å finne ut det faktiske resultatet.

Q # 3) Forklar forskjellen mellom funksjonstesting og ikke-funksjonell testing.

Svar: Forskjellen mellom funksjonstesting og ikke-funksjonell testing kan forklares som nedenfor:

Sp # 4) Hvordan er 'Build' forskjellig fra 'Release'?

Svar: Bygg er en kjørbar fil som refererer til den delen av et program som blir overlevert til en tester for å teste den implementerte funksjonaliteten til applikasjonen sammen med noen feilrettinger. Bygget kan avvises av testteamet hvis det ikke består den kritiske sjekklisten som inneholder hovedfunksjonaliteten til applikasjonen.

Det kan være flere bygninger i testsyklusen til et program.

Utgivelse refererer til programvareapplikasjonen som ikke lenger er i testfasen, og etter fullført testing og utvikling blir applikasjonen overlevert til klienten. Én utgivelse har flere bygninger tilknyttet.

Q # 5) Forklar feilsyklusen.

Svar: Feil sies å være en uønsket feil, feil, feil osv. Som har skjedd i applikasjonen og forhindrer at den leverer ønsket utdata. Når det oppdages en feil eller en feil i et program mens du tester, beveger en feil seg fra en loggføring til en oppløsning gjennom en bestemt livssyklus kjent som Bug Lifecycle.

Figuren nedenfor gir deg en ide om Bug livssyklus:

(bilde kilde )

Hele prosessen går når det oppstår et problem eller en feil. Det rapporteres / logges på feilsporingsverktøy i et betydelig format. Disse feilene tildeles utvikleren, og statusen blir gjort som 'Åpen'. Utvikler kan nå gjennomgå feilen, reprodusere den på slutten og begynne å jobbe med den.

Hvis feilen er løst, endrer utvikleren statusen til 'Fixed', eller statusen kan flyttes til 'trenger mer informasjon', 'vil ikke fikse', 'kan ikke reprodusere' osv., I andre tilfeller. QA utfører deretter regresjon, dvs. bekreft feilene med en spesifikk handling og svar deretter.

Hvis problemene / feilen nå oppfører seg som forventet, endres statusen til Bekreftet / Lukket ellers Åpne igjen.

Q # 6) Bruk noen feilstatus sammen med beskrivelsen.

c ++ udefinert referanse til funksjon i topptekstfilen

Svar: Nedenfor er det få feilstatus sammen med beskrivelsene:

• Ny: Når feilen eller feilen logges for første gang, blir den sagt som Ny.
• Tildelt: Etter at testeren har logget en feil, blir feilen hans gjennomgått av testledningen, og deretter tilordnes den til det tilsvarende utviklerteamet.
• Åpen: Tester logger en feil i åpen tilstand, og den forblir i åpen tilstand til utvikleren har utført noen oppgaver på den feilen.
• Løst / løst: Når en utvikler har løst feilen, dvs. nå produserer applikasjonen ønsket utdata for et bestemt problem, endrer utvikleren statusen til Løst / løst.
• Bekreftet / stengt: Når en utvikler har endret statusen til å være løst / løst, tester testeren nå problemet på slutten, og hvis det er løst, endrer han status for feilen til 'Bekreftet / Lukk'.
• Åpne igjen: Hvis en tester er i stand til å reprodusere feilen igjen, dvs. feilen fortsatt eksisterer selv etter at den er løst av utvikleren, er statusen merket som Åpne igjen.
• Ikke en feil / ugyldig: En feil kan merkes som ugyldig eller ikke en feil av utvikleren når det rapporterte problemet er i samsvar med funksjonaliteten, men er logget på grunn av feiltolkning.
• Utsatt: Vanligvis når feilen har minimal prioritet for utgivelsen, og hvis det mangler tid, blir de minimale prioritetsfeilene i så fall utsatt til neste utgivelse.
• Kan ikke reprodusere: Hvis utvikleren ikke klarer å reprodusere feilen på slutten, følger du trinnene som nevnt i problemet.

Q # 7) Hva er kjent som datadrevet testing?

Svar: Datadrevet testing er metodikken der en serie testskript som inneholder testtilfeller utføres gjentatte ganger ved hjelp av datakilder som Excel-regneark, XML-fil, CSV-fil, SQL-database for inndataverdier, og den faktiske utgangen sammenlignes med den forventede i bekreftelsen prosess.

For eksempel, et teststudio brukes til datadrevet testing.

Noen fordeler med datadrevet testing er:

• Gjenbrukbarhet.
• Repeterbarhet.
• Test dataseparasjon fra testlogikk.
• Antall testsaker reduseres.

Sp # 8) Hva er de viktige punktene som bør vurderes når du skriver testsaker?

Svar: Å skrive en testsak sies å være den viktigste aktiviteten i testgjennomføringsprosessen som krever skrivekunnskaper, samt inngående kunnskap om applikasjonen for å lage effektive og gjenbrukbare testsaker.

Få viktige punkter som bør vurderes når du skriver testsaker inkluderer:

• Det bør være en klar forståelse av klientens krav før du begynner å skrive testsakene. Ingenting skal antas, og enhver tvil angående kravene bør fjernes.
• Hvert krav bør inkluderes i form av testtilfeller, og ingenting skal utelates. Vanligvis opprettholdes sporbarhetsmatrisen for å kontrollere hver implementering og testing av alle krav.
• I henhold til kravspesifikasjonene, skal alle funksjonelle og ikke-funksjonelle krav inkludert UI-grensesnitt, kompatibilitet dekkes.
• Testtilfeller bør sjekkes innimellom for gjentakelse eller redundans.
• Prioritet er en viktig faktor som bør settes for testsaker mens du skriver. Denne prioriteten hjelper testeren til å teste applikasjonen først med tester med høy prioritet som inkluderer grunnleggende funksjonalitet, deretter medium og senere lavprioritetssaker.
• For en bestemt utgivelse kan testsaker også bygges Sprint klokt slik at testeren, så vel som utvikleren, kan analysere kvaliteten på produktet basert på utførelse av testsaken.
• Strukturen i testsaker skal være lett forståelig og må være på et enkelt språk. Inndataverdiene for testtilfeller bør være gyldige så vel som i et bredt spekter.

Sp # 9) Hva er automatiseringstesting?

Svar: Automatiseringstesting er en testmetodikk der et automatiseringsverktøy brukes til å utføre testsaken for å øke testdekningen samt hastigheten til å utføre testen. Automatiseringstesting krever ingen menneskelig inngripen da den utfører forhåndsskriptede tester og er i stand til å rapportere og sammenligne resultater med tidligere testkjøringer.

Repeterbarhet, brukervennlighet, nøyaktighet og større konsistens er noen av fordelene med automatiseringstesting.

Noen automatiseringsprøveverktøy er oppført nedenfor:

• Selen
• Tellurium
• vann
• SÅPE

Q # 10) Forklar begrepet stresstesting og belastningstesting.

Svar:

Stresstesting er en form for ytelsestesting der applikasjonen er nødt til å gå gjennom anstrengelse eller stress, dvs. gjennomføring av applikasjon over terskelen for pause for å bestemme punktet der applikasjonen krasjer. Denne tilstanden oppstår vanligvis når det er for mange brukere og for mye data.

Stresstesting verifiserer også applikasjonsgjenoppretting når arbeidsbelastningen reduseres.

Lastetesting er en form for ytelsestesting der applikasjonen kjøres over forskjellige belastningsnivåer for å overvåke toppytelsen til serveren, responstid, servergjennomstrømning etc. Gjennom lastetesting blir prosessstabilitet, ytelse og integritet av applikasjonen bestemt under samtidig systembelastning .

Spørsmål nr. 11) Hva forstår du med volumtesting?

Svar: Volumtesting er en form for ytelsestesting som bestemmer ytelsesnivåene til serverens gjennomstrømning og responstid når samtidige brukere, samt stor datalast fra databasen, blir satt på systemet / applikasjonen under tester.

Sp # 12) Hva er de forskjellige testteknikkene som brukes i funksjonstesting?

Svar: Det er to forskjellige testteknikker som brukes i funksjonstesting.

De kan defineres som nedenfor:

• Kravbasert testing: Denne formen for funksjonell testing utføres med prioritering av kravene på grunnlag av risikokriterier. Dette forsikrer også at alle de kritiske testbanene er inkludert i testprosessen.
• Bedriftsprosessbasert testing: Denne formen for funksjonell testing utføres fra forretningsprosessperspektivet. Scenariene inkluderer kunnskap om forretningsprosesser for å utføre testing.

Q # 13) Hva forstår du med Exploratory Testing? Når utføres den?

Svar: Utforskende testing betyr å teste eller utforske applikasjonen uten å følge noen tidsplaner eller prosedyrer. Mens de utfører undersøkende tester, følger ikke testere noe mønster og bruker tankegangen og mangfoldige ideer for å se hvordan applikasjonen fungerer.

Å følge denne prosessen dekker selv den minste delen av applikasjonen og hjelper med å finne flere problemer / feil enn i den normale testprosessen.

Utforskende testing utføres vanligvis i tilfeller der:

• Det er en erfaren tester i testteamet som kan bruke testopplevelsen til å bruke alle de beste mulige scenariene.
• Alle kritiske baner er dekket, og store testtilfeller er utarbeidet i henhold til kravspesifikasjonene som er utført.
• Det er en kritisk applikasjon, og ingen mulige tilfeller kan i alle fall savnes.
• Ny tester har kommet inn i teamet. Å utforske applikasjonen vil hjelpe dem å forstå bedre, så vel som de vil følge sitt eget sinn mens de utfører ethvert scenario i stedet for å følge banen som nevnt i kravdokumentet.

Q # 14) Hva er de mulige påloggingsfunksjonene som skal testes for alle webapplikasjoner?

Svar: Oppført nedenfor er mulige scenarier som kan utføres for å teste påloggingsfunksjonen til ethvert program fullt ut:

• Sjekk inntastingsfeltene, dvs. brukernavn og passord med både gyldige og ugyldige verdier.
• Prøv å angi gyldig e-post-ID med feil passord, og skriv også inn en ugyldig e-postadresse og gyldig passord. Se etter riktig feilmelding som vises.
• Skriv inn gyldig legitimasjon og bli logget på applikasjonen. Lukk og åpne nettleseren på nytt for å sjekke om du fortsatt er logget på.
• Gå inn i applikasjonen etter innlogging, og naviger deretter tilbake til påloggingssiden for å sjekke om brukeren blir bedt om å logge på igjen eller ikke.
• Logg på fra en nettleser og åpne applikasjonen fra en annen nettleser for å bekrefte om du også er logget på en annen nettleser.
• Endre passord etter å ha logget på applikasjonen, og prøv deretter å logge på med det gamle passordet.

Det er få andre mulige scenarier som også kan testes.

Sp # 15) Forklar tilgjengelighetsprøving og dens betydning i dette scenariet.

Svar: Tilgjengelighetsprøving er en form for brukervennlighetstesting der testing utføres for å sikre at applikasjonen lett kan håndteres av mennesker med nedsatt funksjonsevne som hørsel, fargeblindhet, dårlig synlighet osv. I dagens scenario har nettet fått den største plassen i livet vårt i form av e-handelsnettsteder, e-læring, e-betaling osv.

For å vokse bedre i livet, bør alle kunne være en del av teknologien, spesielt mennesker med noen funksjonshemninger.

Nedenfor er noen få typer programvare som hjelper og hjelper personer med nedsatt funksjonsevne å bruke teknologi:

• Programvare for talegjenkjenning
• Skjermleserprogramvare
• Skjermforstørrelsesprogramvare
• Spesielt tastatur

Spørsmål nr. 16) Hva er Adhoc-testing?

Svar: Adhoc-testing, vanligvis kjent som tilfeldig testing, er en form for testing som ikke følger noen testtilfeller eller krav til applikasjonen. Adhoc-testing er i utgangspunktet en ikke-planlagt aktivitet der en hvilken som helst del av applikasjonen blir tilfeldig kontrollert for å finne feil.

I slike tilfeller er feilene veldig vanskelige å reprodusere, da ingen planlagte testsaker følges. Adhoc-testing utføres vanligvis når det er begrenset tid til å utføre omfattende testing.

Sp # 17) Hva er ekvivalenspartisjonering?

Svar: Partisjonering av ekvivalens, også kjent som partisjonering av ekvivalensklasse, er en form for black-box testing der inngangsdata blir delt inn i dataklasser. Denne prosessen gjøres for å redusere antall testtilfeller, men dekker likevel maksimalkravet.

Ekvivalenspartisjoneringsteknikk brukes der inngangsverdier kan deles inn i områder. Området for inngangsverdiene er definert på en slik måte at bare en tilstand fra hver rekkevidde skal testes forutsatt at alle de andre forholdene til den samme partisjonen vil oppføre seg likt for programvaren.

For eksempel: For å identifisere rente per saldo på kontoen, kan vi identifisere omfanget av saldobeløpet på kontoen som tjener en annen rente.

Q # 18) Forklar grenseverdianalyse.

Svar: Grenseverdianalysemetode sjekker grenseverdiene til ekvivalensklassepartisjoner. Grenseverdianalyse er i utgangspunktet en testteknikk som identifiserer feilene ved grensene i stedet for innenfor verdiene for området.

For eksempel , Et inntastingsfelt kan tillate minimum 8 tegn og maksimalt 12 tegn, så regnes 8-12 som det gyldige området og 13 betraktes som det ugyldige området. Følgelig er testtilfellene skrevet for gyldig partisjonsverdi, nøyaktig grenseverdi og ugyldig partisjonsverdi.

Q # 19) Forklar forskjellen mellom alvorlighetsgrad og prioritet.

Svar: Defekt alvorlighetsgrad er definert av nivået eller graden av innvirkning av mangelen på applikasjonen som testes. Jo høyere alvorlighetsgraden av mangelen er, desto mer er virkningen på applikasjonen.

Følgende er de fire klassene der en mangel alvorlighetsgrad er kategorisert:

• Kritisk
• Major
• Medium
• Lav

Feilprioritet definerer i hvilken rekkefølge feilen skal løses først, dvs. jo høyere prioritet til mangelen innebærer at applikasjonen er ubrukelig eller sitter fast på et tidspunkt, og mangelen skal løses så snart som mulig.

Følgende er de tre klassene der en defektprioritet er definert:

• Høy
• Medium
• Lav

Spørsmål nr. 20) Når utfører vi røykprøving?

Svar: Røykprøving utføres på applikasjonen etter mottak av bygningen. Tester tester vanligvis for den kritiske banen og ikke dyp funksjonalitet for å være sikker på om build skal aksepteres for videre testing eller for å bli avvist i tilfelle brukket program.

En røyksjekkliste inneholder vanligvis den kritiske banen til applikasjonen uten hvilken applikasjon er blokkert.

Spørsmål nr. 21) Hva forstår du med Sanity-testing?

Svar: Sanity testing utføres etter å ha mottatt build for å sjekke den nye funksjonaliteten / feilene som skal løses. I denne formen for testing er målet å kontrollere funksjonaliteten omtrent som forventet og avgjøre om feilen er løst, og også effekten av den faste feilen på applikasjonen som testes.

Det nytter ikke å akseptere byggingen av testeren og kaste bort tid hvis Sanity-testing mislykkes.

Spørsmål nr. 22) Hva forstår du med kravsporbarhetsmatrise?

Svar: Kravsporbarhetsmatrise (RTM) er et verktøy for å holde oversikt over kravsdekning over testprosessen.

I RTM kategoriseres alle krav som deres utvikling i løpet av sprint, og deres respektive IDer (implementering / forbedring av nye funksjoner / tidligere utgaver osv.) Opprettholdes for å holde oversikt over at alt nevnt i kravdokumentet er implementert før utgivelsen av produktet.

RTM opprettes så snart kravdokumentet er mottatt og vedlikeholdes til utgivelsen av produktet.

Spørsmål nr. 23) Hva er faktorene som skal vurderes i risikobasert testing?

Svar: Ved risikobasert testing av et prosjekt er det ikke bare å levere et prosjekt risikofritt, men hovedmålet med risikobasert testing er å oppnå prosjektresultatet ved å utføre beste praksis for risikostyring.

De viktigste faktorene som skal vurderes i risikobasert testing er som følger:

• Å identifisere når og hvordan du implementerer risikobasert testing på en passende applikasjon.
• Å identifisere tiltak som fungerer godt for å finne og håndtere risiko i kritiske områder av applikasjonen.
• For å oppnå prosjektresultatet som balanserer risiko med kvaliteten og funksjonen til applikasjonen.

Q # 24) Skille mellom regresjonstesting og re-testing.

Svar: Forskjellen mellom regresjonstesting og omprøving kan forklares som følger:

Q # 25) Forklar testing av brukertillatelse.

Svar: Test av brukeraksept utføres vanligvis etter at produktet er grundig testet. I denne testformen bruker programvarebrukere eller si klient selve applikasjonen for å sikre at alt fungerer som det er kravet og perfekt i den virkelige verden.

UAT er også kjent som sluttbrukertesting.

Konklusjon

Gjennom denne artikkelen har jeg prøvd å forklare hvert tema for funksjonstesting, slik at enhver som forbereder seg til intervjuet enkelt kan forstå emnet og huske dem også.

Disse spørsmålene og svarene på intervjuer om funksjonell testing vil lede deg til å fjerne ethvert intervju med full tillit.

Vi ønsker deg lykke til.

hvordan åpne apk-filer på Android-telefon

Jeg håper disse funksjonelle testintervjuspørsmålene og -svarene vil hjelpe deg på et eller annet tidspunkt i karrieren din.

Anbefalt lesing

• Funksjonstesting mot ikke-funksjonell testing
• 16 Nye funksjoner i Micro Focus UFT (Unified Functional Testing) Tool - QTP vs UFT
• 5 beste HP Unified Functional Testing (UFT) alternative verktøy
• En komplett ikke-funksjonell testveiledning for nybegynnere
• En trinnvis guide til Jubula - Open Source Automated Functional Testing Tool
• Funksjonstesting mot ytelsestesting: Bør det gjøres samtidig?
• Komplett funksjonell testguide med typer og eksempel
• Parrot QA Tutorial: Cross Browser Functional Testing Tool Review
• Spock for integrering og funksjonstesting med selen
• Forskjellene mellom enhetstesting, integrasjonstesting og funksjonstesting
• Topp 25 Funksjonstesting Intervju Spørsmål og svar
• Topp 30 funksjonelle testverktøy i 2021