Применение тестирования BDD для пакетных сценариев?

Question

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

Во время наших тестов интерактивные онлайн-тесты, вероятно, составляют всего 40-50% тестовых сценариев, а остальные встроены в пакетное задание. В качестве примера, тестовый сценарий может быть:

1. Учитывая, что мой сберегательный счет имеет баланс $ 100 по состоянию на 10 вечера
2. Когда еженощно партия запускается в 11pm
3. Затем в 3 часа после пакетного запуска я должен вернуться и посмотреть, что у меня есть дополнительный начисленный процент в размере 0,001 доллара США.
4. И в главной книге банка должна быть дополнительная запись для начисленных процентов в размере 0,001.

Как вы можете видеть, это чрезвычайно асинхронный сценарий. Если я должен использовать Cucumber для его запуска, возможно, я смогу создать определение шага, чтобы вставить баланс $ 100 в учетную запись на 10PM, но не будет реалистично использовать Cucumber для запуска партии, которая будет запускаться с 11:00, когда пакетные задания обычно выполняемые операторами с использованием собственных средств планирования, таких как Control-M. И имея Огурцов, подождите и послушайте несколько часов, прежде чем проверять начисленные проценты, я не уверен, что я натолкнулся на тайм-аут или нет.

Это всего лишь один сценарий. Пакетные трассы очень дороги для банка, и мы всегда придерживаемся как можно большего числа сценариев, чтобы ездить на одном групповом запуске. У нас также есть сценарии старения, когда нам нужно запустить 6 месяцев партии, чтобы проверить, является ли окончательный интерес в конце срочного депозита правильным или нет (я определенно не могу заставить Огурца ждать и слушать так долго, не так ли?)

Мой вопрос в том, есть ли какой-либо пример, где методы BDD применялись к таким крупным сценариям, как эти? Как можно подойти к этому?

Изменить, чтобы объяснить, почему я не была направлена ​​на выполнение изолированных тестовых сценариев, где я нахожусь в контроле:

Мы делаем отдельные сценарии, в одном из уровней тестирования (мы называем его испытания системы в моем банке) и BDD действительно работает в этом контексте. Но в конечном итоге нам нужно попасть на тестовый уровень, который имеет всю сквозную среду, как правило, в SIT. В этой среде это критерий для параллельного запуска нескольких сценариев тестирования, ни один из которых не имеет полного контроля над средой. В зависимости от объема проекта эта среда может работать до 200 приложений. Таким образом, каналы клиентов, такие как Интернет-банк, будут запускать сценарии транзакций, которые будут выполняться в основной банковской системе, будут выполнены сценарии, такие как расчет процентов, автоматические переводы и т. Д. Будут также сценарии учета, при которых система главной книги объединяет и балансирует все учетные записи в среде. Для проведения ручного тестирования в этой среде часто требуется не менее 30-50 человек, выполняющих транзакции и проверяющих результаты.

То, что я пытаюсь сделать, - найти способ использовать механизм BDD для автоматизации выполнения теста и захвата результатов, чтобы нам не пришлось вручную отслеживать их все в среде.

Answer 1

Это звучит так, как будто вы не контролируете выполнение сценария.

Очевидно, что ожидание пары часов до подтверждения результата - не очень хорошая идея.

Возможно ли извлечь только ту часть партии, которая интересна в этом сценарии? Если это возможно, я бы не ожидал, что время выполнения составит 4 - 6 часов.

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

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

Answer 2

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

Я предполагаю, что каждый пакетный запуск имеет уникальный идентификатор. Этот идентификатор будет использоваться в качестве ключа для результатов теста.

Вот пример того, как это может работать:

• Мы знаем, когда партии пробеги закончены (скажем, это в 4 утра). Мы планируем, что задание на отчетность начнется после завершения пакетного запуска (скажем, в 5 часов утра), которое анализирует тестовые учетные записи.
• В задании по отчетности рассматривается учетная запись X и учетная запись Y. Она регистрирует сумму денег в своей учетной записи в таблице вместе с уникальным идентификатором для пакетного запуска. Эта информация хранится в базе данных результатов тестирования.
• Отдельный процесс соответствует тестовым сценариям с результатами испытаний. Он знает, что тестовый сценарий 29 был привязан к пакетному запуску ZZ20, и поэтому он просматривает базу данных результатов теста для анализа из пакетного запуска ZZ20.
• Утром инженер-испытатель проверяет результаты прогона. Они видят, что тестовый сценарий 29 потерпел неудачу, поскольку в счете X было всего 100 фунтов стерлингов, а не ожидалось 100,00 фунтов стерлингов.

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