Когда вы нажимаете «Войти», страница не сама решает, верный ли пароль, — она отправляет запрос на сервер и получает ответ. Этот способ общения программы с сервером называется API. Тестировать можно не только кнопки, но и сам этот обмен — напрямую, без интерфейса. Инструмент для этого — Postman.
Звучит технически, но на базовом уровне всё просто: запрос — это «вопрос» серверу, ответ — его «реплика». Разберём, что это за вопросы-ответы и как задать их руками.
Что такое API простыми словами
API — это способ, которым одна программа обращается к другой. Для тестировщика важна самая частая его разновидность — обмен по протоколу HTTP, тот же, по которому работают сайты.
Аналогия: API — это официант. Вы (страница) говорите официанту (API) «принеси список моих заказов», он идёт на кухню (сервер) и возвращается с блюдом (данными). Вам не нужно знать, как устроена кухня, — достаточно правильно сделать заказ и проверить, что принесли.
Зачем тестировать API отдельно от интерфейса:
- Быстрее. Проверить десяток вариантов запроса напрямую куда быстрее, чем кликать через страницы.
- Глубже. Иногда баг в API, а интерфейс его маскирует (или наоборот). Проверив напрямую, вы точно знаете, где сломано.
- Раньше. API часто готово раньше, чем интерфейс, — можно начинать тестировать, пока кнопок ещё нет.
Из чего состоит запрос
У каждого запроса есть несколько частей:
- Метод — что мы хотим сделать. Основные: GET (получить данные — «покажи мои заказы»), POST (создать — «создай новый заказ»), PUT/PATCH (изменить), DELETE (удалить).
- URL (адрес) — куда обращаемся, например
example.com/api/orders. - Заголовки (headers) — служебная информация: формат данных, токен авторизации (кто мы такие).
- Тело (body) — данные, которые отправляем, обычно для POST. Часто в формате JSON — простом текстовом виде «ключ: значение».
Из чего состоит ответ
Сервер отвечает, и в ответе для нас главное:
- Статус-код — короткий итог. Их стоит запомнить по группам:
- 2xx (200, 201) — успех, всё хорошо.
- 4xx (400, 401, 403, 404) — ошибка на нашей стороне: неверный запрос, не авторизованы, нет доступа, не найдено.
- 5xx (500) — ошибка на сервере. Почти всегда баг.
- Тело ответа — сами данные (обычно JSON): список заказов, сообщение об ошибке, созданный объект.
Проверка API сводится к тому же, что и везде: сравнить фактический ответ (статус + тело) с ожидаемым.
Первые шаги в Postman
Postman — бесплатная программа, где запрос собирается мышкой: выбрал метод, вписал адрес, при необходимости добавил тело и заголовки, нажал Send — получил ответ со статусом и телом.
Простой сценарий для тренировки:
- Выбрать метод GET, вписать адрес открытого учебного API (в интернете есть бесплатные, например по запросу «public test API») и нажать Send. Посмотреть статус 200 и данные в ответе.
- Попробовать POST — отправить тело с новыми данными, увидеть статус 201 и созданный объект в ответе.
- Сделать заведомо неправильный запрос (несуществующий адрес) и увидеть статус 404.
Так вы на практике почувствуете связку «запрос → ответ → статус». Что именно проверять в ответах — те же позитивные и негативные сценарии: правильные данные, пустые, неверные, без авторизации.
Где это применяется
API-тестирование — важный навык уже для среднего уровня. На проекте вы будете проверять запросы напрямую, когда нужно быстро перебрать много вариантов, отделить баг сервера от бага интерфейса или начать тестировать до готовности экранов. А в связке с вкладкой Network это даёт полную картину: там вы видите, какой запрос шлёт страница, а в Postman можете повторить его руками и поиграть с данными.
Где спотыкаются начинающие:
- Боятся слова API и обходят его стороной, теряя мощный и быстрый способ проверки.
- Не понимают статус-коды. Хотя бы группы 2xx/4xx/5xx нужно знать назубок — они сразу говорят, где искать.
- Проверяют только успешные запросы и забывают про негативные: без авторизации, с пустым телом, с неверными данными.
Что учить дальше. Запрос ушёл, сервер что-то сохранил — а как убедиться, что сохранил правильно? Заглянуть в базу данных. Про это — SQL для тестировщика.