Автоматизация — это важно, но ручное тестирование API позволяет:
Быстро исследовать поведение API при изменении входных данных
Понять бизнес-логику и ограничения
Найти неочевидные баги, которые сложно формализовать
Проверить edge cases до написания автотестов
Валидировать документацию API
Инструменты для ручного тестирования: Postman, Insomnia, curl, браузер (для GET-запросов)
Виды тестирования API
Позитивное тестирование (Positive Testing)
Проверяет, что API корректно работает при валидных входных данных.
Что проверять:
Корректный ответ при правильных данных
Правильный статус-код (200, 201)
Все обязательные поля присутствуют в ответе
Типы данных соответствуют спецификации
Данные действительно сохраняются/изменяются на сервере
Примеры позитивных тест-кейсов для POST /users:
#
Действие
Ожидание
1
Отправить POST с валидными данными
201 Created, пользователь создан
2
Отправить GET на созданного пользователя
200 OK, данные совпадают
3
Отправить PATCH с новым именем
200 OK, имя обновлено
4
Отправить DELETE
204, GET возвращает 404
Негативное тестирование (Negative Testing)
Проверяет, что API корректно обрабатывает невалидные данные и ошибочные ситуации.
Что проверять:
Невалидные входные данные
Отсутствие обязательных полей
Неверный формат данных
Несуществующие ресурсы
Нарушение бизнес-правил
Примеры негативных тест-кейсов для POST /users:
#
Действие
Ожидание
1
Пустое тело запроса
400 Bad Request
2
Невалидный JSON (сломанный синтаксис)
400 Bad Request
3
Без обязательного поля email
400 или 422
4
Невалидный email (без @)
422 Unprocessable Entity
5
Пустая строка в name
422
6
Дублирующийся email
409 Conflict
7
Очень длинная строка (10000 символов)
400 или 422
8
SQL-инъекция в поле name
400 или экранирование
9
XSS в поле description
400 или экранирование
Граничные значения (Boundary Values)
Один из самых эффективных методов тестирования. Проверяет поведение API на границах допустимых диапазонов.
Принцип
Если поле принимает значения от 1 до 100, проверяем:
Минимум: 0, 1, 2
Максимум: 99, 100, 101
Специальные: -1, null, пустая строка
Примеры граничных тестов
Поле age (допустимый диапазон: 0–150)
Значение
Ожидание
Тип
null
400/422 — обязательно
Ниже минимума
-1
400/422 — невалидно
Ниже минимума
0
200 — допустимо
Граница минимума
1
200 — допустимо
Выше минимума
150
200 — допустимо
Граница максимума
151
400/422 — невалидно
Выше максимума
1000
400/422 — невалидно
Значительно выше
2147483647
400/422
INT_MAX
2147483648
400/422
INT_MAX + 1 (переполнение)
"abc"
400/422
Неверный тип
12.5
400/422
Дробное число (если целое)
Поле name (макс. 255 символов, мин. 1 символ)
Значение
Ожидание
Тип
"" (пустая)
400/422
Ниже минимума
"A" (1 символ)
200
Граница минимума
"AB" (2 символа)
200
Выше минимума
Строка из 254 символов
200
Ниже максимума
Строка из 255 символов
200
Граница максимума
Строка из 256 символов
400/422
Выше максимума
Строка из 10000 символов
400/422
Значительно выше
null
400/422
Отсутствие значения
Пробелы " "
400/422
Только пробелы
Спецсимволы "<>&\"'"
200 (экранировано)
Спецсимволы
Unicode "Иван Танака"
200
Unicode-символы
Emoji "😀🔥"
200
Emoji
Пагинация (?page=1&limit=10)
Значение
Ожидание
page=0
400 или page=1
page=-1
400
page=1
200, первая страница
page=999999
200, пустой массив
limit=0
400 или пустой массив
limit=-1
400
limit=1
200, 1 элемент
limit=100
200, до 100 элементов
limit=10001
400 или ограничение
limit=abc
400
Тестирование аутентификации
Что проверять
#
Сценарий
Ожидание
1
Запрос без токена
401 Unauthorized
2
Запрос с невалидным токеном
401 Unauthorized
3
Запрос с истёкшим токеном
401 Unauthorized
4
Запрос с валидным токеном
200 OK
5
Запрос с токеном другого пользователя
403 Forbidden
6
Попытка доступа к чужому ресурсу
403 Forbidden
7
Попытка выполнить действие без прав
403 Forbidden
8
Пустой заголовок Authorization
401
9
Неверный формат (нет Bearer)
401
Различия 401 и 403
401 Unauthorized → «Кто ты?» → Аутентификация не пройдена
→ Нет токена, невалидный токен, истёкший токен
403 Forbidden → «Я знаю, кто ты, но тебе нельзя» → Авторизация не пройдена
→ Нет прав на ресурс, нет нужной роли
Практические сценарии
Проверка доступа к admin-эндпоинтам:
Без токена → 401
С токеном обычного пользователя → 403
С токеном администратора → 200
Проверка доступа к чужим данным:
Пользователь A запрашивает свои данные → 200
Пользователь A запрашивает данные пользователя B → 403
Администратор запрашивает данные любого пользователя → 200
Валидация данных (Data Validation)
Проверка структуры ответа
// В Postman Tests:
pm.test("Структура ответа корректна", function () {
const r = pm.response.json();
pm.expect(r).to.have.property("id");
pm.expect(r).to.have.property("name");
pm.expect(r).to.have.property("email");
pm.expect(r).to.have.property("created_at");
});
Дочерние ресурсы тоже удалены (или запрет удаления)
5
Статус заказа
Допустимые переходы: new → paid → shipped → delivered
Проверка сортировки и фильтрации
GET /users?sort=name&order=asc → имена по алфавиту
GET /users?sort=created_at&order=desc → новые первые
GET /users?role=admin → только админы
GET /users?search=иван → содержит "иван"