Тестирование API для начинающих
Пользователь нажимает «Создать аккаунт» и видит зелёное подтверждение. Следующая система получает неполные данные, поэтому спокойный экран скрывает сломанную договорённость. Интерфейс показывает финальную сцену, а API переносит состояние к следующему шагу.
Тестирование API для начинающих лучше строить вокруг одного запроса: от его контракта к побочным эффектам. Код статуса даёт важную подсказку, но не весь вывод.
Тестирование API для начинающих начинается с контракта запроса
До отправки запишите метод, URL, состояние авторизации, заголовки и тело. Отметьте обязательные поля, связи между значениями и ответ, который должен означать успех. Так вкладка инструмента превращается в проверяемую договорённость.
Сначала используйте маленькую полезную нагрузку. Ошибку проще понять, когда в запросе нет лишних решений.
Проверяйте не только код статуса
Смотрите на статус, структуру ответа, типы, обязательные поля и осмысленные значения. Ответ 200 может содержать пустой список, устаревший идентификатор или состояние, которое следующая система не сможет использовать.
Если ответ должен создать или изменить состояние, сохраните идентификатор и проверьте следующий наблюдаемый результат. Ответ и сохранённый эффект, две части одной истории.
Проверяйте негативные данные как решения, а не как случайный ущерб
- Уберите одно обязательное поле.
- Передайте неверный формат или неподдерживаемое значение.
- Повторите запрос, если операция должна быть идемпотентной или защищённой.
- Используйте роль или токен без нужного доступа.
Для каждой негативной проверки назовите ожидаемый отказ и то, что не должно измениться. Нельзя считать запрос безопасным, если он возвращает ошибку, но всё равно создаёт данные.
Проверяйте связи и побочные эффекты
Проследите за данными в следующей системе, записи или пользовательском пути. Убедитесь, что идентификаторы относятся к нужной сущности, суммы остаются согласованными, а отклонённое действие не оставляет частичное состояние там, где договорённость этого не допускает.
Не обязательно проверять все эффекты в первом сценарии. Выберите тот, который меняет решение о риске, а остальные запишите как границу.
Сделайте первую коллекцию повторяемой
Меняющиеся значения вынесите в переменные, подготовку отделите от проверок, а нужные доказательства назовите явно. Начните с небольшой коллекции, отвечающей на один вопрос. Добавляйте следующий запрос только тогда, когда можете объяснить, какую часть цепочки он расширяет.
Хорошая API-проверка делает невидимую договорённость видимой: входные данные, ответ, состояние и последствие.
Тестирование API для начинающих: проследите запрос до состояния
Выберите метод создания, изменения или поиска. Запишите контракт, отправьте минимальный корректный запрос и сохраните поля ответа, которые нужны следующему шагу.
Уберите одно обязательное поле и повторите запрос. Проверьте и отказ, и отсутствие нежелательного изменения состояния. Затем снова выполните корректный запрос из чистого начального состояния.
Опишите цепочку в пяти строках: вход, ожидаемый ответ, фактический ответ, сохранённый эффект и оставшаяся неопределённость. Это уже полезный первый артефакт API-практики.
Вопросы перед следующим шагом
- Какая часть запроса является контрактом?
- Что меняется при успехе кроме тела ответа?
- Что не должно измениться после отказа?
- Какая переменная сделает коллекцию повторяемой?
Сочетайте практику запросов со структурированным изучением основ тестирования.
Открыть roadmap тестировщика →