Почему QA-инженерам нужно понимать веб-архитектуру

Когда вы находите баг в веб-приложении, первый вопрос разработчика будет: «Это проблема frontend или backend?» Если вы не можете ответить на этот вопрос, ваш баг-репорт будет перебрасываться между командами, тратя время всех участников.

Понимание веб-архитектуры превращает вас из тестировщика, который говорит «оно сломалось», в QA-инженера, который говорит «API возвращает статус 200, но тело ответа содержит пустой массив, когда у пользователя есть товары в корзине — похоже, это проблема получения данных на backend».

Такой уровень точности вызывает уважение разработчиков и ускоряет исправление багов.

Модель клиент-сервер

Каждое веб-приложение следует одному и тому же фундаментальному паттерну: клиент отправляет запрос, а сервер отправляет ответ.

Клиентская сторона

Клиент — это почти всегда веб-браузер: Chrome, Firefox, Safari, Edge. Задача браузера:

  1. Отправлять HTTP-запросы на серверы
  2. Получать ответы (HTML, CSS, JavaScript, изображения, данные)
  3. Отрисовывать визуальный интерфейс, который видит пользователь
  4. Выполнять JavaScript для обеспечения интерактивности страницы

Современные веб-приложения выполняют значительную часть работы на стороне клиента. Приложение на React или Angular может получить минимальную HTML-страницу, а затем построить весь интерфейс с помощью JavaScript. Это важно для тестирования, потому что клиентские баги ведут себя иначе, чем серверные.

Серверная сторона

Сервер принимает запросы, обрабатывает их и возвращает ответы. Типичный веб-сервер:

  1. Получает HTTP-запрос
  2. Маршрутизирует его к соответствующему обработчику
  3. Выполняет бизнес-логику (валидация ввода, обработка данных, применение правил)
  4. Выполняет запросы к базе данных при необходимости
  5. Формирует и отправляет HTTP-ответ

Серверы работают на фреймворках вроде Express (Node.js), Django (Python), Spring (Java) или Rails (Ruby). У каждого фреймворка свои паттерны и характерные категории багов.

Слой базы данных

За сервером располагается одна или несколько баз данных, хранящих постоянные данные — учётные записи пользователей, каталоги товаров, записи транзакций. Слой базы данных привносит свой класс багов:

  • Данные не сохраняются корректно
  • Запросы возвращают устаревшие данные
  • Race conditions при одновременном изменении одной записи несколькими пользователями
  • Несогласованность данных между таблицами

Как работает HTTP

HTTP (HyperText Transfer Protocol) — это язык, на котором общаются клиенты и серверы. Каждое взаимодействие, которое вы видите в веб-браузере — загрузка страницы, отправка формы, получение данных — это HTTP-диалог.

Цикл запрос-ответ 

Клиент (Браузер)                    Сервер
     |                                |
     |--- HTTP Request (GET /home) -->|
     |                                | Обработка запроса
     |                                | Запрос к БД
     |<-- HTTP Response (200 OK) -----|
     |    HTML + CSS + JS             |
     |                                |
     | Браузер рендерит страницу      |

HTTP-методы, важные для тестирования

МетодНазначениеФокус QA
GETПолучение данныхНе должен изменять данные. Проверять, что повторные GET возвращают согласованные результаты
POSTСоздание новых ресурсовТестировать валидацию, повторную отправку, обязательные поля
PUTОбновление всего ресурсаПроверять, что все поля обновляются, а не только некоторые
PATCHЧастичное обновлениеПроверять, что неизменённые поля остаются нетронутыми
DELETEУдаление ресурсаТестировать авторизацию, soft delete vs. hard delete, каскадные эффекты

Коды статусов HTTP

Коды статусов сообщают, что произошло на сервере. Как QA-инженеру, вам нужно знать эти категории:

  • 2xx (Успех): 200 OK, 201 Created, 204 No Content
  • 3xx (Перенаправление): 301 Permanent, 302 Temporary, 304 Not Modified
  • 4xx (Ошибка клиента): 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 422 Unprocessable Entity
  • 5xx (Ошибка сервера): 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable

Когда пользователь видит пустую страницу, код статуса подскажет, упал ли сервер (5xx), не существует ли ресурс (404) или пользователь не авторизован (401/403).

Паттерны веб-архитектуры

Монолитная архитектура

Всё работает в одном приложении. Frontend, backend-логика и доступ к базе данных деплоятся вместе. Баги в одной области могут повлиять на всю систему.

Влияние на тестирование: Проще настраивать тестовые окружения, но сложнее изолировать сбои. Проблема с базой данных может проявиться как ошибка в UI.

Микросервисная архитектура

Приложение разделено на маленькие независимые сервисы. Сервис пользователей отвечает за аутентификацию, сервис продуктов управляет каталогом, сервис заказов обрабатывает покупки.

Влияние на тестирование: Каждый сервис может упасть независимо. Нужно тестировать, что происходит, когда один сервис недоступен, а другие работают. Интеграционное тестирование становится критически важным.

Serverless-архитектура

Функции выполняются по запросу в облаке (AWS Lambda, Google Cloud Functions). Нет постоянных серверов для управления.

Влияние на тестирование: Cold start может вызывать всплески задержки. Функции имеют ограничения по времени выполнения. Тестирование должно учитывать параллельное выполнение и отсутствие состояния.

Полный путь запроса

Когда пользователь вводит URL и нажимает Enter, вот что происходит на самом деле:

  1. DNS-разрешение: Браузер ищет IP-адрес для доменного имени
  2. TCP-соединение: Браузер устанавливает соединение с сервером
  3. TLS Handshake: При HTTPS согласовывается шифрование
  4. HTTP-запрос: Браузер отправляет запрос
  5. Load Balancer: Распределяет запрос на доступный сервер
  6. Веб-сервер: Принимает и маршрутизирует запрос
  7. Логика приложения: Обрабатывает запрос, выполняет запросы к БД
  8. Ответ: Сервер отправляет HTML, JSON или другие данные
  9. Рендеринг в браузере: Парсит HTML, загружает CSS, выполняет JavaScript
  10. API-вызовы: JavaScript делает дополнительные запросы за динамическими данными

Каждый шаг — потенциальная точка отказа и, следовательно, возможность для тестирования.

Практическое исследование архитектуры для QA

Теперь, когда вы понимаете теорию, давайте применим её к реальным сценариям тестирования.

Чтение сетевого трафика

Откройте Chrome DevTools (F12), перейдите на вкладку Network и загрузите любую веб-страницу. Вы увидите каждый запрос, который делает браузер:

  1. Запрос документа: Начальная HTML-страница
  2. Статические ресурсы: CSS-файлы, JavaScript-бандлы, изображения, шрифты
  3. API-вызовы: XHR или Fetch запросы за динамическими данными
  4. Сторонние запросы: Аналитика, реклама, ресурсы CDN

Для каждого запроса обратите внимание на:

  • Код статуса: Был ли запрос успешным?
  • Время: Сколько времени занял запрос?
  • Размер: Сколько данных было передано?
  • Заголовки: Какие метаданные были отправлены и получены?

Определение архитектуры из браузера

Вы можете многое узнать об архитектуре приложения, просто наблюдая:

Single Page Application (SPA): При начальной загрузке скачивается JavaScript-бандл. Последующая навигация не вызывает полную перезагрузку страницы — только API-вызовы для получения данных. Ищите фреймворки React, Angular или Vue в исходном коде.

Server-Side Rendered (SSR): Каждая навигация по страницам вызывает полный HTML-ответ. HTML содержит всё содержимое страницы. Для начального рендеринга требуется меньше JavaScript.

Гибридный подход: Начальная загрузка рендерится на сервере для SEO и производительности, затем клиентский фреймворк берёт управление для последующих взаимодействий (паттерны Next.js, Nuxt.js).

Упражнение: Составить карту архитектуры приложения

Выберите веб-приложение, которым вы регулярно пользуетесь (интернет-магазин, инструмент управления проектами, социальная сеть). Используя DevTools браузера:

  1. Загрузите главную страницу и подсчитайте, сколько HTTP-запросов выполняется
  2. Перейдите на другую страницу — происходит ли полная перезагрузка или API-вызов?
  3. Отправьте форму — какой HTTP-метод и endpoint используются?
  4. Проверьте заголовки ответа на наличие Server, X-Powered-By или Via, которые раскрывают технологический стек

Задокументируйте свои находки в таком формате:

КомпонентНаходка
Тип архитектурыSPA / SSR / Гибрид
Frontend-фреймворкReact / Angular / Vue / Не определён
Серверная технология(из заголовков)
CDN(из заголовков или доменов запросов)
Количество API-вызовов при загрузке(число)
Пример находок для типичного интернет-магазина
КомпонентНаходка
Тип архитектурыГибрид (SSR + client hydration)
Frontend-фреймворкReact (Next.js)
Серверная технологияNode.js (из заголовка X-Powered-By)
CDNCloudflare (из заголовка cf-ray)
Количество API-вызовов при загрузке12 (данные продуктов, сессия пользователя, корзина, рекомендации)

Типичные баги, связанные с архитектурой

Понимание архитектуры помогает предсказать, где появятся баги:

Слой архитектурыТипичный багКак обнаружить
DNSНеправильный домен в ссылках после миграцииПроверить все ссылки, проверить редиректы
CDN/CacheУстаревший контент после деплояHard refresh, проверить заголовки кэша
Load BalancerПроблемы с привязкой сессийАвторизоваться, выполнить запросы, проверить сохранение сессии
ПриложениеRace conditions при параллельных запросахОткрыть несколько вкладок, отправить одновременно
База данныхНесогласованность данных после неудачных транзакцийПрервать операции в середине процесса

Создание чеклиста архитектуры

Для каждого нового проекта создайте карту архитектуры перед началом тестирования:

  1. Какая frontend-технология используется? Это определяет, какие специфичные для браузера баги искать
  2. Как frontend взаимодействует с backend? REST API, GraphQL, WebSocket?
  3. Какая база данных используется? SQL-базы имеют другие режимы отказа, чем NoSQL
  4. Есть ли слой кэширования? Redis, Memcached или CDN-кэширование влияют на актуальность данных
  5. Какие сторонние сервисы интегрированы? Платёжные системы, email-сервисы, аналитика — каждый является зависимостью, которая может отказать

Ключевые выводы

  • Веб-приложения следуют модели клиент-сервер: браузер отправляет запросы, сервер обрабатывает и отвечает
  • HTTP-методы (GET, POST, PUT, DELETE) и коды статусов (2xx, 4xx, 5xx) — словарь веб-коммуникации
  • Паттерны архитектуры (монолит, микросервисы, serverless) создают разные вызовы для тестирования
  • Понимание полного пути запроса помогает точно определить, где возникают сбои
  • DevTools браузера — ваш основной инструмент для исследования веб-архитектуры
  • Знание архитектуры превращает расплывчатые баг-репорты в точные и действенные