Повторение: какие задания могут быть на API?
Еще одно практическое задание

Коллекция в Swagger, с которой предстоит работать: https://petstore.swagger.io/

🔳Предусловия:
▪️Base URL: https://petstore.swagger.io/
▪️Request URL: https://petstore.swagger.io/v2/pet
▪️Headers: 'Content-Type': 'application/json'
▪️В теле запроса указывать статус питомца: "status": "available"

📝 Задание: создать коллекцию в Postman
В коллекции должны быть следующие запросы:

1. Создание нового питомца (POST /pet)
Заполнить все ключи тела запроса своими примерами значений.
На вкладке Scripts прописать скрипт, который:
- получает из тела ответа id созданного питомца;
- сохраняет id в переменную коллекции.
Совет: в Postman может возникать некорректное поведение при сохранении значения через сниппет pm.collectionVariables.set(...). Чтобы избежать проблем, можно задать id вручную и проверить.

2. Получение и проверка значения tags питомца
Написать скрипт, который:
- извлекает name из tags в теле ответа;
- сохраняет его в переменную коллекции.
Добавить проверку с использованием pm.test, чтобы убедиться, название tags из тела запроса равно названию tags из тела ответа сервера.
📖 Примеры скриптов — см. пост: https://news.1rj.ru/str/info_course_protestinginfo/267

3. Получение информации о питомце по id (GET /pet/{petId})
Использовать переменную id, сохранённую в коллекции ранее.
На вкладке Scripts прописать скрипт, который отправит следующий запрос:
Обновление данных питомца (POST /pet/{petId})
- Изменить значение поля status на "sold"
- Использовать pm.sendRequest.

4. Негативные проверки
Создать отдельные запросы, эмулирующие ошибки:
- Невалидный id при создании питомца
Ожидаемый ответ: 400 Bad Request (bad input)
- Несуществующий id при получении питомца
Ожидаемый ответ: 404 Not Found (Pet not found)
- Неподдерживаемый формат данных при создании питомца
Ожидаемый ответ: 415 Unsupported Media Type
- Серверная ошибка при создании питомца
Добиться, чтобы сервер вернул ошибку 500, например, такую:

{
  "code": 500,
  "type": "unknown",
  "message": "something bad happened"
}

Подумать, какие данные могут вызвать такую ошибку, и протестироватьразные варианты.

📤 Экспортировать коллекцию:
Postman → Export → Export Collection и отправить её на проверку @nadin_qa.

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

Привет всем!
В середине августа планирую провести мощнейший вебинар 🤔 по токенам (авторизация, аутентификация) с уклоном на практику.
Чтобы подготовиться к нему и быть в курсе, ожидайте серию тестов по этой теме — они будут публиковаться на этом канале @protestinginfo до начала вебинара.
Анонс с деталями представлю в начале августа.
Вебинар приурочен к старту новых потоков по тестированию бэкенда и подготовке к собеседованиям.
💻На практике мы разберём различные способы авторизации на разных сервисах — от базовой аутентификации до OAuth 2.0. 💻Также, возможно, затрону тему применения сертификатов при отправке запросов, которые активно используются у меня на работе в финтехе.

Изучаем и закрепляем знания перед тестами

Authorization в Postman
▪️Наследование авторизации (Inherit auth from parent), что пригодится при группировке запросов в коллекции и папки для комплексного тестирования нескольких конечных точек одного веб-сервиса с разными HTTP-запросами, чтобы повторно использовать одни учетные данные вместо ввода этих параметров каждый раз при отправке запроса. По умолчанию запросы внутри коллекции или папки наследуют аутентификацию от родителя...
▪️Отсутствие авторизации (No auth), что не предполагает добавления учетных данных к запросу;
▪️Ключ API (API key) – в заголовок или в параметры HTTP-запроса добавляется пара ключ-значение. Чтобы использовать это для тестирования, предварительно нужно получить ключ разработчика API на стороне тестируемого сервера.
▪️Tокен на предъявителя (Bearer token) – это веб-маркер JSON (JWT, JSON Web Token), который представляет собой текстовую строку, включенную в заголовок запроса, надо предварительно получить токен разработчика API от тестируемого сервера.
▪️ JWT-носитель (JWT bearer), что предполагает генерацию носителя JWT прямо в Postman с использованием криптографических алгоритмов с SHA (HMAC, RSASSA-PKCS1-v1_5, ECDSA, RSASSA-PSS), секрета, закрытого ключа и полезной нагрузки для генерируемого JWT-токена в формате JSON.
▪️Базовая аутентификация (Basic auth) — отправка подтвержденного имени пользователя и пароля вместе с HTTP-запросом. Эти учетные данные добавляются в заголовок HTTP-запроса Authorization в кодировке Base 64. Это не самый безопасный способ, т.к. перехваченные данные легко раскодировать.
▪️Дайджест аутентификации (Digest auth), когда клиент отправляет первый запрос к API, а сервер отвечает несколькими деталями, включая одноразовый номер, значение области действия (realm) и HTTP-ответ со статусом 401. На это клиент снова отправляет серверу зашифрованный массив данных, включая имя пользователя и пароль, вместе с данными, полученными от сервера в первом запросе...(читать далее)
▪️Аутентификация Hawk (Hawk authentication) позволяет использовать частичную криптографическую проверку, задав Hawk Auth ID, Hawk Auth Key и алгоритм хеширования для создания кода аутентификации сообщения (MAC).
▪️Подпись AWS (AWS Signature) для запросов к веб-сервисам Amazon. AWS использует для аутентификации специальную схему HTTP, основанную на ключе HMAC (код аутентификации хэш-сообщения) с ключом доступа и секретом.
▪️NTLM-аутентификация (Windows Challenge/Response) — поток аутентификации для операционной системы Windows и автономных систем с указанием домена или хоста.
▪️Akamai EdgeGrid от провайдера веб-услуг Akamai, что включает учетные данные (токен доступа, токен клиента и секрет клиента), полученные при регистрации клиентского приложения в Akamai.
▪️OAuth 1.0 – аутентификация через стороннего провайдера (например, войти через VK, Google, Github и пр.), которая позволяет клиентским приложениям получать доступ к данным, предоставляемым внешним API, не раскрывая имя пользователя и пароль. Протокол OAuth 1.0 иногда называют двусторонним (аутентификация только между клиентом и сервером) . Чтобы запросить пользовательские данные с помощью стороннего сервиса, клиентское приложение запрашивает маркер доступа, используя учетные данные, такие как ключ и секрет...(читать далее)
▪️OAuth 2.0 является развитием предыдущего вида и предполагает получение токена доступа к API, а затем его использование для проверки подлинности запросов. Обычно доступ к данным с помощью OAuth 2.0 отличается у разных провайдеров API, но включает несколько прямых и обратных запросов между клиентским приложением, пользователем и API...(читать далее)
▪️ASAP (Atlassian) - Протокол аутентификации Atlassian S2S (ASAP ) — это токен-носитель JSON Web Token (JWT), который сервер API может использовать для аутентификации запросов от клиента

источник

На вебинаре я планирую разобрать часто используемые в работе: API Key, Basic Auth, Bearer Token, JWT (JSON Web Token), OAuth 2.0 и еще авторизация через куки, используя заголовок Cookie c значением sessionId