PrepBro
← Назад к вопросам

Как понять, ошибка на стороне Backend или Frontend

2.0 Middle🔥 252 комментариев
#Веб-тестирование#Клиент-серверная архитектура#Процессы и методологии разработки#Работа с дефектами#Тестирование API

Комментарии (2)

🐱
deepseek-v3.2PrepBro AI5 апр. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Определение источника ошибки: Backend vs Frontend

Понимание того, где находится источник ошибки — на стороне Backend (серверная логика, API, база данных) или Frontend (интерфейс, браузер, клиентский код) — является одним из фундаментальных навыков QA-инженера. Это позволяет эффективно классифицировать дефекты, правильно их документировать и ускорять процесс их исправления. Вот системный подход, основанный на анализе симптомов, инструментах и методах верификации.

1. Анализ симптомов и поведения приложения

Первое, с чего стоит начать — наблюдение за поведением приложения.

  • Интерфейс отображается некорректно (съехавшие элементы, неработающие анимации, ошибки стилей) — почти всегда указывает на проблемы Frontend (CSS, HTML, загрузка ресурсов).
  • Данные не загружаются или отображаются некорректно (пустые списки, неверные значения, бесконечный спиннер загрузки) — здесь источник может быть как на Frontend (ошибка в коде рендеринга), так и на Backend (ошибка в API или базе данных). Требуется дальнейшая проверка.
  • Действия пользователя не выполняются (нажатие кнопки «Отправить» ничего не делает, форма не валидируется) — часто проблема клиентского JavaScript (Frontend). Если же действие инициируется, но завершается ошибкой (например, «Сервер не отвечает»), проблема, скорее всего, в Backend или в сети.
  • Разные пользователи или сессии видят разные данные при одних и тех же условиях — это почти гарантированно проблема кеширования или логики на Backend.
  • Ошибки аутентификации и авторизации (пользователь не может войти, хотя данные верны, или получает доступ к чужим данным) — в первую очередь проверяется Backend, так как он управляет сессиями, токенами и правами доступа.

2. Использование Инструментов Разработчика в Браузере (DevTools)

Это основной и самый мощный инструмент для первичной диагностики. Откройте Панель разработчика (F12) и следуйте шагам:

  • Вкладка Console (Консоль): Ищите ошибки JavaScript (красные сообщения). Они явно указывают на Frontend. 
    // Пример ошибки Frontend в консоли
Uncaught TypeError: Cannot read properties of undefined (reading 'map')
    at renderUserList (app.js:47:15)
  • Вкладка Network (Сеть):
    1.  Воспроизведите сценарий с ошибкой (например, отправку формы).
    2.  Фильтруйте запросы по типу `XHR` или `Fetch`.
    3.  **Смотрите на статусы ответов.**
        *   **Статусы 4xx (например, 400, 401, 403, 404, 422):** Это **ошибка на стороне Backend**. Сервер получил запрос, но отказался его обработать из-за проблемы на своей стороне (неверные данные, нет прав, сущность не найдена). В ответе часто есть поясняющее тело (JSON).
        *   **Статусы 5xx (500, 502, 503, 504):** Это однозначно **ошибка сервера (Backend)**. Сервер не смог выполнить запрос из-за внутреннего сбоя (исключение в коде, проблема с базой данных, timeout).
        *   **Статус 200 (OK):** Запрос успешен. Если данные на экране все равно отображаются неверно, проблема, скорее всего, в **Frontend** — клиентский код некорректно обрабатывает полученный ответ.
    4.  **Анализируйте Payload (тело запроса) и Response (тело ответа).** Убедитесь, что Frontend отправляет корректные данные (Payload). Если Backend возвращает правильные данные (Response), а интерфейс их ломает — ошибка во **Frontend**. Если Backend возвращает неверные или пустые данные — ошибка в **Backend**.


```
# Пример анализа во вкладке Network
Запрос: POST /api/v1/orders
Статус: 422 Unprocessable Entity
Response Body (JSON): {"error": "Validation failed", "details": {"quantity": "Must be positive"}}
```

    *Вывод:* Backend валидно отработал и указал на проблему с данными. Frontend не должен был позволить отправить `quantity <= 0`. Ошибка, вероятно, в логике валидации на **Frontend**, но дефект регистрируется на Backend, так как он не обработал некорректный запрос.

3. Воспроизведение запросов с помощью API-клиентов (Postman, cURL, Insomnia)

Это ключевой метод для изоляции Backend. Если вы сомневаетесь, скопируйте проблемный HTTP-запрос из вкладки Network (правая кнопка мыши -> Copy -> Copy as cURL или Copy as Fetch) и выполните его в Postman, передав те же заголовки (особенно Authorization) и тело.

  • Если ошибка воспроизводится в Postman при идентичных данных — проблема точно на стороне Backend (или в конфигурации сети/доступа). Вы изолировали Frontend.
  • Если в Postman запрос выполняется успешно и возвращает верные данные — проблема в Frontend. Он либо отправляет иной запрос (другие параметры, заголовки), либо некорректно обрабатывает правильный ответ.
# Пример cURL-запроса, скопированного из DevTools
curl -X POST 'https://api.example.com/login' \
  -H 'Content-Type: application/json' \
  --data-raw '{"username":"test","password":"123"}'

Запустив эту команду в терминале, вы получите чистый ответ сервера, без влияния фронтенд-кода.

4. Проверка логов

  • Frontend-логи: Отладочные сообщения, отправленные в console.log, или ошибки в Sentry/Raygun, относящиеся к коду интерфейса.
  • Backend-логи: Это наиболее достоверный источник. Если у QA есть доступ к логам сервера (например, через Kibana, Grafana или терминал), поиск по ID запроса (request_id) или тексту ошибки даст точный стектрейс и причину сбоя на сервере.

5. Стратегия локализации на практике

Применяйте следующий алгоритм:

  1. Воспроизведите ошибку с открытой вкладкой Network в DevTools.
  2. Найдите сетевой запрос, связанный с операцией.
  3. Проанализируйте статус ответа и тело.
  4. Если статус 4xx/5xx: Убедитесь, что Frontend отправляет валидные данные (Payload). Если да — дефект в Backend. Если нет (например, отправляет null вместо числа) — дефект в Frontend.
  5. Если статус 200: Сравните полученный Response с ожидаемыми данными. Если данные неверны — дефект в Backend. Если данные верны, но отображаются/обрабатываются неправильно — дефект во Frontend. Проверьте Console на наличие JS-ошибок.
  6. Для уверенности: Скопируйте запрос в Postman и выполните его, чтобы окончательно исключить влияние клиентского кода.

Ключевой вывод: Ответственность за валидацию данных для удобства пользователя лежит на Frontend, но за гарантию целостности бизнес-логики и безопасности всегда отвечает Backend. Поэтому «дыра» в валидации на Frontend — это дефект Frontend, но Backend обязан иметь защиту от таких инцидентов. Грамотное описание дефекта должно включать: шаги воспроизведения, ожидаемый/фактический результат, скриншоты DevTools (вкладки Network и Console), примеры некорректных запросов/ответов и условия окружения.