Тестирование API в Postman: от основ протокола HTTP до автоматизации проверок

Основы API и протокола HTTP для тестировщика: методы, коды ответов и структура запроса

Представьте, что вы приходите в ресторан. Вы не идете на кухню, чтобы лично жарить стейк, — вы общаетесь с официантом. Официант принимает ваш заказ, передает его повару, а затем приносит готовое блюдо или сообщает, что ингредиенты закончились. В мире программного обеспечения роль такого официанта выполняет API (Application Programming Interface). Это контракт, который позволяет одной программе «попросить» что-то у другой, не вникая в детали того, как именно работает чужой код. Для тестировщика это означает, что мы проверяем не графический интерфейс (кнопки и формы), а правильность обмена этими «заказами».

Понимание архитектуры Client-Server и роли HTTP

Большинство современных веб-приложений строятся на архитектуре «клиент-сервер». Клиент (ваш браузер, мобильное приложение или Postman) отправляет запрос, а сервер (удаленный компьютер с базой данных и бизнес-логикой) возвращает ответ. Общение происходит по протоколу HTTP (HyperText Transfer Protocol). Это набор правил, определяющий формат сообщений. Если клиент нарушит правила (например, забудет указать обязательный параметр), сервер его просто не поймет.

Тестирование API критически важно, потому что ошибки на этом уровне «дешевле» исправлять, чем на уровне UI. Если сервер позволяет создать пользователя с отрицательным возрастом через API, никакие красивые проверки в браузере не спасут систему от порчи данных. Мы работаем с «фундаментом» приложения.

Анатомия HTTP-запроса: из чего состоит «заказ»

Каждый запрос, который вы будете отправлять в Postman, состоит из четырех обязательных компонентов. Понимание их структуры — это 50% успеха на техническом интервью.

URL (Endpoint): Адрес ресурса. Например, https://api.shop.com/v1/products/42. Здесь api.shop.com — это хост, а /v1/products/42 — путь к конкретному товару.

Метод (Verb): Что мы хотим сделать? (Получить, создать, удалить).

Заголовки (Headers): Служебная информация. Здесь мы указываем, в каком формате передаем данные (например, JSON), или передаем ключ доступа (Token).

Тело (Body): Сами данные. Если мы регистрируем пользователя, в теле будут его имя и пароль. У простых запросов на получение данных тела обычно нет.

> Инсайт: Тестировщик должен проверять не только успешные сценарии, но и то, как API реагирует на «сломанные» компоненты: неверный URL, отсутствие заголовков или пустой Body.

Методы HTTP: CRUD в действии

В тестировании API мы чаще всего сталкиваемся с концепцией CRUD (Create, Read, Update, Delete). Каждой операции соответствует свой метод HTTP. Понимание разницы между ними часто проверяется на собеседованиях через каверзные вопросы.

| Метод | Операция CRUD | Идемпотентность | Описание | | :--- | :--- | :--- | :--- | | GET | Read | Да | Запрашивает данные. Не должен менять состояние сервера. | | POST | Create | Нет | Создает новый ресурс. Каждый повторный запрос создаст новый объект. | | PUT | Update | Да | Полностью заменяет существующий ресурс данными из запроса. | | PATCH | Update | Нет (обычно) | Частично обновляет ресурс (например, только поле "цена"). | | DELETE | Delete | Да | Удаляет указанный ресурс. |

Идемпотентность — это важное свойство метода. Если вы нажмете кнопку «Удалить» 10 раз (метод DELETE), результат после первого раза не изменится: ресурс удален, и последующие запросы ничего не изменят. А вот если вы 10 раз отправите POST на создание заказа, в системе может появиться 10 одинаковых заказов. Это критично для тестирования логики оплаты или регистрации.

Коды ответов сервера: язык статусов

Когда сервер возвращает ответ, первое, на что смотрит тестировщик — это Status Code. Это трехзначное число, которое сообщает о результате операции. Коды делятся на пять классов, и их знание — база для любого QA.

2xx: Успех (Success)

Самый желанный код — 200 OK. Он означает, что запрос выполнен успешно. Если вы создавали объект (POST), сервер может вернуть 201 Created. Это специфический успех, подтверждающий появление новой записи в базе.

3xx: Перенаправление (Redirection)

Эти коды говорят о том, что ресурс переехал. Для тестировщика API они встречаются реже, так как клиент обычно обрабатывает их автоматически. Например, 301 Moved Permanently.

4xx: Ошибка клиента (Client Error)

Это ваши основные «рабочие» ошибки. Если вы видите 4xx, значит, проблема в запросе. * 400 Bad Request: Сервер не понял запрос (ошибка в синтаксисе JSON). * 401 Unauthorized: Вы не представились (нужен логин/токен). * 403 Forbidden: Вы представились, но у вас нет прав доступа к этому ресурсу (например, обычный юзер лезет в админку). * 404 Not Found: Ресурс по такому адресу не существует. * 405 Method Not Allowed: Вы пытаетесь применить DELETE к ресурсу, который можно только читать (GET).

5xx: Ошибка сервера (Server Error)

Это «баги» на стороне разработчика или проблемы инфраструктуры. * 500 Internal Server Error: Самая частая ошибка. Что-то «упало» в коде сервера. Тестировщик должен завести баг-репорт и приложить логи сервера. * 503 Service Unavailable: Сервер перегружен или на обслуживании.

Разбор примера: Жизненный цикл запроса на покупку билета

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

Шаг 1: Поиск сеансов (GET) Вы отправляете запрос GET /movies/123/sessions. Сервер возвращает список доступных мест. Вы проверяете, что пришел код 200 OK и массив данных в формате JSON.

Шаг 2: Бронирование места (POST) Вы отправляете POST /bookings с телом {"session_id": 123, "seat": "A1"}. Сервер создает бронь и возвращает 201 Created с ID вашей брони. Если вы отправите этот же запрос второй раз, сервер должен вернуть 409 Conflict (место уже занято) или 400, но не создавать дубликат.

Шаг 3: Изменение данных (PATCH) Вы решили добавить к билету попкорн. Отправляем PATCH /bookings/789 с телом {"popcorn": true}. Сервер обновляет только это поле и возвращает 200 OK.

Шаг 4: Отмена (DELETE) Планы изменились. Отправляем DELETE /bookings/789. Сервер удаляет бронь и возвращает 204 No Content (успешно, но данных в ответе больше нет).

Формат данных JSON: стандарт индустрии

Хотя API могут общаться через XML или даже обычный текст, стандартом является JSON (JavaScript Object Notation). Он легок для чтения человеком и машиной.

В JSON важно соблюдать типы данных: строки пишутся в кавычках, числа — без, булевы значения (true/false) — тоже без. Массивы заключаются в квадратные скобки [], а объекты — в фигурные {}. Ошибка в одной запятой приведет к тому, что сервер вернет 400 Bad Request.

Если из этой главы запомнить три вещи — это разница между методами (GET vs POST), классы статус-кодов (2xx, 4xx, 5xx) и структура запроса (URL, Method, Headers, Body). Эти знания станут фундаментом для нашей следующей практической работы в Postman.

Интерфейс Postman и отправка первых запросов: работа с Body, Headers и Params

Когда мы разобрались с теорией HTTP, пора переходить к практике. Postman — это самый популярный инструмент для работы с API, который прошел путь от простого расширения для браузера до мощной платформы разработки и тестирования. Для QA-инженера это «швейцарский нож»: здесь мы будем составлять запросы, имитировать поведение реальных пользователей и автоматизировать проверки. В этой главе мы освоим интерфейс и научимся правильно передавать данные серверу.

Знакомство с интерфейсом: где что лежит

При первом запуске Postman может напугать обилием вкладок, но его логика проста. Весь интерфейс делится на три основные зоны:

Sidebar (Боковая панель): Здесь живут ваши Collections (папки с запросами) и History. Это ваша библиотека тестов.

Request Builder (Конструктор запроса): Верхняя центральная часть. Тут мы выбираем метод (GET, POST и др.), вводим URL и настраиваем параметры.

Response Pane (Панель ответа): Нижняя часть, которая появляется после нажатия кнопки Send. Здесь мы видим статус-код, время ответа, размер данных и, собственно, сам JSON-ответ.

> Совет: Всегда начинайте работу с создания Collection. Это не просто папка — это единица измерения в Postman, которую можно запускать целиком, экспортировать или настраивать для неё общие правила авторизации.

Query Parameters: уточняем запрос через Params

Часто нам нужно не просто получить «все товары», а отфильтровать их. Для этого используются Query Parameters. В URL они пишутся после знака вопроса: .../products?category=shoes&size=42.

В Postman для этого есть вкладка Params. Когда вы вписываете ключ (Key) и значение (Value) в таблицу, Postman автоматически дописывает их в строку URL. Это удобнее, чем вручную следить за знаками ? и &.

Пример из практики: Представьте, что вы тестируете поиск в Google. Запрос будет выглядеть как https://www.google.com/search?q=postman. Здесь q — это ключ параметра, а postman — значение. Если вы добавите второй параметр hl=en (язык), URL превратится в .../search?q=postman&hl=en.

Headers: «Метаданные» вашего запроса

Вкладка Headers отвечает за служебную информацию. Сервер использует заголовки, чтобы понять, кто вы и что вы ему прислали. Самые важные заголовки для тестировщика: * Content-Type: Говорит серверу, какой формат данных в теле запроса. Обычно это application/json. Если вы отправите JSON, но забудете этот заголовок, сервер может выдать 400 Bad Request или 415 Unsupported Media Type. * Accept: Сообщает серверу, какой формат ответа ожидает клиент. * Authorization: Здесь передаются токены доступа (например, Bearer <token>).

Postman автоматически добавляет скрытые заголовки (например, User-Agent). Вы можете увидеть их, нажав кнопку «7 hidden» в списке заголовков.

Работа с телом запроса: вкладка Body

Для методов POST, PUT и PATCH вкладка Body — самая важная. Здесь мы формируем данные, которые будут сохранены в базе. В Postman есть несколько типов Body:

none: Тела нет (используется для GET и DELETE).

form-data: Используется для отправки файлов или данных из HTML-форм.

x-www-form-urlencoded: Похоже на form-data, но только для текста.

raw: Самый частый выбор QA. Здесь мы выбираем тип JSON и пишем структуру вручную.

binary: Для отправки картинок, PDF и других бинарных файлов.

Разбор кейса: Создание пользователя Допустим, нам нужно создать нового сотрудника в системе.

Метод: POST

URL: https://reqres.in/api/users

Body -> raw -> JSON:

После нажатия Send сервер вернет нам 201 Created и объект с ID нового пользователя и временем создания. Если мы допустим ошибку в синтаксисе (например, забудем закрывающую кавычку), Postman подсветит ошибку красным, а сервер вернет ошибку.

Path Variables: динамические адреса

Иногда часть URL сама является параметром. Например, в https://api.com/users/15 число 15 — это ID пользователя. Чтобы сделать запрос универсальным, в Postman используют двоеточие: https://api.com/users/:userid. После этого во вкладке Params появится раздел Path Variables, где вы сможете быстро менять userid, не редактируя строку адреса. Это особенно полезно, когда один и тот же запрос нужно проверить для разных ID.

Разбор примера: Отправка сложного запроса с авторизацией

Давайте объединим всё изученное. Нам нужно обновить цену товара в закрытом каталоге.

Шаг 1: Метод и URL Выбираем PATCH. Вводим URL: https://api.market.com/products/:id. В Path Variables ставим id = 505.

Шаг 2: Параметры (Params) Добавляем Query Param notify_subscribers = true. Теперь URL выглядит так: .../products/505?notify_subscribers=true.

Шаг 3: Заголовки (Headers) Добавляем Authorization со значением Bearer my-secret-token-123. Без него сервер ответит 401 Unauthorized.

Шаг 4: Тело (Body) Выбираем raw -> JSON. Пишем:

Шаг 5: Анализ ответа Нажимаем Send. Получаем 200 OK. В блоке Response проверяем время ответа (Response Time) — если оно больше 2 секунд, это может быть поводом для заведения бага на производительность.

Типичные ошибки новичков

Не тот тип Body: Пытаются отправить JSON в режиме form-data. Сервер не сможет распарсить такой запрос.

Лишние пробелы или символы в URL: Postman обычно их кодирует, но в Path Variables это может привести к 404.

Забытый Content-Type: Если вы пишете JSON в raw, Postman сам предложит поставить нужный заголовок. Не игнорируйте это.

Копирование из чатов: Часто при копировании JSON из Slack или Telegram «умные» кавычки “ ” заменяют стандартные " ". Это ломает запрос.

Если из этой главы запомнить три вещи — это роль вкладки Params для фильтрации, разница между raw JSON и form-data в Body, и важность заголовка Content-Type. В следующей статье мы научимся не вводить данные вручную каждый раз, а использовать переменные.

Параметризация и управление данными: использование переменных и окружений (Environments)

Представьте, что у вас есть 100 тестов для API вашего интернет-магазина. Все они стучатся на тестовый сервер test-api.shop.com. Внезапно разработчики говорят: «Тестовый сервер переехал на stage-api.shop.com». Если вы вписывали адрес вручную в каждый запрос, вам придется потратить несколько часов на скучное обновление. Чтобы этого избежать, профессиональные тестировщики используют переменные (Variables). Это позволяет менять данные в одном месте, обновляя их во всем проекте.

Иерархия переменных в Postman

В Postman переменные работают по принципу матрешки. Если переменная с одним и тем же именем объявлена на разных уровнях, Postman возьмет ту, которая «ближе» к конкретному запросу (имеет более узкую область видимости).

Global Variables: Доступны во всем приложении, во всех коллекциях. Используются редко, например, для хранения вашего имени пользователя.

Collection Variables: Доступны только внутри одной коллекции. Идеально для базового URL проекта.

Environment Variables: Самый мощный инструмент. Позволяют переключаться между наборами данных (например, «Тестовый стенд» и «Прод»).

Data Variables: Берутся из внешних файлов (CSV/JSON) при запуске коллекции через Runner.

Local Variables: Живут только во время выполнения одного запроса.

> Правило приоритета: Если у вас есть переменная url в Globals и в Environments, Postman выберет значение из Environments, так как эта область видимости уже и приоритетнее.

Работа с окружениями (Environments)

Окружение — это именованный набор переменных. Обычно QA создают как минимум два окружения: Staging и Production.

Чтобы создать окружение:

Нажмите на иконку глаза в правом верхнем углу или выберите вкладку Environments в сайдбаре.

Нажмите Create Environment и назовите его, например, «My Shop - Dev».

Добавьте переменную baseUrl со значением https://dev-api.shop.com.

Теперь в любом запросе вместо длинного адреса пишите {{baseUrl}}/products. Обратите внимание на двойные фигурные скобки — это синтаксис обращения к переменным в Postman. Если скобки стали красными, значит, переменная не найдена (проверьте, выбрано ли нужное окружение в выпадающем списке сверху).

Initial Value vs Current Value: в чем разница?

При создании переменной вы увидите две колонки для значений. Это часто сбивает с толку на интервью. * Initial Value (Начальное значение): Это значение хранится на серверах Postman (если вы залогинены) и доступно вашим коллегам при совместной работе. Сюда нельзя класть пароли и секретные токены! * Current Value (Текущее значение): Это локальное значение на вашем компьютере. Оно никогда не уходит в облако. Именно его использует Postman при отправке запроса.

Кейс для безопасности: В Initial Value для токена пишите your-token-here, а свой реальный секретный ключ вставляйте только в Current Value. Так вы не «сли its» пароли при экспорте коллекции.

Динамические переменные (Dynamic Variables)

Иногда для теста нужны уникальные данные: случайное имя, email или случайное число, чтобы сервер не ругался на дубликаты. В Postman встроена библиотека для генерации таких данных. Они начинаются со знака guid}}: Генерирует уникальный идентификатор (UUID). * {{randomEmail}}: Случайный почтовый адрес. * {{randomEmail}}", "password": "Password123" } ` Каждый раз при нажатии кнопки Send Postman будет отправлять новый email, и вы сможете тестировать регистрацию бесконечно без ручной правки данных.

Сценарий: Автоматическая передача токена между запросами

Это классическая задача. У вас есть запрос Login, который возвращает токен, и запрос Get Profile, которому этот токен нужен в заголовках.

В запросе Login на вкладке Tests (мы разберем её подробнее в следующей статье, но сейчас важен принцип) мы пишем код, который берет токен из ответа и сохраняет его в переменную окружения:

pm.environment.set("token", pm.response.json().access_token);

В запросе Get Profile во вкладке Headers добавляем заголовок:

Authorization: Bearer {{token}}.

Теперь вам не нужно копировать токен руками. Вы один раз «залогинились», и все остальные запросы в коллекции подхватили актуальный ключ доступа автоматически.

Разбор примера: Настройка проекта с нуля

Шаг 1: Создание коллекции Создаем коллекцию «API Testing Course». В настройках коллекции (вкладка Variables) добавляем переменную version со значением v1.

Шаг 2: Создание окружения Создаем окружение «QA-Stand». Добавляем host = https://reqres.in.

Шаг 3: Составление запроса Пишем URL: {{host}}/api/{{version}}/users?page=2. Здесь host подтянется из окружения, а version — из настроек коллекции.

Шаг 4: Использование динамических данных В POST запросе на создание пользователя используем {{$randomJobTitle}} для поля вакансии.

Почему это важно для архитектуры тестов

Использование переменных делает ваши тесты переносимыми. Если завтра проект перейдет с версии API v1 на v2, вы измените одну переменную в коллекции, и все 100 запросов обновятся. Если вы захотите запустить тесты на компьютере коллеги, вам достаточно экспортировать коллекцию и окружение — и всё заработает «из коробки», без необходимости править URL или токены.

Если из этой главы запомнить три вещи — это синтаксис {{variable}}, разница между Initial и Current` значениями для безопасности, и мощь окружений для переключения между стендами. В следующей главе мы перейдем к самой интересной части — написанию скриптов, которые будут проверять ответы сервера за нас.

Автоматизация проверок: написание скриптов на вкладке Tests и валидация JSON-ответов

До этого момента мы проверяли ответы сервера глазами: смотрели на статус-код, сверяли данные. Но если у вас десятки запросов, ручная проверка становится невозможной. В Postman есть вкладка Tests, которая позволяет писать небольшие программы на языке JavaScript. Эти программы запускаются автоматически сразу после получения ответа от сервера и говорят нам: «Тест пройден» или «Тест провален».

Как работает вкладка Tests

Вкладка Tests — это песочница, где вам доступен объект pm (Postman). Через него вы можете обращаться к данным ответа, заголовкам и даже времени ожидания.

Стандартный тест в Postman выглядит так:

Если условие внутри функции выполняется, в панели ответа на вкладке Test Results вы увидите зеленый индикатор PASS. Если нет — красный FAIL с описанием ошибки.

> Подсказка: Справа от окна ввода кода есть Snippets (заготовки). Не нужно учить все команды наизусть — просто кликните на нужный сниппет (например, "Status code: Code is 200"), и Postman сам вставит код.

Базовые проверки для QA

Начинающему тестировщику достаточно освоить четыре типа проверок, которые покрывают 80% задач.

1. Проверка статус-кода

Это база. Мы должны убедиться, что сервер ответил именно то, что мы ожидали.

2. Проверка времени ответа

Важно для тестирования производительности (Performance Testing). Если API отвечает дольше секунды, пользователям будет некомфортно.

3. Проверка содержимого JSON (Body)

Чтобы проверить данные внутри ответа, сначала нужно превратить текст ответа в JavaScript-объект.

Здесь pm.expect — это функция-утверждение. Мы говорим: «Я ожидаю, что поле name в ответе будет равно Ivan».

4. Проверка типов данных

Иногда нам не важно конкретное значение, но важно, чтобы поле было строкой или числом.

Работа с массивами и вложенными объектами

Реальные API редко возвращают плоские структуры. Чаще это сложные вложенные объекты. Пример ответа:

Тест для проверки статуса первого заказа:

Обратите внимание на [0] — в программировании отсчет в списках (массивах) начинается с нуля.

Динамические проверки: используем переменные в тестах

Помните, в прошлой статье мы использовали переменные? Их можно и нужно использовать в тестах. Если вы отправили в запросе имя {{randomFirstName}}'); pm.collectionVariables.set("currentName", name); javascript pm.test("Имя в ответе совпадает с отправленным", function () { const expected = pm.collectionVariables.get("currentName"); pm.expect(pm.response.json().name).to.eql(expected); }); javascript pm.test("Успешный логин", () => { pm.response.to.have.status(200); }); javascript pm.test("Токен присутствует в ответе", () => { const data = pm.response.json(); pm.expect(data).to.have.property('token'); pm.expect(data.token).to.be.a('string'); }); javascript if (pm.response.code === 200) { const token = pm.response.json().token; pm.environment.set("auth_token", token); } `

Частые ошибки в скриптах

Забытый парсинг JSON: Попытка обратиться к pm.response.name вместо pm.response.json().name. Помните: pm.response — это весь ответ (с заголовками и кодами), а .json() — это только данные тела.

Ошибки в путях: Если в JSON есть вложенность user -> profile -> email, а вы пишете data.email, тест упадет с ошибкой undefined.

Тесты на "хрупкие" данные: Не проверяйте дату создания или ID, если они меняются при каждом запуске. Проверяйте формат или наличие поля.

Если из этой главы запомнить три вещи — это использование сниппетов для скорости, обязательный парсинг через pm.response.json()` и важность проверки типов данных, а не только значений. В финальной главе мы научимся запускать все наши тесты одной кнопкой и готовиться к вопросам на собеседовании.

Работа с коллекциями, запуск тестов через Runner и подготовка к техническому интервью

Мы прошли путь от понимания того, как работает интернет, до написания кода, который проверяет API автоматически. Теперь пришло время собрать всё воедино. В этой главе мы научимся запускать сотни тестов за один клик и разберем, как отвечать на вопросы интервьюера, чтобы получить оффер на позицию QA.

Коллекции — это больше, чем папки

В Postman Collection — это основа автоматизации. Главная фишка коллекций в том, что вы можете задавать настройки сразу для всех запросов внутри:

Authorization: Вы можете настроить токен на уровне коллекции. Все запросы внутри выберут тип «Inherit auth from parent» и будут использовать этот токен. Обновили токен в папке — он обновился везде.

Scripts: Вы можете написать тест (например, проверку на 200 OK) на уровне всей коллекции. Он будет запускаться автоматически для каждого запроса внутри. Это экономит сотни строк кода.

Collection Runner: запускаем всё и сразу

Когда у вас готова папка с тестами, вы не нажимаете Send для каждого. Вы используете Collection Runner.

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

Выбираете коллекцию и нажимаете Run.

Выбираете окружение (Environment).

Указываете количество итераций (сколько раз прогнать тесты).

Если нужно, загружаете файл с данными (Data File).

После запуска вы увидите отчет: сколько тестов прошло, сколько упало и на каких запросах. Это и есть простейшая автоматизация. Если разработчик что-то сломал в коде, ваш Runner сразу подсветит это красным.

> Кейс для интервью: Если вас спросят, как вы проводите регрессионное тестирование API, отвечайте: «Я организую запросы в коллекции и запускаю их через Collection Runner (или Newman для CI/CD), чтобы быстро проверить, что новые изменения не сломали старый функционал».

Продвинутая автоматизация: Newman

Для работы в реальных проектах тесты должны запускаться сами (например, каждую ночь или при каждом обновлении кода). Для этого используется Newman — это версия Postman для командной строки (консоли). Он позволяет запускать ваши коллекции без открытия графического интерфейса. Это «взрослый» уровень, который очень ценится работодателями.

Подготовка к интервью: типичные вопросы и ответы

Давайте разберем «хиты» технических собеседований для QA по теме API.

Вопрос 1: В чем разница между PUT и PATCH?

Ответ: Оба метода используются для обновления. Но PUT заменяет ресурс целиком (нужно отправить все поля объекта), а PATCH обновляет ресурс частично (отправляем только те поля, которые хотим изменить). PUT идемпотентен, PATCH — не всегда.

Вопрос 2: Что делать, если API возвращает 500 Internal Server Error?

Ответ: Это баг на стороне сервера. Нужно:

Проверить, корректен ли мой запрос (Body, Headers).

Посмотреть логи сервера (если есть доступ).

Завести баг-репорт, приложив туда CURL запроса и тело ответа сервера.

Вопрос 3: Как проверить, что API возвращает правильную схему данных, а не просто значения?

Ответ: В Postman на вкладке Tests можно использовать библиотеку ajv для валидации JSON-схемы. Мы описываем ожидаемую структуру (какие поля обязательны, какие типы данных) и сверяем ответ с этим шаблоном.

Вопрос 4: Зачем нужны переменные окружения?

Ответ: Чтобы не хардкодить (не вписывать вручную) данные, которые меняются. Например, базовый URL для разных стендов (Dev/Prod) или токены авторизации. Это делает тесты гибкими и безопасными.

Стратегия тестирования API (чек-лист для практики)

Когда вам дадут тестовое задание, следуйте этому алгоритму:

Позитивные тесты: Отправляем валидные данные, ожидаем 200/201.

Негативные тесты:

* Пустое тело запроса (ожидаем 400). * Неверный токен (ожидаем 401). * Доступ к чужим данным (ожидаем 403). * Несуществующий ID (ожидаем 404).

Граничные значения: Если поле «возраст» принимает от 18 до 99, проверьте 17, 18, 99 и 100.

Типы данных: Отправьте строку там, где ожидается число.

Финальный совет: как «продать» свои знания

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

Если из этого курса вы запомнили, как отправить запрос, как использовать переменные для разных стендов и как написать базовый скрипт на статус-код — вы уже готовы к своей первой работе в QA. Практикуйтесь на открытых API (например, JSONPlaceholder или ReqRes), собирайте свои коллекции и не бойтесь экспериментировать.