Автоматизирование тестирование на заглушках при помощи фреймворка AT Framework BSC

В продолжение цикла статей о тестировании1 и о тестировании на заглушках2, в данной статье описан процесс работы с фреймворком работы с заглушками AT Framework BSC.

AT Framework BSC – программное обеспечение, как часть подхода для автоматизированного тестирования.

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

Тестируемое приложение обменивается данными через шину с помощью настройщика очередей IBM MQ или через микросервисы3 с помощью REST API. Поэтому фреймворк должен уметь работать с разными видами обмена сообщениями. Для эмуляции работы шины, так же как и для фреймворка Citrus, необходимо задать хост и имена очередей. Для эмуляции работы микросервисов необходимо переопределить URL4, куда будут уходить запросы от приложения. Соответственно, фреймворк от BSC должен «слушать» те же самые очереди и отвечать на запросы.

Для работы мокирования очередей необходимо в файле application.properties указать параметры для подключения к провайдеру:

mq.manager - Тип провайдера (IBM_MQ, RABBIT_MQ, ACTIVE_MQ);

mq.username - Имя пользователя;

mq.password – Пароль.

Для запуска WIREMOCK необходимо выполнить команду:

Интерфейс для управления REST-заглушками и просмотр журналов доступны по адресу:

http://:1397/ui/

Рисунок 1. Интерфейс для управления REST-заглушками

^ a ☆ ^ БЗ f s □ e о

BSC WireMOCk Mapping» REST log MQtog

О Update rtouest list 30   * X Clear

CI_COMMO«_TEST_Ra >

CI_COMMOH_7EST_Ra * C_COMMOM_7EST_RS CI_COMMO.'t.7EST_RQ > C_COMMON_TE5T_RS C1_COMMON_7EST_R<1 J CI_COMMON_TEST_RS CLCOMMO^TEST-RQ э CI_COMMON_TES7_RS Cl_COMM№_1EST_RO > CLCOMMON,TEST„RS Ci_COMMCW_TEST_RQ > GLCONMON_TEST_RS CI_COMMON_TEST_Ra > CLCOMMON_TEST_R$ CI_COMM№_7EST_RQ > CLCQMMQN_TEST_RS CLCOMMC, TEST, -1 : DC IMON TEST R5 Cl_COMMOS_7EST_R a * C_COMMON_7EST_RS Cl_COMMON_7EST_RQ > CI_COMMON_TEST_RS CI_COMMO&_7E£T_RO > Cl_COMMON_TEST_RS Ci_COMM№LlEST_Ra > CI_COMMON_TE5T_RS Cl_COMMe«_TEST_RO > C!_COMMON_TEST_R$ CI_COMMON_TEST_RO > CI_COMMON_TEST_R$ С1_СОММОМ_ТЕ5Т_На > CI_COMMON_TEST_RS CI_COMMOM_TEST_RQ > CI_CQMMOM_TEST_RS Cl_COMMON_TEST_Ra » CI_CCMMON_TEST_RS CI_COMMOW_TEST_RQ > Cl_COMMON_TES7_RS Ci_COMMCd;_1EST_RO > CLCOMMON„TEST_RS Ci_C0mmCw_7EST_R0 , Ci_COMWON_TE$T_R5

Cl_COMM№_TEST_Ra > CI_CC*1MON_TEST_RS

Таким образом, все сообщения, поступающие в очередь QUEUE_OUT_MOCK, будут пересылаться в очередь QUEUE_OUT.

В общем виде подкладываемая заглушка имеет следующий вид: { "guid": "string", "httpUrl": "string", "responses": [ { destinationQueueName": "string", "responseBody": "string" } ], “sourceQueueName": "string "testId": "string “xpath": "string" }

Заполненный JSON отправляется по адресу через Rest POST-запросом: https://:1397/mq-mock/__admin/add_mapping

JSON-ответ для Rest API отправляется по адресу POST-запросом https://:1397/

Данный инструмент, в отличии от Citrus, имеет ряд преимуществ:

• 1.    Заглушки через API добавляются, удаляются, просматривается список всех заглушек

• 2.    Заглушки можно добавлять и удалять в реальном времени или в конфигурационном файле держать дефолтный список

• 3.    Заглушки могут быть как уникальны под тестовые данные, так и быть дефолтными

• 4.    Уникальность заглушек достигается благодаря xpath request'a

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

• 1.    Отсутствовала многопочность при обновлении списка респонсов.

• 2.    Не было возможности получить все логи.

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