Алена Вахтина 14 сентября 2021

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

Изучишь REST API – останешься в Стране Чудес, и я покажу тебе, насколько глубоко уходит кроличья нора и как удобнее всего в нее нырнуть.
🛠 Осваиваем инструменты QA-инженера или как ручному тестировщику работать с REST API
Пусть за спиной остался не один баг-репорт, написан не один ручной тест и пройден не один регресс, но почему все еще кажется, будто мир тестирования так и не открыл свои тайны? Ответ прост: пора двигаться дальше. Ведь баги возникают не просто так, и веб-браузер – это не картинка на экране.

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

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

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

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

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

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

Если REST API – набор способов, подчиняющихся определенным правилам, то зачем большинство web-приложений используют такое сочетание?
  • Правила порождают порядок и единообразие. Это облегчает работу с кодом, а также его чтение.
  • Сервисы становятся масштабируемыми, что дает возможность сделать приложение отказоустойчивым и более безопасным.
  • Появляется возможность более легкого исправления ошибок и внесения изменений.
  • Прозрачность связей между компонентами также упрощает чтение и работу с кодом.

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

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

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

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

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

1xx Информационные сообщения. Например, 102 – идет обработка запроса.
2xx Успешное сообщение.
3xx Была проведена переадресация, т.е. запрашиваемая информация больше не находится по этому адресу и запрос полетел по другому адресу.
4xx Ошибка на стороне клиента. Т.е. нужно изменить запрос или его заголовки, например.
5xx Ошибка на стороне сервера. Можно открыть логи (если есть возможность) и поискать ошибку.

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

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

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

  • Headers – заголовки и основная информация.
  • Preview – посмотреть тело запроса.
  • Response – посмотреть тело ответа.

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

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

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

GET Получение данных. Например, чтобы загрузить статью на странице.
POST Создание сущности.Например при создании нового пользователя.
PUT Обновление сущности. Например изменение пароля или логина у уже существующего пользователя или заголовка статьи.
DELETE Удаление сущности. Например удаление статьи, пользователя или теста. Иногда вместо DELETE используется PUT с пустым телом запроса.

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

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

Существует множество удобных инструментов для работы и проверки 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, значит тело запроса нужно менять.

Немного освоив curl, можно переходить к более высокоуровневому инструменту. В статье я рассмотрю Postman, но есть и другие варианты.

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

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

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

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

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

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

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

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

Выводы

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

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

***

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

МЕРОПРИЯТИЯ

Комментарии

ВАКАНСИИ

Добавить вакансию
Старший DevOps инженер
по итогам собеседования
Data Scientist
по итогам собеседования

ЛУЧШИЕ СТАТЬИ ПО ТЕМЕ