top 15 popular specflow interview questions
Запитання та відповіді на інтерв'ю, що найчастіше задаються:
У нашому попередньому підручнику з Specflow було коротко про це Як створити звіти про тести та виконати селективні тести .
У цьому навчальному посібнику ми розглянемо найпопулярніші питання інтерв’ю Specflow разом із їхніми відповідями.
Прочитайте Пройдіть серію навчальних програм Specflow для легкого розуміння концепції. Specflow - це інструмент, що підтримує практики BDD у середовищі .NET. Це фреймворк з відкритим кодом, розміщений на GitHub. Це допомагає використовувати ATDD (Розробка драйвера перевірки прийнятності) для .NET.
Найкращі запитання та відповіді на інтерв’ю Specflow
Нижче наведено найпопулярніші запитання щодо інтерв’ю Specflow із відповідями та прикладами для вашого легкого розуміння.
Q # 1) У чому різниця між файлом функції та файлами прив'язки?
Відповідь: Написання тестів BDD у Specflow має 2 основні компоненти, а саме
- Файли функцій: Які містять тести, написані як сценарії на мові домену (DSL), і є по суті простими англійськими файлами, які підходять і зрозумілі для всіх зацікавлених сторін проекту. Насправді вони є власне тестовими файлами і інтерпретуються через прив'язки або визначення етапів.
- Крок прив'язки: Ці файли коду є фактичною логікою розвідки, яка стоїть за виконанням тесту. Кожен крок у сценарії (який є частиною файлу функції) прив’язується до файлу визначення кроку, який фактично виконується під час запуску тесту.
Отже, поєднання як файлів функцій, так і визначення кроку або прив’язок дає можливість Specflow (або будь-якому іншому BDD) виконувати тести.
Q # 2) Що таке BDD і чим він відрізняється від TDD або ATDD?
Відповідь: Всі ці три терміни, тобто BDD, TDD та ATDD, певною мірою пов'язані з розробкою, керованою тестами, але вони насправді багато в чому різні
- TDD: TDD в основному створює тести з точки зору розробника. Простими словами, це набір тестів, які розробник пише, щоб його код пройшов (або провалився). По суті, це техніка, яка робить ваш код невдалим, доки не будуть вирішені всі конкретні вимоги. В основному він слідує циклу рефактора для коду, поки тести не стануть зеленими.
- BDD: BDD тісно пов'язаний з TDD, але є більш актуальним з точки зору 'зовні', що насправді означає, що тести BDD більше пов'язані з вимогами бізнесу / продукту та визначають бажану поведінку системи у вигляді сценаріїв. TDD, навпаки, пропонує більш детальний рівень одиничних тестів. Крім того, специфікації BDD - це звичайний текст англійською мовою, який легко зрозуміти та дозволяє розширити співпрацю між усіма зацікавленими сторонами проекту.
- ATDD: Основна увага в розробці, що базується на тестах прийняття, більше стосується точки зору користувача. Ці тести також визначають поведінку замовника, але з точки зору інтеграції або кінцевого продукту, де кінцевий випадок використання клієнта перетворюється на тестовий сценарій, і вся робота з розробки спрямована на те, щоб задовольнити ці вимоги.
Запитання №3) Що міститься в автоматично згенерованому файлі для функції Specflow?
Відповідь: Файли із кодом Specflow - це автоматично згенеровані файли з розширенням .cs. Ці файли мають логіку прив’язки від кроків до фактичного визначення кроку.
Кілька моментів щодо автоматично згенерованих файлів:
- Ці файли не слід змінювати або редагувати вручну. Навіть якщо ви спробуєте це зробити, зміни не зберігаються.
- Після кожної зміни у файлі функцій компілятор повторно генерує цей файл для збору оновлень.
Q # 4) Як здійснюється доступ до прив'язок кроків, розподілених по різних вихідних файлах?
різниця між тестуванням чорної скриньки та білої скриньки
Відповідь: Файли прив'язки кроків можна використовувати повторно, навіть якщо вони існують в окремих вихідних файлах, і збіг прив'язок відбувається через регулярний вираз.
Файли прив'язки кроків по суті є частковими класами, що приписуються (Пошиття) атрибут. Це гарантує, що всі прив'язки кроків доступні у всьому світі та можуть використовуватися разом із сценаріями кроків у різних або однакових файлах функцій.
Q # 5) Як можна вирішити неоднозначні реалізації прив'язки кроків?
Відповідь: Specflow забезпечує механізм, щоб уникнути неоднозначної реалізації прив'язки Крок за допомогою концепції, яка називається Об’ємні прив’язки.
Це корисно в сценаріях, коли у вас є подібні кроки в сценаріях у тих самих або різних файлах функцій, і якщо ви хочете по-різному ставитися до обох кроків.
У звичайному сценарії, оскільки всі збіги кроків відбуваються через регулярний вираз, і це жадібний збіг, вам доведеться переконатися, що ви пишете дещо інший текст (щоб вони не відповідали одній реалізації) для кроків, хоча вони впливають читабельність.
Використовуючи Scoped Bindings, ви можете вказати теги з певною реалізацією прив'язки або з цілим файлом прив'язки та переконатися, що у відповідності також є додатковий фільтр категорії.
Кроки, яких потрібно дотримуватися, перелічені нижче:
до) Позначити сценарій категорією за допомогою синтаксису - @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.
Q # 6) Як можна зберігати тестовий контекст під час запуску різних сценаріїв?
Відповідь: Контекст тесту можна зберігати, використовуючи різні підходи під час запуску тестів спекфлоу, і кожен підхід має свої плюси і мінуси.
- Використання ScenarioContext та FeatureContext: Подумайте про FeatureContext та ScenarioContext як про глобальний словник пар ключ-значення та доступний під час виконання функції та виконання сценарію відповідно. Поле значення може зберігати будь-який тип Об'єкта, і під час отримання його потрібно закидати в об'єкт за бажанням.
- Використання полів у файлах прив'язки: Цей підхід дозволяє обмінюватися контекстом між реалізаціями прив'язки в однакових та / або різних файлах прив'язки в одному просторі імен. Це не відрізняється у підтримці стану за допомогою змінних класу, і його можна встановити або отримати в реалізаціях прив’язки, якщо потрібно.
- Використовуючи власну структуру DI Specflow: Specflow забезпечує структуру введення контексту і може використовуватися для передачі контексту у вигляді простих класів / об'єктів POCO. Об'єкти / класи контексту можуть бути введені через поля конструктора і можуть передаватися разом із різними файлами прив'язки Крок.
Див. Приклад нижче, коли 2 об’єкти вводяться за допомогою ін’єкції конструктора.
Як створити масив загального типу в Java
(Binding) public class StepImplementationClass { private readonly Context1 _context1; private readonly Context2 _context2; public YoutubeSearchFeatureSteps(Context1 context1, Context2 context2) { _context1 = context1; _context2 = context2; } } Q # 7) Які загальні обмеження Specflow або BDD?
Відповідь: BDD, як випливає з назви, визначає поведінку програми, яка по суті перетворює випадки використання на тестові сценарії.
Отже, відсутність зацікавлених сторін, таких як бізнес, продукт та / або клієнти, може вплинути на фактичні специфікації, для яких розробники збираються впровадити тести написання, і, отже, це може призвести до того, що не надасть фактичної вартості того, що він міг би надати і мав би всі зацікавлені сторони були доступні під час визначення сценаріїв.
Сказавши, що більшість випадків професіонали перехитрили мінуси BDD, і це справді дуже корисна техніка для перевірки / перевірки специфікацій. Оскільки це більш-менш мовно агностичне, оскільки існують фреймворки BDD, доступні майже для всіх основних мов програмування, таких як Cucumber для Java, RSpec для Ruby та Specflow для .NET.
Q # 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 Посилаючись на зразок коду вище, усі три кроки пов’язані. Але, якби це було за допомогою звичайного зіставлення регулярних виразів, то вам потрібно було б написати три різні крокові реалізації.
За умови перетворення аргументів Step, можна перетворити значення і створити a Мітка часу об'єкт із зазначених параметрів і повернутися до початкового етапу реалізації.
Давайте розглянемо реалізацію трансформації.
(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 тепер повертається назад до фактичного методу реалізації прив'язки Крок.
Q # 9) Які різні типи гачків надає Specflow?
Відповідь:
Specflow надає багато спеціальних хуків або спеціальних подій, за допомогою яких обробники подій (по суті, методи / функції) можуть бути прив'язані до виконання певної логіки налаштування / відключення.
Specflow надає такі гачки:
- BeforeFeature / AfterFeature: Подія, викликана до та після завершення функції, і завершує її виконання відповідно.
- BeforeScenario / AfterScenario: Подія, що виникає до та після виконання сценарію, починається та завершується відповідно.
- BeforeScenarioBlock / AfterScenarioBlock: Подія, що виникає до та після блоку сценарію, тобто коли будь-який із блоків сценарію, що належить “Дано”, “Коли” чи “Тоді”, починається або завершується.
- BeforeStep / AfterStep: Подія, піднята до і після кожного кроку сценарію.
- BeforeTestRun / AfterTestRun: Ця подія піднімається лише один раз протягом усього виконання тесту та один раз після завершення тесту.
Тут важливо зауважити, що ці події викликаються за замовчуванням і обробляються тоді і тільки тоді, коли для цих хуків передбачені прив’язки. Крім того, не обов’язково реалізовувати ці гачки попарно, і кожен гачок може існувати незалежно один від одного.
Q # 10) Чим ScenarioContext відрізняється від FeatureContext?
Відповідь: І ScenarioContext, і FeatureContext - це статичні класи, що надаються фреймворком Specflow і дійсно корисні для виконання таких завдань, як передача інформації між прив'язками, отримання важливої інформації, як контекст виконання функції / сценарію тощо.
Давайте подивимось, чим вони відрізняються:
Як випливає з назви, ScenarioContext надає дані або інформацію на рівні виконання Scenario, тоді як FeatureContext має справу з речами на рівні функції.
Спрощено кажучи, все, що зберігається у featureContext, буде доступним для всіх сценаріїв, наявних у цьому файлі функцій, тоді як ScenarioContext буде доступним лише для прив’язок, поки не триває виконання сценарію часу.
Q # 11) Наскільки важливим є порядок подання, коли і тоді?
Відповідь: Specflow не накладає жодних обмежень на порядок Враховуючи, коли і тоді . Це більше стосується логічної послідовності тестового сценарію та будь-якої практики тестування загалом, тобто, як і в модульних тестах, ми, як правило, дотримуємося значень трьох А ' Організуйте, дійте та стверджуйте '.
Отже, для сценаріїв спекфлоу немає обмежень на замовлення, а також не передбачено, що мають бути присутні всі три розділи.
Часто інсталяція може бути мінімалістичною і навіть не потрібною. Отже, для цих сценаріїв ви можете просто пропустити ' Дано ”Заблокуйте та запустіть сценарій за допомогою Коли ”Блок.
Q # 12) Що таке ScenarioInfo та FeatureInfo?
Відповідь: SpecflowContext та FeatureContext надалі забезпечують вкладені статичні класи, а саме ScenarioInfo та FeatureInfo.
ScenarioInfo надає доступ до інформації щодо сценарію, який виконується в даний час.
Деякі речі, з якими ви можете ознайомитись за допомогою цього класу, подані нижче:
- Назва: Назва сценарію. Синтаксис: ScenarioContext.Current.ScenarioInfo.Title
- Теги: Список тегів у вигляді Рядок (). Синтаксис: ScenarioContext.Current.ScenarioInfo.Tags
S іміларний до ScenarioInfo, FeatureInfo також надає інформацію, що стосується поточної функції, яка виконується на даний момент.
На додаток до заголовка та тегів, він також надає інші корисні речі, наприклад, що є цільовою мовою, для якої код функції, що стоїть за файлом, генерує код, деталі мови, на яких написаний файл особливостей тощо.
Синтаксис для отримання значень FeatureInfo залишається таким же, як ScenarioInfo, як показано нижче:
FeatureContext.Current.FeatureInfo
Q # 13) Різниця між таблицями структури сценарію та таблиці спектрів.
Відповідь:
Сценарій в основному є способом виконання сценаріїв, керованих даними, за допомогою 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 Подібно до атрибута Теги - ви можете використовувати будь-яку інформацію, надану 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 } } Подібно до атрибута Теги - ви можете використовувати будь-яку інформацію, надану ScenarioInfo, для управління потоком виконання будь-якого кроку реалізації.
Q # 15) Як можна виконувати тести Specflow у режимі безперервної інтеграції?
Відповідь:
У сучасних методологіях розробки програмного забезпечення безперервна інтеграція є різновидом загальнодоступного слова і, як правило, називається набором практик, коли кожне зобов’язання щодо вихідного коду розглядається як кандидат на виробничий випуск.
Отже, кожен коміт, по суті, ініціює різні типи тестів як якісні параметри, щоб гарантувати, що зроблена зміна не призведе до того, що будь-які тести провалюються або ламаються.
Specflow - як ми знаємо, дуже добре інтегрується з відомими фреймворками, такими як NUnit і MSUnit, і може бути легко запущений через консольні програми цих тестових фреймворків, враховуючи DLL скомпільованого проекту, який має функції Specflow та крокові реалізації.
Отже, для того, щоб досягти тестів Specflow, які працюють як частина безперервної інтеграції, наведено перелік кроків високого рівня, яких можна виконати:
# 1) Скомпілюйте проект, що містить функцію Specflow і визначення кроку, щоб отримати скомпільовану DLL.
# два) Тепер використовуйте консолі NUnit або MSUnit і надайте скомпільовану DLL як джерело тесту (ці фреймворки надають інші можливості, а також забезпечують тестові фільтри залежно від категорій тощо).
Цей крок може бути інтегрований з конвеєром безперервної інтеграції і може бути виконаний за допомогою оболонки або сценарію DOS за допомогою інструмента CI, такого як Jenkins або Bamboo тощо.
# 3) Після завершення тестування згенерований вихідний звіт (який характерний для використовуваного консольного запуску) може бути перетворений у більш читабельний звіт HTML за допомогою Спектр виконуваний файл доступний як частина NugetPackage.
Цей крок також може бути виконаний через командний рядок, який надається зразу всіма основними фреймворками безперервної інтеграції.
# 4) Після завершення вищевказаного кроку ми готові до звіту про виконані тести та узагальнених показників деталей виконання тесту.
команда grep у скрипті оболонки unix
Ми сподіваємось, вам сподобався весь набір підручників у цій серії навчальних програм Specflow. Ця серія навчальних посібників справді була б найкращим посібником для будь-якого новачка або досвідченого, хто хоче збагатити свої знання про Specflow!
НАЗАД Підручник АБОПоверніться до ПЕРШИЙ підручник
Рекомендована література
- Запитання та відповіді на інтерв’ю
- Запитання для інтерв’ю з Spock (найпопулярніші)
- Деякі цікаві питання для тестування програмного забезпечення
- 20 найпопулярніших запитань та відповідей на інтерв’ю TestNG
- 30 найкращих запитань та відповідей на інтерв’ю з огірками
- 50 найпопулярніших запитань та відповідей на інтерв’ю CCNA
- 40 найкращих запитань та відповідей на інтерв’ю J2EE, які слід прочитати
- 25+ Найпопулярніші запитання та відповіді на інтерв’ю ADO.NET