Додаток 5. Приклад тест-кейсів для контрактного тестування

Цей додаток містить приклади тест-кейсів для контрактного тестування Consent API, зокрема сценарії створення, авторизації, перевірки статусу та відкликання згоди.

Тест №1.1. Cтворення згоди

1. POST /v2/consents/account-access (див. розділ 5)

Примітка: потрібно передати reccuringindicator, який дорівнює:

• 1 кейс – false;

• 2 кейс – true. | | Очікуваний результат | Позитивний:

• Згода створена, HTTP status code = 201 (див. розділ 5)

Негативний:

• Згода не створена, HTTP code ≠ 201:
  • невідповідність або невалідність даних QWAC та Реєстрі платіжної інфраструктури;
  • переданий некоректний IBAN;
  • IBAN не належить цьому ASPSP;
  • балансовий рахунок не входить у перелік рахунків відкритого банкінгу;
  • некоректний request syntax;
  • некоректний semantics. | | Постумова | Згода створена у статусі received. |

Тест №1.2. Авторизація ресурсу згоди

1. POST /v2/{resource-path}/{resourceId}/{authorisation-category} (див. розділ 9.1 Протоколу функцій та заходів безпеки) | | Очікуваний результат | Позитивний:

• Ресурс згоди авторизований, HTTP status code = 201

Негативний:

• Ресурс згоди не авторизований, HTTP status code ≠ 201:
  • невідповідність або невалідність даних QWAC та Реєстрі платіжної інфраструктури;
  • переданий некоректний resourceId;
  • некоректний request syntax;
  • некоректний semantics. | | Постумова | Для SCA Redirect отриманий лінк для перенаправлення PSU для проходження SCA на стороні ASPSP.

Для Decoupled користувач отримав push-повідомлення для проходження SCA. |

Тест №1.3. Перевірка статусу згоди

1. GET consents/account- access/{consentId} (повертає повну інформацію про згоду)

або

2. GET /v2/consents/{consent-category}/{consentId}/status (повертає тільки статус згоди). (див. розділ 6).

Примітка: AISP на власний розсуд вирішує, чи потрібно тестувати обидва endpoint.

Потрібно протестувати отримання статусу:

• А – створеної згоди;

• Б – попередньої згоди по цьому ж рахунку (якщо така була: разова та множинна). | | Очікуваний результат | Позитивний:

• HTTP status code = 200, отриманий Consent status (див. розділ 6)

Негативний:

• HTTP status code ≠ 200:
  • невідповідність або невалідність даних QWAC та Реєстрі платіжної інфраструктури;
  • некоректний request syntax;
  • некоректний semantics;
  • некоректний/неіснуючий consentid. | | Постумова | Відсутня |

Тест №1.4. Відкликання згоди PSU через AISP

1. DELETE /v2/consents/{consent-category}/{consentId} (див. розділ 7)
2. Виконує тест-кейс 1.3 для перевірки статусу відкликаної згоди. | | Очікуваний результат | Позитивний:

• HTTP status code = 204, Consent status = terminatedByTPP

Негативний:

• HTTP ≠ 204:
  • невідповідність або невалідність даних QWAC та Реєстрі платіжної інфраструктури;
  • некоректний request syntax;
  • некоректний semantics;
  • некоректний/неіснуючий consentid;
  • Consent status ≠ terminatedByTPP. | | Постумова | Відсутня |

Примітки

1. TPP Registration Number — OrganizationIdentifier у QWAC. Наприклад, PSDU-NBU–123456, де 123456 — це код ID НБУ (NbuId) — єдиний ідентифікатор, що присвоюється Національним банком України установі.
2. TPP Name — це поле Organization (O) у QWAC.
3. TPP Role — RolesOfPSP(0.4.0.19495.1)X509v3 extensions.qcStatements.
4. TPP National Competent Authority — OrganizationIdentifier – PSDU-NBU.
5. Resource ID — зверніть увагу, що Resource ID транспортується в path після формування ресурсу згоди. Це параметр path без явного кодування імені атрибута.