Примеры сценариев для интеграционного тестирования#

Шаг 1-й:
    1) Клиент-генератор отправляет сообщения в тестируемый сервис/систему.
    2) Тестируемый сервис/система получает сообщение от генератора и отправляет сообщение в заглушку.
    3) Тестируемый сервис/система получает ответное сообщение от заглушки и отдает ответ в генератор.

Шаг 2-й:
    1) Клиент-генератор подключается к topic(s) запросов потребителя и эмулирует нагрузку.
    2) Тестируемая система/сервис вычитывает сообщение из данного topic(s) и отправляет сообщение в конечный topic(s) запроса поставщика.
    3) Заглушка вычитывает данное сообщение из конечного topic(s) запроса поставщика, генерирует и отдает ответ в topic(s) ответа.
    4) Тестируемая система вычитывает сообщение из topic(s) ответа поставщика и отправляет сообщение в конечный topic(s) ответа потребителя.
    5) Клиент-генератор получает данный ответ и коррелирует его со своим запросом.

Шаг 3-й:
    1) Клиент-генератор отправляет сообщения (xml/json) в тестируемый сервис/систему.
    2) Тестируемый сервис/система получает сообщение от генератора и отправляет сообщение в «заглушку».
    3) Тестируемый сервис/система получает ответное сообщение от «заглушки» и отдает ответ в генератор.

Шаг 4-й:
    1) Клиент-генератор отправляет сообщения (xml/json) в тестируемый сервис/систему.

Шаг 5-й:
    1) Клиент-генератор получает сообщения (xml/json) от тестируемого сервиса/системы.

1) В блоке transport для генератора указывается идентичные настройки, что были описаны в разделе "Сценарии использования":
    Сценарий 2. Генератор HTTP, заглушка HTTP. Синхронный режим.
    Сценарий 3. Генератор gRPC (HTTP/2), заглушка gRPC (HTTP/2). Синхронный режим.
    Сценарий 5. Запрос/ответ по протоколу KAFKA.

2) В блоке testdata прописываем шаблоны сообщения для генератора и «заглушки»:
    Данный блок содержит в себе тестовые данные, которые будут использоваться при интеграционном тестировании.
    В тестовых данных можно использовать переменные, их значение система подставит перед использованием этого шаблона данных.
    Помимо стандартных переменных ${rq_uid}, ${rnd_date|<format>} и ${rnd_number|<length>} можно в тестовых данных задавать 
    свои переменные, которые заполнять значениями из ответа вызываемых сервисов.
    Также при исполнении интеграционного сценария доступна валидация тела и заголовков сообщения по эталону с помощью 
    блока "message_to_compare":
    1) Для сравнения тела:
       Ожидаемый ответ задается в тестплане генератора (см. пример) с помощью параметра "body" в блоке "message_to_compare",
       который заполняется парой в виде key:value, где ключем является значение "body", а значением является ожидаемый ответ.
       Если необходимо пропустить валидацию для одного или нескольких тегов/параметров в xml/json, то нужно добавить
       соответствующий тег/параметр в значение атрибута "message_to_compare" -> "ignore_body_tags" в тестовых данных. (см. пример)
    2) Для сравнения заголовков:
       Ожидаемый ответ задается в тестплане генератора (см. пример) с помощью атрибута "compare_headers" в блоке "message_to_compare",
       который заполняется парой в виде key:value, где key является именем ключа ожидаемого заголовка, а value является
       ожидаемым значением. Если приходящий заголовок содержит rq_uid или случайную строку/дату (допустим таковые
       сгенерировала и прислала заглушка), то их можно сравнить с помощью переменных rq_uid, rnd_date и rnd_number.
       В случае rnd_date значение пришедшего заголовка будет проверено на соответствие формату, а в случае rnd_number
       и rq_uid значение пришедшего заголовка сопоставится по длине (для rq_uid фиксированная длина строки 32 символа).

Настройка «заглушек» для всех протоколов не отличается от настроек раздела "Сценарии использования"

3) В блоке testplan описываем сам сценарий тестирования, связывая его с сообщениями и подключениями по их именам:
    Уточнение: Для интеграционных тестов поддерживается 2 режима работы:
    1) Единоразовое выполнение интеграционной цепочки.
    2) Многократное выполнение интеграционной цепочки.
    Режим настраивается параметром: type, если type равен ONERUN, то тест отработает один раз, если type равен NT, 
    то цепочка будет выполняться многократно.
    
    Сами шаги интеграционного теста задаются в разделе steps тестового плана (Приведенные ниже параметры специфичны, 
    поэтому применяются только для интеграционных тестов). Каждая запись в разделе steps имеет следующую часть атрибутов:
        action – "PUT / GET", PUT – операция записи, например отправка сообщения в MQ очередь, отправка Rest / GRPC запроса. 
                  GET – операция чтения, сейчас реализована операция чтения из IBM MQ очереди и Kafka topic(s);
        vars – раздел для объявления новых переменных. Каждая запись имеет атрибуты type, path и varName;
        path – в зависимости от значения поля type данный параметр может содержать как простые строковые значения 
               (type: header, const), так и xpath и jsonpath пути (type: xpath, jsonpath, jsonInJson, xmlInJson);
               Работает при type равном NT:
        startTPS – начальный TPS в тесте;
        maxTPS – максимальный TPS в тесте;
        stepSize – шаг увеличения нагрузки;
        stepTimeMS – время в миллисекундах, после которого увеличивать нагрузку на stepSize.
    Примечание: В режиме многократного выполнения интеграционной цепочки (type: NT) генератор, при достижении maxTPS, подает 
    TPS равное maxTPS * кол-во шагов с операцией записи (action: PUT).Например, в тестовом плане задано 4 шага на запись и 
    maxTPS равен 50, тогда итоговый TPS генератора будет равен 200. Таким образом достигается целевой TPS равный 50 (maxTPS) 
    на каждый endpoint (шаг).

Шаг 1-й:
    1) Клиент-генератор отправляет сообщения в тестируемый сервис/систему.
    2) Тестируемый сервис/система получает сообщение от генератора и отправляет сообщение в заглушку.
    3) Тестируемый сервис/система получает ответное сообщение от заглушки и отдает ответ в генератор.

Шаг 2-й:
    1) Клиент-генератор подключается к очереди запросов потребителя и эмулирует нагрузку.
    2) Тестируемая система/сервис вычитывает сообщение из данной очереди и отправляет сообщение в конечную очередь запроса поставщика.
    3) Заглушка вычитывает данное сообщение из конечной очереди запроса поставщика, генерирует и отдает ответ в очередь ответа.
    4) Тестируемая система вычитывает сообщение из очереди ответа поставщика и отправляет сообщение в конечную очередь ответа потребителя.
    5) Клиент-генератор получает данный ответ и коррелирует его со своим запросом.

Шаг 3-й:
    1) Клиент-генератор подключается к topic(s) запросов потребителя и эмулирует нагрузку.
    2) Тестируемая система/сервис вычитывает сообщение из данного topic(s) и отправляет сообщение в конечный topic(s) запроса поставщика.
    3) Заглушка вычитывает данное сообщение из конечного topic(s) запроса поставщика, генерирует и отдает ответ в topic(s) ответа.
    4) Тестируемая система вычитывает сообщение из topic(s) ответа поставщика и отправляет сообщение в конечный topic(s) ответа потребителя.
    5) Клиент-генератор получает данный ответ и коррелирует его со своим запросом.

1) В блоке transport для генератора указывается идентичные настройки, что были описаны в разделе "Сценарии использования":
    Сценарий 2. Генератор gRPC (HTTP/2), заглушка gRPC (HTTP/2). Синхронный режим.
    Сценарий 7. Генератор Artemis, заглушка Artemis.
    Сценарий 5. Запрос/ответ по протоколу KAFKA.

2) В блоке testdata прописываем шаблоны сообщения для генератора и «заглушки»:
    Данный блок содержит в себе тестовые данные, которые будут использоваться при интеграционном тестировании.
    В тестовых данных можно использовать переменные, их значение система подставит перед использованием этого шаблона данных.
    Помимо стандартных переменных ${rq_uid}, ${rnd_date|<format>} и ${rnd_number|<length>} можно в тестовых данных задавать 
    свои переменные, которые заполнять значениями из ответа вызываемых сервисов. 
    Также при исполнении интеграционного сценария доступна валидация тела и заголовков сообщения по эталону с помощью блока "message_to_compare":
    1) Для сравнения тела:
       Ожидаемый ответ задается в тестплане генератора (см. пример) с помощью параметра "body" в блоке "message_to_compare",
       который заполняется парой в виде key:value, где ключем является значение "body", а значением является ожидаемый ответ.
       Если необходимо пропустить валидацию для одного или нескольких тегов/параметров в xml/json, то нужно добавить
       соответствующий тег/параметр в значение атрибута "message_to_compare" -> "ignore_body_tags" в тестовых данных. (см. пример)
    2) Для сравнения заголовков:
       Ожидаемый ответ задается в тестплане генератора (см. пример) с помощью атрибута "compare_headers" в блоке "message_to_compare",
       который заполняется парой в виде key:value, где key является именем ключа ожидаемого заголовка, а value является
       ожидаемым значением. Если приходящий заголовок содержит rq_uid или случайную строку/дату (допустим таковые
       сгенерировала и прислала заглушка), то их можно сравнить с помощью переменных rq_uid, rnd_date и rnd_number.
       В случае rnd_date значение пришедшего заголовка будет проверено на соответствие формату, а в случае rnd_number
       и rq_uid значение пришедшего заголовка сопоставится по длине (для rq_uid фиксированная длина строки 32 символа).
Настройка «заглушек» для всех протоколов не отличается от настроек раздела "Сценарии использования"

3) В блоке testplan описываем сам сценарий тестирования, связывая его с сообщениями и подключениями по их именам:
   Уточнение: Для интеграционных тестов поддерживается 2 режима работы:
    1) Единоразовое выполнение интеграционной цепочки.
    2) Многократное выполнение интеграционной цепочки.
       Режим настраивается параметром: type, если type равен ONERUN, то тест отработает один раз, если type равен NT,
       то цепочка будет выполняться многократно.

    Сами шаги интеграционного теста задаются в разделе steps тестового плана (Приведенные ниже параметры специфичны,
    поэтому применяются только для интеграционных тестов). Каждая запись в разделе steps имеет следующую часть атрибутов:
        action – "PUT / GET", PUT – операция записи, например отправка сообщения в MQ очередь, отправка Rest / GRPC запроса.
        GET – операция чтения, сейчас реализована операция чтения из IBM MQ очереди и Kafka topic(s);
        vars – раздел для объявления новых переменных. Каждая запись имеет атрибуты type, path и varName;
        path – в зависимости от значения поля type данный параметр может содержать как простые строковые значения
        (type: header, const), так и xpath и jsonpath пути (type: xpath, jsonpath, jsonInJson, xmlInJson);
    Работает при type равном NT:
        startTPS – начальный TPS в тесте;
        maxTPS – максимальный TPS в тесте;
        stepSize – шаг увеличения нагрузки;
        stepTimeMS – время в миллисекундах, после которого увеличивать нагрузку на stepSize.
    Примечание: В режиме многократного выполнения интеграционной цепочки (type: NT) генератор, при достижении maxTPS, подает
    TPS равное maxTPS * кол-во шагов с операцией записи (action: PUT).Например, в тестовом плане задано 4 шага на запись и
    maxTPS равен 50, тогда итоговый TPS генератора будет равен 200. Таким образом достигается целевой TPS равный 50 (maxTPS)
    на каждый endpoint (шаг).

Шаг 1-й:
    1) Клиент-генератор отправляет сообщения в тестируемый сервис/систему.
    2) Тестируемый сервис/система получает сообщение от генератора и отправляет сообщение в заглушку.
    3) Тестируемый сервис/система получает ответное сообщение от заглушки и отдает ответ в генератор.

Шаг 2-й:
    1) Клиент-генератор подключается к очереди запросов потребителя и эмулирует нагрузку.
    2) Тестируемая система/сервис вычитывает сообщение из данной очереди и отправляет сообщение в конечную очередь запроса поставщика.
    3) Заглушка вычитывает данное сообщение из конечной очереди запроса поставщика, генерирует и отдает ответ в очередь ответа.
    4) Тестируемая система вычитывает сообщение из очереди ответа поставщика и отправляет сообщение в конечную очередь ответа потребителя.
    5) Клиент-генератор получает данный ответ и коррелирует его со своим запросом.

Шаг 3-й:
    1) Клиент-генератор подключается к topic(s) запросов потребителя и эмулирует нагрузку.
    2) Тестируемая система/сервис вычитывает сообщение из данного topic(s) и отправляет сообщение в конечный topic(s) запроса поставщика.
    3) Заглушка вычитывает данное сообщение из конечного topic(s) запроса поставщика, генерирует и отдает ответ в topic(s) ответа.
    4) Тестируемая система вычитывает сообщение из topic(s) ответа поставщика и отправляет сообщение в конечный topic(s) ответа потребителя.
    5) Клиент-генератор получает данный ответ и коррелирует его со своим запросом.

1) В блоке transport для генератора указывается идентичные настройки, что были описаны в разделе "Сценарии использования":
    Сценарий 2. Генератор gRPC (HTTP/2), заглушка gRPC (HTTP/2). Синхронный режим.
    Сценарий 7. Генератор Artemis, заглушка Artemis.
    Сценарий 5. Запрос/ответ по протоколу KAFKA.

2) В блоке testdata прописываем шаблоны сообщения для генератора и «заглушки»:
    Данный блок содержит в себе тестовые данные, которые будут использоваться при интеграционном тестировании.
    В тестовых данных можно использовать переменные, их значение система подставит перед использованием этого шаблона данных.
    Помимо стандартных переменных ${rq_uid}, ${rnd_date|<format>} и ${rnd_number|<length>} можно в тестовых данных задавать 
    свои переменные, которые заполнять значениями из ответа вызываемых сервисов. Также при исполнении интеграционного 
    сценария доступна валидация тела и заголовков сообщения по эталону с помощью блока "message_to_compare":
    1) Для сравнения тела:
       Ожидаемый ответ задается в тестплане генератора (см. пример) с помощью параметра "body" в блоке "message_to_compare",
       который заполняется парой в виде key:value, где ключем является значение "body", а значением является ожидаемый ответ.
       Если необходимо пропустить валидацию для одного или нескольких тегов/параметров в xml/json, то нужно добавить
       соответствующий тег/параметр в значение атрибута "message_to_compare" -> "ignore_body_tags" в тестовых данных. (см. пример)
    2) Для сравнения заголовков:
       Ожидаемый ответ задается в тестплане генератора (см. пример) с помощью атрибута "compare_headers" в блоке "message_to_compare",
       который заполняется парой в виде key:value, где key является именем ключа ожидаемого заголовка, а value является
       ожидаемым значением. Если приходящий заголовок содержит rq_uid или случайную строку/дату (допустим таковые
       сгенерировала и прислала заглушка), то их можно сравнить с помощью переменных rq_uid, rnd_date и rnd_number.
       В случае rnd_date значение пришедшего заголовка будет проверено на соответствие формату, а в случае rnd_number
       и rq_uid значение пришедшего заголовка сопоставится по длине (для rq_uid фиксированная длина строки 32 символа).
       
Настройка «заглушек» для всех протоколов не отличается от настроек раздела "Сценарии использования"

3) В блоке testplan описываем сам сценарий тестирования, связывая его с сообщениями и подключениями по их именам:
    Уточнение: Для интеграционных тестов поддерживается 2 режима работы:
    1) Единоразовое выполнение интеграционной цепочки.
    2) Многократное выполнение интеграционной цепочки.
    Режим настраивается параметром: type, если type равен ONERUN, то тест отработает один раз, если type равен NT, 
    то цепочка будет выполняться многократно.
    
    Сами шаги интеграционного теста задаются в разделе steps тестового плана (Приведенные ниже параметры специфичны, 
    поэтому применяются только для интеграционных тестов). Каждая запись в разделе steps имеет следующую часть атрибутов:
        action – "PUT / GET", PUT – операция записи, например отправка сообщения в MQ очередь, отправка Rest / GRPC запроса. 
                  GET – операция чтения, сейчас реализована операция чтения из IBM MQ очереди и Kafka topic(s);
        vars – раздел для объявления новых переменных. Каждая запись имеет атрибуты type, path и varName;
        path – в зависимости от значения поля type данный параметр может содержать как простые строковые значения 
               (type: header, const), так и xpath и jsonpath пути (type: xpath, jsonpath, jsonInJson, xmlInJson);
               Работает при type равном NT:
        startTPS – начальный TPS в тесте;
        maxTPS – максимальный TPS в тесте;
        stepSize – шаг увеличения нагрузки;
        stepTimeMS – время в миллисекундах, после которого увеличивать нагрузку на stepSize.
    Примечание: В режиме многократного выполнения интеграционной цепочки (type: NT) генератор, при достижении maxTPS, подает 
    TPS равное maxTPS * кол-во шагов с операцией записи (action: PUT).Например, в тестовом плане задано 4 шага на запись и 
    maxTPS равен 50, тогда итоговый TPS генератора будет равен 200. Таким образом достигается целевой TPS равный 50 (maxTPS) 
    на каждый endpoint (шаг).

Шаг 1-й:
    1) Клиент-генератор отправляет сообщения в тестируемый сервис/систему.
    2) Тестируемый сервис/система получает сообщение от генератора и отправляет сообщение в заглушку.
    3) Тестируемый сервис/система получает ответное сообщение от заглушки и отдает ответ в генератор.

Шаг 2-й:
    1) Клиент-генератор подключается к очереди запросов потребителя и эмулирует нагрузку.
    2) Тестируемая система/сервис вычитывает сообщение из данной очереди и отправляет сообщение в конечную очередь запроса поставщика.
    3) Заглушка вычитывает данное сообщение из конечной очереди запроса поставщика, генерирует и отдает ответ в очередь ответа.
    4) Тестируемая система вычитывает сообщение из очереди ответа поставщика и отправляет сообщение в конечную очередь ответа потребителя.
    5) Клиент-генератор получает данный ответ и коррелирует его со своим запросом.

Шаг 3-й:
    1) Клиент-генератор подключается к topic(s) запросов потребителя и эмулирует нагрузку.
    2) Тестируемая система/сервис вычитывает сообщение из данного topic(s) и отправляет сообщение в конечный topic(s) запроса поставщика.
    3) Заглушка вычитывает данное сообщение из конечного topic(s) запроса поставщика, генерирует и отдает ответ в topic(s) ответа.
    4) Тестируемая система вычитывает сообщение из topic(s) ответа поставщика и отправляет сообщение в конечный topic(s) ответа потребителя.
    5) Клиент-генератор получает данный ответ и коррелирует его со своим запросом.

1) В блоке transport для генератора указывается идентичные настройки, что были описаны в разделе "Сценарии использования":
    Сценарий 2. Генератор gRPC (HTTP/2), заглушка gRPC (HTTP/2). Синхронный режим.
    Сценарий 7. Генератор Artemis, заглушка Artemis.
    Сценарий 5. Запрос/ответ по протоколу KAFKA.

2) В блоке testdata прописываем шаблоны сообщения для генератора и «заглушки»:
    Данный блок содержит в себе тестовые данные, которые будут использоваться при интеграционном тестировании.
    В тестовых данных можно использовать переменные, их значение система подставит перед использованием этого шаблона данных.
    Помимо стандартных переменных ${rq_uid}, ${rnd_date|<format>} и ${rnd_number|<length>} можно в тестовых данных задавать 
    свои переменные, которые заполнять значениями из ответа вызываемых сервисов. Также при исполнении интеграционного сценария 
    доступна валидация тела и заголовков сообщения по эталону с помощью блока "message_to_compare":
    1) Для сравнения тела:
       Ожидаемый ответ задается в тестплане генератора (см. пример) с помощью параметра "body" в блоке "message_to_compare",
       который заполняется парой в виде key:value, где ключем является значение "body", а значением является ожидаемый ответ.
       Если необходимо пропустить валидацию для одного или нескольких тегов/параметров в xml/json, то нужно добавить
       соответствующий тег/параметр в значение атрибута "message_to_compare" -> "ignore_body_tags" в тестовых данных. (см. пример)
    2) Для сравнения заголовков:
       Ожидаемый ответ задается в тестплане генератора (см. пример) с помощью атрибута "compare_headers" в блоке "message_to_compare", 
       который заполняется парой в виде key:value, где key является именем ключа ожидаемого заголовка, а value является 
       ожидаемым значением. Если приходящий заголовок содержит rq_uid или случайную строку/дату (допустим таковые 
       сгенерировала и прислала заглушка), то их можно сравнить с помощью переменных rq_uid, rnd_date и rnd_number.
       В случае rnd_date значение пришедшего заголовка будет проверено на соответствие формату, а в случае rnd_number 
       и rq_uid значение пришедшего заголовка сопоставится по длине (для rq_uid фиксированная длина строки 32 символа).
       
Настройка «заглушек» для всех протоколов не отличается от настроек раздела "Сценарии использования"

3) В блоке testplan описываем сам сценарий тестирования, связывая его с сообщениями и подключениями по их именам:
    Уточнение: Для интеграционных тестов поддерживается 2 режима работы:
    1) Единоразовое выполнение интеграционной цепочки.
    2) Многократное выполнение интеграционной цепочки.
    Режим настраивается параметром: type, если type равен ONERUN, то тест отработает один раз, если type равен NT, 
    то цепочка будет выполняться многократно.
    
    Сами шаги интеграционного теста задаются в разделе steps тестового плана (Приведенные ниже параметры специфичны, 
    поэтому применяются только для интеграционных тестов). Каждая запись в разделе steps имеет следующую часть атрибутов:
        action – "PUT / GET", PUT – операция записи, например отправка сообщения в MQ очередь, отправка Rest / GRPC запроса. 
                  GET – операция чтения, сейчас реализована операция чтения из IBM MQ очереди и Kafka topic(s);
        vars – раздел для объявления новых переменных. Каждая запись имеет атрибуты type, path и varName;
        path – в зависимости от значения поля type данный параметр может содержать как простые строковые значения 
               (type: header, const), так и xpath и jsonpath пути (type: xpath, jsonpath, jsonInJson, xmlInJson);
               Работает при type равном NT:
        startTPS – начальный TPS в тесте;
        maxTPS – максимальный TPS в тесте;
        stepSize – шаг увеличения нагрузки;
        stepTimeMS – время в миллисекундах, после которого увеличивать нагрузку на stepSize.
    Примечание: В режиме многократного выполнения интеграционной цепочки (type: NT) генератор, при достижении maxTPS, подает 
    TPS равное maxTPS * кол-во шагов с операцией записи (action: PUT).Например, в тестовом плане задано 4 шага на запись и 
    maxTPS равен 50, тогда итоговый TPS генератора будет равен 200. Таким образом достигается целевой TPS равный 50 (maxTPS) 
    на каждый endpoint (шаг).