Осваиваем инструменты QA-инженера или как ручному тестировщику работать с REST API

Общение между сервером и клиентом, краткое определение REST API

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

Схема клиент-серверной архитектуры.Схема клиент-серверной архитектуры.

REST (Representational State Transfer) – это набор правил взаимодействия компонентов распределенного приложения, которые включают в себя следующие требования (ограничения):

  • отделять в архитектуре клиент от сервера;

  • в период между запросами клиента никакая информация о его состоянии не должна храниться на сервере;

  • необходима возможность кэширования ответов сервера;

  • необходимо единообразие интерфейса для возможности независимого развития каждого сервера;

  • необходимо предоставлять возможность добавления слоев между клиентом и сервером для лучшей масштабируемости и безопасности.

Почему большинство веб-приложений используют REST?

  • Правила порождают порядок и единообразие. Это облегчает работу с кодом, а также его чтение.

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

  • Появляется возможность более легкого исправления ошибок и внесения изменений.

  • Прозрачность связей между компонентами также упрощает чтение и работу с кодом.

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

Определяем где ошибка, классификация кодов HTTP

Хватит общих слов. Пора переходить к практике: нужно открыть devtools браузера (нажать клавишу F12) и перейти во вкладку Network (можно настроить фильтр на показ XHR, так будет удобнее).

Скриншот браузера с открытой панелью devtools.Скриншот браузера с открытой панелью devtools.

Колонка статуса показывает статус выполнения запроса, прошел ли он успешно, или была допущена ошибка. Если кратко, то статусы можно для простоты сортировать следующим образом:

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

Скриншот браузера с открытой devtools.Скриншот браузера с открытой devtools.

Основная информация, которую можно посмотреть по запросу, начиная работать с REST – это первые три вкладки:

  • Headers – заголовки и основная информация.

  • Preview – посмотреть тело запроса.

  • Response – посмотреть тело ответа.

Остальные вкладки можно рассмотреть как-нибудь потом.

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

В общей информацией указан метод, который используется в запросе (в данном случае GET). Основные используемые методы (о других можно дополнительно почитать здесь).

Еще нужно обратить внимание на такой заголовок как Content-Type. Он отображает в каком формате передаются данные в запросе: json, xml или text.

Инструменты тестировщика для работы с REST

Первый инструмент, который не требует никакой дополнительной установки – это devtools используемого браузера. Достаточно нажать F12 и начать отслеживать, какие запросы летят и нет ли ошибок, которые нужно задокументировать в баг.

Второй инструмент, который всегда под рукой у пользователя Unix/Linux – это curl (в Windows нужно будет его специально установить). Чтобы посмотреть информацию по этой утилите, достаточно набрать следующую команду в терминале:

        man curl
# или
curl --help

    

Для начала можно попробовать отправить GET-запрос и получить ответ:

        curl -i https://proglib.io/posts/fetch
    

Непонятные символы появились, потому что нет русификации консоли.Непонятные символы появились, потому что нет русификации консоли.

Был повторен GET-запрос и получен ответ. Используя ключ -i, можно посмотреть дополнительную информацию. Дальше можно попробовать отправить POST-запрос, сразу же отправив header content-type:

        curl -i -X POST -d '' -H 'content-type: application/json' https://proglib.io/post/info
    

Консоль с вызванным curl.Консоль с вызванным curl.

В нашем запросе -X POST показывает, что используется метод POST (по умолчанию отправляется метод GET), -d ‘’ – тело запроса (в данном случае пустое) и -H 'content-type: application/json' – заголовок, показывающий, что тип сообщений – json. В ответ пришел статус 400, значит тело запроса нужно менять.

Postman – свободно распространяемая программа с платным контентом для взаимодействия в команде. Для работе в ней нужно зарегистрировать свою почту на официальном сайте и скачать десктопную версию (хотя можно работать и через браузер). Также для Postman есть официальная документация и обучающие видео.

Начнем с отправки того же самого GET-запроса, что и с помощью curl:

Скриншот программы Postman.Скриншот программы Postman.

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

Теперь можно отправить POST-запрос, тело которого также будет пустым, и будет прописан указывающий тип запроса header:

Скриншот программы Postman.Скриншот программы Postman.

Был получен такой же ответ с таким же статусом, как и при отправке запроса с помощью curl.

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

Выводы

Можно продолжать тестировать только клиентскую часть, раз за разом проводя тест-дизайн, пытаться отловить ошибку и не пытаясь проанализировать ее с точки зрения кода программы… Но разве этого достаточно? Разве не хочется заглянуть под картинку и увидеть, как все работает?

В статье описаны основы и показаны некоторые инструменты. Открытие консоли браузера – только первый шаг, который ведет к нагрузочному тестированию, автоматизации rest-test или пониманию, как все устроено. Однако дорогу осилит идущий, а в следующих публикациях мы разберем и более сложные темы. Удачи!

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

Last updated

Was this helpful?