Использование SpecFlow для сквозного регрессионного тестирования

Мы используем BDD и SpecFlow для стимулирования нашего развития (ATDD).

Наша команда QA хотела бы определить свои собственные «сквозные регрессионные тесты» (в Gherkin / SpecFlow) и повторно использовать шаги, которые мы уже определили.

(Обратите внимание - я знаю, что это не лучший пример, но он должен содержать достаточно подробностей)

Тест может включать ..

  1. Авторизоваться
  2. Искать продукт
  3. Выберите товар для покупки
  4. Создать заказ
  5. Выберите вариант доставки.
  6. Отправьте заказ.
  7. Отменить заказ.

Это предполагает такой сценарий ..

Если я вошел в систему
Когда я ищу продукт
И я выбираю продукт для покупки
И я создаю заказ
И я выбираю вариант доставки
И я Отправьте заказ
И я Отменю заказ
Тогда ?? !!

Что явно неверно, поскольку мы не проверяем вывод на каждом шаге.

Таким образом, это может быть разрешено как последовательность сценариев:

Сценарий 1:
Если я вошел в систему
Когда я ищу продукт
Затем я вижу список продуктов

Сценарий 2:
Когда я выбираю продукт для покупки
Затем я могу создать заказ

Сценарий 3:
Когда я создаю заказ
и выбираю вариант доставки
Затем я могу отправить заказ

и т. д. и т. д.

Основная проблема заключается в том, что, похоже, нет способа указать порядок / последовательность, в которой запускаются сценарии (характеристика nUnit?). Поскольку между сценариями существуют зависимости (для них не задана известная начальная точка), они должны выполняться последовательно.

Мои вопросы:

а) Мы пытаемся вставить квадратный колышек в круглое отверстие ?!

б) Кто-нибудь знает, есть ли способ использовать SpecFlow / Gherkin таким образом?

в) Или кто-нибудь знает, какие есть альтернативы?

Большое спасибо!


person Mark Chidlow    schedule 13.12.2011    source источник


Ответы (1)


Я бы сказал, что вы пишете свои сценарии не на том уровне абстракции. Но это зависит от того, для чего вы хотите их использовать;

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

Я бы посоветовал вам объединить ATDD-тесты, которые вы пишете, и поговорить с отделом тестирования, чтобы узнать их мнение по этому поводу и включить тестовые примеры, необходимые им для тщательного тестирования системы. Кто знает? Вы можете даже чему-то научиться друг у друга: P

И когда вы пишете эти «спецификации» (как я их скорее называю), вы пишете их на более высоком уровне. Итак, вместо того, чтобы писать:

Given I am logged in
When I Search for a product
  And I Select a product to buy
  And I Create an order
  And I Select delivery option
  And I Submit the order

ты пишешь что-то вроде

When I submit an order for product 'Canned beans'

В определениях шагов, стоящих за этим шагом, вы выполняете всю эту автоматизацию (вход в систему, переход на страницу продукта, выбор вариантов доставки, отправка заказа).

Обо всем этом можно прочитать в этих замечательных статьях о том, как писать легко обслуживаемые тесты автоматизации пользовательского интерфейса:

надеюсь, это поможет

person Marcus Hammarberg    schedule 14.12.2011
comment
Большое спасибо за ваш ответ, Маркус, и статьи, которые вы перечисляете - очень полезно! Теперь я немного прояснил вопрос теста. То есть «есть ли у нас возможность связывать уже написанные сценарии вместе для последовательного запуска для выполнения сквозных системных тестов?» например войдите в систему, просмотрите продукты, затем отправьте заказ, затем зарегистрируйте учетную запись, затем отредактируйте учетную запись, затем выполните поиск заказов, затем просмотрите заказ, затем отмените заказ и т.д. похоже, что это не способ запускать сценарии в определенном порядке. - person Mark Chidlow; 15.12.2011
comment
Обновление: если сценарии называются «001 Сделай это», «002 Сделай это» и т. Д., То они запускаются в указанном порядке. Кажется немного взломанным, но для наших целей этого достаточно, пока не будет найдено лучшее решение. - person Mark Chidlow; 15.12.2011
comment
Я бы настоятельно рекомендовал не писать сценарии, зависящие от порядка. Это будет трудно поддерживать ... - person Marcus Hammarberg; 15.12.2011
comment
Мне было интересно, почему вы используете BDD для регрессионного тестирования. Как говорится в официальном документе, его следует использовать для приемочных испытаний. - person Apoorv; 10.02.2020