Topp 15 populära specflow-intervjufrågor

top 15 popular specflow interview questions

Vanliga frågor och svar om Specflow-intervjuer:

Vår tidigare Specflow-handledning orienterad om Hur man genererar testrapporter och utför selektiva tester .

I den här handledningen tar vi en titt på de mest populära Specflow-intervjufrågorna tillsammans med deras svar.

Läs igenom Komplett Specflow-träningsserie för en enkel förståelse av konceptet. Specflow är ett verktyg som stöder BDD-metoder i .NET-ramverket. Det är ett ramverk med öppen källkod som finns på GitHub. Det hjälper till att använda ATDD (Acceptance Test Driver Development) för .NET.

Top Specflow Intervju Frågor och svar

Nedan listas de mest populära Specflow-intervjufrågorna med svar och exempel för din lätta förståelse.

F # 1) Vad är skillnaden mellan funktionsfilen och bindande filer?

Svar: Att skriva BDD-tester i Specflow har två huvudkomponenter, nämligen

1. Funktionsfiler: Som innehåller tester skrivna som Scenarios in Domain Specific Language (DSL) och i huvudsak är enkla engelska filer som är lämpliga och förståliga för alla intressenter i projektet. I själva verket är de själva testfilerna och tolkas genom bindningar eller stegdefinitioner.
2. Stegbindningar: Dessa kodfiler är den faktiska intelligenslogiken bakom testkörningen. Varje steg i ett scenario (som är en del av funktionsfilen) binds till en stegdefinitionsfil som faktiskt körs när testet körs.

Därför gör en kombination av både funktionsfiler och stegdefinition eller bindningar det möjligt för Specflow (eller någon annan BDD) ram att köra testerna.

gratis youtube till mp4-omvandlare för mac

F # 2) Vad är BDD och hur skiljer det sig från TDD eller ATDD?

Svar: Alla dessa tre termer, dvs. BDD, TDD och ATDD är något relaterade till testdriven utveckling i allmänhet men de skiljer sig verkligen på många sätt

1. TDD: TDD skapar i princip tester ur en utvecklarperspektiv. Med enkla ord är det en uppsättning tester som en utvecklare skriver för att få sin kod att passera (eller misslyckas). Det är i grunden en teknik för att få din kod att misslyckas tills alla specifika krav tillgodoses. Det följer i princip en refaktorcykel för kod tills alla tester är gröna.
2. BDD: BDD relaterar nära till TDD men är mer relevant ur ett “utifrån” perspektiv vilket faktiskt innebär att BDD-tester är mer knutna till affärs- / produktkrav och definierar systemets önskade beteende i form av scenarier. TDD handlar däremot på mer detaljerade enhetstestnivåer. Dessutom är BDD-specifikationer i allmänhet vanlig engelsk text som är lätt att förstå och möjliggör större samarbete mellan alla intressenter i projektet.
3. ATDD: Fokus för Acceptance Test-Driven Development är mer ur användarens acceptansperspektiv. Dessa tester definierar också kundbeteende men från integrering eller slutlig produktperspektiv där kundens slutliga användningsfall omvandlas till ett testscenario och allt utvecklingsarbete fokuseras för att möta dessa krav.

F # 3) Vad finns i den automatiskt genererade filen för Specflow-funktionen?

Svar: Specflow-kod bakom filer är automatiskt genererade filer med tillägget '.cs'. Dessa filer har bindningslogiken från steg till den faktiska stegdefinitionen.

Få poäng angående de automatiskt genererade filerna är:

• Dessa filer bör inte ändras eller redigeras manuellt. Även om du försöker göra det sparas inte ändringarna.
• Efter varje ändring i funktionsfilen genererar kompilatorn den här filen igen för att fånga uppdateringar.

F # 4) Hur nås stegbindningar över olika källfiler?

Svar: Stegbindningsfiler kan återanvändas även om de finns i separata källfiler och bindningsmatchning sker via en regex.

Stegbindningsfilerna är i huvudsak delklasser tillskrivna av (Bindande) attribut. Detta säkerställer att alla stegbindningar är tillgängliga globalt och kan användas med scenariot i olika eller samma funktionsfiler.

F # 5) Hur kan tvetydiga stegbindande implementeringar lösas?

Svar: Specflow ger en mekanism för att undvika tvetydig implementering av stegbindning med hjälp av ett koncept som kallas Omfattade bindningar.

Detta är användbart i scenarier där du har liknande steg i scenarier i samma eller olika funktionsfiler och om du vill behandla båda stegen på olika sätt.

I ett normalt scenario, eftersom all stegmatchning sker genom Regex, och det är en girig match, måste du se till att du skriver en lite annan text (så att de inte matchar samma implementering) för steg även om de påverkar läsbarhet.

Med Scoped Bindings kan du ange taggar med en viss bindningsimplementering eller hela bindningsfilen och se till att matchningen också har ett ytterligare filterfilter.

Stegen som måste följas listas nedan:

till) Tagga scenariot med en kategori med syntax - @Märka. Exempel: Vi taggar nedanstående scenario med taggen - @scopedBinding

b) Använd nu samma tagg på stegbindningen som säkerställer att förutom regex-matchning även taggen eller kategorimatchningen äger rum (och säkerställer att andra steg inte matchar denna implementering även om regex-matchningen lyckas)

I exemplet ovan vill vi omfatta bindningen för steget. “ Och jag har gått in i Indien som sökord ”, Vi lägger till Scope-attributet med Scoping-parameter som tagg.

På samma sätt som scoping med tag är det också möjligt att ha scoped-bindningar med Feature och Scenario-titlar.

F # 6) Hur kan testkontext lagras när olika scenarion körs?

Svar: Testkontexten kan lagras med olika tillvägagångssätt medan du kör specflödestester och varje tillvägagångssätt har sina fördelar och nackdelar.

1. Använda ScenarioContext och FeatureContext: Tänk på FeatureContext och ScenarioContext som en global ordlista för nyckel-värdepar och är tillgänglig under funktionskörning respektive scenariekörning. Värdefältet kan lagra vilken typ av objekt som helst och under hämtning måste det kastas i objektet efter önskemål.
2. Använda fält i bindande filer: Detta tillvägagångssätt gör det möjligt att dela sammanhang över bindande implementeringar i samma och / eller olika bindningsfiler i samma namnområde. Det är inte annorlunda när det gäller att upprätthålla tillstånd med klassvariabler och kan ställas in eller hämtas över bindande implementeringar efter behov.
3. Med Specflows egna DI-ramverk: Specflow ger ett ramverk för kontextinjektion och kan användas för att skicka sammanhang i form av enkla POCO-klasser / objekt. Kontextobjekten / klasserna kan injiceras genom konstruktionsfält och kan skickas längs olika stegbindningsfiler.

Se ett exempel nedan med två föremål injicerade genom konstruktionsinjektion.

F # 7) Vilka är begränsningarna för Specflow eller BDD i allmänhet?

Svar: BDD, som själva namnet antyder, definierar beteendet med applikationen som i huvudsak omvandlar användningsfall till testscenarier.

Därför kan frånvaron av intressenter som ett företag, en produkt och / eller kunder påverka de faktiska specifikationer som utvecklarna kommer att genomföra skrivtester för och därmed kan det leda till att de inte ger det verkliga värdet vad de kunde ha gett och hade alla intressenter var tillgängliga när scenarierna definierades.

Med detta sagt för det mesta överträffar proffs nackdelarna med BDD och är verkligen en mycket hjälpsam teknik för att testa / validera specifikationerna. Eftersom det är mer eller mindre språkagnostiskt eftersom det finns BDD-ramar tillgängliga för nästan alla större programmeringsspråk som Gurka för Java, RSpec för Ruby och Specflow för .NET.

F # 8) Vad är stegargumenttransformationer?

Svar: Argumenttransformationer som namnet antyder är inget annat än att omvandla scenariot.

Tänk på det som ett extra matchande lager som händer innan den faktiska stegbindningsmatchen sker, och det kan vara användbart för att omvandla en annan typ av användarinmatning snarare än att ha olika individuella stegimplementeringar för samma typ av ingång.

För alla transformationssteg är attributet som krävs StepArgumentTransformation

Se exempelvis kodexemplet nedan:

Med hänvisning till kodprovet ovan är alla tre stegen relaterade. Men om det hade gått igenom den vanliga regex-matchningen skulle du behöva skriva tre olika stegimplementeringar.

Med Step-argumenttransformationer på plats är det möjligt att transformera värdena och skapa en Tidsstämpel objekt från de angivna parametrarna och återgå till den ursprungliga stegimplementeringen.

Låt oss titta på genomförandet av transformationen.

Således omvandlar vi här scenariotillgången till ett mellanliggande värde (som TimeStamp) och återför det transformerade värdet till det faktiska bindande genomförandet som visas i exemplet nedan.

Lägg märke till hur det transformerade värdet av typen TimeSpan nu återgår till den verkliga stegbindningsimplementeringsmetoden.

F # 9) Vilka är de olika typerna av krokar som tillhandahålls av Specflow?

Svar:

Specflow tillhandahåller många anpassade krokar eller speciella händelser med vilka händelseshanterarna (i huvudsak metoder / funktioner) kan vara bundna att utföra en viss installations- / nedbrytningslogik.

Specflow ger följande krokar:

1. BeforeFeature / AfterFeature: Händelsen som lyfts före och efter funktionen startar och slutför körningen.
2. BeforeScenario / AfterScenario: Händelsen som tagits fram före och efter att ett scenario körs startar och slutförs.
3. BeforeScenarioBlock / AfterScenarioBlock: Händelsen som uppkommit före och efter ett scenarioblock d.v.s. när något av scenarioblocken som tillhör 'given', 'när' eller 'sedan' startar eller slutförs.
4. BeforeStep / AfterStep: Händelsen som tas upp före och efter varje steg i scenariot.
5. BeforeTestRun / AfterTestRun: Denna händelse tas upp bara en gång under hela testkörningen och en gång efter att testkörningen har slutförts.

Det är viktigt att notera här att dessa händelser tas upp som standard och hanteras om och bara om det finns bindningar för dessa krokar. Det är inte heller obligatoriskt att implementera dessa krokar parvis och varje krok kan existera oberoende av varandra.

F # 10) Hur skiljer sig ScenarioContext från FeatureContext?

Svar: Både ScenarioContext och FeatureContext är statiska klasser som tillhandahålls av Specflow-ramverket och är mycket användbara för att utföra uppgifter som att skicka information mellan bindningar, få viktig information som exekveringskontext för funktion / scenario etc.

Låt oss se hur båda skiljer sig åt:

Som namnet antyder ger ScenarioContext data eller information på Scenario-exekveringsnivå medan FeatureContext hanterar saker på funktionsnivå.

I förenklade termer kommer allt som lagras i featureContext att vara tillgängligt för alla scenarier som finns i den funktionsfilen medan ScenarioContext bara kommer att vara tillgängligt för bara bindningarna tills tidsscenariokörningen pågår.

F # 11) Hur viktigt är ordningen för given, när och då?

Svar: Specflow inför inte några begränsningar i ordningen Givet, när och då . Det handlar mer om den logiska sekvensen av ett testscenario och all testmetod i allmänhet, dvs. som i enhetstester följer vi vanligtvis tre A-stånd för ' Ordna, agera och hävda ”.

Så för specflow-scenarier finns det ingen begränsning för beställning och det föreskriver inte heller att alla de tre sektionerna ska vara närvarande.

Ibland kan installationen vara minimalistisk och kanske inte ens behövs. Därför kan du helt enkelt hoppa över ”för dessa scenarier Given ”Blockera och starta scenariot med“ När ”Blockera.

F # 12) Vad är ScenarioInfo och FeatureInfo?

Svar: SpecflowContext och FeatureContext ger vidare kapslade statiska klasser, nämligen ScenarioInfo och FeatureInfo.
ScenarioInfo ger tillgång till information kring det scenario som för närvarande körs.

Några av de saker som du kan lära känna med den här klassen ges nedan:

1. Titel: Scenariot. Syntax: ScenarioContext.Current.ScenarioInfo.Title
2. Taggar: Lista över taggar i form av Sträng(). Syntax: ScenarioContext.Current.ScenarioInfo.Tags

S liknar ScenarioInfo, FeatureInfo ger också information om den aktuella funktionen som för närvarande körs.

Förutom titel och taggar, ger det också andra användbara saker som vad är målspråket för vilken funktionskod som ligger bakom filen genererar kod, de språkdetaljer där funktionsfilen är skriven etc.

Syntaksen för att erhålla värden för FeatureInfo förblir densamma som ScenarioInfo enligt nedan:
FeatureContext.Current.FeatureInfo

F # 13) Skillnad mellan Scenario Outline och Specflow-tabeller.

Svar:

ScenarioOutline är i princip ett sätt att utföra datadrivna scenarier med Specflow där en lista med ingångar finns i Exempel avsnittet i scenariot och scenariot körs en gång vardera beroende på antalet angivna exempel.

Se ett kodprov nedan för att förstå det tydligare.

Tabeller är bara medel för att tillhandahålla tabelldata med valfritt steg i scenariot och skickas som argument för Specflow-tabell i stegimplementeringen, som senare kan analyseras till önskad objekttyp efter behov.

Se avsnittet 'fet' i kodprovet nedan för mer information:

På samma sätt som attributet Taggar - du kan använda vilken information som helst från ScenarioInfo för att kontrollera exekveringsflödet för alla stegimplementeringar.

F # 14) Kontrollerar testkörning via ScenarioInfo.

På samma sätt som omfångsbindningar, som kan tillåta att du lägger till ett extra filterkriterium medan du matchar stegdefinitionen genom taggar, kan du också använda kontrollen av testkörningen genom den information som tillhandahålls med ScenarioInfo.

Till exempel, Du har två scenarier med taggar, dvs @ tag1 och @ tag2 och båda innehåller samma stegdefinition. Nu måste du lägga till anpassad logik beroende på scenariotaggarna.

Således kan du i stegdefinitionsimplementeringen helt enkelt hämta alla taggar som är associerade med ett scenario med ScenarioContext.Current.ScenarioInfo.Tags och kontrollera om det finns en tagg i scenariot som körs och bestäm vilken kod du vill köra.

Se kodprovet nedan för en bättre förståelse:

På samma sätt som attributet Taggar - du kan använda vilken information som helst från ScenarioInfo för att kontrollera exekveringsflödet för alla stegimplementeringar.

F # 15) Hur kan Specflow-test utföras i en kontinuerlig konfiguration av Integration?

Svar:

Med moderna programvaruutvecklingsmetoder är kontinuerlig integration ett slags ett slagord och kallas vanligtvis en uppsättning metoder, där varje åtagande till källkoden betraktas som en kandidat för produktionssläpp.

Därför utlöser varje åtagande i huvudsak olika typer av tester som kvalitetsgrindar för att säkerställa att den förändring som begås inte orsakar att några tester misslyckas eller bryts.

Specflow - som vi vet integrerar det mycket väl med kända ramar som NUnit och MSUnit och kan köras enkelt genom konsolapplikationerna i dessa testramar med tanke på det kompilerade projektets DLL som har Specflow-funktioner och stegimplementeringar.

Följaktligen, för att uppnå Specflow-test som körs som en del av en kontinuerlig integrationsinställning, är följande en lista över steg på hög nivå som kan följas:

# 1) Kompilera projektet som innehåller Specflow-funktionen och stegdefinitionen för att få en kompilerad DLL.

#två) Använd nu NUnit- eller MSUnit-konsollöpare och ange den kompilerade DLL som testkälla (dessa ramar ger andra funktioner samt tillhandahåller testfilter beroende på kategorier etc).

Detta steg kan integreras med den kontinuerliga integrationsrörledningen och kan utföras genom skal eller DOS-skript med CI-verktyget som Jenkins eller Bamboo etc.

# 3) När testkörningen är klar kan den genererade utgångsrapporten (som är specifik för den konsolrunner som används) konverteras till en mer läsbar HTML-rapport med Specrun körbar är tillgänglig som en del av NugetPackage.

Detta steg kan också utföras via kommandoraden som tillhandahålls direkt från rutan av alla större ramar för kontinuerlig integration.

# 4) När ovanstående steg har slutförts är vi redo med rapporten om de utförda testerna och sammanfattade mätvärden för utförandet av testet.

Vi hoppas att du gillade hela utbudet av handledning i denna Specflow-träningsserie. Denna serie handledning skulle verkligen vara den bästa guiden för alla nybörjare eller erfarna personer som vill berika sin kunskap om Specflow!

PREV-handledning ELLERGå tillbaka till The FÖRSTA självstudier

Rekommenderad läsning

• Intervjufrågor och svar
• Spock intervjufrågor med svar (mest populära)
• Några intressanta frågor om mjukvarutestning
• 20 mest populära TestNG-intervjufrågor och svar
• Topp 30+ populära gurkaintervjuer och svar
• Topp 50 mest populära CCNA-intervjufrågor och svar
• Topp 40 populära J2EE intervjufrågor och svar du bör läsa
• 25+ mest populära ADO.NET intervjufrågor och svar