Тестовые запросы SQL и HTTP: как проверять базы данных и API

Разработчик и тестировщик каждый день пишут десятки проверочных запросов — к базе, к API, к внешним сервисам. В этом гайде разберём по-человечески, как составлять тестовые запросы SQL, что такое тестовый HTTP-запрос, чем GET отличается от POST и на каком сервере всё это можно потренировать.

Что такое тестовый запрос и зачем он нужен

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

Такие запросы нужны в трёх ситуациях:

• Разработчик пишет новую фичу и хочет убедиться, что запрос к БД вернёт то, что нужно.
• Тестировщик проверяет API перед релизом — руками через Postman или автотестами.
• Аналитик собирает данные и хочет посмотреть срез, прежде чем строить отчёт.

Разница между тестовым и боевым запросом только одна: цель. Синтаксис тот же самый, но тестовый вы гоняете на песочнице или на копии данных, а не на живой продакшн-базе.

Тестовые запросы SQL: с чего начать

Тестовые запросы SQL — это простые SELECT-конструкции, которые помогают проверить структуру таблиц, наличие данных и корректность связей. Начинать всегда стоит с самого лёгкого.

Классический минимум, который вы будете писать чаще всего:

• SELECT * FROM users LIMIT 10 — посмотреть, что вообще лежит в таблице.
• SELECT COUNT(*) FROM orders — проверить, есть ли записи.
• SELECT * FROM users WHERE email = 'test@test.ru' — найти конкретную строку.
• SELECT u.name, o.total FROM users u JOIN orders o ON u.id = o.user_id — проверить связь двух таблиц.

Совет от практики: перед любым UPDATE или DELETE всегда сначала прогоните тот же WHERE через SELECT. Увидите, какие строки попадут под изменение — и не удалите половину базы одним движением.

Где безопасно тренироваться

Не трогайте прод. Поднимите локальный PostgreSQL или MySQL в Docker, либо возьмите готовые тренировочные базы — Sakila, Northwind, Chinook. Там уже есть данные, на которых можно отработать JOIN, GROUP BY и подзапросы.

Тестовый HTTP-запрос: как устроен и чем отправлять

Тестовый HTTP-запрос — это ручная или автоматическая отправка обращения к серверу, чтобы посмотреть, какой ответ он вернёт. Так проверяют API, вебхуки, интеграции с внешними сервисами.

Любой HTTP-запрос состоит из четырёх частей:

• Метод — GET, POST, PUT, DELETE, PATCH.
• URL — адрес, куда стучимся.
• Заголовки — служебная информация: тип контента, токен авторизации.
• Тело — данные, которые отправляем (для POST и PUT).

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

• Postman — визуальный клиент, подходит и новичку, и опытному тестировщику.
• Insomnia — легче и быстрее Postman, но с меньшим количеством фич.
• curl — консольная утилита, стоит на любом сервере.
• HTTPie — удобная замена curl с человеческим синтаксисом.

Тестовый GET-запрос: получаем данные

Тестовый GET-запрос — это самый простой способ проверить, что сервер жив и отдаёт нужные данные. GET ничего не меняет на сервере, только читает.

Пример через curl:

• curl https://jsonplaceholder.typicode.com/users/1 — получить данные пользователя с id=1.
• curl -H "Authorization: Bearer TOKEN" https://api.example.com/orders — запрос с авторизацией.

Что проверять в ответе:

• Код ответа — 200 OK, 404, 500. Каждый говорит своё.
• Заголовки — тип контента, кеширование, CORS.
• Тело ответа — приходит ли JSON, все ли поля на месте, правильные ли типы данных.
• Время ответа — если больше секунды, уже стоит задуматься.

GET-запросы удобно писать прямо в браузере: вставили ссылку в адресную строку — увидели ответ. Быстрее не бывает.

Тестовый POST-запрос: отправляем данные

Тестовый POST-запрос — это отправка данных на сервер: создание пользователя, оформление заказа, загрузка файла. В отличие от GET, POST меняет состояние системы, поэтому проверять его нужно внимательнее.

Пример через curl:

• curl -X POST -H "Content-Type: application/json" -d '{"name":"Иван","email":"ivan@test.ru"}' https://api.example.com/users

Что обязательно тестировать в POST-запросах:

• Валидные данные — приходит ли ответ 201 Created, вернулся ли id новой записи.
• Невалидные данные — пустое имя, кривой email, слишком длинная строка. Сервер должен вернуть 400 Bad Request.
• Дубликаты — что будет, если создать пользователя с уже занятым email.
• Без авторизации — придёт ли 401 Unauthorized.
• Инъекции — попробуйте вставить в поле SQL или скрипт, посмотрите на реакцию.

Важно: тестовые POST-запросы всегда гоняйте на стейджинг-окружении. В проде вы будете создавать реальные заказы и слать реальные уведомления клиентам — это никому не нужно.

Тестовый сервер для запросов: где потренироваться бесплатно

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

Проверенные варианты, которыми пользуются все:

• JSONPlaceholder (jsonplaceholder.typicode.com) — самый популярный. GET, POST, PUT, DELETE работают, но данные не сохраняются. Идеально для первых шагов.
• ReqRes (reqres.in) — эмулирует реальный API с задержками и разными кодами ответов.
• httpbin (httpbin.org) — показывает всё, что вы отправили. Удобно проверять заголовки и куки.
• Postman Echo — сервер от Postman для тестов внутри их клиента.
• Public APIs — коллекция настоящих открытых API: погода, курсы валют, космос.

Если нужен полностью свой контроль — поднимите mock-сервер через Mockoon или json-server. Настраивается за пять минут, отдаёт любые ответы, которые вы пропишете.

Частые ошибки при работе с тестовыми запросами

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

• Тесты на проде. Классика жанра. Один DELETE без WHERE — и вы объясняете руководству, куда делись заказы.
• Забытая авторизация. Запрос вернул 401, а вы полчаса ищете баг в коде — просто токен протух.
• Неправильный Content-Type. Отправляете JSON, а в заголовке text/plain. Сервер не понимает и ругается.
• Игнор кодировки. Кириллица в теле запроса ломается, если не указан UTF-8.
• Только позитивные сценарии. Проверили, что всё работает на правильных данных, а на пустой строке система падает.

Хорошая привычка — вести коллекцию тестовых запросов в Postman или Bruno. Один раз настроили — потом всей командой пользуетесь.

Как это устроено у нас в AiPepDen

Мы в AiPepDen — AI-агентство маркетинга. Тестовые запросы для нас — это не только про код. Мы гоняем аналогичные проверки по воронке клиента: как приходят лиды, где утекают, что реально приносит деньги.

Всё сводим в Карту Дохода — еженедельную модель по каналам. Видно, где вход денег растёт, а где канал просел. За рекламу отвечает Елена, за SEO — Виктор, за аналитику — Гена. Работаем круглосуточно, первый ответ от Анны — около 30 секунд.

Начинаем всегда с бесплатного AI-аудита за 24 часа. Если видим, чем помочь — беремся. Если нет — честно скажем. Написать можно в Telegram-бот Анны. Больше кейсов — в разделе /chronicle/.

← Все материалы хроники