39 TOPP Automatiseringstest Intervjuespørsmål og svar

39 top automation testing interview questions

Ofte stilte spørsmål om automatiseringstest Intervju for nybegynnere og avanserte kandidater:

Testautomatisering spiller en veldig viktig rolle i hele programvarens livssyklus. Mesteparten av tiden når vi ønsker å forberede oss på et intervju om automatiseringstesting, fokuserer vi bare på verktøyspesifikke spørsmål.

Vi bør imidlertid også vurdere det faktum at læring og kunnskap om verktøyet bare er et middel, og det er ikke det endelige målet.

Derfor, når vi forbereder oss på et intervju om automatiseringstester, må vi vurdere 'Automasjon' som en helhet og fokusere på rammeverket og trinnene som er involvert.

Vi vet alle at programvaretesting er en veldig viktig del av programvareutvikling. Men med de raskt voksende metodikkene og miljøene for programvareutvikling blir det vanskelig å teste alt manuelt for en applikasjon innen en begrenset periode sammen med kostnadsbegrensninger.

Dermed vokser automatiseringstesting raskt i markedet for å øke hastigheten på utviklingstempoet. Denne opplæringen inkluderer topp intervjuspørsmål om automatiseringstesting. Jeg har prøvd å sitere korte og raske spørsmål som er veldig spesifikke for automatiseringen som helhet og som ikke er spesifikke for noe “verktøy”.

Topp 39 spørsmål om automatiseringstesting

Vi har dekket grunnleggende testautomatiseringsspørsmål, samt noen avanserte spørsmål for kandidater på mellomnivå til ekspertnivå med opptil 2 til 5 års erfaring.

Q # 1) Hva er automatisering?

Svar: Automatisering er enhver handling som kan redusere menneskelig innsats.

Spørsmål 2) Hva er automatiseringstesting?

Svar: Prosessen med å bruke spesielle programvareverktøy eller skript for å utføre testoppgaver som å legge inn data, utføre testtrinnene og sammenligne resultatene osv. Er kjent som automatiseringstesting.

Q # 3) Hva kan du automatisere?

Svar:

• Regresjonstest suite
• Røyk / Sanity test suite
• Bygg distribusjon
• Test dataopprettelse
• Automatisering bak GUI som testing av APIer og metoder.

Sp # 4) Når er automatiseringstesting nyttig?

Svar: Automatiseringstesting er nyttig i følgende scenarier:

a) Regresjonstesting: I tilfelle en feilretting eller implementering av en ny modul, må vi sørge for at den allerede implementerte eller uendrede funksjonaliteten ikke påvirkes. I dette tilfellet ender vi med å kjøre regresjonstestsaken flere ganger.

For eksempel: Etter hver endringsforespørsel eller feilretting, etter hver iterasjon i tilfelle trinnvis utvikling, etc.

b) Ikke-funksjonell testing: Testing av ikke-funksjonelle aspekter ved en applikasjon.

For eksempel, Lastetesting eller ytelsestesting osv. Er veldig vanskelig for mennesker å spore og analysere.

c) Kompleks beregning sjekker eller tester scenarier som er utsatt for menneskelige feil.

d) Gjentatt gjennomføring av de samme testene: Noen ganger må vi kjøre det samme settet med testtilfelle for et annet datasett eller etter hver build-utgivelse eller på flere maskinvare, programvare eller kombinasjoner av begge.

Å automatisere testsakene i ovennevnte scenarier hjelper til med å oppnå hastigheten på testing og minimere menneskelige feil.

Spørsmål nr. 5) Hvordan identifiserer du testtilfellene som er egnet for automatisering?

Svar: Å identifisere passende testtilfeller for automatisering er det viktigste trinnet mot automatisering.

Sp # 6) Kan du oppnå 100% automatisering?

Svar: 100% automatisering ville være vanskelig å oppnå fordi det ville være mange kanttesttilfeller og noen saker som utføres sjelden. Automatisering av disse sakene som ikke blir utført som ofte ikke vil gi verdi til den automatiserte suiten.

Sp # 7) Hvordan bestemme verktøyet man skal bruke til automatiseringstesting i prosjektene sine?

Svar: For å identifisere verktøyet for automatiseringstesting i prosjektet ditt:

til) Forstå prosjektkravene dine grundig og identifiser testscenariene du vil automatisere.

b) Søk etter listen over verktøy som støtter prosjektets krav.

c) Identifiser budsjettet for automatiseringsverktøyet. Velg verktøyene innenfor budsjettet.

d) Identifiser om du allerede har dyktige ressurser for verktøyene. Hvis du ikke har de nødvendige dyktige ressursene, kan du identifisere kostnadene for opplæring av eksisterende ressurser eller ansettelse av nye ressurser.

er) Sammenlign nå hvert verktøy for viktige kriterier som:

• Hvor enkelt er det å utvikle og vedlikeholde manusene til verktøyet?
• Kan en ikke-teknisk person også gjennomføre testsakene med lite trening?
• Støtter verktøyet forskjellige typer plattformer som nett, mobil, stasjonær pc, basert på prosjektkravene dine?
• Har verktøyet en testrapporteringsfunksjonalitet? Hvis ikke, er det enkelt å konfigurere for verktøyet?
• Hvordan er verktøyet for nettleserstøtte for nettbaserte applikasjoner?
• Hvor mange forskjellige testtyper kan dette verktøyet støtte?
• Hvor mange språk støtter verktøyet?

f) Når du har sammenlignet verktøyene, velger du verktøyet som er innenfor budsjettet og støtter prosjektkravene dine, og gir deg flere fordeler basert på nøkkelkriteriene nevnt ovenfor.

Sp # 8) For øyeblikket har jeg ikke noen automatisering på plass i prosjektet mitt, men nå vil jeg implementere automatisering, hva ville være trinnene mine?

Svar:

• Identifiser først hvilken type testing / testtilfeller du vil automatisere.
• Identifiser verktøyet
• Design rammeverket
• Lag verktøyfiler og miljøfiler.
• Start skripting
• Identifiser og arbeid med rapportering.
• Tildel tid til å forbedre og vedlikeholde manusene.

Fremgangsmåten som kreves for å få på plass automatiseringstesting for et prosjekt inkluderer:

• Forstå fordelene og ulempene ved automatiseringstesting og identifiser testscenariene som er egnet for automatisering.
• Velg automatiseringsverktøyet som er best egnet til å automatisere de identifiserte scenariene
• Finn verktøyeksperten som hjelper deg med å sette opp verktøyet og ønsket miljø for å utføre testsakene ved hjelp av verktøyet.
• Tren teamet slik at de kan skrive skript på programmeringsspråket som verktøyet støtter.
• Lag testrammeverket eller identifiser det allerede eksisterende som oppfyller dine krav.
• Skriv en gjennomføringsplan for operativsystem, nettlesere, mobile enheter osv.
• Skriv programmeringsskript for manuelle testsaker for å konvertere dem til automatiserte testsaker.
• Rapporter testtilstandsstatus ved å bruke rapporteringsfunksjonen til verktøyet.
• Vedlikehold skriptene for pågående endringer eller nye funksjoner.

Sp # 9) Hvordan bestemmer du hvilket verktøy du må bruke?

Svar: Avsluttende hvilket verktøy som er best egnet for prosjektet krever mye idédugnad og diskusjoner.

Spørsmål nr. 10) Hva ville være de neste trinnene dine når du har identifisert verktøyet?

Svar: Når vi er ferdig med verktøyet, vil vårt neste trinn være å designe rammeverket.

Sp # 11) Hva er et rammeverk?

Svar: Et rammeverk er et sett av strukturen til hele automatiseringsserien. Det er også en retningslinje som, hvis den følges, kan resultere i en struktur som er enkel å vedlikeholde og forbedre.

Disse retningslinjene inkluderer:

• Kodningsstandarder
• Håndtering av testdata
• Vedlikeholde og håndtere elementene (objektlager i QTP)
• Håndtering av miljøfiler og eiendomsfil
• Rapportering av data
• Håndtering av tømmerstokker

Spørsmål nr. 12) Hva er egenskapene til et godt rammeverk?

Svar: Egenskapene inkluderer:

• Modulær: Rammeverket skal kunne tilpasses endringer. Testere skal kunne endre skriptene i henhold til miljøet eller endring av påloggingsinformasjon.
• Gjenbrukbar: De vanligste metodene eller verktøyene skal skrives i en vanlig fil som er tilgjengelig for alle skriptene.
• Konsistent: Suiten skal skrives i et konsistent format ved å følge alle aksepterte kodingsrutiner.
• Uavhengig: Manusene skal skrives på en slik måte at de er uavhengige av hverandre. I tilfelle en test mislykkes, bør den ikke holde igjen de gjenværende testtilfellene (med mindre det er en påloggingsside)
• Tømmerstokker: Det er bra å ha implementert loggingsfunksjonen i rammeverket. Dette vil hjelpe hvis skriptene våre kjører i lengre timer (si nattmodus), hvis skriptet mislykkes når som helst, vil det å ha loggfilen hjelpe oss å oppdage plasseringen sammen med feiltypen.
• Rapportering: Det er bra å ha rapporteringsfunksjonen automatisk innebygd i rammeverket. Når skriptingen er ferdig, kan vi få resultatene og rapportene sendt via e-post.
• Integrering: Automation Framework bør være slik at det er enkelt å integrere med andre applikasjoner som kontinuerlig integrering eller utløse det automatiserte skriptet så snart build er distribuert.

Sp # 13) Kan du klare deg uten rammer?

Svar: Rammeverk er retningslinjer og ikke obligatoriske regler, så vi kan klare oss uten rammer, men hvis vi lager det og følger det, ville det være enkelt å implementere forbedring og vedlikehold.

Sp # 14) Hva er de forskjellige typene av automatiseringsverktøyet du er klar over?

Svar: Åpen kildekodeverktøy som Selen, JMeter, etc.

Betalte verktøy som QTP, Load Runner, Ranorex, RFT og Rational Robot.

Sp # 15) Hva er generelt strukturen til et rammeverk?

Svar: Normalt skal strukturen ha - (Det vil variere fra prosjekt til prosjekt)

• En “src” (kilde) mappe med de faktiske testskriptene.
• En ”lib” (bibliotek) mappe med alle biblioteker og vanlige metoder.
• En 'klasse' -mappe med hele klassefilen (i tilfelle bruker java).
• En 'logg' -mappe med loggfilen (e).
• En fil / mappe som har alle webelement-ID-ene.
• En fil som inneholder URL, miljø og påloggingsinformasjon.

Sp # 16) Hvor vil du opprettholde informasjon som URL, pålogging, passord?

Svar: Denne informasjonen bør alltid oppbevares i en egen fil.

Spørsmål nr. 17) Hvorfor vil du beholde denne typen informasjon i en egen fil og ikke direkte i koden?

Svar: URL, pålogging og passord er den typen felt som brukes veldig ofte, og disse endres i henhold til miljøet og autorisasjonen. I tilfelle vi kode det inn i koden vår, må vi endre det i hver fil som har referanse.

I tilfelle hvis det er mer enn 100 filer, blir det veldig vanskelig å endre alle de 100 filene, og dette kan igjen føre til feil. Så denne typen informasjon opprettholdes i en egen fil, slik at oppdateringen blir enkel.

Spørsmål nr. 18) Hva er de forskjellige typene rammer?

Svar: Ulike typer rammer inkluderer:

• Søkeorddrevet rammeverk
• Datadrevet rammeverk
• Hybrid Framework
• Lineær skripting

Q # 19) Kan du fortelle noen gode kodepraksis mens du automatiserer?

Svar: Noen av de gode kodepraksisene inkluderer:

• Legg til passende kommentarer.
• Identifiser de gjenbrukbare metodene og skriv den i en egen fil.
• Følg de språkspesifikke kodekonvensjonene.
• Vedlikehold testdataene i en egen fil.
• Kjør skriptene dine regelmessig.

Spørsmål nr. 20) Enhver form for test som du mener ikke burde automatiseres?

Svar:

• Tester som sjelden blir utført.
• Utforskende testing
• Brukervennlighetstesting
• Test som utføres raskt når du gjør det manuelt.

Q # 21) Tror du at testing bare kan gjøres på UI-nivå?

erklære statiske variabler i c ++

Svar: I dag når vi går til Agile-modus, er testing ikke begrenset til UI-laget. Tidlig tilbakemelding er viktig for et smidig prosjekt. Hvis vi bare konsentrerer oss om brukergrensesnittlaget, venter vi faktisk til brukergrensesnittet er utviklet og tilgjengelig for testing.

Snarere kan vi teste selv før brukergrensesnittet faktisk er utviklet. Vi kan teste APIene eller metodene direkte ved hjelp av verktøy som agurk og FitNesse .

På denne måten gir vi tilbakemeldingene mye tidlig og tester allerede før brukergrensesnittet er utviklet. Å følge denne tilnærmingen vil hjelpe oss å bare teste GUI-aspektet ved små kosmetiske endringer eller noen valideringer på brukergrensesnittet, og vil hjelpe utviklerne ved å gi mer tid til å fikse feilene.

Q # 22) Hvordan velger du hvilket automatiseringsverktøy som passer best for deg?

Svar: Valg av automatiseringsverktøy avhenger av forskjellige faktorer som:

• Omfanget av applikasjonen som vi vil automatisere.
• Administrasjonsomkostninger som kostnad og budsjett.
• På tide å lære og implementere verktøyet.
• Type støtte tilgjengelig for verktøyet.
• Begrensning av verktøyet

Q # 23) Hva tror du holder testerne tilbake for å gjøre automatisering? Er det en måte å overvinne det på?

Svar: Det største hinderet for testere er å lære programmering / koding når de vil automatisere. Siden testere ikke koder, er det litt utfordrende for testere å tilpasse seg koding.

Vi kan overvinne det ved å:

• Samarbeide med utviklere når de automatiserer.
• Tatt i betraktning at automatisering er hele teamets og ikke bare testernes ansvar.
• Gi en dedikert tid og fokus på automatisering.
• Få riktig ledelsesstøtte.

Du kan lagre disse spørsmålene om intervjuer om automatiseringstesting som pdf og skrive ut for videre lesing.

Q # 24) Hva er et rammeverk for automatiseringstesting?

Svar: Et rammeverk er generelt et sett med retningslinjer. Et sett med retningslinjer, antakelser, konsepter og kodingspraksis for å skape et kjøringsmiljø der testene skal automatiseres, er kjent som et rammeverk for automatiseringstesting.

Et rammeverk for automatiseringstesting er ansvarlig for å lage en testsele med en mekanisme for å koble til applikasjonen som testes, ta innspill fra en fil, utføre testsakene og generere rapportene for testutførelse. Et rammeverk for automatiseringstesting bør være uavhengig av applikasjonen, og det skal være enkelt å bruke, endre eller utvide.

Q # 25) Hva er de viktige modulene i et rammeverk for automatiseringstesting?

Svar: Viktige moduler i et automatiseringsrammeverk er:

1. Test påstand verktøy: Dette verktøyet vil gi påstander for å teste de forventede verdiene i applikasjonen som testes. For eksempel. TestNG, Junit, etc.
2. Dataoppsett: Hver testsak må ta brukerdataene enten fra databasen eller fra en fil eller innebygd i testskriptet. Frameworks datamodul bør ta seg av datainntaket for testskript og de globale variablene.
3. Build Management Tool: Rammeverk må bygges og distribueres for bruk av å lage testskripter.
4. Kontinuerlig integrasjonsverktøy: Med CICD (kontinuerlig integrasjon og kontinuerlig utvikling) på plass kreves kontinuerlig integrasjonsverktøy for å integrere og distribuere endringene som er gjort i rammeverket ved hver iterasjon.
5. Rapporteringsverktøy: Det kreves et rapporteringsverktøy for å generere en lesbar rapport etter at testsakene er utført for bedre oversikt over trinnene, resultatene og feilene.
6. Loggverktøy: Loggverktøyet i rammeverket hjelper til med å bedre feilsøking av feilen og feilene.

Spørsmål nr. 26) Forklar noen verktøy for automatiseringstesting.

Svar: Noen av de berømte testverktøyene for automatisering er forklart nedenfor:

(i) Selen : Selen er et testrammeverk for testing av automatisering av webapplikasjoner. Den støtter flere nettlesere og er operativsystemuavhengig. Selen støtter også forskjellige programmeringsspråk som Java, C #, PHP, Ruby og Perl, etc.

Selen er et open source-sett med biblioteker som kan brukes til å utvikle flere testrammer eller testskript for testing av nettbaserte applikasjoner.

(ii) UFT : Unified Functional Testing er et lisensiert verktøy for funksjonstesting. Den tilbyr et bredt spekter av funksjoner som APIer, webtjenester osv., Og støtter også flere plattformer som stasjonære maskiner, nett og mobil. UFT-skript er skrevet på visuelt grunnleggende skriptspråk.

(II) epoker : Appium er et åpen kildekode-testverktøy for mobilapplikasjoner. Den brukes til å automatisere testing på tvers av plattformer, native, hybrid og nettbaserte mobilapplikasjoner. Appium automatiserer alle mobilapplikasjoner fra hvilket som helst språk med full tilgang til APIer og DB-er fra testkoden.

Appium er basert på klientserverarkitekturen og har utviklet seg fra selen.

(iv) Agurk : Agurk er et open source atferdsdrevet utviklingsverktøy. Den brukes til nettbasert applikasjonsautomatiseringstest og støtter språk som rubin, java, scala, groovy, etc. Agurk leser kjørbar spesifikasjon skrevet i ren tekst og tester applikasjonen under test for disse spesifikasjonene.

For at agurk skal forstå scenariene i ren tekst, må vi følge noen grunnleggende syntaksregler som er kjent som Gherkin.

(v) TestComplete : TestComplete er et lisensiert automatisert UI-testverktøy for å teste applikasjonen på tvers av forskjellige plattformer som stasjonære maskiner, nett, mobil osv. Det gir fleksibilitet til å registrere en testcase i en nettleser og kjøre den i flere nettlesere og støtter dermed testing av tvers av nettlesere.

TestComplete har innebygd objektgjenkjenningsalgoritme som unikt identifiserer et objekt og lagrer det i depotet.

Spørsmål nr. 27) Hva er de forskjellige typene testrammeverksteknikker?

Svar: Det er fire typer rammeteknikker for testing av automatisering.

De er:

(i) Modular Testing framework:

Dette rammeverket er bygget på begrepet abstraksjon. I dette rammeverket oppretter testeren skript for hver modul av applikasjonen som testes individuelt, og deretter kombineres disse skriptene i den hierarkiske rekkefølgen for å lage store testtilfeller.

Det skaper et abstraksjonslag mellom modulene, og eventuelle modifikasjoner i testskriptene for en modul påvirker ikke andre moduler.

Fordeler med dette rammeverket:

• Enklere vedlikehold og skalerbarhet i testsaker.
• Det er enklere og raskere å lage testsaker ved å bruke allerede skriptmoduler.

Ulemper:

• Test tilfeller har data innebygd i dem. Dermed er å utføre det samme testskriptet med forskjellige data en stor endring på skriptnivå.

(ii) Datadrevet testrammeverk:

I det datadrevne testrammeverket lagres inngangsdataene og de forventede utdataene som tilsvarer inngangsdataene i en fil eller database, og det automatiserte skriptet kjører det samme settet med teststrinn for flere datasett. Med dette rammeverket kan vi kjøre flere testtilfeller der bare inngangsdataene er forskjellige og trinnene for utførelse er de samme.

Fordeler:

• Reduserer antall testskripter som må utføres. Vi utfører det samme skriptet flere ganger med forskjellige data.
• Mindre koding for automatiseringstesting.
• Større fleksibilitet for å vedlikeholde og fikse feilene eller forbedre funksjonaliteten.
• Testdata kan opprettes selv før det automatiserte testsystemet er klart.

Ulemper:

• Bare lignende testsaker med samme sett med utføringstrinn kan kombineres for flere datasett. De forskjellige settene med utførelsestrinn krever en annen testsak.

(iii) Søkeorddrevet testrammeverk:

Det er et applikasjonsuavhengig testrammeverk som bruker datatabeller og selvforklarende nøkkelord. Nøkkelord forklarer handlingene som skal utføres på applikasjonen som testes, og datatabellen gir inngangs- og forventede utdata.

Søkeordbasert testing er en økning i datadrevet testing.

Fordeler:

• Mindre koding og samme skript kan brukes til flere datasett.
• Automatiseringskompetanse er ikke nødvendig for å lage en testsak ved bruk av allerede eksisterende søkeord for handlinger.
• Samme nøkkelord kan brukes i flere testtilfeller.

Ulemper:

• Dette rammeverket er mer komplisert da det trenger å ta vare på søkeordhandlingene og også datainndataene.
• Testtilfeller blir lengre og kompliserte og påvirker vedlikeholdsevnen til det samme.

(iv) Hybrid Testing framework:

Dette rammeverket er en kombinasjon av alle de ovennevnte testrammene (modulær, datadrevet og søkeorddrevet).

I dette rammeverket er testsakene utviklet fra modulskript ved å kombinere dem i modulrammeverket. Hver av testtilfellene bruker et driverskript som bruker en datafil som i datadrevet rammeverk og en søkeordbasert handlingsfil.

Fordeler:

• Modulær og enkel å vedlikeholde.
• Mindre koding kan ivareta flere testsaker.
• Én testsak kan utføres med flere datasett.

Ulemper:

• Kompleks å lese, vedlikeholde og forbedre.

Spørsmål nr. 28) Når foretrekker du manuell testing framfor automatiseringstesting?

Svar: Vi foretrekker manuell testing framfor automatiseringstesting i følgende tilfeller:

• Prosjektet er kortsiktig og å skrive manus vil være tidkrevende og kostbart sammenlignet med manuell testing.
• Fleksibilitet er nødvendig. Automatiserte testsaker programmeres og kjøres på en spesifikk måte for konfigurasjoner.
• Brukervennlighetstesting må utføres.
• Søknader / modul er nylig utviklet og har ingen tidligere testtilfeller.
• Ad-hoc eller utforskende testing må utføres.

Spørsmål nr. 29) Er automatiseringstesting i smidig metodikk nyttig eller ikke?

Svar: Automatiseringstesting er nyttig for regresjon, røyk eller sunnhetstesting. Alle disse typene testing i den tradisjonelle fossemodellen skjer på slutten av syklusen, og noen ganger, hvis det ikke er mange forbedringer i applikasjonen, trenger vi ikke engang å gjøre Regresjonstesting .

Mens, i smidig metodikk , hver iterasjon krever å utføre regresjonstesttilfellet ettersom noen nye funksjoner er lagt til.

Også selve regresjonspakken vokser etter hver sprint, ettersom funksjonelle testtilfeller til den nåværende sprintmodulen må legges til regresjonspakken for neste sprint.

Dermed er automatiseringstesting i smidig metodikk veldig nyttig og hjelper til å oppnå maksimal testdekning på kortere tid etter sprinten.

Q # 30) Oppgi noen fordeler og ulemper ved automatiseringstesting.

Svar:

Fordeler:

• Færre menneskelige ressurser
• Gjenbrukbarhet
• Mer testdekning på kortere tid
• Pålitelighet
• Parallell gjennomføring av testsaker
• Fort

Ulemper:

hvordan vise eps-filer i Windows

• Utvikling og vedlikeholdstid er mer.
• Verktøyskostnad
• Dyktige ressurser kreves.
• Miljøoppsett
• Feilsøking av testskript er et problem.

Q # 31) Liste over noen fordeler og ulemper ved manuell testing.

Svar:

Fordeler:

• Ingen miljøoppsett er nødvendig.
• Programmeringskunnskap er ikke nødvendig.
• Anbefales for dynamisk skiftende krav.
• La menneskelig observasjonskraft oppdage flere feil.
• Kostnaden er mindre for kortsiktige prosjekter.
• Fleksibilitet

Ulemper:

• Vanskelig å utføre komplekse beregninger.
• Gjenbrukbarhet
• Tid tar
• Høy risiko for menneskelige feil eller feil.
• Det kreves flere menneskelige ressurser.

Spørsmål nr. 32) Kan vi gjøre automatiseringstesting uten rammer? Hvis ja, hvorfor trenger vi et rammeverk?

Svar: Ja, vi kan utføre automatiseringstesting selv uten å bruke et rammeverk. Vi kan bare forstå verktøyet vi bruker til automatisering og programmere trinnene i programmeringsspråket som verktøy støtter.

Hvis vi automatiserer testsaker uten rammer, vil det ikke være noen konsistens i programmeringsskriptene for testsaker.

Det kreves et rammeverk for å gi et sett med retningslinjer som alle må følge for å ha opprettholdt lesbarhet, gjenbrukbarhet og konsistens i testskriptene. Et rammeverk gir også et felles grunnlag for funksjonalitet for rapportering og logging.

Sp # 33) Hvordan automatiserer du grunnleggende testtilfeller for 'pålogging' for en applikasjon?

Svar: Forutsatt at automatiseringsverktøyet og rammeverket allerede er i stedet for testmiljøet.

Slik tester du den grunnleggende funksjonen 'Innlogging':

• Forstå prosjektkravet : Innloggingsfunksjonalitet vil ha et brukernavn tekstboks, et passord tekstboks og en påloggingsknapp.
• Identifiser testscenariene: For påloggingsfunksjonalitet er de mulige testscenariene:
  • Tomt brukernavn og passord
  • Ugyldig brukernavn og passord
  • Et gyldig brukernavn og ugyldig passord
  • Gyldig brukernavn og passord
• Forbered en Datainndatafil med dataene som tilsvarer hvert scenario.
• Start verktøyet fra programmet.
• Identifiser brukernavnfeltet, passordfeltet og påloggingsknappen.
• For hvert testscenario, få dataene fra datafilen og skriv inn de tilsvarende feltene. Programmet klikker på påloggingsknappen etter å ha tastet inn dataene.
• Validere feilmeldingen for negative scenarier og suksessmeldingen for positive scenarier i testskriptet ved hjelp av påstander.
• Løpe testpakken og generere rapporten.

Q # 34) Er automatiseringstesting en Blackbox-testing eller White-Box-testing?

Svar: Automatiseringstesting er stort sett en black box testing ettersom vi bare programmerer trinnene som en manuell tester utfører for applikasjon under test uten å kjenne applikasjonen på lavt nivå eller koden.

Noen ganger trenger automatiserte testskripter tilgang til databasedetaljene som brukes i applikasjonen som testes, eller noen flere kodingsdetaljer, og kan derfor være en type hvitbokstesting.

Dermed kan automatisert testing være både svart eller hvit boks type testing, avhengig av scenariene der automatiseringen utføres.

Spørsmål nr. 35) Hvor mange testsaker har du automatisert per dag?

Svar: Antall avhenger av kompleksiteten i testsakene. Da kompleksiteten var begrenset, klarte jeg å automatisere 5 til 6 testsaker per dag. Noen ganger klarte jeg å automatisere bare en testtilfelle for komplekse scenarier.

Jeg har også delt ned testtilfellene mine i forskjellige komponenter som, ta input, gjøre beregningen, verifisere output etc. i tilfelle svært komplekse scenarier og har tatt 2 eller flere dager.

Spørsmål nr. 36) Hvilke faktorer bestemmer effektiviteten av automatiseringstesting?

Svar: Noen av faktorene som bestemmer effektiviteten av automatiseringstesting er:

• Tidsbesparelse ved å kjøre skript over manuell gjennomføring av testsaker.
• Feil funnet
• Test dekning eller kodedekning
• Vedlikeholdstid eller utviklingstid
• Skriptets stabilitet
• Test gjenbrukbarhet
• Kvaliteten på programvaren som testes

Spørsmål nr. 37) Hvilke testsaker kan automatiseres?

Svar: Typer av testsaker som kan automatiseres er:

(i) Røykprøvesaker: Røykprøving er også kjent som byggverifiseringstesting. Røykprøvesaker kjøres hver gang en ny versjon frigjøres for å kontrollere helsen til bygningen for å bli godkjent for å utføre testing.

(ii) tilfeller med regresjonstest : Regresjonstesting er testen for å sikre at tidligere utviklede moduler fungerer som forventet etter at en ny modul er lagt til eller en feil er løst.

Regresjonstesttilfeller er veldig avgjørende i trinnvis programvaretilnærming der en ny funksjonalitet blir lagt til i hver trinnfase. I dette tilfellet utføres regresjonstesting i hver inkrementelle fase.

(iii) Komplekse beregningstesttilfeller: Test tilfeller som involverer noen komplekse beregninger for å verifisere et felt for en applikasjon faller inn i denne kategorien. Komplekse beregningsresultater er mer utsatt for menneskelige feil, og når de automatiseres, gir de nøyaktige resultater.

(iv) Datadrevne testtilfeller: Testtilfeller som har samme sett med trinn og kjører flere ganger med endring av data, er kjent som datadrevne testtilfeller. Automatisert testing for denne typen testsaker er rask og kostnadseffektiv.

(v) Ikke-funksjonelle testsaker : Testtilfeller som belastningstester og ytelsestester krever et simulert miljø med flere brukere og flere maskinvare- eller programvarekombinasjoner.

Å sette opp flere miljøer manuelt er umulig for hver kombinasjon eller antall brukere. Automatiserte verktøy kan enkelt skape dette miljøet for å utføre ikke-funksjonell testing enkelt.

Spørsmål nr. 38) Hva er fasene i automatiseringstesting av livssyklus?

Svar: Fasene i automatiseringstestets livssyklus inkluderer:

1. Beslutningen om å utføre automatiseringstesting.
2. Identifiser og lær om automatiseringsverktøyet.
3. Bestem omfanget av automatiseringstesting.
4. Design og utvikle en testpakke.
5. Testutførelse
6. Vedlikehold av testskript.

Q # 39) Hva er et automatisert testskript?

Svar: Et automatisert testskript er et kort program som er skrevet på et programmeringsspråk for å utføre et sett med instruksjoner på et program som testes for å verifisere om applikasjonen er i samsvar med kravene.

Dette programmet når det kjøres, gir testresultatene som bestått eller ikke avhenger av om applikasjonen er som forventet.

Konklusjon

Dette er hovedspørsmålene som er uavhengige av automatiseringsverktøyet eller programmeringsspråket. Automatiseringstestintervjuer inkluderer også verktøy- og programmeringsspråkspesifikke spørsmål, avhengig av verktøyet du har jobbet med.

De fleste spørsmål om testautomatiseringsintervju er sentrert om rammeverket du utvikler, så det anbefales at du oppretter og forstår testrammeverket ditt grundig. Når jeg intervjuer, og kandidaten har svart på spørsmålet mitt om rammeverket, foretrekker jeg også å stille et språkspesifikt spørsmål (core Java i mitt tilfelle).

Spørsmålene starter fra det grunnleggende i Java for å skrive logikken til et grunnleggende scenario som:

• Hvordan vil du trekke ut et sett med tekst fra en gitt linje?
• Hvordan vil du trekke ut URL-en?
• På hvilken som helst webside, i hvilken som helst ramme, endres antall lenker og innholdet dynamisk, hvordan vil du håndtere det?
• Hvordan håndterer du bilder og blitsobjekter?
• Hvordan finner du et ord i en linje?

Svar på alle disse test automatiseringsintervju spørsmål er veldig spesifikke for verktøyet / språket du bruker for å automatisere. Så før du går til intervjuet, børst opp programmeringsferdighetene dine.

I tilfelle du ikke fikk sjansen til å lage rammeverket ditt og noen andre har laget det, så bruk litt tid til å forstå det grundig før du setter deg til intervjuet.

Noen tips for intervjuer om automatiseringstesting vil være:

• Kjenn verktøyet ditt grundig.
• Lær deg lokaliseringsteknikkene som brukes av verktøyet ditt.
• Øv på programmering med språket du bruker til automatiseringstesting.
• Lær rammeverket ditt og dets komponenter.
• Det er alltid fordelaktig hvis du har vært involvert i utviklingen av rammeverket ditt. Så vær grundig med modulene i rammeverket du har jobbet med.

Håper disse spørsmålene vil være nyttige for deg å forberede deg på et testautomatiseringsintervju.

Anbefalt lesing

• Intervju spørsmål og svar
• ETL Testing Intervju Spørsmål og svar
• Noen interessante intervjusspørsmål om programvaretesting
• 25 beste spørsmål om svar og svar på smidig testing
• Topp 20 viktigste API-tester Intervju spørsmål og svar
• Spørsmål og svar om programvaretesting (del 1)
• Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
• Topp 30 sikkerhetstestintervju og spørsmål