Post запрос онлайн: Форма послать POST/GET запрос

Автор: Кристин Джеквони (Kristin Jackvony)

Оригинал статьи: http://thethinkingtester.blogspot.ru/2018/03/testing-post-requests.html

Перевод: Ольга Алифанова.

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

Чтобы разобраться с POST-запросами, мы снова обратимся к Swagger Pet Store и Postman. Перейдите в Pet Store (http://petstore.swagger.io) и кликните на первом POST-запросе к «/pet». Этот POST-запрос добавит питомца в магазин. Посмотрите на Example Value (примеры значений):

Это окно вкратце описывает, что за значения используются в теле запроса. Вы можете нажимать на иконки «>», чтобы раскрыть каждую секцию модели. С моей точки зрения, она расплывчато описывает, что такое категория и тэги, поэтому мне придется поиграть в угадайку. Давайте пройдемся по каждой секции модели Pet:

• id: это id питомца, который можно использовать в GET-запросах, которые мы уже рассматривали.
• category:
  описывает, к какому виду принадлежит питомец. Id – уникальный идентификатор категории, а name – слово, описывающее животное.
• name: имя питомца.
• photoUrls: строки-ссылки на изображения питомца.
• tags: описания, которые можно добавить к питомцу. Id – уникальный идентификатор тэга, а name – слово, описывающее питомца.
• status: статус питомца в магазине. Может быть available (доступен), pending (забронирован) или sold (продан).

Мы можем использовать информацию в модели, чтобы создать POST-запрос на добавление нового питомца. Нажмите на «Try it out» и замените тело запроса следующей информацией:

{
  "id": 102,
  "category": {
    "id": 1,
    "name": "cat"
  },
  "name": "Grumpy Cat",
  "photoUrls": [
    "https://pbs.twimg.com/profile_images/948294484596375552/RyGNqDEM_400x400.jpg"
  ],
  "tags": [
    {
      "id": 1,
      "name": "blue eyes"
    }
  ],
  "status": "sold"
}

Перед тем, как нажать на Execute, обратите внимание, что кое-что в этом POST-запросе отличается от того, с чем вы столкнетесь в ваших приложениях. Обычно при публикации объекта с id, который уже существует в базе данных, вы получите сообщение, что запись уже имеется.

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

Давайте убедимся, что новый питомец действительно добавлен! Вернитесь к запросу GET pet/{petId}, откройте его и нажмите «Try it out». Введите 100 в поле ID, и нажмите на «Execute». Вы должны увидеть добавленного вами питомца в теле ответа.

Мы успешно создали запрос в Swagger, теперь давайте попробуем прогнать его в Postman. Откройте приложение и нажмите на кнопку с плюсиком «+» для создания нового запроса. Щелкните по иконке выпадающего списка рядом со словом GET, и выберите POST. Введите URL запроса: http://petstore.swagger.io/v2/pet. Нажмите на вкладку «Body» под URL и выберите опцию «Raw». В секции тела запроса ниже вставьте запрос, который мы ранее использовали в Swagger. Возможно, вам захочется его слегка изменить, поменяв id или имя питомца.

Перед тем, как отправить этот запрос через Postman, нам нужно выполнить еще одно действие – добавить заголовок. Заголовки используются в HTTP-запросах и ответах для передачи дополнительной информации серверу. В этом случае нам нужно сказать серверу, какого типа содержимого ему ожидать. Кликните на вкладке «Header» под URL, и в поле под «Key» введите «Content-Type». В поле под «Value» введите «application/json». Таким образом мы сообщаем серверу, что ему нужно искать тело запроса в json-формате. Теперь нажмите на кнопку «Send». В нижней половине окна Postman вы должны увидеть код ответа 200 и тело ответа, совпадающее с добавленными вами данными. Теперь вы можете использовать GET-запрос, чтобы убедиться, что ваш питомец добавлен.

Мы уже обсуждали тестирование форм, и тут то же самое – POST-запросы можно тестировать массой различных сценариев. Во-первых, нам надо протестировать сценарии «счастливого пути».

{
  "id": 102,
  "category": {
    "id": 2,
    "name": "dog"
  },
  "name": "Snoopy",
  "photoUrls": [
    "https://schulzmuseum.org/wp-content/uploads/2017/06/920608_FlyingAce-200.jpg",
    "https://www.calmuseums.org/images/snoopy/snoopy.png",
    "https://vignette.wikia.nocookie.net/peanuts/images/2/28/AmigosperdemoSono.png/revision/latest?cb=20110823202539"
  ],
  "tags": [
    {
      "id": 2,
      "name": "beagle"
    },
    {
      "id": 3,
      "name": "flying ace"
    }
  ],
  "status": "available"
}

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

{
  "name": "Snoopy",
  "photoUrls": [
    "https://schulzmuseum.org/wp-content/uploads/2017/06/920608_FlyingAce-200.jpg"
  ]
}

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

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

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

Теперь мы посмотрим на границы значений, которые мы отдаем. ? Вы можете тестировать эти значения на всех ID: питомца, категории и тэга. Насколько длинными могут быть строки? А насколько короткими? Есть ли недопустимые символы? Стоит протестировать верхние и нижние границы строк и убедиться, что запрещенные символы не принимаются сервером. Это также неплохая возможность проверить на SQL-инъекции и внедрение сценариев. К примеру, можно попробовать передать что-то вроде:

<script>alert('XSS')</script>

или

' or 1 = 1--

и посмотреть, разрешено ли это. В случае с PetStore это, скорее всего, разрешается, но реальное приложение должно запрещать такой ввод или как минимум делать его неэффективным.

Еще стоит задуматься о тестировании списка значений статуса питомца. Статус может быть одним из трех: available, pending, sold. Что произойдет, если вы передадите в статусе другое слово, число, символ? Что будет, если вы передадите статус в верхнем регистре, или если некоторые буквы будут записаны в нем? POST-запросы, как правило, нечувствительны к регистру.

Закончив тестировать тело запроса, переходите к заголовкам. Этому конкретному POST-запросу требуется заголовок Content-Type, позволяющий или application/json, или application/xml значение. Если заголовок отсутствует, вы получите 415 ошибку. При использовании application/xml значения вы получите ошибку 400, если только не измените тело запроса на XML-формат. Вы также можете протестировать отправку xml-тела с заголовком application/json.

И, наконец, можно протестировать URL самого запроса и его тип. Что будет, если вы сделаете запрос через https? А если измените POST на GET?

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

Больше информации по этой теме вы можете получить в курсе Тестирование REST API

Предыдущие статьи на эту тему

Введение в REST-запросы и тестирование GET-запросов

Обсудить в форуме

Имя

Описательное имя выходного коннектора, используемое для ссылки в GeoEvent Manager.

URL-адрес

Базовый URL внешнего веб-сайта, на котором будут опубликованы данные. GeoEvent Server отправляет запрос HTTP/POST на URL-адрес для отправки данных JSON.

Имя параметра заголовка:Список значений

Параметры, включаемые в HTTP-заголовок запроса при опросе внешнего веб-сервера или веб-сервиса. Параметры заголовка должны быть заданы с помощью пар Имя: Значение (включая двоеточие), разделенных запятыми.

Форматированный JSON

Указывает, будет ли форматироваться исходный JSON (подготавливаться). Известен также как PJSON. Значение по умолчанию для этого параметра — Нет.

• Да – исходный JSON будет форматироваться (подготавливаться).
• Нет – исходный JSON не будет форматироваться.

Параметры

Задает параметр запроса (или несколько параметров запроса) для присоединения к базовому URL. Параметры запроса будут разными для каждого веб-сервиса и поддерживаются не всеми сервисами. Если поддерживаются, параметры запроса помогают указать данные, представляющие особый интерес. У этого параметра нет значения по умолчанию.

Использовать URL-адрес прокси

Указывает, будет ли GeoEvent Server использовать URL-адрес прокси при выполнении HTTP-запросов. По умолчанию Нет.

• Да – GeoEvent Server будет использовать указанный прокси-сервер при отправке запроса на URL-адрес внешнего сервиса.
• Нет – GeoEvent Server не будет использовать URL-прокси-сервера. Доступ к базовому URL будет выполняться напрямую.

URL-адрес прокси

(Условия)

URL прокси для использования в время запроса HTTP. У этого параметра нет значения по умолчанию.

Этот параметр показывается, когда для свойства Использовать URL-адрес прокси задано значение Да, и скрыто, если выбрано значение Нет.

Тип MIME тела сообщения

Задает тип MIME данных, включенных в тело содержимого HTTP/POST запроса. Типы MIME обычно состоят из структуры типа/подтипа и используются для указания типов интернет-носителей, используемых и принимаемых HTTP-клиентом/сервером. Этот коннектор задает следующий тип MIME для JSON, который является значением по умолчанию для этого параметра: application / json.

Ожидание HTTP (в секундах)

Задает максимальное время (в секундах) ожидания выходным коннектором ответа от внешнего веб-сервиса, который отправил запрос HTTP/POST. Значение должно быть задано целым числом от 1 до 2147483. Значение по умолчанию – 30 секунд (HTTP/POST-запрос будет остановлен через 30 секунд, если ответ не получен).