Непрерывное тестирование API

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

Стратегия тестирования API становится необходимой частью жизненного цикла разработки API. Организация системы тестирования API является такой же важной частью как и проектирование его интерфейса.

БЕСПЛАТНО СКАЧАТЬ КНИГИ в телеграм канале "Библиотека тестировщика"

Необходимость наличия жесткой обратной связи

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

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

Ваш конвейер тестирования API должен состоять из 3 ключевых этапов:.

1. Хорошо проработанные тесты для ваших API.
2. Возможность запуска тестов по требованию и по расписанию.
3. Сообщать о результатах тестов в системы оповещения и аналитики.

Написание хороших тестов

Система тестирования настолько хороша, насколько хороши тесты. Все начинается с хорошо написанных тестов. Когда речь идет о тестировании API, необходимо проверять ответы, отправляемые приложением.

Вы можете проверить структуру данных ответа, наличие (или отсутствие) определенных параметров в ответе, время ответа, заголовки ответа, cookies и статус ответа. Если ваш API работает не по протоколу HTTP, то эти семантические характеристики могут отличаться. Это более серьезная тема для обсуждения, но основные моменты, которые вы будете проверять в ответе, останутся теми же.

Для всего этого необходимы хорошие тестовые примеры. Эти тестовые примеры должны соответствовать бизнес-требованиям. Это могут быть кейсы пользователей, пути пользователей или сквозные рабочие процессы. Тестовые случаи можно документировать в виде BDD-спецификаций или в виде эпиков/историй в платформе управления продуктом или в Postman Collections.

Вы можете выбрать любой инструмент по своему усмотрению, лишь бы у вас была возможность создавать такие тесты, желательно совместно, и выполнять их в нужный момент.

Выполняйте тесты по требованию или по расписанию

Это ключ к непрерывному тестированию. Чтобы перейти к этому этапу, необходимо иметь конвейер непрерывной интеграции (CI). Предполагается, что часть API-тестов будет выполняться во время сборки, а часть – по расписанию. Периодичность выполнения зависит от масштаба системы и частоты фиксации изменений кода.

Выполнение по требованию: Вы будете запускать контрактные, интеграционные и сквозные тесты в системе сборки. Изменения кода, слияния и потоки релизов являются типичными источниками, запускающими конвейеры сборки. В зависимости от того, как настроены конвейеры сборки, каждый этап тестирования может быть запущен только после прохождения предыдущих этапов. На рисунке ниже показано, как устроены конвейеры непрерывного развертывания Postman.

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

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

Аналитика и оповещение

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

Системы оповещения позволят заинтересованным лицам узнать о сбое в работе системы, в данном случае это должны быть неудачные тесты. Здесь можно использовать такие сервисы, как Pagerduty или BigPanda. Если вы используете Slack на работе, вы также можете отправлять уведомления в Slack.

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

Непрерывное тестирование с помощью Postman

Философия непрерывного тестирования не зависит от инструментов. Но если вы хотите внедрить непрерывное тестирование в своей организации с помощью Postman, то вот руководство. Давайте сопоставим три ключевых этапа конвейера тестирования API, о которых я говорил выше, с возможностями, которые предоставляет Postman.

1. Написание хороших тестов – Коллекции: Именно здесь Postman Collections приходят на помощь. Коллекция – это группа API-запросов, которые можно выполнить за один раз. Вы можете писать тесты для каждого запроса и для группы запросов. Postman сообщает вам, сколько тестов прошло или не прошло, когда вы запускаете коллекцию. Вы можете иметь коллекции для каждого набора тестов. Например, у вас будет коллекция, выполняющая контрактные тесты ожиданий данного потребителя по отношению к производителю, и отдельная коллекция, выполняющая проверку работоспособности данного сервиса.
2. Запуск тестов – newman и мониторов: Вы нужно будет интегрировать newman, программу запуска коллекций из командной строки Postman, в свои CI-системы и запускать коллекции по требованию как часть своего CI-конвейера. Они запускаются на вашей установке. С другой стороны,  Мониторы в Postman позволяют планировать запуск коллекций на заранее заданные интервалы времени. Мониторы могут работать в нескольких регионах по всему миру. Они работают в облачной инфраструктуре Postman.
3. Аналитика и оповещение – Интеграции и пользовательские запросы: Postman имеет предопределенные интеграции с внешними сервисами. Ваши запуски мониторов могут интегрироваться с системами аналитики и отслеживать результаты запусков в течение определенного периода времени. Также имеются интеграции с системами уведомлений, которые могут предупреждать вас в случае неудачных запусков мониторов. Кроме того, всегда можно включить запросы в свою коллекцию, которые передают данные сторонним службам. Это полезно, когда вы выполняете свои коллекции на собственной инфраструктуре с использованием newman.

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

Наконец, вот довольно большая иллюстрация, достойная плаката, показывающая, как эти элементы концептуально сочетаются друг с другом.

Перевод статьи «Continuous Testing of APIs».