Blog

Тестирование По: Postman Для Тестирования Api

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

ручное тестирование api

В нашем случае — чтобы создать пользователя в системе. И важно понимать, а что будет потом с нашими данными? Будут ли они нормально отображаться в интерфейсе? Ведь если нет, то надо ставить ограничение на API-метод. Обратите внимание на то, что мы вроде как тестируем API-метод, но после его выполнения лезем в графический интерфейс и проверяем, как там выглядит результат нашего запроса. Или вот описание Jira Cloud REST API, выберем в левом навигационном меню какой-нибудь метод, например «Delete avatar».

Что Такое Use Case? Теория И Примеры

REST — буквально «передача самоописываемого состояния», стиль взаимодействия распределенного приложения в сети. REST API — набор функций для создания и выполнения запросов и получения ответов по HTTP. Например, если есть ресурс создания и обновления пользовательских экаунтов, отправка одного и того же PUT-метода https://deveducation.com/ будет каждый раз обновлять пользователя. Отправка одинакового POST-метода много раз создаст много экаунтов, или вернет ошибки «такой юзернейм-почта уже зарегистрированы». В Postman есть встроенный компонент Collection Runner, с его помощью можно запустить наполненную запросами и тестами коллекцию.

ручное тестирование api

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

Какие Сложности Возникали При Тестировании Api На Прежней Работе?

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

  • Общедоступный API, ориентированный на клиента, который делают открытым для конечных пользователей, сам по себе становится продуктом.
  • По факту это всё то же самое, что в GUI + дополнительные тесты.
  • Юнит-тестирование проходит по методике белого ящика, API — обычно черного ящика.
  • И у него есть какие-то свои фишечки, ограничения, заголовки опять же.
  • Тогда тестируем блок «Исключительные ситуации».

Приведенные выше рекомендации применимы к любому API, но для простоты в этом посте мы предполагаем наиболее широко используемую архитектуру веб-API – REST через HTTP. Если ваш API спроектирован именно как RESTful API, важно убедиться, что контракт REST действителен, включая всю семантику, соглашения и принципы HTTP REST. Общедоступный API, ориентированный на клиента, который делают открытым для конечных пользователей, сам по себе становится продуктом.

В ресте же схема WADL необязательна, да и там любят придерживаться принципа минимальных чернил, лишнего не выводить. Ищем «хранителя информации», расспрашиваем, проверяем, как работает на самом деле. Думаем, есть ли проблемы в текущем поведении. Она может или отработать “словно так и надо”, или выдать ошибку. И тут следим за тем, чтобы ошибка была внятной и понятной.

ручное тестирование api

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

ручное тестирование api

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

Интеграционные тесты API проверяют корректность API end-to-end. Таким образом тестируются эндпойнты REST API или запросы к GraphQL API. Юнит-тестирование проходит по методике белого ящика, API — обычно черного ящика.

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

Write a comment