Topp 15 populære spørsmål om spesifikke intervjuer

top 15 popular specflow interview questions

Ofte stilte spørsmål og svar om spesifikke intervjuer:

Vår forrige spesifikasjonsveiledning orientert om Hvordan generere testrapporter og utføre selektive tester .

I denne opplæringen vil vi ta en titt på de mest populære spørsmålene om Specflow-intervju sammen med svarene deres.

Les gjennom Komplett Specflow Training Series for en enkel forståelse av konseptet. Specflow er et verktøy som støtter BDD-praksis i .NET-rammeverket. Det er et open source-rammeverk som er vert på GitHub. Det hjelper i å bruke ATDD (Acceptance Test Driver Development) for .NET.

hva er ruterenes brukernavn og passord

Topp spørsmål og svar om spesifikke intervjuer

Nedenfor er de mest populære Specflow-intervjuspørsmålene med svar og eksempler for enkel forståelse.

Q # 1) Hva er forskjellen mellom funksjonsfilen og bindende filer?

Svar: Å skrive BDD-tester i Specflow har to hovedkomponenter, nemlig

1. Funksjonsfiler: Som inneholder testene skrevet som Scenarios in Domain Specific Language (DSL) og i det vesentlige er enkle engelske filer som er passende og forståelige for alle interessenter i prosjektet. I virkeligheten er de de faktiske testfilene og tolkes gjennom bindinger eller trinndefinisjoner.
2. Trinnbindinger: Disse kodefilene er den faktiske intelligenslogikken bak utførelse av test. Hvert trinn i et scenario (som er en del av funksjonsfilen) binder seg til en trinndefinisjonsfil som faktisk kjøres når testen kjøres.

Derfor gjør en kombinasjon av både funksjonsfiler og trinndefinisjon eller bindinger det mulig for Specflow (eller et annet BDD) rammeverk å kjøre testene.

Q # 2) Hva er BDD og hvordan er den forskjellig fra TDD eller ATDD?

Svar: Alle disse tre begrepene, dvs. BDD, TDD og ATDD, er noe relatert til testdrevet utvikling generelt, men de er virkelig forskjellige på mange måter

1. TDD: TDD lager i utgangspunktet tester fra utviklerens perspektiv. Med enkle ord er det et sett med tester som en utvikler skriver for å få koden til å bestå (eller mislykkes). Det er egentlig en teknikk for å få koden til å mislykkes før alle spesifikke krav blir adressert. Det følger i utgangspunktet en refaktorsyklus for kode til testene er grønne.
2. BDD: BDD er nært knyttet til TDD, men er mer relevant fra et “utenfor-i” perspektiv, som faktisk betyr at BDD-tester er mer knyttet til forretnings- / produktkrav og definerer ønsket oppførsel til systemet i form av scenarier. TDD handler derimot på mer detaljerte enhetstester. Dessuten er BDD-spesifikasjoner generelt engelsk tekst som er lett å forstå og tillater større samarbeid mellom alle interessenter i prosjektet.
3. ATDD: Fokuset for Acceptance Test-Driven Development er mer fra brukerens akseptperspektiv. Disse testene definerer også kundeatferd, men fra integrasjon eller sluttproduktets synspunkt hvor kundens endelige brukssak blir konvertert til et testscenario og alt utviklingsarbeidet er fokusert for å oppfylle disse kravene.

Q # 3) Hva finnes i den automatisk genererte filen for Specflow-funksjonen?

Svar: Specflow-kode bak filer er automatisk genererte filer med utvidelsen “.cs”. Disse filene har bindingslogikken fra trinn til den faktiske trinndefinisjonen.

Få poeng angående automatisk genererte filer er:

• Disse filene skal ikke endres eller redigeres manuelt. Selv om du prøver å gjøre det, blir ikke endringene lagret.
• Etter hver endring i funksjonsfilen genererer kompilatoren denne filen på nytt for å fange oppdateringer.

Q # 4) Hvordan får du tilgang til trinnbindinger fordelt på forskjellige kildefiler?

Svar: Trinnbindingsfiler kan brukes på nytt selv om de finnes i separate kildefiler og bindingsmatching skjer gjennom en regex.

Trinnbindingsfilene er i hovedsak delvise klasser tilskrevet av (Bindende) Egenskap. Dette sikrer at alle trinnbindinger er tilgjengelige globalt og kan brukes med Scenario Steps i forskjellige eller samme funksjonsfiler.

Sp # 5) Hvordan kan tvetydige trinnbindende implementeringer løses?

Svar: Specflow gir en mekanisme for å unngå tvetydig trinnbindingsimplementering ved hjelp av et konsept som heter Omfangsbindinger.

Dette er nyttig i scenarier der du har lignende trinn i scenarier i samme eller forskjellige funksjonsfiler, og hvis du vil behandle begge trinnene på en annen måte.

I et normalt scenario, da all trinnmatching skjer gjennom Regex, og det er en grådig kamp, ​​må du sørge for at du skriver en litt annen tekst (slik at de ikke samsvarer med den samme implementeringen) for trinn, selv om de påvirker lesbarhet.

Ved hjelp av Scoped Bindings kan du spesifisere koder med en bestemt bindingsimplementering eller hele bindingsfilen og sørge for at matchingen også har et ekstra filterfilter.

Trinnene som må følges er oppført nedenfor:

til) Merk scenariet med en kategori ved hjelp av syntaks - @Stikkord. Eksempel: Vi merker scenariet nedenfor med taggen - @scopedBinding

b) Bruk nå den samme taggen på trinnbindingen som vil sikre at i tillegg til regex-samsvar, finner taggen eller kategorikampen også sted (og sikrer at andre trinn ikke samsvarer med denne implementeringen, selv om regex-match er vellykket)

I eksemplet ovenfor ønsker vi å omfatte bindingen for trinnet. “ Og jeg har angitt India som søkeord ”, Vil vi legge til Scope-attributtet med Scoping-parameter som tag.

I likhet med scoping med tag, er det også mulig å ha scoped-bindinger med Feature og Scenario-titler.

Sp # 6) Hvordan kan testkontekst lagres mens du kjører forskjellige scenarier?

Svar: Testkonteksten kan lagres ved hjelp av forskjellige tilnærminger mens du kjører specflow-tester, og hver tilnærming har sine fordeler og ulemper.

1. Bruke ScenarioContext og FeatureContext: Tenk på FeatureContext og ScenarioContext som en global ordbok over nøkkelverdipar og er tilgjengelig under henholdsvis funksjonsutførelse og scenarioutførelse. Verdifeltet kan lagre alle typer objekter, og under henting må det kastes i objektet etter ønske.
2. Bruke felt i bindingsfiler: Denne tilnærmingen gjør det mulig å dele kontekst på tvers av bindende implementeringer i samme og / eller forskjellige bindingsfiler i samme navneområde. Det er ikke annerledes når det gjelder å opprettholde tilstand ved hjelp av klassevariabler, og kan settes eller hentes over bindende implementeringer etter behov.
3. Ved å bruke Specflows eget DI-rammeverk: Specflow gir et kontekstinjeksjonsrammeverk og kan brukes til å overføre kontekst i form av enkle POCO-klasser / objekter. Kontekstobjektene / klassene kan injiseres gjennom konstruktorfelt og kan sendes langs forskjellige trinnbindingsfiler.

Se et eksempel nedenfor med to gjenstander injisert ved hjelp av konstruktørinjeksjon.

Q # 7) Hva er begrensningene for Specflow eller BDD generelt?

Svar: BDD, som navnet antyder, definerer atferden med applikasjonen som i hovedsak konverterer brukssaker til testscenarier.

Derfor kan fraværet av interessenter som en bedrift, et produkt og / eller kunder påvirke de faktiske spesifikasjonene som utviklerne skal implementere skrivetester for, og dermed kan det føre til at de ikke gir den virkelige verdien det de kunne ha gitt og hadde alle interessentene. var tilgjengelig mens scenariene ble definert.

Når det er sagt, overlever proffene ofte BDs ulemper, og det er virkelig en veldig nyttig teknikk for å teste / validere spesifikasjonene. Siden det er mer eller mindre språkagnostisk, siden det er BDD-rammer tilgjengelig for nesten alle større programmeringsspråk som Cucumber for Java, RSpec for Ruby og Specflow for .NET.

Q # 8) Hva er trinnargumenttransformasjoner?

Svar: Argumenttransformasjoner som navnet tilsier er ingenting annet enn å transformere scenariet.

Tenk på det som et ekstra matchingslag som skjer før den faktiske trinnbindingsmatchen skjer, og det kan være nyttig for å transformere en annen type brukerinngang i stedet for å ha forskjellige individuelle trinnimplementeringer for samme type innganger.

For ethvert transformasjonstrinn er det nødvendige attributtet StepArgumentTransformation

For eksempel, se kodeeksemplet nedenfor:

Med henvisning til kodeeksemplet ovenfor er alle tre trinnene relatert. Men hvis det hadde vært gjennom den vanlige regex-samsvaringen, ville du bli bedt om å skrive tre forskjellige trinnimplementeringer.

Med trinnargumenttransformasjoner på plass, er det mulig å transformere verdiene og skape en TimeStamp objekt fra de angitte parametrene og gå tilbake til den opprinnelige trinnimplementeringen.

La oss se på implementeringen av transformasjonen.

Dermed transformerer vi her scenarioinngangen til en mellomverdi (som TimeStamp) og returnerer den transformerte verdien til den faktiske bindingsimplementeringen som vist i eksemplet nedenfor.

Legg merke til hvordan den transformerte verdien av typen TimeSpan nå returneres tilbake til den faktiske trinnbindingsimplementeringsmetoden.

Sp # 9) Hva er de forskjellige typer kroker som tilbys av Specflow?

Svar:

Specflow gir mange tilpassede kroker eller spesielle hendelser som hendelsesbehandlerne (i hovedsak metoder / funksjoner) kan være bundet til å utføre noen oppsett / nedrivningslogikk.

Specflow gir følgende kroker:

1. BeforeFeature / AfterFeature: Arrangementet som ble hevet før og etter funksjonen starter henholdsvis og fullfører kjøringen.
2. BeforeScenario / AfterScenario: Arrangementet som ble hevet før og etter et scenarioutførelse starter henholdsvis.
3. BeforeScenarioBlock / AfterScenarioBlock: Arrangementet hevet før og etter en scenarioblokk, dvs. når noen av scenarioblokkene som tilhører “Gitt”, “Når” eller “Så” starter eller fullføres.
4. BeforeStep / AfterStep: Arrangementet hevet før og etter hvert trinn i scenariet.
5. BeforeTestRun / AfterTestRun: Denne hendelsen løftes bare en gang i løpet av hele testutførelsen og en gang etter at testutførelsen er fullført.

Det er viktig å merke seg her at disse hendelsene heves som standard, og håndteres hvis og bare hvis det er bindinger gitt for disse krokene. Det er heller ikke obligatorisk å implementere disse krokene parvis, og hver krok kan eksistere uavhengig av hverandre.

Sp # 10) Hvordan er ScenarioContext forskjellig fra FeatureContext?

Svar: Både ScenarioContext og FeatureContext er statiske klasser levert av Specflow-rammeverket og er veldig nyttige for å utføre oppgaver som å sende informasjon mellom bindinger, få viktig informasjon som kjøringskontekst for funksjon / scenario osv.

La oss se hvordan begge to er forskjellige:

Som navnet antyder gir ScenarioContext data eller info på Scenario-utførelsesnivå mens FeatureContext håndterer ting på funksjonsnivå.

Forenklet vil alt som er lagret i featureContext være tilgjengelig for alle scenariene som er tilstede i denne funksjonsfilen, mens ScenarioContext vil være tilgjengelig for bare bindinger til tidsscenarioutførelsen pågår.

Sp # 11) Hvor viktig er rekkefølgen for gitt, når og da?

Svar: Specflow pålegger ikke rekkefølgen på Gitt, når og da . Det handler mer om den logiske rekkefølgen av et testscenario og enhver testpraksis generelt, dvs. som i enhetstester følger vi vanligvis tre A-stående for ' Ordne, handle og hevde ”.

Så for specflow-scenarier er det ingen begrensninger på bestilling, og det pålegger heller ikke at alle de tre seksjonene skal være til stede.

Ofte kan oppsettet være minimalistisk og kanskje ikke engang nødvendig. Derfor kan du ganske enkelt hoppe over “for Gitt ”Blokkér og start scenariet med“ Når ”Blokk.

Sp # 12) Hva er ScenarioInfo og FeatureInfo?

Svar: SpecflowContext og FeatureContext gir videre nestede statiske klasser, nemlig ScenarioInfo og FeatureInfo.
ScenarioInfo gir tilgang til informasjon rundt scenariet som for øyeblikket blir utført.

Noen av tingene du kan bli kjent med denne klassen er gitt nedenfor:

1. Tittel: Tittelen på scenariet. Syntaks: ScenarioContext.Current.ScenarioInfo.Title
2. Tagger: Liste over koder i form av Streng (). Syntaks: ScenarioContext.Current.ScenarioInfo.Tags

S likner ScenarioInfo, FeatureInfo gir også informasjon om gjeldende funksjon som for øyeblikket blir utført.

I tillegg til tittel og koder, gir den også andre nyttige ting som hva er målspråket som funksjonskoden bak filen genererer kode for, språkleddet som funksjonsfilen er skrevet i, etc.

Syntaksen for å skaffe verdier for FeatureInfo forblir den samme som ScenarioInfo som nedenfor:
FeatureContext.Current.FeatureInfo

Q # 13) Forskjell mellom Scenario Outline og Specflow-tabeller.

Svar:

ScenarioOutline er i utgangspunktet en måte å utføre datadrevne scenarier ved hjelp av Specflow der en liste over innganger er gitt i Eksempler delen i scenariet, og scenariet utføres en gang hver, avhengig av antall eksempler som er gitt.

Se et kodeeksempel nedenfor for å forstå det tydeligere.

Tabeller er bare midler for å levere tabelldata med hvilket som helst trinn i scenariet, og blir sendt som argument for spesifikk tabell i trinnimplementeringen, som senere kan analyseres til ønsket objekttype etter behov.

Se “fet” delen i kodeeksemplet nedenfor for mer informasjon:

I likhet med merkeattributtet - du kan bruke hvilken som helst informasjon fra ScenarioInfo til å kontrollere kjøringsflyten for trinn implementering.

Sp # 14) Kontrollerer testutførelse gjennom ScenarioInfo.

I likhet med omfangsbindinger, som kan tillate å legge til et ekstra filterkriterium mens du matcher trinndefinisjon gjennom koder, kan du også utnytte kontrollen av testutførelsen gjennom informasjonen som følger med ScenarioInfo.

For eksempel, Du har to scenarier med koder, dvs. @ tag1 og @ tag2, og begge inneholder samme trinndefinisjon. Nå må du legge til tilpasset logikk, avhengig av scenarietaggene.

Dermed i trinndefinisjonsimplementeringen kan du ganske enkelt få alle kodene tilknyttet et scenario ved hjelp av ScenarioContext.Current.ScenarioInfo.Tags og se etter tilstedeværelsen av en tag i scenariet som utføres, og bestem hvilken kode du vil utføre.

Se kodeeksemplet nedenfor for bedre forståelse:

I likhet med merkeattributtet - du kan bruke hvilken som helst informasjon fra ScenarioInfo til å kontrollere kjøringsflyten for trinn implementering.

Sp # 15) Hvordan kan Specflow-tester utføres i en kontinuerlig integrasjonstype?

Svar:

Med moderne programvareutviklingsmetoder er kontinuerlig integrasjon et slags moteord og blir vanligvis referert til som et sett med praksis, der hver forpliktelse til kildekoden blir ansett som en kandidat for produksjonsutgivelse.

Derfor utløser hver forpliktelse i hovedsak forskjellige typer tester som kvalitetsporter for å sikre at endringen som blir begått ikke fører til at noen tester mislykkes eller går i stykker.

Specflow - som vi vet, integreres veldig godt med kjente rammer som NUnit og MSUnit og kan kjøres enkelt gjennom konsollapplikasjonene til disse testrammene gitt DLL av det kompilerte prosjektet som har Specflow-funksjoner og trinnimplementeringer.

Derfor, for å oppnå Specflow-tester som kjører som en del av et kontinuerlig integrasjonsoppsett, er følgende en liste over trinn på høyt nivå som kan følges:

#1) Kompiler prosjektet som inneholder Specflow-funksjonen og trinndefinisjon for å få en kompilert DLL.

#to) Bruk nå NUnit- eller MSUnit-konsolløpere og oppgi den kompilerte DLL-en som testkilde (Disse rammene gir andre muligheter, samt gir testfiltre avhengig av kategorier osv.).

Dette trinnet kan integreres med kontinuerlig integrasjonsrørledning og kan utføres gjennom skall eller DOS-skript med CI-verktøyet som Jenkins eller Bamboo etc.

# 3) Når testutførelsen er fullført, kan den genererte utgangsrapporten (som er spesifikk for konsollløperen som brukes) konverteres til en mer lesbar HTML-rapport ved hjelp av Specrun kjørbar er tilgjengelig som en del av NugetPackage.

Dette trinnet kan også utføres gjennom kommandolinjen som leveres ut av boksen av alle de store rammene for kontinuerlig integrering.

# 4) Når trinnet ovenfor er fullført, er vi klare med rapporten om de utførte testene og oppsummerte beregninger av testutførelsesdetaljene.

Vi håper du likte hele spekteret av opplæringsprogrammer i denne Specflow-opplæringsserien. Denne opplæringsserien vil faktisk være den beste guiden for enhver nybegynner eller erfaren person som ønsker å berike sin kunnskap om Specflow!

PREV Opplæring ELLERGå tilbake til The FØRSTE veiledning

Anbefalt lesing

• Intervju spørsmål og svar
• Spock Intervjuespørsmål med svar (mest populære)
• Noen interessante intervjusspørsmål om programvaretesting
• 20 mest populære TestNG intervju spørsmål og svar
• Topp 30+ populære agurkintervju spørsmål og svar
• Topp 50 mest populære CCNA-intervjuspørsmål og svar
• Topp 40 populære J2EE intervjuspørsmål og svar du bør lese
• 25+ mest populære ADO.NET intervjuspørsmål og svar