Осваиваем инструменты QA-инженера или как ручному тестировщику работать с REST API
Last updated
Last updated
Большинство веб-приложений в современном мире работают на клиент-серверной архитектуре. Основной ее смысл в том, что сетевая нагрузка распределена между поставщиком (сервер) и потребителем (клиент). Общение между ними осуществляется через сетевые протоколы, но для любого общения нужны правила, и тут мы как раз подходим к REST API.
Схема клиент-серверной архитектуры.
REST (Representational State Transfer) – это набор правил взаимодействия компонентов распределенного приложения, которые включают в себя следующие требования (ограничения):
отделять в архитектуре клиент от сервера;
в период между запросами клиента никакая информация о его состоянии не должна храниться на сервере;
необходима возможность кэширования ответов сервера;
необходимо единообразие интерфейса для возможности независимого развития каждого сервера;
необходимо предоставлять возможность добавления слоев между клиентом и сервером для лучшей масштабируемости и безопасности.
Правила порождают порядок и единообразие. Это облегчает работу с кодом, а также его чтение.
Сервисы становятся масштабируемыми, что дает возможность сделать приложение отказоустойчивым и более безопасным.
Появляется возможность более легкого исправления ошибок и внесения изменений.
Прозрачность связей между компонентами также упрощает чтение и работу с кодом.
Перечислять можно долго, но основной смысл в том, что такой подход упрощает работу и систематизирует код.
Хватит общих слов. Пора переходить к практике: нужно открыть devtools браузера (нажать клавишу F12) и перейти во вкладку Network (можно настроить фильтр на показ XHR, так будет удобнее).
Колонка статуса показывает статус выполнения запроса, прошел ли он успешно, или была допущена ошибка. Если кратко, то статусы можно для простоты сортировать следующим образом:
Допустим, был интересен определенный запрос, потому что именно его меняли в нужном релизе, или его статус указывает на ошибку. Чтобы посмотреть информацию по запросу, нужно дважды щелкнуть (уверена, что знаете, но проговорить нужно):
Основная информация, которую можно посмотреть по запросу, начиная работать с REST – это первые три вкладки:
Headers – заголовки и основная информация.
Preview – посмотреть тело запроса.
Response – посмотреть тело ответа.
Остальные вкладки можно рассмотреть как-нибудь потом.
На первой вкладке содержится общая информация по данному запросу, а также header, которые в нем используются (дополнительная информация к запросу, передаваемая между сервером и клиентом).
В общей информацией указан метод, который используется в запросе (в данном случае GET). Основные используемые методы (о других можно дополнительно почитать здесь).
Еще нужно обратить внимание на такой заголовок как Content-Type. Он отображает в каком формате передаются данные в запросе: json, xml или text.
Первый инструмент, который не требует никакой дополнительной установки – это devtools используемого браузера. Достаточно нажать F12 и начать отслеживать, какие запросы летят и нет ли ошибок, которые нужно задокументировать в баг.
Второй инструмент, который всегда под рукой у пользователя Unix/Linux – это curl (в Windows нужно будет его специально установить). Чтобы посмотреть информацию по этой утилите, достаточно набрать следующую команду в терминале:
Для начала можно попробовать отправить GET-запрос и получить ответ:
Был повторен GET-запрос и получен ответ. Используя ключ -i, можно посмотреть дополнительную информацию. Дальше можно попробовать отправить POST-запрос, сразу же отправив header content-type:
В нашем запросе -X POST показывает, что используется метод POST (по умолчанию отправляется метод GET), -d ‘’ – тело запроса (в данном случае пустое) и -H 'content-type: application/json' – заголовок, показывающий, что тип сообщений – json. В ответ пришел статус 400, значит тело запроса нужно менять.
Postman – свободно распространяемая программа с платным контентом для взаимодействия в команде. Для работе в ней нужно зарегистрировать свою почту на официальном сайте и скачать десктопную версию (хотя можно работать и через браузер). Также для Postman есть официальная документация и обучающие видео.
Начнем с отправки того же самого GET-запроса, что и с помощью curl:
На картинке видно, что заголовки были заполнены автоматически. Ответ более читаемый, чем при запросе с помощью curl.
Теперь можно отправить POST-запрос, тело которого также будет пустым, и будет прописан указывающий тип запроса header:
Был получен такой же ответ с таким же статусом, как и при отправке запроса с помощью curl.
Postman умеет еще множество вещей: можно собирать запросы в коллекции, писать тесты на Java Script, осуществлять мониторинг определенных запросов, документировать их и т.д.
Можно продолжать тестировать только клиентскую часть, раз за разом проводя тест-дизайн, пытаться отловить ошибку и не пытаясь проанализировать ее с точки зрения кода программы… Но разве этого достаточно? Разве не хочется заглянуть под картинку и увидеть, как все работает?
В статье описаны основы и показаны некоторые инструменты. Открытие консоли браузера – только первый шаг, который ведет к нагрузочному тестированию, автоматизации rest-test или пониманию, как все устроено. Однако дорогу осилит идущий, а в следующих публикациях мы разберем и более сложные темы. Удачи!
Если вы только начинаете осваивать профессию, стоит обратить внимание на Факультет ручного тестирования образовательной онлайн-платформы GeekBrains. Обучение длится всего 10 месяцев и включает теоретическую часть, практику с четырьмя проектами в портфолио и как бонус – диплом о профессиональной переподготовке с гарантированным трудоустройством. Программа обучения актуальна, а занятия ведут практикующие специалисты российских технологических компаний.
Скриншот браузера с открытой панелью devtools.
Скриншот браузера с открытой devtools.
Непонятные символы появились, потому что нет русификации консоли.
Консоль с вызванным curl.
Скриншот программы Postman.
Скриншот программы Postman.
