Клиент-серверная архитектура - это модель, в которой одна часть системы запрашивает данные или действие, а другая часть их предоставляет. Клиент инициирует запрос, сервер его обрабатывает и возвращает результат.
На словах это звучит просто, но для QA это одна из главных базовых моделей. Как только ты начинаешь смотреть на продукт через неё, многие баги перестают казаться "странным поведением интерфейса" и начинают раскладываться на понятные точки отказа: клиент, сеть, сервер, база данных, внешняя интеграция, кэш, очередь, авторизация.
Как это работает
В типичном web или mobile продукте клиентом выступает браузер, мобильное приложение или другой сервис. Пользователь нажимает кнопку, клиент собирает данные и отправляет запрос. Сервер принимает его, проверяет права, валидирует входные данные, выполняет бизнес-логику и при необходимости обращается к базе или внешним системам.
- →Клиентом может быть браузер, мобильное приложение, другой сервис или внешний партнёр.
- →Сервером не всегда является один процесс или один монолит.
- →Между клиентом и сервером часто стоят gateway, балансировщик, кэш, очередь, база данных и внешние интеграции.
Поэтому один пользовательский клик может запускать не одну операцию, а целую цепочку действий.
Простой пример
Пользователь нажимает "Оплатить заказ". Клиент отправляет запрос с ID заказа, суммой и данными пользователя. Сервер проверяет, существует ли заказ, имеет ли пользователь право его оплачивать, валиден ли текущий статус, затем вызывает платёжного провайдера, сохраняет результат и возвращает ответ клиенту.
Пользователь видит только кнопку и итоговое сообщение. QA должен видеть всю цепочку целиком. Иначе легко ошибиться с причиной дефекта.
Что важно QA
- →Был ли вообще запрос.
- →Какой именно запрос ушёл.
- →Что сервер вернул в ответ.
- →Как клиент интерпретировал этот ответ.
- →Изменились ли данные там, где должны были измениться.
- →Есть ли зависимость от внешнего сервиса или нестабильного окружения.
Если в интерфейсе отображается неверная сумма, причина может быть разной: сервер вернул неправильное значение, база хранит не те данные, внешний сервис ответил неожиданно или клиент неправильно отрисовал корректный ответ. Снаружи симптом один, а точки отказа разные.
Какие слои чаще всего приходится проверять
- →Клиентский слой - отправился ли запрос, корректно ли собраны параметры, правильно ли показан результат.
- →Серверный слой - правильно ли отработали валидации, права доступа и бизнес-логика.
- →Слой данных - созданы, изменены или удалены ли данные так, как ожидалось.
- →Интеграционный слой - как система ведёт себя при сбоях, таймаутах и неожиданных ответах внешних сервисов.
Где это реально помогает в работе
Во-первых, при расследовании дефектов. Если QA видит только экран, он пишет "не работает". Если QA понимает архитектуру, он пишет: запрос ушёл с неверным параметром, сервер вернул 403, хотя роль должна была иметь доступ, данные в базе не обновились. Это уже другой уровень качества.
Во-вторых, при тест-дизайне. Когда ты понимаешь, какие слои участвуют в сценарии, ты строишь более сильные проверки: не только happy path через UI, но и ошибки сети, повторные запросы, частичные сбои, рассинхронизацию данных и проблемы интеграций.
В-третьих, в коммуникации с командой. Такая модель помогает говорить предметно: проблема на клиенте, на сервере, в данных или во внешнем провайдере. Это экономит время и делает triage спокойнее.
Что должен вынести QA из этой темы
- →За одним пользовательским действием часто стоит несколько технических шагов.
- →Один и тот же баг в UI может рождаться в разных слоях системы.
- →Для локализации проблемы нужно смотреть не только на экран, но и на запрос, ответ, данные и зависимости.
- →Понимание клиент-серверной архитектуры делает баг-репорты точнее и ускоряет расследование.
Что ещё почитать
- →Внутри базы: Что такое API - базовая статья про сам интерфейс взаимодействия.
- →Внутри базы: HTTP и HTTPS - чтобы лучше понимать transport-уровень запросов и ответов.
- →Внутри базы: Методы, статус-коды, заголовки - чтобы увереннее читать технические сигналы API.
Клиент-серверная архитектура - это модель, в которой одна часть системы запрашивает данные или действие, а другая часть их предоставляет. Клиент инициирует запрос, сервер его обрабатывает и возвращает результат.
На словах это звучит просто, но для QA это одна из главных базовых моделей. Как только ты начинаешь смотреть на продукт через неё, многие баги перестают казаться "странным поведением интерфейса" и начинают раскладываться на понятные точки отказа: клиент, сеть, сервер, база данных, внешняя интеграция, кэш, очередь, авторизация.
Как это работает
В типичном web или mobile продукте клиентом выступает браузер, мобильное приложение или другой сервис. Пользователь нажимает кнопку, клиент собирает данные и отправляет запрос. Сервер принимает его, проверяет права, валидирует входные данные, выполняет бизнес-логику и при необходимости обращается к базе или внешним системам.
- →Клиентом может быть браузер, мобильное приложение, другой сервис или внешний партнёр.
- →Сервером не всегда является один процесс или один монолит.
- →Между клиентом и сервером часто стоят gateway, балансировщик, кэш, очередь, база данных и внешние интеграции.
Поэтому один пользовательский клик может запускать не одну операцию, а целую цепочку действий.
Простой пример
Пользователь нажимает "Оплатить заказ". Клиент отправляет запрос с ID заказа, суммой и данными пользователя. Сервер проверяет, существует ли заказ, имеет ли пользователь право его оплачивать, валиден ли текущий статус, затем вызывает платёжного провайдера, сохраняет результат и возвращает ответ клиенту.
Пользователь видит только кнопку и итоговое сообщение. QA должен видеть всю цепочку целиком. Иначе легко ошибиться с причиной дефекта.
Что важно QA
- →Был ли вообще запрос.
- →Какой именно запрос ушёл.
- →Что сервер вернул в ответ.
- →Как клиент интерпретировал этот ответ.
- →Изменились ли данные там, где должны были измениться.
- →Есть ли зависимость от внешнего сервиса или нестабильного окружения.
Если в интерфейсе отображается неверная сумма, причина может быть разной: сервер вернул неправильное значение, база хранит не те данные, внешний сервис ответил неожиданно или клиент неправильно отрисовал корректный ответ. Снаружи симптом один, а точки отказа разные.
Какие слои чаще всего приходится проверять
- →Клиентский слой - отправился ли запрос, корректно ли собраны параметры, правильно ли показан результат.
- →Серверный слой - правильно ли отработали валидации, права доступа и бизнес-логика.
- →Слой данных - созданы, изменены или удалены ли данные так, как ожидалось.
- →Интеграционный слой - как система ведёт себя при сбоях, таймаутах и неожиданных ответах внешних сервисов.
Где это реально помогает в работе
Во-первых, при расследовании дефектов. Если QA видит только экран, он пишет "не работает". Если QA понимает архитектуру, он пишет: запрос ушёл с неверным параметром, сервер вернул 403, хотя роль должна была иметь доступ, данные в базе не обновились. Это уже другой уровень качества.
Во-вторых, при тест-дизайне. Когда ты понимаешь, какие слои участвуют в сценарии, ты строишь более сильные проверки: не только happy path через UI, но и ошибки сети, повторные запросы, частичные сбои, рассинхронизацию данных и проблемы интеграций.
В-третьих, в коммуникации с командой. Такая модель помогает говорить предметно: проблема на клиенте, на сервере, в данных или во внешнем провайдере. Это экономит время и делает triage спокойнее.
Что должен вынести QA из этой темы
- →За одним пользовательским действием часто стоит несколько технических шагов.
- →Один и тот же баг в UI может рождаться в разных слоях системы.
- →Для локализации проблемы нужно смотреть не только на экран, но и на запрос, ответ, данные и зависимости.
- →Понимание клиент-серверной архитектуры делает баг-репорты точнее и ускоряет расследование.
Что ещё почитать
- →Внутри базы: Что такое API - базовая статья про сам интерфейс взаимодействия.
- →Внутри базы: HTTP и HTTPS - чтобы лучше понимать transport-уровень запросов и ответов.
- →Внутри базы: Методы, статус-коды, заголовки - чтобы увереннее читать технические сигналы API.