Автор: Ноэми Феррера (Noemi Ferrera)
Оригинал статьи
Перевод: Ольга Алифанова

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

Если вам интересно, как это выглядит в веб-приложении, то можно просто посмотреть на вкладку "Сеть" в панели инструментов разработчика. вы увидите, что при взаимодействии с веб-сайтом в фоновом режиме осуществляется множество вызовов.

Вкладка "Сеть" в Chrome для сайта google.com

Если кликнуть на вызов в левой части панели, в правой части появится информация о нем. URL запроса – это адрес, которого пытается достичь вызов.

Для веб-вызовов используется два основных метода – GET (для получения информации с сервера) и POST (для отправки информации на сервер). Узнать больше о других методах можно здесь.

Следующее поле тоже очень важно. Это сообщение, которое сервер отправляет после выполнения вызова. В этом случае это 307 (перенаправление). Узнать, что значат другие коды статусов, можно по этой ссылке, если вы кошатник, или этой, если предпочитаете собак.

Для отправки информации между устройствами используется два широко применяемых протокола – SOAP (простой протокол доступа к объектам), отправляющий информацию в формате XML, и REST (передача состояний представления), передающий информацию в различных форматах – это может быть json, html, xml, и чистый текст (см. статью, поясняющую их особенности).

Инструменты тестирования API

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

В следующей секции я покажу, как провести тест API.

Swagger

Согласно официальному сайту, Swagger – это профессиональный инструментарий с открытым исходным кодом, который "упрощает разработку API для пользователей, команд и предприятий".

https://swagger.io/tools/swagger-ui/

Я пользовалась Swagger UI, чтобы легко проверить API URL, разобраться в вызовах, а затем добавить их в код моих тестов, но опробовала не все инструменты Swagger. Мне кажется, это простой способ сообщить команде об изменениях API и задокументировать их.

В качестве альтернативы разработчики могут документировать вызовы API в другом формате – обычно списком, как сделано у Twitter. Проблема тут в том, что такая документация может устаревать, и затем надо копаться в коде разработки, чтобы понять, как конкретно выглядит этот вызов. Swagger подтягивает набор вызовов напрямую из кода, поэтому с ним проще работать и поддерживать актуальность документации.

Swagger сделан компанией SmartBear, как и SoapUI, поэтому для тестирования API с их помощью прочитайте следующую секцию.

SoapUI и Postman

SoapUI - это "Полный фреймворк автоматизации тестирования API для SOAP, REST, и многого другого". У него есть версия с открытым исходным кодом, а также профессиональная версия, в которой шире функциональность. Тестирование API выглядит так:

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:

https://www.soapui.org/docs/endpoint-explorer.html

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

Postman – это "платформа для совместной разработки API". Для разработчиков Постман предоставляет автоматическую документацию, и это ликвидирует проблему, при которой разработчики меняют функциональность, а затем забывают сообщить об этом.

Приступить к тестированию API с Postman очень легко. Вы можете создавать запросы REST, SOAP и GraphQL. Инструмент поддерживает множество протоколов авторизации (я расскажу об этом позже) и управление сертификатами. Пожалуйста, посетите официальный сайт, чтобы узнать больше.

Wireshark и Fiddler

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

Несмотря на это, я использовала Wireshark и Fiddler для тестирования API, требовавшего особых сертификатов безопасности, а также для дебага проблем (особенно проблем производительности). Чтобы лучше познакомиться с Fiddler, прочитайте эту статью, а для Wireshark – эту.

https://blog.wireshark.org/

Как это автоматизировать?

Если вы хотите добавить тесты API в свой код автоматизации, вышеуказанные инструменты помогут вам в этом. Однако в разных языках программирования различаются способы выполнения таких типов вызовов. К примеру, вот так делается REST-вызов в Python:

Это становится сложнее, если вам нужно добавить параметры, авторизацию, или проанализировать данные, но весь процесс хорошо документирован. Давайте рассмотрим конкретный пример, используя API numbersapi.com.

Результат после выполнения кода выше:

200

{'text': '42 is the result given by the web search engines Google, Wolfram Alpha and Bing when the query "the answer to life the universe and everything" is entered as a search.', 'number': 42, 'found': True, 'type': 'trivia'}

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

Обсудить в форуме