Тестирование апи что это
Тестирование Web API — From Zero To Hero
Под фразой «тестирование API» большинство людей подразумевает именно тестирование Server-Side Web API, несмотря на то, что Web API всего лишь один из многих типов API. [1]
В статье представляем полный набор теории, инструментов, открытых Web API и Roadmap для освоения основ тестирования Server-Side Web API.
Термины
API (программный интерфейс приложения) — описание способов, которыми одна компьютерная программа может взаимодействовать с другой программой. [2]
Web API — это API для WEB, которое необходимо для взаимодействия веб-сервера и веб-клиента. [3]
Server-side Web API — это API на стороне веб-сервера, которое состоит из одного или нескольких публично доступных точек доступа (endpoints) для системы обмена определенными сообщениями вида запрос-ответ, которые, обычно, описываются при помощи JSON или XML и передаются через Web при помощи HTTP. [4, пер.]
Front-End и Back-End разработчики в компании, не проводящей тестирование API
Roadmap по обретению навыка тестирования Server-Side Web API
Процесс изучения тестирования Server-Side Web API:
Тестирование API
Введение: Что такое API
В широком смысле слова API (Application Programming Interface) это метод который приложение предоставляет внешним пользователям для коммуникации с ним. Обычно через Интернет.
Это может быть взаимодействие с сервером приложения на смартфоне, между компьютерами или другими устройствами.
API применяются там где невозможна или нежелательна непосредственная интеграция с исходным приложением, то есть практически везде.
Крупные интернет-компании обычно предоставляют (платно или бесплатно) доступ к API своих сервисов.
Где применяют API
Сейчас будет несколько абстрактных примеров просто для понимания сути.
Конкретные примеры работы с API я разбираю в учебнике
Пример №1:
Если Вы хотите разместить на своём сайте яндекс-карты Вам не нужно устанавливать программы от Яндекса, достаточно послать несколько запросов и Яндекс передаст необходимую информацию.
Пример №2:
Предположим, что Вы создали сайт vk2.com. Вы хотите, чтобы вебмастера могли добавить на свои сайты возможность комментировать записи используя учётную запись vk2, но раскрывать или раздавать свой код не хотите.
Чтобы обойти эту проблему Вы выкладываете в публичном доступе правила, по которым вебмастера могут обращаться к vk2, чтобы получить комментарии.
Формат этих сообщений это обычно либо JSON либо XML. О них мы поговорим позже.
Повторим для закрепления сути: Смысл в том, что сайт написанный на любом языке, поддерживающем HTTP запросы, не посылает на сервер никаких PHP/C/Python команд, а общается ним с помощью запросов, описанных в API.
Если вам интересен реальный пример работы с API рекомендую статью Работа с API GitHub
Endpoint
Адрес, на который посылаются сообщения называется Endpoint.
Обычно это URL (например, название сайта) и порт. Если я хочу создать веб сервис на порту 8080 Endpoint будет выглядеть так:
Если моему Web сервису нужно будет отвечать на различные сообщения я создам сразу несколько URL (interfaces) по которым к сервису можно будет обратиться. Например
https://andreyolegovich.ru:8080 /resource1/status
https://andreyolegovich.ru:8080 /resource1/getserviceInfo
https://andreyolegovich.ru:8080 /resource1/putID
http://andreyolegovich.ru:8080 /resource1/eventslist
https://andreyolegovich.ru:8080 /resource2/putID
…
Как видите у моих эндпойнтов (Enpoints) различные окончания. Такое окончание в Endpoint называются Resource, а начало Base URL.
Такое определение Endpoint и Resource используется, например, в SOAP UI для RESTful интерфейсов
Endpoint = Base URL + Resource
Понятие Endpoint может использоваться в более широком смысле. Можно сказать, что какой-то определённый роутер или компьютер является Endpoint. Например, в понятии Endpoint Management под Endpoint имеют в виду конечное устройство. Обычно это понятно из контекста.
Также следует обратить внимание на то, что понятие Endpoint выходит за рамки RESTful и может использовать как в SOAP так и в других протоколах.
Термин Resource также связан с RESTful, но в более широком смысле может означать что-то другое.
На программистском сленге Endpoint иногда называют ручкой.
Спецификация
После того все эти интерфейсы созданы, их необходимо описать. Нужен документ из которого будет понятно
Этот документ должен быть доступен программистам с обеих сторон, иначе они просто не смогут договориться и реализовать работающий Web сервис.
HTTP методы
Вернёмся к первому пункту списка, а именно к тому, что такое методы.
В протоколе HTTP предусмотрено несколько способов отправить запрос на один и тот же Endpoint.
Про их свойства можно почитать здесь.
Когда мы знаем какие методы с какими Enpoint можно использовать составить запросы не составит труда.
GET http://andreyolegovich.ru:8080 /resource1/status
GET http://andreyolegovich.ru:8080 /resource1/getserviceInfo
PUT http://andreyolegovich.ru:8080 /resource1/putID
GET http://andreyolegovich.ru:8080 /resource1/eventslist
POST http://andreyolegovich.ru:8080 /resource1/eventslist
PUT http://andreyolegovich.ru:8080 /resource2/putID
…
Таким образом простейший запрос состоит из метода и Enpoint
Request = Method + Endpoint
Пример API
Чтобы узнать количество велосипедистов в городе нужно отправить GET запрос на https://topbicycle.ru:/bicyclists/$город
GET https://topbicycle.ru /bicyclists/helsinki
Получив такой запрос сайт вернёт число велосипедистов в Хельсинки.
Попробуйте вставить эту строку в браузер.
Это очень простые уроки для самых начинающих. Буду рад любым отзывам и предложениям в комментариях.
Тестирование API без документации
Если Вам по какой-то причине предстоит проделать эту неблагодарную работу, определетесь, насколько всё плохо. Какая у Вас есть информация об объекте тестирования.
Известно ли какие порты для Вас открыты? Знаете ли Вы нужные endpoints?
Сканирование портов
Перебор запросов
Если Вам известен нужный порт и соответствующий endopoint переберите все возможные HTTP методы. Начните с наиболее очевидных:
В худшем случае, когда ни порт ни endpoints неизвестны Вам, скорее всего придётся перебирать все открытые порты и генерировать endpoints, которые подходят по смыслу.
Разработчики обычно не особо заморачиваются и закладывают минимально-необходиму информацию. Так что включите воображение и попробуйте придумать endpoints опираясь на бизнес логику и принятые в Вашей компании стандарты.
Если ни endpoints ни бизнес логика Вам неизвестны, то у меня есть подозрение, что Вы тестируете API с не самыми хорошими намерениями.
Инструменты для тестирования
Существует множество инструментов для тестирования. Здесь Вы можете познакомиться с одними из самых популярных: Python и SOAP UI.
О работе с REST API на Python вы можете прочитать в статье «REST API с Python»
Инструменты тестирования API
Пожалуйста, учтите, что упомянутыми ниже инструментами их спектр для API тестирования не ограничен. Я говорю именно об этих, потому что ими я уже пользовалась.
В следующей секции я покажу, как провести тест API.
Swagger
Согласно официальному сайту, Swagger – это профессиональный инструментарий с открытым исходным кодом, который «упрощает разработку API для пользователей, команд и предприятий».
Я пользовалась Swagger UI, чтобы легко проверить API URL, разобраться в вызовах, а затем добавить их в код моих тестов, но опробовала не все инструменты Swagger. Мне кажется, это простой способ сообщить команде об изменениях API и задокументировать их.
В качестве альтернативы разработчики могут документировать вызовы API в другом формате – обычно списком, как сделано у Twitter. Проблема тут в том, что такая документация может устаревать, и затем надо копаться в коде разработки, чтобы понять, как конкретно выглядит этот вызов. Swagger подтягивает набор вызовов напрямую из кода, поэтому с ним проще работать и поддерживать актуальность документации.
Swagger сделан компанией SmartBear, как и SoapUI, поэтому для тестирования API с их помощью прочитайте следующую секцию.
SoapUI и Postman
s ” a Complete API Test Automation Framework for SOAP, REST and more”. There is an open source version and a professional one featuring more functionality. The API testing part looks like this:
Я взяла изображение с официального сайта, и оно довольно самоочевидно. Кроме того, проект хорошо документирован, что поможет вам разобраться с ним.
Postman – это «платформа для совместной разработки API». Для разработчиков Постман предоставляет автоматическую документацию, и это ликвидирует проблему, при которой разработчики меняют функциональность, а затем забывают сообщить об этом.
Приступить к тестированию API с Postman очень легко. Вы можете создавать запросы REST, SOAP и GraphQL. Инструмент поддерживает множество протоколов авторизации (я расскажу об этом позже) и управление сертификатами. Пожалуйста, посетите официальный сайт, чтобы узнать больше.
Wireshark и Fiddler
Эти два приложения очень полезны для анализа сетевых пакетов. Это мощные программы, которыми в обязательном порядке надо владеть, тестируя безопасность, сеть и производительность, а также проверяя пакеты на микро-уровне. Они помогают увидеть, какие конкретно данные пересылаются через сеть. Однако если вы ищете инструментарий для тестирования API, возможно, стоит выбрать что-то из вышеперечисленных – они более высокоуровневые, и предназначены именно для работы с API.
Несмотря на это, я использовала Wireshark и Fiddler для тестирования API, требовавшего особых сертификатов безопасности, а также для дебага проблем (особенно проблем производительности). Чтобы лучше познакомиться с Fiddler, прочитайте эту статью, а для Wireshark – эту.
Как это автоматизировать?
Если вы хотите добавить тесты API в свой код автоматизации, вышеуказанные инструменты помогут вам в этом. Однако в разных языках программирования различаются способы выполнения таких типов вызовов. К примеру, вот так делается REST-вызов в Python:
# сделать что-то с результатом
response.status_code # это дает вам код статуса, о чем говорилось выше
response.json() # это дает вам json с ответом
Это становится сложнее, если вам нужно добавить параметры, авторизацию, или проанализировать данные, но весь процесс хорошо документирован. Давайте рассмотрим конкретный пример, используя API numbersapi.com.
Результат после выполнения кода выше:
При помощи Python вы можете анализировать данные json, легко извлекая и валидируя текст или число.
Чтобы узнать больше о том, что именно тестировать при проверке API, прочитайте эту статью, которая чудесно объясняет этот вопрос на примере Postman.
А мне какое дело? Сравнение тестирования UI и API
Тестирование UI (пользовательского интерфейса) – наилучший способ имитировать реальное поведение пользователей. Однако мы склонны тестировать через UI то, что уже может быть покрыто тестами API (которые в некоторых компаниях могут выполняться другой группой или командой).
Допустим, разработчик изменил вызов API. Пусть это будет вызов списка избранных фильмов. Теперь представим, что этот вызов не изменился в какой-то части приложения, и в результате пользователь не может найти понравившиеся фильмы. Что происходит в UI-тесте?
UI-тест не сможет найти объект. Это может случиться из-за неверного вызова API, баге в автоматизации, обновлении способа получения объекта, нерабочей кнопки, спрятанного объекта…
Однако при наличии API-теста вы поймете, что вызов ничего не получает в ответ. Если вам нужно проверить что-то вроде результатов поиска, лучше использовать API для проверки всего списка (что можно сделать быстрым сравнением), и убедиться через UI, что результат появляется там, где должен, а не само содержание результата. Вы также должны убедиться, что вызов API верен (и обновить тестовый вызов, если это не так).
Переходим на уровень выше
Вызовы API меньше склонны к переменам по сравнению с объектами UI, и, как правило, перемены имеют другую версию, не затрагивая предыдущие релизы приложения. Это означает, что может быть разумным добавить функциональность проверки того, какая именно версия тестируется.
Тесты API также можно использовать для ускорения UI-тестирования. Наиболее распространенный пример – это метод авторизации. Этот метод обычно становится бутылочным горлом для остальных тестов, и если он падает – вы не можете узнать, что еще падает или успешно проходит, до исправления бага вы беспомощны. Очень важно иметь под рукой тест авторизации, чтобы убедиться, что ваши пользователи способны авторизоваться, но выполнение авторизации через UI при каждом прогоне тестов, для которых она требуется, увеличивает время выполнения этих тестов.
Что же делать? Использовать тестирование API, чтобы пропустить авторизацию. Будьте осторожны, в релизном окружении это будет небезопасным. К примеру, можно настроить уникальные токены (см. пример с SoapUI) с коротким сроком жизни для выполнения этого перехода, и отправлять их вместе с URL, или задать вызов API, настраивающий куки или сессию авторизации.
Если у вас есть другие повторяющиеся зависимые тесты, рассмотрите возможность прогонять API-вызовы, прежде чем переходить к зависящим от этих вызовов тестам. Это серьезно ускорит прогон тестов, и его результаты дадут вам более достоверную информацию о проблеме.
Учитывая вышесказанное, UI-тесты – наилучший способ убедиться, что все корректно работает относительно пользовательского поведения, E2E и интеграционные тесты не должны заменяться тестами API. Используйте их как вспомогательный инструмент, если они не увеличивают сложность и отказы ваших тестов.
И еще на уровень выше: статистика
Другая интересная штука, которую можно делать благодаря API-вызовам – это выяснять информацию о приложении и том, как его использует аудитория. Для глобального анализа и визуализации вызовов можно использовать такие инструменты, как elastic search и kibana, и даже пользоваться искусственным интеллектом для получения выводов об этих вызовах… но это уже другая история.
Стратегия тестирования REST API: что именно вам нужно тестировать?
Общедоступный API, ориентированный на клиента, который делают открытым для конечных пользователей, сам по себе становится продуктом. Если он сломается, это подвергнет риску не только одно приложение, но и целую цепочку бизнес-процессов, построенных вокруг него.
Знаменитая пирамида тестов Майка Кона помещает тесты API на сервисный уровень (интеграционный), что предполагает, что около 20% или более всех наших тестов должны быть сосредоточены на уровне API (точный процент зависит от наших потребностей).
Пирамида тестов
Когда у нас уже есть прочный фундамент из модульных тестов, охватывающих отдельные функции, тесты API обеспечивают более высокую надежность. Они проверяют интерфейс, более близкий к пользователю, но не имеют недостатков тестов пользовательского интерфейса.
Стратегия тестирования API
Основными задачами функционального тестирования API являются:
гарантировать, что реализация API работает в соответствии со спецификацией требований (которая позже становится нашей документацией по API).
предотвратить регрессий между написанным кодом(merge) и релизом.
эндпоинты правильно именованы;
ресурсы и их типы правильно отражают объектную модель;
нет отсутствующей или дублирующей функциональности;
отношения между ресурсами правильно отражаются в API.
Если у вас общедоступный API, ориентированный на клиента, такое тестирование может быть вашим последним шансом убедиться, что все требования соглашения выполнены. После публикации и использования API любые внесенные вами изменения могут внести ошибки в код клиента.(Конечно, когда-нибудь вы сможете опубликовать новую версию API (например, /api/v2 /), но даже в этом случае обратная совместимость скорее всего будет обязательной).
Итак, какие аспекты API мы должны протестировать?
После того как мы проверили соглашение API, мы можем поразмышлять о том, что тестировать. Независимо от того, думаете ли вы об автоматизации тестирования или ручном тестировании, наши функциональные тест-кейсы имеют одинаковый набор тестовых действий. Они являются частью более широких категорий тестовых сценариев и их можно разделить на три потока тестирования.
Этапы тестирования API
Каждый тест состоит из тестовых шагов. Это отдельные атомарные действия, которые тест должен выполнять в каждом потоке тестирования API. Для каждого запроса API тест должен будет выполнить следующие действия:
Проверьте корректность кода состояния HTTP. Например, создание ресурса должно возвращать 201 CREATED, а запрещенные запросы должны возвращать 403 FORBIDDEN и т. Д.
Проверьте полезную нагрузку ответа. Проверьте правильность тела JSON, имен, типов и значений полей ответа, в том числе в ответах на ошибочные запросы.
Проверьте заголовки ответа. Заголовки HTTP-сервера влияют как на безопасность, так и на производительность.
Проверьте правильность состояния приложения. Это необязательно и применяется в основном к ручному тестированию или когда пользовательский интерфейс или другой интерфейс можно легко проверить.
Проверьте базовую работоспособность. Если операция была завершена успешно, но заняла неоправданно много времени, тест не пройден.
Категории тестовых сценариев
Наши тест-кейсы делятся на следующие общие группы тестовых сценариев:
Основные позитивные тесты (прохождение успешного сценария по умолчанию)
Расширенное позитивное тестирование с дополнительными параметрами
Негативное тестирование с валидными входными данными
Негативное тестирование с недопустимыми входными данными
Тесты безопасности, авторизации и доступности (которые выходят за рамки этой статьи)
Тестирование успешного сценария по умолчанию проверяет базовую функциональность и критерии приемки API. Позже мы расширим положительные тесты, чтобы включить дополнительные параметры и дополнительные функции.
Тестовые потоки
Давайте разделим и обозначим три вида потоков тестирования, которые составляют наш план тестирования:
Мы выполняем запросы через API и проверяем действия через пользовательский интерфейс веб-приложения и наоборот. Цель этих потоков проверки целостности состоит в том, чтобы гарантировать, что, хотя на ресурсы влияют различные механизмы, система по-прежнему поддерживает ожидаемую целостность и согласованный поток данных.
Пример API и тестовая матрица
Теперь мы можем отобразить все в виде матрицы и использовать ее для написания подробного плана тестирования (для автоматизации тестирования или ручных тестов).
Предположим, что подмножеством нашего API является конечная точка /users, которая включает следующие вызовы API:
Тестирование апи что это
В этой статье я хочу поделиться опытом освоения тестирования (в т. ч. автоматизации) на уровне API (Application Programming Interface – интерфейс программирования приложений, интерфейс прикладного программирования). Надеюсь, что предлагаемый материал будет представлять интерес для всех, кто ранее проводил тестирование через графический интерфейс и еще не имеет опыта работы с http-запросами.
Немного о REST API и SOAP API
Стоит отметить, что на сегодняшний день есть два основных подхода к построению программного интерфейса веб-приложений: REST (RESTful) API и SOAP API:
Если уподобить HTTP-запрос бумажному носителю, то можно сказать, что REST API в большинстве случаев передает простые записки, а время от времени – письмо в конверте (возможно, написав при этом часть послания и на самом конверте). В свою очередь, SOAP API передает все инструкции в подробном письме стандартного вида, используя конверт (единичный HTTP-запрос) лишь как средство доставки. Для лучшего понимания разницы подходов я рекомендую читателю посмотреть следующую инфографику.
В статье речь будет идти о REST API, так как этот подход является более распространенным из-за своей относительной простоты и удобства для разработчиков. SOAP API преимущественно характерен для больших корпоративных (enterprise) систем.
Чем работа с API может быть полезна тестировщику?
Для начала постараемся понять, зачем вообще тестировщику осваивать что-либо на таком уровне. Казалось бы, программные интерфейсы – это территория разработчиков. Ниже мы рассмотрим выгоды использования тестирования API.
Выгода первая: точная локализация.
Умение работать с API позволяет лучше понимать и точнее описывать возникшие ошибки. Предположим, вы открываете некую страницу сайта и видите в пользовательском интерфейсе сообщение об ошибке. Чем конкретно она вызвана? Насколько она серьезна? Может ли она отразиться на других частях системы? Нам будет гораздо проще ответить на эти вопросы, если мы сможем понять, какую именно функцию не удалось выполнить системе. Сообщения в графическом интерфейсе не всегда позволяют оценить эту зависимость.
Выгода вторая: экономия времени при подготовке тестовых данных и ситуаций.
Многие тесты требуют подготовки условий для их проведения. Так, для прохождения кейса про редактирование документа нам может потребоваться создать сам документ. В графическом интерфейсе это займет немало времени: придется, например, нажимать множество кнопок, чекбоксов, заполнять текстовые поля и т. д. По сути, мы выполняем лишь подготовительные действия для того, чтобы браузер отправил серверу запрос на создание документа. При этом сама отправка и исполнение запроса, как правило, занимает доли секунды.
Более того – многочисленные действия в браузере часто являются причиной ложных «падений» автоматизированных тестов, которым на уровне GUI свойственна «хрупкость». Одно неуспешное нажатие кнопки может привести к необходимости повторения либо всего теста, либо какой-то его части. Сформировав запрос программно или воспроизведя его с помощью специальных инструментов (об этом чуть позже), мы можем существенно сократить время проверки.
Выгода третья: возможность воспроизводить тесты на больших наборах входных данных.
Для некоторых проектов важно проводить тесты с большим количеством разнообразных наборов входных данных, отделенных от кода самого теста и вынесенных в отдельный файл. В этом случае один и тот же сценарий может повторяться многократно для разных значений. Эту методологию (так называемую Data Driven Testing) сложно реализовать через графический интерфейс с приемлемой скоростью и стабильностью. Напротив, на уровне http-запросов это делается очень быстро и с гораздо более высокой надежностью.
Практические шаги к освоению работы с REST API сайта
Итак, вы решили освоить работу с программным интерфейсом вашего сайта. С чего же начать?
Шаг 1: откройте средства разработчика в браузере.
Откройте средства разработчика (developer tools) в браузере (например, в Mozilla Firefox и Google Chrome просто нажмите F12) и перейдите во вкладку, в которой отражается сетевая активность (Network, Net, Сеть и т. д.)
Совершайте обычные действия в браузере и наблюдайте за результатом. Первое, что бросается в глаза, – это огромное количество запросов даже при загрузке одной страницы: для получения каждого изображения, стилей, шрифтов, структуры страницы, скриптов. При использовании AJAX (от англ. Asynchronous Javascript and XML – асинхронный JavaScript и XML, подход к построению интерактивных пользовательских интерфейсов веб-приложений, заключающийся в «фоновом» обмене данными браузера с веб-сервером) количество запросов может увеличиваться, даже если вы не производите никаких активных действий.
Шаг 2: скройте запросы, не относящиеся к логике работы.
Что же делать с огромным количеством запросов? Как выбрать те, которые для нас полезны? Попробуйте применить текстовый фильтр. Многие запросы, относящиеся к логике взаимодействия клиента и сервера (то есть, к API), могут содержать в своих URL фрагмент, указывающий на это (например, «api/rest»). Если вы обнаружили такой фрагмент – введите его в поисковую строку DevTools. Средства разработчика в браузере также позволяют выделить запросы определенного типа: XHR, JS, CSS, Images и т. д.
Выберите XHR (XMLHttpRequest) – это интерфейс языка JavaScript, используемый для конструирования запросов, имеющих тело. Обычно именно этот интерфейс используется для обращения к API. Вы можете столкнуться с большим количеством однотипных запросов, порождаемых различными системами мониторинга (например, yandex.webvisor). Их можно скрыть, применив негативный фильтр (например, «-yandex» для Chrome), даже если вы не знаете точно, что именно эти запросы делают. Однотипные и часто повторяющиеся запросы, как правило, относятся к мониторингу сайта, а не к логике совершаемых пользователем действий.
По клику на картинку откроется полная версия.
Просмотрите внимательно оставшиеся после применения фильтра запросы и постарайтесь выявить те, которые относятся именно к логике действий. В случае необходимости обратитесь за разъяснениями к разработчикам. Если вам доступна документация, в которой описываются endpoint-ы сервисов вашего проекта (т. е. адреса, к которым обращаются запросы, относящиеся к API), – изучите ее. Ниже я буду рассматривать вариант, когда подробной документации или соответствующих доступов у вас нет.
Достаточно часто по адресу endpoint-а можно догадаться, за что именно отвечает запрос к данному сервису. Например, адрес, содержащий фрагмент « api/rest/createContract », скорее всего, используется для создания договора, « api/rest/buildInfo » – для вывода информации о версии, установленной в текущий момент, а « api/rest/news/search » – для поиска новостей. Если трудно «выловить» нужный запрос в общей массе (а запросов к API тоже может быть немало) – очистите историю запросов перед совершением интересующего вас действия. Довольно быстро вы научитесь видеть нужные запросы и сопоставлять их с действиями в пользовательском интерфейсе.
Шаг 3: проведите более детальный анализ структуры запросов.
Обратите внимание на то, что часть запросов передает информацию только в запрошенном URL-е. В первую очередь, это GET-запросы, которые предназначены для получения определенного содержимого или запуска процесса. Классический пример – запрос на текстовый поиск. Его URL может выглядеть как « https://anysite.ru/search?keywords=my_query&itemsperpage=20 », где « ../search » – адрес поискового сервиса, « keywords=… » – текст запроса, « itemsperpage » – параметр, отвечающий за количество результатов, выводимых на одной странице.
С другой стороны, встречаются запросы, передающие большинство параметров в теле самого запроса. При этом часть параметров может передаваться и в URL. Примером могут послужить POST-запросы:
URL : POST https://www.youtube.com/feed_ajax?action_pause_watch_history=1 HTTP/1.1
Request headers : дополнительная информация, в т. ч. cookies.
Message Body :
session_token=QUFFLUhqbER0TE5idlp2MngybFh1ZUUyblYtaGlmLVhmZ3xBQ3Jtc0tta1J5W
m9uZHpVTW9oWHIzOWdIblkzVk1wVTNFQS1aS0pfNG85OWw3Sk14U2
В этом случае суть необходимого действия передается в URL-е ( action_pause_watch_history=1 ), а информация о пользователе – в теле запроса ( session_token ).
На структуру тела запросов и ответов не накладывается ограничений. Это может быть как просто набор пар поле/значение (т. н. Form Data, как в примере выше session_token/значение ), так и документ в удобном для разработчика формате (JSON, XML или каком-то ином).
Проанализируйте приходящие ответы (вкладка Response) и их коды. Помимо всего прочего, коды ответов, как правило, несут полезную информацию и сообщают о логике происходящего. Большинство запросов имеют код ответа «200 OK», сообщающий о том, что операция выполнена успешно. В случае возникновения ошибки коды будут начинаться на 4 (ошибка на стороне клиента) или на 5 (ошибка на стороне сервера). Например, таковы всем известные ошибки 404 («клиент запросил несуществующий ресурс») и 500 («внутренняя ошибка сервера»). Обратите внимание, что браузеры предоставляют возможность просмотра подробностей запросов/ответов как в удобном формате («parsed» в Google Chrome, «pretty print» в Mozilla Firefoх), так и в «сыром» виде («source»). Конечно, для понимания проще «parsed»/«pretty print», но в том случае, когда вам необходимо скопировать часть запроса, лучше переключиться в режим «source».
По клику на картинку откроется полная версия.
По клику на картинку откроется полная версия.
Шаг 4: воспроизведите запросы.
Итак, вы видите нужные запросы и понимаете, какие именно параметры они передают и с какой целью. Теперь можно попробовать самостоятельно менять значения параметров для получения нужных действий. Каким образом можно воспроизвести запросы с измененными параметрами? Самый простой способ — создавать GET-запросы, просто вводя их в адресную строку браузера (по сути, адресная строка – это интерфейс командной строки для воспроизведения GET-запросов). Но вам не удастся сделать многое, ограничившись лишь GET-методом.
Для расширения ваших возможностей используйте Fiddler или подобные ему инструменты (например, такие). Эти программы перехватывают весь сетевой трафик, позволяя просматривать, редактировать и воспроизводить отдельные запросы. Уже на этом уровне можно что-то тестировать – например, валидацию данных на стороне сервера. Если веб-клиент в браузере не позволил вам ввести некоторые значения – в Fiddler-е вы сконструируете запрос сами. Такой способ может существенно ускорить проверку большого набора данных для ввода, особенно если изменение значений в браузере занимает длительное время.
По клику на картинку откроется полная версия.
Дальше – автоматизация тестирования REST API!
Постигнув принципы работы API, вы можете использовать эти навыки в автоматизированных тестах. Остается выбрать инструменты, которые будут воспроизводить нужные вам запросы и отслеживать содержимое ответов. Если вы умеете писать автоматизированные тесты для графического интерфейса (например, с использованием Selenium), то идеальным вариантом, на мой взгляд, будет интеграция тестов API в существующий фреймворк. Тесты часто содержат подготовительные/вспомогательные действия, многие из которых удобнее выполнить с использованием API. Это будет быстрее и стабильнее.
С другой стороны, механизм авторизации бывает достаточно сложным, его не всегда легко пройти только с помощью запросов. Но и это не представляет проблемы в том случае, если API-тесты интегрированы с тестами GUI. Нужные cookie можно забрать в браузере, открытом с помощью Selenium ( driver.manage().getCookieNamed(«sessionId»).getValue() ).
protected ExtractableResponse postRequest(String requestPayload, String endpoint, int expectedStatus) <
return
given().
auth().basic(«login», «password»).
cookies(«sessionId», session).
contentType(ContentType.JSON).
body(requestPayload).
relaxedHTTPSValidation().
when().
post(endpoint).
then().
statusCode(expectedStatus).
body(containsString(«www»)).
extract();
>
Например, вы можете проверить, соответствует ли статус ответа ожидаемому ( statusCode(expectedStatus) ) и содержит ли тело ответа определенный фрагмент текста ( body(containsString(«www»)) ). Команда extract() позволяет получить ответ и использовать его, например, для извлечения определенных значений.
Это можно сделать следующим образом:
ExtractableResponse response = postRequest(session, payload, endpoint, 200);
int numberOfResults = response.path(«results.total»);
Стоит отметить, что и Java, и Python имеют средства работы с http в числе стандартных возможностей, но я неоднократно сталкивался с мнением, что они не слишком удобны. Если вы не планируете писать тесты с использованием языка программирования, то вам, скорее всего, подойдет инструмент Postman – он позволяет воспроизводить и сохранять запросы, а также выстраивать из них тесты.
Заключение
Все сказанное выше позволяет сделать следующий вывод: умение тестировщиков работать с API может принести пользу практически любому проекту. Например, это дает возможность в считанные минуты провести смоук (и убедиться, что ничего важного не сломалось), выполнить одни и те же тесты с разнообразными наборами входных данных или быстро проделать какие-либо вспомогательные действия по созданию тестовых данных и ситуаций.
Наконец, еще раз хочу напомнить, что тестирование API становится особенно востребованным в свете растущей популярности микросервисной архитектуры. Следовательно, даже в том случае, если на вашем проекте пока не используется тестирование на уровне API, вам имеет смысл присмотреться к возможностям, которые оно предоставляет.