Top 15 populære specflow-interviewspørgsmål

top 15 popular specflow interview questions

Ofte stillede Specflow Interview-spørgsmål og svar:

Vores tidligere Specflow-vejledning orienteret om Sådan genereres testrapporter og udføres selektive tests .

I denne tutorial tager vi et kig på de mest populære Specflow Interview-spørgsmål sammen med deres svar.

Læs gennem Komplet Specflow-træningsserie for en let forståelse af konceptet. Specflow er et værktøj, der understøtter BDD-praksis i .NET-rammen. Det er en open source-ramme hostet på GitHub. Det hjælper med at bruge ATDD (Acceptance Test Driver Development) til .NET.

Top Specflow Interview Spørgsmål og svar

Nedenfor er de mest populære Specflow Interview-spørgsmål med svar og eksempler for din nemme forståelse.

Q # 1) Hvad er forskellen mellem funktionsfilen og bindende filer?

Svar: Skrivning af BDD-tests i Specflow har to hovedkomponenter, nemlig

1. Funktionsfiler: Som indeholder testene skrevet som Scenarios in Domain Specific Language (DSL) og i det væsentlige er almindelige engelske filer, der er egnede og forståelige for alle projektets interessenter. I virkeligheden er de de faktiske testfiler og fortolkes gennem bindinger eller trindefinitioner.
2. Trinbindinger: Disse kodefiler er den faktiske intelligenslogik bag testudførelse. Hvert trin i et scenario (som er en del af funktionsfilen) binder til en trindefinitionsfil, der faktisk udføres, når testen køres.

Derfor gør en kombination af både Feature-filer og Step-definition eller bindinger det muligt for Specflow (eller ethvert andet BDD) framework at køre testene.

Q # 2) Hvad er BDD, og ​​hvordan adskiller den sig fra TDD eller ATDD?

Svar: Alle disse tre udtryk, dvs. BDD, TDD og ATDD, er noget relateret til testdrevet udvikling generelt, men de er faktisk forskellige på mange måder

1. TDD: TDD opretter dybest set tests fra en udviklers perspektiv. Med enkle ord er det et sæt tests, som en udvikler skriver for at få sin kode til at bestå (eller mislykkes). Det er i det væsentlige en teknik til at få din kode til at mislykkes, indtil alle de specifikke krav bliver løst. Det følger grundlæggende en refaktorfunktion for kode, indtil testene alle er grønne.
2. BDD: BDD har en tæt tilknytning til TDD, men er mere relevant set fra et ”udefra” -perspektiv, hvilket faktisk betyder, at BDD-tests er mere bundet til forretnings- / produktkrav og definerer systemets ønskede opførsel i form af scenarier. TDD handler derimod på mere detaljerede enhedstestniveau. BDD-specifikationer er også generelt almindelig engelsk tekst, som er let at forstå og giver mulighed for større samarbejde mellem alle interessenter i projektet.
3. ATDD: Fokus for Acceptance Test-Driven Development er mere fra brugerens acceptperspektiv. Disse tests definerer også kundeadfærd, men fra integration eller endeligt produktperspektiv, hvor en kundes endelige brugssag omdannes til et testscenarie, og alt udviklingsarbejdet er fokuseret for at imødekomme disse krav.

Spørgsmål nr. 3) Hvad findes i den automatisk genererede fil til Specflow-funktionen?

Svar: Specflow-kode bag filer er automatisk genererede filer med filtypenavnet “.cs”. Disse filer har bindingslogikken fra trin til den faktiske trindefinition.

Få punkter vedrørende de automatisk genererede filer er:

• Disse filer bør ikke ændres eller redigeres manuelt. Selv hvis du prøver at gøre det, gemmes ændringerne ikke.
• Efter hver ændring i funktionsfilen genererer compileren denne fil igen for at opfange opdateringer.

Spørgsmål nr. 4) Hvordan fås trinbindinger spredt over forskellige kildefiler?

Svar: Trinbindingsfiler kan genbruges, selvom de findes i separate kildefiler, og bindingstilpasning sker gennem en regex.

Trinbindingsfilerne er i det væsentlige delvise klasser tilskrevet af (Bindende) attribut. Dette sikrer, at alle trinbindinger er tilgængelige globalt og kan bruges med scenarie-trin i forskellige eller samme funktionsfiler.

Spørgsmål nr. 5) Hvordan kan tvetydige trinbindende implementeringer løses?

Svar: Specflow giver en mekanisme til at undgå tvetydig implementering af trinbinding ved hjælp af et koncept kaldet Omfangsbindinger.

selenium test interview spørgsmål og svar

Dette er nyttigt i scenarier, hvor du har lignende trin i scenarier i samme eller forskellige funktionsfiler, og hvis du vil behandle begge trin forskelligt.

I et normalt scenarie, da al trinmatchning sker gennem Regex, og det er en grådig kamp, ​​bliver du nødt til at sikre, at du skriver en lidt anden tekst (så de ikke matcher den samme implementering) til trin, selvom de påvirker læsbarhed.

Ved hjælp af Scoped Bindings kan du angive tags med en bestemt bindingsimplementering eller hele bindingsfilen og sikre, at matchningen også har et ekstra filter af kategori.

De trin, der skal følges, er anført nedenfor:

til) Tag scenariet med en kategori ved hjælp af syntaks - @Tag. Eksempel: Vi mærker nedenstående scenarie med tag - @scopedBinding

b) Brug nu det samme mærke på trinbinding, som vil sikre, at ud over regex-match, tag eller kategorimatch også finder sted (og sikrer, at andre trin ikke matcher denne implementering, selvom regex-match er vellykket)

I ovenstående eksempel ønsker vi at omfatte bindingen til trinnet. “ Og jeg er kommet ind i Indien som søgeord ”, Vi tilføjer Scope-attributten med Scoping-parameter som tag.

I lighed med scoping med tag er det også muligt at have scoped-bindinger med Feature og Scenario-titler.

Spørgsmål nr. 6) Hvordan kan testkontekst gemmes, mens forskellige scenarier køres?

Svar: Testkonteksten kan gemmes ved hjælp af forskellige tilgange, mens der køres specflowtests, og hver tilgang har sine fordele og ulemper.

1. Brug af ScenarioContext og FeatureContext: Tænk på FeatureContext og ScenarioContext som en global ordbog over nøgleværdipar og er tilgængelig under henholdsvis funktionskørsel og scenariekørsel. Værdifeltet kan gemme enhver type objekt, og under hentning skal det kastes i objektet efter ønske.
2. Brug af felter i bindende filer: Denne tilgang giver mulighed for at dele kontekst på tværs af bindende implementeringer i samme og / eller forskellige bindingsfiler i samme navneområde. Det er ikke forskelligt ved opretholdelse af tilstand ved hjælp af klassevariabler og kan indstilles eller hentes på tværs af bindende implementeringer efter behov.
3. Brug af Specflows egen DI-ramme: Specflow giver en kontekstinjektionsramme og kan bruges til at overføre kontekst i form af simple POCO-klasser / objekter. Kontekstobjekterne / klasserne kan indsprøjtes gennem konstruktorfelter og kan sendes langs forskellige trinbindingsfiler.

Se et eksempel nedenfor med 2 genstande injiceret gennem konstruktørinjektion.

Q # 7) Hvad er begrænsningerne ved Specflow eller BDD generelt?

Svar: BDD, som navnet selv antyder, definerer adfærd med applikationen, som i det væsentlige konverterer brugssager til testscenarier.

Derfor kan fraværet af interessenter som en forretning, et produkt og / eller kunder påvirke de faktiske specifikationer, som udviklerne skal implementere skrivetest for, og det kan derfor resultere i ikke at give den faktiske værdi, hvad den kunne have givet og havde alle interessenterne var tilgængelige, mens scenarierne blev defineret.

Når det er sagt, overstiger professionelle fordele ofte BD's ulemper og er virkelig en meget nyttig teknik til at teste / validere specifikationerne. Da det er mere eller mindre sprog-agnostisk, da der er BDD-rammer tilgængelige for næsten alle større programmeringssprog som Agurk til Java, RSpec til Ruby og Specflow til .NET.

Q # 8) Hvad er trinargumenttransformationer?

Svar: Argumenttransformationer, som navnet antyder, er intet andet end at transformere scenarietrinet.

Tænk på det som et ekstra lag af matchning, der sker, før den egentlige trinbindingsmatch sker, og det kan være nyttigt til at transformere en anden type brugerinput i stedet for at have forskellige individuelle trinimplementeringer til den samme type input.

For ethvert transformationstrin er den krævede attribut StepArgumentTransformation

For eksempel henvises til nedenstående kodeeksempel:

Med henvisning til kodeeksemplet ovenfor er alle tre trin relateret. Men hvis det havde været gennem den sædvanlige regex-matching, ville du blive bedt om at skrive tre forskellige trinimplementeringer.

Med Step-argumenttransformationer på plads er det muligt at transformere værdierne og oprette en Tidsstempel objekt fra de angivne parametre og vende tilbage til den oprindelige trinimplementering.

Lad os se på implementeringen af ​​transformationen.

Således transformerer vi her scenarieinput til en mellemliggende værdi (som TimeStamp) og returnerer den transformerede værdi tilbage til den faktiske bindingsimplementering som vist i eksemplet nedenfor.

Bemærk, hvordan den transformerede værdi af typen TimeSpan nu returneres til den faktiske Step-bindende implementeringsmetode.

Spørgsmål nr. 9) Hvad er de forskellige krogtyper leveret af Specflow?

Svar:

Specflow giver mange brugerdefinerede kroge eller specielle begivenheder, som begivenhedshåndtererne (i det væsentlige metoder / funktioner) kan være bundet til at udføre en vis opsætnings- / nedbrydningslogik.

Specflow giver følgende kroge:

1. BeforeFeature / AfterFeature: Begivenheden, der blev rejst før og efter funktionen, starter henholdsvis og fuldfører udførelsen.
2. BeforeScenario / AfterScenario: Begivenheden, der blev rejst før og efter et scenarie, udføres henholdsvis og afsluttes.
3. BeforeScenarioBlock / AfterScenarioBlock: Begivenheden rejst før og efter en scenarieblok, dvs. når nogen af ​​scenarieblokkene, der hører til 'givet', 'hvornår' eller 'derefter' starter eller fuldføres.
4. BeforeStep / AfterStep: Begivenheden rejst før og efter hvert trin i scenariet.
5. BeforeTestRun / AfterTestRun: Denne begivenhed hæves kun én gang under hele testudførelsen og én gang efter, at testudførelsen er afsluttet.

Det er vigtigt at bemærke her, at disse begivenheder hæves som standard og håndteres, hvis og kun hvis der er bindinger til disse kroge. Det er heller ikke obligatorisk at implementere disse kroge parvis, og hver kroge kan eksistere uafhængigt af hinanden.

Q # 10) Hvordan adskiller ScenarioContext sig fra FeatureContext?

Svar: Både ScenarioContext og FeatureContext er statiske klasser leveret af Specflow-rammen og er virkelig nyttige til at udføre opgaver som at videregive info mellem bindinger, få vigtige oplysninger som eksekveringskontekst for funktion / scenarie osv.

Lad os se, hvordan de begge adskiller sig:

Som navnet antyder giver ScenarioContext data eller info på Scenario-eksekveringsniveau, mens FeatureContext beskæftiger sig med ting på funktionsniveau.

Forenklet set vil alt, der er gemt i featureContext, være tilgængeligt for alle scenarier, der er til stede i denne funktionsfil, mens ScenarioContext kun vil være tilgængeligt for kun bindingerne, indtil udførelsen af ​​tidsscenariet er i gang.

Spørgsmål nr. 11) Hvor vigtig er rækkefølgen af ​​den givne, hvornår og derefter?

Svar: Specflow pålægger ikke nogen begrænsning i rækkefølgen af Givet, hvornår og derefter . Det handler mere om den logiske sekventering af et testscenarie og enhver testpraksis generelt, dvs. som i enhedstest følger vi typisk tre A'er for ' Arranger, handle og hævde ”.

Så for specflow-scenarier er der ingen begrænsning for bestilling, og det pålægger heller ikke, at alle de tre sektioner skal være til stede.

Ofte kan opsætningen være minimalistisk og måske ikke engang nødvendig. Derfor for disse scenarier kan du bare springe ' Givet ”Bloker og start scenariet med“ Hvornår ”Blok.

Spørgsmål nr. 12) Hvad er ScenarioInfo og FeatureInfo?

Svar: SpecflowContext og FeatureContext giver yderligere indlejrede statiske klasser, nemlig ScenarioInfo og FeatureInfo.
ScenarioInfo giver adgang til information omkring det scenarie, der i øjeblikket udføres.

Nogle af de ting, du kan lære at kende med denne klasse, er angivet nedenfor:

1. Titel: Titlen på scenariet. Syntaks: ScenarioContext.Current.ScenarioInfo.Title
2. Mærker: Liste over tags i form af Snor(). Syntaks: ScenarioContext.Current.ScenarioInfo.Tags

S ligner ScenarioInfo, FeatureInfo giver også information vedrørende den aktuelle funktion, der i øjeblikket udføres.

Ud over titel og tags giver det også andre nyttige ting, som hvad er målsproget, for hvilken funktionskode bag filen genererer kode, de sprogoplysninger, hvori funktionsfilen er skrevet osv.

Syntaksen for at opnå værdier for FeatureInfo forbliver den samme som ScenarioInfo som nedenfor:
FeatureContext.Current.FeatureInfo

Q # 13) Forskel mellem Scenario Outline og Specflow-tabeller.

Svar:

ScenarieOutline er dybest set en måde at udføre datadrevne scenarier ved hjælp af Specflow, hvor der er en liste over input i Eksempler sektion i scenariet, og scenariet udføres en gang hver, afhængigt af antallet af eksempler.

Se en kodeeksempel nedenfor for at forstå det mere tydeligt.

Tabeller er bare midler til at levere tabeldata med ethvert trin i scenariet og sendes som Specflow-tabelargument i trinimplementeringen, som senere kan parses til ønsket objekttype efter behov.

Se afsnittet 'fed' i nedenstående kodeeksempel for flere detaljer:

Svarende til tags-attributten - du kan bruge enhver info leveret af ScenarioInfo til at kontrollere udførelsesstrømmen for ethvert trinimplementering.

Q # 14) Kontrollerende testudførelse via ScenarioInfo.

I lighed med omfangsbindinger, som kan tillade tilføjelse af et ekstra filterkriterium, mens du matcher trindefinition gennem tags, kan du også udnytte styringen af ​​testudførelsen gennem den information, der leveres med ScenarioInfo.

For eksempel, Du har to scenarier med tags, dvs. @ tag1 og @ tag2, og begge indeholder den samme trindefinition. Nu skal du tilføje brugerdefineret logik afhængigt af scenarie-tags.

Således i trindefinitionsimplementeringen kan du simpelthen få alle de tags, der er knyttet til et scenario ved hjælp af ScenarioContext.Current.ScenarioInfo.Tags og kontroller for tilstedeværelsen af ​​et tag i scenariet, der udføres, og beslut hvilken kode du vil udføre.

Se kodeeksemplet nedenfor for en bedre forståelse:

Svarende til tags-attributten - du kan bruge enhver info leveret af ScenarioInfo til at kontrollere udførelsesstrømmen for ethvert trinimplementering.

Spørgsmål nr. 15) Hvordan kan Specflow-tests udføres i en kontinuerlig integrationstype opsætning?

Svar:

Med moderne softwareudviklingsmetoder er kontinuerlig integration en slags buzzword og kaldes generelt et sæt praksis, hvor enhver forpligtelse til kildekoden betragtes som en kandidat til produktionsudgivelse.

Derfor udløser hver forpligtelse i det væsentlige forskellige typer tests som kvalitetsporte for at sikre, at den ændring, der begås, ikke får nogen test til at mislykkes eller brydes.

Specflow - som vi ved integrerer meget godt med kendte rammer som NUnit og MSUnit og kan let køres gennem konsolapplikationerne i disse testrammer i betragtning af det kompilerede projekts DLL, der har Specflow-funktioner og trinimplementeringer.

Derfor, for at opnå Specflow-tests, der kører som en del af en kontinuerlig integrationsopsætning, er følgende en liste over trin på højt niveau, der kan følges:

# 1) Kompilér projektet, der indeholder Specflow-funktionen og trindefinition for at få en kompileret DLL.

#to) Brug nu NUnit- eller MSUnit-konsolløbere, og angiv den kompilerede DLL som testkilde (Disse rammer giver andre muligheder samt giver testfiltre afhængigt af kategorier osv.).

Dette trin kan integreres med den kontinuerlige integrationsrørledning og kan udføres via shell eller DOS-script med CI-værktøjet som Jenkins eller Bamboo osv.

# 3) Når testudførelsen er afsluttet, kan den genererede outputrapport (som er specifik for den anvendte konsolløber) konverteres til en mere læsbar HTML-rapport ved hjælp af Specrun eksekverbar er tilgængelig som en del af NugetPackage.

Dette trin kan også udføres via kommandolinjen, der er leveret ud af kassen af ​​alle de større kontinuerlige integrationsrammer.

# 4) Når ovenstående trin er afsluttet, er vi klar med rapporten om de udførte tests og de opsummerede metrics af testudførelsesoplysningerne.

Vi håber, at du nød hele rækken af ​​tutorials i denne Specflow-træningsserie. Denne serie af tutorials ville faktisk være den bedste guide til enhver nybegynder eller erfaren person, der ønsker at berige sin viden om Specflow!

PREV-vejledning ELLERGå tilbage til The FØRSTE vejledning

Anbefalet læsning

• Interviewspørgsmål og svar
• Spock Interview-spørgsmål med svar (mest populære)
• Nogle interessante softwaretestinterviewspørgsmål
• 20 mest populære TestNG Interview Spørgsmål og svar
• Top 30+ populære agurkspørgsmål og svar
• Top 50 mest populære CCNA Interviewspørgsmål og svar
• Top 40 populære J2EE interviewspørgsmål og svar, du bør læse
• 25+ mest populære ADO.NET interviewspørgsmål og svar