Меню

Топ 15 популярни въпроси за интервю за Specflow

top 15 popular specflow interview questions

Опитайте Нашия Инструмент За Премахване На Проблемите

Най-често задавани въпроси и отговори за интервю за Specflow:

Предишният ни урок за Specflow направи кратка информация за Как да генерирам отчети от тестове и да изпълнявам селективни тестове .

В този урок ще разгледаме най-популярните въпроси за интервю за Specflow заедно с техните отговори.

Прочетете Пълна серия Specflow Training за лесно разбиране на концепцията. Specflow е инструмент, поддържащ BDD практики в .NET рамката. Това е рамка с отворен код, хоствана на GitHub. Той помага при използването на ATDD (Разработване на драйвер за тест за приемане) за .NET.

Въпроси за интервю за Specflow

youtube to mp4 бързо безплатно онлайн

Най-добрите въпроси и отговори за интервю за Specflow

По-долу са изброени най-популярните въпроси за интервю за Specflow с отговори и примери за вашето лесно разбиране.

Q # 1) Каква е разликата между характеристичния файл и свързващите файлове?

Отговор: Писането на BDD тестове в Specflow има 2 основни компонента, а именно

  1. Файлове с функции: Които съдържат тестовете, написани като сценарии на специфичен за домейн език (DSL) и са по същество обикновени английски файлове, които са подходящи и разбираеми за всички заинтересовани страни от проекта. В действителност те са действителните тестови файлове и се интерпретират чрез обвързвания или дефиниции на стъпки.
  2. Свързващи връзки: Тези кодови файлове са действителната логика на разузнаването зад изпълнението на теста. Всяка стъпка в сценарий (който е част от файла на характеристиките) се свързва с файл за дефиниция на стъпка, който действително се изпълнява при изпълнение на теста.

Следователно комбинация от файлове с функции и дефиниция на стъпка или обвързвания правят възможно Specflow (или която и да е друга BDD) рамка да изпълнява тестовете.

В # 2) Какво е BDD и как се различава от TDD или ATDD?

Отговор: Всички тези три термина, т.е. BDD, TDD и ATDD, са донякъде свързани с тестваното развитие като цяло, но те наистина са различни в много отношения

  1. TDD: TDD всъщност създава тестове от гледна точка на разработчика. С прости думи, това е набор от тестове, които разработчикът пише, за да накара кода си да премине (или да се провали). Това е по същество техника да накарате кода си да се провали, докато не бъдат адресирани всички специфични изисквания. По принцип следва цикъл на рефакторинг за код, докато тестовете станат зелени.
  2. BDD: BDD е тясно свързан с TDD, но е по-подходящ от гледна точка „отвън“, което всъщност означава, че BDD тестовете са по-обвързани с бизнес / продуктовите изисквания и определят желаното поведение на системата под формата на сценарии. TDD за разлика от това предлага по-подробно ниво на единични тестове. Също така, спецификациите на BDD обикновено са обикновен текст на английски език, който е лесен за разбиране и позволява по-голямо сътрудничество между всички заинтересовани страни от проекта.
  3. ATDD: Фокусът на разработката, основана на теста за приемане, е по-скоро от гледна точка на приемането от потребителя. Тези тестове също определят поведението на клиентите, но от гледна точка на интеграцията или крайния продукт, където случаят на крайното използване на клиента се превръща в тестов сценарий и цялата разработка е насочена към изпълнение на тези изисквания.

В # 3) Какво се съдържа в автоматично генерирания файл за функцията Specflow?

Отговор: Файловете зад кода на Specflow са автоматично генерирани файлове с разширение „.cs“. Тези файлове имат логиката на свързване от стъпки до действителната дефиниция на стъпка.

Няколко точки относно автоматично генерираните файлове са:

  • Тези файлове не трябва да се променят или редактират ръчно. Дори ако се опитате да го направите, промените не се запазват.
  • След всяка промяна във файла с характеристиките, компилаторът генерира този файл, за да улавя актуализации.

В # 4) Как се осъществява достъп до обвързването на стъпки в различни изходни файлове?

Отговор: Файловете за обвързване на стъпки могат да бъдат използвани повторно, дори ако те съществуват в отделни изходни файлове и съвпадението на обвързването става чрез регулярно изражение.

Файловете за свързване на стъпки са по същество частични класове, приписвани от (Обвързване) атрибут. Това гарантира, че всички обвързвания на стъпки са достъпни в световен мащаб и могат да се използват със Сценарии на сценарий в различни или същите файлове с функции.

В # 5) Как могат да бъдат разрешени двусмислени изпълнения на обвързващи стъпки?

Отговор: Specflow предоставя механизъм за избягване на двусмислено изпълнение на свързване на стъпки, използвайки концепция, наречена Обхванати обвързвания.

Това е полезно в сценарии, когато имате подобни стъпки в Сценарии в същите или различни файлове с функции и ако искате да третирате и двете стъпки по различен начин.

В нормален сценарий, тъй като всички съвпадения на стъпки се случват чрез Regex и това е алчно съвпадение, ще трябва да се уверите, че пишете малко по-различен текст (така че те да не съвпадат със същото изпълнение) за стъпки, въпреки че те оказват влияние четливост.

Използвайки обхванати обвързвания, можете да посочите тагове с конкретно изпълнение на обвързване или целия свързващ файл и да се уверите, че съвпадението има и допълнителен филтър за категория.

Стъпките, които трябва да се следват, са изброени по-долу:

да се) Маркирайте сценария с категория, използвайки синтаксис - @Tag. Пример: Маркираме сценария по-долу с таг - @scopedBinding

@scopedBinding Scenario: Youtube should search for the given keyword and should navigate to search results page Given I have navigated to youtube website And I have entered India as search keyword When I press the search button Then I should be navigate to search results page

б) Сега използвайте същия етикет за обвързване на стъпки, което ще гарантира, че в допълнение към съвпадението на регулярните изрази се провежда и съвпадението на маркера или категорията (и гарантира, че други стъпки не успяват да съответстват на това изпълнение, дори ако съвпадението на регулярно изражение е успешно)

В горния пример искаме да обхванем обвързването за стъпката. „ И въведох Индия като ключова дума за търсене ”, Ще добавим атрибута Scope с параметър Scoping като таг.

(Given(@'I have entered (.*) as search keyword'), Scope(Tag ='scopedBinding')) public void GivenIHaveEnteredIndiaAsSearchKeyword(String searchString) { // step binding implementation }

Подобно на определянето на обхват с етикет, също е възможно да има обвързвания с обхват със заглавия на Feature и Scenario.

В # 6) Как може да се съхранява тестовият контекст, докато се изпълняват различни сценарии?

Отговор: Тестовият контекст може да се съхранява с помощта на различни подходи, докато се изпълняват тестове за спекфолд и всеки подход има своите плюсове и минуси.

  1. Използване на ScenarioContext и FeatureContext: Помислете за FeatureContext и ScenarioContext като за глобален речник на двойки ключ-стойност и е достъпен съответно по време на изпълнение на функция и изпълнение на сценарий. Полето за стойност може да съхранява всякакъв тип обект и по време на извличането трябва да бъде хвърлено в обекта по желание.
  2. Използване на полета в свързващи файлове: Този подход позволява да се споделя контекст между реализациите на обвързване в еднакви и / или различни обвързващи файлове в едно и също пространство от имена. Не е различно при поддържането на състояние с помощта на променливи на класа и може да бъде зададено или извлечено в изпълнения на обвързване според изискванията.
  3. Използване на собствената DI рамка на Specflow: Specflow предоставя рамка за инжектиране на контекст и може да се използва за предаване на контекст под формата на прости POCO класове / обекти. Контекстните обекти / класове могат да се инжектират през полетата на конструктора и могат да се предават по различни файлове за свързване на стъпка.

Вижте пример по-долу, като 2 обекта се инжектират чрез инжектиране на конструктор.

(Binding) public class StepImplementationClass { private readonly Context1 _context1; private readonly Context2 _context2; public YoutubeSearchFeatureSteps(Context1 context1, Context2 context2) { _context1 = context1; _context2 = context2; } }

В # 7) Какви са ограниченията на Specflow или BDD като цяло?

Отговор: BDD, както подсказва самото име, дефинира поведението на приложението, което по същество преобразува случаи на употреба в тестови сценарии.

Следователно отсъствието на заинтересовани страни като бизнес, продукт и / или клиенти може да повлияе на действителните спецификации, за които разработчиците ще внедрят тестове за запис и следователно може да доведе до не предоставяне на действителната стойност на това, което би могло да предостави и ако всички заинтересовани страни бяха на разположение при определяне на сценариите.

Като казах, че повечето пъти професионалистите надхитряват минусите на BDD и наистина е много полезна техника за тестване / валидиране на спецификациите. Тъй като е повече или по-малко езиково агностичен, тъй като има налични BDD рамки за почти всички основни програмни езици като Cucumber за Java, RSpec за Ruby и Specflow за .NET.

Въпрос # 8) Какво представляват трансформациите на стъпков аргумент?

Отговор: Аргументните трансформации, както подсказва името, не са нищо друго освен трансформиране на стъпката на сценария.

Помислете за това като за допълнителен слой на съвпадение, който се случва преди действителното съвпадение на свързването на стъпки и това може да бъде полезно за трансформиране на различен вид потребителски вход, вместо да има различни реализации на отделни стъпки за същия тип вход.

За всяка стъпка на трансформация необходимият атрибут е StepArgumentTransformation

Например, вижте примерния код по-долу:

Given I have entered 50 days into the timestamp to minute converter Given I have entered 1 day, 2 hours, 3 minutes into the timestamp to minute converter Given I have entered 1 day, 1 hour, 1 minute, 30 seconds into the timestamp to minute converter

Позовавайки се на примерния код по-горе, и трите стъпки са свързани. Но ако беше преминал през обичайното съвпадение на регулярни изрази, тогава щеше да се наложи да напишете три различни стъпкови реализации.

Със стъпкови преобразувания на аргументи е възможно да се трансформират стойностите и да се създаде a TimeStamp обект от посочените параметри и се върнете обратно към изпълнението на първоначалната стъпка.

Нека да разгледаме изпълнението на трансформацията.

(StepArgumentTransformation(@'(?:(d*) day(?:s)?(?:, )?)?(?:(d*) hour(?:s)?(?:, )?)?(?:(d*) minute(?:s)?(?:, )?)?(?:(d*) second(?:s)?(?:, )?)?')) public TimeSpan convertToTimeSpan(String days, String hours, String minutes, String seconds) { // timestamp conversion logic }

По този начин тук трансформираме входа на сценария в междинна стойност (като TimeStamp) и връщаме обратно трансформираната стойност към действителното изпълнение на обвързване, както е показано в примерната по-долу.

(Given(@'I have entered (.*) into the timestamp to minute converter')) public void GivenIHaveEnteredDaysIntoTheTimestampToMinuteConverter(TimeSpan tsTransformed) { // binding implementation }

Забележете, как трансформираната стойност от тип TimeSpan сега се връща обратно към действителния метод за изпълнение на свързване на стъпка.

В # 9) Какви са различните видове куки, предоставени от Specflow?

Отговор:

Specflow предоставя много персонализирани куки или специални събития, с които манипулаторите на събития (по същество методи / функции) могат да бъдат обвързани да изпълняват някаква логика за настройка / прекъсване.

Specflow предоставя следните куки:

  1. BeforeFeature / AfterFeature: Събитието, повдигнато преди и след функцията, стартира и завършва изпълнението съответно.
  2. BeforeScenario / AfterScenario: Събитието, предизвикано преди и след изпълнението на сценария, започва и завършва съответно.
  3. BeforeScenarioBlock / AfterScenarioBlock: Събитието, повдигнато преди и след блок на сценарий, т.е. когато някой от сценариите блокира, принадлежащи на „Дадено“, „Кога“ или „Тогава“, започва или завършва.
  4. BeforeStep / AfterStep: Събитието, повдигнато преди и след всяка стъпка от сценария.
  5. BeforeTestRun / AfterTestRun: Това събитие се повишава само веднъж по време на цялото изпълнение на теста и веднъж след завършване на тестовото изпълнение.

Тук е важно да се отбележи, че тези събития се повдигат по подразбиране и се обработват, ако и само ако за тези куки са предвидени обвързвания. Също така не е задължително тези куки да се изпълняват по двойки и всяка кука може да съществува независимо една от друга.

В # 10) С какво ScenarioContext се различава от FeatureContext?

Отговор: И ScenarioContext, и FeatureContext са статични класове, предоставени от рамката Specflow и са наистина полезни за изпълнение на задачи като предаване на информация между обвързванията, получаване на важна информация като контекст на изпълнение на функция / сценарий и т.н.

Нека да видим как и двамата се различават:

Както подсказва името, ScenarioContext предоставя данни или информация на ниво изпълнение на Scenario, докато FeatureContext се занимава с неща на ниво функция.

С опростени термини, всичко, съхранявано в featureContext, ще бъде достъпно за всички сценарии, присъстващи в този файл на характеристиките, докато ScenarioContext ще бъде достъпно само за обвързването, докато не започне изпълнението на времевия сценарий.

В # 11) Колко важен е редът на даване, кога и тогава?

Отговор: Specflow не налага никакви ограничения в реда на Дадено, кога и тогава . Това е по-скоро за логическото последователност на тестовия сценарий и всяка практика на тестване като цяло, т.е.подобно на единичните тестове, ние обикновено следваме три A ' Подредете, действайте и утвърждавайте ”.

Така че за сценарии за спекфлоу няма ограничение за поръчки и също така не е задължително всичките три раздела да присъстват.

Често понякога настройката може да бъде минималистична и дори да не е необходима. Следователно за тези сценарии можете просто да пропуснете „ Дадено ”Блокирайте и стартирайте сценария с“ Кога ”Блок.

В # 12) Какво представляват ScenarioInfo и FeatureInfo?

Отговор: SpecflowContext и FeatureContext допълнително предоставят вложени статични класове, а именно ScenarioInfo и FeatureInfo.
ScenarioInfo дава достъп до информация около сценария, който се изпълнява в момента.

Някои от нещата, които можете да опознаете с този клас, са дадени по-долу:

  1. Заглавие: Заглавието на сценария. Синтаксис: ScenarioContext.Current.ScenarioInfo.Title
  2. Етикети: Списък на маркери под формата на Низ (). Синтаксис: ScenarioContext.Current.ScenarioInfo.Tags

С имиларен на ScenarioInfo, FeatureInfo също така предоставя информация, отнасяща се до текущата функция, която в момента се изпълнява.

В допълнение към заглавието и таговете, той предоставя и други полезни неща като какъв е целевият език, за който кодът на функцията зад файла генерира код, подробностите за езика, в който е написан файлът на характеристиките и т.н.

Синтаксисът за получаване на стойности за FeatureInfo остава същият като ScenarioInfo, както по-долу:
FeatureContext.Current.FeatureInfo

Въпрос # 13) Разлика между таблиците с контур на сценария и Specflow.

Отговор:

Сценарий Очертание е основно начин за изпълнение на управлявани от данни сценарии, използващи Specflow, където списък с входни данни е предоставен в Примери раздел в сценария и сценарият се изпълнява веднъж всеки в зависимост от броя на предоставените примери.

Вижте примерен код по-долу, за да го разберете по-ясно.

Scenario Outline: Youtube keyword search And I have entered as search keyword When I press the search button Then I should be navigate to search results page Examples: | searchTerm | | India | | America

Таблиците са само средства за предоставяне на таблични данни с всяка стъпка от сценария и се предават като аргумент на таблица Specflow в изпълнението на стъпката, която по-късно може да бъде анализирана до желания тип обект, както се изисква.

Моля, вижте раздела „получер“ в примерния код по-долу за повече подробности:

Scenario: Pass data through Specflow tables for StudentInfo object Given I have entered following info for Student | FirstName | LastName | Age | YearOfBirth | | test | student | 20 | 1995 | When I press add Then i student should get added to database and entered info should be displayed on the screen

Подобно на атрибута Tags - можете да използвате всяка информация, предоставена от ScenarioInfo, за да контролирате потока на изпълнение на всяка стъпка.

Q # 14) Контролиране на тест, изпълняващ се чрез ScenarioInfo.

Подобно на обвързването на обхвата, което може да позволи добавяне на допълнителен критерий за филтриране, докато съвпада с дефиницията на стъпка чрез тагове, можете също да използвате контрола на изпълнението на теста чрез информацията, предоставена със ScenarioInfo.

Например, Имате 2 сценария с тагове, т.е. @ tag1 и @ tag2 и двата съдържат една и съща дефиниция на стъпка. Сега трябва да добавите персонализирана логика в зависимост от маркерите на сценария.

По този начин в изпълнението на дефиницията на стъпка можете просто да получите всички маркери, свързани със сценарий, като използвате ScenarioContext.Current.ScenarioInfo.Tags и проверете за наличие на таг в изпълняващия се сценарий и решете кой код искате да изпълните.

Обърнете се към примерния код по-долу за по-добро разбиране:

(When(@'I press add')) public void WhenIPressAdd() { String() tags = ScenarioContext.Current.ScenarioInfo.Tags; String expectedTag = 'tag1'; if(tags.Any(s => s == expectedTag)) { // do something } else { // do something else } }

Подобно на атрибута Tags - можете да използвате всяка информация, предоставена от ScenarioInfo, за да контролирате потока на изпълнение на всяка стъпка.

Въпрос # 15) Как могат да се изпълняват тестове Specflow при непрекъсната интеграция?

Отговор:

Със съвременните методологии за разработване на софтуер непрекъснатата интеграция е нещо като модна дума и обикновено се нарича набор от практики, където всеки ангажимент към изходния код се разглежда като кандидат за продуктова версия.

Следователно всеки коммит по същество задейства различни видове тестове като качествени портати, за да се гарантира, че извършената промяна няма да доведе до неуспех или прекъсване на тестовете.

Specflow - както знаем, се интегрира много добре с известни рамки като NUnit и MSUnit и може лесно да се стартира през конзолните приложения на тези тестови рамки, като се има предвид DLL на компилирания проект, който има Specflow функции и стъпкови реализации.

Следователно, за да се постигнат тестове Specflow, които се изпълняват като част от настройка за непрекъсната интеграция, по-долу е даден списък от стъпки на високо ниво, които могат да се следват:

# 1) Компилирайте проекта, съдържащ функцията Specflow и дефиниция на стъпка, за да получите компилирана DLL.

# две) Сега използвайте NUnit или MSUnit конзолни бегачи и осигурете компилираната DLL като тестов източник (Тези рамки предоставят други възможности, както и тестови филтри в зависимост от категориите и т.н.).

Тази стъпка може да бъде интегрирана с конвейера за непрекъсната интеграция и може да бъде изпълнена чрез черупка или DOS скрипт с инструмента CI като Jenkins или Bamboo и т.н.

# 3) След като изпълнението на теста завърши, генерираният изходен отчет (който е специфичен за използвания конзолен бегач), може да бъде преобразуван в по-четлив HTML отчет с помощта на Спекрън изпълнимият файл е достъпен като част от NugetPackage.

Тази стъпка може да се изпълни и чрез командния ред, който се предоставя от всички основни рамки за непрекъсната интеграция.

# 4) След като горната стъпка приключи, ние сме готови с отчета за изпълнените тестове и обобщени показатели за подробностите за изпълнението на теста.

Надяваме се, че сте се насладили на цялата гама от уроци в тази серия за обучение Specflow. Тази серия уроци наистина би била най-доброто ръководство за всеки начинаещ или опитен човек, който иска да обогати знанията си за Specflow!

PREV Урок ИЛИВърнете се в ПЪРВИ Урок

Препоръчително четене

^