Что такое API?

Что такое Swagger?

Postman: посмотреть, как отправлять запросы, настраивать url, метод, заголовки и тело запроса.

Виды авторизации: API токен, Bearer token, basic auth

Вкладка Tests/Scripts в Postman: как добавить в запрос дополнительную проверку на код ответа, на время ожидания ответа.

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

Как в целом можно тестировать бэк: статья от Ольги Назиной.

Чек-лист из этой статьи перенеси себе в шпаргалку и желательно запомнить несколько пунктов оттуда

Тестовый API https://petstore.swagger.io/

1️⃣ Что такое API 🖥️

Описание:
API (Application Programming Interface) — это контракт, который предоставляет программа.

«Ко мне можно обращаться так и так, я обязуюсь делать то и это».

API включает:

операции, которые можно выполнить
данные на входе
данные на выходе (результат или ошибка)

Пример:
Если переводить на русский — это как договор на покупку машины:

мои обязанности — внести сумму
обязанности продавца — дать машину

Функции API:
API — это набор функций, может быть одна функция или много.

2️⃣ Зачем тестировщику знать API 🔍

Даже если вы тестируете GUI, API всегда есть в системе:

оплата товаров и билетов через платежные системы
система внутри себя общается через API

API позволяет:

проверять логику работы
ускорять тестирование без GUI
локализовать баги быстрее

Пример:
Создание пользователя через Postman вместо ручного заполнения формы — экономит много времени.

3️⃣ Контракт и интерфейс 📝

Контракт API = интерфейс. Пользователь работает с GUI, программа — с API.

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

4️⃣ Вызовы API 🔗

Прямые вызовы:

Система вызывает функции внутри себя
Система вызывает метод другой системы
Человек вызывает метод через Postman
Автотесты дергают методы

Косвенные вызовы:

Пользователь работает через GUI, кнопки вызывают API-функции

5️⃣ Тестирование API ✅

Тестирование API = проверка функциональности через API, чаще Remote API (интеграция двух систем).

Цели:

автотесты на уровне API
интеграционные проверки между системами

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

Postman — создание, отправка, тестирование HTTP-запросов
Swagger — документация и тестирование API
SoapUI — SOAP-сервисы
Fiddler — анализ HTTP-трафика
JMeter — нагрузочное тестирование

7️⃣ Swagger 📄

Swagger — инструмент для:

документирования API
тестирования запросов
генерации клиентского кода

Преимущества:

лёгкость использования
автоматическая генерация документации
поддержка разных языков и открытых стандартов
тестирование и валидация API

8️⃣ HTTP-методы 🌐

POST — создание объекта
GET — получение данных
PUT — редактирование
DELETE — удаление

Пример:

POST /pets
{
  "name": "doggie",
  "status": "available"
}

9️⃣ Postman 🧰

Описание:

Создание коллекций запросов
Тестирование API
Переменные и окружения
Collection Runner
Документирование API

🔟 Скрипты и тесты в Postman 📝

Pre-request Script: выполняется перед запросом
Tests: выполняется после запроса, проверяет ответ

Пример теста:

pm.test("Status is ok", function () {
  pm.response.to.be.ok;
});

1️⃣1️⃣ Переменные ⚙️

Глобальные
Окружений
Коллекции
Локальные
Уровня данных

Использование: {{variable_name}}

Пример:

pm.environment.set("userId", 777);
pm.environment.get("userId");

1️⃣2️⃣ Collection Runner ▶️

Запускает все запросы коллекции или папки
Итерации
Файл данных для разных тестов
Формирует отчет

1️⃣3️⃣ Консоль Postman 🖥️

Отладка скриптов
Лог запросов и ответов

Пример:

console.log(pm.response.json());

1️⃣4️⃣ Практика: создание цепочки запросов 🔄

GET https://postman-echo.com/get?userId=777 → сохранить userId
POST https://postman-echo.com/post с телом:

{"userId": {{userId}}, "username": "Bob"}

Тест на совпадение userId
Проверка схемы JSON через tv4
Запуск через Collection Runner с файлом данных users.json

1️⃣5️⃣ Полезные команды 💻

// Переменные
pm.environment.set("key", "value");
pm.environment.get("key");

// Ассерты
pm.test("value is true", function() {
  pm.expect(true).to.be.true;
});

// GET-запрос
pm.sendRequest("https://postman-echo.com/get", (err, res) => console.log(res));

1️⃣6️⃣ Заключение 🏁

Плюсы Postman:

наглядность
быстрый старт
написание тестов
интеграция с CI через Newman

Минусы:

редактирование коллекций только через Postman
сложности при ревью JSON

Коллекции Postman — живая интерактивная документация, ускоряющая тестирование и разработку.

1️⃣ Введение в тестирование REST API 🛠️

Ручной тестировщик часто пугается API: «Что проверять, как, с чего начать?»
Принцип: тестирование API похоже на GUI — сначала тест-дизайн и проверки, потом технические детали (заголовки, тело, параметры).
Чек-лист: помогает систематически проверять функционал, ничего не упустить.
Практика будет на методе doRegister системы Users.

2️⃣ Общий чек-лист проверок ✅

Основные категории:

Тело запроса: соответствует примеру и ТЗ
Бизнес-логика: позитивные и негативные сценарии
Параметры: обязательность, корректность, работа разных значений
Перестановка элементов: заголовки, тело
Регистрозависимость: заголовки и тело
Ошибки: не well formed XML / JSON

Где искать параметры:

URL
Заголовки
Тело запроса
Комбинации

3️⃣ Тестирование параметров 🧩

Проверки для каждого параметра:

Корректный параметр (по примеру или документации)
Обязательность (что если параметр не передан?)
Бизнес-логика (например, проверка валидных/невалидных комбинаций)
Регистрозависимость (для текстовых параметров)
Перестановка параметров (влияет ли порядок на работу метода)

Принцип: тестируем параметры REST так же, как GUI-поля формы.

4️⃣ Тестирование заголовков 📬

Заголовки из документации должны работать
Проверка обязательности заголовка (что если не передан)
Проверка неправильных значений (текст ошибки)
Позитивные тесты по документации
Регистронезависимость заголовков

5️⃣ Проверка ответа API 📡

Основное, что проверяем:

Status Code: соответствует документации
Body:

Все поля ответа
Значения в полях
Сообщения об ошибках

Сравнения:

Поля с ТЗ
Поля между SOAP и REST

6️⃣ Позитивное vs негативное тестирование 🌈⚠️

Начинаем с позитивного теста: работает система при нормальных данных
Негативное тестирование иногда важнее (интеграция с внешними системами)

Проверяем, чтобы сообщения об ошибках были понятны пользователю
Сокращаем обращения в техподдержку

7️⃣ Порядок тестирования ⏱️

Примеры из ТЗ → проверяем, что метод работает
Основной позитивный сценарий → проверяем рабочую цепочку
Альтернативные сценарии → дополнительные условия
Негативные сценарии → проверка ошибок и нестандартных данных
Проверка параметров, заголовков, тела, URL и типа метода

8️⃣ Практика: Users — doRegister 👩‍💻

Пример запроса:

{
  "email": "milli@mail.ru",
  "name": "Машенька",
  "password": "1"
}

Тип запроса: POST
URL: http://users.bugred.ru/tasks/rest/doregister
Если пример не уникален → редактируем данные

С Postman (динамический email и имя):

{
  "email": "milli{{$randomInt}}@mail.ru",
  "name": "Машенька{{$randomInt}}",
  "password": "1"
}

9️⃣ Проверка основного позитивного сценария 🎯

Проверяем, что пользователь реально создан: GUI → поиск пользователя
Проверяем поля: email, автор, дата изменения
Проверяем авторизацию: данные работают → регистрация успешна

🔟 Альтернативные сценарии 🔄

Дополнительные условия из ТЗ:

Автор через REST или SOAP
Изменение полей возможно только через соответствующий метод

Проверяем GUI и SOAP UI, чтобы убедиться, что ограничения соблюдаются
Маленькие баги: например, регистр автора не совпадает с ТЗ → фиксируем или обновляем документацию

1️⃣1️⃣ Негативные сценарии ❌

Проверка сообщений об ошибках
Сначала бизнес-логика, потом API (well-formed JSON/XML)
Примеры проверки уникальности:

Дубликат имени, уникальный email
Дубликат email, уникальное имя
Дубликаты сразу email + имя

Цель: понять, что ошибка понятна, статус-код корректный

1️⃣2️⃣ Параметры запроса ✍️

Проверка обязательности
Перестановка элементов
Бизнес-логика: если параметры изменены, система корректно реагирует

Принцип: тестируем REST-поля так же, как GUI-поля формы

1️⃣3️⃣ Email: тестовые проверки 📧

Корректный email → позитивный тест
Верхний регистр, цифры → TEST77@mail9.ru
С дефисами, подчеркиваниями, точками
Некорректные:

без точек в домене
превышение длины (>320 символов)
отсутствие @
пробелы в имени и домене
пустое имя пользователя или домена
некорректный TLD

1️⃣4️⃣ Name: тестовые проверки 🏷️

Простая строка
Разный регистр, спецсимволы
Максимальная длина: 1 000 / 1 000 000 символов
Проверка отображения в GUI после запроса
Проверяем позитивные сценарии

1️⃣5️⃣ Password: тестовые проверки 🔑

Простой пароль → позитивный тест
Разные регистры, спецсимволы
Длинные значения → проверяем верхние границы
Проверка отображения и функциональности GUI

1️⃣6️⃣ Остальные тесты 🧪

Перестановка мест слагаемых (тело, заголовки)
Регистрозависимость
Проверка well-formed XML/JSON

Принцип: API-тестирование проверяет все особенности работы метода, а GUI помогает визуально убедиться, что данные корректно обработаны.

1️⃣ Тестирование заголовков (Headers) 📬

1.1 Основная идея

Заголовки должны обрабатываться либо на сервере, либо на клиенте.
Если заголовок никем не обрабатывается → лишний трафик, который не нужен.
Принцип: меньшее зло — либо заголовок используется, либо не нужен.

1.2 Поведение при отсутствии заголовка

Используется дефолтное значение (в коде разработчика)
Заголовок не нужен (например, Postman может сам подставлять hidden-headers)
Язык (Accept-Language) важен, иначе сервер может вернуть данные не на том языке

⚠️ Пример: если разработчик зашил русский язык по умолчанию, даже Accept-Language: en-USможет вернуть русский.

1.3 Возможные сценарии

Заголовок не передан:

выдаёт ошибку → понятно ли пользователю, что делать
применяет поведение по умолчанию

Заголовок передан:

верное значение → OK
неверное значение → сообщение об ошибке

1.4 Регистронезависимость

Заголовки должны быть регистронезависимы по спецификации
Примеры:

Accept: application/json
Accept: APPLICATION/JSON
ACCEPT: application/json
ACCEPT: APPLICATION/JSON
ACcePT: APPlicATIon/JSon

⚠️ Проверка нужна, т.к. разработчик должен прописать это в коде.

1.5 Подводные камни

Прокси (например, Nginx) может менять регистр заголовков → система должна корректно обрабатывать
Hidden-headers в Postman → не тестируем, отправляем запрос чистым curl

1.6 Практика (Users API)

Если удалить все заголовки → doRegister работает
Проверяем без hidden-заголовков

2️⃣ Тестирование тела запроса (Body) 📝

2.1 Основные проверки

Правильное тело (по примеру ТЗ)
Различные параметры:

обязательность
работа параметров

Бизнес-логика
Ошибки в бизнес-логике
Перестановка мест слагаемых
Регистрозависимость
Ошибки: не well formed JSON / XML

2.2 Перестановка мест слагаемых 🔀

API передает пары «ключ:значение», порядок не должен влиять
Проверяем, что система читает по названию ключа
В GUI переставить поля нельзя → только в API

Пример JSON:

{
    "name": "Машенька{{$randomInt}}",
    "email": "test{{$randomInt}}@mail.com",
    "password": "1"
}

Переставляем поля → должно работать одинаково

2.3 Регистрозависимость 🔠

Названия ключей чувствительны к регистру (например, NAME вместо name → ошибка)
В Users: регистрозависимость есть → критично для тестирования

2.4 Well formed JSON ✅❌

Правила:

Пары «ключ:значение»
Данные разделены запятыми
Объект в {}
Массив в []

Ошибки:

Лишняя запятая после последней пары

{
  "email": "test@mail.com",
  "name": "Машенька",
  "password": "1",
}

Не пары ключ:значение

{
  "email": "test@mail.com",
  "name": "Машенька",
  "password"
}

Данные без запятых

{
  "email": "test@mail.com"
  "name": "Машенька"
  "password": "1"
}

Объект в квадратных скобках

[
  "email": "test@mail.com",
  "name": "Машенька",
  "password": "1"
]

Ожидаемый результат: 400 Bad Request + сообщение "Не well formed JSON"

3️⃣ Тестирование параметров в URL 🌐

3.1 Общие принципы

GET-параметры тестируем как body
Проверяем:

корректное значение
обязательность
бизнес-логику
регистрозависимость (для текстовых параметров)

3.2 Практика (Jira Cloud API)

Метод: GET /rest/api/3/issue/{issueIdOrKey}
Параметры: id или key (13005 / TEST-1)

Тесты:

Правильное значение → базовый позитивный тест
Не передан параметр → проверка обязательности
Разные состояния объекта:

свежесозданная
несколько раз изменённая
минимально / максимально заполненная
закрытая / удалённая / несуществующая

Регистрозависимость ключа (для issue key):

/rest/api/3/issue/test-1
/rest/api/3/issue/TEst-1

Цифры регистронезависимы, буквы — тестируем

1️⃣ Тип метода (HTTP Method) ⚡

1.1 Основная идея

Проверяем, как система реагирует на “подмену” метода:

POST → GET (совсем разные)
POST → PUT (похожие)

Возможные реакции:

Система отрабатывает как будто всё нормально
Выдаёт понятную ошибку

⚠️ Хорошая практика — ловить “неправильные” методы сразу, особенно при интеграции, чтобы потом обновления релиза не тормозились.

1.2 Практика (Users API)

POST → GET → успешно
POST → PUT → проверить корректность ответа
Вывод: иногда API “терпимо” к методу, но это нужно фиксировать для надёжности.

2️⃣ Тело ответа (Response Body) 📦

2.1 Чек-лист проверки

Поля: какие вернулись, сравнить с ТЗ
Значения: соответствие ожидаемым
Текст ошибок: читаемость, информативность

2.2 Сравнение SOAP и REST

Если есть оба интерфейса, проверить идентичность:

Пустые поля могут различаться (SOAP возвращает все, REST — только заполненные)
SOAP использует WSDL для обязательных полей
REST может придерживаться “минимальных чернил”

2.3 Особенности проверки

Отсутствие данных на входе (поле не пришло / пустое)
Пустые поля на выходе → проверяем, соответствует ли документации

2.4 Практика (Users API)

Базовый запрос → REST и SOAP
Различие: SOAP возвращает все поля, REST — только основные
Проверяем бизнес-логику один раз → API-проверка идентична

3️⃣ Перестановка полей и регистрозависимость 🔀🔠

3.1 Перестановка мест слагаемых

В REST: порядок ключей не должен влиять → проверка “ключ:значение”
В SOAP: проверка на порядковые номера тегов

Пример: name и email поменяли → SOAP выдал некорректный email → баг

3.2 Регистрозависимость тегов (XML)

Открывающий и закрывающий теги должны совпадать по регистру
Пример:

<EMAIL>ggg55555@mail.com</EMAIL>  → работает
<EMAIL>ggg55555@mail.com</email>  → Bad Request

3.3 Well-formed XML

Пример ошибки:

<wrap:doRegister>
  <email>ggg5555@mail.com</email
  <name>Имечко 666</name>
  <password>1</password>
</wrap:doRegister>

Ответ: <faultcode>SOAP-ENV:Client</faultcode><faultstring>Bad Request</faultstring>
🔹 Идея: проверяем адекватность ошибки при некорректной структуре

4️⃣ Статус-коды HTTP 🟢🔴

4.1 Основная схема

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

4.2 Возможные “нестандартные” коды

Например:

570 — пустой ответ на поиск
571 — найден один ФЛ
572 — несколько ИП

Разработчик может даже перекрывать стандартные:

400 → Internal Server Error

⚠️ Проверяем статус-код всегда:

Хороший запрос → 200
Плохой запрос → 4xx/5xx (не 200!)

4.3 Практика (Users API)

Хороший запрос → 200 OK
Плохой запрос → 200 с ошибкой в теле → баг

🔹 Итоговый чек-лист проверки `doRegister`

В первую очередь проверяем бизнес-логику, затем API-аспекты: регистрозависимость, перестановку параметров, корректность JSON/XML, тип метода.

1️⃣ Базовый тест (Пример из ТЗ)

Тело запроса:

{
  "email": "milli{{$randomInt}}@mail.ru",
  "name": "Машенька{{$randomInt}}",
  "password": "1"
}

Ожидаемый результат:

Статус: 200 OK
Поля ответа:

name: отправленное имя
avatar: стандартная аватарка
password: хэш пароля
birthday: 0
email: отправленный email
gender: ""
date_start: 0
hobby: ""

Дополнительно:

Пользователь появился в списке (проверка через GUI)
Можно войти под этим пользователем (email + пароль)

2️⃣ Бизнес-логика из ТЗ

6️⃣ Тело запроса (Body)

6.1 Перестановка мест параметров

JSON:

{
  "name": "Машенька{{$randomInt}}",
  "email": "test{{$randomInt}}@mail.com",
  "password": "1"
}

✅ Статус 200, корректный ответ

Form-data → также статус 200

6.2 Регистрозависимость

{
  "email": "test{{$randomInt}}@mail.com",
  "NAME": "Машенька{{$randomInt}}",
  "password": "1"
}

✅ Статус 200, корректный ответ

6.3 Подмена метода

POST → GET
❌ Статус 400, ошибка «Неправильный тип метода, нужно использовать POST»

7️⃣ Вывод

Тестирование API ≈ тестированию GUI, но с доп. возможностями:

Менять порядок полей
Менять имена ключей
Проверять разные типы методов
Ломать JSON/XML

Всегда начинаем с бизнес-логики (проверка по ТЗ, классы эквивалентности, граничные значения)
Добавляем API-часть:

Перестановка параметров JSON и Form-data
Регистрозависимость
Другой тип метода
Проверка well-formed JSON/XML

не забудь заглянуть сюда

https://youtu.be/M1kwub3H0AI?si=CvHAxad7bDq8Cnrd

и почитать вот тут:

https://habr.com/ru/companies/vk/articles/750096

1️⃣ Что такое API 🖥️

2️⃣ Зачем тестировщику знать API 🔍

3️⃣ Контракт и интерфейс 📝

4️⃣ Вызовы API 🔗

5️⃣ Тестирование API ✅

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

7️⃣ Swagger 📄

8️⃣ HTTP-методы 🌐

9️⃣ Postman 🧰

🔟 Скрипты и тесты в Postman 📝

1️⃣1️⃣ Переменные ⚙️

1️⃣2️⃣ Collection Runner ▶️

1️⃣3️⃣ Консоль Postman 🖥️

1️⃣4️⃣ Практика: создание цепочки запросов 🔄

1️⃣5️⃣ Полезные команды 💻

1️⃣6️⃣ Заключение 🏁

1️⃣ Введение в тестирование REST API 🛠️

2️⃣ Общий чек-лист проверок ✅

3️⃣ Тестирование параметров 🧩

4️⃣ Тестирование заголовков 📬

5️⃣ Проверка ответа API 📡

6️⃣ Позитивное vs негативное тестирование 🌈⚠️

7️⃣ Порядок тестирования ⏱️

8️⃣ Практика: Users — doRegister 👩‍💻

9️⃣ Проверка основного позитивного сценария 🎯

🔟 Альтернативные сценарии 🔄

1️⃣1️⃣ Негативные сценарии ❌

1️⃣2️⃣ Параметры запроса ✍️

1️⃣3️⃣ Email: тестовые проверки 📧

1️⃣4️⃣ Name: тестовые проверки 🏷️

1️⃣5️⃣ Password: тестовые проверки 🔑

1️⃣6️⃣ Остальные тесты 🧪

1️⃣ Тестирование заголовков (Headers) 📬

1.1 Основная идея

1.2 Поведение при отсутствии заголовка

1.3 Возможные сценарии

1.4 Регистронезависимость

1.5 Подводные камни

1.6 Практика (Users API)

2️⃣ Тестирование тела запроса (Body) 📝

2.1 Основные проверки

2.2 Перестановка мест слагаемых 🔀

2.3 Регистрозависимость 🔠

2.4 Well formed JSON ✅❌

3️⃣ Тестирование параметров в URL 🌐

3.1 Общие принципы

3.2 Практика (Jira Cloud API)

1️⃣ Тип метода (HTTP Method) ⚡

1.1 Основная идея

1.2 Практика (Users API)

2️⃣ Тело ответа (Response Body) 📦

2.1 Чек-лист проверки

2.2 Сравнение SOAP и REST

2.3 Особенности проверки

2.4 Практика (Users API)

3️⃣ Перестановка полей и регистрозависимость 🔀🔠

3.1 Перестановка мест слагаемых

3.2 Регистрозависимость тегов (XML)

3.3 Well-formed XML

4️⃣ Статус-коды HTTP 🟢🔴

4.1 Основная схема

4.2 Возможные “нестандартные” коды

4.3 Практика (Users API)

🔹 Итоговый чек-лист проверки doRegister

1️⃣ Базовый тест (Пример из ТЗ)

6️⃣ Тело запроса (Body)

6.1 Перестановка мест параметров

6.2 Регистрозависимость

6.3 Подмена метода

7️⃣ Вывод

🔹 Итоговый чек-лист проверки `doRegister`