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

Тестирование API включает как прямую (изолированную) проверку API, так и тестирование в составе сквозных сценариев в ходе интеграционного тестирования^[1]. Помимо REST-интерфейсов, такие сценарии охватывают различные конечные точки: веб-сервисы, ESB, базы данных, мэйнфреймы, веб-интерфейсы, ERP-системы. Тестирование API проводится как для API, разрабатываемых командой, так и для сторонних API, используемых в приложении^[4].

Тестирование API позволяет убедиться, что API корректно формирует ответы (в ожидаемом формате) на широкий спектр допустимых запросов, правильно реагирует на граничные условия, отказы и нештатные/экстремальные входные данные, выдаёт ответы в пределах допустимого времени, а также устойчиво к возможным атакам на безопасность^[1]. Для изоляции тестируемых сервисов и расширения доступа к окружениям часто применяют виртуализация сервисов, позволяющую эмулировать недоступные API/сервисы^[5].

Обычно тестирование API включает работу с REST-API или SOAP-веб-сервисами, при этом JSON или XML используются как форматы обмена сообщениями по HTTP, HTTPS, JMS и MQ^[2].^[6] Также могут применяться форматы сообщений SWIFT, FIX, EDI и другие форматы с фиксированной длиной, CSV, ISO 8583, Protocol Buffers, передаваемые по различным транспортам/протоколам, таким как TCP/IP, ISO 8583, MQTT, FIX, RMI, SMTP, TIBCO Rendezvous^[7].

Тестирование API признано более пригодным для автоматизации тестирования и непрерывное тестирование (особенно при использовании Agile и DevOps) по сравнению с тестированием GUI^[3].^[8] Среди причин выделяют:

• Сложность системы: Тесты интерфейса пользователя не способны полноценно проверить функциональные пути и внутренние API/сервисы многослойных архитектур. API считается самым стабильным интерфейсом тестируемой системы.
• Короткие релизные циклы и быстрые обратные связи: Команды Agile и DevOps, работающие в коротких итерациях, отмечают, что тесты пользовательского интерфейса требуют значительных доработок для поддержки частых изменений. Тесты на уровне API менее хрупки и легче в сопровождении.

По этим причинам рекомендуется повышать долю тестирования на уровне API и снижать зависимость от тестов интерфейса. Автоматизация тестирования в большинстве случаев строится вокруг API-тестов и максимально автоматизированного тестирования граничных условий. Тесты графического интерфейса оставляют для проверки типичных сценариев на уровне всей системы, тестов мобильных приложений и оценки удобства использования^[3].

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

• Использование искусственного интеллекта (AI) в тестировании API повышает эффективность и точность тестирования; ИИ способен автоматически генерировать тест-кейсы, выявлять потенциальные проблемы и анализировать результаты тестов с помощью машинного обучения для поиска закономерностей и аномалий^[9].
• Дымовой тест — предварительное тестирование для проверки работы базовых функций API и выявления критических сбоев перед более глубокой проверкой.
• Функциональное тестирование — валидация программной системы относительно функциональных требований путём подачи входных данных и проверки соответствия выхода. Обычно реализуется как тестирование «чёрного ящика», без анализа исходного кода.
• Тестирование чёрного ящика — тестирование, при котором взаимодействие с API происходит без знаний о его внутреннем устройстве; на основании входа и выхода определяют корректность работы API при штатных и нештатных сценариях.
• Модульное тестирование — проверка мельчайших частей приложения («юнитов»), в случае API — тестирование отдельных конечных точек с одиночными запросами.
• Тестирование на совместимость — проверяет, может ли API беспрепятственно взаимодействовать с другими программными компонентами и системами (характерно для SOAP-API).
• Тестирование надёжности — определяет, соблюдает ли API требования по функционалу, надёжности, производительности и безопасности. Цель — гарантировать стабильную работу.
• Валидационное тестирование — подтверждает соответствие программного продукта бизнес-требованиям и ожидаемым результатам (аналог тестирования на приёмку).
• Выявление ошибок времени выполнения — выявление ошибок работы API в реальном времени, анализ сбоев, утечек ресурсов и других проблем исполнения.
• Фаззинг — подача в API случайных, некорректных или неожиданных данных для поиска неизвестных ошибок и уязвимостей. Специальные инструменты (фаззеры) генерируют запросы и анализируют реакцию API.
• Нагрузочный тест — моделирует реальные пользовательские нагрузки для поиска узких мест и определения максимального числа пользователей или операций, доступных системе.
• Тестирование производительности — оценка работы API в условиях высокой нагрузки и различных сценариев для проверки способности сохранять необходимый уровень производительности. Сюда относят функциональное тестирование производительности и нагрузочное тестирование.
• Тестирование безопасности — поиск уязвимостей и устранение недостатков безопасности API, в том числе имитация действий злоумышленника и предотвращение несанкционированного доступа и атак.
• Тест на проникновение (пентест) — этичное взломывание API внешними специалистами «с чёрной коробкой», поиск уязвимостей интеграций до выявления ошибок бизнес-логики или реализации.
• Тестирование на соответствие WS-* — тесты для SOAP-API, проверяющие реализацию стандартов WS-Addressing, WS-Discovery, WS-Federation, WS-Policy, WS-Security, WS-Trust.
• Тестирование Web UI — проверка, верно ли отображаются и работают визуальные элементы пользовательского интерфейса веб-приложения. В отличие от API-тестирования, здесь тестируется внешний вид, а не коммуникация между компонентами.