Testy agregacji danych z rachunków płatniczych (AIS)
Scenariusz testowy AIS1.
ID | Krok | Test | Rezultat oczekiwany | Dodatkowe sprawdzenia | Komentarz |
1 | Pobranie listy wspieranych krajów | Wywołanie metody GET ##{{api_url}}/country | Lista krajów | Weryfikacja struktury odpowiedzi wykonywana jest automatycznie w ramach CI/CD. | |
2 | Pobranie listy wspieranych ASPSP | Wywołanie metody GET ##{{api_url}}/country/PL/bank | Lista ASPSP Każdy ASPSP posiada przypisany kod SWIFT | Weryfikacja przypisania poszczególnych ASPSP do api-clientId Sprawdzenie w bazie LDS select b.id, b.name, psd2p.Config, psd2c.ConnectorName | Weryfikacja struktury odpowiedzi wykonywana jest automatycznie w ramach CI/CD. |
2a | Pobieranie szczegółów dotyczących banku na bazie swiftCode | Wywołanie metody GET ##{{api_url}}/bank/SwiftCode/##{{swiftCode}} | Szczegóły dotyczące banku | Sprawdzenie w bazie LDS select * from Bank b join BankIdentifier bi on bi.BankId = b.Id | Weryfikacja struktury odpowiedzi wykonywana jest automatycznie w ramach CI/CD. |
2b | Pobieranie szczegółów dotyczących banku na bazie id banku | Wywołanie metody GET ##{{api_url}}/bank/##{{bankId}} | Szczegóły dotyczące banku | Sprawdzenie w bazie LDS select * from Bank where Id = ##{{bankId}} | Weryfikacja struktury odpowiedzi wykonywana jest automatycznie w ramach CI/CD. |
2c | Pobieranie szczegółów dotyczących banku z podaniem dwóch różnych api-clientId | Wywołanie metody: GET ##{{api_url}}/bank/ | Szczegóły dotyczące banku dla określonych api-clientId | Sprawdzenie w bazie LDS: select * from ApiClientBank acb join ApiClient ac on ac.Id = acb.ApiClientId | Weryfikacja struktury odpowiedzi wykonywana jest automatycznie w ramach CI/CD. |
3 | Utworzenie użytkownika APIHub | Wywołanie metody POST ##{{api_url}}/user z podaniem nowego unikalnego api-userId = userId | User zostaje dodany w LDS. Metoda GET/##{{api_url}}/user/userId gdzie {userId} to identyfikator podany w metodzie POST zwraca dane użytkownika (HTTP 200) | Sprawdzenie w bazie LDS SELECT * FROM aspnetusers WHERE ExternalId = userId zwraca 1 rekord | Weryfikacja struktury odpowiedzi wykonywana jest automatycznie w ramach CI/CD. |
3a | Utworzenie użytkownika PSD2Hub dla nowo przekazanego identyfikatora przy inicjacji AIS | Wywołanie metody POST ##{{api_url}}/bank/{bankId}/authorize | User zostaje dodany w LDS. Metoda GET/##{{api_url}}/bank/{bankId}/authorize zwraca dane użytkownika (HTTP 200) | Sprawdzenie w bazie LDS SELECT * FROM aspnetusers WHERE ExternalId = userId zwraca 1 rekord | Weryfikacja struktury odpowiedzi wykonywana jest automatycznie w ramach CI/CD. |
4 | Usunięcie użytkownika APIHub | Wywołanie metody DELETE ##{{api_url}}/user z podaniem api-userId = userId użytego w kroku 3 | User zostaje usunięty z LDS. Metoda GET/##{{api_url}}/user/userId gdzie userId to identyfikator podany w metodzie DELETE zwraca brak użytkownika (HTTP 200) i komunikat: { "data": null, "success": true } | Sprawdzenie w bazie LDS SELECT * FROM aspnetusers WHERE ExternalId = userId zwraca 0 rekordów | Weryfikacja struktury odpowiedzi wykonywana jest automatycznie w ramach CI/CD. |
5 | Zainicjowanie sesji AIS | Wywołanie metody POST /##{{api_url}}/bank/bankId/authorize z podaniem nowego unikalnego api-userId = userId | Zwrócony zostaje link do SCA | W LDS tworzy się wpis o sesji dla danego usera select * from ApiSession apis, aspnetusers u where u.id=apis.userid and u.ExternalUserId = userId W kolumnie status zapisany będzie status sesji = 1 (Initaited) | Status sesji zmienia się zgodnie z cyklem życia sesji: |
5a | SCA | Przejście SCA na stronie ASPSP. Przejście przez proces SCA na stronie ASPSP | Poprawnie wykonane SCA z wyborem rachunku po stronie ASPSP. W odpowiedzi przekazywany jest identyfikator sesji sessionId oraz identyfikator zgody consentId | Weryfikacja link'u do SCA w przeglądarce Weryfikacja link'u do SCA w przeglądarce mobilnej Weryfikacja link'u do SCA w aplikacji natywnej ASPSP(opcjonalnie) | |
5b | Przekazanie oAuth code do APIHub | Wywołanie metody POST /##{{api_url}}/bank/ ##{{bankId}}/authorize z przekazaniem wartości code | Kod zostaje wymieniony na access token i refresh token i rozpoczyna się sesja AIS | W LDS wykonuje się sprawdzenie: select AccessToken, AccessTokenExpires, RefreshToken, RefreshTokenExpires, * from PsuCredentials | Weryfikacja struktury odpowiedzi wykonywana jest automatycznie w ramach CI/CD. |
6 | Sprawdzenie statusu sesji (polling) | Wywołanie metody GET ##{{api_url}}/bank/session/sessionId z przekazaniem identyfikatora sesji sessionId | Poprawnie zakończona sesja zwraca stage=Transactions, status=Finished | Status sesji zmienia się na stage=Accounts, status=Initated select * from ApiSession apis, aspnetusers u where u.id=apis.userid and u.ExternalUserId = userId | Status sesji zmienia się zgodnie z cyklem życia sesji: |
7 | Weryfikacja działania callback AIS | Wywołanie metody z przekazaniem parametru state | Pobieranie redirect uri do autoryzacji | ||
8 | Pobranie listy rachunków | Wywołanie metody GET z przekazaniem identyfikatora użytkownika userId Wywołanie metody GET z przekazaniem identyfikatora konta użytkownika accountId | Metoda zwraca listę rachunków dla wskazanego użytkownika. Na liście powinny występować wszystkie rachunki wskazane w SCA (krok 5a) | Sprawdzenie w bazie LDS SELECT * FROM bankaccount ba, usercompany uc, aspnetusers a WHERE u.id = uc.userid and uc.companyid=ba.companyid and u.externaluserid = userId zwraca liczbę rekordów odpowiadającą liczbie rachunków wskazanych w SCA (krok 5a) SELECT * FROM bankaccount where id=##{{accountId}} | Weryfikacja struktury odpowiedzi wykonywana jest automatycznie w ramach CI/CD. |
8a | Zmiana parametrów lokalnych (LDS) rachunku | Wywołanie metody POST ##{{api_url}}/bankaccount/{accountId} | Metoda robi update rachunku wskazanego pod accountId | Sprawdzenie dokonanych zmian w bazie LDS SELECT * FROM bankaccount where id=##{{accountId}} SELECT * FROM ApiBankAccount where SyncOffline = 1 | Weryfikacja struktury odpowiedzi wykonywana jest automatycznie w ramach CI/CD. |
8b | Modyfikacja relacji do rachunku | Wywołanie kolejno metod:
| Zmiana w polu relations dla określonego rachunku bankowego na jedną z poniższych wartości: | Sprawdzenie w LDS: Select * from bankaccount where id=##{{accountId}} | Weryfikacja struktury odpowiedzi wykonywana jest automatycznie w ramach CI/CD. |
9 | Pobranie listy transakcji | Wywołanie metody GET ##{{api_url}}/bankaccount/accountId/transaction?PageNumber=1&PageSize=100 z przekazaniem identyfikatora użytkownika userId i id rachunku pobranym w kroku 8 accountId | Metoda zwraca listę transakcji dla wskazanego rachunku | Sprawdzenie w bazie LDS SELECT * FROM transaction t WHERE t.bankaccountid= accountId zwraca liczbę rekordów odpowiadającą liczbie transakcji na wskazanym rachunku | Weryfikacja struktury odpowiedzi wykonywana jest automatycznie w ramach CI/CD. |
10 | Pobranie szczegółów pojedynczej transakcji | Wywołanie metody GET ##{{api_url}}/transaction/transactionId?userID=userId z przekazaniem identyfikatora użytkownika userId i id transakcji pobranych w kroku 9 transactionId | Metoda zwraca szczegóły wskazanej transakcji | Sprawdzenie w bazie LDS SELECT * FROM transaction t WHERE t.id= transactionId | Weryfikacja struktury odpowiedzi wykonywana jest automatycznie w ramach CI/CD. |
11 | Pobranie informacji o zgodzie | Wywołanie metody GET ##{{api_url}}/consent z przekazaniem identyfikatora użytkownika userId | Metoda zwraca szczegóły wskazanej zgody Oczekiwane wartości:
| Badanie prawidłowego zapisu zgody można sprawdzić w mongo w kolekcji Consent, gdzie można przeprowadzić sprawdzenie dla określonego użytkownika userId. select userid from apisession where externalUserId = ##{{userId}} W bazie LDS znajduje się informacja o zgodzie przypisanej do określonego użytkownika (PSUCredentials, BankAccountSync) select consentid from bankaccountsync where bankaccountid =##{{accountid}} | Weryfikacja struktury odpowiedzi wykonywana jest automatycznie w ramach CI/CD. |
12 | Konfiguracja konektora | Konfiguracja konektora zależna jest od wymagań banku i dla każdego banku jest inna. Metodą badania działania konektora jest przejście flow AIS i sprawdzenie między innymi zwracanego SCA url, czy otrzymanych wyników ze poszczególnych strzałów z postamana. | Działający prawidłowo i reaktywny konektor | Dane zapisywane są w LDSie w poszczególnych tabelach BankAccount, PSD2BankAccount | Weryfikacja struktury odpowiedzi wykonywana jest automatycznie w ramach CI/CD. |
13 | Usunięcie rachunku | Wywołanie metody POST ##{{api_url}}/bankaccount/accountId/delete z przekazaniem identyfikatora użytkownika userId i id rachunku pobranym w kroku 8 accountId | Rachunek zostaje usunięty z LDS. Metoda GET ##{{api_url}}/bankaccount/accountId zwraca brak rachunku (HTTP 200) i komunikat: { "data": "BankAccount with Id = accountId does not exist.", "success": false } | Sprawdzenie w bazie LDS SELECT * FROM bankaccount WHERE id = ##{{accountId}} zwraca 0 rekordów | Weryfikacja struktury odpowiedzi wykonywana jest automatycznie w ramach CI/CD. |
14 | Usunięcie zgody | Wywołanie metody DELETE ##{{api_url}}/consent/##{{consentId}} Wywołanie metody DELETE | Zgoda zostaje usunięta dla określonego consentId Zgoda zostaje usunięta dla określonego usera w określonym bankId i opcjonalnie określonego numeru IBAN dla rachunku. Jeśli parametr DeactivateAccounts jest ustawiony na true, wszystkie konta bankowe powiązane ze zogdą zostają zdeaktywowane. Domyślnie parametr jest ustawiony na true. | Sprawdzenie w bazie LDS, czy dany rachunek ma flagę isActive ustawioną na 0 SELECT * FROM bankaccount where IsActive = 0 and id = ##{{accountid}} | Weryfikacja struktury odpowiedzi wykonywana jest automatycznie w ramach CI/CD. |
15 | Prawidłowe mapowanie danych z tabel stageowych PSD2* - konta | Sprawdzenie danych wywołaniem GET | Rachunek zostaje wyświetlony dla określonego użytkownika za pośrednictwem jego accountId | Sprawdzenie w bazie LDS, czy dane zostały prawidłowo zmapowane z tabeli PSD2BankAccount do BankAccount select * from Psd2BankAccount where BankAccountId in | Weryfikacja struktury odpowiedzi wykonywana jest automatycznie w ramach CI/CD. |
15a | Prawidłowe mapowanie danych z tabel stageowych PSD2* - transakcje | Wywołanie metody Pobranie stronicowanej listy transakcji | Transakcje zostają wyświetlone z podaniem id transakcji lub wyświetlenie wszystkich transakcji dla określonego użytkownika | Sprawdzenie w bazie LDS, czy dane zostały prawidłowo zmapowane z tabeli PSD2Transaction do tabeli Transaction | Weryfikacja struktury odpowiedzi wykonywana jest automatycznie w ramach CI/CD. |
16 | Sprawdzenie statusu dostępności API- wykorzystywane przez load-balancer | Wywołanie metody HEAD ##{{api_url}}/status/check | Pokazanie statusu dostępności API przez load-balancera (pod warunkiem, że w pliku check w folderze REST dla określonego app poola wstawiona jest wartość 1) | ||
17 | Sprawdzenie wersji API | Wywołanie metody GET ##{{api_url}}/status/version | Pokazanie wersji używanego API |
Scenariusz testowy AIS2
ID | Krok | Test | Rezultat oczekiwany | Dodatkowe sprawdzenia | Komentarz |
1 | Pobranie oraz aktualizacja listy rachunków | Wywołanie kolejno następujących metod: GET ##{{api_url}}/api/bankaccount?userId=##{{userId}}&refreshActiveAccounts=false
z użyciem parametru userId (kolumna ExternalId z tabeli Company/AspNetUsers) | Metoda zwraca listę rachunków dla wskazanego użytkownika. Jeśli flaga RefreshActiveAccounts jest ustawiona na true, asynchroniczna synchronizacja danych zostanie wyzwolona dla konta z ważnym tokenem | Przed i po wykonaniu każdego strzału wskazane jest uruchomić sprawdzenie w bazie LDS kolumny SyncLastDate w tabeli BankAccount, by ustalić datę ostatniej synchronizacji konta dla użytkownika o podanym userId Sprawdzenie w bazie LDS select ba.Id as BankAccountId, where bi.[Value] = '##{{swiftCOde}}' (select u.ExternalId from AspNetUsers u, UserCompany uc where uc.CompanyId = ba.CompanyId and uc.UserId = u.Id) as ExternalUserId, from BankAccount ba | Weryfikacja struktury odpowiedzi wykonywana jest automatycznie w ramach CI/CD. |
Scenariusz testowy AIS3
ID | Krok | Test | Rezultat oczekiwany | Dodatkowe sprawdzenia | Komentarz |
1 | Pobranie i odświeżanie listy rachunków | Wywołanie kolejno następujących metod: GET ##{{api_url}}/api/bankaccount?userId=##{{userId}}&refreshActiveAccounts=false z użyciem parametru userId (kolumna ExternalId z tabeli Company/AspNetUsers) Pomiędzy każdorazowym wywołaniem metody GET następuje uruchomienie BatchJoba | Cykliczne odświeżenie rachunków, dla których flaga IsSyncOffline = 1 za pomocą batch joba. Ogólnie BatchJob odpowiedzialny jest za synchronizację danych w trybie offline. Metoda zwraca listę rachunków, dla których aktywne jest cykliczne odświeżenie. W BatchJob strzelany jest dla każdego usera request bankaccount?refreshActiveAccounts=true, który spełnia takie warunki: Dla każdego tworzy się sesja z sessionsource = 3 (Batch)
| Sprawdzenie w bazie LDS rachunków dla których ma następować cykliczne odświeżanie: select * from ApiBankAccount where SyncOffline = 1 select * from [BatchJob] select distinct [uc].userId from apibankaccount aba join bankaccount ba on aba.id = ba.id Konfiguracja batchjoba znajduje się w bazie w zapytaniu: | Weryfikacja struktury odpowiedzi wykonywana jest automatycznie w ramach CI/CD. |