{Microservises and Monolitic apps}

Explanation, Test approaches and a bit of API

Iryna Volnykh

+ 9 years in E-commerce
+ 7 years as a QA engineer

ISTQB Certified Tester

Automation/Manual QA engineer

QA lead & exScrum master at Vaimo

Teacher at Beetroot Academy

# CHAPTER 1

Moноліт

Монолітна архітектура – це класичний підхід створення програмного забезпечення, де весь софт формується як єдиний технічний комплекс. Всі його частини працюють у взаємозв'язку та розміщуються на одному або кількох серверах.

# CHAPTER 2

# CHAPTER 3

Що хорошого та поганого

Інтерфейс: Усі частини веб-сайту (головна сторінка, каталог інших сторінок, СMS, адмін-панель тощо) обслуговуються одним застосунком.

+ QA з досвідом легко створювати тестову документацію та підтримувати її

- Постійна регресія, експертність в одній області

1.

2.

База даних: Є одна база даних, до якої застосунок звертається для отримання, зберігання або оновлення даних.

+ Оскільки вона одна (декілька?) рівень компетенції легко прокачати (ERD for rel.DB)

- нема

3.

Розширення: Якщо потрібно додати новий функціонал, наприклад, модуль обробки замовлень, його додають прямо в основний код застосунку.

Масштабування: Для підвищення продуктивності потрібно розгортати додаткові екземпляри цілого застосунку, а не його окремих частин.

- Довгий час на розгортання

- Постійна регресія

- Легасі код

- Unit, integration тести часозатратні 👀

# CHAPTER 4

Microservices Design

Microservice (Мікросервіс) - маленький незалежний сервіс.
Containers (Контейнери) – упаковують сервіси та їхні залежності. Вони гарантують, що єдиниця є послідовною на всіх етапах розробки, включаючи тестування.
Service mesh (Сервісна сітка) - сприяє комунікації між мікросервісами через спеціалізований динамічний шар обміну повідомленнями.

Service discovery (Виявлення сервісу) - допомагає мікросервісам знаходити один одного в екосистемі.
API gateway (API шлюз) - відкритий шлях між мікросервісами та зовнішніми клієнтами. Разом інтеркомунікація та обмін даними формують функції повного застосунку.

```
Shift left
```
```
Contract testing
```
```
API testing and automation
```
```
End-to-end 
```
```
State transition
```
```
Security
```
```
Load
```

Шо робить?

# CHAPTER 5

Розподілений моноліт (Distributed Monolith) - це термін в архітектурі програмного забезпечення, який описує систему, яка на вигляд є архітектурою мікросервісів, але насправді тісно пов'язана. Внаслідок цього вона зберігає багато проблем монолітної системи і не отримує справжніх переваг мікросервісів.

Тісно пов'язані сервіси: Навіть якщо сервіси фізично відокремлені, вони можуть мати тісні залежності, що означає, що зміна в одному сервісі може вимагати координованих змін в інших.

Спільні бази даних: Замість того, щоб кожен сервіс мав свої власні дані, декілька сервісів можуть використовувати одну та ту ж базу даних або таблиці, що може ускладнити зміни схеми.

Синхронна комунікація: Надмірна залежність від синхронних віддалених викликів може означати, що один сервіс не може функціонувати без іншого, що призводить до вразливості і ботлнеків.

Разом розгортаються: Якщо сервіси завжди потрібно розгортати разом, оскільки вони так тісно пов'язані, вони насправді не є відокремленими.

Поширення збоїв: В добре розробленій системі мікросервісів збій одного сервісу повинен бути ізольованим і не повинен призводити до збоїв в непов'язаних сервісах. У розподіленому моноліті збій одного сервісу може призвести до каскадних збоїв в системі.

🤬

API

ВСЬОМУ ГОЛОВА

Функціональні тести

Тестування продуктивності

Тестування безпеки

Тестування логування та обробки помилок

Тестування інтеграцій

Тестування навантаження

Тестування контрактів: Особливо важливо для мікросервісів, де необхідно забезпечити, що різні сервіси мають однакове розуміння того, як має працювати API.

Для монолітів основний акцент зазвичай робиться на функціональному тестуванні, тому що весь код знаходиться в одному місці. У випадку мікросервісів увагу слід приділяти тестуванню інтеграції, контрактів та безпеки, оскільки різні сервіси розробляються незалежно один від одного і можуть оновлюватися в різний час.

ДЯКУЮ!

API testing with POSTMAN

29.08 Старт

15 практичних занять де ви вивчите нарешті

ту теорію на практиці 😺

Postman, Що таке API?, Клієнт-серверна архітектура, Статус коди, HTTP request, Особливості REST та SOAP: XML, JSON та інші типи передачі даних, Застосування Swagger та огляд OpenAPI, API через браузер, Техніки дизайну тестів для API, Postman tests, Objects, Request Examples, Headers and Cookies, Середовища та змінні, Автоматичний запуск тестів, SoapUI: тест сьюти та тест кейси, Висновки: Моделювання тестової стратегії, підходів та естімейти.