Тестирование¶
Партнёр может протестировать взаимодействие с BaaS перед тем, как предоставить продукт реальному клиенту. Для этого необходимо совершить следующие шаги:
Получение доступа¶
Для получения доступа обратитесь к вашему курирующему менеджеру. Менеджер запросит необходимую информацию и:
- сообщит о факте выдачи доступа;
- предоставит Bearer-токен и
productId
для авторизации запросов к тестовой среде BaaS.
После сообщения о выдаче доступа проверьте результат: отправьте запрос на создание клиента. Если клиента не удалось создать, обратитесь к курирующему менеджеру.
Выполнение сценариев¶
У каждого продукта есть свой набор бизнес-сценариев. Ниже представлен пример тестового сценария, состоящего из типовых функций BaaS.
Обратите внимание
При выполнении сценария следуйте правилам тестирования.
%%{init: {
"sequence" : {
"wrap":true,
"messageFontSize":14,
"noteFontSize":14,
"actorMargin":
155 }}}%%
sequenceDiagram
participant С as Клиент
participant P as Партнёр
participant B as BaaS
С->>P: Регистрация
P->>+B: Создание клиента и счёта
B-->>-P:
P->>С: Запрос данных для идентификации
Note over С,P: "Добро пожаловать! Расширьте свои возможности, пройдя идентификацию"
С->>P: Ввод данных
P->>+B: Упрощённая идентификация
B-->>-P:
P->>С: Коммуникация с клиентом
Note over С,P: "Идентификация успешна. Выпустите карту и оплачивайте покупки в интернете"
С->>P: Запрос на выпуск карты
P->>+B: Выпуск виртуальной карты
B-->>-P:
P->>С: Коммуникация с клиентом
Note over С,P: "Карта выпущена, осталось её пополнить"
С->>P: Пополнение карты
P->>+B: Пополнение с банковской карты
B-->>-P:
P->>С: Коммуникация с клиентом
Note over С,P: Пополнение успешно
Note left of С: Оплата покупок с виртуальной картой в интернет-магазине
B->>+P: Уведомление о покупке
P-->>-B:
P->>С: push-уведомление
С->>P: Просмотр истории платежей
P->>+B: Получение истории платежей
B-->>-P:
P->>С: Отображение списка платежей
С->>P: Просмотр лимитов
P->>+B: Получение лимитов
B-->>-P:
P->>С: Отображение списка лимитов и остатков в рамках лимитов
Указанные на диаграмме этапы см. в статьях BaaS → :
- → «Управление клиентом и его счётом» → «Создание клиента и счёта»;
- → «Идентификация» → «Сценарии» → «Упрощённая идентификация»;
- → «Управление банковской картой» → «Сценарии» → «Выпуск виртуальной карты»;
- → «Пополнение» → «Сценарии» → «Пополнение с банковской карты»;
- → «Уведомления»;
- → «История платежей»;
- → «Лимиты».
Правила тестирования¶
URL-адрес для вызовов API¶
Во время тестирования запросы должны быть отправлены на URL-адрес https://api-test.qiwi.com.
Работа с ошибками¶
Формат ответа при неуспешном запросе к API:
Поле | Обязательное/Опциональное | Описание |
---|---|---|
serviceName | Обязательное | Имя сервиса, который вернул ошибку |
errorCode | Обязательное | Код ошибки: cм. справочник кодов ошибок в документации API (см. BaaS → «Описание API») |
dateTime | Обязательное | Дата и время формирования ответа |
traceId | Обязательное | Параметр, необходимый для анализа логов. Его значение также присутствует в заголовке ответа X-B3-TraceId |
cause | Опциональное | Объект с информацией о причине возникновения ошибки. В случае возникновения ошибки валидации содержит элемент вида <fieldName> .value , где:• <fieldName> — название параметра запроса, значение которого заполнено некорректно;• value — корректное значение, которое необходимо указать в запросе для параметра <fieldName> |
{
"serviceName": "openapi-payment-api",
"errorCode": "validation.error",
"dateTime": "2020-07-23T20:13:22.290416+03:00",
"traceId": "67477569e8bc6838",
"cause": {
"fromFunderId.value": [
"Abc-123-DEF-456" # string, regex: ^[A-Za-z0-9-]{1,100}$
]
}
}
В примере выше причиной ошибки валидации данных (validation.error
) является некорректно заполненное значение параметра fromFunderId
. Корректным значение является строка, удовлетворяющая регулярному выражению ^[A-Za-z0-9-]{1,100}$
.
Если получен ответ с ошибкой, выполните следующие действия:
- Изучите описание, указанное для значения
errorCode
в справочнике кодов ошибок. - Измените параметры запроса или сформируйте новый запрос таким образом, чтобы устранить ошибку.
- Отправьте запрос повторно.
Пример
В errorCode
вернулась ошибка openapi.clients.client.not.found
, которая означает, что клиент не найден. Проверьте, был ли успешно создан клиент с указанным в запросе идентификатором. Если такой клиент не был создан, выполните одно из действий:
- создайте его и повторите запрос;
- укажите в запросе идентификатор ранее созданного клиента.
Если ошибку не удаётся устранить, скопируйте значение traceId
из ответа и направьте его представителям BaaS. Канал общения определяется для каждого партнёра индивидуально.
Обратите внимание
Предоставление traceId
является обязательным условием для анализа ошибки.
Функциональность¶
Функциональность, описанная в разделе BaaS на developer.qiwi.com/explain, доступна для тестирования. Исключение — проведение операций домена CARDS
.
Примеры операций домена CARDS
:
- оплата товаров и услуг в неавторизованной зоне;
-
Заём может быть выдан только во время покупки в неавторизованной зоне, а такая покупка относится к операциям домена
CARDS
. - просмотр баланса в неавторизованной зоне
и т.д.
Таким образом для тестирования доступны все методы, указанные в документации из раздела BaaS → «Описание API», и не доступно совершение любых операций, относящихся к домену CARDS
.
Пример
Эмулировать оплату товаров и услуг в неавторизованной зоне не удастся, однако получать уведомления о таких операциях партнёр может.
Особенности тестирования, если они имеются, вы найдёте в:
- статье «Тестирование» нужной вкладки меню портала;
- разделе «Тестирование» внутри статьи с описанием нужной функциональности.
Примеры из вкладки меню BaaS:
- «Идентификация» → «Сценарии» → статья «Тестирование»;
- «Управление банковской картой» → «Сценарии» → «Выпуск виртуальной карты» → раздел «Тестирование»;
- «Пополнение» → «Сценарии» → «Пополнение с банковской карты» → раздел «Тестирование»;
- «Расходные операции» → «Сценарии» → «Перевод на банковскую карту» → раздел «Тестирование»;
- «Уведомления» → раздел «Тестирование»;
- «История платежей» → раздел «Тестирование».