39 TOP Automation Testing Interview Spørgsmål og svar

39 top automation testing interview questions

Ofte stillede spørgsmål om automatiseringstest Interviewspørgsmål til kandidater til begyndere og avancerede niveau:

Testautomatisering spiller en meget vigtig rolle i hele softwarelevecyklussen. Det meste af tiden, når vi ønsker at forberede os til et automatiseringsprøvningssamtale, fokuserer vi kun på værktøjsspecifikke spørgsmål.

Vi skal dog også overveje det faktum, at indlæring og kendskab til værktøjet bare er et middel, og det er ikke det ultimative mål.

Så når vi forbereder os på et automatiseringstestersamtale, skal vi overveje 'Automation' som en helhed og fokusere på rammerne og de involverede trin.

Vi ved alle, at test af software er en meget vigtig del af softwareudvikling. Men med de hurtigt voksende softwareudviklingsmetoder og miljøer bliver det vanskeligt manuelt at teste alt for en applikation inden for en begrænset periode sammen med omkostningsbegrænsninger.

Således vokser automatiseringstesten hurtigt på markedet for at fremskynde udviklings tempoet. Denne vejledning inkluderer de vigtigste interviewspørgsmål om automatiseringstest. Jeg har forsøgt at citere de korte og hurtige spørgsmål, som er meget specifikke for automatiseringen som helhed og ikke er specifikke for noget ”værktøj”.

Top 39 Interviewtest om automatiseringstest

Vi har dækket grundlæggende testautomatiseringsspørgsmål samt nogle avancerede spørgsmål til kandidater på mellemniveau til ekspertniveau med op til 2 til 5 års erfaring.

Q # 1) Hvad er automatisering?

Svar: Automatisering er enhver handling, der kan reducere menneskelig indsats.

Q # 2) Hvad er automatiseringstest?

Svar: Processen med at bruge specielle softwareværktøjer eller scripts til at udføre testopgaver såsom indtastning af data, udførelse af testtrin og sammenligning af resultater osv. Er kendt som Automation-test.

Q # 3) Hvad alle ting kan du automatisere?

Svar:

• Suite til regressionstest
• Røg / Sanity test suite
• Byg implementering
• Test oprettelse af data
• Automatisering bag GUI som test af API'er og metoder.

Spørgsmål nr. 4) Hvornår er automatiseringstest nyttig?

Svar: Automatiseringstest er nyttigt i følgende scenarier:

a) Regressionstest: I tilfælde af en fejlrettelse eller implementering af et nyt modul skal vi sikre os, at den allerede implementerede eller uændrede funktionalitet ikke påvirkes. I dette tilfælde kører vi regressionstestsagen flere gange.

For eksempel: Efter hver ændringsanmodning eller fejlrettelse, efter hver iteration i tilfælde af trinvis udviklingsmetode osv.

b) Ikke-funktionel testning: Test af de ikke-funktionelle aspekter af en applikation.

For eksempel, Belastningstest eller ydelsestest osv. Er meget vanskeligt for mennesker at spore og analysere.

c) Kompleks beregning kontroller eller testscenarier, der er tilbøjelige til menneskelige fejl.

d) Gentagen udførelse af de samme tests: Nogle gange er vi nødt til at køre det samme sæt testsag for et andet datasæt eller efter hver buildudgivelse eller på flere hardware, software eller kombinationer af begge.

Automatisering af testsagerne i ovenstående scenarier hjælper med at opnå testens hastighed og minimere menneskelige fejl.

Spørgsmål nr. 5) Hvordan identificerer du de testsager, der er egnede til automatisering?

Svar: Identifikation af de relevante testsager til automatisering er det vigtigste skridt mod automatisering.

Q # 6) Kan du opnå 100% automatisering?

Svar: 100% automatisering ville være vanskeligt at opnå, fordi der ville være mange kanttestsager og nogle sager, der udføres sjældent. Automatisering af disse sager, der ikke udføres, som ofte ikke tilføjer værdi til den automatiserede suite.

Spørgsmål nr. 7) Hvordan vælger man det værktøj, man skal bruge til automatiseringstest i deres projekter?

Svar: For at identificere værktøjet til automatiseringstest i dit projekt:

til) Forstå dine projektkrav grundigt og identificer de testscenarier, du vil automatisere.

b) Søg efter listen over værktøjer, der understøtter dit projekts krav.

c) Identificer dit budget til automatiseringsværktøjet. Vælg værktøjerne inden for dit budget.

d) Identificer, om du allerede har dygtige ressourcer til værktøjerne. Hvis du ikke har de nødvendige kvalificerede ressourcer, skal du identificere omkostningerne ved at træne de eksisterende ressourcer eller ansætte nye ressourcer.

er) Sammenlign nu hvert værktøj for nøglekriterier som:

• Hvor let er det at udvikle og vedligeholde scripts til værktøjet?
• Kan en ikke-teknisk person også udføre testsagerne med lidt træning?
• Understøtter værktøjet forskellige typer platforme som web, mobil, desktop osv. Baseret på dine projektkrav?
• Har værktøjet en testrapporteringsfunktionalitet? Hvis ikke, kan det let konfigureres til værktøjet?
• Hvordan er værktøjet til understøttelse på tværs af browseren til webbaserede applikationer?
• Hvor mange forskellige testtyper kan dette værktøj understøtte?
• Hvor mange sprog understøtter værktøjet?

f) Når du har sammenlignet værktøjerne, skal du vælge det værktøj, der ligger inden for dit budget, og understøtte dine projektkrav og give dig flere fordele baseret på de ovennævnte nøglekriterier.

Q # 8) I øjeblikket har jeg ikke nogen automatisering på plads i mit projekt, men nu vil jeg implementere automatisering, hvad ville være mine trin?

Svar:

• Identificer først, hvilken type test / test-sager du vil automatisere.
• Identificer værktøjet
• Design rammen
• Opret hjælpefiler og miljøfiler.
• Start scripting
• Identificer og arbejd med rapportering.
• Tildel tid til forbedring og vedligeholdelse af scripts.

De nødvendige skridt til at få automatiseringstest på plads for et projekt inkluderer:

• Forstå fordele og ulemper ved automatiseringstest og identificer de testscenarier, der er egnede til automatisering.
• Vælg det automatiseringsværktøj, der er bedst egnet til automatisering af de identificerede scenarier
• Find værktøjsexperten til at hjælpe med opsætningen af ​​værktøjet og det krævede miljø til udførelse af testsagerne ved hjælp af værktøjet.
• Træn holdet, så de kan skrive scripts på det programmeringssprog, som værktøjet understøtter.
• Opret testrammen eller identificer den allerede eksisterende, der opfylder dine krav.
• Skriv en udførelsesplan for OS, browsere, mobile enheder osv.
• Skriv programmeringsskripter til manuelle testsager for at konvertere dem til automatiserede testsager.
• Rapporter testtilstandsstatus ved hjælp af værktøjets rapporteringsfunktion.
• Vedligehold scripts til løbende ændringer eller nye funktioner.

Spørgsmål nr. 9) Hvordan beslutter du, hvilket værktøj du skal bruge?

Svar: Afslutning hvilket værktøj der er bedst egnet for projektet kræver en masse brainstorming og diskussioner.

Spørgsmål nr. 10) Når du har identificeret værktøjet, hvad ville være dine næste trin?

Svar: Når vi er færdige med værktøjet, er vores næste skridt at designe rammen.

Spørgsmål nr. 11) Hvad er en ramme?

Svar: En ramme er et sæt af strukturen i hele automatiseringspakken. Det er også en retningslinje, som, hvis den følges, kan resultere i en struktur, der er let at vedligeholde og forbedre.

Disse retningslinjer inkluderer:

• Kodningsstandarder
• Håndtering af testdata
• Vedligeholdelse og håndtering af elementerne (objektlager i QTP)
• Håndtering af miljøfiler og egenskabsfil
• Rapportering af data
• Håndtering af logfiler

Spørgsmål nr. 12) Hvad er egenskaberne ved en god ramme?

Svar: Karakteristika inkluderer:

• Modulær: Rammen skal kunne tilpasses ændringer. Testere skal være i stand til at ændre scriptsne i henhold til miljøet eller ændringer af logininformation.
• Genanvendelig: De almindeligt anvendte metoder eller hjælpeprogrammer skal skrives i en fælles fil, der er tilgængelig for alle scripts.
• Konsekvent: Pakken skal skrives i et ensartet format ved at følge alle de accepterede kodningsmetoder.
• Uafhængig: Manuskripterne skal skrives på en sådan måde, at de er uafhængige af hinanden. Hvis en test mislykkes, bør den ikke holde de resterende testsager tilbage (medmindre det er en login-side)
• Logger: Det er godt at have implementeret logfunktionen i rammen. Dette vil hjælpe i tilfælde af, at vores scripts kører i længere timer (siger nattilstand), hvis scriptet mislykkes på et hvilket som helst tidspunkt, vil det at have logfilen hjælpe os med at registrere placeringen sammen med typen af ​​fejl.
• Rapportering: Det er godt at have rapporteringsfunktionen automatisk integreret i rammen. Når scriptingen er færdig, kan vi få resultaterne og rapporterne sendt via e-mail.
• Integration: Automation Framework skal være sådan, at det er let at integrere med andre applikationer som kontinuerlig integration eller udløse det automatiserede script, så snart build er implementeret.

Spørgsmål nr. 13) Kan du klare dig uden rammer?

Svar: Rammer er retningslinjer og ikke obligatoriske regler, så vi kan undvære en ramme, men hvis vi opretter den og følger den, ville forbedring og vedligeholdelse være let at implementere.

Spørgsmål nr. 14) Hvad er de forskellige typer af automatiseringsværktøjet, som du er opmærksom på?

Svar: Open source-værktøj som Selen, JMeter osv.

Betalte værktøjer som QTP, Load Runner, Ranorex, RFT og Rational Robot.

Spørgsmål nr. 15) Hvad er generelt strukturen i en ramme?

Svar: Normalt skal strukturen have - (Den vil variere fra projekt til projekt)

• En “src” (kilde) mappe med de faktiske test-scripts.
• En ”lib” (bibliotek) mappe med alle biblioteker og almindelige metoder.
• En 'klasse' -mappe, der har alle klassefilen (i tilfælde anvendt java).
• En 'log' -mappe med logfilen (e).
• En fil / mappe med alle webelement-id'erne.
• En fil, der indeholder URL, miljø og loginoplysninger.

Q # 16) Hvor opretholder du oplysninger som URL, login, adgangskode?

Svar: Disse oplysninger skal altid opbevares i en separat fil.

Spørgsmål nr. 17) Hvorfor vil du gemme denne form for information i en separat fil og ikke direkte i koden?

Svar: URL, login og adgangskoder er den slags felter, der bruges meget ofte, og disse ændres i henhold til miljøet og autorisationen. Hvis vi indlæser det i vores kode, skal vi ændre det i hver fil, der har sin reference.

Hvis der er mere end 100 filer, bliver det meget vanskeligt at ændre alle de 100 filer, og dette kan igen føre til fejl. Så denne form for information vedligeholdes i en separat fil, så opdatering bliver let.

Spørgsmål nr. 18) Hvad er de forskellige typer rammer?

Svar: Forskellige typer rammer inkluderer:

• Søgeordsdrevet ramme
• Datadrevet ramme
• Hybrid ramme
• Lineær scripting

Q # 19) Kan du fortælle nogle gode kodningsmetoder, mens du automatiserer?

Svar: Nogle af de gode kodningsmetoder inkluderer:

• Tilføj passende kommentarer.
• Identificer de genanvendelige metoder og skriv den i en separat fil.
• Følg de sprogspecifikke kodningskonventioner.
• Vedligehold testdataene i en separat fil.
• Kør dine scripts regelmæssigt.

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

Svar:

• Test, der sjældent udføres.
• Undersøgende test
• Brugervenlighedstest
• Test, der udføres hurtigt, når det udføres manuelt.

Q # 21) Tror du, at test kun kan udføres på UI-niveau?

.net interview spørgsmål og svar

Svar: I dag, når vi bevæger os til Agile-tilstand, er test ikke begrænset til UI-laget. Tidlig feedback er afgørende for et smidigt projekt. Hvis vi kun koncentrerer os om brugergrænsefladen, venter vi faktisk, indtil brugergrænsefladen er udviklet og tilgængelig til test.

Vi kan snarere teste, selv før brugergrænsefladen faktisk er udviklet. Vi kan teste API'erne eller metoderne direkte ved hjælp af værktøjer som agurk og FitNesse .

På denne måde giver vi feedbacken meget tidligt og tester, selv før brugergrænsefladen er udviklet. Ved at følge denne tilgang vil det hjælpe os med kun at teste GUI-aspektet ved små kosmetiske ændringer eller nogle valideringer på brugergrænsefladen og vil hjælpe udviklerne ved at give mere tid til at rette fejlene.

Spørgsmål nr. 22) Hvordan vælger du, hvilket automatiseringsværktøj der passer bedst til dig?

Svar: Valg af automatiseringsværktøj afhænger af forskellige faktorer som:

• Omfanget af applikationen, som vi vil automatisere.
• Ledelsesomkostninger som omkostninger og budget.
• Tid til at lære og implementere værktøjet.
• Type support tilgængelig til værktøjet.
• Begrænsning af værktøjet

Q # 23) Hvad tror du holder testere tilbage for at gøre automatisering? Er der en måde at overvinde det på?

Svar: Den største forhindring for testere er at lære programmering / kodning, når de vil automatisere. Da testere ikke kode, er tilpasning til kodning lidt udfordrende for testere.

Vi kan overvinde det ved:

• Samarbejde med udviklere, når de automatiserer.
• I betragtning af at automatisering er hele teamets ansvar og ikke kun testere.
• At give en dedikeret tid og fokus på automatisering.
• Få ordentlig ledelsesstøtte.

Du kan gemme disse spørgsmål om automatiseringstestinterview som en pdf og udskrive til yderligere læsning.

Spørgsmål nr. 24) Hvad er en ramme om test af automatisering?

Svar: En ramme er generelt et sæt retningslinjer. Et sæt retningslinjer, antagelser, koncepter og kodningsmetoder til at skabe et eksekveringsmiljø, hvor testene automatiseres, er kendt som en Automation-testramme.

En automatiseringsprøvningsramme er ansvarlig for at oprette en testsele med en mekanisme til at oprette forbindelse til den applikation, der testes, tage input fra en fil, udføre testsagerne og generere rapporterne til testudførelse. En automatiseringsprøvningsramme skal være uafhængig af applikationen, og den skal være let at bruge, ændre eller udvide.

Spørgsmål nr. 25) Hvad er de vigtige moduler i en automatiseret testramme?

Svar: Vigtige moduler i en Automation-testramme er:

1. Test påstande værktøj: Dette værktøj giver påståede erklæringer til test af de forventede værdier i den applikation, der testes. For eksempel. TestNG, Junit osv.
2. Dataopsætning: Hver testsag skal tage brugerdataene enten fra databasen eller fra en fil eller indlejret i testscriptet. Frameworks-datamodulet skal tage sig af dataindtaget til testskripter og de globale variabler.
3. Build Management Tool: Framework skal bygges og implementeres til brug af oprettelse af testscripts.
4. Kontinuerligt integrationsværktøj: Med CICD (kontinuerlig integration og kontinuerlig udvikling) på plads kræves der kontinuerligt integrationsværktøj til integration og implementering af de ændringer, der er foretaget i rammen ved hver iteration.
5. Rapporteringsværktøj: Der kræves et rapporteringsværktøj til at generere en læsbar rapport, efter at testsagerne er udført for at få et bedre overblik over trin, resultater og fejl.
6. Logningsværktøj: Logningsværktøjet i rammen hjælper med bedre fejlfinding af fejlen og fejlene.

Q # 26) Forklar nogle automatiserings-testværktøjer.

Svar: Nogle af de berømte Automation-testværktøjer er forklaret nedenfor:

(i) Selen : Selen er en testramme til test af automatisering af webapplikationer. Det understøtter flere browsere og er OS-uafhængig. Selenium understøtter også forskellige programmeringssprog som Java, C #, PHP, Ruby og Perl osv.

Selen er et open source-sæt af biblioteker, der kan bruges til at udvikle yderligere testrammer eller testscripts til test af webbaserede applikationer.

(ii) UFT : Unified Functional Testing er et licenseret værktøj til funktionel test. Det giver en bred vifte af funktioner som API'er, webtjenester osv. Og understøtter også flere platforme som desktops, web og mobil. UFT-scripts er skrevet på visuelt grundlæggende scriptingsprog.

(II) epoker : Appium er et open source-testværktøj til mobilapplikationer. Det bruges til at automatisere test på tværs af platforme, native, hybrid og webbaserede mobile applikationer. Appium automatiserer enhver mobilapplikation fra ethvert sprog med fuld adgang til API'er og DB'er fra testkoden.

Appium er baseret på klientserverarkitekturen og har udviklet sig fra selen.

(iv) Agurk : Agurk er et open source adfærdsdrevet udviklingsværktøj. Det bruges til webbaseret applikationsautomatiseringstest og understøtter sprog som rubin, java, scala, groovy osv. Agurk læser eksekverbar specifikation skrevet i almindelig tekst og tester applikationen under test for disse specifikationer.

For at agurk skal forstå scenarierne i almindelig tekst, skal vi følge nogle grundlæggende syntaksregler, der er kendt som agurk.

(v) TestComplete : TestComplete er et licenseret automatiseret UI-testværktøj til at teste applikationen på tværs af forskellige platforme som desktops, web, mobil osv. Det giver fleksibilitet til at optage en testcase i en browser og køre den i flere browsere og understøtter således testning på tværs af browsere.

TestComplete har indbygget algoritme til genkendelse af objekter, der entydigt identificerer et objekt og gemmer det i arkivet.

Spørgsmål nr. 27) Hvad er de forskellige typer af testrammerteknikker?

Svar: Der er fire typer rammeteknikker til automatiseringstest.

De er:

(i) Modular Testing Framework:

Denne ramme er bygget på begrebet abstraktion. I denne ramme opretter testeren scripts til hvert modul af applikationen, der testes individuelt, og derefter kombineres disse scripts i den hierarkiske rækkefølge for at oprette store testcases.

Det skaber et abstraktionslag mellem modulerne, og eventuelle ændringer i testskripter til et modul påvirker således ikke andre moduler.

Fordele ved denne ramme:

• Lettere vedligeholdelse og skalerbarhed af testsager.
• Det er lettere og hurtigere at oprette testcases ved at bruge allerede scriptede moduler.

Ulemper:

• Testcases har data indlejret i dem. Således er udførelse af det samme testscript med forskellige data en stor ændring på scriptniveau.

(ii) Datadrevet testramme:

I den datadrevne testramme lagres inputdataene og de forventede outputdata svarende til inputdataene i en fil eller database, og det automatiske script kører det samme sæt testtrin til flere datasæt. Med denne ramme kan vi køre flere testtilfælde, hvor kun inputdataene adskiller sig, og udførelsestrinene er de samme.

Fordele:

• Reducerer antallet af testskripter, der skal udføres. Vi udfører det samme script flere gange med forskellige data.
• Mindre kodning til automatiseringstest.
• Større fleksibilitet til vedligeholdelse og reparation af bugs eller forbedring af funktionaliteten.
• Testdata kan oprettes, selv før det automatiserede testsystem er klar.

Ulemper:

• Kun lignende testtilfælde med det samme sæt af udførelsestrin kan kombineres til flere datasæt. De forskellige sæt af udførelsestrin kræver en anden testsag.

(iii) Søgeordsdrevet testramme:

Det er en applikationsuafhængig testramme, der bruger datatabeller og selvforklarende nøgleord. Nøgleord forklarer de handlinger, der skal udføres på den applikation, der testes, og datatabellen giver input og forventede outputdata.

Søgeordsbaseret test er en stigning i datadrevet test.

Fordele:

• Mindre kodning og det samme script kan bruges til flere datasæt.
• Automatiseringsekspertise er ikke påkrævet for at oprette en testsag ved hjælp af de allerede eksisterende nøgleord til handlinger.
• Samme nøgleord kan bruges på tværs af flere testsager.

Ulemper:

• Denne ramme er mere kompliceret, da den skal tage sig af nøgleordets handlinger og også datainput.
• Testcases bliver længere og komplekse og påvirker vedligeholdelsesevnen af ​​den samme.

(iv) Hybrid testramme:

Denne ramme er en kombination af alle de ovennævnte testrammer (modulær, datadrevet og søgeordsdrevet).

I denne ramme er testcases udviklet fra modulære scripts ved at kombinere dem i modulrammestest-rammen. Hver af testsagerne bruger et driverscript, der bruger en datafil som i den datadrevne ramme og en nøgleordsbaseret handlingsfil.

Fordele:

• Modulær og nem at vedligeholde.
• Mindre kodning kan tage sig af flere testsager.
• Én testsag kan udføres med flere datasæt.

Ulemper:

• Kompleks at læse, vedligeholde og forbedre.

Spørgsmål nr. 28) Hvornår foretrækker du manuel test frem for automatiseringstest?

Svar: Vi foretrækker manuel test frem for automatiseringstest i følgende tilfælde:

• Projektet er kortsigtet, og skrivning af scripts vil være tidskrævende og dyrt sammenlignet med manuel test.
• Fleksibilitet er påkrævet. Automatiserede testsager programmeres og køres på en bestemt måde at konfigurere på.
• Usability test skal udføres.
• Applikationer / modul er nyudviklet og har ingen tidligere testtilfælde.
• Ad-hoc eller sonderende test skal udføres.

Spørgsmål nr. 29) Er automatiseringstest i agil metode nyttig eller ej?

Svar: Automatiseringstest er nyttig til regression, røg eller sundhedstest. Alle disse typer af test i den traditionelle vandfaldsmodel sker i slutningen af ​​cyklussen, og nogle gange, hvis der ikke er mange forbedringer af applikationen, behøver vi måske ikke engang at gøre regressionstest .

Der henviser til, at i agil metode , hver iteration kræver udførelse af regressionstestsagen, efterhånden som nye funktioner tilføjes.

Også selve regressionssuiten vokser efter hver sprint, da de funktionelle testtilfælde for det aktuelle sprintmodul skal føjes til regressionssuiten til den næste sprint.

Således er automatiseringstest i agil metode meget nyttigt og hjælper med at opnå maksimal testdækning på kortere tid efter sprinten.

Q # 30) Angiv nogle fordele og ulemper ved automatiseringstest.

Svar:

Fordele:

• Færre menneskelige ressourcer
• Genanvendelighed
• Mere testdækning på kortere tid
• Pålidelighed
• Parallel udførelse af testsager
• Hurtig

Ulemper:

interviewspørgsmål om afslappende webtjenester

• Udvikling og vedligeholdelsestid er mere.
• Værktøjsomkostninger
• Der kræves kvalificerede ressourcer.
• Opsætning af miljø
• Fejlfinding af testscript er et problem.

Q # 31) Angiv nogle fordele og ulemper ved manuel test.

Svar:

Fordele:

• Ingen miljøopsætning nødvendig.
• Programmeringskendskab er ikke påkrævet.
• Anbefales til dynamisk skiftende krav.
• Tillad menneskelig observationskraft at opdage flere bugs.
• Omkostningerne er mindre for kortsigtede projekter.
• Fleksibilitet

Ulemper:

• Vanskeligt at udføre komplekse beregninger.
• Genanvendelighed
• Det tager tid
• Høj risiko for menneskelige fejl eller fejl.
• Flere menneskelige ressourcer er påkrævet.

Spørgsmål nr. 32) Kan vi udføre automatiseringstest uden rammer? Hvis ja, hvorfor har vi brug for en ramme?

Svar: Ja, vi kan udføre automatiseringstest selv uden at bruge en ramme. Vi kan bare forstå det værktøj, vi bruger til automatisering og programmere de trin i programmeringssprog, som værktøjer understøtter.

Hvis vi automatiserer testsager uden rammer, vil der ikke være nogen konsistens i programmeringsscriptene til testsager.

Der kræves en ramme for at give et sæt retningslinjer, som alle skal følge for at have opretholdt læsbarhed, genanvendelighed og konsistens i testskripterne. En ramme giver også et fælles grundlag for rapporterings- og logfunktionalitet.

Spørgsmål nr. 33) Hvordan automatiserer du grundlæggende sager til 'login' -funktionstest for en applikation?

Svar: Forudsat at automatiseringsværktøjet og rammen allerede er i stedet for testmiljøet.

Sådan tester du den grundlæggende 'login' -funktionalitet:

• Forstå projektkravet : Login-funktionalitet har et brugernavn tekstboks, en adgangskode tekstboks og en login-knap.
• Identificer testscenarierne: For login-funktionalitet er de mulige testscenarier:
  • Tomt brugernavn og adgangskode
  • Ugyldigt brugernavn og adgangskode
  • Et gyldigt brugernavn og ugyldig adgangskode
  • Gyldigt brugernavn og adgangskode
• Forbered en Datainputfil med de data, der svarer til hvert scenarie.
• Start værktøjet fra programmet.
• Identificer brugernavnfeltet, adgangskodefeltet og login-knappen.
• For hvert testscenarie skal du hente dataene fra datafilen og indtaste de tilsvarende felter. Klik på programmet på login-knappen efter indtastning af dataene.
• Bekræft fejlmeddelelsen for negative scenarier og succesmeddelelsen for positive scenarier i testscriptet ved hjælp af påstande.
• Løb testpakken og generere rapporten.

Spørgsmål nr. 34) Er automatiseringstestning en sort boks-test eller hvid-boks-test?

Svar: Automatiseringstest er for det meste en test af sort boks da vi bare programmerer de trin, som en manuel tester udfører til applikation under test uden at kende applikationens lave niveau eller kode.

Nogle gange har automatiserede testskripter brug for adgang til de databaseoplysninger, der bruges i applikationen under test, eller nogle flere kodningsoplysninger og kan således være en type hvidboks-test.

Således kan automatiseret test være både sort eller hvid boks type test afhængigt af de scenarier, hvor automatisering udføres.

Spørgsmål nr. 35) Hvor mange testsager har du automatiseret om dagen?

Svar: Tja, antallet afhænger af kompleksiteten i testsagerne. Da kompleksiteten var begrænset, kunne jeg automatisere 5 til 6 testsager om dagen. Nogle gange var jeg i stand til at automatisere kun en test case for komplekse scenarier.

Jeg har også opdelt mine testsager i forskellige komponenter som f.eks. Tager input, foretager beregningen, kontrollerer output osv. I tilfælde af meget komplekse scenarier og har taget 2 eller flere dage.

Spørgsmål nr. 36) Hvilke faktorer bestemmer effektiviteten af ​​automatiseringstest?

Svar: Nogle af de faktorer, der bestemmer effektiviteten af ​​automatiseringstest er:

• Tidsbesparelse ved at køre scripts over manuel udførelse af testsager.
• Mangler fundet
• Test dækning eller kodedækning
• Vedligeholdelsestid eller udviklingstid
• Stabiliteten af ​​scripts
• Test genanvendelighed
• Kvaliteten af ​​den testede software

Spørgsmål nr. 37) Hvilke testsager kan automatiseres?

Svar: Typer af testsager, der kan automatiseres, er:

(i) Røgtesttilfælde: Røgtest er også kendt som test af buildverifikation. Røgtest-sager køres hver gang en ny build frigives for at kontrollere bygningens helbred for accept for at udføre test.

(ii) Tilfælde med regressionstest : Regressionstest er testen for at sikre, at tidligere udviklede moduler fungerer som forventet, efter at et nyt modul er tilføjet eller en fejl er rettet.

Regressionstestsager er meget afgørende i trinvis softwaretilgang, hvor der tilføjes en ny funktionalitet i hver inkrementfase. I dette tilfælde udføres regressionstest i hver trinvise fase.

(iii) Komplekse beregningstestsager: Testcases, der involverer nogle komplekse beregninger for at verificere et felt til en applikation, falder inden for denne kategori. Komplekse beregningsresultater er mere tilbøjelige til menneskelige fejl, og når de automatiseres, giver de nøjagtige resultater.

(iv) Datadrevne testsager: Testtilfælde, der har samme sæt trin og kører flere gange med ændring af data, er kendt som datadrevne testsager. Automatiseret test af denne type testsager er hurtig og omkostningseffektiv.

(v) Ikke-funktionelle testsager : Testtilfælde som belastningstest og ydelsestest kræver et simuleret miljø med flere brugere og flere hardware- eller softwarekombinationer.

Det er umuligt at oprette flere miljøer manuelt for hver kombination eller antal brugere. Automatiserede værktøjer kan nemt skabe dette miljø til let at udføre ikke-funktionel test.

Spørgsmål nr. 38) Hvad er faserne i automatiseringstestets livscyklus?

Svar: Faserne i automatiseringstestets livscyklus inkluderer:

1. Beslutningen om at udføre automatiseringstest.
2. Identificer og lær om automatiseringsværktøjet.
3. Bestem omfanget af automatiseringstest.
4. Design og udvikle en testpakke.
5. Testudførelse
6. Vedligeholdelse af testskripter.

Spørgsmål nr. 39) Hvad er et automatiseret testscript?

Svar: Et automatiseret testscript er et kort program, der er skrevet på et programmeringssprog for at udføre et sæt instruktioner til en applikation, der testes, for at kontrollere, om applikationen er i henhold til kravene.

Dette program giver, når det køres, testresultaterne som bestået eller ikke afhænger af, om applikationen er som forventet.

Konklusion

Dette er de vigtigste spørgsmål, der er uafhængige af automatiseringsværktøjet eller programmeringssproget. Automatiseringstestsamtaler inkluderer også værktøjs- og programmeringsspecifikke spørgsmål afhængigt af det værktøj, du har arbejdet med.

De fleste af spørgsmålene om testautomatiseringsinterview er centreret om den ramme, du udvikler, så det anbefales, at du opretter og forstår din testramme grundigt. Når jeg interviewer, og kandidaten har besvaret mit spørgsmål om rammen, foretrækker jeg også at stille et sprogspecifikt spørgsmål (kernen Java i mit tilfælde).

Spørgsmålene starter fra det grundlæggende i java for at skrive logikken i nogle grundlæggende scenarier som:

• Hvordan ville du udtrække et sæt tekst fra en given linje?
• Hvordan vil du udtrække URL'en?
• På enhver webside, på en hvilken som helst ramme, ændres antallet af links og dets indhold dynamisk, hvordan ville du håndtere det?
• Hvordan håndterer du billeder og flashobjekter?
• Hvordan finder du et ord i en linje?

Svar på alle disse test automatiseringsspørgsmål er meget specifikke for det værktøj / sprog, du bruger til automatisering. Så inden du går til interviewet, børst dine programmeringsfærdigheder op.

Hvis du ikke fik en chance for at skabe dine rammer, og en anden har oprettet den, skal du bruge lidt tid på at forstå det grundigt, inden du sidder til interviewet.

Nogle tip til interviews med automatiseringstest ville være:

• Kend dit værktøj grundigt.
• Lær de lokaliseringsteknikker, der bruges af dit værktøj.
• Øv programmering på det sprog, du bruger til automatiseringstest.
• Lær din ramme og dens komponenter.
• Det er altid en fordel, hvis du har været involveret i udviklingen af ​​din ramme. Så vær grundig med modulerne i de rammer, som du har arbejdet med.

Håber disse spørgsmål vil være nyttige for dig til at forberede dig til et testautomatiseringsinterview.

Anbefalet læsning

• Interviewspørgsmål og svar
• ETL Testing Interview Spørgsmål og svar
• Nogle interessante spørgsmål om software-test Interview
• 25 bedste spørgsmål om svar på Agile Testing Interview og svar
• Top 20 mest vigtige API-test Interviewspørgsmål og svar
• Spørgsmål og svar til softwaretest (del 1)
• Bedste softwaretestværktøjer 2021 [QA Test Automation Tools]
• Top 30 sikkerhedstest Interviewspørgsmål og svar