Microservices
Особенности тестирования
АРХИТЕКТУРНЫЕ ПАТТЕРНЫ
Не существует формального перечня существующих
архитектурных паттернов
Но на сегодняшний день можно выделить основные (часто-
используемые) подходы:
● Многоуровневая архитектура
● Сервис-ориентированная (микросервисная) архитектура
МНОГОУРОВНЕВАЯ (СЛОИСТАЯ)
АРХИТЕКТУРА
Является одной из самых известных архитектур, в которой каждый
слой выполняет определенную функцию. В зависимости от ваших
нужд вы можете реализовать любое количество уровней.
Среди недостатков можно выделить возможные сложности с
производительностью и масштабированием – всему виной
необходимость прохождения запросов и данных по всем уровням
(опять же, в том случае, если все слои являются закрытыми).
МНОГОУРОВНЕВАЯ (СЛОИСТАЯ)
АРХИТЕКТУРА
МИКРОСЕРВИСНАЯ АРХИТЕКТУРА
Отличительные особенности микросервисов:
● Микросервисы независимы;
● Микросервисы общаются друг с другом только при
помощи сообщений (API);
● Каждый микросервис может быть развернут,
приостановлен, дублирован или перемещен независимо
от других.
МИКРОСЕРВИСНАЯ АРХИТЕКТУРА VS
МОНОЛИТНАЯ АРХИТЕКТУРА
МИКРОСЕРВИСНАЯ АРХИТЕКТУРА VS
МОНОЛИТНАЯ АРХИТЕКТУРА
Достоинства
● сверхвысокая масштабируемость
● легкость распределения задач
Недостатки
● необходимость передачи большого объема данных
● необходимость автоматизации развертывания и тестирования
Уровни тестирования
Component testing или Unit testing
Component testing или Unit testing
Component testing или Unit testing
Integration testing
Integration testing
Интеграционное тестирование
предназначено для проверки связи
между компонентами, а также
взаимодействия с различными
частями системы (операционной
системой, оборудованием либо
связи между различными
системами)
Integration testing
Подходы к интеграционному тестированию:
- Снизу вверх (Bottom Up Integration)
- Сверху вниз (Top Down Integration)
- Большой взрыв ("Big Bang" Integration)
Integration testing
Bottom Up Integration - все низкоуровневые модули,
процедуры или функции собираются воедино и затем
тестируются. После чего собирается следующий уровень
модулей для проведения интеграционного тестирования.
Данный подход считается полезным, если все или практически
все модули разрабатываемого уровня готовы. Также данный
подход помогает определить по результатам тестирования
уровень готовности приложения
Integration testing
Top Down Integration - вначале тестируются все
высокоуровневые модули, и постепенно один за другим
добавляются низкоуровневые. Все модули более низкого уровня
симулируются заглушками с аналогичной функциональностью,
затем по мере готовности они заменяются реальными
активными компонентами
Integration testing
"Big Bang" Integration - все или практически все разработанные
модули собираются вместе в виде законченной системы или ее
основной части, и затем проводится интеграционное
тестирование.
Такой подход очень хорош для сохранения времени. Однако
если тест кейсы и их результаты записаны неверно, то сам
процесс интеграции сильно осложнится, что станет преградой
для команды тестирования при достижении основной цели
интеграционного тестирования
Integration testing
Подходы к тестированию
● Record and replay
● Fake server
● Contract
Record and Replay - подход при котором обращения к
тестируемому микросервису записываются а затем повторяются,
но уже автоматически. По сути, запись происходит по принципу
proxy-сервера с последующим изменением запроса, при это
технологический стэк не имеет значения - повтор будет
происходить не зависимо от протокола.
Пример: Hoverfly
Подходы к тестированию
● Record and replay
● Fake server
● Contract
Fake server это подход, при котором любой из микросервисов
может рассматриваться как провайдер. Он генерирует fake-
запросы и затем любой другой взаимодействующий с ним сервис
может скачать этот стаб и проверить правильность работы.
Пример: Prism
Подходы к тестированию
● Record and replay
● Fake server
● Contract
Contract-подход предполагает взаимодействие двух
ролей - Provider и Consumer. Между ними есть
договоренность - pact, которая содержит набор
возможных взаимодействий. Каждое
взаимодействие состоит из ожидаемого запроса и
минимального ответа.
Пример: PACT