Собеседования по API-тестированию
Собеседования по API-тестированию оценивают понимание HTTP-протоколов, REST-архитектуры, механизмов аутентификации и способность тестировать бэкенд-сервисы независимо от фронтенда.
Основные области знаний
HTTP-методы и их тестовые особенности
| Метод | Назначение | Идемпотентный | Фокус тестирования |
|---|---|---|---|
| GET | Получение данных | Да | Формат ответа, фильтрация, пагинация |
| POST | Создание ресурса | Нет | Валидация, предотвращение дубликатов |
| PUT | Замена ресурса | Да | Полная замена, поведение при отсутствии полей |
| PATCH | Частичное обновление | Нет | Логика частичного обновления |
| DELETE | Удаление ресурса | Да | Soft vs hard delete, авторизация |
Знание статус-кодов
Успех (2xx): 200 OK, 201 Created, 204 No Content Редиректы (3xx): 301 Moved, 304 Not Modified Ошибки клиента (4xx): 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 422 Unprocessable Entity, 429 Too Many Requests Ошибки сервера (5xx): 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable
Тестирование аутентификации
API Keys: Валидный ключ, невалидный, отсутствующий, истёкший, отозванный OAuth 2.0: Получение токена, refresh-поток, истечение, валидация scope JWT: Структура токена, валидация подписи, истечение, подменённый payload Basic Auth: Валидные данные, невалидные, отсутствующий заголовок
Типичные вопросы собеседования
В1: Как тестировать API без документации?
- DevTools браузера для перехвата запросов
- Анализ паттернов request/response
- Тестирование разными HTTP-методами
- Поиск сообщений об ошибках, раскрывающих структуру
В2: Как валидировать схему ответа API?
- JSON Schema-валидация структуры и типов
- Проверка обязательных полей
- Проверка типов данных
- Валидация вложенных объектов и массивов
В3: Как тестировать производительность API?
- Время отклика под нормальной нагрузкой
- Throughput при ожидаемом числе пользователей
- Поведение под стрессом
- Connection pooling и таймауты
В4: Что такое идемпотентность и почему это важно для тестирования?
- Идемпотентные операции дают одинаковый результат независимо от числа вызовов
- GET, PUT, DELETE идемпотентны; POST обычно нет
- Тестировать вызовом одного endpoint несколько раз
Практическая демонстрация
Подход к тестированию CRUD API:
1. Позитивный поток:
POST /users → 201 (создать)
GET /users/id → 200 (проверить создание)
PUT /users/id → 200 (обновить)
DELETE /users/id → 204 (удалить)
GET /users/id → 404 (проверить удаление)
2. Тестирование валидации: Пустые поля, невалидные типы, дубликаты 3. Тестирование авторизации: Без токена, невалидный токен, неправильная роль 4. Граничные случаи: Конкурентные изменения, большие payload, спецсимволы
Упражнение: Задача по API-тестированию
Протестируйте эту API-спецификацию как на собеседовании:
Endpoint: POST /api/bookings
Тело: guest_name (string, обязательное), check_in/check_out (дата), room_type (standard|deluxe|suite), guests (1-4)
Составьте минимум 15 тест-кейсов.
Решение
- Валидное бронирование → 201
- Без guest_name → 400
- Без check_in → 400
- check_out раньше check_in → 400
- check_in в прошлом → 400
- Одинаковые даты check_in/check_out → уточнить
- Невалидный формат даты → 400
- Невалидный room_type → 400
- guests = 0 → 400
- guests = 5 → 400
- Очень длинный guest_name → 400
- Спецсимволы в имени → 200
- SQL-инъекция → 400
- Дублирующее бронирование → 409 или 200
- Пустое тело запроса → 400
Ключевые выводы
- Досконально знайте HTTP-методы, статус-коды и паттерны аутентификации
- Структурируйте API-тестирование по слоям: функционал, валидация, авторизация, граничные случаи
- Демонстрируйте системный подход при тестировании незнакомых API
- Понимайте идемпотентность, пагинацию и rate limiting
- Контрактное тестирование и валидация схем — маркеры senior-уровня