НАЧАЛО РАБОТЫ С CUCUMBER BDD ДЛЯ АВТОМАТИЗИРОВАННОГО ТЕСТИРОВАНИЯ

Введение

В последние годы все больше команд разработчиков программного обеспечения все чаще применяют методологию Agile в процессе разработки, чтобы адаптироваться к этому быстро меняющемуся рынку. Эта тенденция требует от групп тестирования управления тестовыми наборами и тестовыми сценариями, которые необходимо поддерживать в соответствии с меняющимися требованиями. Поиск подходящего метода тестирования с самого начала — один из ключевых элементов успешного проекта программного обеспечения Agile.

НАЧАЛО РАБОТЫ С CUCUMBER BDD ДЛЯ АВТОМАТИЗИРОВАННОГО ТЕСТИРОВАНИЯ

Что такое Cucumber?

Фактически, многие Agile-команды успешно внедрили метод Behavior-Driven Development (BDD) для своего процесса тестирования с помощью инструмента Cucumber. Итак, что такое огурец? И почему эта стратегия рекомендуется для Agile-проектов вместе с BDD?

Cucumber — это инструмент, используемый для запуска автоматических приемочных тестов, созданных в формате BDD. Одной из наиболее выдающихся особенностей инструмента является возможность выполнять функциональные описания в виде простого текста (написанные на языке Gherkin) в виде автоматических тестов. Давайте посмотрим на приведенный ниже пример:

123456

Функция: обновление пароля  Сценарий: пользователь-администратор может обновить пароль пользователя. Если я нахожусь в системе управления персоналом с учетной записью администратора. Когда я обновляю пароль другого пользователя, я получаю сообщение об успешном обновлении пароля, и пароль пользователя обновляется до нового пароля

< p>Эта невероятная особенность подхода Behavior-Driven Development (BDD) со следующими преимуществами:

  • Написание тестов BDD на вездесущем языке, языке, структурированном вокруг модели предметной области и широко используемом всеми членами команды, состоящей из разработчиков, тестировщиков, бизнес-аналитиков и клиентов. команда разработчиков программного обеспечения.
  • Разрешено прямое взаимодействие с кодом разработчика, но тесты BDD написаны на языке, который также может быть понят заинтересованными сторонами бизнеса.
  • Последний но, что не менее важно, приемочные испытания могут выполняться автоматически, в то время как заинтересованные стороны бизнеса выполняют их вручную.

Cucumber помогает улучшить коммуникацию

Cucumber помогает улучшить общение между техническими и нетехническими участниками одного проекта. Давайте посмотрим на приведенное ниже требование и его тесты автоматизации:

12345678

Как пользователь-администратор, я хотел бы изменить пароль учетных записей других пользователей. Функция: Обновить пароль  Сценарий: Пользователь-администратор может обновить пароль пользователя    Учитывая, что я нахожусь в системе управления персоналом с учетной записью администратора    Когда я обновляю пароль другого пользователя    Тогда я получить сообщение об успешном обновлении пароля    И пароль пользователя обновлен до нового пароля

С помощью TestNG приведенный выше тестовый сценарий может быть реализован следующим образом: размер:4;-webkit-размер вкладки:4;размер вкладки:4;размер шрифта:12px!важно;высота строки:15px!важно>@test public void testAdminUserCanUpdateUserAccountPassword() { //создаем пользователей User userAdmin = new User(UserRole.ADMIN, username, password); Пользователь user = новый пользователь (UserRole.VIEWER, user_username, user_password); //использовать пользователя с правами администратора для обновления пароля другого пользователя String message = userAdmin.updatePassword(user, user_new_password); //проверка смены пароля Assert.assertEquals(message, "Пароль успешно изменен"); Assert.assertEquals(user.getPassword(), user_new_password); }

12345678910111213

@testpublic void testAdminUserCanUpdateUserAccountPassword() {  //создаем пользователей  User userAdmin = new User(UserRole.ADMIN, имя пользователя, пароль); Пользователь user = новый пользователь (UserRole.VIEWER, user_username, user_password); //использовать пользователя с правами администратора для обновления пароля другого пользователя   String message = userAdmin.updatePassword(user, user_new_password); //проверка смены пароля   Assert.assertEquals(message, “Пароль успешно изменен”); Assert.assertEquals(user.getPassword(), user_new_password);

Тот же тест можно написать с помощью Cucumber:

123456

Функция: Обновить пароль  Сценарий: пользователь-администратор может обновить пароль пользователя    Учитывая, что я нахожусь в системе управления персоналом с учетной записью администратора    Когда я обновляю пароль другого пользователя    Я получаю сообщение об успешном обновлении пароля    И пароль пользователя обновляется до нового пароля< /table>

Оба приведенных выше скрипта автоматизированного тестирования хорошо работают для автоматического завершения теста. Но все ли тестировщики вашей команды разбирают эти тесты? Могут ли другие бизнес-аналитики и другие заинтересованные лица снова использовать эти тесты на этапе приемочного тестирования (AT)?

Автоматизированное тестирование с помощью TestNG может быть сложным для большинства ручных тестировщиков и бизнес-аналитиков. Более того, повторно использовать этот тест для АТ нельзя. В результате, исходя из упомянутых ранее недостатков, этот метод нельзя считать подходящим.

В отличие от этого, автоматизированное тестирование с Cucumber BDD создается на языке бизнес-домена или на естественном языке, который может быть легко понят всеми членами группы разработки программного обеспечения. Коммуникация имеет решающее значение для любой команды разработчиков, особенно в Agile-команде. Обычно между разработчиками и тестировщиками происходит много непрерывных чатов, дискуссий или даже споров, чтобы выяснить, каково правильное поведение функции. Используя Cucumber, одна и та же спецификация функций теперь используется для разработки разработчиками и для тестирования тестировщиками. Он считается мощным инструментом, поскольку помогает снизить риск недопонимания, а также нарушения связи.

Cucumber – это автоматизированный инструмент приемочного тестирования

Приемочное тестирование обычно проводится бизнес-аналитиками/клиентами, чтобы убедиться, что команда разработчиков создала точные функции. Типичным действием на этом этапе тестирования является проверка системы на соответствие первоначальным требованиям с конкретными реальными данными из производства. Тестирование Cucumber не только следует требованиям в качестве тестовых сценариев, но также помогает бизнес-аналитикам или менеджерам по продуктам легко корректировать тестовые данные. Вот демонстрация с небольшими изменениями:

123456789

Как пользователь-администратор, я хотел бы изменить пароль учетных записей других пользователей. Функция: Обновить пароль  Сценарий: пользователь-администратор может обновить пароль пользователя    Учитывая, что я нахожусь в системе управления персоналом с учетной записью администратора    Когда я обновляю пароль другого пользователя    Я получаю сообщение об успешном обновлении пароля    И пароль пользователя обновляется до нового пароля< /таблица>

Тест автоматизации, написанный в Cucumber framework:

1234567891011

Схема сценария: Проверка функции обновления пароля пользователя  Учитывая, что я нахожусь в системе управления персоналом с учетной записью “<account_type>” и есть другой пользователь с паролем “<old_password>”,  когда я обновляю пароль пользователя на “<new_password>” Затем я получил сообщение “<message>”  И пароль пользователя должен быть “<final_password>” Примеры:|account_type  |old_password  |new_password |message                |final_password ||Admin         |$Test123      |@Test123     |Пароль изменен |.. @Test123       ||Просмотрщик        |$Test123      |@Test123     |Неправильный доступ.. |$Test123       |

Все тестировщики могут принять участие в автоматическом тестировании с помощью Cucumber

Помимо улучшения общения между членами одной и той же команды тестирования, Cucumber также помогает эффективно использовать навыки тестировщика. Дефицит знаний всегда существует в каждой организации. Другими словами, некоторые тестировщики обладают высокими техническими знаниями в области программирования с использованием автоматизированного тестирования, в то время как другие выполняют ручное тестирование с ограниченными навыками программирования в одной команде. Благодаря Cucumber все тестировщики, независимо от уровня их квалификации, могут участвовать в процессе выполнения автоматизированных тестов.

Давайте рассмотрим приведенный выше пример:

  • Любой тестировщик, знакомый с бизнес-логикой и рабочим процессом, может писать файлы функций, добавлять дополнительные сценарии и тестировать наборы данных.
  • Любой тестировщик, обладающий базовыми знаниями в области программирования и ноу-хау для создания объектов, доступа к свойствам, вызова методов, может генерировать определения шагов.
  • Любой тестировщик с более высоким уровнем навыков программирования может принять участие в процессе создания фреймворка, определить подключение к источнику данных и так далее.

Есть еще несколько потенциальных проблем при реализации Cucumber:

  • Cucumber помогает запускать тестовые сценарии, указанные в текстовом файле, используя знания предметной области. Таким образом, использование языков и восприятие того, кто создает тест, могут напрямую влиять на сценарии тестирования, что приводит к риску неправильного понимания. Тестовые сценарии должны быть представлены четко, а их реализация должна выполняться точно для каждого шага. Например, если вы хотите проверить функцию поиска в Google, тест должен быть следующим:

1234

Сценарий : выполнение поиска в googleУчитывая, что я нахожусь на сайте “www.google.com”, когда я ищу “огурец и BDD”, то…

Эти шаги могут быть включены для проведения следующего теста:

123

Сценарий : выполнение поиска в googleКогда я ищу “Огурец и BDD”Тогда …

Этапы инструмента Cucumber выполняются на обычном языке. Их можно снова использовать в различных тестовых сценариях. Это помогает сократить усилия по созданию тестов. Тем не менее, поддержание теста, чтобы он был одновременно читабельным и пригодным для повторного использования, — действительно большая проблема. Если тест написан на очень высоком уровне, чтобы все заинтересованные стороны могли его разобрать; несколько шагов, выделенных жирным шрифтом, можно использовать повторно: оба приведенных выше сценария верны; однако второй не очевиден, потому что он делает гораздо больше, чем ожидалось: открывает веб-сайт Google и выполняет поиск по указанному тексту. Представьте, что если вы хотите расширить тест для поиска большего количества текстов, вы можете повторить описанный выше шаг, и в результате сайт Google откроется дважды. Если вы не будете строго следовать этому требованию, инструмент тестирования Cucumber рано или поздно вызовет недопонимание, и его будет сложно поддерживать при расширении.

123456789101112

Функция: Обновить пароль  Сценарий: пользователь-администратор может обновить пароль пользователя    Учитывая, что я нахожусь в системе управления персоналом с учетной записью администратора    Когда я обновляю пароль другого пользователя    Я получаю сообщение об успешном обновлении пароля    И пароль пользователя обновляется до нового пароля   Сценарий : Пользователь Viewer не может обновить пароль пользователя    Учитывая, что я нахожусь в системе HR с учетной записью Viewer     Когда я обновляю пароль другого пользователя     Затем я получаю сообщение о невозможности обновить пароль пользователя     И пароль пользователя остается прежним

In Напротив, если тест является общим и может использоваться повторно, например, при проверке обновления фамилии пользователя, заинтересованным сторонам, не являющимся техническими специалистами, будет трудно наверстать упущенное и выполнить приемочные тесты:

123456789

Сценарий: пользователь с правами администратора может обновить пароль пользователя:  Если я нахожусь на странице “$System.HR_Page” с именем пользователя “admin@test.com” и паролем “$Test123”,  и есть другой пользователь на странице “$System.HR_Page” с именем “user@”. test.com”имя пользователя и пароль “$Test123”  Когда я обновляю “$UserTemplate.Password” пользователя “user@test.com” на “@Test123”  и сохраняю ответное сообщение как “response_message”  Тогда “$response_message” должен быть “Пароль успешно изменен”      “$UserTemplate.Password” пользователя “user@test.com” должен быть “@Test123”

В процессе тестирования вам необходимо регулярно корректировать тестовые сценарии, пока они полностью не достигнут приемлемого баланса, который смогут понять и использовать все участники.

123456

Сценарий: проверка функции обновления пароля пользователя  Учитывая, что я нахожусь в системе управления персоналом с учетной записью “Администратор” и есть еще один пользователь с паролем “$Test123”  Когда я обновляю пароль пользователя на “@Test123” , я получаю сообщение “Пароль изменен успешно.” И пароль пользователя должен быть “@Test123”

Или с некоторыми другими тестовыми данными:

1234567891011

Схема сценария: Проверка функции обновления пароля пользователя  Учитывая, что я нахожусь в системе управления персоналом с учетной записью “<account_type>” и есть другой пользователь с паролем “<old_password>”,  когда я обновляю пароль пользователя на “<new_password>” Затем я получил сообщение “<message>”  И пароль пользователя должен быть “<final_password>” Примеры:|account_type |old_password |new_password |message           |final_password ||Admin        |$Test123     |@Test123     |Пароль изменен. /table>

Важные примечания для группы тестирования, которая хочет начать работу с Cucumber

  • Считайте автоматические тесты столь же важными, как и реальный проект. Код должен соответствовать практике кодирования, соглашениям и т. д.
  • Следует рассмотреть соответствующий инструмент редактора. Этот редактор должен помочь отлаживать и редактировать файлы функций в стандартном текстовом формате. Aptana (бесплатный редактор), RubyMine (коммерческий редактор) и Katalon Studio — подходящие варианты, полностью поддерживающие Cucumber на основе BDD. вы можете сохранять полученные тестовые данные и форматировать тестовые данные. Бизнес-логика предметной области не включена.

В заключение, предлагая реальный коммуникационный уровень поверх надежной среды тестирования, Cucumber не только может выполнять автоматизированное тестирование по широкому спектру требований тестирования от бэкэнда до внешнего интерфейса, но и также создать глубокие связи между членами команд тестирования. Эта функция вряд ли встречается в других средах тестирования. Обладая многолетним опытом в области создания и применения автоматизированных тестов, я предлагаю применять Cucumber для тестирования веб-интерфейса и веб-сервисов в проектах гибкого программного обеспечения. Использование BDD на основе Cucumber с Katalon Studio в качестве редактора — правильный выбор, который может значительно сократить усилия по выполнению регрессионных тестов.

Автор: Тронг Буи, специалист по контролю качества в KMS-Technology

TAG: qa