Home

Автор: Кристин Джеквони (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 (примеры значений):

Это тело POST-запроса. В отличие от GET-запросов, у которых обычно нет тела, в POST вы, как правило, найдете json или xml. Тело запроса – это данные, которые вы добавляете в базу данных. Кликните по ссылке Model:

Это окно вкратце описывает, что за значения используются в теле запроса. Вы можете нажимать на иконки ">", чтобы раскрыть каждую секцию модели. С моей точки зрения, она расплывчато описывает, что такое категория и тэги, поэтому мне придется поиграть в угадайку. Давайте пройдемся по каждой секции модели 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, который уже существует в базе данных, вы получите сообщение, что запись уже имеется. В случае Pet Store, если 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-запросы можно тестировать массой различных сценариев. Во-первых, нам надо протестировать сценарии "счастливого пути". Попробуйте отправить POST-запросы, варьируя id, категорию питомца и ее id, имя питомца, ссылки на фото, тэги и их id, и статусы питомца. Вам нужно протестировать все три статуса: sold, available и pending. Также стоит обратить внимание, что можно передавать несколько ссылок на фото, и несколько тэгов. Вот пример тела 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"
}

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

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

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

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

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

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

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

или

' or 1 = 1--

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

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

Закончив тестировать тело запроса, переходите к заголовкам. Этому конкретному 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-запросов

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