Стратегии тестирования API: о чём часто забывают аналитики

Когда речь заходит про тестирование API, имеется в виду не просто «протестировать», а понимать, что именно должно проверяться.

1. Функциональное тестирование

Это проверка базовой функциональности: корректность работы методов, соответствие контракту и правильность данных в ответе

2. Негативные сценарии

Вот где чаще всего всё ломается.

Помните, оба тестировщика в своих интервью говорили про этот пункт? Задавать себе вопрос “а что если что-то пойдет не так?”

То есть обязательно проверяем невалидные данные, отсутствующие поля и неправильные форматы. 

И вот здесь важно не просто «вернуть ошибку», а заранее зафиксировать, какой код возвращаем, что пишем в ответе и одинаково ли это работает во всех методах.

3. Boundary testing (граничные значения)

Одна из самых недооценённых стратегий, обычно кажется, что всё это «мелочи».
Но! Очень важно проверить минимальные и максимальные значения, длину строк и лимиты.

4. Тестирование идемпотентности

Вот это прям классика интеграций. Один и тот же запрос может прилететь дважды… проблемы с сетью, retry, пользователь нажал кнопку 2 раза – да что угодно.
Ну то есть в ТЗ мы это и фиксируем (какие методы идемпотентны, как обрабатываются дубли и тд)

5. Нагрузочное тестирование (стресс-тест)

Это уже не всегда зона аналитика напрямую, но понимать это нужно.
Т.к. когда запросов становится много и интеграции начинают «долбить» систему, всплывает всё, о чём писала раньше: rate limiting, очереди и т.д.

6. Тестирование интеграций 

API почти никогда не живёт сам по себе, он завязан на другие сервисы.
И здесь главный вопрос: что будет, если один из них отвалится?
• запрос потеряется?
• будет retry?
• сломается вся цепочка?
Это всё критично.

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