🔌 API: Эвристики тестирования бэкенда
Здесь мы тестируем не кнопки, а логику и безопасность.
1️⃣ Принцип идемпотентности Повторный вызов того же метода (без изменения данных) не должен менять состояние системы. ✅ Правильно: GET /users/123 возвращает то же самое. ❌ Баг: Каждый POST /create создает новую сущность даже с одинаковыми данными без проверки.
2️⃣ Семантика методов (CRUD) Строгое соответствие HTTP-методов действиям: — GET — только получение данных, никогда не меняет состояние. — DELETE — удаляет. (Проверьте: а не меняет ли он статус заказа на «отменен» вместо реального удаления? Это нарушение контракта). — PUT — полная замена ресурса. — PATCH — частичное обновление.
3️⃣ Эвристика полноты ответа (RESTful) Что должно возвращаться после создания ресурса (POST)? Хороший тон — 201 Created и Location header с ссылкой на новый ресурс. Плохо — просто пустой 200 OK.
4️⃣ Отсутствие избыточности API не должен возвращать поля, которые не нужны клиенту в данном контексте. Если клиент не просил пароль, его хэш не должен лететь в ответе даже по ошибке.
5️⃣ Эвристика границ и типов Передаем в integer поле строку "abc". Проверяем: — Резкость: Бэкенд вернет 400 Bad Request. — Пластилин: Бэкенд вернет 500 Internal Server Error. Правильный ответ — 400 с внятным сообщением.
6️⃣ Эвристика авторизации (IDOR) Классика: если я меняю в запросе user_id=123 на user_id=124 и получаю чужие данные — это критическая уязвимость. Проверяем, что проверка прав доступа происходит на уровне бэкенда, а не скрыта в UI.
📌 Бонус: Топ-3 вопроса для код-ревью или анализа бага
1. Условия гонки (Race Conditions) : Что будет, если два запроса отправятся одновременно с разными данными на один ресурс? 2. Обработка ошибок: Приходит 5xx ошибка. Она «падает» на UI или система показывает человеческое сообщение? 3. Согласованность UI/API: Может ли пользователь увидеть в интерфейсе то, что запрещено возвращать API по роли?
Используйте эти эвристики как чек-лист для «быстрой проверки», чтобы не полагаться только на написанные тест-кейсы. 🚀
· 01.04
POST метод не идемпотентен по определению. Здесь речь уже о дедупликации.
ответить
коммент удалён
· 01.04
Вы правы) писал пост кратко, хорошо что подсветили, в следующем посте рассмотрю тему глубже
ответить
ответ удалён