У нас во всех проектах есть спецификации. В основном это спецификации двух версий — это OpenAPI-спецификации v1.zero и OpenAPI-спецификации v2.zero. В какой-то момент пришёл менеджер и сказал, что мы больше не будем релизить новые REST API-сервисы без спецификаций. Всё благодаря этой замечательной странице Swagger UI.
Однако при наличии API-теста вы поймете, что вызов ничего не получает в ответ. Вы также должны убедиться, что вызов API верен (и обновить тестовый вызов, если это не так). Тестирование UI (пользовательского интерфейса) – наилучший способ имитировать реальное поведение пользователей. Однако мы склонны тестировать через UI то, что уже может быть покрыто тестами API (которые в некоторых компаниях могут выполняться другой группой или командой). Если вам интересно, как это выглядит в веб-приложении, то можно просто посмотреть на вкладку «Сеть» в панели инструментов разработчика. Вы увидите, что при взаимодействии с веб-сайтом в фоновом режиме осуществляется множество вызовов.
API используются для обмена данными между разными приложениями, веб-сервисами и серверами. Если вы начинающий тестировщик, то знание API может быть полезным для вас, так как API-тестирование может помочь выявлять ошибки и улучшать качество приложения. В результате мы получаем HTML-страницу, на которой видим общую информацию о покрытии операций, общую информацию по покрытию тегов, сколько условий мы покрываем. Swagger-diff — это opensource-проект, который помогает сравнить две спецификации. Я взял его в качестве примера, но есть и другие проекты. Для того чтобы настроить генерацию тестов, нам надо прописать template_directory с нужными темплейтами и добавить шаблон для тестов.
Мы также можем анализировать обратную совместимость. Выявлять случайное удаление параметров и другие изменения. Я буду рассматривать контрактные тесты и тесты на сравнение. Здесь Story API, мы вызываем метод getInventory и его выполняем.
Давайте подробнее разберём, что она собой представляет. Мы там ставим версию нашего API, устанавливаем хосты, базовые пути, схемы и прочее. Также у нас есть блок с описанием всех возможных операций, в которых мы указываем параметры и все возможные ответы. Чтобы запустить коллекцию тестов, зайдите во вкладку «Коллекции», выберите необходимую коллекцию и в выпадающем списке выберите «Run Collection». Переходим во вкладку physique и JSON, а затем копируем информацию о любом пользователе из предыдущего задания.
Swagger
Здесь параметром выступает Request specification. Мы устанавливаем в Request specification все возможные параметры со значениями, которые описаны у нас в спецификации. Аналогично можно сгенерировать тесты для параметров и моделей.
Ниже реальный пример, где я использовал генерацию кода. Мы разобрали, как работает конструктор запросов. С его помощью можно проверять как собственное API, так и сторонних сервисов. Мы будем использовать тот же публичный тестовый API. Мы написали в коде false, а не true, потому что у нас есть только созданные проекты, а удалённых нет.
В качестве альтернативы разработчики могут документировать вызовы API в другом формате – обычно списком, как сделано у Twitter. Проблема тут в том, что такая документация может устаревать, и затем надо копаться в коде разработки, чтобы понять, как конкретно выглядит этот вызов. Swagger подтягивает набор вызовов напрямую из кода, поэтому с ним проще работать и поддерживать актуальность документации.
Инструменты Тестирования Api
Меня зовут Игорь Гросс, я руководитель проектов в Test IT — это такая система управления тестированием. В этом посте я расскажу об одном интересном инструменте тестировщика — Postman — а также о том, как с его помощью решать распространённый тип задач — тестирование API. Использовать тестирование API, чтобы пропустить авторизацию. Будьте осторожны, в релизном окружении это будет небезопасным.
Из неё нам понятно, какой перед нами API, понятны все операции, понятно, как API используется и что вернётся. Это экономит огромное количество времени разработке для коммуникации с фронтендерами, разработчиками мобильных приложений, с ребятами, которые занимаются клиентами. Более того, через эту страницу можно делать запросы и получать ответы. Это https://deveducation.com/ оценили наши тестировщики, которые могут, не используя Curl, тестировать релиз. Исходя из этого мы решили, что будем строить наши автотесты на основе кодогенерации, и в качестве основы мы возьмём Swagger/OAS. С помощью Swagger UI можно создавать и отправлять запросы разных типов, можно быстро перемещаться по документации и тестировать проект.
Мы можем проверять в тестах, что наш ответ после запроса соответствует определённой модели, которая описана в спецификации. Но в реальности это очень маленькое, узкое покрытие. Мы проверяем только модели и не проверяем значения. Если это, например, JSON, то мы проверяем только поля и что они соответствуют схеме.
Вместо кода, где у нас не типизированные assertions, а стандартные hamcrest матчеры, мы получаем типизированные assertions — более удобные и понятные. Если у нас кроме модели ещё есть примеры значений параметров, то можем попробовать сгенерировать реальные шаблоны тестов и сами тесты. Нужно добавить парочку темплейтов, и получим тесты.
Мы всегда сможем вернуться и отредактировать окружение с помощью кнопки Manage Environments (шестерёнка в правом верхнем углу основного экрана). Postman предлагает внушительный список, нам нужен GET. Это сообщение, которое сервер отправляет после выполнения вызова. Узнать, что значат другие коды статусов, можно по этой ссылке, если вы кошатник, или этой, если предпочитаете собак.
Прежде чем нам дальше разбираться с postman, нам необходимо узнать что такое Swagger и научиться с ним работать. Swagger Core написан на языке Java, поэтому для его корректной работы понадобится Java не старше версии 8.0. Также нужны будут фреймворк Apache Maven 3 ручное тестирование api.zero.three или новее и JSON-процессор Jackson 2.four.5 или новее. При написании спецификации редактор Swagger Editor в режиме реального времени проверяет инструкцию на предмет её валидности. Таким образом, можно быстро исправить ошибку.
API может быть внутренним, частным — когда программные компоненты связаны между собой и используются внутри системы. Чтобы узнать больше о том, что именно тестировать при проверке API, прочитайте эту статью, которая чудесно объясняет этот вопрос на примере Postman. При помощи Python вы можете анализировать данные json, легко извлекая и валидируя текст или число. Чтобы лучше познакомиться с Fiddler, прочитайте эту статью, а для Wireshark – эту.
Это становится сложнее, если вам нужно добавить параметры, авторизацию, или проанализировать данные, но весь процесс хорошо документирован. Давайте рассмотрим конкретный пример, используя API numbersapi.com. Эти два приложения очень полезны для анализа сетевых пакетов. Это мощные программы, которыми в обязательном порядке надо владеть, тестируя безопасность, сеть и производительность, а также проверяя пакеты на микро-уровне. Они помогают увидеть, какие конкретно данные пересылаются через сеть. Для веб-вызовов используется два основных метода – GET (для получения информации с сервера) и POST (для отправки информации на сервер).
В opensource есть два больших, достаточно популярных проекта. Это Swagger Codegen, он на данный момент поддерживается компанией SmartBear. И OpenAPI Generator, тоже opensource-проект, но он поддерживается комьюнити. OpenAPI-спецификация — это opensource-проект, описывающий спецификацию и поддерживаемый линукс-сообществом (Linux Foundation Collaborative Project). Это популярный проект, у него звёздочек на GitHub.
- Чтобы запустить коллекцию тестов, зайдите во вкладку «Коллекции», выберите необходимую коллекцию и в выпадающем списке выберите «Run Collection».
- Чтобы создать запрос, нужно нажать на кнопку New и выбрать пункт Request.
- Пожалуйста, посетите официальный сайт, чтобы узнать больше.
- Как можно увидеть, спецификации OpenAPI и инструменты Swagger Editor/Swagger являются неотъемлемыми атрибутами в процессе тестирования API.
- Всё благодаря этой замечательной странице Swagger UI.
Пример реализации генерации API тестов на основе OpenAPI спецификаций можно посмотреть тут с Java + RestAssured + Maven/Gradle. Пример тестовой OpenAPI-спецификации в форматах JSON и YAML. OpenAPI — инструмент, который часто используется разработчиками и аналитиками. Но и тестировщики могут применить его, чтобы ускорить работу. API (Application Programming Interface) – это набор инструкций и протоколов, которые позволяют программам взаимодействовать между собой.
Тогда мы получим шаблоны тестов, которые можно использовать и писать. Значения в OpenAPI-спецификации второй версии хранятся в поле «x-exаmple». Возьмём в качестве примера простейшую операцию GET /store/Inventory из Story API и попробуем написать тест. Мы будем делать простейший запрос без параметров и валидировать ответ.
Пожалуйста, учтите, что упомянутыми ниже инструментами их спектр для API тестирования не ограничен. Я говорю именно об этих, потому что ими я уже пользовалась. Есть проект SwaggerHub, облачная платформа, которая позволяет использовать возможности Swagger онлайн. Для доступа к ней предлагается три тарифных плана. План Free — бесплатный; платные планы Teams и Enterprise предназначены для компаний. Так что начинающий разработчик может пользоваться проектом и не платить за него.
Я дал только ограниченные примеры их использования. Но гибкие возможности OpenAPI позволяют существенно автоматизировать рутинные процессы тестирования и сделать жизнь тестировщика проще. Здесь пример теста, который просто сравнивает эти два ответа. У нас есть функция, которую принимает API-клиент и возвращает ответ, который мы сравниваем через matcher jsonEquals.