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

Как проверить исход статус-кода 500

1.3 Junior🔥 131 комментариев
#Тестирование API

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

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

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

Как проверить и проанализировать статус-код 500 (Internal Server Error)

Статус-код 500 Internal Server Error — это общий код ответа HTTP сервера, указывающий на то, что на стороне сервера произошла непредвиденная ошибка, которая помешала выполнить запрос. Как QA Engineer, моя задача не просто "зафиксировать факт" ошибки, а исследовать её причины, воспроизвести и предоставить разработчикам максимально полезную информацию для исправления.

Проверка и анализ этой ошибки — многоуровневый процесс.

1. Воспроизведение и Первичный Анализ

Сначала необходимо подтвердить, что ошибка стабильно воспроизводится, и собрать базовый контекст.

  • Воспроизведение сценария: Выполнить действия, приведшие к ошибке, несколько раз, меняя условия (разные пользователи, данные, время суток).
  • **Анализ HTTP

Ответа:** Использовать инструменты разработчика в браузере (F12, вкладка Network) или специализированные тулзы (Postman, cURL). Важно смотреть не только на статус-код. http HTTP/1.1 500 Internal Server Error Content-Type: text/html; charset=utf-8 Date: Mon, NA, 00:00:00 GMT Server: nginx/1.18.0 Content-Length: 1234

  • Изучение тела ответа: Часто сервер возвращает HTML-страницу с ошибкой или JSON-объект с деталями. Это — первый ключ к разгадке.
  • Проверка заголовков: Заголовки Server, X-Powered-By могут указать на технологический стек (Apache, Nginx, Node.js, PHP).

2. Глубокий Анализ на Стороне Сервера и Приложения

Здесь подключаются более мощные инструменты. Доступ к ним часто требует согласования с DevOps или разработчиками.

  • Логи сервера (Server Logs): Это основной источник истины. Нужно искать записи, соответствующие времени запроса.
    *   **Логи доступа (Access Logs):** Фиксируют сам факт запроса и ответа.
    *   **Логи ошибок (Error Logs):** Содержат **стектрейс (stack trace)**, сообщения об исключениях, фатальных ошибках. Например, в логах Nginx или Apache.
  • Логи приложения (Application Logs): Если приложение ведет логи самостоятельно (в файлы или централизованные системы типа ELK Stack или Graylog), там будет максимально подробная информация: какие методы были вызваны, с какими параметрами, где именно упало.
  • Мониторинг и APM-инструменты: Системы вроде Datadog, New Relic, Application Insights часто автоматически детектируют 500 ошибки, показывают связанные с ними транзакции, медленные запросы и проблемные участки кода.

3. Практические Шаги и Инструменты для QA

Вот конкретный чек-лист действий для тестировщика:

  1. Сбор информации для баг+репорта:
    *   **URL и метод запроса** (GET, POST, etc.).
    *   **Полные заголовки запроса** (особенно `Authorization`, `Content-Type`).
    *   **Тело запроса** (если есть).
    *   **Точные шаги воспроизведения**.
    *   **Окружение** (браузер, ОС, версия приложения, среда: stage/prod).
    *   **Скриншоты/видео** ошибки и вкладки Network.
    *   **Текст ошибки из тела ответа**.
  1. Использование cURL для изоляции проблемы: Позволяет исключить влияние браузера и отправить точно контролируемый запрос. 
    curl -v -X POST "https://api.example.com/v1/users" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_TOKEN" \
-d '{"name": "Test", "email": "test@example.com"}'

    Флаг `-v` покажет и заголовки, и ответ.

  1. Анализ через Postman/Insomnia: Можно легко манипулировать параметрами, создавать коллекции для воспроизведения, использовать тесты для автоматической проверки статус-кодов.

  2. Проверка зависимостей: 500 ошибка может быть вызвана:

    *   **Сбоем базы данных** (коннекшн пул исчерпан, неверный запрос).
    *   **Отказом внешнего API** или микросервиса.
    *   **Проблемами с файловой системой** (нет прав, диск переполнен).
    *   **Ошибками в конфигурации** (.env файлы, настройки веб-сервера).

4. Что Включить в Идеальный Баг-*Репорт

Заголовок: [API] POST /v1/orders возвращает 500 при отправке некорректного payload Шаги:

  1. Отправьте POST запрос на /v1/orders с телом: {"items": []}.
  2. ... Фактический результат: Статус 500, тело: {"error": "NullPointerException at OrderService.process()"} Ожидаемый результат: Статус 400 с валидационной ошибкой или корректная обработка пустого списка. Дополнительно:
  • Время запроса: 2023-NA-00 14:05:UTC.
  • cURL для воспроизведения: (прилагается).
  • Важно: Указать, найдена ли ошибка в логах (если есть доступ). Например: "В error.log приложения найдено исключение: ...".

Заключение

Проверка 500 ошибки — это не просто констатация "сервер упал". Это расследование, требующее понимания клиент—серверного взаимодействия, умения работать с инструментами анализа трафика и логами. Цель QA — превратить безликий код 500 в конкретный, воспроизводимый сценарий с техническими деталями, который разработчик сможет быстро понять и исправить. Наиболее ценная информация обычно кроется в стектрейсах приложения и логах ошибок сервера.