Содержание
Что такое тестирование BDD? Пример платформы
Что такое тестирование BDD (разработка, управляемая поведением)?
BDD (Разработка, управляемая поведением) Тестирование — это метод гибкой разработки программного обеспечения, являющийся расширением TDD, т. е. разработки через тестирование. В BDD тестовые примеры написаны на естественном языке, который могут читать даже непрограммисты.
Как работает тестирование BDD?
Учтите, что вам поручено создать модуль перевода средств в приложении Net Banking.
Есть несколько способов проверить это
- Перевод средств должен осуществляться при наличии достаточного остатка на исходном счете
- Денежный перевод должен быть осуществлен, если реквизиты пункта назначения указаны верно
- Перевод средств должен выполняться, если пароль транзакции / код rsa / аутентификация безопасности для транзакции, введенной пользователем, верны
- Перевод средств должен осуществляться, даже если это выходной день
- Перевод средств должен быть осуществлен в будущую дату, установленную владельцем счета
.
.
Сценарий тестирования становится более детальным и сложным, поскольку мы рассматриваем дополнительные функции, такие как сумма перевода X за интервал Y дней/месяцев, остановка графика перевода, когда общая сумма достигает Z и т. д.
Общая тенденция разработчиков заключается в разработке функции и написать тестовый код позже. Как видно из приведенного выше случая, разработка тестового примера для этого случая сложна, и разработчик отложит тестирование до выпуска, после чего он проведет быстрое, но неэффективное тестирование.
Чтобы решить эту проблему (разработка, основанная на поведении), был задуман BDD. Это упрощает весь процесс тестирования для разработчика.
В BDD все, что вы пишете, должно состоять из заданных-когда-то шагов. Давайте рассмотрим тот же пример выше в BDD
Учитывая , что модуль перевода средств в приложении сетевого банковского обслуживания был разработан И я получаю к нему доступ с надлежащей аутентификацией
Когда я переведу с достаточным балансом в моей исходной учетной записи Или я переведу в выходной день Или я перенесу на будущую дату И информация о пункте назначения верна И пароль транзакции/код rsa/аутентификация безопасности для транзакции верны И нажмите или нажмите кнопку отправки
Затем необходимо перевести сумму И событие будет зарегистрировано в файле журнала
Разве это не легко написать, прочитать и понять? Он охватывает все возможные тестовые случаи для модуля перевода средств и может быть легко изменен для включения большего количества. Кроме того, это больше похоже на написание документации для модуля перевода средств.
Что такое тестирование REST API?
Поскольку в настоящее время REST стал довольно популярным стилем для создания API, не менее важной стала автоматизация тестовых случаев REST API наряду с тестовыми примерами пользовательского интерфейса. Таким образом, в основном это тестирование REST API включает в себя тестирование действий CRUD (Create-Read-Update-Delete) с методами POST, GET, PUT и DELETE соответственно.
Что такое поведение?
Behave — одна из популярных сред тестирования Python BDD.
Давайте посмотрим, как работает функция Behave:
Файлы функций написаны вашим бизнес-аналитиком / спонсором / кем-то еще с вашими сценариями поведения. Он имеет формат естественного языка, описывающий функцию или часть функции с репрезентативными примерами ожидаемых результатов.
Эти шаги сценария сопоставлены с реализациями шагов, написанными на Python.
И, по желанию, есть некоторые элементы управления окружением (код для запуска до и после шагов, сценариев, функций или всего матча стрельбы).
Давайте начнем с настройки нашей платформы тестирования автоматизации с помощью Behave:
Настройка BDD Testing Framework Behave в Windows
Установка:
- Загрузите и установите Python 3 с https://www.python.org/
- Выполните следующую команду в командной строке, чтобы установить поведение
- pip устанавливает поведение
- IDE: я использовал PyCharm Community Edition https://www.jetbrains.com/pycharm/download
Настройка проекта:
- Создать новый проект
- Создайте следующую структуру каталогов:
Файлы функций:
Итак, давайте создадим наш файл функций Sample_REST_API_Testing.feature с функцией Выполнение операций CRUD в службе «сообщения».
В нашем примере я использовал http://jsonplaceholder.typicode.com/ posts образец службы REST.
Пример сценария POST
Сценарий: Пример сообщения POST -> Здесь мы рассматриваем возможность создания нового элемента сообщения с использованием службы «сообщения».Дано: я устанавливаю конечную точку API сообщений для сообщений -> Это обязательное условие для теста, который устанавливает URL-адрес службы сообщений. Когда: я установил тип содержимого запроса параметра HEADER как «application/json». И установить тело запроса И отправьте HTTP-запрос POST -> Это фактический тестовый шаг отправки почтового запроса. Тогда: Затем я получаю действительный код ответа HTTP 201 И тело ответа "POST" не пусто-> Это проверка тела ответа
Аналогичным образом вы можете написать оставшиеся сценарии следующим образом:
Sample_REST_API_Testing.feature
Функция: тестирование методов CRUD в тестовой среде Sample REST API Фон: Учитывая, что я установил образец URL-адреса REST API Сценарий: пример сообщения POST Учитывая, что я установил конечную точку API для сообщений POST Когда я устанавливаю тип содержимого запроса параметра HEADER как «application/json». И установить тело запроса И отправьте HTTP-запрос POST Затем я получаю действительный код ответа HTTP 201 И тело ответа "POST" не пусто.Сценарий: пример сообщений GET Учитывая, что я установил конечную точку API GET сообщений "1" Когда я устанавливаю тип содержимого запроса параметра HEADER как «application/json». И отправить запрос GET HTTP Затем я получаю действительный код ответа HTTP 200 для «GET». И ответ BODY "GET" не пуст. Сценарий: пример сообщений UPDATE Учитывая, что я установил конечную точку API сообщений PUT для «1» Когда я устанавливаю тело запроса на обновление И отправить HTTP-запрос PUT Затем я получаю действительный код ответа HTTP 200 для «PUT». И ответ BODY "PUT" не пуст. Сценарий: пример УДАЛЕНИЯ сообщений Учитывая, что я установил конечную точку API сообщений DELETE для «1» Когда я отправляю HTTP-запрос DELETE Затем я получаю действительный код ответа HTTP 200 для «УДАЛИТЬ».
Реализация шагов
Теперь для функций Steps, используемых в описанных выше сценариях, вы можете писать реализации в файлах Python в каталоге «steps».
Инфраструктура поведения идентифицирует функцию Step с помощью декораторов, соответствующих предикату файла функций. Например, предикат Given в файле Feature Scenario ищет пошаговую функцию, имеющую декоратор «данный». Аналогичное сопоставление происходит для When и Then. Но в случае «Но», «И», функция шага принимает декоратор так же, как и предыдущий шаг. Например, если вместо «Дано» стоит «И», декоратором соответствующей пошаговой функции будет @дано.
Например, когда шаг для POST может быть реализован следующим образом:
@when (u'I Установить тип содержимого запроса параметра HEADER как "{header_conent_type}"') Сопоставление Когда, здесь уведомление «application/json» было передано из файла функций для «{header_conent_type}». Это называется параметризацией def step_impl (контекст, header_conent_type): Это сигнатура метода реализации шага request_headers['Content-Type'] = header_conent_type Код реализации шага, здесь вы будете устанавливать тип контента для заголовка запроса
Аналогично, реализация других шагов в файле шага python будет выглядеть так:
sample_step_implementation.
py
запросы на импорт api_endpoints = {} request_headers = {} код_ответа = {} ответ_тексты={} запрос_боди = {} api_url = нет @given(u'I установил образец URL-адреса REST API') def step_impl (контекст): глобальный API_url api_url = 'http://jsonplaceholder.typicode.com' # НАЧАТЬ Сценарий POST @given(u'I устанавливаю конечную точку API сообщений POST') def step_impl (контекст): api_endpoints['POST_URL'] = api_url+'/сообщения' print('url:'+api_endpoints['POST_URL']) @when(u'I Установить тип содержимого запроса параметра HEADER как "{header_conent_type}"') def step_impl (контекст, header_conent_type): request_headers['Content-Type'] = header_conent_type # Вы также можете включить «И» или «Но» в качестве шага — они переименовываются по поведению, чтобы взять имя предыдущего шага, поэтому: @when(u'Установить тело запроса') def step_impl (контекст): request_bodies['POST']={"title": "foo","body": "bar","userId": "1"} # Вы также можете включить «И» или «Но» в качестве шага — они переименовываются по поведению, чтобы взять имя предыдущего шага, поэтому: @when(u'Отправить HTTP-запрос POST') def step_impl (контекст): # отправка запроса на получение и сохранение ответа в качестве объекта ответа response = request.post(url=api_endpoints['POST_URL'], json=request_body['POST'], headers=request_headers) #response = request.post(url=api_endpoints['POST_URL'], headers=request_headers) #https://jsonplaceholder.typicode.com/posts # извлечение текста ответа response_texts['POST']=ответ.текст print("Ответ на публикацию:"+response.text) # извлечение ответа status_code код состояния = response.status_code response_codes['POST'] = код состояния @then(u'Я получаю действительный код ответа HTTP 201') def step_impl (контекст): print('Код представителя сообщения ;'+str(response_codes['POST'])) утвердить response_codes['POST'] 201 # Сценарий END POST # НАЧАТЬ ПОЛУЧИТЬ Сценарий @given(u'I установил конечную точку GET для сообщений API "{id}"') def step_impl (контекст, идентификатор): api_endpoints['GET_URL'] = api_url+'/сообщения/'+id print('url:'+api_endpoints['GET_URL']) # Вы также можете включить «И» или «Но» в качестве шага — они переименовываются по поведению, чтобы взять имя предыдущего шага, поэтому: @when(u'Отправить HTTP-запрос GET') def step_impl (контекст): # отправка запроса на получение и сохранение ответа в качестве объекта ответа response = request.
get(url=api_endpoints['GET_URL'], headers=request_headers) #https://jsonplaceholder.typicode.com/posts # извлечение текста ответа response_texts['GET']=ответ.текст # извлечение ответа status_code код состояния = response.status_code response_codes['GET'] = код состояния @then(u'Я получаю действительный код ответа HTTP 200 для "{request_name}"') def step_impl (контекст, имя_запроса): print('Получить код представителя для '+request_name+':'+ str(response_codes[request_name])) утвердить response_codes[имя_запроса] равно 200 @then(u'Response BODY "{request_name}" непусто') def step_impl (контекст, имя_запроса): print('имя_запроса: '+имя_запроса) печать (response_texts) утверждать, что response_texts[request_name] не равно None # КОНЕЦ ПОЛУЧИТЬ Сценарий # НАЧНИТЕ ПОСТАВЛЯТЬ/ОБНОВЛЯТЬ @given(u'I установил конечную точку API PUT для "{id}"') def step_impl (контекст, идентификатор): api_endpoints['PUT_URL'] = api_url + '/posts/'+id print('url:' + API_endpoints['PUT_URL']) @when(u'Я установил тело запроса на обновление') def step_impl (контекст): request_bodies['PUT']={"title": "foo","body": "bar","userId": "1","id": "1"} @when(u'Отправить HTTP-запрос PUT') def step_impl (контекст): # отправка запроса на получение и сохранение ответа в качестве объекта ответа # response = request.
post(url=api_endpoints['POST_URL'], headers=request_headers) #https://jsonplaceholder.typicode.com/posts response = request.put(url=api_endpoints['PUT_URL'], json=request_body['PUT'], headers=request_headers) # извлечение текста ответа response_texts['PUT'] = ответ.текст print("обновить ответ:" + response.text) # извлечение ответа status_code код состояния = response.status_code response_codes['PUT'] = код состояния #КОНЕЦ ВСТАВКИ/ОБНОВЛЕНИЯ #СТАРТ УДАЛИТЬ @given(u'I установил конечную точку API DELETE для "{id}"') def step_impl (контекст, идентификатор): api_endpoints['DELETE_URL'] = api_url + '/posts/'+id print('url:' + API_endpoints['DELETE_URL']) @when(u'Я отправляю HTTP-запрос DELETE') def step_impl (контекст): # отправка запроса на получение и сохранение ответа в качестве объекта ответа ответ = запросы.удалить(url=api_endpoints['DELETE_URL']) # response = request.post(url=api_endpoints['POST_URL'], headers=request_headers) #https://jsonplaceholder.
typicode.com/posts # извлечение текста ответа response_texts['DELETE'] = ответ.текст print("УДАЛИТЬ ответ:" + response.text) # извлечение ответа status_code код состояния = response.status_code response_codes['DELETE'] = код состояния #КОНЕЦ УДАЛИТЬ
Запуск тестов
Теперь мы закончили с нашей частью разработки тестового сценария, поэтому давайте запустим наши тесты:
Выполните следующую команду в командной строке, чтобы запустить наш файл функций
C:\Programs\Python\Python37> поведения -f довольно C:\<ваш путь к проекту>\features\feature_files_folder\ Sample_REST_API_Testing.feature
Это отобразит результаты выполнения теста следующим образом:
Отображение отчета на консоли
Давайте посмотрим еще одну интересную вещь.
Так как пользователи всегда предпочитают видеть результаты тестов в более читабельном и презентабельном формате, давайте с помощью Allure иметь отчеты в формате HTML.
Отчеты
Сначала необходимо установить средство форматирования Allure Behave [https://docs.qameta.io/allure-report/]:
А теперь выполните следующую команду:
Для отчетов
> поведения — f json -o <путь к папке с вашим отчетом> Sample_REST_API_Testing.feature
<путь к папке allure-bin>> allure serve <путь к папке с вашим отчетом>
Это создаст отчет о результатах тестирования в презентабельном и информативном формате, например:
Отчет о тестировании в формате HTML
Отчет о тестировании, отображающий результат отдельного сценария
Резюме:
- BDD — это разработка, основанная на поведении. Это один из методов гибкой разработки программного обеспечения.
- В настоящее время REST стал довольно популярным стилем для создания API, стало не менее важным автоматизировать тестовые примеры REST API наряду с тестовыми примерами пользовательского интерфейса.
- BDD имеет формат естественного языка, описывающий функцию или часть функции с репрезентативными примерами ожидаемых результатов
- Инфраструктура поведения идентифицирует функцию Step с помощью декораторов, соответствующих предикату файла функций
- Примеры сред тестирования BDD: 1) Cucumber 2) SpecFlow 3) Quantum 4) JBehave 5) Codeception
.
Полное руководство по разработке, ориентированной на поведение (BDD)
Разработка программного обеспечения, ориентированная на поведение (BDD), определяется как процесс, который фокусируется на требованиях и ожиданиях пользователей, облегчая сотрудничество между разработчиками, тестировщиками и руководителями проектов. Вот подробное руководство по процессу разработки, основанное на поведении, с подходящими примерами.
Содержание
- Что такое BDD (разработка, основанная на поведении)?
- Процесс разработки, основанный на поведении
- Примеры разработки, основанной на поведении
Что такое BDD (развитие, управляемое поведением)?
BDD (разработка, ориентированная на поведение) — это процесс разработки программного обеспечения, основанный на методологии Agile. Концепция разработки, ориентированной на поведение, возникла из подхода разработки через тестирование (TDD). Этот процесс разработки программного обеспечения ориентирован на требования конечных пользователей и их взаимодействие с продуктом.
Объяснение процесса BDD
Насколько хорошо основные функции приложения будут работать для конечных пользователей, каким будет общее поведение приложения для пользователей и какова обратная связь аудитории при взаимодействии с приложением — все эти факторы учитываются при создание продукта с использованием подхода к разработке, основанного на поведении.
Разработка на основе поведения — это очень востребованная методология разработки программного обеспечения, используемая для разработки разнообразных приложений для различных секторов, от B2B до SaaS. Разработка, основанная на поведении, основана на трех столпах: обнаружение, формулировка и автоматизация.
Давайте посмотрим, почему разработка на основе поведения так популярна среди разработчиков и тестировщиков.
Основные преимущества BDD
Концепция BDD заключается в том, чтобы позволить разработчикам, тестировщикам и бизнес-партнерам четко понимать поведение приложения и обеспечить сотрудничество между техническими и нетехническими командами.
Основные преимущества BDD
Помимо этого, существуют и другие преимущества, перечисленные ниже:
1. Разработка продукта, ориентированная на клиента
Благодаря раннему рассмотрению отзывов клиентов и применению методологии Agile разработка, ориентированная на поведение, обеспечивает высокоэффективный и ориентированный на клиента продукт, который не только соответствует требованиям клиентов, но и превосходит их.
2. Правильное определение приоритетов функций
Определение приоритетов функций продукта играет решающую роль в разработке программного обеспечения. Например, критически важными функциями приложения для потоковой передачи музыки являются качество потоковой передачи видео/аудио, совместимость устройств и пользовательские элементы управления, и это лишь некоторые из них.
Точно так же для каждого продукта существуют основные функции, которые определяют, насколько эффективно продукт будет выполнять свои обещания. В подходе к разработке, основанном на поведении, можно выделить основные функции продукта, установить для них приоритет и разделить их в соответствии с требованиями.
В первую очередь могут быть реализованы, протестированы и доставлены функции, предлагающие более важные бизнес-решения. Это также помогает оптимизировать время, затраты и ресурсы при одновременном повышении качества продукции.
3. Большая прозрачность
Прозрачность является ключом к успеху при любом подходе к разработке продукта, особенно если используется совместная позиция. Разработка, основанная на поведении, обеспечивает большую видимость функций системы, чтобы все разработчики, тестировщики, заинтересованные стороны бизнеса и другие члены команды могли четко понимать, что разрабатывается, и могут ли функции соответствовать определенному набору требований или нет. В результате можно поддерживать большую прозрачность во время разработки продукта и избегать двусмысленностей или конфликтов.
4. Снижение риска обслуживания и проекта
Разработка любого продукта сопряжена с определенными рисками, такими как возможность неэффективной разработки функций, отказ функций продукта, проблемы совместимости, затраты и время на доработку и другие. Выбирая подход к разработке, основанный на поведении, организации могут свести к минимуму риски, связанные с разработкой программного обеспечения.
5. Лучшее согласование с общими бизнес-целями
Поскольку этот подход к разработке делает акцент на поведении каждой функции, подробности о том, какой цели они служат, насколько хорошо они соответствуют текущему рынку, как они могут принести больше прибыли и т. д., могут быть лучше передать. В результате разработка продукта, соответствующего бизнес-критериям, становится проще.
См. также: 10 лучших инструментов для тестирования на проникновение в 2022 году
Процесс разработки, основанный на поведении
Процесс разработки, основанный на поведении, основан на трех важнейших подходах:
1.
Тестовый подход 9 0075
Тест Первый подход ориентирован на тестирование продукта в нужное время, чтобы убедиться, насколько он эффективен в режиме реального времени. Это требует гибкости команд разработки, тестирования и проекта, а также ясности в отношении технического процесса, принципов и методов, принятых на различных этапах разработки проекта.
Подход «сначала тестирование» устраняет традиционные ограничения разработки и тестирования, когда многие лазейки или проблемы обнаруживаются после окончательного запуска продукта. Вот почему подход «сначала тестирование» считается одним из важнейших подходов в разработке, основанной на поведении.
2. Гибкий подход к тестированию
Одним из важнейших факторов, отличающих разработку, основанную на поведении, от других традиционных методов разработки, является уникальный подход к тестированию. Вместо того, чтобы следовать традиционной процедуре сборки, тестирования и исправления ошибок, он фокусируется на Agile-тестировании. Гибкое тестирование основано на известной методологии итеративной разработки и тестирования, в которой особое внимание уделяется сотрудничеству между клиентами и командами.
В результате в процессе разработки и тестирования учитываются мнения клиентов. Agile-тестирование — это основной подход в процессе разработки, основанной на поведении, поскольку оно не только закладывает основу, но и помогает оптимизировать время, затраты и ресурсы, а также сокращает время отклика на обратную связь при минимальных требованиях к документации.
3. Встроенный подход к качеству
Разработка на основе поведения придерживается встроенного подхода к качеству, который гарантирует, что конечный продукт будет иметь все необходимые функции и решения и соответствовать текущему рынку. Недостаточно иметь набор функций и решений; но она должна быть ориентирована на рынок и ориентирована на клиента. Разработка, основанная на поведении, учитывает этот аспект, обеспечивая разработку конкурентоспособных продуктов, отвечающих всем требованиям конечных пользователей.
Теперь поговорим об этапах развития, основанного на поведении. BDD в основном включает три этапа: открытие, формулирование и автоматизация.
Давайте углубимся, чтобы узнать, как работает каждый из этих этапов.
1. Фаза открытия
Фаза открытия — это первая фаза разработки, основанной на поведении, на которой исследуются и определяются критерии приемлемости. Как правило, менеджер по продукту активно участвует в фазе исследования разработки, основанной на поведении.
На этом этапе критерии приемлемости разрабатываются на основе типа продукта, его ключевых характеристик, целевой аудитории, существующего рынка и других факторов. Другие члены команды, такие как менеджер проекта, разработчик, тестировщик или операционная группа, вносят свой вклад. В целом, этап открытия разработки, основанной на поведении, требует совместных усилий членов команды для выработки критериев приемлемости.
2. Фаза формулировки
Фаза формулировки начинается после того, как завершена фаза открытия и вот-вот начнется фаза реализации. Фаза формулировки в основном актуальна, когда элемент невыполненной работы вот-вот будет реализован. Основная цель этого этапа — убедиться, что критерии приемлемости подтверждены и готовы к применению в режиме реального времени. Приемочные испытания на этапе формулировки выполняют эту часть.
Целью приемочного тестирования является проверка методов обеспечения качества для определения того, соответствует ли приложение или продукт требованиям. Он решает, в какой степени вы можете принять продукт, исходя из потребностей и одобрения конечного пользователя. Таким образом, фаза формулировки посвящена превращению первоначальных критериев приемки в стабильную версию с меньшей неопределенностью или недостатками.
3. Этап автоматизации
Как следует из названия, этап автоматизации автоматизирует процесс приемочных испытаний. Он оптимизирует затрачиваемое время и используемые ресурсы, обеспечивая при этом получение требуемых результатов и соответствие критериям. На этом этапе BDD приемочные тесты автоматизируются и выполняются непрерывно для проверки и обеспечения совместимости новых шаблонов или моделей поведения с системой.
Узнать больше: Что такое тестирование на проникновение? Типы, методы и рекомендации
Примеры разработки на основе поведения
Разработка на основе поведения может определять характеристики или поведение каждой функции продукта с помощью соответствующих примеров. Определение функций с помощью примеров происходит до процесса разработки и выступает в качестве критерия приемки. Вот несколько примеров того, как можно по-разному использовать разработку, основанную на поведении, с различными инструментами, платформами и синтаксисом.
1. BDD с синтаксисом Gherkin
Синтаксис Gherkin состоит из набора строк, называемых шагами, и поставляется с дополнительной структурой, предназначенной для предоставления простой кривой обучения даже нетехническим специалистам и непрограммистам. Остальная часть и центральная часть синтаксиса Gherkin представлены в виде обычного текста.
Основная цель синтаксиса Gherkin не только в том, чтобы подчеркнуть конкретное назначение примера и теста, но и в том, чтобы использовать точное описание для отображения основных бизнес-правил. Некоторые из наиболее ярких примеров разработки на основе поведения с синтаксисом Gherkin используются со следующими ключевыми словами:
- Функция: Используется для описания функции программного обеспечения.
- Сценарий: Обозначает поведение системы. Сценарий описывает различные шаблоны, такие как события, требуемые результаты, исходный контекст и другие.
- Фон: Фон относится к контексту и фону системы с определенным набором функций и решений.
- Схема сценария: Схема сценария подразумевает схему поведения системы, особенно в случае нескольких сценариев.
- Примеры: Примеры обозначают различные факторы, относящиеся к BDD, такие как функции, решения, функции и другие.
- Дано, Когда, Тогда и Но (Шаги): Они обозначают различные шаги, условия и отношения между шагами.
- «»» (Строки документов): Обозначает строки документов.
- | (Таблицы данных): Представляет данные, хранящиеся в таблицах.
- @ (Tags): Они относятся к различным элементам процесса разработки, основанного на поведении.
- # (Комментарии): Комментарии передают важную и дополнительную информацию, относящуюся к программированию, управляемому поведением.
2. BDD с Cucumber
Еще один яркий пример BDD можно увидеть с помощью среды тестирования CucumberOpens a new window . Cucumber — широко используемый фреймворк для тестирования, написанный на Ruby. Будучи открытым исходным кодом и простым для понимания, Cucumber широко используется разработчиками и тестировщиками.
Он полностью поддерживает разработку, основанную на поведении, и позволяет легко писать разнообразные тестовые примеры. Вы можете наметить, определить и задокументировать поведение приложения с помощью простого текста, языка и синтаксиса, называемых корнишонами, как обсуждалось выше.
Одним из наиболее значительных преимуществ реализации разработки, основанной на поведении, с помощью Cucumber является то, что он может тестировать код разработки, основанной на поведении, написанный на разных языках, таких как Java, C# и Python, и это лишь некоторые из них. Еще одним преимуществом использования Cucumber в разработке, основанной на поведении, является то, что он поддерживает совместный подход, принятый в процессе BDD.
Например, если во время разработки, основанной на поведении, существует большее количество команд и их соответствующие мнения, используется Cucumber. Кроме того, Cucumber действует как универсальная платформа для автоматизации тестирования, помощи в разработке и документации по разработке, ориентированной на поведение.
3. BDD с SpecFlow
Другой типичный пример BDD наблюдается, когда он используется со SpecFlowOpens a new window , распространенной платформой разработки на основе поведения для .NET. Хотя существует некоторое сходство между SpecFlow и Cucumber, он основан на Ruby on Rails и размещен на GitHub.
Это также платформа с открытым исходным кодом, которая не только обслуживает разработку, основанную на поведении, и разработку драйверов приемочных испытаний, более известную как ATDD. Разработка драйвера приемочного тестирования облегчает совместную работу членов команды и в основном включает четыре этапа:
- Обсудить: Это начальная фаза или этап цикла ATDD, на котором происходит первоначальное обсуждение между заинтересованными сторонами.
- Distill: На этом этапе цикла ATDD методология Agile применяется для реализации автоматизации тестирования и надлежащего выполнения тестов на протяжении всего проекта.
- Разработка: Этап разработки цикла ATDD работает по методу разработки сначала тестирования или TFD, который подразумевает, что тест сначала запускается, затем указываются ошибки или проблемы, и, наконец, процесс выполняется для более быстрого и безошибочное развитие.
- Демонстрация: На этом этапе команда предоставляет демонстрацию заинтересованным сторонам, чтобы сообщить о выполнении тестов, результатах и проблемах или ошибках, которые необходимо исправить, если таковые имеются.
Хотя BDD и ATDD широко используются с похожими инструментами/платформами, они отличаются одним основным фактором. ATDD больше фокусируется на конкретных требованиях, которые должны быть выполнены, в то время как BDD делает упор на поведенческие аспекты функций. Понимание как ATDD, так и BDD рекомендуется для раскрытия потенциала SpecFlow, используемого в BDD.
Как и Cucumber, SpecFlow также предлагает простую кривую обучения и позволяет командам документировать поведение и свойства системных функций на простом английском языке. Поскольку он поддерживает совместный подход, принятый в BDD, это еще один популярный выбор для разработчиков, ориентированных на поведение. SpecFlow также позволяет документировать спецификации функций в формате Gherkin.
Тест SpecFlow/Cucumber BDD: Реальный пример:
Вот краткий обзор того, как тест SpecFlow/Cucumber BDD будет искать приложение или системную функцию «Вход в систему».
Функция: вход в систему
вход должен быть быстрым и удобным для пользователя
сценарий: успешный вход в систему 04 Дано пользователь решил зарегистрироваться
Когда пользователь зарегистрируется с действительными учетными данными
Затем он должен получить всплывающее сообщение
Сценарий: недействительные учетные данные
Когда пользователь пытается войти в систему, используя учетные данные, которых не существует.
Сценарий: неверный пароль
Когда пользователь вводит неверный пароль
Это помогает визуализировать всю функцию системы и ее поведение в различных условиях. Это также помогает совместному подходу, используемому в разработке, основанной на поведении, поскольку он легко понятен различным командам, предприятиям и заинтересованным сторонам.
4. BDD для картирования влияния
Картирование влияния относится к разработке графической стратегии для определения основных и дополнительных функций продукта, которые являются наиболее важными и подходящими для продукта. Картирование воздействия имеет решающее значение и должно выполняться в начале разработки любого продукта. Это один из критических вариантов использования или примеров широкого использования BDD.
Как обсуждалось выше, BDD имеет ключевое значение для описания характеристик продукта и применимо в картировании воздействия. Одной из распространенных проблем при разработке продукта является попытка добавить слишком много функций для достижения конечной цели или критериев. Часто это приводит к чрезмерным затратам времени, денег и усилий, а в итоге продукт оказывается с избыточными функциями.
Лучшая практика разработки продукта — не разрабатывать слишком много функций, а создавать основные функции, чтобы они могли предоставить требуемое решение конечным пользователям. Вот почему BDD в картировании воздействия актуален для разработки различных продуктов.
Подробнее: Тестировщик на проникновение: описание работы, ключевые навыки и зарплата в 2022 году
Вывод
Поведенческий подход к развитию отличается тем, что позволяет мыслить и строить с точки зрения клиента. Вместо того, чтобы просто разрабатывать набор функций, он фокусируется на характеристиках, которые могут хорошо подходить для приложений и вариантов использования в реальном времени.
Кроме того, если вы предпочитаете совместную работу или если вы стремитесь создать продукт, ориентированный на клиента и ориентированный на рынок, вам следует выбрать разработку, основанную на поведении.
Помогла ли вам эта статья понять, как работает разработка, основанная на поведении? Дайте нам знать на Facebook Открывает новое окно , Twitter Открывает новое окно и LinkedIn Открывает новое окно .