Тестирование API (API - Application Programming Interface)

Каждый день используя любимые мобильные приложения и веб-ресурсы вы незаметно взаимодействуете с API, скрытым под интерфейсом пользователя.

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

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

Можете попробовать взаимодействие с API сами: отправляете GET запрос на https://reqres.in/api/users, и получаете в ответ список пользователей. Это очень удобно, когда вы хотите предоставить интерфейс взаимодействия со своим сервисом сторонним лицам. Например, у google, instagram, vk и, в общем-то, всех популярных продуктов есть открытая часть API. То есть у вас есть документ с перечнем того, что и как можно спросить и что вам на это придет в ответ. Взаимодействовать с API можно и с веб-страницы, и с помощью специальных инструментов и напрямую из кода. Помимо прочего, API бывает не только в контексте сетей, например, в той же системе Android есть внутреннее системное API.

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

https://cdn-images-1.medium.com/fit/t/1600/480/0*xP5HjXhJk383Jkyz.png

Типы тестирования API:

• Unit testing: Для проверки функциональности отдельной операции;

• Functional testing: Чтобы проверить функциональность более широких сценариев с помощью блока результатов unit-тестирования, протестированных вместе;

• Load testing: Чтобы проверить функциональность и производительность под нагрузкой;

• Runtime/Error Detection: Мониторинг приложения для выявления проблем, таких как исключения и утечки ресурсов;

• Security testing: Чтобы гарантировать, что реализация API защищена от внешних угроз;

• UI testing: Это выполняется как часть end-to-end integration тестов, чтобы убедиться, что каждый аспект пользовательского интерфейса функционирует должным образом;

• Interoperability and WS Compliance testing: Совместимость и WS Compliance testing - это тип тестирования, который применяется к SOAP API. Функциональная совместимость между API-интерфейсами SOAP проверяется путем обеспечения соответствия профилям функциональной совместимости веб-служб. Соответствие WS- * проверено, чтобы гарантировать, что стандарты, такие как WS-Addressing, WS-Discovery, WS-Federation, WS-Policy, WS-Security и WS-Trust, должным образом реализованы и используются;

• Penetration testing: Чтобы найти уязвимости при атаках злоумышленников;

• Fuzz testing: Для проверки API путем принудительного ввода в систему некорректных данных для попытки принудительного сбоя;

• Usability testing: проверяет, является ли API функциональным и удобным для пользователя и хорошо ли интегрируется с другой платформой;

• Documentation testing: команда тестирования должна убедиться, что документация соответствует требованиям и предоставляет достаточно информации для взаимодействия с API. Документация должна быть частью окончательного результата;

Примеры проблем, которые обнаруживает тестирование API:

• Некорректная обработка условий ошибки;

• Неиспользуемые флаги;

• Отсутствующие или повторяющиеся функции;

• Вопросы надежности;

• Сложность подключения и получения ответа от API;

• Проблемы с безопасностью;

• Проблемы с многопоточностью;

• Проблемы с производительностью. Время отклика API очень велико;

• Неправильные ошибки / предупреждение вызывающему абоненту;

• Неправильная обработка допустимых значений аргументов;

• Данные ответа неправильно структурированы (JSON или XML);

Контрактное тестирование API

В общем случае контрактное тестирование или Consumer Driven Contract (CDC) является связующим звеном между модульным и интеграционным тестированием.

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

• Пишут подробное описание спецификации интерфейса - контракт;

• Реализуют сервис поставщика согласно спецификации;

• Передают спецификацию интерфейса потребителю;

• Ждут реализации от другой стороны;

• Запускают ручные системные тесты, чтобы всё проверить;

• Держат кулачки, что обе стороны будут вечно соблюдать описанный интерфейс;

Сегодня многие компании заменили последние два шага на автоматизированные контрактные тесты, которые регулярно проверяют соответствие описания и реализации у поставщика и потребителя определенного контракта. Что является набором регрессионных тестов, которые обеспечивают раннее обнаружение отклонения от контракта.

Разберемся во взаимодействии на примере REST архитектуры: поставщик создает API c некоторым endpoint, а потребитель отправляет запрос к API, например, с целью получения данных или выполнения изменений в другом приложении. Это контракт, который описывается с помощью DSL (domain-specific language). Он включает API описание в форме сценариев взаимодействия между потребителем и поставщиком. С помощью CDC выполняется тестирование клиента и API с использованием заглушек, которые собираются на основе контракта. Основной задачей CDC является сближение восприятия между командами разработчиков API и разработчиков клиента. Таким образом, участники команды потребителей пишут CDC тесты (для всех данных проекта разработки), чтобы команда поставщика смогла запустить тесты и проверить API. В итоге команда поставщика с легкостью разработает свой API, используя тесты CDC. Результатом прогона контрактных тестов является понимание, что поставщик уверен в исправной работе API у потребителя. Следует обратить внимание, что команда потребителя должна регулярно осуществлять поддержку CDC-тестов при каждом изменении, и вовремя передавать всю информацию команде поставщика. Если регулярно фиксируем неудачно выполненные CDC-тесты, то следует пойти (в буквальном смысле слова, к пострадавшей стороне теста и узнать, в рамках какой задачи были изменения (что привело к падению теста).

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

• Команда разработчиков (тестировщиков) со стороны потребителей пишет автоматизированные тесты с ожидаемыми параметрами со стороны потребителей.

• Тесты передаются команде поставщика.

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

Минусы CDC:

• CDC тесты не заменяют E2E тесты. По факту я склонен отнести CDC к заглушкам, которые являются моделями реальных компонентов, но не являются ими, т.е. это еще одна абстракция, которую нужно поддерживать и применять в нужных местах (сложно реализовать сложные сценарии);

• CDC тесты не заменяют функциональные тесты API. Лично придерживаюсь золотого правила - если убрать контракт и это не вызывает ошибки или неправильную работу клиента, то значит он не нужен. Пример: Нет необходимости проверять все коды ошибок через контракт, если клиент обрабатывает их (ошибки) одинаково. Таким образом контракт то, что важно для клиента сервиса, а не наоборот;

• CDC тесты дороже в поддержке, чем функциональные тесты;

• Для реализации CDC-тестов нужно использовать (изучать) отдельные инструменты тестирования - Spring Cloud Contract, PACT;

Отличие API от SDK:

SDK (software development kit) - это набор функционала (библиотек) и утилит для разработки. Собственно SDK и предоставляет реализацию некоторого API, это оболочка API's, которая упрощает работу для разработчиков.

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

• SDK: набор реальных инструментов внедрения. Это как чемодан деталей и инструментов, который позволяет вам подключиться к телефонной системе или электрической проводке. Это библиотеки, в которых реализованы вызываемые функции + файлы необходимые для подключения этих библиотек;

Тестирование API без документации/черным ящиком:

Если Вам по какой-то причине предстоит проделать эту неблагодарную работу, определитесь, насколько все плохо и какая у Вас есть информация об объекте тестирования. Известно ли какие порты для Вас открыты? Знаете ли Вы нужные endpoints? Если дело совсем плохо - просканируйте порты, например, с помощью netcat. Открытые порты сохраните в файл. Эта операция займет довольно много времени. Можете почитать советы по работе с Nmap и Netcat. Если Вам известен нужный порт и соответствующий endpoint - переберите все возможные HTTP методы. Начните с наиболее очевидных POST, PUT, GET. Для ускорения процесса напишите скрипт, например, на Python.В худшем случае, когда ни порт ни endpoints неизвестны Вам, скорее всего придется перебирать все открытые порты и генерировать endpoints, которые подходят по смыслу. Разработчики обычно не особо заморачиваются и закладывают минимально-необходимую информацию. Так что включите воображение и попробуйте придумать endpoints опираясь на бизнес логику и принятые в Вашей компании стандарты. Если ни endpoints ни бизнес логика Вам неизвестны, то у меня есть подозрение, что Вы тестируете API с не самыми хорошими намерениями.

Источники:

• API Testing Tutorial: What is API Test Automation? How to Test

• A Comprehensive API Testing Guide

• API Testing Tutorial: A Complete Guide For Beginners

• Spring Cloud Contract. Что такое контрактное тестирование и с чем его едят

• Чем отличается api от sdk?

• Тестирование API без документации

Доп. материал:

• Список полезных статей и видео для изучения тестирования API

• Тестирование GraphQL

• Удачный шаблон документации на API, который будут читать

• Игорь Гольшмидт. АPI тестирование без документации

• Курс Тестирование ПО. Занятие 29. Тестирование API - QA START UP

• Курс Тестировщика с нуля / 27 урок/ Тестирование API с помощью Postman

• Rest Assured и Postman - два подхода к тестированию API

• Эвристики и мнемоники в тестировании: шаблоны для тестирования API

• От шока до принятия: пять стадий тестирования API

• Тестирование API

• Swagger/OpenAPI Specification как основа для ваших приемочных тестов

• История одного сервера и тестировщика Васи

• What Is an API?

• Тестирование API простыми словами за 8 минут / Тестировщик API

• Тестирование Web API - From Zero To Hero

• Стратегия тестирования REST API: что именно вам нужно тестировать?

• Test Design and Automation for Rest API. Part 1. Иван Катунов. Comaqa Spring 2018 + Test Design and Automation for Rest API. Part 2. Иван Катунов. Comaqa Spring 2018 + pdf

• What is the Difference Between an API and an SDK?

• Introduction to API Testing

• 19:05 «Контрактное тестирование Rest API» + презентация

• Организация контрактного тестирования микросервисов и графического портала

• Introduction To Contract Testing With Examples

• Микросервисы для разработчиков Java: Контрактное тестирование

• Как тестировать GraphQL API? Гайд для начинающих

• Что такое API

• Что такое API

• Как передать в API фото формата base64

• API: под каким углом на них смотреть