Привет! 👋 Лови тест по SQL: Пройти тест на Stepik Если хочешь закрепить знания и потренироваться перед собеседованием, можешь пройти Тесты по тестированию ПО для подготовки к собеседованиям Там вопросы и практические задания по SQL, тест-дизайну, Postman, API и асинхронному взаимодействию. После каждого задания есть разбор ответа, поэтому можно сразу понять, где ошибся. По промокоду TESTS до 30 сентября (скидка 1000р) Посмотреть курс
REST (Representational State Transfer) - это архитектурный стиль для построения распределённых систем REST API - архитектурный стиль проектирования программных интерфейсов RESTful API - это термин, который использует строгое следование принципам REST
1️ Клиент-Сервер (Client-Server) Полное разделение интересов. Клиент → UI/UX 🖥️ Сервер → Данные и логика Зачем: Независимое развитие и масштабирование.
2️⃣ Отсутствие состояния (Stateless) Сервер не помнит предыдущие запросы. Каждый запрос самодостаточен. Зачем: Надежность, простота балансировки нагрузки. ⚠️ Токены передаются в каждом запросе!
3️⃣ Кэшируемость (Cacheability) Ответы должны явно маркироваться (Cache-Control, ETag). Зачем: Снижение нагрузки, ускорение работы. 💡 Для QA: Проверяй заголовки кэша в Network / Application!
4️⃣ Единообразие интерфейса (Uniform Interface) Единый стандарт взаимодействия: • Идентификация ресурсов (URI) • Манипуляция через представления (JSON) • Самодостаточные сообщения • Стандартные методы (GET, POST, PUT, DELETE) • HATEOAS (ссылки в ответе)
5️⃣ Многоуровневая система (Layered System) Архитектура из слоев (прокси, балансировщики, серверы). Клиент видит только шлюз. Зачем: Безопасность, гибкость инфраструктуры.
6️⃣ Код по требованию (Code on Demand) Сервер может передать исполняемый код (JS). ⚠️ Опционально и используется редко из-за рисков безопасности.
Какой принцип самый сложный для понимания или легко запоминающийся? Пиши в комментариях 👇
Ставь ❤️, если полезно!
А завтра планирую снова тесты провести, 🔥 для завтрашнего дня
Монолит vs Микросервисы: в чем разница для QA? 👇 Архитектура Монолит • UI, бизнес-логика и БД — единое приложение • Общая база данных • Компоненты тесно связаны Микросервисы • Каждый сервис отвечает за свою бизнес-функцию • У каждого сервиса может быть собственная БД • Взаимодействие через API и очереди сообщений Что тестировать? Монолит ✅ Функциональность приложения ✅ Бизнес-логику ✅ Интеграцию модулей ✅ Работу с общей БД Микросервисы ✅ API между сервисами ✅ Contract testing ✅ Kafka / RabbitMQ ✅ Консистентность данных ✅ Логи, tracing и мониторинг ✅ Отказоустойчивость сервисов Надёжность Монолит ❌ Ошибка может повлиять на всё приложение ❌ Единая точка отказа Микросервисы ✅ Сбой чаще локализован ✅ Остальные сервисы продолжают работать ✅ Проще масштабировать отдельные компоненты 🔄 переход из монолита в микросервисы Для QA появляются дополнительные проверки: • регрессия после выделения сервиса; • совместная работа монолита и новых сервисов; • API и контрактов между сервисами; • очередей сообщений; • логов, мониторинга; • отказоустойчивости и восстановления после сбоев. Важно В микросервисной архитектуре нет догмы, что у каждого сервиса должна быть отдельная физическая база данных. Рекомендуемый паттерн Database per Service, где каждый сервис владеет своими данными, но это может быть отдельная схема, отдельная БД или даже выделенные таблицы. Общая база тоже встречается, особенно при миграции с монолита, но это компромисс, который усиливает связанность сервисов. Главное, не количество баз, а независимость владения данными и границами сервиса. Многие крупные продукты годами успешно работают на монолитной архитектуре. Переход к микросервисам обычно имеет смысл тогда, когда появляются независимые команды, отдельные релизы, требования к масштабированию и высокая нагрузка. Из моего опыта Монолит мне довелось тестировать один раз. А вот с микросервисами работаю регулярно, и самая интересная часть для меня - интеграционное тестирование, поиск проблем во взаимодействии сервисов, анализ логов и проверка очередей.
