Майя

Страна для удаленщиков, любителей Азии

2025-12-23T13:26:02.148Z

Визы, документы.

🇮🇩 Индонезия — официально

Visitor Visa / e-VOA (туризм, временное пребывание)

Тип визы: e-VOA / VOA (Visitor Visa)
Въезд: single-entry
Срок: 30 дней + 1 продление ещё на 30 (итого до 60)
Стоимость: IDR 500,000
Удалённая работа: ❌ формально запрещена (серое использование на практике)
Перевыпуск: после выезда можно оформить снова, лимита «X раз в год» нет, но частые въезды = риск отказа
Оверстей: IDR 1,000,000 за каждый день + депортация при серьёзном нарушении

Официальные источники

Гос. визовый портал Индонезии (e-Visa / e-VOA):
https://evisa.imigrasi.go.id/front/info/evoa
Иммиграционная служба Индонезии:
https://imigrasi.go.id

Может быть продлен каждый раз на 60 дней (2 месяца) до максимального общего срока пребывания 180 дней (6 месяцев).

Required Documents

Scanned copies of:

passport or valid travel document;
letter of guarantee from the same sponsor submitted when applying for the visa (if using a sponsor);
statement letter explaining the purpose and intention of staying in Indonesia.

Fees

ITK for 30 days: Rp500,000 per application
ITK for 60 days: Rp2,000,000 per application
ITK for 180 days: Rp6,000,000 per application

долгую визу сложнее получать так как надо регистрировать там свою компанию

🇻🇳 Вьетнам — официально

e-Visa (туризм / краткосрочное пребывание)

Тип визы: e-Visa
Въезд: single или multiple
Срок: до 90 дней
Стоимость:

$25 — single
$50 — multiple

Удалённая работа: ❌ формально запрещена
Перевыпуск: можно подавать повторно после выезда
Оверстей: штрафы + возможная депортация, санкции ужесточаются

Безвизовый въезд для РФ

Срок: до 45 дней
Продление: ❌ нельзя

Официальные источники

Посольство Вьетнама в РФ — безвиз:
https://vnembassy-moscow.mofa.gov.vn/ru-ru/Consular%20Services/Visa%20Exemption/Pages/default.aspx
Официальный e-Visa портал правительства Вьетнама:
https://evisa.gov.vn

🇹🇭 Таиланд — официально

Visa Exemption (без визы)

Для граждан РФ: да
Срок: до 60 дней
Ограничение: не более 90 дней в течение 6 месяцев
Удалённая работа: ❌ формально запрещена
Оверстей: 500 THB/день, максимум 20,000 THB

Tourist Visa (TR)

Въезд: single / multiple
Стоимость:

2,000 THB — single
5,000 THB — multiple

Перевыпуск: возможен, но частые визы → вопросы на границе

Destination Thailand Visa (DTV) — лучший вариант под удалёнку

Тип: long-stay / workcation
Удалённая работа: ✅ разрешена при работе на иностранного работодателя
Срок: долгосрочный (зависит от категории)

Официальные источники

Посольство Таиланда в Москве — визы:
https://moscow.thaiembassy.org/en/publicservice/98912-general-visa-information
Посольство Таиланда (пример виз TR):
https://rtehanoi.thaiembassy.org/th/publicservice/25691-tourist-visa

2. Условия получения туристической визы

2.1 Туристическая виза действительна в течение 3 месяцев с даты выдачи. Путешественники должны въехать в страну в течение указанного 3-месячного периода.

2.2 Путешественникам будет разрешено оставаться до 60 дней, считая с даты въезда. Продление пребывания возможно еще на 30 дней, при этом максимальный срок пребывания составляет 90 дней, считая с даты въезда. Путешественники должны связаться с Управлением Иммиграционного бюро (http://www.immigration.go.th) для получения дополнительной информации. Продление визы осуществляется исключительно по усмотрению сотрудника иммиграционной службы.

2.3 Если владелец туристической визы нарушает условия въезда (например, если он/она занимается деятельностью, связанной с работой), разрешение на пребывание будет аннулировано, и ему/ей будет запрещено въезжать в Таиланд в будущем.

3. Необходимые документы для подачи заявления на получение туристической визы

3.1 Паспорт или проездной документ со сроком действия не менее 6 месяцев

3.2 Одна заполненная визовая анкета

3.3 Одна (01) недавняя фотография (размер 3,5 x 4,5 см.) прикрепляется к форме заявления на визу

3.4 Доказательства транспортировки

Маршрут полета для билета туда и ОБРАТНО (на тайском или английском языках)
В бронировании/маршрута должно быть указано полное имя заявителя, дата и время прибытия и вылета, а также данные о рейсе

(2) Заявитель, проживающий в арендованном жилье:

Копия договора аренды
Копия регистрации дома (если таковая есть)
Копия владельца дома и удостоверения личности арендодателя (для граждан Таиланда) или паспорта и разрешения на работу (для иностранцев) арендодателя

🇵🇭 Филиппины — официально

Безвизовый въезд

Для РФ: да
Срок: 30 дней
Удалённая работа: ❌ формально запрещена

Продление пребывания (ключевая фишка Филиппин)

Продления: 29 дней → 1 / 2 / 6 месяцев
Максимум: до 36 месяцев без выезда
Перевыпуск: не нужен — всё продлевается внутри страны
Оверстей: штраф от PHP 500/месяц + обязательная легализация

Официальные источники

Посольство Филиппин (консульский раздел):
https://philippines.mid.ru/en/consular-services/

ТУРИСТИЧЕСКАЯ ВИЗА

Требования:

Заявление (заполненное на https://visa.kdmid.ru/ и распечатанное) с подписью Заявителя и фотографией (3,5x4,5);
Паспорт, действительный не менее 6 месяцев с даты истечения срока действия визы;
Ваучер и подтверждение от авторизованного российского туристического агентства;
Вид на жительство / долгосрочная виза (или другая), подтверждающая право на пребывание в Республике Филиппины на срок более 180 дней - если заявитель не является гражданином Республики Филиппины.

🇯🇵 Япония — официально

Short-Term Stay Visa (single-entry)

Тип: краткосрочная виза
Срок: до 90 дней
Стоимость для РФ: 0 (по взаимности)
Удалённая работа: ❌ строго запрещена
Перевыпуск: возможен, но частые поездки = высокий риск отказа
Оверстей: до 3 лет тюрьмы или штраф до 3 млн иен + бан

Официальные источники

МИД Японии — визы для граждан РФ:
https://www.mofa.go.jp/j_info/visit/visa/short/russia.html

список документів по ссыпке https://www.ru.emb-japan.go.jp/itpr_ja/tourism2022.html

Брокер сообщений, логи

2025-10-20T08:57:42.280Z

📩 Что такое брокер сообщений и для чего он нужен?

Брокер сообщений — это компонент архитектуры, который выступает посредником между различными частями системы. Он помогает системам обмениваться данными, снимая нагрузку с веб-сервисов, так как им не нужно напрямую пересылать сообщения друг другу.

В брокере сообщений есть две ключевые роли:

Producer (издатель) 📝 — создаёт и отправляет сообщения.
Consumer (потребитель/подписчик) 📥 — получает и обрабатывает сообщения.

Сообщения могут передаваться двумя способами:

Прямо от отправителя к получателю — каждое сообщение используется только один раз.
Схема публикации/подписки (Pub/Sub) 🔄 — продюсер публикует сообщение в топик, а все подписчики получают его. Так можно строить распределение задач между подписчиками, где каждый получает только свои сообщения.

⚡ Преимущества брокеров сообщений перед API:

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

❌ Недостатки:

Усложнение архитектуры.
Возможные проблемы с консистентностью данных.
Отладка распределённой системы сложнее.

🛠 Когда полезны:

Долгие и ресурсоёмкие задачи.
Микросервисы для координации сервисов через топики.
Мобильные приложения с push-уведомлениями.
Транзакционные системы с последовательными этапами обработки.

🏭 Apache Kafka: продюсеры, брокеры, консумеры

Как устроен Kafka

Producer 📝 — приложение, отправляющее сообщения в кластер Kafka.
Broker 💻 — сервер, который хранит данные и распределяет их между консумерами.
Consumer 📥 — приложение, читающее сообщения из Kafka.

Kafka работает через логи 📜 — упорядоченные по времени записи событий. Каждое событие добавляется в конец лога и остаётся неизменным.

Топики, партиции и сегменты

Топик 🗂 — логическая группа сообщений (например, статусы заказов).
Партиции 🔹 — деление топика на части для масштабирования. Каждая партиция — строго упорядоченный лог.
Сегменты 📄 — файлы на диске, в которых хранятся сообщения партиций.

Каждое сообщение имеет offset — порядковый номер. Партиции могут реплицироваться для отказоустойчивости.

Продюсеры и партицирование

Продюсер сам выбирает, в какую партицию писать сообщение:

По ключу (hash-based) 🔑 — гарантирует порядок сообщений для одного ключа.
Round-robin 🔄 — равномерное распределение сообщений без гарантии порядка.

Семантики доставки сообщений

At-most-once ❌ — можно потерять сообщения, но дубликатов нет.
At-least-once ✅ — сообщения не теряются, но возможны дубликаты.
Exactly-once 🎯 — каждое сообщение доставлено ровно один раз.

Консумеры и консумер-группы

Consumer 📥 — читает сообщения из партиций.
Consumer group 👥 — несколько консумеров читают партиции кооперативно.
Heartbeat и session timeout ⏱ — проверка живости консумеров.
Ребалансировка 🔄 — перераспределение партиций при добавлении/удалении консумеров.

📝 Логи: что это и зачем смотреть

Что такое логи

Логи — это записи событий и сообщений системы. Они помогают понять, что происходит внутри приложения.

Когда смотреть логи

Тестирование новой функциональности 🧪
Регрессионное тестирование 🔄
Проверка взаимодействия с внешними системами 🌐
Отладка ошибок 🐞
Оценка производительности ⚡

Уровни логирования

FATAL 💀 — критическая ошибка, ведущая к завершению программы.
ERROR ❌ — ошибка, требующая вмешательства.
WARN ⚠️ — предупреждение о потенциальной проблеме.
INFO ℹ️ — информация о ходе работы.
DEBUG 🐛 — подробные данные для отладки.
TRACE 🔍 — максимально подробная информация, шаги выполнения.

Виды логов

Application logs 🖥 — события внутри приложения.
Server logs 🖧 — ошибки и запросы на сервере.

Error logs ❌
Access logs 🔑

System logs ⚙️ — работа ОС и системные события.

Что хранится в логах

Время и дата события 🕒
Уровень логирования
Контекст системы или модуля 🏷
Текст сообщения
Стек вызовов при ошибках 🧾

🔧 Инструменты для просмотра логов

Lens 👓 — визуализация логов.
Grafana Loki 📊 — мониторинг и поиск по логам в реальном времени.

Почитай тут https://habr.com/ru/companies/yandex_praktikum/articles/739058/

А посмотри вот здесь:
https://youtu.be/keBrfAhFiP4?si=PCnASeFENyotAuDn

Базы данных

2025-10-20T08:35:53.125Z

🔹 Реляционные базы данных (RDB)

1️⃣ Что такое реляционная база данных

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

3️⃣ Первичный и внешний ключи

Первичный ключ (Primary Key)

Уникальный идентификатор записи.
Не может быть NULL.
Обеспечивает однозначную идентификацию строки.

Внешний ключ (Foreign Key)

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

Родительский ключ (Parent Key)

Первичный ключ, на который ссылается внешний ключ.

5️⃣ Нормализация

Разделение таблицы на несколько, чтобы:

Исключить дублирование данных
Присвоить уникальные ключи для каждой записи
Обновления происходили только один раз

Нормальные формы: 1NF → 2NF → 3NF → … → 6NF

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

🔹 SQL (Structured Query Language)

1️⃣ Определение

SQL — язык для работы с реляционными базами данных.
Позволяет:

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

Важно: SQL — декларативный язык: вы описываете, что хотите получить, а не как это реализовать.

3️⃣ Основные операции SQL

INSERT — добавить запись
UPDATE — изменить запись
DELETE — удалить запись
SELECT — выбрать данные
ORDER BY — сортировка
DISTINCT — уникальные значения
COUNT, SUM — агрегатные функции
LIMIT — ограничение числа результатов
JOIN — объединение таблиц

4️⃣ Примеры запросов

4.1 Таблица Users

-- Вывести всех пользователей с именем "Олег", сортировка по id
SELECT * FROM Users
WHERE name = 'Олег'
ORDER BY id;

4.2 Таблица Orders

-- Посчитать количество заказов с оплатой "online"
SELECT COUNT(*) FROM Orders
WHERE payment = 'online';

4.3 JOIN с условиями

-- Выбрать все заказы пользователей из города "Saratov"
-- Вариант с JOIN
SELECT o.*
FROM Orders o
JOIN Users u ON o.user_id = u.id
WHERE u.city = 'Saratov';

-- Вариант с вложенным SELECT
SELECT * FROM Orders
WHERE user_id IN (
    SELECT id FROM Users WHERE city = 'Saratov'
);

4.4 Соединение трёх таблиц

SELECT *
FROM Orders o
JOIN Users u ON o.user_id = u.id
JOIN Products p ON o.product_id = p.id;

5️⃣ Практика

Использовать Postman, DBeaver или аналогичные инструменты.
Создать локальную БД и таблицы Users и Orders, заполнить тестовыми данными.
Пробовать все виды запросов, включая JOIN, агрегатные функции и фильтры.

Посмотри еще тут

https://youtu.be/k8jXX7E_Wkg?si=LJBwHKevI4a314es

Тут инфа по тренажерам

https://habr.com/ru/articles/943924/

HTTP-запросы

2025-10-20T08:25:40.638Z

🔹 HTTP-запросы: структура, методы, коды состояния

1️⃣ Базовые понятия HTTP

HTTP (HyperText Transfer Protocol) — протокол прикладного уровня для передачи гипертекста и доступа к ресурсам веба.
Участники:

Клиент — запрашивает ресурс.
Сервер — обрабатывает запрос и возвращает ресурс.

Порт по умолчанию: 80 (HTTP), 443 (HTTPS).
Спецификация: RFC 2616. Популярные версии: HTTP/1.1 и HTTP/2.

2️⃣ HTTP-сообщения

Типы:

Запросы (Request) — от клиента к серверу для получения ресурса или выполнения действия.
Ответы (Response) — от сервера клиенту, содержат результат обработки запроса.

Структура:

Стартовая строка — метод, URL, версия протокола.
HTTP-заголовки — метаданные запроса/ответа.
Пустая строка — разделитель метаданных и тела.
Тело сообщения (опционально) — данные запроса или документа.

3️⃣ Стартовая строка запроса

Состоит из:

Метод (GET, POST, PUT, DELETE и др.)
URL (Scheme, Host, Port, Path, Query String)
Версия протокола (HTTP/1.1, HTTP/2)

Пример:

GET /index.html HTTP/1.1

4️⃣ Методы HTTP

GET — получить ресурс.
POST — отправить данные на сервер.
PUT — обновить ресурс.
DELETE — удалить ресурс.
HEAD, OPTIONS, PATCH — вспомогательные методы.

Примечание: Некоторые методы могут иметь тело запроса (POST, PUT), другие — нет (GET, DELETE).

5️⃣ URL-компоненты

Scheme — протокол (http://, https://)
Host — доменное имя или IP
Port — номер порта (по умолчанию для http 80, https 443)
Path — путь к ресурсу (например /index.html)
Query String — параметры запроса (?param=value&param2=value2)

Обязательные: Scheme + Host. Остальные опциональны.

7️⃣ HTTP-заголовки

Формат: Имя-Заголовок: Значение
Регистрозависимость: нет, но принято начинать каждое слово с заглавной буквы.

8️⃣ Тело запроса

Обязательное только для методов, которые отправляют данные (POST, PUT).
Отсутствует у GET, DELETE, HEAD, OPTIONS.

9️⃣ HTTP-ответы

Структура: аналогична запросу — стартовая строка (status line), заголовки, тело.

Строка статуса

Содержит:

Версию протокола
Код состояния (HTTP status code)
Текстовое пояснение к коду

Коды состояния

1xx — информационные
2xx — успех (200 OK, 201 Created)
3xx — редирект
4xx — ошибка клиента (400 Bad Request, 404 Not Found)
5xx — ошибка сервера (500 Internal Server Error)

10️⃣ Заголовки ответа

Формат: Имя: Значение
Назначение: уточнение ответа, не влияет на тело.

11️⃣ Тело ответа

Необязательное.
Присутствует для большинства ответов (HTML, JSON, XML).
Отсутствует для 201 Created, 204 No Content.

12️⃣ Безопасность: HTTP vs HTTPS

HTTP — данные передаются в открытом виде.
HTTPS — данные шифруются, используется порт 443, защищает учетные данные пользователей.

13️⃣ Практика: как отправить HTTP-запрос

Инструменты:

Инструменты разработчика в браузере (F12 / Ctrl+Shift+I)

Вкладка Network показывает все запросы, метод, URL и статус.

cURL — командная утилита для отправки запросов:curl -v https://selectel.ru/blog

🔹 Идемпотентность в API

1️⃣ Определение

Идемпотентность — повторение действия не изменяет результат после первого выполнения.
Позволяет избежать дублирования и непредсказуемых результатов при сетевых сбоях.

2️⃣ Примеры

Пицца:

orders = {}

def place_order(order_id, pizza):
    if order_id in orders:
        return "Заказ уже существует."
    orders[order_id] = pizza
    return "Заказ успешно создан."

first_try = place_order("123", "Пепперони")
second_try = place_order("123", "Пепперони")
print(first_try)  # Заказ успешно создан.
print(second_try) # Заказ уже существует.

Повторный запрос не создаёт дубликат заказа.

3️⃣ Идемпотентные методы HTTP

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

Любой повторный запрос не изменяет состояние сервера более одного раза.

4️⃣ Ключ идемпотентности

Уникальный идентификатор операции (например UUID).
Система распознает повторные запросы и не выполняет их снова.
Пример: перевод денег, где повторный запрос не создает двойной перевод.

5️⃣ Плюсы и минусы

Плюсы:

Надежность и стабильность системы
Предсказуемость действий
Упрощение разработки и тестирования

Минусы:

Требует дополнительного проектирования
Может ограничивать некоторые сценарии бизнес-логики

6️⃣ Вывод

HTTP — расширяемый протокол прикладного уровня для веба.
HTTPS обеспечивает безопасную передачу данных.
Идемпотентность — ключ к надежности API и предотвращению дублирования действий.

Еще посмотри тут:

https://youtu.be/OyfroULbRN4?si=u1IhOAgFGL1f66G5

и почитать тут https://habr.com/ru/articles/739166/

Тестирование бэка: Swagger. Postman

2025-10-20T08:12:25.564Z

Что такое 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

Тестирование бэка: Swagger. Postman

2025-10-20T08:12:20.810Z

Что такое API?

Что такое Swagger?

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

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

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

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

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

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

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

Создать коллекцию запросов в Postman, в которой ты сначала создаешь питомца, потом проверяешь его успешное создание GET-запросом, потом изменяешь его, опять проверяешь изменение гетом, потом удаляешь и проверяешь, что он удалился.
То есть итоговая коллекция должна содержать 6 запросов.

Добавь в каждый запрос любой дополнительный тест во вкладке Tests/Scripts или сгенерируй тесты автоматически через функцию "Generate tests" в меню коллекции.

Получившуюся коллекцию экспортируй в JSON-файл и прикрепи в эту таску

UPD: Перед экспортом коллекции нужно жмякнуть кнопку "SAVE" во всех запросах по отдельности, иначе есть риск, что они экспортируются не доделанные

UPD2: Перед экспортом коллекции запусти полностью всю коллекцию по нажатию кнопки "Run collection". Все запросы должны возвращать код 200 кроме последнего GET-запроса (он должен возвращать 404). Если у тебя получились другие коды ответа, то это значит, что где-то ошибка

Слово «API» мелькает в вакансиях даже для начинающих тестировщиков. То REST API, то SOAP API, то просто API. Что же это за зверь такой? Давайте разбираться!

— А зачем это мне? Я вообще-то web тестирую! Вот если пойду в автоматизацию, тогда да… Ну, еще это в enterprise тестируют, я слышал…

А вот и нет! Про API полезно знать любому тестировщику. Потому что по нему системы взаимодействуют между собой. И это взаимодействие вы видите каждый день даже на самых простых и захудалых сайтах.

Любая оплата идет через API платежной системы. Купил билет в кино? Маечку в онлайн-магазине? Книжку? Как только жмешь «оплатить», сайт соединяет тебя с платежной системой.

Но даже если у вас нет интеграции с другими системами, у вас всё равно есть API! Потому что система внутри себя тоже общается по api. И пока фронт-разработчик усиленно пилит GUI (графический интерфейс), вы можете:

скучать в ожидании;
проверять логику работы по API

Конечно, я за второй вариант! Так что давайте разбираться, что же такое API. Можно посмотреть видео на youtube, или прочитать дальше в виде статьи.

Что такое API

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

Если переводить на русский, это было бы слово «договор». Договор между двумя сторонами, как договор на покупку машины:

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

Перевести можно, да. Но никто так не делает ¯\_(ツ)_/¯

Все используют слово «контракт». Так принято. К тому же это слово входит в название стиля разработки:

Code first — сначала пишем код, потом по нему генерируем контракт
Contract first — сначала создаем контракт, потом по нему пишем или генерируем код (в этой статье я буду говорить именно об этом стиле)

Мы же не говорим «контракт на продажу машины»? Вот и разработчики не говорят «договор». Негласное соглашение.

API — набор функций

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

Соответственно, API отвечает на вопрос “Как ко мне, к моей системе можно обратиться?”, и включает в себя:

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

Тут вы можете мне сказать:

— Хмм, погоди. Операция, данные на входе, данные на выходе — как-то всё это очень сильно похоже на описание функции!

Если вы когда-то сталкивались с разработкой или просто изучали язык программирования, вы наверняка знаете, что такое функция. Фактически у нас есть данные на входе, есть данные на выходе, и некая магия, которая преобразует одно в другое.

И да! Вы будете правы в том, что определения похожи. Почему? Да потому что API — это набор функций. Это может быть одна функция, а может быть много.

Как составляется набор функций

Да без разницы как. Как разработчик захочет, так и сгруппирует. Например, можно группировать API по функционалу. То есть:

отдельно API для входа в систему, где будет регистрация и авторизация;
отдельно API для отчетности — отчет 1, отчет 2, отчет 3… отчет N. Для разных отчетов у нас разные формулы = разные функции. И все мы их собираем в один набор, api для отчетности.
отдельно API платежек — для работы с каждым банком своя функция.
...

Можно не группировать вообще, а делать одно общее API.

Можно сделать одно общее API, а остальные «под заказ». Если у вас коробочный продукт, то в него обычно входит набор стандартных функций. А любые хотелки заказчиков выносятся отдельно.

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

И конечно, функции можно переиспользовать. То есть одну и ту же функцию можно включать в разные наборы, в разные апи. Никто этого не запрещает.

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

При чем тут слово «интерфейс»

— Минуточку, Оля! Ты же сама выше писала, что API — это Application programming interface. Почему ты тогда говоришь о контракте, хотя там слово интерфейс?

Да потому, что в программировании контракт — это и есть интерфейс. В классическом описании ООП (объектно-ориентированного программирования) есть 3 кита:

Инкапсуляция
Наследование
Полиморфизм

Инкапсуляция — это когда мы скрываем реализацию. Для пользователя все легко и понятно. Нажал на кнопочку — получил отчет. А как это работает изнутри — ему все равно. Какая база данных скрыта под капотом? Oracle? MySQL? На каком языке программирования написана программа? Как именно организован код? Не суть. Программа предоставляет интерфейс, им он и пользуется.

Не всегда программа предоставляет именно графический интерфейс. Это может быть SOAP, REST интерфейс, или другое API. Чтобы использовать этот интерфейс, вы должны понимать:

что подать на вход;
что получается на выходе;
какие исключения нужно обработать.

Пользователи работают с GUI — graphical user interface. Программы работают с API — Application programming interface. Им не нужна графика, только контракт.

Как вызывается API

Вызвать апи можно как напрямую, так и косвенно.

Напрямую:

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

Косвенно:

Пользователь работает с GUI

Вызов API напрямую

1. Система вызывает функции внутри себя

Разные части программы как-то общаются между собой. Они делают это на программном уровне, то есть на уровне API!

Это самый «простой» в использовании способ, потому что автор API, которое вызывается — разработчик. И он же его потребитель! А значит, проблемы с неактуальной документацией нет =)

Шучу, проблемы с документацией есть всегда. Просто в этом случае в качестве документации будут комментарии в коде. А они, увы, тоже бывают неактуальны. Или разработчики разные, или один, но уже забыл, как делал исходное api и как оно должно работать…

2. Система вызывает метод другой системы

А вот это типичный кейс, которые тестируют тестировщики в интеграторах. Или тестировщики, которые проверяют интеграцию своей системы с чужой.

Одна система дергает через api какой-то метод другой системы. Она может попытаться получить данные из другой системы. Или наоборот, отправить данные в эту систему.

Допустим, я решила подключить подсказки из Дадаты к своему интернет-магазинчику, чтобы пользователь легко ввел адрес доставки.

Я подключаю подсказки по API. И теперь, когда пользователь начинает вводить адрес на моем сайте, он видит подсказки из Дадаты. Как это получается:

Он вводит букву на моем сайтеМой сайт отправляет запрос в подсказки Дадаты по APIДадата возвращает ответМой сайт его обрабатывает и отображает результат пользователю
Вон сколько шагов получилось! И так на каждый введенный символ. Пользователь не видит этого взаимодействия, но оно есть.

И, конечно, не забываем про кейс, когда мы разрабатываем именно API-метод. Который только через SOAP и можно вызвать, в интерфейсе его нигде нет. Что Заказчик заказал, то мы и сделали ¯\_(ツ)_/¯

Пример можно посмотреть в Users. Метод MagicSearch создан на основе реальных событий. Хотя надо признать, в оригинале логика еще замудренее была, я то под свой сайт подстраивала.

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

Функционал супер-поиска доступен только по API, пользователь в интерфейсе его никак не пощупает.

В этом случае у вас обычно есть ТЗ, согласно которому работает API-метод. Ваша задача — проверить его. Типичная задача тестировщика, просто добавьте к стандартным тестам на тест-дизайн особенности тестирования API, и дело в шляпе!

(что именно надо тестировать в API — я расскажу отдельной статьей чуть позднее)

3. Человек вызывает метод

Причины разные:

Для ускорения работы
Для локализации бага (проблема где? На сервере или клиенте?)
Для проверки логики без докруток фронта

Если система предоставляет API, обычно проще дернуть его, чем делать то же самое через графический интерфейс. Тем более что вызов API можно сохранить в инструменте. Один раз сохранил — на любой базе применяешь, пусть даже она по 10 раз в день чистится.

Для примера снова идем в Users. Если мы хотим создать пользователя, надо заполнить уйму полей!

Конечно, это можно сделать с помощью специальных плагинов типа Form Filler. Но что, если вам нужны адекватные тестовые данные под вашу систему? И на русском языке?

Заполнение полей вручную — грустно и уныло! А уж если это надо повторять каждую неделю или день на чистой тестовой базе — вообще кошмар. Это сразу первый приоритет на автоматизацию рутинных действий.

И в данном случае роль автоматизатора выполняет… Postman. Пользователя можно создать через REST-запрос CreateUser. Один раз прописали нормальные “как настоящие” данные, каждый раз пользуемся. Профит!

Вместо ручного заполнения формы (1 минута бездумного заполнения полей значениями «лпрулпк») получаем 1 секунду нажатия на кнопку «Send». При этом значения будут намного адекватнее.

А еще в постмане можно сделать отдельную папку подготовки тестовой базы, напихать туда десяток запросов. И вот уже на любой базе за пару секунд вы получаете столько данных, сколько вручную вбивали бы часами!

Если вы нашли баг и не понимаете, на кого его вешать — разработчика front-end или back-end, уберите все лишнее. Вызовите метод без графического интерфейса. А еще вы можете тестировать логику программы, пока интерфейс не готов или сломан.

4. Автотесты дергают методы

Есть типичная пирамида автоматизации:

GUI-тесты — честный тест, «как это делал бы пользователь».
API-тесты — опускаемся на уровень ниже, выкидывая лишнее.
Unit-тесты — тесты на отдельную функцию

Слово API как бы намекает на то, что будет использовано в тестах ツ

Допустим, у нас есть:

операция: загрузка отчета; на входе: данные из ручных или автоматических корректировок или из каких-то других мест; на выходе: отчет, построенный по неким правилам
Правила построения отчета:

Ячейка 1: Х — YЯчейка 2: Z * 6...

GUI-тесты — честный тест, робот делает все, что делал бы пользователь. Открывает браузер, тыкает на кнопочки… Но если что-то упадет, будете долго разбираться, где именно.

API-тесты — все то же самое, только без браузера. Мы просто подаем данные на вход и проверяем данные на выходе. Например, можно внести итоговый ответ в эксельку, и пусть робот выверяет ее, правильно ли заполняются данные? Локализовать проблему становится проще.

Unit-тесты — это когда мы проверяем каждую функцию отдельно. Отдельно смотрим расчет для ячейки 1, отдельно — для ячейки 2, и так далее. Такие тесты шустрее всего гоняются и баги по ним легко локализовать.

Косвенный вызов API

Когда пользователь работает с GUI, на самом деле он тоже работает с API. Просто не знает об этом, ему это просто не нужно.

То есть когда пользователь открывает систему и пытается загрузить отчет, ему не важно, как работает система, какой там magic внутри. У него есть кнопочка «загрузить отчет», на которую он и нажимает. Пользователь работает через GUI (графический пользовательский интерфейс).

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

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

И вот уже пользователь видит перед собой готовый отчет. Он вызвал сложное API, даже не подозревая об этом!

Что значит «Тестирование API»

В первую очередь, мы подразумеваем тестирование ЧЕРЕЗ API. «Тестирование API» — общеупотребимый термин, так действительно говорят, но технически термин некорректен. Мы не тестируем API, мы не тестируем GUI (графический интерфейс). Мы тестируем какую-то функциональность через графический или программный интерфейс.

Но это устоявшееся выражение. Можно использовать его и говорить “тестирование API”. И когда мы про это говорим, мы имеем в виду:

автотесты на уровне API
или интеграцию между двумя разными системами.

Интеграция — когда одна система общается с другой по какому-то протоколу передачи данных. Это называется Remote API, то есть общение по сети, по некоему протоколу (HTTP, JMS и т.д.). В противовес ему есть еще Local API (он же «Shared memory API») — это то API, по которому программа общается сама с собой или общается с другой программой внутри одной виртуальной памяти.

Когда мы говорим про тестирование API, чаще всего мы подразумеваем тестирование Remote API. Когда у нас есть две системы, находящихся на разных компьютерах, которые как-то между собой общаются.

И если вы видите в вакансии «тестирование API», скорее всего это подразумевает умение вызвать SOAP или REST сервис и протестировать его. Хотя всегда стоит уточнить!

Резюме

Контракт включает в себя:

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

Вызвать API можно как напрямую, так и косвенно:

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

Когда говорят про API с тестировщиком, обсуждают два варианта:

автотесты на уровне API (умение автоматизировать)
интеграцию между двумя разными системами (обычно SOAP или REST, то есть работу в SOAP Ui или Postman).

Тестируем с помощью Swagger

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

Наиболее популярные и эффективные инструменты для тестирования API:

Postman — это инструмент для тестирования API, позволяющий создавать, отправлять и тестировать HTTP-запросы и проверять ответы на них.
Swagger — это инструмент для документирования и тестирования API, позволяющий автоматически создавать документацию API из описания структуры API в формате YAML или JSON файла.
SoapUI — это инструмент для тестирования веб-сервисов, позволяющий создавать и выполнять тесты на протоколе SOAP.

Fiddler — это инструмент для анализа и отладки HTTP-трафика между веб-браузером и веб-сервером. С точки зрения тестирования API Fiddler позволяет перехватывать, анализировать и модифицировать HTTP-запросы и ответы, передаваемые между клиентом и сервером. Это позволяет тестировщикам осуществлять валидацию запросов и ответов, проверять правильность передачи параметров, куки и другие элементы запросов, отслеживать проблемы с трафиком, а также выявлять и локализовать проблемы с API.
JMeter — это инструмент для тестирования производительности и функциональности программного обеспечения, который может использоваться для тестирования API. С точки зрения тестирования API, JMeter является инструментом, позволяющим создавать запросы к API, анализировать ответы и оценивать производительность и функциональность API. JMeter может использоваться для создания нагрузки на API, чтобы измерить производительность, время ответа и другие метрики, которые помогут обнаружить ошибки в API и улучшить его производительность и функциональность.

Вышеперечисленные инструменты позволяют тестировщикам эффективно и быстро проверять API на разных этапах разработки, чтобы обеспечить его соответствие требованиям и качеству.

В данной публикации рассмотрим подробнее Swagger, позволяющий создавать, документировать и тестировать API. С помощью Swagger можно узнать доступные эндпоинты, параметры запросов и формат ответов.

О Swagger

Swagger разработан компанией Reverb Technologies, основанной в 2010 году в Миннеаполисе, США. Основателями компании были Тони Тамбурино (Tony Tambourine), Райан Дювелл (Ryan Duell) и Ник Селлер (Nick Sutterer).

Swagger создан в целях облегчения работы разработчиков API и обеспечения большего взаимодействия между разработчиками и потребителями API. В 2015 году Swagger был перенесен в сообщество OpenAPI Initiative, которое является частью Linux Foundation, где его разработка и поддержка продолжаются по сей день.

Преимущества и особенности Swagger:

Легкость использования: Swagger имеет простой и легкий интерфейс, позволяющий разработчикам быстро и легко создавать и документировать API.
Автоматическое поколение документации: Swagger позволяет автоматически создавать документацию для API с использованием стандарта OpenAPI. Это позволяет потребителям API быстро и легко понять, как взаимодействовать с API и использовать его функциональность.
Поддержка различных языков программирования: Swagger поддерживает многие языки программирования, что позволяет разработчикам использовать его для документирования API на любом языке программирования.
Поддержка открытых стандартов: Swagger основан на стандартах OpenAPI, которые поддерживаются большим количеством инструментов и платформ, что позволяет разработчикам использовать его с любым другим инструментом или платформой, поддерживающими стандарты OpenAPI.
Тестирование и валидация API: Swagger позволяет разработчикам тестировать и валидировать API, обеспечивая большую надежность и качество работы API.
Расширяемость Swagger имеет открытый код и активное сообщество разработчиков, что позволяет им расширять и настраивать его под свои нужды.

Для каждого из методов HTTP Swagger позволяет описать параметры запросов и формат ответов.

Например, для метода GET можно описать параметры запросов, такие как query string parameters, headers, или path parameters, и формат ответа, такой как JSON или XML. Аналогично Swagger позволяет описывать параметры и формат ответов для методов POST, PUT и DELETE. Это обеспечивает понятность и консистентность описания API и позволяет разработчикам эффективно использовать API в своих приложениях.

Примеры описания параметров запросов и формат ответов можно найти здесь.

рПримеры методов

POST метод (создание объекта):

Результат после отправки запроса:

GET метод (получение данных):

PUT метод (редактирование данных):

Результат после отправки запроса:

Метод DELETE (удаление объекта):

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

Полезные материалы:

Официальная документация Swagger: на сайте Swagger есть подробная документация с описанием различных функций и возможностей.
Swagger Editor: это бесплатный онлайн-редактор Swagger, позволяющий создавать, редактировать и проверять файл Swagger в режиме реального времени.
SwaggerHub: это интерактивная среда Swagger, которая позволяет создавать, документировать и публиковать свои API, а также общаться с другими разработчиками API.
Swagger UI: это интерактивный пользовательский интерфейс, который позволяет тестировать API непосредственно из браузера. Вы можете выполнять запросы API и просматривать ответы в разных форматах.
Swagger Codegen: это инструмент, позволяющий сгенерировать клиентский код для вашего API на основе файла Swagger. Вы можете выбрать язык программирования и тип клиента для создания кода, который соответствует вашим потребностям.

“Разработка API сложна, Postman делает её лёгкой” © Postdot Technologies, Inc

Когда видишь описание инструментов Postman — захватывает дух, просыпается чувство всевластия над своим будущим детищем. Кажется, что и взрощенные в прошлом "монстры" наконец-то падут перед тобой!

В этой статье мы расскажем о Postman и попробуем написать свой первый скрипт.

Postman

Основное предназначение приложения — создание коллекций с запросами к вашему API. Любой разработчик или тестировщик, открыв коллекцию, сможет с лёгкостью разобраться в работе вашего сервиса. Ко всему прочему, Postman позволяет проектировать дизайн API и создавать на его основе Mock-сервер. Вашим разработчикам больше нет необходимости тратить время на создание "заглушек". Реализацию сервера и клиента можно запустить одновременно. Тестировщики могут писать тесты и производить автоматизированное тестирование прямо из Postman. А инструменты для автоматического документирования по описаниям из ваших коллекций сэкономят время на ещё одну "полезную фичу". Есть кое-что и для администраторов — авторы предусмотрели возможность создания коллекций для мониторинга сервисов.

Введение

1 — коллекция, 2 — папка, 3 — запрос

Главные понятия, которыми оперирует Postman это Collection (коллекция) на верхнем уровне, и Request (запрос) на нижнем. Вся работа начинается с коллекции и сводится к описанию вашего API с помощью запросов. Давайте рассмотрим подробнее всё по порядку.

Collection

Коллекция — отправная точка для нового API. Можно рассматривать коллекцию, как файл проекта. Коллекция объединяет в себе все связанные запросы. Обычно API описывается в одной коллекции, но если вы желаете, то нет никаких ограничений сделать по-другому. Коллекция может иметь свои скрипты и переменные, которые мы рассмотрим позже.

Folder

Папка — используется для объединения запросов в одну группу внутри коллекции. К примеру, вы можете создать папку для первой версии своего API — "v1", а внутри сгруппировать запросы по смыслу выполняемых действий — "Order & Checkout", "User profile" и т. п. Всё ограничивается лишь вашей фантазией и потребностями. Папка, как и коллекция может иметь свои скрипты, но не переменные.

Request

Запрос — основная составляющая коллекции, то ради чего все и затевалось. Запрос создается в конструкторе. Конструктор запросов это главное пространство, с которым вам придётся работать. Postman умеет выполнять запросы с помощью всех стандартных HTTP методов, все параметры запроса под вашим контролем. Вы с лёгкостью можете поменять или добавить необходимые вам заголовки, cookie, и тело запроса. У запроса есть свои скрипты. Обратите внимание на вкладки "Pre-request Script" и "Tests" среди параметров запроса. Они позволяют добавить скрипты перед выполнением запроса и после. Именно эти две возможности делают Postman мощным инструментом помогающим при разработке и тестировании.

1 — вкладки с запросами, 2 — URL и метод, 3 — параметры запроса, 4 — параметры ответа

Скрипты

"Postman Sandbox" это среда исполнения JavaScript доступная при написании "Pre-request Script" и "Tests" скриптов. "Pre-request Script" используется для проведения необходимых операций перед запросом, например, можно сделать запрос к другой системе и использовать результат его выполнения в основном запросе. "Tests" используется для написания тестов, проверки результатов, и при необходимости их сохранения в переменные.

Последовательность выполнения запроса (из оф. документации)

Помимо скриптов на уровне запроса, мы можем создавать скрипты на уровне папки, и, даже, на уровне коллекции. Они называются также — "Pre-request Script" и "Tests", но их отличие в том, что они будут выполняться перед каждым и после каждого запроса в папке, или, как вы могли догадаться, во всей коллекции.

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

Переменные

Postman имеет несколько пространств и областей видимости для переменных:

Глобальные переменные
Переменные коллекции
Переменные окружения
Локальные переменные
Переменные уровня данных

Глобальные переменные и переменные окружения можно создать, если нажать на шестеренку в правом верхнем углу программы. Они существуют отдельно от коллекций. Переменные уровня коллекции создаются непосредственно при редактировании параметров коллекции, а локальные переменные из выполняемых скриптов. Также существуют переменные уровня данных, но они доступны только из Runner, о котором мы поговорим позже.

Приоритет пространств переменных (из оф. документации)

Особенностью переменных в Postman является то, что вы можете вставлять их в конструкторе запроса, в URL, в POST параметры, в Cookie, всюду, используя фигурные скобки в качестве плейсхолдера для подстановки.

{{domain}} и {{slack_incoming_webhook}} — переменные окружения DNS Checker будут заменены на значения во время выполнения запроса

Из скриптов переменные тоже доступны, но получить их поможет вызов стандартного метода встроенной библиотеки pm:

// получить глобальную переменнуюpm.globals.get("variable_key");// получить переменную из окруженияpm.environment.get("variable_key");// получить переменную из любого пространства согласно приоритетуpm.variables.get("variable_key");

Collection Runner

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

// Следующим выполнится запрос с названием "Create order",postman.setNextRequest('Create order');

После выполнения всех запросов формируется отчет, который покажет количество успешных и провальных проверок из скриптов "Tests".

Collection Runner

Console

Пользуйтесь консолью для отладки ваших скриптов, и просмотра дополнительной информации по запросам. Консоль работает, как во время запуска одного запроса, так и во время запуска пакета запросов через Runner. Чтобы её открыть, найдите иконку консоли в нижнем левом углу основного экрана приложения:

Практика

Так как создание коллекций и запросов в конструкторе не должно вызвать затруднений, практическую часть посвятим написанию скриптов, и рассмотрим как создать цепочку запросов с тестами. Перед началом создайте новую коллекцию, назовите её “Habra”, затем создайте новое окружение под названием "Habra.Env"

Шаг 1

Создайте новый запрос, в качестве URL укажите https://postman-echo.com/get?userId=777, а метод оставьте GET. Здесь и далее для простоты и удобства мы будем использовать echo-сервер любезно предоставленный разработчиками Postman. Сохраните запрос в коллекцию "Habra" и назовите “Get user id”, он будет имитировать получение идентификатора пользователя от сервера. Перейдите на вкладку "Tests" и напишите следующий код:

// Тестируем статус ответа и форматpm.test("Status is ok, response is json", function () {    pm.response.to.be.ok; // проверка статуса    pm.response.to.be.json; // проверка формата});try {    // сохраняем userId из json ответа в переменную окружения    pm.environment.set("userId", pm.response.json().args.userId);} catch(e) {    // выводим исключение в консоль    console.log(e);}

С помощью этого скрипта мы проверили статус и формат ответа, а также сохранили полученный из ответа идентификатор пользователя в переменную окружения для последующего использования в других запросах. Чтобы проверить работу нашего теста, запустите запрос. В панели информации об ответе, во вкладке "Tests" вы должны увидеть зелёный лейбл “PASS”, а рядом надпись “Status is ok, response is json”.

Шаг 2

Теперь давайте попробуем вставить идентификатор нашего пользователя в json запрос. Создайте новый запрос, в качестве URL укажите https://postman-echo.com/post, выберите метод POST, установите тип для тела запроса raw — application/json, а в само тело вставьте:

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

Сохраните запрос в нашу коллекцию, и назовите "Update username", он будет запрашивать импровизированную конечную точку для обновления username пользователя. Теперь при вызове запроса вместо {{userId}} система автоматически будет подставлять значение из переменной окружения. Давайте проверим, что это действительно так, и напишем небольшой тест для нашего нового запроса:

// тестируем статус ответа и форматpm.test("Status is ok, response is json", function () {    pm.response.to.be.ok;    pm.response.to.be.json;});// проверим, что userId из окружения равен userId из ответаpm.test("userId from env is equal to userId from response", function () {    pm.expect(parseInt(pm.environment.get("userId"))).to.equal(        pm.response.json().data.userId    );});

В нашем новом тесте мы сравниваем полученный от сервера userId с тем, что хранится у нас в переменной окружения, они должны совпадать. Запустите запрос и убедитесь, что тесты прошли. Хорошо, двигаемся дальше.

Шаг 3

Вы могли заметить, что два тестовых скрипта имеют одинаковую проверку формата и статуса:

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

Пока мы не зашли слишком далеко, давайте исправим эту ситуацию и перенесем эти тесты на уровень коллекции. Откройте редактирование нашей коллекции, и перенесите проверку формата и статуса во вкладку "Tests", а из запросов их можно удалить. Теперь эти проверки будут автоматически вызываться перед скриптами "Tests" для каждого запроса в коллекции. Таким образом мы избавились от копирования данной проверки в каждый запрос.

Шаг 4

Мы научились записывать и получать переменные окружения, настало время перейти к чему-то потяжелее. Давайте воспользуемся встроенной библиотекой tv4 (TinyValidator) и попробуем проверить правильность схемы json объекта. Создайте новый запрос, в качестве URL используйте https://postman-echo.com/post, установите метод в значение POST, для тела запроса укажите raw — application/json, и вставьте в него:

{    "profile" : {        "userId": {{userId}},        "username": "Bob",        "scores": [1, 2, 3, 4, 5],        "age": 21,        "rating": {"min": 20, "max": 100}    }}

После запуска запроса echo-сервер должен вернуть нам нашу json модель в качестве ответа в поле "data", таким образом мы имитируем работу реального сервера, который мог бы прислать нам информацию о профиле Боба. Модель готова, напишем тест, проверяющий правильность схемы:

// получаем профиль из ответаvar profile = pm.response.json().data.profile;// описываем схему моделиvar scheme = {    // указываем тип объекта    "type": "object",    // указываем обязательные свойства    "required": ["userId", "username"],    // описываем свойства    "properties": {        "userId": {"type": "integer"},        "username": {"type": "string"},        "age": {"type": "integer"},        // описываем массив        "scores": {            "type": "array",            // тип элементов            "items": {"type": "integer"}        },        // описываем вложенный объект        "rating": {            "type": "object",            "properties": {                "min": {"type": "integer"},                "max": {"type": "integer"}            }        }    }};pm.test('Schema is valid', function() {    // валидируем объект profile с помощью правил из scheme    var isValidScheme = tv4.validate(profile, scheme, true, true);    // ожидаем, что результат валидации true    pm.expect(isValidScheme).to.be.true;});

Готово, мы провалидировали схему объекта profile. Запустите запрос и убедитесь, что тесты проходят.

Шаг 5

У нас получился небольшой путь из 3-х запросов и нескольких тестов. Настало время полностью его протестировать. Но перед этим, давайте внесем небольшую модификацию в наш первый запрос: замените значение “777” в URL на плейсхолдер “{{newUserId}}”, и через интерфейс добавьте в окружение "Habra.Env" переменную “newUserId” со значением “777”. Создайте файл users.json на своём компьютере и поместите туда следующий json массив:

[    {"newUserId": 100},    {"newUserId": 200},    {"newUserId": 300},    {"newUserId": 50000}]

Теперь запустим Runner. В качестве "Collection Folder" выберем "Habra". В качестве "Environment" поставим "Habra.Env". Количество итераций оставляем 0, а в поле "Data" выбираем наш файл users.json. По этому файлу "Collection Runner" поймет, что ему нужно совершить 4 итерации, и в каждой итерации он заменит значение переменной "newUserId" значением из массива в файле. Если указать количество итераций больше, чем количество элементов в массиве, то все последующие итерации будут происходить с последним значением из массива данных. В нашем случае после 4 итерации значение "newUserId" всегда будет равно 50000. Наш “Data” файл поможет пройти весь наш путь с разными newUserId, и убедиться, что независимо от пользователя все выполняется стабильно.

Запускаем наши тесты нажатием "Run Habra". Поздравляем вы успешно создали коллекцию и протестировали наш импровизированный путь с помощью автотестов!

Тестирование коллекции "Habra"

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

Отдельно хочу отметить, что в реальном проекте мы не держим все запросы в корне коллекции, а стараемся раскладывать их по папкам. Например, в папке "Requests" мы складываем все возможные запросы описывающие наш API, а тесты храним в отдельной папке "Tests". И когда нам нужно протестировать проект, в "Runner" запускаем только папочку "Tests".

Коллекция, окружение и данные из примера

Полезно знать

В завершении приведем основные команды, которые вам могут понадобиться во время написания скриптов. Для лучшего усвоения, попробуйте поиграться с ними самостоятельно.

Установка и получение переменных

// глобальные переменныеpm.globals.set(“key”, “value”);pm.globals.get(“key”);// переменные окруженияpm.environment.set(“key”, “value”);pm.environment.get(“key”);// локальные переменныеpm.variables.set(“key”, “value”);pm.variables.get(“key”); // если нет локальной, будет искать на уровне выше

Тестирование или asserts

// с использованием анонимной функции и специальных assert конструкцийpm.test(“Название теста”, function () {    pm.response.to.be.success;    pm.expect(“value”).to.be.true;    pm.expect(“other”).to.equal(“other”);});// с использованием простого условия и массива teststests[“Название теста”] = (“a” != “b”);tests[“Название теста 2”] = true;

Создание запросов

// пример get запросаpm.sendRequest(“https://postman-echo.com/get”, function (err, res) {    console.log(err);    console.log(res);});// пример post запросаlet data = {    url: “https://postman-echo.com/post”,    method: “POST”,    body: { mode: “raw”, raw: JSON.stringify({ key: “value” })}};pm.sendRequest(data, function (err, res) {    console.log(err);    console.log(res);});

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

pm.response.json(); // в виде jsonpm.response.text(); // в виде строкиresponseBody; // в виде строки

Ответ доступен только во вкладке “Tests”

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

Документация регламентирует наличие некоторого количества встроенных библиотек, среди которых — tv4 для валидации json, xml2js конвертер xml в json, crypto-js для работы с шифрованием, atob, btoa и др.

// подключение xml2jsvar xml2js = require(“xml2js”);// преобразование простого xml в json объектxml2js.parseString("<root>Hello xml2js!</root>", function(err, res) {    console.log(res);});

Некоторые из библиотек, например, как tv4 не требуют прямого подключения через require и доступны по имени сразу.

Получение информации о текущем скрипте

pm.info.eventName; // вернет test или prerequest в зависимости от контекстаpm.info.iteration; // текущая итерация в Runnerpm.info.iterationCount; // общее количество итерацийpm.info.requestName; // название текущего запросаpm.info.requestId; // внутренний идентификатор запроса

Управление последовательностью запросов из скрипта

Стоит отметить, что данный метод работает только в режиме запуска всех скриптов.

// установить следующий запросpostman.setNextRequest(“Название запроса”); // по названиюpostman.setNextRequest(ID); // по идентификатору// остановить выполнение запросовpostman.setNextRequest(null);

После перехода на следующий запрос Postman возвращается к линейному последовательному выполнению запросов.

Создание глобального хелпера

В некоторых случаях вам захочется создать функции, которые должны быть доступны во всех запросах. Для этого в первом запросе в секции “Pre-request Script” напишите следующий код:

// создаем и сохраняем хелпер для глобального использованияpm.environment.set("pmHelper", function pmHelper() {    let helpers = {};    helpers.usefulMethod = function() {        console.log(“It is helper, bro!”);    };    return helpers;} + '; pmHelper();');

А в последующих скриптах пользуемся им так:

// получаем объектvar pmHelper = eval(pm.environment.get("pmHelper"));// вызываем наш методpmHelper.usefulMethod();

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

Заключение

Основные плюсы, которые подтолкнули нас к использованию Postman в своём проекте:

Наглядность – все запросы всегда под рукой, мануальное тестирование во время разработки становится легче
Быстрый старт – вовлечение нового игрока в команду, будь то программист или тестировщик, проходит легко и быстро
Тесты – возможность писать тесты для запросов, а потом быстро составлять из них, как из пазлов, различные варианты и пути жизни приложения
Поддержка CI — возможность интегрировать тесты в CI с помощью newman (об этом будет отдельная статья)

Среди минусов можно выделить:

Редактирование коллекции привязано к Postman, т. е. для изменений потребуется сделать импорт, отредактировать, а затем сделать экспорт в репозиторий проекта
Так как коллекция лежит в одном большом json файле, Review изменений практически невозможно

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

P.S.:
Основной функционал Postman бесплатен и удовлетворяет ежедневным нуждам, но есть некоторые инструменты с рядом ограничений в бесплатной версии:

Postman API – позволяет получать доступ к данным вашего аккаунта, добавлять, удалять и обновлять коллекции, запросы, и другую информацию программно, напрямую через API. Вы можете обратиться к нему 1000 раз в месяц.
Mock сервер – позволяет развернуть заглушки для вашего API на серверах разработчиков Postman. Доступно 1000 запросов в месяц.
Api Monitoring – позволяет создавать коллекции для мониторинга и запуска их по расписанию с серверов разработчика Postman. Система мониторинга сделает для вас не больше 1000 запросов в месяц
Api Documentation – позволяет публиковать автоматически сгенерированную документацию на серверах приложения Postman. Ограничение 1000 просмотров в месяц

Как тестировать методы REST API

Когда ручного тестировщика впервые просишь проверить метод REST API, того охватывает паника: «Как это делать? Я вообще почти ничего не знаю про API. Что делать? Как это тестировать?»

Спокойно. Без паники =) Я уже рассказывала на простом языке, что такое API. А сегодня я расскажу о том, как его тестировать. На самом деле почти также, как GUI: в первую очередь это тест-дизайн и придумывание проверок, а потом уже всякие API-штучки. Но и про них не стоит забывать.

Я дам вам чек-лист, к которому вы сможете обращаться потом — «так, это проверил, и это, и это. А вот это забыл, пойду посмотрю!». А потом мы обсудим каждый пункт — зачем это проверять и как.

После теории будет практика! Для неё возьмем метод doRegister системы Users — он находится в открытом доступе, можете дергать по ходу чтения и проверять =)

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

Общий чек-лист:

Правильное тело (пример)
Бизнес-логика: позитив, негатив
Различные параметры (обязательность, работа параметров)
Перестановка мест слагаемых (заголовки, тело)
Регистрозависимость (заголовки, тело)
Ошибки: не well formed xml / json

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

В URL
В заголовках
В теле запроса
Комбинация

Тестирование параметров:

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

То есть берём REST-часть и обычную, применяем тест-дизайн, словно это параметр в графическом интерфейсе.

Тестирование заголовков:

Заголовки из документации работают (в целом)
А если какой-то не передать? (обязательность)
А если передать, но неправильно? (текст ошибки)
Позитивные тесты по доке
Регистронезависимость заголовков

Что смотрим в ответе:

Status Code
Body

В теле смотрим:

Какие поля вернулись в ответе?
Значения в полях
Текст ошибок

Поля в ответе нужно:

сравнить с ТЗ
сравнить между собой SOAP \ REST

Кратко прошлись, теперь разберемся в деталях и с примерами.

Содержание

Что тестируем в запросе

Что тестируем в ответе

Позитив или негатив?

Я учу начинающих тестировщиков так: ВСЕГДА сначала позитивное тестирование, а потом негативное. Иначе вы успеете проверить всякий треш, а с нормальными данными система работать не будет.

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

Сначала надо проверить негатив. Потому что разработчики продукта, которые подключают наше API, всегда будут напарываться на грабли. Не прочитали документацию / прочитали криво — получили ошибку.И нужно, чтобы по сообщению об ошибке они поняли:— Что они сделали не так— Как это исправитьЭто нужно для того, чтобы уменьшить количество обращений в тех. поддержку.Так что проверьте сначала всякие извращения, а потом, пока разработчик чинит найденные баги, сидите со своими позитивными тестами и позитивными сценариями.

В целом, есть логика в его словах. Ну и плюс всё зависит от времени, если вам позитивные тесты погонять займет полчасика, то проще начать с них. А если там куча сценариев + обязательные автотесты часа на 4, то можно сначала погонять руками, выдать пачку замечаний и сидеть спокойно писать свои тесты.

Обсудите со своими разработчиками, как им будет удобнее — чтобы вы сначала потыкали “на слом” и прислали очевидные баги, или вдумчиво проверили всё и прислали результат одним файлом. Как им удобнее, так и делайте.

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

В каком порядке тестируем

1. Примеры в ТЗ

Самое простое, что можно сделать — дернуть пример из документации, чтобы посмотреть, как метод вообще работает. А потом уже писать обвязку в коде.

Это пойдут делать тестировщики, получив от вас новый функционал. И это же сделает разработчик интеграции / другой пользователь API.

Отсюда вытекают следующие выводы:

а) Примеры в документации должны быть! Причем желательно не один, а на каждый интересный кейс. Чтобы на него точно обратили внимание!

б) Примеры тестируем в первую очередь, потому что именно их дернут первыми. И потом будут делать по аналогии.

Практика на примере Users

В Users есть только один пример:

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

Его и попробуем отправить!

Тип запроса — POST
URL — http://users.bugred.ru/tasks/rest/doregister
Тело — из примера

Упс, ошибочка… Читаем её внимательно:

" email milli@mail.ru уже есть в базе"

В целом логично, раз метод создает нового пользователя, может быть ограничение уникальности. Смотрим в ТЗ, и правда:

Имя и емейл должны быть уникальными

Значит, метод не идемпотентный… Нельзя просто взять пример из ТЗ и отправить не глядя.

СправкаМетод HTTP является идемпотентным, если повторный идентичный запрос, сделанный один или несколько раз подряд, имеет один и тот же эффект, не изменяющий состояние сервера. Корректно реализованные методы GET, HEAD, PUT и DELETE идемпотентны, но не метод POST. © developer.mozilla.org

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

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

А можно использовать функционал Postman, который позволяет указать рандомные значения — динамические переменные. Пожалуй, мне хватит $randomInt. Но так как я отправляю запрос в JSON-формате, то надо обернуть переменную в фигурные скобки, иначе постман считает её как простой текст:

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

Сработало!

См также: Как понять, что мы отправляли, какую переменную?

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

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

И чем больше у вас пользователей, тем больше таких вопросов будет. Заводить ли тут баг на правку документации? Можно предложить дописать в ТЗ как-то так:

Запрос (для проверки запроса исправьте имя пользователя и email, чтобы они были уникальными): ...

То есть заранее подсказываем, что надо изменить, чтобы запрос сработал AS IS. Можно было бы и пример с рандомными переменными постмана дать, но тут надо понимать, что через постман его будут дергать тестировщики и аналитики со стороны заказчика.

Разработчики же должны написать код, используя ваш пример. А они тоже любят копипастить))) И если дать пример, заточенный под постман, то к вам снова придут с вопросом, почему ваш пример не работает, но уже в коде. И тут опять или писать около примера, что “$randomInt — переменная Postman, она тут для того-то”, или всё же примеры оставить в покое.

Я не вижу особой проблемы в текущем описании, это не повод ставить баг на документацию. Пример нормальный и рабочий. А если принесет головную боль поддержке, тогда и замените.

В нашей доке всего 1 пример. Если бы их было больше, надо было бы вызвать все. Именно на примерах пользователи учатся работать с системой. Дернули, получили такой же ответ, изучили его, осознали, запомнили =)

2. Основной позитивный сценарий

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

В идеале он берет этот сценарий из примера. Если примеров нет, будет дергать метод наобум, как он считает правильным. Знаете, как с новым девайсом — сначала попробовал сам, если не получилось, пошел читать инструкцию.

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

Практика на примере Users

А у нас есть пример, так что основной позитивный сценарий мы уже почти проверили!

Почему “почти”? Мы проверили, что система вернула в ответе «успешно создалась Машенька562», но точно ли она создалась? Может быть, разработчик сделал заглушку и пока метод в разработке, он всегда возвращает ответ в стиле “успешный успех”, ничего при этом не делая.

Так что идем и проверяем, есть ли наша Машенька в GUI — http://users.bugred.ru/. Ищем поиском — есть!

Проверяем все поля:

Емейл правильный, какой мы отправляли.
Автор «rest», что логично.
Дата изменения — сегодня, что тоже правильно.

Значит, пользователь правда создан! Хотя постойте… Я же выполняла не метод CreateUser, а doRegister. Его основная цель — не создать карточку, а зарегистрировать пользователя в системе. Просто при регистрации карточка автоматом создается, поэтому её тоже зацепили проверкой.

А как проверить, что регистрация прошла успешно? Правильно, попробовать авторизоваться!

Нажимаем «Войти» и вводим наши данные: milli754@mail.ru / 1

Вошли! Ура, значит, регистрация правда сработала. Вот теперь мы закончили с основным позитивным сценарием.

3. Альтернативные сценарии

На самом деле если в ТЗ нет отдельно выделенного сценария использования, то можно объединить пункты “альтернативные сценарии” и “негативное тестирование”, потому что по факту после базового теста мы:

Читаем каждое предложение из ТЗ, «Особенности использования» или как этот раздел у вас называется
Продумываем, как его проверить: как позитивно, так и негативно.

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

Практика на примере Users

Читаем особенности использования:

Пользователь создается и появляется в системе.

Это мы уже проверили. Дальше:

Автор у него всегда будет «SOAP / REST», изменять его можно только через соответствующий-метод.

Автора тоже проверили, но только вот в ТЗ он указан капсом, а по факту создается в нижнем регистре. Это уже небольшой баг, скорее всего документации, так как некритично и проще доку обновить. Сделали заметочку / сами исправили доку, если есть доступ.

А дальше видим, что изменять только только через соответствующий метод. Ага, то есть если создали через REST, менять можно тоже только через REST, через SOAP нельзя. И наоборот. Это и проверим.

Для начала под Машенькой в ГУИ посмотрим, есть ли возможность отредактировать собственную карточку — нету. Ок. Открываем в SOAP Ui WSDL проекта — http://users.bugred.ru/tasks/soap/WrapperSoapServer.php?wsdl, и смотрим, каким методом можно вносить изменения.

Нам вполне подойдет UpdateUserOneField, он обновляет одно любое поле пользователя. А как понять, какие поля есть? Покопаться в документации. В Users описаны не все методы, но есть описание CreateUser, где можно взять названия полей. Допустим, хочу обновить кличку кошки — cat. Получается запрос:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wrap="http://foo.bar/wrappersoapserver">   <soapenv:Header/>   <soapenv:Body>      <wrap:UpdateUserOneField>         <email>milli754@mail.ru</email>         <field>cat</field>         <value>Еночка</value>      </wrap:UpdateUserOneField>   </soapenv:Body></soapenv:Envelope>

Отправляем, хммммм:

Поле cat успешно изменено на Еночка у пользователя с email milli754@mail.ru

Проверяем в интерфейсе, находим карточку пользователя и жмем “Просмотр” (прямую ссылку давать бесполезно, база дропается каждую ночь, тут только самому создать и посмотреть). Значение обновилось:

Значит, условие из ТЗ не выполнено, можно ставить баг!

А мы пока читаем дальше:

Имя и емейл должны быть уникальными

Раз должны, то будет ошибка в случае неуникальности. А мы решили вынести тестирование негативных сценариев отдельно. Видите, решение тестировать альтернативы отдельно от негативного сразу оказалось не самым удобным — куда лучше просто читать ТЗ и каждый пункт проверять. Так хоть не запутаешься, что проверил, а что ещё нет… Однако в рамках статьи мы всё-таки рассмотрим негативные тесты отдельно.

Пока же смотрим дальше — а всё, кончилось ТЗ, метод то простенький. Тогда переходим к негативу!

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

По факту это проверка сообщений об ошибках. Смотрим на метод и думаем, как его можно сломать? Сначала бизнесово, а потом API-шно…

С бизнесовой точки зрения очень удобно, когда все ошибки прописывают прямо в ТЗ. Получается руководство к действию! Это можно быть разделение на «Особенности использования» и «Исключительные ситуации», как в Folks (логин для входа тут). Тогда тестируем блок «Исключительные ситуации».

Или вот описание Jira Cloud REST API, выберем в левом навигационном меню какой-нибудь метод, например «Delete avatar». Там есть описание метода, а потом в блоке Responces переключалки между кодами ответов.

Ну так вот все желтые коды — это ошибки. Открываем каждую, читаем «Returned if» и выполняем это условие, очень удобно:

В общем, если есть отдельно про ошибки — класс, проверяем по ТЗ. А потом ещё думаем сами, что там могло быть пропущено.

Плюс проверяем логику ошибок в API, но о ней чуть позже. Сначала бизнес-логика, потом уже серебряная пуля типа well formed json.

Практика на примере Users

Ограничение в ТЗ:

Имя и емейл должны быть уникальными

Для проверки нам надо сделать неуникальным:

имя
емейл
оба поля сразу

Можем взять за основу наш исходный запрос, который 1 раз создался:

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

И варьируем его

1. Уникальный емейл, дубликат имени

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

2. Уникальное имя, дубликат емейл

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

3. Дубликаты сразу имени и емейл

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

И смотрим на ответ. Понятно ли нам из сообщения об ошибке, что именно пошло не так? А статус-код соответствует типу ошибки?

5. Параметры запроса

На входе мы передаем какие-то параметры. И теперь нам нужно взять каждый параметр и проверить отдельно. Как проверяем:

Обязательность
Перестановка мест слагаемых
Бизнес-логика

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

Вот у вас есть параметры запроса. Как их проверять? Если вы впали в ступор сейчас, то просто представьте себе, что это не API, а GUI. Что у вас в интерфейсе есть форма ввода с этими полями? Как будете тестировать? Вот ровно так и тестируйте, выкинув разве что попытку убрать ограничение на клиенте (снять с поля maxlenght).

Практика на примере Users

По ТЗ входные параметры:

Имя параметра

Тип

Обязательный?

Описание

строка

да

email пользователя

name

строка

да

имя пользователя

password

строка

да

пароль

Тестируем каждый параметр в отдельности. И тут, как и в GUI, надо понимать:

Есть ли какие-то проверки у поля? Проверяется ли email по маске email-а? Имя выверяется по справочникам? Или это “просто строка, как прислали, так и сохранил?”
Куда данные идут дальше, где отображаются? В приветствии, в отчете, в личном кабинете, где?
Как они потом используются? На емейл придет письмо?

email

Вроде доп. проверок разработчик не делал, но точно я этого не знаю. Поле базовое, может есть прям во фреймворке какие-то проверки, или в интернете скопипастил… Так что тут стоит убедиться, что email корректный.

Можно взять за основу вот этот чек-лист, но часть проверок скомбинировать

Корректный существующий email, куда может прийти почта — подставляем свой (начинаем всегда с корректного)
Верхний регистр, цифры в имени пользователя и доменной части — TEST77@mail9.ru
Email с дефисами и нижним подчеркиванием — test_user-1@mail_test-1.com
Email с точками в имени пользователя и парой точек в доменной части — test.user@test.test.test.ru

А дальше идут интересные тесты, которые по идее должны падать, но упадут ли в Users, есть ли там такие проверки?

Email без точек в доменной части — test@mailcom
Превышение длины email (>320 символов)
Отсутствие @ в email — testmail.ru
Email с пробелами в имени пользователя — test user@mail.ru
Email с пробелами в доменной части — test@ma il.ru
Email без имени пользователя — @mail.ru
Email без доменной части — test@
Некорректный домен первого уровня (допустимо 2-6 букв после точки: .ru) — test@mail.urururururu

Помним, что имя должно быть быть уникальным при этом, потому что негативные тесты мы не смешиваем, только если в этом состоит сам тест “а что, если несколько полей сразу плохие”. Так что пример запроса:

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

И сервер отвечает — некорректный емейл!

Так что проверки на емейл нужны, особенно — на некорректный.

name

Имя можно тестировать по разному. Если по нему определяется пол, тесты будут одни, если предлагаются подсказки, другие, а если это простая строка — третьи.

Так вот, в Users имя — это простая строка. Пол по ней не определяется, оно просто сохраняется в системе, разве что в правом верхнем углу отображается

Поэтому закапываться в “а теперь проверим мужское имя, и женское, и…” смысла нет.. Так что наша задача — проверить:

Что это правда простая строка и туда влезет всё, что можно
Максимальную длину изучить

Ну и начинаем с позитивного теста. Итого получаем:

Простое имя типа “Ольга”
Имя с разным регистром, разными буквами и спецсимволами (все спецсимволы можно перечислить) — если есть ограничение по длине, разобьем на разные тесты
1 000 символов — ищем верхнюю границу, если она есть. Заодно смотрим, как это выглядит в интерфейсе и корректируем тест.
1 000 000 символов — ищем технологическую границу

Обратите внимание на то, что мы вроде как тестируем API-метод, но после его выполнения лезем в графический интерфейс и проверяем, как там выглядит результат нашего запроса.

А всё почему? Потому что нет абстрактных методов, которые делают “ничего”, просто отправляются. Они все зачем-то нужны. В нашем случае — чтобы создать пользователя в системе. И важно понимать, а что будет потом с нашими данными? Будут ли они нормально отображаться в интерфейсе? Ведь если нет, то надо ставить ограничение на API-метод.

Поэтому помните, что API и GUI идут рука об руку, а не живут в разных мирах.

Password

На пароле тоже никаких ограничений нет — мы это знаем, потому что уже отправляли запрос с паролем “1”. Вот если бы были всякие “нужны заглавные буквы” и прочее, мы бы провели тесты “а если пароль ненадежный” и посмотрели на качество сообщения об ошибке, а так тесты будут как у имени:

Обычный пароль типа 1
Смесь из разных регистров, разных букв и спецсимволов — если есть ограничение по длине или составу, разобьем на разные тесты
1 000 символов — ищем верхнюю границу, если она есть. Заодно смотрим, как это выглядит в интерфейсе и корректируем тест.
1 000 000 символов — ищем технологическую границу

6. Остальные тесты

А дальше мы уже идем по специфике API:

Перестановка мест слагаемых (заголовки, тело)
Регистрозависимость (заголовки, тело)
Well formed xml / json

На конкретных примерах мы остановимся подробнее в следующих разделах. Просто важно не забывать про эти тесты. Этим и отличается API от GUI — тут нельзя снять границу из серии “убрать maxlenght”, зато можно и нужно проверить особенности API запросов.

Что тестируем в запросе

Заголовки (Headers)

Заголовки должны где-то обрабатываться:

— на сервере;

— на клиенте;

Иначе они не нужны, только лишний трафик гонять. Мы ведь передаем сообщение по сети, если интернет плохой, то каждый байт на счету. Зачем отправлять информацию, которую никто не использует?

Так что разработчики используют «Принцип меньшего зла»: заголовок или кем-то обрабатывается, или он вообще не нужен.

Если заголовка нет:

— используется дефолтный, прописанный в коде;

— он вообще не нужен;

Язык должен указываться всегда, иначе непонятно, как вернуть ответ от сервера. Но разработчик может в код зашить русский язык, и тогда даже если вы передадите заголовок «Accept-Language: en-US», то ответ получите на русском.Почему? Потому что разработчик игнорирует этот заголовок, он его не считывает из запроса в принципе. Его право =)

Возможные ситуации, которые надо проверить

Заголовок не передан, как система реагирует:

— выдает ошибку → понятно ли, что мне надо сделать?

— применяет поведение по умолчанию (если язык не передан, используй русский)

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

— верно

— неверно → какая ошибка?

Плюс регистрозависимость. Согласно спецификации, все заголовки должны быть регистронезависимы. И неважно, как я их передаю. Могу в CamelCase (первая буква большая, остальные мелкие), могу в верхнем регистре, причем как значение заголовка, так и его название, могу как-то ещё:

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

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

Был случай у моих коллег — заголовок проверили, всё работает. Но проверили по доке, прислали значения «как указано». Вот Accept может быть (как передаются входные данные):

application/json
application/xml

А потом пользователи приходят и жалуются на ошибки «у вас плохой заголовок». При том, что заголовок они отправили правильный. Начали разбираться — запрос идет не напрямую на сервер, он проходит через прокси Nginx. А Nginx меняет заголовки на upper case: ACCEPT: APPLICATION/JSON.

Система к такому не готова, она ищет «Accept», не находит его и выдает ошибку. А переданный заголовок игнорирует. Так что проверять регистр — надо!

Итого — тестирование заголовков в API

Заголовки из документации работают (в целом)
А если какой-то не передать? (обязательность)
А если передать, но неправильно? (текст ошибки)
Позитивные тесты по доке
Регистронезависимость заголовков

Практика на примере Users

В документации вообще ничего не сказано про заголовки. Поэтому проверяем, можно ли отправить сообщение без них. Идем на вкладку Headers и снимаем все галки, если они по каким-то причинам там стояли. Запрос сработал успешно:

Но обратите внимание, что в постмане есть ещё скрытые заголовки (hidden):

Это те заголовки, что генерирует сам постман. По сути постман — это клиент, помогающий нам отправить запрос на сервер. И у него есть какие-то свои фишечки, ограничения, заголовки опять же.

Можно нажать на это сообщение “(цифра) hidden” и раскрыть этот список (а потом всегда можно нажать на кнопку “hide hidden”:

Это некий стандарт, дефолтные значения по умолчанию. Тот же Cache-Control, раз вы его не передаете, по факту он вам не нужен, то есть как если бы вы указали “no-cache”.

Но учтите, что если снять тут все-все-все галки, система может выдать ошибку:

Плохо ли это? Стоит ли заводить баг “в документации сказано, что можно без заголовков, а так не работает” — нет. Для начала попробуйте отправить запрос через curl и посмотрите на результат.

Помните, что Postman — это всё-таки клиент, у которого есть свои навороты. Так что пусть он их накручивает сколько влезет, эти хидден-заголовки тестировать особо не надо. А вот послать хотя бы разок честный curl — надо!

Так что прячем hidden-заголовки и проверяем без них в этом пункте. Да, doregister без заголовков работает, всё ок.

Тело запроса (body)

Что мы тут тестируем:

Правильное тело (пример)
Различные параметры (обязательность, работа параметров)
Бизнес-логика
Ошибки: бизнес-логика
Перестановка мест слагаемых
Регистрозависимость
Ошибки: не well formed xml / json

Пункты 1-4 мы уже обсудили выше. Идем по ТЗ и каждую строчку изучаем и проверяем.

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

Это как раз особенность API, поэтому очень важно её проверить. Бизнес-логика и проверки “а что можно ввести в такое-то поле” одинаковы для GUI и API, а вот переставить поля местами в графическом интерфейсе не получится.

При этом в API это сделать проще простого. Мы ведь передаем пары “ключ-значение”. Что будет, если мы попробуем поменять их местами?

В идеале ничего не случится, потому что принимающая система должна из запрос цеплять информацию именно по названию ключа, а не делать “select *” и потом говорить “для первого поля из запрос проверь то, для второго сделай это…”.

Ведь потом изменится входной запрос и у нас вся интеграция сломается! А это нехорошо… Так что смотрим как система реагирует на перестановки.

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

Вы же помните о том, что регистронезависимость не появляется из воздуха? Её делает разработчик. Поэтому и проверить “как ведет себя система” — тоже надо. И в заголовках, и в теле, и в параметрах URL — вообще везде, где есть символы.

Ошибки в ответе от сервера

Всегда обязательно изучаем ошибки. Помимо ошибок в бизнес-логике есть ещё неправильно составленный запрос. То есть не well formed. Пробуем такой послать и смотрим на адекватность ошибки

См также:Правила Well Formed XML Правила Well Formed JSON

Практика на примере Users

По бизнес-логике мы уже прошли, теперь пойдем по API-части:

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

В json пробуем перестановку:

{

    "name": " Машенька{{$randomInt}}",

    "email": "test{{$randomInt}}@mail.com",    

    "password": "1"

}

Ура, работает! А как насчет form-data? Тоже всё ок, это хорошо:

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

Мы уже поняли, что в Users регистронезависимости может и не быть. Поэтому проверим на одном поле для начала. И не email, а то с ним может быть ложная уверенность в корректной ошибке:

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

Запрос не сработал, увы: "Параметр name является обязательным!"

Названия ключей регистрозависимы. Это не очень хорошо, хотя и некритично. Такой баг разработчик может не захотеть исправлять, “пусть присылают по документации”. Ну что же, тогда единственным аргументом будет потом количество обращений в поддержку.

Но мы, по крайней мере, получили информацию по работе системы.

3. Well formed

У нас на входе json, смотрим его правила:

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

И пытаемся сломать. Вообще самая частая ошибка — это запятая после последней пары «ключ:значение». Мы обычно скопипастим строку из середины (вместе с запятой), поставим в конец объекта, а запятую удалить забудем. Получится как-то так:

{

    "email": "test{{$randomInt}}@mailcom",

    "name": " Машенька{{$randomInt}}",

    "password": "1",

}

Отправляем такой запрос. М-м-м-м, ответ как-то не очень:

Это постман мне настойчиво подсвечивает красным лишнюю запятую, а если вызов идет из кода и там подсветки нет, то как понять, что пошло не так? Из текста сообщения об ошибке. Только вот из такого текста разработчик очень долго будет угадывать, что не понравилось системе… Нехорошо, стоит завести баг.

Попробуем другие способы сломать формат:

— не в виде пар “ключ:значение”

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

Ответ будет такой же — "Параметр email является обязательным!"

Заметьте, что если мы “сломаем” так email, будет ложное ощущение, что система работает хорошо и правильно дает подсказку. А на самом деле нет…

Так что если уже замечали странности раньше, проверяем на другом поле — на пароле, а не емейле. И видим, что ошибка непонятная.

— данные не разделены запятыми

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

— объект в квадратных скобках, а не фигурных

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

Ответ везде одинаковый — "Параметр email является обязательным!"

Не очень хорошо, в ожидаемый результат чек-листа проверок мы запишем что-то более «правильное» =)) Например, ошибка 400 и сообщение "Не well formed json в запросе".

URL

Там тоже могут быть параметры. Обычно это в методе GET делается, прямо в параметры URL зашивается какая-то информация. Например, идентификатор элемента, который мы хотим получить.

Тестируем точно также, как если бы параметр был в теле:

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

Практика на примере JIRA

Почему не на примере Users? А потому что в методе doRegister нет параметров, которые передаются в URL. Да и вообще в Users их нету, там даже get через POST сделан, но сейчас не об этом…

Поищем примеры в Jira Cloud REST API. Например, метод «Get Issue», вот какой у него URL:

GET /rest/api/3/issue/{issueIdOrKey}

Мы передаем в URL или id задачи, или её ключ. Условно говоря, это или что-то типа “13005” или “TEST-1”.

И вот тут мы уже можем развернуться!

Правильное значение

Базовый позитивный тест, что метод в целом работает. Вызываем обязательно и так, и так:

13005
TEST-1

Обязательность

Попробуем не передать параметр:

/rest/api/3/issue//rest/api/3/issue

Тест-дизайн

Тут стоит подумать в тему состояний объекта. Пробуем получить:

Свежесозданную задачу
Несколько раз измененную / отредактированную
Заполненную по минимуму / по максимуму
В разных статусах
Закрытую
Удаленную
Не существующую (такого номера ещё нет — это отличается от “он есть в базе, но задача была закрыта”)

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

При передаче issueId этот пункт не проверить, цифры сами по себе регистронезависимы. Но если мы передаем задачу через Key, то это уже символы. Значит, проверка актуальна:

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

Тип метода

Что будет, если мы “подменим” тип запроса?

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

Как система отреагирует? Она может или отработать “словно так и надо”, или выдать ошибку. И тут следим за тем, чтобы ошибка была внятной и понятной.

А ещё может показаться, что игнорирование ошибок пользователя — это хорошо. Но далеко не всегда. Например, у меня был случай, когда на проекте обновили библиотеку и она стала намного жестче с ошибкам интеграции. Тут то и выяснилось, что запросы исходные системы присылали “кто во что горазд”.

Если бы система сразу падала, то на первичной интеграции пришлось бы поднапрячься побольше, зато дальнейшие переходы были бы бесшовными. А когда уже всё в продакшене, это будет стопить обновление релиза. Так что может, лучше заранее начать ловить за руку “ты мне какой-то треш” шлешь?

Практика на примере Users

Меняем в запросе тип метода с POST на GET — а ему всё равно, успешно!

Нельзя сказать, что это прям вау-поведение, но для Users это нормально =)

Что тестируем в ответе

Тело ответа

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

Какие поля вернулись в ответе?
Значения в полях
Текст ошибок

Поля в ответе нужно:

сравнить с ТЗ
сравнить между собой SOAP \ REST

Если у нас есть ТЗ — то всё понятно. Читаем, как должно быть, проверяем, как есть на самом деле. Смотрим на то, что все поля из требований вернулись, и что в них правильное значение. А то вдруг я сохраняю имя “Оля”, а там всегда сохраняется “Тестовый”... Очень удобно сразу автотесты писать в том же постмане, если отдельного фреймворка нет — идем по ТЗ и каждое поле выверяем.

Если ТЗ нет, то уже сложнее. Ищем «хранителя информации», расспрашиваем, проверяем, как работает на самом деле. Думаем, есть ли проблемы в текущем поведении. Нет? Ок, значит, так и надо.

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

См также:Каким должно быть сообщение об ошибке Сообщения об ошибках — тоже документация, тестируйте их!

Если у вас в системе два интерфейса — SOAP и REST, нужно проверить оба. Обычно они должны быть идентичны. Да и в коде это обеспечивается условно говоря двойной аннотацией “сделай и soap, и rest сгенери”, разработчик не дублирует всю функциональность дважды, а просто “включает” API.

В таком случае действительно всё будет работать идентично, кроме пустых полей в ответе. Что будет, если какое-то поле не заполнено? Может легко быть такая ситуация:

— SOAP возвращает пустые поля;

— REST нет.

Более того, это даже может быть нормально! Например, исходно писался только SOAP-интерфейс, и было правило возвращать все поля, даже пустые. Потом решили стать модными, молодежными, подключили REST. И решили там поля пустые не возвращать.

К тому же в SOAP всегда есть схема WSDL, где указаны обязательные поля. Значит, они будут возвращаться в ответе. В ресте же схема WADL необязательна, да и там любят придерживаться принципа минимальных чернил, лишнего не выводить.

В общем, проверьте обязательно, как методы срабатывают на:

Отсутствие данных на входе (поле не пришло вообще / пришло пустое)
Пустые поля на выходе

Если по разному, то это должно быть описано в доке!

Практика на примере Users

Сначала отправляем базовый запрос и там, и там, как в документации. Но уже по документации мы можем заметить, что набор поле в ответах разный. В SOAP перечислены все поля юзера, включая кличку кошечки, собачки итд… В REST же несколько базовых полей, и всё.

Как так вышло? Очень просто. Для реста набор полей согласовали, разработчик сделал. Потом я сказала, что хочу ещё и SOAP. А там нужна схема WSDL, разработчик с ней особо не парился. Есть сущность “user”? Ну её и вернем в ответе. А в сущности как раз много полей…

Мне не критично, так что менять не стали, да и вообще отличный пример «да, и так бывает» же! =))

Ок, давайте теперь посмотрим на особенности API, ведь всю бизнес-логику перетестировать в SOAP смысла нет, она должна совпадать… Ну разве что вы совсем не верите своим разработчикам… Или кейсы очень важные. А так — бизнес-логику смотрим один раз, а потом переходим в особенностям API.

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

Поменяем местами name и email — ой ёй ёй!

Система пишет «Некоректный email Имечко 666». Это значит, что она ориентируется не названия полей, передаваемые в тегах, а на их порядковых номер. И это ОЧЕНЬ ПЛОХО, на такое стоит идти ставить баг.

Тем более обоснование у нас есть — неединообразно работает. REST вот от перестановки не зависит, и SOAP не должен.

А ещё слово «Некоректный» написано неправильно, там должно быть две буквы “р”. Проверяем в REST, посылая заведомо плохой емейл — да, и там ошибка. Надо бы исправить. Текстовку ошибок вычитываем внимательно!

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

Каждый тег регистрозависим сам по себе — открывающий и закрывающий должны совпадать по написанию, в том числе по регистру. Если это сломать, будет точно плохой запрос, но мы начнем с условно хорошего — оба тега в капс-локе:

<EMAIL>ggg55555@mail.com</EMAIL>

Работает!

А вот теперь попробуем разный регистр внутри тегов (в json такую проверку не сделать, это особенно XML, дублирование названия поля):

<EMAIL>ggg55555@mail.com</email>

Не работает — Bad Request. Чтож, вполне логично.

Well formed XML

Что, если сломать XML? Скажем, оставить закрывающий тег «/email» без второй угловой скобки:

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

Возвращается ошибка

<faultcode>SOAP-ENV:Client</faultcode><faultstring>Bad Request</faultstring>

Не супер информативно, но в целом ясно, что мы где-то с запросом накосячили. И если такой текст именно на well formed, то и ладно. Тогда по нему будет сразу понятно, в чем именно проблема. Посмотрим дальше.

Статус-коды

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

2хх — все хорошо
4хх — ошибка на клиенте (в запросе)
5хх — ошибка на сервере

А может придумать свои:

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

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

400 — Bad Request
↓
400 — Internal Server Error

Но так лучше не делать =))) Просто знайте, что возможность такая имеется.

Если разработчик ленивый и не настроил коды, то вы будете огребать на любую ошибку стандартный код: 400 Bad Request. Неверный заголовок? Ошибка 400. Неверное тело? Ошибка 400. Проблемы в бизнес-логике? Ошибка 400… Ну и как тут разобраться, что именно надо исправлять?

Или ещё “лучше”, разработчик может сказать “всегда возвращай код 200”. И это очень нехорошо, ведь именно по коду мы ориентируемся в первую очередь: всё хорошо или что-то плохо?

Поэтому статус-код проверяем всегда, обращаем на него внимание. Ну а если в методе собственные статусы (как, например, в методе MagicSearch)

Практика на примере Users

На статус надо было обращать внимание всегда, чтобы не дублировать снова все тесты. Но сейчас просто дернем “хороший” и “плохой” запросы.

Хороший — статус 200, всё ок:

Плохой — ой, статус снова 200, хотя мы видим сообщение об ошибке:

Нехорошо! На это надо ставить баг.

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

Помним, что в первую очередь проверяем бизнес-логику. А потом уже всякие API-штучки, куда входят:

Регистрозависимость
Перестановка мест параметров
Well formed запрос

Базовый тест

Базовый тест тщательно выверяет каждое поле из “корректного” ответа. Проверяет, как вызов API-метода влияет на отображение в GUI… Поэтому его пропишем текстом, а остальные тесты соберем в табличку.

1. Проверка примера из ТЗ (но имя и емейл меняем на уникальные)

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

ОР:

1. Статус 200

2. В ответе следующий набор полей:

"name": " Машенька562", (то имя, что мы отправили)"avatar": "http://users.bugred.ru//tmp/default_avatar.jpg", (в этом методе всегда такой урл стандартной аватарки)"password": "4dff4ea340f0a823f15d3f4f01ab62eae0e5da579ccb851f8db9dfe84c58b2b37b89903a740e1ee172da793a6e79d560e5f7f9bd058a12a280433ed6fa46510a","birthday": 0,"email": "milli754@mail.com", (тот емейл, мы мы отправили)"gender": "","date_start": 0,"hobby": ""

3. Пользователь добавлен в общий список. Проверяем через GUI — http://users.bugred.ru/. Ищем поиском — есть!

Проверяем все поля:

Емейл правильный, какой мы отправляли.
Автор «rest», что логично.
Дата изменения — сегодня, что тоже правильно.

4. Под пользователем можно войти в систему — нажимаем “Войти”, вводим емейл из запроса, пароль из запроса, проверяем авторизацию.

Остальные тесты

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

Уникальный емейл, дубликат имени

{

"email": "milli{{$randomInt}}@mail.ru",

"name": " Машенька562",

"password": "1"

}

ОР: Статус 400

В теле ошибка: "name (переданное имя) уже есть в базе"

Уникальное имя, дубликат емейл

{

"email": "milli754@mail.ru",

"name": " Машенька{{$randomInt}}",

"password": "1"

}

ОР: Статус 400

В теле ошибка: "email (переданный email) уже есть в базе"

Дубликаты сразу имени и емейл

{

"email": "milli754@mail.ru",

"name": " Машенька562",

"password": "1"

}

ОР: Статус 400

В теле ошибка: "email (переданный email) уже есть в базе"

Параметр email

Корректный существующий email, куда может прийти почта — подставляем свой (начинаем всегда с корректного)

Успешный запрос

Верхний регистр, цифры в имени пользователя и доменной части — TEST77@mail9.ru

Успешный запрос

Email с дефисами и нижним подчеркиванием — test_user-1@mail_test-1.com

Успешный запрос

Email с точками в имени пользователя и парой точек в доменной части — test.user@test.test.test.ru

Успешный запрос

Email без точек в доменной части — test@mailcom