Как проверить API: чек-лист начинающего тестировщика

Фронтенд — лицо приложения, а API — его скелет и нервная система. Красивый интерфейс не спасет, если сервер отдает не те данные или не отвечает вовсе. Чтобы такого не произошло, перед выпуском проводят API-тестирование. Что это такое — рассказываем в статье.

Что такое API в тестировании?

API (Application Programming Interface) — набор правил и инструментов, с помощью которых одна программа «общается» с другой и может запрашивать данные.

Как это работает: 

1. Клиент отправляет HTTP-запрос на определенный адрес.
2. Сервер обрабатывает запрос и ищет нужные данные в базе.
3. Сервер возвращает HTTP-ответ с данными или подтверждением операции.

Например, благодаря API можно авторизоваться в новом приложении через соцсети, провести оплату картой на сайте или узнать актуальный прогноз погоды. 

API можно сравнить с официантом в ресторане, где вы (программа-клиент) делаете заказ, кухня (сервер) готовит его, а он выступает в роли посредника. Чтобы все работало правильно, проводят API-тесты. Они позволяют проверить функциональность и безопасность приложения до выпуска в продакшен. 

Инструменты для тестирования API

Для тестирования API используют специальные клиенты. Самые популярные: 

• Postman — позволяет отправлять разные HTTP-запросы, анализировать ответы, создавать автотесты на JavaScript и управлять средами.
• Insomnia API Client — популярное десктопное приложение для проектирования, отладки и тестирования API. Позволяет отправлять запросы к серверу, анализировать ответы, управлять окружениями и генерировать документацию. 
• Swagger UI — инструмент с открытым исходным кодом. Автоматически генерирует интерактивную документацию, позволяет просматривать структуру API и отправлять запросы. 
• cURL — утилита командной строки, которая используется для передачи данных на сервер по разным протоколам. Позволяет отправлять API-запросы, загружать файлы и тестировать сайты без браузера. Встроена в большинство современных операционных систем (Linux, macOS, Windows).

Для работы с API можно выбрать любой удобный клиент, но чаще всего используют Postman. У него удобный интерфейс, где можно создавать запросы без кода. По данным компании-разработчика, Postman используют 40 миллионов пользователей и около 500 000 компаний. 

Виды тестирования API

Есть разные виды тестирования API:

• Функциональное тестирование: проверяет, работает ли API, как реагирует на корректные/некорректные запросы и сообщает об ошибках.
• Интеграционное тестирование: смотрит, как API общается с внешними сервисами (CRM, платежными шлюзами, СМС-рассылками). Например, если API принял заказ и списал деньги, но не отправил уведомление клиенту в Telegram — это баг интеграции.
• Тестирование авторизации и аутентификации: проверяет механизмы доступа к API.
• Нагрузочное тестирование API: проверяет, как приложение ведет себя под нагрузкой или при большом количестве запросов. 
• Тестирование безопасности: ищет уязвимости, чтобы предотвратить возможные утечки и несанкционированный доступ. 

Вид тестирования всегда выбирают под задачу. Но чаще тестировщик комбинирует разные тесты в зависимости от нужд проекта.

Чек-лист тестирования API 

Универсальная схема проверки API выглядит так: статус → тело ответа → заголовки → бизнес-логика. Если последовательно пройти по этим шагам, вы не пропустите критичные ошибки.

• Проверка HTTP-статусов: когда вы отправляете запрос, сервер его обрабатывает. Чтобы информировать, что все прошло гладко, на каждый запрос сервер возвращает трехзначный код статуса: 

• 2xx — успех;
• 4xx — ошибка клиента;
• 5xx — ошибка сервера.

Если пришел код 2хх — все хорошо. Но возможны и негативные сценарии, например 400 Bad Request или код 500. Это значит, произошла проблема на стороне сервера или клиента, и нужно смотреть логи.

• Валидация тела ответа: код 200 означает, что запрос к серверу выполнен успешно, ресурс найден и ответ передан без ошибок. Однако, это не гарантирует, что в содержании именно то, что нам надо. Важно проверить, все ли поля приходят и совпадают ли типы данных. Например, мы можем отправить запрос на получение пользователя с именем «Иван», а в ответе придет «name»: «Петр».
• Проверка заголовков: заголовки относятся к служебной информации. Они не видны в теле, но влияют на то, как клиент обработает ответ. Например, если в ответе заголовок должен быть Content-Type: application/json, а придет text/html, то фронтенд может сломаться.
• Проверка бизнес-логики: часто баги прячутся в сценариях. Важно проверить цепочки действий пользователя. Например:

Удалили товар из корзины (DELETE) → Попытались оформить заказ (POST). 

Сервер должен вернуть ошибку с кодом 4xx и сообщением «Корзина пуста», а не создавать заказ с нулевой суммой.

В реальной работе порядок шагов может меняться. Например, если API только разрабатывается, важнее проверить статусы и бизнес-логику, чтобы убедиться, что сценарии работают правильно. Важно не просто механически пройти по всем пунктам, а научиться видеть связи между ними. 

Популярные ошибки в API

Чаще всего во время API-тестов находят эти проблемы:

• «Кривой» JSON: сервер прислал ответ, но из-за лишней запятой или сломанной структуры его невозможно распарсить и фронтенд просто повисает. 
• Несоответствие документации: бывает, что в документации описана одна структура данных, а при тестировании приходит другая. Например, указано 10 полей, а в ответе их 15. Или наоборот — не приходят обязательные поля.

• Проблема «200-го статуса»: иногда при отправке заведомо некорректного запроса (например, без обязательного поля или с неверным паролем), сервер возвращает код 200. При этом внутри тела ответа лежит «error»: «wrong password» или пустой объект. 
• Доступ к чужим данным (IDOR): когда вы авторизуетесь как обычный пользователь id=1 при запросе к api/users/1 сервер возвращает ваши данные. Но если вручную изменить в запросе api/users/2, то сервер отдает данные другого пользователя без проверки прав доступа.
• Некорректная обработка спецсимволов: если отправить в поле ввода спецсимволы, кавычки, иероглифы или эмодзи, то API должен корректно сохранить эти данные или отфильтровать. 

Большинство проблем с API предсказуемые — зная их заранее, вы быстрее найдете ошибки в проекте. К любому багу обязательно прикладывайте запрос, ответ сервера и скриншот. Тогда разработчику не придется гадать, что именно сломалось.

Как работать с коллекциями в Postman

Работать с одиночными запросами в Postman легко, но в реальном тестировании используют десятки запросов и держать отдельные вкладки становится неудобно. В таком случае создают коллекции — папки с запросами. Их можно сохранять, делиться с командой и даже прогонять автоматически. 

Как организовать коллекцию, чтобы в ней было удобно работать:

• Используйте структуру: разбейте запросы в Postman по функциональным блокам — авторизация, пользователи, товары, заказы, платежи и т.д. Так будет интуитивно понятно. 
• Пронумеруйте папки: в Postman все папки автоматически сортируются по алфавиту. Если назвать просто Auth, Users, Products, то порядок может быть нелогичным. Нумерация поможет закрепить нужную последовательность (1 Auth, 2 Products, 3 Users)
• Давайте понятные имена: не «test1» или «GET», а «GET список пользователей», «POST создать заказ». Это поможет не запутаться.
• Располагайте запросы в Postman в порядке жизненного цикла: создать (POST) → получить (GET) → обновить (PUT) → удалить (DELETE). Это поможет поддерживать порядок внутри папок.

Коллекции не только облегчают работу, но и удобны для командной работы. Новому сотруднику можно дать ссылку на коллекцию, он сразу увидит все запросы и сможет начать работать без долгого погружения.

Главное о тестировании API

• API — набор правил и инструментов, с помощью которых программы «общаются» друг с другом и обмениваются данными.
• Postman — это самый популярный клиент для тестирования API. Он позволяет отправлять HTTP-запросы, анализировать ответы и делать автотесты.
• Есть разные виды тестирования API — можно проверить отдельную функцию, интеграцию с внешним сервисом, безопасность или производительность.
• Стандартный процесс проверки API включает: валидацию HTTP-статуса, проверку структуры и содержимого ответа, анализ заголовков и тестирование сценариев бизнес-логики. 
• Запросы в Postman можно собирать в коллекции — это удобно для командной работы.
• Типовые ошибки при тестировании API: несоответствие документации, некорректные HTTP-статусы, уязвимости доступа, ошибки обработки спецсимволов.