Online QADay 2021 #2 ДМИТРО СКРИПКА «Difference between API Response Analysis and Back End Testing» telegram: wwww.t.me/goqameetup fb: www.fb.com/goqaevent fb: www.fb.com/qaday.org linkedin: https://www.linkedin.com/company/goqa/ Сайт: www.qaday.org

1. Разница между
анализом API response
и Back End тестированием

2. 2

3. BACK-END LEGION
Core
Domain 1
Crypto&Trading
Domain
Core
Domain 2
Core
Domain 3
Core
Microservice
Core
Microservice
Core
Microservice
Core
Microservice
Core
Microservice
Core
Microservice
Core
Microservice
Core
Microservice
Core
Microservice
Core
Microservice
FRONT-END LEGION
3

4. Back-End QA Legion
Core
Domain 1
Crypto&Trading
Domain
Core
Domain 2
Core
Domain 3
BACK-END LEGION FRONT-END LEGION
Back-End QA Legion
4

5. POST http://internalApiAddress/exchange
Request:
{
"CurrencyTo": "{SomeCurrency}",
"CurrencyFrom": "{SomeCurrency}",
"CurrencyToAmount": 1.2,
"CurrencyFromAmount": 347.91,
}
Response: Status 200Ok
{
"operationId": "f28e1195-a1e6-48ce-8110-de644ad56431"
}
5

6. Exchange:
AAVE/JPY
AAVE sell
JPY buy
AAVE sell
BTC buy
BTC sell
USD buy
USD sell
JPY buy
Batch
Batch
Batch
6

7. 100 100 100
40 25
90
Order Order Order
3rd Party
110 60
50
50
7

8. Order
Exchange:
AAVE/JPY
AAVE sell
JPY buy
AAVE sell
BTC buy
BTC sell
USD buy
USD sell
JPY buy
Batch
Batch
Batch
Order
Order
3rd Party

9. UI
API
UNIT
Component
Integration
Пирамида тестирования
9

10. 10
• Клиент тесты (Browser, Android, IOS)
• Проверка End-To-End
• Мок Back-End стороны
• Негативные сценарии
• Позитивные сценарии
UI Testing:

11. API
• End-To-End тесты
• Атомарность теста
• Позитивные сценарии
• Негативные сценарии
• Проверяется частично
• Контракты
• Интеграция
11

12. • End-To-End тесты
• Проверка операции на каждом слое
взаимодействия сервисов
• Проверка контрактов
• Проверка данных в БД
• Проверка ивентов
• Не глубокие проверки на уровне микросервисов
• Зависимость от preconditions
• Время выполнения
• Не проверяются сервисы которые не участвуют user flow
Integration
12

13. • Проверки только в рамках микросервиса (Sanity)
• Проверка БД
• Проверка внутренней логики
• Валидация контрактов
• Проверка ивентов
• Отсутствует привязка к пользователю/аккаунту
• Практически отсутствуют прекондишены
• Время исполнения
• Обнаружение критических ошибок еще
до стадии разработки интеграции
• Нет привязки к сторонним сервисам
Component
13

14. 14
Пример 1
GET /notebook/{contactId}/accounts
{
"contactId": "string",
"accounts": [
{
"contactId": "string",
"accountId": "string",
"label": "string",
"currency": "string",
"requisites": {
"destinationAddress": "string",
"firstName": "string",
"lastName": "string",
}
}
]
}
PUT ​/notebook/{contactId}​/account​/{accountId}
{
"contactId": "string",
"accountId": "string",
"label": "string",
"currency": "string",
"requisites": {
"destinationAddress": "string",
"firstName": "string",
"lastName": "string",
}
}
• Поход на Internal API
• Нет валидации по owner или authToken
• Ключевые поля передаются в url
• У злоумышленника есть возможность
сменить реквизиты

15. GET /transaction/{transactionId}/validation
{
"validationRule": "string",
"amount": "decimal",
"transactionValidationId": "guid"
}
POST /transaction​
{​
"accountid": "string",​
"amount": "decimal",​
"transactionValidationId": "guid"​
}​
• Нет внутренней проверки корреляции
transactionId и transactionValidationId
• У злоумышленника есть возможность
провести транзакцию по другому протоколу
Пример 2
15

16. Provider 1 Provider 2
Provider 4
Provider 3 Provider 5
3rd Party
POST /transaction
{
"transaction": {
"accountId": "string",
"transactionType": "string",
"transactionProvider": "string",
}
"amount": "decimal",
"transactionValidationId": "guid"
}
Service
public enum Provider
{
Provider1,
Provider2,
Provider3,
Provider4,
Provider5
}
Пример 3

17. Благодарю за внимание!