Всем привет, я Сергей Герасимов, а эта статья — моя шпаргалка для тестирования. Особенно полезна она будет начинающим тестировщикам, но я и сам буду использовать, чтобы не держать в голове значения всех кодов и причины их возникновения.

Да, у нас есть стандартные коды 400, 404, 500 и прочие популярные ошибки, но есть и куча других. Не знаю как вы, а мне периодически приходится выяснять, что значит та или иная http-ошибка и как их воспроизводить. А когда приходят задачи из категории «проверить логирование ошибок запроса ....», то иду гуглить, как их провоцировать.

Пусть эта статья закроет часть вопросов. Коллеги, добавляйте от себя советы в комментарии, чем подробнее – тем лучше.

Определения

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

«Код состояния HTTP (англ. HTTP status code) — часть первой строки ответа сервера при запросах по протоколу HTTP.

Представляет собой целое трёхразрядное десятичное число. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа»

От нейросети Grok:

«Код состояния HTTP — это трёхзначное число, которое сервер отправляет в ответ на запрос клиента, указывая результат обработки. Он делится на группы: 1xx (информация), 2xx (успех), 3xx (перенаправление), 4xx (ошибка клиента), 5xx (ошибка сервера).»

От нейросети Сбера GigaChat:

«Код состояния HTTP — это трёхзначный числовой идентификатор, сообщающий клиенту итог обработки его запроса сервером. Эти коды подразделяются на категории, каждая из которых отражает определённый класс результатов: успех (2xx), перенаправление (3xx), ошибку клиента (4xx) или сервера (5xx).»

Поехали дальше.

Какие коды мы будем разбирать сегодня

В этой статье — несколько 400-х и 500-х кодов ошибок, которые я встречал чаще всего в карьере и в жизни. Тут нет полного перечня проверки всех‑всех‑всех запросов, так как большую их часть вы никогда не встретите: я опираюсь только на свой опыт и опыт знакомых‑тестеров. Еще раз — буду рад вашим комментариям с дополнениями :)

Стартуем

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

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

Что будем использовать

Для тестирования будем использовать Postman.

Примеры апих для тестирования будут с нашего сайта: petrovich.ru, и местами будем сходить с него в сторону нейросети. Отмечу, что curl-ы нейросеть приводит для примера, за их работоспособность автор ответственности не несет. Нам важны примеры того, КАК можно спровоцировать ошибку.

Буду показывать на самых распространенных методах — GET и POST/PUT/DELETE запросах. Это для наглядности, т.к. в GET‑запросах нет тела, а в POST — запросах тело есть. Можно было бы всё показать и на одном POST-методе (или PUT, или другие), но нам важно разнообразие.

400-е коды 

По задумке, это ошибки от действий пользователя. На деле не всегда виноват именно клиент, проблема может быть в логике сервиса, неправильных условиях, ошибке в коде и тд. Поэтому в некоторых случаях из статьи причины ошибок будут одинаковыми либо близкими по смыслу. Для выявления этого мы и делаем проверки.

400 ошибка

Что это: 

«Bad Request» – дело в неправильном запросе со стороны пользователя.

Когда возникает:

  • Неверный синтаксис запроса (например, некорректный JSON или XML).

  • Отсутствие обязательных параметров или заголовков.

  • Неправильные или некорректные данные в параметрах (например, строка вместо числа).

  • Превышение лимита длины URL или тела запроса.

  • Некорректный метод HTTP (например, использование GET вместо POST).

  • Также может возникать, когда есть неверный нейминг внутри кода. Например, обращение идет в «pictures», а на сервере у нас папка называется «images»

Пример, как воспроизвести:

GET-запрос к наличию товар в корзине:

Как в этом методе можно спровоцировать ошибку:

  1. Неверный формат обязательного параметра в строке запроса. Например, вместо кода города spb ввести spb 1 – это выдаст ошибку:

  1. Или вовсе удалить обязательный параметр:

  1. Или неверный синтаксис в URL-е, здесь добавил символ «%» в URL:

POST — запрос к добавлению товара в корзину:

Здесь всё то же самое, как с GET, но нужно добавить ошибки, связанные с телом запроса:

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

  2. Неверный формат body, здесь я поменял JSON на HTML:

  3. Синтаксическая ошибка в body, здесь убрал закрывающую скобку:

401 ошибка

Что это: 

«Unauthorized» — для запроса требуется аутентификация. У пользователя отсутствуют или указаны неверные учетные данные.

Когда возникает:

  • Отсутствие заголовка аутентификации (например, Authorization) в запросе.

  • Неверные учетные данные (логин/пароль, токен, API-ключ).

  • Истекший или недействительный токен (например, JWT).

  • Запрос к защищенному ресурсу без предварительной авторизации.

Пример, как воспроизвести:

GET-запрос на получение списка строительных объектов у пользователя. Небольшое пояснение: у нас на сайте для любого пользователя доступна функция создания строительных объектов, куда клиент может выборочно сортировать свои заказы. Объекты закреплены за учеткой пользователя и доступны только ему.

  1. Тут всё просто. Если клиент неавторизован, то и список объектов недоступен:

Далее мы двинемся в сторону от Петровича, т. к. есть NDA — моменты. Возьмем примеры, которые мне предоставила нейросеть:

  1. GET-запрос: Попытка получить защищённый ресурс без токена или с недействительным токеном:


curl -X GET https://api.example.com/protected-resource \

-H "Authorization: Bearer invalid-token"

 

Причина 401: Сервер проверяет заголовок Authorization, но токен недействителен или отсутствует.

  1. PUT-запрос: Попытка обновить ресурс с истёкшим токеном:

    curl -X PUT https://api.example.com/protected-resource/123 \

-H "Authorization: Bearer expired-token" \
-H "Content-Type: application/json" \
-d '{"data": "updated"}'


Причина 401: Сервер отклоняет запрос, так как токен истёк или невалиден.
 

  1. DELETE-запрос: Удаление ресурса без предоставления API-ключа:

    curl -X DELETE https://api.example.com/protected-resource/123
    Причина 401: Эндпоинт требует API-ключ или токен в заголовке, но они не переданы.

 

403 ошибка

Что это: 

«Forbidden» — отсутствие прав к запрашиваемому ресурсу. Ошибка указывает на недостаточность разрешений или какие-то дополнительные ограничения для данного типа пользователя.

Когда возникает:

  • У пользователя/токена нет прав для выполнения действия (например, только админ может удалить запись).

  • Доступ к ресурсу ограничен для данного пользователя, IP или роли.

  • Ограничения на уровне сервера (например, доступ к файлу запрещен из-за настроек).

  • Неверная настройка политик доступа.

Пример, как воспроизвести:

GET — запрос на печать заказа в формате .xls:

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

404 ошибка

Что это:

Наверное, это самая популярная в интернете ошибка «Not Found» – запрашиваемый ресурс не найден на сервере. Это ошибка указывает на то, что клиент обратился к несуществующему адресу или ресурсу, хотя сам сервер доступен и работает корректно.

Когда возникает:

  • Неверный URL (например, опечатка в адресе или пути).

  • Ресурс удален или перемещен, но клиент запрашивает старый адрес.

  • Неправильная конфигурация маршрутов на сервере (роутинг не настроен).

  • Запрос к несуществующему эндпоинту API или файлу.

  • Ограничение доступа, маскируемое как 404 (иногда эта ошибка вылезает вместо 403, для безопасности).

Пример, как воспроизвести:

GET — запрос на печать заказа в формате .xls:

  1. Делаем запрос на несуществующий GUID:

2. POST-запрос на добавление товара:

3. Меняем в URL с /products на /product:

405 ошибка

Что это:

«Method Not Allowed» — метод запроса не поддерживается у запрашиваемого ресурса. Т.е. ресурс существует, но метод запроса не разрешен.

Когда возникает:

  • Использование неподдерживаемого HTTP-метода для эндпоинта (например, POST вместо GET).

  • Ограничения, заданные сервером или API (например, только GET и POST разрешены).

  • Ошибка в конфигурации маршрутов или логики API.

  • Смена метода со стороны команды разработки.

  • Попытка выполнить действие, не соответствующее спецификации ресурса (например, DELETE на ресурс, который нельзя удалять).

Пример, как воспроизвести:

Самый простой способ проверить — просто поменять метод.

POST-запрос на добавление товара:

Меняем метод запроса с POST на GET:

408 ошибка

Что это: 

«Request Timeout» — клиент не отправил полный запрос в течение установленного времени ожидания (timeout). Сервер прекратил ожидание данных от клиента и закрыл соединение.

Когда возникает:

  • Клиент слишком долго не отправляет запрос (например, медленное соединение или зависание).

  • Клиент начал отправку данных, но не завершил её в отведённое время.

  • Проблемы с сетью (высокая задержка, потеря пакетов).

  • Клиентское приложение «зависло» или не успело сформировать запрос.

  • Сервер настроен на строгий таймаут (например, ожидает данные не дольше 30 секунд).

Пример, как воспроизвести:

Здесь не будет примеров, просто знайте, что обычно это инфраструктурные вещи (по крайней мере на моей практике). Как правило, чтобы проверить эту ошибку, лезут куда-то под капот и либо отключают сервис, либо делают искусственную задержку. После чего инициируют нужный запрос и смотрят, что будет.

Если хотите понять, как это работает, можете скачать любое банкинг приложение или приложение любой криптобиржи и там в настройках поставить logout при отсутствии активности за определенный период времени, например, за 15 минут. После прохождения этого периода времени попытайтесь перейти в личный кабинет и, возможно, вы увидите эту ошибку :)

422 ошибка

Что это:

«Unprocessable Entity» – возникает, когда сервер понимает запрос, но не может его обработать из-за семантических ошибок в данных, например, неверного формата или недопустимых значений. И даже допустимые значения с правильным форматом могут вызвать эту ошибку. Т.к. этот код разработчиком может использоваться по-разному, например в качестве заглушек на какие-то действия клиента или для собственных тестов. По ошибке 422 нужно обращаться к разработчикам и выяснять, что может ее провоцировать.

Когда возникает:

  • Запрос с некорректными параметрами в URL, которые не соответствуют ожидаемому формату.

  • Отправка данных в теле запроса, которые не проходят валидацию.

  • Обновление ресурса с неполными данными.

  • Некорректные идентификаторы в URL.

Пример, как воспроизвести:

DELETE /api/orders?order_id=non-existent

Параметр order_id имеет значение, которое не соответствует существующему ресурсу или ожидаемому формату (например, ожидается UUID, а передана строка). Сервер вернёт 422.

429 ошибка

Что это:

«Too Many Requests» — превышение лимита на количество запросов в определенный период времени.

Когда возникает:

  • Клиент отправил слишком много запросов в единицу времени (например, более 100 запросов в минуту).

  • Превышение лимита API (например, ограничение по количеству вызовов для конкретного пользователя или токена).

  • Дело в автоматизированных скриптах или ботах, генерирующих высокий трафик.

  • Идёт неправильная реализация клиентского приложения, вызывающая избыточные запросы.

Пример, как воспроизвести:

Здесь также не будет примеров, которые можно показать.

Наверное эти тесты ближе к тестировщикам-нагрузочникам или к тестировщикам-безопасникам, потому что речь об инициации большого количества повторяющихся (или нет) запросов в единицу времени.

Например, у вас на сайте может стоять ограничение на количество заказов от одного пользователя в минуту.

И вы по-разному можете тестировать эти ограничения.

Подскажу, что в Postman есть раннеры, которые помогут с этой задачей:

  1. Создаёте коллекцию или находите существующую коллекцию

  2. Нажимаете на троеточие

  1. Выбираете Run

  1. Открывается раннер, который вы сможете настроить под свою задачу (запросы, количество повторов, единицы времени) и пускаете его:

500-е ошибки 

Этоошибки, которые происходят на стороне сервера. Клиент практически никак не может влиять на них самостоятельно. Специально воспроизвести такие ошибки достаточно сложно, тут важно знать нюансы тестируемой системы. Где и как можно воспроизвести ту или иную ошибку — нужно искать, опираясь на документацию и советы разработчиков. Но давайте посмотрим, какие у нас есть варианты.

Еще раз напоминаю, что все коды ошибок — это скорее принятые правила, на деле будет работать так, как заложит разработчик при проектировании API.

500 ошибка

Что это:

«Internal Server Error» — сервер столкнулся с неожиданной проблемой, которая помешала ему обработать запрос клиента. Это одна из самых распространенных ошибок, но ее диагностика трудна, так как не предоставляется информация о причинах сбоя. Лучше сразу открывать логи и пытаться найти причину там.

Когда возникает:

Когда угодно, это не классифицированная ошибка. Например:

  • Ошибки в коде приложения: синтаксические ошибки, неправильная логика и т.п.

  • Проблемы с конфигурацией сервера.

  • Нехватка ресурсов.

  • Проблемы с базой данных.

  • Ошибки зависимостей: сбой внешних сервисов, библиотек или API, от которых зависит сервер.

  • Проблемы с правами доступа, когда сервер не может получить доступ к нужному ресурсу (по идее должна появиться ошибка 403, но не всегда разработчики могут это предусмотреть, либо есть какие-то ситуации-исключения).

  • Обновления или изменения: недавно внесённые изменения могут вызвать конфликт.

Пример, как воспроизвести:

С этой ошибкой всё непросто. Провоцирование ошибки можно попробовать осуществить совсем неожиданными для системы действиями, например, организовать недоступность nginx. Как правило, недоступность nginx выдает 500 ошибку.

502 ошибка

Что это:

«Bad Gateway» – это серверная ошибка, связанная с проблемами взаимодействия между серверами.

Когда возникает:

1. Бэкенд-сервер недоступен:

  • Сервер, обрабатывающий запрос, выключен, перезагружается или устал упал.

  • Сетевые проблемы между прокси и бэкендом.

2. Перегрузка бэкенда:

  • Сервер перегружен из-за большого количества запросов, нехватки памяти или CPU.

3. Тайм-аут соединения:

  • Бэкенд слишком долго отвечает на запрос, и прокси-сервер прерывает соединение из-за тайм-аута.

  • Бэкенд возвращает ответ в неправильном формате, который прокси-сервер не может обработать.

4. Ошибки конфигурации.

5. Программные сбои:

  • Ошибки в коде на бэкенде.

  • Проблемы с БД, к которой обращается бэкенд.

Пример, как воспроизвести:

Здесь также нет универсальных методов проверок. Самые базовые способы специально вызвать ошибки:

  1. Поменять записи в БД на некорректные, чтобы то, что должно отдаваться, приходило в неправильном виде.

  2. Сымитировать задержку ответа путём отключения каких-то серверов или настроек. Также можно создать «узкое горлышко», одновременно увеличив время на обработку запросов и количество этих запросов.

503 ошибка

Что это:

«Service Unavailable» – сервер временно не может обработать запрос из-за технического обслуживания, перегрузки или других проблем. Обычно это временная ошибка, которая показывает, что сервер не готов обработать запросы в данный момент.

Когда возникает:

1. Перегрузка сервера:

  • Слишком большое количество запросов приводит к нехватке ресурсов.

2. Техническое обслуживание:

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

3. Сбой приложения или сервиса:

  • Веб-приложение или связанные сервисы не работают.

4. Ограничения ресурсов:

  • Хостинг-провайдер или конфигурация сервера ограничивают использование ресурсов, вызывая отказ в обработке запросов.

5. Ошибки конфигурации:

  • Неправильные настройки веб-сервера или отсутствие доступных рабочих процессов для обработки запросов.

Пример, как воспроизвести:

Первое, что нужно сказать: пытаться воспроизвести эту ошибку нужно только с согласия товарищей по проекту.

Второе: готовясь к статье, я спрашивал у нейросети, как можно воспроизвести эту ошибку. Первый ее совет: отправлять множество запросов одновременно для перегрузки сервера – так делать не надо. Просто не надо. Можно, конечно, побаловаться с локальным сервером, но я так не делал, поэтому не могу посоветовать. Если вы обычный тестировщик-ненагрузочник и вам принципиально важно спровоцировать ошибку 503, вам достаточно будет следующих советов:

  1. Используйте API с лимитом запросов (например, публичные API) и превышайте его, сработает, если на случай превышения запросов по документации прописана 503 ошибка.

  2. Уточните у админов или других коллег, кто отвечает за обновления и пусконаладку серверов на вашем проекте, когда будут работы на сервере. Пытайтесь тестировать именно в этот промежуток времени. Идеально, если это будет выделенный стенд.

504 ошибка

Что это:

«Gateway Timeout» — сервер не получил своевременный ответ от другого сервера (обычно бэкенда), к которому обращался для обработки запроса.

Когда возникает:

1. Долгое выполнение запроса на бэкенде:

  • Бэкенд-сервер обрабатывает запрос слишком долго из-за сложных вычислений, долгих запросов к базе данных или других операций.

2. Перегрузка бэкенда:

  • Высокая нагрузка на сервер замедляет обработку запросов.

3. Проблемы с сетью:

  • Сетевые сбои, задержки или блокировки между прокси и бэкендом.

4. Бэкенд-сервер не отвечает:

  •  Сервер может быть временно недоступен из-за перезагрузки или сбоя.

5. Неправильные настройки тайм-аутов:

  • Прокси-сервер имеет слишком короткий тайм-аут, который не соответствует времени, необходимому бэкенду для ответа.

6. Ошибки в коде приложения:

  • Плохо оптимизированный код или бесконечные циклы на бэкенде приводят к задержкам.

Пример, как воспроизвести:

Здесь будет один из советов для 502 ошибки: сымитировать задержку ответа путем отключения серверов или настроек. Также можно создать «узкое горлышко», увеличив время на обработку запросов и количество этих запросов одновременно.

В зависимости от настроек, где‑то на ответе будет выводится 502, а где‑то 504 ошибка. Думаю, что если по вашей задаче нужно увидеть 504 ошибку — значит, настроено именно на нее и совет поможет.

507 ошибка

Что это:

«Insufficient Storage» — проблемы с хранилищем, чаще всего просто не хватает места для выполнения текущего запроса. Также ошибку могут провоцировать какие-то ограничения со стороны хранилища. Ошибка обычно временная.

Когда возникает:

1. Недостаток дискового пространства:

  • Физический диск сервера заполнен, нет места для записи новых данных (например, логов, загруженных файлов или временных данных).

2. Ограничения квоты:

  • Клиент, приложение или сервер превысили выделенную квоту хранения, установленную администратором или хостинг-провайдером.

3. Проблемы с файловой системой:

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

4. Перегрузка сервера:

  • В редких случаях другие ресурсы (например, дескрипторы файлов или память) могут ограничивать способность сервера выделять хранилище.

5. Ошибки конфигурации:

  • Неправильные настройки сервера или приложения, которые неверно управляют дисковым пространством.

Пример, как воспроизвести:

  1. Работа с местом в хранилище: уменьшить квоту хранения данных для пользователя.

  2. Поменять расширение файла, куда записывается информация (только потом вернуть как было) — НО нужно обязательно сначала узнать у коллег и руководителя, можно ли так сделать.

  3. Перенаправлять полученные данные в ложную несуществующую таблицу.

Заключение

Надеюсь, эта шпаргалка поможет в ваших проверках. Еще раз прошу: пишите в комментариях советы, как можно воспроизвести ту или иную ошибку, какие хитрые способы ее получения вы использовали при проверках. Я не идеален, не исключаю, что вы знаете лучше и больше. Только не нарушайте NDA, пожалуйста :)

P.S. Чур моки не предлагать! Я опирался на полноценное воспроизведение ошибки, а не на перетасовку данных.

P.S.S. И последняя напоминалка: все коды ошибок будут работать так, как заложит разработчик, статья написана с опорой на общепринятые правила.

Всем спасибо за внимание! Всех обнял!